[gpsd-dev] Using multiple location sources to improve accuracy and reliability

[Olivier Cornu]

Hi all,

Every summer holidays i'm lucky enough to spend a few weeks sailing the seven seas. A pretty good opportunity to using and tinkering with gpsd.

A couple years ago, i stumbled upon the infamous multipacket bug while serializing location data from my smartphone to gpsd over bluetooth; This smartphone was the only GPS device on board at the time.

Two summers later, there are now 7 GPS devices on board (4 smartphones and 3 USB dongles). Of course, we never really meant to bring so many: GPS technology has just become ubiquitous in the meantime.

Thus my interest this year has naturally shifted to the way gpsd handles multiple location devices.

What i've seen in the code so far reflects what i experience when i plug 2 GPS devices: what i'd call "basic multiplexing". That is, the client app receives data from both devices, pretty much as they broadcast it.

Typically it means that, plotting my position on a map while moving in a straight line, the boat is shown moving in a saw-teeth pattern, alternatively jumping from one GPS' "trace" to the other's.

Worse: after i plugged the second GPS, my client once received a valid "0°N, 0°E" position at some point (probably as the device acquired a fix for the first time, but i did not fully investigate it). It seems gpsd was perfectly happy with sending my client app two positions thousands of miles away from each other within the same split-second.

I wasn't. This is clearly not what i expected.

What did i expect? Put simply: more than basic multiplexing.

I expected to gain something from device redundancy: either improved accuracy (reduced statistical error using several measures) or improved reliability (if one device starts behaving incorrectly), or both. It seems i get none.

Or, should i say, only the bare minimum in added reliability that multiplexing happens to provide: i.e. if you've got two GPS and one becomes silent, you still get one location source talking.

It seems like there is much more than can be harvested from redundancy of GPS devices; I don't like witnessing wasted resources. ;-)

Besides, accuracy and reliability are not secondary topics or optional features for a software such as gpsd. In critical conditions, they are potential life-savers. At least, i consider they'll become such for me during the coming year.

Such features also appear to belong to gpsd, not clients, nor another proxy layer between them: accurate and reliable location information is precisely what most clients expect from gpsd itself.

Clients that care about underlying devices (and their individual states) can always request extensive raw data. However, i believe most clients only want the best location information you can feed them, no matter how you achieve it nor where it came from. Thus, that should be the default behavior, imho.

Using redundancy in order to provide the best service possible means it is not enough to blindly relay GPS data: gpsd would have to maintain its own unique internal location state, that GPS devices would only contribute to.

Gpsd would have to be more than a transparent hub designed to hide proprietary protocols (and bugs) and broadcast GPS messages to clients. It would have to become a location provider in its own right, actively mangling with raw GPS data for the best.

Practically speaking, what kind of mangling am i talking about?

Simple example: to my knowledge most commercial airplanes use 3 different location sources. They select the middle longitude and middle latitude from these 3 sources in order to compute their position. Doing so makes the overall location a bit more accurate and way more reliable. Of course, possibilities are not limited to this.

In the current architecture, the piece of code updating the internal location state would be run by the multiplexer when new data becomes available from a device (gpsd.c:consume_packets()).

What am i getting wrong so far?

Is there any chance trunk might come this way, or will i have to hack a solution tailored for my use case?

Thanks,

--
Olivier Cornu