Mobile device navigation

[Graham W]

UK-based Quark-Elec is selling what looks like the old 8" Sailproof (before it was updated with a faster chip) under its own name https://www.quark-elec.com/product/ad08-rugged-marine-waterproof-tablet-8-inch-android/.  It's more expensive than the old Sailproof version but considerably cheaper than the Tripltek, which is made in the USA.

It appears that all Sailproof models are made by Chinese company Geshem.  In theory and if you are feeling brave, you could buy one on Alibaba for about half the UK price https://www.alibaba.com/product-detail/Geshem-10-Inch-Android-10-0_1600281518491.html.  There are various options on things like screen brightness - if you're going to take the plunge, make doubly sure that you have the right specification.

[Graham W]

This US-oriented post is a comprehensive review of marine apps for mobile devices, including those that can use NMEA data in both directions https://panbo.com/mobile-app-navigation-app-roundup/.  No mention of the Android version of iNavx's fatal lack of UK charts, and no mention at all of one of my favourite apps, Memory-Map for All.

[Graham W]

I've finally managed to get full integration between mobile devices and NMEA-connected instruments and sensors.  Full integration in the sense that the tablet/phone can receive all sorts of variables (wind, depth, position, speed over ground etc) but can also broadcast waypoint and route data to instrument displays in the other direction, the waypoint chosen simply by tapping a point on an electronic chart.  All without the benefit of a GPS/fishfinder from one of the oligopolists inhabiting their absurdly expensive technical silos.

I've managed to achieve this on iNavX, which as Andy has already noted, only has UK charts on Apple's iOS, not Android.  So with iNavX I've only succeeded on a landlubberly iPad and iPhone, not on my waterproof Android Sailproof.  I think that I've also managed it on an Android app called i-Boating on my Sailproof. The problem with i-Boating is that it's quite clunky and it's sometimes difficult to tell what's going on.  I can also get NMEA data into my Sailproof using Android versions of Navionics and Memory-Map but in one direction (incoming) only.

There seem to be two important criteria if bidirectional NMEA functionality is to be achieved on a mobile app:
1. The app must have the functionality to control an autopilot, the incidental benefit of which (to me) is that it broadcasts NMEA waypoint data in the opposite direction to incoming wind/speed/depth data.  I don't have an autopilot but can make use of that data.
2. It has to be connected over WiFi on the TCP rather than the UDP protocol.  This means that only one tablet or mobile can be connected to the system at any one time (on my basic multiplexer anyway).  UDP allows several simultaneous connections.  I suppose this makes sense - you wouldn't want several people trying to control an autopilot at the same time.  As an irrelevant aside, you might not want to control an autopilot from a tablet at all - apparently this raises  safety concerns.

In the absence of iNavX for UK waters, the hunt is now on for other Android apps that fulfil these bidirectional criteria.  It looks like OpenCPN and qtVlm may both be candidates.  However, unlike Navionics or iNavX, they are both fiendishly complicated with a very steep learning curve.  The journey continues....

This is an interesting (to me) use of my time during the long winter evenings.  However I suspect that during the sailing season, sailing on my own, I am more likely to use something simple like Navionics, with basic NMEA depth and GPS data flowing one way only onto my Sailproof.  Because Navionics is unidirectional, I can connect my Sailproof on UDP, which gives me the ability if needed to also connect my iPhone to the system and maybe simultaneously run a different NMEA app on that.

This will be at least until iNavX sort themselves and produce UK charts for Android as well as for iOS.  As Andy has noted above, iNavX unfortunately seem to have been knocked sideways by various factors beyond their control, including devious behaviour by competitor Garmin/Navionics.

[AndyB]

Hi,
I just wanted to modify  some statements below if that is okay. Please do not take offence it is just to help others when they try what you have achieved. I do hope I have not confused it more

