uBlox Dynamic Model Setting?

[darksidelemm]

Maybe I missed something, but I couldn't spot anywhere in your code where you are setting the dynamic model of the uBlox GNSS chipset.
If you don't set this to one of the airborne dynamic models (I recommend Airborne 1G), the GNSS receiver will drop lock at 18km altitude. Not good for a high altitude balloon flight!

I'd also highly recommend using the ublox binary protocol rather than NMEA. There's plenty of examples of using this in other high altitude balloon tracker projects.

[Nevvman18]

I missed that, thanks. Didn't know that the default mode doesn't support higher altitudes. In the free time I will implement that in the firmware.

[Nevvman18]

Published a new release with experimental support for this function. It wasn't tested right now, because I don't have an SDR capable of spoofing the GPS for testing the higher altitudes. We will have to probably wait for a real HAB flight to confirm that it's working. The source code of the function is based on the RS41HUP, so I hope it's alright, becasue as mentioned somewhere else, the new GPS doesn't have a public, complete datasheet.
Again thanks for help!

[darksidelemm]

The protocol specification will match this: https://content.u-blox.com/sites/default/files/u-blox-M10-SPG-5.10_InterfaceDescription_UBX-21035062.pdf

[darksidelemm]

From a brief look over that protocol specification, it looks like the configuration method for the uBlox chipsets has changed significantly with the 10-series chipsets, and the CFG-NAV5 message no longer exists.

You are instead going to have to set the CFG-NAVSPG-DYNMODEL setting (still to a value of 6=AIRBORNE1G), using the UBX-CFG-VALSET command. This is described pretty thoroughly in the protocol specification.

I'd also highly recommend that this value then be polled using the UBX-CFG-VALGET command to ensure it has been set correctly. This means you will need to be able to receive ublox binary data, not just NMEA. The code from RS41ng is probably a suitable starting point for this - the overall message structure is the same, but you would need to add in new message definitions.

[Nevvman18]

I didn't have time to work on it yet (school term etc).
But if the Clive1's data packets seem alright with the GPS docs (I'll check that later), then the implementation of it in the firmware should be rather easy. The current method in the firmware is indeed wrong, because someone here mentioned that the M10 series uses different formats.

[darksidelemm]

Both the code snippets above are still sending the obsolete CFG-NAV5 message, so will not work on the ublox 10.
I've already mentioned the messages you are going to need to send above...

[videobuff]

I deleted my post because darkside is correct - I did not notice that the coding was for version 8 & 9.
I contacted clive and he replied that UBX-CFG-VALSET for RAM is B5 62 06 8A 09 00 00 01 00 00 21 00 11 20 06 F2 4F
And the UBX-CFG-VALGET query is: B5 62 06 8B 08 00 00 00 00 00 21 00 11 20 EB 57

He also modified his repository.

uint8_t ubx_cfg_valset_dyn6[] = { // Series 9 and 10
0xB5,0x62,0x06,0x8A,0x09,0x00, // Header/Command/Size UBX-CFG-VALSET (RAM)
0x00,0x01,0x00,0x00,0x21,0x00,0x11,0x20,0x06, // Payload data (0x20110021 CFG-NAVSPG-DYNMODEL = 6)
0xF2,0x4F };

See also Clive1's repository at # https://github.com/cturvey/RandomNinjaChef/blob/main/uBloxHABceiling.c

[darksidelemm]

Yes, that looks a lot better - it's really important to read back the setting and verify that it's taken effect as well though...

[Nevvman18]

I have finally had enough time to add the Clive's commands for M10 uBlox series to the RS41-NFW code. New release here. For now, there is no reading function of the Dynamic Model setting, because I'll have to investigate how to do it (the VALGET query is helpful so that's what I'll be observing now). Currently, it sends the commands to the GPS twice, as a kind of fail-safe.
We will also have to somehow test it in a real life scenario.

[Nevvman18]

Wrote some simple code that would read the response from the GPS. The problem is that it's not similar to the format like I think it should be, but this will need some thinkering. The good news is that something is changing here because the response after sending the VALSET command is different.

[videobuff]

Franek, worked with the new code in order to understand.

The output I see on my serial port is

Received response: 75 2D 62 6C 6F 78 2E 63 6F 6D 2A 34 45 D A 24 47 4E 54 58 54 2C 30 31 2C 30 31 2C 30 32 2C 48

Clive helped me out because i could not make sense of these codes. He replied that these are the hex codes for portions of NMEA Sentences.

