Nemo gateway – easy NMEA networking for your boat

Connecting marine electronics together is an important goal for modern boaters. Many different ways exist to do this, but most require gateways or direct connections to larger equipment. Once you have them connected, configuration and being able to use all the data effectively from as many devices as possible is usually the next challenge. The Nemo gateway from Rose Point is an easy way to connect everything together, while also easily providing high quality, frequent data to a number of sources.

Rose Point is one of my favorite manufacturers because of Coastal Explorer. I’ve used it since 2007, and I think it is the best PC navigation software you can buy. They have a great relationship with their customers, and a very open way of doing development that other manufacturers should really try to emulate. When I heard they had developed a gateway product, I was very interested in it given their reputation.

Hardware

The Nemo hardware is a thing of beauty. It is a well milled piece of metal with some heft to it. All of the connectors are removable terminal blocks which make it easy when wiring. It can accept a wide DC input voltage of 8-32v, and draws 0.2 amp at 12v, and 0.1 amp at 24v – nice for us sailboaters with smaller power reserves.

On one side you have a NMEA 2000 port and power, as well as a USB accessory port for a Rose Point GPS system if you have one.

On the other side is a bevy of NMEA 0183 connections and an ethernet port. For 0183, you have two talkers and 4 listeners.

I ended up connecting my VHF radio to the Nemo since it only has NMEA 0183.

Removable terminal blocks are great to get the fiddly little undersized wires used in NMEA 0183 securely connected and working.

Setup

One of the more interesting things about the gateway is how easy it is to setup. After initial connections to my NMEA networks and power, I was immediately able to connect to it and see sensors and data flowing correctly.  This is seriously one of the quickest configurations that I’ve ever had for a marine gateway or other similar device. Most of them require defining all sorts of things before any data even flows, or require other hardware/software to get started.

I initially accessed the Nemo via its built in webserver, but you can also use Coastal Explorer (more on that below) or Android or iOS apps. It has the usual settings you would expect – networking, firmware updates, security options, etc. plus a lot more for the actual devices connected to it.

One thing that is nice is the ability to set a password. You’d be surprised how many marine electronics have static, crappy passwords, or none at all.

You can change just about anything you could need – in the example above, if you have two position sensors, you can drag them into the order you would prefer or disable individual ones.

Clearly the Nemo designers thought a lot about user experience – the device is quick to get going, easy to use through a web browser, and doesn’t require clunky software.

Coastal Explorer Integration

One of the best features of the Nemo gateway is the ability for it to automatically configure itself inside Coastal Explorer. To start, make sure your computer is on the same network as the Nemo, turn it on, and open up Coastal Explorer. If you have a modern version of CE, it will detect the Nemo on the network, auto-configure, and you’re ready to go!

In Settings under Electronics, you’ll see the Rose Point Nemo Gateway automatically configured and working in the list of devices. In my case, you can see a Vesper AIS device and iKommunicate which I also had configured.

You can interact with the gateway directly from Coastal Explorer. It looks like Rose Point have wrapped the entire web interface for the device inside of CE which allows you to do anything you could do directly on the webserver without leaving the program. This makes for a seamless experience in one place, which is nice if you are a heavy Coastal Explorer user.

I have found the frequency of data from the Nemo to be much higher than all other gateways and products I’ve used in the past. Part of this is because of the way they send the data out from the gateway – something called multicast.

Most devices have services that wait for your computer to connect to them, negotiate some bits, and then the two happily talk to each other without bothering anyone else (commonly called unicast). Multicast means that the Nemo gateway is sending out all of the data from all of your devices to your network, all the time, for every device to consume.

This is the default configuration, and makes it easy for you to get started using the gateway. It also allows other apps to immediately start consuming the data without much configuration.

Deeper Configuration

Whether you use Coastal Explorer or a web browser to interact with the Nemo, there are a wealth of settings and screens to interact with. Not only can you configure the device, but the depth of information you can see on the network, devices, and data is amazing. I actually use the Nemo gateway as a debug tool when working on my NMEA networks.

The NMEA 2000 Network detail page shows all of the connected devices on your network and their status indicated by a little dot – whether they have been active on the network recently. This has been great when I have been hacking on my network to make sure everything is still powered up and connected.

Here’s where my geek gets even more excited – the amount of data, presented in a usable fashion, without complex PC programs or debug stuff, is simply excellent. You can see above my Raymarine Axiom chart plotter and all of the types of data it is sending. The data itself is not decoded, as I suspect that would require a lot of custom formulas and conversion, but I can see that the chart plotter is sending what I would expect it to send.

