Added powerSaveMode (and some minor corrections)

[PaulZC]

Hi Nathan (@nseidle),

Here's a re-submission of the powerSaveMode PR. This supersedes PR #53.

I've based this on a clean fork of the library, so hopefully it should be easy to merge. That said, I did muck up the first commit (850cce0), had to revert it (ead94de), but here it is in all its glory (6364ea4)!

This adds the powerSaveMode function which, as discussed, now includes protocol version checking. It checks that the protocol is less than 27 before it tries to apply the change.

While I was working on this, I corrected a few small gremlins in the getProtocolVersion code:

• maxWait wasn't being passed down from getProtocolVersionHigh (and Low) to getProtocolVersion
• getProtocolVersion was attempting to return versionLow when it should only return a boolean

There is some kind of strange race condition that exists when parsing UBX packets. If we send (poll/get) a packet and the GNSS module returns both a packet and an ACK, the ACK can upset subsequent sends using the same class and ID. The weird thing is that it doesn't happen all the time. enableDebugging changes its behavior. And it is different on I2C compared to Serial.

The solution seems to be that if we know we are going to do another sendCommand quickly, using the same class and ID, then it would be wise to wait and eat the ACK using another waitForResponse (with a short maxWait) in between. Hence me adding lines like this in two places:

// Let's make sure we wait for the ACK too (sendCommand will have returned as soon as the module sent its response)
// This is only required because we are doing two sendCommands in quick succession using the same class and ID
waitForResponse(UBX_CLASS_CFG, UBX_CFG_RXM, 100); // But we'll only wait for 100msec max

I've tested this on the ZOE, NEO, MAX and ZED using both Serial and I2C. As discussed, this will fail on the ZED but at least now does it gracefully.

Enjoy!
Paul

[nseidle]

Looks and works well. I saw a small (33 to 28mA) current change but I think that's because I was operating from a window rather than clear sky so I doubt the SAM-M8Q could really shut down.

I modified your example a bit to add a controllable menu. Makes it easier to toggle back and forth.

Thanks!

[PaulZC]

Thanks Nathan - I really like the changes.
A couple of points just for information:

• The receiver only decreases its current draw once it has finished acquiring satellites. That can be many seconds after it first gets a 3D fix, even with a clear view of the sky. So, you shouldn't be alarmed if you don't see the current fall while the SAM is peeking through a window.
• I have had bad experiences putting the CAM-M8Q into a low power state too early. (The CAM is another member of the M8 family - it has a chip antenna on-board.) It can cause the receiver to spontaneously reset. Which is why, in the example, I waited until we had a 3D fix before enabling powerSaveMode. Now, I think I was also using UBX-CFG-PMS to change the powerSetupValue, possibly to one of the aggressive power saving modes. So maybe I only have myself to blame. But it is something to be aware of. If you see the GNTXT messages appear unexpectedly in the data stream, that's a clue that the receiver has reset. I'll test the example as-is and will let you know if I see anything strange. Worst case, we'll need to put the wait-for-3D-fix bit back in.

Thanks again - and Merry Christmas!
Paul

[PaulZC]

With PR #62 this checks out very nicely. No sign of the receiver doing anything strange.
Thanks again.