NMEA Open Source Project

My 2 cents.

Preamble: My feedback below is based on a strong belief that (1) most basic sensors on boats won't be coming in TCP/IP flavors, either hardware or wireless, ever. Forget about it, not happening (2) power consumption is an issue that cannot be avoided (3) the largest groups of uses interested in having mobile access to boat information are sailboats of all types and power boats under 30 feet looking to avoid the cost of an MFD (4) the most common use of mobile data in two years will be the owners smart phone, iApple or Android device, temporarily mounted in the cockpit running three or more applications simultaneously to enhance boating experience (4) Someday most sensors will be available in a flavor of bluetooth where the device receives wired power, but sends/rcv data via lower power bluetooth (5) a dedicated GPS on a boat has compelling advantages over the GPS on portable devices and will not be replaced by the GPS on mobile devices (6) most marinas will have free wi-fi access in two years (7) capability for boats to provide feedback to boat owners (e.g. bilge pump running excessively, low battery, boat security) will be done thru marina wi-fi more than 50%, compared to cell phone based devices (8) two years in the future, most boat owners will get their wi-fi access while underway from smart phones with wireless broadband capabilities, not specialized wi-fi receivers on their boats. (9) Using linksys routers on a boat as a routing hub sounded like a great idea in 2008 but in 2010, not so interesting unless android and andrid marketplace becomes available on a WRT54. (10) if a good open source solution comes about cheap, most marine vendors will offer applications to configure and load software upgrades to their products, instead of PC's, on Android and iApple products instead.

And with that pre-amble …

My feedback: (1) Open source project should be focused on getting boat telemetry over bluetooth, not wi-fi, to iApple and Android based phones and tablets. (2) The ideal bridge from nmea and seatalk protocols would be a low powered product that is a 2-way bridge to low powered Bluetooth, that can use so little power that a boat sitting at a mooring 4 weeks unused would have less than 50 Amp Hrs power used (3) The ideal platform for running apps on a boat (rather than a linksys) is a iApple or Android product without a data plan (e.g. our old iApples and Android devices as either us or our children discarded our previous generation devices every 2 years) using bluetooth to connect to mobile clients on the boat, and a mostly off wi-fi capability that turns on briefly to transmit boat telemetry via wi-fi ashore when our boats are not in use, (4) a dedicated gateway should not be required, the same function should be support thru the owner temporarily lending their smart phone each time they use the boat (5) such a platform can serve a duel role of bridging 0183 / 2000 / seatalk (6) an open source project needs to focus on how we can have a single mobile client with full capabilities (configure marine products, upload new software upgrades to marine products and multiple mobile clients with read-only capabilities such that multiple applications on such clients can be running at the same time from a single stream of data (e.g. all applications on the device can get gps, boat speed, etc.) and generically offer boat telemetry to third party applications that can allow users to build their own dashboards to display data. (7) The exclusion of radar, video (cameras), and other wired Ethernet type data on our boats in the solution is not a problem. (8) efforts such as being able to configure and software upgrade NMEA-2000 devices on the boat network would be greatly enhanced by an NMEA-2000 standard for (i) sending software upgrades end to end from a mobile device thru a gateway and to a device supporting a new standard for such & (ii) reading/writing configuration data from a mobile device thru a gateway such that the gateway need not be aware of the structure of the configuration data.

If anyone is architecting such a solution now, I would be interested in participating.

Kenyon,

Its good to hear that there are more people out there who want open hardware and software as part of their instrument systems. I've been working on my own for a little while now and would love to have more people involved.

I think maybe the first thing to do would be to get a wiki set up. It would be a better way to collect and organize ideas than the forums. I was planning on doing that for my project anyhow. I would have no problem expanding the scope of my project a bit to encompass other ideas like network support.

My thoughts on your questions:

1) To get N2k data onto an IP network I would probably use the Actisense NGW-1 and a little microcontroller. The NGW-1 converts to NMEA 0813 and the uC could send UDP broadcasts of the NMEA 0813 messages. Of course the problem with this is that N2k messages that have no 0813 equivalent would get lost. A better solution would be to use the Actisense NGT-1-ISO, but I can't find anyone who sells that, just the NGT-1-USB.

2) On the receiving hardware Kee's packetlogger would be a good start, if he'd be willing to release the source code. That would save a considerable amount of time and effort. I do hate reinventing wheels.

I've got both the Lawicel CANUSB and the Actisense NGT-1 and both work well on x86 Linux. I haven't had much luck getting them to work on an ARM platform, but I've got a pretty old kernel there, so that could be part of the problem.

The Simrad NSO system might make a good platform for development. It's x86 hardware and runs Slackware Linux. I just wish I could afford $4k to buy the processor and play with it.

There are a lot of open source programs that can display charts and read GPS data from a NMEA0813 source.

I've also just built an IP65 computer. Total cost was about $500. About half of that was the ARMv4 SBC (Technologic TS-7300). The other half was round connectors.

3) I'm not sure that Ethernet is really warranted for moving N2k data around. It's already got its own bus and reading that isn't so hard that we should be trying to convert it. I woud have one central computer that received the all of the shipboard sensor data, from whatever kind of bus it was on. It would do all of the necessary processing and calculate datapoints that can't be measured like true wind speed and current set. It would also store all of the chart data, multimedia files, data logs, and whatever else needs storing. Other computers would just be remote displays using VNC or X. A 1GHz ARM Cortex system like the BeagleBoard-MX would be ideal for this. It would be more than powerful enough.

~Tim

Bluetooth, Dan?

Sorry, I have hard time picturing that. Where do you get the idea that "Someday most sensors will be available in a flavor of bluetooth where the device receives wired power, but sends/rcv data via lower power bluetooth"? Is there even one such marine sensor in development?

I also don't see how Bluetooth works as a niche protocol for iOS and Android apps. Heck, I've yet to get my Stowaway "Universal" BT keyboard to work with either my iPhone or Droid Incredible. The wireless device has to have the right drivers and it doesn't seem like third party developers can create them easily. I see very few apps in either the iTunes or Android app stores that do much with Bluetooth. Am I missing something here?

It seems that the Digital Yacht iAIS uses a Wifly GTX WiFi module:

http://www.rovingnetworks.com/wifly-gsx.php

Could this, or one of its siblings, and the Actisense NGT-1 technology be combined to get the N2K-to-WiFi job done? Is Actisense itself considering such a product?

Some great stuff so far. I meant to add my comments on the questions last night, but did not get to it.

1) Obviously, the need for Multicasting N2K data on an IP network is there which is the perfect place for a UDP server. For communicating back to the N2K network, TCP offers better reliability. This also separates the functionality into separate components that can live on the same device and provide some isolation for stability. Power is obviously a concern, but the hardware needed to accomplish this would be pretty low power.

2) There were some comments from people on the blog post that have a serial server working. Mark mentioned the Lantronix Wibox and I know others have mentioned the Digi products. It sounds like people have these working with 0183, but not N2K. It sounds like we need to get our hands on an ISO version of the Actisense NGT-1. If this solution works, it would at least provide a interim solution to start developing apps with. It would be nice to have 1 device instead of 2 of course. Ben, would you be able to reach out to a vendor like Actisense and see if an N2K-TCP TPG product is even on their radar?

