Can a 'Serial' Central Station control a 'Parallel' decoder's speed?
- Thread starter Sammler
- Start date
Thanks for the replies.
Another question! Could an LGB parallel-only Central Station (or maybe a Roco Multi Maus system) be used to control the speed and direction of an old digital locomotive that has a serial-only decoder such as the LGB 55020?
Another question! Could an LGB parallel-only Central Station (or maybe a Roco Multi Maus system) be used to control the speed and direction of an old digital locomotive that has a serial-only decoder such as the LGB 55020?
Yes, the "serial" stuff relates to how functions are switched off and on, not how speed and direction are controlled.
Never had to try it myself, but I believe I read somewhere that with practice you can repeatedly press F1 on a "parallel" system at the appropriate rate to simulate the serial pulses and activate the functions on an old serial-only decoder.
Never had to try it myself, but I believe I read somewhere that with practice you can repeatedly press F1 on a "parallel" system at the appropriate rate to simulate the serial pulses and activate the functions on an old serial-only decoder.
But not for new Marklin/LGB models with their decoder I am afraid..Sammler said:Thanks. It looks like my MTS 1 still have a few years left in it
Good news: I have just fitted the 'older' style XLS in a couple of the new-interface loco's.. So it will still be possible to produce a version for the older MTS equipment users.
Just to be clear about the new Marklin decoders (paraphrasing from a Markin document I found on champex-linden website): they are shipped set to 28 speed steps, but can be programmed to 14 speed steps so should be drivable with MTS1. However the new decoders don't understand serial function commands. Reprogramming to 14 speed steps can done with the LGB 55015 "p" or other NMRA DCC systems via the setting of CV29 bit 1.
It seems there are also some differences in the way the new decoders deal with functions: with the new decoders switching a function on or off on the throttle directly affects that function in the decoder, whereas with the old decoders it was a change from high to low that toggled the function on and another change from high to low that toggled it off again (so a kind of momentary operation?)
Here's the link to the document (in german):
https://www.champex-linden.de/download_fremddokumente_2014/2014_lgb_aenderungen_digitalsystem.pdf
It's well past time to move on from MTS1 I think.
It seems there are also some differences in the way the new decoders deal with functions: with the new decoders switching a function on or off on the throttle directly affects that function in the decoder, whereas with the old decoders it was a change from high to low that toggled the function on and another change from high to low that toggled it off again (so a kind of momentary operation?)
Here's the link to the document (in german):
https://www.champex-linden.de/download_fremddokumente_2014/2014_lgb_aenderungen_digitalsystem.pdf
It's well past time to move on from MTS1 I think.
Nick, are you saying that it looks like the marklin decoder switches on and then off as two diffferent processes, where as the usual method is to just send the same pulse as a trigger each time you activate it.
If so this will be useful for things like smoke where you want it on or off, not just triggered
If so this will be useful for things like smoke where you want it on or off, not just triggered
This will depend on how the 'switched' item responds to commands.. If it switches on a falling edge (or high to low), and you go from 'off' to 'on' as a rising edge, then you need to press twice to generate the necessary change in logic..
At least, how I read it..
At least, how I read it..
Yeah, well I'd always assumed that on and off were two different command states rather than a toggle, except maybe for things like the horn/whistle function. Maybe it's something that can configured in the command station or throttle (I'll have to dig around in my NCE manual).
[edit]
As far as the NMRA protocol goes, functions are sent as on or off bits within the command byte, so it must depend on how the decoder interprets the on-off change when it receives a new function command, ie. as Marklin have described.
Come to think of it I've noticed the sounds on my old LGB Mikado sometimes require multiple function presses to switch on or off, so maybe that's a symptom of the old "toggle" logic.
[/edit]
[edit]
As far as the NMRA protocol goes, functions are sent as on or off bits within the command byte, so it must depend on how the decoder interprets the on-off change when it receives a new function command, ie. as Marklin have described.
Come to think of it I've noticed the sounds on my old LGB Mikado sometimes require multiple function presses to switch on or off, so maybe that's a symptom of the old "toggle" logic.
[/edit]
Well I asked Peter Ting of Massoth about this very issue several years ago.
(Real) LGB decoders have always acted differently to virtually every other make of decoder in that they would operate a function based on a change of state, whereas all of the others that I know of 'on' would mean 'on' and 'off' would mean 'off'. The 'on' is 'on' way of working is a sort of de-facto standard because I haven't found it written down in any standard. Massoth decoders themselves follow the 'on' means 'on' rule. But it is worse than that these LGB decoders would also remember the state of a function over a power off. If say sound was on when power was removed then when power was restored sound would also be on. This could mean that either turning a function 'on' would actually turn it 'on', or it could mean it actually turned it 'off'!
Peter told me that the LGB way of operating functions was something that LGB had mandated to Massoth.
Now usually this doesn't make much difference since a user has ears and can tell if sound is on or not and can press the function button on his/her handset until the desired state is achieved. For a computer assuming 'on' is 'on' the LGB way of working is not good, because it depends on the state of the function when power was last removed. Sometimes when the computer program thought it was turning the sound on it was actually turning it off, because sound was on when power was last removed.
I probably haven't described that very well but it meant for me I had to take special measures in a computer program when it was controlling an LGB decoder.
I am glad MLGB are changing the way their functions operate so that they follow what everyone else does.
(Real) LGB decoders have always acted differently to virtually every other make of decoder in that they would operate a function based on a change of state, whereas all of the others that I know of 'on' would mean 'on' and 'off' would mean 'off'. The 'on' is 'on' way of working is a sort of de-facto standard because I haven't found it written down in any standard. Massoth decoders themselves follow the 'on' means 'on' rule. But it is worse than that these LGB decoders would also remember the state of a function over a power off. If say sound was on when power was removed then when power was restored sound would also be on. This could mean that either turning a function 'on' would actually turn it 'on', or it could mean it actually turned it 'off'!
Peter told me that the LGB way of operating functions was something that LGB had mandated to Massoth.
Now usually this doesn't make much difference since a user has ears and can tell if sound is on or not and can press the function button on his/her handset until the desired state is achieved. For a computer assuming 'on' is 'on' the LGB way of working is not good, because it depends on the state of the function when power was last removed. Sometimes when the computer program thought it was turning the sound on it was actually turning it off, because sound was on when power was last removed.
I probably haven't described that very well but it meant for me I had to take special measures in a computer program when it was controlling an LGB decoder.
I am glad MLGB are changing the way their functions operate so that they follow what everyone else does.
-
1
- Show all
I received an email from LGB regarding their decoders and older MTS 1 Central Stations:
"thanks for your question.
Future version of the LGB/Märklin Digital Decoder will also be compatible with the LGB MTS 1 & MTS II 'Serial' Central Station.
New LGB Digital products will work with your LGB 55000 and 55005 'Serial' MTS Central Station. The MTS1 still control the direction of an LGB/Marklin Digital locomotive.
Sincerely yours,
your account manager"
"thanks for your question.
Future version of the LGB/Märklin Digital Decoder will also be compatible with the LGB MTS 1 & MTS II 'Serial' Central Station.
New LGB Digital products will work with your LGB 55000 and 55005 'Serial' MTS Central Station. The MTS1 still control the direction of an LGB/Marklin Digital locomotive.
Sincerely yours,
your account manager"
The problem with DCC is there is no feedback to tell the CS, or throttle, or computer, if a command has been received and acted on, or what state the function is in..
DCC systems tend to send the command a number of times, and hope it gets through!
Why no one has done a proprietary system using TCP/IP protocols, I do not know??
DCC systems tend to send the command a number of times, and hope it gets through!
Why no one has done a proprietary system using TCP/IP protocols, I do not know??
PhilP said:
You've not read the "Next Gen interfaces- emerging schemas" thread on MyLargeScale then? Lots of experimentation going on with peer-to-peer wifi networking between intelligent devices etc. I followed it for a while but to be honest good old NMRA DCC is fine for my needs.
Just received an email from Marklin saying that the older MTS controllers and central station won’t work with the latest LGB locomotives such as the new LGB 22963 OBB Class 2095
That likely explains why I have in the past had all sorts of problems getting sound on when you have that and engine start up shut down with dismals and similar with puffers.
-
1
- Show all
Has anyone tried using an LGB Serial Controller and Central Station with a new Marklin loco decoder? I read on another thread that changing the value of CV29 can make the new decoders Serial compatible, though Marklin say the decoder doesn’t work with Serial equipment. Maybe they meant it wouldn’t work “out of the box” with Serial Controllers and Central Stations?
