A couple DCC++EX questions....

Sumner Aug 15, 2020

  1. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    First, thanks guys for all the work you are putting into DCC++EX. For those that haven't checked on their progress lately I'd strongly suggest seeing what they have done and what they have planned. This is a whole new DCC product coming along that has lots to offer.

    https://dcc-ex.com/notes/rewrite/

    I have a couple questions and will include some quotes from your DCC++EX web site:

    #1. 'An example of this is input and output. It doesn't matter whether JMRI is sending commands to DCC++ EX or if it is a wireless Cab Controller. It doesn't matter if the output device is the serial monitor or an I2C display. It doesn't matter if you want to use a serial port or a network device to route data.'

    I have the components to build two of Dave Bodnar's wireless throttles. The connection between the wireless throttle and DCC++ running on an Arduino Uno is via two HC-12 serial radios. One in the throttle and the other connected to the RX pin on the Arduino.

    Do you see this still working fine with EX?

    Here are two links for anyone interested in the throttle...

    http://www.trainelectronics.com/DCC_Arduino/DCC++/Throttle/index.htm#Wireless_Option

    http://trainelectronics.com/Arduino/HC-12-Serial_Radio/

    -----------------------------------------------------------------------------------------

    #2. 'The current detection routines are completely different. One key difference is all current readings is in milliAmps instead of meaningless pin readings. So if you want to set your overload protection to kick in at 3 Amps, you just enter 3000 for 3000 milliAmps instead of looking up a value from a table.'

    How is this done? Do you have to edit the sketch for the Arduino and then reinstall it?

    -----------------------------------------------------------------------------------------
    #3. A question that might primarily pertain to myself but maybe others also. I have a personal home layout where I'll most likely be the only one running trains and that is what I need DCC to do for me. run trains. I won't be automating anything that I need to control via DCC (turnouts, signaling, block detection, etc.). I'll only use DCC to run trains using a wireless Android throttle (running Engine Driver on my phone) and hopefully one or two of Dave's wireless throttles. That is the extent of what I need DCC to do for me. The question is, should I just be using Classic or does EX still have advantages for me?

    -----------------------------------------------------------------------------------------

    #4. 'The 3 most requested features were: 1. More reliable CV read and writes, 2. Railcom cut-out, 3. Automation. We haven't limited ourselves to just these features, but we put a lot of time into redesigning things to accomodate them.'

    Not a question but an observation. Items 2 & 3 above aren't important to me but #1 is. I've been running the original version of DCC++ for about a year until first going to your Classic version of DCC++ a couple months ago and recently to the EX version. Since downloading both into the Arduino I'd say almost all if not all problems I was having using Decoder Pro to program decoders I've been installing has gone away. This has been huge as at times it was very frustrating trying to program decoders.

    I have a feeling that most of my problems with the old DCC++ was that it wasn't very tolerant of the older DC locos I was converting if all the electrical contacts between and including the wheels on the trucks to the positive and negative supply wires to the decoder weren't in excellent condition. Not sure if you have upped the current or what but it seems to be working well. For those of you still running the original DCC++ I'd strongly suggest upgrading to one of the newer versions.

    Thanks,

    Sumner
     
    Mo-Pac likes this.
  2. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Since it is using the DCC++ serial protocol it should still work. You will need to adjust the config to use a second UART but not much beyond that. Keep in mind that the HC-12 is designed as a point-to-point connection system with one device on each end. I believe Dave did test with multiple throttles and one receiver with success but it is not guaranteed to not have cross-talk/corruption of data if two throttles talk simultaneously to the same receiver.

    Most of the fixes were in making the PROG interface closer to NMRA standard compliant. There are still a few areas which are not 100% compliant but it is at least closer.
     
  3. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    Is this a requirement with the new EX vs. the Gregg's version? I don't remember Dave mentioning having to do that with his install but might of missed it or he didn't mention it. If I build the throttles is this something I could easily do? I'm assuming it would be editing the sketch and reinstalling it on the Arduino. I went through all that except for the editing when I installed Greg's version but would have to look it all up again. Dex's installer spoils one :).

    If needing to adjust the config file is an 'EX' requirement only could I go back to the 'Classic' and avoid doing that?

    [QUOTE=".....K eep in mind that the HC-12 is designed as a point-to-point connection system with one device on each end. I believe Dave did test with multiple throttles and one receiver with success but it is not guaranteed to not have cross-talk/corruption of data if two throttles talk simultaneously to the same receiver..[/QUOTE]

    I saw where he was surprised that it worked. I'm not too worried about that as I really don't see someone using the second throttle. I decided to get the parts since to get good pricing I had way more of some of the parts than I needed for one throttle so building a second didn't add much to the cost and it will be a backup.

    Thanks for the info!!

    Sumner
     
  4. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    It's more likely Dave simply used UART0 (Serial) that is the default for DCC++ (Classic or EX) and routed that to the HC-12 removing the need for any extra rerouting. However, with the EX version it is possible to have more than one UART enabled concurrently (something I added to my original fork of DCC++ that was used as a base for EX).

    I'd suggest use the EX version, you can connect the HC-12 to UART0 but you wouldn't be able to use the same connection for JMRI.

    Good luck!
     
  5. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    I'm running JMRI on a Pi so at the moment there isn't anything connected to the RX pin on the Uno. At this point all that I want to add is the throttle so if I'm understanding correctly I can hook the HC-12 to the RX pin and run JMRI like I currently do and I won't have to change the sketch on either the Classic or EX version??

    Thanks,

    Sumner
     
  6. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Is JMRI connecting to the Uno via USB? If so it is using both TX and RX from the Uno.

    You would need to move up to the EX version likely.
     
  7. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    Thanks, so even if nothing is connected to the TX/RX pins since the Uno is connected to the Pi running JMRI with the USB cable the end result is it is the same as if the pins where being used??

    This came up a while back and Richard posted the following.

    I guess the best thing to do is build the throttle and try running it with Classic and EX without doing anything else at first. Then if it doesn't work I'll be back here with more questions :(. Need to find time to build the throttle, currently actually trying to get a small oval track with a couple sidings up and running so I have more than my short straight test track. Got the table built yesterday and will get the foam board on today,

    Sumner
     
  8. IronMan1963

    IronMan1963 TrainBoard Member

    161
    173
    9
    Not with my experience.
    The Raspberry Pi is hooked up to the DCC++ system via the USB. TX and RX pins are attached to the HC-12 transmitter modules on the DCC++ system and on the throttle. This is per Dave's setup. Dave's throttle and the DCC++ system work on their own. I just hooked it up to the Raspberry Pi with the WI throttle running to see if I could also use my phone. It worked. I ran it first on a Raspberry Pi Zero W. it worked but the Zero W was a little slow to boot. It would work for a small T-Trak or very small N scale setup.
    Later Richard
     
  9. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Sumner :

    1. Yes. You can use HC-12, which is just an serial to radio bridge. Any two serial devices that use a cable can be replaced with a pair of these. We can also use RF24 Node controllers, or WiFi. Not sure why people would want to use radio vs. wifi. I guess the reason is networking is more complex and it wasn't fleshed out in DCC++? And it doesn't require changes to the code for anything that already was working with a serial cable? But it limits your number of devices to the number of serial ports you have. Though Dave hinted it can work with multiple radios talking to the same serial port. I would have to look at the schematic and firmware to see if they actually have anything that is designed to do that and prevent collisions or if it is just luck. Anyway, my advice, use a Mega. Either than or you are going to have to write a few lines of code to add a softwareSerial port to the Uno and use different pins.

    We have pursued expanding WiFi support. That did require writing a WiThrottle server implementation. This is part of the Command Station software now. So anything that talks WiThrottle or DCC++ commands can control the CS (as you can see in our new exWebThrottle). This is a variation on the Bodnar throttle that we will be working on:

    http://www.scalatt.it/forum/viewtopic.php?f=117&t=15474

    and a person who expanded on this and describes it in English:

    https://www.trainboard.com/highball...-to-dave-bodnars-dcc-nextion-throttle.108041/

    About using the USB port and the serial Tx/Rx pins (0 and 1) at the same time. This is is important enough for me to write about in a new reply. Bottom line, don't do it ;) See new message after this one.

    2. You would need to use the new DCC++ EX. If you wanted to change any values, you still can, you would just enter the information in milliAmps, not a pin reading value. The values are automatically set for the motor boards we support, but you can alter them. Some people have had to reduce the ACK value to get some decoders to acknowledge reading and writing CVs. We are looking at a way to save settings in EEPROM that you can edit by sending a command to the CS. But right now, you have to change a config setting and upload the sketch again.

    3. There is nothing wrong with people still wanting to use the old DCC++ "Classic" if that works. We fixed it up a bit. However, the differences between that version and DCC++ EX, especially the current beta release, are large enough to require another document to list them. But a few big ones are:

    • The DCC waveform generator (and much of the rest of DCC++) is completely rewritten from scratch and uses only one interrupt and it is detached from a particular pin. This means we can move the pins around in our software to match most motor boards' configuration. IOW, no jumpers!
    • The ack detection and short circuit detection is much more accurate and much faster. We look for the response to CV read and write commands in between each packet instead of waiting until as many as 14 packets are sent. We break out of sending unnecessary packets once we sense an ACK.
    • Settings for ack detection are customized for each tested board with a formula for that board based on measurements, not a mathematical theory from a spec sheet (which can be off by as much as 20 percent or more).
    • WiThrottle throttles like Engine Driver can connect directly to a DCC++ EX Command Station.
    • There is an internal "board manager" to handle the separate tracks and the handling the different motor controllers that can be connected
    • There is an internal "comm manager" that manages commands and messages and allows more than one controller and routes messages back to the correct device.
    • The Command Station sketch is much simpler because the core functions of DCC++ EX are now in a library (the Command Station EX beta version). Any changes you need to make are all in one config file and there only 2 files, your config file and your sketch file.
    • The library has an API. This means that you can customize and directly program the CS by calling functions if you need to. We also have "user functions" also called "filters" that let you add to or override functions. For example, we built a filter for RF24 support. It is a function that goes in the .ino file. It overrides the turnout commands (all without you having to touch the library). So if you are using RF24 node controllers, the turnout command can bypass DCC and not send any packets to the track, but go to the nodes that are controlling the switches. We will have examples of multiple setups and you can just use the config file you want that has what you need already in it.

    4. This is true about CV Reads and Writes. We are STILL working on that and tweaking it in EX. The issue is that if we are going to try and support different motor boards and different discreet current sense boards, they have to be tested and it is a lot of work. The bottom line is that the BEST experience is going to be with a controlled environment built from the best components like the FireBox. The next best thing is to use an Arduino with tested components. We will have an interim step with our own shield that has a motor controller, current sense, and wifi. Trying to use Pololu boards or discreet little motor controller boards and wiring them up is a huge challenge that would require another white paper just to cover all the things that people should be aware of. If you are using Railcom or Reversing sections of track, you have to check with use before using a board other than the Arduino Motor Controller.

    We will have some release notes and a non technical marketing blurb to make it more clear what has been added and changed in the newer releases. I know it is a bit confusing now with all the versions, but it will be more clear when there is just DCC++ Classic and CommandStation-EX. :) Thanks for all your support!
     
    Erik84750, KC Smith and Sumner like this.
  10. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    DON'T CONNECT SOMETHING TO THE USB PORT AND PINS 0 and 1 (Tx/Rx) AT THE SAME TIME!!

    Will you blow something up? Probably not. But if it works, its luck and 2 resistors in the circuit.

    The USB port and the Tx/Rx (0 and 1) pins ARE THE SAME!! They are connected in parallel. Here is the schematic. The 16U2 Uart (USB) is on the left, the Atmega328p in the middle, and the header for pins 0 and 1 on the right:


    [​IMG]

    Just because something seems to work doesn't mean it can reliably work. If JMRI was *active* and controlling a loco and you had a throttle connected to the pins and trying to control a different loco (hope you don't try also control the same loco ;)) It can interfere. The only reason it works at all is because:

    • The commands are spread out so they don't always collide
    • DCC++ won't respond to an invalid command
    • The throttle commands are resent by JMRI
    • And the protection resistors that offer 2 features (see next paragraph)

    The resistors (RN4A and RN4B) protect the UART chip since things can be plugged into the 0 and 1 pins, and they require 5mA of current to pull the pin low. That means they prioritize anything plugged directly into the pins over anything plugged into the USB port. So if there is a conflict where both are trying to pull the pin low, the pins win. The UARTs bit will be lost. There is also no diode in the circuit to prevent the USB Tx signal from going into the Rx pin of whatever you are connecting to the Arduino and visa versa.

    So you really can't have something connected to USB and pins 0 and 1 at the same time if they will both be sending commands and receiving responses at the same time. And if JMRI has a loco enabled, it is sending the "check current" command once per second and throttle refreshes more often than that. And a discussion for another time is, "how do you know who a response is for when you have more than one controller?". These are some of the significant technical challenges we have been trying to overcome in an Arduino environment.
     
    Erik84750, KC Smith and Sumner like this.
  11. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    Thanks for the detailed information and I'll stay away from using the USB and pins at the same time. I'm really interested in what you guys come up with in the way of a throttle.

    Don't know if this helps or not but maybe take a look at this video starting at about 20 min and 50 sec in....



    Sumner
     
    FlightRisk likes this.
  12. IronMan1963

    IronMan1963 TrainBoard Member

    161
    173
    9
    Dave"s throttle is not running both TX and RX pins at the same time. The throttle Nano is sending the signal via the TX pin of the HC-12 to the RX pin of the HC-12 on the UNO. There is no cross talk of the 2 Arduinos other than the throttle telling the UNO DCC++ system what to do with the locos it is controlling. I have had 6 locos running at the same time with this setup 4 on the throttle and 2 on my phone. It has worked every time I fire the system up. Obviously I am running N scale. Maybe shouldn't work but it has worked for me. All 3 DCC++ system I have built work the same. 2 with UNOs and 1 Mega. 2 different motor shields both L298 boards.
    Later Richard.
     
  13. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    Richard thanks for the input. Are you connecting the HC-12 to the RX pin on the motorshield above the RX pin on the Uno?

    Sumner
     
  14. IronMan1963

    IronMan1963 TrainBoard Member

    161
    173
    9
    Yes it is on the motor shield.
     
    Sumner likes this.
  15. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Hi @IronMan1963 I'm not sure I followed you. I think you are saying that there is no crosstalk at the Command Station level since there is only one HC-12 connected to the Arduino and other HC-12s talk to it via the radio link. Is that right? The only physical connection it the CS's HC-12 connected to serial pins 0 and 1. Sounds like you have a great setup. If you have pics or a video of running all those locos I would love to see it! (I'll give you credit if I "borrow" any of your ideas ;) )

    So there are two issues, the first is running 2 things connected to the hardware serial port at the same time (one into the USB port like another controller such as JMRI) and having the HC-12 Transceiver connected to pins 0 and 1. That is what will cause an issue. It would be interesting to look at the data in a configuration where this is running and see what is happening and how many collisions there are. With 6 locos, each one can still get about 18 commands per second, so there is enough headroom for lost data.

    After looking at the design specifications of the board, they are designed to use a "one to many" configuration. While the endpoints (the arduinos) are using a serial protocol, the radios are transmitting them using 802.11 networking protocol. It looks like one of them may become an Access Point and allows up to 4 connections to it.
     
  16. IronMan1963

    IronMan1963 TrainBoard Member

    161
    173
    9
    I will get you a photo of the setup up on the boards. The only thing the CS gets is the incoming signal from the throttle. The transmit pin is not hooked up.
    Later Richard
     
    FlightRisk likes this.
  17. S t e f a n

    S t e f a n TrainBoard Member

    167
    93
    6
    I have another question about DCC++EX, unrelated to Sumner's question:
    Where is the development/beta version?
    I looked at the development branch https://github.com/DCC-EX/BaseStation-EX/tree/development/DCCpp_EX/DCCppEX , but it doesn't seem like it is the development version you are talking about in your preview of the rewrite, or is it? It still seems to be using two interrupts tied to certain pins, for example.
     
  18. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @IronMan1963 Did you come up with a photo? If not, is the HC12 connected to pin 0 on an Uno and JMRI connected to the Arduino through the USB port (which is the same port electrically)
     
  19. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @S t e f a n We are moving things to a different location. I will post a link later
     
  20. IronMan1963

    IronMan1963 TrainBoard Member

    161
    173
    9
    Yes it is attached to pin 0/RX on the Uno and the Raspberry Pi running JMRI is attached to the USB port.
    Sorry haven't been doing much train stuff lately. Been busy with other stuff.
     

Share This Page