OpenCPN Beta Version 3.3.2330 Released

[HappySeagull]

By the way-Mollymawk-New Toolbox works well-EZ for this usr.

[Douwe Fokkema]

Is this the place to report issues? If yes read on.

Environment: Win 7, HP Probook 4520s, I3, Intel Integrated Graphics.

Version 2330 starts OK. When switching OpenGL on it seems to function. Can display radar images with BR24radarpi, but issue also occurs with pi being loaded. Closing OCPN sometimes successful, sometimes crashes. Restart gives blank (white) screen, only title bar and positionbar show up. Starting OCPN 1606 cures the problem (and so does modifying the version number in the .ini file). After that OCPN 2330 comes up with the "warning messages" again and functions. Next time blank screen again.
Typical: when not working InitialdDIndex=-1 in .ini file, but resetting to 0 does not help as it is being set to -1 again immediately by OCPN when not working.
If I don't switch OpenGL on no issues, but can not use radar.


This issue does not occur on a later system with Geforce video.

[Littlechay]

I am seeing issues on CM 93 with some chart objects showing very very small and it seems more objects than before just showing as a magenta "!".

This screen-shot shows some tiny tidal current arrows (with a ! overlaid for some reason) and one of the peculiar "!" which is also some current info.

The objects in question are two things SE of Shag Rock and the one further out.

This is the Jan 2011 CM93 that floats around the internet

[Biggles]

Hello Dave,


I have been trialling .2330 at sea today. A few moans and suggestions:


The VMG dial in the dashboard does not work, even though the VMG in the active route leg pane does.


The GRIB pane is much improved but lacks a minimize button. This is annoying as the pane takes up too much chart space. Previously I would minimize and drag to the top left hand corner. It would also be great if there was a 'Now' button visible in the minimized pane to allow easy update of the data display. Would it even be possible for the program to auto update the GRIB data display according to the computer time?


I really missed the 'Navigate to Here' in the right click drop down menu. This was a great one click 'go to' function which now seems to be a more cumbersome operation involving dropping a waypoint the activating it. Why did it go?


Another thing that I feel could be improved is the ability to set the properties of an active route. I have several routes set up in dark blue with long dashes and 4 pixels. When I activate the route the colour changes to red and the route line becomes thinner and hard to see, especially in areas where there are previous track lines cluttering the chart. Maybe the active route properties could be tweaked to make the route more prominent as a quick fix?


As a single handed sailor who has to sleep sometimes, the one feature I would like to see in future releases is the ability to draw boundary lines which if crossed, sets off an alarm. Nobeltec VNS did this well, and it would be a very useful addition to an otherwise excellent program. Your handling of AIS is far better than any other program I have used or have seen, and in general OpenCPN is a joy to use. Thank you for all your hard work.


Regards


Ian Shepherd s/y Crusader (Amel Supermarau 2000)

[bdbcat]

Littlechay....

I see those objects, too. They look valid and important to me.

Not sure what the issue is, though. Is there a problem with them?

Thanks
Dave

[HappySeagull]

double-click em or right click choose "Object Query" and see what is important...zooming in can help click accuracy.
I've got lots of those ...doesn't everybody? Current arrows above but just about anything else the Hydrographers want to say about anything that normally bordered the old printed chart .You can tweak them away in Vector Chart settings using Mariners Standard checkboxes

[LeaseOnLife]

I remember deleting own-ship-tracks was slow. Now that we can record tracks of AIS-vessels, this is becoming more of an issue. See screenshot, deleting one AIS track, 107.77 miles long, 20000 points, takes 20 min on my old quad core. Is this just a bug, or maybe some filesystem problem on my linux PC?

Or... should tracks be stored outside of navobj.xml ?

Also, my OpenCPN often closes (crashes?) at the end of this process. Restarting OpenCPN finishes the deletion and does clean up navobj.xml

Anybody else seeing this?

Dirk

PS: the track is from Pilot Vessel CALIFORNIA, MMSI=366808340, recorded from the San Francisco TCP AIS stream, currently at 207.7.139.10:80

[cagney]

AIS tracks..... I just started testing, and came up with a few 30 M long tracks that was no problems deleting. The test continues......

