Why does NKE system not accept heading data from Raymarine EV-1

[fxykty]

We have a Raymarine SeatalkNG network that includes a Raymarine EV-1 sensor, which provides heading data for our instruments and Raymarine Evolution autopilot. All works as it should. We output data from our network via a YachtDevices gateway and all the data we expect is available to any connected device and apps such as OpenCPN and iSailor, including heading.

We’ve added a NKE Gyropilot autopilot, with a switch that determines which of our autopilots sends control signals to our hydraulic steering pump. The NKE system is connected to our SeatalkNG network and has access to all the data on that network (wind, depth, GPS, waypoints, etc.). This works as expected and we can select which autopilot computer we want to use. However, the NKE system does not recognise any heading data from the SeatalkNG network (provided by the EV-1), so the NKE autopilot does not have a Heading mode.

Before we spend big money buying a NKE fluxgate compass to provide its own source of heading data, any ideas why our SeatalkNG heading data is not being recognised by the NKE system?

[Dockhead]

You do NOT want the NKE Fluxgate, which is a primitive 2hz non-gyro compass which does not give rate-of-turn.

Autopilot performance is highly dependent on compass performance.

SeaTalk NG is just NMEA2000. The NKE Gyropilot does not speak N2K without the optional adapter. It wants NMEA 0183 compass data.

You will need the NKE NMEA 2000 to Topline Gateway to make that work.

Or buy a separate 0183 compass like the NKE Gyrocompass HR or 9X.

[fxykty]

We do have the NKE Box N2K, which pulls in NMEA 2K data (connected to our SeatalkNG network directly) and outputs it to the Topline bus where it goes to the Gyropilot via NMEA 0183. For whatever reason, it is accepting data including rate of turn (which comes from the EV-1). For whatever reason, it isn’t picking up heading data.

If we can’t figure this out (NKE technicians in France can’t figure this out either) then we’ve got a few options. If we have to buy a new compass we’d rather spend the money on a Raymarine AR200 Sensor Module. But will the NKE system accept its data? Playing it safe, one the NKE compasses you reference will do.

[boatpoker]

I mixed brands too ... Raymarine Evo pilot and Garmin GPS/plotter, they do not work together. Raymarie says its a Garmin problem, Garmin says it's a Raymarine problem. I will never mix brands again.

[Dockhead]

Originally Posted by fxykty

We do have the NKE Box N2K, which pulls in NMEA 2K data (connected to our SeatalkNG network directly) and outputs it to the Topline bus where it goes to the Gyropilot via NMEA 0183. For whatever reason, it is accepting data including rate of turn (which comes from the EV-1). For whatever reason, it isn’t picking up heading data.

If we can’t figure this out (NKE technicians in France can’t figure this out either) then we’ve got a few options. If we have to buy a new compass we’d rather spend the money on a Raymarine AR200 Sensor Module. But will the NKE system accept its data? Playing it safe, one the NKE compasses you reference will do.

That's weird.


I'm afraid I don't have anything to to contribute. The EV-1 is a good rate compass, the kind you want.



If you end up buying an NKE one, it might sweeten the blow a bit to know that a compass works better if it's directly connected to the pilot computer via 0183, rather than via N2K. An 0183 connection is point to point and has less latency, especially if the N2K network is busy.

[Baronkrak]

Originally Posted by fxykty

Before we spend big money buying a NKE fluxgate compass to provide its own source of heading data, any ideas why our SeatalkNG heading data is not being recognised by the NKE system?

For your information

Originally Posted by Baronkrak

Are you aware than an EV-1 will send repeatedly a Standby sentence

Good luck for using EV-1 as heading in a non EV-1 autopilot system.

[Baronkrak]

Originally Posted by Dockhead

Autopilot performance is highly dependent on compass performance.

Fancy autopilots are highly dependent on all sensors performance and a waste of money if for instance Water Speed is erratic.

[barnakiel]

It is quite simple actually.


ANY maker wants to avoid hearing one million questions related to things no one but GOD knows the answers to.


So they want you to use SAME sensors/hardware so that they can at all find and kill any existing bugs.


I would not expect NKE or anyone to know all the other systems of which there are say 8 main brands plus unlimited number of sensor makers.


All it takes is the EV containing anything in its output that throws and error on NKE side. Any thing. And believe me both companies may do this intentionally - only to be able to be providing quality service and quality products, rather than spending their crew time on solving computer riddles.


Go get a quality sensor as recommended by NKE for their system. (NOT an old style fluxgate - as already mentioned). Get a magnetometer (chip) based one, with spacial (acceleration and gyro) info. NKE makes these.


