wavedcc - DCC Command Station running on a Raspberry Pi...

Glenn Butcher Jun 29, 2021

  1. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    First....I've been following along. Not enough programming and electrical background to understand more than maybe 10% but still have enjoyed it. Thanks for posting.

    Secondly........ I do have some background in laying turnouts. I'm not the least bit worried about you having success there. I started with FastTrack code 55 #6 turnout fixture and one of the point forming tools and StockAid tools. Glad I did because I need a lot of #6's and have 40 or so made to this point.

    Saying that though I've built a number different straight and curved turnouts along with some 3-ways off of templates and it hasn't been that bad at all. Even have designed some oddball curved turnouts that there weren't templates for and they weren't that hard. I still use the point forming tool for the frogs and points and the StockAid tool. Wouldn't want to be without those.

    My Point forming tool was suppose to be good for only #6's but have found it gets me close enough for more than that with some additional hand filing to get the angle close (it isn't real critical).

    [​IMG]

    I also have some fixtures (shown above) that one can print for various frog point angles. No printer, no problem, before getting the printer I made some with blocks of wood and aluminum using a saw for the slot.

    So if interested maybe pick up a PointForm tool and StockAid tool and start with using a template (you can print theirs). Sooner or later you will probably move to templates anyway for turnouts or crossings that you only need one or two of. If one is doing a lot, say more than 10, of a turnout the fixtures can speed the process up.

    I have hints on tools, soldering, designing one-off turnouts and more ( HERE ). Good luck and have fun with building turnouts and you are right if they are good they can be very smooth, reliable and look great.

    Sumner
     
    Last edited: Aug 13, 2021
    Glenn Butcher likes this.
  2. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    @Sumner, just walked through your turnout-building pages, a most-excellent resource. I haven't read a bad account about FastTracks, and you've well-illustrated how to use their products to advantage. I'm convinced now...
     
  3. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    Yeah, one of the reasons I got back into model trains was the challenge of DCC (I had a boxed-up collection of DC N scale stuff and another box full of Unitrack). The idea of marrying a Raspberry Pi and JMRI, even with an off the shelf SPROG hat, and time to pursue them, was all I needed...

    Now I kinda like the idea of either DCC++EX or your solution... But if my career taught me anything, segregating tight real-time stuff from non-real-time saves heartache from some really hard to diagnose problems. Maybe the Pi's DMA stuff will do that, maybe not...

    I wish Raspberry Pi had a big/little architecture, with some little cores for the real time stuff, and some big ones for the rest.

    Maybe that's what they intended 3rd party products like the Pi SPROG hat to do. I wish there was a more open hat like that.
     
  4. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    Oh, I'm with you on that, I've had experience trying to sort out a design where too much critical timing was allocated to the unix box. That said, I'm really encouraged by this DMA-gated PWM thing; the programmer just builds a pulsetrain, hands it over to the engine, and goes on to make up the next pulsetrain at it's context-interrupted leisure. The gating engine isn't a thread, and thus isn't disturbed by context-switching. It really is a "little core", with a specific purpose.

    One of the elegant things about having a daemon do all the GPIO for all users is that other programs can monitor the GPIOs while the DMA engine bangs them. libpigpio has a 'scope program, piscope, that does just this, plays all the GPIOs as time traces, and the wavedcc DCC signal is depicted tight and continuous, no gaps where the OS did its thing.

    If you haven't figured it out by now, I rather like libpigpio...
     
  5. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    Are you using DMA to read the current sensor as well? Is there a way to include/synchronize current sensor reads in/with the DCC waveform DMA?
     
  6. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    Not in a phase transition sense. I use the wave_chain() routine of libpigpio to build a pulse train of the 5 verifies and the surrounding resets, kick that off in the DMA engine, then do a loop sampling the current until the waveform finishes. So, with that I know the samples come from within the waveform transmission.
     
  7. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    How consistent is the delay to start of said loop, after the DMA starts?
     
  8. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    The statement just prior to the start of the loop is the function call to start the wave train. Here's a link to the relevant lines of code:

    https://github.com/butcherg/wavedcc/blob/main/dccengine.cpp#L636

    For context, it's in the middle of a function called verifyBit(). There's similar code in a function below that, called verifyByte().
     
  9. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    At this point, I've got a working DCC command station sufficient for my immediate use. Still need to figure out F0, build a couple of throttles, but I can run trains all day, read and write CVs, so I'm happy.

    I can connect wavedccd to a JMRI, run a loco from it's throttle, and read individual CVs, but I haven't yet figured out the whole DecoderPro thing. If someone else takes this on and has wavedcc questions about it I'm happy to answer, but I'm not so inclined to deal with the JMRI side of it right now.

    The README.md file is updated to what I think is sufficient to guide someone in building a simple wavedcc unit for use. Also happy to answer questions on that, and post updates to the README to correct and clarify.

    Right now, sitting in front of the shelf upon which I'm going to build a representation of the Chama, NM north yard, contemplating whether the computer monitor stand I bought will lift one of them sufficient to clear a coaling tower... :D
     
    BigJake and Sumner like this.
  10. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    Thanks Glenn, for proving the DMA driven method on the R-Pi can really work well for creating the DCC waveform, and sharing your insights and trials (and code!) along the way with us. It's been very informative and engaging.
     
  11. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    I was reading the ops manual for my Blackstone K-27, particularly the lubrication section. Interspersed in the instructions are the words "...after every 25 hours of operation". Man, who keeps track of operating hours, I thought. Then, the programmer part of me kicked in, and poof! - wavedcc now does this!

    Didn't take too long to write; essentially, the throttle <t ...> command captures timestamps, and every time the throttle is changed, the timestamps are used to increment the uptime. When the throttle speed goes to zero, the uptime accumulation stops; accumulation picks up again when speed goes > 0. When the main (ops mode) is turned off, the uptimes in seconds for each loco in the roster are written to a file and the uptimes are reset to 0. A new file is written each time. File names are fixed, of the form "year-month-day_hour:minute:sec.txt"

    There are two configuration file properties, one to turn this logging on/off, and the other to specify a directory in which to store the uptime files.

    Now, this is where it gets tricky, to use this data one needs to collect all the entries for a particular locomotive and add up all the values to get seconds of operation. Me, I'd just awk it to death to get a number in total hours, but that's probably not a good solution for folks not versed in unix shell. But, the essential capability is now in the main branch.
     
    BigJake likes this.
  12. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    What a fantastic idea!
     
  13. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    I just posted a Q on the JMRI user group to see if it can do anything like this (which would apply across all DCC system instances controlled by JMRI.)

    It would also be interesting to incorporate locomotive uptime in automated operations, whereby unavailable downtime would be automatically scheduled for locomotives, thus impacting the scheduling of locomotives for trains/moves.

    Hey, it's only software... How hard can it be?! ...Says a retired electronic hardware development engineer! ;):whistle:
     
  14. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    Really, JMRI would be a better place to allocate the function, as DecoderPro is better-equipped already to take on this sort of data. Thing is, to collect data on actual energy applied to the motor, all throttles would need to use the JMRI interface to the layout.
     
    BigJake likes this.
  15. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    Glenn, thanks for your efforts! Without them, I would never have thought about locomotive uptime information, or that JMRI collects this locomotive uptime data!

    It is also, IMHO, just another good reason to use JMRI, and JMRI-served WiFi throttles, to run trains!

    AFAIK, all WiFi throttles (and throttle apps) use the same Wi-Throttle WiFi protocol, and thus are capable of being served by a computer running JMRI, instead of the DCC system manufacturer's or partner's WiFi interface.

    -- Andy - Arlington TX
     
    Glenn Butcher likes this.

Share This Page