Using the NMEA 0183 Wi-Fi Gateway

Using the NMEA0183 Wi-Fi Gateway

 

The Gateway is easy to use but, as with device, a bit of attention is needed to ensure that the settings match between the Gateway and the app on your phone, tablet or PC. The gateway is shipped so that it will connect without needing any configuration in most cases. Once set up, the settings will be saved, so it is always a lot easier to reconnect than to make the initial connection.

Using the gateway requires the following three things to be set up correctly:

  • The NMEA connection to your instruments
  • The connection to your Wi-Fi network
  • Connecting your app to the gateway

The NMEA Connection

With your Gateway wired to your boat’s instruments, the data rate needs to be set correctly for the two to communicate. By default the Gateway operates at the standard NMEA data rate of 4800bps, but it can be configured to operate at other speeds if needed, including the 38400bps used by AIS and some other devices.

The other aspect to be configured is the NMEA settings in your instruments. In many instruments you need to go into their configuration menu to switch on the NMEA0183 port on the instrument, and to select which messages you want to send and receive. If you have a choice of versions of the NMEA0183 standard, it is almost always best to choose the highest numbered one, as each version adds new sentences and new fields, whilst retaining backwards compatibility with earlier versions. As for the sentences, if your app lists the sentences that it supports then it makes sense to enable all sentences supported by your app, or otherwise the NMEA Revealed web site is a good starting point to understanding what data each sentence contains, if you don’t want to buy the official NMEA standard.

Some apps, in particular the more powerful PC applications, also let you select which sentences they will read in and send out. If this is the case, then you can go through the same process of selecting NMEA sentences once you have the app connected to the instruments, though generally you can just accept all sentences as input. However you may want to think about what sentences you output – do you want to be able to output the route and waypoints from your app, or control your autopilot, or do you want to leave that to a dedicated chart plotter? If you enable it on both, then at some time there will be conflicts, and having your chart plotter and your app send conflicting commands to your autopilot could get it very confused!

Once this is set up, you are unlikely to need to change these settings unless you change your instruments or your app.

 The Wi-Fi Connection

Before your app can talk to the Gateway, the device the app is running on needs to be on the same Wi-Fi network as the Gateway. 

If, like most small craft, you do not have a router on board, then on your device you need to switch Wi-Fi on and select the Gateway’s Wi-Fi network SSID of TeamSurv-nn-nnnnnn (where nn-nnnnnn is the serial number of your Gateway, shown on a label) and connect to it. The default password is teamsurv, though hopefully you will have followed good practice and gone into the configuration to change this. You may get a warning that the Wi-Fi network connection does not have internet access, which you can ignore.

If you do have a router on board, and you have configured the Gateway to connect to the router, then you just need to connect to the boat’s Wi-Fi network as set up by the router, using its SSID and password.

At this point your device and the Gateway are connected on the same Wi-Fi network, so your software can talk to the Gateway. The last step is to set this up.

 The App Connection

Now you need to get your app and the Gateway talking to each other. To do this, we need to match up three settings: selecting the TCP or UDP protocol; matching the IP address; and matching the port number. If using TCP, you may also want to configure the timeout setting. To some extent, the settings here will vary according to the capabilities of your chosen app.

To set up the connection in the app you will need to find the screen to make a connection to the instruments. If you need to change anything in the Gateway, this can be done through the configuration pages in your web browser.

Auto Configuration

To make things easy, our Gateway broadcasts its current connection settings, and lets apps change its configuration, so if your app supports this  it should configure itself automatically once on the same Wi-Fi network, with no need for any input or technical knowledge from you. If your app doesn’t support this, why not ask the developers if they can include it in a future release, as it will make configuration much easier for their users?

TCP or UDP?

There are two protocols that can be used: TCP or UDP, though many apps support just one or the other. TCP is bi-directional communications between a pair of devices, so as well as receiving NMEA data from the instruments it also lets you send back data such as routes, waypoints and autopilot commands, so you need to choose it if you want to output data from your app. It is also the most efficient and secure protocol, but the number of TCP connections, and so the number of simultaneous users, is often restricted (to 3 on our device, but just 1 on many others). UDP broadcasts data from the gateway to any app that may want to listen in, so the app cannot send data back to the instruments. Whilst easy to configure, and capable of supporting an unlimited number of devices using the data, data is prone to corruption and can only be sent out from the instruments to the app; it also slows down the performance of the Wi-Fi network as a whole.

By default the Gateway is set up to support both TCP and UDP, so no configuration is necessary at that end. Your app may support either TCP or UDP or both, and some apps may give a choice of UDP Broadcast or Multicast (the difference between these is described in the IP Address section next). Given a choice, our recommendation is that you use TCP and switch off UDP in the Gateway; failing that, use UDP Multicast; or otherwise use UDP Broadcast. You can read more on the pros and cons of TCP and UDP in this blog entry.

IP Address

Your app needs to now where the Gateway is on the network, to be able to open a communications link. Broadcast UDP is the easiest to configure here – as it is open to anyone to listen in to, no IP address is needed.

Both TCP and Multicast UDP require the app to know the IP address of the Gateway, and this should be entered in to the app. If the Gateway is being used in stand-alone AP mode, then the default IP address is 192.168.4.1. If you want to use UDP Multicast, then you need to switch to this in the Gateway configuration, and a default IP address is shown there (though you can change it).

If you are using the Gateway through a router, and the app cannot auto configure itself to the Gateway, then the easiest situation is if you allocated a fixed IP address to the Gateway, in which case you just enter that into your app. Otherwise, the DHCP Server in the router will have allocated a random IP address which may change with time, so you will need to go into the router to check it – for this reason, use of a dynamic IP address is not recommended unless the app can configure itself to the Gateway.

Port Number

As the IP address is specific to the Wi-Fi connection on a device, and is shared by all apps, more information is needed to route data to the right app, and this is given by the port number. This needs to be set up for all connection types, and the values in the app and the Gateway must match. The TCP and UDP ports can have different port numbers, though by default they are the same. The Gateway’s default port number is 10110, the official port number for NMEA data.

If your app uses the official port number of 10110 then that’s great, as there is nothing to change. If the app either isn’t set up with a default port number, or it is but it is not the one in the Gateway and is editable, we suggest you edit it in the app connection settings to match the Gateway value. Unfortunately some apps have a fixed port number, in which case you need to change the configuration in the Gateway to match, and if  anybody on the boat wants to use another app then they need to change the port number to mach.

Time Out

If you have a TCP connection, then it makes sense to enable the time out option in the Gateway, as this ensures that if a TCP connection is not properly closed down then the Gateway can close it, to prevent all of the TCP ports being used up by these orphaned connections, and so the device requiring a reboot. For this to work, your app needs to be able to output NMEA data, and you need to switch this on with at least one sentence being output. If your app cannot output NMEA data, then you cannot use the timeout facility, as the Gateway needs incoming data to know that the app is still up and running.

If the timeout is not running (which is the default) then if you find that when you try and start your app (or, for iPhones and iPads, you bring it up on the screen from the background), it can no longer connect to the Gateway, then this is probably because of too many orphaned connections, and you need to restart the Gateway by pressing the Reset switch to clear them.

If the timeout is running and you find your app loses its connection with the instruments, then this could be because your app is not set up to send NMEA data to the Gateway. If this is so, then you either need to enable NMEA output in the app, or switch off the time out by setting the time period to 0 in the Gateway’s configuration. If the app is outputting NMEA data and it still loses the connection occasionally, it could be that it is getting out of Wi-Fi range, and setting the timeout to a longer period in the Gateway will fix it.