RFC: GPS parameters & A-GPS

[Baruch Even]

Hi,

I'd like to add some new features to gpsd and would like to discuss them
before I spend time to implement them, I'd like to see if it will be
accepted in gpsd.

My knowledge is about the u-blox 4 GPS which is available in the Neo
Freerunner phone, I didn't yet take a look at other GPSs, maybe others
can chime in how such features are relevant to other models.

The features I'd like to support in the u-blox 4 are:
* Navigation parameters (CFG-NAV2, CFG-SBAS)
* Ephemeris & Almanac download/upload
* A-GPS support

Navigation Parameters
---------------------

The navigation parameters include two key params: Mode & Static
threshold. Mode can be Stationary, Pedestrian, Car, Marine and three
levels of Flight (<1g, <2g & <4g). Static threshold is a value in cm/s
below which the GPS doesn't consider it a movement. The Static threshold
helps to get a cleaner signal when the car is stopped at a red-light
f.ex.

There may be additional parameters but these two are the key, the rest
can be supported as well.

My thinking for the parameters is to have a GPSD api to get all
parameters, this will give us the name and the value and to be able to
set them. We can try to map the parameters appropriate to different GPSs
so that we will have as much in common between them all.


Ephemeris & Almanac download/upload
-----------------------------------

The u-blox 4 allows the user to get periodically the ephemeris & almanac
and to upload it at startup so that if the user restarts the GPS not too
long after he turned it off the GPS can get a hot-start and get a fix
very quickly. This is currently employed in the Freerunner FSO framework
to great success. The logic is simple, get the ephemeris, keep it in
memory, when the gps is turned off save it to disk, when the gps is
started load it back up. Saving it to disk is debatable.

This can be extended to download the data from the u-blox assist online
website just before the user leaves his network connection. This needs
to be triggered from outside.

I've seen a few discussions in the past regarding ephemeris download and
upload but that was in relation to a TCP/IP server, here I'm interested
in the local saving of the data, once we have that it should also be
possible to create an open service that collects such information and
distributes it.

A-GPS
-----

The idea here is part of the one above, A-GPS in this context is to
provide the GPS with a good time and location estimates to start with.
The time can be taken from the system, maybe with an offset if the
system time is found to be wrong.

The location can be estimated externally by different means, in my case
I already implemented a crude service to estimate the location based on
GSM cell data, so that you can get not-too-bad estimate in a second and
feed it to the gps so it will have a chance to get a faster fix. The
accuracy of the GSM location is at worst about 30Km (give or take),
which should be sufficient for the GPS.

In this case we need a way to register an A-GPS provider with gpsd so
that we can register multiple providers (maybe wifi hot-spot based) and
let gpsd use it as needed.


Cheers,
Baruch
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Baruch Even <baruch@...>:
> I'd like to add some new features to gpsd and would like to discuss them
> before I spend time to implement them, I'd like to see if it will be
> accepted in gpsd.

You picked a good time to bring this up. We've just switched to a new,
JSON-based command protocol that is specifically intended to support
extensiuons like those you have in mind.
 
> My knowledge is about the u-blox 4 GPS which is available in the Neo
> Freerunner phone, I didn't yet take a look at other GPSs, maybe others
> can chime in how such features are relevant to other models.
>
> The features I'd like to support in the u-blox 4 are:
> * Navigation parameters (CFG-NAV2, CFG-SBAS)
> * Ephemeris & Almanac download/upload
> * A-GPS support

We're open to these.  I know my chief lieutenant, Chris Kuethe, is
specifically interested in ephemeris/almanac access for SiRFs
and Trimbles.

> Navigation Parameters
> ---------------------
>
> The navigation parameters include two key params: Mode & Static
> threshold. Mode can be Stationary, Pedestrian, Car, Marine and three
> levels of Flight (<1g, <2g & <4g). Static threshold is a value in cm/s
> below which the GPS doesn't consider it a movement. The Static threshold
> helps to get a cleaner signal when the car is stopped at a red-light
> f.ex.
>
> There may be additional parameters but these two are the key, the rest
> can be supported as well.
>
> My thinking for the parameters is to have a GPSD api to get all
> parameters, this will give us the name and the value and to be able to
> set them. We can try to map the parameters appropriate to different GPSs
> so that we will have as much in common between them all.

Yes.  The way to implement this sort of thing would be to add a driver
method for parameter-setting - signature something like this:

void gpsctl(struct gps_device_t *session, int paramtype, bool set, int *value);

There would be an eumerated type or series of #defines for paramtype

#define NAV_MODE 1
#define THRESHOLD 2

etc.  There's at least one other chipset - SiRF - that could support these.
Then we'd add new JSON commands to call the hook.  None of this would be
very difficult, the main issue is actually deciding what the command set
ought to look like.
 

> Ephemeris & Almanac download/upload
> -----------------------------------
>
> The u-blox 4 allows the user to get periodically the ephemeris & almanac
> and to upload it at startup so that if the user restarts the GPS not too
> long after he turned it off the GPS can get a hot-start and get a fix
> very quickly. This is currently employed in the Freerunner FSO framework
> to great success. The logic is simple, get the ephemeris, keep it in
> memory, when the gps is turned off save it to disk, when the gps is
> started load it back up. Saving it to disk is debatable.
>
> This can be extended to download the data from the u-blox assist online
> website just before the user leaves his network connection. This needs
> to be triggered from outside.
>
> I've seen a few discussions in the past regarding ephemeris download and
> upload but that was in relation to a TCP/IP server, here I'm interested
> in the local saving of the data, once we have that it should also be
> possible to create an open service that collects such information and
> distributes it.

Yes.  This should be even easier.  All we'd need to do is initialize
the chip into a mode that emits these periodically, then recognize
those packets coming back up and make them trigger a JSON report to
client sessions.  As before, the major issue is defigning s reasonable
chipset-independent support format.
 

> A-GPS
> -----
>
> The idea here is part of the one above, A-GPS in this context is to
> provide the GPS with a good time and location estimates to start with.
> The time can be taken from the system, maybe with an offset if the
> system time is found to be wrong.
>
> The location can be estimated externally by different means, in my case
> I already implemented a crude service to estimate the location based on
> GSM cell data, so that you can get not-too-bad estimate in a second and
> feed it to the gps so it will have a chance to get a faster fix. The
> accuracy of the GSM location is at worst about 30Km (give or take),
> which should be sufficient for the GPS.
>
> In this case we need a way to register an A-GPS provider with gpsd so
> that we can register multiple providers (maybe wifi hot-spot based) and
> let gpsd use it as needed.

Use it how?  What would trigger a data transfer, and how would it be incodesd?

One easy step we could take would vbe to write a JSON command that would
ship the chip a position and time estimate.  This, again, would require
another standard driver method, but that's OK - sereveral of our
supported chipsets could use it.

If your location service could behave as a gpsd client (e.g., oprn
a client connection and ship it a JSON-encoded estimate) that problem
would be solved.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev