[time-nuts] Why using HP5370 ext-ref is (maybe) a bad idea

Bob Camp lists at rtty.us
Sat Mar 1 19:06:31 UTC 2014


Hi

They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The amount of adjustment is a function of the solution they derive from the GPS messages. In some cases they do a solution, and correct the *next* edge to that solution. In other chip sets the solution and the edge come out at the same time.

Bob

On Mar 1, 2014, at 2:02 PM, John Seamons <jks at jks.com> wrote:

> 
> On Mar 2, 2014, at 7:05 AM, Pete Lancashire <pete at petelancashire.com> wrote:
> 
>> Idea. On the next go around for the board put the copper down and holes for
>> a couple small daughter cards and any support logic needed to interface
>> with the BBB.
>> The the only additional cost would be limited to the daughter board I/O
>> since my guess it would be SMT hence a bit hard to leave it unpopulated.
> 
> Good idea. Also the Beagle spec allows for multiple, stacked interface boards ('capes' they call them). So for a backwards compatible solution an experimental GPSDO + backup power cape could be interposed between the Beagle and 5370 board. I say experimental because I have no idea if any of the SDGPS projects out there would be ultimately suitable for a DO.
> 
> This brings up a question I have about how the PPS edge is actually derived by a GPS receiver. Does it originally come from the NAV data stream and then get corrected by the (fixed-mode) positioning solution to account for transmission/system delays? I know about the issue of alignment with the VCTCXO clock, but I'm talking about upstream of that.
> 
> _______________________________________________
> 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_lists.febo.com mailing list