About the AutoTrackRaymarine Plugin

[Douwe Fokkema]

Originally Posted by akopac

I’d Bark and do Rollie’s for the Pi version[emoji190][emoji252]
The x86 processor is such a waste of power...

You will find the Pi version in the master plugin catalog. Just click Install. And this plugin should now work with any n2k interface supported by OpenCPN. So the functionality is no longer limited to the NGT-1. With thanks to Rick Rgleason for his help to get this deployed. One precaution, we have not been able to test all interfaces with AutoTrackRaymarine. So I will be glad to hear your experiences.

Douwe

[akopac]

Originally Posted by Douwe Fokkema

You will find the Pi version in the master plugin catalog. Just click Install. And this plugin should now work with any n2k interface supported by OpenCPN. So the functionality is no longer limited to the NGT-1. With thanks to Rick Rgleason for his help to get this deployed. One precaution, we have not been able to test all interfaces with AutoTrackRaymarine. So I will be glad to hear your experiences.

Douwe

Ok. I’m heading to Sorarrow in the next couple days. I’m going to wait til I get to Fiji and give it a shot

Thanks
I’m doing rallies and barking like a dog over here. LoL

[sailingjazz]

I would really like to get this working. I have a Evo 100. I use OCPN connected via wifi to an Brookhouse iMux multiplexer which is connected to my 0183 instruments. I have a Actisense NGW-1 converter also connected to the iMux.
In order to make the PI work, I am planning to replace the NGW-1 with a Digital Yachts iKonvert NEMA 2000 to USB converter. I would like opinions as to rather this should work. The tablet I use at the help is connected to the iMux via wifi, I assume I could not control the Ev0100 from there?


Current Setup:

Planned Setup:

[dwynalda]

All

I had the opportunity to install the autotrackraymarine plugin in OpenCPN this week as I am currently on the great loop and needed to fulfill my geek needs.

First I tried to install the plugin in open plotter. It installs and can see the ngt1 (and control it) but there's a bit of updating needed to display the status properly. The buttons work and the plugin does what it's supposed to do... But the display is something Douwe is now working on.

Since I'm a geek and had Linux and Windows on board I installed standalone OpenCPN (still using signalk server from open plotter) and in Windows the app works exactly as expected. Actually even better than I expected.

Be warned... When I first turned on the autopilot to track with a route in OpenCPN it navigated like a drunk sailor. Turns out my calibrations in my Ray Marine evo autopilot were not good. After a couple of hours troubleshooting that, I found the autopilot bearing differed from OpenCPN by 4 degrees. Once I got everything talking on the same standard (and configured a compass adjustment on the autopilot to match) I had very good results.

Even better I decided to go to the next step. I booted my tablet and opened Navionics boater app. I picked a point up river a bit from me and a point 100 miles downriver. The app calculated a route (in the center of the channel) the whole way. I saved this route in gpx format to Google drive and then grabbed the file with my PC. I imported the file into OpenCPN and activated the route and then when I drew near to the first point on the route I double clicked AUTO and saw the plugin go into tracking mode.

I then sat back for HOURS marveling at the miracle that is this plugin. My boat stayed near center channel waypoint after waypoint running a few meters left or right at major turn angles - but literally staying right near the middle of the channel. Yes, I literally navigated 50+ miles of the Illinois River and only had to standby when oncoming barges needed us to run near the edge of the channel to make room.

