Question on NMEA 2000 to 0183 conversion

[BjarneK]

As some of you have noticed, I am in the process of building a combined NMEA 0183 multiplexer and NMEA 2000 to and from 0183 converter. It will work with a Raspberry Pi computer. I am at the point where I have a good handle on the NMEA 2000 communication both ways.

I have a couple of questions on the NMEA 2000 to 0183 converter. What is the best solution for multiple NMEA 2000 devices communicating the same type of data? With GPS data, for example, it is best to just receive data from one device. In this case, I can go by the one that has the lowest (or highest) NMEA 2000 device instance number. Or I can make it possible to select which instance is preferred. What do you think? If the instance numbers are the same, I can go by NMEA 2000 address which should always be unique for a given device, but may change over time. Or I can go by the NMEA 2000 NAME which is unique and more constant (the NAME contains the instance number, so can change).

Are there any types of data where you will want NMEA 0183 output from more than one device sendng the same type of data (for example wind speed, depth, magnetic course, etc.)? If the answer is yes, how would you want both devices represented in the NMEA 0183 data stream? For most data type, it seems that the only way to do this is be using different Talker IDs (the first two characters of the NMEA 0183 sentences), but does not seem to be complete freedom in choosing these two characters. Sentences from GPS devices should for example start with "GP".

Any input would be appreciated.

[Pizzazz]

This was a typical problem with NMEA 0183 data devices, how do you select the right one. Manufacturers handle it differently. For example, Garmin products have a function to select the data source on 0183. Typically you would see in the setup menu, select data source: internal GPS, nmea:01 source, nmea:02 source, etc. So for Garmin it would make sense to show all the available data with unique talker IDs. Raymarine would take any talker ID (I think it just ignores the two characters) and treat it as new data. This means that if your GPS positions between the two sources are slightly off, the boat position on the Raymarine display will jump unpredictably. In reality, the problem is only significant with GPS and heading data. It is rare that you have multiple sources for wind, speed or depth. However, if people use your device together with a multiplexer, they can create loops that would multiply the problem. Lastly, NMEA 0183 is typically run at 4800 bps which will create a bottleneck.

A good solution is for the device to test if the data is already present on the network (this means both nmea in and out to be connected) and only put up new data on the NMEA 0183 network if it is NOT already present.

Either way, it gets messy very quickly. This was one of the key reasons the NMEA 0183 standard was abandoned. I would prefer that your device has a web interface that allows the user to turn individual data streams on and off but a lot of people would find this too complicated.

I hope this helps. Note that this is a niche product and you need to make it as simple as possible.

SV Pizzazz

[smac999]

you do not want multiple data on a single nmea 183 line. because it won't be able to seperate it. it will simply use data from both. thinking the data has changed. so if each one is sending every sec. every 0.5 sec it will switch vaules.

2 gps will be slightly different. so the boat will go crazy back and forth every sec.

some devices could chose which com port to take data from if data same data was comming from 2 different lines. but that is different then multiple data on same com port.

[Dsanduril]

If I was multiplexing NMEA in then what I'd like would be a configuration capability (don't really care much about how) where I could assign priority and timeout. If you receive a $GPGLL on port 1 use it, if you don't receive anything for 30 seconds then use the $GPGLL available on port 2. This complicates the MUX but I agree that you don't want two sets of that data on the network.

Another option would be to change the second source to use a $Px talker id and then let the consumer deal with priority and sentence dropping. Of course that means re-casting the lower priority sentence and recalculating the checksum, much easier to just drop something. It would work if the consumer is something relatively sophisticated like OpenCPN or a good MFD, but fails with simpler instruments.

[BjarneK]

Thanks for the replies so far. Notice that I am talking about taking the data from an NMEA 2000 network and putting it into a single NMEA 0183 stream.

For now the question is what to do with multiple NMEA 2000 devices sending the same type of data. It looks like I will just choose one device and forward that to the NMEA 0183 stream. I will make it possible for the user to select which NMEA 2000 device is chosen for forwarding. Ideas are welcome for the best way to choose which NMEA 2000 device (instance number, NAME field, NMEA 2000 address etc.).

[SVHarmonie]

Of course in transferring data from NMEA2K to 0183 there are a LOT of decisions to be made, since there is a LOT more data that moves on a NMEA2K network.

When setting up a NMEA network there is always a way to define the data sources, which ones are used and which are ignored. In my system that is done through the setup on the MFD. You can have it pick from redundant data sources automatically (I have no idea how it decides) or you can chose manually. I know in my system there are several source of GPS data, two units supplying depth data, two sending heading and multiple source of true wind data, and others I have either forgotten or don’t even know about! There is also usually a way of defining priority for critical data sources. A primary GPS and a secondary one to be automatically switched to if the primary one isn’t sending data.