Trust in NKE. You already have.


barnakiel

[CatLove]

Originally Posted by fxykty

We have a Raymarine SeatalkNG network that includes a Raymarine EV-1 sensor, which provides heading data for our instruments and Raymarine Evolution autopilot. All works as it should. We output data from our network via a YachtDevices gateway and all the data we expect is available to any connected device and apps such as OpenCPN and iSailor, including heading.

We’ve added a NKE Gyropilot autopilot, with a switch that determines which of our autopilots sends control signals to our hydraulic steering pump. The NKE system is connected to our SeatalkNG network and has access to all the data on that network (wind, depth, GPS, waypoints, etc.). This works as expected and we can select which autopilot computer we want to use. However, the NKE system does not recognise any heading data from the SeatalkNG network (provided by the EV-1), so the NKE autopilot does not have a Heading mode.

Before we spend big money buying a NKE fluxgate compass to provide its own source of heading data, any ideas why our SeatalkNG heading data is not being recognised by the NKE system?

which NKE Gyropilot do you have? There are at least 3 versions
You wrote the autopilot doesn't have a "heading mode" due to not recognizing heading info.
The user manual does not use the term "heading mode". It has 2 modes that involve heading info, one is named "compass mode" and the other is "GPS mode". Do you have these and which of them works or not?

[s/v Jedi]

This is simply not true. Our B&G pilot happily takes heading and rot from both our Maretron and Airmar heading sensors.

It sounds like this AP isn’t much good… lack of n2k ports is a bad sign.

Some remarks:

- no, you shouldn’t keep to using everything from one brand only. Instead you should demand all equipment allows combining with other brands sensors.

- no, nmea0183 isn’t faster nor more responsive. For good autopilot performance you need a 10Hz rte of updates (heading updated 10 times per second). It’s tough to send that over nmea0183 so probably this is why the converter can’t process it. Nmea2000 is so much faster that it can easily combine data from many sensors into one stream. You can check the load of the system on many instruments and plotters. I have 10Hz heading and position, 5Hz rot, rudder, two feeds of AIS and my bandwidth utilization is 40%.

- the best heading sensors are the so called satellite heading sensors.

[CatLove]

Originally Posted by s/v Jedi

This is simply not true. Our B&G pilot happily takes heading and rot from both our Maretron and Airmar heading sensors.

It sounds like this AP isn’t much good… lack of n2k ports is a bad sign.

Some remarks:

- no, you shouldn’t keep to using everything from one brand only. Instead you should demand all equipment allows combining with other brands sensors.

- no, nmea0183 isn’t faster nor more responsive. For good autopilot performance you need a 10Hz rte of updates (heading updated 10 times per second). It’s tough to send that over nmea0183 so probably this is why the converter can’t process it. Nmea2000 is so much faster that it can easily combine data from many sensors into one stream. You can check the load of the system on many instruments and plotters. I have 10Hz heading and position, 5Hz rot, rudder, two feeds of AIS and my bandwidth utilization is 40%.

- the best heading sensors are the so called satellite heading sensors.

Yes Jedi, the NKE is a bad design, that's why all the IMOCA's and other highest performance race classes use it.
And again, yes you're right, NMEA0183 is sloow, that's why the NKE uses it and sends heading updates at 25Hz, not 10Hz.

[Dockhead]

Originally Posted by s/v Jedi

. . . - no, nmea0183 isn’t faster nor more responsive. For good autopilot performance you need a 10Hz rte of updates (heading updated 10 times per second). It’s tough to send that over nmea0183 so probably this is why the converter can’t process it. Nmea2000 is so much faster that it can easily combine data from many sensors into one stream. You can check the load of the system on many instruments and plotters. I have 10Hz heading and position, 5Hz rot, rudder, two feeds of AIS and my bandwidth utilization is 40%.. . ..

Just for information, the multimillion dollar racing programs use 0183 and never N2K to connect compasses to autopilots. And their wind sensors are either pulse, or 0183 (the €5000 B&G 7-series wind sensor we put on my friends Discovery 67 is 0183, for example). Same with speed transducers -- they connect these to their racing computers with pulse output connections (Signet Blue Top is almost universal in racing).


The problem with N2K is LATENCY. You need a very low level of latency for a pilot to work really well. 0183 as serial communications has zero latency. N2K can have a lot depending on the bus load.



From the racing computer to the displays you use N2K.


Bandwidth is not an issue with 0183 connections. Standard 0183 is 4800 baud; the B&G wind instruments use 38,400 baud NMEA 0183.


