Interesting info, but I still subscribe to the old mantra...

Don't fix stuff that ain't broke.

Unless the existing simple board causes me issues, I'll be using those for the foreseeable future.

All lined up and pumping out a WD faithfully without any user intervention.

I too adhere to that mantra in many aspects of my life ... plumbing in particular.

But, IMHO that perhaps the three most powerful words every uttered, written, published or broadcast have been "Hey ... what if ...".

bd

Hey... what if you just connected it like I show, and you lived happily ever after.

LOL.  TOUCHÉ.  bd

Barry, it was a joke, I'll delete it since it offends you.

John,

For me to know that I was in fact mis-reading your intent is very much a relief!  Deleting my reply.

For any inquiring minds that may want to know ....
Generates 3 (100 millisecond) reset pulses separated by 1 second goes quite until the next test cycle (10 seconds).
I revised the test code to remove the 'delays' (which can be a bad thing) and incorporated Timers. Revised code below, brief video attached

#include "Arduino.h"
#include <BlockNot.h> // Library used for Timer Functions

BlockNot WDT_Timer_1(1, SECONDS); // Length of time between resets
BlockNot WDT_Timer_2(100, MILLISECONDS); // Length of time reset pulse is generated
BlockNot WDT_Timer_3(10, SECONDS); // Length of time between completion and restart of test cycles

int WDT = 0; // Variable to store trigger count

void setup() {
pinMode(9, OUTPUT); // Output pin to trigger reset
digitalWrite(9, HIGH); // Sets trigger pin High to prevent immediate reset
WDT_Timer_3.RESET; // Test cycle timer reset
}

void loop() {
if (WDT_Timer_3.TRIGGERED){ // If 10 seconds have passed, start test cycle
WDT = 6; // Set to 6 for 3 reset cycles
}
if (WDT >= 1){   // If WDT is greater than 0, directs code flow to watchdog subroutine
Watchdog();
}
}
void Watchdog(){
if (WDT == 6 || WDT == 4 || WDT == 2){  // Or Statements
  if (WDT_Timer_1.TRIGGERED){  // if 1 Second has elasped
    digitalWrite(9, LOW);  // Initiates reset pulse
    WDT_Timer_1.RESET;  // Resets interval between resets timer
    WDT_Timer_2.RESET;  // Resets pulse length timer
    WDT = WDT - 1;  // Decrements cycle count by 1
    }
  }
if (WDT == 5 || WDT == 3 || WDT == 1){  // Or Statements
  if (WDT_Timer_2.TRIGGERED){  // if 100 Milliseconds have elasped
    digitalWrite(9, HIGH);  // Turns reset pulse off
    WDT_Timer_1.RESET;  // Resets interval between resets timer
    WDT_Timer_2.RESET;  // Resets pulse length timer
    WDT_Timer_3.RESET;  // Resets cycle timer
    WDT = WDT - 1;  // Decrements cycle count by 1
   }
  }
}

So from what I can tell, the actual hookup using the direct Arduino method (no PBW board required) is something like:

The optical isolation is accomplished with a optocoupler chip plus a resistor for less than, say, $1.  There are built modules with this function albeit for more out-of-pocket.  This does require opening the DCS-RC and attaching 2 wires to the internal circuit board.

It occurs to me that the same, or very similar, Arduino code could drive a 5V relay module that would momentarily interrupt power to the DCS-RC which would then trigger its Watchdog upon restoration of power.

This would not require opening the DCS-RC.

And in a don't try this at home (until someone confirms this works), there have been various references to interrupting power to a passively-powered TIU channel to trigger the TIU Watchdog.  Again, the same or very similar Arduino code could momentarily interrupt power to the TIU via an inexpensive relay module.  This would eliminate the need for the DCS-RC which is apparently getting difficult to find and/or quite spendy.

@stan2004 posted:

And in a don't try this at home (until someone confirms this works), there have been various references to interrupting power to a passively-powered TIU channel to trigger the TIU Watchdog.  Again, the same or very similar Arduino code could momentarily interrupt power to the TIU via an inexpensive relay module.  This would eliminate the need for the DCS-RC which is apparently getting difficult to find and/or quite spendy.

