gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Additional SV flags?


From: Michael J. Tubby B.Sc. MIET
Subject: Re: [gpsd-dev] Additional SV flags?
Date: Tue, 30 Apr 2019 22:17:45 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1


On 30/04/2019 21:27, Gary E. Miller wrote:
Yo A.S.!

On Tue, 30 Apr 2019 15:14:02 -0400
"A.S." <address@hidden> wrote:

Looking into, at least the U-Blox binary protocol, there are some
additional flags/details set in the UBX-NAV-SVINFO message that aren't
making it through GPSd.
Once you start looking you will find many things that different GPS
output that gpsd throws away.

In particular, I'm looking at the "flags" field, of which bits 2 and 3
would be "nice to have" for the Android HAL, as they correspond
directly to the HAS_EPHEMERIS_DATA and HAS_ALMANAC_DATA bits of
GnssSvFlags.
https://source.android.com/reference/hidl/android/hardware/gnss/1.0/IGnssCallback#gnsssvflags
Why would you care?  If the GPS is outputting good time (2D fix), then
it has the Ephemeris already.  Pretty much one directly follows the other.

Some location software on Android displays the value of these flags in
order to give the user an idea about where it is in the process of
getting a location fix. For example;
https://github.com/barbeau/gpstest -- displays flags A, E, U for
Almanac, Ephemeris, and Used.
Since a u-blox 8 goes from cold start to a fix in under about two
minutes, the useful time of that information is short.

The newest GPS, like the u-blox 9, do not even bother to acquire the
Almanac anymore, they go direct to the Ephemeris since they have so many
receive channels.  On the 9 that takes about 6 seconds.

Which is interesting, however without a valid almanac I don't think you know the number of leapseconds between GPS time and UTC.

So as long as long as the Ublox 9 has a valid almanac from a previous use/run you're okay, but first time up you can't compute UTC if you don't have the almanac, since UTC is computed:

    unsigned long utc = gps.week_number * 608400L + (unsigned long)gps.time_of_week - gps.utc_offset + GPS_SYSTEM_OFFSET;

where GPS_SYSTEM_OFFSET is the difference between 1st Jan 1970 and 6th Jan 1980, i.e. 315964800L   

The problem is that gps.utc_offset comes from the almanac message. This is 20+ year old code from a Timble based product of ours but I think the same holds true for all GPS - the UTC offset is only valid when you have a valid almanac?


Mike



NMEA never bothered to report that data.

The "used" flag for each sat is all over the place.  gpsd just uses the
used flag from the skyview sentences.

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

Michael J Tubby B.Sc. (Hons) MIET / Technical Director
Email: address@hidden
Direct: +44 (0)1905 752892
Mobile: +44 (0)7973 225144

Thorcom Systems Limited
Phone: +44 (0)1905 756 700
Address: Unit 4, 96B Blackpole Trading Estate West, Worcester, WR3 8TJ, England, UK
Company registered in England & Wales No. 02704696 / VAT Number GB487925681 / EORI GB487925681000

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Thorcom Systems Limited.
If you are not the intended recipient of this email, you must not take any action based upon its contents or disclose it to any third-party.
Please contact the sender if you believe you have received this email in error.



reply via email to

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