Arduino / DCS-RC WD Reset / Proof of Concept

But wait, there's more!

To eliminate "noisy" electro-mechanical relays, I was curious if there were multi-channel solid-state relay modules with IR control.  No doubt they exist but stumbled across an inexpensive IR receiver with 8 discrete outputs.  This module could then drive an 8-channel solid-state relay module.  That is, in the case of the DCS-RC, IR is the only "backdoor" to command it to transmit valid DCS activity (e.g., Bell command to engine 0) as a proxy for the WD signal at engine power-up.

Stan, it's a DC-DC solid state relay, lots of those around.  Look for an DC controlled AC solid state relay, a considerably rarer bird for low voltage AC control.

Oops.  Yeah, that would be a problem. 

Perhaps that's why the AC solid-state relay discussed earlier was $88!

You're right, there are gobs of DC-input, AC-output solid-state relays but start at 24V AC minimum voltage.  Kind of reminds me of the occasional question on whether you can use a traditional 120VAC triac lamp dimmer to control 18VAC O-gauge for conventional operation.

Well, one thing is for sure.  If low-voltage solid-state AC output relays are rare birds, it would be an even rarer bird that is IR controllable!  Hence the IR receiver module might still be part of the solution.

FWIW, I have some solid state DC controlled AC relays, and they have similar specifications.  However, they only drop about a volt of AC at 18 volts, so they are possible to use.  I haven't used them, I'll have to see if I can find them.

Ok, here's what I believe I can say with at least a modicum of confidence. Using the DCS-RC Remote consistent results with the locomotive staying dark & silent as long as the DCS-RC reset is triggered within 1-2.5 seconds. Consistent results using the Arduino and IR LED were consistently inconsistent . It might trigger a reset 5 times in row then miss, 3 times in a row and miss, 8 times in a row.  At first I thought it might be that the Arduino could not provide sufficient current to the IR LED so I ran two tests. I replaced the IR LED with a standard LED and could see the trigger pulse at a very reasonable brightness. Re-coded the sketch, replaced the IR LED and turned my TV off from approximately 10'. Stan, I re-read your post with the waveform and you had stated the pulse from the DCS-RC Remote was approximately 40kHz. From what I've read regarding the IR Library used to encode the pulse it sets the modulation frequency at 38kHz for the NEC protocol. Wondering if the Arduino may be modulating the pulse a little on either side of 38kHz. I have no idea how tight the tolerances are.
bd

Right.  I say ~40 kHz because there are a multitude of options when selecting an IR "frequency."

I looked at the actual IR receiver component in my DCS-RC base and it was stamped with the number 4838.  I then re-scoped the "bell" button and turned on the parameter measurements for the burst:

So the DCS-RC remote is modulating the IR LED at about 38 kHz which matches the receiver component in the base.

But the fact of the matter, based on the technology used in these IR receiver chip, is they are not THAT frequency selective...in the way that an RF crystal receiver is fairly exacting on the carrier frequency.

In the top diagram, note how even if you're several kHz off (i.e., 5% or even 10%) you still get a response.  Yes, maybe it's only half as sensitive so you can't trigger from 20 feet away...but maybe only 10 feet away.  But it's not like you get nothing.

If I understand your experiments, if you "manually" press the Bell button on the DCS-RC remote within ~2 seconds of turning on the engine...you get 100% success keeping the engine silent and in command-mode.

But using the Arduino you get something less than certainty.  When it doesn't work are you getting the momentary blink "off" of the green LED in the DCS-RC base?  If you don't get this blink then the DCS-RC base is not recognizing the Arduino's IR burst.

This may be a bit in the weeds, and I haven't studied it, but do you know HOW the Arduino library generates the 38 kHz NEC modulation?  Specifically, does it "bit-bang" the output port with loops of instruction cycles at the 38 kHz rate?  Or does it use a PWM output set to ~38 kHz and bit-bang that port at the slower baud rate (vs. the 38 kHz carrier rate)?  Or does it use the SPI port with a FIFO queue to stream out the pre-determined bit pattern at the 38 kHz carrier rate?

Stan, what I can speak to is the DCS-RC 'green' LED does not blink and the engine normally comes up is conventional mode.  I say normally because it does not seem to be an absolutely every time 'thing', but more often than not.  I understand this sounds confusing, but it seems that occasionally the capacitors in the locomotive hold the command mode longer than other times.  That behavior has been driving me crazy.  Every time I believe I have found a sequence with an expected result it seems to note that and change the rules.

Regarding the Arduino, my understanding is that a PWM port and Timer Interrupt are used to pulse the IR LED, beyond that I have no clue.

bd

@barnun posted:

