SOG/COG Problem?

[Jurien72]

Is there any update about the problem where SOG and COG are not displaying? Does OpenCPN use a different sentence to read that data than RMC? I just can't figure out what's going on. I'm also getting an intermittent signal displayed in the box at the upper right hand corner of the screen.

I use OpenCPN to play a game called Sailaway. The data is coming from a program that reads data from the game server and transmits it over a TCP connection to 127.0.0.1 on port 10110. When I use this same connection in Qtvlm, it reads SOG and COG flawlessly. I'm just stumped, and would appreciate any help or get pointed in the right direction! Thanks!

[GordMay]

Greetings and welcome aboard the CF, Jurien.

[transmitterdan]

Look at the NMEA debug window. Post some lines from that window if you can.

[bcn]

With RMC only you will have a green "ball" as GNSS indicator in the upper right. When missing the sentence, it will become red.


The bars require NMEA sentences carrying the number of sats.
GNS, GSA, and mostly used GSV.

[Jurien72]

Ok here is the sentences being sent from the server

<GREEN>12:46:50 (TCP:127.0.0.1:10110) $GPGLL,2546.261,N,7959.8522,W,174650.217,V*3B<0x0D ><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $GPGGA,174650.217,2546.261,N,7959.8522,W,6,4,0,0,M ,,,,*24<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $IIVHW,82,T,82,M,4.9,N,9,K*4F<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $IIHDT,82,T*06<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $WIMWV,45,T,8.9,N,A*0B<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $WIMWV,28,R,13.3,N,A*36<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $SDDPT,286.00,0.00*5B<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $SDDBT,938.32,f,286.00,M,156.39,F*31<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $IIVTG,79,79,4.9,9.1*40<0x0D><0x0A>
<GREEN>12:46:50 (TCP:127.0.0.1:10110) $GPRMC,174650.217,V,2546.261,N,7959.8522,W,4.9,79, 230320,,,*0D<0x0D><0x0A>

[Dsanduril]

Originally Posted by Jurien72

$GPRMC,174650.217,V,2546.261,N,7959.8522,W,4.9,79,X230320,,,*0D<0x0D><0x0A>

Check the NMEA window directly, there is an extra space in the sentence as posted in your data, but I don't know if that is a problem with the copy/paste from the window or if it is real in the NMEA stream. If it is real it is throwing off the checksum, which then invalidates the sentence. You can try changing the connection in OpenCPN to ignore checksum, but in my experience it doesn't always ignore.

The space is at position 50 in the sentence, and I've seen that exact same thing here before, so I don't know if the problem is with posting quotes on the forum, the copy/paste function somewhere else, or if the problem actually exists in the real NMEA string.

[Edit]The GLL string looks good, you could set RMC to ignore, and then use the "compute SOG and COG from position change" setting in OpenCPN [/edit]

[Jurien72]

@Dsanduril I checked the NMEA Debug window and even the paste that I did into notepad++ - there is no space present in that sentence, so yeah its a weird bug that doesn't happen until posting on the forum. Weird.

I attempted your solution, set RMC to ignore, compute SOG and COG from position change, Still no SOG/COG in the bottom but I did get some very funky readings on the dashboard. Boat is going east but it constantly read 180 deg with random values appearing for speed (nothing useable - I think I got 800 kn at one point).

I do appreciate the responses and help!

[Dsanduril]

My next step at troubleshooting would be to set the OpenCPN connection to "accept only" and then set the sentence filter to RMC. If that works you can then start adding in sentences one at a time and see which one might be providing conflicting data.

Also make sure you remove the "calculate SOG/COG" otherwise it will overwrite and you will see glitchy data.

[Jurien72]

I already tried that and theres no difference.

[transmitterdan]

Here is what you can do to help us find the problem.

Install the Voyage Data Recorder plugin. Use it to record the NMEA datastream for about 5 minutes. Then compress that file using .zip or other format you like. If the compressed file is not too long post it here with .pdf extension. We can play that file through OpenCPN and see what is going on.

[Jurien72]

Ok let's see if this works. I'm getting some strange messages during playback that aren't there when I'm recording. Idk if that makes a difference or not.

[stevead]

$GPGLL,2546.261,N,7959.8522,W,174650.217,V*3B<0x0D ><0x0A>
$GPRMC,174650.217,V,2546.261,N,7959.8522,W,4.9,79, 230320,,,*0D<0x0D><0x0A>

For both sentences, "V" means data invalid.
Not unreasonable for OpenCPN to not process these sentences.
Also the GLL sentence appears to be an older version of NMEA 183 as it lacks the mode indicator.
The more important question is why hasn't your GPS obtained a valid fix ? Oops, forgot it was a game that was creating your data. Perhaps file a bug with the game developers ?

[Dsanduril]

Can't believe I didn't catch that Forest for the trees I guess.

The "V" means void, which would cause OpenCPN to ignore the data. Sounds like maybe time to go back to the SailAway developers or the tool used to pass the data.

If you can playback from a file, change the "V"s to "A"s and see if that resolves the issues.

[Jurien72]

Ahh ok then, that's probably the tidbit of information I was looking for. The funny thing is, the same exact data stream works just fine in another program (Qtvlm). I do believe that this data stream was tailored to work with that program, so perhaps things were done in a way not cross-compatible. After all, it is just a game, and I'd say the majority of the players use this Qtvlm for their routings. I'm kinda the guinea pig as far as using OpenCPN.

Again, thanks for your help. I'll check back here if I have any more questions.

[Jurien72]

Alright so I went thru that playback file and changes the Vs to As- no change.