Last night my radio controlled alarm clock was exactly two hours slow.Funny you should say that, last night at 10pm I noticed our MSF kitchen
I previously lent it to a friend, then took it home in the my car. I
am guessing it lost its signal during the journey. Two things puzzle
me here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then
set the hour hand then set the minute hand. How come the minutes were showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in general are okay.
Last night my radio controlled alarm clock was exactly two hours slow.
I previously lent it to a friend, then took it home in the my car. I
am guessing it lost its signal during the journey. Two things puzzle
me here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then
set the hour hand then set the minute hand. How come the minutes were showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in general are okay.
On Mon 16/01/2023 16:27, Scott wrote:
Last night my radio controlled alarm clock was exactly two hours slow.
I previously lent it to a friend, then took it home in the my car. I
am guessing it lost its signal during the journey. Two things puzzle
me here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then
set the hour hand then set the minute hand. How come the minutes were
showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in
general are okay.
If your battery is dying the radio will stop working long before the
rest of the clock (same goes for radio thermometers as well.) If you
re-power the clock it will wind the fingers in normal clock fashion to
12:00, then when the receiver kicks in - usually after about 2-3 minutes
- it will wind round to the current time. The second hand will sync with
the radio immediately it syncs as that hand is managed independently of
the clock mechanism.
The only other question that comes to mind is whether the clock is
running off DCF in which case there should be a system setting within
the clock to add or subtract time-shift hours which for DCF would be one
hour negative. There may also be an independent DST switch, which could >account for the two hour error. Having said that these last two points
will usually only apply to digital clocks.
On Mon, 16 Jan 2023 17:39:36 +0000, Woody <harrogate3@ntlworld.com>Is your clock DCF (Frankfurt) or MSF (Anthorn) ?
wrote:
On Mon 16/01/2023 16:27, Scott wrote:See Mark's post which muddies the water considerably.
Last night my radio controlled alarm clock was exactly two hours slow.If your battery is dying the radio will stop working long before the
I previously lent it to a friend, then took it home in the my car. I
am guessing it lost its signal during the journey. Two things puzzle
me here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then
set the hour hand then set the minute hand. How come the minutes were
showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in
general are okay.
rest of the clock (same goes for radio thermometers as well.) If you
re-power the clock it will wind the fingers in normal clock fashion to
12:00, then when the receiver kicks in - usually after about 2-3 minutes
- it will wind round to the current time. The second hand will sync with
the radio immediately it syncs as that hand is managed independently of
the clock mechanism.
The only other question that comes to mind is whether the clock is
running off DCF in which case there should be a system setting within
the clock to add or subtract time-shift hours which for DCF would be one
hour negative. There may also be an independent DST switch, which could
account for the two hour error. Having said that these last two points
will usually only apply to digital clocks.
On 16/01/2023 18:44, Scott wrote:
On Mon, 16 Jan 2023 17:39:36 +0000, Woody <harrogate3@ntlworld.com>Is your clock DCF (Frankfurt) or MSF (Anthorn) ?
wrote:
On Mon 16/01/2023 16:27, Scott wrote:See Mark's post which muddies the water considerably.
Last night my radio controlled alarm clock was exactly two hours slow. >>>> I previously lent it to a friend, then took it home in the my car. IIf your battery is dying the radio will stop working long before the
am guessing it lost its signal during the journey. Two things puzzle
me here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then
set the hour hand then set the minute hand. How come the minutes were >>>> showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in >>>> general are okay.
rest of the clock (same goes for radio thermometers as well.) If you
re-power the clock it will wind the fingers in normal clock fashion to
12:00, then when the receiver kicks in - usually after about 2-3 minutes >>> - it will wind round to the current time. The second hand will sync with >>> the radio immediately it syncs as that hand is managed independently of
the clock mechanism.
The only other question that comes to mind is whether the clock is
running off DCF in which case there should be a system setting within
the clock to add or subtract time-shift hours which for DCF would be one >>> hour negative. There may also be an independent DST switch, which could
account for the two hour error. Having said that these last two points
will usually only apply to digital clocks.
Last night my radio controlled alarm clock was exactly two hours slow.
I previously lent it to a friend, then took it home in the my car. I am guessing it lost its signal during the journey. Two things puzzle me
here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then set
the hour hand then set the minute hand. How come the minutes were
showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in general are okay.
On Mon, 16 Jan 2023 16:27:45 +0000, Scott wrote:
Last night my radio controlled alarm clock was exactly two hours slow.
I previously lent it to a friend, then took it home in the my car. I am
guessing it lost its signal during the journey. Two things puzzle me
here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then set
the hour hand then set the minute hand. How come the minutes were
showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in
general are okay.
Was moved faster than light.
Last night my radio controlled alarm clock was exactly two hours slow.
I previously lent it to a friend, then took it home in the my car. I
am guessing it lost its signal during the journey. Two things puzzle
me here:
1. I thought if a radio controlled clock lost signal it would keep
running until a new signal was found.
2. I thought the control process first took the clock to 12:00 then
set the hour hand then set the minute hand. How come the minutes were showing exactly correct but the hour was two hours out?
It has now recovered so I am assuming the battery and the mechanism in general are okay.
The error detection and correction on the protocols they use was
designed a long time ago and is very crude. This means there is a
relatively high chance of interference or weak signal causing the clock
to set itself incorrectly.
On Tue, 17 Jan 2023 21:22:32 +0000, Brian Gregory ><void-invalid-dead-dontuse@email.invalid> wrote:
The error detection and correction on the protocols they use was
designed a long time ago and is very crude. This means there is a
relatively high chance of interference or weak signal causing the clock
to set itself incorrectly.
There is no error correction, only detection using parity.
The data rate is 118 bits per minute:
8 bits are used for framing
4 bits are used for parity
53 bits are used for data
53 bits are unused (currently)
Any decent controller should at least wait for error-free consistent
data for at least 2 complete minutes before setting the clock.
That catches most of the errors that the parity checks don't.
That's what I did in my software anyway, way back when I wrote it
for the Maplin receiver module.
On Thu, 19 Jan 2023 19:27:32 GMT, Paul Ratcliffe
<abuse@orac12.clara34.co56.uk78> wrote:
On Tue, 17 Jan 2023 21:22:32 +0000, Brian Gregory >><void-invalid-dead-dontuse@email.invalid> wrote:
The error detection and correction on the protocols they use was
designed a long time ago and is very crude. This means there is a
relatively high chance of interference or weak signal causing the clock
to set itself incorrectly.
There is no error correction, only detection using parity.
The data rate is 118 bits per minute:
8 bits are used for framing
4 bits are used for parity
53 bits are used for data
53 bits are unused (currently)
Any decent controller should at least wait for error-free consistent
data for at least 2 complete minutes before setting the clock.
That catches most of the errors that the parity checks don't.
That's what I did in my software anyway, way back when I wrote it
for the Maplin receiver module.
Does any of this explain how Mark's clock could be 2 hours fast at the
same time as mine was two hours slow, probably living about 500 miles
apart?
Does any of this explain how Mark's clock could be 2 hours fast at the
same time as mine was two hours slow, probably living about 500 miles
apart?
On 19/01/2023 21:38, Scott wrote:
Does any of this explain how Mark's clock could be 2 hours fast at the
same time as mine was two hours slow, probably living about 500 miles
apart?
I think we'd have heard about this elsewhere if this was anything
other than a co-incidence.
On 20/01/2023 00:57, Brian Gregory wrote:
On 19/01/2023 21:38, Scott wrote:Indeed. My clock has been fine since too, so just a co incidence
Does any of this explain how Mark's clock could be 2 hours fast at the
same time as mine was two hours slow, probably living about 500 miles
apart?
I think we'd have heard about this elsewhere if this was anything
other than a co-incidence.
On Thu, 19 Jan 2023 19:27:32 GMT, Paul Ratcliffe <abuse@orac12.clara34.co56.uk78> wrote:
On Tue, 17 Jan 2023 21:22:32 +0000, Brian Gregory ><void-invalid-dead-dontuse@email.invalid> wrote:
The error detection and correction on the protocols they use was
designed a long time ago and is very crude. This means there is a
relatively high chance of interference or weak signal causing the clock
to set itself incorrectly.
There is no error correction, only detection using parity.
The data rate is 118 bits per minute:
8 bits are used for framing
4 bits are used for parity
53 bits are used for data
53 bits are unused (currently)
Any decent controller should at least wait for error-free consistent
data for at least 2 complete minutes before setting the clock.
That catches most of the errors that the parity checks don't.
That's what I did in my software anyway, way back when I wrote it
for the Maplin receiver module.
Does any of this explain how Mark's clock could be 2 hours fast at the
same time as mine was two hours slow, probably living about 500 miles
apart?
"Paul Ratcliffe" <abuse@orac12.clara34.co56.uk78> wrote in message news:slrntsj6d4.1dqo.abuse@news.pr.network...
Any decent controller should at least wait for error-free consistent
data for at least 2 complete minutes before setting the clock.
That catches most of the errors that the parity checks don't.
That's what I did in my software anyway, way back when I wrote it
for the Maplin receiver module.
How often is the time data sent? 2 minutes seems a long time to wait,
but I suppose if the time updates are 1 minute apart (for example), 2
minutes is only two samples to check for consistency.
The very old clock/radio (*) that my wife had before I met her had particularly stupid radio-controlled clock. It had a habit of adjusting itself to random time, usually doing this in the middle of the night
when no-one was awake to notice that the clock was wrong. This meant
that the alarm didn't go off at the time it was set (because it was set
for 07:00 but the clock time was wrong), so it either went off in the
middle of the night or else long after she should have set off for work.
And it had no way of manually setting the time, so even if you noticed
the night before, you couldn't put it right (and hope it didn't get auto-adjusted to the wrong time after that) - you had to want many hours until the time corrected itself.
That radio went in the bin (after I'd had a quick look inside in case
there was obvious sign of the radio-clock aerial being detached). No we
use Alexas as (amongst other things) alarm clocks.
Are radio-controlled "Rugby/Anthorn" clocks still used much these days?
I imagine that as long as you have wifi link to an internet connection,
you can use an NTP source to get an update within a fraction of a
second. Are there any simple clocks which do this - apart from
multi-purpose devices like Alexa which do so much more as well.
(*) It was old enough that it had manual radio tuning with a rotary
knob, a needle that moved across a scale and a variable capacitor,
rather than digital synthesised tuning indicated on the LED display.
Probably about 30 years old.
Any decent controller should at least wait for error-free consistent
data for at least 2 complete minutes before setting the clock.
That catches most of the errors that the parity checks don't.
That's what I did in my software anyway, way back when I wrote it
for the Maplin receiver module.
In article <tqe3va$22o85$1@dont-email.me>,
MB <MB@nospam.net> wrote:
I know that any time I have any problems with one of the clocks I check
the battery or just change it. Most electronic items tend to behave
erratically when the batteries are low. Sometimes even though the
battery voltage seems normal, the fault will clear after a battery change.
nothing really changes, When I first started doing equipment maintenance in >the 1960s, the first thing to look at was the power supply.
I know that any time I have any problems with one of the clocks I check
the battery or just change it. Most electronic items tend to behave erratically when the batteries are low. Sometimes even though the
battery voltage seems normal, the fault will clear after a battery change.
With possessing any electrical knowledge, I understand that it the
battery goes flat the device usually stops working.
On Fri, 20 Jan 2023 14:29:30 +0000 (GMT), charles
<charles@candehope.me.uk> wrote:
In article <tqe3va$22o85$1@dont-email.me>,
MB <MB@nospam.net> wrote:
I know that any time I have any problems with one of the clocks I checknothing really changes, When I first started doing equipment maintenance in >>the 1960s, the first thing to look at was the power supply.
the battery or just change it. Most electronic items tend to behave
erratically when the batteries are low. Sometimes even though the
battery voltage seems normal, the fault will clear after a battery change. >>
With possessing any electrical knowledge, I understand that it the
battery goes flat the device usually stops working.
"Paul Ratcliffe" <abuse@orac12.clara34.co56.uk78> wrote in message news:slrntsj6d4.1dqo.abuse@news.pr.network...
Any decent controller should at least wait for error-free consistent
data for at least 2 complete minutes before setting the clock.
That catches most of the errors that the parity checks don't.
That's what I did in my software anyway, way back when I wrote it
for the Maplin receiver module.
How often is the time data sent? 2 minutes seems a long time to wait, but I suppose if the time updates are 1 minute apart (for example), 2 minutes is only two samples to check for consistency.
On Fri, 20 Jan 2023 14:29:30 +0000 (GMT), charles
<charles@candehope.me.uk> wrote:
In article <tqe3va$22o85$1@dont-email.me>,
MB <MB@nospam.net> wrote:
I know that any time I have any problems with one of the clocks I checknothing really changes, When I first started doing equipment maintenance in >> the 1960s, the first thing to look at was the power supply.
the battery or just change it. Most electronic items tend to behave
erratically when the batteries are low. Sometimes even though the
battery voltage seems normal, the fault will clear after a battery change. >>
With possessing any electrical knowledge, I understand that it the
battery goes flat the device usually stops working.
On 20/01/2023 16:08, Scott wrote:
On Fri, 20 Jan 2023 14:29:30 +0000 (GMT), charles
<charles@candehope.me.uk> wrote:
In article <tqe3va$22o85$1@dont-email.me>,
MB <MB@nospam.net> wrote:
I know that any time I have any problems with one of the clocks I check >>>> the battery or just change it. Most electronic items tend to behavenothing really changes, When I first started doing equipment maintenance in >>> the 1960s, the first thing to look at was the power supply.
erratically when the batteries are low. Sometimes even though the
battery voltage seems normal, the fault will clear after a battery change. >>>
With possessing any electrical knowledge, I understand that it the
battery goes flat the device usually stops working.
You'd make a great engineer. The other thing you need to know before you >qualify is - if it's not working, kick it.
On 20/01/2023 16:08, Scott wrote:
On Fri, 20 Jan 2023 14:29:30 +0000 (GMT), charles
<charles@candehope.me.uk> wrote:
In article <tqe3va$22o85$1@dont-email.me>, MB <MB@nospam.net> wrote:
I know that any time I have any problems with one of the clocks I
check the battery or just change it. Most electronic items tend to
behave erratically when the batteries are low. Sometimes even though
the battery voltage seems normal, the fault will clear after a
battery change.
nothing really changes, When I first started doing equipment
maintenance in the 1960s, the first thing to look at was the power
supply.
With possessing any electrical knowledge, I understand that it the
battery goes flat the device usually stops working.
You'd make a great engineer. The other thing you need to know before you qualify is - if it's not working, kick it.
That is known, technically, as "Percussive Maintenance"
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 117:24:24 |
| Calls: | 6,662 |
| Files: | 12,209 |
| Messages: | 5,334,237 |