LGB s and p modes

[don9GLC]

I have to confess to a varied career. I was educated and worked as a professional electrical engineer then I became involved in the legal aspect of contracts. I next made the mistake of applying for a management position which I got and regretted.

So when I read a document I expect it to be technically accurate, unambiguously written and understandable by others less technically trained (or it should be made clear that it is a technical document).

I am often disappointed when it comes to DCC!


As I understand it LGB MZS in s mode sends a single pulse when the F1 key is depressed. If the command station is set to s mode it then waits for a interval for another pulse, and so on until the interval timer times out. It then translates the sequence as a 'word''

Hence, for example, if you press the F1 key 5 times quickly the central station understands that as an F5 command in s mode.

LGB describe this as 'serial' operation as I understand it.


However when set in p mode the F1 key pressed five times will cause the F1 output to switch on, then off, until finally on when the key is no longer activated. But pressing the F5 key once will sent the F5 command to the central station.


I don't have an LGB MZS system so I cannot prove this.


According the the LGB user instructions, setting CV51 bits 1-8 allows 'Only parallel commands (NMRA) via function buttons 1-8' I have done a search on NMRA RP 9.2.2. but cannot find a reference to parallel. CV51 is 'manufacturer reserved'. It is also beyond my technical experience that a parallel connection involves only two conductors. (Two rails to relate the the physical).

I think LGB have done a fantastic job in developing the garden railway hobby. I have many 'red boxes' but I have a fair number of other colors too! However I think they have got it technically incorrect when assigning descriptions to s and p modes.

I believe they are correctly S(ingle) and P(acket) modes and I can well understand why LGB did not want to let technical 'gobbledygook' prevent brining MZS to the marketplace. Even in 2011 I see references to 'the Dark Side'. Your grandchildren would be disgusted at your technical reluctance!


In summary

s = single
p = packet


Have I missed something?
(still counting rivets - and micro processors!)

In case you are wondering, I have been looking at other DCC manufacturers, particularly Lenz and Zimo, so I'm expecting more than what has been on offer for a very long time (in terms of electronic developments)

 

[whatlep]

Don - I believe your understanding of the Massoth/LGB serial vs. parallel mode implementation is correct at a technical level, though a couple of comments are not quite accurate. You may want to check some of the input on http://forum.massoth.com/ in the MZS section (MZS=MTS in German language). May be worth asking the question you pose in your posting.

Remember that when MZS/MTS first appeared in 1998 it was cutting edge stuff and produced by Lenz, not Massoth. MTS evolved rapidly and LGB made sure that there was the ability for existing serial users to carry on without having to upgrade components. Thus my serial handset and serial board fitted locos work very happily with my parallel fitted receiver and central station. Both receiver and central station can receive serial and parallel commands and process them automatically. Indeed I suspect that the receiver has no knowledge of what is received, the parallel upgrade being to do with enhanced reception range via improved components than signal interpretation. Conversely, my parallel fitted handset can equally happily issue serial commands which is what they do most of the time. For non-sound types like me it's pretty much a non-issue.

 

[whatlep]

According the the LGB user instructions, setting CV51 bits 1-8 allows 'Only parallel commands (NMRA) via function buttons 1-8' I have done a search on NMRA RP 9.2.2. but cannot find a reference to parallel. CV51 is 'manufacturer reserved'. It is also beyond my technical experience that a parallel connection involves only two conductors. (Two rails to relate the the physical).

Quick further posting. I think you may want to look at NMRA RP 9.2.1 as well, particularly section C's description of function groups one & two. Looking at that, I suspect that the serial Lenz/LGB implementation pre-dates the NMRA recommendation and is an "illegitimate" solution which LGB/Massoth kit can understand in addition to the NMRA standard.

 

[stockers]

What he said.:holdon:

 

[don9GLC]

Quick further posting. I think you may want to look at NMRA RP 9.2.1 as well, particularly section C's description of function groups one & two. Looking at that, I suspect that the serial Lenz/LGB implementation pre-dates the NMRA recommendation and is an "illegitimate" solution which LGB/Massoth kit can understand in addition to the NMRA standard.

Thanks Peter for the suggestion about RP 9.2.1.

It clarified some of my wooly thinking. It seems its the LGB decoder that processes the repeated keying of the F1 key. The central station probably does not. Its possible that older s mode remotes and central stations cannot generate or transmit the p mode data packets. One day when I'm tired of having fun I might even look at the DCC waveform to confirm.

From my reading of RP 9.2.1 the LGB s mode is not NMRA compliant, as you suggested. However that's probably academic since its only auxiliary functions such as lights, sounds and servos that are affected. And these are older decoders which may not have many or any of these functions.


I noticed on another forum that some people were confused about communication protocols and assumed because Lenz had introduced RailCom that they no longer used CanBus and even thought that this would replace XpressNet.

Of course even in s mode the decoder is receiving a data packet over a serial link. Its the same in p mode so its hard to come up with two expressions that are technically correct but not confusing to those who have limited understanding of communications protocols.

In my opinion LGB are excellent at producing products that simplify the technology so that anyone can use them. Under EU legislation they are technically 'toys' so I'm happy to play with them, even if in reality I am generally testing them. (Who's kidding whom?) There is even a kind of logic that serial commands can take longer to process than parallel, so that considering outcomes rather than communications protocols

s mode = serial
p mode = parallel

is a practical description though no engineer would agree! And Dilbert confirms this


Don

 

[whatlep]

Don

You've raised some interesting (to me) points in your posts and I've mulled a few during today. As Muns corrected me in another thread, the loco decoder is key to the reception of serial or parallel commands, rather than the central station. I think my use of the term "illegitimate" for the serial transmission protocol in respect of NMRA standards was also ungenerous, at least by strict definitions. After all, the serial transmissions simply send the group one binary stream several times. Each iteration accords with the defined standard, though the underlying philosophy may not have been what is now considered "normal".

As to expressing this in a publicly communicable format, serial and parallel as used in the LGB marketing stuff seems remarkably clear, at least compared to talking about sending binary bits in a particular sequence! However, if in doubt Dilbert is always the final word!