... Every time I believe I have found a sequence with an expected result it seems to note that and change the rules. .

Like Lucy holding the football for Charlie Brown.  LOL.

Well, it seems to me that if you're not getting the green LED on the DCS-RC to blink "off" then the DCS-RC is not recognizing the Arduino IR burst.  In a certain sense it doesn't matter what the DCS engine is doing or not doing.  Stated differently, in a walk-before-you-run metaphor, you must first get the green LED to blink "off" with 100% reliability in response to an Arduino burst. Does reliability change/improve if you move the Arduino IR LED emitter closer to the DCS-RC?

I'm assuming you get 100% reliability (green LED ALWAYS blinks "off") in response to a button press on the DCS-RC handheld remote.

@stan2004 posted:

Like Lucy holding the football for Charlie Brown.  LOL.

Does reliability change/improve if you move the Arduino IR LED emitter closer to the DCS-RC?

I'm assuming you get 100% reliability (green LED ALWAYS blinks "off") in response to a button press on the DCS-RC handheld remote.

LOL, exactly like Lucy with the football.

No change in reliability with changes in distance or angle of attack.  I even removed the DCS-RC cover to expose the IR Receiver, same results.  Using the hand held remote I've not seen it miss a 'blink' or if it did I may have assumed I didn't 'mash' the bell button hard enough.  Just out of curiosity I might try testing with a separate IR receiver next to the DCS-RC and see if I ever do not get a 'blink' and the separate receiver picked up a pulse.  Kind'a like "I was working in the lab late one night ..." and do the 'mash'.

bd

I think this may be another case of simply declaring victory.  That is, the matter at hand is using an Arduino to control the DCS Watchdog for yard siding power control.  So if using the 8-channel IR relay module, one could simply co-opt one of the relays to interrupt power to a DCS-RC...and then have 7 other relays to control 7 sidings.  Ta da!

It appears it will be a challenge to find a reasonably-priced low-voltage solid-state AC relay so one more electro-mechanical relay should not add too much to the cacophony!

Like the WIU mystery I'm sure in the end we (well, "you" to be precise) could experiment further and track down what/why you can't trigger a Watchdog by power interruption when a WIU is attached to a TIU.  Like you said, you can control your TV using the Arduino IR library.  Obviously there are no published specs on the DCS-RC IR link and MTH was certainly under no obligation to implement the NEC protocol to a T ...  as long as they pair-well together.  When I was messing with Universal Remotes years ago for various IR projects, I could activate the DCS-RC with some manufacturer/device setting; I'm sure I did not do any reliability testing!

"This is not the end.  It is not even the beginning of the end.  But it is perhaps, the end of the beginning."... Winston Churchill

I've chosen to do a little additional testing ... you had asked previously about the Remote and DCS-RC and reliability.  Tested 100 times with 100% response (except for the 1 or 2 times I fat fingered the button).  I placed an IR detector adjacent to the DCS-RC unit and both units responded in sync as long as I properly pressed the button.  I think the 1 or 2 times neither unit noted a pulse receipt I either did not seat the button fully or pressed on one side instead of the middle.

I've also modified the test arrangement by seating the Arduino components on PCB's as opposed to a 'breadboard' arrangement, which will result in much greater faith in the test results.  I completed a test with the IR transmitter 16" away from the Arduino IR receiver and let it run for 100 cycles, the two tracked perfectly.  So, the next test will be the same but with the DCS-RC behind the Arduino IR receiver making sure the DCS-RC IR Receiver is in the line of sight to the Arduino IR transmitter.  I'll post those results.

Depending on the results of the above test, if successful or very close to successful, I'll re-add the relay to power the test siding track back into the mix and see how that goes.  I totally agree with your earlier assessment that the DCS-RC / Arduino transmitter IR link being dependable is the critical piece of the puzzle.

On a side note, I did see some low voltage DC control, AC power relays much cheaper.  But were still a little pricey at $10 a pop.

bd

I scoped the IR receiver chip inside the DCS-RC base (orange trace) and the DCS-RC track voltage current (red trace) albeit with DC voltage passively applied.  The DC voltage makes it easier to capture the high-frequency DCS signaling activity.

This shows 3 relatively rapid presses of the remote Bell button...about 1/2 second apart...so about 3 Bell commands in 1 second.  In each case the DCS-RC base responded "instantly" spewing high-frequency DCS signal packets onto the track voltage.  A 100x magnification (in time) is shown in light blue showing the DCS activity presumably telling an engine at DCS-address 0 to turn on/off its Bell.

The takeaway is this means one can stimulate DCS activity MORE OFTEN than once per second as is the case with the WD.  That is, it appears the DCS-RC on initial power up...or when electronically reset by the PBW PCB add-on...takes about 3/4 second to generate the WD.  This effectively means you can only generate WDs maybe once per second.

