Added setDynamicModel

[PaulZC]

Hi Nathan (@nseidle),
Here's a PR which adds a new function: setDynamicModel.
(Apologies. This PR also seems to include the changes for PR #50. Clearly I don't yet know how to use branches correctly!)
setDynamicModel uses the UBX-CFG-NAV5 message to set the navigation model settings (dynamic platform model) to: PORTABLE, STATIONARY, PEDESTRIAN, AUTOMOTIVE, SEA, AIRBORNE1g, AIRBORNE2g, AIRBORNE4g, WRIST, or BIKE.
This is essential for M8 receivers launched on high altitude balloons - you'll get very strange position fixes if you don't change the model to AIRBORNE1g.
I've included an example and have tested it on the Qwiic ZOE-M8Q breakout.
Enjoy!
Paul

[nseidle]

Looks good. Couple problems:

• The example doesn't work for me. It compiles, but the change fails.
• You should read the current X2 mask, and change only the dyn bit. Your code would modify any other timeMask, posMask, etc bits.

[nseidle]

Ok, it works, but only after a few tries (resetting board to re-send command). Not sure why?

[PaulZC]

Hi Nathan,
So, I had the same thoughts as you regarding the dyn bit. In fact it woke me up at 4AM and I had to go play with the hardware just to check.
I was testing the code on the ZOE-M8Q and - like you - was suddenly worried that if I set ONLY the dyn bit, would it disable all of the other lovely features linked to the UBX-CFG_NAV5 message?
I was using a Redboard to link the example to a ZOE-M8Q breakout via Qwiic. Meanwhile I also had the ZOE's UART pins connected up via an FTDI cable so I could run u-center simultaneously. I found that using the PR as-is, setting only the dyn bit, produced the desired results. I could check via u-center that the other NAV5 parameters were unaffected. So, my confidence in the PR as-is is high.
The u-blox documentation is ambiguous. The description for the mask field says "Parameters Bitmask. Only the masked parameters will be applied.". I take that to mean that only the fields identified via mask are changed. If you run the example and then poll the NAV5 settings from u-center the mask field still comes back as FFFF not 0001.
Anyway, all of this is moot. I'll change the PR so that it OR's the dyn bit into mask, so all of the other fields will be written back unchanged.
I've got NEO-M8T, MAX-M8Q and ZED-F9P breakouts here, so I'll try all of them and will let you know if I get any unexpected results.
Leave it with me!
All the best,
Paul

[nseidle]

Ah! I re-read the CFG-NAV5 section and agree with you. There's no reading, just set the bit to apply the changes:

So I don't think we need to do a read/mask/set (nor could we).

I'm sure you know this but we can use u-center to inspect the packets it uses to verify anything ambiguous. I would have a look at the packets when we change the dyn model vs the min elevation setting and see what u-center does. But my foot is currently on a bouncy seat and my ZED-F9P is just out of reach...

[nseidle]

I suspect my issue may be that the packet might not be acking, or failing, or something related. I saw failures with your low power PR because I was using the ZED-F9P (which doesn't support low power -CFG-RXM packets) with silent failure. I need to look into how we're handling NACKs.

[PaulZC]

OK - no probs. I'll run some duplicate tests here in the morning and will let you know what I find. Glad you are putting your foot to good use!
All the best,
Paul

[PaulZC]

Hi Nathan (@nseidle),
There is much weirdness going on but I think I am starting to get to the bottom of it...
I've been testing setDynamicModel and powerSaveMode on my breakouts using Serial, and I regularly see both functions fail. I'm only testing the M8 family at the moment (not the ZED).
The function calls fail less if I enableDebugging (which makes me think it is a timing issue linked to something happening too fast - the Debug messages will generally help slow things down).
I think the root cause is something like:

• Both of these functions read (get or poll) some settings from the GNSS, change one value, and then write (set) them back again.
• The write uses the same class and ID as the read.
• The read causes a packet to be returned that contains the settings followed by a separate ACK.
• I think the waitForResponse in the read returns true as soon as it has received the settings packet.
• Then the write sends the modified settings and also does a waitForResponse.
• I think the ACK from the read causes the waitForResponse in the write to return true prematurely and then something bad happens that causes a timeout.

The thing is... setUART1Output or setI2COutput essentially do the same thing but I don't see problems there. Mind you, I don't actually bother checking that those calls return true!
The solution will, I think, involve making sure that the ACK from the read gets trapped correctly before starting the write.
I'll keep digging...
All the best,
Paul

[PaulZC]

Closing this for now until I understand the root cause of the timeout failures. I'll re-submit from a fresh fork.
Bye for now!
Paul