Ok. I know this discussion has been on many threads before. And I'm not one to just blindly post without reading the many threads on this very same issue I'm having that other's have had. But I need some advice, pointers in the right direction if you will. I've setup a DCC++ BaseStation. It consists of an Elegoo Arduino Mega and a Pololu MC33926 motor shield. Genuine Pololu, and even though the Mega is not THE Arduino, it does have high reviews. DigiTrax decoders. Either a H166d or H126d. HO Scale. So here's the recurring issue. No decoder reads or writes on either main or programming track. Yes I know the main ops track doesn't read. Moving backwards from the track. I've tested continuity from track rails to the shield. .05 ohms. Just slightly over what my meter reads with just ohming out the probes. I've made sure that the traces to be cut on the motor shield are actually cut by measuring their resistance and they do show an open. I've gone through the diagnostic procedure first on just the Mega and then with the shield attached. The red/green LEDs do alternate back and forth on both channels on the shield. While the LEDs are alternating, i can see the AC voltage going up and down accordingly. Now to the DC supply. I started with a 12volt 2.5 amp wall wart. With this powering the motor shield, when i would perform a read or write operation, the motor would very very slightly jitter. Barely noticable. But no actual read or actual write. So I tried using a DC old train transformer power supply. Dialed it to 16.5volts with no load on the terminals. The motor shield powered up ok. But now no jitters when doing a read or write operation and the same failed using the processing/controller program. All diagnostics still the same. Same red/green alternating so on and so forth. So bumped to an 18.5volt 2.5amp laptop power supply. Same as with the 16.5 transformer. Went back down to the 12volt. The train jitters are back when doing a read or write but fails just the same. Now I'm totally at a loss. I could really use some help with this one. Thank you Steve
It is not the power supply, I would go back and carefully check the modifications needed to the Pololu board first. Are you trying to read CV's on the Main output or the Program output? You cannot read CV's on the Main output.
I'll go back and double, triple, and quadruple check all the modifications. I'm trying to read any CV on the program track. Using either the JMRI program or the Controller program, or even just the serial monitor on the IDE. On the main track, i can't even do a write. I know the main track cannot read CVs, but should do a write. If there was a problem on the Pololu, i would have thought that it would fail the diagnostic mode. Thank you. Steve Sent from my SM-N950U using Tapatalk
Digitrax decoders are an issue also. There was a small change made to a sketch that fixed this issue. I do not know if this was incorporated into the sketch or not. It fixed my problem and can read anything now. it is posted here on this board.
I think the change you are referring to is the current sample max. I found the post on it. I will give that a try when i get home from work and update on the results. The max setting should be the only change, right? Double it. Would the smoothing value need to be changed for any reason? Or leave it as is? Thank you Steve
This is the information: DCC++ has a noise filter/smoother on the current signal to deal with system noise. With newer low current motors, sometimes the current draw is below the cut off. With Z scale I had to edit ACK_SAMPLE_THRESHOLD in PacketRegester.h to get it to read. I currently have it set to 15 from the default of 30. You could try playing with this setting. I’ve gone as low as 5 and had it work. Still need to work with this setting. BTW my Engine is a Bachmann Forney in LargeScale with a TCS WOW-121 installed. The other is making sure the Read and Acknowledge timing is correct. loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bRead,3,5); // NMRA recommends 5 verfy packets loadPacket(0,resetPacket,2,1); // forces code to wait until all repeats of bRead are completed (and decoder begins to respond) This is the original code from the BaseStation. The DH10C does not perform the acknowledgement because of the last resetPacket that is used to wait until all bRead Packets have been digested. I changed the resetPacket to another bRead Packet and all works fine. loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bRead,3,5); // NMRA recommends 5 verify packets loadPacket(0,bRead,3,1); // forces code to wait until all repeats of bRead are completed (and decoder begins to respond) Similar changes are necessary in the routines for WriteCVByte and WriteCVBit. Use the bWrite and not the bRead on theses two changes
So got home, and immediately the wife had to leave with the 2 older kids leaving me with a 2yr old and a 1yr old. But bound and determined with a baby in my lap and the other running rampant in the house, I made the changes we talked about. It works! Thank you, thank you, thank you. Question, with the digitrax decoders working on the 12volt power supply, i want to run at least 3-4 at a time. Do you think it's safe to use the 18.5 volt power supply now? Steve Sent from my SM-N950U using Tapatalk
Just an addition to anyone who may come across the unique issues I have encountered. So after making the changes that RCMan had mentioned above, I thought I had it all figured out. I had it working on one of my more basic engines. During programming the engine would jitter for every CV read or written, and the light (bulb, not LED) would flicker. But I was using a DC controller/transformer to input the voltage into the pololu shield. It would program the basic engine at a lower voltage, but would not program the Chuggington Bachmann engines. Now these are Digitrax 126 decoders. I had to turn the dial almost all the way up and maybe it would work maybe it wouldn't. The decoders were plug and play. Why did it work on the other engine? Now getting back to it after taking some time away from the hobbie, I went back to using my 18.5v 3.5a laptop power supply to feed the motor shield. USB power to the arduino. Same thing. Worked on a basic engine, not the Bachmanns. Ah ha! These engines, though plug and play needed some mod work. They have 3 capacitors on the engine, as well as 2 resistors. I guess the capacitors act as a filter of sorts when you have not so great connections on your track. When you tried to program a Bachmann engine, the LED would flicker, but kept getting a no acknowledge error from JMRI. I cut out just and only all 3 capacitors. Bingo. Now the Bachmann Chuggington engines with the digitrax decoder will program and read and run without any issues. One other thing I noticed too is that the polarity of the wires from the programming side of the pololu to the track makes a difference too. If the wires are reversed, programming didn't always work. But on the Ops side, wire polarity didn't seem to make a difference. These are my findings thus far. As I continue to build my collection and layout, should I come across any more ah ha moments, I will post it here. Sent from my SM-N950U using Tapatalk
I have been placed at another shop and have a little more down time. So I actually had a chance to bench work it properly. And went through everything with a fine tooth comb. Of course in the process, I end up burning the front light output on the decoder because I let the wires touch while it was powered on the track. Oops. Sent from my SM-N950U using Tapatalk
I also had issues with a Digitrax Decoder and had to get the latest JMRI update as I heard (somewhere) that the prior version had some issues with DCC++ & Digitrax decoders. FYI - I could program my Engine/Loco but could not read it afterword.
