I love using the nav setting on my autopilot, which normally keeps the boat within .02NM of the proper course to the active waypoint. In the past I had some wild course swings on nav that were finally traced to a NMEA feedback loop.
I still have one situation where I get wild course swings. Many times (but not always) when following a route, I will reach a waypoint, and the boat will make a dramatic turn way off course before correcting itself and coming back to the proper track line. I thought it was due to the large error in the steering compass.
A few days ago I fixed the compass error. I used nav to go to one waypoint, then canceled and selected a route in MacENC before switching back to nav on the autopilot. When I reached the next waypoint I should have turned from roughly 110° COG to 90° COG but the heading on the autopilot was at 31° by the time I switched from nav. After putting the boat back on the proper course I switched to nav again and the autopilot display instantly started dropping. I gave up on nav for a while.
About 10 minutes later, I tried switching to nav again. This time it steered the boat almost perfectly along the route, through a sharp turn of more than 100° and finally into the harbor channel to the point that .02NM was too much error to let it stay on nav. While doing the sharp 100° turn the boat overshot the track line, spun around almost 160° to starboard, then quickly corrected back to port to settle onto the new track line. The overshoot went to .07NM XTE, but when the boat corrected back to port it only went to .02NM XTE. Other than the one sharp turn, all of the waypoint turns occurred almost exactly as one would hope.
What could possibly be wrong to make the boat turn dramatically off course at one waypoint, yet 15 minutes later allow the laptop/autopilot to steer the boat almost all the way to its harbor stall? This behavior occurs at a different time than it did with the NMEA feedback loop. The feedback loop caused sudden swings while traveling in a straight line and this problem only occurs when advancing to the next waypoint on a route. I thought it was related to the large discrepancy between the steering compass and the calculated course, but now the steering compass is within a few degrees of MacENC's magnetic COG.
2 things come to mind:
1. Make your waypoint arrival circle smaller. When crossing the arrival circle with the "Auto Next" function selected, a new BTW (Bearing to Waypoint) to the next waypoint is immediately calculated from current position, NOT from the waypoint you were steering to.
2. If you have a waypoint activated in MacENC but you're NOT using the Autopilot to follow it ("Track" with Raymarine gear "Nav" with yours?) i.e you are just on Auto or hand steering, any crosstrack that is built up from the time you activated the Waypoint in MacENC til the time you put the Autopilot into "Nav" will immediately be dealt with by your Autopilot. This could make for some large course corrections. The way to deal with this is to reset the Waypoint by selecting it in the Waypoints or Route panel and hitting "Go To" again (a new BTW is drawn with your crosstrack at zero), THEN go into "Nav".
Remember, all MacENC is doing is sending out "direction to turn" for new waypoints and then crosstrack error and BTW for the Autopilot to follow.
.....if there are intermittant errors coming from the fluxgate driving your Autopilot, that could also explain the issue.
I did make the waypoint arrival circles smaller. This problem is happening when I'm using nav, so there isn't any XTE built up, beyond the ordinary minor course variation. This is only happening when I reach a waypoint on nav and MacENC switches to the next waypoint, so it is hard to imagine that the fluxgate is intermittently going bad at exactly that moment. Further, the magnetic heading data from the autopilot and MacENC are in agreement while this happens.
Though I see this problem when switching from one waypoint to the next, it is not strictly true that the problem is isolated to that precise situation. Some times I see it happen when I first switch to nav, immediately after hitting goto (no XTE yet). When it happened a few days back, I had been on nav only 7-8 minutes before the waypoint advanced on my route. I could see that MacENC was sending new headings in a smooth steady fashion with XTE increasing sharply from zero. It even stopped momentarily, for example going to 70° when it should be 90°, and after some XTE was generated, it decided to change the heading to 30°. I steered the boat back to the proper course with XTE at zero again and switched to nav, and it immediately veered back toward 30°. After steering the boat along the route line for another 10-15 minutes, I switched to nav again and the problem was gone. The boat then steered on nav literally almost into its harbor stall.
The one thing I see in all of this is a time component. It seems that the problem only exists during the first 20 minutes or so of following a route. The autopilot doesn't do anything unexpected at any other time (i.e. not on nav). MacENC will eventually correct itself and come back to the original course line if I have enough room to let it do so. While this strongly resembles the action I saw with the NMEA feedback loop, it happens at a different (nonrandom) time.
I've seen this happen dozens of times. The impression that I get is that there is a data table somewhere and it takes a certain amount of time to overwrite the old data. It is like MacENC needs to calculate some compensation to account for XTE before it can follow the route accurately. One thing I haven't tried is testing nav to a single waypoint vs a route. Every time that stands out in my mind I was following a route.
When ever a waypoint is activated (i.e. Goto) either manually or automatically XTE (Cross Track Error) is reset to 0. One thing that comes to mind is possibly there is so much NMEA data buffered up in a multiplexer or in the autopilot that it is lagging behind what MacENC is displaying. To minimize the amount of NMEA data sent to the Autopilot make sure "Autopilot Only" is checked in the GPS panel Settings drawer.
"Autopilot only" is indeed checked in the GPS panel. The multiplexer is a Shipmodul 41USB and you would know far better than me how much data can be held in the buffer. Do you know of some way of purging the multiplexer buffer as a test?
The autopilot is a ComNav 1001, which is an exceedingly common model in this region. Oddly, I don't know of anyone else who has rigged a computer to a 1001 to use the nav function so I don't know if it could be something inherent in the autopilot.
It's quite sloppy here today, but as soon as I can get back out I'm going to experiment with a single waypoint vs route. Both cases use the nav function but I can't recall ever seeing a problem going to a single waypoint. I can also kill the only piece of electronics that could conceivably cause a feedback loop.
hmmmm, the 41USB has no filtering capabilities, I think you are returning the Autopilot stream right back to MacENC via the ComNav feed into the mux....feedback loop
Nice try, but the ComNav 1001 is rx only.
yeah, just looked up your manual....
any other path for the Autopilot stream to come back on?
what are you using for a GPS source and does it go thru the mux?
what all is going thru the mux?
Is this on a sailboat or a powerboat? On my autohelm (pre-raytheon) I can tweak how the autopilot responds to changes so that it doesn't overshoot when turning, or at least it doesn't overshoot as much as it used to before coming back on course. I'll have to look at the manual to see what they call the setting, but the diagram that I do recall demonstrates your issue.
FWIW just this week I was on a boat with a (fairly new S1 series Raymarine) autopilot that was just way too abrupt. A course change of 10 degrees in any direction would result in a wild swing of at least 30-40 degrees in that direction, then a (sinusoidal decaying) correction. It did not appear to be a fluxgate (because fluxgate did show the heading as it was, i.e the abrupt swing and all). It was not one of the settings either (I am somewhat familiar with Raymarine autopilots and went through all the settings including the re-initialization). Something "else" made it do that - but what I do not know (and I left it at that since it was not my boat).
This probably does not help, but it can add another point to ponder. It did help me to input course changes one degree at a time though, which may be a nice feature for autopilot controlling software - feeding new bearing to the autopilot incrementally over a period of time.
Hi everyone, & fish to live,
At the risk of being totally wrong, I enquire if VHF radio was used to chat during the off course sessions?
Reason to say this is that I had an Autohelm 3000 can type which dashed off to port when the TX was keyed. Had to reroute the feeds differently to the radio particularly and screen everything.
Probably a red herring!
Sea Slacker,
That is usually caused by too much rudder gain on a raymarine pilot. Try reducing the value of that calibration parameter.
Rudder gain control was the first thing I tried. It had no perceptible effect (which really surprised me - I was sure I'll have this issue solved in a second
).
Now that I think about it, may be it was a faulty rudder angle sensor? I'll never know now - it was a charter boat.
I'm driving a 48' commercial fishing boat. The multiplexer is mostly there as a convenient way to go from USB to the autopilot's rx terminal. It is also a backup route to put an alternate GPS feed into the computer. Right now I'm using a BU-353 in one of the laptop's USB ports. The other USB port goes to the multiplexer. Besides the autopilot (which is rx only) I had only one thing turned on, and that was a Furuno FCV-585 color sounder.
It was the sounder that caused the feedback loop last year. It is tx/rx and there is an option to retransmit whatever is received. The Furuno owner's manual was not very clear about the proper setting, but after realizing that I was re-transmitting the steering information (the feedback loop) I turned the option off and never had that steering problem again.
The feedback loop problem occurred while traveling in a straight line. This problem mainly occurs at a waypoint switch along a route. I don't recall a time when it happened while going to a single waypoint (things are often hectic when it happens—that detail might have escaped me) but if it is happening while going to a single waypoint, it is only happening for some period immediately after I switch to nav. That would be the single line equivalent of when it happens on a route. Since the sounder is relatively quick to kill or restart, that is the box that I'm planning to disable the next time this happens.
The VHF radio is a red herring. Remember, I'm in Alaska and there are long periods of time when nobody else is in radio range. A VHF radio can definitely screw up certain navigational electronics though. I saw a fancy Sperry gyrocompass once that would spin like a frisbee if a handheld VHF was keyed too close to it. I've also seen a SSB radio screw up a hard disk whenever it was keyed on a mid-4megs frequency.
My autopilot also has settings to control the turn rate. Those settings don't do anything to control the new direction of travel. They only control how long it takes to swing around to the new heading. Normally my autopilot does a pretty good job of turning on to a new heading. The 100°+ turn that I described in my first post overshot the new course bearing line only because of the extreme angle of turn and it corrected itself rapidly when it came back to the course line. When the problem occurs the autopilot display clearly shows that it is receiving a new heading that is way off the proper bearing. In fact, since the wrong heading is usually 40-60° off the proper bearing, the autopilot usually does a great job of turning to the wrong heading.
On a ComNav autopilot an alarm will sound if the rudder angle sensor doesn't detect movement after about 3 seconds. I suspect that Sea Slacker would have heard an alarm in the event of a rudder indicator failure. The strong sinusoidal swings are described in my autopilot owner's manual too. I have a setting that is the equivalent of gain for straight line control, and a second that controls the turn rate when a new course is entered into the autopilot. My wild swings aren't sinusoidal though. The boat doesn't oscillate. It just goes off in the wrong direction until the XTE builds to at least 0.1NM.
fish2live Wrote:I'm driving a 48' commercial fishing boat. The multiplexer is mostly there as a convenient way to go from USB to the autopilot's rx terminal. It is also a backup route to put an alternate GPS feed into the computer.
I'm assuming the backup GPS is either not turned or not wired? No possibility that it is feeding data into the incoming stream....
fish2live Wrote:The VHF radio is a red herring.
yeah, I don't think it's the radio, easy way to verify it would be to key it and if nothing happens AP-wise, probably not the cause...
fish2live Wrote:My autopilot also has settings to control the turn rate. Those settings don't do anything to control the new direction of travel. They only control how long it takes to swing around to the new heading. Normally my autopilot does a pretty good job of turning on to a new heading. The 100°+ turn that I described in my first post overshot the new course bearing line only because of the extreme angle of turn and it corrected itself rapidly when it came back to the course line. When the problem occurs the autopilot display clearly shows that it is receiving a new heading that is way off the proper bearing. In fact, since the wrong heading is usually 40-60° off the proper bearing, the autopilot usually does a great job of turning to the wrong heading.
When you say the autopilot display shows it is receiving new heading..do you mean it is displaying the same BTW as the computer? To the best of my recollection, the NMEA sentences for Autopilot data do NOT include heading info for steering to a WP, only BTW (Bearing to WP not to be confused with the heading to the WP) An Autopilot in "Nav" mode steers to a WP using crosstrack, not heading. It may or may not, depending on the SW residing in the AP itself, use heading info to increase or decrease rudder in order to null crosstrack.
I would suggest experimenting with the rate of turn control. I think that what is happening upon receiving the new WP, the AP is oversteering to come onto the new course.
Lastly, what version of MacENC are you running? Older versions (much older) dealt with new waypoints in routes in a manner that would explain perfectly what is happening...