[Feature Request] Please increase maxNMEAByteCount to cover high resolution GGA

[mstranne]

Hey,

I got an m8p connected to an ESP32 via I2C.
In the old library, parsing nmea messages in combination with the micronmea lib worked fine.

However, at the moment I do not get new (valid) nmea sentences frequently. (sometimes even more secounds without any new sentence)

I got setNavigationFrequency to 10, disabled all messages except GGA, setI2CTransactionSize to 128 and call checkUblox frequently.

Then I process new nmea sentences like this:

void SFE_UBLOX_GNSS::processNMEA(char incoming)
{
  if(nmea.process(incoming) == true) {  //new full sentence
    const char* sentence = nmea.getSentence();
    if(nmea.isValid() == true){
      //do something
    }   
   else{
     // here sometimes like this: $GNGGA,114346.50,4703.5545385,N,01527.5036357,E,2,07,1.27,405.326,M,42.403,M,0.5,4$GNGGA,114347.00,4703.5546372,N,01527.5036167
    }
  }
}

I am also using pushRawData to feed rtcm corrections received to the the ublox chip .

I expect new new sentences at 10Hz. Any idea where the problem could be ?

Cheers Marco.

[mstranne]

when I do not use the rtcm stream and pushRawData it works fine. Any idea how I can get both to work?
I guess there is a problem when rtcm messages arrive, I need to set stop of pushRawData to false, so rtcm messages are parsed correctly on the uBlox side. But when I do so it messes up the nmea reading via I2C. If I set stop to false, nmea data is parsed, but the rtcm messages are fail crc check at the ublox chip.

[PaulZC]

Hi Marco (@mstranne ),

Did 10Hz work OK with the old library? (I'm trying to work out what has changed.)

Looking at the datasheet for the NEO-M8P, it suggests you can only achieve 10Hz (PVT) or 8Hz (RTK) when tracking GPS only. Have you disabled the other constellations?

enableGNSS will help here:

SparkFun_u-blox_GNSS_Arduino_Library/examples/Data_Logging/DataLoggingExample5_Fast_RXM/DataLoggingExample5_Fast_RXM.ino

Lines 147 to 156 in b20579e

	// Modules like the ZED-F9P can produce RAW navigation data at rates of up to 25Hz but not while using all of the GNSS constellations.
	// Please consult the data sheet for the Performance figures for your module.
	// In this example we make sure GPS is enabled and then disable Galileo, GLONASS, BeiDou, SBAS and QZSS to achieve 25Hz.
	myGNSS.enableGNSS(true, SFE_UBLOX_GNSS_ID_GPS); // Make sure GPS is enabled (we must leave at least one major GNSS enabled!)
	myGNSS.enableGNSS(false, SFE_UBLOX_GNSS_ID_SBAS); // Disable SBAS
	myGNSS.enableGNSS(false, SFE_UBLOX_GNSS_ID_GALILEO); // Disable Galileo
	myGNSS.enableGNSS(false, SFE_UBLOX_GNSS_ID_BEIDOU); // Disable BeiDou
	myGNSS.enableGNSS(false, SFE_UBLOX_GNSS_ID_IMES); // Disable IMES
	myGNSS.enableGNSS(false, SFE_UBLOX_GNSS_ID_QZSS); // Disable QZSS
	myGNSS.enableGNSS(false, SFE_UBLOX_GNSS_ID_GLONASS); // Disable GLONASS

Best wishes,
Paul

[mstranne]

Damn, I thought about something like that.

However, the problem was that I enabled high precision mode and as soon as the correction data was forwarded to the ublox chip, and it got an RTK fix the nmea messages have a length of 88, which was more than maxNMEAByteCount (82), so messages were not parsed any more.

Example String:
$GPGGA,172814.0,3723.46587704,N,12202.26957864,W,2,6,1.2,18.893,M,-25.669,M,2.0,0031*4F

Would be awesome if you could fix that value!

Thanks a lot.

Best wishes,
Marco

[Darmann2]

Hello!

I run up to the same problem, and I think this is a little bug not a feature request.

GGA without RTK is working:
$GNGGA,123303.50,4648.8589739,N,01451.3921055,E,1,12,0.63,468.064,M,42.859,M,,*4C

GGA with RTK is not working
$GNGGA,080102.75,4648.8577377,N,01451.3912508,E,5,12,0.56,464.699,M,42.859,M,0.8,0000*6E

Thanks!
Alfred

[PaulZC]

Hi Alfred (@Darmann2 ),

Nah, I'm calling it a feature request ;-D . The extra precision from RTK takes the length of the GGA message beyond the usual maximum length for NMEA (82 bytes). I'm trying to decide what new maximum length to use (probably 128 bytes just to make sure we don't run into this issue again) or whether to add a new function to let users define what maximum length to use. If you have a preference, please let me know.

A fix is coming soon. Meanwhile, if you want to fix this yourself, please edit this line in the library header file:

SparkFun_u-blox_GNSS_Arduino_Library/src/SparkFun_u-blox_GNSS_Arduino_Library.h

Line 1322 in 929a9ee

const int8_t maxNMEAByteCount = 82; // Abort NMEA message reception if nmeaByteCounter exceeds this (https://en.wikipedia.org/wiki/NMEA_0183#Message_structure)

Best wishes,
Paul

[PaulZC]

Hi Marco (@mstranne ) / Alfred,
Thank you for your patience. I've changed maxNMEAByteCount to 88 and have made it configurable via setMaxNMEAByteCount. The code changes are here. Version 2.0.8 of the library will be released soon once I have finished testing the new SPI functionality.
Very best wishes,
Paul

[PaulZC]

Resolved in v2.0.8. Closing...