[time-nuts] Z3801A Problem
Ed Palmer
ed_palmer at sasktel.net
Tue Nov 6 19:59:59 UTC 2012
When I look at the data that the VP is sending to the Z3801A, all I see
are the Ba, Bb, and Bn commands. I don't know if any of those have
enough low level information to play with.
But if this is a firmware issue, shouldn't there be lots of Z3801As with
this problem? I suspect that there's a fault with my unit, but I can't
imagine what. I've got good signal levels. The SYST:STAT command shows
levels of > 200 on a 1-255 scale for some satellites.
Ed
On 11/6/2012 12:41 PM, Bob Camp wrote:
> Hi
>
> At least some of the Motorola receivers passed across per satellite timing
> information. That would allow you to play with what you used or didn't use
> in the firmware.
>
> Bob
>
> -----Original Message-----
> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
> Behalf Of Hal Murray
> Sent: Tuesday, November 06, 2012 1:15 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Z3801A Problem
>
>
> lists at rtty.us said:
>> If the firmware is fine tuning something, (like s/n or elevation) that
> would
>> explain the first issue. If it's something like s/n where they may be
>> averaging values, then a single bad packet *could* mess up their averaging
>> and "turn it all off".
> What can the firmware do if it decides that it doesn't like a satellite?
> The
> GPS receiver does the math and sends over the PPS. How would the firmware
> adjust that calculation to not use a particular satellite?
>
> You can set the elevation mask angle. I don't see a way to set a S/N
> filter.
> (I assume the mask angle gets passed to the GPS receiver.)
>
> You can tell it to ignore specific satellites. I assume that list gets
> passed to the receiver. The firmware might be able to use that mechanism
> for
> S/N filtering, but the timing seems wrong. If the S/N for a sat is too low,
>
> the firmware would have to ignore the data for that second, tell the
> receiver
> to ignore that sat, and hope the data for the next second is good.
>
> It might work if S/N only changes slowly, but I don't think that's the case
> for things like multipath.
>
>
>
More information about the Time-nuts_lists.febo.com
mailing list