drivers: gnss: add a generic NMEA GNSS driver

[fabiobaltieri]

Minimal generic NMEA based UART GNSS driver, basically the Quectel driver without any specific stuff or power management. Prob worth adding PM at a later stage, a sleep pin + regulator or something, but let's start minimal for now.

Tested against an Antenova M10578-A3 and a random ebay ublox counterfeit module.

[fabiobaltieri]

there, selfie review, I would nack and request changes if I could

[fabiobaltieri]

Skimmed it down a bit more and tested again, added a build_all test as well. Should be good enough for a start.

[cfriedt]

Some nits, but would be magical even without magic numbers ✨

[bjarki-trackunit]

Two small changes an we are good to go! I tested the driver on a Quectel L76LB as well, worked immediately :)

[fabiobaltieri]

Update:

• moved few magics (✨) in defines and Kconfig
• fixed the native_sim and maintainer path
• also realized that few buffers were using ARRAY_SIZE, switched to sizeof, I think that would be correct one since that's used as bytes
• moved the delimiters on a file wide variable, this allowed dropping the initializer from the data structure which should save few bytes, could not make it const though, I think there's few fields in struct modem_chat_config that could use a const and then we could tweak some drivers to save some RAM

[fabiobaltieri]

I tweaked the default nmea-timeout-ms up to 500, this is a sneaky one to get right, we could use a dedicated debugging option and some strategic debug print. Or maybe just a well placed warning if sentences are dropped continuously. Basically what I bumped into was that everything was working, then I disabled satellite support, that dropped the handler for GSV which sent the timing off and caused it to not work until I tweaked it up again.

[bjarki-trackunit]

In the Quectel driver, I could use proprietary NMEA commands to disable GSV and anything else I was not listening for to have a constant timeout, of course this can not be done for the generic one :)

One more nit though

[bjarki-trackunit]

500ms :)

[fabiobaltieri]

Fixed. Do you think it would be possible to have the driver measure few messages and tweak this automatically?

[bjarki-trackunit]

I think so, if we track the max delta between messages we are listening to, then we could set the timeout to half that delta.

0.10s RMC
0.15s GGA +0.05s
0.35s GSV +0.20s
0.36s GSV +0.01s
0.37s GSV +0.01s
0.38s GSV +0.01s
0.39s GSV +0.01s
1.00s RMC +0.61s

Max delta / 2 = 305ms

0.10s RMC
0.15s GGA +0.05s
0.35s GSV +0.20s
0.36s GSV +0.01s
0.37s GSV +0.01s
0.38s GSV +0.01s
0.39s GSV +0.01s
10.00s RMC +9.61s

Max delta / 2 = 4805ms

We can use RMC to recalculate the automatic delta calculation, to handle the user changing the fix rate. The first 1 to 2 data points would be discarded since the delta is not known

[bjarki-trackunit]

Now that I'm looking at it, it can just be fix rate / 2 :D

[fabiobaltieri]

but then if the link is slow enough (guess 4800 is still common on these) then a transmission I think could use well over 50% of the uart bandwidth and get close to the 1s fix. Maybe it could use like 90% fix rate and then reset once the message is published?

[bjarki-trackunit]

The issue is the order, we don't know which message comes first, RMC, GGA or GSV, if we don't get the timing right, we could be publishing an RMC message which contains data which does not reflect GGA or GSV. The timeout is for re-synchronization, so we know when to publish

[bjarki-trackunit]

If we knew which came first, we could forego the timeout completely

[fabiobaltieri]

Ok but then it sounds like the timeout option would only be usable on fast channels, if more than 50% of the uart time is utilized you'd end up never timing out and always reporting one of the two out of sync I imagine. But then the only solution would be to manually specify which one comes first... wondering how gps handles that.

[cfriedt]

Could always convert to Kconfig, but not blocking