NMEA Parity Errors - Can I Disable?

[svPickles]

Summary: can I turn off NMEA parity errors using the OpenCPN ini file?

Details:

I have just started working with OpenCPN - what a joy it is to load a Windows program so fast!

My initial problem has to do with invalid checksums on a specific NMEA sentence.

If I feed OpenCPN using a serial to UPS (Keyspan) device I get a valid GPRMC sentence and I get COG and SOG but no AIS.

If I feed it using a Comar AIX-Multi I get both valid and invalid GPRMC sentences - here's an example of an invalid sentence from the log:

2:55:36 PM: AIS.NMEA Sentence received...$GPRMC,195536,A,0847.8821,N,07933.1366, W,0.2,138.7,250310,2.9,W,D*6A
2:55:36 PM: MEH.NMEA Sentence received...$GPRMC,195536,A,0847.8821,N,07933.1366, W,0.2,138.7,250310,2.9,W,D*6A
2:55:36 PM: RMC, Invalid Checksum : $GPRMC,195536,A,0847.8821,N,07933.1366,W,0.2,138.7 ,250310,2.9,W,D*6A

With the invalid checksum the lat/long comes through into OpenCPN but the COG and SOG never do.

This is almost certainly not an OpenCPN problem since I can manifest the same behaviour in Fugawi and NavMonPC. However, in NavMonPc I can turn off NMEA parity errors and this allows the COG and SOG to come through.

Incidentally, I also get many invalid checksums on the AIS data so I assume something is tripping over itself.

Is there, or could there be, a flag for the OpenCPN ini file that could disregard NMEA parity errors? Would be very helpful for testing as above, and might allow me to use the AIS-Multi.

As a side note, we're sitting in Panama with more than 90 AIS targets in view, so I don't know if the AIS-Multi is spitting out too much data and overloading the channel - this is pure speculation based upon utter ignorance.

Obviously I could feed the GPS via serial and the AIS separately to bypass this problem but it's physically messy.

Thank you, developers, for the cleanest and fastest piece of navigation software I've ever tried.

Guy

[Viking Sailor]

Guy,

On XP it is:

control panel -> system -> hardware -> device manager -> ports -> com port x -> port settings -> parity = none

Hope this helps,

Paul

[svPickles]

Thanks Paul for the help.

The port itself already has parity=none.

I do wonder if I'm mixing up Parity errors and Checksum errors. I was hoping for a solution that would tell OpenCPN to disregard the Checksum. This appears to be what happens in NavMonPc when you tell it to ignore NMEA parity errors.

Guy

[scotte]

Hmmm.. The checksum for that sentence should be *16, but the sentence itself should only have 11 fields, not 12 - the ",D" at the end is "extra". Even without that, the checksum would be different (*7E), though.

It seems pretty unlikely the AIS unit is just flat out wrong...

Does the AIS unit have any options or setup regarding NMEA setup? That might be worth a look...

I guess you could always route it through NavMonPC for now using the virtual serial port for output, and use that for the input to OpenCPN... That would at least be a workaround.

And yes, parity and checksum are different things...

[scotte]

One other thing - although I don't see signs of it in your example above, is the possibility of line noise. It will be significantly more likely at 38400bps than at 4800bps. If you made your own cables, just double check that all your connections are good and if differential-differential that both + and - are connected, and if differential-singleended, just connect +, and grounds, nothing to the - of the differential end.

Don't count out that the problem may just be between the GPS and the AIS receiver - it's giving it's best try at providing a valid stream based on what it's receiving.

Lots of speculation as to the cause, hope it helps but not sure it does ...

[svPickles]

Thank you Scotte. Two helpful suggestions - I'll check the physical cables and try piggybacking on NavMonPC.

Interesting that you point to the "D" as an extra component in the sentence - I get the same "D" when the GPS outputs via the serial port - here's a sample of a "valid" sentence from the log:

1:11:21 PM: NMEA Sentence received...$GPRMC,181124,A,0847.8879,N,07933.1329, W,0.1,30.2,250310,2.9,W,D*2D

And this one gives a valid reading on COG and SOG. I've tried to spot the differences between the valid and invalid sentences and can't.

The serial port works, the AIS-multi doesn't, but the sentences look the same except for the checksum.

And I think I'm conflating checksum and parity because when I click the button labelled "Ignore NMEA Parity Errors" in NavMonPC I get SOG and COG from the AIS-Multi.

Thank you for giving me something to test.

Guy

[Paul Elliott]

The NMEA sentence "$GPRMC,195536,A,0847.8821,N,07933.1366, W,0.2,138.7,250310,2.9,W,D*6A" does have a bad checksum -- I calculate that it should be *36. The final "D" parameter is legal, and it is called the Mode Indicator. The "D" indicates that the GPS is operating in Differential mode. I believe that this was an addition to the original RMC definition.

