Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 23-09-2015, 20:26   #466
Registered User

Join Date: Jul 2010
Location: Monastir, Tunisia
Boat: Amel Sharki
Posts: 1,774
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by rgleason View Post
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
Attached Thumbnails
Click image for larger version

Name:	Aus-North-Reef-line.png
Views:	102
Size:	10.0 KB
ID:	109750  
__________________

__________________
CarCode is offline   Reply With Quote
Old 24-09-2015, 03:06   #467
Registered User

Join Date: Aug 2010
Location: Oz
Boat: EX prawn trawler 14m
Posts: 100
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by RhythmDoctor View Post
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
Attached Files
File Type: pdf 08.09.15APB.pdf (10.5 KB, 15 views)
__________________

__________________
redog is offline   Reply With Quote
Old 24-09-2015, 07:15   #468
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,310
Re: OpenCPN Version 4.0 Released

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.
__________________
rgleason is online now   Reply With Quote
Old 24-09-2015, 15:41   #469
Registered User

Join Date: Aug 2010
Location: Oz
Boat: EX prawn trawler 14m
Posts: 100
Re: OpenCPN Version 4.0 Released

Quote:
Originally Posted by rgleason View Post
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
Attached Files
File Type: gpx newport to peal.gpx (4.3 KB, 17 views)
__________________
redog is offline   Reply With Quote
Old 24-09-2015, 17:22   #470
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,877
Re: OpenCPN Version 4.0 Released

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.

Code:
$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
__________________
bdbcat is offline   Reply With Quote
Old 24-09-2015, 20:13   #471
Registered User

Join Date: Aug 2010
Location: Oz
Boat: EX prawn trawler 14m
Posts: 100
Re: OpenCPN Version 4.0 Released

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
__________________
redog is offline   Reply With Quote
Old 24-09-2015, 20:52   #472
Registered User

Join Date: Jan 2011
Posts: 571
Re: OpenCPN Version 4.0 Released

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.
__________________
Please support OpenCPN by donating through Paypal!
RhythmDoctor is offline   Reply With Quote
Old 24-09-2015, 21:54   #473
Registered User

Join Date: Aug 2010
Location: Oz
Boat: EX prawn trawler 14m
Posts: 100
Re: OpenCPN Version 4.0 Released

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
__________________

__________________
redog is offline   Reply With Quote
Reply

Tags
enc, lease, opencpn

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN Beta Version 3.1.814 Released bdbcat OpenCPN 185 14-09-2012 08:43
OpenCPN Beta Version 3.1.802 Released bdbcat OpenCPN 158 14-08-2012 11:07
OpenCPN Beta Version 3.1.714 Released bdbcat OpenCPN 91 01-08-2012 18:08



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 21:28.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.