Railcom Using Global Detector

[Mihai]

According to the NMRA specs here (page 23rd, Figure 5) there appears to be a global detector built in the booster/command station itself. What I'm after: using a Lenz LZV100 station and a Lenz LI-USB-Ethernet interface I'm looking to collect information from locomotives around the layout (speed/direction). I'm not interested (currently) in which block each locomotive is in - but simply a way to gather feedback from all of them; hence I'm thinking I could avoid the Railcom detectors for now. Is my assumption correct ?

[Mihai]

I was under the impression that the data packets emitted by the loco decoders via Railcom (during the cutout period) would "flow" normally through the track, and would get picked up by the Lenz LI-USB-Ethernet interface via XPressNet from the command station and forwarded to the PC.But I do agree with you, if it would work this way it would probably have to be flagged as a spec So it would mean that the command station only ensures the pre-requisites for Railcom signal (by providing the cutout) but it's up to another piece of logic (Railcom detectors) to pick up and understand the replies.

 

Looking at Lenz RailCom detectors here, there are only 2 suitable candidates - the LRC130 and the LRC135 working in tandem. However I'm not finding the manual for LRC135. Another question that pops up is if the LI-USB-Ethernet interface could be used instead of the LRC135.

[Nigelcliffe]

I'd suggest a small step backwards and asking "how and where do you plan to display/interpret the railCom data?".  Then step forwards again.   I'd also look outside Lenz' products.   

 

For example, swapping out all the Lenz command station for an ESU ECoS might do what you need.   Alternatively, several third party RailCom detectors may be able to transmit the information you require to a computer (though your choice of software might influence which hardware).

 

Or, do you really need to details from decoders ?   As decoders just respond to instructions from the command station, are you really asking "what is the command station sending to the track?",  in which case, sending a data query to the Lenz command station should recover the information. 

 

 

- Nigel 

[Mihai]

Hi Nigel. The data will be displayed on the PC. I agree that the speed will be set by the command station itself after all, but I'm also looking for more "interesting" features - such as back EMF data from the decoders, which will tell how "hard" a locomotive is pulling at one point, which I've understood it's possible to be sent using RailCom.

 

As for the manufacturer, I'd like to currently keep the scope to Lenz, since I've already bought the command station (LZV 100), one inverter (LK200) and the LI-USB-Ethernet interface, which is a sizeable sum. However if going down the RailCom path proves to be too complicated / expensive then for sure I'll be happy to explore products from different manufacturers.

[Mihai]

One more thing - based on your ESU ECoS refernce, I've just looked around and found here that "Of course, the ECoS has a pre-installed DCC RailCom® function: with its „global detector“ it recognizes RailCom®-compatible decoders (e.g. our LokPilot V3.0 decoder) directly on the main track". Wonder why Lenz would have left this out, since RailCom was being drafted around 2005 if I'm not mistaken.

[PaulCheffus]

I was under the impression that the data packets emitted by the loco decoders via Railcom (during the cutout period) would "flow" normally through the track, and would get picked up by the Lenz LI-USB-Ethernet interface via XPressNet from the command station and forwarded to the PC.But I do agree with you, if it would work this way it would probably have to be flagged as a spec So it would mean that the command station only ensures the pre-requisites for Railcom signal (by providing the cutout) but it's up to another piece of logic (Railcom detectors) to pick up and understand the replies.

 

Looking at Lenz RailCom detectors here, there are only 2 suitable candidates - the LRC130 and the LRC135 working in tandem. However I'm not finding the manual for LRC135. Another question that pops up is if the LI-USB-Ethernet interface could be used instead of the LRC135.

 

Hi

 

Have a read here

http://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf

 

9.3.1 seems to have been discontinued. I have uploaded a copy of the version I saved from the NMRA website before it was removed. 

RP-931(Jan_2007)RailCom Electrical.pdf

 

I have built two of these and they work well as standalone devices. More work would be required in order to get them to talk to a PC.

http://usuaris.tinet.cat/fmco/railcom_en.html

 

You could also take a look here

http://www.opendcc.de/elektronik/xpressnet/railcom_xpressnet.html

 

Cheers

 

Paul

[Mihai]

