Here follows a comparison of our device against others on the market. To best fit the page, we have split this up into general information; wired interfaces; Wi-Fi; and networking. In each section we have also given some notes on the significance of each attribute. All information was taken from the manufacturer's web sites on 26 May 2017.
Pricing is inclusive of UK VAT (at 20%) and exclusive of shipping (except for vYacht - they are too small to be subject to VAT). Where necessary, prices have been converted to GBP. Sales to countries outside of the EU will not have to pay VAT, but may have other sales taxes.
Thought needs to be given to configuring the device. If it can't be configured, will it be flexible enough to meet your needs? If it has a configuration program, do you have the right computer or phone to run it? Or if it needs scripts, are you up to writing and uploading them, or will you need to call out an engineer?
Here are listed the wired interfaces of the device. For the NMEA ports, we have given the data rates, or V if they are user configurable and cover at least 4800 (standard NMEA) and 38400 bps (AIS). Note that for Digital Yacht they do two models, one for each data rate. We also say if the ports are opto-isolated - this avoid many problems from interference, ground loops and other things, so is well worth looking out for. We also list other interfaces the device may have, with those that need to be specified when ordering given in italics.
Finally, we say whether the device can act as a multiplexer, combining the multiple inputs into an output through the output port(s). Note that the DMK device does not output any NMEA data it receives over Wi-Fi, and the NKE device only supports a subset of NMEA sentences. If you need a multiplexer, then Brookhouse and ShipModul are your best bet for features in this area.
Wi-Fi is often poor in marinas, so anything that can help is an advantage - though out at sea it is less of a problem. As we go from 802.11b through g to n we get higher data rates, greater range and greater resistance to interference. Also, the ability to switch to a less congested channel is useful.
The SSID is the name of your Wi-Fi network, and it also has a WEP or WPA password for security. If there is no password, then anyone can log in to the device and send and receive NMEA data - possibly accidentally if they have the same device but log in to yours and not theirs. Basic network security says you should set your own password, and the SSID should either be settable or at least unique.
If there is no other Wi-Fi on the boat, the device will need to work as an Access Point (AP), i.e. as the master device on the network; this means that when you want to switch your phone between NMEA data and a Wi-Fi connection to the internet you will need to change Wi-Fi networks. If you have a router on board that connects to the internet, and you connect the device to it as a client, then users can connect to the instruments and to the internet over the one network. The vYacht device acts as a router in its own right. The DMK device can also work in ad hoc (or peer to peer) mode to connect to a single phone or tablet.
Each device in a network needs an IP address, which must be within the range used by the network and unique within it. If the device is in AP mode, then if it has a DHCP Server it will allocate IP addresses to all phones, tablets and PCs that connect to it, otherwise this must be set up manually for each one. If the device is set up as a client to a router then you may want the device to have a fixed IP address, or you may want to have it allocated dynamically by the DHCP server in the router. If the IP address in the device is fixed, then to connect as a client to a router you may have to change the IP addresses in the router and the rest of the network.
Here we look at the data connection between the app on the phone or tablet and the device. This can be done using TCP or UDP. TCP allows two way communication, so the app can send data back to the instruments, e.g. a new route or autopilot commands; it also keeps retrying until the data gets through. But it is more complex to implement and requires more processor power, so most devices limit the number of simultaneous connections - we have noted where this is just 1. Also, if the phone running the app goes out of range, or the app is not closed properly, the device may not free up the connection and so require a reboot - our device has a timeout to guard against this, but it isn't clear how many other devices do.
With UDP, data flows in just one direction, from the device to the app. Also, it does not resend any data that doesn't get through, and there is some data loss - not an issue for most data that is resent every second or so, but it may be for events messages such as arriving at a waypoint or an alarm. There are two flavours: broadcast sends data out to all devices, and multicast where it is only sent to those apps that have requested it.
It is useful to have both TCP and UDP operating at the same time. This means you can easily run multiple apps, some of which may expect UDP and others TCP, without having to reconfigure the device, whether that is just one person using an app at a time, or the crew wanting to use different apps simultaneoulsly.
A connection is made using a specific port number, which must be the same on the device and in the app. Being able to change the port number is useful as some apps have a fixed port number, so if it doesn't match the one in the device they cannot connect.
The key thing to note in this section is the need for flexibility - some apps insist on TCP whilst others demand UDP; and some are fixed to a single port number. So if you can't change these settings, you may find you can't use the app you want.