Open N2K to WiFi, Chetco SeaSmart & DMK Yacht Instruments
It took me less than an hour to cable a sample Chetco SeaSmart E-Net to Gizmo’s NMEA 2000 network and WiFi router and use the boat’s PC to scan for its IP address, which then yielded screens like the “Weather Info” browser page above on both my iPad and Android Incredible phone. Cool! And if I was actually proficient at the sort of IT stuff represented in that SeaSmart “Network Setup” screen, it probably would have been quicker. Admittedly there are some issues with that data — Gizmo was not pitched 30 degrees, for instance! — and I’ve got a lot more testing to do, but I am excited about the growing number of devices designed to gateway NMEA 2000 (and other boat sensor data) out to Ethernet and WiFi in forms that can be easily displayed, or, better yet, easily used by any software developer…
I wrote about Chetco Digital’s various SeaSmart devices in February, and was pleased to meet the principals Steve James and Joe Burke in Fort Lauderdale. I’ve also mentioned how Digital Yacht’s BOATraNET is getting N2K compatability, as well as specs published for developers about how the PGN data is encapsulated (like Chetco offers). And of course Maretron was really first up with its IPG100, also covered here last February — and now it’s gone on to solve off-boat monitoring issues like fixed IP addresses with its new Maretron Cloud Service. But Maretron’s gateway serves data exclusively to its own PC and mobile software, at least so far, and there are boaters out there dreaming about what an open apps world with access to multiple boat sensors could be like…
Those folks will be excited to hear about a brand new company, DMK Yacht Instruments, which has developed a WiFi gateway purportedly able to broadcast NMEA 0183 and Raymarine SeaTalk sensor messages as well as N2K PGNs. The box is available on Amazon for $399
I am very excited to be working with Chetco Digital Instruments to integrate N2K data into iNavX and MacENC via the SeaSmart Marine network adapters.
I believe that wireless connectivity is such an important part of marine electronics moving forward. I’m already using a Chetco box for development. It’s important to point out that they’ve continued developing the capabilities of their unit since it was first brought to my attention on Panbo in the beginning of the year. They’ve added a lot of missing pieces.
It’s nice to now see DMK adding their own product in this category. So far the specs show that it has UDP support. I’d like to see a lot more technical information. I’ll also need to get my grubby little hands on the thing to hit it with a lot of different platforms to see how it performs in a real live network among different devices.
I have used and installed several of the DMK boxes and they work as advertised. Also note that the DMK box will feed data via TCPIP/UDP to other iOS apps such as iNavX for things like AIS targets and instrument data. There is also a version with a built-in GPS receiver, combine that with a Standard Horizon GX2150 and a basic wifi iPad and you have a nice setup for a small sail or power boat.
Full disclosure, I sell the DMK box as well as other brands of marine electronics at my showroom.
-Earl
Chetco SeaSmart already seems close to working with iNavX. I can see the data streaming in on the TCP/IP NMEA Client dialog box, but it doesn’t show in the app. Does that mean you still have to write some code to translate Chetco’s method of forwarding the N2K data, Rich? Also, what do you think of the DMK box?
Yes, the next release of iNavX will include supporting the SeaSmart proprietary NMEA data sentences. I am pleased iNavX supports several WiFi multiplexers including those from DMK, Brookhouse and DigitalYacht.
Thanks, but for clarity, aren’t they all proprietary because there is no standard way to do this? Also, is it hard to support so many different ways of receiving NMEA messages, and do you have to add code for each additional message type, like engine RPM or tank level?
Other than the SeaSmart, the other multiplexers just broadcast good old NMEA-0183 data over IP. So really no special or unique handling for that. With the SeaSmart additional N2K data (i.e. engine) is available besides the standard GPS navigation data. As far as the iNavX user is concerned it will all work the same regardless of WiFi adapter in use.
But isn’t the DMK box also able to encapsulate N2K, plus SeaTalk? And doesn’t at least one DY product, Boatranet, now broadcast N2K?
But I guess the real question is when will other charting app developers follow your lead and support these gateways? I’ve yet to really experience it myself, but have got to believe that integrating apps with a boat’s sensors is a big deal.
The SeaSmart will be the first native N2K support in iNavX. Previously one could combine an Actisense NGT-W ISO with any of the NMEA-0183 WiFi multiplexers to have N2K compatibility. This won’t be the first time, however I supported N2K as MacENC natively supports N2K via the Actisense NGT-1.
What is ultimately needed here is a standard way to discover IP based NMEA 2K and 0183 data streams and a definition re:how they are transported over UDP (probably multicast). I would think an informational RFC with IETF is appropriate. This would allow any IP based app to discover and consume the stream via a interoperable standard.
Thanks, Paul. Hopefully NMEA is considering a standard for this. But is UDP fast enough, and can it be used in both directions?
Chetco SeaSmart, incidentally, is already two way, and I saw a demo of it running a Chetco switching box. That’s one of several reasons why I think Chetco ought to get their products NMEA 2000 certified. I hope DMK is looking into certification too.
Couple ways this could be done…
1. Multicast UDP
2. Over a specific TCP connection.
One of the readily available multicast IP discovery mechanisms could be used to locate the service (Bonjour, DLNA, etc) and indicate which transport it is using. Security desires would tilt the TCP/UDP choice.
As IP based standards go, this would be technically relatively easy to do. The mechanisms are already there. The “work” would be in reaching a stakeholder consensus, writing it up, submitting to IETF, etc.
To make a note, SeaSmart.net has the advantage of supporting both TCP and UDP broadcasts as well as a full function Web Server. This means that not only can it provide NMEA 1083 and NMEA 2000 data directly to such apps as vDash, iNavX and Coastal Explorer for chart plotting (via TCP or UDP ports) , it can also at the same time, provide graphical display to other hand helds via Web browser interface for data not handled such as engine monitoring, fluid tanks, battery status and more.
Recently added is the ability to provide bi-directional support for NMEA 2000 which leads to wireless bridging of separate NMEA 2000 networks. In addition – is the support for remote switch control.
The SeaSmart.net Protocol is actually an extension of the NMEA 0183 Protocol where NMEA 2000 data is converted to ASCII and encapsulated in NMEA 0183 propriety sentences.
[$PCDIN,01F200,06C0F47D,01,00E01FFFFF7FFFFF*23]
This allows legacy equipment to continue to handle the new data. The complete Protocol spec can be found at
http://www.digitalmarinegauges.com/support.html/manuals/seasmart-manual.html
All NMEA 2000 PGNs are supported and the most common already decoded in the specification and Web Page examples.
The Web Server interface is open sourced so anyone can modify the existing content to suit their needs. Recently for the Paris Boat Show, new graphics were created to better suit iPad and user customization of each gauge by simply tapping on the display window to cycle through PGN parameters. An example of the new set of Web pages can be seen here at
http://www.chetcodigital.com/SeaSmart_NGT_Navigation.htm
At any time, customers can download new Web Content to replace/update existing files so SeaSmart.net can grow and evolve.
Another customer wanted to modify the Fuel Info page to include several fuel tanks, water tanks, holding tanks. It only took a few hours to create the new pages from the existing examples.
While we do not expect every SeaSmart.net customer to be experts in Web/HTML design – it does allow for quick modification and development for those who have the skills or can hire those who do. The hope is that cooperative efforts can lead to interesting and useful new applications.
One of the advantages of WiFi and Ethernet support is remote access by Web Browsers from anywhere in the world given the vessel network has internet connectivity. Just about all routers these days (costing from $29) support Port Translation thereby allowing remote browser clients to access the SeaSmart Web Server from behind the router firewall. Yes – this takes a little bit of IT knowledge but is very common place and widely supported.
And if that wasn’t enough, new this coming quarter, is a USB memory data logging device called SeaStick. It attaches to the SeaSmart.net adapter and allows any USB Memory Stick to be used as a storage device to data log all bus activity. It is being used in performance analysis and asset tracking. A 8 GB memory stick can easily hold up to 365 days of continuous 24/7 data. Supplied utilities can read and dump the data in to a spreadsheet or playback on virtual instrumentation/chart plotting programs.
This is all very exciting — the N2K to Ethernet problem is finally being addressed.
I think it’s interesting that from an Ethernet data transfer approach, Chetco and DMK seemed to take opposite approaches: Chetco went the “pull” route, where a client application has to request data periodically from the SeaSmart hardware, while DMK went the “push” route, constantly streaming incoming N2K data out via UDP. (Chetco apparently also supports push via HTTP POST.)
Both approaches have strengths and weaknesses. The primary benefit of pull via HTTP (Chetco approach) is that it is extremely easy to code to — virtually anyone with some web development experience can write a custom N2K “app”. This approach also gives the application control over the amount of network bandwidth consumed by N2K data transfer. The downside of pull is that it doesn’t quite match up with what the N2K senders are actually doing — constantly writing data onto the bus at different rates and priorities. Each “pull” of data from the Chetco box represents a snapshot of the data on the N2K bus at a moment in time, and in theory high frequency data may be “lost” (that is, not sampled). This raises questions about how such data should be handled — for example by averaging it between pulls.
The benefit of push is that all N2K data is streamed onto the Ethernet network, and it is up to the application developer how to handle it. In theory, no data should ever be lost (or more specifically, unavailable to the consuming application). It’s up to the application developer how to handle the data — sampling rate, averaging, etc. become the programmer’s problem. And this of course is the downside of push/UDP — it’s more difficult to code to.
Separately, it is definitely worth mentioning that while both of these devices are very interesting, and while I hope they will generate a lot of new ideas and applications by DIYers and installers, if you already have a computer on your boat network there is a cheaper approach to accessing N2K data. Frequent Panbo contributor Kees has written a pull-style N2K data server “daemon” based on his packetlogger research that can neatly expose N2K data to a software developer running a Linux or OSX computer with an Actisense NGT-1 N2K/USB interface. Moreover, Kees has done a very nice job of reverse engineering and decoding the N2K messages, something that both Chetco and DMK leave to the developer (though Chetco has published a number of PGN decodes in the PDF referenced in Ben’s post above).
In all, these developments are a major sign of the maturity for vessel monitoring and control. Whereas previously N2K data was accessible only to that rarified group of engineers with hardware and software experience with Devicenet, our boats’ data has now been…democratized.
/afb
Adam, both devices support both push and pull. I’ve got my hands wrapped around one of the devices right now and I’ve been talking to both companies about some minor extension that perhaps they didn’t consider. I’m most interested in providing a solution to move routes between devices and these boxes make that possible in some very nice ways. Exposing all the network traffic wirelessly is a wonderful benefit as well.
Kees solution is very nice as well. We’ve been chatting too. There’s such great things going on right now.
We’re at a funny time with all of this. Most discussions like this one often happen behind the scenes and not in public. Panbo and internet discussions open up some of the sausage-making parts of product development – some of which is not pretty.
I’d hope that a wireless standard for network N2K/N183 would hold off a bit until more exploration can be done. There’s a lot to uncover with these new tools and some capabilities which should be considered. At a minimum, I’d hope that any standards effort would consider the different players involved and what they think is needed.
Jeff,
under the “some capabilities that should be considered” , any chance some thought is given too:
(1) Allowing applications on smartphones to massage the data, and pass it back to the network? For example, some real useful applications would be:
(i) take wind and boat speed information, determine a target true wind angle to sail at and target wind speed, to be displayed on instruments. E.g. If I have displays that allow me to select which nmea2000 sensor to display, I might want that calculated target angle and speed from the smart phone application to get injected into the nmea2000 bus as if they were coming from sensors
(ii) take my PB200 apparent wind, heel angle, ultrasonic boat speed, H2183 compass, engine RPM, rudder angle, gps information and spit out (based on engine running or not), an adjusted true wind relative to water, ground wind, current set & drift, all adjusted for the estimated forces acting on the sails and keel of the sailboat.
(iii) expanding on the idea, maybe my smart phone is spitting out sailing information entirely undefined in nmea2000, but still be co-mingled with the wireless protocols create so that the information can appear on other smart phones or tablets on the boat and be captured in a data logger as below.
(2) Automatic & reliable data logging with captured data being available “in the cloud” when next in range of Wi-Fi, either shore based or a hot spot capable smart phone. I would like to be able to use past information from my travels without having to (a) start/stop a capture from an MFD or smartphone (b) insert / remove / transport files on memory chips, (c) manage a transfer of files to a computer at home (d) do this without a dedicated device on my boat.
From the cloud, be able to use it in applications ranging from ActiveCaptain to sailboat racing simulators, converting it to formats other applications use (may require reducing sampling rate), or pulling it up on excel.
Dan
I agree totally, Dan. It’s that type of discussion that’s needed to uncover everything that’s required. I don’t think these newer gateway products are really designed to filter and modify incoming data to send it on to other devices – not even sure N2K can handle that type of thing unless some type of virtual instrument is created in the gateway with data combined together from the real instruments.
My desire is to get multiple, simultaneous, wireless connectivity off N2K and N183 as well as allow wireless data to be put onto one of those networks providing direction to a particular device.
Jeff, Paul’s question on the forum got me thinking of a very common scenario for a virtual STW instrument.
Basic STW: Take inputs as STW and SOG, and output STW as a 2nd STW sensor on N2K. If STW is zero for > 5 minutes, automatically substitute SOG for STW.
Advanced STW: Take as input STW, angle of heel, table of values, a virtual instrument would output an adjusted STW based on looking up the heel angle in a calibration table that would adjust STW for different boat speeds and angles of heel. Maybe even allow for two STW sensors (port & starboard). Benefit is more accurate STW, true wind, set & drift in a variety of boat hulls including those that plane. Clearly calibration values would be different at the speed the boat planes.
There could be good reasons that the virtual instrument logic is not in the gateway (unless the gateway is based on android and owners can load virtual instruments from the android market or something), but (i) it would be nice is a basic set of virtual instruments was included, and (ii) it would be a good location to inject the virtual instrument data calculated on a smartphone, tablet, or pc, onto the N2K bus.
Ben, Paul, Jeffery, Joe, et al – Streaming the instrument data over WiFi is great, as we’ve recently experienced using the Brookhouse iMux product into iNavX – but one nagging problem is the need to disconnect from the onboard WiFi network (and lose the Internet connectivity) in order to connect to the multiplexers WiFi network and receive the data. If you’re using an iOS device and have a 3G connection, it’s not an issue – but without the 3G, or if using a laptop or PC, you have to choose one Wi-Fi network over the other, and fuss with the settings each time.
Can any of you clever fellows comment on whether it is technologically feasible to combine the datastream from any of these devices (Chetco, DMK, or others) with an existing, internet-connected onboard Wifi router, something a lot of boats have these days?
Requiring a disconnect from the main boat router is unacceptable. I wouldn’t consider a solution that required that. I can have a high gain WiFi receiver providing WiFi internet connectivity to my boat’s router as well as the NMEA2K/183 gateway plugged in so everything is available on the same router connection. It’s the only thing that makes sense.
The Chetco SeaSmart WiFi will work in both AdHoc (stand alone network) or Infrastructure mode (existing network). A firmware update will allow it to accept both N2K and N-0183 data. It’s a good solution.
I sure hope the people that make these bridges are listening to Dan Corcoran. I have been looking for a way to create a virtual instrument to inject a modified relative wind, rotating mast, for display on a maretron DSM 250. It sure would make life a lot better for quite a few circumstances and is hopefully the way forward, one less area of vendor lockin. Now to just get rid of the proprietary radar and i will be content
Jeffery and Rich, thanks for your responses. So it definitly is feasible – now I just need to figure out how to get the Brookhouse iMux WiFi signal into the exisiting Netgear router – which I am guessing won’t work unless the gateway specifically supports infrastructure mode….the quest continues.
iNavX 3.5.0 is now available in the iTunes app store. iNavX 3.5.0 adds native NMEA 2K support for the Chetco Digital Instruments SeaSmart WiFi. A complete list of NMEA data supported is here ..
http://www.gpsnavx.com/iNavX/help/instruments.htm
The plan is to add native N2K AIS support in the next release. In the meantime N-0183 AIS is supported.
Existing SeaSmart WiFi owners should contact Chetco about a firmware update to take advantage of the latest features.
Will this work with the ethernet version of SeaSmart as well? I am looking to add this for spring, but no need for WiFi from this box, just want to integrate into boat-wide wifi.
Curt, that’s exactly the setup I wrote about in the entry:
“It took me less than an hour to cable a sample Chetco SeaSmart E-Net to Gizmo’s NMEA 2000 network and WiFi router…”
I’ll have the SeaSmart E-Net running in the lab soon, and I just got the DMK box running with NMEA 2000 and 0183 simultaneously. More soon…
Yes, iNavX will work with SeaSmart Ethernet (E-Net) version which connects to existing router. The advantage of using existing router, is multiple iDevices can wirelessly connect to the N2K data.
I should add the SeaSmart WiFi will accept both N2K and N-0183 data. I believe a newer SeaSmart E-Net is in the works that will also accept both. iNavX can handle both N-0183 and N2K at the same time.
Ah, so the 183 is the key difference for now, I imagine that will be solved before the snow melts! Thanks all and here is to hoping ipad3 is great in sunlight!
Digital Yacht also introduced a third generation Class B AIS transponder in London. Video here:
http://www.youtube.com/watch?v=67Ke0xveckg
And product page here:
http://www.digitalyacht.co.uk/product_info.php?products_id=11686
Among other things, it’s good to see a smaller company like DY getting products NMEA 2000 certified.
Sorry to report that NMEA has essentially served Chetco with a Cease & Desist order regarding its various SeaSmart “NMEA 2000 compatible” products, and I think NMEA has a valid case. I hope the situation will be resolved to everyone’s satisfaction, but until then I have to advise caution about purchasing SeaSmart products.
Ben, if NMEA is going after Chetco, doesn’t that mean any developer who uses/support a NMEA certified Actisense NGT-1 will also required to pay/certify with NMEA? I thought the whole point of the NGT-1 was developers are abstracted from NMEA and Actisense would do the certification themselves? In other words it let the small developer support N2K without a large expense. I sure hope so.
http://www.actisense.com/HTML/Products/Gateways/NMEA_2000_PC_Gateway_1/Software.htm
No worries, GPSNavX. I believe that by NMEA 2000 rules what Actisense and you (and many other software developers) are doing is perfectly fine. But NMEA treats hardware with an embedded Actisense gateway quite differently, and that’s where the problems arose. Like I said above, I’m hopeful that the issue will get solved. But I’d rather “wait and see” before I write more about it.
The DMK Yacht guys sent us a sample and it does seem to work well.
The 0183 data streams in with no changes necessary and extending it to NMEA 2000 was just a few minutes work with a bit longer to debug.
Nice little product.
Thanks, Nick. So Expedition maybe running on a Windows tablet with WiFi connection to boat sensors? Sounds good.
But I suspect that DMK has to get right with NMEA too. The organization has been pretty tolerant about non-certified hardware over the years, but I think un-certified products whose main function is accessing the PGNs that so many members worked hard to create got their goat. (Though it is a complicated story which I hope to delve into soon.)
By the way, I saw your work on the America’s Cup committee boat…well done! http://goo.gl/9HQL9
Thanks. AC34 has been an interesting distraction.
DMK. At present they are only listening to the NMEA 2000 traffic. As far as I can see, the device doesn’t request an address on the CAN network, so is invisible to the network to all intents and purposes.
The other thing is that it just has connections for CAN H and L rather than a standard connector. Of course, it can also be powered off the N2K bus as well
Whether that has any bearing on anything is another matter of course.
I am looking for a NMEA 2000 compatible device that can detect the network data frames and convert the information to a serial character string without reducing the instrument information that is contained in the NMEA sentences. Masking should be enabled so that individual or groups of sentences can be selected. The device should be capable of bi-directional data flow.
One possibility may be the WiFi or Bluetooth OBDLink devices that utilize the STN1100 IC for frame detection and decoding. The devices are CAN compatible, but I do not know if there would be any problem with handling the NMEA 2000 frames. I do have experience with use of these devices for automotive applications and have written software to translate and process the instrument data.
A second choice could be the Actisense NGT-1.
The Actisense NGT-1 site indicates that “Direct transfer of the NMEA 2000 messages mean there is no translation to change the NMEA 2000 data”. Actisense also states that “the Actisense ‘Certified Software’ program offers software vendors a quick method of adding an NGT to their products – allowing them to share and interact safely on the NMEA 2000 network via the computers’s serial or USB port. The NGT acts much like a firewall – preventing illegal operations and maintaining the integrity of the NMEA 2000 network.”
The exact meaning is unclear, but it appears that the NGT-1 and the application software must meet NMEA 2000 (and Actisense ?) licensing requirements and costs. A second limitation may be that Actisense’s interface software may limit data transfers to specific PGN sentences.
Additional possibilities might be the Chetco SeaSmart.NET devices or the DMK box. The Chetco devices apparently have a limitation that only specific PGNs are processed. Adding to or changing the list of the PGNs requires firmware updates from Chetco. The details of the DMK box are unknown at this time
SeaSmart.net is a WiFi/Ethernet gateway that supports NMEA 0183 and NMEA 2000 via the Actisence NGT platform,
The additional technology SeaSmart.net adds to the NGT platform is on the user end of the gateway. We add an additional controller and firmware that reformats the NGT API to create a more usable protocol compatible with the embedded Web Server and Network interfaces (WiFi and Ethernet). It is this published protocol (http://www.seasmart.net/pdf/SeaSmart_Net_Protocol_revD.pdf) that developers such as iNavX have been using to add NMEA 2000 support to their products. There is no indication that this violates any NMEA license or IP. Developer talks to our SeaSmart protocol, our SeaSmart protocol talks to Actisense NGT API, Actisense NGT API talks to NMEA 2000 bus.
Chetco Digital will offer a separate Actisence NGT adapter bundled at a reduced price to connect to a SeaSmart WiFi or Ethernet adapter serial port if full NMEA 2000 certification solution is required.
Joe Burke
CTO
Chetco Digital Instruments
http://www.chetcodigital.com
SeaSmart.net will support all PGNs passed to the Actisense NGT adapter with a “ Receive All” command.
Users can also configure specific lists of PGNs using the SeaSmart protocol as described in the Spec protocol (http://www.seasmart.net/pdf/SeaSmart_Net_Protocol_revD.pdf). When not using the “Receive All” mode, the active list is 32 PGNs. There is no restriction to PGNs that can be used.
Changing the default PGN list does not require a firmware update. They can be set by direct USB connection to PC and Actisense NMEAReader tool, via embedded Web Page, or directly over TCP connection at any time. At times it may be desirable to filter PGN traffic.
SeaSmart.net will also process NMEA 0183 and NMEA AIS messages received on a separate serial port.
Joe Burke
CTO
Chetco Digital Instruments
http://www.chetcodigital.com
Hi Joe,
Thank you very much for the information. The PGN clarification is most helpful.
It would be useful to be able to pass device resets, updates and other similar data to the CANBus. Do you know the extent to which the Actisense firewall restricts incoming data ?
The licensing is still confusing. There is a lengthy document on the Actisense site entitled “ActisenseComms SDK Compatibility Process”
The link is: http://www.actisense.com/Downloads/Documents/NGT-1/ActisenseComms%20SDK%20Compatibility%20Process%20issue%201.pdf
I don’t know if Chetco uses the Actisense SDK or not. SDK access requires NMEA membership and there is a complex certification process if one wishes to meet the NMEA/Actisense licensing requirements.
I understand Chetco’s approach which uses an additional hardware interface and a Web server. It is possible that this avoids some of the NMEA licensing restrictions.
SeaSmart.net does not use the Actisense SDK but rather a lower level API.
We are looking into the effect on third party Apps and will some more info on that shortly.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmart.net
iNavX 3.5.1 is now available in the Apple iTunes app store. It adds N2K AIS support to the SeaSmart multiplexer.
Congratulations to Chetco for getting not one but three products NMEA 2000 Certified. They are the SeaSmart NMEA 2000 TCP/IP Gateway, the SeaSmart Analog Gateway, and the SeaSmart NMEA 2000 Gateway. More info here: http://www.seasmart.net/