[Drivers] GNSS Parser

[AndronikosKostas]

Description of the Issue

Use the output from the GNSS as input, identify the NMEA messages to extract (in this case, only the RMC), and define all the necessary variables for that NMEA message. Then Store them in a designated area of the eMMC memory. Additionally, measure the time required to complete these calculations to define the limit of the rephrase rate of the GNSS.

Chore Tasks

• Integrate the necessary libraries (minmea.[h,c]) from here
  Update: changed only this: time_t timestamp = mktime(&tm); /* See README.md if your system lacks timegm(). */

Main Tasks

• Modify the parser to get UTC time

• A parsing function for the RMC designed to handle two scenarios: one where the GNSS outputs all NMEA messages, and another where it outputs only the RMC message.

• Measure the time required for all the calculations
  Update: It takes approximately 50ms if the GNSS transmits all the lines, but with the optimized solution of sending only the RMC and GGA, the time reduces to around 20ms (baseline parser, without all the calculations needed to convert the lla to ECEF)
  Update takes again 20ms including the ddm to dd conversion (with doubles)

• Calculate also the amount of information that is gonna stored eventually (needed for the link budgets)
  Update: Currently, we are storing 24 bytes. If we change the speed and course over ground to int16, the size reduces to 20 bytes. Additionally, by including the year and month only in the first packet, we can further reduce it to 18 bytes. But if you could store 16 bytes which is multiple 512 it could be more efficient to store them in the eMMC.
  If we are storing the struct that is below we need only 16 bytes but the parser does not give the UTC time so we need to modify it.
  

• Use references instead of pointers to avoid checking for null. Check here

• Use etl::to_string instead of sprintf or snprintf.
  Update: we will not use that.

• Fix valid bool. If you don't manage this check the quality factor.

• Handle the raw values from the GNSS because the parser library does not have this capability
  Update: static_cast<float>(frame_rmc.latitude.value) / 10000000.0f; Then convert them from dddmm.mmmmm to decimal degrees

    static T convertToDecimalDegrees(T ddm) {
        LOG_DEBUG << "ddm " << ddm;
        // Extract degrees (integer part)
        int degrees = static_cast<int>(ddm); 
        LOG_DEBUG << "degrees: " << degrees;
        // Extract minutes (fractional part)
        T minutes = (ddm - degrees) * 100;
        LOG_DEBUG << "minutes: " << minutes;
        // Return the decimal degrees by adding the minutes divided by 60
        return degrees + (minutes / static_cast<T>(60.0));  
    }

However, maybe it is better to handle them as doubles and then when it comes to storing...store them as int32_t by multiplying them by $10^-7$.

• Generate GPS baseband signal data streams which can be converted to RF with the BladeRF.
  Update: check here
• Test negative latitudes or longitudes.
  Update: Working as expected

• Check the precision of the float and double.
  Update: We receive GNSS data with 5 decimal places, but to prevent rounding errors during arithmetic operations and preserve input precision, we need to retain 7 decimal places. Since a float can hold up to 6.9 digits, we use doubles for calculations, as they can handle up to 15 decimal places. For storage, we use int32_t values by multiplying the data by the precision factor we want to maintain. For example for 7 fractional decimal digits precision, you multiply the double with $10^7$
• Fix microseconds. When you have a number like 992700...you have to keep 99 (the first two numbers...but when the number is 002241 the parser keeps the 2241 so you have to keep 00 not 22.
  Update: We will not play with that...It is better to have the UTC time instead which is only int32_t
  Update: For now on we will store it as it is.
• COCOM limit
  Update Confirmed that it is disabled. During the generation of GPS signals from PeakSat's orbit, we observed an output of 7.6 km/s, significantly exceeding the COCOM limit.

Test Tasks

• Check that the above function works independently of the constellation that GNSS is locked (GP or GN)
  Update:
• You should also test the parser with real GNSS data.
  Update: In outdoor tests, the GNSS required approximately 25 to 40 seconds to achieve a lock. However, simulations of the SDR showed that it took longer to lock, and even when the simulation was stopped, the GNSS receiver continued outputting the last received signal. Since the validity flag was marked as 'V', these outputs can be filtered out by simply checking the validity character.
  New Update: We leave the filtering scenario with the validity flag (because minmea parser does not parse it correctly) and proceed with the quality factor and satellites in view.
• Test it with all the tasks running
  Update: Works fine
  drive parser output
• GPS time, however, does not account for leap seconds. So compare that with the political time.
  Update: GPS time is the same as the political time.

References

https://www.tronico.fi/OH6NT/docs/NMEA0183.pdf

[AndronikosKostas]

[AndronikosKostas]

gnss_parser_output.txt

[AndronikosKostas]

[AndronikosKostas]

Keep in mind the following