Receiving the MSF time signal on cheap radio modules
Splitting the MSF received signal into 100ms chunks, all of the seconds
apart from the start-of-minute marker are of the form 0AB11111. Using "x"
to represent a 100ms chunk whose value could not be determined, I notice
that many of the received seconds were of the form "0AB1x111" or "0AB11x11"
etc - i.e. there was only one 100ms chunk within the second whose value
could not be reliably determined and whose value was non-critical.
Ooops - apologies - this referred to another algorithm I investigated, and
makes no sense in the context of this algorithm.
Still I believe a blame algorithm would recover a lot of lost data. It
would require a shift register 1,200 wide - with each slot representing the
value during a 100ms interval from achosen edge.
Thanks.
In message CAGJ4F+54Sxqc34fpNefNW3q3emHmq+uC-V-Lfc5Bnfk7h7qWUw@mail.gmail.com, "Deirdre O'Byrne" writes:
With a blame algorithm in place it should be possible to recover these signals.
Yes, easily.
At distance MSF is significantly harder to receive than DCF77.
One of the reasons is that USA also operates two 60kHz transmitters
also very precisely on frequency, so there are areas of the world
where the three signals cancel and areas where they reinforce
each other.
I tried to model this many years ago, but I don't trust the result,
somebody with better HF-propagation chops than me should look at it.
In addition to that problem, switch-mode designers seems to just
love 60 kHz, and at least here in Denmark there is a lot more
"hash" around 60 kHz than 77.5 kHz.
Finally, the modulation scheme of MSF is a bit on the overengineered
side, which makes pulse discrimination needlessly hard - as you have
also found out.
The big advantage of the blame algorithm is that since it is so
tolerant of missing pulses, you can be throw everything away which
isn't 100% clearcut.
If you look at the top of the dcf77.c file, you can see how I did
that for DCF77, but the complex modulation of MSF needs a much
more complex state engine there.
Finally, many of the small "clock-receivers", like the one you use,
are optimised for battery-life and therefore they use very resonant
filters, often crystal-filters, and heavy low-pass after demodulation,
and that trows away a LOT of information which would be useful to
have to discriminate the pulses.
If you go for the SDR approach, you will have much more information
available, and can use much more well-behaved filters to detect the
pulses, and one added advantage of carrier-tracking is that the
power-modulation is carrier-synchronous, which makes them much
easier to spot.
So really: Get yourself an 1MSPS ADC chip and go that route instead.
(In theory, certain modern sound-cards should be usable for this if
you can rip out their low-pass filters. Havn't tried.)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message A2B31A8C-147B-4D35-BDC2-8D64D3743226@n1k.org, Bob kb8tq writes:
If you want to get even more “nutty", look at the “seed” that you likely already have
for the computation. In this day and age, you probably know what day / month / year it is.
So, some of us think of that as cheating :-)
Since you might not (say) know the hour, you have a +/- 1 day sort of tolerance on that. It rolls
into month and year in some cases. The seed adds complexity, but probably makes
things more robust.
I tried it, and it gave surprisingly little benefit.
Unless very fast initial aquisition is your goal (why?!) you get a
more robust result by not "cheating", since in real life at some
point your RTC chip will contain bogus values.
If you go the SDR route and decode DCF77 and MSF (and 162kHz France,
WWV/B, the japanese signal at 40kHz and the russian at 200/3 kHz for
that matter) in parallel, it is perfectly fair to expect them all
to have the same date (modulus timezones).
And yes, I would really love to se a colaborative project that
produced an "all-world VLF timecode SDR-receiver"...
One cute thing is that this stuff is (in general) not very compute intensive. If data past the
minute tick is being looked at, you probably can afford to run multiple parallel solutions (even
on a < $5 MCU).
The NTPns ran on a Soekris4501 and I was never able to measure a
difference in power having the DCF77 blame code running or not.
After all, it's only sixty trival patterns to match once a second...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Deirdre,
Great discussion on my favorite topic. I am the guy on the other side of
the lake that curses MSFs interference with WWVB.
I did indeed cheat by using the GPS time and 1 second tick to recreate the
WWVB timecode bits to remove the psk shifts in the received signal here on
the east coast. This allowed phase tracking receivers to correctly work
again.
Did MSF finally go to a BPSK signal format? I heard they were considering
that.
regards
Paul
WB8TSL
On Tue, Feb 6, 2018 at 4:26 PM, Poul-Henning Kamp phk@phk.freebsd.dk
wrote:
In message A2B31A8C-147B-4D35-BDC2-8D64D3743226@n1k.org, Bob kb8tq
writes:
If you want to get even more “nutty", look at the “seed” that you likely
already have
for the computation. In this day and age, you probably know what day /
month / year it is.
So, some of us think of that as cheating :-)
Since you might not (say) know the hour, you have a +/- 1 day sort of
tolerance on that. It rolls
into month and year in some cases. The seed adds complexity, but probably
makes
things more robust.
I tried it, and it gave surprisingly little benefit.
Unless very fast initial aquisition is your goal (why?!) you get a
more robust result by not "cheating", since in real life at some
point your RTC chip will contain bogus values.
If you go the SDR route and decode DCF77 and MSF (and 162kHz France,
WWV/B, the japanese signal at 40kHz and the russian at 200/3 kHz for
that matter) in parallel, it is perfectly fair to expect them all
to have the same date (modulus timezones).
And yes, I would really love to se a colaborative project that
produced an "all-world VLF timecode SDR-receiver"...
One cute thing is that this stuff is (in general) not very compute
intensive. If data past the
minute tick is being looked at, you probably can afford to run multiple
parallel solutions (even
on a < $5 MCU).
The NTPns ran on a Soekris4501 and I was never able to measure a
difference in power having the DCF77 blame code running or not.
After all, it's only sixty trival patterns to match once a second...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
Hi
On Feb 6, 2018, at 4:19 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message CAGJ4F+54Sxqc34fpNefNW3q3emHmq+uC-V-Lfc5Bnfk7h7qWUw@mail.gmail.com, "Deirdre O'Byrne" writes:
With a blame algorithm in place it should be possible to recover these signals.
Yes, easily.
At distance MSF is significantly harder to receive than DCF77.
One of the reasons is that USA also operates two 60kHz transmitters
also very precisely on frequency, so there are areas of the world
where the three signals cancel and areas where they reinforce
each other.
I believe we only have one transmitter on the air at 60 KHz in the US. The
Japanese do indeed operate multiple transmitters on the same frequency
( 40 KHz). There have been a number of proposals to set up a second US
transmitter. The last time I noticed them beating the drum for one, it was
going to be at 40 KHz rather than 60 KHz. The proposal pretty much died
yet again ….
Since MSF is on 60 KHz, you do indeed get dead spots. There probably is an
interesting plot of locations that have issues with both the 40 KHz and 60 KHz
transmissions due to simply being in the wrong place.
Bob
I tried to model this many years ago, but I don't trust the result,
somebody with better HF-propagation chops than me should look at it.
In addition to that problem, switch-mode designers seems to just
love 60 kHz, and at least here in Denmark there is a lot more
"hash" around 60 kHz than 77.5 kHz.
Finally, the modulation scheme of MSF is a bit on the overengineered
side, which makes pulse discrimination needlessly hard - as you have
also found out.
The big advantage of the blame algorithm is that since it is so
tolerant of missing pulses, you can be throw everything away which
isn't 100% clearcut.
If you look at the top of the dcf77.c file, you can see how I did
that for DCF77, but the complex modulation of MSF needs a much
more complex state engine there.
Finally, many of the small "clock-receivers", like the one you use,
are optimised for battery-life and therefore they use very resonant
filters, often crystal-filters, and heavy low-pass after demodulation,
and that trows away a LOT of information which would be useful to
have to discriminate the pulses.
If you go for the SDR approach, you will have much more information
available, and can use much more well-behaved filters to detect the
pulses, and one added advantage of carrier-tracking is that the
power-modulation is carrier-synchronous, which makes them much
easier to spot.
So really: Get yourself an 1MSPS ADC chip and go that route instead.
(In theory, certain modern sound-cards should be usable for this if
you can rip out their low-pass filters. Havn't tried.)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Did MSF finally go to a BPSK signal format? I heard they were considering
that.
I don't know, though I've ordered a SDR which should be able to receive the
raw signal. I don't see anything about it in the documentation, though.
Regards,
Deirdre.
Hi
On Feb 6, 2018, at 3:48 PM, Deirdre O'Byrne deirdre.dub@gmail.com wrote:
Tom,
Thanks for the feedback!
On 6 February 2018 at 20:29, Tom Van Baak tvb@leapsecond.com wrote:
- Not all decoding errors are equal. Since this is a time code instead of
arbitrary binary data you can use the internal structure of the data to
your benefit.
As I said to Poul-Henning, that is the next level of error detection, which
also has application in error correcting some of the "almost-right" signals.
- A side-effect of your data set is that you can track performance of the
oscillator inside the logic analyzer: convert the 700k GPS timestamps into
interval, find and replace the 4 glitch lines with 2 lines of 1.000150, and
then use Stable32 or TimeLab to plot. I used a 10 minute running average to
reduce the 50 us quantization noise. Note the mean frequency of your
timebase is 152 ppm low.
I made it out to be 152.2ppm, which is kinda disappointing. But the signal
analyser cost very little, and you get what you pay for.
I have not yet wrapped my head around how to create ADEV plots, so thanks
for your work on that - it's interesting to see that (presumed) initial
thermal effect.
Over 8 days this results in a cumulative sampling error of 105 seconds. If
your decoding algorithms are relative instead of absolute this won't be a
problem. OTOH, you may be able to use your decoding process to detect this
drift and then compensate for it in software. You have the beginnings of a
MSF-Disciplined-Oscillator project.
MSF disciplined oscillator?! I don't trust these receivers to any better
than about the 20ms mark, so such a disciplined oscillator would have quite
a long integration time!
Once upon a time, that was how people did disciplined oscillators. Part of the
answer to “how?” is that their target accuracies were not as tight as what we now
think of as normal.
Bob
Thanks again.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
In message CAGJ4F+697SyXwm3yWG-XczN4zF7r2RAmXzAcEm=dhaqBJc_NNw@mail.gmail.com, "Deirdre O'Byrne" writes:
MSF disciplined oscillator?! I don't trust these receivers to any better
than about the 20ms mark, so such a disciplined oscillator would have quite
a long integration time!
It's actually more complicated and better than that.
The low-pass filter dominates, so the falling flank at second N
depends on the pulsewidth at second N-1.
I can't remember the numbers I got when I "sorted" DCF77 pulses depending
on the previous pulse being short or long, but it was a fair bit better
than 20ms.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Challenge accepted! And I thought this project was over :)
My gnuplot skills are quite poor, but the two attached files tell a story.
Yes there is a correlation between the length of the second and the
"lateness" of the second pulse relative to UTC. BUT - the correlation is
different between the two receivers.
So one would have to characterise the receiver you were using.
D.
[image: Inline images 2][image: Inline images 1]
On 7 February 2018 at 07:13, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message <CAGJ4F+697SyXwm3yWG-XczN4zF7r2RAmXzAcEm=dhaqBJc_
NNw@mail.gmail.com>, "Deirdre O'Byrne" writes:
MSF disciplined oscillator?! I don't trust these receivers to any better
than about the 20ms mark, so such a disciplined oscillator would have
quite
a long integration time!
It's actually more complicated and better than that.
The low-pass filter dominates, so the falling flank at second N
depends on the pulsewidth at second N-1.
I can't remember the numbers I got when I "sorted" DCF77 pulses depending
on the previous pulse being short or long, but it was a fair bit better
than 20ms.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
I've updated my paper, which now contains the attached graph. (I did a
linear regression analysis to see what the correction for the receivers
should be, and I applied receiver 2's correction to both receivers to
generate this graph).
So maybe a very cheap MSF disciplined oscillator might just work!? :o
[image: Inline images 1]
On 7 February 2018 at 12:53, Deirdre O'Byrne deirdre.dub@gmail.com wrote:
Challenge accepted! And I thought this project was over :)
My gnuplot skills are quite poor, but the two attached files tell a story.
Yes there is a correlation between the length of the second and the
"lateness" of the second pulse relative to UTC. BUT - the correlation is
different between the two receivers.
So one would have to characterise the receiver you were using.
D.
[image: Inline images 2][image: Inline images 1]
On 7 February 2018 at 07:13, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message <CAGJ4F+697SyXwm3yWG-XczN4zF7r2RAmXzAcEm=dhaqBJc_NNw@mail.
gmail.com>, "Deirdre O'Byrne" writes:
MSF disciplined oscillator?! I don't trust these receivers to any better
than about the 20ms mark, so such a disciplined oscillator would have
quite
a long integration time!
It's actually more complicated and better than that.
The low-pass filter dominates, so the falling flank at second N
depends on the pulsewidth at second N-1.
I can't remember the numbers I got when I "sorted" DCF77 pulses depending
on the previous pulse being short or long, but it was a fair bit better
than 20ms.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
incompetence.
