gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] ✘Galileo TITSUP


From: Gary E. Miller
Subject: Re: [gpsd-users] ✘Galileo TITSUP
Date: Tue, 16 Jul 2019 11:11:57 -0700

Yo Mike!

On Tue, 16 Jul 2019 09:16:43 +0100
Mike Tubby <address@hidden> wrote:

> The way that Trimble do 'health of GPS receiver' is interesting and
> may be relevant as there is only one 'good' state and multiple 'not
> good' states:

To a certain extent we are talking apples and oranges.  The 'health'
flag I added comes directly from the GNSS satellite in the ephemeris.
It is turned on and off by the GNSS ground station.  It is basically
mission control telling you when to ignore a particular satellite.

> Current status of receiver:

I think you refer to the Trimble "Report Packet 0x46: Receiver Health".

>      0    Doing position fixes
>      1    Do not have GPS time yet
>      2    (Reserved)
>      3    PDOP is too high
>      8    No usable satellites
>      9    Only 1 usable satellite
>      10    Only 2 usable satellites
>      11    Only 3 usable satellites
>      12    The chosen satellite is unusable - when in 1D (single 
> satellite) mode

What you have is the receiver status, not the satellite status.
It describes the state of the receiver encompassing all its
seen or not seen satellites.  Not the state of individual satellites.

I see no value in this data to the user.  Either he has a fix, or he does
not.  The user can deduce these from DOP and Skyview.  Worse, it is
idiosyncratic to the Trimble.  new variables need to be supportable by
more than one brand.

> In addition to the core 'receiver health' many receivers now are able
> to monitor the antenna for open/short circuit and some receivers also 
> detect and report jamming and/or spoofing.

Yeah, many people have asked for that.  I'm just not sure where to
put it.  My personal experience is that the ant status data is more
often misleading or wrong than helpful.  Plus it requires receiver
configuration that gpsd does not know how to do, that is dependant on
the exact hardware configuration.

> If we're making changes to git head would you consider:
> 
>      typedef  struct {
>          unsigned char health;
>          unsigned char antenna;
>          unsigned char spoofing;
>          unsigned char jamming;
>      } gps_health_t;

Other than the antenna, does anyone really care?  The user should
only care about the error estimates of the fix data.

> where:
> 
>      health:        is receiver health is a enumerated value
> indicating the state of the receiver, for example:
>                              0: Doing position fixes
>                              non-zero values for other states

Which is not even close to the health that I just added.  That name is
just too easy to confuse with the "health' flag in the subframes.  I
just do not see any value here.  If you are getting fixes you do not
need a flag to tell you that.  If you are not getting fixes you need to
move your antenna.

>      antenna:    is the health of the antenna, for example:
>                              0: No fault detected or antenna not
> monitored 1: Short circuit detected
>                              2: Open circuit detected

Which would require user configuration.  Until that is done, this does
nothing.

>      spoofing:    is the state of the spoof detection:
>                              0: No spoofing detected or spoof
> detection not supported
>                              1: Spoofing detected

u-blox has many more sataes to that flag.

>      jamming:    is the state of the jamming detection:
>                              0: No jamming detected or jamming
> detection not supported
>                              1: Jamming detected

u-blox has many more states to that flag.

I do not see Trimble supporting either spoofing or jamming.  U-blox
9 does, but requires configuration that gpsd does not yet support.

> this would regularise everything to be zero for no problem or no
> fault and non-zero for a problem/fault

A bit of an overstatement, but a fair direction.

Before we can decode and pass on such flags, we need a way to configure
the receiver to output that data.  Care to sumbit a patch/MR/procedure
that does that?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

Attachment: pgplGYzqh7qEX.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]