Updated setVal, added 'multi' setVal and an Example (supersedes #28)

[PaulZC]

Added 8- and 32-bit versions of setVal. See Issue #21 for details.
Added 8-, 16- and 32-bit versions of newCfgValset, addCfgValset and sendCfgValset to provide multiSetVal support. See Issue #20 and #23 for details.
Included an example showing how to use the new functions.
This PR supersedes #28.

[vispell]

Thank you for coding # 25 commit.
As a beginner, I struggled two weeks ago to fix the library.
But I didn't fully understand what I changed.
This pull request deepened my understanding. Thank you.

[PaulZC]

@nseidle
Hi Nathan,
Any chance we can merge this PR?
Many thanks,
Paul

[nseidle]

Hi Paul - My apologies. I only have GPS antenna setup at home so I can only work on this lib at night (GPS doesn't like to work through concrete and steel).

I'm very hesitant to include as your changes increase the RAM footprint from 64 bytes to 768. This comes very close to making this library non-Uno compatible. Is there anything we can do to decrease the RAM usage? Do you really need to store all 768 bytes or could we get sneaky?

As an aside, I can't get your example 10 (thank you for including it) to run on Artemis. Such is the life of cross platform library writing. I'll need to fix this before a release.

[PaulZC]

Hi Nathan,

Don't worry! Concrete and steel, yes I know that feeling. Hence my GNSS and Iridium antenna farm on top of our study roof at home...

The 768 MAX_PAYLOAD_SIZE is very much a worst case (of 64 key and maximum length value pairs). 64 or 128 bytes should meet the needs of most people. Since you've wrapped the MAX_PAYLOAD_SIZE in an #ifndef the user can always define a larger payload size if required for very long multi-SetVal messages. So, I have no problem going with 64 or 128. I'm happy to amend as required.

It looks like the Artemis is getting confused by NAV-PVT messages? You are sending a Class 0x06 ID 0x8A UBX-CFG-VALSET message to set the high precision mode (CFG-NMEA-HIGHPREC 0x10930006) and that gets acknowledged OK with a Class 0x05 ID 0x01 ACK. Then you send a second VALSET message to set the measurement rate (CFG-RATE-MEAS 0x30210001). The code is expecting an ACK (or NACK) but instead receives a Class 0x01 ID 0x07 UBX-NAV-PVT message which causes confusion. The Class 0x05 ID 0x01 ACK comes through about five messages later.

So, I'm guessing you have previously configured the UBX NAV-PVT messages previously and have that setting stored in Battery Backed RAM?

I don't have an Artemis board and so can't easily duplicate what you're seeing. Is there a recommended 'family' of test boards I should test the code on before issuing a PR? If there is, please let me know. Very happy to try it on as many platforms as required...

All the best,

Paul

[nseidle]

Unfortunately I don't know a good way of passing a #define from a sketch to the library. We'd need to do something with the constructor but that would require malloc() which I'm very adverse to do. I plan to reduce MAX_PAYLOAD_SIZE to 128. Let me know if you see this leading to problems.

For my own documentation (and perhaps for others) here was a gotcha I hit:

Commenting out all changes except change measurement rate doesn't work:

It looks like Your payload is different from the payload that Ucenter sends:

Ucenter reports sending

00 01 00 00 01 00 21 30

Your PR reports

0 2 0 0 1 0 21 30

Ah, my bad. This lib defaults to writing settings to BBR and I was reading RAM using Ucenter. Changing to

  setValueSuccess &= myGPS.setVal16(0x30210001, 200, 1); 

correctly sets the RAM value.

Which leads to my main issue...

[nseidle]

I really like this addition and am ready to pull in your branch. I'm trying to verify that the layers get set correctly. Ah, found it. newCfgValset8() is responsible for the layer setting. Very good. Pulling in PR shortly.