Regarding measuring the voltage on pin 6 of the opto... Are you measuring ~2.5V *while* that pin is connected to pin 2 of the arduino? Is so, where should I connect the second probe? Ground? Vcc? You gave me another idea too... since the arduino has an internal pullup resistor, I'm going to see what happens when I remove the resistor from pin 6 of the opto.
Oh wait, I made a small bit of progress! I've been scanning google for schematics using the 6n136, and there was a side note on one of them that said it could be replaced with a 137 if you included the resistor on pin 7. (!) So I *removed* my resistor from pin 7, and now I have a 2.5V signal coming off of pin 6. I swear this is the first positive step I've made in a week. Unfortunately I've tried a couple different sketches and STILL not actually getting any results from either the sniffer or the LED decoder. *sigh* At least there's a chance that a signal is reaching the arduino now.
Well here's an odd bit... I noticed once in a while as I was poking around the board one of the serial LEDs would flash, and some info would be echoed to the serial console. The USB port is connected to the first serial port on the arduino, and there are exposed lines for a second serial port. It's not consistent, but I could get it to output data once per second (the update rate I set for the sniffer) if I held a finger on or near those pins. Moreover if I attach a 6" wire to Rx and let it hang, I can get it to continue outputting data when I walk away. I played around with changing the Vcc and ground wires, adding 0.1uF caps across various locations, moving the 270pF cap around the track input lines, but nothing seems to make if output data consistently without either my finger or that wire hanging from Rx. As near as I can tell, the arduino just freezes up without that interference. I also tried loading the LED test program, but still couldn't get it to accept any commands to light the LEDs. And when the sniffer is running and I send turnout and accessory commands, I don't see any indication of them echoed to the serial console. It's a sign of a little more progress, but still no success.
OK one last update for tonight... it appears I may have an interrupt problem. I connected that wire from Rx to D2, and now I am getting legitimate data on the sniffer. It is showing packets for my loco at cab 03, and when I send an accessory command <a 6 3 159> it showed up as device 24 in the output. So hooray, some actual information finally! However it is after 1am here so I will have to wait until tomorrow before I try to sort out exactly what is going on. It definitely has to have both pins of the arduino connected to pin 6 of the opto. Does anyone know how to change the pin number within the sniffer?
Unless specified, all measurements are made against ground. The 2.5V is the mean value between logical 5V and 0V, so it is direct voltage. If the opto is fed with 5V and with its 10Ks, you do not need the arduino. At the same time you see if it is not 0V or 5V. To do that, you must declare the input as pinMode(2,INPUT_PULLUP); https://www.arduino.cc/en/Tutorial/InputPullupSerial
All right, fresh start, and making progress. So for some reason it seems that with this board references to pin 2 are going to the physical pin 2 of this board (marked as Rx) rather than the I/O pin 2 (marked as 2). Or maybe the pin number doesn't matter and only the interrupt has any real function here? Anyway I have connected opto pin 6 to the arduino Rx and set up the code to use interrupt 2 (this matches the pinout for this board) and the sniffer is working beautifully. I still cannot get Rudy's DCC decoder program to work. I set it up leaving accessory 2 as a one-shot but setting its duration to 10000 (10 seconds). On the bench this works fine, when I plug in the arduino the LED comes on for 10 seconds then turns off again. When I plug in the DCC signal, the LED comes on and never turns off again, and the serial port goes away as soon as setup() completes. There is no response at all when sending <a 1 0 1> (to turn on the first LED) or <a 1 1 0> (to turn off the one-shot). Is there a different command I should be using to activate accessories in this code? The interrupt definition at the beginning of the code was changed to 2. The pinMode command in setup() was tested for pin 0 and pin 2. It's interesting to note that the sniffer never actually defines an input pin though. Next I tried the Nmra 17LED decoder from Geoff's page. Here the DCC function was initialized using interrupt 2 and pin 0, and after punching in a few test commands I found that this code responds as functions on address 24. For example using <f 24 144> will turn on LED0. So FINALLY I have a working decoder! Only one more step to go, as the goal was to make a decoder for turnouts and this code does not respond to <T> commands, but at least I know I have functional hardware now and I know what pin and interrupt to use. I'll play with some more sketches later today and see what comes up, but once I find something that responds to the <T> commands then I can move forward with trying to get the PCA9685 16-servo board working as well. The final step will be trying to get this to all work on an ATtiny, if possible. And I noticed this morning that the headlight in my DCC-fitted loco has gone out. It still responds to throttle commands, just no longer has a light. I guess it is time to pull it back apart and get it replaced with an LED that is actually connected to the DCC board. So once again, thanks to both of you for all the extensive help you provided! It's been a really rough week trying to figure this out but I finally made it because of all of your suggestions.
Great! - you are getting some positive results! I'm not familiar with the Pro micro, but it does look as though there are differences with the interrupt features on the Pro Micro compared to the Pro Mini or Nano (that I use). I didn't need to change any pin or interrupt settings on Rudy's decoder sketch for the Nano.
Happy to know that it is ok for you. Just to say that I used Rudy sniffer (a V2) on a Pro Mini also without any pin or interrupt change ...
And I'm back up and running again... Had to force myself to step away from it and relax for the weekend, so I'm feeling more focused again. The first thing I did tonight was stop and look at the accessory code I was trying to work with, and realized that I was having to make a LOT of changes to match things that looked important in the function code. It makes me suspect that particular code may not actually be complete, so I stopped and checked what else might be better suited. I noticed that AccDec_10Servos_7LED_6Ftn much more closely resembles the structure of Dec_17LED_1Ftn that was working for me, so I loaded it up, tried to get familiar with what was in the code and how accessories were addressed, then flashed it to the arduino... And nothing. Again. All right it's about time for dinner, time to step away agai... hey wait a minute, I forgot to change the pin and interrupt in the new code! Flashed the change, hooked it back to the track, and presto we're in business and it's responding with serial output to the address and turnout commands. Hooray! Yeah, maybe I'm too old to be getting this excited about such small steps, but hey, I'm too young to care. So now I'm just trying to figure out how to get the LEDs to light up again with either <a> or <T> commands, although since the goal is to operate servos maybe I should try hooking one directly to the breadboard and see if I can actually throw it. Anyway, the fight goes on! Regarding the board changes -- From the reading I have done I have no doubts there are differences between the boards. In fact I've seen a lot of references that specifically use a mini or a nano *because* the exact pinouts are locked in place and even the chinese knock-offs use the exact same layout. Unfortunately with this board, not so much. I'm really not sure why I couldn't get interrupt 0 or 1 to work on D2 but that's actually OK for my needs. I don't need the second serial port for this, so using the Rx pin and interrupt 2 is working just fine, and pins D2 and D3 are actually the SDA and SCL pins for using I2C, which is what the 16-servo controller board requires, so I will be making use of those pins later anyway. I just have to work with the code enough to understand how and where the DCC commands are converted to actual functions in the code so I can add in my own function to work with the new servo board.
I managed to figure out a few things before bed last night. Made changes to the default CVs to use the first four addresses as on/off LEDs and was able to control them with the <a> and <T> commands like I was hoping for. More importantly I found a function near the bottom that handles what to do with each command as they come in, and the structure makes it easily apparent as to how I can add my own routines and servo handlers. Apparently I'm not quite understanding how to set CVs with this code though. That was what stopped me earlier last night, I thought I was sending the right CVs to the right address but they didn't change the function of the pins. This particular bit is what I have to go on: Code: #define SET_CV_Address 24 // THIS ADDRESS IS FOR SETTING CV'S Like a Loco #define Accessory_Address 40 // THIS ADDRESS IS THE START OF THE SWITCHES RANGE // WHICH WILL EXTEND FOR 16 MORE SWITCH ADDRESSES So I thought the address I needed to use was 24, and I know the CV I need to set is 30. I tried using <w 24 30 0> which should have set CV 30 to a value of 0, right? Oh well, I made the changes to the actual code and re-flashed, and was then able to use the accessory addresses to control the LEDs. Tonight if I have time I'll try to add in the library for the 16-servo board and see how that goes.
I know that this is an old thread, but I also had problems with the Arduino DCC optocoupler interface from Dave Falkenburg, using RudyB's software. I couldn't get any 6N137 to work, although I could see they working perfectly when driven with a 1.33MHz 5V signal directly from an Arduino. I investigated further. I've seen Dave Falkenburg's circuit suffer from a phenomenon called Diode Reverse Recovery, where the 1N4148 D1, when reverse biased, conducts for a very short period. This causes a glitch in the output of the optocoupler which looks a bit like contact bounce; on every 1->0 transition, the signal goes 1->0->1->0 within less than a microsecond. Most of the DCC programs / libraries I've looked at are not able to handle this and don't function (often this is unjustifiably diagnosed as a bad Chinese Arduino or a duff batch of optocouplers). The exception is NmraDcc library which contains extra validation of the signal and is able to operate despite the glitches. Solutions to make it reliable include: 1) putting a 10nF capacitor across the DCCin terminals; 2) replacing D1 with a 330 ohm resistor. Replacing D1 with an LED might work but depends heavily on the characteristics of the LED. None of the LEDs I tried (different colours with different forward voltages) made any difference. For more information and supporting evidence, see https://wakwak2popo.wordpress.com/2020/12/11/dcc-sniffer/. I welcome your comments, particularly if your testing confirms (or otherwise) my conclusions.
Thank you for posting your detailed analysis Neil. I had the MynaBay circuit and DCC_Decoder library working really well using a LENZ command station. However, when I switched to the DCC++ EX (MEGA/Arduino Motor Shield) all I got was the empty sniffer output. After spending a couple of frustrating hours checking every component and connection with no success I found this thread and then your blog. First, removing the diode from the circuit and getting sniffer packets showed me I was back on the right path. Adding the 0.1uF across the DCC in also worked. I am intrigued why there is a difference? Is it because the LENZ unit includes a capacitor in the Command Station circuit? Or is it more complicated to do with how the 2 systems generate the DCC signal? Maybe the DCC+ EX build should include capacitors for the main and programming tracks? Thank you again - your blog got my project back on track.
Glad it was of help to you. I only have Arduino based controllers so can't comment on the output circuits of others, but I suspect you're right that commercial controllers have some components across the output that reduce the slew rate, thereby reducing the diode bounce effect on decoders. I also agree that the controller is the best place to address this, not the decoder or sniffer. I recommend the NMRADCC decoder as it has an input filter, and also applies a generous tolerance on the measured bit lengths to allow for measurement inaccuracy, while the MynaBay decoder is much more strict and hence discards more packets.
I will have a look at the NMRADCC library. One thing I noticed is that entering a single accessory decoder command from the DCC++ EX CS results in multiple events being raised by the MynaBay decoder. I saw the same thing on the LENZ system but assumed it was a button press issue - as the commands would be sent as long as you held the +/- key down. Do you know if multiple packets are sent by design or if this is also a possibly a timing issue/signal/interrupt issue in the decoder software? I solved for now by disregarding subsequent identical commands on the decoder onAccessory handler. Will be interesting to see if the NMRADCC library has the same behavior.
The DCC++ and DCC++ EX command station both send multiple (3 I think) identical packets for accessory commands, and loops continuously sending loco commands. This is because the protocol is one-way, with no acknowledgements of receipt, so the command station cannot tell if the addressed device received the command or not. So to mitigate the possibility of lost packets, it sends them multiple times. This works fine if few messages are lost, but if the reliability of communications drops too far then there is a higher probability that a command isn't received at all. As you point out, it is therefore necessary that the commands have a well-defined result that does not depend on the current state. For example, 'turn on' or 'turn off' are well-defined as the final result does not change if the command is repeated. 'Toggle state' is not well-defined as the result is different each time it is executed.
I have all that working now. It was relatively straight-forward to switch out the DCC Decoder libraries. I need to spend some more time exploring the NMRA library, it seems like there a lot more options and configurations than the MynaBay. The optoisolator circuit is working well. Is it possible to add optional LED across both the DCC in and the ARD out without messing it up? Just so that you can visually see that it is connected and ready?
