Jump to content
 

Handmade RailCom


keybuk
 Share

Recommended Posts

It's pretty easy to make a home-made RailCom detector, and by doing so you get all sorts of flexibility that you wouldn't get by buying something off the shelf. Unfortunately, even though the circuit for one is right there in the standard, the super-dense and precise (German) nature of it all makes it a little daunting.

 

I'll try and break it apart a bit.. first up, what is RailCom? Simply put, it's a method for a decoder to reply to messages from a command station, or to broadcast its own information (such as its address). The most obvious use is for block detection, knowing exactly which decoder is in which block, but once it's demystified, there's all sorts of uses for it!

 

The Booster generates the "cutout", or in plain English, it turns off the power to the track entirely for a few millionths of a second.

 

The Decoder (powered by a capacitor or two) puts its reply or broadcast back onto the track in this off period, with a very low current.

 

The Detector picks up the response, and passes it back (by however it wants, XpressNet, LCC, USB, Bluetooth, WiFi, etc.) to the Command Station.

 

RailCom is the blue line in this badly drawn sketch (there will be a lot of bad drawings):

 

BzmTi0l.jpg

 

Remember that the top of the DCC signal is +15V or so, and the bottom of the DCC signal is -15V, so the RailCom cutout off period is 0V, and one of the few times we deal with it in DCC. The RailCom signal is very low current, anything under 6mA is a 1, anything over 10mA is a 0. Also remember it can go "either direction" depending on which rail is which.

 

Now here's what the standard should say at this point, but it doesn't.

 

RailCom is UART.

 

Its exactly and precisely compatible with the RX pin on any Microcontroller, such as the Arduino you might use for this. You don't need to worry about timings, and sampling the track 250,000 a second, or figuring out "start bits", and synchronization. Your microcontroller already has hardware to do this, all you will need do is call Serial.read() a bunch of times during the cutout.

 

Obviously we can't just stick the track pin directly into the Arduino, we do need a small circuit, and that's what the standard has. I'll break it up into bits and explain it.

 

First up, look back up at the drawing and see what we're going to do - I've drawn two green lines slightly either side of 0V, aiming to detect currents of 10mA or greater/less in either a positive or negative direction.

 

Let's begin by splicing our detector between the Booster and the Track:

SNtKuSy.jpg

 

Two inputs, one we'll call DCC, and the other we'll make our GND. We place a very small resistor of 1.8 ohm on the second input before it heads to the track, and the other side of this we'll call DECODER. Thus the voltage drop DECODER-GND is whatever current is coming from the decoder.

 

With a 1.8 ohm resistor, a current of 10mA will be +/- 18mV.

 

The two diodes in the schematic are there to keep the current across the resistor low, bleeding the excess past it. You don't want 10A (125W) dumped into a 1/4 W resistor in case of a short on the tracks.

 

Our next step is to feed the DCC signal itself into the Arduino:

VUzKmYz.jpg

 

What? No diodes? No pull-ups? Voltage dividers? Nope! None of them are necessary; if you take a look at the ATmega328P datasheet, its input pin circuits have all of that protection anyway - all that matters is that we limit the current to manageable levels, a 47k resistor does the trick.

 

If I was building a circuit around like a Raspberry Pi, I'd worry about opto-isolation and such here; but an ATmega is no more expensive than an isolator chip to begin with. Embed it in the circuit, don't protect it from it; that's what it's for!

 

I use the D2 pin because it's INT0, and you can use an ISR to track the edges and never worry about the actual values (you don't need them for DCC).

 

Now let's get the RailCom signal from the decoder into the RX pin:

N2skDFF.jpg

 

We use a window comparator circuit for this, the inputs are the DECODER output from across the resistor, along with +18mV and -18mV references we'll make shortly. The output will be high whenever the current on the track is between the references (less than +/- 10mA) and low whenever it's outside either.

 

I suspect I have this backwards from the actual schematic in the spec, but it makes no difference - this way we're detecting the 1 bits, backwards you'd be detecting the 0 bits. This way saves a logic gate, since you can just tie the Op-Amp outputs together and pull them up.

 