3) I guess this is the most pressing issue since we still don't have a clear solution to this problem which is the current bottleneck. It's definitely not the most sexy or fun product to work on.

I will ping the guys who say that current products are working for them and get some details. We can start a Wiki like Tim suggested and provide results and directions if we have some success.

Kenyon

Ben,
That module looks like it could provide what we need as do some of the others that are mentioned. The question that maybe you could answer is why are DY, Furuno and others producing new products with NMEA 0183? Is it a cost thing? I know N2K development is expensive because of the membership, documentation, and certification costs, but It shouldn't be a big issue for a company like Furuno who is already producing N2K products. I just don't get it.

Kenyon

Dan,
I have to agree with Ben, I have no idea where Bluetooth fits into this. It has it's place, but it has inherent issues for this type of solution. WiFi, Ethernet, and CANBus will easily accomplish everything we need to do.

I agree that a standard for updating and configuring N2K devices would be nice. It seems like we are still stuck buying an instrument or MFD from the same manufacturer as many transducers just to be able to configure them.

Kenyon

Tacktick’s depth and boat speed sensors are examples of sensors that get wired power, where as the data is transmitted via bluetooth. This year TackTick has an option for a powered instrument display (rather than solar) that receives data bluetooth. I have no doubt there are web-sites that can tell you how to listen in on TackTick data on your smartphone via Bluetooth

(edit: I found such a site quickly, looks like you can transmit NMEA-0183 data to TackTick as well, neat !) http://www.sailclever.com/taktic.php

While Tacktick is a handy example to defend the beliefs I stated in my prior post, my beliefs are actually formed instead from my experiences in telecommuncations, as owner of a telecommunications software company, as an investor in an Android application, and as an alumni of StonyBrook University where I am on the Deans’ Council and exposed bi-annually to research projects that involve sensor networks for collecting environmental information and acting upon it.

Bluetooth has improved rapidly in how devices mate to each other (a source of consumer pain), has reduced power needs vs. wi-fi, has a limited range that fits nicely within the size of most boats, plays better / is less apt to step on signal on boats near each other than wi-fi would, and is supported by smart phones. We do need a way for multiple applications on a smart phone to share the same bluetooth radio and in doing so establish how they play nice together, what format the data is in (N2K PGN’s ? XML modeled on 0183 ? Other ?), how multiple sources of bluetooth data are combined and delivered to those applications, how applications can transmit data to other applications in the smartphone only, and how applications can trasmit data back out to boat systems including allowing for configuration and uploads of new software versions an iApple or Android has obtained from the sensor vendors. That seems to be a worthy focus of an open standards effort. Once such a standard exists, it would open the doors to a lot of really nifty smartphone applications, plus those applications could have a two-way connection to our boats which could lead to our powered and sunlight viewable instrument displays being at the command of our smartphone applications instead of those applications being handicapped to sunlight un-viewable displays to tiny to share between crew members on a boat. (I also have visions of marine instrument displays being replaced by future stock iApple and Android devices that are sunlight viewable.)

Something I would like to see an open standards group tackle up front, is the combining of alarms. It would be ideal if any application developers application had the option of silencing their own alarms, and forwarding to a single alarm application and ultimatly to a single instrument display or instrument display window on our boats. I already would like a single place to receive, filter, display, make noise, and silence alarms among the devices I have on my boat, without adding Android and iApple applications that could add Anchor Alarms, depth alarms based on cartography, speed alarms based on sailboat target speeds, count down timers, and more.

Something I think all manufactures would like, is a path towards retiring all the PC software that has been created to configure products over NMEA-2000. Smartphone applications are so much cheaper to create, distribute, and update. Such a path would need to allow application developers to have full access to their N2K wired devices including all proprietary PGN’s, so the Android/Apple smartphones can allow users to configure their devices and upload software upgrades without bridges/gateways/etc. filtering proprietary PGN’s.

Dan, I don't think Tacktick uses Bluetooth. The software product you found uses a Bluetooth dongle that wires to the Tacktick server NMEA 0183 ports:

http://www.sailclever.com/racer_overview.php

If Tacktick really did use Bluetooth and it was easy to get Bluetooth data to iThing and Android apps, that would be neat, and I imagine there would be many apps that would make good use of it. But I don't think either is true.

Remember, too, that ShipModul has for years made a NMEA 0183 multiplexer that also outputs Bluetooth. But I don't know of any wireless apps except maybe Windows Mobile ones like Sailclever that can use the output. Do you?

http://www.shipmodul.com/en/miniplex-2bt.html

Yes, your right, I see my error with sailclever.

I am going to follow-up on the bluetooth. It's been determined in other sensor applications to be a much better fit than wi-fi.

I suspect that the NGT-1-USB and NGT-1-ISO are basically the same board. Although it would be nice to get the ISO version, it's not necessary. If we need to interface the NGT-1 to another microcontroller, the TTL level serial lines are pins 63 and 64 of it's ARM uC. Also, Actisense was nice enough to break out the JTAG pins for the ARM chip. Could be useful.

What were you referring to in 3) as the the most pressing issue?

Hey Tim,
i was just referring to getting the N2K data onto the IP network.

I just bought a Seagate Dockstar that I have hacked and is running OpenWRT. It's got a 1.2Mhz ARM CPU w/128MB of RAM, 512MB flash, a 4 USB ports and 1 Gigabit Ethernet port and consumes 8w. I got it at Fry's for $25, so it's a nice cheap fairly hackable little piece of hardware. I am going to try my Keyspan serial adapter with my Garmin GPS. It's only NMEA 0183, but I just want to see if I can get it connected and get some data. If I crack it open, there are pins for a serial port, but I'm not sure if it's actually RS-232 or just for a serial console. Anyway, should be fun to play with.

It would be interesting to find out what is running in the Actisense unit and how hackable it is.

Kenyon

Open Skipper - Open Source NMEA 0183/2000/AIS

It's great to see all this discussion of open source NMEA 0183 and NMEA 2000 software. We have been developing Open Skipper (http://www.openskipper.com) with the aim of decoding, displaying translating and forwarding NMEA 0183 and N2k messages. The software is still very much under development, but provides features such as:
- input of 0183 messages via a serial port
- input of N2k messages via the Actisense N2k-USB unit
- decoding and real time display of 0183, N2k and AIS data
- receiving and forwarding of 0183, N2k and AIS messages via TCP and UDP, including broadcasting
- a protocol for sending N2k messages over an 0183 stream
- generation of (very simple) dynamic web output for viewing via a browser (such as on a smart phone)
- an editor to add/edit new N2k/0183/AIS messages which are defined by XML files
- import of Kees XML N2k files (but this needs updating for his latest format)
- logging and replay via text files

Open Skipper is written in C#, and should run in Mono, making it work under Linux. It is licensed under the GPL.

I had not thought of running in a wireless router, but that is an interesting idea. Running on an Android would also be good.

Open Skipper is available on Sourceforge via http://www.openskipper.com Hopefully bits or all of this will be useful. All feedback is most welcome.

