OpenCPN Release Candidate Version 3.1.1411 Released

[sbfreddie]

Originally Posted by stensmo

Please post a link to your build. I'll test it. My OS X Version is 10.8.2.

Stensmo:
I have no way to post anything. I don't have a Web site and no access to anyplace on this forum.
I you have any suggestions let me know.

Thanks,
Freddie

[Gilletarom]

Hello Dave,

Just a little bug. Just a problem of refresh (perhaps)

Open Route manager
Load a track
Use context menu "Reduce data ..."
Choice by exemple "<100 meters"
Said Ok

The new track as the same length that initial track.

But this is false.

It is necessary to open the properties window of the track and then shutdown immediately this properties window and then the route manager is refreshed and the length of the new track is now correct.

B.R. Gilletarom

[stensmo]

Originally Posted by sbfreddie

Stensmo:
I have no way to post anything. I don't have a Web site and no access to anyplace on this forum.
I you have any suggestions let me know.

Thanks,
Freddie

Upload - Speedy Share - upload your files here

[CarCode]

Originally Posted by stensmo

Upload - Speedy Share - upload your files here

Actually the app bundle of Freddie points to the wrong library path. When this is fixed a link to the working bundle app will be announced.

[cagney]

Originally Posted by P_Dub

Here it is the ini file........
P_Dub

[PlugIns]

....

; with exception though of some high speed vessel ( say 20 knots or so ).

To me this indicates that the feature is actually working for you.
You say nothing about how you view the targets. What scale, for example. The cog line is actually a position predictor. If you zoom out enough, all the position predictions will fall within the colored ship triangle, and appear not to have a course line predictor.
So if you don't see a course line in front of a vessel, zoom in!

Thomas

[P_Dub]

Thomas, I did zoom in to the extreme limit and still no course line. I have increase the time from 15 to 60 minutes and still no course line. So what is next.
P_Dub

[cagney]

Originally Posted by P_Dub

Thomas, I did zoom in to the extreme limit and still no course line. I have increase the time from 15 to 60 minutes and still no course line. So what is next.
P_Dub

Please publish the data file you are using, or record a bit of your live stream, if that is your source. Use the VDR plugin.
What happens if you use OpenGL?

Thomas

[HotRod]

Originally Posted by SethDart

We've now two instruments: "Compass" and "GPS Compass". The former displays heading (magnetic or true) if available, while the latter displays COG.

Current translation file nb_NO doesn't contain the string for "GPS Compass" thus it's not translated. Can you take the latest version of plugins/dashboard_pi/po/dashboard_pi.pot and fill the blanks?

You can send me the .po file and I'll push it.

Thanks,
Jean-Eudes

Here you go... New translation out of the dashboard_pi.pot.
Check the attachment.

[bdbcat]

P_Dub....

I think you have the

Options->Ships->AIS Targets->Moored target max speed

set too high. Maybe 20 kts?

COG arrows will not be shown for target COG less than this value.

This should be set to something like 0.2 knots, to avoid unwanted COG arrows for very slow targets.

Dave

[Icnoships]

Dave
the 1411 beta is looking fantastic on 10.7 lion in 64 bit.
compiled very cleanly using the gcc-apple-4.2 compiler just a half dozen warnings.
using Macports and wx 2.9.4.1.
The options window patch appears to be working ok but wx debug is throwing up this alert when you click to open the options window, click no & window opens and all is normal - c below

The whole feel of O is much more responsive, with the exception of chart redraw it has slowed to a crawl using just cm93.
Deleting all charts from database and just zooming and moving around on the base map is extremely fast.
Not sure if it has something todo with this strange behaviour in the log - c below



thanks
mo

[reflectionsv37]

Ahoy Dave!

I just downloaded and tested the Furuno upload again. What worked in before in 3.1.1405 is not working now. There is still a problem, but I think it is very,very minor.

Using a 6 waypoint route that worked in the 1405 version. I compared the NEMA output for both versions. The only difference is in the GPRTE segment. In 1405, each waypoint in the sentence had a leading space before the waypoint name:

$GPRTE,1,1,c,01, TST001, TST002, TST003...

In the 1411 version it is:

$GPRTE,1,1,c,01,TST001,TST002,TST003...

My documentation says, "length of each waypoint name is fixed to 7 bytes.
1st byte:Skip code '-'(Hyphen) = Skip ON, Space Code = Skip Off"
After 2nd byte: Waypoint name (fixed to 6 bytes)"

I assume the skip code of '-' would cause the Furuno to "skip" that particular waypoint. In any event, I'm certain restoring the leading space will correct the problem.

I tried creating a route with waypoints that included a leading space for testing purposes(and OpenCPN let me do this), however, when the upload started, the Furuno repeated beeped and displayed "Illegal Name" and none of the waypoints were uploaded. It appears the Furuno doesn't like waypoint names that begin with a space. Do to this, I couldn't do any further testing. Sorry!

I did do some testing with routes up to about 20 waypoints and checking the NEMA data stream, everything looked perfect with the exception of that leading space.

I was not able to determine if 8 waypoints per sentence will work. My documentation indicates there may be an 80 byte limit to NEMA sentences. With the $GPRTE string, fixed segments 1-4 of the sentence and 8 waypoint names, would be exactly 80 bytes. That does not include the <CR><LF> at the end of the sentence. I don't think that will cause a problem, but I'm not certain.

Let me know if there is anything I can do to help. Sorry for not seeing the new version was out until now. I'm off to see how I can get myself set up to get notified by email when a new version is released!!!

Gene

[bdbcat]

Gene...

Furuno radars are great. As for their other electronic stuff, well....

Anyway, OK, another RC coming soon.

Dave

[bdbcat]

Icnoships...

1. Errant assert dialog on Options:
Please edit options.cpp::SetInitialSettings(). Comment out (one-by-one) each of the lines that has a format specifier in it. Rebuild and test Options.

For example, the first is at line 1858.

    s.Printf( _T("%d"), g_COGFilterSec );

The next is at line 1860, etc.

We are looking for the one that induces the Assert dialog. When you comment it away, the assert should not appear when you click Options..
There may be more than one offending line.

This is a slow but sure way to isolate the offending instruction, since the assert dialog does not tell us exactly which instruction is at fault.

2. Performance with cm93: How does it look with BSB charts? Sluggish with cm93? Can you give us some relative idea? Also, a log snippet showing cm93 cell access might be instructive.

btw, the funny log entries are part of the autosave system, activated every 5 minutes. Should have nothing to do with zoom/pan performance.
I'm looking into that, just to avoid log flooding.

Thanks
Dave

[Fishstretcher]

I am noticing slow redraw and 100% CPU utilization when I enable openGL and overzoom over the base map. It appears to only occur with openGL enabled. Not sure if this might be related to Icnoships' problem. It doesn't repeat when overzooming over an ENC chart. Although the processor does bog down and redraws slow down, they don't grind to a halt.
This is on a WinXP 32 bit install with a 2.13 GHz Pentium M and ATI FireGL V5000 openGL enabled card (but an old one, circa 2006- it might only support early versions of the openGL spec)

[Fishstretcher]

I just checked- I was in a land area of an ENC chart over land. The same openGL performance hit happens in 3.02 at zooms of 128(ish) on an ubuntu 12.04 install on a dual core Atom netbook with intel 945 chipset. So the phenomenon isn't new.