In another note and video we show various ways to get accurate time and demonstrate that these various sources do indeed give the same time, which took some coordination of sources. That article includes a 2015 rate measurement of a Timex quartz watch, done in a way similar to what is described here.
For now we illustrate the process of measuring the rate of a watch, in part to support our GPS Backup Kit that includes a rated watch. This shows the method we use to rate the watches we include in those kits. Chances are, some users of that kit will have their own quartz watch, which is probably more sophisticated (and expensive!) than the one we include. However, it is also just as likely that the watch in hand does not have a known rate. It is likely right to the nearest minute, but for cel nav we need to know UTC accurate to the second. Ask yourself now how much you would bet that the watch on your arm—or a crew member's arm—is accurate to the second, or that its rate is known the the correction can be computed.
On the other hand, these days it is actually not as likely that someone is wearing a watch as it was 10 years ago. Many folks have replaced watches with cellphone time, which is accurate when connected to a network. However, once we head off to sea, it is prudent to go back to wearing a traditional watch, preferably with known rate.
We start by setting all the watches to the same time, in this case, within ± 0.5s. The standard source for UTC used here is an iWatch connected to a cellphone network. We have confirmed that the watch is indeed ticking off the correct UTC seconds—although we did notice that every once in a while it appeared to hesitate a fraction of a second at the transition, but this did not affect its transition for the following second.
So with a wireless connection to your phone, it will likely be the most convenient source of accurate time. Or your computer time when linked to the internet. Computers and watches off shore away from any wireless connection, however, are essentially just stand alone watches, although in principle they should have a clock circuit in them that would be as good as a random quartz watch.
Off shore—or on land, for that matter—the primary source of accurate UTC is a GPS signal, which includes UTC as well as your position. GPS is the source the phone and internet companies rely on to provide us with accurate time on our devices.
We are effectively using the GPS here to rate a watch in preparation for losing the GPS. That is, we are talking here about rating a watch so we can do accurate celestial navigation, which would typically mean that for some reason we have lost all GPS navigation.
Below shows the watches lined up on Day 1 when they were set. The iWatch is on ZD = +7, so it was on day July 6, while the others are set to UTC, which would be 7 hr later on July 7.
The three Casios are model F-91W, which is perhaps the most famous of all watches. It is at least very popular. Dating from 1991, they are still popular and sell for $10 (Walmart or Amazon), with millions having been sold globally. They are water resistant, with a 7-year battery. The only weakness is this type of resin band, which if worn daily will only last a year or so before they harden and break. It is easy to replace the band with a more durable style. Also the light in them is not very useful; but they are accurate watches, known to last for many years. The other is a Timex Expedition with several ocean crossings to its credit. Essentially this same model is available today for about $32. Its virtues are a super good light (Indiglo, a timex innovation) and true waterproof. Two time zones are also standard, but not needed. They are, however, no more accurate than the F-91Ws, as is the case with most quartz watches.
Next we want to start a notebook to keep track of the data. (If you use spreadsheets, the notebook data can be later transferred to the computer as a good way to organize the data and maybe make a graph of the results.) We do not need any special math for this exercise. We find time differences, then then divide by some time period to get the rate in seconds per, say, 10 days. This can all be done perfectly well with a few written notes in your logbook.
Here is the second data point two days later.
So far we have not learned much, but this will take a couple weeks. For best values it will take longer. Good timekeeping would call for us checking and recording its error to extend the rate measurement as long as we have accurate UTC available.
This check does not have to be done every day, but some regular check every 3 days or so will lead to a better evaluation—see, for example, the plot of watch error vs time given in the link above. It will also be clear, even on the second data point, that the seconds do not turn over on the watches (test case and reference time) simultaneously, so we are only ± 0.5s at this point. A way to get around this is illustrated below.
After a while it won't matter much if you are off ± 0.5 sec on each reading, we can still get a good average value over an extended time. But if you care to home in on the rate more quickly, then one trick that is a good estimate of the fractions of a second is to take a series of rapid cell phone pics of the two time sources. In this case is would be a phone taking a series of pictures like the one above. Then make a table as shown below, this one made on the 7th day. It shows the watch errors from 8 pics, each taken just as the iWatch changed seconds.
Remember we are after the correction we apply to the watch to get UTC, so a positive number means we add this to the watch time; negative, we subtract it. In this example, in the second pic of watch B, it read 2 second below the iWatch standard, so it is a +2. Now we can summarize what we have to date.
The time difference between first and latest times in decimal days (dT) is figured from the times converted to decimal days (d.dd), which can be adequately approximated as d.dd = d + h/24. The "10d-rate" is latest watch error (WE) divided by time elapsed since setting (dT).
We don't have good rates yet, but we have learned a lot. First, these $10 Casio F-91W classic watches (A, B, C) are indeed very good. They are all gaining time (except maybe C, which is spot on after 7.8 days), but at a very low rate, and the Timex Expedition is losing time. So far it looks like -2.3 s/10 days, but it is too early to tell.
I will post this note now, and then update it every few days till we get convincing rates. We should know these pretty well in another week or so... but again, for best cel nav practice, this should be considered an ongoing process where you keep a record of the watch error and date, from which you can continually update the rate... or better put, home in on a more and more accurate rate.
If you are using your own phone to compare to a watch, then you would need a second phone to take the pics. Or hang the phone over a computer monitor and use pictures of that for the series, such as shown below. That is in fact how we did it for the rating example in our Celestial Navigation textbook in Figure 11.5-2. Most computers have some option to show the time on the screen... again we have to assume you have internet connections and have the system clock set to update automatically.
I will return to this post every few days for a while to update the rates. For those following it, you will then see how the accuracy of the rate improves with time—or better still, find a watch and rate it yourself as an exercise in practical cel nav.
But looking ahead, here is what we are after (using new timing numbers):
We want to know the rate of the navigation watch and the date we set it. Say it turns out to be +2.4 s every 10 days, and we set it to have no error on Aug 8. Then on Dec 3 we want to know the watch error so we can find a correct UTC.
First we figure the number of days between Dec 3 and Aug 8. You can count this out, or use the day numbers from the back of the Nautical Almanac—yes, there is such a table there, probably originally for this very purpose, although there are quite a bit of data in the Almanac that was at one time used frequently that we don't use much these days.
Dec 3 (day 337) - Aug 8 (day 220) is 117 days. Then 117d x 2.4/10d = 28.1s. We read the time from the watch and add 28 seconds to get the right watch time, then we add the zone description (ZD) of the watch to get UTC. The ZD might be, for example, ZD = +4h, corresponding to EDT.
Belt and suspenders.
We are wearing the watch (watch time, WT) we navigate by, and it is set to ZD = +4. That, by definition, means UTC = WT + 4h, assuming no watch error (WE). But we know all watches gain or lose time at some rate. In this case we know the rate is +2.4s every 10 days, and we set the watch to the correct ZD+4 time on Aug 8. It is now Dec 3.
We did a sun sight and the WT was 18:20:05. So we add 28s (as noted above) to get 18:20:33 on Dec 3. Then we add 4h to get 22:20:33 as the correct UTC to use when we look up data in the Nautical Almanac.
The data tables below will be updated every few days, with comments on progress. The date of last entry is given in the table.
The rates are getting better known, but still not stable. After we see the 10d rate the same for a while we know we are getting closer. We need to know this to the tenth of a second so we can correct the watch farther into the future.
Now that we know they are good, we added 3 more of the F-91s (D,E,F), and started tracking them 1.79 days ago, so we will have enough calibrated watches for the backup kits.
Next time you look here there will be a new table in this space,
which we will update every few days, with comments on progress.