NMEA CR and LF are passed to badCrcCallback

[PaulZC]

After commit 4904613, the NMEA CR and LF are: retained in the parse->buffer; included in the parse->length; and, critically, are passed through to the badCrcCallback.

On the Unicore UM980, the pseudo-NMEA command responses include the $ prefix in the checksum calculation. This means the badCrcCallback is triggered each time a response is received.

The Unicore Library badNmeaChecksum function is hard-coded to expect the NMEA checksum in the last two bytes. The CR and LF mess this up, causing the modified checksum check to fail.

The Unicore Library sends a MODE command during begin to establish if the GNSS isConnected. Because the CR and LF are present, isConnected fails and so the begin fails.

Long story short, any code which uses UM980::begin will currently fail. This includes RTK Everywhere on Torch...

We have broken backward-compatibility... All code which includes a badCrcCallback for NMEA is now getting the CR and LF, when it wasn't previously.

Thinking about possible fixes:

We can add a nasty fix in the UM980 Library to test for and ignore the CR and LF.

Or, in this library, we could reduce parse->length by 2 before passing parse to the badCrcCallback. In essence, this is what the previous library was doing.

Or, we could do something clever with the new bytesToIgnore parameter, including passing that to the badCrcCallback....?

Votes please.

[PaulZC]

Please be aware that the Unicore_Hash code currently truncates the CR and LF, like the NMEA code used to. If we're being consistent, we should probably include the same solution there?

SparkFun_Extensible_Message_Parser/src/Parse_Unicore_Hash.cpp

Lines 203 to 204 in 3b61674

	// Don't add the current character to the length
	parse->length -= 1;

SparkFun_Extensible_Message_Parser/src/Parse_Unicore_Hash.cpp

Lines 229 to 230 in 3b61674

	// Don't add the current character to the length
	parse->length -= 1;

SparkFun_Extensible_Message_Parser/src/Parse_Unicore_Hash.cpp

Lines 255 to 256 in 3b61674

	// Don't add the current character to the length
	parse->length -= 1;

[nseidle]

Or, in this library, we could reduce parse->length by 2 before passing parse to the badCrcCallback. In essence, this is what the previous library was doing.

IMO - I've seen enough devices that exclude CR LF after a NMEA (type) sentence that lead me to think \r\n should be ignored/removed from processing.

[PaulZC]

Resolved in v2.0.2

https://github.com/sparkfun/SparkFun_Extensible_Message_Parser/releases/tag/v2.0.2