24 47 4E 54 58 54 2C 30 31 2C -> $GNTXT,01,

You'll have to fish through the stream looking for B5 62 06 .. patterns
The response is likely to lag, several hundred milliseconds or more.
Hope it helps.

[Nevvman18]

Thanks, that makes sense now.

[darksidelemm]

Working with mixed NMEA and uBlox binary sentences is always going to be a bit messy... You may be better off just disabling all the NMEA output and working with the uBlox binary data directly.
The driver structure from RS41ng already provides the frameworks for reading in ublox data, though you would probably need to modify the message types a little, as a few have changed with the ublox 10 series.

[Nevvman18]

And thats probably the hardest part, with implementing the binary protocol. I'll look at the responses again, maybe there is a lag somewhere, maybe the code doesn't read everything. We'll see.
I'd like to stay with the NMEA, because of it's ease of use, though if it's really necessary then I'll research on implementing the UBX (either way I didn't see any issues yet with NMEA when using uBlox GPS modules for some time in other tracking projects).

[darksidelemm]

I guess my point here is that you don't need to start from scratch. Other projects have implemented the uBlox protocol, e.g. the RS41ng implementation here: https://github.com/mikaelnousiainen/RS41ng/blob/main/src/drivers/ubxg6010/ubxg6010.c
It has all the state machine for handling incoming bytes, checksumming, etc...
You would need to modify/add some message definitions to support the different configuration approach, and probably update a few of the other message types a little, but it's mostly there.
I find the NAVPVT message quite handy, as it has everything needed for balloon telemetry all in one message: https://github.com/mikaelnousiainen/RS41ng/blob/main/src/drivers/ubxg6010/ubxg6010.c#L26

[zanco]

I flew BZ-nextgen today. The balloon position / altitude appeared to work nicely, 23363 m altitude was burst level and no show of wrong postitions or altitude .

https://grafana.v2.sondehub.org/d/HJgOZLq7k/basic?var-Payload=BZ-NEXTGEN&from=1726993343000&to=now&orgId=1&refresh=1m

[Nevvman18]

I think that the VALGET query won't be as important now, because we can see that the GPS of the new model worked perfectly. I'll try to finally add it in the future, but I'm happy that the VALSET works properly on the new model.

[darksidelemm]

I still think it's important to check that the mode is correct.

On a related note, the uBlox 10-series is a multi-GNSS receiver, though oddly only a maximum of 12 SVs were reported during the flight - I would have expected a higher number than this. I'm wondering if the ublox is outputting NMEA strings from other 'talkers' (e.g. GPNDA vs GPGGA) that TinyGPS might not be interpreting. A dump of serial output from one of these modules would be interesting to look at.
... of course, if you use the ublox binary NAVPVT message this should all be included in there anyway.

[videobuff]

Same story here with an semi indoor location. Max no of satelites is 12

[Nevvman18]

Yeah, but the number of satellites value is dependent on the NMEA messages mentioning GPS constellation, by the TinyGPS++ library. The actual coordinates are calculated on the GPS module using more of them.
Edit: also if I remember correctly, the factory original RS41 firmware doesn't show more than 12 of them, at least when I analyzed some of the flights, the number of GNSS satellites in use was never above 12.

[darksidelemm]

This is why i was asking about what NMEA sentences are actually being sent. Often there is are 'combined' sentences beginning with $GN (e.g. GNGGA) which provide multi-constellation information. It would be valuable to report this information if it exists.

[Nevvman18]

There are combined sentences, but it would be only valuable in the number of visible satellites. It won't make a difference in navigation capabilities, though.

[darksidelemm]

Sure... it would be nice to show though!
It would also give a potential indication in the telemetry of what model RS41 PCB is in use (as the 4x2 PCBs would be limited to GPS only).

[Nevvman18]

Like to send the information about the PCB model (including Horus)?
Also, what do you mean by the RSM4x2 being limited by the GPS? :)

[darksidelemm]

What I mean about the RSM4x2 is that it uses a GPS-only receiver. It's only going to report up to some limited number of SVs, since it only sees the GPS constellation. It seems the maximum number is about 12 (which make sense, thats about as many GPS SVs you can see at once from a given location).

The RSM4x4 series has a multi-GNSS receiver, so the total number of SVs it can see will be higher, as it's seeing GPS+Glonass+Beidou+Galileo. If you report that complete number, it should make it a bit more obvious that the board in use is one of the RSM4x4 series.

[Nevvman18]

Oh I see. Thanks