[GPS_Standard] VE2ZAZ

[Bert, VE2ZAZ]

Hi Bob,

I don't know what kind of OCXO you are using. But it is not uncommon to 
see a OCXO re-trace period of a week or more. This means that the OCXO 
drifts significantly more than what you would expect, and then 
eventually stabilizes. I have seen it on good HP OCXOs. What model of 
OCXO are you using?

Dave,

The system performance you are describing (1/30th to 1/300th of a 
second) appears to fall short of what most see. you should get better 
than 1x10e-9, with the mid to low 10e-10's a more common place. I don't 
know if you meant that your S sampling period is between 8 and 16 
minutes, but this is likely too short. An hour to a couple of hours is 
more common on this type of system. Of course, the stability of your 
OCXO may force you to go with shorter sampling period...

Thanks and 73,

Bert, VE2ZAZ
http://ve2zaz.net


Dave Platt wrote:
> Bob Bownes wrote:
>> Finished up my GPS standard over the weekend. Still struggling with
>> getting it to lock and stay locked however. It seems to think the
>> oscillator is drifting quite a bit with temperature, however, my
>> counters seem to indicate otherwise.
>>
>> Not quite sure where to go from here.
> 
> Some additional data would be helpful, I think.
> 
> *  What make/model of GPS are you using?
> 
> *  How good a lock on your location does it have?  Is it in
>    "position hold" mode, or is it trying to track a (presumably
>    moving) receiver location?
> 
> *  What are your FLL parameters?
> 
> For what it's worth - I fired up my own standard about six
> weeks ago (after several years of procrastination in building
> it).  It's not done yet, but I've got "first light" on the
> build, with the ability to achieve a lock and some initial
> statistics and evaluation of its behavior.  I've noted several
> things:
> 
> *  Achieving an initial lock is a bit of a mixed bag.  With the
>    FLL set to a relatively short averaging period (e.g. 8 or 10
>    cycles) and a relatively low unlock threshold, it indicated
>    "lock achieved" within a few minutes, but then continued to
>    adjust in the same direction after almost every averaging
>    period for quite some time... it took a day or so to reach
>    the point at which it was either not adjusting, or was
>    "dithering" between + and - adjustments fairly consistently.
> 
> *  With the FLL parameters adjusted for "OK, we're just about
>    there" operation (8- or 16-minute averaging period, different
>    thresholds) the system does tend to make a fine adjustment every
>    few periods, apparently in response to temperature shift (I can
>    see a regular daily cycle).  From what I can see of the amount of
>    frequency-count error which triggers these changes, the frequency
>    error wouldn't show up on any of my counters.  I did compare the
>    system with a friend's rubidium standard, and the disagreement
>    seems to be between 1/30 Hz at worst and about 1/300 Hz at best.
> 
> *  I'd love to see some "adaptive parameter adjustment" logic added
>    to the controller firmware, so that it could (e.g.) increase the
>    averaging period dynamically when the system is stable, and reduce
>    it (or adjust the control voltage with finer resolution other than
>    just coarse/fine) when the system is drifting or off frequency.
>    Perhaps some sort of proportional-integral (P-I) control logic
>    could be used?
> 
> ______________________________________________________________
> GPS_Standard mailing list
> Home: http://mailman.qth.net/mailman/listinfo/gps_standard
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:GPS_Standard at mailman.qth.net
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> 
>