|
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#gnsssvflagsWhy 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 Thorcom Systems Limited 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. |
[Prev in Thread] | Current Thread | [Next in Thread] |