Andrew

Kenyon, I did query Actisense and was glad to hear that a NMEA 2000 to TCP/IP product is on their list. At the top, actually, though no time frame was mentioned. Could take a while, but could be a winner.

I've started to explain my reasoning on what I've developed for myself (and am still considering to productize) over on my own blog:

http://yachtelectronics.blogspot.com/search/label/canboat

In short, I think you should not need to install apps on mobile clients.
This leads you in the direction of web applications. These can still be made to function as a real app on iOS.
Web applications cannot use UDP, only TCP. They like JSON. So I chose JSON as the data transfer format.

Andrew,
Great to hear what you have been working on. I was originally planning on doing something similar, I wanted to build a configurable dashboard for N2K instrument data. I will take a look and try to run it under Mono on a Mac. I might also see how well it would port to Java which would make it easier to get onto an Android device. I like the JSON idea, a HTML5/AJAX application is one thing I would look as well.

cheers,
Kenyon

I agree kees, I like that direction.

I am confused about the thought of not needing to install apps on mobile clients / going in the direction of web applications.

1) Are you talking a path that excludes the good iOS and Android apps that are already out there, that could benefit from the addition of sensor data from our boats? E.g. a race application that has to settle for SOG, because it cannot get STW/SOW from the boat; an anchor alarm application that cannot get GPS lat/long except from the smartphone the user is walking around the boat with which has no fixed relationship to the bow; etc. ?

2) No matter the architectual benefit of making each of the applications web like, there would be a much wider audience of potential software buyer's for any given developer's application, if the apps are simply downloaded to smartphones via the various application markets as they are now.

3) Have you given some thought, as part of an open source project, to provide an application that is downloaded to each smartphone (free?) that provides a standard way for any application developer to access nmea data as if it's already on the phone, e.g. not caring about how it is sent and received ?

Ben, it's good to hear that Actisense, who I consider the most forward-looking and standards-seeking of the hardware vendors, is thinking about N2K->TCP/IP. However, I hope that before they spend engineering resources on that project they finish the NGW-1 translations, particularly AIS and DSC. They've been "coming soon" for quite some time now.

Dan,

I happen to think my main arguments are pretty compelling. An anchor alarm app on an iOS or Android device is just silly -- it will run your battery down pretty quickly and might fail at inopportune moments.

You ask:
Are you talking a path that excludes the good iOS and Android apps that are already out there, that could benefit from the addition of sensor data from our boats?
No, once you have data you can put this out in various forms. One does not preclude the other. In fact putting out NMEA 2000 data in JSON form on UDP packets is a question of about 10 lines of code on top of my freely available packetlogger program, as that can already produce JSON.

No matter the architectual benefit of making each of the applications web like, there would be a much wider audience of potential software buyer's for any given developer's application, if the apps are simply downloaded to smartphones via the various application markets as they are now.
That may be true, but I don't want those apps myself and think they are too much work to develop for my own use. That's why I am putting my money (=effort) where my mouth is and have developed what I do want in the time that I did have.

Have you given some thought, as part of an open source project, to provide an application that is downloaded to each smartphone (free?) that provides a standard way for any application developer to access nmea data as if it's already on the phone, e.g. not caring about how it is sent and received ?
I don't see the advantage that this provides beyond agreeing on a standard network protocol. Accessing network data is a minor obstacle, integrating a 3rd party library is usually more work (assuming the protocol is well designed.) There are many more examples of succesful open network protocols (IP, TCP, HTTP, SMTP, SSL) than cross-platform open libraries...

But, once the protocol is a published work then everyone is, of course, free to provide such a library.

Dan,

Here's a few lines of PHP to prove my point on that once you've got the data writing it to a network can be simple.

Building on my Actisense reader and packetlogger software all you need to write out packets of NMEA 2000 sourced data encapsulated as JSON on Ethernet via UDP is (error handling removed, but the below code does work):

<?php
$stream = popen('/usr/local/bin/actisense-serial /dev/actisense | /usr/local/bin/analyzer -json', 'r');
$sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_set_option($sock, SOL_SOCKET, SO_BROADCAST, 1);
while (!feof($stream))
{
  $packet = rtrim(fgets($stream, 4000));
  socket_sendto($sock, $packet, strlen($packet), 0, "255.255.255.255", 1138);
}
?>

Kees

1) You wrote "An anchor alarm app on an iOS or Android device is just silly -- it will run your battery down pretty quickly and might fail at inopportune moments." -- In defense of all the silly anchor alarm apps ...
- you can place the alarm near your pillow, and for that matter your smartphone charger. (using a DC charger of course)
- The writer of such applications have a wide audience for the application under iOS & Android. If they build in an option to use lat/long information via your efforts, then the anchor alarm is optionally better in those circumstances where someone has access to your good work, and need not be converted to a web application.

2) Did you have any comments about an early comment I made about centralizing alarms ? If you have some thoughts about it, I would contribute some effort to expanding upon the idea and a potential JSON data format.

Glad to see this thread take off !

Dan, forgive me but your last question suggests you don't have experience developing applications for Android and iOS, and I wanted to clarify.

You wrote: "Have you given some thought...to provide an application that is downloaded to each smartphone ...that provides a standard way for any application developer to access nmea data as if it's already on the phone...?"

Software like what you describe would not likely be an app as such, it would be an API (see below).

(While it is possible to write, say, an application that consumes NMEA data from the network and then rebroadcasts it from the phone via TCP/IP [in which case other apps on the phone could access said data], this would be redundant.)

What Kees is describing is a standard way of accessing NMEA data published via a Web server over HTTP (either in the clear on port 80 or encrypted on port 443). JSON data is extremely simple (in fact it's human-readable), so virtually any programmer, working on any platform, mobile or otherwise, could utilize such data in their own app. No additional libraries would need to be provided.

When you talk about code "that provides a standard way for any application developer to access nmea data as if it's already on the phone", you're describing an API (application programming interface) for NMEA data that handles the network access. APIs are not downloaded by end users; they're incorporated by developers into applications. As Kees says, with NMEA data accessible over HTTP from a small server, there is nothing stopping someone from writing an API for Android, iOS, or other platform. I agree with him that due to the simplicity of JSON this probably isn't necessary, but there could be some value in an API that handles network issues, such as slowdowns or brownouts, in an elegant way. For example, an API could provide standardized warning codes to a developer in the event that the NMEA data server was unreachable. Such codes would allow an application to let the user know of connection problems (perhaps your phone is too far away from your onboard wifi access point). Of course app developers could write this stuff themselves; there don't seem to be a lot of standard use cases that would mandate the development of an API.

If I misunderstood your question please accept my apologies.

/afb

Dan,

You wrote about alarms. One of the great advantages of running a server based solution is that everything runs through it. So if we went that way you can still have clients, but they would need to upload any alarms they raise to the server. They are still allowed to raise their own alarm, but if the server tells them the alarm situation has been confirmed then they'd need to stop raising the alarm.

The server can raise additional warning utilities such as warning other interested applications, and fire up the big siren as well.

At the next level it can also send an SMS text message if I'm not on-board. So if the alarm is "bilge running > 5 minutes" I would be aware of it, and could call in help or race to the boat.

Kees

You wrote "There are many more examples of succesful open network protocols (IP, TCP, HTTP, SMTP, SSL) than cross-platform open libraries..." .. good point !

just my tuppence

Bluetooth) I just cant see a future for that in boat sensors, ifs there is going to be a wireless future and no doubt there is , it will be wifi.

