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 > <p...@phk.freebsd.dk>wrote: > >> In message <4d9129d8.4060...@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 >> p...@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.