So as usual I agree with @Atani. Let's get back to focus and get DCC the best we can then discuss all the rest of it. Focusing on mid/long term is fun but also premature. So I agree with upgrading hardware to latest but really if it improves dcc signal and timing and more future proofs. Loconet, LCC etc do indeed go on a seperate and parallel bus that honestly we shouldnt have in scope at least not until we feel happy with the base DCCEX being stable and optimized.
@Keith Ledbetter yes, we need to keep focus but also be thinking about the future. So at a minimum we need to agree on a common expansion header, and what signals that header contains. I'm going to work on putting together a basic SAMD21 base station that has railcom hardware integrated. I'll build a couple extras and send those out if a couple people want to volunteer on the software side to get the port finished and the railcom turned on.
Ok guys i have wonderful news the new release of the Basestation installer is up and posted to GitHub here is the link for the download please test and let me know. This version will do both Extended and Classic with basic settings for moto shield. More settings for Extended to come once i get confirmation that everything is working the way it needs to again please let me know. https://github.com/DCC-EX/BaseStation-Installer/releases/tag/alpha-1.2
Wadloper97: There are boosters which can make a RailCom cutout if the DCC preamble is >= 16 bits. That's not as much $$ as a whole base station and can be used later as well. At least in my fork I made the preamble 16 bits (actually easy configurable in the source) so that this should work. What Motorshield do you have? Maybe it can be convinced to make the cutout somehow for example by activating a "cutout pin" which then via some logic network could do something on the motor shield (for example if there is a H-bridge "brake" input). Regards, Harald.
I found the reset pin to be redundant, since load does the same thing. So with my implementation I use 3 pins for the busses, one for load and one for clock, 5 total.
Keith's post has pretty well summed it up from my perspective also. Arduino + Motor Shield = Train Controller. That's why I became interested in DCC++. I'd be happy to see a basic vanilla setup available, running reliably and NRMA compliant. Then move up the ladder and develop enhancements where we can see the need. Personally, I'd love to see accessory control taken away from the track buss. But for now I think the main game should be at the basic setup. (Meant to add, I use JMRI to control DCC++. Just couldn't get the hang of Gregg's Controller.)
That is one of the major pluses for LCC, it handles everything that isn't DCC (but does offer a bridge layer for DCC interactions via LCC).
Unfortunately the technical stuff still eludes me somewhat. For example, what triggers a railcom cutout? Do i need it to cut out on the block or on the whole layout? a lot is still a bit unclear. maybe you have a suggestion for essential reading (preferably not in academic german ). If you have already added it to your fork, should it not be merged or made in to a module? I found some of the boosters with cutout ability, but could not find an arduino sketch to demistify it's inner workings, only a pre-compiled hex file. I believe the arduino is 8-bit, so can it do 16-bit output? Or would I need to replace the arduino with something more beefy? Would be alright, since I can still use the arduino in a CNC machine, but I want to avoid unnecessary purchases until I get a working test layout with a few blocks, turnouts and signals going. Since I'll be running only two trains for now, I won't really need an extra booster. The DCC++ base station should do just fine. Besides, how different is a booster from an extra motor shield, except maybe for a more beefy H-bridge and galvanic isolation.. I like tinkering and if I were to spend any extra money it'd probably be on a digikeijs DR5088RC, since that seems to do just what I want, but since I have all these components laying around already I might as well make something out of them. Sorry to come off lazy, but where can I find your fork? There seem to be multiple forks all with the same five year old documentation. it's hard to distinguish them from each other. There seems to be the evili one, but that only seems to have a to-do list, it does explain how to do it, but a schematic and example code would be very helpful, since I have no idea of the railcom/dcc mechanics. I'm also still a bit uncertain if I need keep-alive modules and such for it to even function. I read somewhere the hardest part of the implementation would be compatibility with JMRI, but I forget why. I'm running on the genuine arduino motor shield, still need a proper power supply since this one is but 1 amps, but it works. Like I said, I'd be willing to do some prototyping and implement the suggested changes, but I'm not proficient enough to figure it out on my own.
The cut-out is triggered typically by the command station *OR* by a dedicated device that injects the cut-out during the preamble bits. It depends on if the command station has an integrated detector or not. It can be either, it depends on if you have only a global detector or block specific detectors. A block specific detector could listen only for channel 1 which is used primarily for occupation messages and channel 2 is used for feedback (POM response as example). The AVR platform can indeed process RailCom data just fine, it is just UART data coming in at 250Kbps and only up to 6 bytes of data at at time. I haven't seen very many open source RailCom detectors but I do know of at least one working implementation for the Tiva and I'll be re-adding it back to ESP32 CS soon (reworking it currently).
On the track there is the continous stream of PREABLE-DATA-PREAMBLE-DATA.... The Device which makes the Railcom cutout listens in on the data stream (or is the one that generates it), takes some bits out of the PREAMBLE and replaces these with the cutout. If the PREAMBLE is too short that won't work. As all your booster districts should be in sync, the cutout should happen on all or none. Otherwise you may have funny effects when you cross from one booster district to another. Then you don't need to look at the RailCom data per block/district if you don't want to. Not different. However there are boosters today which can do a railcom cutout. I don't know of any DCC++ fork which can do that yet. https://github.com/habazut/dcc-ardu/ Btw, tonight i did add little better short current protection to the code. Note, my code does _not_ make a cutout signal but there are enough preamble bits so that another device can. About the 16-bit Railcom data: No worries, an 8-bit CPU can handle 16-bit data, it just has to shovel twice internally ;-) If you have the one called Rev3 with the L298P chip then you probably have the same as I have. I have been staring at the schematics but I don't think the L298P can be made to go into "brake"-Mode where it connects the outputs together (and disconnects from the inputs). That would be needed during the Railcom cutout. Someone can please correct me if necessary. We are still quite a long way from RailCom support, especially if we compare to the ones that have been doing that a while: https://www.opendcc.de/index.html But we can aim high ;-) Regards, Harald.
It should be possible since the brake pin is brought out to pin 8/9 on most shields. These same pins are recommended to cut the trace on the backside of the shields and that trace would need to be either restored or rerouted to another pin. The minimum for the decoders to accept the packet as valid is 11 (excluding the RailCom cut-out), with the RailCom cut-out being roughly 5 "1" bits (487 msec vs ~500 msec) it brings the minimum preamble bits to 16 to support RailCom. Definitely no reason not to plan in advance
Thanks for the answers so far, they clarify a lot for me. I'll ask my local computer genius if he has any revolutionary ideas and insights how to proceed for now, maybe he can contribute as he's quite insightful. My main use case would be block control, not much else I think. For now, i can do it with optical sensors which should give me more than enough to mess around with since I'm mainly figuring out things before investing too much. On my motor shield I only cut the Vin trace, since that was the only one in the original instruction video's, since the DCC comes from the arduino before going to the H-bridge, it should be relatively simple to patch in a secondary device to read out the preamble bits? What kind of IC would I need, or would second Atmega be required? I have a spare nano lying around I could try with, maybe.
Wadloper87: I think your (and my) problem is that the motor shield in question we have can no complete the cutout circui. But the motorshield experts here can answer that. Harald.
I just did a test where I reconfigured my layout to be connected with DCC++ and the arduino instead of the LocoBuffer and the Digitrax DCS50. Well guess what happened? It works But with a small quirk. All the turnouts (switches) are thrown/closed backwards compared to what you get when you use the same config with LocoNet (I only changed the prefix in the JMRI config). So the question is where to invert the logic. In the translation to what JMRI sends to DCC++ or what DCC++ does when it get the accessory command. My guess is that we should get JMRI to change as DCC++ only hands through the 0 or 1 it gets for how the switch should be thrown. Regards, Harald.
If you have the Arduino L298 rev 3 shield with an L298P and not one of the "stepper motor" ones (L293D IIRC) you should be able to implement the cut-out period without additional hardware. You will need some sort of detector though. Rev 3 Arduino motor shield schematic: https://www.arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf Implementing the cut-out using this shield (which applies to clones that adhere to the same schematic, most do!) can be done by pulling BRAKE HIGH and PWM LOW. This is effectively the same approach I'm using to inject the cut-out in my code.
I can test that. I don't know yet if I can do the exact timing for RailCom later but to pull some pins during the preamble in some direction and see what happens should be possible to start with (in the interrupt routine). Harald.
Try starting after the first bit of the preamble to pull PWM LOW and BRAKE HIGH. Then go back to normal after the 6th bit has been set up. If you can toggle the bits at the same time that the DIR pin is toggled it would be even better.
The interrupt routine is triggerd when OCRxB is reached at the transition at half bit-1 time. Then it takes a little under 6.6µs until the first instruction of the routine actually is executed (says my scope) and then at another 8.7µs it's done. So I don't think I can hit the transition as I don't have a timer "to get there". The DIR pin and the interrupt routine with it's 6.6µs startup time are on the same timer. Or do I see that wrong? Code: ISR(TIMER1_COMPB_vect){ // set interrupt service for OCR1B of TIMER-1 // here I could do something if (mainRegs.currentBit == PREAMBLE_MAIN) digitalWrite(TRIGGERPIN,HIGH); // 6.6us to here DCC_SIGNAL(mainRegs,1,PREAMBLE_MAIN,tickCounter+=) digitalWrite(TRIGGERPIN,LOW); //15.3us to here } Regards, Harald.
It doesn't have to be exact, but somewhere around 26usec into the bit is the target for the transition to the cut-out, similarly around the same point of exiting the cut-out. You can also try https://github.com/NicksonYap/digitalWriteFast as an alternative that will be faster than digitalWrite, which would be better inside the ISR since performance is key in these.
Hello Harald, I have a bit of feedback on your latest build but first a little background. I have been using the original version of DCC++ for a few years and it has worked well with the exception of one issue - reliably reading / writing CVs. A while back I made edits to PacketRegister.cpp and PacketRegister.h recommended by a Trainboard member and that did help a lot. But I had one locomotive that was still misbehaving. I purchased a Lionel Polar Express and it is the only loco I have that when placed on the programming track has no perceptible movement when a read or write command is sent. Most of my locos click and clack and move down the track but not this one. DCC++ refused to program it but a friends NCE Powercab worked fine (even though the loco didn't seem to move at all). I eventually swapped the Lionel decoder for a Tsunami but the behavior was still the same. Fast forward to today. I have been trying the various DCC++ updates on github and am very happy to see a great team is coming together to resolve some of the nagging issues and then to take the platform to the next level. Until today my Polar Express loco was still refusing to read and write CVs without changing some of the constants in PacketRegister.h. Today I noticed in your comments you had made some changes to the code that may improve robustness of CV reads and writes so I gave it a try. I'm not sure what you did but it works great. Keep up the good work! Best regards, Marty