The "Ignore NMEA Parity Errors" in NavMonPc is indeed referring to NMEA sentence checksum errors. I've seen "checksum" and "parity" used interchangably here, but I belive that it is properly called a checksum. I probably ought to change the wording in NavMonPc.

I have no idea why your checksums should be bad, but some equipment doesn't properly calculate them, possibly after a header modification or the like. That's why I added the option in NavMonPc. This has absolutely nothing to do the the serial port parity.

If someone could convince me that it was a useful feature, I could optionally regenerate the checksums on NMEA sentences when NavMonPc forwards them to its output ports...

Good luck!
-Paul (author of NavMonPc)

[PjotrC]

A couple of weeks ago I had a problem with NMEA parity, too.
The essence of the problem was that NMEA stream recorded through some other software had every line end in CR, CR, LF instead of typical CR, LF.
I was considering then an option to turn off all checksumming, but decided against it, because of general attitude of OpenCPN (as I understand it) to accept strictly normative input (e.g. GPS at 4800, AIS at 38400).
Of course, it is a policy matter, easy to implement one way or the other.

P.

[svPickles]

Thank you Paul for clarifying the distinction between parity errors and the bad checksums. The problem is clearly with bad checksums in this case. I don't know why they are bad either but I'm going to recable the AIS-Multi to a different GPS output port on the Garmin just on the off chance that it is a noise or cabling issue.

Thanks also for clearing up the issue of the final "D". Clearly the only problem with the sentence is the checksum.

Certainly it would be nice if NavMonPC could clean up an input stream with defective checksums and put out a clean stream but I'm not going to ask for it outright since it seems a bit of an esoteric feature. Were it to be implemented, hypothetically speaking, of course I would be delighted...



Guy

[Paul Elliott]

Originally Posted by svPickles

Certainly it would be nice if NavMonPC could clean up an input stream with defective checksums and put out a clean stream but I'm not going to ask for it outright since it seems a bit of an esoteric feature. Were it to be implemented, hypothetically speaking, of course I would be delighted...

I'm working on a new release at the moment, and it wouldn't be too hard to fit this in as an option. Obviously the better solution is to fix the problem at the source, but I've already got a bunch of options in NavMonPc that I put there as Navsystem debugging aids, so one more wouldn't be out of place. I'm hoping to have the testing done in a day or two...

[hellosailor]

Pickles-
Think of it this way: Parity errors are a polite way of saying "Yo, Captain, Your navigation data is all garbage!"

You might want to plot the course with a very wide crayon when you get parity errors. At worst, it means one of the little silicon kids has gone psycho and needs to be sent out for rehabiliation. At best...I'd agree that it could simply be line noise. Might be a bad solder joint, a loose plug or contact, or the lines crossing or running alongside something else that is placing EMI/RFI into them. Next to radio transmitter lines? Charger or battery monitor lines? Something often simple and physical.

Meanwhile...use the wide crayon.<G>

[svPickles]

It is a bit of a conundrum. Zapping the checksum error using, for example, Paul's newest version of NavMonPC, would allow the data to come through, and in this particular instance I *know* that the data is good and the checksum inappropriate and that would allow the use of the sentence.

But...what if the data were to go bad: without the checksum we'd never know.

So yes, we really need to fix the source problem with the magic black box screwing up the sentence. I was more interested in the ability to disable the checksum checking sequence as a testing step than as a long term solution.

And I'm with you on the wide crayon. Always a good thing to look out the window and correlate with reality.

Thanks for the very appropriate caution.

Guy

[hellosailor]

" and in this particular instance I *know* that the data is good and the checksum inappropriate "
How can you tell that, unless you have some reason to "know" that the software generating the checksum is faulty? Because it is either the data, or the software generating the checksum, that is faulty. In which case you can't trust the software you are running in any case, can you?

[Viking Sailor]

Originally Posted by hellosailor

" and in this particular instance I *know* that the data is good and the checksum inappropriate "
How can you tell that, unless you have some reason to "know" that the software generating the checksum is faulty? Because it is either the data, or the software generating the checksum, that is faulty. In which case you can't trust the software you are running in any case, can you?

HOS,

The checksum has been re-calculated by Paul Elliott and myself. We came up with the same checksum. The checksum in the example is different then the one we calculated. These results point to the source generating a bad checksum. If you want to check it yourself there are checksum calculators on the internet.

Paul

[hellosailor]

Paul, I take your word on it. And note again, since you've proven the checksum is being calculated incorrectly, you've also proven there is at least one known failure in the software that is calculating it. Whatever that program is, can you trust that there are no other problems in it?

First time I used a soda can recycling machine, the kind that uses a hydraulic ram to crush the cans, the machine stopped at one point and said "Remove can". Uh-uh. There's a hydraulic crusher telling me it has a problem, and I should insert my HAND INTO ITS MAW? No, not me. I've been taught to let sticks and things do that job, hands are harder to come by.

Sometimes, one error just means you can't trust the entire product. At least, not quickly.