OpenCPN Version 4.0 Released

[nohal]

RD...
Yes, VDR recording, please...
Pavel

[NahanniV]

Originally Posted by bdbcat

Wrong...

I think I see what's up.

To confirm, will you post the output of your cmake step, like:

$cmake ..

I think your system has OpenGLES libraries install, which confuses the build.

I suspect you will see a line like:

"Found OpenGLESv2"
or
"Found OpenGLESv1"

in the cmake output.

This is not expected for a standard build. If found, thats a bug in the cmake script.

If this is the case, you may modify the CMakeLists.txt, line 263,as follows:

#Search for opengles, short of running a program to test the speed
# of acceleration, I simply use gles on arm systems
IF (ARCH MATCHES "arm*")
find_path(OPENGLESv2_INCLUDE_DIR GLES2/gl2.h )
IF (OPENGLESv2_INCLUDE_DIR)
  MESSAGE (STATUS "Found OpenGLESv2")
#  ADD_DEFINITIONS(-DocpnUSE_GLES)
ELSE()
find_path(OPENGLESv1_INCLUDE_DIR GLES/gl.h )
IF (OPENGLESv1_INCLUDE_DIR)
  MESSAGE (STATUS "Found OpenGLESv1")
#  ADD_DEFINITIONS(-DocpnUSE_GLES)
ENDIF()
ENDIF()
ENDIF()

Note the two "#" characters added before the ADD_DEFINITIONS lines.

Then, $cmake .. and $make as usual.

Maybe?

Thanks
Dave

Should This be done for all ARM builds ?

Thanks,
JM.

[RhythmDoctor]

Dave/Pavel - One other thing. I just added True HDG to the dashboard while the VDR script is playing. So now I can look at Mag HDG and True HDG side-by-side. There is something chaotic going on there involving the 12° magnetic variation. True HDG should be 12° lower than magnetic at all times, but it switches back and forth chaotically. True actually shows up 12° HIGHER most of the time, but after a couple seconds True will suddenly drop by 24° (to the value that it should be). But this only lasts for a split second, then True goes back to being 12° higher than Magnetic.

This seems to be very closely correlated to the changing heading vector on the chart (with a little time lag between the two). It seems sensible that in order to display this vector on screen O needs to calculate the true heading first, and the chaotic value that I'm seeing in the dashboard is causing the fluctuation when the vector overlays the chart.

Knowing your history, I suspect you'll find the problem in the code fairly quickly. But enjoy your vacation first - there's no rush for this, as my boat is laid up until the water melts.

FYI, you may recall that I had found a similar issue in magnetic correction for autopilot bearing-to-waypoint sentences about six months ago. Maybe this is related to that.

[bdbcat]

RD...

We could look at a VDR trace first. I suspect some trouble with variation determination and/or application.

Thanks
Dave

[bdbcat]

NahanniV...

The CMake patch should be applied if you see the lines about GLES in the cmake output.

"Found OpenGLESv2" or "Found OpenGLESv1"

If you don't see those lines, then all is well.

Good Luck
Dave

[RhythmDoctor]

Originally Posted by bdbcat

RD...

We could look at a VDR trace first. I suspect some trouble with variation determination and/or application.

Thanks
Dave

The VDR trace was added to post #153.

In case you are curious, the prior message thread on magnetic conversion problems can be found here:

http://www.cruisersforum.com/forums/...ot-127944.html

[Helmsmatt]

Help! We upgraded to 4.0
Previously, Dave was a lifesaver to help us get the correct own ship and radar overlay orientation on the previous beta version by ignoring the proper NMEA sentences. We had the same configuration for 4.0, but can't get the boat pointing in the right direction, or the radar overlay to be correct. We try to turn different sentences on and off, and lose depth, true heading, wind data, and SOG with different selections. What are we doing wrong?
We've been using OCPN throughout our Caribbean cruise, in Tobago Cays now, and this upgrade is driving us nuts! Help!

[nohal]

Matt...
We need to see your configuration.
And a screenshot of the NMEA debug window
And a recording of the stream with the VDR plugin would certainly be nice if your problem won't be obvious.
In the NMEA debug window look for HDG sentences. Are they green?
Without precise information, it is impossible to help you further.

Pavel

[bdbcat]

RD...

This is a variation problem from your autopilot heading sensor message.

From the VDR trace:

$GPHDG,231.50,,,12.00,E*03

$GPRMC,020716,A,3951.7176,N,07518.4128,W,000.0,000.0,200115,012.1,W*7C

The variation at Philly is -12, or 12W. The HDG message says 12E. The RMC message is correct at 12.1W. This agrees with WMM_PI.

   /*
   ** HDG - Heading - Deviation & Variation
   **
   **        1   2   3 4   5 6
   **        |   |   | |   | |
   ** $--HDG,x.x,x.x,a,x.x,a*hh<CR><LF>
   **
   ** Field Number:
   **  1) Magnetic Sensor heading in degrees
   **  2) Magnetic Deviation, degrees
   **  3) Magnetic Deviation direction, E = Easterly, W = Westerly
   **  4) Magnetic Variation degrees
   **  5) Magnetic Variation direction, E = Easterly, W = Westerly
   **  6) Checksum
   */

Dunno what to do about this...
A custom version to accommodate bad code in the hdg sensor?

Dave

[Helmsmatt]

Thanks for the quick reply, Pavel!
I don't get depth, wind info, or STW.
Removed all port connections and reestablished. no change. Also, radar overlay is not correct, or ownship direction.

[Helmsmatt]

Pavel,
There must be a bug.
I have AIS coming in on COM4, all NMEA data on COM3, and LAN for Radar.
If I add a second COM3 connection to OCPN, and allow all sentences, I get back wind data, depth,and STW. I closed the program, opened it and these data weren't working. I disabled that second COM 3 connection and reenabled it and the data came back.
VEXING!
We're not moving right now, so can't confirm ownship direction is correct. Radar pattern seems to correspond with the chart though.....

[nohal]

Matt...
No bug, but there technically was one in the betas. As you can see from your screenshot, you had COM3 set to let just a couple of sentences come through and, although not visible from the screenshot, HDG was not one of them, which resulted in it being dropped (and displayed in maroon in the debug window) In the earlier betas the rule applied just to the core program, but the sentences were still sent to the plugins, in 4.0 they are really dropped completely upon reception - that was the reason for your trouble.

Pavel

[Helmsmatt]

Great!
So what's the fix for me?

[Helmsmatt]

HDG doesn't help with wind data, depth, and STW on the dashboard plugin.
Why does establishing another COM 3 allow the data, but it doesn't come back when I close and reopen the program? Also, I was only allowing HDT previously. Are you saying I need HDG also?
Thanks again for your reply and help

[nohal]

Matt...
Set the filters to correctly let through all the messages you want on each port.

Pavel