OpenCPN Version 4.0 Released

[bdbcat]

Sean...

re:

I would like to know about the case using opengles doesn't work on arm and why it was disabled.  Is glshim built and used?  Why...

The removal of GLES was a temporary patch to get Wrong moving forward with android chroot mode. He had GLES libs installed, which fooled the OCPN cmake script. I don't plan to push the patch to master. It is not good enough. We need more complex logic in cmake to detect all arm/GL cases correctly.

The only accessible OpenGL in the android chroot environment will probably be swX11, which is worse than no OpenGL, I suspect. I doubt that a standard GLES for gtk can find the Mali hardware in chroot mode, but I would love to be incorrect about that.

I have no native arm/linux/GLES capable hardware, so can't work this one directly. Sean and NahanniV are the best candidates to work this one out.

Thanks
Dave

[dominig]

Hello,

I am about to push OpenCPN 4.0 on OpenSUSE official repos and I would be interrested to know which plugins have been tested with 4.0?

I do not have the capability to check all of them one by one and having a list of the valid plugins would be of a great help for packagers like me who build the release for many people who will use it in configuration that we do not control what push us to include as many plugins as possible.

Thanks again to the team for that great software.

Dominig

[nohal]

Dominig...
All the plugins at PlugIns | Official OpenCPN Homepage work with OpenCPN 4.0

Pavel

[Wrong]

Originally Posted by boat_alexandra

Yes, well the two possibilities are using opengles which should always accelerated if supported and opengl which may not be accelerated and usually isn't on arm. Before, by default it would attempt to use opengles on arm platforms if available which is maybe not complex enough logic.

I would like to know about the case using opengles doesn't work on arm and why it was disabled. Is glshim built and used? Why would you want to use software rendering when hardware acceleration is available? What is the problem and how can we fix it? If we can't fix it, how can we detect systems that can't handle hardware acceleration in the cmake file?

I can only guess, but believe your experience is primarily related to arm devices with a kernel installed along with the O.S.. The kernel provides drivers that are compatible with your device hardware and are directly controlled by your linux O.S. Not so when linux is running in a chroot environment on an android device - made possible only because the android kernel is a linux kernel. And here's the rub. A fully Linux compatible and linux controlled video device driver is unavailable largely due to proprietary restrictions. So, the 'normal' approach to achieving hardware accelleration doesn't work.

This doesn't mean there isn't a workaround that doesn't use glshim. The swx11 driver enables OpenGL in the chroot environment without using opengles.

Changes to the CMakeTexts.txt file simply make OpenCPN USABLE IN NON-OPENGL MODE IN A CHROOT ENVIRONMENT. I can't say why since my understanding of OpenGL and opengles is non-existent.

My sense is there should be a few questions posed during the cmake process that once answered can resolve this issue of platform compatibility in regard to OpenGL.

[RhythmDoctor]

I thought I would post a quick update on the magnetic variation issue from the vYacht router.

Originally Posted by muttnik

...Reviewing Thomas Knauf's doc, seatalk variation is a single *signed* byte with positive values being west, negative east, so 0x01 is 1 degree west, 0xff is one degree east which is (I think) counter intuitive.

Yes, it is counter-intuitive, since the normal convention is the opposite of the way Seatalk does it. The guy who makes and sells the vYacht router wrote back confirming that he had the negative sign backwards, and that it will be an easy fix. He will send an update soon.

