Chetco SeaSmart.Net modules, wide open N2K-to-Ethernet?
Chetco Digital Instruments has been quietly developing software and hardware to digitize and display analog engine info for some time, and with some success I hear. But as of yesterday’s big press release, Chetco has jumped big time into marine data networking, particularly the hot, if confusing, area of putting NMEA 2000 messages into an Ethernet format and serving them to whatever wired and wireless devices can use them. So that little $579 SeaSmart device above contains an N2K-to-Ethernet gateway (by Actisense, I think), a WiFi transciever, and a “CGI/AJAX web server” that puts out an “open sourced HTML protocol” that will purportedly support “any application from weather station, dual engines, battery banks, fluid tanks and more.” Excited yet?…
Now I’m not quite geek enough to thoroughly understand what Chetco is doing here, let alone put it in context, but I’ll bet that numerous Panbo readers are, and here’s hoping that some of you will comb through the materials and report back. Is this HTML technique limited to browser displays — like Chetco is showing off online — or can it feed nav data to apps like iNavX and Navionics Mobile or whatever? Multiple apps simultaneously? Would it be hard to modify such apps to read data in this form? Is this the technique Digital Yacht should use so that its BoatraNet system can serve third party apps as well as its own web pages (which DY is interested in doing). Is this how Maretron could serve nav data to third party apps while keeping its new IPG100 N2KView server secure (which Maretron is mulling)? Are we looking at a simple standard for NMEA data over Ethernet/TCP/IP? Or am I dreaming 😉
OK, the direction they’re going…stellar. I’d just really like to see more specifications. They seem to confuse html and http. I don’t like seeing words like html protocol – that just looks like a typo.
I would hope that they allow http access to the server in the box to query parameters. That’s what the table of http headers implies. But there isn’t enough information on it. I’ve love so much to see a real interface specification about how I can query the box.
This is exactly what I think is needed – they’ve hit it perfectly. I love that they even provide a WiFi model.
So Ben, why can’t a radar input interface be next? Don’t you think just one manufacturer is going to see the value in opening their hardware to a huge new customer base?
I love this and would love to experiment with it on multiple platforms.
Ben,
Q1) Is this HTML technique limited to browser displays — like Chetco is showing off online — or can it feed nav data to apps like iNavX and Navionics Mobile or whatever?
A1) No, AJAX implies that other apps can get at the data
Q2) Multiple apps simultaneously?
A2) Probably, no reason why not.
Q3) Would it be hard to modify such apps to read data in this form?
A3) No.
Q4) Is this the technique Digital Yacht should use so that its BoatraNet system can serve third party apps as well as its own web pages (which DY is interested in doing).
A4) Maybe, see below.
Q5) Is this how Maretron could serve nav data to third party apps while keeping its new IPG100 N2KView server secure (which Maretron is mulling)?
A5) Maybe, see below.
Q6) Are we looking at a simple standard for NMEA data over Ethernet/TCP/IP? Or am I dreaming 😉
A6) Maybe, see below.
Certainly if somebody presents a “really open” standard that is well designed then it would be a good thing if manufacturers would build in support for this standard. This could very well be that standard.
If I read the (sparse) Chetco documentation it looks as if they are processing NMEA2000 into NMEA0183 style messages, as it says that it will serve up NMEA0183 and NMEA2000 combined with the reference to $P ($P is the prefix for proprietary NMEA0183 messages.)
That means that interspersing NMEA2000 with NMEA0183 is well defined, but it does mean we’re back to NMEA0183. The range of circumstances that the protocol is useful for will depend on the content of the message arguments. Unanswered questions at this point are how the protocol handles multiple sources for the same information and whether timing information is passed on.
Still, I welcome this development, and I will be happy to produce an open source version of this protocol server when Chetco publishes more information for those Panbots that prefer something home-brew.
Wow, you guys are fast! I’ve just let Chetco know that this entry has gone up, and hopefully Steve James or another member of the team will answer some of these questions. They’re purportedly going to send me one of the WiFi units to test, too.
And then have them call me. I will cost reduce it so they can sell it for $150.
Wow, hope this is what we are waithing for. iNavx? What is your comment?
And if It converts from nmea 2000 to 0183, It Will be easier for Apps to use.
Ok It is à way back but the only protocol Apps are using till now.
I am in the back of the bus — or class — on the excitement here. Is it that you might monitor almost anything via your phone as an app ?
I can see could be MIGHTY useful if you’d like to know in-season how low your boat is on it’s her lines… or when out-of-season and when on stands whether she’s still upright after last nights gusts came through and blew the town’s church steeple off its mounts !
I like Chetco’s approach. It appears that they are displaying the data in a webpage rather than an app. This way there is no need for additional costly apps or specialized software.
Any device that has a web browser can display the data. The introduction of the new HTML5 standard will add many addtional features to web pages.
Mark
http://i-marineapps.blogspot.com/
Mark M, Browser data display seems OK for some things like instruments, but I’m hopeful that this same data can be used by apps to plot boats on charts, etc. etc. (And glad to hear about your app review blog, which I’ll add to Panbo’s blogroll soon.)
Mark P, I think the sky’s the limit here. Putting basic sensor data into a form that can travel easily to any platform has infinite possibilities. Off boat monitoring, in season and out, is definitely one. And I’m heartened that Kees and Jeff — who know a lot more about the nitty gritty of all this than I do — seem tentatively enthusiastic too. Hopefully, we’ll hear more from Chetco soon.
If anyone wants the equivalent of NMEA data over wifi, HTTP will never cut it. We would need a new protocol. HTTP was not designed to broadcast information in real time to all listeners on a network, like NMEA is. HTTP is a Client/Server protocol: client X requests info from server Y. Anything built upon HTTP you be fundamentally different then NMEA.
NMEA is a push or a “Broadcast” protocol where all devices transmit information as it happens in real time and all listeners receive it instantly. It’s one transmission for all (broadcast). Listeners can decide to ignore a message, but they get it no matter what.
With HTTP the client (say with iNavX over wifi) is responsibility to request the information “it think’s” it needs when “it thinks” it’s the time to get it. Another difference is that only the client requesting the information will get the answer. Even if ten clients request the same info at the same time, the server will send the same answer ten time in a row, one answer for each client.
The fundamental difference is HTTP is not suitable for real time “event driven” type of communication network.
In short, HTTP is great to display info where “real time” accuracy is not important, such as fuel tank level and such, so with this in mind the SeaSmart.Net is great. It’s nice for gadgets like iPhone or “over the internet” boat monitoring and antitheft system. I would not expect more from this new product. All of the above could be the reason why DY says its BoatraNet HTML charting system should not be used for navigation and that they had no plans to make this a true navigation software.
Where I have reserves is using wifi for anything serious. Wifi is very unreliable, it’s prone to electric and metallic interference and not energy efficient, a big issue on a boat don’t you think?
Well David, it all depends.
If you strain the spec a little bit it is quite possible for a HTTP connection to “stream” content. HTTP 1.1 helps, as does chunked transfer encoding. Those aren’t really necessary though. All that it takes is that the sender and receiver agree on how the content is received.
For instance, a “HTTP” server that sends out pure NMEA0183 strings could send the following response to a connection request:
HTTP/1.0 200 OK
X-Streaming: yes
Content-Type: text/nmea
$IIDPT,xx,xx,xx,…
$GPGLL,xx,xx,xx,…
and then just keep sending NMEA0183 until the other side stops the connection.
Now such a thing may not be “in the spirit” of HTTP, but it is quite legal. As compared to a “clean” TCP/IP connection what HTTP brings here is a standardized way of specifying possible query limiters (the HTTP request could state which NMEA sentences the receiver is interested in) and it makes it easier for the protocol to pass through firewalls. Chunked content would make it acceptable to proxy servers as well.
Kees
I agree you could stretch HTTP above and beyond, but that is different then broadcasting. It would also cause some issue down the road as there could be tcp session issues on http servers, client browsers and network devices, says NATing devices or firewall type devices that do application layer filtering. But you can get something going.
HTTP was not designed for real time event driven communications while MNEA2000 is. We shouldn’t think that replacing an apple with an orange will give us the same results.
You are right, we could/now have great NMEA2000 to HTTP gateways over WiFi or ethernet. It would suit some applications and be a great addition to boating. But I would not trust, not one second, HTTP to be the core communication between my autopilot, my heading compass, ruder sensor and Wind instruments, not wired and certainly over not wireless.
That’s what I meant by HTTP would never cut it as an equivalent alternative to NMEA2000.
Going along with Kees, since 1999 HTTP 1.1 has supported persistent connections. I would hope that an application-specific box would provide capabilities appropriate for the application. It’s why I’d like to see more info about the http support.
But even more, if they support HTTP and see the light about being open with the protocol, there’s no reason they wouldn’t support UDP eventually too – if not now. It would give them more customers immediately as some existing products can accept and use a UDP stream today.
I kind of like WiFi for a boat for inter-device communications. It might have some issues on steel boats – don’t really know. But it’s fantastic on mine.
Jeffrey
Persistent connections is another matter. It’s about not having to open and close communication sessions every time a client makes a request. Like every time you click a link to the same server using your browser. Opening and closing a TCP communication session is expensive. It’s not for sending continual information to a client (called streaming).
Then UDP is also another matter. Its counter part is TCP. Basically you use tcp where you need to be sure your information will get to the receiver (there is more to it but let’s keep it simple). UDP is for when you send info but you don’t care if it gets there or not. There is less overhead with UDP but it has its down side.
A few points re: some of the comments made above and a review of the brochures (contain several technical errors that make it tough to discern exactly what the products do).
– one should be able to point any web browser at the Chetco and view a display of the NMEA data. Upside is that no special app needs be installed. Downside is you get only the Chetco display.
– They imply that HTTP POST can be used to push data to non browser based apps, but details are thin. Seems there would have to be a way to tell the Chetco where to POST the data. The receiver has to be running an app which contains a HTTP server.
– though HTTP is typically used in a client pull mode, there are ways to use it such that the client can subscribe to and receive immediate data updates.
– UDP multicast might be more useful than the HTTP POST.
The very good news here is that someone is pushing NMEA 2000/0183 over IP. You then have the flexibility to choose the underlying network that works best for your situation (Ethernet, Wifi, Zigbee, etc). Also can choose upper layer protocols as appropriate (UDP, HTTP, etc).
If I’m reading your post and the Chetco web site correctly, this little widget would let me view most NMEA2000 data on my iPhone (or other web enabled device) much like the Maretron IPG100 + Maretron N2KView solution but for far less money.
The Chetco solution retails for $580 versus $1,100 for Maretron – or $3,600 if you want the Maretron N2KView version that is able to control switches via NMEA2000 (Chetco appears to include switch control at no extra cost).
Of course the Chetco box uses more power than the Maretron one (12LEN versus 3LEN), the Chetco default gauges aren’t nearly as pretty as their Maretron equivalents, and there are additional features in the Maretron solution that might be desirable or required in some installations. On balance, however, this looks like it might be exactly what I’m looking for at a price I’m willing to pay. I just with that the Chetco site was a bit more forthcoming about the details.
Jeff,
Wifi has no problem reaching all parts of my aluminum sailing yacht. YMMV, but Wifi seems quite adept at getting through the windows (which I cleverly placed my Wifi antenna near to!)
David,
Who was talking about replacing the compass input for your AP with Wifi? We’re talking information input into your navigation display here, which is a LOT less time/system critical compared to the AP. To put my remark in perspective, I do NOT want my boat to start turning when I didn’t instruct it to, but I don’t mind that my nav display on my SECONDARY nav display is a bit behind the times when I am dodging rocks!
At this point in time I don’t think Jeff or me or anyone else is advocating doing away with your dedicated MFD quite yet, just that a portable system is a very nice add-on for relaxed cruising!
I personally found that now I’m using the following (in order of decreasing “mision criticalness”):
1) A chartplotter
2) A PC running navigation software
3) A portable system (in my case: iPad running Navionics (2010) and iNavx (2011))
[with, on a tangent, paper charts in case something goes awry]
that the system I depend on the most is the MFD, but the system that I use the most is the iPad, just because I can tinker with the display from where I am instead of where the MFD is. I run what-if scenarios as well as examining AIS targets a LOT easier from the comfort of wherever I happen to be seated using the iPad.
As was pointed out earlier, at $579 this is quite expensive for what it does btw.
For that money I can also buy both an Actisense NGT-1-ISO connected up to a Digital Yacht iAIS, and get a free AIS receiver thrown in with the Wifi access to N2K data. Well, nearly. Still, a $ 599 iAIS plus $ 150 or so for the NGT-1 suddenly seems very good value …
This looks interesting since we have ethernet and wireless networks in the boat already. Has anyone seen N2K sending units that can be retrofit to a Yanmar 4JH3E? I’m about Googled out, and the Annapolis Boat Show came up dry as well. THX
Wouldn’t it be great if it just multicasted the nmea content in a IP multicast group (like TV is distributed in IP networks), and over udp or rdp? The receiver would then just listen to the stream, and pick whatever parameters it would need for the application. And it would be near real time.
You are absolutely correct. There are no APP’s needed. Its all based on web browser. The data is viewed via web pages. As such, users can create their own layouts and gauges. We hope to encourage this and welcome users that design such pages to share them on our web site for others to use.
I will be addressing the rest of the questions shortly. Power was out for past few hours up here in the great SW Oregon Coast.
Amen!
Kees, re Chetco vs Digital Yacht iAIS…
I like the iAIS product except for one thing. It only allows one WiFi device to be connected. Is there a way to connect more? That means you need one iAIS for each iPad, iPhone, laptop, etc. From what I see, Chetco has a server built in and I’m assuming all my devices can connect to the same gateway.
Then Paul, I read the http POST as the transaction coming from the client to the Chetco box. The viewing app makes a polled POST request and the server in the Chetco box responds back with data. It’s a mediocre way to handle volume transactions because of the transaction setup time. A streaming method like David made clearer is that way to go.
We need some Chetco answers. How come they’re not working on Sunday!
😉
Multicast would allow, in any practical sense, as many receivers as you want. And the bonus is that bandwidth requirements doesn’t increase with additional receivers.
@ Kees (tech warning)
Per HTTP specs, POST is intended to allow a client to update data on a HTTP server, not read data from it (that be a GET).
Yes, more info needed from Chetco re: the HTTP interface. It might be a SOAP based interface, RESTful HTTP, or some other non mainstream usage of HTTP.
Jeff, how does this work if we point our boat computers and/or smartphones to a VPN company like Astrill or Utopia? Does that effectively prevent us from using such a solution, or will our boat computers go direct to the Chetco product without using the VPN?
Try our SeaGauge Remote box. http://www.seagauge.com its 3 pulse, 12 analog and 1 NMEA 0183 input (NMEA 2000 optional.) We convert the Analog to digital then to NMEA 2000. Everything from EGT to batteries 200+ gauge selections to pick from. You pick the gauge, the look, the theme.Change on the fly.Built in USB, Serial/0183.NMEA 2000 Optional.
View and log data on PC, Smartphones, compatible displays or ? vDash performance monitoring software is free.
We can supply N2K to Ethernet for $495. This module would go N2K to Ethernet to Router to Internet, Intranet, Smartphone, iPad etc. Plug and Play installation. No Apps, No license fee’s, No software charges, unlimited HTML display design. A Router is supplied free for the month of March with any SeaSmart.net purchase.
We are not trying to replace anyone just offer cost effective, plug and play open source products.
I’m doing multicast of sensor data on my boat. I get most of the standard data from an E-80 feeding an Actisense NGT-1 connected to a low power server running Voyage Linux where Kees Packetlogger software does the the heavy conversion work. Packetlogger feeds my program which selects data I want, adds in data from other sources, puts it into JSON format, and multicasts it on both the wired and wireless networks.
As others have mentioned, it is a great solution for having any number of auxiliary data processors, displays, etc. I’m going to add a 10Hz GPS that will put out a separate multicast stream.
At this point I am just testing various methods of picking up the data and displaying it. Too bad JavaScript can’t join a multicast group, which probably means that browsers will have to use an alternative method. HTML5 has a feature called WebSocket that might be good for communications with a browser with low latency and overhead.
I am also planning to connect my multicast data with applications such as PolarNavy.
Jon
Hi Jeff,
HTML users can design any gauge look they wish. All we do is pump the data. The displays we currently show are from a small library of looks. Our weather station data is based on Airmar PB200 look. Our goal is to have users to design gauge display looks and themes. All software required to do so is included.
I just came from the lab where I watched NMEA data displayed on 2 Android phones, 1 windows 7 SeaPC computer screen and 1 SeaGauge 8.4″ touchscreen LCD in different display formats (including switch status)
More technical data coming shortly. Check web tomorrow.www.digitalmarinegauges.com or http://www.seasmart.net
Any technical questions we welcome your calls
We do work on Sunday!
Here is a Link to a Preliminary Spec for the SeaSmart.Net Protocol.
http://www.seasmart.net/SeaSmart.Net_Protocol_RevA_022511.pdf
This is designed to be a Real-Time system with updates at about 1-2 seconds. Which means we do not worry about old data – just the current stuff.
The Embedded Web Server runs CGI which takes reformatted NMEA 2000 stuff and creates a HTML page once a second with what ever PGNs have been passed through in that interval. From there, any Browser can query the resulting Web Page then display the data how ever it wants.
The really slick stuff lies on the Browser end and it’s support for JavaScript and AJAX type of updates. The Browser only updates the data – not the entire Web page, so uploads are really fast given the one second interval (only 500 Bytes/sec). The Browser is in charge of everything and all of the graphic processing.
The Key is the XMLHTTPRequest Object supported by most Web Browsers today including Android, iPhone, iPad and others. It simply requests the new HTML Page how ever often it wants and then parses the received data into what it wants to display. It is just a dynamic version of the old HTT POST. In-fact, the SeaSmart.Net modules also directly support HTTP POST of the same translated NMEA 2000 data directly to any Web Server Address.
The NMEA 2000 Protocol Gateway Posts to the embedded Web Server or any other Web Server it may have access to. This is an advantage since to can “PUSH” though any router port directly to the Internet without special NAT or PAT setup. Thus the Web pages can be served both locally and globally.
The embedded Web Servers just makes it convenient for set up since everything is configured out of the box. Just plug into the router and use the DHCP assigned address and off you go. The Web pages and CGI script is already loaded in FLASH memory. Speaking of FLASH – new web pages can be uploaded directly via Browser so updates can be performed anywhere any time.
On the topic of transaction setup time. This would be true if we were not using the newer AJAX style of server requests. However with XMLHTTPRequest objects, the Entire Web page loads just once which is where most of the time is lost. Then after, only new requests for NMEA Protocol data are sent which is much, much faster then the initial loads and startup. In practice, the SeaSmart.Net system can update 20 graphical dials on a Web Page at about 1-2 seconds even over a dial up connection. Keep in mind, that wired Ethernet is about 10 times faster then WiFi when it comes to update rates but Dial-Up is 1000 times slower then WiFi.
Another advantage we have seen is support for multiple Browser devices at the same time. Since the Web Server handles Client Requests on a packet by packet basis, it can support multiple requests for the same live data by severing one then the other within the 1-2 second interval. The response time to serve up 500 bytes of Protocol data is very small compared to the time required to render it into some useful fashion – but that is the job of the Client Browser, not the Web Server. With Smart Phones such as Android and iPhone being so advanced compared to a few years ago, there is plenty of horse power to do the job on the client end.
So, in summary – we do use a form of HTTP POST via CGI to create web pages that update as new NMEA 2000 PGNs arrive. We then leverage the embedded Browser technology of modern devices to render and display this Protocol Data in a fashion suited to the client. All based on the Open Source standards of JavaScript and HTML
Steve James – I think most people here understand how a display could be constructed using html and http POST requests to your SeaSmart.net products. Almost all of the wonderment of your products has been about interfacing outside of a browser – the ability to use NMEA2000-over-network into other applications. Is there a way to retrieve data, preferably streamed, through other TCP network transactions? Your server approach would appear to bring you all the way to this capability if the server can provide other types of requests.
Having gauges displaying raw data on my laptop or mobile device is nice, but not nearly as nice as allowing me to integrate my other navigation products into the NMEA stream that you’re already collecting. Then I could, for example, display depth sounder data over a nautical chart on my iPhone charting app.
I’ll be calling tomorrow looking for you.
Dan – yes, there are ways to get around a VPN for local connectivity. It’s a good question and one that I wouldn’t want to handle the technical support for.
oregonjoe,
Looking at the SeaSmart protocol, it seems like a good way to map NMEA2000 to 0183, without trying to force it into the legacy NMEA-0183 messages.
Are you going to be sending this format out in fully-compliant NMEA-0183 proprietary messages? This would require that you add the *checksum,[CR][LF] at the end, perhaps omitting the [BR] field. You might have to define a multi-part message format for longer NMEA2000 messages, similar to the “!” encapsulation messages.
If you do this we can run these messages through standard NMEA-0183 muxes, through regular TCP/IP / UDP connections, etc, just as we do now for NMEA-0183.
Looking at the first real technical spec provided by oregonjoe (…_RevA_022511.pdf), it seems like you’re forming a pre-made html file once a second for retrieval. There’s no POST even mentioned in the document that the client can do.
Are there more transactions possible or planned?
You are so close to turning this into something with much wider use.
Are there more PGN/data source capabilities planned? My previous depth example couldn’t be implemented for example. Basic GPS sentences are an obvious thing to add. I care much more about the current lat/lon on the NMEA2000 stream than the current air temperature.
It’s a pity to see that there’s “just another attempt to dump NMEA over ethernet”. I also see various implementations over TCP/IP pop up, which require a point to point connection and devices that support possibly multiple connections. NMEA in itself is a broadcast protocol. Both 0183 and 2000. It does not rely on a point to point connection with handshaking, its just “shouting out” the information available. And in my opinion, there is only one suitable equivalent over ether net: UDP. Simply stuff the NMEA 0183 packets into a UDP frame and broadcast them on the net. And any device that needs this data, can pickup what it needs. And there’s a standard already for that as well. NMEA 0183 V4.0 has defined TAG blocks that can be added to NMEA sentences to send them across networks, that ass source and destination info. There is even an IEC standard in the making, which exactly does this. The only drawback there is that this standard defines multiple UDP port numbers in the unallocated range at 60000 and up. I have registered a portnumber (10110) with the IANA and it would be really nice if anyone that wants to send NMEA over ethernet, would adopt this. NMEA 0183 over UDP is simple, it’s clean and lightweight. And… it is still human readable text which beats any debugging tool…
Thanks, Meindert (and all). I recall that Furuno is using UDP to send NMEA 0183 and 2000 around its NavNet 3D networks (undocumented but purportedly unencrypted and using port 10021).
At any rate, I know that many Panbo readers — myself included! — are pretty confused by this conversation, but are hopeful it will lead to good things.
Poll/Post
From some of the comments, I would like to make clear that SeaSmart.Net can support both Post and Poll of NMEA 2000 data.
In the default Web Server mode, client browsers Poll data from the server every 1-2 seconds. The device has a 4K Byte buffer which can hold about 60-70 average sized PGNs. These are all formatted into a standard HTML document which can be retrieved by the Browser using standard XMLHTTPRequest.
In Server Mode, it acts sort of like a broadcast Network since any number of clients can see the same data at the same time. It is just up to the clients to determine when and how often to view it.
SeaSmart.Net also supports HTTP POST of the same data. In fact, it can do both at the same time.
In HTTP POST mode, translated PGN information is written (POSTED) directly to a target IP Address as shown in the following example
/**************************************************
POST /XPORTN2KWrite.asp HTTP/1.1
Host: 192.168.0.1:80
Content-Length: 241
Content-type: application/x-www-form-urlencoded
Name=
$P127508,03,00,0000,7FFF,FFFF*
$P127493,03,00,007F,FF63,00FF*
$P127493,03,01,007F,FF63,00FF*
$P130312,02,00,0000,9FC0*
$P130312,02,01,0000,9FC0*
$P127488,01,00,3800*
$P127488,01,01,38A0*
$P127508,03,01,0000,7FFF,FFFF*
****************************************************/
This allows SeaSmart.Net devices to write directly to any Web Server located any where since HTTP POST can be allowed through any router. So data can written locally or globally.
The HTTP POST specifies the handler Web Page and Server IP Address or Host Name.
The role of SeaSmart.Net is to provide a Gateway to transport raw NMEA 2000 data over HTTP/HTML friendly networks. Browser based applications are more request/response type of environment as opposed to a Broadcast. Each has its place.
With this in mind, it is quite possible to setup a point to point TCP connection that stays alive as long as new data is available. It is established once and remains until terminated. This is called Tunneling and is supported by SeaSmart.Net. The advantage is that NMEA 2000 data can be constantly streamed over the internet without loss– but again, it is up to the listener to keep up.
Support for Lat/Long
SeaSmart.Net does support Latitude and Longitude via the Weather Station PGN 130323. We will be adding additional support for other sources shortly. Also there is support for SOG and COG via PGN 129026 and Sonar Depth via PGN 128267.
Of course, more are being added as requests come in.
General Questions:
Is bandwith available for streaming video?*
What will happen when two vessels are close enough hear the other’s data?
Is the data secure? How?
*Is there a better way to transfer radar, night vision or other images?
oregonjoe – I don’t see any of those PGN’s in the documentation. Don’t see anything about POSTs either. Is there more complete documentation?
Sandy – re bandwidth. You definitely have to fit the application to the medium. Is 30 frame per second video really needed? Would 5/sec work? 1?
For radar, do you need to see the realtime sweep or is a single frame update per sweep good enough? Radar also lends itself to mpeg type of compression since frame-to-frame is very similar. Still, a full refresh of a single frame every couple of seconds seems good enough to me for radar.
WiFi supports multiple channels and collisions. Here in Charleston, I’m seeing about 50 routers that can all be connected to and all sharing the same frequency spectrum. Security is also well handled by WPA encryption. Ethernet/WiFi is the way all of this should be done. Ethernet direct into critical components; WiFi for alternate displays.
I think this is a confusing topic, depending on the technical level of the respondants.
The problem with NMEA 2Kover TCP/IP is theres no standard, so every implementation will be different, but Seamarts ( if it does what it says) is at least an attempt, and the POST method is fairly flexible, even if it requires a bit of processing on the client ( ie the client to the Seasmart).
Talk about video , etc misses the point, this is a nmea to TCP/IP bridge, radar etc will never be on the bridge. Wifi is mor ethen able to handle smart radars, which by the way actually dont use video, they process the “picture” in the radar and return result data.
But again you have to ask, who wants this type of stuff, us few aficianados dont really count. Its not the problem of simply putting radar on the network, Garmin, Furunoand Ray already use Ethernet for this, its actually deciding on an industry open standard, Since theres very little advantage to manufactuers to allow you to cross brands. Wheres the ecomonic imperative
Dave
@Jeff,
Where did you get the info that iAIS can only have one Wifi client? I could not find this restriction in their documentation. Could indicate that they use a very small microcontroller that just can’t handle more than one connection?
It seems Chetco has also chosen to use such a small device, with them only having a 4 KB buffer for PGN data.
@Meindert, others,
Although UDP broadcast (or multicast) is fine from the sender’s point of view, there is a big drawback to UDP receiving: only a single program (per device) can read the UDP data; others will find the port already in use.
That means that only a single consumer like a navigation program could use this datastream.
Now there are various techniques that could be used to overcome this, but it would still be a kludge.
The second problem is that web apps living in a browser are limited to XMLHttpRequest so that they can’t use UDP at all. Websockets is not going to help, that doesn’t have UDP either.
@Chetco,
Can I point out some things in your protocol?
It looks as if you are writing up semi-NMEA0183 message in HTML served up by a proper HTTP server.
The NMEA sentences are embedded in HTML with a tag between lines. The NMEA sentences aren’t proper 0183 messages because they do not include a checksum.
This choice means that the format is incompatible with what most existing navigation programs (f.i., iNavx, Expedition, iAIS) use for reading 0183 data from a TCP server.
I think that you could easily do the following to (IMHO) improve the protocol:
1) Switch from text/html to text/plain, and use CRLF as a line break instead of {lf}
2) Add a NMEA0183 style checksum
You could do this by defining some HTTP query parameters that allow for example:
– Selection of the protocol
– Selection of PGNs
– Selection of update interval
For instance, a client that wants an endless stream of pure NMEA0183 messages encapsulated in text/plain (e.g. not at all except for HTTP headers) could make a GET request like to this URL:
http://chetco.local/data?contenttype=plain&format=0183&stream=yes
And this URL would use your current record format but show data over two sends and filter just GPS and weather data:
http://chetco.local/data?filter=gps,weather&contenttype=html&format=chetco&period=2
@Dan,
Yes, since the wifi built by the Chetco device is local it will be routed directly, outside the VPN built over the 3G connection.
If you currently use your devices using a public Wifi access point then you would have to switch networks to use the SeaSmart and vice versa. In that case you’re probably better off building an onboard Wifi with a wired ethernet SeaSmart wired in plus a Wifi client bridge to get you on the public Wifi.
Kees, iAIS’s own brochure:
http://www.digitalyacht.co.uk/files/iais%20brochure.pdf
“Max number of WiFi users……1”
I think UDP is acceptable. There has to be some tradeoffs. It wouldn’t be difficult to have a gateway type of handler like GPSGate if that was really needed for UDP.
I don’t really like the whole XMLHttpRequest as the sole way to retrieve data along with a pre-built html file to grab. It lends itself to displaying gauges on an iPhone, sure, but not the network interfacing that a $500 gateway should be doing.
Well everyone. This discussion has exceeded my ability to understand. Its now in Joe’s (CTO) hands.
I thank you for all your input. We always welcome ways to improve our product while still delivering what we originally set out to deliver.
In summary what I do know is this:
I have used it, I have seen it working with my own eyes and can greatly appreciate what it does.
We set out to allow all browser enabled devices to interface with the gauges and switches over the NMEA network, Ethernet and Wi-Fi. We enable multitudes of gauges and switch status to be viewed on realistic page layouts with realistic update rates in multiple locations locally or internationally.
Our product line is analog to digital gauge conversion and now NMEA compatible interfaces.
The seasmart.net product line and the SeaGauge/SeaSwitch product line supply a wide range of functionality in a user friendly “license free” “software expense” free package.
We have created a protocol that allows others to interface with the NMEA network. Its there for you all to use.
We did not set out to put sonar over N2K, video over N2K or promise to do anything except show gauge data (including most PGN data)and switch status.
We set out to allow the average boat owner from Megayacht down to a duck boat the ability to get useful data from basically any engine new or old, view the data in any format they choose, on any multiple display types, remotely from internet or onboard via intranet, log the data and review historical performance at will. We accomplished this goal and now we will build from there. You continued input is appreciated. We understand we can not be everything to everybody but we sure give it our best shot. If we start to charge license fee’s and software fee’s, limit tech support to a few hours instead of unlimited, charge for modifications and special programming we will definetly get more accomplished, a heck of a lot quicker but that is not our goal, if anyone wants to volunteer to take on any advanced programming we welcome your interest.
We offer a great product, leading edge technology, fare prices and excellent customer service.
If you want your iPad, smartphone etc to view your gauges and switches we offer a cost competitive answer. Thats not all we do, but for the purpose of this blog this is what we do.
Any less technical questions please contact me direct at [email protected].
I look forward to reading more from everyone and most of all we look forward to helping provide all boaters a better boating experiance.
Steve James
President
Chetco Digital
At the risk of adding too much technical detail…
Kees – It is possible for multiple programs on a single host to receive multicast UDP data if you set SO_REUSEADDR when opening the socket. I like the UDP multicast idea, but admit that work needs to be done.
To clarify, WebSocket is a TCP connection, but it may be a good way for browsers to get data with low overhead since browser cannot use multicast data directly.
Jon
Thanks, Steve. You sound a little frustrated, and I understand that. I asked for geek comments and we got them, in spades! While I’d like to think that this thread will help developers understand the issues around moving N2K data out to Ethernet and the Internet, it no doubt feels like your innovative new product line got lost in the process.
And I agree that pushing radar and/or sonar out to iPads and the like has little to do with current realities. BUT I do think that Chetco is facing the same problem that I’ve expressed to Digital Yacht (re: BoatraNet) and Maretron (re: the IPG100).
Which is that a regular non-geek boater is going to install a SeaSmart WiFi device, be tickled about his or her new ability to see gauge info in a browser on their iPad or whatever…but then be unpleasantly surprised to find out that the very same data can’t get to a charting, weather, or whatever app running on the very same device.
If a regular boater spends several hundred dollars to get depth, GPS, wind, engine, etc. info out onto a boat’s internal WiFi system and/or Ethernet network, they’re going to expect it to be available to whatever app can use it. Like a Bluetooth headset is available to every audio application (on any platform), and like the Elf GPS I’m testing now is available to every mapping and charting app on a WiFi iPad without GPS. These sort of expectations are very hard to turn around.
Right now the charting app iNavX is the only one that can use NMEA boat sensor data delivered over WiFi, but I suspect from this thread that it will not work with your NMEA-to-WiFi boat sensor system. Ditto for BoatraNet and the IPG100, I’m pretty sure. And the same probably applies to the Plotter Sync route and track synchronization just coming to Navionics Mobile apps and Raymarine MFDs (and other brand MFDs to follow). Maybe all are incompatible?!?
Chetco’s SeaSmart offering, in fact, seems the most forthcoming and open-source-minded of any to date. But all the companies moving into this niche have the same problem. When regular boaters learn that they can do SeaSmart browser pages or PlotterSync or N2KView or BoatraNet services or iNavX (and there will be lots more sensor-aware apps like iNavX), but only one of them over a given sensor-to-WiFi system, they are not going to be happy. Which is why, hopefully, all this geek talk is worthwhile 😉
Thanks for all the comments and deep insights
New Doc rev 022811 is on the site at
http://www.SeaSmart.Net
http://www.seasmart.net/SeaSmart.Net_Protocol_RevA_022811.pdf
This is a Open Source type of project so all comments are truly welcome. I especially like the ones on trying to keep some NMEA 0183 compatibility so other equipment can still be used. We will look into that and I am sure we can make that happen too.
The reason we did not go that initially was that the NMEA 0183 leading tag did not support putting the whole 6 character PGN number in with the leading $P. But we will take another look at adding the checksum and see what that does to existing equipment.
We have initially supported Engine data along with Weather, Fluid Tanks, Battery Banks and the like because it what our customer base requested. The Blog here is opening up many other uses we did not target. Keep in mind though, that the Browser Based approach is more suited for the slowly changing instrumentation market as opposed to real-time navigation.
I would also like to point out that 4K – 8K buffer size for the NMEA 2000 data is really quite large given the type of traffic. IN our world, PGN sizes range from 16 to 40 bytes so that’s over 100-200 PGNs per second – more then we ever see. Now, I admit – its not sonar, radar, or video – but that’s not we intended it for.
The SeaSmart.Net supports Browser Based Clients so we did include an embedded Web Server to make setup and installation very simple. All Web pages are preloaded in flash so no configuration is needed. The embedded Web Server, Ethernet, NMEA 2000, WiFi interfaces all drive up the costs but still end up much cheaper then if you had to purchase and install separately.
SeaSmart.Net is available without the embedded Web Server – just NMEA 2000 to Ethernet Gateway for $299 (bundled). With this you can use the HPPT POST and push directly to any Web Server on the Net. It is a great option for vessels that already have an on-board PC system and network.
Hi Ben,
No frustration here. I was just stating the technical depth of the input surpased my ability to follow. Joe has picked up the ball to keep the Chetco feedback on track and more directly answering the higher level of technical experitise needed. We were floored by the level of detail your fellow Panboites were able to share and input.
Heck we love the input good, bad and indifferent.
KEEP IT COMING. Maybe a second blog for the not so technical of us to ask and share thoughts might be needed. We will start one on our seasmart site.
Sorry if I sounded distressed. Not meant be. Keep the comments flowing and we will take it all in stride, add in the positive and adjust for the negative.
A sample headed to you to play with.
Thanks again to all who are sharing idea’s.
Steve
While not the purest N2K solution, one can connect an Actisense NGW-1 to their N2K backbone and either a Brookhouse iMux or DigitalYacht iAIS and receive NMEA-0183 data on their iDevice with iNavX. Or any other NMEA-0183 WiFi aware program.
I am always looking at opportunities to bring more real-time marine data into iNavX wirelessly. I am looking forward to when a UDP compatible WiFi mux is released for their can be a 1 to many iDevice connection. So of course I am paying close attention to these types of devices and threads.
Over on the Mac side, MacENC is now processing more N2K PGNs when used in conjunction with the Actisense NGT-1 gateway. Recently AIS support was added and I am currently working on N2K autopilot support.
Open Protocol
Ben’s comments about intersystem compatibility on Ethernet and WiFi are right on – it would be a benefit to everyone if Apps can all play together.
http://www.SeaSmart.Net/BlockDiagram.jpg
One nice thing about our approach is that there are several points were additional protocol translators can be introduced to provide compatibility with other Aps. Once data is delivered to the Web Server, CGI/ASP/PERL scripts can be run to reformat to target Apps other then Web Browsers.
If other companies publish protocol specs like we do, then it would be possible to interchange all this cool stuff.
As to my dismissal of UDP broadcasting, I have to admit I was wrong. I wrote some test code last year that reaffirmed my belief that it didn’t work. This belief started because I believed the internet sources that came up when I google’d “UDP SO_REUSEADDR”. Initial testing on my Mac seemed to confirm this, I couldn’t get SO_REUSEADDR to work.
My error was that I didn’t realise that there is a SO_REUSEPORT on OS X that you need to use to allow simultaneous receivers. On Linux SO_REUSEADDR works just fine.
Just tested with a Windows machine sending out broadcast messages with 2 Windows, 2 Linux and 2 OS X receivers and all 6 received the message.
So I stand corrected!
I have recently been able to work on the idea that I came up with to solve this problem on my boat. If you are going to use WiFi to provide NMEA data to multiple devices, you have to have a router or access point anyway, so why not have that device server the NMEA data as well.
I bought a Buffalo router with DD-WRT which is an open source router firmware that is based on linux. Using a Keyspan USB-serial adapter I hooked it up to my NMEA 0183 network. I am using GPSd and Socat which are unix programs to broadcast the messages over both TCP and UDP. GPSd outputs them in a JSON format Socat is just redirecting the raw serial data over TCP or UDP. It definitely took some toying with, but these are open source unix tools freely available. I may develop an html/javascript app to use in conjunction similar to what Kees is doing.
The router I got is 12V and uses 2A, but I got the one with more RAM and faster CPU. They have another one that uses 1.25A that might be sufficient. If this solution proves to work well, I may build my own router on one of the embedded platforms based on the DD-WRT or OpenWRT firmware.
As far as N2K goes, I don’t have any N2K devices yet, so I haven’t looked into any of that. Actisense is working on linux drivers for their gateway, so my thought is to use that if possible.
The router firmware offers other attractive features for boaters, but that’s another story.
R.e. UDP to multiple listeners? We already do this with the IstarGPS… the UI allows you to define up to 40 broadcast ports. A brute force method to be sure, but the network is vastly underutilized in most boat implementations. http://www.istargps.com
Seems really odd that NMEA, our industry leader, is absent from these discussions…
@Eric,
They might follow this forum though… I once offered someone a scan of one page the NMEA 0183 manual in a newsgroup and I received a very “nice” e-mail from the NMEA about copyright infringements..
Besides, the new NMEA 0183 standard V4.0 describes TAG blocks that can be prepended to NMEA sentences just for the purpose of sending NMEA over [quote]”complex networks, shipboard and land networks consisting of many devices and controllers. The networks’ elements facilitate communications where a talker’s output may be received by multiple listeners and where a listener may receive output by multiple talkers.” Read: ethernet.
There’s a fair bit of detail about Tag Blocks and other NMEA 0183 V4 features in a NMEA presentation that anyone can download from this page:
http://www.nmea.org/content/technical_updat/rtcm.asp
UDP Broadcasts
In listening to some of the Post is has become clear there is a desire to support UDP Broadcasts. SeaSmart.Net supports both TCP and UDP connections.
The vDash Windows application has long implement TCP support for direct Ethernet connections to the SeaGauge Remote Sensor Interface Units. Connect the Ethernet adapter from the units to router and then on to PC and view live data over Ethernet.
Of course, the drawback here as discussed on this forum is – only one connect at a time can be made to the SeaGauge unit.
Then comes UDP. Encouraged by discussions here, I went back over the SeaSmart.Net documentation and fond that it does indeed support UDP Broadcasts of transported data. I configured the SeaSmart.Net adapter as a UDP Server and sent NMEA 2000/ NMEA 0183 data out the broadcast address 192.168.0.255 Port 10001 and sure enough, it did.
I then went to a local PC with vDash and set it up to listen for the UPD on port 10001 and it did, live data over the Ethernet link. Now for the fun stuff, I took a laptop with WiFi and connected to the network SSID (via the router) and started a copy of vDash there too, and it also received the same Live UDP broadcast. Mother machines updating at the same time for a single source over Ethernet and WiFi.
| |->UDP->WIFI->PC
SG RM ->UDP->|Router|->UDP——->PC
| |->UDP——->PC
Since the Network Transport clearly works over UDP, no reason it can’t with NMEA 2000 data as well. We have developed a low level interface with the Actisense NGT adapter that allows it to connect using Windows Sockets via our Gateway interface so that any NGT based application can also use Ethernet as a transport. It is how vDash is able to read NMEA 2000 data over Ethernet. Anyone with a Actisense NGT can plug into SeaSmart.Net Ethernet/WiFi gateway and view data with vDash (TCP or UDP)
The advantage with UDP Broadcasts is that now one source (engine data, GPS, Sonar) can feed multiple listeners.
Oregonjoe highlights the advantage of IP based application protocols…you can run them over whatever lower network layer fits your situation (Wifi, Ethernet, Zigbee, etc). Write the app to the IP layer.
NMEA 2K is what is referred to as a 1-2-7 app protocol, intimately tied to a specific underlying physical network … CanBUS. Application gateway required to interface 2K to IP.
There were good reasons for this in the late 90s, but NMEA 2K is already long on the tooth versus IP based technologies.
Please, Paul, let’s not go there. Search “Ethernet N2K” in the box above for endless discourse on this subject.
I’m really happy to see oregonjoe keeping on top of the questions raised here. It’s nice to know that there are apparently many configuration options for this new box.
Now let’s get some people using it and let’s see how it performs in some real situations.
sailoutbound – cool stuff with the DD-WRT. I had heard about it but never really knew what it was. Your posting made me look into it. What a really nice approach. Are there any active open source projects with NMEA interfacing and DD-WRT happening?
Higher Level Protocol
I can certainly agree that a common IP based Protocol for NMEA 2000 is desired. We ran into that right away in working with the Actisense NGT products. They provided a low level protocol that allowed microcontrollers to put “wrappers” around the raw NMEA 2000 stuff but no-one had come up with more universal way of making it to client applications.
One example is that you can’t run Maretron’s N2K Analyzer off of a Actisense NGT. Or Actisense’s NMEA Reader off of Maretron’s gateway.
Most of this Blog thus far has discussed transport media such as NMEA 2000, TCP/IP. UDD, and HTTP – but the real goal will be making Apps that can all use the same data set.
While SeaSmart.Net and UDP Broadcasts can make it available to all, no-one knows what to do with it once they have it.
Existing Ethernet/WiFI equipment has the ability to support all the NMEA 2000 transport issues. It is cost effective and widely available. You can walk into a grocery store in Canada and buy a ROUTER next to the bread isle. There is going to be no problem in getting NMEA data onto these networks. It would just be nice if App developers could all access it.
So, to this end, we are proposing a simple higher level protocol that can be used in many ways.
First focus is Web Based because that requires the most commonality. Is was initially impossible to develop for iPhone Browsers because they did not support Java Applets. However, by going to Web Server based ASP/CGI/PERL we could translate NMEA 2000 to a form that Java Scripts could use and thus provide the user (customer) what they wanted.
The next focus could allow App Based clients to use the same Protocol to interface to a common data set.
sailoutbound – Are you sure that your Buffalo router running dd-wrt uses 2 Amps at 12 volts? Could it be 2 Watts?
I have a 3.3v Buffalo router running dd-wrt that consumes something like 2 Watts. I am ripping it out of the boat this weekend though in favor of the “full-featured” PC Engines ALIX 3D3 (not necessarily the best model of the line, but I already had it, and it does have VGA if I decide to use it). The ALIX board provides the wireless access point through a mini-PCI card and runs Voyage Linux. dd-wrt, or Tomato, on a wireless router makes a great access point which is easy to configure, but general programability and storage is limited.
The PC Engines solution will cost about 4x as much as a wireless router and the access point configuration might not be for the faint of heart, but extending its capabilities will be much easier with all Linux development tools and plenty of storage space on a Compact Flash card or USB drive.
The PC Engines boards typically require 4 or 5 Watts.
Jon
N2K and iNavX using Brookhouse iMux or DigitalYacht iAIS and an Actisense NGW-1 ISO
I put together a configuration guide..
http://www.macsailing.net/fbb/showtopic.php?tid/1389/
Meindert is spot-on. Lightweight, fast, simple: UDP. If you want completeness,
use the same port with TCP and put the 0183 stream on it. People have been doing this for at least a decade now and it works just fine.
As for NMEA2000, cleaning up the messiness of the sentences which have accreted over time was a fine idea. The way they did it was wrong when they
started and it’s still wrong. Some of us who suffered through SNMP pleaded
with the commitee to avoid recreating the same mistakes made in SNMP which
they had sucessfully avoided in 0183. Unfortunately, the Second System Effect was in full force (see Brooks: The Mythical Man Month) and they improved.
Now, we finally get around to doing what should have been done in the first place: put the data on Ethernet. It’s perfectly fine for factory automation controlling high-precision machine tools – it’s more than fine for reading your oil pressure, carrying your GPS data, and carrying video from the radar, all at the same time.
sigh
Mike, can we please keep the discussion to the Chetco Seasmart module, which extends an existing network of NMEA 2000 data to Ethernet. This was always conceived as an N2K possibility, and has been done since the beginning by MFDs in a proprietary way, but obviously there is yet no standard way to get the data to a variety of apps on a variety of platforms. Maybe this conversation can help a bit (even if I don’t understand half of it).
But the Chetco device and this conversation are not about replacing N2K with Ethernet. I’m pretty sure that there are zero, or close to zero, engines or GPS sensors, or depth or wind sensors, etc. that output Ethernet.
I lived through the disruptive evolutions of NMEA 0183 with gritted teeth, and survived the confusion of transition to N2K. I am not in any way, shape or form going to put up with another change whether its ethernet or jungle drums. No amount of whining is going to change my mind, or NMEA’s either. Manuifacturers are committed too.
All of you pleading with the dark night should get a grip: technical virtues, like BETA VCR’s and Quadraphonic Stereo litter the wayside, orphans of the inertia of commercial consensus.
We have posted a new SeaSmart.Net Protocol Spec at http://www.seasmart.net/SeaSmart.Net_Protocol_RevB_032711.pdf
It now includes a NMEA 0183 Checksum as was requested on this form. It also changes the start tag from $P to $PCDIN, which is a standard NMEA 0183 Propriety Talker so it will now be compatible with other NMEA 0183 equipment.
The input to the web server from the NMEA 2000 protocol translator now looks like
$PCDIN,000000,02,00,0052,0E9E*70
$PCDIN,127250,03,05,0057,0000,F5D8*58
$PCDIN,127251,02,00,FFFD,F85E*70
$PCDIN,127250,03,05,0057,0000,F5D8*58
$PCDIN,130306,02,02,000F,F4C0*0C
$PCDIN,127251,02,00,FFFC,7FFF*08
$PCDIN,127250,03,05,0057,0000,F5D8*58
$PCDIN,127251,02,00,FFFD,FFFF*7E
Which is a little more network friendly and follows the NMEA 0183 standard.
The checksums can now be used at the Browser interface to throw away partial messages. We have tested this with TCP and UDP and it works well with multiple listeners over wired Ethernet through a Switch/HUB or over WiFi.
I think the key point here is that we are offering a bridge to WiFi/Ethernet for NMEA 2000 data. While Engines are indeed not outputting straight Ethernet over Cat5, this does allow engine data to be more easily accessed and viewed.
If I may add a little nitpick: you should not use the checksum field to determine the end of a sentence to, as you say it: “to throw away partial messages”. The checksum field is not always mandatory in NMEA sentences. The only proper way to detect the end of a sentence is to scan for the CR/LF combo at the end. So if you really want to follow the NMEA standard to the detail, you should add a CR and LF to the end of each sentence…. just my 0.02
Thanks for the comments.
Yes, the checksum is optional but we do include the * and checksum now for completness. Hopefully, it will not get stripped off by other devices.
The CR LF does present a problem in POST to CGI sctipts on the Web Server as they denote the end of each parameter in a multipart POST so we can’t really use them there.
They are however, added to the end of the serial stream going into the Web Server (just stripped off before CGI)
One note on the topic, The SeaSmart.Net modules do support both Web Server/HTML viewing and TCP/UDP tunneling at the same time. So, you can be viewing a Live Web Page of data and using our PC Based vDash Instrumentation S/W over Ethernet/WiFi at the same time.
Also, the lower level Actisense RAW NMEA 2000 protocol is also available just like Nobeltec’s solution.
Ok now I am wondering if any new “box” is available to take onboard N2k data and send it out via WiFi for iPad 2 G3? System has Acticense NGW-1 and NGT-1. Do not want to go through a PC just take that N2k data and send it wirelessly to iPad with charting program like iNavX. Anyone have a better solution than using the Brookhouse iMux?
Hello Jeffrey , Yes we do exactly what you request. We populate iNavX wirelessly via iPad. Actually from what I know iNavX requires NMEA0183 data. Our system does proivde N2K data as well as 0183.We use it wirelessly on our iPad every weekend.
We will be showing this technology at the Ft. Lauderdale Boat show Oct 27 to 31 at Booth 3167 Convention center.
Joe will provide more detail for you. He can be reached at [email protected]
The SeaSmart.net WiFi adapter is available with a NMEA 2000 to NMEA 0183 protocol translator that converts NMEA 2000 data into NMEA 0183 before transmitting out over WiFi. This is compatible with iNavX and allows GPS/Nav/AIS/Weather information to be display on the iPad via iNavx and other applications.
It also has a embedded Web Browser for viewing other NMEA 2000 data not available in iNavx using then Safari Browser interface.
Is there a setup guide for getting this to work with inavx? I didn’t see anything at the chetco site.