Now I'm not up to top racing standards; I have the N2K version of the Furuno satellite compass. But I've had problems with it, and the advice I've gotten is that I should sell it and buy the 0183 version (the SCX-21) and connect it directly to my H5000.


And I'm in the process to switching to a pulse speed log transducer, to replace the very unsatisfactory Airmar UST850.

[s/v Jedi]

Originally Posted by CatLove

Yes Jedi, the NKE is a bad design, that's why all the IMOCA's and other highest performance race classes use it.
And again, yes you're right, NMEA0183 is sloow, that's why the NKE uses it and sends heading updates at 25Hz, not 10Hz.

Originally Posted by Dockhead

Just for information, the multimillion dollar racing programs use 0183 and never N2K to connect compasses to autopilots. And their wind sensors are either pulse, or 0183 (the €5000 B&G 7-series wind sensor we put on my friends Discovery 67 is 0183, for example). Same with speed transducers -- they connect these to their racing computers with pulse output connections (Signet Blue Top is almost universal in racing).


The problem with N2K is LATENCY. You need a very low level of latency for a pilot to work really well. 0183 as serial communications has zero latency. N2K can have a lot depending on the bus load.



From the racing computer to the displays you use N2K.


Bandwidth is not an issue with 0183 connections. Standard 0183 is 4800 baud; the B&G wind instruments use 38,400 baud NMEA 0183.


Now I'm not up to top racing standards; I have the N2K version of the Furuno satellite compass. But I've had problems with it, and the advice I've gotten is that I should sell it and buy the 0183 version (the SCX-21) and connect it directly to my H5000.


And I'm in the process to switching to a pulse speed log transducer, to replace the very unsatisfactory Airmar UST850.

No, you guys are wrong. Latency is the time it takes to transmit and receive the information. The slower this transmission is, the longer it takes. Nmea0183 high speed is 38kbps, while nmea2000 is 250kbps.

Of course the n2k link probably carries much more than just the heading feed, but when the network utilization is below 100%, all data is delivered without delay caused by there being other data.

A 25Hz heading feed is not special, you must have misunderstood my comments so let me try again: you cannot convert a full n2k feed to 0183 because it’s simply too much data. You can’t fit it into aa 0183 connection.

This isn’t a new problem. They invented 0183 high speed because the regular one couldn’t handle the amount of data. Regular 0183 is only 9.6kbps.

So this nke converter must make a selection of what to forward and what not. Apparently it doesn’t forward heading.

A satellite heading sensor is better than the “gyro” sensors. You can check this yourself I’m sure.

There’s nothing bad about 0183 but it is slow yes. More than 6 times as slow as n2k. For as the reason that they don’t switch to n2k I would suspect the same reasons as for commercial shipping: 0183 has all the approvals and can do the job, it’s too expensive to change when there isn’t a clear benefit. They don’t care about wiring.

When nke gives you an external converter instead of a native n2k port then this is nothing to be proud about.

[CatLove]

Originally Posted by s/v Jedi

No, you guys are wrong. Latency is the time it takes to transmit and receive the information. The slower this transmission is, the longer it takes. Nmea0183 high speed is 38kbps, while nmea2000 is 250kbps.

Of course the n2k link probably carries much more than just the heading feed, but when the network utilization is below 100%, all data is delivered without delay caused by there being other data.

A 25Hz heading feed is not special, you must have misunderstood my comments so let me try again: you cannot convert a full n2k feed to 0183 because it’s simply too much data. You can’t fit it into aa 0183 connection.

This isn’t a new problem. They invented 0183 high speed because the regular one couldn’t handle the amount of data. Regular 0183 is only 9.6kbps.

So this nke converter must make a selection of what to forward and what not. Apparently it doesn’t forward heading.

A satellite heading sensor is better than the “gyro” sensors. You can check this yourself I’m sure.

There’s nothing bad about 0183 but it is slow yes. More than 6 times as slow as n2k. For as the reason that they don’t switch to n2k I would suspect the same reasons as for commercial shipping: 0183 has all the approvals and can do the job, it’s too expensive to change when there isn’t a clear benefit. They don’t care about wiring.

When nke gives you an external converter instead of a native n2k port then this is nothing to be proud about.

First of all, the NMEA0183 protocol timing is deterministic 100%.
Each time the talker has to send a certain sentence, it takes it the exact same amount of time to complete the transmission.
A NMEA0183 sentence can not be longer than 80 characters (bytes).
At the 38.4kbps and assuming 10bits/byte it can transmit 3840 chars per second (Bps).
At the max sentence length this means 3840/80=48Hz sentence rate .
The sloow NMEA0183 can update GNSS data up to 48 times per second , and does this like clockwork , with no delays, variations, missing sentences once in a while etc.
Obviously, having a GNSS with an update rate of 10Hz or 25Hz can not become a bottleneck , because at 25Hz the network is occupied half the time at most. No collisions or undelivered , skipped sentences.


