OpenCPN Version 2.1.0 Beta

[PjotrC]

Originally Posted by yachtvalhalla

With the AIS settings shown in ais0.jpg I get the display with anchored boats having a blue 'ball' (but shouldn't it be black?),

However there are some that are anchored and the 'ball' doesn't appear as shown in ais1.jpg and ais2.jpg.

Yes, the ball should be black. Seems an excellent idea

In ais2.jpg the vessel selected (Tanker ARCHIMD) is broadcasting AIS status "underway", and is displayed accordingly. Do you have a case where navigational status does not match display?

Tomorrow I am moving back on board, so I will have an opportunity to test live AIS soon... only had a quick look now.

I attach the symbology for ClassB, AtAnchor and Lost.

Piotr

[PjotrC]

Ooops, sorry for the attachements above.
The thumbnails should be better visible.

Again: ClassB, AtAnchor, Lost.

P.

[idpnd]

Originally Posted by PjotrC

Ooops, sorry for the attachements above.
The thumbnails should be better visible.

Again: ClassB, AtAnchor, Lost.

The "at a glance" anchor ball symbol is a great idea actually. Please permit me to express my thoughts regarding the proposed symbols Pjotr: The class B bracket would be a bit large, and aren't targets usually colour coded by class? Same for lost targets, shouldn't they turn grey or something?

But there is an annoyance in that Nicolle lets the computer sleep or hibernate sometimes and the track doesnt continue

Whilst your computer is hibernating, it doesn't tend to do any gps tracking at all AFAIK.

[PjotrC]

Originally Posted by idpnd

The class B bracket would be a bit large, and aren't targets usually colour coded by class? Same for lost targets, shouldn't they turn grey or something?

More explanation needed... the bracket shows _current target_, for which there is a Target Properties dialog open. The Class B itself is distinguished by the V-shaped transom.

The marking of lost targets follows IMO recommendation for ECDIS. This does not specify colour-coding. Colour-coding, that many land-based systems made popular, does not work well at night, shapes are better.

[idpnd]

Thanks for the explanation Pjotr. I think I got that mixed up with the GPS colour coding..

[blubaju]

138° 0.11nm, all my marks have moved on CM93, - or maybe my marks and waypoints still carry the same ccoordinates, but the charts in oCPN moved in opposite direction.

Am I the only one ? Very confusing

[cagney]

Sounds no longer seems to work. For example "Test Alert Sound" in the AIS tab.

The difference in performance between Linux and Win (don't know about Mac) has been discussed elsewhere, and is still apparent in 2.1.0. The update for the cursor position is almost instant in Win but has a lag of almost 1 sec in Linux(Kubuntu 9.10), the same goes for panning through click & drag or arrow keys.
There is not much difference if the opencpn process has real-time priority or not.
Anyone with ideas how to fix this ?

Thomas

[idpnd]

Originally Posted by cagney

Sounds no longer seems to work. For example "Test Alert Sound" in the AIS tab.

The sounds have always made just a weird hissing noise at my end

[cagney]

Originally Posted by bdbcat

Dacust....
................
Not sure how we could distinguish between topos and photo charts, though. They look like BSB raster charts to ocpn.

Any ideas?
..................

Dave

One way, would be to have our own extension to the kap file header that allowed some kind of quilting priority or quilting "groups". This could allow user defined options under "Select Chart Types for Quilting".

Thomas

[PjotrC]

in OpenCPN 2.1.0

1. import the attached GPX file (the area is Central Baltic)
2. delete the track
3. observe the leftover circle mark on the chart
4. exit OpenCPN cleanly
5. restart OpenCPN - circle is gone (that's good, at least)

but...

1. import the attached GPX file
2. open Track Properties dialog for it (does not matter if it stays open, or is closed with Cancel or OK)
2. delete the track
3. observe OpenCPN 2.1.0 crash

OpenCPN 1.3.6 original (which removes duplicate trackpoints) and OpenCPN with patches 1-7 (which does preserve all trackpoints) handle this well.

I had this bug when tweaking the track handling. It is related to the duplicate trackpoints. Most likely it reappered with reappearance of duplicates removal.

However, I would like to present a case for keeping consecutive trackpoints with same coordinates:

- it is legal GPX, that can be generated by other systems (eg. automatically from LOGBOOK entries)
- if tracking is defined as time-interval-controlled, being stationary will produce duplicate positions, but with different timestamps. In 1.3.6 there were no timestamps for trackpoints. I think this is historical data, that may be worth preserving. With timestamps, it is hard to say if it is the arrival or departure which counts.

[bdbcat]

Cagney....

The slow cursor tracking in GTK is by design. Much earlier, I noticed that the system call to update the displayed cursor position in the status bar was very slow. Not sure if this is a wxWidgets problem, on in the gtk library. Anyway, I added a timeout so that I only update the reported position in the status bar if the cursor has been stopped for X milliseconds.

Presently, X is 1000 msec.

Next Beta (tonight) will set x = 2 msec. I've tried it locally, seems OK now. Maybe fixed along the way by a Widgets update?

You could try it yourself locally.

In chcanv.cpp, around line 1250:

        pCurTrackTimer = new wxTimer ( this, CURTRACK_TIMER );
        pCurTrackTimer->Stop();
        m_curtrack_timer_msec = 2;    // was 1000

What other performance differences between gtk and msw do you see?

Dave

[dacust]

Originally Posted by cagney

One way, would be to have our own extension to the kap file header that allowed some kind of quilting priority or quilting "groups". This could allow user defined options under "Select Chart Types for Quilting".

Thomas

That could work. But I think it would be better to have a method that would work for purchased charts or any charts that were not produced specifically for OpenCPN.

So, basing it on a directory structure would make more sense to me. It would be nice for the user to be able to define it themselves. So, they could define a chart type and the beginning directory for that type. Then, they could pick from that list for the chart types they wish to include.

-dan

[cagney]

Originally Posted by bdbcat

Cagney....


What other performance differences between gtk and msw do you see?

Dave

Thanks Dave, that change made all the difference.Works well, no problem.
Is there a similar value to make the panning snappier?

Dacust, I agree that basing this on a directory structure, would be better and simpler.
On the other hand we know how to change any bsb 2 & 3 chart....., but it's a wee bit complicated!!!


Thomas

[HamishB]

Originally Posted by bdbcat

Anyway, I added a timeout so that I only update the reported position in the status bar if the cursor has been stopped for X milliseconds.

Presently, X is 1000 msec.

Next Beta (tonight) will set x = 2 msec. I've tried it locally, seems OK now.

the human eye can only just make out 60Hz flicker (lighting tube, CRT monitor refresh), and it is smooth by 75Hz. TV and movies get along at 24-28Hz without any of us noticing. So it is just wasted cycles* to refresh a visual display any faster than that.
[*] (aka battery life)

1/20 = 0.050000
1/24 = 0.041667
1/25 = 0.040000
1/60 = 0.016667
1/75 = 0.013333

So 50ms or even 100ms seems like a good place to start.


regards,
Hamish

[bdbcat]

PjotrC....

I think I agree with your logic regarding co-incident trackpoints. As they have different timestamps, then there is information contained in the record that I do not like to discard. This info can be reviewed with TrackProperties dialog.

Also, and this is critical, re-exporting the track produces a gpx file containing the same information as the original import.

Altogether a good idea.

So, next Beta captures gpx tracks exactly as presented.

Thanks for the tip.
Dave