SMartphones) I remain dubious that any sailor will every rely on smartphones ( I use it in its generic sense), as a primary display device, especially as ubiquity and competition means that cost concerns drives down reliability to alomost throwaway status ( witness later Nokias).

Rugged tablets will no doubt be popular, I dont for a moment believe that Apple has this market. The Windoze/Linuz makes are getting up to speed. We'll see( its early days, remember the LISA). As to Android , it remains to be seen ( this could turn into a VHS betamax debacle).

SO N2k into IP, great ( being myeself no fan of N2K), bradcat over wireless great, like the idead of it in a router, rock on.

Dave

just my tuppence

Bluetooth) I just cant see a future for that in boat sensors, ifs there is going to be a wireless future and no doubt there is , it will be wifi.

SMartphones) I remain dubious that any sailor will every rely on smartphones ( I use it in its generic sense), as a primary display device, especially as ubiquity and competition means that cost concerns drives down reliability to alomost throwaway status ( witness later Nokias).

Rugged tablets will no doubt be popular, I dont for a moment believe that Apple has this market. The Windoze/Linuz makes are getting up to speed. We'll see( its early days, remember the LISA). As to Android , it remains to be seen ( this could turn into a VHS betamax debacle).

SO N2k into IP, great ( being myeself no fan of N2K), bradcat over wireless great, like the idead of it in a router, rock on.

Dave

On a tangent back to Bluetooth: I'm surprised that nobody has mentioned Zigbee or IEEE 802.15.4. That's the technology underlying recent marine hardware such as Raymarine's MOB detection hardware.

Quoting from Wikipedia:
Because ZigBee can activate (go from sleep to active mode) in 15 msec or less, the latency can be very low and devices can be very responsive — particularly compared to Bluetooth wake-up delays, which are typically around three seconds. [3] Because ZigBees can sleep most of the time, average power consumption can be very low, resulting in long battery life.

I think it is highly likely that TackTick uses a variation on 802.15.4. Inventing silicon is not economical for such niches as marine electronics.

The interesting thing about Zigbee is that it already has a Home Automation profile. It's most common transfer speed is 250 kBit/s which meshes nicely with N2K.

Still, it is my belief that it will take more than just hardware ubiquity before this takes off in a big way. Bluetooth is very much an existing standard but as Ben said getting it to work is still a pain. That's because the 'profiles' aren't all there or not compatible enough. Bluetooth headsets have gone from unusable for mortals to working very well, just because manufacturers have ironed out the kinks. Wireless on boats (beyond Wifi) will probably sneak in slowly, for instance when one of the big manufacturers starts emulating Tacktick and brings out a wind vane sensor that doesn't require wires.

Zigbee may not be so attractive as new versions of Bluetooth use so little energy that in some applications it's expected that a coin size battery will last a year. See wikipedia http://en.wikipedia.org/wiki/Bluetooth

In regards to TackTick, this article was published in Sailing World and quotes Clive Johnson, a managing director and founders of Tacktick about their "secret" wireless protocol.

http://www.sailingworld.com/gear/race-electronics-go-wireless

"They’ve since developed their own communication protocol, which is similar to the most commonly used wireless protocols-Bluetooth and 802.11b (see box)-but uses less power and takes up a smaller amount of bandwidth. "Our bandwidth is secret but allows you to have faster data transmission than any other system on the market," says Clive. "It’s very quick and very able to transmit what we’re doing and gives us plenty of room for expansion."

A representative at the Anapolis boat show shared thta a version of the Suunto watch is on the way to display TackTick information.

Nexus has a wireless windvane: http://www.nexusmarine.se/templates/Products____31.aspx?epslanguage=EN&productId={BEE55D28-0652-4A2D-BBD7-9455FC9945FE} Solar powered with battery backup, so TackTick aren't the only game in town.

I think both Bluetooth and Zibgee have applications in shipboard wireless communications. They're not they only 2.4GHz options though, just the most popular. TackTick's "secret" is likely nothing more than they used silicon that hasn't found a home in the PC market. The Nordic Semi chips come to mind.

Sparkfun Electronics has a nice Bluetooth serial module: http://www.sparkfun.com/commerce/product_info.php?products_id=8497. At full power, it uses 0.1W of power, about the same as two standard red LEDs. When paired with a computer or tablet it shows up as a standard serial port. They have a pretty good selection of Bluetooth and Zigbee modules (and tons of other stuff too).

Zigbee radios (at least the more powerful 60mW ones) typically have a bit longer range than Bluetooth (about 1 mile). They could be quite useful when communicating data between boats. For instance, data exchange between a race boat and coach boat or two sailboats doing instrument calibration. This is way better than the alternatives (WiFi, packet radio) I think.

I'm still a fan of wired communications between sensors and computer. I like wires; wires are cheap, wires are easy to understand, and wires work well in electrically noisy environments. Of course wires corrode, wires break, and wires aren't necessarily convenient to install.

So in my opinion, wires win for sensors, WiFi or wired Ethernet is the right choice for higher-bandwidth applications, Bluetooth for low-power communications with hand-held devices, and Zigbee for medium-range communications between boats.

Also, as I mentioned in an earlier post, I had intended to set up a Wiki to document the instrument system I've been working on. It's online now at http://wiki.openseasproject.org. There's not much there at present, but I'm taking submissions. :)

PS. Anybody here going to the Annapolis Boat Show in October (either sail or power)?

I'm building an embedded NMEA2000 test environment to begin playing with the messages. Entry for the CAN bus is relatively simple and cheap these days, it's a big standard and used everywhere.

Biggest issue are the NMEA2000 PGNs. Each message can have different types for each of the items it contains, defined by Appendix B of the NMEA2000 spec. The common ones would be pretty easy to establish, and that's mainly what we're worried about.

IP as a transport makes sense for communicating with MFDs, but not with the individual sensors/etc. In an ideal world, IMHO, ethernet would handle radar, sonar, etc, and a node would pass NMEA2000 information to/from the network. This way, each chartplotter would be connected with only a single ethernet connection, and NMEA devices would remain small and cheap. (Ethernet is substantially more expensive, and, unnecessary for small sensors/etc.)

Getting the raw data onto IP is easy as pie. I'm working on a device which, for $75, will put all NMEA2000 data onto the USB bus, and even allow writing to the bus, for analysis/etc. For $200, you get a version with ethernet, logging to SD cards, etc.

My goal for this winter is to finish things to the point where there is a working software stack allowing anyone to create NMEA2000 devices with ease.

Patrick,

Your project sounds most interesting. In the interests of not reinventing the wheel, please note that Open Skipper contains a C# NMEA 2000 decoder that is driven by an XML PGN definition file. Kees has made good progress in extending the range of PGNs we can now decode.

