OpenCPN Version 4.0 Released

[bdbcat]

Wrong...

OK, thank for the info. 217 mm sounds OK for a 7" tablet.

Lets step thru item-by-item, please

1.If you use the standard ownship icon, does it display correctly?

Dave

[bdbcat]

Wrong...

On the marks and waypoints:

Are you using any custom user icons in ~/.opencpn/UserIcons directory?

Thanks
Dave

[Wrong]

*The answer to both questions is no.
*Ships setting is set to default.
*217 mm is what the calculator gives (8.5") for my 10.1" diagonally measured screen.
*Attached is a screenshot of the small 'o' that appears where the ownship should be.
*The second screenshot is when the ownship is changed to vector then zoomed to where the ship first begins to appear.

[rgleason]

RD & Pjotr
Regarding operation of Portable Opencpn and multiple instances
Post #110
Post #117
Post #119
Post #120
Post #122
Post #123
Post #129

I think it would be great if a brief summary of this could be put in the Portable section perhaps under "Run two instances of OpenCPN".
http://opencpn.org/ocpn/portable_opencpn
1. How to do it safely.
2. How not to do it. -do not use same ini log, etc.
3. Concerns
I could start it...but would want someone to review.

[rgleason]

RE: Ownship problem. - Looks like some scaling problem.

[Wrong]

Originally Posted by rgleason

RE: Ownship problem. - Looks like some scaling problem.

Well, the only option offered in the 'Ships' settings which is user definable is for the 'real scale vector'. The same dimensions are used in O4 that are used in 3.3.1618, 9 meters in length (27') and 2.66 meters in width (8'). The only other variables are related to where the gps is located on the boat.

If you know of other scalar variables in opencpn.config or any other file that can cause my problems, what are they?

[bdbcat]

Wrong...

Thanks for the pix.

This is most very strange.
I think there is some trouble reading/loading the chart symbols here.

Will you check your log for the following lines:

19:30:31 EST: Styles loading from /usr/share/opencpn/uidata/styles.xml
19:30:31 EST: No styles found at: /home/dsr/
19:30:31 EST: No styles found at: /home/dsr/.opencpn/

The little "o" on ownship is actually a drawn circle, not a symbol. So the system knows how to draw on the screen. But the standard "bishops hat" ownship is a bitmapped symbol that comes from a png file in the style directory, /usr/share/opencpn/uidata. It should be drawn at the same place.

The same logic applies to routes and marks. The route lines are drawn, the marks are bitmapped symbols.

What is very strange is that the toolbar icons come from the exact same file. I assume that they are shown OK?

I may need to give you some test code to compile and see where those symbols have gotten to...

On the scaled ship: The screen size of 217 mm for a 10" diagonal panel seems OK. When I look at your screen shot, the 27 ft ownship does not seem excessively small compared to the size of the slips in the marina there. What do you think?

I note that on previous version of O, before the ability to enter the screen size was implemented, that the scaling of vector ownship was just plain wrong. Usually way to big. That's one reason why we added the screen size parameter.

Thanks
Dave

[NEVERMIND]

Hi,
In dashbord, I do not have the display of the true wind direction but this one appears on wind history. The number was "0" magentic
An explanation ????
Jean Paul

It is the same touble with XP and W7 different computer.

With 3.3.2503 it is OK

[PjotrC]

Originally Posted by RhythmDoctor

It sounds to me like you could get along just fine by running your customized v2.5 in non-portable mode, and also O4 in portable mode.

You are right here, and for now I am indeed happy I did not port my precious 2.5 extensions to next releases...

But... the basic danger is that a user (by lack of information or just by some misclick) will start twice the same installed instance. All installed instances likely end up as links/shortcuts on the desktop. I would think that the chance of starting twice the same portable instance is about the same as starting twice the regular one, especially if the portable is the one normally used. But there is no protection against running twice the same portable. So the check for some "opencpn" running around covers only one specific scenario, leaving both false positives and false negatives, in some cases behaving as in older releases, but preventing users from executing useful and safe scenarios.

Maybe there is a reason for doing just this... I do not know this now...

Just another idea. Maybe one should have a default "safe" configuration, and allow an option, say, "extreme", that disables the checks that are there purely "just in case". Overzoom protection can already be turned off. Maybe one could turn off also the check for suspicious chart datum, for unknown chart projection, and also - for parallel execution... ? In all these respects 2.5 was "extreme" and - although I agree there should better be no place for it on the bridge of a tanker - it can do a lot of good to an adventurous cruiser...

Needless to say, the developers' effort, knowledge, involvement, helpfulness is way beyond what is commonly seen... thanks a million times for this work!

[nohal]

Originally Posted by PjotrC

You are right here, and for now I am indeed happy I did not port my precious 2.5 extensions to next releases...

But... the basic danger is that a user (by lack of information or just by some misclick) will start twice the same installed instance. All installed instances likely end up as links/shortcuts on the desktop. I would think that the chance of starting twice the same portable instance is about the same as starting twice the regular one, especially if the portable is the one normally used. But there is no protection against running twice the same portable. So the check for some "opencpn" running around covers only one specific scenario, leaving both false positives and false negatives, in some cases behaving as in older releases, but preventing users from executing useful and safe scenarios.

Maybe there is a reason for doing just this... I do not know this now...

Just another idea. Maybe one should have a default "safe" configuration, and allow an option, say, "extreme", that disables the checks that are there purely "just in case". Overzoom protection can already be turned off. Maybe one could turn off also the check for suspicious chart datum, for unknown chart projection, and also - for parallel execution... ? In all these respects 2.5 was "extreme" and - although I agree there should better be no place for it on the bridge of a tanker - it can do a lot of good to an adventurous cruiser...

Needless to say, the developers' effort, knowledge, involvement, helpfulness is way beyond what is commonly seen... thanks a million times for this work!

Yes, it covers just one specific scenario, but the one valid for most likely something like 99% of users, IMHO. The patch solving it better is of course welcome. Change to implement "extreme" (= totally broken) behavior is IMO not a good idea at all.

Pavel

[Wrong]

Originally Posted by bdbcat

Wrong...

Thanks for the pix.

This is most very strange.
I think there is some trouble reading/loading the chart symbols here.

Will you check your log for the following lines:

19:30:31 EST: Styles loading from /usr/share/opencpn/uidata/styles.xml
19:30:31 EST: No styles found at: /home/dsr/
19:30:31 EST: No styles found at: /home/dsr/.opencpn/

The little "o" on ownship is actually a drawn circle, not a symbol. So the system knows how to draw on the screen. But the standard "bishops hat" ownship is a bitmapped symbol that comes from a png file in the style directory, /usr/share/opencpn/uidata. It should be drawn at the same place.

The same logic applies to routes and marks. The route lines are drawn, the marks are bitmapped symbols.

What is very strange is that the toolbar icons come from the exact same file. I assume that they are shown OK?

I may need to give you some test code to compile and see where those symbols have gotten to...

On the scaled ship: The screen size of 217 mm for a 10" diagonal panel seems OK. When I look at your screen shot, the 27 ft ownship does not seem excessively small compared to the size of the slips in the marina there. What do you think?

I note that on previous version of O, before the ability to enter the screen size was implemented, that the scaling of vector ownship was just plain wrong. Usually way to big. That's one reason why we added the screen size parameter.

Thanks
Dave

Dave,

The toolbar icons display properly.

Regarding the size of the ownship. I'd rather see the ownship at all zoom levels rather than in overzoom only. Otherwise, of what use is it in determining at a quick glance your position when underway? I had no problem with the out of proportion ownship that changed to a different shape when zoomed way out. It is in my way of thinking for reference only.

Here's the logfile info:

Styles loading from /usr/share/opencpn/uidata/styles.xml
09:32:21 PST: No styles found at: /home/android/
09:32:21 PST: No styles found at: /home/android/.opencpn/
09:32:21 PST: Detected display size: 433 mm
09:32:21 PST: Detected display size: 433 mm

I have to wonder if the detected display size is only being detected and not used. In spite of my manually specifying 217mm. Just in my nature to suspect such things.

Thanks for explaining the other issues.

[PjotrC]

Originally Posted by nohal

Change to implement "extreme" (= totally broken) behavior is IMO not a good idea at all.

Pavel,

I understand your concerns, sure. "Extreme" is not a right word, more of a joke. But when one is out there, away from the internet, sources, support etc. one tries to use whatever is available. No guarantees, of course.

On approaching south Madagascar we were in need of charts to look for an anchorage to ride out bad weather. Unexpectedly, an almost forgotten C-Map Viewer (the one that does not support GPS) was found on one of the laptops, that included a very old edition of v2. It was just the best for this particular area. So, one never knows...

Thanks and let's hope for the best!

Piotr

[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

[Wrong]

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

Dave,

You're a programming genius! Worked like a charm.

Will this change be incorporated in the git repository so I can remove my precautionary notes in both my threads and @ opencpn.org?

Did you get a working O4 on your tablet?

Regarding Linux Deploy. It isn't readily apparent, but if at some point a download is stopped - installation of linux is incomplete - trying again by tapping on 'Reconfigure' (Start GNU/Linux Reconfiguration) in L.D. will resume an installation where it left off. Also, I've never had issues using L.D. on good wireless networks, something hard to find in the Caribbean. Heck, I had to use TOR in Trinidad where the Telecomms blocked linux repositories. Consequently, I'm probably on the NSA list of miscreants...


Thanks for your perseverance.

[RhythmDoctor]

Dave, you rule. Great job righting Wrong!

As the OpenCPN abuser-in-chief, I have a new discovery for you. I just got done installing the vYacht Marine Router/Seatalk converter, so I now have some new stuff coming into O4, including the magentic compass heading from my autopilot. My boat is on the hard, so its heading should be fairly stable, and sure enough the digital readout of the compass only fluctuates by a couple degrees. Unfortunately, the heading vector coming off my boat fluctuates by about 20° every second or so. You can see in the pics below that the dashboard shows 227° for both screenshots, but the boat's direction vector is very different in both.

Let me know if you need log files or VDR scripts.

Thanks!

By the way, you'll note that the menu bar appears in one of the pics. That has nothing to do with the fluctuating heading. I was using Alt-PrintScreen to do the screen grabs, and I suspect the the menu came up in response to the Alt key. The fluctuation was happening constantly without the menu bar appearing. It does the same thing on my home computer while playing the VDR script.