Wind Instrument

[goboatingnow]

Originally Posted by RaymondR

I think one of the things this discussion is bringing forward is the need to have sufficient robust instrumentation that is independent of the N2K system such to allow the boat to be navigated when the N2K system goes down.

Can bus is extremely reliable. Most other half baked solutions like rs232 based 0183 are likely to fail before the CAN system.

If you understand and rate true redundancy then build a multi CAN solution.

However most people systems fail from equipment failure poor installation or bad connections.

Building a reliable system on the back of poor foundations is also nonsensical

Any sensor on a set of wires running through your boat is a risk factor. Nothing to do with can

[s/v Jedi]

Originally Posted by Tehani

Surely we are not understanding each other.

Of course, an AP can work in NAV / TRACK mode if it receives waypoint or route data from a navigator, also in NO DRIFT if it correctly receives the COG, in WIND if it receives wind data ...
But it will not be able to function in any of the above modes if it is not receiving Heading as well. This information is basic for any pilot.

All modes are used to correct the internal reference heading "in the background" as time passes. Only the reading of the current heading, and currently also the attitude, allow the AP to react quickly to a yaw, in addition to serving as a base reference.

APs apply PID calculations on heading variations at all times, and cannot do without it. On the other hand, they can dispense with all the other data.

Of course, this is all true, but why would anyone want to remove wind or gnss data from the AP stream and loose the ability to steer a wind angle or no drift mode etc.? I do not see the logic in that; dumbing it down does not make it more reliable.

[RaymondR]

Originally Posted by goboatingnow

Can bus is extremely reliable. Most other half baked solutions like rs232 based 0183 are likely to fail before the CAN system.

If you understand and rate true redundancy then build a multi CAN solution.

However most people systems fail from equipment failure poor installation or bad connections.

Building a reliable system on the back of poor foundations is also nonsensical

Any sensor on a set of wires running through your boat is a risk factor. Nothing to do with can

I think NMEA 0183 is based upon RS 422 and NMEA 2000 on RS 485 which are fairly different protocols from RS 232 being designed for more industrial purposes.

[Tehani]

Originally Posted by s/v Jedi

Of course, this is all true, but why would anyone want to remove wind or gnss data from the AP stream and loose the ability to steer a wind angle or no drift mode etc.? I do not see the logic in that; dumbing it down does not make it more reliable.

I have never talked about eliminating wind and GNSS, I am simply saying that there should be an extremely secure bus for basic heading, keyboard and rudder information.
This bus would be isolated from the rest by optocouplers and a kind of router that would allow the passage of wind, depth, navigator and GNSS information, and blocking the rest (AIS, sats in view, etc). If I see that this idea could be interesting, I will be able to develop the necessary device.

RaimondR:
RS232, RS422, RS485 and CAN BUS are not protocols, they are electrical standards and very low level bit packaging formats.
CAN BUS controller chips also perform many tasks "intelligently", such as acknowledging and forwarding when there are data errors.

NMEA0183 is a data structure in the form of a text "phrase" (ASCII chars), and can be transmitted on any physical support (RS232, 422 ...), WiFi and Ethernet.
NMEA2000 (variant of J1939 used in automotive) is truly a protocol, since there is a "conversation" between the devices connected to the bus, and methods to determine priority and routing. Specifically, this protocol is designed to be used over the CAN BUS, because it provides the necessary features for priority management, security, and is faster than the previous RS422 and RS485, as well as being bidirectional for all devices.

[RaymondR]

Originally Posted by Tehani

RaimondR:
RS232, RS422, RS485 and CAN BUS are not protocols, they are electrical standards and very low level bit packaging formats.
CAN BUS controller chips also perform many tasks "intelligently", such as acknowledging and forwarding when there are data errors.

Nah, there are electrical protocols as well.

RS 232 uses ground referenced positive and negative voltages to differentiate between your zero and one of binary data representation whereas RS 422 and 485 use a differential voltage protocol. Whereby both your zeros and ones may be represented by a prescribed difference in voltage both of which may be above or below ground. Saves one from having to implement double ended power supplies.

Electrical protocols is real and it is a fairly general term used to describe a set of implementation rules and parameters in many contexts. For example in "medication protocols" where dosages and schedules are specified .

[goboatingnow]

Can bus is not derived From RS422

Can bus has indeed a low level protocol on top of an electrical interface

Rs232 and RS422 is just a electrical interface

As a result NMEA 0183 has virtually no ability to error check or Re transit , but can has several low level data integrity checks.

As a 30 year embedded system engineer I’ve never heard the term
“ electrical protocol “ used. The correct term would be electrical interface

[tanglewood]

Originally Posted by Joli

Our backbone isn't run up the mast. The ultrasonic MHU is a drop.

But how long is that drop cable? The allowed limit is 6m which is too short for most masts.

[tanglewood]

Originally Posted by s/v Jedi

Depth, position, wind (direction) are all crucial data in emergency situations.

I don’t get where “emergency situations “ come from… I described an Autopilot network that integrates with a second network. I guess you call that AP network an “emergency network”?

Look at it as a core data and control network, with the 2nd network as a “nice to have” network. That 2nd network also needs gnss but maybe use one of those new units that combine heading and attitude with position, or just use a chart plotter internal sensor etc.

I was trying to explain that it’s important that your gnss sensor supports all of gps, glonass and galileo, not just gps. The new units have 72 channels or more and are very capable in combining data from constellations and augmentation for best quality position data.

