Beta Test / Technical

[dominig]

I have closed the bug #58 on github. Issue was linked (I guess) to OpenCPN grib_pi and weather-outing_pi beein out of sync.
https://github.com/seandepagnier/wea...g_pi/issues/58

I had to push OpenCPN to the tag 51a8905d91cade8ab97aacea2f65fded4214f51f from March 27th.
a v2.6.0+

But is works :-)

[dominig]

Hello,

I have updated my wiki pages in English and French and created a new one in German for OpenCPN on OpenSUSE Linux.

As writing text is not my best skill, native reviewers are welcome. I have no shame, I know my spelling level.
If you see obvious errors, the fastest is to correct them directly (it's a wiki), if things are unclear, then please contact me with your proposal.

https://en.opensuse.org/OpenCPN
https://fr.opensuse.org/OpenCPN
https://de.opensuse.org/OpenCPN

Regards

Dominig

P.S. Please note that 4.6 still miss a test at sea before moving to the official repo in Geo:OpenCPN

[dominig]

The download web page from OpenCPN for OpenSUSE points on the French version. Even if I have created a French, German, I still get an English one that I guess should be the desired default.

Correct link should be.

https://en.opensuse.org/OpenCPN

Dominig

[bdbcat]

Dominig...

Link now fixed.

Thanks for supporting and maintaining the OpenSUSE community

Dave

[dominig]

Hello,

as a packager I do not develop but I try to get my user (OpenSUSE community) equipped with the latest stable release.

I face 2 major issues :
- Plug ins have mostly no tags. Using Laster or Nohal fork is often the only solution.
- I do not have a easy tracking tool to know when New OpenCPN releases are created.

Where could I get a RSS, a mailing list, ... ?
Could we encourage Plugins developers to create tags tested with Stable release.

I check OpenCPN web site regularly but I still regularly miss steps as U prefer silting during my Free time than keeping poking OpenCPN web site.

Finally I found far more efficient to use the Issue in Git hub than the tracker (in particular for Plugins) should that no become the main bug tool ?

Dominig

[transmitterdan]

Dominig,

Plugin maintenance is probably the biggest issue as the main program evolves. There is no central clearing house. Rick Gleason is doing a good job keeping as many plugins available as possible. But many plugins seem to have stopped development. Also, there are multiple versions of the same plugin floating around on github. It is a bit of a Easter Egg hunt (see how i worked the holiday into the post) to find the best/recent versions. I suggest you send Rgleason a PM. He is probably the best resource for plugin maintenance.

[skipperearly]

Originally Posted by Douwe Fokkema

I tested the redshank.txt with 4.2, an older 4.5 (0fe5f55e0f7b14) and the latest 4.5. First 2 versions give a nice SOG of 0.0 and a COG of 121, without filtering. This is as it should be apart from the COG, GPS seems to do the filtering as it presents a SOG of 0. all the time. But the last version (02c0061f6) shows a SOG of --- in the bottom line. In this case SOG is valid but 0., consequently COG is not valid, though it is presented by the GPS. So various options are possible:
- consider both COG and SOG as not valid if SOG is absent or 0. (current situation)
- always present COG an SOG if and as received from the GPS
- allow for a valid SOG with an invalid COG where we make COG invalid if SOG < .01 (some limit)
The last option may be the nicest but adds complexity, the second option seems sufficient to me (change m_NMEA0183.Rmc.SpeedOverGroundKnots > 0 into m_NMEA0183.Rmc.SpeedOverGroundKnots >= -0. )

With the redshank.txt I have not seen the fluctuating SOG that started this discussion.

Douwe Fokkema

sorry, but option 2 is no good as those silly values are then also entered in the logbook. Why not using the damping settings from the dashboard plugin? - or alternatively some "minimum threshold values" in the ini file? SOG < threshval = 0, > show value. same for COG.

If none of this then lets please revert to old methode (option 1)

[transmitterdan]

Where is redshank.txt found? I will try to see what is happening if I have that file.

[skipperearly]

Originally Posted by transmitterdan

Where is redshank.txt found? I will try to see what is happening if I have that file.

post 1899 above

[skipperearly]

Originally Posted by skipperearly

sorry, but option 2 is no good as those silly values are then also entered in the logbook. Why not using the damping settings from the dashboard plugin? - or alternatively some "minimum threshold values" in the ini file? SOG < threshval = 0, > show value. same for COG.

If none of this then lets please revert to old methode (option 1)

Did some more testing at home today with GPS not moving at all! See attached NMEA log and logbook file to see how errors add up. Different damping factors in the dashboard plugin have no impact other than on the display.

[transmitterdan]

Originally Posted by skipperearly

Did some more testing at home today with GPS not moving at all! See attached NMEA log and logbook file to see how errors add up. Different damping factors in the dashboard plugin have no impact other than on the display.

One issue with the NMEA messages in your test files is that some RMC messages do not actually contain any location coordinates. OpenCPN does not like this because it assumes an RMC message will have some text in these fields. I have submitted a pull request to tell OpenCPN to ignore such RMC messages so it does not get confused about them. This is one example from your file:

$GPRMC,081716.00,V,,,,,,,200417,,,N*74

This message only contains the date and UTC time.

But this is not the reason the OWN SHIP icon moves around. The GPS data actually contains coordinates that vary in position. I don't think OpenCPN can or should do anything about that. It has no way to know the ship is stationary as it relies on the GPS to give accurate coordinates. It would cause a lot of users consternation if OpenCPN did not accurately report coordinates as received from the GPS.

The Dashboard has nothing to do with how OpenCPN displays the OWN SHIP position on a chart. Neither does Dashboard have any impact on logging.

This message for example:

$GPRMC,081720.00,A,4815.30761,N,01620.42655,E,1.590,,200417,,,A*7F

contains valid position and speed but no valid course. So OpenCPN will display the speed (and log it if the time is right) but it will indicate the course as --- since there is no valid course data between the commas. Likewise, the magnetic variation data is not present. However, there is also an extra field at the end ("A") and I am not sure what that means. Perhaps this is some vendor specific code that we should understand. It is not part of NMEA V3 as far as I know. Maybe it is part of NMEA V4.

[rgleason]

TDan will try to compile and test tomorrow or next day. Have run into some difficulties getting a bss website finished.

[skipperearly]

Originally Posted by transmitterdan

One issue with the NMEA messages in your test files is that some RMC messages do not actually contain any location coordinates. OpenCPN does not like this because it assumes an RMC message will have some text in these fields. I have submitted a pull request to tell OpenCPN to ignore such RMC messages so it does not get confused about them. This is one example from your file:

$GPRMC,081716.00,V,,,,,,,200417,,,N*74

This message only contains the date and UTC time.

But this is not the reason the OWN SHIP icon moves around. The GPS data actually contains coordinates that vary in position. I don't think OpenCPN can or should do anything about that. It has no way to know the ship is stationary as it relies on the GPS to give accurate coordinates. It would cause a lot of users consternation if OpenCPN did not accurately report coordinates as received from the GPS.

The Dashboard has nothing to do with how OpenCPN displays the OWN SHIP position on a chart. Neither does Dashboard have any impact on logging.

This message for example:

$GPRMC,081720.00,A,4815.30761,N,01620.42655,E,1.590,,200417,,,A*7F

contains valid position and speed but no valid course. So OpenCPN will display the speed (and log it if the time is right) but it will indicate the course as --- since there is no valid course data between the commas. Likewise, the magnetic variation data is not present. However, there is also an extra field at the end ("A") and I am not sure what that means. Perhaps this is some vendor specific code that we should understand. It is not part of NMEA V3 as far as I know. Maybe it is part of NMEA V4.

Thanks Transmitterdan, for your analysis and explanations.
From GPRMC documentation:
eg3. $GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,1 30694,004.2,W*70
1 2 3 4 5 6 7 8 9 10 11 12


1 220516 Time Stamp
2 A validity - A-ok, V-invalid
3 5133.82 current Latitude
4 N North/South
5 00042.24 current Longitude
6 W East/West
7 173.8 Speed in knots
8 231.8 True course
9 130694 Date Stamp
10 004.2 Variation
11 W East/West
12 *70 checksum

the 2nd parameter already indicates an invalid sentence, so ocpn should indeed ignore it. Thanks for raising the pull request to repair this bug.

The last parameter is the checksum.

If it would be usefull to have a damping or passing every valid GPRMC sentence through is probably philosophical, maybe its enough to damp only the display sequence as long as the bus isn't overloaded.

Again, thanks for your efforts.

[transmitterdan]

Originally Posted by skipperearly

the 2nd parameter already indicates an invalid sentence, so ocpn should indeed ignore it. Thanks for raising the pull request to repair this bug.

Just for clarification, OpenCPN already ignores invalid data. The bug I found is a minor thing where it tries to parse the missing data anyway. It passes empty strings around which is technically an error but does not cause any outwardly visible errors.

I suspect that when the signal strength is very low then you will get the jumping around of position and incorrect velocity messages abeit with a valid flag in the message. I did a little testing with an old Garmin GPS. If I put it outside with clear sky view there is no jumping and speed is 0. But if I obstruct the antenna then with more and more obstruction the boat jumps around and velocity is shown at about 0.6 knots. It looked very much like your data. So I would suggest a possible solution is to find a better location for the GPS antenna.

[transmitterdan]

Originally Posted by cagney

I have recorded a VDR file of a similar situation. Anchoring and O 4.5.0 continues to show some speed.
I 'm using an old Garmin GPS 128, that shows 7 good satellites used.

O shows: COG 121, SOG 0.9
GPS128 shows: COG 121, SOG 0.0

Attachment 139913

Thomas

Thomas,

I finally got back to my debug machine. When I play your VDR file I don't see much movement of the vessel. I recorded the track and attached what I see. Only 3 positions were recorded in the track after the initial fix. I think this is normal behavior without WAAS. Does your Garmin use WAAS?

I also have an old Garmin and when I was in the BVI it locked up during a passage. I asked Garmin about it and they said it was a firmware bug and the workaround was to turn off WAAS when operating in that area. But without WAAS the stability of the fix is substantially less.

Also, note that all of the boat movement is in longitude (latitude stays fixed) which further suggests some "noise" in the GPS fix calculation. I don't see anything wrong with OpenCPN in this instance.