Exceptional. Nice work Douwe. I look forward to the day when a version is released that works in Linux/Open plotter (it already *works* but the status fields don't show XTE, Bearing, status etc). I'm sure that's actually a minor thing as the +1-1+10-10 buttons change color when the status changes.... so it's probably an xWindows thing.

[Rick Welin]

Hi All, First post!

I'm just waiting for my EV-200 system to arrive so I was reading up on Douwe's plugin. I'm happy to see that it's supporting NMEA 2000 now, that's great! I'm very much looking forward to using it.

My question is regarding the laptop USB - Sea Talk EV system connection. Which dongle should I be looking for now that we don't need a 183/2000 converter?

[dwynalda]

Originally Posted by akopac

Hi Douwe,
Will the updated plugin version work with:
Raspberry Pi
Evo100
Yacht Devices Usb to nmea2000 interphase
Opencpn/Openplotter
SignalK

it does work. I used it today. but there is a bug in the gui that doesn't show the status in the plugin on the RPI (por Linux for that matter as I tried Ubuntu on pc). Douwe is aware. there is a new graphical framework in Linux he is using and there is likely a bug in that code. should be fixed once he is able to overcome the changes in the compiler they have made...

worked flawlessly in windows for me today. I left the pi feeding everything and running signalk and ran opencpn on windows with ngt1 plugged in via USA and talking over network to signalk. worked great. I had serious config tweaking to do on my Evo config though as apparently I was lazy setting it u. compass didn't agree with other devices on my boat at steering sensitivity had to be changed to more properly represent how my slow to turn boat responded.

once I did that- things went swimmingly.

[dwynalda]

>The XTE is well displayed on the Plugin but not on the p70Rs.
>The TWS and DTW are also not displayed on the p70Rs.

I think you might misunderstand the nature of the plugin. it is not going to talk raymarine enough to change the layout of a preprogrammed head and it is not going to send the route to the head. the pc runs the route and displays the next way point (when in tracking mode) and changes the bearing requested every second based on tracking to the route. when the boat reaches a point it changes the bearing again to the next point. it doesn't have any way to add a tracking button on the display of the p70. it just tells the p70 where to go continually.

this is different than the bidirectional tracking raymarine would do via p70 as a display from an axios display - but functionally the result is the same if not better.

the head does control the plugin. the plugin controls the head. but the head can't show the tracking status. it's quite obvious though that it's tracking as it constantly changes the heading desired to correct for deviation from plan on the active route.

I do this... I tell navionics boating app to plot me a route. (use automatic. if on a river etc it will use the middle of the channel. save the route from navionics as a gpx file. ask opencpn to import it as a route. go to the route in the route manager in opencpn. choose it, activate it.

then you can either hit "tracking" on the pc in the plugin or hit auto twice on the p70 to make it act. you will see the status change on the plugin window (in windows) and the four fields for xte, bearing etc will all be updated continuously. as you progress on the route (if your autopilot is tuned nicely to the boats responsiveness) the pc will switch way points as you go and follow the route.

works great but it does not do what you ask because cresting fields in the p70 is outside if scope. it's not a pc display, it's a hardware device configured in eeprom at the factory.

douwe has hacked the instructions that go between raymarine plotter and the Evo.., but he can't reprogram the evo....

now... if you are not using windows there is a display bug in Linux and Openplotter versions (likely due to changes in how Linux X displays stuff) that Douwe is working on. I have this installed in five devices to test. windows variants working well (doing what it is advertised to do) but not all you ask. and working (functionally) in linux/PI but not graphically completely displaying. ,

[Rick Welin]

OK Trying my own question. (Do we still need a dongle to use AutoTrackRaymarine with the EV-200) I found this in the O manual:

Question: OpenCPN works fine with the EV1 without any plugins and without NMEA2000. Any commercial NMEA0183-2000 gateway (actisense/yacht devices/etc) handles the translation. The only thing it can't do is start the autopilot (engage “auto”). Even that, the YDWG-02 will optionally do when it receives the APB sentence. So what is AutoTrackRaymarine for, some peculiar connection type?

Answer: Yes, It is called NMEA2000… It implements the Raymarine proprietary PGNs, so no device doing translation, like the YDWG, is needed. Now that OCPN supports NMEA2000 the AutoTrackRaymarine plugin supports n2k and the Raymarine PGNs (as adding proprietary PGNS of a single vendor is not on any list for the core application). The only difference with O5.8 is we take care of the connection to the NMEA bus for them.

Confusing wording to me. It seems to say we dont't need a dongle like Actisense etc? So how do we get USB out of the PC into the Seatalk network?

Originally Posted by Rick Welin

Hi All, First post!

I see that O is supporting NMEA 2000 now, that's great! I'm very much looking forward to using AutoTrack.

My question is regarding the laptop USB - Sea Talk EV system connection. Which dongle should I be looking for now that we don't need a 183/2000 converter?

[stevead]

My question is regarding the laptop USB - Sea Talk EV system connection. Which dongle should I be looking for now that we don't need a 183/2000 converter?

The list of supported NMEA 2000 adapters can be found buried here

>The XTE is well displayed on the Plugin but not on the p70Rs.
>The TWS and DTW are also not displayed on the p70Rs.

Neither core OpenCPN or Douwe's plugin generate the standard PGN's 129283 or 129284 when a route or waypoint is activated. These PGN's contain the data that would normally populate these fields on NMEA 2000 MFD's, Instrument Displays or Autopilot Control Heads.

works great but it does not do what you ask because cresting fields in the p70 is outside if scope. it's not a pc display, it's a hardware device configured in eeprom at the factory.

This is a little incorrect. Fields of interest when navigating to a waypoint such as Cross Track Error (XTE), Distance to Waypoint (DTW), Time To Waypoint (TTW), Bearing to Waypoint (BTW) are standard fields available in manufacturers' devices and don't require any fancy programming or fiddling with EEPROM's, they just require the generation of the relevant NMEA 2000 messages.

[Douwe Fokkema]

Originally Posted by stevead

The list of supported NMEA 2000 adapters can be found buried here
Neither core OpenCPN or Douwe's plugin generate the standard PGN's 129283 or 129284 when a route or waypoint is activated. These PGN's contain the data that would normally populate these fields on NMEA 2000 MFD's, Instrument Displays or Autopilot Control Heads.
This is a little incorrect. Fields of interest when navigating to a waypoint such as Cross Track Error (XTE), Distance to Waypoint (DTW), Time To Waypoint (TTW), Bearing to Waypoint (BTW) are standard fields available in manufacturers' devices and don't require any fancy programming or fiddling with EEPROM's, they just require the generation of the relevant NMEA 2000 messages.

I could add the generation of PGN's 129283 or 129284 to the AutoTrackRaymarine plugin. But it might be better to add the generation of the messages to OpenCPN itself. O generates navigational messages for NMEA0183, so why not for NMEA2000. I will try to estimate the effort involved in either solution.

[stevead]

But it might be better to add the generation of the messages to OpenCPN itself. O generates navigational messages for NMEA0183, so why not for NMEA2000.

That's the perfect place for it.

All the information required to construct PGN's 128283 (XTE) and 129284 (Navigation Data) is present in OpenCPN as the same information is used to generate the APB & RMB NMEA 183 sentences that OpenCPN transmits when a waypoint or route is active.

Plugin developers could implement it, however to construct these PGN's, plugins need to aggregate data using the SetNMEASentence API and extract the data from the APB & RMB sentences.

There is no single API or struct that provides the data necessary to construct these PGN''s. For example the Plugin_Active_Leg_Info struct that is the argument to the SetActiveLegInfo API, does not contain enough information to construct PGN 129284.

Should be easy for OpenCPN to implement as I believe that Timo's libraries support these PGN's.

If you want to roll your own and aren't using Timo's libraries, this is a snippet of code I use for constructing PGN 129284

if (parser->Rmb.IsDataValid == NTrue) {
	
	n2kMessage->push_back(sequenceId);

	unsigned int distanceToWaypoint = 100 * parser->Rmb.RangeToDestinationNauticalMiles/ CONVERT_METRES_NAUTICAL_MILES;
	n2kMessage->push_back(distanceToWaypoint & 0xFF);
	n2kMessage->push_back((distanceToWaypoint >> 8) & 0xFF);
	n2kMessage->push_back((distanceToWaypoint >> 16) & 0xFF);
	n2kMessage->push_back((distanceToWaypoint >> 24) & 0xFF);
		
	byte bearingRef = HEADING_TRUE;
        // BUG BUG Correct value is in APB sentence
	byte perpendicularCrossed = parser->Rmb.IsArrivalCircleEntered == NTrue ? 1 : 0;	
	byte circleEntered = parser->Rmb.IsArrivalCircleEntered == NTrue ? 1 : 0;

	byte calculationType = 0;
	
	n2kMessage->push_back(((bearingReference << 6) & 0xC0) |
		((perpendicularCrossed << 4) & 0x30) |
		((circleEntered << 2) & 0x0C) |
		(calculationType & 0x03));

	// Calculate ETA

	unsigned short waypointClosingVelocity = 100 * parser->Rmb.DestinationClosingVelocityKnots / CONVERT_MS_KNOTS;

	if (waypointClosingVelocity > 0) {
		wxDateTime now = wxDateTime::Now();
		wxDateTime epoch((time_t)0);
		double elapsedTime = distanceToWaypoint / waypointClosingVelocity;
		unsigned int hours = floor(elapsedTime);
		unsigned int minutes = round((elapsedTime - floor(elapsedTime)) * 60);
		now.Add(wxTimeSpan::Hours(hours));
		now.Add(wxTimeSpan::Minutes(minutes));
		wxTimeSpan dateDiff = now - epoch;
		daysSinceEpoch = dateDiff.GetDays();
		secondsSinceMidnight = ((dateDiff.GetSeconds() - (*days * 86400)).GetValue()) * 10000;
	}
	else {
		daysSinceEpoch = USHRT_MAX;
		secondsSinceMidnight = UINT_MAX;
	}

	n2kMessage->push_back(secondsSinceMidnight & 0xFF);
	n2kMessage->push_back((secondsSinceMidnight >> 8) & 0xFF);
	n2kMessage->push_back((secondsSinceMidnight >> 16) & 0xFF);
	n2kMessage->push_back((secondsSinceMidnight >> 24) & 0xFF);

	n2kMessage->push_back(daysSinceEpoch & 0xFF);
	n2kMessage->push_back((daysSinceEpoch >> 8) & 0xFF);

	unsigned short bearingOrigin = USHRT_MAX;
	n2kMessage->push_back(bearingOrigin & 0xFF);
	n2kMessage->push_back((bearingOrigin >> 8) & 0xFF);

	unsigned short bearingPosition = 1000 * DEGREES_TO_RADIANS(parser->Rmb.BearingToDestinationDegreesTrue);
	n2kMessage->push_back(bearingPosition & 0xFF);
	n2kMessage->push_back((bearingPosition >> 8) & 0xFF);

	wxString originWaypointId = parser->Rmb.From;
	// BUG BUG Need to get the waypointId
	n2kMessage->push_back(0xFF);
	n2kMessage->push_back(0xFF);
	n2kMessage->push_back(0xFF);
	n2kMessage->push_back(0xFF);

	wxString destinationWaypointId = parser->Rmb.To;
	n2kMessage->push_back(0xFF);
	n2kMessage->push_back(0xFF);
	n2kMessage->push_back(0xFF);
	n2kMessage->push_back(0xFF);

	int latitude = parser->Rmb.DestinationPosition.Latitude.Latitude * 1e7;
	if (parser->Rmb.DestinationPosition.Latitude.Northing == NORTHSOUTH::South) {
		latitude = -latitude;
	}
	n2kMessage->push_back(latitude & 0xFF);
	n2kMessage->push_back((latitude >> 8) & 0xFF);
	n2kMessage->push_back((latitude >> 16) & 0xFF);
	n2kMessage->push_back((latitude >> 24) & 0xFF);
			
	int longitude = parser->Rmb.DestinationPosition.Longitude.Longitude * 1e7;
	if (parser->Rmb.DestinationPosition.Longitude.Easting == EASTWEST::West) {
		longitude = -longitude;
	}

	n2kMessage->push_back(longitude & 0xFF);
	n2kMessage->push_back((longitude >> 8) & 0xFF);
	n2kMessage->push_back((longitude >> 16) & 0xFF);
	n2kMessage->push_back((longitude >> 24) & 0xFF);
	// See above for Waypoint Closing Velocity
	n2kMessage->push_back(waypointClosingVelocity & 0xFF);
	n2kMessage->push_back((waypointClosingVelocity >> 8) & 0xFF);
		
	return TRUE;
}

You can take the credit for filing an issue on the Github OpenCPN repo.

[Douwe Fokkema]

Originally Posted by stevead

That's the perfect place for it.

All the information required to construct PGN's 128283 (XTE) and 129284 (Navigation Data) is present in OpenCPN as the same information is used to generate the APB & RMB NMEA 183 sentences that OpenCPN transmits when a waypoint or route is active.

Plugin developers could implement it, however to construct these PGN's, plugins need to aggregate data using the SetNMEASentence API and extract the data from the APB & RMB sentences.

Steve, thanks for your info. I agree that implementation in OpenCPN is by far the best option, however I think it is beyond my scope. If it is done, it has to be done properly, including the adaptation of the Options/Connections window with the sentence selection for Rx and Tx.
What I could do rather easily is to compose PGN 128283 (XTE) and a PGN 129284 (Navigation Data) with only the fields DTW, BTW and WP_name filled in, rest 0, inside the plugin and transmitted from the plugin through O. These are the available fields from the SetActiveLegInfo and these are just the fields that the user wants to see on his P90 control head. I assume the P90 will accept a PGN with missing data. This requires some testing with the real pilot, and will take some time as the boat is on shore and not next door. Could be implemented in time for next season.

[sailingjazz]

I have a DY STng usb interface to my Nav PC providing a two way NEMA 2000 interface to my EVO 100 AP. I also have an iMux wifi that converts old ST instruments to 0183 and multiplexes it with other 0183 feeds. OpenCPN is running on the Nav PC and is getting data from both. I intend to set up an unfiltered OpenCPN input / output connection on this Nav PC.

My questions are;

Will I be able to use this data on a PC at the helm to control the Autotrack PI?

Is there any need for a Signal K data server? The Helm and Nav PCs will be on the same wifi router.

Will all the necessary sentences for the PI be passed through to/from the Nav PC?

Thanks,
Kevin

[akopac]

What is the differences and best practices with the plugins:
* Autopilot Route
* AutopilotTrackRaymarine
I have a EV100 autopilot tied into my nmea2000 network with appropriate adapters. RPI with opencpn setup on it and do water sailing">blue water sailing on a regular basis.

[stevead]

I thought it would be pretty obvious from the plugin descriptions, but then again perhaps not.

The Autopilot Route plugin is for autopilots connected via NMEA 183. It performs comprehensive route calculations and generates the XTE, APB, RMB sentences that the autopilot uses when it is in track mode.

On the other hand, Douwe's AutoTrackRaymarine plugin is specifically for Raymarine EVO autopilots connected via Seatalkng (NMEA 2000). It generates the NMEA 2000 messages that control the Raymarine EVO modes (standby, heading, wind, track) and also provides the steering guidance when following a route or navigating to a waypoint.

I personally find it amusing/confusing that there are several "autopilot" plugins as well as OpenCPN's own "autopilot" control, all performing the same role, but using different algorithms and targetting different models of autopilots. One day we might see some sanity (aka a specification) as to how OpenCPN handles autopilots.