OpenCPN Beta Version 3.3.2410 Released

[sailorF54]

Originally Posted by P_Dub

I have made many current file for the St-Lawrence, all are working OK except this one, that I am including you ( idx part and harmonic part and also a print screen) Any idea why I can not see the curve on the chart correctly?


HARMONIC.idx
cNAA:Can:Qbc: -70.6474 46.9964 -5:0 BANC EMPRESS_CURRENT, QUEBEC
^12 0.00 0 06 1.00 0 0039 220 052 1 BANC EMPRESS_CURRENT, QUEBEC


#

A shot in the dark (I have not checked the format)
006 or 060 instead of 06 ???

[P_Dub]

Originally Posted by sailorF54

A shot in the dark (I have not checked the format)
006 or 060 instead of 06 ???

Sorry, but all the others are layout that way and works properly, so this has nothing to do with it.
Regards

[Hakan]

Originally Posted by bdbcat

Håkan....
Something very strange.
If you look at the commit, you will see nothing that affects the dialog rendering code. All it does is remove a focus recapture that was in the wrong place.
Will you post a picture?

Thanks
Dave

Dave..
And here is about the appearance change:

The first picture of BR24radar menu is where I use O built 2014-12-12, where the dialogue box loss of focus is not a critical issue.

The second picture is the same menu but using O built 2014-12-19.

While O's versions is changed, BR24Radar_pi is the same edition, 2014-12-19, in both pictures. The different background colour can be because they are not from the same PC, but as you can see the button corners are rounded and text is centred on the first.

I'm not saying for sure that the radar menu was changed in last commit, it can be it changed some commit just before.

Håkan

[Littlechay]

Originally Posted by bdbcat

We don't do head up mode. I think it should be on the Feature Request list if not already. The reality is, though, that very few boats have an interfaced heading sensor unless they use a relatively complicated muxing system.

Dave

I have a N2K system interfaced via an actisense NGW, works very well.. gives me heading along with other stuff from the Airmar PB200.

Chris

[RhythmDoctor]

Originally Posted by Littlechay

Heading, and COG, vary as the boat yaws (depending on the systems damping) causing the screen to rotate.

Many systems have a "course up" mode where the chart rotation is set either by the course currently active in a route or set by the COG (or heading if you have it) instantaneously when course up mode is engaged, and then this course (heading) is fixed.

This is gives a much more stable display, and is particularly useful when bashing upwind in short steep seas which constantly throw your bow off.

I downloaded a VDR plug from another thread and experimented with the "Filter NMEA course and speed data" setting. Setting this value to 5 seconds or higher provides significant damping which reduces the undesirable random rotation of the screen. You should try this and see if it eliminates most of your problem in course-up mode.

[Littlechay]

Originally Posted by RhythmDoctor

I downloaded a VDR plug from another thread and experimented with the "Filter NMEA course and speed data" setting. Setting this value to 5 seconds or higher provides significant damping which reduces the undesirable random rotation of the screen. You should try this and see if it eliminates most of your problem in course-up mode.

I don't have a problem, not sure why you thought that. I don't stare at my plotter when sailing; but refer to it as needed. I was just explaining that there are different ways of seeing course up, and head up and they all have a place.

But I have sailed with some who do. I once had a gentleman in quite a panic that we were about to park on the bricks, I urged him to look around him, we were in an area with about 1/2 a mile error on the charts when compared with WGS84.

Thanks for experimenting and thinking of me


Sent from my iPhone using Cruisers Sailing Forum

[RhythmDoctor]

Originally Posted by Littlechay

I don't have a problem, not sure why you thought that...

Sorry. I guess I misinterpreted this statement as being a problem report:

Originally Posted by Littlechay

Heading, and COG, vary as the boat yaws (depending on the systems damping) causing the screen to rotate.... when bashing upwind in short steep seas which constantly throw your bow off...

Since many people read these threads, then if others consider it a problem, then they can solve the problem by following my prior suggestion...or choose not to.

[Ptizef]

Originally Posted by bdbcat

JP...

Your OpenGL intel driver is just broken. The standard OpenGL function glGenerateMipmap() just does not work on your system. Produces black images. No surprise, I suppose. intel OpenGL drivers are well known to be faulty in many undocumented ways.

You might try to upgrade your OpenGL drivers, and see if it helps.

Please send me your OpenGL log entries again. I will simply have to disable blurring on this chipset. Looks like you ( and some other wretched intel graphics users) will get fogging instead of blurring.

Sorry
Dave

Dave

I got a younger driver and installed it but no change

I completely agree. Disabling blurring and get what you name "fogging" is perfect
for me.

here you are the log

many thanks

Jean Pierre
//
11:33:30 PM: Warning: unable to use NPOT texture for chart symbols
11:33:31 PM: OpenGL-> Renderer String: Mobile Intel(R) 4 Series Express Chipset Family
11:33:31 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
11:33:31 PM: OpenGL-> Texture rectangle format: de1
11:33:31 PM: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
11:33:31 PM: OpenGL-> Vertexbuffer Objects unavailable
11:33:31 PM: OpenGL-> Detected Windows Intel Mobile renderer, disabling Frame Buffer Objects
11:33:31 PM: OpenGL-> Framebuffer Objects unavailable
11:33:31 PM: OpenGL-> Using Depth buffer clipping
11:33:31 PM: OpenGL-> Using s3tc dxt1 compression
11:33:31 PM: OpenGL-> Compressed tile size: 128kb (6:1)
11:33:31 PM: OpenGL-> Minimum cartographic line width: 1.0
11:33:31 PM: OpenGL-> Minimum symbol line width: 1.0
11:33:31 PM: ChartDB Cache policy: Application target is 1024 MBytes
11:33:31 PM: Loading chart db version: V018
//