NMEA2000 is NOT deterministic. It's very easy to make a simple error and enable too much data onto the bus.
NMEA2000 PGN's are allowed a max length of over 1700 bytes or 17,000 bits. In this worst case scenario less than 15 updates per second can be sent over the bus. That means an update every 60ms , 3 times slower than the NMEA0183.

People want all sorts of crap to monitor or control, fridge temps, underwater LED lights , tank levels etc., including multiple instances , beside the strictly navigation related things.
They do this because they can and after network capacity is exceeded intermittently, because senders are asynchronous, so conflicts never happen with the exact timing twice , troubleshooting begins.


Now back to the NKE pilot story, the system uses NKE Topline bus to connect with sensors. There are 2 NMEA0183 but no 2k.

This bus may run at 38k-115kbps and has a proprietary protocol. It can transfer other types of commands and data that are not ordinarily used with NMEA . For example load cell monitoring forestay tension in real time.


I don't believe this is done to lock users into a proprietary system, rather the opposite. NMEA are closed standards, you need to pay to buy the standards, you need to pay for testing any device you produce if you want to claim compatibility with NMEA. As a user, you don't have easy access to troubleshooting info.


Because of having extra data types NKE does things that other autopilots can't do. For example it measures all boat motions and accelerations (linear and angular) in real time and based on the mast height is able to calculate the true wind speed and direction by eliminating all boat motion influences on the masthead wind sensor.


They have a 3D HR true heading sensor that appears to be a GNSS augmented 9 axes +magnetic . This is also using a Topline non NMEA connection to the bus.
In Jedi's lingo, this would be a combination satellite heading and gyro.
This is how most of such sensors work nowadays, 2-4 GNSS receivers as moving baseline RTK, enhanced thru sensor fusion with accelerometers and gyros running an EKF .



In order to implement a NKE system one doesn't need any NMEA2k or 0183. As a user , probably I wouldn't want to pay for a built in NMEA interface that I may never use.


So it may be that the autopilot needs to be fed data from the Topline bus (proprietary) , because that simply has data that doesn't exist on the NMEA network.
It's very possible the Raymarine system doesn't generate exactly what the NKE needs anyway.
Basically the NMEA/Topline conversion could be useful the other way around, to display on Raymarine MFD's the NKE info, but not to use Raymarine sensors for the NKE pilot
That's at least because of the delays and extra conversions the data is undergoing in its journey from Raymarine sensors thru nondeterministic NMEA2k, then conversion thru the NKE box.


The conversion box has a non trivial setup procedure that may involve a configuration and setup software on a PC , in addition to some self configuring . It looks like something I could easily mess up and not enable the correct PGNs . Even though they were available on the N2k bus.


Sorry for the long rant

[s/v Jedi]

Originally Posted by CatLove

First of all, the NMEA0183 protocol timing is deterministic 100%.
Each time the talker has to send a certain sentence, it takes it the exact same amount of time to complete the transmission.
A NMEA0183 sentence can not be longer than 80 characters (bytes).
At the 38.4kbps and assuming 10bits/byte it can transmit 3840 chars per second (Bps).
At the max sentence length this means 3840/80=48Hz sentence rate .
The sloow NMEA0183 can update GNSS data up to 48 times per second , and does this like clockwork , with no delays, variations, missing sentences once in a while etc.
Obviously, having a GNSS with an update rate of 10Hz or 25Hz can not become a bottleneck , because at 25Hz the network is occupied half the time at most. No collisions or undelivered , skipped sentences.


NMEA2000 is NOT deterministic. It's very easy to make a simple error and enable too much data onto the bus.
NMEA2000 PGN's are allowed a max length of over 1700 bytes or 17,000 bits. In this worst case scenario less than 15 updates per second can be sent over the bus. That means an update every 60ms , 3 times slower than the NMEA0183.

People want all sorts of crap to monitor or control, fridge temps, underwater LED lights , tank levels etc., including multiple instances , beside the strictly navigation related things.
They do this because they can and after network capacity is exceeded intermittently, because senders are asynchronous, so conflicts never happen with the exact timing twice , troubleshooting begins.


Now back to the NKE pilot story, the system uses NKE Topline bus to connect with sensors. There are 2 NMEA0183 but no 2k.