For the user selection it seems it HAS to be the device name. Very few users will have any idea which instance number or network address their devices are.

It would seem to be useful such a device would need a way to intelligently reject a lot of data—not just redundant sources—to avoid totally overwhelming the 4800 BAUD data rate of 0183 data line. I would assume the end user would want control over that.

Is this something different in functionality than an Actisense NMEA2K to NMEA0183 convertor? If they are identical, or similar, their documentation might be a good source of ideas.

[verkerkbr]

If your are using an RPI 3 or 4. The answer for converting NMEA2000 tot NMEA183 is very simple.

You can us the OpenPlotter options and install the SignalK server. Or install the server yourself.

This server converts NMEA2K to SignalK and to NMEA183. You can also use NMEA183 to NMEA2K input.

I'am using this small Canable board ( $ 29,-) to receive the NMEA2K data in SignalK.

SignalK is also a Multiplexer.

Works great.You can also use the NGT-1 from Actisense for this purpose. But this option is much more expensive.

In OpenPlotter there is an application to show all the data that is coming form the NMEA2K bus and NMEA183. With the latest version of OpenCPN the SignalK data can be used direct without conversion to Nmea183.

Bram

[BjarneK]

Originally Posted by SVHarmonie

Of course in transferring data from NMEA2K to 0183 there are a LOT of decisions to be made, since there is a LOT more data that moves on a NMEA2K network.

When setting up a NMEA network there is always a way to define the data sources, which ones are used and which are ignored. In my system that is done through the setup on the MFD. You can have it pick from redundant data sources automatically (I have no idea how it decides) or you can chose manually. I know in my system there are several source of GPS data, two units supplying depth data, two sending heading and multiple source of true wind data, and others I have either forgotten or don’t even know about! There is also usually a way of defining priority for critical data sources. A primary GPS and a secondary one to be automatically switched to if the primary one isn’t sending data.

For the user selection it seems it HAS to be the device name. Very few users will have any idea which instance number or network address their devices are.

It would seem to be useful such a device would need a way to intelligently reject a lot of data—not just redundant sources—to avoid totally overwhelming the 4800 BAUD data rate of 0183 data line. I would assume the end user would want control over that.

Is this something different in functionality than an Actisense NMEA2K to NMEA0183 convertor? If they are identical, or similar, their documentation might be a good source of ideas.

Ok, so some users certainly have several devices outputting the same type of data. I will try and find a good solution for choosing which device to forward data from. The particular situation I am working on now is to get the data on a Raspberry Pi. The use case for that would typically be to forward the data to OpenCPN, some other plotter program or a visualization of the data (e.g. a web server). In these cases the data rate is not a big issue.

I am also considering making a hardware-only solution that translates NMEA 2000 to 0183. I already have a prototype for that which feeds my VHF radio with GPS data from the NMEA 2000 network. This device is more like the Actisense converter since it does not involve a Raspberry Pi. In such cases, bandwidth is more of an issue, but I guess most devices can receive 38,400 baud these days? The solution must be to make it possible to select which output sentences are needed and to give a minimum time between transmissions of each sentence type.

[BjarneK]

Originally Posted by verkerkbr

If your are using an RPI 3 or 4. The answer for converting NMEA2000 tot NMEA183 is very simple.

You can us the OpenPlotter options and install the SignalK server. Or install the server yourself.

This server converts NMEA2K to SignalK and to NMEA183. You can also use NMEA183 to NMEA2K input.

I'am using this small Canable board ( $ 29,-) to receive the NMEA2K data in SignalK.

SignalK is also a Multiplexer.

Works great.You can also use the NGT-1 from Actisense for this purpose. But this option is much more expensive.

In OpenPlotter there is an application to show all the data that is coming form the NMEA2K bus and NMEA183. With the latest version of OpenCPN the SignalK data can be used direct without conversion to Nmea183.

Bram

Thanks, I will try to set up SIgnalK and see how it works. Getting to know NMEA 2000 is one of the reasons I am doing this, so even though other solutions exist, I still want to experiment. Also, I might make a stand alone NMEA 2000 to 0183 converter without a Raspberry Pi. To make that, I need to know how it all works.

Cool that OpenCPN now also works directly with SignalK data. Maybe my board would be useful for Signal K users. It will have eight NMEA 0183 inputs and an NMEA 2000 connection.

[OS2Dude]

