DCC++ EX Software Thread

David Cutting Apr 8, 2020

  1. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @UkBloke True on sscanf_P. I had talked to Atani about that. I think most of us are in this conversation now. We are trying to invite a few others, especially on the JMRI side of things. And @haba is around as well. People come and go, but if we can keep up the energy, I think that will help us move ahead. How about making a list of what we want. Brainstorm. Shotgun. Anything goes. In particular, I am suggesting we go over features people have been asking for (better current detection, Railcom support) and things we see could be improved in the code (replacing the packet generating code, maybe even with assembly, isolating units by function). Those are examples, we can decide later what value they have or if they are in scope, etc. Some things might wind up as another project, spinoff or completely separate, and that's ok. We will figure that out by the end of this process.

    Is this the best place to start? Each of us list out our ideas and then one of us organize into a list to vote on? Another project I contribute to has youtube chats at least once a year. It is not a Webex, since one person leads the video discussion and the rest type in a chat window. They create a list and then vote on it. So if you have ideas of how to organize such a list, please offer. It could be added to a todo here: https://github.com/orgs/DCC-EX/projects/2 and then filtered into a final version. We could put a document in GitHub and everyone issue pull requests? That might work. I'm open to anything. Someone start. :)
     
    David Cutting likes this.
  2. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    My vote would be for a group google doc that is view-only, if you want access you can PM @FlightRisk for edit access.
     
  3. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    Actually, I change my mind. @Dex reminded me about discord, and that's where my vote would go. Here's a channel link if people want to start joining. It will last for a day. If we go another direction, that's fine too! https://discord.gg/9DrHnV
     
  4. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    Hi David,
    Yes we are to a certain extent going down the same lines... but have attacked different areas... so there is plenty of room for cooperation.

    1) The DCC API I see you have a working DCC API where you have simplified the interface to the transmitter down to loadpacket, much as I did but yours is more complete because it contains all the turnout and sensor stuff and you already have the serial comms and string parser so I would happily use your bits here. (Although I have a bunch of programming tips that would save you quite a lot more memory)

    2) I see you have implemented automatic generation of the preambles and start bits which is exactly what I did but I think in this area my waveform generator is much simpler because it hangs on a single unchanging interrupt and eliminates the ghastly pointer messing through all those volatile variables which is so difficult to read and has kept bugs hidden for years (e.g. when loadPacket updates nextReg the interrupt handler could get half the pointer updated and start corrupting memory all over the place.) My generator also doesn't need the registers, but loco speed reminders can be sent by a loop function picking up the speed table which you already populate in the api.
    I didn't yet add Railcom cutout, but I can see from your code and a bit of research that it shouldn't be more than 5 lines of code in my waveform generator.

    So I recon if we bolted your API to my waveform generator, we should have something really slick.
     
  5. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    I have been experimenting with a test program to demonstrate proof of concept of my waveform generator and to examine the ACK issues which I understand are causing problems, I now have this working in a simple CV reading sketch which you can try.

    Please see my repo https://github.com/Asbelos/CVReader


    The code has a complete Waveform generator and two functions lifted from David Cuttings API and simplified/cleaned up as an example of how simple it is to now issue messages and get responses.

    Also included is a DIAG macro which demonstrates important memory saving techniques that prevent strings being copied into the precious RAM.

    Please bear in mind, the various hardware specific constants are fine for my MEGA and standard power shield. Your hardware may need different pins. (oh and I don't need the jumper wire...)

    Please let me know if you try it, good or bad!
     
  6. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
  7. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    That code appears to be using a brake pin to do the cutout. As I understand it this will cut the power BUT it will also short the tracks together to make a motor slow down quickly. If the tracks are shorted then a rail com detector would not be able to see the loco response. Maybe I'm wrong but I think the cutout should just cut the power pin.
     
  8. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    You actually do have to short the motor leads together... if the H-bridge simply tri-states the outputs, you'll end up with the railcom on one rail only, and it will be floating, meaning any back-EMF from the motors on the rails will kill the data coming through.

    That's my simpleton understanding, others feel free to add more if I got something wrong.
     
  9. Quax

    Quax TrainBoard Member

    27
    5
    8
    The tracks need to be shorted together to form a current loop. A detector is inserted into this circuit (see Fig. 1 in the RailCom specs PDF).
     
  10. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    Thanks Quax and David... Ok I,ll do that. ( and resolder my cut brake jumpers on my shield! )
    I had assumed that the current loop was through the decoder
     
  11. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    I have added the railcom cutout to my waveform generator in what I think is a neat (maybe even elegant ;-)) way.
    Please see my repo https://github.com/Asbelos/CVReader A search fro railcom will reveal all the code involved in the cutout process and then you can tell me I've got it all wrong...!


    For my next trick, I'd like to see if I can integrate it with David's CommandStation by taking a branch on his repo.
    I expect this to involve changing the internal DCC api calls to call my waveform, and renaming some of my config values to match he traditional ones.
     
  12. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    You got it pretty close, reference S9.3.2 section 2.4 for more accurate timing of the cut-out. You should start the cut-out around 26 usec into the first preamble bit and end the cut-out no later than 488 usec. At the start of the cut-out flush the RX buffer, process channel one data (two bytes maximum, flush extras!) around 177 usec into the cut-out and process channel two data (up to six bytes, flush extras!) around 454 usec into the cut-out. Disengage the cut-out no later than 488 usec after starting it, you can disable it as soon as channel two period ends even.

    I'll fire your code up on my test track and see if I can see any data coming in.
     
  13. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    Awesome of you to take a look... I'll try and make sense of the timings with respect to my single 58uS regular interrupt.
     
  14. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    you may need a second interrupt dedicated just to RailCom decoding, if you can easily change the trigger point on it. Keep your current interrupt for the DCC signal if you can.
     
  15. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    I certainly couldn't interfere with the main timer because it's driving both tracks.

    And... I'm really confused now.... , Why would I want to read the railcom loco response? This wouldn't work with >1 loco on the track and if there's only one, then why would I want to know it's id?
     
  16. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    Channel 1 would be corrupted by a second loco (general occupancy data, loco address will come in on this channel when it enters a detection block)... *BUT* channel two is of interest for a command station since it will contain data from the decoder as a response to a POM packet...
     
  17. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    What about the 2 delay() calls? I didn't really think through it, but wanted to ask at what point those are being called and since they stop all other execution, are they in a place where we won't miss anything? I never use delay in an event driven program.
     
  18. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    This program isn't actually event driven, except for in the interrupt routines where there are no delays or blocking loops.

    The delays are really in the polling loops for ACKs... basically while waiting for an ACK you have to allow the interrupts to keep feeding idles/resets but you cant allow anyone else to run ahead and send packets or else they may send a packet that intereferes with your ack or they get your ack... If this was a multi-tasking operating system, you would have to block with mutexs or something anyway.

    In general, a send to the main track wouldn't be blocked by the prog track waiting for an ack because they use separate pending buffers.
     
  19. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    Clearly I have some more reading to do... but I'm already doing 7 things at once and my wife is starting to get antsy ...LOL
     
    Atani likes this.
  20. UkBloke

    UkBloke TrainBoard Member

    42
    5
    3
    Oh and by the way... the classic DCC++ code delays by looping while(nextReg!=NULL) and by doing thousands of current sense operations.... its all the same in the end.
     

Share This Page