DCC Fast Clock
A Fast Clock is, as the name suggests, a clock that runs faster than normal. Since trains often run to timetable schedules, clocks are very important on real railroads. And for modelers who want to simulate the operational aspects of railroading, a clock is likewise important. But model railroads tend to be fairly compact: in Japanese N scale, a kilometer is 6.7 meters (21’ 10.5”), meaning that yards and destinations tend to be much closer than in reality. So a clock running four times as fast (a “4:1” fast clock) makes a train traveling at a scale speed appear to have four times as much distance between stops. Most fast clocks run somewhere between 4:1 and 8:1, but are often configurable to run at different rates.
Although I’m not yet ready to run multiple trains in and out of staging, which limits my operational possibilities, I do plan to do that eventually, and at least some of the time to run passenger trains to a timetable. So I started looking into my options. It turns out I have quite a few: Digitrax’s handheld throttles with LCD panels have a fast clock (displayed via the “CLOC” key) that, in theory, synchronizes with a master clock on some of their command stations. The JMRI software I’m using (via a LocoNet-USB interface) has its own fast clock, which can be synchronized to the command station. And there are other fast clocks available that can be connected to LocoNet to act as master clocks or displays.
You’d think these would all work together smoothly. You’d be wrong. As it stands right now, I’m going to have to choose between using the handheld clocks, or using the computer and a large LED clock display. I can’t get both to work together thanks to a software bug. Read on for the details.
Note: The various LocoNet Fast Clocks are digital, and can be set to display in AM/PM or 24-hour format. I’m using 24-hour display.
The Bug
After a good bit of testing, and sure I was doing something wrong, I contacted Digitrax’s tech support. They responded quite promptly. It turns out that the DT402 model of throttles do have a known “problem with the synchronization of the fast clocks” (i.e., they don’t synchronize, even when on a wired Loconet). And at present, there’s no fix for this.
I’ll detail what I found below, but the bottom line is that I’ll be using the computer and display clock, and ignoring the clocks on the handheld throttles, at least for now.
Accuracy
So with all these different clocks, do they actually need to re-synchronize periodically, or can they all just run independently if synchronized once? Just how accurate are fast clocks?
The answer, unfortunately, is “not very”. I suppose this is because they’re using some kind of simple oscillator circuit, and nobody bothered to calibrate these to any kind of reference (which would require an adjustment capability, or matching components before assembly, both of which have a significant cost). Digitrax seems to at least be close to consistent, if not “accurate”. Then again, all I really need is consistency and approximate accuracy, which is what it has.
I did a number of tests, and in the process discovered that my DT402Ds would not sync their clocks to any other reference, even when wired to LocoNet. If you set the time on the DT402D it sets the master Loconet clock, but the other handheld throttle never learns the new time. And if you set the master clock from a computer, the handhelds just ignore you. As noted above, this is some kind of bug in the DT402D, but I’m likely to just not use the handheld clocks, instead using a network-based clock (the Logic Rail clock noted below).
On the other hand, the clock in the DT402D, if left to its own devices, ran at about 8.1:1 when set to 8:1, and the two handhelds only diverged by a couple of minutes per hour (and divergence at 4:1 should be half of this), so you could use these alone in a short session. Just treat them like pocket watches, and have the crew synchronize them at the start of the session. That’s actually prototypical, since watches aren’t all that accurate, and were required in most places to be synchronized on a regular (typically daily) basis to a trusted clock.
Digitrax’s Fast Clock
The Digitrax DCS100 I’m using for a control station includes a “network fast clock”, although it apparently has a software bug that causes it to gain time. It’s certainly not particularly accurate. However, this clock is only useful if you have something that will sync to it, and neither my DT402D throttles nor the Logic Rail clock would do so (JMRI would sync to it, but since the computer has a more accurate fast clock, there’s not much point; if you’ve got a computer, it’s better to have JMRI be the source).
DT402D Throttle showing fast clock at 19:15
In theory, the DT402D throttles I have and other Digitrax throttles that support a fast clock display will sync to the network fast clock kept by the DCS100 when they connect to LocoNet (and some postings I’ve read suggest they re-sync every few minutes), although the DT402R can’t receive signals when operating wirelessly, so they only sync when plugged in.
However, my experience, backed up with a lot of careful logging of LocoNet traffic using JMRI, is that mine never sync under any circumstances. If you set the clock from the DT402D, both the network clock (as read by JMRI) and the DT will have the same time and rate set, but there’s never any additional communications, and over time they’ll drift apart (and this happens even if JMRI isn’t connected, so it’s not the case that that software is interfering somehow). Unplugging and re-connecting the DT will generate a few LocoNet messages, but will not update the clock on the DT to match the one appearing in log messages. And setting the time or rate on one DT will only change the time on the DT itself and the clock being logged, and not on any other DT in use.
Note: I did, however, appear to see one sync once. I’m not sure what was different that time, and I haven’t been able to re-create it, so I may have misinterpreted some other behavior as a sync.
Additionally, the DCS100 fast clock always believes it is the master. And this can cause problems if its on a Loconet with some other clock acting as master if you aren’t careful.
Logic Rail LocoNet Fast Clock
But that’s not all, you can add one or more fast clock displays that will (supposedly) learn their time from the DCS100 Fast Clock. Logic Rail makes two models, the LNFC-1 that I bought (which has 0.8” digits and is designed for mounting to the layout fascia, although it can also mount in a Radio Shack #270-1805 kit box) and the LNFC-L, which has very large 2.3” digits and is designed to be mounted in some kind of frame on a wall. Both are available with or without the necessary wall-wart power supply. The LNFC-1 uses the same 2.1mm power jack as most Digitrax accessories, so it can be powered off the same kind of supply used for those.
My LNFC was purchased in October 2010, and came with version 4.6 software (which looks to be on a socketed IC, so perhaps it can be upgraded in the future).
LocoNet Fast Clock at 19:07
This is not quite as simple as it’s made out to be. Out of the box, the Logic Rail clock will work, but it is acting as a master, overriding the DCS100 clock (or so it seems). If you set the time using the DT402D, the Logic Rail clock will set itself to the correct time. However, it appears that the DCS100 clock and the Logic Rail clock will diverge fairly quickly, as both believe they are the master clock.
Setting the Logic Rail clock to be a slave didn’t work either, as it still failed to learn its time from the DCS100 (I don’t really care if the fast clock drifts, as long as all the displays agree). Although with JMRI it worked somewhat better, since JMRI would cause both the DCS100 and the Logic Rail clock to sync to it (except that the Logic Rail clock was exactly 1 “fast minute” behind the other clocks in most configurations, and this appears to be a known problem).
Also note that this clock requires a LocoNet. If not connected, or if the LocoNet is in turned off, the display will read “IDLE”. It doesn’t have to be a working LocoNet if the Logic Rail clock is set to be the master; it just has to see the LocoNet as active. I plugged it into a disconnected but powered LNRP LocoNet Repeater, and it was quite happy to run.
Computerized Fast Clock
The JMRI software implements an internal Fast Clock, which can be synchronized to the LocoNet clock, or which can synchronize the LocoNet clock to it. It can also apply a correction factor when the LocoNet clock is being used as the source, to keep it accurate, although this didn’t seem to be correct (it may be that the rate error on my DCS100 differs from the one this is intended to fix, due to newer code or just component variation).
With the LNFC set to passive, and JMRI set to sync the LocoNet clock to the computer (without time correction), the LogicRail clock and the DCS100 clock (as displayed by the computer) stayed in sync, but ran at a different rate from the two DT402D throttles (as noted above, the DT402 throttles have a known bug that prevents them from synchronizing to a master clock on the LocoNet).
This is the configuration I plan to use: Computer as clock source, multiple LNFC-1 as slaved displays. As noted in the testing below, the time shown on the LNFC-1 is always one minute behind the time shown on the computer. I could avoid this by making the LNFC-1 the master, but I’m not sure I wouldn’t have the same problem with a second LNFC-1 (and I need to buy one now that I know the DT’s can’t be used as displays).
Testing
I tested several different combinations of configurations, checking the time on the two DT throttles, the DCS100 (as reported by the log messages or the JMRI software), and JMRI itself. All tests were made with all devices set to a nominal 8:1 fast time ratio (as will be seen, none actually ran at exactly 8:1 except JMRI).
In all testing, the computer was connected directly to one of the two LocoNet ports on the DCS100, and was set to log all LocoNet messages. In all tests, the rate reported in log messages was 8.1:1, not 8:1, which is likely due to some kind of rounding. This number will show up below in interesting places.
Test #1: JMRI set to “source Loconet”, “Sync Clock”, No “correction”, LNFC set to “master”.
Test #2: JMRI set to “source Loconet”, No “Sync Clock”, No “correction”, LNFC set to “master”.
Test #3: JMRI set to “source Loconet”, “Sync Clock”, No “correction”, LNFC set to “slave”.
Test #4: JMRI set to “source Loconet”, “Sync Clock”, Yes “correction”, LNFC set to “slave”.
Test #5: JMRI set to “source Internal”, “Sync Clock”, No “correction”, LNFC set to “slave”.
Test #1 failed, apparently with JMRI and the LNFC both trying to change the time, which caused the clocks to jump back and forth in values (and put a huge amount of traffic on the LocoNet bus, as shown in the JMRI logs). Okay, only one master time source allowed, that makes sense and agrees with the LNFC documentation, which says if multiple of them are used, only one can be set as master. However, a subsequent test without the LNFC connected at all failed in the same way, so this may be a JMRI problem.
Test #2 showed the effects of the LNFC acting as the master: the computer and the LNFC were exactly identical at the end of the 146 minute test, running at a rate of 7.53:1. The two DTs had run (apparently independently) at rates of 8.51:1 and 8.48:1, diverging by 4 “minutes” of fast time (30 seconds real time) from each other, and by 139 minutes from the computer (nearly one minute of fast time off per real minute, which is far too divergent to be useful). In this test, no “write fast clock” messages were logged, although there were periodic “read fast clock” messages. This was the only test in which the computer and LNFC agreed exactly, which suggests that the “one minute” error is an LNFC bug.
Test #3 was intended to show the effects of the DCS100 acting as the master clock, with JMRI set to sync to it. The interesting thing about this test is that the LNFC was always exactly one fast minute slower than the JMRI software (I’ve seen other references to this online, and apparently it’s a known bug). This test ran for 249 minutes, and what’s interesting is that the two DT throttles ran at a different rate (8.10:1), and apparently synchronized with each other (although they were 1 fast minute apart at the end, that’s close enough to call them synchronized, as they didn’t both start at the same instant). It’s none too clear what they did synchronize to, as the LNFC and the time reported by JMRI (which may have been either the DCS100 or the LNFC, I can’t really be sure which was the source, although it should have been the DCS100) was substantially different. Both the LNFC and the time reported by JMRI ran at a rate of 10.63:1 (and I confirmed both were showing 8:1 as their nominal rate, and 8.1:1 was what appeared in the logs). I don’t have a good explanation for this, but my suspicion is that the DCS100 clock was correct, and the DTs synchronized to it somehow, while the JMRI software synchronized to the LNFC (which was seriously wrong).
Test #4 was intended to show the ability of JMRI to correct the rate of the DCS100 clock. Given that it appeared from test #3 that the DCS100 might actually have been running at 8.1:1, presumably this would either have no effect, or would “fix” it to be a true 8:1. What I got was that the two DTs ran at 8.10:1 and 8.07:1 over 201 minutes, diverging by 6 minutes. More puzzlingly, the LNFC ran at 7.21:1, and the time reported by JMRI was again one minute fast throughout the test relative to it. It looks like what was being corrected was the LNFC.
One theory I have is that Digitrax has updated their DT403D to correct for the erroneous clock in the DCS100. The hole in this theory is that if they were going to make a fix, it would have been much simpler to make it a DCS100 software fix (but perhaps the bad clock is a hardware problem not easily fixed).
Test #5 was to see how things worked if the computer was the time source, overriding the DCS100. What I saw was a bit odd. Both the LNFC and JMRI were running at 8.0:1, and were again 1 fast minute different throughout the test. The two DTs however, ran at 8.08:1 and 8.04:1, diverging by 4 fast minutes over the 109 minutes of the test. The fact that they weren’t 8.1:1 is what puzzles me.
After upgrading JMRI to version 2.10 (it had been 2.9) this problem seemed to go away. Re-running test #5 (computer as source, set to synchronize, no correction, with LNFC-1 set to slave) the two clocks displayed the exact same time. However, this time the clocks were running at 8.1:1, not 8:1, even though the computer was supposedly the source. Well, I don’t suppose that really matters, as long as I don’t need to synchronize with any external clock.
Summary
What this appears to show is that if the computer and LNFC are not the master, the DTs will run (roughly) correctly, but the LNFC and computer won’t. And if the LNFC is the master, the computer will match it, but the DTs will run independently. Finally, if the computer is the master, the LNFC will run correctly (but be one minute off), and again the DTs will run independently.
Also, when I say the throttles “run correctly”, as noted there’s a flaw. You can set the time and/or fast-time rate from either DT and the computer or LNFC will learn the time and/or rate. But the other throttle never does. So the only way to synchronize two or more throttles to the same time is manually, which is a lot of unnecessary work.
So, my choice is that I can either use the LNFC and computer as my fast clock, and disregard what’s on the throttles, or I can use the throttles, not have a large display, and live with the computer not knowing what “time” it is.