I assume you'll be coding in C, or maybe C++? It would be great if your code could also be driven by the same XML definition file that the community shares and updates.

Open Skipper can send/receive NMEA 2000 messages over TCP and UDP in a variety of formats, including as NMEA 0183 messages (which makes mixing 0183 and N2k data streams easy); see https://sourceforge.net/apps/mediawiki/openskipper/ It would be great if your N2k->IP device spoke one of these formats (or another that the community agreed upon).

You may wish to make your N2k->USB device Actisense compatible; their data format is a sensible one (and one that we partially document).

We started off using a standard CAN device, but it was not ideal at sending N2k Fast Packets, which seems to me to be the tricky thing about NMEA 2000. My thoughts are that these messages need to be sent to the device as a single long message that is then broken up and transmitted by the device. Is this your intention? It seems to be what Actisense do, and is probably the only feasible option to meet timing requirements.

Cheers, Andrew

Note that sending N2K onto a bus is really something that you'd want to be very careful of. A crackpot N2K sender could easily dominate the bus by sending out PGNs as fast as it can at the highest priority allowed. Like any bus, the system depends for its wellbeing on there only being well-behaved participants.

One of the things that the Actisense NGT-1 does is keep track of PGNs that it sends out, so as not to send out data more often than allowed. This is why I'm personally using the NGT-1 now. It takes care of all lower levels of the N2K software stack as well as the hardware interface. On the downside, it is why it is necessary that the firmware on the NGT-1 knows about the PGNs that you want to send, and why it only allows a limited number of PGNs to be sent (as its memory is limited.)

Patrick writes:

Biggest issue are the NMEA2000 PGNs. Each message can have different types for each of the items it contains, defined by Appendix B of the NMEA2000 spec. The common ones would be pretty easy to establish, and that's mainly what we're worried about.

As far as I know I've got all standard PGNs for standard sensors (GPS, AIS, depth, speed, wind) completely covered now.

The outlierssuch as AC data, DC data, engine data etc. are less covered because not a lot of people seem to have those on their N2K network yet.

If you have such a device installed, please do some analysis yourself and help the community. So far, the analysis community consists of one (1) person.

Engine data is my #1 priority actually. I do have a couple NoLand RS11's here which can send the test data to analyze, and I'd be happy to send anyone a stream once my CAN transceiver chip gets here.

I'll check out OpenSkipper, that XML file sounds like exactly what I've been looking for. Is there a better forum to discuss this? Is that something I should create?

Kees:

I sent you some captures from packetlogger, did you get those?

I've also have some pretty good CAN analysis tools at my disposal. Where I work, we do a lot of embedded development and all of our hardware uses CANbus. Vector CANalyzer is rather good at deciphering CAN packets.

Patrick:

I have a google group to go along with the wiki I mentioned earlier: http://groups.google.com/group/openseas-project

Hi Tim,

Sorry i didn't confirm your mail with log files -- I received it but haven't looked at them yet but I don't expect to see any surprises as they are from equipment that I've got covered pretty well.

Patrick, you can find the XML file with PGN explanations on my website, http://www.keversoft.com/Keversoft/Packetlogger.html -- as Andrew explained I've added XML export of the n2k definitions so that openskipper can understand them. Note that my latest XML explanation files have a new field that explains if and if so, how many, terminating fields repeat in the PGN. Openskipper does not yet accept this new format. It was necessary because my analysis showed that there are pgns that have fields that repeat fifty odd times, and that made the old format that just kept on naming fields too unwieldy.

Once you've got your hardware set up you can use it (packet logger) to analyze the engine PGNs and check whether I've guessed the field lengths and datatypes properly. I know that rpm is ok, rest I just don't know. Without access to the should-be values it is hard to interpret PGNs from log files. You can use your own code to generate raw files for consumption of the analyzer or use my actisense or lawicel reader programs. You can check out the raw PGN formats that the analyzer understands on my blog at http://yachtelectronics.bloodspot.com .

Sorry I haven't recorded any log files yet, Kees, been a busy week. But I'll try tomorrow. By the way, I think you mean http://yachtelectronics.blogspot.com/ unless you're going to the dark side ;-)

Kees: No worries, I figured you probably had those PGNs already covered, but more info never hurt. I've also got a Garmin 5212 that sends out a few messages. Any interest in what it has to say?

And finally, I'm borrowing a CANcase and CANalyzer (https://www.vector.com)from work for the weekend, so if you've got any PGNs whose format you're not sure about, I can get you the answer.

I have a NoLand RS11 that someone can borrow (no logger) I believe it sends engine dynamic & rapid update messages... Would be good to have.

Kenyon,
I've been "lurking" on this conversation, hoping for some consensus to arise around a specific project for getting system information from (and potentially to) a boat.

Here is my interpretation of the conversation sofar
(1) All of us are looking for a common, standard way to communicate with the proprietary NMEA standards, 0183 and 2000 as they are used in the market place by a wide range of suppliers.
(2) Some are looking to monitor (and potentially control) things locally via phone, computer, iPad etc.
(3) Some (myself included) are looking to monitor boat information remotely for the purpose of location acquisition or security.

