I’m working on a battery powered GPS datalogger where a microcontroller normally in sleep mode is awaken by the PPS signal, collect GGA-RMC NMEA data at 460800baud (all other NMEA messages are turned off) and then goes back to sleep. My goal is obviously to maximise the sleep time to save battery and to do that I’d like the NMEA messages to come out as soon as possible after the PPS signal. I have the PPS set to 10msec duration (the ON time) and currently I can get the NMEA parsed with 70-80msec, so the microcontroller sleeps for about 900msec in every second which is pretty good, but if there is any more improvement I could make… then why not?
My questions are:
am I at the practical limit (GPS processing power) so I can’t really expect the NMEA to come out any quicker? Changing the position rate (PAIR050) to 100ms/200ms/300ms/400ms doesn’t seem to make much of a difference
Is there a binary format that I can use instead of NMEA to produce smaller messages quicker to process?
Instead of using the PPS signal, could you not just sit there waiting for the NMEA data, parse it when you receive it, and then sleep for the remainder of the period? If you start your timer on the first byte received, and you know how long you took to parse it, then you sleep for the remainder of the period time, and wake up in time for the next reception. It should always remain in sync.
Yes that’s an option, but I need the microcontroller to sleep so in order to wake up I would need to setup an interrupt to the UART. It looks like there is traffic on the UART besides the NMEA sentences that would wake it up more often than needed. The PPS seems the most reliable way to maximize the sleep time on the MCU. If I could get an alternative message to NMEA, like a binary message that is smaller I could make the awake time even smaller.
Is anyone aware of a binary messaging equivalent to the UBX?
Why do you need any external interrupts to wake up the microcontroller? Does it not support a sleep for a specific time period? If so, it could poll for the serial input while awake and after parsing it, put itself to sleep for the remaining period before the next message. It could then wake up just before the next message is expected to arrive, and then repeat the sequence.
There is less precision compared to an interrupt driven wakeup, but it’s simpler and should not matter for your application?
yes, that could work, but adding an interrupt is not difficult at all and with it I don’t really care if there are other delays or if I add other tasks to the ESP32 (saving to SD card), respond to WIFI calls or other user interaction for which the fixed sleep time will have to be adjusted for every possible scenario… with the PPS interrupt I know the MCU will always wake up when needed and I’m not bounded to custom length sleep time…