L76 I2C partial read

IoT Modules GNSS Module
1

We are currently looking to integrate the L76 in our hardware, however as this is on a system with tight timings we were wondering if it is possible to do a partial read of the I2C data. The Application Note on I2C communication only shows full packets of 255 bytes. To save on polling time I was thinking of reading 2 bytes from the buffer, and if these are not both 0A I would read more data.

Would this scheme work or will this result in missed data?

2

Hi,
It is not recommended to adopt this scheme, there may be certain risks. Please follow the application note.

Best Regards

3

Thanks for the quick response. In that case we would need to make sure to only read when we can be sure there is data available. I noticed the 255 PMTK_SET_SYNC_PPS_NMEA to presumably ensure that the NMEA would be transmitted shortly after the PPS signal. If we use the PPS signal as the trigger (with maybe a small delay) to read out the data would that work?

With an NMEA output interval of 1, and a POS Fix of 10000, and the PPS CONFIG on 4 (Always)

4

Hi,
The solution you proposed is a good idea.
This method is theoretically possible, but we have only tested the UART (through PMTK255 enable or disable fixed NMEA output time in PPS function). Maybe you can try it…
It should be noted that the use of this function requires valid fix.

Best Regards

5

If we use $PQ1PPS,W,4,100*1D to set the PPS to be always enabled we shouldn’t require a valid fix? I guess we could always wait like 100-200ms after the PPS before reading the data.

6

No, in the actual test, only after getting a valid fix, the delay of PPS and NMEA is within a fixed range (465 ms~485ms), otherwise it is an uncertain value.

7

Is there any other way to check if there is data available on the I2C? And how bad is it if very rarely we would read the message only partially or not at all in one round (if the output is drifting in comparison to the I2C read)?

We only have the --RMC and --GGA messages enabled so buffer overflows shouldn’t happen and as long as the RMC does not have it’s valid flag set to A we would discard all the messages anyway.

I guess we will have to do some testing once we have the hardware to see how things go.

I see however that it is possible for just the time to be synchronized before the location is known. You mention that the device requires a fix before the PPS and NMEA are set to a fixed time offset, is this a full fix where the GPS position is known (2d/3d fix?) or is this already from when the time is synchronized?

8

Hi,
This feature need a full fix where the GPS position is known (2d/3d fix).
And I still recommend to follow the Application Note solution.

Best Regards