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 <j...@jks.com> wrote:
>
> On Mar 2, 2014, at 7:05 AM, Pete Lancashire <p...@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@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.