You are correct, if you interrupt the power to any channel, that channel will emit the watchdog upon power-up when it receives power again.  That works for passive or active mode, obviously for active mode it's power to the input side and passive is power to the output side with no connection to the input side.

@stan2004 posted:

It occurs to me that the same, or very similar, Arduino code could drive a 5V relay module that would momentarily interrupt power to the DCS-RC which would then trigger its Watchdog upon restoration of power.

And in a don't try this at home (until someone confirms this works), there have been various references to interrupting power to a passively-powered TIU channel to trigger the TIU Watchdog.  Again, the same or very similar Arduino code could momentarily interrupt power to the TIU via an inexpensive relay module.

Your conclusions regarding the coding are spot on, minimal changes required.  Also correct regarding the use of relays.  I've tried to shy away from the relays for this particular application for three reasons 1.  Being electromechanical it will eventually fail (as is true of any component).  2. A noise factor (small but obnoxious) of a relay or relays chattering through the cycles. 3. I'm unsure of the recovery time for the TIU channel or channels.

@gunrunnerjohn posted:

if you interrupt the power to any channel, 'that' channel will emit the watchdog upon power-up

GRJ graciously proved this in an earlier post.  Would'da been way too easy to toggle a spare channel and the watchdog transmit on all channels.  Oh, well.  I'm not set in concrete against the use of relays as there are quite a number of them throughout the layout, was just trying to avoid that if possible.  Still wondering if there could be a way to couple a spare channel watchdog to an active TIU channel?  Transformer / capacitance arrangement?  Optoisolator driving a chip on the hot TIU channel arrangement?  Just kinda' throwing stuff at the wall and nothing is sticking. 

Barry

You could always trigger the channel power with a solid state relay.  There's any number of ways to switch power solid state.

I strongly recommend not connecting two TIU outputs together.

@gunrunnerjohn posted:

You could always trigger the channel power with a solid state relay.  There's any number of ways to switch power solid state.

I strongly recommend not connecting two TIU outputs together.

GRJ, duly noted regarding TIU channel coupling.  However, the solid state relay idea is brilliant.   Thought I might have found one that spec wise seemed perfect ... and they only wanted $88 for it.  WHAT!!!  Obviously designed for DOD use.  I'll try to do some more research tomorrow.

Barry

@barnun posted:

...Still wondering if there could be a way to couple a spare channel watchdog to an active TIU channel?  Transformer / capacitance arrangement?  Optoisolator driving a chip on the hot TIU channel arrangement?

@gunrunnerjohn posted:

You could always trigger the channel power with a solid state relay.  There's any number of ways to switch power solid state.

I strongly recommend not connecting two TIU outputs together.

GRJ, please elaborate on NOT hooking 2 TIU outputs together in the specific configuration under discussion.

That is, there is a SPARE TIU channel.  The spare TIU channel AND the active TIU channel are powered passively by the same track power source.  Because the SPARE TIU channel is only being used to generate a watchdog on demand, it is only passively powered for maybe 1 second at a time...and only when the Arduino "knows" that it is turning on power to a yard siding, roundhouse whisker, or what have you.  99.99% of the time the SPARE channel is OFF, unpowered, and its red-terminal "hot" is electrically disconnected to the red-terminal "hot" of the always-on main TIU channel.

Stan, it's possible that it will function, but keep in mind that ANY activity for the TIU is broadcast out all ports.  Given that fact, it'll be generating a DCS signal for any command or activity on any channel.  Since we know that the TIU DCS drivers, on the Rev. L at least, are fragile, having two channels driving at the same time seems like a really bad idea.  Also, the channels are independently driven, so the data won't be perfectly synchronized, and the drivers would be fighting each other.

What that will do I can't say, but I can tell you personally that I don't recommend connecting TIU outputs together.

With that being said, it's likely not to be a huge problem as when you're running over different power districts, those outputs get temporarily connected as the train connects the two through the rollers.

@barnun posted:

...

3. I'm unsure of the recovery time for the TIU channel or channels.

GRJ graciously proved this in an earlier post.  Would'da been way too easy to toggle a spare channel and the watchdog transmit on all channels.

@gunrunnerjohn posted:

... ANY activity for the TIU is broadcast out all ports.  Given that fact, it'll be generating a DCS signal for any command or activity on any channel.  Since we know that the TIU DCS drivers, on the Rev. L at least, are fragile, having two channels driving at the same time seems like a really bad idea.  Also, the channels are independently driven, so the data won't be perfectly synchronized, and the drivers would be fighting each other....

There seems to be a disconnect here.  if ANY activity for the TIU is broadcast out all port then it seems the easy solution is to indeed to simply toggle a spare channel and the watchdog transmit on all channels.

@stan2004 posted:

ANY DCS activity during the first few seconds will tell a newly powered DCS engine to start up silent and in Command mode.

Stan, back in the 'Proposed Solution' post you had stated the above.  Since I'm kinda' late to the game for DCS (most everything is Legacy except for one DCS loco, hoping soon to be two), wondering if we could issue an engine specific DCS command initiated from the MC thru an RS232 adapter to a Ser2 module across the PDI buss to the MTH TIU also connected to a Ser2.  Thinking of something like 'Turn Cab Light Off'.   My thought was this command could be repeated for however many DCS engines are possible on the layout regardless of which siding/loco is powering up.  This might only work for a small number of engines due to the timing and is certainly of no help for those administrating club layouts or heavily DCS loaded layouts.  The advantages would be no spare TIU channel, no DCS-RC or PBW required.  Again, just throwing stuff at the wall.

Barry

@stan2004 posted:

There seems to be a disconnect here.  if ANY activity for the TIU is broadcast out all port then it seems the easy solution is to indeed to simply toggle a spare channel and the watchdog transmit on all channels.

The WD is a unique case.  However, if you address an engine and send any command, it comes out on all the TIU channels.  The WD only happens when a power cycle on the specific channel takes place.

@barnun posted:

wondering if we could issue an engine specific DCS command initiated from the MC thru an RS232 adapter to a Ser2 module across the PDI buss to the MTH TIU also connected to a Ser2.  Thinking of something like 'Turn Cab Light Off'.

Did some research / reading of Professor Chaos & Carl552 posts and linked over to Mark DeVecchio's web page.  The above scenario will not work directly but could perhaps be accomplished with additional hardware.  Still researching.

Barry

@gunrunnerjohn posted:

The WD is a unique case.  However, if you address an engine and send any command, it comes out on all the TIU channels.  The WD only happens when a power cycle on the specific channel takes place.

So by unique case are you saying the WD is only transmitted on the specific channel where a power cycle takes place?

If so, then the "spare channel" method would never have two channels transmitting a TIU signal at the same time.  The "spare channel" is only turned on for a second or so whenever a new yard siding is powered.  And during the brief interval (one second) when both TIU channels are tied together, only the "spare channel" would be transmitting.

@barnun posted:

Did some research / reading of Professor Chaos & Carl552 posts and linked over to Mark DeVecchio's web page.  The above scenario will not work directly but could perhaps be accomplished with additional hardware.  Still researching.

I understand it would be nice to remove the "spare channel" requirement.  Though if pondering developing Arduino software to back-door command the TIU to issue a benign (e.g., turn cab light off) DCS command, I'd suggest first trying the other proposed relay method.  That is, this does NOT require a spare TIU channel and the Arduino code is already "done" as you described earlier.

As drawn, by way of example, suppose Fixed1 is the TIU channel that eventually makes its way to your yard sidings.  Fixed1 is normally powered.  When you want to power up a yard siding you would presumably know that Fixed1 is idle.  Then interrupt power to just the Fixed1 output.  Note that any other already powered engines on the Fixed1 track do not see the power interruption.

Some type of high school science project is needed to determine how long an interruption is needed to trigger the Watchdog of Fixed1 and what are the side-effects and/or unintended consequences.

@stan2004 posted:

Some type of high school science project is needed to determine how long an interruption is needed to trigger the Watchdog of Fixed1 and what are the side-effects and/or unintended consequences.

Stan, agreed.  I will try and rig something up to test the passive power interrupt method.

bd

@stan2004 posted:

So by unique case are you saying the WD is only transmitted on the specific channel where a power cycle takes place.

Correct, the WD only comes out on the channel that just received power.

@stan2004 posted:

If so, then the "spare channel" method would never have two channels transmitting a TIU signal at the same time.  The "spare channel" is only turned on for a second or so whenever a new yard siding is powered.  And during the brief interval (one second) when both TIU channels are tied together, only the "spare channel" would be transmitting.

