Invalid GGA/GSV length about gps.js HOT 20 CLOSED

@anking In my case, to blame was the faulty input data. Long story short, the problem turned out to be completely uncorrelated with GPS.js. If you are having a similar problem, what I would suggest based on this experience, would be to triple-check your input data manually, by reading and checking if it looks fine so as to ensure that the problem is not your data source.

from gps.js.

Thanks for the ticket, I added these throws for exactly that reason. Some manufacturers tend to have slightly different output formats (or own spec interpretations or ...) and I designed the library to be conservative so that these edge cases can be added explicitly when they arise. I'll look into them in a second and push the change then.
BTW: If you got a stream of data, you can use updatePartial() instead of splitting the data yourself.
Would you mind to tell me what receiver you're using?

from gps.js.

Yeah, sure. Thanks for Your support, btw. I've written a native node addon utilizing pigpio to bit-bang read from the gps via uart. It's an UBlox Neo-7M compatible module (actually manufactured by Waveshare). I'm reading all available data from the buffer every 880ms.

from gps.js.

That's a really strange thing. I have never seen such truncated messages. I mean they got the checksum and it's all fine, but why are they 8 instead of 16 fields long. The length mentioned in the note is about the string length in general and is no problem for the library. That might be a thing for parsers written in C with a pre-allocated area of memory.

I checked a few GGA specs (with extensions) and all state that the way it's implemented is the correct way. I also checked if online tools can get out some information of the two messages you posted, and all say it's malformed. Is your receiver getting other GSV and GGA messages that pass through? Even here https://www.waveshare.com/wiki/UART_GPS_NEO-7M-C they post the correct format. Probably your receiver is broken in a way, but the library acts correctly.

I will not change the code to ignore that malfunctioning receiver. As this does not help you, here a workaround to ignore the messages:

GPS.mod.__oldGGA = GPS.mod.GGA;
GPS.mod.__oldGSV = GPS.mod.GSV;

GPS.mod.GGA = function(str, gga) {
if (gga.length !== 16) return; // Ignore
GPS.mod.__oldGGA(str, gga);
};
GPS.mod.GSV = function(str, gsv) {
if (gsv.length < 9 || gsv.length % 4 !== 1) return; // Ignore
GPS.mod.__oldGSV(str, gsv);
};

from gps.js.

Okay, I mailed with the support of waveshare. Could you please contact them as well? They have three NEO-7M products and need further details to clarify that case. You can reach them via service at waveshare.com.

from gps.js.

Any news on this?

from gps.js.

Yes, sorry for lack of response, I was a bit busy. I tried using updatePartial, but this doesn't work at all - the data event is never emitted. I didn't have any success in other approaches. I'll contact Waveshare and post there as soon as I get to know something

from gps.js.

What do you see when you simply print the data instead of passing it to updatePartial? Does this reveal anything? But thanks!

from gps.js.

Well, finally I have found a suspect - but I'm not 100% sure if that's it yet. I believe the problem lays in the way I read the data, which would mean GPS.js is 'innocent' here. When I analyzed the data again (after a dozen of times), I eventually noticed that the last NMEA sentence of each data packet is read from two to four times - that's because I use pigpio to read the uart. Explanation from doc http://abyz.me.uk/rpi/pigpio/cif.html#gpioSerialRead :

The serial data is returned in a cyclic buffer and is read using gpioSerialRead.
It is the caller's responsibility to read data from the cyclic buffer in a timely fashion.

And this is the moment I forgot to do what is described in the second sentence: the buffer is not flushed after reading data, which means I have to store the last data somewhere and in the next data read loop check whether the sentence is still the same or has changed, otherwise I will pass a random part of a NMEA sentence to further processing. As I said, I'm not absolutely sure if that's the problem, but tomorrow (as I live in Poland and today it's already too late) I'll make a test and confirm the result here. Thanks for Your help all the time.

from gps.js.

You're welcome :)
Okay, that could definitely be the case, because the checksum isn't correct either.

from gps.js.

Alright, I can finally confirm that the issue was resolved and it wasn't a problem with GPS.js. Now, when the data is read properly, the library works perfect! Thank You @infusion for Your support! 👍

from gps.js.

You're welcome :) Good luck with your project.

from gps.js.

Thanks 😄

from gps.js.

Hi guys,

so can you please describe how you solved the problem? From your post I cannot really see it.
I also updatePartial, then the exact same error appears but only after some time.

How can the incoming signal be "flushed"?
How is the solution please?

Regards

from gps.js.

The problem was not on the gps.js side, it was a problem of the GPS receiver. If you can't make it work, please open a new issue with a sentence you want to parse that fails.

from gps.js.

from gps.js.

Hi guys,

so can you please describe how you solved the problem? From your post I cannot really see it.
I also updatePartial, then the exact same error appears but only after some time.

How can the incoming signal be "flushed"?
How is the solution please?

Regards

Having this issue too, even try/catch block do not help. the process still crashes... any ay this can be solved?

from gps.js.

Or post sample sentences that fail. I introduced this harsh exception behavior to collect standard enhancing sentences through the community.

from gps.js.

Sorry for the delayed response,

I totally understand that some sentences can fail, but it doesnt make it OK to crash the application. Currently I cannot even catch this error in try/catch block for some reason. Unless I'm not wrapping the right thing:

		try {
			socket.on('data', c => gps && gps.updatePartial(c)); //send character to gps data parser
		} catch (e) {
			console.log("Caught GPS lib error: " + JSON.stringify(e));
		}

Above code is not cathing anything, the app stil crashes. Example of "bad" sentences:
Error: Invalid GSV length: $GPGSV,3,2,10,09,48,298,26,16,65,039,35,18,03,05726,31,055,35,166
Error: Invalid GSV length: $GLGSV,3,2,18,066,19,79,56,018,37,80,36,290,,81,31,104,38,174
Error: Invalid GLL length: $GNGLL,4036.1695108004.41356,W,235848.00,A,A67
Error: Invalid GSA length: $GNGSA,A,3,81,69,78,79,88,,,,1.33,0.64,1.17,201
...and many more

Sometimes it can also spit out smth like:
Error: INVALID GSA FIX: 81
Error: INVALID GSA FIX: 322

from gps.js.

You may find this solution (although completely unrelated with the library) helpful: you can set up a catch-all error listener, which should handle the error (but will also catch all other unhandled errors). You can listen for an unhandledRejection event if message parsing happens in an async function, or uncaughtException if this is a synchronous block as in the below snippet (based on https://stackoverflow.com/a/40867663/4618440)

process
  .on('unhandledRejection', (reason, promise) => {
    console.error(reason, 'Unhandled Promise rejection', promise);
  })
  .on('uncaughtException', err => {
    console.error(err, 'Uncaught exception');
  });

from gps.js.