|
Watch technology (pg. 2)
|
View this Thread in Original format
| Sly_Guy |
ummm, yeah people I don't think that's the case. Putting a radio reciever on a watch would be a completely inefficient use of resources. Think like an engineer, if there's an easier way to do it, without adding unecessary hardware that's what they'll do.
My money is on the idea that it's pre-programmed with the standardized time and when you enter your time zone it automatically sets the display time with the correct time zone offset. Much easier to accomplish than putting a radio on it. |
|
|
| amb_ |
| quote: | Originally posted by Sly_Guy
ummm, yeah people I don't think that's the case. Putting a radio reciever on a watch would be a completely inefficient use of resources. Think like an engineer, if there's an easier way to do it, without adding unecessary hardware that's what they'll do.
My money is that it's pre-programmed with the standardized time and when you enter your time zone it automatically sets the display time with the correct time zone offset. Much easier to accomplish than putting a radio on it. |
My travel alarm clock automatically sets itself to the local time via shortwave radio signal. |
|
|
| DJ El Kay Dee |
k my watch picks up teh signal from fort collins colorado...but still doesnt explain thru what medium its recieved...hmmm
radiowaves? |
|
|
| rabbitjoker |
| quote: | Originally posted by DJ El Kay Dee
k my watch picks up teh signal from fort collins colorado... |
I am right.
| quote: | Originally posted by DJ El Kay Dee
radiowaves? |
Yes. |
|
|
| DJ El Kay Dee |
| quote: | Originally posted by rabbitjoker
I am right.
Yes. |
all the way from colorado tho???
wow
some pretty strong ass waves there |
|
|
| Fir3start3r |
I dug this up; it's fairly long and only a portion of the actual website.
Veeeedy interesting...
>> Source <<
| quote: |
Time Source
The final puzzle piece arrives from radio station WWVB. The more familiar WWV and WWVH broadcasts, intended primarily for human audiences, can be picked up on any shortwave receiver. WWVB, however, transmits the current Coordinated Universal Time (abbreviated UTC from the French acronym) in machine-readable BCD at 1 bit per second on a 60-KHz carrier frequency that can't be tuned by most general-coverage receivers.
Yes, the data rate really is 1 bit per second. The entire time code repeats once each minute, with 43 data, 10 unused, and 7 framing bits. The 60-KHz carrier provides a phase reference, and the BCD digits give the actual time at the start of each minute.
In addition to the current minute, hour, day, and year, the time code indicates leap seconds, leap years, whether DST is in effect, and a few other odds and ends. If you need sidereal (pronounced "sigh-DEER-al") time with subsecond resolution, the signal includes the current fractional-second offset between UTC and UT1 but, if you know and care about that, you probably haven't read this far anyway.
Now, let's put everything together.
Here and Now
Because WWVB transmits UTC time, the receiver must know its offset from UTC. That's what the time zones tell us: Adding the zone's offset to UTC produces local time. For example, the east coast of the U.S. is in time zone -5, so 1200 UTC becomes 0700 Eastern Standard Time (EST).
At least in the winter, that is, with EST in effect. During the summer months the east coast of the U.S. enters Daylight Savings Time, steps forward one hour, and the time zone offset becomes UTC-4 hours: 1200 UTC becomes 0800 Eastern Daylight Time (EDT).
The WWVB signal includes DST information so, given the time zone, the receiver can figure out the correct local time. Except, of course, in Arizona, Hawaii, or the 77 Indiana counties that do not observe Daylight Savings Time. In those areas, the watch inexorably displays the wrong time.
Indiana has a particularly interesting situation. The state's 92 counties span the Eastern (-5) and Central (-6) time zones. The eastern five counties switch from EST to EDT, and the western 10 switch from CST to CDT, but the central 77 remain on EST throughout the year. Even if the watch knew what state it was in, it still couldn't show the right time!
New Zealand presents another boundary condition, because they're in zone UTC+12 during their winter months. Because they observe DST, their time jumps to UTC+13 in the summer, just about when the northern hemisphere switches out of DST. I wonder if radio-controlled watches can handle a 13-hour winter offset?
I don't know if the watches include a DST override function to disable the automatic adjustment. The only other choice would be to use an adjacent time zone to make the numeric answer come out right. Travellers to Arizona, for example, would normally set their watch to Mountain Standard Time (MST), except during the usual summer months when they must set it to Pacific Standard Time (PST) so the automatic adjustment to PDT would kick the display back into step.
As a result, only those people who wouldn't ordinarily have anything to do with DST must adjust their atomic timepieces twice each year. This is progress?
Fractional Time
The advertisements I've seen mention that the radio-controlled watches and clocks have adjustments for "24 time zones," which sounds reasonable until you recall that there are really 25 ideal and 37 actual zones. I assume, without any justification, that they do not count the UTC zone itself as a time zone and list only the 24 offsets from that base.
Newfoundland provides a useful boundary test case for this situation. Although it's geographically in the Atlantic Time Zone with a -4-hour offset, it adds an additional 30 minutes so that local time is UTC-3:30. I'm reasonably sure that Newfoundland Standard Time isn't among the 24 (or 25) time zones included in the watch's repertoire, which means you must set the time manually.
This is not an isolated situation, as 10 of the 37 time zones on that map I mentioned earlier use half-hour offsets from their nominal zone time. And that doesn't include whatever Nepal's offset might be this week.
The WWVB transmitter emits 50 KW of RF power and covers nearly all of the continental U.S. with an effective signal. It does not blanket the world, so travellers must rely on the accuracy of the internal quartz oscillator when they are out of range.
Newfoundland lies just on the fringe of the WWVB coverage area, so we may safely assume (by invoking the Law of Conservation of Perversity) that a radio-controlled watch will occasionally receive a valid signal. Unless you disable the receiver in your watch, it will automatically adjust itself to the wrong time whenever it hears WWVB.
It's worth noting that Newfoundland also observes DST, but the changeover does not occur at 2:00 am local time as it does in the U.S. The governing statute for Newfoundland specifies that the time changes one minute after midnight, which leads to interesting complications: The effective time steps across a day boundary.
I suspect, without evidence, that Windows 95 would have trouble with those transitions, too.
Redundant Errors
A friend called a while ago and asked if I knew any reason why his new WWVB-based alarm clock might be off by exactly six hours for a while, then snap back to agree with his other, nonradio clocks. The changes seemed to come overnight, when radio reception improves.
Although it may seem strange, the WWVB signal does not include any error-detection or correction bits. Given generally noisy reception and the consequent bit errors, the receiver must sanity-check the framing bits, verify that the time code steps sensibly in successive minutes, and use copious redundancy to overwhelm entropy. This is not as bad as it sounds because the short-term drift of the local oscillator can be quite good. Indeed, a single daily synchronization will suffice for most around-the-house timing purposes.
We both decided that his clock's error-detection algorithm, whatever it might be, had mistakenly accepted at least one invalid time frame. Until it accepted a valid frame, which it might not be able to do for the next 24 hours, the clock displayed the wrong time. There being no manual override, what you saw was what it got, for a whole day.
Now, if the guts of that clock formed part of a system that depended on always having the correct time, there could be some nasty side effects. In order to ensure a valid time code, you must endure a considerable delay, and oscillator stability becomes a significant part of the overall spec.
What's Wrong With...
Although we engineering and programming bears tend to think of time as an inherent part of the universe, it's actually a political construct and, as with all things political, subject to change essentially without notice.
Back in the bad old days, when humans either set their own clocks or got along perfectly well without them, governments could change nearly anything on short notice with impunity. Add a few days to the calendar? Define time zones? Tweak the definition of the second itself? Anything was possible.
Now that the world depends on precise, synchronized clocks, such wrenching changes become decreasingly likely. At some point, though, DST will probably vanish, simply because accounting for duplicate and missing hours twice a year is such a pain in the CPU.
Actually, political time forms just the tip of the legal iceberg, as any and all of the rules and regulations you (or your lawyers) depend on may change during your product's development. It's not like pure engineering, where physical constants and equations generally remain fixed for decades.
Conversely, there may be no such thing as pure software engineering, where even the development tools have the lifetime of a mayfly. But that's an entirely different rant.
The user interface forms another part of the problem. Just how much complexity do you want to jam into a wristwatch-sized case with two or three buttons? No, the IBM Linux watch (http://www.research.ibm.com/Wearabl.../factsheet.html) doesn't count.
The lesson to be learned? Even when your project's specifications seem simple and well contained, Stuff Happens.
|
|
|
|
| Orko |
| quote: | Originally posted by DJ El Kay Dee
all the way from colorado tho???
wow
some pretty strong ass waves there |
i think its a long wave length they use travel long distances |
|
|
| DJ El Kay Dee |
holy ..thats impressive....
doesnt look like a clock tho...lol |
|
|
| Rocco |
| quote: | Originally posted by rabbitjoker
And here's the bad-ass clock they use to keep track of the time:
http://www.boulder.nist.gov/timefre...um/fountain.htm
The uncertainty of NIST-F1 is less than 1 x 10-15, which means it would neither gain nor lose a second in more than 30 million years! |
freaky ! so much for trying to stay alive for a million years so i can gain a whole day of sleep |
|
|
| trancechaos |
| the clock could be preprogramed and all you need to do is select time zone and it does the rest, no communication needed |
|
|
|
|
