Closed craft4tnt closed 2 weeks ago
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
Sounds good for new boards that will use the M9, M10, or F10. What about designs that don't have a GPS_EN pin? What about designs that use M8 or earlier? You should also update your repo to be in sync with the latest master, as it is 42 commits behind.
Fixing that sleep issue without the GPS_EN signal would require some major refactoring of the ublox M10 GPS power management and many changes how GPS position updates are requested by the microcontroller. As far as I know, there are barely any devices which use the M10, so new designs should consider that when they want to optimize on battery life. The code I modfied is specific to the M10, so older models are not affected by the changes. Whether they suffer from the same issue I couldn't test because I only have M10Q receivers available.
Do you know of any devices that use, or will use the M10? I have several M10s as well as M9/F9/F10s that I use in other contexts. None of the M10s I got off Amazon/AliExpress have the EXTINT pin exposed, so for DIY projects, this change might have issues. It is critical that the GPS be put into the lowest power mode during Deep Sleep, so this is an important feature to implement, that goes for all GPSs not just u-blox (few have programmatic power save modes, some have "standby" pins) Also managing the active antenna power is also important, few of the current designs properly switch the RF VCC.
I don't know any apart from one I developed with a colleague which will soon be added to the device list. If the EXTIN pin is not connected, it doesn't effect the normal operation of the M10 module. The change is only relevant if the meshtastic device is powered off (microcontroller put in deepsleep). It will still enter the same sleep mode in between periodic position updates by using PMREQ commands. The newly added features of the M10 in PM-CFG such as periodic low power tracking (PSMCT) have no effects as long as power control over PMREQ commands is used. I might check the sleep behaviour of other GPS modules in the future and check if there is room for optimization
I have some concerns that other u-blox generations need to be supported in insuring that the GPS is sent into a low power state when the CPU is put in Deep Sleep, but this is a good beginning, there are very few changes to the mainline code, and affect only the M10. More detailed analysis of the low power modes (during Deep Sleep) for other than u-blox products need to be investigated.
Approved.
This PR fixes #4061
The ublox GPS modules power state is controlled by legacy
UBX-RXM-PMREQ
commands. A defined sleep time and/or a wakeup source (in this case UART_RX activity) is defined in the sleep request message (_message_PMREQ_10 in ubx.h). For an unknown reason, the receiver wakes up/stays awake if the meshtastic device is switched off, even if sleep time is set to 0 (wakeup only by external events).To fix this issue, the existing signal
PIN_GPS_EN
is used to control to the EXTINT pin of the receiver. (PIN_GPS_EN pin needs to be defined in the boards variant.h)This requires only the modification of the M10 specific CFG-PM register.
The important modifications are:
Further explanation is commented in the code ubx.h
The normal operation is not influenced by the register change. All other parameters of CFG-PM were ineffective anyways because the receivers power state was controlled by legacy
UBX-RXM-PMREQ
commands. Further documentation regarding the power modes can be found in the SAM M10Q Integration manualThe configuration stream was generated with the UBlox u-center2 utility