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. Note iOS products default to using network time, but many Android phones do not, so you have to turn that on in settings, else the phone could be off by quite a lot.
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, which is effectively the update of this data.
The first is, if you want to home in on the rate within just 2 or 3 weeks, then the photo method is crucial. We had to throw out the first two B and C data points that were not taken that way. In other words, you can't be wrong by a large fraction of a second and hope to learn anything in a day or two when the rate is barely 1 second every 10 days. The photo method works fine to get this to the tenth.
Here is a review of that method. We take 10 cel nav pics each time the base watch switches seconds, which means even trying that we are random over that second on the pics. Samples are below.
Then we look at each pic to read off how many seconds do we have to add or subtract to that watch reading to get the iWatch value... which is a tested accurate time. From that we make a scratch paper list as shown below.
This is easy to average. For watch B, for example, it is (10*3 + 6)/10 = 3.6 which is added to the main table above. Takes seconds to do the pics, maybe 5 min to read each and write them down, and another few minutes to add to the table. So the full process to do 7 watches is about 10 min, which only has to be done every 4 days or so about 5 times.
That is all the good news learned so far.
The bad news is, I forgot the iWatch and used my iPhone for the master for the first 7/14 measurement, and discovered that coincidentally for the time of the measurements the iPhone was off by 1 second. This could be spotted after doing the above exercise and noting the data did not make sense. It was obvious something was wrong, and that was the issue. Later that day, we did it again with the iWatch after getting it, and that is the second 7/14 entry in the table. In the first one, I adjusted all the measurements by 1 second.
I had checked this iPhone for accurate time very many times over several years, and it was always spot on. So this was a rare observation. And, about one hour later, it was magically right back on the correct time to the second. Nevertheless, this is an important observation in this game.
This is effectively the end of this article. We will add new data in a week or so, but i am guessing we know the rates. We also bid farewell to Watch A, which is off today in one of our Backup Kits for a world cruise, standing by to help the skipper if called upon. Here is a copy of the certificate that went with the watch.
This type of plot can be made when the data are put into a spreadsheet, and fitting it with a curve is a bit better than just using the first and last points, but the rate in this case are the same, 1.227 vs the 1.2 we are calling it.