"Atomic" clock fail

[RobertVA]

I have one of those "atomic" clocks that automatically corrects its setting based on a remote time standard, including adjustments for switching back and forth between standard and daylight savings time. It doesn't even have a setting knob or combination of buttons to allow me to set it manually.

This weekend it continued a long tradition of semi uselessness for a couple of days after the time change. It was late advancing to daylight savings time, eventually caught up, only to go back to standard time at some point Sunday when I wasn't looking. It's now Two AM Monday and it's still displaying standard time.

Does anybody know what radio broadcast those clocks use for a standard? I curious if the "standard" is also switching back and forth or the clock is detecting different broadcasts at different parts of the day and one of the "standards" is late resetting their clock.

 

[Asbo Zaprudder]

I suspect that the firmware in your clock is to blame. However, I don't know what the format of the time code is. I'd be surprised if it encoded daylight saving changes, and wasn't just broadcast as Universal Time, leaving it up to the receiver to make any necessary corrections for local time zone and daylight saving adjustments.

http://en.wikipedia.org/wiki/Time_signal#Radio_time_sources

ETA: Seems that the time code does include TZ and DST information as well as UTC.

http://en.wikipedia.org/wiki/WWVB#Announcement_bits

Maybe the time-code station did screw up, but I'd be more inclined to blame the firmware.

http://en.wikipedia.org/wiki/Radio_clock#Daylight_Saving_Time

 

[FreezeC77]

I miss spring forward/fall back.

Now that Daylight Savings time lasts almost 2/3 of the year shouldn't it be called standard time? If something happens 2/3 of the time and something else happens 1/3 of the time, wouldn't you call the thing that happens 2/3 of the time the standard?

 

[Robert Maxwell]

I miss spring forward/fall back.

Now that Daylight Savings time lasts almost 2/3 of the year shouldn't it be called standard time? If something happens 2/3 of the time and something else happens 1/3 of the time, wouldn't you call the thing that happens 2/3 of the time the standard?

You would think. I'd rather have the time be the same all year than have it flip-flop like it does. I don't care if we stick with DST or standard, just pick one!

 

[Jadzia]

I'd rather have the time be the same all year than have it flip-flop like it does. I don't care if we stick with DST or standard, just pick one!

I agree. We should all use GMT. Then we can all celebrate new year at the same time, and we'll all know what time it is everywhere in the world. If people are worried about dark mornings or dark evenings, then we can adjust the start/stop times of the working day, rather than the clock.

 

[sojourner]

^awfully convenient for you.

I have no idea how that broadcast system works, so this is just wild supposition. Are you perhaps close to the border of a time zone and getting competing signals?

 

[Jadzia]

^awfully convenient for you.

The English defined standard time! That's why the G in GMT stands for Grimsby

But being half way between Australia's +8 to +10 and USA's -5 to -8, it makes sense that either GMT or GMT+1 would be the common standard


.

 

[Owain Taggart]

I have an atomic clock. Actually, I have two; my bedside clock and my watch, and I didn't have any trouble this time, but last time I was having a lot of trouble receiving the signal. I thought maybe there were problems with the signal.

 

[RobertVA]

The clock I have has controls to select which time zone it "displays" (it has old fashion hands that step instead of just rotating slowly) so it shouldn't be having problem with being near the border of a time zone. I live near the Atlantic coast far south of the Canadian provinces that are in the Atlantic time zone.

The Wikipedia articles describe some signal formats that I think might have some potential for a clock to get "confused" for the period between 1900EST Saturday and 2000EDT Sunday, but my interpretation of the signaling scheme leads me to beleive the signal should be in the same format by 2000EDT Sunday that it should be in until we go back to standard time in the fall. I'm still suspecting somebody is tardy changing their transmission and clocks that aren't having problems are either not receiving the corrupt signal or have been programed to ignore switching between standard and savings time more than once in a period of a few days.

 

[Brolan]

Likely it just isn't getting a good signal. Unless it is near a wall in a wood-frame building or a window in any building, it will not get a good signal.

 

[RobertVA]

