Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 25-03-2010, 15:51   #1
Registered User

Join Date: Mar 2010
Posts: 5
NMEA Parity Errors - Can I Disable?

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
__________________

__________________
svPickles is offline   Reply With Quote
Old 25-03-2010, 16:27   #2
Registered User
 
Viking Sailor's Avatar

Join Date: Nov 2006
Location: San Francisco Bay
Boat: Fantasia 35 - s/v Feeling Good
Posts: 1,074
Guy,

On XP it is:

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

Hope this helps,

Paul
__________________

__________________
Viking Sailor is online now   Reply With Quote
Old 25-03-2010, 17:23   #3
Registered User

Join Date: Mar 2010
Posts: 5
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
__________________
svPickles is offline   Reply With Quote
Old 25-03-2010, 20:06   #4
Registered User
 
scotte's Avatar

Join Date: Apr 2007
Location: SF Bay Area, CA, USA
Boat: Privilege 39
Posts: 664
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 is offline   Reply With Quote
Old 25-03-2010, 20:24   #5
Registered User
 
scotte's Avatar

Join Date: Apr 2007
Location: SF Bay Area, CA, USA
Boat: Privilege 39
Posts: 664
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 ...
scotte is offline   Reply With Quote
Old 25-03-2010, 20:43   #6
Registered User

Join Date: Mar 2010
Posts: 5
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
__________________
svPickles is offline   Reply With Quote
Old 25-03-2010, 21:49   #7
Moderator
 
Paul Elliott's Avatar

Cruisers Forum Supporter

Join Date: Sep 2006
Posts: 3,857
Images: 4
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)
__________________
Paul Elliott, S/V VALIS - Pacific Seacraft 44 #16 - Friday Harbor, WA
www.sailvalis.com
Paul Elliott is offline   Reply With Quote
Old 26-03-2010, 06:59   #8
Registered User

Join Date: Feb 2010
Posts: 619
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.
__________________
PjotrC is offline   Reply With Quote
Old 26-03-2010, 16:35   #9
Registered User

Join Date: Mar 2010
Posts: 5
Checksums and parity

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
__________________
svPickles is offline   Reply With Quote
Old 26-03-2010, 17:50   #10
Moderator
 
Paul Elliott's Avatar

Cruisers Forum Supporter

Join Date: Sep 2006
Posts: 3,857
Images: 4
Quote:
Originally Posted by svPickles View Post
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...
__________________
Paul Elliott, S/V VALIS - Pacific Seacraft 44 #16 - Friday Harbor, WA
www.sailvalis.com
Paul Elliott is offline   Reply With Quote
Old 26-03-2010, 19:27   #11
֍֎֍֎֍֎֍֎֍֎

Cruisers Forum Supporter

Join Date: Apr 2006
Posts: 13,022
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>
__________________
hellosailor is offline   Reply With Quote
Old 27-03-2010, 15:46   #12
Registered User

Join Date: Mar 2010
Posts: 5
Wide Crayons

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
__________________
svPickles is offline   Reply With Quote
Old 27-03-2010, 18:19   #13
֍֎֍֎֍֎֍֎֍֎

Cruisers Forum Supporter

Join Date: Apr 2006
Posts: 13,022
" 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?
__________________
hellosailor is offline   Reply With Quote
Old 27-03-2010, 20:46   #14
Registered User
 
Viking Sailor's Avatar

Join Date: Nov 2006
Location: San Francisco Bay
Boat: Fantasia 35 - s/v Feeling Good
Posts: 1,074
Quote:
Originally Posted by hellosailor View Post
" 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
__________________
Viking Sailor is online now   Reply With Quote
Old 28-03-2010, 00:03   #15
֍֎֍֎֍֎֍֎֍֎

Cruisers Forum Supporter

Join Date: Apr 2006
Posts: 13,022
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.
__________________

__________________
hellosailor is offline   Reply With Quote
Reply

Tags
ais, nmea

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bad GPS Errors - windsaloft Navigation 2 29-07-2009 08:57
Multitude of Errors Doomed Malu Sara 1960cjj Cruising News & Events 3 30-06-2009 02:31
errors in Publication 229 alan2 Navigation 1 14-03-2009 04:57
Phishing & Script errors Jerry Forum Tech Support & Site Help 2 18-10-2006 12:30
New Post selection errors Talbot Forum Tech Support & Site Help 3 19-08-2006 00:05



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 21:34.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.