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 <[email protected]>wrote: > In message <25AAB11446C04D4897253FDD883547E1@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 > [email protected] | 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 -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
