Using Multiple DCC++ systems concurrently with JMRI

crusader27529 Apr 26, 2017

  1. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    So, instead of modifying DCC++ to use multiple Motor Driver boards with the associated issues of current sense and power on/off for the multiple systems in JMRI, I thought that since JMRI appears to allow multiple DCC systems concurrently, I though that it'd make sense to use multiple DCC++ systems at the same time instead of modifying the code for multiple power districts.

    I don't need Processing or any SW like that for control, just basic DCC operation. So, does JMRI actually allow using multiple system concurrently, or am I interpreting the capability of JMRI wrong???

    Obviously, the setup would require multiple USB connections to the multiple DCC++ systems, but that doesn't appear to be an obstacle. Longer USB connections should work OK, up to a point, and shielded cabling and/or USB hubs should be able to regenate the USB data if needed.

    The proposed club layout would be about 40'X50' and placement of the JMRI system would be physically central to the layout.

    Comments please??? Suggestions??
     
    Scott Eric Catalano likes this.
  2. Scott Eric Catalano

    Scott Eric Catalano TrainBoard Member

    205
    57
    6
    Did you ask this same question on the JMRI forum? Ken replied back stating it wouldn't work how ever they have a dongle that makes controllers from multiple dcc systems look like a generic OpenLCB throttle...this may have some merit here
     
  3. CSX Robert

    CSX Robert TrainBoard Member

    1,503
    640
    41
    Why not just use a single DCC++ with multiple boosters?
     
    Scott Eric Catalano likes this.
  4. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    Cabling for long runs can be problematic......using multiple DCC++ systems with amplified USB cables allows full speed communications to about 80', which would be adequate for almost any layout, and likely be more reliable. Depending on distance and cabling, both techniques would work.
     
    Scott Eric Catalano likes this.
  5. RCMan

    RCMan TrainBoard Member

    271
    132
    12
    USB might work at 80 feet but if you do not know how to troubleshot issues on communication I feel you will get frustrated IMHO.

    I have been thinking of using something more reliable for communication to "Dumb Boosters".

    Why not add a Ethernet shield to each DB and connect them with Cat5/6 cables to a switch or hub. Only the Main Booster communicates via USB to the computer and also has a Ethernet shield. A router could also be added for wireless throttles and eliminate the switch/hub for up to 4 Arduino units, that would be 1 Smart Booster, 1 program track and 6 Dumb Boosters.

    Dennis in NE Tennessee
     
    Scott Eric Catalano and KC Smith like this.
  6. brendanf

    brendanf TrainBoard Member

    62
    54
    8
    I don't see why the need to run long comm wires at all.

    If your already running wires at length, why not just have all your boosters in one tidy location and just run the power to the track the length it needs to go.

    And if your worried about voltage drop, just run a larger wire, because you will still need to get power of some sort to the device that will end up at the zone your planning to control.

    @RCMan Cat5 is a good option like you suggested, max length is roughly 300'. Another option, is the very cheap Wifi modules out there. Costs less than a Cat5 cable, no messy wiring to deal with. Just have to get power to the device.
     
    kmcsjr and Scott Eric Catalano like this.
  7. Scott Eric Catalano

    Scott Eric Catalano TrainBoard Member

    205
    57
    6
    yes...its good to have all electronics in one central location.....easy to troubleshoot, configure etc
     
  8. RCMan

    RCMan TrainBoard Member

    271
    132
    12
    Yes, that would work in some cases, but if you have a location with high traffic on wireless or other transmitters the you might have issues. I want to put this in a large club layout in a business and wireless is not the best option, hard wire works better and lets everyone use the wireless part. You only have wireless point that is the router.
     
    Scott Eric Catalano likes this.
  9. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    Just how would you add an ethernet shield to a dumb booster??? It's not as simple as you might think......AAMOF I don't know of an ethernet to digital signal level repeater device, and I'm a retired EE.

    What magic device would you use?
     
    Scott Eric Catalano likes this.
  10. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    Except for the current sense required for DCC++, RS-485 should work instead of ethernet.......actually, ethernet cabling would work for connections less than 100 feet, so that may be a viable option.....

    The current sense issues would vary depending on how the motor driver/booster is designed, but a shielded twisted pair cable would probably be just fine, because the 'bandwidth' of the signal is extremely low......voltage drop would be more of an issue.

    So, I took your technically unsound idea, and probably have come up with a solution.

    THANK YOU.
     
    Scott Eric Catalano likes this.
  11. RCMan

    RCMan TrainBoard Member

    271
    132
    12
    RS-485 would be another option.

    You only need one Smart Booster per system, then Dump Booster does not generate the commands, it just receives and send command from the Smart Booster. The The commands are sent over the IP or RS-485. The Ethernet Shield is the buss to connect the boosters as one system. Have all Boosters in one place on a large layout is not a desirable way of wiring a large layout. You should keep the DCC track buss as short as possible.

    I was into Animated Christmas Light shows for many years. The protocols to send and receive data started out as vendor specific and then started evolving into something universal and better with the demand for more and better network capability. What happened is they adopted two standards and made them work together. The first was DMX which is used by all light studios to control light show effects. DMX is like DCC in that they call it a universe and consists of 512 individual channels. That allowed you to have 512 different lights you can control. After a couple of years the demand for more channels increased 10 fold as the demand for channels as greater than 512. Well adding more universes was needed but adding more connections (cables) from the computer did not make sense. What happened was several people got together and designed how to send a thousand DMX universes each one with 512 channels over one IP cat 5 cable. This was called E1.31 and now is a standard for controlling lights over the internet. You probably say videos of complete buildings or cities at Christmas time having lights synchronized to music.

    What I am proposing is have DCC over IP. The hardware is stable and we all have it now. Lets use it as a buss to connect multiple boosters together.

    Just my 2 cent worth
     
    Scott Eric Catalano likes this.
  12. brendanf

    brendanf TrainBoard Member

    62
    54
    8
    So because you can't dream it up or haven't heard of it or seen it, it doesn't exist or isn't possible?

    Your very rude.
     
    Scott Eric Catalano likes this.
  13. brendanf

    brendanf TrainBoard Member

    62
    54
    8
    Its really not that hard even with existing hardware and the existing software.

    There are a couple of ways to go about this.

    One issue to keep in mind though, IIRC the Uno can't support the Ethernet Shield AND a MD board at the same time. I think one of the timers used is also one of the SPI pins which is how the ethernet shield communicates. You could combine the 2 outputs from the MD to the one timer that is not interfering with the SPI. Disabling the interfering timer would require some deletion of code and some re-writing. So if your planning a multi node system RS-485 may be the best way if Uno are used. An RS485 to RS232 convertor would be all that is needed at each remote driver. The code would be the same. There would have to be some kind of hierarchy with master/slave created to prevent collisions.

    The Mega has multiple serial ports (4) and the ethernet shield can be used with it since a different timer is used to free up the SPI.

    You could connect a MASTER station (Mega) via USB or Ethernet to a PC and connect your different nodes via RS485 one to each of the spare serial ports. In the code on the MASTER in the loop() you just take whatever comes in on your main Interface and parse it out the other ports. Afterwards you can just listen on one port at a time and relay it back to the PC.

    Now if going Ethernet everywhere it would be the same for the most part, but you will need static IPs and have a KNOWN list of secondary IPs to relay to and then just loop through all the IPs sending out whatever packet came in. This might take a lot of processor time so if there are a lot of these to be done, if could interfere with the interuppts that drive the timers.

    Someone once told me about a 'fluid mesh' network which might work well. Each node in a mesh network also acts as a router so it could help take some cpu load off a master base station.

    What are your thoughts?
     
    Scott Eric Catalano likes this.
  14. brendanf

    brendanf TrainBoard Member

    62
    54
    8
    I had some more thoughts on this today.

    To make it more user friendly and easier to code and to clear up one of my concerns.

    We would need to know how many base stations are required obviously, and from there we could set our initial IP address (as an offset) and have any info received relayed to the next IP address by counting up or down until we reach the limits.

    So for example if we went up wards, and had 4 base stations, or initial IP would be 192.168.2.252, then whatever is received would also be sent to 192.168.2.253, and so on, until 192.168.2.255 which is the top of the IP stack. A simple if() statement to test to see if the base station has the max IP would be enough to stop the relaying.

    The whole process wouldn't burden one CPU either.

    Setting each IP adress could also be done a couple of ways. 1. Each one is hard coded in sketch prior to compiling. That isn't too bad since it will free up I/O but it is time consuming. 2. An 8 DIP rocker switch would be very user friendly but eat up a lot of I/O. If there is spare I/O then it's not much of an issue, but an Uno has almost none left. 3. A simple circuit with an LED and 2 push buttons, where the LED flashes the IP address and using the push buttons the IP can be modified and stored.

    Let me know what you think.
     
    Scott Eric Catalano likes this.
  15. Scott Eric Catalano

    Scott Eric Catalano TrainBoard Member

    205
    57
    6
    I personally would't want to be burdened with pushing buttons all the time
     
  16. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    Isn't 192.168.2.255 the broadcast addres for this /24 subnet? Not as simple as you think.......
     
    Scott Eric Catalano likes this.
  17. brendanf

    brendanf TrainBoard Member

    62
    54
    8
    .255 was meant as an example.

    Hard coded IP limits could easily be written into the sketch.
     
    Scott Eric Catalano likes this.
  18. lyncher

    lyncher TrainBoard Member

    16
    11
    14
    Dennis,

    What you suggest is how I understand the NCE system to work: the NCE command station (smart booster) polls each throttle/cab for commands, interprets the commands, generates the DCC signal and sends the signal to the boosters - I believe it's RS485 between the command station and boosters. NCE definitely uses RS485 between the throttles and command station - the throttle/cab bus separate and distinct from command station / booster bus.
     
    Scott Eric Catalano likes this.
  19. RCMan

    RCMan TrainBoard Member

    271
    132
    12
    All DCC systems have some kind of bus to connect the "Base Station" (Smart Booster) to the other Boosters only (Dumb Boosters) . I have seen to many proprietary systems that take telephone cables, shielded twisted pairs, special cables, etc and have a sole source to all the parts, some MFG's release there protocol specs for other MFG's to use, then the other MFG's modify the data buss for there use as they thinks there way is better. Yes you can connect dumb boosters from NCE, Lenx, and Digitrax and others but with limited capability. The newest one is the LCC protocol. supposed to be the buss of the future, well that did not turn out as they are using today's standard automobile communications. Called drive by wire.

    I would like to see off the shelf parts we can use and quickly setup a network for expanding the number of Booster needed to run larger layouts. To way communication is required.

    I do believe in "Keep it Smart and Simple" takes some thought to come up with the end product sometimes.
     
    Scott Eric Catalano likes this.
  20. cmitcham

    cmitcham New Member

    4
    3
    5
    the 10 amp nce system doesn't even bother putting a booster in the box with the command station. the command station simply listens to throttles and creates a dcc signal and puts it on the control bus which daisy chains to the boosters. the command station has no idea how many boosters are on the control bus. each booster handles current sensing/shutdown for itself.

    I just completed my first dcc++ test, and am very excited about what you folks have done for us. I can't wait for the multi-booster final result.

    I about forgot, the command station does power and communicate with the programming track.

    calvin.
     
    Scott Eric Catalano likes this.

Share This Page