Starting persistent tracking leads to more or less "garbage" values for "Speed" (to start with) "Average Speed" and "Time enroute".

Thomas

[LJH]

Originally Posted by LeaseOnLife

I remember deleting own-ship-tracks was slow. Now that we can record tracks of AIS-vessels, this is becoming more of an issue. See screenshot, deleting one AIS track, 107.77 miles long, 20000 points, takes 20 min on my old quad core. Is this just a bug, or maybe some filesystem problem on my linux PC?

Or... should tracks be stored outside of navobj.xml ?

Also, my OpenCPN often closes (crashes?) at the end of this process. Restarting OpenCPN finishes the deletion and does clean up navobj.xml

Anybody else seeing this?

Dirk

PS: the track is from Pilot Vessel CALIFORNIA, MMSI=366808340, recorded from the San Francisco TCP AIS stream, currently at 207.7.139.10:80

I just tried to delete a layer (22.3MB). First track had 94500 points it took 5 mins with "OpenCpn(Not Responding)" then 22 minutes with the Track Delete Window. Next track was 32000 points took 9:00 minutes. Then several small tracks. OpenCPN would often go (Not Responding) for a minute or two between tracks. All in all it was 45 minutes to delete the layer.

i7-2630 QM CPU, 8GB Ram running Win 7 Hope Premium SP1

Lyndon

P.S. I don't normally delete layers because they take to long. It is quicker to close OpenCPN and reopen it.

[LeaseOnLife]

Originally Posted by cagney

AIS tracks..... I just started testing, and came up with a few 30 M long tracks that was no problems deleting. The test continues......

Starting persistent tracking leads to more or less "garbage" values for "Speed" (to start with) "Average Speed" and "Time enroute".

Thomas

Currently Pilot Boat "San Fran" is on duty in the San Francisco pilot area.
MMSI: 366798310

I receive a AIS track entry in irregular intervals: ~6-30 sec

Let that run over night and you should have several thousand points.

[LeaseOnLife]

Originally Posted by LJH

I just tried to delete a layer. First track had 94500 points it took 5 mins with "OpenCpn(Not Responding)" then 22 minutes with the Track Delete Window. Next track was 32000 points took 9:00 minutes. Then several small tracks. After the last track was deleted OpenCPN "hung at (Not Responding) for 3 more minutes.

Lyndon

P.S. I don't normally delete layers because they take to long. It is quicker to close OpenCPN and reopen it.

Good (or not!), so it's not just me, thanks!

Dirk

[nohal]

Originally Posted by cagney

Starting persistent tracking leads to more or less "garbage" values for "Speed" (to start with) "Average Speed" and "Time enroute".

Thomas...
Remember that track is just a set of locations + timestamps, nothing else (we do not save any metadata with it), the speeds etc. are calculated, so if we receive 2 reports .25 miles apart, in 5 seconds, the speed looks like bogus for that leg. I see nothing wrong with averages for my tests.
Same with time enroute - it is simply the timestamp of the last recorded trackpoint - timestamp of the first one.

And yes, deleting tracks takes suspiciously long, I will have a look at it.

Pavel

[CarCode]

The last commit of today "Correct a small but persistent memory leak in OCPNRegion dtor." doesn't help much. There are still memory leaks with OCPNRegion here.
Gerhard

[bdbcat]

Gerhard...

More info, please, as usual...

Chart type?
OpenGL?
Quilting?
NMEA input alive, or simulating?

All this makes a big difference in the code paths, and resulting resource utilization.

Thanks
Dave

[nohal]

Originally Posted by nohal

Thomas...
Remember that track is just a set of locations + timestamps, nothing else (we do not save any metadata with it), the speeds etc. are calculated, so if we receive 2 reports .25 miles apart, in 5 seconds, the speed looks like bogus for that leg. I see nothing wrong with averages for my tests.
Same with time enroute - it is simply the timestamp of the last recorded trackpoint - timestamp of the first one.

And yes, deleting tracks takes suspiciously long, I will have a look at it.

Pavel

And I see a possible bug in saving an already existing ais route, but have to switch back from BBQ mode to confirm it


Sent from my iPhone using Cruisers Sailing Forum