The power for the chip comes from a 5V source (we'll get to that shortly), but rather than grounding it, we actually place the other pin at VCC; this is because our -18mV reference is going to be "lower than ground."

 

The RX output goes straight into the Arduino RX pin. Configure the UART for 250,000 bps.

 

Since the LM339 has four Op-Amps, and we're only using two, we'll actually go a bit further and detect the cut-out period itself (since -15V and 0V look the same on the D3 pin):

OVgYrT8.jpg

 

Same basic circuit, rather than using the DECODER line, we use DCC and a voltage divider to sample a small fraction of its voltage. For the output we add a R/C filter pair, this takes out the noise of every zero-crossing during the usual DCC operation and leaves us with just the cutout.

 

This can go into the Arduino, I use a D3 (INT1) so it can be watched by an ISR again.

 

Okay, so we need 5V for the LM339, and we'll also want that for the Arduino:

vjd3r5w.jpg

 

Notice that I haven't used a rectifier here, I'm just using a diode and caps to bridge the gaps created by the DCC signal. This works because DCC is a square wave, and it allows us to declare one of the inputs to be the "Ground" for the circuit, while still allowing us to think about "negative" voltages.

 

That's not directly useful in this circuit alone (we could rectify and just compare <10mA), but it's very useful if we want to do "direction sensing" later on (i.e. which polarity is the current we sensed), a common add-on feature of shop-bought detectors that seems to add another zero to the price tag.

 

Hopefully otherwise this circuit is familiar, it's just a 5V regulator, some caps to smooth it out, and a diode/resistor pair to make sure we only take one side of the current.

 

Now, our references.. With a 5V source, it's super-easy to make a +18mV reference:

mDOydvn.jpg

 

This is just a voltage divider; easy!

 

The -18mV reference takes a bit more work:

Kuktkrw.jpg

 

Let's walk through this; and yes, it's a bit odd that I've drawn GND above the circuit, but that's to illustrate that we're measuring things "below ground".

 

On the right is a voltage divider again.

 

Notice how all the diodes go in the opposite direction to the one we used for the 5V part, this means we're sampling the negative part.

 

Rather than divide 15V, which will heat up the resistors, we use a diode to give us a fixed -600mV drop and divide that. A 220 ohm resistor limits current across the diode.

 

Just like our 5V side, we use a capacitor to smooth out the gaps of the DCC signal.

 

Then we have another diode/resistor pair back to DCC to ensure the magic smoke doesn't escape from the capacitor.

 

One last bit, VCC comes out from the bottom of this circuit; at the -600mV drop of the diode. This is allows the LM339 to measure from -600mV to +5V.

 

Throw an Arduino in there (or a microcontroller of your choice) and that's a complete RailCom detector.

  • Thanks 2
  • Informative/Useful 1
  • Interesting/Thought-provoking 1
  • Friendly/supportive 1
Link to post
Share on other sites

Keybuk,

 

Can you elaborate a bit more on the raspberry pi solution please?

 

Also, how do you decode/process the info read into the microcontroller - or is that in the railcom standard?

 

Edits correct what autocorrect thinks I want to type...... Grrrr!

Edited by leopardml2341
Link to post
Share on other sites

Interesting post! But I'm missing the schematics? Or are you describing the RC detector from the standard? (see attachment, page 6)

attachicon.gifs-9.3.2_2012_12_10.pdf

There should be some hand-drawn sketches throughout the post.

 

If you put them all together, you'll end up with a circuit almost, but not quite, like the one on p6 of the standard yeah.

 

I do one notable thing backwards, which means I don't need that NAND gate the spec has.

Link to post
Share on other sites

Can you elaborate a bit more on the raspberry pi solution please?

 

Also, how do you decode/process the info read into the microcontroller - or is that in the railcom standard?

 

Edits correct what autocorrect thinks I want to type...... Grrrr!

If you were passing this into a Raspberry Pi, since it's a bit more expensive, I'd probably add opto-isolators between the outputs of this circuit (D2, D3, RX) and the Pi. The outputs from the above are all TTL compatible, so you could just put them into the input of an isolator, ground the output - and then do the same for pins on the Pi.

 

As for decoding the info, you basically do this (Arduino code) - obviously the exact method will depend on the code you're inserting it into:

 

// setup

pinMode(3, INPUT);

Serial.begin(250000);

 

// loop

if (digitalRead(3) && Serial.available()) {

  int byte = Serial.read()

  // 

}

 

In each cutout, you get two bytes and four bytes (total of 6)

 

To convert the bytes you need a lookup table, see p8/9 of the standard - you want a table to translate the values on the right to the values on the left and 0xff for any missing value

Edited by keybuk
Link to post
Share on other sites

Let's say you just want to pull out the decoder address. That's transmitted in two packets, twelve consecutive calls to Serial.read() will get you:

 

99 A5  F0 F0 F0 F0

A3 AC  F0 F0 F0 F0

 

The first two bytes are "channel 1", the next four are "channel 2" - since channel 2 is for replying to commands, we can ignore that.

 

So we have two sets of two:

 

99 A5

A3 AC

 

We have to decode these using the lookup table on p8/9 - invert the table to decode (right is what we have, left is what we want)

 

So we have (hex to bin conversion on above)

 

10011001 10100101

10100011 10101100

 

Since each byte has 4 1s we know it's valid aka. it has an entry in our inevitable lookup table, which we now apply (hex on right is from lookup table):

 

10011001 = 08

10100101 = 03

 

10100011 = 04

10101100 = 00

 

each of these pairs is a 6-bit half of a 12-bit datagram, so really what we have (hex back to bin) is:

 

001000 000011 (08 03)

000100 000000 (04 00)

 

first 4-bits is the "ID" followed by an eight-bit byte:

 

0010 00000011

0001 00000000

 

ID 1 = adr_high (ignore the English standard)

ID 2 = adr_low

 

so thus we have the (hex) address:

 

0003

 

Link to post
Share on other sites

  • 1 year later...

 

Dear Keybuk,

 

In the 2012 I studied the Railcom (with very few information I found in the internet), and I achieved to read the locomotive address in every block, no problem. The home circuits I made, worked, no problem. I read only the address (that is the "channel 1").

 

Now, I would like to read the speed (and also the direction of the locomotive). I have read in the internet, the speed locomotive (and also other parameters), are read in the "chanel 2". But my doubt is, assuming I read the "chanel 2", how could I decodify the information of the channel 2, for identifying the speed? The decodification of the "channel 1", it is very clear for me, and it works in my home circuits since years ago. But I have not idea about the decodification of the "channel 2". I know it is possible to read other registers (as % of load), but I am interested in reading only the speed (for showing in a pannel).

 

If you would be able to help me, I would be very happy.

 

Thank you very much.

 

BR,

 

Dvorak

Link to post
Share on other sites

Quote

Now, I would like to read the speed (and also the direction of the locomotive). I have read in the internet, the speed locomotive (and also other parameters), are read in the "chanel 2". But my doubt is, assuming I read the "chanel 2", how could I decodify the information of the channel 2, for identifying the speed? The decodification of the "channel 1", it is very clear for me, and it works in my home circuits since years ago. But I have not idea about the decodification of the "channel 2". I know it is possible to read other registers (as % of load), but I am interested in reading only the speed (for showing in a pannel).

 

channel two is available only for " addressed decoders " wheres channel 1 is a broadcast channel , The same UART mentioned will also get the data stream from channel 2 ( assuming your preamble length is sufficient to allow enough dead time for channel 2 )  in fact channel one  cant handle two locos in the same detection railcom section , wheres channel 2 is only sent after a loco has received a DCC command , hence a round robin style of polling control 

 

The spec shows what bytes represent the speed function 

 

HOWEVER, many decoders DO not transmit speed , including all of Lenzs unit , ZIMO does  and its about the only one that does so across its range 

 

Hence unless you standardise on ZIMO , you're  likely to find getting speed to be frustrating 

 

I built a test Railcom decoder to specifically get speed , but its very frustrating to be forced essentially to have one manufacturers decoder

 

Lenz/ESU have largely abandoned Railcom for Railcom Plus , the technical details of which are not available 

 

 

Edited by Junctionmad
Link to post
Share on other sites

Dear Junctionmad,

 

Thank you by your answer. It clarifies what I have seen just now. My cutout has enough duration, so the decoder can send its channel two.

 

I have seen with the oscilloscope, when I address the locomotive (with a Lenz decoder), in the channel two there is a kind of aknowledge by the decoder, but nothing change in this channel two, changing the speed. In few words,  I have got the same conclusion than you: the decoder doesn´t send its speed. Firstly I thought  I was doing something wrong...but once I read your answer, I have seen the Lenz decoder doesn´t send its speed. I feel frustrated with this...

 

Thank you very much,

 

Dvorak.

Link to post
Share on other sites

Hello again, Junctionmad.

 

As I feel frustrated for be unable of read the speed, I follow looking for information in the internet. I found this link of the Lenz:

 

http://www.lenzusa.com/1newsite1/RailCom.html

 

Where it says:

"Decoder initiated information – provides ability to display the real speed of a train and tons of other features.  Even the fuel and water can be transmitted."

 

We know, theoretically, the Railcom can read the speed, but, if the Lenz decoder can not do it...why Lenz write it is possible to read the speed? Perhaps we are doing something wrong? I don´t understand...

 

BR,

 

Dvorak

Link to post
Share on other sites

You notice that press release in from 2000

 

lenz fell out with NMRA over Railcom and Railcom plus 

 

the result was lenz removed features such as speed reporting from its Railcom decoders 

 

You might find this comparison of Railcom decoders useful , as they qualify which ones decode speed 

 

https://www.opendcc.de/info/railcom/railcom_decoder_overview.html

Edited by Junctionmad
  • Informative/Useful 1
Link to post
Share on other sites

3 hours ago, Junctionmad said:

You notice that press release in from 2000

 

lenz fell out with NMRA over Railcom and Railcom plus 

 

the result was lenz removed features such as speed reporting from its Railcom decoders 

 

You might find this comparison of Railcom decoders useful , as they qualify which ones decode speed 

 

https://www.opendcc.de/info/railcom/railcom_decoder_overview.html

 

Not a comprehensive list as there is no Hornby Sapphire which can use Railcom to report back coal/water usage.

Link to post
Share on other sites

Hi, Junctionmad.

 

Now, it is fully clear. Thanks to your support I have avoid many hours of work and much more frustration, because I would be trying and trying to read the speed, thinking I would be doing something wrong.

 

Thank you so much by your help, I appreciate a lot.

 

BR,

 

Dvorak.

Link to post
Share on other sites

quick question from a Railcom user - when they say that the decoder will report speed, how can the decoder know the speed of the loco as the speed is dependant upon the rotational speed of the motor, the worm gear and drive train ratios, the diameter of the driving wheels and, finally the scale of the model that the decoder is fitted into  - to my mind the only aspect the chip might know is the rotational speed of the motor which has a relationship to the actual speed, but isn't the 'speed' of the loco in any way.

 

Or am I missing something?

 

 

Link to post
Share on other sites

4 hours ago, WIMorrison said:

quick question from a Railcom user - when they say that the decoder will report speed, how can the decoder know the speed of the loco as the speed is dependant upon the rotational speed of the motor, the worm gear and drive train ratios, the diameter of the driving wheels and, finally the scale of the model that the decoder is fitted into  - to my mind the only aspect the chip might know is the rotational speed of the motor which has a relationship to the actual speed, but isn't the 'speed' of the loco in any way.

 

Or am I missing something?

 

 

 

BEMF would allow decoder to report  that loco had reached the speed steps set on the controller.

Link to post
Share on other sites

29 minutes ago, RAF96 said:

 

BEMF would allow decoder to report  that loco had reached the speed steps set on the controller.

 

That isn't any different to what I am questioning, the fact that it had reached SS20 on one loco could be 30 km/h, on another 50 km/h or what ever variation you could imagine - I therefore return back to my question which is what 'speed' does Railcom return?

Link to post
Share on other sites

3 hours ago, WIMorrison said:

 

That isn't any different to what I am questioning, the fact that it had reached SS20 on one loco could be 30 km/h, on another 50 km/h or what ever variation you could imagine - I therefore return back to my question which is what 'speed' does Railcom return?

The actually says in effect “ distance over the ground “ ie kmph 

 

this is achieved in the Zimo decoder by calibrating the loco , other decoders simple report back the equivalent speed step out of 128 

Link to post
Share on other sites

  • RMweb Premium

If you've set up your speed steps and know what the speed is for each step, then if the BEMF reports what speed step has been reached you will know the speed of the locomotive from the current speed step 'lookup'.

 

If you wanted to know the speed without any preset speed steps or without having 'calibrated' the steps, then yes you would need to take into account all the aspects of the drive train from motor to wheels, and the scale.

Link to post
Share on other sites

I wonder how many people actually calibrate the top speed, let alone the SS below 126(128) or 27(28)? :) Then there is the question of how many controllers display anything more than the speed step selected which would need a lookup table for each loco to change the speedstep in a meaningful mph or km/h.

 