It makes sense that poor reception would delay the switches between standard and savings time. I see no reason it should make the correct change followed a few hours later by a switch back to the wrong time.

This is reminiscent of the problems I've had with touch tone dial pads. When the phone is off hook the line is supposed to provide DC to power the touch pad. If the pad doesn't get the correct polarity it can't operate. Apparently a lot of phone companies had problems getting the polarity reversed and manufacturers started putting a circuit in their new phones that made them tolerant of a phone line that doesn't comply with the published specifications. I had a few occasions when the local provider managed to reverse the polarity on my line, disabling the pads on my older phones, one of which I had retailed after the phone company was no longer allowed to rent phones.

 

[Alpha_Geek]

These clocks incorporate a VLF reciever that catches signals from WWVB, a station run by the US National Institute of Standards and Technology.

WWVB transmits from Fort Collins, Colorado at 60 kilohertz and provides the time via binary coded decimal at 1 bit per second. The signal from WWVB is significantly different in format than that of it's sister stations, WWV and WWVH as they provide audio announcements and clock ticks.

WWVB transmits the time in UTC, which is essentially the same as old Greenwich Mean Time.

If your're getting a signal and have the correct time zone selected, then it could be a firmware issue as someone else suggested. No suprise since Lawmakers redefined when DST starts and ends a few years ago.

 

[RobertVA]

These clocks incorporate a VLF reciever that catches signals from WWVB, a station run by the US National Institute of Standards and Technology.

WWVB transmits from Fort Collins, Colorado at 60 kilohertz and provides the time via binary coded decimal at 1 bit per second. The signal from WWVB is significantly different in format than that of it's sister stations, WWV and WWVH as they provide audio announcements and clock ticks.

WWVB transmits the time in UTC, which is essentially the same as old Greenwich Mean Time.

If your're getting a signal and have the correct time zone selected, then it could be a firmware issue as someone else suggested. No suprise since Lawmakers redefined when DST starts and ends a few years ago.

Doesn't explain why the problem only occurs for the first couple of days after a EST to EDT or EDT to EST switch instead of the entire week or more long period between the current change overs and the old dates.

The clock wouldn't need to have changeover dates in it's firmware, as the incoming radio signal contains all the information required. The only internal information necessary is the time zone, as selected by the row of buttons on the back of the clock. The signal includes a bit to control when saving time is to be applied and a separate bit to indicate which day (one day, not the next several) when the clock should wait until 0200 local time to spring forward or fall back.

I'm suspecting the computer that generates the signals has a bug concerning when it should include the bit that tells the clocks to wait until 0200 to change times. The brevity of the problem period suggests the "change day" bit is being transmitted for an extra day or two and the unpredictable nature of the clock going back to the incorrect time dependent on when radio propagation permits the clock to have another reception opportunity. I thinking clock manufacturers may have compensated for that problem by imposing a longer minimum period before displaying another standard-saving or saving-standard time change.

 

[Owain Taggart]

The clock wouldn't need to have changeover dates in it's firmware, as the incoming radio signal contains all the information required. The only internal information necessary is the time zone, as selected by the row of buttons on the back of the clock. The signal includes a bit to control when saving time is to be applied and a separate bit to indicate which day (one day, not the next several) when the clock should wait until 0200 local time to spring forward or fall back.

Right, exactly. All it needs to do is receive the signal. It shouldn't matter on the clock's end if there was a rule change, though I did notice a bit of confusion with the clock when the rule was still new on when to change, though I suspect they've done something with the signal to help with that. With my Atomic watch, it seems to have a number of tries before it gives up to try again the next day. I think it's 3. Also one thing to try would be to put the clock high up and facing a window. I feel that always helps me when having it change.

 

[Alpha_Geek]

WWVB transmits UTC information only because that's the only thing the precision measurement crowd cares about. DST isn't part of it, that's incumbent on the end user equipment to compensate for or discard.

I'm still gonna say it's wonky firmware in your clock, or for some reason it thinks you're in a different time zone than eastern.

http://www.nist.gov/pml/div688/grp40/radioclocks.cfm