polling is slow

[tve]

I'm not very happy with the performance of the library due to the polling mechanism being used. Specifically, when calling getPVT I'm seeing delays of 400ms and up before the GPS responds. It looks to me like it waits until the internal timer driven by NavFrequency fires and it produces a fresh fix. In my app, I can't handle delays that long, so I'm looking for alternatives.

As far as I can tell, the I2C interface is actually nice in that the GPS has a fairly large internal buffer, so if one turns periodic reporting on it can actually buffer things nicely until the arduino comes and polls. But this requires some changes in the library.

The way I would change things around is to allow enabling periodic reports and to store the last one so it can be queried without delay. For this to work I would move the parsing of UBX_NAV_PVT (and possibly other messages) into processUBXpacket and then:

• add setAutoPVT(bool PVT) which enables periodic UBX_NAV_PVT reporting in the GPS
• modify getPVT such that it doesn't send a poll request if periodic reports are enabled and instead returns false if no new report has come in.

The rest of the interface would remain the same. Thoughts?

[nseidle]

I too experienced this. You can't force the module to produce the most recent PVT, it will only respond with a new one. By default, this is created once a second. In the worst case a getPVT will take slightly less than 1000ms because the module in between 1Hz cycles. My solution was to increase the setNavigationFrequency() from 1Hz to 5 or 10Hz depending on my application.

Internal buffer: Agreed, it looks like 4088 bytes (ZED-F9P datasheet page 65, SAM-M8Q page 200).

I like your plan and it sounds like it shouldn't break any current user's code. My only concern is the best way to represent "freshness" of the PVT solution. If I request PVT, I expect it to the be PVT right now. If it's buffered, it's old. Perhaps we expose the time portion of PVT but that's another couple bytes of global RAM I'd like to avoid if possible.

[nseidle]

Excellent solution in PR 4. Thanks!