Well, sounds good.  As long as the "spare channel" doesn't remain connected to the live channel, I suspect it wouldn't be an issue.

@barnun posted:

Stan, agreed.  I will try and rig something up to test the passive power interrupt method.

bd

Well, I won't bore everyone with the details but the one result that seemed repeatable is when tested with a stand alone TIU, passively powered, the interrupt method worked.  However, when I added a WIU to the equation it did not work.  By itself you can see the TIU power LED blink and a second LED about 2/3 of the way to the right blink.  Thinking that may have something to do with the watchdog circuit, but not positive.  With the WIU attached, it supplies power to the TIU and during the reset the LEDs do not blink and the engine comes up conventional.  So it seems to me this option has a pretty limited audience (no WIU and no Aux power).  I couldn't test the Aux power but my best guess are the results would be the same.  I also do not have a Remote, so I couldn't test that as well.  Hope that helps.

bd

Aux power doesn't change how the WD is generated, the individual channel WD is generated anytime channel receives voltage.  Interestingly enough, the WD is also generated on the variable channels for any voltage change, not sure why they thought that was necessary.  Although I do have a WIU connected, the DCS-RC WD generators haven't affected the operation at all.  FWIW, I use AUX power to the TIU.

It's curious that the WIU "disables" the power interruption method.  I would have thought the WIU in effect "simply" replaces the MTH remote and how the user sends commands...and that any low-level, almost hardware-like, functions like WD reset on powering a channel would not be affected.  Oh well.  In any case, I think you should declare victory on the idea of an Arduino controlling the DCS-RC WD Reset - that was the topic of the thread after all!  

---

But OGR being a discussion forum...where ideas can be thrown at a wall to see which stick... I was thinking about your earlier idea of back-dooring commands into the TIU via the TIU serial port.  That is, sending some benign (e.g., cab light on/off) DCS command as a proxy for the WD when powering up a new yard siding.

In this recent OGR thread, @Rod Stewart shared an inexpensive IR wireless relay module for about $1/relay.  The 10 Amp relays would be suitable for switching power to yard sidings for example.

As mentioned earlier "any" DCS activity on the track during the first few seconds of a PS2/3 engine turning on will keep the engine silent and in DCS command mode.  That is, you don't have to send the specific WD command.

For about $1, you can get an IR transmitter module that can be driven by a single output pin of an Arduino.  There are gobs of Arduino code floating around to transmit IR codes for a DIY Universal Remote to control televisions or other IR controllable appliances and gadgets.  So as shown above, the Arduino could talk to the relay module over the IR link to turn on a particular siding via relay.  Then the Arduino could talk to the DCS-RC over the IR link to send a DCS command as if it were the DCS-RC handheld remote.  In fact, "any" DCS-RC command would be "benign" because the DCS-RC always tries to talk to a DCS engine at address "0" (IIRC) which would not be a valid address for an engine in a TIU layout.  Hence the DCS-RC command would be ignored by any engine in a TIU layout other than to serve as an indication of DCS activity and hence a WD proxy.

The eyes can start rolling....wait for it....  now!

@stan2004 posted:

The eyes can start rolling....wait for it....  now!

My eyes rolled right out of my head, I'm still feeling around for them on the floor!

Did you figure out how to generate a valid command that the DCS-RC would recognize?

@gunrunnerjohn posted:

...

Did you figure out how to generate a valid command that the DCS-RC would recognize?

Do you mean the format or protocol of the IR packets sent from the DCS-RC remote to the DCS-RC base?

Yep, did you decode those?  I suspect they're fairly simple, but I've never seen them documented.

Yes.  It was years ago and memory fuzzy but I'm pretty sure I used a "Universal Remote" and could control the DCS-RC by setting the Universal Remote to emulate a Brand "X" TV or VCR or whatever.  In other words you press the Universal Remote "1" button and this would fire the DCS-RC front-coupler, press the "2" button and this would mute the engine, and so on. This was back when guys on OGR were literally giving away the DCS-RC for the price of postage as the DCS-RC was included in MTH Starter Sets and guys would get a good deal on Starter Sets only wanting the engine.  In other words I figured who cares and just patted myself on the back!

