DY NavLink, how will your iPad get boat data?
On Friday I got a press release announcing Digital Yacht’s NavLink NMEA2000 to WiFi Server, and while I certainly understand the desire to get boat sensor data of all sorts onto iPads and other tablets, I remain confused about how it will all play out. For instance, how is the NavLink “revolutionary” when the Chetco SeaSmart and DMK boxes purportedly do the same job? And whereas there is no NMEA standard for putting N2K onto Ethernet yet, are all these products doing it differently so they won’t necessarily work with even the few marine apps that already accept data over WiFi? Then there’s the issue of NMEA 2000 certification; though I sure wish the standards organization would get this sorted out, I still think their certification process must especially be honored when a product is all about translating NMEA’s intellectual property. When I wrote about that several of you disagreed, but I understand that Chetco is very close to certification just got its WiFi gateway certified, and I trust Digital Yacht will also work on it. But I don’t see NMEA 2000 certification on the NavLink box and also don’t now what DY means by “Digital Yacht has their own, certified version of NMEA2000, called N2NET, and in the future customers will see more and more products enabled with this interface.” I’m hoping DY will clarify — they just did, and well, see first comment on Panbo — but in the meantime I’ve been testing some other means to the same end…
Actually I was testing the USB NMEA 0183 output of a Raymarine AIS 650 (which, like its Em-Trak B100 sibling‘s, seems a bit flaky) and when it seemed to be stable when read by Coastal Explorer 2011 charting software, I thought I’d try CE’s “Data Server” feature. Well, despite a warning about the need for advanced IT skills — which I don’t have — it worked just fine…
All I had to do was type the Host and Port addresses suggested by CE into iNavX — which seems to support about every external data source available — and the latter started getting GPS and AIS data over the boat’s WiFi network both the iPad and the PC were on…
You can see the data fields coming from the AIS 650 through CE to iNavX on the screen above, taken this morning as we returned from a weekend of testing and cruising. Unfortunately, though, the Coastal Explorer running in the pilothouse was also getting wind, depth, and other data from an Actisense NGT-1 NMEA 2000 gateway, but CE apparently does not bridge N2K data over to 0183 and therefore was not serving it to the iPad. But given that the TCP/IP pipe is established, how hard would be for CE to send over all sorts of info? And given that the Rosepoint CE developers like iPads themselves, might they come up with their own app and/or a complete data solution (if you are also running a PC onboard)?…
Of course developing their own apps and building WiFi right into an MFD that collects virtually all sensor data — NMEA 0183, 2000, radar, sonar, etc. etc. — is the stradegy already taken by Raymarine and Furuno, and it’s got a lot going for it (if you’re willing to update your main hardware). I do wish that the Raymarine c- and e-Series could join an onboard WiFi network like the Furuno TZTouch MFDs can, but once I do the switch above, RayControl works very well…
Ray warns that RayControl may be slow on an original iPad like mine, but I sure didn’t notice it even with radar running. My wife wasn’t impressed by the visibility of the iPad on our flying bridge, and yes I did have it at max brightness, but you can of course take it to a shady spot. And, besides, the most likely scenario, I think, is have a c- or e-Series outside and using the app at your nav station below (or in your berth ;-). I took the screen below to show how the display shrinks a bit when you flip open the keypad but the need to do that will decline when the c- and e-Series gets the onscreen controls that are first coming in the new a-Series. The screen also illustrates a radar overlay problem that’s been discussed on the forum. I had unplugged Gizmo’s heading sensor because it needs calibration (again!) and would have liked the e7 to do overlay with COG instead. But Bill Bishop is reporting that Raymarine plans to put that possibility back into their MFDs (at least some of them).
But I digress. The point of the entry is that there are lots of ways to skin the boat-data-to-iPad cat…and I haven’t even mentioned a couple more I’m not permitted to discuss yet 😉
Just as I finished this I got some answers from Paul Sumpner, CTO at Digital Yacht. It all sounds good to me, though I think DY should have mentioned in their PR that NavLink is also a NMEA 2000 to 0183 gateway:
“I can confirm that NavLink is up for certification. We have applied for a product code and once we have this, we will be running the certification tests on this and the Boatranet Gateway we will be releasing later this summer with Boatranet Service Pack 2.
We have taken a different path to Chetco, in as much as NavLink converts the NMEA2000 PGNs in to standard NMEA0183 messages, giving it maximum compatibility with all existing Nav Software currently on the market. We recognise that this limits the number of PGNs that we can support but for a large number of customers NavLink will provide all of the key navigational data they need.
The proprietary approach that Chetco have taken converts more NMEA2000 PGNs but in so doing produces another manufacturer’s “closed” solution that will be promoted to customers as another format and this further dilutes what the NMEA organisation is trying to do.
We had considered a more complete solution but will wait to see how the market reacts to the NMEA announcements later this year.
N2Net is the name for our NMEA 2000 network. We looked at what the big manufacturers were doing trying to have their own flavour of NMEA2000 and much as it fragments and confuses the market, we thought it might be strategically beneficial for Digital Yacht to establish our own N2Net version of NMEA 2000 from the very beginning, even though it is currently 100% NMEA 2000 with no proprietary PGNs.
Who knows what the future will bring but our thinking was that as we got more and more involved in NMEA2000, that we may want to move quicker than the NMEA committee and adopt our own PGNs to do new things as we come up with interesting ideas. Where I think we will take a different approach to the larger manufacturers is in feeding back these ideas in to the NMEA Committee so that the new PGNs that we develop/prove are then adopted into the NMEA standard.
We certainly will not be creating our own range of connectors or any other activities that make installation and compatibility worse than the standard NMEA2000.”
Ben, you know I think you’re great, but at this point I wonder what will have to happen in the market to convince you of the wrongheadedness of the NMEA’s continuing policy of maintaining that the N2K PGN definitions are trade secrets that deserve IP protection. (We can leave aside physical cabling standards and the low-level CANBus-based stuff.)
This time around we have — as far as I can tell from the information you posted — an innovating company hamstringing a new product by tying it to an ancient, and limited, data format standard for the purposes of maintaining conformance with NMEA norms. Some brief research online reveals that NMEA0183 has no sentences defined for engine data, tank levels, AC or DC electrical systems, or really anything beyond basic navigation and sea and wind conditions.
As a developer interested in doing creative stuff with the information generated by the N2K sensors installed on an increasing number of boats, that limited data set really isn’t interesting. DY appears to know that, which is apparently why they’ve gone ahead and created a “shadow” N2K format they’re calling N2Net, which, by Paul Sumpner’s own admission is exactly the same as N2K!
Do you not agree that’s ridiculous?
Adam is wrong, wrong, wrong. You are -nearly- great. Even your flaws are endearing, like a puppy that; no, like a random brush stroke… no, like a …, er…. Never mind.
But Adam expresses exactly the mindset that mixes creative drive with visions of financial gain and must be vigourously resisted by buyers. The Tower of Babel was funded by consumers.
There are industrial NMEA 2000 to Ethernet interfaces that communicate the data without converting the sentences to NMEA 0183. This approach avoids the necessity of converting each PGN sentence, some of which may be undefined in the 0183 format.
ADFWeb, an Italian company, markets a variety of NMEA 2000 gateways including: NMEA2000 from/to Modbus, NMEA2000 from/to Modbus TCP, NMEA2000 from/to Ethernet, NMEA2000 from/to CANopen, NMEA2000 from/to DeviceNet and NMEA2000 from/to PROFIBUS.
The disadvantages of a general purpose NMEA 2000 to Ethernet gateway are that the interfaces are relatively expensive and the subsequent processing of raw NMEA 2000 data is moderately complicated.
One alternative is to use the Actisense NGT-1 gateway ($170) to convert the NMEA 2000 data to RS 232 compatible serial data that can then be converted to Ethernet packets by a Serial to Ethernet Interface. An example is the Chiyu Technology Company (Taiwan) model BF-430 RS-232 Serial to Ethernet Converter ($69).
The NGT-1 can handle any incoming instrument data on a NMEA 2000 network. A software interface to the NGT-1 does, however, need be able to transmit the proper sentences which control instrument functions including whether or not the NGT-1 converts specific instrument data.
Many mariners would probably like to have on-board Internet access via WiFi or some other transceiver technology in addition to having access to a local, on-board network.
NMEA 2000 instrument data can be communicated to the Ethernet network via a gateway either by a direct Ethernet local area network connection or by WiFi.
I would like to ask “How will our boat get iPad data” ?
A 1-way only path of data from boat to smartphone/tablet, is very limiting.
I hope it’s not forgotten that smartphones and tablets are wonderful platforms to run basic non-graphical software that can process boat information and return it back to our boat (by emulating sensors?) so that data (and alarms, think AIS) can get to our sunlight readable, water proof, fixed mount, and continuously powered displays.
What a great way it could be to send a 2yr old smartphone into retirement. Imagine cancelling the cell data plan (use wi-fi to load software), mount it down below, plug into battery, load some software, and let it talk wi-fi back and forth to the boat. Then everyone once in a while download some new software for $10 from the marketplace that can help you find fishing spots, have better AIS alarms, help racing sailors find the right groove, and more. And if it breaks, replace it with the next smart phone that retires.
Regarding the Raymarine AIS 650, I just installed one for use with my relatively new C-80 display, and it has worked well. However, I have noticed that I receive “AIS failure” messages pretty regularly. When I check the diagnostic page on the C-80, it shows that the messages are still going thru.
I was going to re-do all of my connections on the theory that it is an intermittant connection failure, but with this info, I will hold off for a while and see what Ben can turn up.
I would like to point out that SeaSmart.net Protocol is in no way “closed” or “propriety”. The specification is openly published (http://www.seasmart.net/pdf/SeaSmart_HTTP_Protocol_RevG_043012.pdf) and there is no charge for anyone who wishes to use it. The spec evolves as more developers adopt it into their apps. It the past year it has been available, many enhancements have been added to support developers requests for AIS, Autopilots, and bi-directional data flow.
To date, four app developers have integrated SeaSmart.net protocol to add Engine and Vessel data not found in the older NMEA 0183. Most importantly is new support for dual engines and fluid tanks simply not possible with NMEA 0183.
Even when only considering GPS/NAV devices, NMEA 0183 falls apart when addressing multiple data sources.
While we can applaud established app developers like iNavX and NMEA REMOTE for supporting SeaSmart.net – the real value comes into view when new apps like the one from Mill Port Media (www.millportmedia.com) come on-line that start to take it to another level. These are not competing apps but complimenting each other.
Not to mention that SeaSmart.net has a full embedded WEB Server for HTML and JAVA support. No one has ever said HTML was a “propriety” or “closed” system.
SeaSmart.net protocol has encouraged many new third party application over the past year and the list is growing.
It would be even be great if other products like NavLink supported the SeaSamart.net Protocol
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmat.net
The SeaSmart.net Ethernet adapter (http://www.seasmart.net/marine-wireless-networking-ethernet.html) does just that – converts NMEA 2000 directly to Ethernet. It is based on a licensed NGT engine and has recently been NMEA 2000 Certified.
By connecting SeaSmart Ethernet adapter to a Router with WiFi access point – you can have both local wireless access (iPad/iPhone) and remote Internet all at the same time.
The problem has always been (and pointed out in this blog) that while it is easy to convert NMEA 2000 to Ethernet packets, what happens on the other end. You still need something that can read/understand it. The NGT converts NMEA 2000 to “propriety” binary data. SeaSmart.net takes that binary data and translates to a more “open” readable format that can used by follow-on applications. The Spec is fully published and does not restrict which PGNs are implemented. To date, a half a dozen applications are using the “open” SeaSmart.net protocol to add Engine and Vessel instrumentation not possible with NMEA 0183 – and the list is growing.
One thing that is missed in these discussions is that NMEA 2000 requires that any “certified” device be able to publish/post a list of supported PGNs so any protocol implementation needs to be able to create/delete PGN lists to match. SeaSmat.net handles this.
Yes – anyone can purchase a serial NGT and find a separate serial to Ethernet adapter and wire them together but there are issues. The NGT does not supply Power so the Ethernet adapter has to be separately powered. SeaSmart.net is the only NMEA 2000 Certified device to draw power directly from the NMEA 2000 bus and isolates any potential ground loops which is critical in marine environments. Also need to consider enclosures, cable, and connectors in the harsh marine environment as well. Maybe you save a few dollars by stringing together separate devices but in the end, more connections means increased chance of failure.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmat.net
Obviously I made a mistake when I first wrote that Chetco was “very close to certification” and I’ve corrected that above. In fact, if you look on the “New NMEA 2000 Products” page at NMEA.org, you’ll see that Chetco got three certifications, which I think are all three products shown at the top of http://seasmart.net/ Note that besides the N2K-to-WiFi gateway discussed previously on Panbo, they also have a gateway that can take 8 analog engine outputs to 0183, 2000, and Ethernet/WiFi. Congratulations, Chetco!
rxc, the only AIS 650 problem I’m seeing is USB output and may simply be a USB driver issue. NMEA2000 output is fine and I imagine NMEA 0183 output is also fine. I have not seen any “AIS failure” messages and don’t know what that’s about.
As a developer of navigation software I certainly hope whoever comes next in a wireless N2K gateway product line – will use one of the existing protocols (or a trivial variation thereof).
Note that PolarView/PolarCOM currently support both Actisense and SeaSmart data (and that was fun enough to develop, but two is enough 🙂 )
Actisense generally provides N2K data as-is, and Chetco product encapsulates it into NMEA0183-like envelope but still forwards it unchanged. At this point, in my humble opinion, there is no need to breed additional encapsulation formats.
Devices which act as wireless routers are silly, IMO. Chartplotters, radars and sounders already communicate via ethernet… use it!
Wireless access should be provided by a wireless access point for the multiple devices on a boat which are now using ethernet, not a separate access point for each device.
NMEA did everyone a favor by being so late (still not here!) to the party coming out with a (high-priced of course) standard for NMEA2000 over IP before devices started to appear… we now have a window to develop an open, vendor-independent implementation. An ideal way would be for an RFC to be developed. While existing implementations are great, the big picture has HTTP as well as binary TCP and UDP protocols.
Most importantly, the standard has to account for the future which is bi-directional. Your iPad needs to be able to send a message to the bus to turn lights on, adjust settings, and everything else… not just read data. There is a lot of fear about opening the protocol to software writes, but it’s inevitable and not nearly as scary as NMEA and some folks would like you to believe.
Patrick, not every boater wants to mess with an onboard WiFi network (though I think they’ll become very common on boats about Gizmo size and up). A direct WiFi connection from, say, RayControl on an iPad to a Raymarine c95 immediately gets the user a full second station, plus the touchscreen control the c-Series doesn’t. Some boaters are finding that to be very cool and very simple.
Moreover, the Furuno TZTouch is using device WiFi not only for that feature, but also as a firewall to protect their navigation Ethernet system. For instance, the TZTs can display weather GRIB files downloaded from MaxSea but they come in via WiFi not Ethernet. Seems like a smart architecture.
By the way the already existing NMEA to Ethernet gateways — like Maretron’s N2KView and Seasmart.net — are already bidirectional, as are the 0183 to Ethernet gateways (though not all developers use the inbound option).
Finally, what does “vendor independent” actually mean? For instance, isn’t NMEA 2000 vendor independent because no one vendor controls it and any vendor can use it? And how about Seamart.net? If Joe is serious that gateway competitors (not just developers) are free to use it but Chetco still owns it, what’s that?
There is plenty of precedent for single vendors developing open standards, by the way. Like Bosch creating CANbus and then turning it over to a standards organization. By open I mean open for use by anyone, not necessarily free.
Ben,
I completely agree that “not every boater weants to mess with an onboard WiFi network” – and I guarantee that most boaters do not want *3* of them… so why include it in every device like a MFD, a NMEA2000 converter, etc.? That was my only point.
Fusion did it right with an ethernet port on the IP700, even though they know nobody is going to be chaining their laptop to it with an ethernet cable to change songs. An ethernet port is very inexpensive to add hardware wise so it costs very little money to those people who don’t want it, and chances are if you want to control your Fusion radio over WiFi, you’ll also be the same type of person who enjoys seeing/controlling their MFD over WiFi too. All that’s missing is an inexpensive 12v WiFi router designed for the marine environment. This could easily include NMEA2000 as a freebie, once the standard is developed 🙂
Vendor independent means that ideally everything can work together. We basically have that with NMEA2000 – so it should apply to NMEA2000 over IP as well.
Making this work for everyone takes a lot more than a single manufacturer developing exactly what they need and then going “okay, anyone can use this!” That’s like chaining your lawnmower to your porch and then saying anyone can borrow it, when you can’t get it to your lawn 🙂 Manufacturers have to work together to develop a forward-thinking standard that has the pieces that other manufacturers need, and will need in the foreseeable future. IE, a non-HTTP protocol. Remember when every manufacturer had their own physical NMEA2000 connector, even though the messages were standardized? That’s what we want to avoid.
It’s not as simple as just throwing raw NMEA2000 on a port and allowing anyone to access it, nor is it as simple as encoding it in 0183 and sharing that, nor picking XML, JSON or anything else and calling it a standard. When you go IP, things need to be considered like authentication – it’s easy with HTTP as you can ASSUME that HTTP basic auth would be acceptable, but what about with the TCP protocol? What about bus discovery, ie should there be support for multiple busses on one ethernet network? (Why not?) What about security – it’s inevitable that at some point, someone will want to disallow some PGNs from being accepted via IP… perhaps you want to disable autopilot course changes from the network?
Ideally, you should be able to hit the app store of your favorite device and download whatever app you need to do the task, and not worry about if you need SeaSmart.net’s protocol, Chetco’s protocol, etc. The problem for these companies that make money on hardware and software is if it’s open, their hardware is no longer needed. Navico, Raymarine, Furuno, etc. could easily include N2Kethernet in the MFD which already has those interfaces… it’s not much code. (Obviously there are advantages to a dedicated converter for some people)
The interconnected boat is better for the end user. With basic standards, you can use current WiFi gear to access your boat remotely. Instead of a fancy specific “anchor watch” tool like you have for Gizmo, with NMEA2000 over ethernet and your cellular router, that capability would be yours without a specific hardware device. You could also easily log in and check the fuel, turn off the lights you forgot to turn off, etc.
Panbo is a great place to discuss things like this as it’s gotten to the point where manufacturers, hobbyists and connected boat owners are all in the dialog… we’re at a great point to move forward from here with Panbo as the hub 🙂
We’re not so far apart, Patrick. But I think WiFi radios are getting pretty inexpensive too and if you do have a router on the boat it should be a one-time thing to tell, say, a Raymarine MFD to join that network (if Raymarine had that feature). I used to always prefer Ethernet cable over WiFi for linking network devices in my house and on the boat, but experience is changing that opinion.
Also, what do you think of Furuno’s architecture, the idea of keeping the Ethernet offline and exclusive to critical navigation devices?
Finally, there is a discussion an “open source” NMEA 2000 like project on the Forum, though it’s gone somewhat dormant:
https://panbo.com/forum/2010/09/nmea-open-source-project.html
Nope, I think we’re usually on the same page in fact… just a bit hard to explain in text 🙂
Devices definitely need to be able to join a network if they’re going to include a wireless functionality, or allow all the same functionality over their physical ethernet port.
Furuno is a bit more professional gear, it’s an interesting distinction but not one I think is necessary for recreational boats/yachts. Your core navigation is still on a physical NMEA2000 bus between devices. You certainly wouldn’t want this on a public vessel over the same network available to the public’s devices! But for most of us, it’s not relevant.
I’ve played with a number of the projects out there, there is enough protocol data on NMEA2000 that if a standardized conversion method were developed, the app stores could fill with cool apps 🙂 While the cost of the standard itself is prohibitive, it’s to the point where you can legally get the information elsewhere.
In addition, great things would come – Navionics iOS app for example could easily accept GPS data over the network, you could click a spot and create a waypoint and send it to any manufacturer’s MFD, etc. It’s not worth their time to modify their app to support 5 different manufacturer-specific formats, if there was a standard… I think it definitely would be.
We’re at a good point in time for boat electronics, and it’s only going to get more interesting!
Hi Ben,
Two comments.
Using a NMEA 2000 to Ethernet gateway and a wired connection to a LAN is the best approach if one already has a combination of NMEA 2000 and Ethernet networks. Compared with WiFI, the wired approach is technologically simpler, cheaper, faster and more reliable.
Regarding open source, we have freely available a Visual Basic program for the acquisition, processing and display of NMEA 2000 data. A serious catch is that the code depends on the use of multiple commercial modules. Some of these are already licensed for distribution. Others would require permission and/or royalty payments to the owners of the code.
If anyone has an interest in the Visual Basic part of the program, more information and some screen shots are available at: http://www.RERThird.dyndns.info
“… If Joe is serious that gateway competitors (not just developers) are free to use it but Chetco still owns it, what’s that? …”
I suppose all Hardware Vendors “own” whatever data they provide. My point is, we created a usable format and openly publish the specification for everyone to use. Other vendors with Ethernet and NMEA 2000 do not so a customer must only purchase a specific app from the same vendor. Since SeaSmart.net is public and unlicensed – other App developers can use it and create variations that best suit the market. Recent releases by iNavX, NMEA Remote, Polar Navy, and Mill Port Media are not controlled by Checto Digital and as a result are free to address whatever customer base they choose.
Therefor SeaSmart.net is an “open” and not “closed” architecture where multiple vendors can participate and access the data just like what has happened with NMEA 0183. With UDP Broadcast, a single data source (GPS/Weather/AIS/Engine) can be easily shared among multiple PC/iPad apps from different vendors.
As Ben pointed out, SeaSmart.net is bi-directional and customers can currently use iPad/iPhones to turn on/off devices (lights, bilges, pumps) using the HTML interface (I can even do this over an internet connection from home). Some of the above mentioned Apps also use the bi-directional feature to enable PGN lists and control Autopilots.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmat.net
RXC, Raymarine has just released a 5.16 software upgrade for the C80 and other C-Series Classics. See the “Downloads & Updates” tab here:
http://www.raymarine.com/ProductDetail.aspx?SITE=1&SECTION=2&PAGE=1921&PRODUCT=1672
The note I got doesn’t say anything about the issue of decoding the standard NMEA 2000 Class B Static Data PGN but does say that this update “increases the MFD’s target time-out period to prevent it from unnecessarily dropping and reacquiring AIS targets (and generating nuisance alarms.) It also improves the TCPA calculations for stationary and underway targets.”
There’s also updated the software for A-Series (v1.23), C-Widescreen (v2.35), E-Classic (v5.69), E-Widescreen (v2.65) and G-Series (v4.65).
Ben,
Thanks for the info. I will upload it and try it. I have been watching for an AIS software update as well. It would really be nice if the AIS-650 USB output worked better, and if there was some way ‘to modify the dynamic info, like ship destination. I have a few friends who have been follow us on Marine traffic, and they would like to see our next destination.
I found out that the software updates discussed in the comment above do not fix the Class B Static Data over NMEA 2000 problem, but it’s high on Ray’s wish list and “hopefully it will make it into the next round”.
I wonder if it is now time to start considering Arduino as a DIY project to build a NMEA to WiFi Gateway. I think it will eventually cost much less than the devices mentioned above.