Here’s another example showing my Maretron depth, speed, and temp sensor. You can see the identified PGNs that the Nemo has highlighted in bold, and the data changes as fast as it is coming through the gateway, which shows you that things are working / being transmitted.

Similarly, NMEA 0183 also shows all of the sentences coming into the gateway. Above, you can see my VHF radio sending AIS data into the gateway. In the case of NMEA 0183, sentences aren’t decoded, but having lived in that world for years, I know that AIVDM are AIS target updates from various ships. Most helpful with 0183 is the fact that you can see data flowing through, knowing that you got your wiring correct, and that baud rates at both ends are setup correctly.

NMEA 0183

NMEA 0183, while quite old, is still present on many boats. I have a VHF radio that still uses it, and I want its data on all of my networks. With the Nemo gateway, you have 2x talker ports and 4x listeners that you can leverage for that older equipment, which is quite a bit more than I’ve ever seen on a single gateway product.

For mobile apps that need NMEA 0183 over your ethernet network, like iNavX, NMEAremote and others, you can configure NMEA 0183 over UDP. This sends out a UDP stream of NMEA 0183 data on port 10110 that you can use with other apps.

Beyond just turning it on, you can choose what sentences you want sent out over UDP and adjust many other parameters.

Besides the different sentences, you can change the frequency at which they’re sent, the source of the data, or completely turn them off.

First, you can choose the sentence you want to generate, and there is a pretty extensive list to choose from.

Next, you can choose the talker ID that the data should show up from – this is an option I have very rarely seen on any other gateway without advanced configuration.

You can choose the source for the data itself, if you have multiple devices that generate the same type.

Finally, you can choose the frequency for updates in quite a wide set of options.

Many other gateways that I’ve used have some of these features, but they require absolutely terrible PC software (usually does not work on Mac) or adapters, or esoteric understanding about sentence names and types to configure. Rose Point have made their gateway not only supremely configurable, but usable by anyone. Clearly their attention to user experience and design from products like Coastal Explorer have flowed into the Nemo.

Mobile App

There are Android and iOS apps for the Nemo gateway which allow you to interact with the gateway without using a web browser.  I’ve used it for quick debugging on my network while away from the computer.

The interface is a carbon copy of the web interface, which makes it easy to transition between one or the other.

Just like with the web interface, I can see data flowing in from my depth sensor, but in this case, I can see it quickly on my phone.

Checking on NMEA 0183 data while configuring my VHF radio…

Gateway

One of the most important parts of a gateway is to be able to unify the different networks together, and the Nemo doesn’t disappoint here either. Devices on NMEA 0183 can send things to the gateway, which are sent through to NMEA 2000 and vise versa. With the options above for granular control over sentence generation on NMEA 0183, you have a lot of flexibility as to what you’d like to send where, from where, and how frequently.

In addition, if you have multiple sensors for Depth, Heading, Position or Speed, you can create a prioritized list of the available sensors so that the one you consider best is used first. In the event that the primary fails, secondary items are used. I have at least 3 heading sensors (Raymarine chart plotter, Raymarine autopilot, AIS) and multiple position sensors (Raymarine chart plotter, AIS, VHF) and this allows me to make sure the one I trust the most is used if it is on and functioning.

Local Network & Apps

While a gateways primary purpose is to unify NMEA 0183 and 2000 and provide granularity there, the Nemo also goes one step further and spits all of its data out onto the local network. In todays connected world, it is expected that any network boating device does something to share its data with computers and apps. As covered above, it of course works with Coastal Explorer, but also sends out a UDP stream to port 10110 that devices can consume.

I used a bunch of different applications including TimeZero Navigator, OpenCPN, and SeaNav US on my PC and Mac systems. All were easily configured and immediately started showing data.

For apps, I’ve used NMEAremote, iNavX, SeaNav US, and a number of others. All were very easy to configure, and worked well.

The Nemo would be a great way to have high quality, rapid updating data for PC or tablet navigation as well. The multicast stream and adjustable update rates for specific data types makes the experience more customizable depending on what you are doing – I could see racing folks liking the high frequency updates for performance information, and tuning down the non-essential stuff.

Support

One factor in anything I use on my boat is how well it is supported. I look for products that have support included as part of the purchase for a decent length of time, as well as active, open forums or other similar communication methods.

Rose Point has always had a great community behind Coastal Explorer, and that continues with Nemo. The same forum system used for CE is available for Nemo, and has helpful people responding both from Rose Point, and end users.