Now it appears the DCS-RC is out-of-production (?) and they go for $100 and up used on eBay.  I was just looking and even the DCS-RC remote alone can fetch $50 on eBay.  Imagine that!

To your point, I can't imagine why MTH would "officially" document this.  And, yes, it has to be fairly simple since if you look at the IR receiver chip (under the round red lens) in the DCS-RC base, it is a generic 3-pin IR receiver chip and these have finite baud-rate and protocol limitations. 

Gad, I have a box of the DCS-RC remote units, they go with the four DCS-RC receivers on my layout power panel!   I guess I should list them on eBay.

In keeping on-topic with the Arduino theme, as I think about it, the DCS-RC base under Arduino control (via the IR link) might be the least expensive layout-control "system" in O-gauge.  There are countless layouts where ONLY 1 engine runs at a time.  So if you have an Arduino and the itch to write code to automate a 1 engine layout, the DCS-RC might be the way to go!  Interesting....

What would be super would be if you could add stuff like smoke control, etc.  That's not available on the DCS-RC...

Stan,  just to make sure I understand your proposal I've re-drawn your diagram, a kind'a sanity check.  Does this look correct?  I have the DCS-RC Remote and I believe I should be able to capture a command that the Arduino could output.  Assuming the diagram is correct and we can get the DCS-RC to respond then we could next work on the relay code.  The Arduino could fire the relay and about 50 milliseconds later trigger the DCS-RC.  That should give the relay time to operate.  Thoughts?

bd

Pardon my confusion, but exactly what is accomplished using all these parts?  It seems you're making a simple project very complicated, or am I missing something?

GRJ, if that's question for me ... the answer is I'm not using them or will necessarily ever use them.  Was simply trying to test for Stan or any others on the forum who may be interested.  So far, I'm perfectly happy with my DCS-RC and PBW.

bd

OK, it looks like a lot of parts to do a simple task, I just wanted to make sure I wasn't missing some important point of all the extra complexity! 

Your diagram is spot on.

This is simply in the spirit of OGR being a discussion forum.  As I see it, the topic at hand is how an Arduino can interact with the DCS-RC to do interesting things.  There may indeed be better/cheaper/faster ways to do the same thing.  But one can review the "mother" of all DCS-RC WD threads (5+ years ago with 314 posts and counting) and observe that it really took quite some time to beat the yard-siding watchdog problem into submission...resulting in the PBW module which itself has undergone upgrade/modification over the years.

And yet here we have a thread not yet a month old that is an alternative solution albeit for a slice of the OGR population (the Arduino crowd).

I hooked up an IR detector and captured, by way of example, a "Bell" button on the DCS-RC remote.  The IR packet is about 70 milliseconds long.  There is a long "start" bit burst and then what appear to be data bits of equal burst width with bit separations defining the data pattern.  Back when I had a better functioning brain I could probably even tell you what this kind of data modulation is called.  Anyway each burst is modulated at ~40 kHz.  I recognize this as very common/standard protocol and am confident this can be routinely implemented with an Arduino.

Stan, using the standard Arduino example IR-Recv Demo 2 it identified 'Bell' as Hex 1CE340BF using the NEC chipset.  bd

Nice.  Yep, that indeed looks like about 32 bits of data.  And given the state-of-the-art back in the last century it makes sense the error-checking "algorithm" was simple byte-wide 1's complement ...1C -> E3, 40 -> BF...allowing implementation with logic gates rather than a microprocessor.

Since the green LED in the DCS-RC base blinks off when it receives an IR command from the remote, it would be fairly simple to confirm the Arduino is properly emulating the DCS-RC remote.

So to your diagram, for the application at hand it stands to reason that a multi-relay would be a good choice to power yard sidings, roundhouse whiskers, or whatever.  An inexpensive IR transmitter module would then require only 1 Arduino output pin to control a large number of relays (via the IR controllable relay module) and the DCS-RC to issue a benign (e.g., Bell) DCS command packet to keep any newly powered PS2/3 engine silent and in command mode.  Sure, an Arduino has dozens of input/output pins but seems just the time-savings alone of not having to wire up a harness or cable-bundle to go from the Arduino to possibly distant relays has value.