[time-nuts] Alternative WWVB Spectracom solution

paul swed paulswedb at gmail.com
Sat Jun 15 09:37:11 EDT 2013


Tom,
Yes indeed thats what the phase flipper components are all about (Though
simply not added) to the d-psk-r. Essentially the costas loop gives you the
1 and 0 and then you flip an invert or non invert amp. That allows any rcvr
to work. You can soft limit to improve the signal for the traditional phase
tracking rcvrs. As mentioned no matter what you do you still need the TRF
front end or to hack into the classic rcvr to obtain the carrier and
data.The goal of the TRF section of the d-psk-r was to give me that
information.

So all of that said I am indeed very interested digital approaches. I think
there are many to explore. The first approach I would take is simple watch
the carrier from a non locked reference sampled at a high enough rate and
look for two items. The phase flip gap 0 signal due to the filter and then
measure the some additional carrier crossings to confirm the flip. Then
flip the flipper if indeed it had changed state. Dumb and perhaps simple.
Predictive behavior is even more attractive. But agree with the comment
that you can home brew the code and then do not need the external reference.

But as I mentioned I did read the spec and for me at least the gotcha was
the FEC correction and the rest of the message. Perhaps as I get out from
under the d-psk-r and really focus it will make sense.

Or a far far better suggestion.
There are very smart people on this list. Just perhaps someone could create
the NIST WWVB PSK message for dummies cookbook. I for one would read it.
But it has to be for dummies. Seriously. My focus would then be to code
elements and experiment. But as an example the FEC code process needs to be
clear and not at a high level. add subtract mult div.... Ummm really good
at basic by the way especially when the micro its on runs at 75 Mhz and
they are cheap so use a few. Others will have to approach the FPGA that
will always show up in the discussion.
Regards
Paul.


On Sat, Jun 15, 2013 at 5:06 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <25AAB11446C04D4897253FDD883547E1 at pc52>, "Tom Van Baak" writes:
>
> >It would be a good project for a RPi (running an NTP client) or
> >an Arduino (using a cheap GPS NMEA+1PPS receiver). If you can spot
> >holes in the design let me know. It seems too simple to be true.
>
> NTP shouldn't be needed:  The computer could simply decode the new WWVB
> signal and use the decoded bits to predict what the future bits will be.
>
> If you use a technique similar to the "disprove" method I used for
> DCF77 in NTPns, you will get very fast convergence, even if you don't
> know all the individual bits yet.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>


More information about the time-nuts mailing list