In addition, while I was testing my Nemo unit, I had some weird things going on with one of my Raymarine autopilot components, and Rose Point support was super helpful, very responsive, and got to the root of a rather detailed problem as quickly as I would have expected. It turned out to be something wrong with my network, not their product, but their technical expertise both with their product, and the devices surrounding it was impressive. Thanks to Marius, Garth, and Chris for their help!

Comparisons

Gateways (sometimes also called Multiplexers) have been around for a long while. I remember using NMEA 0183 only devices in the early 2000s, and even had a ShipModul brand back in 2007 that allowed 0183 stuff to talk together.

Actisense has been one of the biggest names doing 0183 to 2000 conversion, and their NGW-1 is quite popular. However, this requires PC software to configure, and only allows one NMEA 0183 device to connect to the NMEA 2000 network. This solution is around $230. You could combine multiple NMEA 0183 devices with an upstream device, but you’d probably end up paying $200 more for that, and have two different pieces of hardware to manage, and no granularity between who hears/sees what. In addition, this device has none of the WiFi / local network connectivity features at all.

Yacht Devices has a similar product in the YDNG-02 for $149, but it is also a single NMEA 0183 device, has less configurability, and has no local network features either.

iKommunicate, which I am a big fan of because of my love of SignalK, sells for $300, and has more NMEA 0183 talkers and listeners than the above devices, but still falls short of the Nemo Gateway. It also has extremely limited configuration options for what flows between networks and configuring sentences on NMEA 0183 – it would require a lot of work to even get close to the functionality and ease of use in the Nemo. It also has not gotten many updates since its release, which is a bit worrisome.

Using a chart plotter is also an option to connect NMEA 0183 and 2000 together. Most of the main manufacturers have at least one NMEA 0183 input and output, some have a few more. The challenge for most configs is cabling length from the 0183 devices to the chart plotter, and the limited configuration options. Most only allow you to connect a VHF radio or AIS device, and have limited control over the sentences that come and go between them. There are forum posts filled with people trying to decode what chart plotters allow through or translate back and forth. You also still have the limitation of only one or two NMEA 0183 devices, and most chart plotters don’t stream data out to other devices very well.

The Nemo Gateway sells for $699, and while that is a higher price compared to the above, you are getting a clearly premium product combining multiple of the items above. You don’t have to have programming level experience to get it going, buy additional software or adapters to configure it, and can use it from just about anything without a lot of effort. I personally am willing to pay more for something that is more usable and reliable, and gives me more time to spend on the water.

Summary

If you need a gateway on your boat to unify NMEA 0183 and NMEA 2000, or you need a device to allow computers and apps to consume data from your existing network, I would highly recommend the Nemo Gateway. If you have more than two NMEA 0183 devices, you definitely should look at the Nemo, as it is one of the only devices out there that can handle multiple connections with extended configuration. If you are a Coastal Explorer user, it also would be an essential add-on that provides a high quality data stream to multiple PCs around your boat. It is easy to configure, has more options that most gateways I have seen, doesn’t require expensive software or hardware to use, and is extremely well built and designed.