Thanks for the links, Paul. I've found some interesting text on the 2nd one: "NOTE: In 2008 following NMRA RP-9.3.2, besides of address and CV, Lenz Gold sends speed and temperature and Zimo decoder sends speed, temperature and load, but now RailCom specification is changing to RailComPlus not following the RP-9.3.2 of the year 2008 so with new decoders as Lenz and ESU you only get address and CV that are compatible with RP-9.3.2". Since I believe the load can't simply be read out via a specific CV, that would mean bad news for my plans - unless the information there has changed in the meantime.

 

As for the electronic-building side of things, it's not really my strong field and I'd rather just purchase off-the shelf components. Like you said, getting those to work with a PC will be more work, aside from the one required to built the components in the first place.

[Ron Ron Ron]

....... Wonder why Lenz would have left this out, since RailCom was being drafted around 2005 if I'm not mistaken.

 

That's because Lenz had planned to replace the LZV100 with a newer model, the LZV200, three years ago in 2012.

(IIRC it was announce in 2011? )

However, the new model has yet to see the light of day.

 

The LZV200 incorporates an integrated global RailCom detector, allowing RailCom readout of CV's.

 

 

 

.

[Mihai]

That's because Lenz had planned to replace the LZV100 with a newer model, the LZV200, three years ago in 2012.

(IIRC it was announce in 2011? )

However, the new model has yet to see the light of day.

 

The LZV200 incorporates a integrated global RailCom detector, allowing RailCom readout of CV's.

 

 

 

.

 

Found the detaled specs here. Fortunately, it looks as if the integrated global detector can be retrofitted to the LZV100 by simply sending it to Lenz. However like you very well pointed out, it's 3.5 years since this model was supposed to be launched, and there's no sign of it yet, so I don't think it's realistic to get any hopes on this side for the near-future.

 

There's another thing that's puzzling - in order to see what information and CVs can be sent back, a simply hands-on test with a Lenz Gold -or equivalent decoder would be in order - however I can't figure out how to "sniff" the traffic coming back. The LRC130 reportedly sends that information over a "RailCombus", but not sure how to hook into that. Easiest way would be to connect it to the USB gateway so the data can be easily analyzed on a computer. Yet searching for the 2 products at the big retailer I usually buy from doesn't yield any result - maybe because as well neither LRC130/135 never saw the light of day until now. 

[Nigelcliffe]

I really think this would be easier if "Lenz" was dropped from the solution.   From my observations, Lenz stopped being a lead player in DCC many years ago, and has been largely coasting on its past reputation.   

 

There are solutions which will interwork to some extent with some of Mihai's Lenz hardware. Suggest reading up on products from DCC4PC (UK company), Tams (German) and there are others.    

[PaulCheffus]

There's another thing that's puzzling - in order to see what information and CVs can be sent back, a simply hands-on test with a Lenz Gold -or equivalent decoder would be in order - however I can't figure out how to "sniff" the traffic coming back. The LRC130 reportedly sends that information over a "RailCombus", but not sure how to hook into that. Easiest way would be to connect it to the USB gateway so the data can be easily analyzed on a computer. Yet searching for the 2 products at the big retailer I usually buy from doesn't yield any result - maybe because as well neither LRC130/135 never saw the light of day until now. 

 

Hi 

 

What data would you like to see? The data returned is in the first document I linked to in my previous post. As mentioned I have built Paco RailCom Display and I can modify the firmware to show anything on the screen such as the raw data instead of the CV values for example.

 

Cheers

 

Paul

[GoingUnderground]

Reading you opening post, you seem to be looking to gather dynamic data, speed, direction, loading on the loco via back EMF etc for each loco. But I don't think that what you want is available using Railcom.

 

Railcom allows you to read back CVs from a loco whilst it is on normal motion around the track. CVs are static in that they set up the way the decoder controls the loco, and operating the loco doesn't normally change their values. Unless a decoder is designed to vary the value of a specific CV to indicate speed or a different one for direction or a third for load, then no matter what detector you have you will not be able to get this sort of dynamic information back from the decoder by reading back a CV using Railcom as AFAIK, most decoders don't have such CVs, but Hornby do have dynamic CVs in their Sapphire decoders for water level etc,

 

