I work on a project that involves a 9-DOF IMU (MPU9250) and a GPS (SAM-M8Q). I use these sensors to track an RC car. The sensors are plugged to a Nano (I2C for both of them) placed on the car and data is sent to a Uno through RF transmission (nRF24L01), then data comes through Serial port to my computer to be treated in Matlab. I have for that a transmitter program a receiver program.
The update rate of the IMU is 200Hz and 1Hz for the GPS.
My problem is a delay in my data flow that happens just before GPS data come. As you can see in the following pictures, when GPS is not updated I have some “0” in my GPS data containers, and when data is updated I put it in these containers.
I know this delay comes from the functions in the libraries I use (the Ublox library causes a huge delay of around 900ms, the tinygps++/SparkFun_I2C_GPS_Arduino_Library causes a variable delay between 50ms and 150ms). The transmitter program I put here is the one using the tinygps++ library which is the best I have so far.
I tried several layout for my loop (in TR_nano_LT) but I am still stuck with this delay. It is annoying for the IMU data because I need a regular and fast flow. Maybe it is possible to deal with the GPS only when IMU is not sending anything, even if it means having some delay for the GPS?
The other option I have would be to use another microcontroller that would deal only with the gps, but it is really the least sophisticated solution.
RE_uno.ino (5.05 KB)
TR_nano_LT.ino (18.9 KB)
I suspect the 'delay' might be because the GPS is doing what its default setup tells it to do, send out position update sentences about once per second.
You can program the GPS to send out updates more often, see the device datasheet for details, or connect the U-center application up to the GPS to see what its doing.
Yes I began to think about it with the datasheet (p210/386 of the ublox-M8 datasheet, Navigation/Measurement Rate Settings), but what is strange is that the delay is different for different libraries, that is why I suspect the delay to be caused by the architecture of the library itself, and maybe there is something I can change in them to remove this delay?
Actually I realized the delay in the combined libraries TinyGPS++/SparkFun_I2C_GPS_Arduino_Library was in the :
while (myI2CGPS.available()) //available() returns the number of new bytes available from the GPS module
gps.encode(myI2CGPS.read()); //Feed the GPS parser
and for the Ublox library SparkFun_Ublox_Arduino_Library, the delay comes from the following methods:
check out the picture on page 2, and the surrounding text:
the pulse comes first, the data comes at some highly variable later point, the parser takes time to do its thing. the leading edge of the pulse is where the accurate time is found. it's "at the tone, the time was"
you have to use an interrupt driven by the leading edge from the GPS to establish accurate short term timing
Thank you for the advice.
I am not used to manipulate interrupts so first I will do further research about that. It also seems that the NeoGPS library has the possibility to use them, if some people have experience with interrupts in this library I would be very interested.
I found a solution to my problem with the library NeoGPS and the example program NMEA_isr which gives an example of communication with interruption for a GPS: