Data may be sent from your instruments to your app by one of two protocols: UDP or TCP. Whilst some apps, and some Wi-Fi gateways, support just one or the other of these, if you have a choice which is the best option? Let's first cover some basics, then look at both in turn over networks in general, and then add in some peculiarities of Wi-Fi, before drawing some conclusions.
To make a connection between two pieces of software over a network, each requires an IP address that identifies the device the app is running on (or, more precisely, its network port), and a port number (the connection within the device). Many data protocols have standard port numbers, e.g. port 80 is used for HTML, which brings web pages into your browser; the registered port number for NMEA data is 10110, though a significant number of apps don't follow this, and use their own port number. These may be seen as being analogous to a street address and a flat number (or apartment number in America) within the building.
Network connections can be unicast, broadcast or multicast. Unicast connections are point to point, so there is a dedicated connection between the applications running at each end - in our case the Wi-Fi gateway server at one end, and the marine app at the other. Broadcast connections are, as you may expect, when an application just squirts out data on a given port regardless, and other apps can decide to receive it or not. For this, a number of publicly known IP addresses are used (e.g. 255.255.255.255). Multicast is similar to broadcast, in as much as it is also one to many, but instead of broadcasting on a public address, a specific address (in the multicast range) is used, and listeners need to subscribe to the service using the specific IP address and port number - but the sender never knows which (if any) devices are listening in. A point to note is that with a unicast connection there can be two way communications, whereas with broadcast or multicast this is not possible (without some deep network jiggery pokery).
TCP is a bi-directional unicast protocol with guaranteed delivery - the recipient of the data sends an acknowledgement, and if this is not received the data is re-sent. There is some network overhead for the acknowledgements, but on a typical marine network this is not significant. This sounds ideal, as for example the app can both receive GPS and other data, and send commands out to the autopilot, plus the data is guaranteed to get there. So why would anyone want to use anything else? There are a couple of drawbacks, for both the app user and the gateway manufacturer.
First, for the gateway manufacturer, to support TCP needs a more powerful processor with more memory - there is a need to support a separate network connection for each app that connects to the gateway, and the code needed to support multiple TCP connections is quite a bit more complex than to just broadcast on UDP, increasing development and hardware costs. Then, from the users' point of view, configuration is a bit more complex, as in addition to having to set the port number for the connection, they also need to work out what the IP address of the gateway device. This, then increases support calls to the gateway manufacturer. So, although technically great, in practice there are some drawbacks.
UDP data is generally broadcast or multicast - although unicast UDP is available, it is not (to my knowledge) currently supported in any marine related apps or NMEA Wi-Fi gateways.This means that it just goes in one direction, so the app cannot send data back into the wired NMEA network via the gateway, so no controlling of your autopilot, or using your phone's GPS as a backup to your boat's.
For the gateway, this makes life simple as it just sends out all incoming NMEA data, with no need to establish a connection for each client app. Also, for the app developer and user, broadcast UDP makes things simple as there is no need to ask for an IP address. And, as NMEA devices typically sends data out once a second, is it significant if we lose one boat speed reading, as the next will come in before the missing one is noticed - so long as we ignore NMEA sentences marking events, such as waypoint arrival or other alarms, and other sentences that are generally sent less often, such as routes and waypoints.
So far, we have just looked at connections over a standard, wired network, without the additional complexities of Wi-Fi - and this is where it get interesting! The first thing to understand is that Wi-Fi networks run at variable speeds, with the speed varying with the strength of connectionl, as slower data rates are generally more reliable - so the more bars on your signal strength display, the faster the network speed. And this is done on each connection between the access point (AP) and an individual client, due to some lower level communications. So, if the network signal is weak, the speed may throttle right down to 1Mbps. This is for all connections between the AP and the client device, shared between all apps using wireless data.
This is interesting, but with the short distances on a boat isn't the signal always strong, so why does this matter? With TCP it doesn't, but with broadcast or multicast UDP it definitely does, as the Wi-Fi Access Point isn't getting any feedback from the clients about the signal strength. So, to try and ensure that all listeners to the multicast or broadcast data receive the data, the Wi-Fi standards insist that the slowest possible data rate is used for broadcast and multicast connections.
Another consideration is that sending data over Wi-Fi is much more error-prone than sending data over copper wires. Sending data over a radio link is in itself unreliable, and furthermore there is much more interference, both between the overlapping Wi-Fi channels and also from other wireless transmitters using the same public frequency band, e.g. Bluetooth, Zigbee, and poorly shielded microwave ovens. To cope with this, the Wi-Fi protocol has its own low-level error correction protocol, but this is carried on normal network traffic, and so doesn't work when used with broadcast or multicast connections as there is no connection back to the AP. This is the real killer, as UDP transmission errors rise from about 1% over a wired network to 15% or more over Wi-Fi.
Whilst UDP has the benefits over lower hardware requirements and easier setup, the killer is that a high proportion of broadcast and multicast messages are corrupted when sent over Wi-Fi, and this is generally unacceptably high. In contrast, TCP is wholly reliable over Wi-Fi as it is a unicast protocol, and also has its own error correction. Furthermore, it has the benefit of being a bi-directional protocol. So, whenever there is a choice, TCP should be used in preference to UDP.
Recently we've had a couple of customers send us data files with NMEA0183 sentences that weren't being logged by our data logger, wondering what the problem was. Our logger checks the sentences are in a valid format, and only logs well formed sentences (it doesn't look at the message contents - everything that is valid gets logged).
So what makes a sentence valid? Here are the key points:
Without burrowing down to the level of the electronic signal, NMEA data is basically unidirectional. When setting up a serial port to send or receive NMEA data it should be configures as 1 start bit, 8 data bits, 1 stop bit and no parity. The official data rate of NMEA0183 is 4800bps. A faster data rate of 38400bps is referred to as NMEA0183-HS, and is primarily used by AIS. Some devices may use other speeds, e.g. many non-marine GPS receivers have a default speed of 9600bps. If these settings are wrong, you may get garbage, including characters not allowed by NMEA0183, or you may get nothing.
Of course, if sending NMEA data over a network cable or Wi-Fi, these serial settings don't apply, as the data is sent over the network using TCP or UDP.
Basically it uses the printable ASCII characters (i.e. decimal codes 20 to 127 inclusive). Within this range, the following characters are reserved for specific purposes: $*,!\^~ and <DEL>, plus <CR> and <LF>. This means upper and lower case unaccented characters from the Latin alphabet, digits 0 to 9, and standard punctuation marks.
Each message begins with a $ or ! and ends with a <CR><LF>, and can be up to 82 characters long (that is 79 characters between the first character and the <CR><LF>). After the initial $ or ! there are 5 characters comprising upper case letters or number (or 4 if the sentence begins $P), and then a comma. From then on there are a series of comma separated fields, e.g.: $ESDPT,11.3,,100<CR><LF>. In most instances fields are optional, e.g. in this example the field between 11.3 and 100 is omitted. Also, there is no comma between the last field and the <CR><LF>.
There is an optional checksum between the last field and the terminating <CR><LF> (though a few sentences are now required to have it, to meet backwards compatibility needs the checksum is still effectively optional). The checksum consists of a * and then two hex characters (i.e. 0 - 9 and A-F), for example: $ESDPT,11.3,,100*56<CR><LF>. Whilst this gives another way of detecting corrupted data, if you are generating long sentences it also shortens the available length by 3 characters.
The checksum is calculated by doing a bitwise exclusive or (XOR) of all characters between (but not including) the initial $ or ! and the final <CR><LF>. In hexadecimal representation this is a 2 digit number which is converted to the ASCII characters. The * and two character checksum is then added to the sentence. For example, continuing with the example here, XORing ESDPT,11.3,,100 gives 86 as a decimal or 56 as a hexadecimal, so we add in *56 as the checksum. If you need to code this up, Google will give you code snippets in most languages, and there is a useful checksum calculator here.
So, before looking at the information content of a sentence, quite a lot can be done to check that it is valid, and hasn't been corrupted in transit - which is relatively rare when sending NMEA data over wires, but is all too common sending data over Wi-Fi using UDP (which I may look at in a later post).
Which is best for marine apps? Apple's iPhone and iPad, or Android? There are pros and cons on both sides.
First, it must be said that most boat owners use an iPhone or iPad when off the boat, so their natural tendency is to stick to the same platform when on board. But is it worth changing, with all the hassle of learning how a different device works? There are a greater variety of apps written for Apple devices, and if you want to run a specific app then it is probably available in the iPhone store. The big exception to this is OpenCPN, which is oly available on Android as far as mobile devices go.
A big benefit of Android devices is that they are multi-tasking. On an iPhone or iPad, if you are running your nav app and then want to bring up a different app, the operating system will force the nav app to close down, and it will disconnect the connection to your instruments, so when you bring the app back up, it will have lost a chunk of data. Also, if the app isn't that well written, it may not properly close off the link to the instruments, so your NMEA to Wi-Fi device may be left with an open connection, and when brought up the app may think it is still connected to the instruments. Of course, if the app is well written then the connection issues will be properly handled, but you will still have lost a chunk of data. On an Android device, the app will continue logging data in the background, and the data connection will not be dropped (again, if the app is properly written).
Another advantage of Android devices is that they are cheaper than Apple. Most boats are at best a damp environment, at worst very wet, and very few phones or tablets are designed to be water resistant or waterproof. So sooner or later it is likely that your phone or tablet will die, either from water getting in, or in the longer term from corrosion due to the damp, salty atmosphere. With Android devices being that much cheaper, it is a less painful experience when they fail!
So, in conclusion, the first thing to do is to look at the apps you want to run, and see which platforms they support. This may make the decision for you. Then, if you have the choice, would recommend having an Android tablet for the boat.