It would therefore seem that what Railcom therefore returns for speed is simply the motor RPM. I feel it might be more accurate if this is the way it was described rather than implying it is 'speed'

Link to post
Share on other sites

3 hours ago, Ian J. said:

If you've set up your speed steps and know what the speed is for each step, then if the BEMF reports what speed step has been reached you will know the speed of the locomotive from the current speed step 'lookup'.

 

If you wanted to know the speed without any preset speed steps or without having 'calibrated' the steps, then yes you would need to take into account all the aspects of the drive train from motor to wheels, and the scale.

There is no need to measure BEMF per se , knowing the actual speed step is sufficient 

 

1 hour ago, WIMorrison said:

I wonder how many people actually calibrate the top speed, let alone the SS below 126(128) or 27(28)? :) Then there is the question of how many controllers display anything more than the speed step selected which would need a lookup table for each loco to change the speedstep in a meaningful mph or km/h.

 

It would therefore seem that what Railcom therefore returns for speed is simply the motor RPM. I feel it might be more accurate if this is the way it was described rather than implying it is 'speed'

The specification “ implies “ what should be returned is speed over the ground , ie the models KMPH , the reason being , this is transferable across decoders and drive systems 

 

it’s the proper way to specify it 

 

however , because railcom has never been standardized by nmra and is in essence in limbo , the actual implementation by decoders manufacturers has been very spotty 

 

most decoders that are railcom don’t report speed of any nature 

 

to report kmph , you need calibrated decoders , all the high end decoders typically support it , as you need calibration to properly implement automatic stops ( or else you transform the process into a computer calibration , like Train Controller does ) 

 

some decoders that report speed , report the actual speed step being sent to the motor at that time, you don’t not need to sense BEMF to do this.

 

only the decoder knows the actual speed step , the controller only knows the commanded speed step , particularly in sound equipped locos , the difference can be marked. 

 

Whether people calibrate their deciders is irrelevant , because the facility is there , many people don’t use the features of many decoders, so what 

 

done right , railcom speed is very useful in precision controlled stops , without a central automation computer 

Edited by Junctionmad
Link to post
Share on other sites

  • 9 months later...

Dear Keybuk

 

First of all thanks for sharing your knowledge 

I have been reading your the article a couple of times, but i somehow lost the overview. So if I want to Railcom monitor connected to the tracks with Arduino, which is the diagrams should I use?

 

Link to post
Share on other sites

  • 3 years later...

Hi,

 

I realise this is an old thread but hoping someone might be able to help.

 

I have made a handmade Railcom decoder but suspect there may be an issue somewhere and I'm not sure what to do next.

 

I have hooked up a scope to the INT and data and the result is as follows.

 

INT is the blue top trace, RX is the red trace - I separated them vertically for clarity.

 

image.png.d67d3e2de5aa5745ff9d62bfb515537d.png

 

What I don't understand is that the data from the locomotive seems to be arriving just before the cut-out starts... i thought the whole idea was that it is the cut-out that allows the decoder to talk back.  Its almost as is the cut-out is being delayed,

 

Looking at the spec, it should all happen inside the cut-out:

 

image.png.54039d7456724aca98634f361b09f56e.png

 

Here is the detection part of of my circuit.  All the voltages are correct, and as you can see from the trace, the data is actually good (and i have manually decoded the hex coming back and it is correct for the locomotive on the track)

 

 

image.png.56f27f549e036fd30f7b5a8be87a80eb.png

 

If anyone has any ideas id be really grateful.

 

It seems that I need to use the cut-out period as a way to start the serial reads and while the the two aren't arriving as expected in time that isn't going to work.

 

Thanks,

 

Joel.

 

Edited by jhauxwell
The schematic had a mistake
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...