This bus may run at 38k-115kbps and has a proprietary protocol. It can transfer other types of commands and data that are not ordinarily used with NMEA . For example load cell monitoring forestay tension in real time.


I don't believe this is done to lock users into a proprietary system, rather the opposite. NMEA are closed standards, you need to pay to buy the standards, you need to pay for testing any device you produce if you want to claim compatibility with NMEA. As a user, you don't have easy access to troubleshooting info.


Because of having extra data types NKE does things that other autopilots can't do. For example it measures all boat motions and accelerations (linear and angular) in real time and based on the mast height is able to calculate the true wind speed and direction by eliminating all boat motion influences on the masthead wind sensor.


They have a 3D HR true heading sensor that appears to be a GNSS augmented 9 axes +magnetic . This is also using a Topline non NMEA connection to the bus.
In Jedi's lingo, this would be a combination satellite heading and gyro.
This is how most of such sensors work nowadays, 2-4 GNSS receivers as moving baseline RTK, enhanced thru sensor fusion with accelerometers and gyros running an EKF .



In order to implement a NKE system one doesn't need any NMEA2k or 0183. As a user , probably I wouldn't want to pay for a built in NMEA interface that I may never use.


So it may be that the autopilot needs to be fed data from the Topline bus (proprietary) , because that simply has data that doesn't exist on the NMEA network.
It's very possible the Raymarine system doesn't generate exactly what the NKE needs anyway.
Basically the NMEA/Topline conversion could be useful the other way around, to display on Raymarine MFD's the NKE info, but not to use Raymarine sensors for the NKE pilot
That's at least because of the delays and extra conversions the data is undergoing in its journey from Raymarine sensors thru nondeterministic NMEA2k, then conversion thru the NKE box.


The conversion box has a non trivial setup procedure that may involve a configuration and setup software on a PC , in addition to some self configuring . It looks like something I could easily mess up and not enable the correct PGNs . Even though they were available on the N2k bus.

Sorry for the long rant

Don’t be sorry, I agree with almost everything you write. From the OP I understand he is using an NKE supplied converter that takes nmea2000 and converts it to this Topline protocol. All his data comes through except for heading. Even his rotation data, which comes from the same sensor is available.

It is not unusual for manufacturers to use proprietary data, they don’t need a new data system for it, they simply use proprietary sentences or PGN’s on either 0183 or n2k. It sounds like this is what NKE does using 0183, plus it supports 115kbps and it calls this Topline.
Using 115kbps isn’t unique to NKE, I have used this for years, but even at that speed 0183 can’t support the same amount of data that n2k supports simply because n2k is still more than double the speed.

Yes it’s true that people even control their entertainment systems over n2k and that this generates more network data than a heading sensor. Your math examples show that a single 0183 feed can do four heading sensors each at 10Hz if heading was all they output (in reality they also output rotation, 3D acceleration, GNSS etc.) but you forgot to mention how many of those 10Hz feeds n2k can do. The PGN’s involved aren’t significantly different in size so all in all n2k can do 6 times as many so not 4 but 24 of them.

On n2k there are PGN’s for acceleration data so no proprietary sentences are needed. All modern systems use this data, there is nothing unique from NKE about this.

Now back to the OP problem: if this adapter he has (but you never mention) does indeed do Topline at 115kbps then I don’t believe he has too much n2k data to fit causing his heading to be dropped. As everything else is available, it appears it is purposefully filtered out.

This isn’t the first time I hear of autopilots requiring to use their own sensors. They will of course claim it’s because their sensors are superior but tests have shown that to not be reality and it’s even questionable that they manufacture it themselves. Most tests I have seen the Airmar sensor was the best but those tests are old.

This is the reason they don’t have the n2k port because the n2k consortium requires them to support the standardized PGN’s in that case and this means they must accept data from other brands sensors.

Edit: n2k is based on CAN bus and this is a solid platform that the whole world uses. Your car won’t drive without it. One of the features of it is that devices can determine the utilization rate as well as error counts, retransmissions etc. this means you can simply see on connected displays if the network is healthy, if it is congested etc. While I wouldn’t recommend using it close to 100% utilization, most networks aren’t that high anyway, but you can simply segment it, creating a core that only has this sailing performance data without all the fridge temperatures etc.

On timing: yes, you can create a heartbeat like signal from heading data received from 0183 but only get the stability of rate that the sensor has in sending sentences and I am not convinced this is a perfect rate (also, both are asynchronous so never perfect). Tests have shown no noticeable improvement in performance with more than 10Hz data feed from heading, wind direction etc. and I think the higher rates are used simply to compensate for variations in update frequency.

I was under the impression that B&G had the best performing system, not NKE.