LGB/Marklin new stock with Marklin decoder - ?problems?

PhilP

PhilP

G Scale, 7/8th's, Electronics
TRADER
Country flag
All,
Whilst at GRS yesterday, I was asked to look at a new Marklin/LGB BR139 that a Client had brought back..

It would appear that you are not able to change the loco (short) address in the normal way on these decoders??

Using a Massoth Central Station / Navigator, I was not able to get a 'tick' when changing the loco address.
An Anglo-German email from LGB referred to the lgb.de website, and a 'CV calaculator'..
This appears to be for long addresses, where you set CV's 17 and 18 for addresses above 256.

Putting the German text through Google translate was less than informative.

I have not been able to find either the instructions for this loco, or the decoder it contains online as yet.

Any thoughts People?
TIA.
PhilP.
 
Here is the link to the multi-lingual manual: http://medienpdb.maerklin.de/product_files/7/pdf/20755_betrieb.pdf
 
So, according to the manual.. It should be possible to change this using our 'normal' methods..

Probably a 'red-herring'??
With the Allegra, we needed a 'special' lead, so as to allow programming, as the loco took way too much current if everything was 'on'. - I do not believe this to be a problem with this model though?
 
I don't know which decoder is installed in the BR 139, but here's some info on the new Märklin style 27 pin decoder: http://www.gscalenews.com/pdf/lgb/lgb-decoder-interface-info.pdf
 
Thanks for both sets of information Gentlemen..

An 'alarm bell' is starting to ring.. I wonder if the 'long address' bit in CV 29 has been set? - Wondering if it has, whether it will affect being able to directly program a short address to CV1??

This supposes that ALL a Massoth does is write to CV1 when you change the address??
 
When you change a loco address with the Navigator (using the "Loco Address" function) it will change CV29 as well - to set the speed steps and if it is using a long/short address.
 
muns said:
When you change a loco address with the Navigator (using the "Loco Address" function) it will change CV29 as well - to set the speed steps and if it is using a long/short address.
Click to expand...
So this may / may not work with a different make of decoder then?
Next question is can the Navigator change CV1 using the 'change CV' function?
 
CV29 is also NMRA standard so what the Massoth Navigator does should work the same for any decoder the claims to be NMRA DCC compliant. The Marklin decoder is supposed to be compliant isn't it? They'd be stupid NOT to make it so.

This is where I feel something like JMRI/SPROG (or equivalent the LGB programmer) is a better / friendlier tool, you can use it to read the existing CV29 setting and be sure you're ONLY affecting the speed steps and long address bits and nothing else (so not touching the "reverse direction" or "analogue operation" bits etc.)
 
Used the Sprog on a Massoth XLS M1 yesterday = no prob. I'll play with the navvy later
 
stockers said:
Used the Sprog on a <assoth XLS M1 yesterday = no prob. I'll play with the navvy later
Click to expand...

Wouldn't expect any problems programming a Massoth decoder either way. The M1 is simply a new pin arrangement specifically for the new Marklin socket isn't it?

The concern in this thread is more to do with the Marklin decoders and how their firmware behaves. I get the impression the Marklin decoders are very closely related (or identical) to their gauge 1 multi protocol decoders that have been around for a while.
 
ntpntpntp said:
Wouldn't expect any problems programming a Massoth decoder either way. The M1 is simply a new pin arrangement specifically for the new Marklin socket isn't it?

The concern in this thread is more to do with the Marklin decoders and how their firmware behaves. I get the impression the Marklin decoders are very closely related (or identical) to their gauge 1 multi protocol decoders that have been around for a while.
Click to expand...
Yes.. BUT I am talking about a Massoth Nav. to a Marklin decoder..

There are other 'gotcha's' with a XLS-M1 to be aware of..
 