Firstly you are correct in that the app needs to provide all or some of the NMEA 0183 sentences or 2000 equivalent ( or indeed signal K)  for the  autopilot to work ( sentences RMB,RMC,APB,XTE and BWC) the hardest for me to build being XTE - cross track error.  These then need to be sent to the autopilot in some way.  I have also been looking at i-boating and it indeed sends these sentences and it works on Android so seems a good fit.  However the circles ( orange, green and red)  seem to clutter up the display - I am going to ask if there is a way or removing these but the maps themselves look really good for the Solent area.

With regard to networking I wanted to just correct a few areas.

Background

The User Datagram Protocol ( UDP) is primarily used for fast connectionless communications (fire and forget) . It used in video transmission such as streaming services. Although the original I believe was for DNS lookup.  It is fast as there is no checking. The messages are not guaranteed  to arrive in sequence or at all. It is broadcast on xxx.xxx.xxx.255 on a predetermined port number.  Any receiver ( or client) can open the port and read the data.   

If you want a reliable transmission then the Transmission Control Protocol ( TCP) should be used. The server establishes a 'hanging socket' which comprises an  ip address and port number. The client requests a connection to the hanging socket which then provides another port number where socket 2-way communication can occur.  This is difficult to programme as each connection needs to be handled synchronously and in the modern world is achieved using parallel computing and shared memory.  This is why TCP connections are restricted to one only. However sequence of transmission is guaranteed and delivery is guaranteed.

Port numbers are used to establish types of connections between computers on a common ethernet based network. For instance web pages use port 80 ( and 8080 for secure pages). Any program listening or providing messages on that port needs to comply with message construct for that port. There are fixed pre-defined purposes for port numbers but also a range of number that are not fixed - I use 8829. You usually find a free one by scanning the ports on the computers you are using.

To come back nearer to the real world....

The problem here is to find a bridge ( yet another computer term - your internet router has a wifi bridge) that will take the point to point NMEA0183 messages based on serial comms ( 4800 baud) to a wifi/ethernet network. This is usually accomplished via a multiplexor of which some allow 2 way communication.  The serial connections usually have an in and out connection which some devices can cope with. For example a wind sensor would have an 'out' port connection and the autopilot an 'in' connection. The multiplexor will be configured to receive NMEA messages from the wifi network and send those messages out on a pre-determined 'out' connection. It can also route messages from an 'in' port to an 'out' port. Not normally an issue as these are hardwired. I use the later to send wind information to the autopilot.

The Wi-Fi network can either be UDP or TCP. I prefer TCP as the wind displays seem more consistent than with UDP however I may be imagining things here.  So you could broadcast on one UDP port and receive on another UDP port. However most apps don't seem to want to do this ( prefer a single port) and those with auto pilot functionality prefer TCP as the sequence of NMEA messages are important.

I have moved completely over to TCP and programmed the raspberry pi to handle multiple TCP connections. It would appear that Graham's multiplexor can send messages on both TCP and UDP and receive on TCP. So I would set that up to have one TCP connection to the app that is going to provide the autopilot data and the other apps ( such as Navionics) which only receive to a UDP connection.

The NMEA 2000 network is not point to point. That means many messages from many sensors, chart plotters etc are flying around it.  There could as a result be a clash of messages ( 2 devices sending the same message such as GPS data) The NMEA 2000 message has a source id that allows the receiver to decide which takes priority. So the GPS unit rather than the phone GPS( coming through the wifi bridge)  would be used unless the GPS unit stops sending. Most chart plotters have this priority functionality which is setup by the installer.

In the world of Android/IOS networks it is the individual apps that provide the messages. So I would see a clash if say the Android tablet provides a GPS signal along with the phone and you have apps that transmit both over the network. In this case you would need to decide which app takes priority and turn off the other. I do this with Navionics on the Sailproof Android device. I turn off the Sailproof  GPS ( which saves a lot of power) and use the more accurate GPS unit which send the position over the multiplexor to the Wi-Fi network and then to Navionics.


So to summarise:
UDP comms is connectionless. You could use 2 ports to provide 2-way communication but it would be very difficult to synchronise the messages and why build it when there is one waiting to be used - TCP.

TCP comms is reliable and can perform 2-way comms. It is hard to programme.  Most simple multiplexors constrain the usage to one TCP connection.

Part of the chartplotter installation is to determine the priority of messages should the same one come from different devices.

When using a tablet/phone/pc based chart plotter when setting up the software priority of message source has to be determined by the installer.

It is interesting to note that most installations of multiplexors assume the only interesting bit of information you get back from the wifi network is autopilot information but I suspect a lot will use it as a means to get back GPS data to obtain say true wind from a wind sensor....

Please let me know if this type of message is inappropriate. I do not want to offend people.

Best regards
Andy B

[The Lazy Sheet]

All this talk of TCP etc leaves me feeling quite queasy. I can just manage to switch on my Sailproof tablet so, sadly, will not have an integrated NASA and Sailproof setup as discussed (I think) by Andy and Graham. But it is interesting to hear what is possible.

On a more prosaic level, Sailproof are offering 20% off tablets atm, so perhaps worth a look for anyone in the market for an Android Nav tablet. I've been very pleased with my SP10, despite the battery not lasting a day - perhaps I can tweak the settings to extend the power.

[AndyB]

I do apologise for getting all technical.

When you buy sensors and a commercial chart plotter and want them all joined together you generally also purchase an installation service. This is why they are so expensive....

The same can be said if you purchase sensors and join them up to to chart plotters based on tablets/ phones etc.

For years on my previous boat I had a depth sounder with its own display ( NASA) and a mobile phone with Navionics and used the phone's GPS and it all worked just fine. Then I purchased a Bluetooth wind instrument which connected to my phone and flipped between the map and the wind instruments. I often wished I stayed that way.

Then I got the Baycruiser 26 and it came with all these NMEA based sensors and to integrate them all is complicated and you need some knowledge to do it. There must be an installation service out there for those that need it.

But please stay with a tablet , Navionics and a separate depth sounder and use the tablet's GPS. It is all so much simpler.

You can extend the battery life by turning the display intensity down. I find at 75% it lasts more than a day and you can still see it in the sun. Screen intensity is the largest consumer closely followed by the GPS sensors.

[Graham W]

A revised model of the Sailproof 10" Android tablet is coming out next month https://sailproof.shop/product/sp10x-high-end-10-inch-android-rugged-tablet/.

The main improvements are a faster and more capable CPU (including a barometric pressure sensor), a screen that can be read with polarised sunglasses and a waterproof charge socket and lead.  No change to battery capacity or to screen resolution or brightness, which are a bit on the low side compared to some competitors but still perfectly good enough for our sun-drenched sailing purposes.

[Graham W]

I've recently come back from sailing off Barra in the Outer Hebrides.  Often not much wind and when there was some, it was not necessarily from a convenient direction.  The eProp outboard had much more use than I had expected and acquitted itself well, without too much range anxiety. Photo of some typical "sailing" below.

