JohnGaltLine posted:So I have a bit of a question here...
We know that MTH chose not to have the TIU (or DCSRC) repeat the watchdog constantly, which would have eliminated the need for this fix in the first place. Do you guys think it might be that the extra 'traffic' of this signal would reduce the effective bandwidth on the signal for other commands, and if so, will supplying a cycling watchdog, as this project is doing, cause any problems with the over-all signal on the layout? I'm picturing it being a case where it wouldn't be a big deal normally to have two commands sent out from different sources , but with data constantly being sent from one point, will it affect the reliability of signals from a second source?
I guess this comes back to the idea that there must have been some reason that the designers chose not to have the TIU provide a watchdog at a regular interval, and the only ones I can come up with are that: 1, the electronics used couldn't keep up with that on top of all the other functions, 2, the watchdog would interfere with the system in some way (using too much bandwidth), or 3, a lack of foresight that users might want to power up an engine after the layout has been powered. If it is the last, though, I would think it would have been changed in a firmware update by now.
Anyway, I guess this will mostly go to Stan for now, with the DCSRC cycling, do you experience any problems with other DCS functions?
JGL
Your comments/questions are quite astute and on-point. There was a somewhat "animated" thread which for all I know got deleted where another member and I were at odds about whether a DCSRC and a TIU "talking" at the same time on a command track would/could interfere with each other. Aside from that free-for-all, I don't recall seeing much discussion about this.
My approach targets GRJ's specific scenario aptly described by this thread's title. That is we are talking about a yard. Or (as I have extrapolated) a roundtable. In other words a limited environment where the TIU channel is talking to one DCS engine doing "simple" things or what I'll call low-bandwidth DCS communications. So no loading of a new soundset, chain file, or whatever. My belief is in a low-bandwidth DCS environment you will not see any material effect from a perpetual watchdog.
A question was posed early on about the relative signal power of the TIU watchdog and the DCSRC watchdog. I did not measure this as it seems the TIU signal power/timing has changed over time so did not want to confuse matters. I will suggest, anecdotally anyway, that the DCSRC signal is not as strong as the TIU. Hence this is why I propose this alternative as useful for a limited environment like a yard or roundtable.
I choose not to ponder what it would take or why (or why not) MTH doesn't change the TIU into a perpetual barking watchdog...or at least make it feature that can be turned on/off on a per-channel basis. I again find it curious that the watchdog length has increased over time and is now up to 45 seconds which seems like strange value! But this does indirectly shows that watchdog activity can co-mingle with normal DCS command activity.
Not sure I provided definitive or hard-data to answer your questions...other than to clarify that I am proposing an idea to address a somewhat narrow/limited DCS scenario rather than DCS overall.
