Forum: GNU Radio MSF/DCF/RBU Time Station Receiver Implementation

4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2014-05-15 21:26
(Received via mailing list)
Hi Everyone,

In recent days I had the idea to plug my LF preamp and antenna into my
192k Soundcard. Even with Nyquist being his usual pain, that still gives
me DC to 96kHz. Perfect for certain time stations :)

I lashed up a linear receiver, put it on 59kHz, and what do I hear ?
"pip pip pip" from MSF. Switch to 76.5kHz, and hear DCF's simpler 100ms
and 200ms "pip pip pip". Thought I'd get adventurous and tried 66.666k,
and I hear pips again (not quite the same, more of this later)

I lashed up a quick Goertzel filter at 250Hz, and re-tuned so I was
250Hz off from MSF. Hacked up some code to actually decode the
output of GRC to the timecode bits for MSF. It decodes perfectly,
even without parity checking!

DCF, I haven't quite got around to that bit yet, but it was detecting
the 100mS and 200mS very well, despite the periodic (relatively) wide
band noise that was around last night.

In case anyone is interested, the flow graphs are located at
http://hal.g7iii.net/GRC/Radio_Clocks/

They are in .grc format, and .png Feel free to use them, however be
aware as well as device changes, you will probably have to fiddle with
the threshold and squelch levels, but they might be a useful starting
point for anyone wanting to do a WWV/WWVB/JJY/BPM decoder.


Now, RBU, There's a thing. It is a little more complex, as rather
than just a carrier, it uses two tones. Only each 100mS is divided,
and there are periods of time with an unmodulated carrier, and even
no carrier at all within each 100mS period.

The gory details are located at
http://en.wikipedia.org/wiki/RBU_%28radio_station%29

This is challenging. The best I have come up with is in the RBU
flowgraphs at the same URL using the CTCSS Squelch block (incl
with a Goertzel filter ahead of it), but I get missing 100mS "packets"
[for want of a better term], and even some times when it thinks both
the 100Hz and 312.5Hz tones are active at the same time! (This is most
likely one squelch not closing before the other opens)

Is this the approach other folks would take with trying to decode
RBU ? Or are there other approaches that might work better ? Suggestions
would be welcomed, and if anyone wants a recording of RBU to test
their own code with, just holler.


Iain
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2014-05-15 21:32
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2014-05-15 21:48
(Received via mailing list)
On 15/05/14 20:30, Marcus Leech wrote:

> I worked on a WWVB receiver a few years back.  Then realized that I'm in an
> apparent "null" in the WWVB transmit pattern.  Even
>     my commercial WWVB clocks cannot receive it.  Sigh.

Ah, that's unfortunate, to say the least. And now they've gone and
complicated it even further with the Phase Shift Keying stuff.

I have a similar issue with BBC Radio 4 Longwave here, despite not
being particularly far from the transmitter, it is def weak with me.

Which reminds me. DCF, Radio 4, and TDF (France) also twiddle the phase
of the signal for a more accurate timecode. I have the details of that
twiddling, but am at a bit of a loss as to how I might use the PSK
blocks and friends within GRC to decode them.

(For me, it's moving from the deep end of the pool where I'm very happy
fiddling around, and the deep ocean, so if anyone has any suggestions
on where to start that would also be appreciated.)

My PSK knowledge is entirely from Amateur Radio, although I did manage
to write a PSK receiver in GRC that would receive all the fldigi PSK
modes, but even that was converted from someone else's raw python
flowgraph doing the same thing!)


Iain
D2595f4322a69535ddb92617d17f0eef?d=identicon&s=25 Louis Brown (madengr)
on 2014-05-16 00:30
(Received via mailing list)
Iain Young, G7III wrote
> I lashed up a quick Goertzel filter at 250Hz, and re-tuned so I was
> 250Hz off from MSF. Hacked up some code to actually decode the
> output of GRC to the timecode bits for MSF. It decodes perfectly,
> even without parity checking!

Thank you for the post.  I was experimenting with WWVB reception also
and
will have to try this for NDB DX reception.  What advantage does the
Goertzel filter have as opposed to just using a narrow band FIR?  I see
you
still have to specify the 250 Hz offset in the filter, so I assume it
doesn't help with detection if you drift off frequency.

Thanks,
Lou
KD4HSO





--
View this message in context:
http://gnuradio.4.n7.nabble.com/MSF-DCF-RBU-Time-S...
Sent from the GnuRadio mailing list archive at Nabble.com.
4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2014-05-16 19:30
(Received via mailing list)
Hi Lou,

You Wrote:

On 15/05/14 23:28, madengr wrote:

> doesn't help with detection if you drift off frequency.
I'm not actually sure what advantages if any the Goertzel has over a
narrow-band FIR, although there is a post in the archive from Marcus
suggesting 15% CPU.

It was mainly an arbitrary decision on my part. I had been thinking
about how to detect particular tones some time ago, and discovered the
Goertzel filter. Some of the other reasons why I selected it this
time were:

a) I could be off frequency from DC when looking at complex
waterfalls (I often write my flowgraphs in this way) I guess an
extra Frequency Translating FIR filter could be used

b) I could hear the signal more easily while developing

c) RBU was going to need something like this, and it seemed easier to
start with a single tone (carrier). Not that I'm getting much further
with RBU at the moment...

d) It also essentially decimates. Out of the Goertzel as shown is a
1kHz sample rate (48k/48). For the radio clocks that was more than
sufficient, and meant less data needed to be stuffed down the pipe and
processed at the other end.

(see http://permalink.gmane.org/gmane.comp.gnu.radio.general/7128 for
how it actually works)


You are correct that the Goertzel filter doesn't help you keep lock if
you drift off frequency. It's whole reason for being is to detect a
particular tone.

In being off frequency by the same amount the Goertzel, of course, it
"sees" the carrier as the expected tone, and lights up.


73s

Iain

PS:and with that comment about detection if you drift off frequency,
you now have me thinking if I could re-implement using some kind of PLL.
Gagh, another project, but I need to find some simple examples first
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2014-05-16 19:39
(Received via mailing list)
On 05/16/2014 01:29 PM, Iain Young, G7III wrote:
>
> I'm not actually sure what advantages if any the Goertzel has over a
> narrow-band FIR, although there is a post in the archive from Marcus
> suggesting 15% CPU.
With the advances in VOLK, it would be useful to try the benchmarks
again to see which approach
   is best.


>


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
This topic is locked and can not be replied to.