Open nolanholden opened 7 years ago
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?
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.
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.
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.
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: