keybuk

It's definitely an interesting approach... I'm less interested for locomotives, since they need power anyway, but I've been considering using BLE or similar 2.4 Ghz as an LCB replacement - my concern has been the amount of radio interference typically generated by DC motors. I guess you're finding, even with the antenna in the loco, that it's manageable?

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

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

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.

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): 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: 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: 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: 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): 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: 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: This is just a voltage divider; easy! The -18mV reference takes a bit more work: 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.

Home-made RailCom detectors are pretty easy, you just need something to send the responses to

These look worth the wait!

My Class 68 "with Sound Fitted" arrived this week without a decoder! The larger DCC supplies bass reflex speaker is fitted, and tolerances aren't just tight, but it's just not possible to fit a ESU V4 in there the way they've screwed it together (it sits at such an angle that it's unable to hold itself onto the pins). I guess the decoder fell out at the factory before they put it in the box. Hopefully Hattons will be able to get me a Decoder for it from Dapol, and then I'll be definitely following the advice in this thread for fitting it and "fixing" the loco. (And one day, I'm sure I'll buy something from Dapol that doesn't require manually fixing …)