Are you using or Considering Transponding or RailCom?

[KenS]

DCC was originally one-way.  There are two methods for getting info back from a decoder (other than manually reading it): Digitrax's Transponding (supported mainly by them) and the Lenz (and now draft NMRA standard) RailComm (supported by them, and eventually others).

 

Most people likely don't need this.  Even automation can be done without it.  And the main value seems to be in "smart throttles" that display fuel use (which in turn depends on decoders that track fuel use). Which means that unless you're buying into a system that also has smart throttles, at best it's a way of reminding yourself what address you gave to a train.  With a large collection, that alone seems like a good idea to me, which is what started me thinking about it again when the NMRA RailComm info was annouced a few months ago.

 

If, like most U.S. modellers, you're heavily invested in Digitrax, there's a strong bias to use their system (in fact at present it appears to be impossible to use RailComm with a Digitrax command station without replacing it, or at least adding a booster that costs about the same, although that may change).

 

I'd tried Transponding a couple of years ago, and hadn't been satisfied with it.  I'd recently started thinking about RailComm, only to discover a "cutout device" is needed with older non-RailComm command stations, and nobody makes one yet (there's one due to ship "this month" though).

 

I also noticed that Lenz's new RailComm equipment (LRC130 and LRC135), which was discussed on a 2009 thread here, doesn't appear to have shipped yet.  It's showing as "TBA" in every online store I checked. So as much as I might like to play with it, the answer seems to be "not yet".

 

So that made me wonder. Has anyone done anything with this? I know Don has done a little, but he built his own command station.  So, answer the poll (assuming I manged to set it up correctly) and post your thoughts on the topic.

[Martijn Meerts]

Pretty much all my decoders support RailCom, as do 2 of my digital systems (The Lenz system as well as the ECoS). As I'm going for a computer controller block system, the only benefit I would get from RailCom is an additional check on whether a certain train has entered the block it's supposed to enter, but it'd be too expensive to implement that for the little additional security you get in return. There's also RailComPlus btw, which basically auto detects when a new train is put on the track, and automatically assigns it an address so you'll never have conflicting addresses on the layout.

 

ESU (the makes of the ECoS and LokSound decoders) are working together with Lenz on RailCom these days (it was ESU that implemented RailComPlus, and they already have quite a few RailCom equipment.

[CaptOblivious]

Don't forget CV readback on the main! That's a nice feature of both systems. No more service track!

 

Also, I have on the table a version of RAILbooster with a cutout device. If there is interest, I might attempt an after-market cutout device for non-RailCom systems.

 

Incidentally, I have not actually /done/ anything with RailCom just yet ;)

Edited January 18, 2013 by CaptOblivious

[Martijn Meerts]

<blockquote class='ipsBlockquote'data-author="CaptOblivious" data-cid="77688" data-time="1358526810"><p>

Don't forget CV readback on the main! That's a nice feature of both systems. No more service track!<br />

<br />

Also, I have on the table a version of RAILbooster with a cutout device. If there is interest, I might attempt an after-market cutout device for non-RailCom systems.<br />

<br />

Incidentally, I have not actually /done/ anything with RailCom just yet ;)</p></blockquote>

 

Good point on the reading CVs on main, I guess I actually am using RailCom quite regularly then :)

 

Edit: seems quoting on the mobile template is kinda broken :)

Edited January 18, 2013 by Martijn Meerts

[KenS]

Don't forget CV readback on the main! That's a nice feature of both systems. No more service track!

 

Also, I have on the table a version of RAILbooster with a cutout device. If there is interest, I might attempt an after-market cutout device for non-RailCom systems.

 

Incidentally, I have not actually /done/ anything with RailCom just yet ;)

 

I think you'd still want the service track for programming a new decoder.  I can read CVs on the main today with Ops Mode, but I usually use a programming track on my bench for setup anyway (at the moment my "bench" is the kitchen table with my Zephyr and a loop of track on the Rail outputs, and a short segment of track on the programming outputs).

 

