U-blox NEO-M9N long latency time on I2C

GPS/GNSS
1

I use SparkFun GPS NEO-M9N at 25Hz frequency with ESP32-S2 Thing Plus on I2C.
The GPS module is configure at 25 Hz and I poll it with respect to that frequency.
Then I use the I2C bus to poll other items. But the latency time of the GPS module is so long that the poll frequency of these items is seriously limited.
For the moment, I see that the awaiting time for a GPS polling answer is about 20ms.
Could anyone be able to help me to find some ublox configuration optimization to reduce it, typically to 10ms ?

Thanks

Christian

2

Hi Christian (@Ribinn ),

We need a bit more information before we can offer some suggestions…

Are you using the SparkFun u-blox GNSS library? Or have you written your own code to poll the NEO?

Which messages are you attempting to read, and have you made the messages periodic? (In the SparkFun Library, we call this “auto”.)

Have you disabled any messages you do not need - like the standard NMEA messages?

Best wishes,
Paul

1 Like
3

Hi Paul,
Thank you for your message.

See some elements, part of the code :
Library : #include <SparkFun_u-blox_GNSS_Arduino_Library.h>

SFE_UBLOX_GNSS myGNSS;

// Initialisation du module GNSS (GPS)
if (!myGNSS.begin()) {
Serial.println(“Erreur : GNSS non détecté”);
while (1); // Arrêt si le GNSS n’est pas détecté
}

// Configuration des paramètres GNSS pour accélérer les acquisitions
myGNSS.setUART1Output(0); // DĂ©sactiver la sortie UART
myGNSS.setI2COutput(COM_TYPE_UBX); // Activer les données UBX via I2C
myGNSS.setNavigationFrequency(25); // 25 Hz pour une navigation plus rapide (!!!A optimiser!!!)

}

// 4. Lecture des données GNSS (GPS)
// Ces lectures peuvent être lentes selon la réception du signal satellite
long speedkt = myGNSS.getGroundSpeed();
long Heure = myGNSS.getHour();
long Minute = myGNSS.getMinute();
long Seconde = myGNSS.getSecond();
long Milliseconde = myGNSS.getMillisecond();

Hope this will help you.
Best wishes,
Christian

4

Hi Christian (@Ribinn ),

That is helpful. Thank you.

You are disabling all output on UART1. That is good.

You are only outputting UBX on I2C. That will help.

Ground speed, Hour, Minute, Second, Millisecond all come from the NAV-PVT message. That is good. Only that single message needs to be polled.

My advice is to make the NAV-PVT message periodic, instead of polling. That way, the getPVT will return - quickly - when no new PVT data is available. Please structure your code like Example1_AutoPVT: in setup call myGNSS.setAutoPVT(true); in loop call myGNSS.getPVT(); when myGNSS.getPVT() returns true then read the ground speed/hour/minute etc..

I hope this helps,
Paul

5

Thanks Paul,
We are going to test that with hope that we will not need too long waiting time for such message periodic in order to get them all in successive opened windows.

Anyway, could you tell me if this 20ms latency time looks normal ?
It looks as if the GPS item is loosing time to prepare a lot of different messages for different protocols ?

Regards
Christian

6

Hi Christian,

By default the library requests (polls) each individual message from the GNSS. At 25Hz this can take up to 40ms to complete. This is normal. getPVT will take up to 40ms to return the data.

If you make the messages periodic (“auto”), they are generated by the GNSS every 40ms and placed in the I2C buffer. At 100kHz I2C clock speed, it takes approximately 0.5ms to check how much data is waiting in the I2C buffer. When the 100-byte PVT message is available, it takes approximately 10ms to read all 100 bytes. To summarise, getPVT will return false after 0.5ms if no data is available, and true after 10ms when data is available. You can speed this up by using 400kHz clock speed. The methods like getGroundSpeed will return almost instantly because the data is read from the library.

I hope this helps,
Paul

7

Hi,
Thanks for your message.
I think that the I2C frequency is at 400K :slight_smile:
// Initialisation des capteurs d’angles (I2C)
Wire.begin();
Wire.setClock(400000); // Configuration de la fréquence I2C à 400 kHz (rapide)

Then it would correspond to approximately 2.5 ms, not 20 ms.

Am I wrong ?
Christian

8

Hi Christian,

If the NAV-PVT message is periodic (“auto”) and if I2C is running at 400kHz then:

A NAV-PVT message will be added to the I2C buffer every 40ms (25Hz)
getPVT will take approximately 0.2ms to read the buffer length
If the PVT message is in the buffer, it will take approximately 2.5ms to read all 100 bytes

But only if the PVT message is periodic.

If you have not called myGNSS.setAutoPVT(true);, the library will assume PVT is not periodic and so will: poll (request) the message; and wait for it to arrive. This will take up to 40ms.

I hope this helps,
Paul