Our Simrad EVO2 and B&G Vulcan 7FS allow me to specify the source of the various data types. I believe it does this via the SID portion of the data sentence. When setting the source, it lists all the devices that are transmitting that type of data, then I highlight the one I want and press ENTER. IIRC if there are multiple sources and I do not specify which one, it will use the lowest number (01) as the source.

[tanglewood]

Multiple sources for the same data is very common in larger boats, so it has to be supported for any credible product. If you are just hacking up something for your own use, then whatever works is fine.


Regarding N2K device selection, it's supposed to be done based on the NAME field. That's the globally unique and immutable identifier for a device. Addresses definitely won't work because they can and will change at any time. That's a key part of N2K. Some vendors cheat and just use Device Instance, but it's an unreliable approach since many products do not have a readily programmable Device Instance. Maretron is the biggest offender, and I think Garmin does it too. On, and picking the lowest address doesn't work well either. I have seen plenty of cases where a device gets configured with a low address, but the better data source is something else. Just consider multiple GPSs. One might be a sat compass and have the highest quality position fix, where another may support WAAS, and a third may not have any augmentation. None of that will be reflected in the addresses they are assigned, yet there is a clear priority order in which the devices should be used.



Also make sure you are familiar with the difference between Device Instance and Data Instance. The Data Instance is carried in the data PGN and makes it self-describing. Quite a few PGNs distinguish data sources this way.


As for an 0183 data stream, it's by definition single source for each Sentence. Different sources come in on different physical (or logicial) channels.

[tanglewood]

Originally Posted by Pizzazz

This was one of the key reasons the NMEA 0183 standard was abandoned.

Abandoned? Hardly. It's alive and well. IMO devices are all 0183, and N2K is still not approved for them.

[BjarneK]

Originally Posted by tanglewood

Multiple sources for the same data is very common in larger boats, so it has to be supported for any credible product. If you are just hacking up something for your own use, then whatever works is fine.

It is probably somewhere in between. It would be nice if other people would use it, but it is not going to be a real product. For one thing, the software and hardware design is going to be free.

Originally Posted by tanglewood

Regarding N2K device selection, it's supposed to be done based on the NAME field. That's the globally unique and immutable identifier for a device. Addresses definitely won't work because they can and will change at any time. That's a key part of N2K. Some vendors cheat and just use Device Instance, but it's an unreliable approach since many products do not have a readily programmable Device Instance. Maretron is the biggest offender, and I think Garmin does it too. On, and picking the lowest address doesn't work well either. I have seen plenty of cases where a device gets configured with a low address, but the better data source is something else. Just consider multiple GPSs. One might be a sat compass and have the highest quality position fix, where another may support WAAS, and a third may not have any augmentation. None of that will be reflected in the addresses they are assigned, yet there is a clear priority order in which the devices should be used.

Thank you for this very useful information. I will use the NAME field. Is it right that it is immutable, though? It contains the device instance field which can be changed. I agree that it is globally unique which is useful here.

Originally Posted by tanglewood

Also make sure you are familiar with the difference between Device Instance and Data Instance. The Data Instance is carried in the data PGN and makes it self-describing. Quite a few PGNs distinguish data sources this way.

Thanks, I was aware of that, so will take it into consideration.

Originally Posted by tanglewood

As for an 0183 data stream, it's by definition single source for each Sentence. Different sources come in on different physical (or logicial) channels.

Good point. It would be fairly easy to make multiple NMEA 0183 streams if needed, since it will (typically) be over a network from the Raspberry Pi. A few NMEA 0183 sentences allow for multple devices with the same type of data, such as RPM which gives engine data for a particular engine. Also RSA with rudder angle information allows for port and starboard rudder sensor. In a way this is the same type of data, but since they refer to different instances of engines and rudders, several can co-exist on the NMEA 0183 network. This seems to be the exception, though.

[tanglewood]

You are correct about Device Instance being part of the NAME field, and so not really immutable in its entirety. But unlike the device address which is dynamic and can change during a reconfiguration, the Device Instance only changes if someone does it intentionally. And even if it does change, it’s not possible for some other device to now appear to be the one you were previously using.

Really the NAME is a range of values, and that set is immutable. The key is that one device can’t suddenly look like another device.

[Tehani]

In the case of two or more GPS / GNSS receivers you can use the "GNS Method" field in PGN 129029, to decide which one is more accurate, take your ID, and filter the others.

You can also set a prescaler in the NK2 frame processing, so as not to clutter the NMEA0183 data output. I do these with the "Rapid Update" data, establishing an average at N2K speed.