I very much respect to efforts by Andrew ( http://openskipper.com ) and Kees( http://yachtelectronics.blogspot.com ) but including a user interface to suit lots of applications and devices is a large ask.

I personally like the way the http://gpsd.berlios.de/ project has done a good job of the dirty work to properly interface GPS (which is harder than it might appear) They might give us a role model (or even a partner to assist - they will no doubt have to consider N2k too).

Creating a well defined intermediate protocol (probably json over tcp/ip) will enable lots of innovation for both on-board and remote applications.

Such a protocol might end up in a low cost "black box", connected to the boat's internet connection or be installed as a driver on an on-board router, or as a dedicated device with its own sensors and cellular internet access.

Plenty of options, but it would be good to see some common ground. Do we continue that discussion here?

Hi,

I am on the same path as Marius. I acctually ended also to the gpsd pages, but I am not after only the GPS related sentences.

I am looking a open source project to build a small black-box linux box that can:
- intepret in my case just the 0183 NMEA sentences from serial interface but of cource NMEA 2000 would be nice addition
- have small web server for web apps to utilise that NMEA data
- to provide WIFI hotspot where you can point your iPhone or equivivalent.

I have mix of Raymarine and tacktick instruments on my boat and I have been thinking to build sailing tactics type of web application presenting wind shift information and laylines, etc.

It would be nice to have someting sailing related stuff under development during the long winter.

-Harri

I am not sure if this is a useful contribution to this discussion, but if not, apologies for posting it here and ignore it further. But as far as I understand, this discussion is a.o. about getting N2K data on Ethernet and therefore this posting may be relevant to somebody.

If for any reason you need to get N2K data out on the Ethernet, Sailsoft has a simpel and free utility that can do that, in collaboration with the Actisense NGW-1. The utility is called IpaNema, and reads data from any PC serial port and puts it out in the form of UDP packets on your Ethernet network.
You simply connect the NGW-1 to the N2K bus and point IpaNema to the serial port side of the NGW-1. The NGW-1 converts the N2K PGN's to NMEA-0183 and IpaNema is putting the NMEA data out on the Ethernet. Ports and IP addresses are fully configurable.

I tried this also with the NGT-1, so directly sending N2K PGN's over the Ethernet and that works also, but because of the used baud rate (115200) IpaNema breaks because of buffer overruns. Remember, IpaNema was originally written for standard NMEA-0183 and has only been tested with 4800 baud.

If anyone is interested in this solution I can of course correct the buffer overrun issue so that much higher speeds (and the NGT-1) will work. Just let me know.

AIS will also be supported by Actisense within short. I have already succesfully been running some tests with the NGW-1 AIS supporting beta firmware.

The current version of IpaNema can be downloaded here http://www.sailsoft.nl/downloads.html.

/Ger

I'm a bit confused by something. To read the NMEA packets you need to buy appendix B, which costs $900. Does the open skipper have this in the XML file or do I still need to spend the $900

Harri: Open Skipper is written in C#, and so should run under Mono on a Linux box. It can receive 0183 and N2k data, and act as a web server to feed that data out over a wireless connection. The web server currently delivers just 4 user-selectable values (eg speed, depth, etc), but this is something we want to expand so that the web pages look as good as Kees' displays. Data can also be forwarded over TCP or UDP. Kenyon (see above) is looking at running Open Skipper undrr Mono; he might let us know how this is going? Andrew

David: Yes, Open Skipper has this file built in, and can load new updated files provided by Kees or generated using Open Skipper's editor. This N2k Definition XML file contains definitions for those N2k messages that Kees has been able to explore and understand. He's done a great job, but not all of the definitions are finished, so some of the messages your instruments send out may be ignored by Open Skipper. Note that Open Skipper doesn't yet read Kees' latest files as their format has changed. Hope this helps, and saves you $900! Andrew.

I should make it clear that Open Skipper has not received any official NMEA information, and we have never seen 'Appendix B'. We have not signed any non-disclosure or confidentiality agreements. The XML N2k Definition file is completely un-official and based on Kees' work. Andrew

I've just posted another update to my N2K analyzer program.

The non-proprietary PGNs should all decode correctly now. If not it's a bug :-)

For more information see today's blog entry.

On my twin DD "Sea Dream" I use a product from this company Chetco Digital www.chetcodigital.com. It is the first truely wireless NMEA 2000 package I have seen. My associate has a 110ft in Lauderdale in which he has 4 of these SeaGuage systems installed. I mounted their SeaGauge Remote box with NMEA 2000 converter in my engine compartment.Their "Black box" allows for 16 analog senders to be wired directly into the box using existing wires from VDO senders, 2 SSI Fuel senders tied to the terminal strips in the box. I purchased the wi-fi module and also their 300 meter bluetooth module.(yes 300 meter) I (with a little help from my computer buddy in exchange for a tuna trip) wired it up and it works great. They give free software that allows me to choose from up to 16 readings from the analog senders or ANY NMEA 2000 or 0183 data on the network. Design my own screen layout and choose the viewing format.ALSO THE BEST PART IS I CAN DATA LOG MY ENGINE PERFORMANCE.
Since I have access to all the data on the network it has allowed me to display most of the data coming the NMEA devices and now in addition I added all the analog data from my 1996 DD's. I can view all engine data over the internet from home, like fuel level, bilge levels, battery status. They also allow me to view my Airmar weather station data before I get to the dock.
Once on board I can fire up the bluetooth and display all the data on my computer screen in the helm, a computer screen in the fly bridge, my laptop anywhere else onboard.
I have used the data logging feature to improve my engine performance.
Lastly I am now able to use the gauge display features of my garmin chart plotter.
This "box" does more for the $2000 investment then any of the products 10x that price come close to doing.
This system is very flexible and could be what you are thinking about for the group. Their tech support is pretty competent and easy to reach.

I hope this helps. It helped me and for on a couple grand well worth the research.

about for the group. Their tech support is pretty competent and easy to reach.[url=http://www.uggspeichernboots.com/]ugg boots knit[/url]

I have spent the last hour reading through this thread and jumping to the 6-7 web sites mentioned. I am very interesting in an open source project and perhaps helping provide data captures for AC power, DC power, engine, weather instruments. I have Maretron and Airmar sensors with Actisense and Maretron USB devices.

I was looking around the Panbo site because I have been working on two applications - an anchor alarm that I can configure to match my boat (distance from the bow to the Airmar GPS, etc) and a mileage log interface to my OneNote daily helm log.

Regards,

There is a company Chetco Digital that uses Actisense chip on thier SeaGuage remote system. I have one and it is slick. (www.seagauge.com). Web Site is a little weak but the sales person I spoke to was quite up to date and knew the stuff inside and out.
The box mounts in the engine compartment with the built in NMEA2k adaptor built in. I wired all my analog senders, Airmar weather inputs and GPS 0183 feeds into the terminal strips. It converts all this to NMEA2000 and makes any of the data avaible over teh NMEA2000 network. My Garmin 5200 is displaying the analog data, my SeaGauge display screen is showing 3 tachs (2 engines and my generator),GPS location, GPS Speed, 3 fuel tanks levels using SSI ultrasonic senders, amps, volts, egt amd oil pressure. Also allows me to have 12 indicator alarms. This is 15 gauges and 12 indicators. It has USB, Serial and NMEA output and input.With the USB I am able to connect to my laptop and data log the analog inputs to review later on the free software they supply. I also added the wireless NMEA 2000 module which allowed me to see the gauges via wi-fi on iphone(android also but traded that in for the iPhone). The wireless NMEA2000 is slick stuff. I can take my laptop anywhere on my vessel and see my NMEA data. I keep reading this blog and honestly the money I spent on this SeaGauge system is the best I spent on my whole restoration. All in including Wireless NMEA was only $1700.00 including an 800NIT 5.7" VGA LED display. Cant say enough about the ease of use.

I can't make Open Skipper receive AIS messages from TCP or UDP. I can use Shipplotter perfectly.
What could be the problem?

I cant receive AIS data with Open Skipper. I can do it perfectly with Shipplotter. What could be the problem?

Luis: Pleased to see you are experimenting with Open Skipper. We have had OpenSkipper successfully receiving AIS data over UDP. Why don't you contact me directly at a.mason at auckland.ac.nz, and we can work out what's happening in your case. Cheers, Andrew

I have read MNEA 0183 data using Hyperterm on a pc. Can I do the same for NMEA 2000 data (from a Garmin GFS 10 fuel sensor) without any special hardware or cables?

Jim B

Sorry no, Jim. But I think it's because N2K is in an efficient binary format and runs on a true network, CANbus, instead of an old-fashioned one-to-one serial connection. And if you buy or borrow one of the NMEA 2000 gateways from Maretron or Actisense you'll see most every detail of what the GFS 10 is putting out as well as every other device on the backbone.

Ben:

Thanks for the quick response. I think I understand your answer.
My background is in programming: C++ or most and language - so I'm somewhat comfortable processing binary data.
Question 1) Is there a defined format of the binary data published?

Since I'm not connecting to a backbone and connecting to ONLY the GFS 10 fuel meter, I'd assume all the data I'd read would come from the GFS 10.

So now I guess question 2) is:
Can I connect, thru a com port, reading the binary data without any other hardware?

