[time-nuts] WWVB Measurements using DSP recovery

paul swed paulswedb at gmail.com
Tue Mar 29 13:57:45 UTC 2011


Now you see I like these up to date solutions with cheap components. I
recently home brewed "YAGPSDO"  yet another GPSDO, just to see how its done.
When I look at things like a frontend  and maybe a mixer thats easy stuff.
Even adding a nice A/D converter etc is easy if you can solder the darn
things.
What gets tricky is indeed the programming of the processor. I would have to
say on the GPSDO its really not much more then a single loop pid with just a
drop of smarts.
So back to this.
I have read the high level comments. But can we get deeper detail. Can it be
done lets say in basic language etc. The comment I read that struck a cord
was that all you did was sample and put the information in roughly 1000
bins. Then I assume look for the bin with the most counts and called that
center frequency. Perhaps plotting that number out.
Is that really it??? Sure various filtering could also be done.
But if the above scenario were correct for me at least it gets interesting
and do-able.
By the way for definition my interest is indeed an alternate comparison
method to GPS. Kind of a second reference since we lost loran.

Having just wrapped up my project with VE2ZAZ for the HP3586 DSS its time to
move on to the tracor 599 and wwvb.
Regards
Paul

On Tue, Mar 29, 2011 at 2:54 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <4D9129D8.4060609 at comcast.net>, Greg Broburg writes:
>
> >Can you show a circuit of what you have done?
>
> Basically I have a 20MSPS PCI card in a PC and do it all in
> software.
>
> I did use similar principles to implement a LORAN-C receiver
> in a aduc7216 (http://phk.freebsd.dk/AducLoran/) but that is
> passe for US people now.
>
> >Would you recommend the 7200 again or something
> >else that is better suited?
>
> The most user friendly way to do it, would be to have a small FPGA
> which takes data from the ADC and averages it into a small piece
> of multiplext or dual port RAM, and a microcontroller (ARM ?) on
> the other port, doing all the high level stuff.
>
> That way there is no real-time component to deal with in the
> programming, and anybody should be able to play with the code.
>
> The alternative is to use a DSP to read the ADC, do the
> averaging and perform the high level functions.  That would
> be a lot harder to program for most people.
>
> The ADC could be 16 bits, and run directly from a house standard
> of 5 or 10 MHz (looks like that would cost $4 from analog.com, isn't
> this future amazing ?)
>
> Add a high resolution DAC for steering OCXO's and a serial port
> or USB interface and we're done...
>
> --
> 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