implemented Power On/Off (UBX-RXM-PMREQ)

[unsurv]

Hey, this is my first pull request hope I did everything right.

I added the ability to power off the GPS device. I worked with this protocol specification.

My initial testing with a Sparkfun SAM-M8Q board and a not that reliable USB power meter showed a current drop of 30mA. Together with the ESP32 deepsleep the reading was at 0.00A This should be validated with a better test setup though. That's also why I haven't added an additional example yet.

Furthermore can you guys have a look at the return statements. I guess I'm comparing to the wrong value or the GPS just doesn't acknowledge a power off command.

I tested with EXINT0 and UARTRX as interrupt pins and it behaved as expected.
As described here activity on some pins wake up the device. Although the I2C pins are not named there, when querying "getLatitude()" or similar extensively via a I2C connection the device seems to wake up too. Can you reproduce this?

Some further testing revealed that when using powerOffWithInterrupt() small voltage edges on presumably the interrupt pin are detected (can't check) and wake the device. I got a good result again when also putting my ESP32 in deepsleep at the same time.

Best

My test code is as folllows and uses an ESP32 WROOM connected via I2C and the INT pin:
GitHub code formatting doesn't like my code... sry :o

simple_ublox_pwr_off.txt

[PaulZC]

Hi @unsurv,
Good work - many thanks for this.
Please let us know when you have an example that demonstrates how to use the new functions and we'll happily merge it.
Please keep the example 'generic' (not specific to any one platform) and please follow the same format as the other examples.
Yes, correct. The PMREQ does not ACK. So you are doing the right thing by checking that is does not NACK.
One thing you might want to think about is what happens if maxWait is set to zero. Does your function still return true then?
Best wishes,
Paul

[unsurv]

You're right about the return value. I added a check for maxWait = 0 and just return a "false" if it is 0. "false" now means "NACK" or "can't tell" but this shouldn't be a problem since if someone specifies 0 ms maxWait he would't care about whether his command has been acknowledged. The other way, as you said, was a problem. Returning "true" while there was no time to check.

[PaulZC]

Hi @unsurv ,
Thanks again for submitting this PR. It is good but needs a few corrections. If you can merge my PR on your fork, then we can get your PR merged here.
unsurv#1
Very best wishes,
Paul