Potential usesof canBoat and SignalK

[Bill Bishop]

I have written a few macro level article level articles on your collective group's most excellent efforts, and I'm currently working on one now for Ocean Navigator magazine. It is at a summary level and will also include Jack Edwards open source and successful Ardunio autopilot project and the six others following in his footsteps. One of the things I'm trying to do is get a handle on potentially where these efforts can go, and who will be the users. I understand canBoat and SignalK are modules/plugins that will fit into a grander picture. So this engenders a handful of questions. Are there currently other open source projects expressing interest in incorporating your efforts? Navgauge and Freeboard are obvious. Open CPN seem to be a possibility, but I can't find any current activities or discussions regarding this. Open Skipper? Seaclear? Openseas? Could there be a tie in with a commercial product in a mode where canBoat, SignalK et al could be freely available plugins to extend capabilities? This alone is a big question. Although the licences currently appear to preclude commercialization, if the buyer of a basic marine navigation software package could after the fact download and use these open source efforts with the application would this be a problem and or violation? This could be a big plus for a developer. lastly what are the grand visions everyone has about these efforts. Any thoughts on this subject would be most appreciated, and I won't publish any revelations made without express permission and review in advance. Many thanks, Bill

[Pavel Kalian]

Bill...
There already is a work in progress on supporting SignalK in OpenCPN in my private tree. But there are currently higher priorities on other stuff and my table is kind of full, so it will take some time until it is any useful. But definitely SignalK will be implemented before the next major release is out.
As far as licenses go - The protocol itself brings no problem. There is also no problem connecting the pieces together. Trying to reuse code licensed under GPL in commercial, closed source, applications problem is, obviously.

Pavel

On 07/22/2014 09:38 AM, Bill Bishop wrote:

I have written a few macro level article level articles on your collective group's most excellent efforts, and I'm currently working on one now for Ocean Navigator magazine. It is at a summary level and will also include Jack Edwards open source and successful Ardunio autopilot project and the six others following in his footsteps. One of the things I'm trying to do is get a handle on potentially where these efforts can go, and who will be the users. I understand canBoat and SignalK are modules/plugins that will fit into a grander picture. So this engenders a handful of questions. Are there currently other open source projects expressing interest in incorporating your efforts? Navgauge and Freeboard are obvious. Open CPN seem to be a possibility, but I can't find any current activities or discussions regarding this. Open Skipper? Seaclear? Openseas? Could there be a tie in with a commercial product in a mode where canBoat, SignalK et al could be freely available plugins to extend capabilities? This alone is a big question. Although the licences currently appear to preclude commercialization, if the buyer of a basic marine navigation software package could after the fact download and use these open source efforts with the application would this be a problem and or violation? This could be a big plus for a developer. lastly what are the grand visions everyone has about these efforts. Any thoughts on this subject would be most appreciated, and I won't publish any revelations made without express permission and review in advance. Many thanks, Bill

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bill Bishop]

Pavel, thank you for the OpenCPN input. The commercialization question has some subtleties.I write a basic navigation app that accepts a USB GPS. I include the hooks to allow the buyers to interface canBoat and signalK into the application, but don't supply the application. The buyer is told if they want to add canBoat and SignalK, they can, but they have to download it themselves. So if the Vendor doesn't supply the plugins, but can accommodate them, is this a licence violation?  

[Fabian Tollenaar | Starting Point]

Hi Bill,

Really cool that you’re writing about Signal K. I can’t speak for CANboat, or even for any of the other individual developers involved with Signal K. What I’m writing here are therefore nothing but my personal views. You can do with them what you like.

Regarding other OS projects: as far as I’m aware, apart from our private efforts (e.g. Navgauge, Freeboard, Saildata), there are no integrations other than Pavel’s efforts yet. But, on the other hand, it’s not like we’ve been extremely active in getting others involved either.

A note on commercial: I did receive an e-mail from a guy building commercial boat controllers who was interested in Signal K. I invited him to visit the Google Group and take a look. No idea if he did though, he seemed put off by the idea of open source. Regarding licences: my position on this is that the format can be used by anybody - since that is exactly the problem with NMEA et al we’re trying to solve.

Grand visions: 

