DCC++ Update Project 2020

FlightRisk Feb 16, 2020

  1. BigJake

    BigJake TrainBoard Member

    3,259
    6,173
    70
    There's more than a lack of decoding going on here. 4/8 coding uses only those 8 bit words which have exactly 4 '1' bits and 4 '0' bits. There are 70 8-bit values that meet that criteria, and of those, 67 are defined, including 3 special purpose codes and 3 unused codes, leaving decoded values 0-63 for general use.

    The received value 255 has 8 '1' bits, so it is an illegal 4/8 encoded value.

    Here is the document describing the encoding, in table form (section 2.5): https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf
     
  2. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    Ah well theres always the budget constraints ...

    But forgive me if I'm wrong on this but essentially you can get an Arduino to read the ACK signal and that signal is sent out by a number of decoders on the market not just during Programming but also during operation as I understand things. Railcom ? Which means that if you have each block of your track setup to read the data you can not only see that there is a loco in the block but also identify it, thus if using JMRI you can show which locos are in which blocks of the track ? At this point I start to loose things as much of the information seems to have been written for those who already have an understanding of DCC but if I understand things correctly you could insert an arduino with an opto coupler and a bridge rectifier + voltage regulator anywhere you wanted in theory in every block of track, and use it to detect not only the block occupancy by detecting the current but also any loco by railcom ? If thats the case it's not going to be massively expensive but I was thinking even a base arduino has a lot of I/O ports and so maybe one arduino can look after multiple blocks, my coding is basic at best but I would imagine that one could simplify things by telling it to only check occupied blocks for railcom signals using a basic IF THEN function.

    The layout I'm planning is a bit unusual and is based on a narrow gauge rack railway in Switzerland, one of their unusual things is they can send multiple trains up one after the other as unconnected consists I guess you could call them in railway terms. I figure I can achieve this appearance using a lot of blocks, I don't think I can use an actual consist because each loco is separated from the next by a short delay but by having very short blocks (the trains in real life are between about 100 and maybe 170 feet in total length make each block just 200 scale feet in length and use JMRI scripting to only allow train two to follow train one once train one enters the next but one block. The trains themselves only travel at just over 16mph 25kph so accidents are very rare LOL
     
  3. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    I know it can be confusing, especially when things use similar terms. It is a slow burn where nothing seems to make sense for weeks and then all of a sudden, it become clear in chunks ;) Let me try to define things.

    DCC - An NMRA standard for a signal on the rails that controls trains and accessories. The standard does not allow and in fact it is technically not possible to have bi-directional communication on its own. The spec has been amended, which I'll cover shortly.

    ACK - This is an acknowledgement back from the train, only on the programming track, in the form of a very short pulse of current. This pulse tells our software "yes". To read a CV, we ask, is CV116 set to 0? Nothing. Is it set to 1? Nothing. Is it set to 2? ACK!. We know CV 116 is 2. That's the gist of it.

    DCC Decoder - The decoder can read the DCC signals and power the train. Many DCC decoders are also Railcom compatible. (I'm getting there)

    Things grew beyond what anyone really imagined we would be doing with model trains. Sound decoders alone add a lot of traffic on the DCC signal with all the things they can do. We send packets and packets of data. At some point, when you have too many trains and accessories, things could slow down because there are too many messages that need to be sent. We have ways of dealing with this, but if your system is that big (a large club) then you might be looking for something else to help out. Add to that the different way (from US hobbyists) Europeans run trains in a centralized way where each operator can be responsible for multiple trains when they enter their block and you get the product called Railcom. There are other ideas, but Railcom is the leader. It is not without it's technical problems, but if you work within its limitations, it is a pretty good solution to bi-directional communication.

    How does it work? Since current to the track in DCC must constantly be applied so that the trains have power to run and the message packages can be sent, a trick had to be created whereby we actually short out the track and create a loop for current (and a signal) to travel to another device, an external Railcom transmitter.

    Since part of the DCC spec is that we send a stream of preamble bits that the decoders count as they wait for a data start bit, someone figured out that you could interrupt that stream of data (and everything on the track including the voltage running the trains) for 488 microseconds, and pass data back and forth without any of your non Railcom devices being any the wiser. This is called a "Railcom cutout". During that cutout, a high density data stream is sent on the rails. This is not an ACK pulse, this is a stream of data packets just like in a network and similar to the uni-directional data packets that DCC sends out. Decoders that are Railcom compatible, allow the train to continue to run while their other programming kicks in to receive AND TRANSMIT data with the Railcom transmitter (or devices that can read the Railcom data as we intend to do). The data is a completely different protocol from DCC, but the two can work together.

    Your description of a device with an opto-isolator and a bridge rectifier, etc. basically describes a decoder. A decision needs to be made as to whether you use simple input and outputs (sensors and switches) or use decoders to do what you want. Many people use a system just like this. ESP8266s, Nanos, Pro Minis, etc. are all very inexpensive. So yes, that is one solution. You would need to find a sketch that can read speak Railcom. It also means everything is connected to the rails. Not to confuse things further, but that is where LCC comes in. DCC can be the thing that controls trains on its data bus (the track), while a completely separate bus controls everything else. Those things are basically wired on their own network. So, something else to read up on! LOL.

    That Swiss train system is very interesting. There are several ways to duplicate that. Simple sensors connected to the Arduino could read as each train passed it and know speed and distance between trains and keep them from running into each other ;) Railcom of course would know the names of the trains and their might be an option there. There are so many interesting challenges to figure out in model railroading.

    There are a ton of articles out there, but this is a good, concise one with more detail on decoders: http://sprog.us.com/howdoes.html
     
  4. BigJake

    BigJake TrainBoard Member

    3,259
    6,173
    70
    I've always wondered why readback does not use a binary search with queries like "Is CVn > m", to read back values from the decoder more quickly.

    You could determine any CV value with only 8 queries, instead of up to 255 queries.
     
  5. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Actually, we do. There is paged mode and direct mode. We default to direct mode which queries the bits. So with 8 bits in a byte, it takes 8 reads to get the value and the duration of any timeouts for the 0 bits and no reply at all. It can be much faster. We have done a few other things in the version we are working on now that does a few more things that make it noticeably faster.
     
  6. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    OK so things are starting to become clearer ... You could say the water is now only slightly cloudy as opposed to full of mud !

    My mistake I went and had a look at the JMRI pages :-( OK now I sort of decided that I'd run my layout on a dedicated Raspberry Pi and JMRI and I'd already been looking at CMRI as other hobbyists seem to have got turnouts and lighting to work with that (and I guess detectors as well) plus it only requires a twisted pair serial cable between boards so easy to setup, but your comments made me go and look at LCC on JMRI and thats where I start becoming confused again.

    Because whilst according to JMRI https://www.jmri.org/help/en/html/hardware/can/index.shtml the NMRA are supporting the OpenLCB as it's LCC and JMRI will support OpenLCB technology it then goes onto say that it only supports sensors and turnouts https://www.jmri.org/help/en/html/hardware/openlcb/index.shtml (though it does go on to say it supports signal masts) but then starts to talk about 16 hexadecimal digit code at which point my eyes begin to glaze over and I start gibbering

    They also talk about MERG CBus which seems to be better supported under JMRI but no less confusing technically

    I think part of the issue is that many of the standards come out of the USA where there's clearly a big market and are defined by the NMRA as a result, which is fine but many seem to be setup for huge layouts probably because there seem to be a lot of layouts built in huge basements, in the UK save for clubs and a few dedicated and or rich enthusiasts most layouts will be much smaller perhaps built in lofts or a spare room. Note I said smaller they may still be just as complicated ;-) It's just that whilst with lots of space you might be building freight terminals and massive stations we are likely to be building branch lines :) Unfortunately we end up using systems that use US standards because thats where the development comes from.

    In an ideal world I'd have a set of CMRI sensor boards around my small layout reporting back to the Pi and JMRI, save that whilst I have found basic sensor board setups for block sensors I've not seen any that can use CMRI and Railcom

    I think my small 10 ft x 12 ft layout is likely to have well over 20 blocks and probably more than 30 point location sensors so I can stop a loco at a set point add in about 15 pairs of turnout reporting sensors and thats a lot of reporting LOL fortunately right now most of this is just theory in my head plus a few drawings.
     
  7. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    I agree with you, it is very confusing. No doubt if you are going to play with anything beyond running a train in an oval, there is a bit of a learning curve. My take on it is start with something you can expand, but just start. For me, that is the DCC++ solution. Having some coding experience, I can directly control some things all on the base station. And JMRI can control just about anything. So you set up your layout there and connect whatever parts you want.

    You are right about the disconnect between the US and other countries. We are a driving force here in terms of standards, but a lot of great innovation comes from elsewhere. We talked about how Railcom is very big in Europe, but not so much here. Still, we can get it all working together, but it can talk about as long as creating a new layout :) I know we want to plan things in advance. My take on it is that it takes about 2 months of reading and talking to people to get up to speed on enough of what technology is out there to feel confident in what you are doing.

    As for me, I am pretty happy running a few trains in loops ;) I like watching the trains run. I can run some routes. I can let the kids play with the trains. And I can have fun making scenery and lighting. Other that some accessories and turnouts, I don't have the same needs as folks who have serious setups with lots of detectors and all the rest. I tend to make things more complicated for myself and want things that I don't really need ;)
     
  8. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
     
  9. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    I think for the time being I shall go back to 3D modelling an HOm Gauge double ended snowblower that's much easier ;-)
     
  10. Ash

    Ash TrainBoard Member

    106
    66
    8
    I started several months ago -- at about page 18... I selected the CMRI route for accessories. Still working on the basics. I used the Dex installer to get the Classic DCC++ and JMRI on Raspberry Pi 3b and Uno/Motor shield. (refer to Sumner's website)

    I considered using DCC for accessories, but CMRI gives me a separate connection for accessories. JMRI lets you use DCC and CMRI together. I connected the RS485 adapter to a RP3b USB port, and then daisy chain several Arduino Pro Minis. You might check this site for some ideas. Mine is similar, but I'm using ULN2803A (Darlington transistor array) with the MCP23017 for signals/relays.
    https://translate.google.com/translate?hl=en&sl=pt&u=https://expressoarduino.blogspot.com/2019/08/interface-configuravel-para-48.html


    I seem to have made progress, once I understood how to use multiple Arduinos to connect servos, relays, sensors, lights and fascia buttons for JMRI. I posted some further details here:
    https://www.trainboard.com/highball...-out-card-for-jmri.116454/page-2#post-1141569
     
    FlightRisk likes this.
  11. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    Looks like you have learned quite a lot

    I'd go for CMRI like a shot if it could handle Railcom but from what I've been able to discover so far it can't

    Maybe someone more knowledgeable on the subject can correct me if I get the following wrong, it's just what I've picked up over the last couple of days

    Railcom decoders send out a 2 channel signal

    Channel 1 basically just sends out the identity of the unit and it does so all the time between DCC pulses in about 80 microseconds

    Channel 2 communicates more information but that info has to be requested (or maybe in effect it's a reply to a command) I'm less clear on this bit as much of the info is in German and I'm relying on Google to translate, this requires you to switch of the psu and the decoder then sends a burst with channel 1 followed by channel 2 over about 350 microseconds

    One problem is in reading in the data which is in mV so tiny compared to the DCC current you can do it over the whole layout but with multiple Locos all responding to the same voltage drop at the same time the system will get confused, likewise if you are using the DCC to control other things like point motors there will effectively be noise in the signal

    The next problem is the signal, reading it should not be difficult as it's a UART base signal (forgive me if I use the wrong technical terms here) and all the Arduinos have a Serial Line, unfortunately most of them only have one line and they will use that to send and receive signals from the control e.g raspberry pi running JMRI, the MEGA however has multiple serial lines (4 in total) so no issues there.

    Now here is where I get a bit confused, from the circuits I've seen they appear to feed data from up to 16 blocks at a time into the reader, great if you want to talk to the reader but not so great if all you actually want to know is which block a particular loco is in (but maybe I don't understand the circuits properly as I'm not an electronics expert)

    Also this will not detect things in a block without a decoder.

    So if I were designing a detection system I would start off with current detectors for each block being checked by an Arduino, if it sees a block with something in it then it checks for a railcom signal and if it gets one it tells the system so the report for a block has 3 options, Empty, Blocked or Blocked by Loco XXXX, in processing terms this does not need to happen particularly quickly 10 checks per block each second ought to be more than adequate. But as I said earlier I'm no expert I have no idea where to even start when it comes to programming or circuit design to achieve this.
     
  12. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    The next meeting of the DCC++ EX team and others who wish to see what is happening or help with the project is this Tuesday 11:30AM EST 15:30 UTC. To join visit https://meetinglab.zoho.com/meeting/join?key=1098237809. There will be dial in number for most countries if you can only access by phone to listen in instead of using a browser for the video meeting.
     
  13. TrainzLuvr

    TrainzLuvr TrainBoard Member

    186
    268
    12
    Hi Excalibur,

    I'm also interested in Railcom+ on my layout, although I am using LCC/OpenLCB for it.

    If you read the https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf it basically tells you how Railcom+ works. A Command Station (CS) or a Booster need to generate a power cutout, at specific intervals in DCC signal, to allow for decoders to communicate Railcom+ packets. This has to happen while power is off on the track, and while it lasts a very short time, it is long enough to send a few bytes.

    The way you need to think about detection is not along the entire main line all at once, but in blocks. Granted you could have multiple locos in a single block and if they are equipped with Railcom+, they will ID themselves accordingly.

    Also, think of your CS/Booster as separate from accessories e.g. BOD (Block Occupancy Detectors) in this case. Your BODs will be independent circuits that will be responsible for their own sections of track and any communication of data.

    There are two things happening here: BOD will be monitoring its designated section of track, and sending events via some protocol back to the CS, when necessary. The latter does not happen over the DCC signal, but instead via LocoNet, OpenLCB, MERG CBUS etc. protocol CS supports for accessories.

    Railcom+ datagram includes both Ch1 and Ch2 (commands, data, etc) in sequence. As per s-9.3.2, Section 3.1, Ch1 must be broadcast after each DCC packet a mobile decoder receives, so a BOD that supports Railcom+ would always listen for this.

    When an occupancy event occurs, and at the opportune moment during a DCC cut-out, BOD would also get the Railcom+ signal and include Ch1 information if present in its report back the CS. For this to happen, the BOD hardware would use an UART port, as data is a serialized sequence of bits with correct timings (as outlined in s-9.3.2).

    If BOD hardware supports Railcom+, and if requested by the CS through a command, BOD would initiate the communication with the decoder on Ch2.

    CS has to initiate a request for further data on Ch2, and thus it needs to keep track of where ID-ed decoders are (which block of track, thus which BOD address is responsible for it).

    BOD would first send a command to a specific decoder (Ch2 "addressed decoder" from s-9.3.2, Section 3.1 in this case), then in the consequent packets wait for the decoder response, and pass that data back to the CS.

    Obviously none of this happens simultaneously (it's serial communication), so a BOD would act as a buffer for any commands back and forth and would ensure they are executed in a timely manner.

    Hardware wise, for a BOD with Railcom+ you would want something that has plenty of UART - a MEGA128 comes to mind for being ubiquitous, and somewhat easy to program. Though I would not stop with BOD/Railcom+ only, and also handle track power (On/Off) and short-circuit detection/protection for each block. But that could be a Phase II, once BOD and Railcom+ are working. :)

    Above is my understanding of the process, and although I did spent considerable time in the past researching this, I could be terribly wrong.
     
  14. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    Thats pretty much what I understood, I think the Mega has 3 spare serial ports if we don't include the one used to actually communicate with the base station, but it looks to me like one can only effectively use one serial port per Block because otherwise the port will potentially get a signal from more than one decoder and won't know which block it's in.

    This was why I was asking if there was some way to use basic block occupancy detection to identify which blocks are occupied and then only interrogate those blocks in sequence for a railcom signal e.g technically the little station I'm working on has 9 blocks which could all be occupied 2 goods sidings, an engine shed, a terminus platform, 2 platforms that can each have 2 short trains and an overflow/goods platform.

    Generally for just detecting where any particular train is and showing it on the computer screen all you need is the id of unit in the Ch1 data but I was looking at JMRI and trying to understand it and I THINK that it only supports the use of one type of BUS at any time the LCB Bus obviously supports railcom, but its less clear if I can use it to run turnouts, lights and accessories under JMRI in the same way that I'd be able to using CMRI ... too many "Standards"
     
  15. TrainzLuvr

    TrainzLuvr TrainBoard Member

    186
    268
    12
    You could probably poll the ports through a serial port expander, and then only have one Railcom+ detector, although that all has to work fast enough for the DCC signal. You will probably need to adjust timing for sequencing all ports, etc, which could be a lot more effort than just building 9 full detectors.

    Much easier is to build a detector using some easy to find parts and standard code, make it work, then clone it 8 more times. :)

     
  16. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    Well a lot more than 8 more that was just one station LOL but maybe thats not a bad sort of way to do things, I wonder if the following is practical, You have one master DCC++ex base station that generates the DCC code and maybe takes care of the programming track, then for every 3 Blocks you have a booster station which also acts as a block detector though I'm not sure this will work, because the locos will all be sending back their signals at exactly the same time so I'm thinking maybe that will cause issues trying to take in 3 sets of data at once over 3 serial lines :-(
     
  17. TrainzLuvr

    TrainzLuvr TrainBoard Member

    186
    268
    12
    Do you really need a booster for every 3 blocks though? Can you fit more than 3 trains into those blocks? Is your traffic that busy?! :)

    Generally, your block is the size of 1 train length and you would most likely have 1 block distance between trains, or your trains will run like a never ending string and it won't look nice.

    What are the reasons to skimp on block detectors? I'm also making an assumption you want to automate your railroad, so BOD is an essential component and needs to be everywhere automation happens.
     
  18. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    Ah sorry you misunderstood, the mega can handle 3 extra serial lines so if we assume one line per block and one standardizes it so that the mega can cope with running a booster, doing current detection and checking 3 blocks for railcom at any one time thats how I came up with the above idea, but I'm not sure if even the mega can handle 3 railcom signals at once one per serial line.

    The layout I'm working on is an alpine one based on a genuine location, there they run a single train every 30 mins up and down the mountain, but if things are busy (which they always are in tourist season) there may be several trains tail chasing each other, the trains travel slowly on a rack railway with under a minute between trains, they are also short, two to three carriages including the driving one so each train is between 35 and 50M long but the platforms are over 200M to accommodate up to 4 trains at once. So my blocks between stations will be short and there will be multiple blocks to a platform.
     
  19. TrainzLuvr

    TrainzLuvr TrainBoard Member

    186
    268
    12
    Thanks for the layout clarification, it sounds like a busy place to model with lots of activity.

    I am not sure about mega doing all these things though, and as I said I would separate BOD and DCC CS. Mega boards are not that expensive so you can get a whole lot and build a separate CS with one and BODs everywhere with others.
     
  20. Excalibur

    Excalibur TrainBoard Member

    14
    2
    2
    Neither am I, currently really trying to understand whats practical rather than what's
    possible. Once I understand that i can start to work out how I need to prep stuff, in my experience it's a lot easier to prepare first and then build rather than build first then have to take stuff apart because you didn't allow for something, that can get very expensive in both time and money .
     

Share This Page