I am currently running DCCppESP32 as my base station and have a train going around the track, now I'm trying to build an accessory decoder. I loaded NmraDccAccessoryDecoder_1 and uncommented the line "#define NOTIFY_DCC_MSG". This is being flashed on an arduino pro micro board. When I start it up, I can see the Serial.print lines from the serial console, but I never receive any DCC commands. Based on the code comments I thought this meant it would show ALL commands that go out over the rails, but nothing ever comes up after the "Init Done" message. Regarding my wiring... I am using a 6N136 optoisolator (I found a lot of references for using both the 136 and 137 with the same circuits, so I assume they are identical in function). I initially had a 1k resistor feeding from the rail to pin 2, but it got very hot and another circuit suggested using a 2.2k which is what I have now. Otherwise it's the standard 4148 diode across pins 2-3, feed the second rail directly to pin 3, pin 5 goes to ground, 8 goes to Vcc, and pins 6-7 each have a 10k resistor connecting them to Vcc. Pin 6 is also connected to pin D2 on my arduino. The voltage supply is 5V coming from the USB port. The wiring was based off this, except I'm using the 6N136: http://www.mynabay.com/dcc_monitor/files/stacks-image-9b57927-898x376.png The code also references a DccAckPin, but none of the schematics I have found suggest anything more than the single D2 pin being hooked up. Should this other pin actually be connected to something as well? Can anyone provide any troubleshooting tips? Am I right in thinking I should be seeing other DCC commands displayed on the serial console? What else am I missing?
Think I found a possible cause. I'm looking at the pinout for the pro micro and noticed that D2 is tied to interrupt 1, while on the Uno it looks like interrupt 0 is used. The sketch does indeed initialize int0 with Dcc.pin(0, 2, 0) so I'll change that tonight and see if it makes a difference. Once I figure out how this all works I need to get it off of pin 2 anyway, because that's SDA for my I2C bus. Hopefully a different pin will work but for now I was just trying to use the default code and make sure it worked before I tried making any changes.
So changing interrupts and pin numbers had no effect, but I did discover a problem with trying to watch the serial monitor from the command line. Got that fixed but still no info being shown. I've gone back over the regular combination of using D2 with interrupts 0 and 1, with and without the pull-up enabled, and I tried swapping out the 6n136 for a new one. Nothing seems to be working. I did add another flag to the serial monitor to show the state of Dcc.isSetCVReady() every so often, which always comes back with 1, so I assume that means 'true'. The other thing that is bugging me is that nowhere in this code does it actually specify the DCC address for this decoder. I thought everything in DCC required an address? But even without a specified address to receive commands on, I would still expect it to be able to see the other commands going out over the rails.
Looking through the NmraDccAccessoryDecoder_1.ino sketch, I think it is intended that only packets that are turnout commands will be shown regardless of the intended address; the code looks for the specific bit patterns of accessory command packets on the rails (remember that the data on the rails is nothing like the ascii string commands that are sent to the DCC++ basestation). If #define NOTIFY_DCC_MSG is uncommented, then all commands on the rails (including cab commands) should be shown. What does appear strange to me though is that the sketch contains some functions, EG notifyDccSigState and notifyDccAccState, that I can't find reference to in the library...... Maybe the sketch example is broken? Jim
There's a couple lines in the code that call out CV29, so I figured I would define turnout 29 just in case that was right. I sent <T 29 29 0> to my base and got a confirmation back. So then I sent <T 29 1> which should put that turnout into a thrown state. I receive back <H 29 1> so I know the base station is accepting the command... but there is still nothing on the arduino. Even if the ID is wrong, I do have that line uncommented so I should be seeing ALL or the possible turnout commands in the serial output of the arduino. So yeah, I'm thinking either their code example simply doesn't work at all, or there is some problem with the optoisolators I'm using. Any suggestions for some accessory code that is known to work with DCC++ and shows me when commands are received? I'm the meantime I'm going to dig around on google again, seems like I saw one project demo that just lit up a row of LEDs, and that would also work to confirm if my hardware is functioning. [EDIT] Oh yeah, I still had the page open on another tab. It was this demo circuit by Geoff. OK will have to try that one tonight, although his circuit also uses a different board than what I have. At least I have more confidence that his code actually works.
My turnout decoder uses Rudyb's software on his site. It has always worked without any problems, although I only need it to operate 4 turnouts. https://rudysmodelrailway.wordpress...uino-dcc-servo-and-function-decoder-software/ The references to CV29 in that code are nothing to do with the actual id or address of the decoder, they are to do with the internals of that library. The setting up of accessory decoders with DCC++ needs an address/sub address to be programmed. I fell foul of this when I first set up my system! Have a look at this page - specifically the first post in the comments section; http://model-railroad-hobbyist.com/node/27318?page=11 So to setup the first turnout (with an id of 10) that is on a decoder set at address 40 needs the DCC++ command: <T 10 10 3> Then to operate it you would send <T 10 0> or <T 10 1>
I thought your turnout definition had a typo and just skimmed over it yesterday, but after not really making any new progress last night I re-read, and then followed through on Geoff's post that you linked. AH!!! I have not seen the funky addressing referenced anywhere else, so let me repeat this info in case anyone else comes by later (because I REALLY hate posts that say "I figured out the problem" and never say HOW they fixed it!) ... Turnout definitions under DCC++ have an odd way of doing their addresses. When you define a new turnout you have to do some basic math and specify the address in two bytes. So it looks like if your decoder address is 40, then the two bytes will be '10 3'. 37 = '10 0', 41 = '11 0', 42 = '11 1', 45 = '12 0', and so on. As Jimbo stated above, the command to define a new turnout is <T 10 10 3> where the first '10' will be your reference, and the final '10 3' is specifying a decoder address of 40. All right, so that gives me something more to test tonight. I can access it remotely so I was able to punch in <T 10 10 3> and I got back <O> which I didn't see when I previously tried to define a turnout, so that seems promising. Unfortunately I can't see the LEDs from my office so testing will have to wait until I get back home. I did expect however to see something from the serial console showing the debug info when I sent <T 10 1>, but it's still blank. Is there something I'm suppose to send to the accessory decoder to initialize it? I thought those examples were pre-defined to set the first 10 outputs as LEDs that could be turned on and off? (And I only used the first four for testing, pins 3, 4, 5, and 6). Also can anyone tell me the difference between the AccDec_ and Dec_ examples? Are there differences in how you would send the commands to activate each channel? I also started playing with CVs last night. I have a SoundTraxx decoder in one loco that I picked up last weekend, and thought I would try setting the rate of acceleration (CV3) and deceleration (CV4). Well the acceleration set correctly using <w 03 3 24> however when I tried setting deceleration with <w 03 4 24> nothing changes. If I put the throttle at 50% it accelerates nice and smooth, but when I drop back to zero it just stops. I have no idea what I'm doing wrong.
I think I might be onto something here! What version of NmraDcc.cpp are you using? I was looking at the one on GitHub where the NmraDccAccessoryDecoder_1.ino is. BUT the NmraDcc.cpp on that Github which has updates to 2017-11-29 listed in its header does not contain functions that include notifyDccSigState and notifyDccAccState as I previously mentioned. However the NmraDcc.cpp included in geoff's zip file here is dated 2015-11-06 and does contain those functions: http://model-railroad-hobbyist.com/...bfiles/new-dual-multifunction-decoderv5_4.zip I'm hoping that the reason you can't get it to work is that you are using the later library, which quite possibly won't work with geoff's decoder sketch or with the example NmraDccAccessoryDecoder_1.ino sketch on the Github - in other words you need to use the older library included in the Geoff's zipfile? Fingers crossed......
For the testing last night I actually unzipped a new copy of the arduino IDE and only put in the libraries from Goeff's zip file. Strange though, I got it from the same link as you mentioned above but my NmraDcc.cpp has a date of 2016-May-11. Regardless, I would think that the code wouldn't compile if there were missing functions in the library I'm using? I also noticed that in Dec_17LED_1Ftn the decoder address is defined as 24 rather than 40, so I defined a new turnout as <T 6 6 3>. Once I get something to actually turn on an LED then I'll delete all the extra definitions and go from there. My test track only has three turnouts anyway so that'll be easy to manage while I'm still trying to get everything figured out.
Sorry I worded it wrong in my last post. The functions notifyDccSigState and notifyDccAccState (those functions print the contents of any turnout commands to the serial monitor) are in the NmraDccAccessoryDecoder_1.ino sketch, and the earlier library has code in to call those functions, but the later library does not. It would probably compile with either earlier or later libraries, but if using the later library you may not get any output on the screen!
I use Rudy accessory decoders with the same DCC interface as the one you use. https://rudysmodelrailway.wordpress.com/software/ The only (!) issues I had are when I drive heavy currents (~700mA) with ULN2803. Solve by large decoupling capacitors (>=1000µF) locally on 12V. And when tested on a single rail, and no locomotive : I had to put a small capacitor (330 pF, almost anything will do) on the rail - or a locomotive. This also seems to happen on small N layouts.
I'm still failing. I tested with the example from Geoff's site first using the proper address values... still nothing. I tried with both INT0 and INT1, neither worked. So now I've moved over to Rudy's code. Nice to see he actually has a variable for the interrupt number at the top, but still no joy. I set the four accessory addresses to pins 3, 4, 5, 6 (where my LEDs are connected). I defined a turnout with <T 1 1 0> and turned it on. I tried using the accessory commands <a 1 0 1> and <a 1 2 1> but nothing came on. At this point I STILL don't even know if the arduino is even receiving the DCC commands. Does nobody have any code that actually confirms if commands are coming in? From my understanding certain things like loco speeds are sent out continuously, so even if everything else is idle I should still be receiving some kind of signals in the arduino (if it is actually receiving them). So far not one sketch I've loaded has provided even the slightest bit of information to help troubleshoot or at least narrow down the possible problems. After a week of trying to get anything to work I'm getting really frustrated. How is it that people with no electronics experience are able to succeed when I'm failing so miserably?
It seems miguelcarmor had exactly the same symptoms as you. He couldn't get a sniffer or decoder to work. He had some faulty Opto isolator chips, and also found that he needed a 270pf cap across the rails: http://www.trainboard.com/highball/...r-problem-with-dcc.113686/page-2#post-1045153
In this packet, you have a DCC sniffer which allows you to watch the packets sent on the rails via the serial of arduino IDE. (based on the same popular interface) https://rudysmodelrailway.wordpress.com/software/
Thanks folks for the replies. Just an update on what all I have tried... First keep in mind I'm using a 6n136 but have some 6n137's on order. I've seen people successfully use both with the same circuits and believe they are interchangeable, but will know for certain when the new chips arrive. I had previously seen some discussion on the 270pf cap, and already have that in my circuit. Mine is connected across pins 2-3 in parallel with the diode. I have also tried a 0.1uf cap across pins 5-8, and I put a large electrolytic cap across the 5v supply. There seems to be a lot of variation on the resistors used. I started out with 10k on pins 6-7 and 1k on pin 2, however quickly found that the 1k resistor got almost too hot to touch. Some reading suggested a 2.2k or 1.5k resistor instead. I've tried both, the 1.5k seems to be fine so that is what I'm using now. On the 10k resistors, I also have seen using 5k on pin 7. I had a 5.6k so that is what I have on pin 7 now (still have 10k on pin 6). None of the changes except for the 1k have made any difference though, so perhaps someone can suggest what values work well for them? On that thread link that Jimbo pasted above, I noticed Michel was also a part of that discussion and there was a lot of talk about defective opto chips. Well that would certainly explain the complete lack of response I've been seeing here! I have a pack of 10 and I've swapped through about half of them with no change. There was a comment about a way to test the chips but maybe I'm not awake enough yet to follow it. Do you still need to hook up a 5v signal to pin 8 for the test to work? I think you're putting the battery across pins 2-3, so which pin gets the positive? And are you measuring resistance across pins 6-7, or some other pins? At this point I think it is certainly worthwhile to test what I have and see if any of the chips actually look good. Oh yes, and back to the software... Thanks very much for pointing out that DCC sniffer sketch. I changed the update time to 1s and added a 10s delay at the beginning of setup(). This gives me time to connect the arduino to the tracks and then start the serial monitor. I receive the initial startup messages but it does not seem to respond to any key presses. I'm trying to hit ? for help but nothing happens. I can't tell if the code has locked up or simply isn't seeing what I'm sending over serial. Obviously the serial port is working in both directions because I can flash new code to the arduino. I also found the attachInterrupt line and changed the 0 to a 1 since all the pinout diagrams say that on my device pin 2 is connected to int1 (pin 3 has int0). I tried punching in accessory and turnout commands on the DCC++ console, and moving the train around the track, but nothing shows on the sniffer output. The comments at the top say it is looking for the DC signal on pin 2 so I should be good there. I think that's all the new info I can provide for now. Thanks again for all the help.
A completely random thought here.... Are you certain that you do have a DCC signal on the rails? I know you have a loco running on it, but I'm thinking its possible that perhaps due to some other problem you are simply supplying pulsing DC and that the loco is running in analog mode? With the loco stopped, if you send a command to the BS but using a different address (EG <t 1 04 64 1>) hopefully it won't run. Then if you send <t 1 03 64 1> and the loco starts, I guess that would confirm that you do indeed have a valid DCC signal on the track....
Among the basic tests (sorry if this is too basic): check the return to arduino GND of the opto 5 pin. Check if with a DMM set on alternative voltage, you have, let say, 10-14V ~ on the rails and later to the opto before the resistor. Then check with a direct voltage setting, if on pin 6 of the opto (to 2 of arduino) you have 2.5V (if you have 5V, the signal does not get through the opto. If you have 0V, there is cabling problem) About the sniffer, to my experience, it does not respond to "?" when it has no DCC signal to analyze.
To be more clear, some photos : opto3. you can put a LED directly on an almost exhausted 2032 battery (still 3V). The current is limited by the inner resistance. The LED is still alive after test. opto1. The same way, if you put positive to pin 2 of the opto and negative to pin 3, you light the inner LED. opto2. If you test with your DMM as ohmmeter (range 20K or more, not 2K as on photo), red - supposed to be positive - on 6, and black=common on 5, you get something like 2K to 8K when you light the inner LED.
@Jimbo -- Regarding DCC signal on the rails... I double-checked with your commands and yes only when sending to cab 03 does the loco start moving. I also had previously confirmed it is an AC signal on the rails. My cheap meter only measured millivolts in DC, and a little under 2VAC, however I have a second loco on the rails fitted with an arduino. The supply voltage for the base station is 16.4V, and after the diode bridge on the arduino loco I measure a solid 15VDC, which is about the expected drop through the diodes and tells me I am getting full voltage in the rails. In addition, the headlight of the loco fitted with the DCC decoder is actually still connected to track power and stays on full regardless of the loco speed. I am also using the web page generated by DCCppESP32 to control the loco speed and direction (and it crawls VERY nicely at a speed of 1!). Finally, I was also able to set the speed curve CV on the decoder using the DCC++ commands to write to the main track, so the loco now accelerates and decelerates smoothly instead of just jumping to speed. So I am confident that I do have the expected DCC square wave on the rails and that commands are being sent and received. @michel -- No problem with getting basic, never hurts to re-check! On my small breadboard I am getting all power through the USB port on the arduino. I have two ground lines and one 5V line feeding the side rails from the arduino to the opto, and have measured +4.78VDC across pins 8-5 of the opto. For the voltage between pin6 of the opto and pin 2 of the arduino, I assume you meant for me to remove the wire that connects the two together. I am measuring between 0.9 to 1.0 VDC between those two. This is with the 5.6K resistor from pin 6 to ground. I put the 10K resistor back in and that dropped the voltage down to about 0.74VDC. Should I perhaps try a small resistor to bring the voltage up? Based on those readings I'm thinking I'll have to drop to at least a 3.3K or smaller to get the voltage up to around 2.5V. For the resistance test of the optos... I had to search a bit to find a suitable button battery but I did find an actual CRC2032 and tested it with a small LED which lit up at about half brightness. The battery measured 2.3V so it has lost a little juice. I went through all ten of the optos I have on hand... - Eight of them saw a resistance change, but the meter was unable to get a lock on a value and kept trying to re-read. - The last two (including the one that I had on the breadboard) are measuring around 20k and climbing. My assumption here is that the the battery is slowly discharging while connected, causing the rising resistance. So there is a possibility that two of the optos are working. I guess I'll try some smaller resistors from pin 6 and see if I can bring up the signal voltage a bit more, because I still don't get any results from the DCC sniffer.
According to my experience : pin6 of the opto and pin 2 of the arduino should be directly connected = no voltage between. pin6 of the opto should be pull up to 5V either by a 10K or arduino input pullup. Nothing else. pin 6 has an on or off state either 0V or 5V. You should mesure 2.5V because it goes between the two logical levels half the time at the pace of DCC. Any 3V battery would do the job, the 2032 are the common ones. The R measurerment is not stable as the voltage as you noticed ... Try to test them on/off (at 6) with a .5 mA current between 2 and 3 and the 10K at 6 and 7 to 5V The 2.5V at 6 (without arduino if you do not use input pullup) is mandatory for the interface to work, but you should not have to modify the basis circuit to get this.
