Empty in certain nmea0183 strings prevents parsing

[KEGustafsson]

Some time ago I was parsing nmea0183 strings and I noticed that in certain sentences with empty ,, prevented parsing and didn't show values in SK. Sentences were GGA and GLL.

I was wondering if function isEmpty too conservative and removes otherwise valid sentences.

Below is how standard IEC 61162-1 (nmea0183) defines e.g. empty/null. 7.2.3.4 Null fields A null field is a field of length zero, i.e. no characters are transmitted in the field. Null fields shall be used when the value is unreliable or not available. For example, if heading information were not available, sending data of "000" is misleading because a user cannot distinguish between "000" meaning no data and a legitimate heading of "000". However, a null field, with no characters at all, clearly indicates that no data is being transmitted. Null fields with their delimiters can have the following appearance depending on where they are located in the sentence: ",," ",*" The ASCII NULL character (HEX 00) shall not be used as the null field.

Unreliable or not available are valid cases for individual measurements, but now it can cause that whole sentence is not processed. In DSC, GGA, GLL, HDG, VWR and ZDA sentences there are this kind of isEmpty check. Could this check be changed following way? accept empty in nmea0183 string

In addition to this, there is another change, which I'd like bundle here. Change would be to nmea0183-utilities. Couple of functions there are returning 0 instead of null for empty. Could this check be changed following way? 0 to null

What do you think?

[tkurki]

Imho the parser is needlessly strict in these cases and should be changed.

Then we need to decide if null should be sent the fields that are missing. In Signal K null JSON value has the same meaning as the null field that you quote: the sensor is working, but information is not available.

So I am not sure if changing how isEmpty works, but should we go over each of the parsers and see what changes are needed?

Instead of changing the existing functions in nmea0183-utilities to behave differently I would add new functons named intOrNull or something. Otherwise we must change the major version, as this is clearly not backwards compatible and people apparently do use that lib outside the parser.

[sergei]

In my case the empty field in RMC message results in magneticVariation reported as zero, which is 13 degrees off where I am.

[KEGustafsson]

intOrNull would be most probably best solution in this case. It would not break anything old.

I could run a check against EN61162-1:2016 standard (Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 1: Single talker and multiple listeners), which defines all nmea0183 sentences and make a proposal about changes. This may take some time, but anyway this need to be done at some phase. Better sooner than later.