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

[Magnus Danielson]

Hi,

Internally you typically run a 1 ms frame on everything. You integrate a 
cycle of C/A code on each channel, sample state on all channels with the 
1 ms clock and the solution will disclose the time-error of that 1 ms 
clock so knowing how a 1 PPS relates to the 1 ms clock is fairly 
trivial. The resolution will naturally be that of the core-clock, and 
ones the delay for the right 1 ms frame has been setup, the PPS error 
compared to the solution is known and you can calculate the "sawtooth" 
if you care about it.

PPS as such is not in the GPS signal, rather all the time-info you need 
to create it.

Cheers,
Magnus

On 01/03/14 20:06, Bob Camp wrote:
> 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.
>
> _______________________________________________
> 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.
>