19 thoughts on “Nemo gateway – easy NMEA networking for your boat

  1. How about a summary for beginners? I am just trying to get into marine networking and find it all a bit byzantine. It reminds mea bit of the old coax networks. I have an old e80 char plotter with ST60 instruments (which i believe are NMEA 0183 although they are called Seatalk) and AIS being fed by my Standard Horizon VHF. Would something like NEMO be appropriate to act as a bridge to more modern devices like my laptop or tablet?

    I love you posts even though I only understand about half of them 🙂

    • NMEA networking can be somewhat confusing. If you add computers and tablets, that can make it even more complex as well. The Raymarine E80 actually has a decent amount of connectivity. It has 1x each of NMEA 0183 input and output, SeaTalk, which is Raymarine’s proprietary protocol, and likely how your ST60s are connected, and one SeaTalkNG/NMEA 2000 port. That is a pretty good mix, and similar to even modern chart plotters, which usually have NMEA 0183 and NMEA 2000.

      I have ST60 instruments as well on my boat, but I put in an ITC-5 (which I wrote about recently) that puts that info right on my NMEA 2000 network. If you ever decide to replace your E80, that is what I would do if you want to keep the ST series stuff, which most people do since there are long cables to the mast and hull for the sensors.

      It sounds like you have something like this:

      E80 NMEA 0183 < -> Standard Horizon VHF
      E80 SeaTalk < -> ST60 instruments

      The Nemo could definitely bridge from your E80 via the NMEA 2000/SeaTalkNG port so you could access everything from a tablet, PC or otherwise. All you would have to do would be plug it in to your onboard WiFi/LAN network (I assume you have one of those!) and plug it into your E80, and you’d see all of the data.

      However, you could go one step further, and have your Standard Horizon VHF connected to the NEMO as well. That would mean that other devices could consume the data from the VHF, and if it has a GPS inside of it, you could use it as a backup or secondary position sensor if you were using a tablet or something else.

      • E80 NMEA 0183 < -> Standard Horizon VHF
        E80 SeaTalk < -> ST60 instruments
        …so simple 🙂

        Ah, things become clearer… How would the VHF connect to the NEMO? By 0183 instead of going to the e80 or split somehow to both?

        Because the basics of NMEA elude me. Is it a star topology like 10 base T or something more linear? From my reading it looks like it can be both. As you can see i know just enough to be dangerous and have failed to find any good starting points. And the nature boat means it ain’t as easy as hit-or-miss screwing around with the LAN.

        Bruce

        • The cleanest and most expandable way would be to have the VHF directly connected to NMEA 0183 ports on the NEMO, the E80 connected to the NMEA 2000 port on the NEMO, and then the NEMO connected to your LAN. The ST60s remain connected to the E80, and it forwards their data out onto NMEA 2000 to the NEMO as well.

          If you decide to add more NMEA 0183, or find something else that is on that network, then you can connect it to the NEMO. If you decide to add NMEA 2000 (that would be more likely, like an AIS transponder, etc.) then you could add it to your new NMEA 2000 network.

          For the NMEA 2000 network you would need the basics there to get started – some conversion cables from the E80 and terminators and such, but it is a good foundation to have for adding other things in the future.

  2. I was about to purchase iKommunicate when I came across this excellent writeup. NEMO is clearly superior if one doesn’t need the SignalK dimension (I don’t). BUT I want to use TimeZero (Maxsea/Nobeltec)….did you get to the bottom of the issue with doing this you found??

    • I can’t remember exactly what didn’t work correctly, but I think it could have been a configuration error. I will re test it today to see if it will work now that I am in a stable configuration and post my result here.

      • TimeZero Navigator seems to work fine now. This is a newer version (v3.3) than the one I tested with so perhaps something was fixed? I’ve attached what TimeZero detected when I scanned the NEMO with TCP. Next one will be UDP.

      • Here is what TimeZero sees on the NEMO using UDP. Notice that AIS is not detected, so there could be something I need to adjust on the NEMO to send that out on UDP, although I see it in Coastal Explorer natively, so not sure.

      • Final one is TimeZero pointed at TCP on SignalK just to show the different sentences detected. Strangely SignalK isn’t producing true wind speed or direction, while both NEMO options did not detect true wind direction – I had to manually select that. I think that might be because there is absolutely no wind today, but am not 100% sure.

        So it does appear that TimeZero works fine as far as the basic instruments. If you get into auto pilot routing and the other things, your mileage may vary as that is very specific to the auto pilot manufacturer, not necessarily the NEMO or TZ.

  3. Steve: perhaps UDP’s absence of a ‘checksum’ routine means it lets some corrupted AIS packets through that would be filtered out in TCP…not sure. Also, right now my TZ install gets AIS (VDM) from a Standard Horizon VHF-AIS Receive radio . The radio itself multiplexes the VDM sentence with DSC (both DSC & DSE sentences) @ 38400 baud. Any idea if MEMO would cope OK with that…or should I post that Q on the CE Forum?

    On the a/pilot, it works perfectly now with TZ though it is older and non-Furuno. I don’t think a gateway like NEMO would be doing anything weird to the Nav out sentences (APB, XTE etc) that the a/pilot needs to follow a route.

    Really interesting to see NEMO develop, not just for the tech reasons but for the ‘commercial’ implications. Furuno now has PC-direct radar and sounder options that don’t require a MFD to sit in the ethernet network (or anywhere). So if 0183 & N2K devices can be ported over to ethernet, why bother with an MFD?

    • In terms of a Standard Horizon radio, I have a GX2200 connected to my NEMO and that all works fine. I don’t think there would be any issues with that config.

      How do you have your TZ system connected to your autopilot now? If you change to rely only on the NEMO you may need to configure it to allow it to write back to the network for the autopilot piece.

      I still see the need for MFDs because they are marine grade, can be in a cockpit with bright sun and salt water, and are generally more stable and reliable than PC programs. But the time is coming when an iPad or PC protected correctly will supplant them – we’re getting closer every iteration.

  4. Steve: currently, I have a digital heading sensor connected via 0183 to my MFD AND to my autopilot. The MFD sends 0183 Nav data to the a/pilot. TZ on a laptop connects via ethernet to the MFD and I can load routes from the laptop to the MFD; and edit these routes, add/delete waypoints, enter GoTo marks, etc etc in real-time while underway and under a/pilot control. I can do everything on the laptop that I can do via the MFD (and then some). I THINK that when I’m using the laptop underway like this, the MFD is “just” playing the role of a gateway between 0183 messages and ethernet…..and I assumed that NEMO would take over this role. Does this sound right to you?

    And yes, I should have qualified my earlier statement to the effect that the PC or non-marinized monitor needs to be protected. I have a lower helm that is totally enclosed/protected that my laptop (and MFD) lives in very happily. When I helm from the outside station, I have a dumb marine monitor there and I operate the laptop’s controls via a Bluetooth mouse and keyboard.

    • The setup you’ve described makes sense. However, I am not sure that the NEMO would take this over seamlessly. I assume you are using TimeZero on your laptop and you have a Furuno or TZ MFD? If so, you may be exchanging data with it via their own methods, not something standardized.

      NEMO will expose 0183 and 2000 via Ethernet, but if you are doing something proprietary between the PC and the MFD, it may not understand that. I would need to know more about that part of the setup.

  5. Steve: your raised a very valid point re: the a/pilot link & that sent me scurrying back to the (super detailed) TZ User Guide. It points to a special “Data Output Routine” within the TZ SetUp Wizard that is used to configure a data output to an a/pilot or ‘other instruments’; and then tells users to first look up in the a/pilot manual what sentences are required (usually APB & XTE, but varies by a/pilot model).

    The Data Output Routine begins by requiring the user to add/configure a Serial (or USB-to-Serial adapter) port OR a UDP or TCP port if ethernet is to be used. Since the laptop will connect to NEMO via ethernet, I suppose a UDP port should be used (?). Whichever port type is selected, a drop-down list of 0183 sentences appears and those to be sent to the a/pilot are “ticked”. My own a/pilot’s manual asks for groups of sentences in this order:
    RMB and RMC
    RMB and GLL
    APB and GLL
    APA and GLL
    BOD and XTE
    My a/pilot’s search stops on the first complete group. If only one sentence is found from the
    above combinations, the autopilot operates from the data in that sentence.

    Hit “Finish” when done with selecting sentences and that’s it. TZ User Guide then goes on to set out a testing routine to ensure the a/pilot link is properly set up & working. It says that if a problem is detected, to try changing the status of the NMEA Talker from “II” to “GP”. Frankly I have no idea what any of that means and hopefully, won’t need to!

    Back to NEMO: I’m still supposing that once this is all done in TZ, in NEMO I set up one of the two 0183 Outport ports to send the Nav sentences and connect this to the a/pilot’s NMEA: IN port.

    So while I’m a little fuzzy around exactly what ports to set up in TZ, it does seem that TZ is designed to directly output 0183 data to an a/pilot without the intervention of an MFD. Would really appreciate hearing your opinion on all this !

    • It sounds like the NEMO should work with this setup. I don’t use TZ to drive my autopilot – I either use my Raymarine MFD or Coastal Explorer. Coastal Explorer is likely using the same method – sending specific sentences to the NEMO gateway which then in turns send it out to the various devices that consume it.

      I will see if I can test this out later today with TZ.

    • Well, I think this might be where you need to post on Coastal Explorer’s forums for more information. I configured TZ to use UDP and TCP and can see the data coming into the NEMO, but my autopilot is not using that data.

      Keep in mind I have not read up fully on what my autopilot would require from TZ to get it to work. However, I was able to use Coastal Explorer (instead of TZ) with NEMO and was able to plan routes and such and the autopilot was happy with that.

  6. Steve: I really appreciate your testing efforts…many thanks! I think I’ll put in a Support Request to TZ first. I’ll post what I learn from that back here.

  7. OK, I checked in with MaxSea support on this. They say there is absolutely no reason why TZ Navigatorv3 should not be able to drive the a/pilot without the involvement of the MFD. They have detailed instructions on just how to do this and how to test that all is working properly once connections are made, too. Biggest issues are ensuring the right com port is set up I Navigator; and that the correct 0183 sentences are being sent to the a/pilot.

    I will try this when I get chance….though that is some months off I think.

Leave a Comment

Click here to subscribe to updates without commenting.