If you could find such decoders, and I'm not sure that they exist, but I may be wrong, then you would need some sort of computer program to keep asking each decoder in turn for its relevant values and to show the results on screen. As you want to display the information on a PC, why not just control them through the PC, It will know the intended speed and direction as it will have issued the command to the loco in the first place.

[PaulCheffus]

Keith, the pdf referred to by the OP in his OP specifies what Hornby is doing in regard of "consumables" in loco's. So they're just using another part of the existing RailCom (RC) spec. These are indeed "dynamic" CV's as their value decreases gradually. You are right, however, that there are no values for speed, direction and load via RC. Having said that, they can be extrapolated by analysing the DCC packet stream (for direction and speed) and a resistor (with accompanying electronics, including an ADC) for load (current sensing).

Hi

 

Unless I am missing something how come when I use the Paco Railcom display it shows the current speed / load of the loco? Lenz gives speed and Zimo gives load.

 

Cheers

 

Paul

[Mihai]

I really think this would be easier if "Lenz" was dropped from the solution.   From my observations, Lenz stopped being a lead player in DCC many years ago, and has been largely coasting on its past reputation.   

 

There are solutions which will interwork to some extent with some of Mihai's Lenz hardware. Suggest reading up on products from DCC4PC (UK company), Tams (German) and there are others.    

 

Just took a look at both DCC4PC and Tams. The most promising looks to be DCC4PC, as they clearly state they support multiple decoders in the same section, which I'm after. They also state that they report back the actual load, provided the decoder will send this information, of course. 1x RailCom Reader + 1x Computer Interface are about 300 euros. Over at Tams, after firing up Google Translate, it turns out they also do RailCom detectors, however there's no mention about their devices supporting more than 1 detector / section, nor any word about actual load; either it's there or isn't explicitly stated, or it's missing. 1x RCD-1 + 1x RC-Link are about 85 euros.

 

 

Btw if there's any issue about posting prices I kindly ask a moderator to let me know.

[Mihai]

Hi 

 

What data would you like to see? The data returned is in the first document I linked to in my previous post. As mentioned I have built Paco RailCom Display and I can modify the firmware to show anything on the screen such as the raw data instead of the CV values for example.

 

Cheers

 

Paul

 

Paul, what I'd need is the missing component - the PC interface that would report data back from the RailCom detector.

[Junctionmad]

Railcom provided more information then just CVs , read the spec

[Mihai]

Reading you opening post, you seem to be looking to gather dynamic data, speed, direction, loading on the loco via back EMF etc for each loco. But I don't think that what you want is available using Railcom.

 

Railcom allows you to read back CVs from a loco whilst it is on normal motion around the track. CVs are static in that they set up the way the decoder controls the loco, and operating the loco doesn't normally change their values. Unless a decoder is designed to vary the value of a specific CV to indicate speed or a different one for direction or a third for load, then no matter what detector you have you will not be able to get this sort of dynamic information back from the decoder by reading back a CV using Railcom as AFAIK, most decoders don't have such CVs, but Hornby do have dynamic CVs in their Sapphire decoders for water level etc,

 

If you could find such decoders, and I'm not sure that they exist, but I may be wrong, then you would need some sort of computer program to keep asking each decoder in turn for its relevant values and to show the results on screen. As you want to display the information on a PC, why not just control them through the PC, It will know the intended speed and direction as it will have issued the command to the loco in the first place.

 

You're right - reading just plain CVs won't help my goal (current set speed, direction, and optionally load).

 

The problem I'm trying to overcome is that supposedly the computer controls locomotive with address 3. Then at one point in time, a user takes the handheld throttle and modifies the speed, thus taking away focus from the computer. The locomotive would run according to the new set speed, but the computer wouldn't know anything about this new value. Just tried this earlier using JMRI and the Lenz LH-100 - and the LI-USB-Ethernet interface was oblivious to commands issues by the LH-100.

[Mihai]

One more thing  - I've mailed Lenz this morning concerning this issue, but I haven't received any reply yet. I'll post as soon as something comes up.

[Junctionmad]

You're right - reading just plain CVs won't help my goal (current set speed, direction, and optionally load).

 

The problem I'm trying to overcome is that supposedly the computer controls locomotive with address 3. Then at one point in time, a user takes the handheld throttle and modifies the speed, thus taking away focus from the computer. The locomotive would run according to the new set speed, but the computer wouldn't know anything about this new value. Just tried this earlier using JMRI and the Lenz LH-100 - and the LI-USB-Ethernet interface was oblivious to commands issues by the LH-100.

Railcom can be used in this situation. The alternative is a means of querying the booster /command station since it must know the current speed since it's generating dcc commands for the decoder

[PaulCheffus]

Railcom can be used in this situation. The alternative is a means of querying the booster /command station since it must know the current speed since it's generating dcc commands for the decoder

Hi

 

Indeed you could do this. I have a packet sniffer built from here

http://www.opendcc.de/elektronik/dcc_sniffer/dcc_sniffer_e.html

But again it would require building and development work in order to get the data back to the PC.

 

Cheers

 

Paul

[Nigelcliffe]

You're right - reading just plain CVs won't help my goal (current set speed, direction, and optionally load).

 

The problem I'm trying to overcome is that supposedly the computer controls locomotive with address 3. Then at one point in time, a user takes the handheld throttle and modifies the speed, thus taking away focus from the computer. The locomotive would run according to the new set speed, but the computer wouldn't know anything about this new value. Just tried this earlier using JMRI and the Lenz LH-100 - and the LI-USB-Ethernet interface was oblivious to commands issues by the LH-100.

This seems to be a limitation of either XpressNet or the Lenz system. Other makers systems (eg. Digitrax) report every throttle change to JMRI.

 

If querying the command station could solve your problem, then suggest you take the issue to the JMRI email group on Yahoo! and ask there. There must be some Lenz users who have had the same issue before.

 

 

- Nigel

[Mihai]

Railcom can be used in this situation. The alternative is a means of querying the booster /command station since it must know the current speed since it's generating dcc commands for the decoder

 

Do you happen to have a link to how this can be done ? Tried searching around but haven't been that successful I'm afraid.

 

 

 

This seems to be a limitation of either XpressNet or the Lenz system. Other makers systems (eg. Digitrax) report every throttle change to JMRI.

 

If querying the command station could solve your problem, then suggest you take the issue to the JMRI email group on Yahoo! and ask there. There must be some Lenz users who have had the same issue before.

 

 

- Nigel

 

Thanks Nigel - went ahead and created an account on the JMRI Yahoo group since this morning, but I've yet to receive an ok from an admin there in order to be able to post. Hopefully it won't be long now.

[GoingUnderground]

You're right - reading just plain CVs won't help my goal (current set speed, direction, and optionally load).

 

The problem I'm trying to overcome is that supposedly the computer controls locomotive with address 3. Then at one point in time, a user takes the handheld throttle and modifies the speed, thus taking away focus from the computer. The locomotive would run according to the new set speed, but the computer wouldn't know anything about this new value. Just tried this earlier using JMRI and the Lenz LH-100 - and the LI-USB-Ethernet interface was oblivious to commands issues by the LH-100.

 

So you route all commands through the PC. You could do that with Traincontroller software and their Smarthand controllers. I still think that you are looking in the wrong place for the answer to your problem.

[Mihai]

This seems to be a limitation of either XpressNet or the Lenz system. Other makers systems (eg. Digitrax) report every throttle change to JMRI.

 

If querying the command station could solve your problem, then suggest you take the issue to the JMRI email group on Yahoo! and ask there. There must be some Lenz users who have had the same issue before.

 

 

- Nigel

 

Turns out it's indeed a Lenz design choice - only broadcast messages will be forwarded via the XPressnet PC interface to the computer along the ones coming back as replies to queries from the computer itself. Actually JMRI will resort to polling the current speed, direction and function settings every 1 second or so if the address is owned by a handheld throttle. JMRI forum thread here.

[Mihai]

One more thing  - I've mailed Lenz this morning concerning this issue, but I haven't received any reply yet. I'll post as soon as something comes up.

 

The reply came back that LRC 130/135 are at this time still under development.

 

As quite a few already indicated, I'll have to pass RailCom for now. Polling for the speed and direction don't require any hardware and has been successfully been employed by JMRI too.