[IGSSTATION-5386] Re: some receivers misreporting satellite health bits

[Jake Griffiths - NOAA Federal]

Dear Colleagues,

Apologies. My little routine for finding the receiver information
had it's own bug. Thanks to Michael Schmidt (NRCan) for detecting it!
I think I have corrected the problem. The definitive list of receiver
names should be:

LEICA GRX1200+GNSS
LEICA GRX1200GGPRO
LEICA GRX1200PRO
TRIMBLE 4000SSI
TRIMBLE 4700
TRIMBLE NETR8
TRIMBLE NETR9
TRIMBLE NETRS

Thanks for your patience.

I will follow up with the firmware versions later. It will take me
some time to gather that info.

Best,
jake

On 4/24/2013 10:09 AM, Jake Griffiths - NOAA Federal wrote:
> Author: Analysis Center Coordinator
>
> Dear Colleagues,
>
> A scan of the GPS navigation RINEX files at NASA/CDDIS for April 23, 2013
> (yyyy=2013 doy=113) highlights an ongoing issue with several receiver types
> reporting incorrect health bits for PRN30/SVN35. According to NANU 2013022
> (e.g., http://www.navcen.uscg.gov/?Do=gpsShowNanu&num=2013022), this satellite
> was set unusable until further notice (UNUSUFN) on March 28, 2013.
>
> The following receiver types:
>
>    AOA BENCHMARK ACT
>    ASHTECH UZ-12
>    LEICA CRS1000
>    LEICA GRX1200
>    LEICA GRX1200GGPRO
>    LEICA GRX1200PRO
>    TPS E_GGD
>    TRIMBLE 4000SSE
>    TRIMBLE 4700
>    TRIMBLE 5700
>    TRIMBLE NETR5
>    TRIMBLE NETRS
>
> at the following IGS stations:
>
> alic barh brft brmu bzrg cagl cas1 cedu chum coco conz darw dav1 drao hert hnpt
> hob2 holb joz2 joze karr lck2 lcki mate maw1 mobs morp nano nico ohi3 pbr2 pbri
> pdel pert pgc5 rcmn sfer str1 str2 tid1 tow2 wes2 wtzr xmis yar3 yebe
>
> however continue to report PRN30/SVN35 as "healthy".
>
> The main reason to report this is that the navigation files from IGS stations
> are assembled to form the global broadcast file (brdc${ddd}0.${yy}n) at the
> Data Centers. Having some stations misreport the health status causes confusion
> when a user attempts to examine the health bits for the entire constellation
> over an extended period of time. The following table is a nice example:
>
> Summary for the Health Bits for all PRNs ('.'=healthy; '1'=unhealthy)
> -------------------------------------------------------------------------
> wwwwd hh  0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3
>            1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
> -------------------------------------------------------------------------
> 17372 00  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . 1 . .
> 17372 02  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . 1 . .
> 17372 04  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . 1 . .
> 17372 06  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . .
> 17372 08  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . .
> 17372 10  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . .
> 17372 12  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . .
> 17372 14  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . .
> 17372 16  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . . . .
> 17372 18  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . 1 . .
> 17372 20  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . 1 . .
> 17372 22  . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . . 1 . .
> -------------------------------------------------------------------------
> wwwwd hh  0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3
>            1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
> -------------------------------------------------------------------------
>
> Incorrect health bits can also cause issues for software that resamples and
> transforms the broadcast ephemerides into ECEF coordinates.
>
> I suspect the issue arises from a firmware bug or that the receivers need their
> memory flushed. Though, of course, any mitigating action should be taken so as
> to minimize the impacts to users.
>
> FYI,
> jake
>