Track length measurement issue OpenCPN 4.0

[tedcoats]

Hi,
I have been using OpenCPN for some time and have nothing but praise for those who have made such a system freely available to the boating community..
I recently upgraded to 4.0 which is running on a MS Surface Pro2 with GPS positions provided by a Globalsat BU353S4 - a pretty standard arrangement.
I have been recently cruising by day, anchored at night, and recording my track length daily, and restarting the track each night, so as to easily sum the total over a cruising holiday.
I noticed that sometimes the track length is much longer than can be real - up to 3 times the measured length - using the measuring tool on top of the track and well zoomed in.
Also the GPX as seen in the track properties window has a couple of large values - legs 0 and 345 in the attached GPX file. These survive being transferred to a desktop running OpenCPN 3.3.2410 - my interpretation is that the GPX file is written with errors although it is hard for me to see issues with the file itself.
Tracking precision is set to medium - if that is of any consequence.
I do note also that when zoomed well in and looking at the track on the screen, there are occasional points where the track is duplicated - the whole thing may be duplicated in fact, but several points along the track show a slight divergence between two or more legs.
With respect to the attached file, the track length showing in the tracks tab of the Route and Mark Manager window is 91 Nm, while the measured length on the chart is 33.3 Nm (which I don't doubt). Subtracting the large values of 24.22 and 24.30 still leaves 42.48 Nm - longer than can truly be the case.
The actual tracking in use - ie vessel position on the chart on-screen - has always been completely accurate with no jumping around to indicate something with the GPS puck.
Anyone else with these sorts of issues? I am always completely open to inadequate setup or something else on my part.
A small matter in an otherwise superb package - helped hugely by the enlightened approach taken by LINZ - our provider of charts locally here in New Zealand.

Cheers
Ted

[cagney]

Ted

I do observe similar things.
Look at the track of the vessel "Malaga". It's definitely tripled in length.
The distance of the three longer legs are about 11M/each.
The computer was left unattended, the screen switched to a different console. From tty 7 to tty3, for about an hour and a half. The pictures shows what happens when the program updates the screen.



Notice Time en-route and speed below.


AIS MALAGA (375752000) 2015-02-12 22:02:53.gpx

Thomas

[tedcoats]

Thanks for that Thomas..
I get a similar (but not so extreme) error in reported speed as well.

Cheers
Ted

[nohal]

Ted, Thomas...
Any of you happen to have the NMEA stream recording from the same time? The position is obviously quite off for some of the route points. We now have to find out why...
Do you have checksum check enable for the data input supplying the position info?
The speed is totally irrelevant - it is calculated from time and distance, so when you jump 12 miles in 1 or 2 seconds, it is obviously a nonsense, we have to find the reason for the jump...

Thanks

Pavel

[sy_gilana]

I used to have a problem like this with a different GPS, I went through all the points in the track and found some "hops" where the position went off by 10 miles or more, and then the next point was a logical continuation of the track. The total mileage was of course including the "detours"
Fixed by changing GPS type (Garmin GPS 16X) not the puck.
I think NOHAL is on the right track, pardon the pun.

[tedcoats]

Hi Pavel,
I would only have the NMEA stream if it was recording unbeknown to me. Where would I look? The example I give is for the last recording I have made so it is unlikely that the relevant time period will have been overwritten.
Yes the Control Checksum box is ticked - so operating.
I did have the course and speed data filtered - period 5 seconds, but not at the time in question.
Yes the position is off - but off along the line of travel, certainly not randomly as that randomness would be very plain to see in the track recording. And as I say, this is visible in the recording of the track and not visible at the time the vessel is travelling.

Is there any other data or logfiles which may be of use to you?

Thanks for your interest - and help.

Cheers
Ted

[tedcoats]

Hi Gilana,
Thanks for your input. I do think that the GPS is reporting correctly - as I reply above, if there was any random result coming through it would be very clear from the track "hopping" randomly away from the actual position and then returning to the projected line of the prior track. Besides, it is extensively used as an anchor alarm on a sub-30 metre radius and that would surely expose the errors you experience.

Cheers
Ted

[nohal]

Ted...
What I need is the recording of the raw NMEA stream using the VDR plugin But just in case there would be jumps as the ones Thomas was showing. Not your case.
What's very interesting on your GPX file is that the whole track is repeated twice there (reading the GPX file there are two trkseg elements, containing exactly the same points with equal timestamps) - if you look at the detail in opencpn, Leg 345 is a jump back to the beginning and exactly the same track is repeated once again.
The question is: How did the track get duplicated?

Puzzling

Pavel

[cagney]

Pavel
No problem to record, as it's just the well known "Baltic"- nmea data stream.
I'll have no problem repeating this. I see the problem regularly, not just for one vessel, but for many targets, during the described circumstances. It does not happen as long as O is shown on the screen. It's observed after a screensaver, after using a different program for some time or as already said, using a different virtual terminal i Linux.( I have not tested on Win but, I can. if required).

Thomas

[tedcoats]

Hi again Pavel,
I have been through the various tracks which show this behaviour. Most do over the time range I have looked at. I have attached other recent GPX files which may help.
By the way, why is there an initial entry (as Leg 0) of some distance - often 40Nm or even more?

Now that I come to look more closely, I really agree - very puzzling. Initially I thought it was due to a very bumpy ride across Cook Strait, but no, these files reflect all kinds of conditions, mostly benign.

Cheers
Ted

[nohal]

Ted...
All the same story - the tracks are there twice, I will try to simulate it, but have never seen it before... Anybody seeing something similar?
The first "leg" is the distance from current boat position - 9000 miles with your tracks in my case right now

Pavel

[tedcoats]

Hi Pavel,
I agree that the bogus leg 0 is the distance from the current boat position to the beginning of the track. I also now see that with Track1 the inserted value at Leg 345 is the straight line distance from the start point to the end point of the track. I haven't checked the others.... but will.

Cheers
Ted

[tedcoats]

Pavel,
And they do -

1. Leg0 is the distance from the track start to the current boat position
2. Leg ((n-x)/2) is appended - the straight line distance track start to track end
3. Then the entire track is repeated to produce a track of approximately double the number of legs actually recorded

x seems to vary according to the number of legs in the track.

Agree?

Ted

[RhythmDoctor]

I have seen similar issues with tracks recorded on my Garmin GPS and imported into OpenCPN. The first one or two points are off, usually reflecting the movement from the last time the GPS was turned off to the point where it was turned on again. This has happened for many years, with every version of OpenCPN (since they all come from the same GPS).

The solution is simple - use the "Split" button to clip off the errant points. I never thought much of it, because it was a GPS issue, not an OpenCPN issue. I'm just glad OpenCPN had the Split feature so I could edit the track.

[tedcoats]

Hi RhythmDoctor,
I agree that editing tracks in the way you describe is valuable in OpenCPN, but what I am highlighting is OpenCPN itself writing the track twice.

My experience with Garmin units is the same as yours - that they send an old position and a (sometimes long) leg to the new position - or nearby as it homes in to a good fix. I notice the same thing with the Globalsat unit I use - powering down OpenCPN or going into standby with an anchor alarm set will commonly trigger the anchor alarm when you power up again.

While it could well be tidied up by editing the double writing behaviour to the track record I observe must relate to my setup alone (which I doubt) or be more widespread at least with OpenCPN 4.0

My question - and Pavel's - is are there others out there seeing the same thing?

Cheers
Ted