parsing issue in $GPRMC format?

[nusense]

I believe the parsing code for the $GPRMC message is treating the position coordinates incorrectly.

   latm = atoi(&nmea_params[3].str[2]);
   nmea_params[3].str[2] = '\0';
   latd = atoi(nmea_params[3].str);
   lats = atoi(&nmea_params[3].str[5]);
   if (*nmea_params[4].str != 'N'){
      latm *= 1;
      latd = latd * -1;
   }
...
   flats = lats;
   flats *= 60;
   flats /= 10000;

The positions are of the form ddmm.mmmm per the NMEA standard. This code seems to assume that the fractional minutes are always given as 4 digits (per the flats /=10000; scaling) but that doesn't seem to be true:

An example sentence from my gps is: $GPRMC,034607.00,A,4154.26837,N,08817.68304,W,1.419,,280117,,,A*64

But you can see that 08817.68304 means lngm is 17, lngd is 88, lngs would be 68304 ... leading to flats = 409.824 (floating point "seconds") a factor of 10 too high.

Even in the ublox documentation the example has more digits (see screen shot):

Though the format column misleadingly only has 4 ms after the the decimal (so I can see where the confusion could arise).

I'm not currently setup to modify/compile and test the code (so possibly I'm not aware of compiler limitations -- otherwise I'd try and then generate a pull request with actual code) but couldn't one simply use atof() to read in the minute + fractional part? Or does that function not exist / not supported?

[nusense]

Also, I think the following code has a index issue for "speed"

nmea_vtg_cb(void)
{
    if (!gps_valid)
                return;
        strncpy(course, nmea_params[1].str, sizeof(course));
    strncpy(speed, nmea_params[6].str, sizeof(speed));
        LOG("course: %s\n", course);
        LOG("speed: %s\n", speed);
}

for the $GPVTG sentence the "speed" is [5] (knots) or [7] (km/hr) not [6] .. I presume, you intended [7] though units aren't specified.

[greenbreakfast]

@nusense could you please submit a PR with your proposed fixes?