Fix uBlox M10 GPS doesn't sleep if device is switched off

[janveeh]

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:

1. CFG-PM-OPERATEMODE set to PSMOO, to enable external control through pin
2. CFG-PM-EXTINTBACKUP set to true, to enable backup mode (deep sleep) if EXTPIN is low.

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 manual

The configuration stream was generated with the UBlox u-center2 utility

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

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.

---

Jan Veeh seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[GPSFan]

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.

[janveeh]

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.

[GPSFan]

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.

[janveeh]

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

[GPSFan]

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.