I would suggest try and process the data if it is available even for channel one. By having general occupancy data coming in the user can decide if they want to auto recognize a loco put on the rails etc. The channel two data is more important for the POM feedback support since with it you can do a read CV outside the PROG track. Sent from my ONEPLUS A5010 using Tapatalk
Most will, the brake pin typically will set both inputs to low and the sense circuitry is still in tact Sent from my ONEPLUS A5010 using Tapatalk
@UkBloke Not sure where you were asking about specs, but we do care about pre Ack current in that the spec says a 60mA pulse for 6ms and a max current of 100mA. So we should get a base reading to see what that value is. Sound decoders are sitting there making all kinds of sounds and pulling some current. The spec from the DCC Wiki also says this: "The programmer should scan for the pulse after the end bit of the second service mode instruction packet, or as many packets as needed to send the instructions, as well as the specified decoder recovery time. The programmer must continue to send packets to the programming track (which turns supplies power to the decoder) until the end of the decoder recovery time." What is "the specified decoder recovery time"? Is it decoder dependent? And this: "Long preamble: The packet will have a preamble of at least 20 bits, to allow the decoder time to process the instructions. Power on cycle: After applying power to the track, the programmer will send at least 20 valid packets before service mode operations commence. This allows the decoder to power up and stabilize.During this time a current draw greater than 250mA lasting more than 100mS after initialization of packet transmissions is considered a fault condition. A decoder should not draw more than 100mA of current, except when processing an acknowledgement." If 20ms passes without a valid packet, the decoder exits service mode until it gets another valid service mode packet.
Many thanks for all the info.... here is how I see handling it. You can check the code in my repo https://github.com/Asbelos/CVreader Its pretty easy to read compared with the original. If the max current is 100mA then the idle current must be below 40mA or the decoder could not create a 60mA spike and stay under the limit. So... we can treat anything up to say 50mA as a zero because even a decoder idling at 0mA must create 60mA for a one. Thus the idle baseline doesn't actually matter UNLESS we have a programming siding and have driven a train full of lights on to it! My CVReader (with diagnostics switched on) reveals these raw analogRead(currentPin) values (assumes the value->amps conversion factor can be calculated elsewhere at compile time depending on hardware). 1. Minitrix 16232 no sound. Idle=0, max during pulse=93 2. Kato EMD SD40-2 with sound. Idle=9, max during pulse=143. My waveform code NEVER stops sending (except during railcom cutout on main). On the prog track it sends resets if it has nothing else to do. The getAck() code deliberately waits until the previous programming packet has started sending before sampling the track power. I can see from the experimental sampling results that its taking up to 25mS from the start of the first message until I can safely say that we have a zero... so that's handling the decoder delay. My config values are Code: // ACK current analogRead values (vary depending on motor shield and cpu voltage) const int ACK_TIMEOUT = 25 ; // millis getAck is prepared to wait for a signal const int ACK_MAX_NOT_PULSE = 10 ; // current below which this is NOT a pulse any more const int ACK_MIN_PULSE = 50 ; // current above which a pulse is recognised Number of preamble bits is configurable... I'm using this: const int PREAMBLE_BITS_MAIN = 20; const int PREAMBLE_BITS_PROG = 22; but any better suggestions are welcome. My power-on routine introduces a deliberate delay of 20ms after power on before allowing other stuff ti happen... I think that's long enough for the 20 resets (on prog) or idles (on main). If not let me know. Interesting conflict between the "100ma max current" in the first quote and the "100mA except... " in the second. It'll never happen ...
I have updated my CVReader https://github.com/Asbelos/CVreader to include diagnostic output of the ack pulse detection. This shows max= highest current reading from sensor pin, up= number of samples taken before a ONE bit or timeout detected, down= number of samples taken before current returns below the lower threshold. If anyone can try this (you will have to look carefully at the pin numbers for your hardware in DCCWaveform.h) I would appreciate feedback. Also... note that program then goes into JMRI input mode so you can use <...> type commands to read cvs and drive locos!
The max current EXCLUDING the current pulse. So resting current can be 100 mA. Not everyone is an N scaler I think the miscommunication was my fault in the way I worded the first paragraph. So there is a relatively tight window in there of 100-250ma. So a decoder could sit idle at 100mA and give a 60 to 150mA pulse if it wanted to (over 250 should trip the overcurrent protection) The experience of our users is invaluable because they will have different scales and different locos and decoders to test. I don't think all of them are in spec either, but I suppose we can deal with those as we find them.
Thanks for putting me right on this... so I will put the baseline stuff in... actually simplifying the code even more in the process! I have ****loads of programming experience but no real DCC experience but trying to create something that will make future maintenance or porting so much easier. What I have working so far looks like it has eliminated huge amounts of complexity and seriously reduced the memory requirements. Your experience is really helping.
Hi! I've tried the new DCC++ EX sketch on my DCC++ system (arduino uno + deek robot motor shield + JMRI)... but i've found a problem (or bug?). I use many Doehler und Haass decoder and because of them, with the old DCC++, I needed the modification described in this thread: https://www.trainboard.com/highball/index.php?threads/dcc-issues-with-d-h-10c-resolved.106064/ Without that, I could not read nor write CVs on my DH10C decoders. With the last version of DCC++ EX that I've found on github, i have the same problem: I always receive error 308 in JMRI when I try to read or write CVs on D&H decoders. I've tried to edit the PaketRegister.cpp file in DCC++ EX according to the Packetregister.cpp found in that thread, but only with partial success. I could read CVs, but when I try to write a CV, I always receive the 308 error. Can someone please help me? Many thanks Roberto P.S. Sorry for my english
Hello Roberto. What DC voltage are you connecting to your Motor Board? The only setting you should need to change is this near the top of PacketRegister.h: #define ACK_SAMPLE_THRESHOLD 50 We are looking for a current pulse from your locomotive of at least 50mA. Some older trains or smaller scale locos have trouble generating that much current (the NMRA specification requires 60mA!). Just make that value lower. Try 30 and see if that works. You can probably go as low as 10, but don't go lower than you need to. Let us know if that works for you.
Thanks for the answer! I use a 15V/5A DC power supply and yes, my locos are small: N scale. I'll try to play with the setting you've kindly suggested and come back here with the result EDIT: Nothing. I've tried to lower that setting down to 10, but I get always the 308 error by reading or writing, but only with D&H decoders. With ESU and Zimo I can read and write CVs without problems. It looks exactly like the bug reported in the thread I've linked two posts ago. EDIT 2: From the same thread: https://www.trainboard.com/highball/index.php?threads/dcc-issues-with-d-h-10c-resolved.106064/ I've copied and pasted all the sections with "bRead" and "bWrite" to the "PacketRegister.cpp" from DCC++EX, compiled and loaded to arduino. Now I can read CVs from D&H decoders, but i get the 308 error when writing. By reading again that CV, I see that the CVs are correctly written, but there's anyway a bug somewhere. Any idea? Here's the packetregister.cpp I'm using https://pastebin.com/a7C76K19
Hi @roby02091987 It seems hard to zero in on a definitive version of all the changes. First, get the latest build here: https://github.com/DCC-EX/BaseStation-EX/tree/master/DCCpp_EX/DCCppEX If Reading a CV works now, then we know the threshold value is good enough to detect the ACK pulse. See if this code works better. If you overwrite everything, make sure to set your threshold back to 10 or what you felt was a good value. The WriteCVByte and WriteCVBit routines are similar the the ReadCV routine. There are two sets of packets sent to the decoder for writes, the write and the reset. loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bWrite,3,5); // NMRA recommends 5 write packets loadPacket(0,idlePacket,2,6); loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bWrite,3,5); // NMRA recommends 5 verify packets loadPacket(0,bWrite,3,6); // NMRA recommends 6 write or reset packets for decoder recovery time So if the download still doesn't work, we can try to change the last line in the second group to be idle packets also. Let me know what you find.
Hi @FlightRisk , I've downloaded and tested the latest build, but with that i can't read nor write CVs. In order to read CVs i needed to add a line in the two read routines, now both of them look like this: 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); // Line for D&H decoders loadPacket(0,idlePacket,2,6); // NMRA recommends 6 idle or reset packets for decoder recovery time For the writing, i have the same problem: When i try to write a CV, Jmri gives me always the 308 error, BUT when i read that CV again, the new value is correctly written. So, I can write CVs, but somehow i can't get the feedback that the writing operation occurred correctly. EDIT: Now everything works! I've edited the two write routines like this: loadPacket(0,resetPacket,2,1); // NMRA recommends starting with 3 reset packets loadPacket(0,bWrite,3,4); // NMRA recommends 5 verify packets loadPacket(0,idlePacket,2,10); // TODO remove old line after testing And the second one: loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bWrite,3,5); // NMRA recommends 5 verify packets loadPacket(0,bWrite,3,1); // NMRA recommends 6 write or reset packets for decoder recovery time without other modifications. The ack_thresold is 50.
Great! I will check that out and see what is happening and incorporate that. I was going to tell you that the write is probably working and you just aren't getting the ACK. This tells us that the ack is being missed in between all those write packets. That last packet only sends it once. So in the pause that happens because another write is not immediately going out, the ACK is sensed. Interesting!
At this stage I would recommend to use DCC++EX https://dcc-ex.github.io/ or my fork dcc-ardu, not the DCC++ original as it has many problems in that part of the code which makes it more "it happens to work" type of program. For example the original code does not work wit Zimo decoders which answer faster than the code goes into "litsen for ack" mode. Much of this has been fixed in the newer versions. Harald.
I'm brand new to DCC++ and EX, and fairly new to Arduino's, but I just downloaded the version from Harald's link and have a question... I loaded and installed BaseStationEX\DCCpp_EX\DCCppEX\DCCppEX.ino into my Uno, using the Arduino IDE. It seems to control my three Zimo decoder'd trains fine using the latest version of JMRI - awesome. But when I switched to my programming track, JMRI can no longer read any of the Zimo CV's. Have I installed the wrong thing the wrong way? Ross.
Were you reading CVs on the main track? If so, then things are wired backwards. You can't read CVs on main. In our software you can still write to them though. It just won't send an acknowledgment that the command was received as designed by the NMRA standards. On the Program track, you should be able to read and write and get ACKs but throttle commands are designed to be ignored. Sometimes you have to tweak settings to be able to sense the ACK pulse sent back by the train.
Thanks for the quick response Flight! Tried reading the CV's on prog track, but no response from either my Zimo MX622N's or my ESU 50709 Digital coach lighting decoder. Tried on main too, but nothing there either. The trains do respond correctly to throttle and light settings on the main, as you'd expect - so the unit is working. I appear to be able to successfully reprogram the CV's on either prog/main, but there is no ack from either. When you say you sometimes have to tweak the settings, are you talking about just changing the 50 ms ACK_SAMPLE_THRESHOLD in PacketRegister.h? If so, based on the discussion up-thread, am I right in guessing I should try a lower value because the Zimo's respond more quickly than most decoders? Maybe try 40, then 30 etc? Ross.