I do find it intriguing that there's no obvious JMRI decoder template for the Marklin decoder family to which the large scale decoder seems to belong, which is why I posted elsewhere asking whether anyone had tried talking to these Marklin decoders with a SPROG. Does the lack of a template mean the decoder doesn't conform well to NMRA programming specs (doubtful but you never know) or does it simply mean no-one's got around to creating a template yet?

I'd love to investigate, but as I run American stuff and I'm not actively buying new locos anyway I don't anticipate getting my hands on anything with a Marklin decoder - unless a friend ends up with something and drops round for help!
 
I suspect that no one has created a decoder template yet.....if I had the time I would probably try and create one but as it (time) seems to whittle away without a care in the world to what one needs (wants) to do I doubt I will get to it.

In any case, will be interested in your response to Jon's question Phil?
 
Zerogee said:
What might those be, Phil?

Jon.
Click to expand...

The main gripe is Massoth sell a XLS-M1 'kit' for the Rhatia loco. This consists of a decoder (with the sound-file loaded) and the relevant loudspeaker to fit the loco.
Now, if you do not know better, or do not read the book, would you not expect to be able to 'plug and play' this decoder?
Well for a start, ALL Massoth decoders come with function outputs at full track voltage. - We KNOW this is a given, but you would sort-of expect a decoder sold for a specific model (and release) of loco to be preset, would you not?

Then there are the cab-light, and firebox lights. These are fed from A2 and A3 in the loco. So you actually turn them off and on when you activate certain sound functions.. Or is it you activate sounds and the lights go on and off!

I have recently fitted standard XLS, XlS-M1, a reed switch trigger board, volume controls, manual switch for smoke, pulsed smoke, and hall effect axle to this loco. Only the physical installation of the XLS-M1 and loudspeaker are straight forward.

Once I get time to marshall my thoughts, and pictures, I will post how-to's here.
 
Thanks Phil, will be interested in your further notes and how-tos.....

Yes, I would expect any decoder to be plug-and-play when it is supplied configured for a particular loco.

Re the lighting voltage, as the XLS-M1 is plugged into the loco's interface board doesn't the lighting power still go through whatever voltage regulation circuitry is installed already for analogue-mode operation? It's not like converting an old loco without an interface, where everything is rewired straight to the decoder...?

Mark (Muns) - as I still haven't found the time to plug the XLS-M1 into my new Franzburg - when I do, do you know if there is anything that I need to adjust CV-wise before powering up the loco, or should everything be pre-set in this case?

Jon.
 
As Jon correctly says it doesn't matter what the voltage of the function outputs is set to when connecting a decoder to the 10 pin LGB DCC interface. That is because there is electronics on the LGB board to handle ANY voltage output by the functions on the decoder.

Are we saying here that the new 27 pin interface does NOT have this protection build it? Clarification on this point would be useful.

Did you actually manage to blow all of the lights Phil by putting in a decoder will full track output on its functions?
 
Cliff George said:
Are we saying here that the new 27 pin interface does NOT have this protection build it? Clarification on this point would be useful.
Click to expand...

I would consider that to be bad design by Marklin if it is indeed the case. I've said it before, relying on the decoder to control function voltage is a bad idea as typically a decoder reset will put function outputs back to full voltage. An interface should be designed to expect typical inputs from any decoder, not assume a specific decoder with pre-set modifications.
 
ntpntpntp said:
I would consider that to be bad design by Marklin if it is indeed the case. I've said it before, relying on the decoder to control function voltage is a bad idea as typically a decoder reset will put function outputs back to full voltage. An interface should be designed to expect typical inputs from any decoder, not assume a specific decoder with pre-set modifications.
Click to expand...
Ah, you see it is designed by highly intelligent members of the human race.. They, like programmers, assume the whole race are as intelligent as they are.. ;)
The problem with 'idiots' (the rest of us) is they under estimate our ability to use ingenuity to b*lls things up!! ??? :o
::) ;) :D ;D ;D
 
You must log in or register to reply here.
Back
Top Bottom