Investigate and resolve the cause for high-sampling rate issues with GPS module.

[nolanholden]

Testing has shown that high sampling rates of the GPS receiver cause the cessation of new fixes (and GPS date, and other data from the satellites). This can be seen by building the project at this commit: https://github.com/nolanholden/payload-level1-rocket/commit/6aa457c37554e53351b3681e5a2015b56ef33ba2

For example:

Opening port
Port open
VMDPV_1|1_VMDPV
Setup complete. . .

sats  hdop     lat          long    fix-age   date      time   (... and friends ...)
9    ,89   ,38.218971  ,-85.753220  ,0    ,07/05/2017,19:04:05,1097 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,720   ,9         ,0        ,
9    ,89   ,38.218971  ,-85.753220  ,513  ,07/05/2017,19:04:05,1610 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,783   ,9         ,1        ,
9    ,89   ,38.218971  ,-85.753220  ,1026 ,07/05/2017,19:04:05,2123 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,846   ,9         ,1        ,
9    ,89   ,38.218971  ,-85.753220  ,1538 ,07/05/2017,19:04:05,2635 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,909   ,9         ,1        ,
9    ,89   ,38.218971  ,-85.753220  ,2051 ,07/05/2017,19:04:05,3148 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,972   ,9         ,1        ,
9    ,89   ,38.218971  ,-85.753220  ,2564 ,07/05/2017,19:04:05,3661 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1035  ,9         ,2        ,
// Above, the "fix age" grew to 2564 milliseconds. (i.e., no new fixes completely arrived for 2.5 seconds)
// This is absolutely unacceptable. 
9    ,89   ,38.218971  ,-85.753220  ,1    ,07/05/2017,19:04:09,4174 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1098  ,10        ,2        ,
9    ,89   ,38.218971  ,-85.753220  ,513  ,07/05/2017,19:04:09,4686 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1161  ,10        ,3        ,
9    ,89   ,38.218971  ,-85.753220  ,1026 ,07/05/2017,19:04:09,5199 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1224  ,10        ,4        ,
9    ,89   ,38.218971  ,-85.753220  ,1539 ,07/05/2017,19:04:09,5712 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1287  ,10        ,4        ,
9    ,89   ,38.218971  ,-85.753220  ,2051 ,07/05/2017,19:04:09,6225 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1350  ,10        ,5        ,
9    ,89   ,38.218971  ,-85.753220  ,2564 ,07/05/2017,19:04:09,6737 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1413  ,10        ,5        ,
9    ,89   ,38.218971  ,-85.753220  ,3077 ,07/05/2017,19:04:09,7250 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1476  ,10        ,6        ,
9    ,89   ,38.218971  ,-85.753220  ,3590 ,07/05/2017,19:04:09,7763 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1543  ,10        ,6        ,
9    ,89   ,38.218971  ,-85.753220  ,4102 ,07/05/2017,19:04:09,8275 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1606  ,10        ,7        ,
9    ,89   ,38.218971  ,-85.753220  ,4615 ,07/05/2017,19:04:09,8788 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1669  ,10        ,8        ,
9    ,89   ,38.218971  ,-85.753220  ,5128 ,07/05/2017,19:04:09,9301 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1732  ,10        ,9        ,
9    ,89   ,38.218971  ,-85.753220  ,5640 ,07/05/2017,19:04:09,9814 ,153.50 ,261.06 ,0.11  ,W     ,9620     ,92.61  ,E     ,1795  ,10        ,10       ,
// Again, "fix age" grew to 5640 milliseconds.
// Very unacceptable. 

• Is the library in-use the sole cause?
  • If so, how can we mitigate?
• Is is because high sampling rates may cause us to fail to completely read NMEA sentences?
  • If so, can we increase data rate at any bottlenecks?
  • Where are the bottlenecks?

[mikalhart]

Nolan, what baud rate are you generating the output above? Is it possible that the very act of printing out all that data is consuming most of your processor bandwidth?

[mikalhart]

Ah, yes, I see from the commit that you are talking at 9600 baud, which means that the typical line (153 characters) takes about 153 char * (10 bits/char) / 9600 bps = nearly 1/6 of a second just to print the line.

Assuming you are using TinyGPS++, check the .failedChecksum() counter to see if you simply can't keep up.

Some GPS modules allow you to disable NMEA sentences you aren't interested in. I use that feature on our balloon flights.

[nolanholden]

Hi Mikal, I appreciate your input on this. That was my first thought. However, the designer of the prototyping board we were using (Teensy 3.6) comments on this thread, “When using Teensy's USB Serial, the actual baud rate is always 12 Mbit/sec, regardless of what baud rate you configure”. That led me to believe something else was at play. In any case, the serial output may be a significant concern, and further testing like this should probably only output very lightweight information.

[mikalhart]

Hmm.. I'm using a Teensy in my latest project with no problem, but it's only a 1Hz (Ultimate GPS) module. Is yours perhaps 5Hz or 10Hz? It should be easy enough to time how long printing that stuff takes: just display "millis" (or equivalent) before and after.