[cagney]

Dave

Feature freeze ...

Here is a potentially very dangerous "feature".....
If the GD value is value is missing, or stated as "UNKNOWN" in a kap chart header, OpenCPN will treat the chart as a WGS84 chart. No warning is given to the user......
I think there are two options. Don't load the chart and state why, in a log message, or load the chart with a warning similar to "overzoom".

There are quite a few older sets of charts floating around in the cyber-space, and it only takes one bad chart and an unsuspecting navigator for a disaster.
Read about a Mexican chart here Chart Info | Official OpenCPN Homepage.

Thomas

[Hakan]

Dave...
Concerning the dialogue box's loss of focus issue. For Info:

Since you seemed surprised that the last commit didn't had effect I've double checked I haven't mixed/merged up things in my repository and it's branches. So I made a new parallel clone and build only that without any of my adaptations. ->>>
Nope - the same result. Loss of focus in the dialogue boxes as before.
Håkan

[HappySeagull]

Originally Posted by cagney

Dave

Feature freeze ...

Here is a potentially very dangerous "feature".....
If the GD value is value is missing, or stated as "UNKNOWN" in a kap chart header, OpenCPN will treat the chart as a WGS84 chart. No warning is given to the user......
I think there are two options. Don't load the chart and state why, in a log message, or load the chart with a warning similar to "overzoom".

There are quite a few older sets of charts floating around in the cyber-space, and it only takes one bad chart and an unsuspecting navigator for a disaster.
Read about a Mexican chart here Chart Info | Official OpenCPN Homepage.

Thomas

Puzzle to me
If it were just the header GD value...which has been a mystery I have often remarked upon...
Note that all these show a shifted grid on a chart that was drawn to NAD27 (and very well too!)
Note that i took the liberty of changing GD from NAD27 to NAD83 and WGS84
Note that O is happy with these.

9:07:09 AM: GPS Watchdog Timeout is: 6 sec.
9:07:09 AM: Initializing Chart ..\..\..\..\ChartsTest\347501mercWGS84.KAP
9:07:09 AM: Initializing Chart ..\..\..\..\ChartsTest\347501mercNAD27.KAP
9:07:09 AM: Initializing Chart ..\..\..\..\ChartsTest\347501mercNAD83.KAP
9:07:09 AM: Getting .gpx layer files from: D:\KEEPERS\Navigation\OPEN CPNinstall+help\O-3.3.14Portable\layers
9:07:09 AM: New layer 1: MARKS_LightlistDatumCheck

Note that the Mark taken from the list of lights does not move, chart to chart, and neither do the grids compared.
I am not saying anything except as it seems to me with my charts issued in 1996 . I have my suspicions that this is some secret held in the Temple Of O code , and I Am Not Worthy..or the charts GD just describes the drawing and not the REFs or Plys

And, from the linkhttp://opencpn.org/ocpn/chart_info where the grid is compared and said to be "funky" I note
that O does an excellent job reading whatever she really is reading,and a shifted grid is not necesarily a reflection on accuracy of position per wgs84 and gps device with the (default )wgs84 datum.

[P_Dub]

Originally Posted by sailorF54

A shot in the dark (I have not checked the format)
006 or 060 instead of 06 ???

I discover the problem, t was an extra space after the word Québec that mess it up. It is a case sensitive.
Thanks and best regards.

[bdbcat]

Håkan...

Loss of focus...

There is still something strange going on here. I believe your reports, but they make no sense with respect to recent github commits.

You will need to do some snooping. With the latest commit, all is well on all my Windows systems, as far as I have tested.

Remember the cardinal rule of software bug tracking:
MINIMIZE the Environment..

1. Unload all plugins. I mean ALL Plugins.
2. find a way to test without parallel portable version.
3. Check focus loss on say Route Properties dialog.

and then, if still losing focus:

4. Without changing anything else, step back in time with git and find the commit that broke things for you.

If not losing focus, with current git master, add complexity until you do. PlugIns, alternate data sources, portable parallels, etc. One step at a time, taking notes. Leave the BR24 PlugIn until last, since it is the most suspect.

If I can't reproduce the problem, then anything I do is just shots in the dark.

Good Luck
Dave

[bdbcat]

Håkan...

Ooops, mea culpa.

git lied to me, which I have seen happen on a weak error prone wifi signal.

Even though

$git push github master

appeared to complete correctly, and make it upstream, my latest "commit" did not actually find its way into the github master repo.

So, you don't have my latest code.

I am currently down a rathole, so can't push right now.
But as a quick test, please comment out the line at chcanv.cpp:3847

//   cc1->SetFocus();

This should fix your focus problems temporarily.

Sorry for the mixup
Dave

[bdbcat]

Håkan...
Saturday, 2100 GMT.

Latest "loss of focus" correction now in github.

Let me know...

Thanks
Dave