Again, thanks for the info.

Jim

Over my head now, Jim. I think you want to look into the world of CANbus-to-PC. But I'm not sure there's any signal coming out of the GFS N2K/CANbus port unti it's attached to a powered-up backbone.

Hi Jim,

The NMEA 2000 protocol is published, but not freely available. If you're looking to get started parsing the N2k data, I'd highly recommend getting an Actisense NGT-1 and downloading OpenSkipper to have a look at their code.

Unfortunately, CANbus is not electrically compatible with RS-232, and therefore you must have some sort of additional hardware to connect to the bus. I would recommend just buying an off-the-shelf CAN adapter, rather than building your own. The NGT-1 can be had for less than $200.00 and the CANusb, which is more generic is even cheaper.

Also, the bus must have some source of external power. At a minimum, a NMEA 2000 bus has two 120ohm terminators, two devices that can communicate with one another, and a source of 12V.

~Tim

Tim and Ben:

THANKS for responses. Looks like I need to buy the Actisense NGT-1 to connect to a Garmin GFS 10 fuel sensor.

Your information is very helpful.

Thanks again,
Jim

MARSSA(MARine Systems Software Architecture)

MARSSA (www.marssa.org) is the first open source community-driven project in the marine industry.

MARSSA will serve as the base for integration, compatibility and interoperability of electronic systems in the marine industry. With MARSSA the marine industry will become opportunity-driven and innovative with enhanced competitiveness. The customers and users will enjoy very high quality, reliable products and systems with seamless interoperability and a low threshold for introduction of the latest technologies. At the same time the total cost of ownership will be radically reduced.

Are you interested in contributing ?

Contribute now!: www.marssa.org

Dear Kenyon,

"If I missed something post it" : here you go... all that you have been waiting for apperently:

A "marine systems and software architecture" - MARSSA.

www.marssa.org

alan

I am working on a bluetooth app to get NMEA0183 data into an android tablet. I am using bluetooth because of the power consumption (small boat). With bluetooth you can only have one talker, but multiple receivers, so I am using a Shipmodule bluetooth multiplexer to connect all my NMEA serial devices (depth,speed,wind,gps) to the tablet via one bluetooth link. The multiplexer consumes less than 100mA. So far I have managed to get the NMEA data into the tablet and scroll the raw data. I now want to build a GUI on the tablet to do 2 things:
1. Show Depth/Speed/Wind/GPS data graphically.
2. More optimistic - store the depth data with the current GPS position and automatically build and display a depth map whenever I want to anchor. Then I can cruise around a bay and see a depth map building on the tablet before deciding where to drop the anchor. On android it should also be possible to overlay the depth map on a browser window running Google maps showing the actual terrain around the bay, although that is getting a little advanced to develop for my private use.
3. I am not interested in the network IP solution because of power consumption - I want to go to bed and have the tablet wake me up if my boat starts dragging the anchor outside the safe zone on the depth map.
John

Hi John,

I found your post while looking into ways to do the same thing you've already done - getting NMEA0183 data into an Android app. I'd appreciate if you could drop me an email: mfahey(at)xtra.co.nz. I'd like to know more about your project.

Mark

posting to subscribe. I wish there was a subscribe button.... :-)

here i found very nice opensource project :
http://www.cruisersforum.com/forums/f134/opencpn-runs-on-embedded-arm-74082.html#post852297

the hardware(beagleboard xm) and software(linux)
opensource!

cheers

Hello all, nice thread go Panbo!

open hardware works! its the peer review.
see the diyDrone group
a open diy solution can be safer, better and cheaper than the off the shelf solution especaly if you save enough for the radar you couldent otherwise afford

no mention yet of arduino, i2c to CANbus chips, android io, android open accessory, amarino, USB to CAN, or SAE j1939 ?

a arduino mega with its 4 hardware UART's should handle all but the fullest and fastest of buses, multiple arduinos could also parse sentences from multiple sources into one stream or even "fuse" redundant sensors into one signal or validate a signal with all sorts of filters, one can add ones own sentences say "aft cat door" or you can make your own display maybe a vintage pannel meeter in your ol woodie or a nice flush dark window with text and graphic lcds and capacitive buttons

some other related thoughts
1: bluetooth is a great option for a low power wireless link though xbee is a bit more reliable
2: part time tcp/ip or a cell data radio to get off the boat
3: a usb router with ddwrt, opware, and a usb to CAN or two can certainly handle the busiest and fastest bus its also on the cheap
4: a tablet or even kindle next to the companyonway would make a slick marine display
5: arduIMU+ v3 just came out paired with a load cell on the main sheet or head stay and some nice math it could keep more wind in the sail, use less AP power, or improve the ride. even B&G only uses IMU data for windspeed calibration
6: how about a MARSHA?
7: we do NEED a wiki
8: please do your part, love your country!!!!STOP SOPA & PIPA HR3261 & S968!!!!call your reps!!!!, move your money, and go solar

thank you for your time
Scott
lets talk seven oh seven ate twentytwo forty sixty

Hi John.
I am quite interested in your project as I wish to be able to use such an application.
How fare are you in the development of it?
I really look forward to reading you.
Thanks in advance.
Nautiquement vôtre.
Claude
P.S.
FYI all my NMEA data coming from my Tactick instruments,AIS engine and GPS are packed together via a MUX and sent BT to the laptop which runs the SeaPro navigation software.
Seapro send back BT info to the MUX to feed up autopilot and Tactick with the needed info.
I wish tablets and phone can use the same BT to receive position so as to feed up the Navionics navigation app.as well as some kind of anchor watch app.(not sure which one yet...still under test) installed on 3 Android tablets and phone.

I would like to see as well open source version of NMEA 0183.

I personally created an iOs app which simply gets the data from transducer and shows the DBT in the screen. I am using some open source software along with some own parsing logic to accomplish this. I am also using WIFI bridge of WLN10 (digital yacht). I am not pro iOs programmer and I have got in the field tests of the app in the boat several crashes so would be nice there would be some more sophisticated project which could be used with the app which would handle the NMEA parsing and the tcp/ip port listening.

I'm interested to know more about this new Simrad GoFree toolkit:
http://www.simrad-yachting.com/en-US/Products/GoFree-Wireless-Technology/GoFree-Toolkit/
"easy access to full numeric navigation system data" - does that mean read only, or read/write? Is it just NMEA0183 or NMEA2000 over Ethernet, or something more?

@Arsi

Google GPSD

Use it as a starting point

Gentleman: I have recently bought NGT-1 in an attempt to capture NMEA 2000 messages, I am using VB.Net and have managed to capture a number PGNs. I am working to try deocde the data fields of PGN 127250, the vessel Heading bytes are captured as 5a7c corresponding to 182.4 degrees. I am aware this corresponds to 3.1838 Radians; I have not been able to decipher this message to reflect this angle .

In another instance I have captured C3AF corresponding to 4.4995 rads

will appreciate all the help I can get

