[time-nuts] Z3801A Problem

[Ed Palmer]

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.
>
>
>