So what's the point?  Well, let's say you can only get 90% reliability of the DCS-RC base to successfully decode an Arduino-generated IR command.  We don't know why, and may never know why, it's not better but just suppose this is what it is.  That means you "fail" 1 in 10 times.  Well, why not send multiple Arduino Bell commands with the 90% reliability.  In 2 seconds, you can send at least 5 Bell commands via IR.  If the DCS-RC fails 10% of the time, then the chances it fails on all 5 times is exceedingly small, say, (1/10)^5 or 1 in 100,000 times that the yard siding is turned on.  I claim that's "reliable" enough for O-gauge!

Looks like for now the DCS-RC and I are agreeing to a cease fire.  Tried a number of tests with no luck, the DCS-RC response is still very intermittent.  Tried to pulse it 1, 2 & 3 times per cycle with various delays between the pulses (10,20,30,40,50 milliseconds) with no changes in the frequency of the responses.

The only other trick I can think of to try is to change the parameters in the Arduino regarding it's implementation of the NEC protocol.  IR Raw Data parameters are not something I've dealt with before so I'll have to do some research and try to educate myself in that area.

Many, many thanks to all for the suggestions and observations.

Reporting live from the Arduino / DCS-RC DMZ.

bd

Stan, just now read your post before my previous post above.  Agree with the logic but the test results do not seem to support the theory.  Of course, it could be my testing or implementation that is flawed.  Most of the test parameters are noted in the previous post except for the delay between cycles which was set at 10 seconds.  My feeling was that I should have seen at least minimal improvement in response, but just didn't happen.

Talk about a head scratcher??

bd

Stan, just noticed something in your scope trace.  If I'm counting correctly the enlargement of the IR receiver pulse shows 16 bits.  I have the Arduino set for (NEC, 32) standard protocol ... kinda' makes you want to go  hmmmm....  Tomorrow I'll modify the Arduino sketch for 16 and see if it compiles, if it does I'll break everything out ALL OVER again.   'Another fine mess you've gotten us into, Stanley'

bd

Just realized that trace was for the DCS side of the equation ... as Emily Litella would say 'nev'er mind'.

bd

Ok, well a giant step forward ....

I'm able 'blink' the DCS-RC with 100% dependability (and no I'm not turning the power on & off ).  During the research I stumbled on a Record & Playback sketch by the author of the IRremote library.  Works like a champ, so now I need to determine what the differences are between what the stored sketch parameters are and the Arduino execution of the standard 'NEC protocol'.  Thinking most likely it will be regarding the bit setting (32 vs. 'x').  Unless of course its 1.21 gigawatts and a flux capacitor.

Back to the research (Ha, you thought I was going to say future).

bd

'Your honor, I must in all good faith recant my previous testimony'.  The Record and Playback sketch, when retested, had roughly the same failure rate as the Send IR sketch.  However, just as I had reached my peak frustration level, I picked up the transmitter module in preparation crushing it in my fist and with it pointing at the ceiling I noticed the DCS-RC was responding exactly as expected.  Two pulses, two blinks.  Research had said the current limiting resistor should be 150 ohms, during testing I had been reducing that value thinking it may not be bright enough.  Man, was I wrong.  I installed a 330 ohm resister and its been happily chugging along, 2 pulses - 2 blinks.  I believe it had been over driving the Receiver Module in the DCS-RC.  I may still tweak it a bit to see what is optimum.  So I declare this VD Day (no, not that kind!) Victory over DCS-RC Day.

bd

So to be clear, by simply changing the resistor, do you still need to use the Record-Playback function/library or can you go back to using a generic NEC protocol library function?

That is, I'd think a "genuine" record-playout sketch would be quite memory and MIPS intensive if it is sampling fast enough to recording any and all IR activity.

Stan, ditched the Record-Playback sketch for the standard IR Send sketch.  I did try improving the responses by changes the resistor values, but the 330 ohm seems best.  Also, kind'a odd but the responses from the DCS-RC maxed out with the transmitter about 1.5 inches from DCS-RC and turned about 20 degrees clockwise from TDC.  Modified the IR Send sketch to send 4 pulses 600 milliseconds apart every 10 seconds using the standard NEC 32 bit protocol and the results with 100 test cycles were : 

Responses    Count
      4                55
      3                35
      2                10
      1                00
      0                00

bd

OK.  So you sent 400 pulses and got 345 responses.  So the failure rate is 55/400 = 14%.  So by sending 4 pulses, the probability that none of them will get recognized is less than 1 in 1000.  I think that's "reliable" enough for hobby work.