A cutout would be a useful device for those of us with older systems who don't want to replace them wholesale.  There's only one company I'm aware of working on one (the UK company DCC4PC) but it's not shipping yet. But that's a gamble that A: people will want to use RailComm, and B: manufacturers won't make it easy to get updated software that can enable a cutout even once there is demand (Digitrax's new Zephyr Xtra has user-updateable firmware, for example).

 

Not to discourage you, but the market seems slim for that. Of course, that could be an opportunity for good PR, if you're the only company with one.

[CaptOblivious]

Ken, Ops mode read back requires either transponding or railcom. That was my point.

[inobu]

It is funny that this is coming up as I was just ordering a few BDL168 to play with transponding.

 

It seems that its a sniffer based on inductance.

 

I never looked at Railcom but the feedback channel looks like the way to go but I don't see why it is needed.

 

From what I've seen the PIC in the decoders have memory locations and registers and if you can read back an address then it is only the point of adding more coding.

 

Adding an ACK and NACK (Acknowledgement and Negative Acknowledgment) algorithm opens the door for a lot. 

 

Read back is the command station saying "Hey Decoder 003!" and read back is the decoder responding 003 ("What!")

 

Labeling the ACK packet with the decoder Address establishes Identification and adding other memory registers in the stream opens the door.

 

Digitrax siffing allows for the data to be gathered outside of the command station so there is no need for the command station to process the response.

 

Inobu

 

KenS what was the issues you did not like on your first go round with Transponding?

Edited January 19, 2013 by inobu

[KenS]

Ken, Ops mode read back requires either transponding or railcom. That was my point.

 

Nevermind. I was more confused than usual.

 

Inobu,

 

The problem I had was that it didn't work.  I set up a test loop, and did a bunch of tests I documented on my site, and basically the BDL168 worked reliably as a simple occupancy detector, and was essentially worthless at doing transponding (the part that depends on the RX sensors). I had some RXs that worked reliably, others (on the same set) that never worked, some that worked erratically, and some that worked on one BDL but not on another (plugged into the same wiring and edge connector, so it wasn't my soldering that was the issue).

 

My suspicion is that there's some cross-talk / noise problem, and some sensors are more sensitive than others, but my wiring was in-spec per Digitrax's documentation. Someday I'd like to take a close look at the signal in the RX and see what's really going on there, but I'd need a better oscilloscope than I have, and that's not going to happen soon.

 

I also have some concerns (based on various statements in Digitrax's documentation) that transponding with LED lighting isn't going to work reliably (insufficient load; F0 current draw needs to be at least 1% of either block current or maximum booster current, which wasn't clear but they noted that 30mA was a minimum recommended F0 load) and that means that it won't work for FL12s, since I'm not going to rewire the lightboards that go along with those and they pull well under 20mA. That's was a disappointment, and led me to consider using non-Digitrax (and thus non-Transponding) decoders for my other trains.

 

And then the NMRA made it clear last summer they were standardizing (slowly) RailComm, and that was the final nail in the coffin.  Why try to make something work that has no long-term future?  Especially something I spent several months on fruitlessly? I'm sure Digitrax will keep it alive for years to come, but the writing is clearly on the wall and everyone else will eventually move to RailComm if they do anything.

 

As yet another problem: like most Digitrax documentation, transponding's various issues and "you must do this" bits aren't all documented on one place, and I kept finding odd little statements in tech depot posts or other manuals like "on a high-current layout, connect a capacitor and resistor across the F0 output for reliable transponding" (say what?).

[inobu]

This is not good............I was afraid of this response. I will read your finding again and try the avenues that you did not venture down. I don't want to waste time repeating your testing.

 

:(

 

I'm glad you documented your findings.

 

Inobu  

[KenS]

My suspicion is that the RXs are REALLY sensitive to placement/routing of wires.  I did try to do a better job of having the blue wires follow the RX leads and not go near the other RXs than some of my photos show, but it never seemed to help.  You might consider using a larger placement area and more careful routing of the twisted feeders to and around the RXs, as well as keeping the RX leads away from each other (Digitrax's documentation says that doesn't matter, but their documentation has been wrong before).

 

If you actually figure out how to make it work, please post something about how you did it.