weird stuff happening - openCPN 5.5.1109 on OpenPlotter and Buster rpi 3 B+

[LifePart2]

Following my previous post, I went out for a test sail today, and now all sorts of weird stuff is happening that I can't figure out, so would appreciate any suggestions:

1) no sound through HDMI as in previous post.

2) my Own Ship icon dances around in direction. The COG predictor line is fine, as is the track it is laying down, but the boat's heading points off in all sorts of directions.

3) When I lay in a route, the direction to destination, every few seconds, shows something impossible, eg 2888576 (M) or 8 (T) and 337 (M) (WMM calculated magnetic variation here is - 15 deg) and then it goes back to a more normal number.





(sorry about the photo quality, don't know how to get a screenshot from the RPI)

4) The NMEA debug window remains empty, so I cannot see what sentences are coming through.


( in this photo the NMEA debug window is open but empty, and the BRG to destination shows 8 deg for both true and magnetic.)

The NMEA data is coming from a Quark-Electric multiplexer from which it goes by USB to my raspberry pi running openPlotter Signal K and from there to OpenCPN.

At the same time I have OpenCPN 5.2.0 running on my laptop receiving the same NMEA data by wifi from the Quark. It does not show any of this erratic behaviour.

So, any suggestions please?

thanks

Noel

[bdbcat]

Noel...
For diagnostic purposes:


1. Disable WMM plugin
2. Manually set magnetic variation to 0 (Settings->Display->Units)


And try again.


Thanks
Dave

[LifePart2]

Hi Dave

On more experimenting it does seem that the problem is somewhere in the USB - signal K- openCPN connection.

If I do a direct wifi connection to OpenCPN, or if I do a direct usb serial connection (not via signal K) then it all works fine.

very odd.

[bdbcat]

noel...
I have updated OCPN to version 5.5.1115. This is available for OpenPlotter now.


To debug your signalK problem, please install OCPN 5.5.1115, then start OCPN from the CLI, with debug logging enabled. Like this:

$ opencpn -l debug

All of the signalK traffic will be posted to your logfile. This will be a lot of data, if you have AIS traffic nearby. So you may like to disable your AIS receiver, temporarily.
Anyway, after running for a few minutes, seeing strange errors in ship heading, you may stop OCPN. Then please post the logfile here.


Good Luck
Dave

[LifePart2]

Thanks, Dave, and sorry for the delay. We were on a passage, and now have some boat maintenance to do.

However, during the passage (using the direct USB connection) all went well except that at random intervals (a few hours apart) OpenCPN would spontaneously shut down without any warning. Sometimes when I was pressing a button, sometimes when I was simply looking at it - or looking away.

When I started it up again, it sometimes said something like 'sorry OpenCPN is busy, try again' but then would load fine, with the warning that it didn't shut down properly last time.

Anyway, as soon as I can, I will update everything again to the latest builds and then test things out again.

Thanks for your efforts on all this. Much appreciated.

[LifePart2]

Hi Dave,
Ok, here it is. I ran OpenCPN for a few minutes until the 'own ship' icon vanished. Then I shut it down. During the time it was running, the icon was spinning around in all directions but, I can assure you, my boat was not!

I split the file into three so I can upload it. They are labeled as DOC but are actually TXT

Hope you can make some sense of it.

Thanks

[LifePart2]

sorry, don't know what happened to the attachments.
Trying again...

[bdbcat]

LifePart2...


We did learn something from the signalK log output, leading to a correction in OpenCPN.
Root cause of the trouble: it seems that your sK server is not providing any Magnetic Variation as is normally found in a GPS RMC message. The sK data message did not provide a manageable or expected "0" for this variation value field. Instead, it provided ...nothing, or null.



Due to a coding omission, this (null) caused OCPN to introduce effectively random magVariation into the datastream. When this random variation was added to your magnetic heading, the resulting true heading was also random. Thus the "spinning owhship".


Anyway, fixed, AFICT. I have no GPS receiver that omits mag variation, so it is difficult to verify exactly. But the solution looks clean.
You should be able to update OCPN to version 5.5.1126, available in the repos now, to validate the fix.


Thanks for the logs, and the chance to fix another fault.
Dave

[stevead]

Dave,

Just because you assume NMEA 183 sentences transmitted to OpenCPN will be valid, doesn't mean they are.

I'm surprised that you don't have a test suite for all the sentences that OpenCPN parses that includes null or invalid (out of range) values.

And btw, this fix on SignalK may have some impact.

Which seems a little at odds to the NMEA 183 standard which for RMC states

All data fields must be provided, null fields used only when data is temporarily unavailable

[Hakan]

re: And btw, this fix on SignalK may have some impact.

Yes of course it will! Thanks for the link to the PR.
I was a bit "ripped off" when checking for this error looking into SK github NMEA to SK parser and found the is!null condition for variation values. But I didn't realized it was not yet included in any SignalK update. So locally is there still no !null checking and obviously an error in OCPN when the incoming RMC sentence contain mismatch.
Meanwhile we await an SK update Dave's OCPN patch will do.

[LifePart2]

Dave, you rock!

The new version seems to work well. I am no longer getting dizzy.

We will test it out on a longer sail soon, but in the anchorage today the boat is looking nice and steady.

Thank you and your team for both a speedy response AND a fantastic product!

I guess in due course a Signal K update will appear? How will we know when that is available?

[Hakan]

Noel..
re: I guess in due course a Signal K update will appear? How will we know when that is available?

In the bottom list in "Dashboard"

Signal K Server version 1.40.0
When logged in and a new version is available it's messaged there and in "Server"-> Updates

[LifePart2]

Maybe this has been addressed in the new 5.6 release, but on our last couple of sails our OCN suddenly shut down with this error message:

/usr/include/wx-30/wx/longlong.h(179):assert"(m_ll>=long.min&&(m_llG<=lo ng_max)"failed in ToLong():wxLonglong to long conversion loss of precision

I have probably copied that down wrong, and couldn't read my own writing either, but hopefully it makes some sense to you!