OpenCPN Version 4.0 Released

[CarCode]

Originally Posted by rgleason

Ran it in 4.0 and found your route in Aus off North Reef.
Turned on tracking and perhaps you can tell me how this route compares to what you experienced. I am not sure where the problem with the change actually occured.

--Any ideas?, anyone?

What are these weird chars ° in your bottom line? Is unicode switched off?

Gerhard

[redog]

Originally Posted by RhythmDoctor

I think I know the problem. I have had it before, and fixed it.

You need to recalibrate your autopilot by driving around in circles. Look it up in our instructions.

The calibration method constructs an electronic correction table for magenetic deviation. It need to be redone every year or so.

What happened is that your boat oversteered because of magnetic interference on your boat.

RD
I will give it a try.

What perplexes me is the cycling of left and right in the navigation window this is coming from O and my AP does not feed any info to O.

I have pulled the first 15 consecutive APB sentences out of my VDR and posted.

You can see that the XTE bounces from L to R.

All the time this should be R as my boat is to the left of the route line.

cheers Redog

[rgleason]

Redog, I believe we need the routing too?

I have region and language set normally. English.
Have not made any changes. If the graphic is not showing properly perhaps it is a badly formed graphic.
However it does show on the CF forum.

RD good idea. Like the donate line.

[redog]

Originally Posted by rgleason

Redog, I believe we need the routing too?

I have region and language set normally. English.
Have not made any changes. If the graphic is not showing properly perhaps it is a badly formed graphic.
However it does show on the CF forum.

RD good idea. Like the donate line.

Rick
Here is the route you requested
Redog

[bdbcat]

Redog...

I think this is a legitimate OCPN bug. I looked at the VDR data, and the internal OCPN logic to calculate the L/R direction for the APB sentence. And this is what I found:

First, the extract I studied.

$ECAPB,A,A,0.06,L,N,V,V,259.0840,M,009,261.1978,M,261.1978,M*27

$GPGGA,005101,2710.9678,S,15307.3762,E,2,10,0.80,16.62,M,40.179,M,,*6C
$GPRMC,005101,A,2710.9678,S,15307.3762,E,6.6995,256.809,080915,,*31
$GPGGA,005101,2710.9667,S,15307.3750,E,1,11,0.80,23,M,37.9,M,,*4B
$GPGLL,2710.9668,S,15307.3746,E,005101,A,A*5C
$GPRMC,005100.317,A,2710.9677,S,15307.3741,E,006.7,255.2,080915,,,A*7C
$ECRMB,A,0.057,R,008,009,2710.910,S,15305.646,E,1.543,272.107,6.694,V*12
$ECRMC,005101,A,2710.967,S,15307.375,E,6.694,254.349,080915,10.916,E*48

$ECAPB,A,A,0.06,R,N,V,V,259.0840,M,009,261.1907,M,261.1907,M*39

1. The VDR stream contains multiple sources of Lat/Lon. Normally OK, unless...
2. The course to be steered is close to due west or due east, and the ship is not very far from the destination waypoint, and the Lat/Lon varies slightly from the different sources. As in your route...
3. In this case the math in OCPN nears an asymptote in a trigonometric function ( atan2(y,x), if interested), and the result of the calculation becomes unstable.

There is a fix, but I'll need to consider what other unintended consequences may come of it. This particular piece of code has been untouched in OCPN for about 10 years, so obviously the problem does not come up often. Don't want to be too hasty...

Anyway, there it is. Thanks for the heads up. Definitely on my TODO list.

Dave

[redog]

Dave
Thanks and as rgleason said and has been said so many times before!

"This is why a good sharp lookout is needed"
cheers Redog

[RhythmDoctor]

Dave - I'm sure you know the best ways to fix it, and given time to mull the unintended consequences you will select the best one. But this brain-teaser is too good for me to resist, so I'll offer my unsolicited advice. I think the root cause is the redundant sources of GPS data from different devices. I've often worried about this affecting my own system, because I've seen in the NMEA debug window how OpenCPN becomes confused with redundant sources. Perhaps you should put in some logic to force OpenCPN to ignore the lower priority source when it receives redundant info? This could potentially clean up a number of possible issues. Of course, that still leaves the issue of what to do if the user has the same priority for both inputs, so maybe you should add something that forces the user to select unique priority numbers when setting up the inputs.

redog - The reason I suspected the autopilot calibration issue is because the way control logic works in the AP control head. I really don't know for sure how it works, because each brand of AP is different and that logic is proprietary. But I have designed control logic before, and if I were designing an autopilot, I would have the autopilot steer the boat to the corresponding BTW (bearing to waypoint) as an initial guess. Then, it monitors XTE over time and if it's increasing (due to side currents or numerous other factors), it tweaks the heading from the calculated BTW to get the XTE to gradually reduce to zero. If your AP is not properly calibrated for magnetic deviation (and/or the magnetic variation is not properly provide to convert from magnetic to true), the boat's initial heading will be wrong (though it should eventually correct as the OpenCPN reports an increasing XTE). A properly calibrated AP will result in the boat tracking properly immediately after turning to the next waypoint, with minimum over/understeer.

[redog]

RD

To help in this situation, all of my sources are set by priorities, as I have in the past been able to fool "O" with endless loops of data via UDP, once my GPS had been disconnected.(not having filters in place, quite a trap for new players)

Current settings
Priority 9 localhost GPSD IN accept all data (from rooftop puck)

Priority 6 network UDP IN reject AIVDO (from AIS unit) Output Drop AIVDO AIVDM(backup computer)

Priority 4 USB1 In accept all data (from echosounder/GPS) Output Transmit RMC ECAPB(to radio and AP)

Each one of these should kick in if the higher priority was to fail.

Maybe someone can see an error in my thinking here.

RD the second part of your post
The AP has its own fluxgate compass which I check regularly against the magnetic display in "O" and compass.
This does show slight variations through the quarters, but the manufacturer says within the units capabilities.

I have always noticed acceptable turns at mid waypoints.
This was however a new route and the first time used in its entirety, as traffic normally dictates manual steering at this location.

Thanks for all the input.
I will trust Dave's intuition to solve this one.
Redog