[time-nuts] WWVB Measurements using DSP recovery

[J. Forster]

Even if you can build a perfect receiver I don't see how you can get
around the variable path length issue short of averaging WWVB for days or
weeks.

-John

================


> 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.
>>
> _______________________________________________
> 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.
>
>