[time-nuts] Building a GPSDO & trouble using Jupiter-T
azelio.boriani at screen.it
Wed Feb 1 09:08:28 UTC 2012
Try this link www.serc.iisc.ernet.in/graduation-theses/babu_09.pdf
On Wed, Feb 1, 2012 at 1:44 AM, Magnus Danielson <magnus at rubidium.dyndns.org
> On 01/02/12 01:29, Chris Albertson wrote:
>> On Mon, Jan 30, 2012 at 6:17 PM, Didier Juges<shalimr9 at gmail.com> wrote:
>>> You have to spend good money to get a GPS receiver capable of calculating
>>> it's time and/or position more than once per second. I am not aware of
>>> being done for timing applications, but it is available for navigation
>>> receivers, such as those used to track race cars (for a race car, one
>>> second is an eternity). I have seen navigation receivers capable of 10
>>> fixes/second, I am sure there are better ones yet. They cost a lot of
>> I'm pretty sure those GPS recievers that send out more frequent data,
>> at say 2Hz or 5Hz are just interpolating. It is not more accurate.
>> The GPS sats only send a frame once over 6 seconds.
>> They send at higher rate so that the system using the GPS does not
>> need to know how to dead reckon and can have decent results for simply
>> using last reported position
> The frames does not relate to the rate of raw-data or solutions. You could
> track every 1 ms, as it would align with the rate of a full C/A code cycle.
> Typically these are integrated into complete sub-code symbols, of 20 ms or
> 50 bauds, so it is not unfair to see that rate of raw-data. The solution
> can be run as often if CPU time for all the calculations are there. The
> ephemeris data is designed such that it doesn't need to change often and is
> re-transmitted regularly, so those bits isn't immediately used for
> navigation solution by necessity. Their phase is however important.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/**
> and follow the instructions there.
More information about the time-nuts