Something I’m definitely interested in is the idea of sharing: some kind of (mesh) network (carrier agnostic) around every vessel (where every vessel in range extends the network - theoretically allowing your Signal K data to reach vessels miles away) in which the public WS streams with Signal K data of each vessel “live” - and can be picked up by anybody in range (directly or indirectly). Basically AIS+. With regular boat sensors (which are merely interesting for the local situation - with the possible exception of depth and wind) this might not be as interesting, but you can share other stuff as well (resources, like waypoints, POIs and even maps). With the right software this can be tremendously interesting for a multitude of applications (not just navigation); imagine for instance about charting organisations utilising publicly available depth data from thousands of vessels, or software building dynamic, near real-time weather maps based on other vessel’s data.

Another thing I’m interested in is the idea of a “app store” of mixed source, free and paid “widgets” that can be installed in a Signal K server and then send out on the (wifi) network in the boat (to any laptop, tablet or phone). These widgets act as consumers of the Signal K stream, and can provide any function.

I’m working (very slowly, since I don’t have a lot of time) on Saildata, which does (will do) just that: a server running on a black box, which takes input from one or more providers (e.g., sensors, a log file, the WS stream from another vessel), multiplexes the data and emits it on a public WS stream. The server also provides a static webserver, which can for instance be used to serve a dashboard with widgets (see my polymeters demo to get an idea of my intentions: http://www.starting-point.nl/polymeters/ - works on Google Chrome only).

Cheers

Fabian

p.s.: sorry for the long text, I’m not a concise writer!

On 22 Jul 2014, at 16:38, Bill Bishop <ipsb...@gmail.com> wrote:

I have written a few macro level article level articles on your collective group's most excellent efforts, and I'm currently working on one now for Ocean Navigator magazine. It is at a summary level and will also include Jack Edwards open source and successful Ardunio autopilot project and the six others following in his footsteps. One of the things I'm trying to do is get a handle on potentially where these efforts can go, and who will be the users. I understand canBoat and SignalK are modules/plugins that will fit into a grander picture. So this engenders a handful of questions. Are there currently other open source projects expressing interest in incorporating your efforts? Navgauge and Freeboard are obvious. Open CPN seem to be a possibility, but I can't find any current activities or discussions regarding this. Open Skipper? Seaclear? Openseas? Could there be a tie in with a commercial product in a mode where canBoat, SignalK et al could be freely available plugins to extend capabilities? This alone is a big question. Although the licences currently appear to preclude commercialization, if the buyer of a basic marine navigation software package could after the fact download and use these open source efforts with the application would this be a problem and or violation? This could be a big plus for a developer. lastly what are the grand visions everyone has about these efforts. Any thoughts on this subject would be most appreciated, and I won't publish any revelations made without express permission and review in advance. Many thanks, Bill

[Pavel Kalian]

Bill...
canBoat is GPL licensed, there is nothing that prevents you from bundling it with your application - no reason to make your users download it separately. What is prohibited by the license is to "borrow/steal/whatever you want to call it" the code Kees wrote, integrate it inside your product's codebase (modified or not) and not make the whole work GPL licensed as well.

Pavel

[kees]

I expressly made CANboat GPL licensed because I want to enforce that commercial vendors don't "steal" it and thus avoid the NMEA licensing fees. It is strictly intended for the fully open source market. Open source products cannot apply for a NMEA license at all, since they cannot publish the knowledge that they gain from the NMEA.

GPL means that they cannot take the CANboat source, or part of it, and include this directly in their own deliverable. Anything that does would also fall under GPL. They also can't just compile it and link to it (which is why CANboat is not under LGPL.)

Theoretically they can provide a hardware device that includes it, as long as they provide (a) acknowledgements and (b) the full source code and any modifications to anyone who asks, even non-customers. This is how router manufacturers use Linux in their hardware, for instance.

Any software, whether open source such as OpenCPN or commercial like iNavX or Expedition is free to implement Signal K. We're definitely interested in this, and it is the entire point of Signal K: an open -- free as in free speach and free as in free beer -- protocol and data definition.

Any NMEA member could write a Signal K producing piece of hardware or software as well, without getting into trouble with the NMEA. Whether they do so will depend on the success of Signal K, of course. At some part they might not be able NOT to.

Given our grander vision, I'd say that even if the NMEA reverses course and fully opens NMEA 2000 and 0183 then we'd still do this as their model is much more limited (to one network on one boat in the case of NMEA 2000). Of course we haven't seen what they are doing for the IP version of NMEA 2000.

[Jeffrey Siegel]

I'm glad to see this group about Signal K.  Thanks to Bill for pushing me to it.  I'm the developer of ActiveCaptain and I think I have some different ways of thinking about Signal K.

We currently have 40 licensees of ActiveCaptain.  Our product is integral in a variety of commercial products out now.  This gives me a wonderful insight into large and small marine electronics and software companies and what they're thinking about.  At the same time, I've been developing a large new group of capabilities that take advantage of what it means to have boats connected together (even while underway) by the internet.  Our eBoatCards, released May 2013, is 5% of this vision and is just the very beginning of what's coming out.

Here's what I see...

NMEA183 / 2K are live protocols.  Data is produced, delivered, and used/displayed.  Software might archive that data, but it's essentially a stream and then it's gone.  That's fine for displaying wind data, watching depth, or controlling an autopilot, but it misses a next layer of capability that surrounds a server architecture and intercommunications between vessels.  I think that  NMEA today is like phone calls of the 1970's.  They happen.  They're perfect for exchanging information.  But when both parties hang up, the conversation is gone.

Signal K or whatever is coming next needs to be the email/forum/messaging upgrade to the phone conversation.  It provides something that can be shared, stored, and served.  TCP/IP is a fine protocol but combining it with http and the server technology it promoted allows us to truly share information.  It wasn't TCP/IP that made all of this work - it was combining it with the server.  And don't think for a second that no one cares about your route, track, depth findings, wind sensings, or any other information you're experiencing.  Sure, there's got to be security and privacy if desired but there are huge new capabilities that come out when data like this is shared.  Note too that sharing is both vessel-to-vessel as well as among devices within a single vessel.  And all of those devices are only going to get more numerous - watches, "glasses", and more.  Think for a second about how poorly N2K fits into a watch/glasses world.

So moving Signal K, in my opinion, to the next level won't be done by creating something that goes head-to-head with N2K.  Instead, build something that goes beyond N2K and adds that server architecture with sharing built in at its core.

I could go on for 10 more pages but instead, here's a suggested plan to get Signal K adopted:

1. Design an architecture centered around a media server - a central server where data is sent and stored - there are many models for this.  Received data can be forwarded immediately over other traditional paths (N183 / 2K) or served on request.  There needs to be both push and pull data architectures and communications built in at the core.  Internally, we've been calling this media server a "Social Navigation Center" because inter-vessel communication possibilities are extremely interesting (and fun) and it's what I've been working on.

2. Allow this server to work extremely well in the N2K world with existing gateways.  But also provide the Signal K protocol in/out to allow other developers to write directly against that.  Look at how few iOS/Android apps exist that display boat instrument displays.  If the iPhone didn't have a built-in GPS, boating apps would be a total mess.  It is very difficult to get live instrument data out of N2K largely because of their draconian licensing.  Give developers a standard way and more boats will put in these servers to interface existing N2K data to the phones/tablets/PC's.

3. Develop a modular server and license it.  This is the Apache version of this media server/Social Navigation Center.  It should work on a PC or dedicated hardware.  Existing MFD manufacturers will see how easy it would be to build this server capability into their fixed stations.  They are all looking for ways of heavily differentiating themselves from iPad's today.  A fixed station that also provides full serving and inter-vessel communications is a good way.  A fixed MFD will always have connectivity to all NMEA networks and can easily gateway traffic to Signal K in a competitive way (no N2K development needed).


There is a large number of new capabilities possible today when connecting devices on a single boat and connecting boats together.  Signal K can't just try to replace N2K with a more reasonable licensing model.  It has to extend what's possible to allow for new capabilities that will become compelling for boaters to adopt and install.  Doing that will provide the communications channel and push the technology out to the point where the new protocol solves all the needs from the top, down.

[Fabian Tollenaar | Starting Point]

Hi Jeffrey,

Nice to read that you're enthusiastic about signal k. Your views aren't different at all, it's basically what we've been talking about! Just skim through the different threads in this group to get a feel about where we're at. The data format itself is the all-important first step, implementations are a logical result.

Welcome to the group,

Fabian 

--

[rob...@42.co.nz]

Jeffrey,

Yes - what you have descibed is what we have as a vision. We started out looking to replace NMEA with a open protocol, but then we saw the same possibilities you have described.
So SignalK has some interesting attributes just for this - although its primarily a data model, it can be sent very easily as a json message - either the full current model, or any branch or leaf. And the JSON can be easily merged into any other  signalK tree, since all data uri's are unique. The practical side of this is that it lends itself nicely to peer-to-peer signalk servers. A single server might hold a whole vessels tree, a whole regions tree, or just the depth branch (eg a depth transducer). So they all just transmit what they should, and merge what they want.

That in turn allows vendors to create hardware at any level - I have my arduino based windmeter pumping out signalK now! So its a rich environment for software and hardware vendors to provide server-in-a-box solutions. The internet of things (nautical edition)

Re wider adoption, I was thinking along similar lines this week after pondering Bills question ('how does the average boater use this?') - I plan to submit a proposal on implementation architecture shortly, and that will cover the various layers of hardware and software. Then we need to look at open sourced reference implementations of the key bits, to get others started.

Rob

[Robert Brown]

Active captain is what made me think of this, and i know the basic concept has been talked about with cloud sourced data. Can there be a special set of "calibrated" or "certified" sensors. My thoughts are that you have a licensed tech come out and measure your GPS and depth sounder. This calibrated sensor now has the exact depth and has been adjusted by its distance from your GPS antennae. Maybe only specific precision sensors can be certified. Now you have certified cloud sourced data

The immediate application is for depth. Many areas and countries have limited or no accurate depth data, shifting sand bars or other underwater terrain or changing landscape. a way to store this data allows a boat without Internet access to add the depth soundings from its voyage to the cloud once Internet is available. Maybe this certified data can be exchanged with other boats when they connect via wifi, so you can have the benefit of their depth data when you come into an anchorage.

Even better one set of these certified sensors with a "mini" server on your dinghy. This would allow you to run around and upload data once you get back. You could scout out anchorages this way in advance. You could gather a lot of depth Info with just your daily shore excursions.

[Robert Brown]

[Fabian Tollenaar | Starting Point]

> On 13 Nov 2014, at 00:32, Robert Brown <sandieg...@gmail.com> wrote:
>
> Active captain is what made me think of this, and i know the basic concept has been talked about with cloud sourced data. Can there be a special set of "calibrated" or "certified" sensors. My thoughts are that you have a licensed tech come out and measure your GPS and depth sounder. This calibrated sensor now has the exact depth and has been adjusted by its distance from your GPS antennae. Maybe only specific precision sensors can be certified. Now you have certified cloud sourced data

You wouldn't even need "certified"/license ("certified" is IMHO really just another word for "proprietary" until you pay me a lot of money); the beauty of crowd sourcing data is that data can be verified by other crowd sourced data.. On top of that, once you hit a large enough scale - especially for a longer time range - you would have enough data to verify any new data using a statistical model based on historical data.

[Robert Brown]

Am i correct in that The data format you are setting up would be easy and quick to transmit? Would that also include via vhf, or marine band radio? I can see both being fairly use full if an update can be transmitted maybe once a minute or so, quickly without using to much power.

Example: a boat in weather transmitting wind, location, heading ect, over marine band every 5 min, letting long range boats know what the weather conditions are. I would suspect that with the ultrasonic weather sensors available now, that a lot of weather or storm info could be transmitted. How about pan pan or other such emergency messages. Would be nice to be able to pass off all my position, heading, water current ect data digitally and on repeat with the problems to would be rescuers

Enough boats sharing data could track current weather and allow you to navigate accordingly to what is best in your situation. IE: avoid storms or navigate to take advantage of wind or maybe even exchange real time local grib files

[Robert Brown]

On my wish list is an app to adjust my polar based on real time info and conditions and not have to add several of thousand dollars of equipment to do it! I have a Zeus plotter, but I can't use my nmea 2000 sensors. I have to get b&g's proprietary sensor and computer system. Expedition is over a $1000. None of the systems or software seem to play well with others! I'm primarily a cruiser and just want to know where I'm in the best sweet spot for a given set of conditions. With the pretailing conditions can I lightly alter my route for a little more efficiency or less time between transits? Everything mostly covers racing, but I want similar stuff and tactical info for cruising, advanced info to make route decisions based on current conditions or Even a little friendly competition between boats to get to the next island.

[Robert Brown]

[Robert Brown]

My meaning for certified is more along the lines of calibrating your sonar by the actual depth of the water. Ie your draft is at 6 feet and calibrating that transducer to add that 6 ft to its depth reading. I know more That a few that were professionally installed or uncalibrated diy installs, and their readings were off. The GPS reading would have to be calibrated so that at the specific time your sonar takes a reading you also have a GPS position reading adjusted directly on the spot the sonar reading was taken. Maybe this is solvable entirely or mostly with software.

Alternately have two tiers of info, regular Joe depth data that needs to be verified, take it with a grain of salt, and certified data that using verified accurate sensors.

The need for someone licensed would be more like having your torque wrenches or gauges calibrated. A check to verify your info is accurate. Smart sensors fail and some boaters are clueless. Possible nefarious action transmitting safe water marks in bad areas intentionally, or just from out of walk calibration or hardware

[kees]

Hi Robert,

At the moment we are focusing on creating the 'dictionary' of things that can be transmitted, as well as creating some reference implementations of the most common use cases. But keep the ideas coming, it helps us refine our reference dictionary.

On Thursday, November 13, 2014 12:54:32 AM UTC+1, Robert Brown wrote:

Am i correct in that The data format you are setting up would be easy and quick to transmit? Would that also include via vhf, or marine band radio? I can see both being fairly use full if an update can be transmitted maybe once a minute or so, quickly without using to much power.

Sure, but the Signal K group does not want to over-reach so right now we're not going to spend any time on physical protocols lower than TCP/UDP. We will probably come up with guidelines of how to transmit Signal K over serial streaming protocols that do not packetise data.

Example: a boat in weather transmitting wind, location, heading ect, over marine band every 5 min, letting long range boats know what the weather conditions are. I would suspect that with the ultrasonic weather sensors available now, that a lot of weather or storm info could be transmitted.

Yup, that is one scenario. At the moment this we don't have any development skills in HAM or unlicensed radio, but sure it could be done. All it takes is someone to come that knows about something like High-speed multimedia radio (http://en.wikipedia.org/wiki/High-speed_multimedia_radio), D-star (http://en.wikipedia.org/wiki/D-STAR) or something else. They could then take the Signal K spec and specify how it would be transmitted over radio waves.

 

[kees]

That is also how Navionics creates its SonarCharts. It uses the data of multiple users. They realised how quickly the data averages given more than one source.

Certainly re-creating SonarCharts is easier than recreating official charts. All it takes is (enough) depth information from enough sources, and a service that takes this data and recreates an averaged map. This could be a local server on a boat, taking all the data received from other boats and its own vessel and slowly building this up, or a central server which would benefit from more sources. This could be at the club level or at the global level (once you are on the internet, why not share?)

I could see how a vessel would store its track and depth and then push this to this central server automatically. That would make it much more convenient than what you need to do right now.

So what we need to do here is make sure that this is easily interchanged using Signal K.

[rob...@42.co.nz]

Robert

The problem with crowd sourced data is reliability, which is basically a trust problem. I suspect that the solution is like ebay where reputation is king. If a source of depth soundings is wrong for one area, its suspect for others. so you flag it reliability down. And the same in reverse.
BTW I think this crowd source depth has a more immediate use - crossing bars (the sandy sort). We cruised the Aussie coast a few years ago, lots of bar entrances, and the charts and  cruising  guides date too quickly. Would be great to get actual conditions from vessels crossing, and see the most successful routes.

And during that same voyage we used SSB data via airmail (sailmail) and a Pactor modem. It would be quite possible and not that difficult to set up a system  (like APRS) that distributed all sorts of data. Probably send and recieve on a schedule, auto update your chart plotter with other vessels, their conditions etc. I agree it would be a fantasic cruising aid, and an extra safety net too. Sort of like the radio nets cruisers use.

Rob