For multiple gnss, heading sensors: many good units allow data source selection, but not everything. It’s very annoying to see a heading line flip flop when it’s using multiple sensors.
But that isn’t the important reason for switching them off. When you use a double pole switch, which breaks both positive and negative power conductors in the nmea2000 drop cable, you isolate the sensor from surges (the data lines are opto isolated). We have had extensive thunderstorm damage, loosing $700 heading sensors, autopilots, gateways etc. Analysis by Maretron showed the surge coming in through the power conductors.

I've taken a similar approach by separating "primary" instruments and devices, and "secondary" instruments and devices.


But my implementation is a bit different with all the primary devices connected via 0183. I just find it much more reliable and deterministic. Turn it on, and 5 years later it's still doing the same thing. My highest quality instruments like the Sat compass and fish finder feed their data to radars, chart plotting, APs via 0183.



Then all the secondary instruments are on N2K, along with incidental ships monitoring. And there is an alternate data feed to radars, APs, and charting via an N2K connection. I can completely shut off the N2K bus and the boat keeps right on going. This gives really good redundancy, though there are always loop holes somewhere or other.

[s/v Jedi]

Originally Posted by tanglewood

But how long is that drop cable? The allowed limit is 6m which is too short for most masts.

I believe what is called a drop cable here is actually a nmea0183 link and the nmea2000 T-connector is the converter.

This allows very long runs and is by far the best solution, used by all the quality sensors.

[Tehani]

With this we return to the starting point of this thread and we are reaching a conclusion on what is the best way to transmit wind data from the top of the mast.

I also think this is the best solution: RS422 and NMEA0183 for the mast travel. Below, optoisolation and conversion to N2k.
That's why I think keeping the CV7, with cable down the mast at NMEA0183 is safer than running the main N2k cable all the way up, just to put in a state-of-the-art B&G sensor. If you like, an H5000 can collect this data from the CV7 through one of its NMEA0183 inputs.

We see that current sensors from quite a few manufacturers (B&G, Raymarine, Garmin, and others) "talk" in NMEA2000 over CAN BUS from up there, which can be a problem for the network. As Maraña says, it forces the main cable to get there, because a "N2k voltage drop cable" must have a maximum length of 6m.

We also know that there are wireless wind sensors powered by small photovoltaic cells. It is ideal for isolation, but it presents several problems:
One, the maximum distance or length of the mast since the coverage radius is a few meters.
Another, the autonomy of the batteries when we sail at night or with little insolation.
And a third, and one that probably worries precision fans: The transmission rate is quite low due to the imposition of power consumption.

Personally, I do not recommend the use of these wireless devices with solar cells.

[Tehani]

Since the NMEA0183 transmission is simplex, and there is a single receiver, this receiver can perform the calibration task before transmitting the data to the "public" N2k network.

[Tehani]

Originally Posted by Tehani

Since the NMEA0183 transmission is simplex, and there is a single receiver, this receiver can perform the calibration task before transmitting the data to the "public" N2k network.

And do not think that this lasts a long time, there can be a delay of 1-2mS from the reception of each NMEA0183 sentence until the complete transmission in its NMEA2000 equivalent with the applied calibration.

[capn_billl]

I use one of these between each section of N2K. I had some funny issues with some instruments dropping out, (too long of runs, and voltage drop?), and splitting the network power fixed it.

https://www.google.com/aclk?sa=l&ai=...gQIARBC&adurl=



The advantage is if a device shorts out, it only blows the fuse to that group.

My compass backlight is run from the instrument panel lights fuse.

My N2k network power is run from a separate fused line direct to DC panel to a circuit breaker marked GPS.

on the other side of a N2K power separator the mast group is powered by a separate N2K power injector that is also separately fused, and goes to the DC panel on a circuit breaker marked RADAR.

SO far, knock on wood, I've never had the entire network go down, and if a single group is offline, I now know where to go troubleshooting.

[RaymondR]

Originally Posted by capn_billl

I use one of these between each section of N2K. I had some funny issues with some instruments dropping out, (too long of runs, and voltage drop?), and splitting the network power fixed it.

https://www.google.com/aclk?sa=l&ai=...gQIARBC&adurl=



The advantage is if a device shorts out, it only blows the fuse to that group.

My compass backlight is run from the instrument panel lights fuse.

My N2k network power is run from a separate fused line direct to DC panel to a circuit breaker marked GPS.

on the other side of a N2K power separator the mast group is powered by a separate N2K power injector that is also separately fused, and goes to the DC panel on a circuit breaker marked RADAR.

SO far, knock on wood, I've never had the entire network go down, and if a single group is offline, I now know where to go troubleshooting.

Just what I was going to suggest.

But do you know whether the device contains an opto isolator so that the data circuits are split electrically and thereby rendered completely independent of each other? In that way shorting out one would not effect either of the power or data circuits.

[wingssail]

Originally Posted by Tehani

And do not think that this lasts a long time, there can be a delay of 1-2mS from the reception of each NMEA0183 sentence until the complete transmission in its NMEA2000 equivalent with the applied calibration.

And do not think that this lasts a long time, there can be a delay of 1-2mS from the reception of each NMEA0183 sentence until the complete transmission in its NMEA2000 equivalent with the applied calibration.

I think one of the issues with the CV7 is that it has corrections inside it's circuit board that are applied during calibration and saved in non-volatile memory. These are not the calculations to compute the TWD and TWS but to correct for velocity, angle, etc. The problem is that the network device which receives the signals from the CVB7 would need to be able to set those corrections and therefore would have to have the UI and programming to do so. OP alludes to this being an issue.