The way the code deals with the GPS/UART is all a bit weird and prone to some issues that then have other fixes.
A PR on git hub covers the serial port/uart FIFO buffer increase to 256 bytes to help fix corrupted gps packets… the bigger buffer is needed as the packets are read when the code gets to it, rather then an IRQ.
A few things to note:
The GPS code will attempt to tell the GPS to only send the packet types it wants. i.e. reduce the need to deal with data not needed… fair enough.
Then it will attempt to put the GPS to sleep (not send any data) and when ready for the next read, enable and read… again no issue with the idea.
But if the time between reads is too short, it will not put the GPS to sleep, allowing it to send data when not needed.
There is a hard coded timer of 5 seconds that will call the GPS “whileActive” function.
In here if the gps is meant to be asleep it will clear anything in the buffer (clearBuffer()
and exit. as it does not care about the data until is due to “care”
IF it does want the data, it will then feed the fifi buffer into tinygps (byte by byte)
once the FIFO is empty it will exit. If it did not get the information it wants, 5seconds later it will try again.
So not lets consider a few things.
the 2 packet types it wants will need about 142 bytes (data depending on gps formatting and supplied data) and the GPS is sending that data every second, so 142 *5 = 710 bytes, so the 5 seconds between reads while have some good full packets will also 100% full the buffer.
(If other packet types where left on, then even more data is dropped and the buffer left full.)
While its hard to home in on the exact cause of the crash, one things I noticed was leaving the GPS updates period at 120 seconds means the GPS is put to sleep and does a few more things as it wakes up, the reduced update period of 10 seconds means the GPS is left running so lots of buffer clears.
In limit testing, it seems that the 120 second beacon period and going to sleep seems more stable.
At the moment, Im still looking at code and adding extra debug outputs trying to see if we can find the exact cause of the “freeze”. I have seen posts around the Pico UART FIFO buffer that indicate that under some condition it could lockup; but it seems more as passing comments, not proven; I was starting to wonder if the FIFO had a memory leak, but that’s Pico microcode, not the application level, and again would need to work out how to test and prove; but we do know we are overflowing the fifo all the time.
A side note re: the discord and/or git hub, there is a 2nd thing that needs to be addressed as well. the way the code is current written, the dont officially support GPIO 0 as valid pin. Pin 0 (index) is used to say “not set” in parts of the code.
So using the default pins 0/1 for the UART0 (which is free on the pico side) while working is not supported. They a have also hardcoded the GPS to be on Serial1 which maps to UART0; so to user UART1 we then need to change the code code as well… as such, I was keen to get to the bottom of the bug rather then ask a question with the answer being “not supported”.
What I am yet to try is moving the UART pins to different free pins (planed for this weekend) and see how it goes.
