RailCom vs. Transponding (Video#39)
Vložit
- čas přidán 21. 03. 2020
- Current sensors can detect the presence of a locomotive or a current consuming car in an isolated track section that is powered via a separate feeder wire. As seen in Video #37 such detectors are cheap to build, reliable, and pretty much the standard approach to block detection. In this video I am extending the focus to other block detector technologies and to train identification, which really is an add-on to block detection.
If you like my work, please consider supporting it with a donation: www.paypal.com/biz/fund?id=Y2...
BlueBox Prototype Board Information: myiott.org/index.php/bluebox-s...
Track Inspection: www.ensco.com/rail/track-imag...
Rail Car Scanning: www.emva.org/wp-content/uploa...
Rail Car Number Recognition: www.axxonsoft.com/integrated_...
Problem detection: www.rtands.com/freight/bnsf-c...
Frauscher Train Identification: • Video
RailCom Standard: www.nmra.org/sites/default/fi...
DIY RailCom decoder: www.rmweb.co.uk/community/ind...
Digitrax Transponding Patent: patents.google.com/patent/US6...
Background Videos taken at: Hendersonville, NC Train Depot Model Railroad Layout www.avmrc.com/ - Věda a technologie
great explonation, I am looking forward to your next video
Thank you!
If you limit a request to one sector the feed back could be send back with the use of wifi.
The DR5000 Command station can use both on your layout. That means if you already have Transponding installed in part of your layout, you can add Railcom to the parts that do not have Transponding and the CS converts them to a single message format.
Thank you for the hint. Now, if I understand right (and after checking the DR5000 manual), this leads to a layout with separate RailCom and Transponding areas, but a decoder that supports transponding is not detected in the RailCom area and vice versa. The main benefit seems to be that the information from both areas are showing up in the main cab control network, therefore are available to software like JMRI. But if this is the case, it is not the hybrid solution I am looking for.
Do you have the Digikeijs DR5000? Can you confirm?
@@IoTT Yes, I do, but have someone else confirming this. The DR5000 takes the
Railcom data and converts it to transponding data. You can see that using the JMRI Loco-net monitor. I am interested in the Hybrid Decoder also.
@@dennischerry4545The LocoNet -based RailCom detectors report RailCom as Transponding messages on LocoNet. This approach could be useful, depending on the design of the layout to sync up automation software that can then block track trains. It is probably easier in most cases however to just replace everything with RailCom.
Ive never seen a club using either system. Many use block detection for signaling. I think the larger issue is that many decoders including all SoundTraxx (which developed the SurroundTraxx system that worked with Transponding) and many TCS decoders (a RailCom supporter) do not support either system. Both Digitrax and ESU offer add-on function decoders that are inexpensive and can be installed alongside another decoder to add their respective train ID technology, but that adds a layer of complexity.
After observing this for some time, I think the value of train identification has been over-estimated and that is probably the main reason that it is not being used in a broad scale. What is the convincing use case? In manual operation you identify the train by looking at it, so you don't need it. In automated operation, the system needs to keep track of the location of each train anyway and that is quite easily done using the track model and simple occupancy detection (the degree of freedom for trains is quite limited, the location only depends on the travel distance and some turnout positions). So, train ID in the best case would serve as confirmation. The 3rd use case would be convenience functions like automatic assignment of a loco to a throttle, but that is technically not possible because a decoder needs to be refreshed (therefore assigned to a throttle) before it can send the ID. So, what value proposition remains? I don't see any.
@@IoTTIn operations, it would be identifying trains to the dispatcher on the panel. For automation, train identification would allow for a train to go outside of the detection areas under manual control, come back, and be identified when it got back to detected territory, or a train to show up in the automation software when it is placed on a staging track. Somehow, the LoDi system and ESU detect a locomotive when it is first placed on the system, even if it is not being controlled by a throttle. Also, for fault recovery, block-tracking systems go completely haywire as they lose track of where everything is.
I recently purchased a DIgikeijs DR5088RC Railcom detector that has 16 blocks and each block can detect a railcom signal. I can communicate with it through a USB interface. It would be nice if there was a way to implement digitrax transponding to this device as you suggest.
Digitrax has no interest in RailCom at this time and since Transponding belongs to Digitrax, you won't see it on other devices.
If you want address location identification you will have to pick one or the other. Digitrax command stations and boosters aren't RailCom compatible. On another note, LocoNet is!
However, I have been able to run both on the Digikeijs DR5000 with a BDL168 and a DR5088RC by double blocking the track. This will require another set of block detectors for the opposite rail and the reporting is done via LocoNet.
Thanks for your comments
>Digitrax has no interest in RailCom at this time and since Transponding belongs to Digitrax, you won't see it on other devices.
*At least not for free. They certainly would license it to someone who is willing to pay for, as they do with LocoNet. But then, none of the others is willing to pay for as there is the free RailCom technology.
>If you want address location identification you will have to pick one or the other. Digitrax command stations and boosters aren't RailCom compatible. On another note, LocoNet is!
*Yes, the network does not care from where the OPC_MULTI_SENSE message originates. It is just a matter of the respective device supporting the protocol.
>However, I have been able to run both on the Digikeijs DR5000 with a BDL168 and a DR5088RC by double blocking the track. This will require another set of block detectors for the opposite rail and the reporting is done via LocoNet.
*This is really interesting. To make this work, I think one of the following must be the case:
1. The booster or cutout device does not add a cutout every time when a particular address comes along the wires so that Digitrax decoders can send the transponding pulses during the preamble sequence or
2. The Digitrax decoders are programmed in a way they can send the transponding pulses in the remaining preamble bits after the cutout.
Would be really interesting to take an oscilloscope and figure out which one is the case.
I've seen your video on double blocking for higher current sensitivity via the BDL168- but this will work with both Transponding AND RailCom at the same time?