Hi chukulubu, take a look at http://canboat.com where you can get my open source NMEA 2000 decoder.

Hi chukulubu,
Reverse the byte order and convert the hex to decimal. Then divide by 1000.
So, in your example, c3af (little endian) becomes afc3 which is 44995 in decimal.

@chukulubu
…of course that should read divide by 10000 in my last message.

Chukulubu
I have been trying to write a SMS app of N2K values as alarm/alerts. Is your code open?

Hello Andrew and Kees,
I have just started going through OpenSkipper C# source code, function by function while it is connected to a Garmin GPS and Airmar Depth/STW/WT sensors through the Actisense NGT-1. Fantastic code! Excellent job. My goal is to add some engine monitoring functionality and maybe also create some programmable analog sensor adapters. Thanks for your efforts on this project.
Best regards,
Norm

If this is the place for it: in my work to build my Ranger29 a boat monitor that sends me status SMS, have some fun resources to share. Good reading at www.imamuseum.org/blog/2012/06/26/tracking-the-island-resident-with-an-arduino/ and he links to the other folks of interest in his Overview section.
I use an Arduino and GSM shield. I'm retired software engineer and interested in how open standards give rise to creative solutions, the historical perspective on product evolution. Have a fun read.

Hi everybody
I am working on a Arduino Uno with CAN shield from SK Pang. All is running fine. I decode instruments and I emulate some of them.
Actually I have a wind vane / anemometer Simrad, a Airmar DST 200, a Em Track class B AIS transponder and a ST70 display.
My problem is for protocol PGN like ISO acknowledge, ISO request, etc.
If you have some doc ?
If you want I can post the libraries for CAN shield and Arduino codes. My codes are not very pro but they are running ...
Best regards.
Bernard.

Talk to this guy who made a packet logger he was gathering PGNs.

http://www.keversoft.com/Keversoft/Packetlogger.html

-patrick

Hi Patrick

I think the link point to a guy named Kees on this forum.

I have already seen his work, the data logger is very good.

My work is with Arduino board to interact on the bus, example read the resistor of a fuel gauge and broadcast the fuel level over the network.

Where I encounter difficulties is with protocol PGN, not for decoding, Kees's docs are very good.

Best regards.

Bernard.

I started a project to do this kind of thing. Have a look at http://www.42.co.nz/freeboard

Provides instruments and chartplotter on a web browser vai wifi, using low cost open source hardware and software.

http://www.navigatrix.net/ ?

I am surprised there seems to be so little activity around using open source on platforms like Raspberry Pi and BeagleBoard to provide low cost, novel navigation solutions. Things are moving forward in navigation with huge MFD's and glass cockpits, but for somebody like me with a 10+ year old sailboat and a moderate pocketbook they don't do much.

Simrad's GoFree is more along the lines I'm thinking, providing universal access to the navigation data via wifi. On the visualisation front I was really impressed with SailSteer: finally somebody started putting the computing power and larger displays for use!

Not wanting to spend that much money on upgrading everything I decided to see what I could do with my existing system and a Raspberry Pi.

The result is a proof of concept HTML5/SVG app usable on pretty much any smartphone, tablet or computer on the boat's wifi hotspot provided by the Pi. It connects to my plotter's NMEA 0183 and my N2K network (via NGT-1 + Canboat) and provides all the data in single interface. Additionally it forwards all the NMEA stuff via UDP to other apps such as iRegatta.

All the software is on Github and I have a demo running on Heroku. See https://github.com/tkurki/navgauge for more info.

T Kurki,

Nice work, I like your main gauge a lot (except the boat outline needs two hulls!). I would like to discuss using a common protocol between server and browser (JSON) so we can interoperate between navgauge and freeboard.

I agree about freeboard being hard to setup, I'm trying to improve that aspect. In that vein I have a new interface board that does most of the physical connections, which I am considering making as a kit, or complete board.

In either case it may fit with your stuff too, so we should discuss. You can get my email on the github site.

Rob
Freeboard ( https://github.com/rob42/freeboard-server )

Rob,

Dropped you a message and created https://github.com/tkurki/navgauge/issues/4 to discuss the json format.

I saw your interface board - nice work! Being much less hardware oriented I'm sticking with stuff I can connect to my Raspberry PI via USB (2 x RS422 to USB for plotter & AIS, NGT-1, wifi dongle, GSM dongle) or I2C (AltIMU, ADC voltage & current measurements).

Teppo

Winter is approaching and the boat is out of the water. Time now to look at improving the race computer on my Tartan 30.

Over the winter I plan on adding a T-122 interface from Raymarine to interface Tack Tick data to my Raymarine e7D chartplotter unless I can find a better option. This will interface the wireless wind and hull speed sensors to the e7D. The e7D outputs NMEA-0183 data via Bluetooth, which I can pick up on my Android tablet. Tablet is running the iRegatta app.

Wish list: Real Time sail trim analysis.

Hello all,

Being a "motor boat owner" I would like to use the new Actisense EMU-1 in combination of a NGT-1 to monitor the motor of my boat.
Till now I've been seeing code for sailing purposes.

Anyone here who might know of open source code what will do the motor monitoring?

And.. You guys also have motors on your boat, and this needs to monitor them too! :-)

Noel

I think the Signal k project (signalk.org) is the way forward for open data. Have a look, and help us define a thorough set of engine params.

Robert

Panbo entry about Signal K here:

https://www.panbo.com/archives/2014/11/signal_k_a_true_game_changer_.html

Guys I've been using a serial to wifi tcp converter for the past 3 years... i send the nmea 0183 data via wifi to ipad,android, pc ecc, at first i used it for iregatta then with open cpn or inavx i can steer the autopilot also... theinterface is cheap (50 usd) is an industrial with even an ethernet port, a rs232port and an rs422 (nmea 0183) port. now I'm looking for an industrial n2k/canbus alredymade to use instead the gofree...
with a seatalk to nmea converter i can even send commands to the raymarine autopilot with a tcp server from android like autopilot+/- +10 -10 auto and standby... the server consumes 100mA...

http://www.aliexpress.com/item/Wecon-4-3-inch-cost-effective-fanless-mini-industrial-pc-embedded-industrial-pc/1215303771.html

with the canbus interface you can see nmea2000... theonly limit is windowsce... maybewith android you can use alredy made apps...

In the very first message of this thread sailoutbound pointed out that "The first issue being discussed is getting NMEA 2000 data onto an IP network so that we can easily use the data in a variety of applications."

Well, here we are, a few years later. Now that Digital Yacht's IKommunicate is shipping we have an off the shelf, NMEA 2000 and 0183 certified solution for getting all the NMEA data onto an IP network.

For varying levels of DIY skills there are open source solutions to achieve about the same.

To drive this "all data over IP" we have Signal K: a data model that states how all the different data items are to be represented and APIs (application programming interfaces) for fetching and live streaming that data.

Being Open Source Signal K ought to be future proof, extendable and evolvable, but time will show us how that turns out.

Shall we say "Achievement Unlocked"? I think yes, but this is only the beginning.

Signal K is just the foundation, now we need to build, marine electronics vendors and open source developers alike.

So let the applications be built!