My 10" Sailproof tablet received plenty of use in unexpectedly bright sunshine.  Some observations:
1.  The big screen at full brightness (1000 nits) uses a lot of charge.  Unless you turn the screen off when you don't need it (on longer hazard-free tacks), you may only get a few hours out of it before it needs recharging.  With the screen switched off, the navigation app will continue to work in the background and uses much less charge.  A spare battery for the day's return leg  is a very good idea and they don't cost a lot.
2.  If you do turn the screen on and off to save the battery, it's a good idea to turn off the screen password so that on re-opening you can go straight to whatever navigation app is running in the background
3.  There were no issues with screen visibility or tablet robustness
4.  On an open boat like the BR20, the screen is likely to get splashed with salt water, particularly if you have the sea squirting up through the centreboard slot.  This can affect visibility as the salt dries out, so a spray bottle of tap water and a dry cloth are useful to have at hand.  This should be much less of an issue on lidded boats.
5.  I had thought that it was important for the tablet screen to be able to swivel (mounted near the aft end of the centreboard capping) when tacking but this didn't seem to be an issue.  As long as I was on the helm and not using the tiller extension, the screen was visible from any direction.
6.  I spent a lot of time and effort last winter making sure that the Sailproof could connect wirelessly to NMEA data from the rest of the system (depth, wind, waypoints).  In the end, I only looked at NMEA depth and SoG/CoG data on the app and relied on the Tacktick displays for the rest of the information.
7.  I used Navionics for route setting and tracking and was perfectly happy with it.  It repeated depth information and used wireless NMEA data from a separate GPS antenna to calculate position and speed information.  The idea was to save battery by not using the tablet's internal GPS but I'm not sure how much difference this made
8.  I needed to use Memory Map to display very large scale Antares chartlets to help get into some of the trickier anchorages under motor, which I would never have attempted normally.  In some cases there were only a few metres to spare either side (see screen shot below).  On occasions I would approach shallows on the chartlet that demanded a dog-leg change of course.  It was only after I was right on it that I could see why it was necessary to skirt around the nearly invisible hazard.
9.  I found the Savvy Navvy app much too slow for real time use and prone to doing unexpected jumps to unwanted screens. 
10.  On one day as I passed some vicious-looking rocks I noticed that my GPS position on Navionics was out by tens of metres.  I now realise that this may have been due to disruption caused by the recent solar flares.  Mostly it was very accurate, I think probably helped by the ability to use GPS signals from the Galileo network of satellites.

Overall, I'm happy with the Sailproof and the apps that it runs.  Compared to my previous Garmin GPS/fishfinder it works as well without the extortionate cost, unreliable wire connectivity issues and being forced to only using the manufacturer's software, which costs a small fortune to update.  It would be nice to have Android versions of the iNavX and PredictCurrent apps available but I can always use these (if I was still subscribed, which I'm not) on my iPhone.

The brand new Apple iPad Pro 11" is more of a competitor to the Sailproof as its screen now also has 1000+ nits of brightness.  However:
* It's much more expensive (£1200+)
* It's not waterproof and less robust and would need an extra strong case when used on board
* It's difficult to work out how its battery life compares in real world conditions.  The iPad's battery is 25% smaller than the one in the Sailproof but Apple's electronics may be more efficient.  Unlike the Sailproof, the iPad's battery is not swappable.

[frwright]

I use a Samsung phone (S21 FE) with the Navionics Android Boating app in the US.  I have no depth sounder, but rely heavily on the Sonar Chart feature in my otherwise poorly surveyed sailing area - western Albemarle Sound.  The algorithms Navionics uses to correct all the depth sounder data from others appear to be quite accurate, matching well my boat hook over the side and centerboard touching depth soundings (almost all is soft mud, sand, or sunken cypress trees).  I am quite appreciative of the depth sounder data - it unfortunately justifies the newly doubled cost of the Navionics subscription.

The Boating App does a very nice job of generating the route, and tracking actual position and progress.  I simply use the phone display in my hand.  The phone case has sufficient antislip to stay in place beside me on the cockpit seat cushion even at large angles of heel.

Just completed my first overnight cruise on Sweet P (Stuart/ODay Mariner 19ft), and I too found the Boating App really takes its toll on the phone battery.  After 8 hrs of sailing, I was down to 15% after starting at 100%.  Looks like I'm going to have to install a 100AH 12V battery and associated system sooner rather than later to keep the phone and handheld VHF charged.  Down the line can add running lights and a fan, as well as a backup slow recharge for the Epropulsion Spirit.  But I kind of enjoyed not having a battery.

Fred W
Yeopim Creek, Albemarle Sound, North Carolina, USA

[Llafurio]

Fred,
You could build yourself a little swiveling stand, and affix your phone with Velcro. Ideally, you also get yourself a waterproof mobile phone, IP 68.