Enhancement request and general queries in the GNSS subsystem

[mayankmahajan-nxp]

@bjarki-trackunit @fabiobaltieri

1. Why are we not parsing time and navigational data in gnss_nmea0183_parse_gga?
2. Is it necessary to enable both GGA and RMC messages on our gnss device?
3. Why data is published only when both GGA and RMC messages are received?

[github-actions[bot]]

Hi @mayankmahajan-nxp! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[bjarki-andreasen]

1. Because we get it in RMC, no need to get it from both :)
2. Yes, although there is overlap, we need speed, bearing and date from RMC, and we need HDOP and number of satellites from GGA
3. Since we need data from both RMC and GGA to fulfill the struct gnss_data, we need to parse both before we publish. We also need to ensure the RMC and GGA are related to the same GNSS fix

@fabiobaltieri Hey, I figured it out! both RMC and GGA contain the same UTC timestamp, so we can use it to ensure they are related to the same fix rather than a timeout :) GSV contains its own index to tie it together (message number and total number of messages)

I will update the NMEA0183 match handlers to use the fix instead of a timeout :)

[fabiobaltieri]

@fabiobaltieri Hey, I figured it out! both RMC and GGA contain the same UTC timestamp, so we can use it to ensure they are related to the same fix rather than a timeout :) GSV contains its own index to tie it together (message number and total number of messages)

Neat!

[mayankmahajan-nxp]

1. Because we get it in RMC, no need to get it from both :)
2. Yes, although there is overlap, we need speed, bearing and date from RMC, and we need HDOP and number of satellites from GGA
3. Since we need data from both RMC and GGA to fulfill the struct gnss_data, we need to parse both before we publish. We also need to ensure the RMC and GGA are related to the same GNSS fix

@fabiobaltieri Hey, I figured it out! both RMC and GGA contain the same UTC timestamp, so we can use it to ensure they are related to the same fix rather than a timeout :) GSV contains its own index to tie it together (message number and total number of messages)

I will update the NMEA0183 match handlers to use the fix instead of a timeout :)

@bjarki-trackunit

1. Thank you for the clarification. I understand now. Although as an end-user of this subsystem, it looks to me that a function called gnss_nmea0183_parse_gga should parse everything in GGA.
2. What if we don't need the details provided by RMC?
3. What if we don't want to fill 'struct gnss_data' completely? What is our motivation behind creating a dependency between gnss_nmea0183_match_gga_callback and gnss_nmea0183_match_rmc_callback.

[bjarki-andreasen]

The GNSS API is not tied directly to the NMEA0183 protocol, which despite being the most used protocol, is not the only one :) See UBX protocol 31.3.2.1 for a message that could replace RMC

We want to get all valuable data a GNSS can produce, where this data exists in whichever protocol is used between modem and host is not relevant. In the case of NMEA0183, this happens to be RMC, GGA, and GSV's for satellite info, (and ZDA to get complete time, which may be added to the common handlers in the future)

The dependency between RMC and GGA (and ZDA in future) is therefore incidental :)