I continue to be concerned about potential discrepancies between the variation reported by GPS and compass. While my case was extreme because of an error in the Seatalk translator logic, even after that bug is fixed, there's the potential for the GPS to report 12.5° and the autopilot to report 12° (since it has not decimal place). Or, on a long cruise, the difference could be even larger if you do not re-program the autopilot. I would expect the GPS's reported variation to always be more reliable than the value manually programmed into the autopilot (since I bet a large majority of users don't even know how to change the variation in the autopilot). I think there should be logic built into O that causes it to ignore the autopilot's reported variation if GPS variation is available.

[bdbcat]

RD...

What sort of autopilot is this? Can you program the output sentence type? How about $xxHDM? This has no variation component at all, just the raw output from the flux-gate compass.

Dave

[rgleason]

Level of sleuthing and solutions here has gone up at least two notches. Congratulations to all of you. Remarkable!


Sent from my GT-N5110 using Cruisers Sailing Forum mobile app

[RhythmDoctor]

Originally Posted by bdbcat

RD...

What sort of autopilot is this? Can you program the output sentence type? How about $xxHDM? This has no variation component at all, just the raw output from the flux-gate compass.

Dave

The Autopilot is a Raymarine ST4000+. It speaks SeaTalk, not NMEA, and there's no way to suppress the variation information. If you set it to zero it transmits zero variation, not a null reading.

My model of vYacht router has a Seatalk-NMEA converter. This is what generates $GPHDG. Bernd (the guy who sells it) makes the source code available, so if I were a programmer I could modify it to do whatever I want. But the web page to control the router just gives the usual router stuff - customize SSID, WiFi password, IP address, plus a couple options to set baud rate of the NMEA inputs. There is no user-accessible option to change NMEA sentences.

In theory I could ask Bernd to make a custom firmware for me, but I do think that the general scenario of O receiving two conflicting variation inputs (from GPS and autopilot) could be a rather common issue that O should filter out.

[bdbcat]

RD...

You are correct that more fine grained prioritization of message contents would be a good thing. Will need a more complex GUI, require more user smarts, etc.

I personally would not worry about variation differences of a degree or so. On most cruising boats, the heading sensor is not that accurate anyway, since the deviation compensation is not very precise, and its impossible to steer small to 1 degree in any seaway.

I also would suggest, if anybody asked, that the router really should not try to send variation in the HDG message. If it is known by the GPS receiver, then it will be available in the RMC message. In the present implementation, the variation in the HDG message is user programmed, so subject to displacement error. Recommendation: Just send the HDM message, raw compass data, and let the upstream sort it out. My 2 cents...

Dave

[Wrong]

A simple solution?

When zyGrib and qtcreator are launched as 'zyGrib' and 'qtcreator' icons and text do not display properly as the first two screenshots reveal.

However, when launched with '-graphicssystem native', they do as in the second set of screenshots.

Trying to launch OpenCPN as 'opencpn -graphicssystem native' returns 'Unknown option -graphicssystem'.

Can this be made possible with OpenCPN?

[nohal]

Originally Posted by Wrong

A simple solution?

When zyGrib and qtcreator are launched as 'zyGrib' and 'qtcreator' icons and text do not display properly as the first two screenshots reveal.

However, when launched with '-graphicssystem native', they do as in the second set of screenshots.

Trying to launch OpenCPN as 'opencpn -graphicssystem native' returns 'Unknown option -graphicssystem'.

Can this be made possible with OpenCPN?

No. OpenCPN is not built on top of the Qt toolkit, but wxWidgets/GTK. Once the QT backend for wxWidgets gets usable, then perhaps.

Pavel

[CarCode]

Bug in OpenCPN 4.0 Mac version
Open Properties window of a waypoint.
Try to write the small chars (no uppercase) a, c, l, m, o, q, s or t in the Description field of the Properties window.
This will trigger the shortcut function only but not write these chars.
For Linux or Windows version this does not happen.
Gerhard

[cagney]

Dave
I get a crash if running O with a DSC sentence with an incorrect check-sum.

$CDDSC,12,3380400790,12,06,00,2335015115,0925,,,S, E*65
$CDDSE,1,1,A,3380400790,00,45004400*17

The first sentence has a wrong check-sum, should be 45 instead of 65 at the end. A repeatable crash occurs when using VDR on sentences above, just after starting O.



If I run VDR on the correct set of sentences first, and then the sentences with an error, there is no crash, neither is there an DSC emergency alarm in this case.

Thomas

[Gilletarom]

Hello Dave, Hello Anyone,

I had already reported an abnormal phenomenon using a MOB in the latest beta, but nobody seems to have the same problem. So nobody has confirmed.

I started the experiment with the 4.0. I have the abnormal phenomenon again.

I use a VDR file on my boat. At one point, I click the MOB button on the toolbar.

As expected, the MOB mark appears under the boat.
As expected, a route is created with a length of 1 nautical mile.

As expected, the route turns BUT only a brief moment and then turns off. Similarly, the route information window opens to the right of the screen. BUT, it closes immediately. This is not normal.

I have experience with several VDR file, an old 2013 and a more recent 2014 The same anomaly occurs.

I tried to manually activate the road. She stopped immediately and the window disappears immediately.

I thought opening a task in the tracker but first I want others to do the same test as me.

I have attached a screen shot and one of my VDR file. (Delete ".pdf" and unzip it)

B.R. Gilletarom

[bdbcat]

Gilletarom...

Regarding the abnormal MOB route deactivate when using VDR:

I can reproduce this bug easily. It should be added to the Flyspray tracker to be certain that it is considered for the next Beta series testing.

Thanks for the note
Dave