tag:blogger.com,1999:blog-91902709920637348062024-03-14T00:13:58.850-07:00Water and ElectrickeryMarine technology and mixologyStripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-9190270992063734806.post-2419708764414896972016-07-13T14:02:00.002-07:002016-07-14T00:55:16.073-07:00OpenPlotter<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<h2>
Open Up</h2>
<div>
<br /></div>
<a href="http://www.sailoog.com/openplotter">OpenPloter</a> is not the first "marine OS" to assemble a variety of boating-related software into a single downloadable image: <a href="http://marinux.tuxfamily.org/">Xinutop</a> and <a href="http://navigatrix.net/">Navigatrix</a> are both <a href="https://en.wikipedia.org/wiki/X86">x86</a> <a href="https://www.gnu.org/gnu/linux-and-gnu.en.html">GNU/Linux</a> distributions which provide <a href="http://opencpn.org/ocpn/">OpenCPN</a> and other free marine software pre-configured. <a href="http://www.sailoog.com/openplotter">OpenPlotter</a>, which has gained a lot of friends in the past year, differs from those in a number of ways. Most obviously it is aimed at <a href="https://en.wikipedia.org/wiki/ARM_architecture">ARM</a> systems, notably the <a href="https://www.raspberrypi.org/">Raspberry Pi</a>, and rather than being simply a collection of useful software it provides sailors with an interest in DIY a platform on which to build an integrated boat electronics system using the plethora of cheap sensors that arena available. Not just a collection of 3rd party software, OpenPlotter adds a GUI to provide unified management of many of its functions, making command-line and configuration-file oriented Linux/UNIX software like <a href="http://www.stripydog.com/kplex">kplex</a> more accessible to a wider range of DIY-ers. Additionally you can purchase tested hardware through the <a href="http://www.sailoog.com/en/shop">OpenPlotter web site</a>.<br />
<br />
Roberto Serrano, OpenPlotter's lead developer, kindly agreed to answer a few questions about the project...<br />
<br />
<b></b><br />
<b></b></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-8YocmO-xTRo/V3aZ6ga8-HI/AAAAAAAAAMg/z4qiz6LVqlkpGgc1rhG-sCYEcEjgvuRiwCKgB/s1600/OP_data.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://2.bp.blogspot.com/-8YocmO-xTRo/V3aZ6ga8-HI/AAAAAAAAAMg/z4qiz6LVqlkpGgc1rhG-sCYEcEjgvuRiwCKgB/s640/OP_data.jpg" width="452" /></a></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><br /></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue;"><i><b>What
does "sailoog" (the name of your website and pseudonym you post under) mean?</b></i></span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box"></a><a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box1"></a>
I would like to <span lang="en-US">tell a </span><span lang="en-US">nice
</span><span lang="en-US">story </span><span lang="en-US">here about
some recondite indigenous language </span><span lang="en-US">or
something similar </span><span lang="en-US">but I cannot. I just nicked it from one of our previous </span><span lang="en-US">and
</span><span lang="en-US">unsuccessful projects, a marine blog system. Sailblog was taken so, </span><span lang="en-US">playing with
logos and letters we said Hey, the Internet is full of double “o”s (google, yahoo, moodle, joomla…) so let’s be cool!</span><br />
<span lang="en-US"></span><br />
<span lang="en-US"></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-c49dIFjlxiM/V4dE2gQmyEI/AAAAAAAAAO8/v_U5M7dylCo_bn2UUi3aQruZs5Av-PHqwCLcB/s1600/op1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://3.bp.blogspot.com/-c49dIFjlxiM/V4dE2gQmyEI/AAAAAAAAAO8/v_U5M7dylCo_bn2UUi3aQruZs5Av-PHqwCLcB/s320/op1.jpg" width="320" /></a></div>
<span lang="en-US"><br /></span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<i><span style="background-color: white; color: blue;"><b>Why
did you start the openplotter project?</b></span></i></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box2"></a>The financial crisis hit hard <span lang="en-US">in southern </span><span lang="en-US">Europe</span><span lang="en-US">
</span><span lang="en-US">and took us our jobs, our homes, our boats
and our dreams. I am from Catalonia and the only option was to go abroad to work </span><span lang="en-US">so
I started OpenPlotter </span><span lang="en-US">project </span><span lang="en-US">just
</span><span lang="en-US">as an exercise to learn English, improve my
skills programming in languages like python and use some tools
like gi</span><span lang="en-US">t</span><span lang="en-US">hub. </span><span lang="en-US">But
I soon realized that I was dealing with something with real
projection and maybe a way to hit back. </span>
</div>
<div lang="en-US" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box5"></a></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box13"></a><a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box14"></a>
<span lang="en-US">We believe we should be able to equip even small
boats with high quality, </span><span lang="en-US">affordable and robust
</span><span lang="en-US">technology without having to rely on</span><span lang="en-US"> the big corporations</span><span lang="en-US">. </span></div>
<div lang="en-US" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box3"></a><span lang="en-US">Governments
and </span><span lang="en-US">proprietary technologies no longer have more</span><span lang="en-US"> guarantees than </span><span lang="en-US">real democracy</span><span lang="en-US">
and open-source technologies so</span><span lang="en-US"> we could say that </span><span lang="en-US">my</span><span lang="en-US">
main motivations </span><span lang="en-US">on</span><span lang="en-US">
this project are </span><span lang="en-US">ethical and political </span><span lang="en-US">but
</span><span lang="en-US">I can not speak by the others, perhaps we
could even disagree but who cares? This is open, </span><span lang="en-US">this
is</span><span lang="en-US"> free, and </span><span lang="en-US">above
all </span><span lang="en-US">this is </span><span lang="en-US">fun.\</span><br />
<span lang="en-US"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-gixFacNaWms/V4dE2fvGJUI/AAAAAAAAAO4/u-RZUg-id0UwMJaUFGX29oHzAqgPNWGyACEw/s1600/op2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://4.bp.blogspot.com/-gixFacNaWms/V4dE2fvGJUI/AAAAAAAAAO4/u-RZUg-id0UwMJaUFGX29oHzAqgPNWGyACEw/s320/op2.jpg" width="320" /></a></div>
<span lang="en-US"><br /></span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>How
many people work on putting openplotter together?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box4"></a>
It is hard to say. A lot of people contribute to
software or hardware while
they are configuring the system on their boats and
then
disappear as the sailing season starts
but there is also an army of loyal
beta-testers
who follow the development closely.
<span lang="en-US">To be more precise,</span><span lang="en-US"> we are</span><span lang="en-US"> currently a </span><span lang="en-US">group of
two people coding and three people developing and testing hardware.</span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-gfXE2yVO7_M/V4dE2qsjtOI/AAAAAAAAAPA/NfjMCwh4e5I9R12sZ4joGm-lgua2lH2hgCEw/s1600/op4.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://4.bp.blogspot.com/-gfXE2yVO7_M/V4dE2qsjtOI/AAAAAAAAAPA/NfjMCwh4e5I9R12sZ4joGm-lgua2lH2hgCEw/s320/op4.jpg" width="320" /></a></div>
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>Navigatrix
fulfils a similar function to openplotter but on a different
platform. Are you continuing to develop navigatrix, are you putting
all your effort into openplotter, or do you intend to combine the two
into one multi-platform project?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
Despite
having contributed to Navigatrix development in different ways for a
long time, I can not consider myself part of the development team.
Navigatrix has its own course and still a long road ahead.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box7"></a>
I think both are <span lang="en-US">complementary projects.
</span><span lang="en-US">Navigatrix is focused on running all the
available nautical software on any PC computer. Its main feature is portability. You can sail on any ship with your Navigatrix
</span><span lang="en-US">laptop</span><span lang="en-US"> </span><span lang="en-US">and
you can even sail with Navigatrix installed on a USB stick in your
pocket and run it on any computer </span><span lang="en-US">on board.</span><span lang="en-US">
However OpenPlotter is focused on hardware, permanent installations
and enhanced interaction with sensors.</span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-1tfSUzu9ke8/V4dE215rwDI/AAAAAAAAAPE/T_-jLfOXpywxMpp-kP_QVoH_7ejpr-BgACEw/s1600/op5.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="195" src="https://3.bp.blogspot.com/-1tfSUzu9ke8/V4dE215rwDI/AAAAAAAAAPE/T_-jLfOXpywxMpp-kP_QVoH_7ejpr-BgACEw/s320/op5.jpg" width="320" /></a></div>
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><i><span style="color: blue;">How
many people do you think are currently using openplotter /
navigatrix?</span></i></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
It is
hard to say again. Since this must be sustainable, we use free file
sharing sites and torrent downloads and we do not have an accurate
number of users or downloads. We have feedback from every continent and sea area, so I guess they could be hundreds or even thousands.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-_uARQnbcUK0/V4dE2yCtsyI/AAAAAAAAAPI/8TuE8LtYUhYstNhiG8XBpkAFCtzh0IogQCEw/s1600/op6.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://1.bp.blogspot.com/-_uARQnbcUK0/V4dE2yCtsyI/AAAAAAAAAPI/8TuE8LtYUhYstNhiG8XBpkAFCtzh0IogQCEw/s320/op6.jpg" width="320" /></a></div>
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>You
sell accessories which are fully supported with openplotter and are
completely transparent with the (optional) donation attached to the
"sponsoring edition" SD card. It's a fantastic business
model, but is openplotter a business, or is it still a hobby?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
We believe in open source, transparency and fair business. Development
and coordination take a lot of time. We need to make some profit to
keep working on it and this is how we try to do it:</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box9"></a>
Probably all your instruments are manufactured in Asia, but
development, support and merchandising is done by <span lang="en-US">third
parties </span><span lang="en-US">who obviously increase the final
price. Retail shopping in the Asian market may be</span><span lang="en-US"> cheaper but it's also </span><span lang="en-US">a traumatic experience due
to </span><span lang="en-US">the</span><span lang="en-US"> lack of
</span><span lang="en-US">product </span><span lang="en-US">documentation
and </span><span lang="en-US">sales support. </span><span lang="en-US">Too
often you finally get a product that doesn't fit the promised
specifications, doesn't work properly or takes more than a
month to arrive. We try to be a filter. We do the hard work of finding reliable
providers </span><span lang="en-US">and charge a little money for doing so.</span></div>
<div lang="en-US" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box15"></a>
<span lang="en-US">I</span><span lang="en-US">n the coming months we
will open </span><span lang="en-US">the "</span><span lang="en-US"><i>fake
shop":</i></span><span lang="en-US"> </span><span lang="en-US">a </span><span lang="en-US">cost
price </span><span lang="en-US">online shop with all the junk and
fake products that we have </span><span lang="en-US">gathered </span><span lang="en-US">in
order to give them an opportunity for a second life in</span><span lang="en-US"> other projects.</span><span lang="en-US"> </span><span lang="en-US">There
will also be a list of providers we have found unreliable to help those who can't even afford our selected products and want to fight their own way through the Asian jungle.</span><br />
<span lang="en-US"><br /></span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-Pae9m88MVRw/V4dE26uJaNI/AAAAAAAAAPM/mn87_6SIodc6mRYmRLVri-xXVhFASUXVwCEw/s1600/op7.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://4.bp.blogspot.com/-Pae9m88MVRw/V4dE26uJaNI/AAAAAAAAAPM/mn87_6SIodc6mRYmRLVri-xXVhFASUXVwCEw/s320/op7.jpg" width="320" /></a></div>
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><i><span style="color: blue;">If
"still a hobby": What's your day job?</span></i></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
This model of donations/selling tested products seems to work and I
can work half time on OpenPlotter. I still need to work as freelance
web developer if I want to a living wage but at least now I
can be selective about the clients and projects I choose.<br />
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-Qq4ascaCuvM/V4dE2SGY1XI/AAAAAAAAAO0/4rbd0lFHlVInWFa9rHZndIevffFLfKViACEw/s1600/op3.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://3.bp.blogspot.com/-Qq4ascaCuvM/V4dE2SGY1XI/AAAAAAAAAO0/4rbd0lFHlVInWFa9rHZndIevffFLfKViACEw/s320/op3.jpeg" width="320" /></a></div>
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><i><span style="color: blue;">Do
you sail a boat, and if so what do you use openplotter for aboard?</span></i></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
My boat is gone but it is said that the best boat will be always your
friends’ boat. I have seen OpenPlotter installations in all kind of
boats.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-t14fX-yd-AI/V4dE3JdSBaI/AAAAAAAAAPQ/Cf6LbXZConAZWxuw6HEtiE2WNirduEnNwCEw/s1600/op8.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://1.bp.blogspot.com/-t14fX-yd-AI/V4dE3JdSBaI/AAAAAAAAAPQ/Cf6LbXZConAZWxuw6HEtiE2WNirduEnNwCEw/s320/op8.jpg" width="320" /></a></div>
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><i><span style="color: blue;">What
features of openplotter are the most popular with users?</span></i></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
The headline is always OpenCPN and its plugins. Second is the SDR AIS
receiver followed by engine sensors and instrument panels. Third is "home automation" features to monitor and control your boat while you are away.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b style="background-color: white;"><span style="color: blue;"><i>Are
openplotter users making much use of Signal K?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
Not much at the moment. I think they feel that SK is just a way to
receive N2K data but then they don't know what to do with these data.
They know the basics but they don't have a sexy instrument panel or phone app to realize its power yet.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://4.bp.blogspot.com/-AH-mjR_eFlg/V4QW79I1CaI/AAAAAAAAAOM/B8p4vkXw8iE3mpZ_2xtETQEHRItlcEi0ACLcB/s1600/gear_S2_Openplotter.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="312" src="https://4.bp.blogspot.com/-AH-mjR_eFlg/V4QW79I1CaI/AAAAAAAAAOM/B8p4vkXw8iE3mpZ_2xtETQEHRItlcEi0ACLcB/s400/gear_S2_Openplotter.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Galaxy Gear S2 driven by OpenPlotter and Signal K</td></tr>
</tbody></table>
<b><i><span style="color: blue;">Do
you see Signal K overtaking NMEA-0183 as the predominant protocol for
marine data communications between applications on IP networks, and
if so when?</span></i></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
NMEA
0183 will be with
us for a long time because it is the language which GPS and AIS talks but
above all because it is the only language that OpenCPN can understand
at the moment. But NMEA
0183 is not capable of managing non strict navigation data. M<span lang="en-US">any
types of sensors have begun to appear in our </span><span lang="en-US">boats
and </span><span lang="en-US">homes </span><span lang="en-US">so</span><span lang="en-US">
we need to store, manage, and show these data </span><span lang="en-US">and
another </span><span lang="en-US">proprietary</span><span lang="en-US">
</span><span lang="en-US">and limited </span><span lang="en-US">protocol
as N2K is not an option</span><span lang="en-US">. </span><span lang="en-US">There
are already some SK servers on the market like OpenPlotter but I think the big</span><span lang="en-US"> change is down to SK apps </span><span lang="en-US">developers</span><span lang="en-US">,
OpenCPN included.</span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><i><span style="color: blue;">What
would make Signal K better?</span></i></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<i>Everything takes time, money, and monkeys. You need a lot from any
two groups, and a little from the third. An increase in any one
reduces the requirement for the other two. Change occurs when one of
those three change.</i></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
Moe's Law, Navigatrix team.<br />
<br />
I think SK now needs monkeys to get to a stable version asap and to improve the documentation.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>You
recently added MQTT support to openplotter, marrying marine data with
the mainstream IoT world. Have users reacted positively or
remained uninterested?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
Yes, some of them are excited about this and they are already playing
with sensors but most of them do not have a clear idea about how they
can set up a IoT system on their boats with OpenPlotter. They need
manuals and a good documentation and we cannot offer this at the
moment since our resources are limited and we have to choose between
developing or documenting.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://2.bp.blogspot.com/-KWRmsfSYPa4/V4aqQ5ZmgeI/AAAAAAAAAOk/v7hcubrYktMmur62BiFfvlic1VT1R1begCLcB/s1600/dbwgtk2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="348" src="https://2.bp.blogspot.com/-KWRmsfSYPa4/V4aqQ5ZmgeI/AAAAAAAAAOk/v7hcubrYktMmur62BiFfvlic1VT1R1begCLcB/s640/dbwgtk2.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">User-contributed MQTT-driven dashboard: <a href="http://forum.openmarine.net/showthread.php?tid=162">http://forum.openmarine.net/showthread.php?tid=162</a></td></tr>
</tbody></table>
</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>What
format are you using to publish to MQTT and why not use Signal K/JSON
objects?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
OpenPlotter can send any kind of string including JSON objects over
MQTT. It is up to the subscribers to parse and manage the string. In
future OpenPlotter releases we will make building JSON
objects easier, NMEA sentences… using any navigational data.</div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>Is
openplotter being used as a generic IoT device in non-marine
applications?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box11"></a>
I don't know, maybe. There are a
lot of IoT home systems based on the Raspberry Pi, since OpenPlotter
is too much boats oriented, <span lang="en-US">maybe it would
be better to use any of them.</span></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<b><span style="color: blue;"><i>What
are the future plans for the openplotter project?</i></span></b></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<br /></div>
<div lang="en-GB" style="line-height: 100%; margin-bottom: 0in;">
<a href="https://www.blogger.com/blogger.g?blogID=9190270992063734806" name="result_box12"></a>
We are still under construction. The main goal now is to fully implement SK in version 0.9.0 in order to be able to deal with analogue sensors (batteries, engine, tanks...) properly. We would also like to offer a good virtual instrument panel to round things off.<br />
<br />
Once the goals are achieved, the
next logic step is focus on hardware. Nowadays OpenPlotter is a
project for “makers” and this always involves <span lang="en-US">some
skill with electronics or at least a big curiosity. </span><span lang="en-US">We
need to simplify the required devices and develop well documented
hardware to make it easier for everyone to build a custom OpenPlotter
system on board.</span></div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com0tag:blogger.com,1999:blog-9190270992063734806.post-10291053097749367392016-02-22T13:02:00.000-08:002016-03-04T09:49:22.572-08:00vyacht router: Now with Signal K<h2>
First Blood</h2>
<div>
Swedish marine electronics producer <a href="https://vyacht.net/">vyacht </a>appears to be first to market with a commercial <a href="http://signalk.org/">Signal K</a> offering. New firmware released at the end of January for the <a href="http://vyacht.net/opencart/n2k-wifi">vyacht WiFi NMEA router</a> supports <a href="http://signalk.org/">Signal K</a>.</div>
<div>
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<h3 style="margin-left: 1em; margin-right: 1em;">
</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-tyF4aRJ7oQc/VtnBLznDfCI/AAAAAAAAALo/Muqie4BNQ7k/s1600/unnamed.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="390" src="https://2.bp.blogspot.com/-tyF4aRJ7oQc/VtnBLznDfCI/AAAAAAAAALo/Muqie4BNQ7k/s400/unnamed.png" width="400" /></a></div>
<br />
<div>
<div class="separator" style="clear: both; text-align: center;">
</div>
The vyacht router is an open source (hardware and software) device which bridges between NMEA-2000, NMEA-0183 plus optionally Seatalk-1 networks and wifi (and optionally ethernet) with the base model costing just SEK1499: a little under €170 at the time of writing.
<br />
<br />
Bernd from vYacht was kind enough to answer some questions about vyacht, the router, the new firmware release and Signal K.
<br />
<h2>
About vyacht</h2>
<span style="color: blue;"><i>You’ve been producing the vyacht router for longer than vyacht AB has existed. Did the project start as a hobby?</i></span>
<br />
<blockquote class="tr_bq">
<span style="background-color: white; color: #222222;"><span style="font-family: inherit;">Its a very intensive hobby, although it's grown bigger and more successful than you could run outside a Swedish aktiebolag [corporation] without losing sleep.</span></span></blockquote>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-HUeYMoLSSvg/VtnBXL_qFxI/AAAAAAAAALw/uED10l7_6FU/s1600/unnamed.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="225" src="https://2.bp.blogspot.com/-HUeYMoLSSvg/VtnBXL_qFxI/AAAAAAAAALw/uED10l7_6FU/s400/unnamed.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The vyacht workbench</td></tr>
</tbody></table>
<h3>
<span class="im" style="font-weight: normal;"><span style="color: blue; font-family: inherit; font-size: small;"><i>Do you now work full time on vyacht?</i></span></span></h3>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">I am currently starting to look into scaling the business up and make it full time. I need people looking after sales and support and setting up distribution in various countries: the direct sales model is limiting.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">And an investor. If someone interested reads this: its not too late to talk to me.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">The vyacht router is a very mature product now and probably the most advanced, flexible and extensible on the market. The market is huge and has just started to ramp up in vyacht's space of innovating in the integration of boat networks, web, mobile and wireless.</span></span> </blockquote>
<span style="font-family: inherit;"><span style="color: blue;"><i>Do you have any other products planned?</i></span></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">There are at least 3 or 4 ready-to-ship products. I just haven't got around to launching them as I am focusing on the router.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">There is also new functionality in the pipeline for the router itself. It's easy to extend even on the hardware side. It's capable of a lot already but ideas and possibilities are endless just on the software side.</span></span></blockquote>
<h2>
The vyacht router</h2>
<h3>
</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-IVvAIk7y8eI/VtnKYHaASRI/AAAAAAAAAMM/NH_IiasOXXQ/s1600/unnamed-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="498" src="https://4.bp.blogspot.com/-IVvAIk7y8eI/VtnKYHaASRI/AAAAAAAAAMM/NH_IiasOXXQ/s640/unnamed-1.png" width="640" /></a></div>
<span style="color: blue;"><i><span style="font-family: inherit;">Is the vyacht router NMEA certified, and if not, is that something </span><span style="font-family: inherit;">potential customers should be concerned about?</span></i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Like most small companies, vyacht hasn't sought NMEA certification. The protocols are </span></span><span style="background-color: white; font-family: inherit;">publicly </span><span style="background-color: white; font-family: inherit;">well documented thanks to the work of many volunteers. vyacht works with all the software and apps out there: none of those that I am aware of is NMEA certified. They are based on the public documentation just like vyacht.</span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">The end user doesn't need to worry. vyacht users have successfully tested the router against probably hundreds of different NMEA instruments and devices. I have seen and fixed all sorts of issues but never any that was specifically about NMEA incompatibility.</span></span><span style="font-family: inherit;"><span class="im"><br /></span></span><span style="font-family: inherit;"><span style="background-color: white;">To my knowledge even Raymarine only certify their MFDs but most of their other products are not NMEA certified either.</span></span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">I am very critical of propriety standards. Unlike some I don't even see a positive marketing or quality effect of using the NMEA certification.</span></span></blockquote>
<span style="font-family: inherit;"><span style="color: blue;"><i>Are all the vyacht software sources available on github?</i></span></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">Sometimes I am a bit behind, but I aim to have all software uploaded there reflecting the latest state.</span></span></blockquote>
<i><span style="color: blue;">The vyacht router is notably much cheaper than competing products from much larger manufacturers. How do you manage this?</span></i>
<br />
<blockquote class="tr_bq">
Margin! On the suggested retail price they will have a margin of at least 200 USD, probably much more depending on their hardware.</blockquote>
<blockquote class="tr_bq">
Also my product is a bit simpler in terms of the case and terminals.</blockquote>
<blockquote class="tr_bq">
I produce in batches of 100. I'm not sure of their batch sizes. Theirs will cost as much in production. If they produce 1000 then prices will drop dramatically. </blockquote>
<blockquote class="tr_bq">
I run it as a very extensive hobby project and 2nd job costing my health ;-) I am not financially dependent on it - and my profit is 0. </blockquote>
<blockquote class="tr_bq">
I started the whole project because I was so frustrated about the price level. Boat owners are the "milking cows" for nice earnings - I <i>thought</i>. Now I know: hardware is expensive, unbelievably expensive and much more than the sum of its sourced parts. If you have a case and knobs and dials it becomes extremely expensive. If you run a company you need to have at least 200 - 300% margin and volume > 1k to survive. Just accounting rules around warehousing will kill you.</blockquote>
<h2>
The new vyacht firmware release</h2>
<span style="color: blue;"><i> As far as you are aware, is the vyacht router the first commercially available Signal K device?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">To my knowledge, yes. The first commercial product and company behind Signal K with full user support for the Signal K components installed.</span></span></blockquote>
<span style="color: blue;"><i> Why did you implement Signal K on vyacht? Have there been requests from customers?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">There was not much interest in Signal K from the vyacht community and so far it hasn't been driving any additional interest into the router.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">I see it as an investment, experiment and as support for a great project. I like and share the vision behind Signal K, and everyone can immediately see the added user value. The instrument panel is built into the router accessible without any additional software installed anywhere: all you need is the router and a browser.</span></span></blockquote>
<span style="color: blue;"><i>Does the new vyacht firmware implement a full Signal K server, or like the iKommunicate act as a gateway device translating NMEA and Seatalk data into Signal K deltas?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">Its a full Signal K server that serves the full format and the delta of updates.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">It might be lacking some implementation details such as the full blown set of own boat data, some engine data or receiving of 3rd party Signal K data as an input.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">I await user feedback on where to invest more to close the gaps.</span></span></blockquote>
<span style="color: blue;"><i> Have you based the server implementation on the Signal K reference servers or written your own from the specifications?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">I used the node server as a reference at times but actually wrote mine from the specifications. There is a difference between the specification and the two reference servers, so nothing is set in stone as things change often in Signal K.</span></span></blockquote>
<span style="color: blue;"><i> Last year you suggested to the Signal K team that they look at popular IoT transports for use with Signal K. Does your new firmware implement MQTT or CoAP?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">No. Maybe as a gateway to Signal K if it starts to make sense.</span></span></blockquote>
<span style="color: blue;"><i> Are there any incompatibilities or notable differences in operation or functionality between the vyacht Signal K implementation and that of the reference servers?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">The node reference server is different from the Java server. The vyacht server which is written in pure C is probably slightly different from either of them.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">There are also many web servers implementations out there which are all very different from each other but which communicate with any web browser using HTML.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">I successfully tested interoperability e.g. of the instrument panel and the vyacht server.</span></span></blockquote>
<span style="color: blue;"><i> Is conversion from NMEA protocols to Signal K one way or can the vyacht router send Signal K deltas on its NMEA output?</i></span>
<br />
<blockquote class="tr_bq">
<span style="background-color: white; font-family: inherit;">It would be a 2 line change in the software to enable that if someone asks for it, but Signal K is quite chatty and I'd expect performance issues over a serial interface such as an NMEA 0183 output.</span></blockquote>
<span style="color: blue;"><i> Signal K is still a "work in progress". How often do you anticipate having to update the vyacht firmware to keep pace with developments?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Probably more often than most users would like. They just want to have something ready to work and not install firmware updates.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">Its still impossible for a non-developer and time consuming even for a developer to get started on this project.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">At least for components like the instrument panel my main effort is almost like that of any Linux package maintainer: pick out the stable parts and package them in a usable way.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">The real advantage of vyacht for Signal K is that vyacht makes Signal K very accessible to users by being pre-installed and supported.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">What I deliver is just there and works out of the box.</span></span></blockquote>
<span style="color: blue;"><i> Your latest firmware works with Navionics sonarchart live. How did you implement that?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">It was just a matter of experimenting and making it configurable for the end user: broadcasting standard NMEA 0183 sentences via UDP on port 2000 and making sure timestamps for GPS data were correct.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span class="im">In the end Navionics even supported me based on user demand. I probably messed up their community charts quite a bit though with all the artificially generated test data that I used to make it work.</span></span> </blockquote>
<h2>
Signal K</h2>
<span style="color: blue;"><i>What do you believe the impact of Signal K will be on marine electronics and software?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;">Signal K or at least the ideas behind it will completely change marine electronics and software.</span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">The marine hardware industry and the NMEA are light years behind any other industry, in a nice comfort zone delivering technically outdated overly expensive equipment to customers used to spending a lot of money.</span></span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">This is changing already without Signal K. First of all its not driven by an industry any more but by many individual enthusiasts. It all started with us just bringing to our own boats what we felt was normal everywhere else already: accessibility and availability everywhere, communication, ease of use and affordability.</span></span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Today you can get better-than-ever racing or weather routing software almost for free and made by extremely experienced sailing pros. You had to spend some thousand $ for this just 2 years ago.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Signal K itself is not only about networking on a boat. The web, Facebook and the iPhone refined our expectations about how things should work. And Signal K, vyacht and many others take this and refine how electronics should work on boats and maybe even more important: between boats.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Sure, there is a way to go still, but we have come a long way already and large vendors sleep tight. It currently feels a bit like the web around 1995. All the companies, software and stores we know today were born then or after that. Almost none of the older ones are relevant to the web today.</span></span></blockquote>
<span style="color: blue;"><i> Do you see Signal K as a potential alternative to NMEA protocols, or would an “open” marine network require a protocol better suited to constrained devices?</i></span>
<br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Signal K is not an alternative to the NMEA protocols. Signal K is a complement or amendment to NMEA. Like a NMEA 2.0 for web. This is probably why the NMEA as an association recognised Signal K.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Signal K is designed for the web and the communication between a browser and a web service. Its unsuitable for communication with a sonar.</span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white;">Signal K is perfect for the communication between a vyacht router and an iPad or tablet but too web-centric for even powerful constrained devices.</span></span></blockquote>
<span style="color: blue;"><i> As a commercial manufacturer, what aspects of Signal K do you think would benefit most from further development?</i></span>
<br />
<blockquote>
<ol>
<li><span style="background-color: white; font-family: inherit;">Make it easy for normal boat folks who are not software engineers to set it up and run. We need to build a wider community and attract all those not so deeply technical boat folks out there who can drive it forward.</span></li>
<li><span style="background-color: white; font-family: inherit;">Reduce the protocol's chattiness and redundancies as well as clean out and document the overall structure for a better understanding and higher level of suitability for smaller devices.</span></li>
<li><span style="background-color: white; font-family: inherit;">Signal K suffers from the same unclear semantics, data life time and data cycle issues that the NMEA 0183 protocol suffers from which NMEA 2000 partially fixes: that needs to be improved.</span></li>
<li><span style="background-color: white; font-family: inherit;">Cut ties with the NMEA and remove references to legacy NMEA protocols in Signal K.</span></li>
<li><span style="font-family: inherit;">Signal K needs to become (more) open.</span></li>
</ol>
<span style="font-family: inherit;"><span style="background-color: white;">The last points are maybe the most important ones: </span></span>The decision making process in Signal K is quite closed and focused on the core development group. That isn't optimal for gaining active participation in development of a new and open standard. Open standards give every participant equal voting rights.</blockquote>
<blockquote>
<span style="font-family: inherit;"><span class="im">Also you can't really distinguish between the reference implementation and the specification. I think the reference implementation and not the community is driving the protocol specification.</span></span> </blockquote>
<blockquote>
<span style="font-family: inherit;"><span style="background-color: white;">Signal K needs to decide if it wants to be a piece of software or a standard that changes the industry. Currently its the software. And in the past 20 years I have seen many good standards going down the drain by making this mistake.</span></span></blockquote>
<blockquote>
<span style="font-family: inherit;"><span style="background-color: white;">I know from talking to a lot of small vendors that they are waiting to see how things will go for Signal K. Some have even implemented it but haven't released it due to concerns they share.</span></span></blockquote>
<blockquote>
<span style="font-family: inherit;"><span style="background-color: white;">As long as nobody moves or they move in different directions we obviously don't get anywhere. If 100 or even just 20 software, app and hardware developers all move in the same direction, then we will change the marine software and hardware landscape quickly for the benefit of both us young marine electronics and software folks and all the boat enthusiasts out there.</span></span></blockquote>
<div class="yj6qo ajU" style="cursor: pointer; outline: none; padding: 10px 0px; width: 22px;">
</div>
</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-2827086757969750822015-10-29T00:59:00.000-07:002015-10-29T05:27:33.201-07:00iKommunicate<h3>
People in Tha Middle</h3>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-SbV6Xx3j2gA/VjEZvvMiGGI/AAAAAAAAAK4/NWFHtdUzkEU/s1600/ik.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-SbV6Xx3j2gA/VjEZvvMiGGI/AAAAAAAAAK4/NWFHtdUzkEU/s1600/ik.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Last friday <a href="https://groups.google.com/forum/#!topic/signalk/INVKKlB7GfA">a post</a> on the <a href="https://groups.google.com/forum/#!forum/signalk">Signal K google group</a> announced a <a href="https://www.kickstarter.com/projects/1689846268/ikommunicate-gateway-enabling-the-internet-of-thin">kickstarter campaign</a> for the first commercial NMEA-to-signal-K gateway to be announced. The <a href="http://ikommunicate.com/">iKommunicate</a> has been prototyped by <a href="http://digitalyacht.co.uk/">Digital Yacht</a>, a company whose track record includes being one of the earliest to market with <a href="http://www.digitalyachtamerica.com/index.php/en/products/interfacing/nmea-to-wifi-adaptors">NMEA-to-wireless-IP converters</a>. iKommunicate features an NMEA-2000 interface, two NMEA-0183 interfaces and an ethernet interface. NMEA data are converted to <a href="http://signalk.org/">Signal K format</a> which is then available for Signal K client applications to query.</div>
<div>
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-R8qwqhhMzlY/VjHnPtBJmnI/AAAAAAAAALI/onoMQYMnbU0/s1600/paulsumpner.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://1.bp.blogspot.com/-R8qwqhhMzlY/VjHnPtBJmnI/AAAAAAAAALI/onoMQYMnbU0/s320/paulsumpner.jpg" width="320" /></a></div>
<br /></div>
<div>
<br /></div>
<div>
Paul Sumpner is Digital Yacht's CTO. We had talked about Signal K at the London Boat Show in January and when I read the iKommunicate announcement I mailed him to ask if he'd mind answering a few questions about it. He very kindly agreed.....<br />
<br /></div>
<h3>
Digital Yacht and Signal K</h3>
<div>
<br /></div>
<div>
<i style="color: blue; font-family: inherit;">P</i><i style="color: blue;"><span style="font-family: inherit;">aul, Digital Yacht were instrumental in popularising the use of “NMEA-0183-over-IP”
with their NMEA-to-wifi bridges. What do you believe will be the most
significant driver for Signal K supplanting this as data format of
choice for app developers?</span></i></div>
<div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="letter-spacing: normal;"><span style="font-style: normal;">NMEA-0183
over IP was a good initial solution and for some people will be quite
satisfactory, but for the developer there is still the issue of
getting the NMEA0183 information, the cost of the spec and NMEA
membership puts a lot of developers off and also they have to support
a relatively specialist and old protocol. </span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="color: black;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">The
driver for Signal K will be the NMEA2000 data that is not supported
in NMEA0183, such as Engine data which until now has been
inaccessible to all but a very few developers and once developers get
their hands on this data, I think we will see some really interesting
and innovative apps.</span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue;"><span style="font-family: inherit; letter-spacing: normal;"><i>There
are currently very few apps which can use Signal K data and almost
none which can only use Signal K as a data source. Who do you see as
the early adopters who will buy the first tranche of iKommunicates?</i></span></span></div>
<blockquote class="tr_bq">
<span style="color: black;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">I
think once a couple of apps that have a large user base, such as
Active Captain or OpenCPN fully release with Signal K support (both
have beta releases) then I think iKommunicate will be in demand.
Michael Zapf the developer of the popular NMEARemote Instrument App
is the first iOS developer to support SK and we will be contacting
other iOS and Android App developers about Signal K and iKommunicate.</span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><span style="color: blue;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><i>A
kickstarter campaign is an unusual method for an established business
</i></span></span></span><span style="color: blue;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><i>l</i></span></span></span><span style="color: blue;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><i>ike
Digital Yacht to fund a new product and your $20,000 target surely can't cover
development costs. Did you take this approach to mitigate risk in
building a product with unknown demand, to create a pre-release buzz
or for another reason?</i></span></span></span></span></div>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="color: black;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><span style="font-style: normal;">I<span style="background-color: #f3f3f3;">t
is very easy to look at Kickstarter and just see it as a way of
getting funding for start-ups but I think any company can benefit
from using this medium. If you are developing a completely new and
unique product or trying to break in to a new market, then Kickstarter is a great way to promote your new initiative, gain
feedback on whether there is a market for your new product/service
and to get directly in contact with the early adopters in that market</span></span></span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3;"><span style="color: black;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><span style="font-family: inherit; font-style: normal;">Apart
from the time and effort in setting up the campaign, there are no
other costs and if it turns out that no one likes your new
product/service and you do not achieve funding, then you have avoided
wasting a lot more time and effort developing a product/service that
no one will buy. This is our first Kickstarter campaign and we would
certainly use it again.</span></span></span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue;"><span style="font-family: Times-Roman, serif;"><span style="font-family: inherit; letter-spacing: normal;"><i>The
kickstarter campaign was launched only days ago but you are more than
a quarter of the way to achieving funding (I will be surprised if
it's not at least “half” by the time you receive this). In the
unlikely event that you don't meet your target, what would be the
trigger for Digital Yacht to revisit iKommunicate in future?</i></span></span></span></div>
<div style="letter-spacing: normal; line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<blockquote class="tr_bq">
<span style="color: black;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">You
are right, as I am writing this answer, we have just broken the 50%
funding target, so fingers crossed we will reach and hopefully exceed
our original $20,000 target. Even if we do not reach our target, we
hate wasting development time and effort, so we will probably
regurgitate the work we have done in to some other new product in the
future, but it would be a real shame as I think what Signal K is
trying to achieve would be good for our industry.</span></span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue;"><span style="font-family: Times-Roman, serif;"><span style="font-family: inherit; letter-spacing: normal;"><i>Even
at the full $299 SRP, the iKommunicate is competitively priced
compared with some other NMEA-to-IP bridge products. Is it worth
buying for its N2K/NMEA-0183 ethernet bridging and multiplexing
capabilities alone?</i></span></span></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<blockquote class="tr_bq">
<span style="color: black;"><span style="font-family: Times-Roman, serif;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">Absolutely,
we have really tried to make iKommunicate competitively priced and
straight out of the box it will be a very powerful NMEA2000 and
NMEA0183 to ethernet bridge, supplying data to many existing apps and
software packages over TCP or UDP. Then as Signal K becomes more and
more established, iKommunicate can simultaneously supply other
devices on the network with the Signal K data.</span></span></span></span></blockquote>
<span style="font-family: inherit;"><br /></span>
<h3>
<span style="font-family: inherit;">iKommunicate Product Details</span></h3>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div style="font-style: normal; letter-spacing: normal; line-height: 100%; margin-bottom: 0in;">
<i style="color: blue; font-family: Times-Roman, serif;"><span style="color: blue; font-family: inherit;">Does
iKommunicate implement a complete Signal K server, and if so were
compromises needed to make it run in only 1MB memory?</span></i></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="letter-spacing: normal;"><span style="font-style: normal;">The
differences between a Signal K server and a Signal K gateway are
somewhat blurred and some Signal K developers would argue that there
should be no difference between them. I don't entirely agree with
this and designed iKommunicate to be primarily a gateway but also
capable of being a basic Signal K server.</span></span></span> </span></blockquote>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-FyBoHd0g80E/VjEWMgV2QtI/AAAAAAAAAKw/Y68xJRdeIVI/s1600/Signal%2BK%2BSmart%2BGateway%2BDiagram.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" height="311" src="http://3.bp.blogspot.com/-FyBoHd0g80E/VjEWMgV2QtI/AAAAAAAAAKw/Y68xJRdeIVI/s320/Signal%2BK%2BSmart%2BGateway%2BDiagram.png" width="320" /></span></a></div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="letter-spacing: normal;"><span style="font-style: normal;">My
own view is that in a smaller boat, you will probably just have an
iKommunicate and some Apps (Signal K "consumers") that will
use the data. So in this instance, iKommunicate is the Signal K
server.</span></span></span> </span></blockquote>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-DiufvbXozPE/VjEWDjM9CvI/AAAAAAAAAKo/kbKtu15Vf_U/s1600/Signal%2BK%2BServer%2B%252B%2BGateway%2BDiagram.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" height="280" src="http://3.bp.blogspot.com/-DiufvbXozPE/VjEWDjM9CvI/AAAAAAAAAKo/kbKtu15Vf_U/s320/Signal%2BK%2BServer%2B%252B%2BGateway%2BDiagram.png" width="320" /></span></a></div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="letter-spacing: normal;"><span style="font-style: normal;">On
a larger boat, you may have an iKommunicate </span><i>and</i><span style="font-style: normal;"> a Signal K server
where iKommunicate is just a gateway converting the NMEA data in to
Signal K but the server is taking this data, managing it and then
serving it up to the apps or sending it to the cloud.</span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="letter-spacing: normal;"><span style="font-style: normal;">iKommunicate
has been designed to be a very efficient gateway and a low power
server, capable of hosting some simple web apps, but not capable of
running sophisticated apps, with charts, messaging, logging, etc. We
are not running LINUX on iKommunicate, just native C code on an ARM
M4 Cortex processor and currently we are not even using half of the
1MB of memory, even when receiving 300+ AIS targets.</span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="letter-spacing: normal;"><span style="font-style: normal;">So
rather than compromises, we feel that a number of new and different
design decisions were taken with iKommunicate and I am very happy
with how our "proof of concept" has performed and been
received.</span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="color: black;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">I
think a full blown Signal K server needs to run an OS, which is an
overhead that requires a faster processor and more memory, but you
get access to loads of software services and utilities, making it so
much easier to do really powerful and innovative functions and
features. That is why the Raspberry Pi, Beagle Board and other COTs
hardware solutions have been initially used as the basis for Signal K
servers.</span></span></span></blockquote>
<span style="color: blue; font-family: inherit;"><i>Does iKommunicate store vessel state (gleaned from NMEA inputs) in an internal data model, or simply dynamically translate NMEA PGNs/sentences into delta format with Signal K context which are then supplied to all websocket clients? And are there any static data supported/query-able in the initial release?</i></span><br />
<pre></pre>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;">iKommunicate has a Signal K namespace memory in which it retains the latest values of all the NMEA data that has been received including AIS data (other Vessels). When a NMEA sentence of PGN is received, it updates the namespace and sends out a Signal K delta file. If an HTTP: restAPI GET request comes in, then this is extracted from the namespace and output as SIgnal K HTTP.<br /> <br />We will have an option in the iKommunicate web config page called "Manage Own Data" or similar and this will make the iKommunicate responsible for populating all of the Signal K "Self" data. The static Own/Self data will be populated where possible automatically from the NMEA data or the user can enter the data manually like Boat Name, Dimensions, MMSI, etc.</span></blockquote>
</div>
<div>
<span style="font-family: inherit;"><br /></span>
<div style="line-height: 100%; margin-bottom: 0in;">
<i style="color: blue;"><span style="font-family: inherit;">What
(if any) are the major differences between Digital Yacht's Signal K server
implementation and the reference open source server?</span></i></div>
<blockquote class="tr_bq">
<span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">The
main differences are:</span></span></span></span></blockquote>
<blockquote class="tr_bq">
<ol>
<li><span style="background-color: #f3f3f3; font-family: inherit;">iKommunicate connects directly to the NMEA2000 network, rather than
via a 3rd party NMEA2000 to USB gateway.</span></li>
<li><span style="background-color: #f3f3f3; font-family: inherit;">iKommunicate is a LAN rather than a WAN device and another server or
app is required to handle the external transmission and reception of
the Signal K data in to the internet. </span></li>
<li><span style="background-color: #f3f3f3; font-family: inherit;">iKommunicate (at least in Version 1) does not support subscription
websockets, it simply sends all "delta" files through the
websocket i.e. every time a new NMEA PGN or Sentence is received it
transmits a Signal K "delta" file. The idea with
subscriptions is that the app asks for specific data and the server
remembers what data the app is interested in and only sends this data
when it changes</span></li>
</ol>
</blockquote>
<div style="font-style: normal; letter-spacing: normal; line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue; font-size: small;"><span style="font-family: inherit; letter-spacing: normal;"><i>Is
the flow of information through iKommunicate “one-way” or can
data be passed back to the NMEA side, e.g. to control an autopilot?</i></span></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">In
Version 1 of iKommunicate there is only data flowing from the NMEA
networks to Signal K, apart from the minimum NMEA2000 network<br /> </span></span></span></span><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">interaction
i.e. address claiming, heartbeat PGN, etc. We will be adding
bi-directional NMEA communication though in a future firmware
release, which by the way is designed to be really easy to update;
either by uploading an update via its built-in web interface,
downloading directly from the internet or copying it to the internal
SD card.</span></span></span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue; font-size: small;"><span style="font-family: inherit; letter-spacing: normal;"><i>Security
is something that has been discussed more than directly implemented
in Signal K. What (if any) security challenges will iKommunicate
address in its initial implementation and what do you intend to
address in future firmware updates?</i></span></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">The
security of the "Internet of Things" in general is being
discussed ad infinitum by many, many technology companies and
organisations and still has some way to go before the procedures,
tools and mechanisms are in place for a secure "IoT" world.
The Signal K team could have wasted a lot of time and effort on
security and it was felt that, at least for Version 1 of Signal K and
iKommunicate, that the issue of security should be left with the Apps
and Services that were taking Signal K data from the boat and
transmitting it in to the internet.</span></span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">In
reality every boat has a large and very good security "firewall",
the open sea they are sailing on, and for the vast majority of Signal
K users, the data will stay firmly on the boat, at least until more
apps and services become available. On larger commercial vessels and
super yachts, there will already be a secure and protected network
onboard which Signal K can hide behind, as after all it is just
normal network data.</span></span></span></span> </span></blockquote>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">We
are following closely how the security of the "IoT" is
progressing outside of the marine world, in particular open source
initiatives such as Let's Encrypt (</span></span></span></span><span style="color: #0000e9;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;"><u>https://letsencrypt.org/</u></span></span></span></span><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">)
to create free SSL certificates. As and when a clear security
solution for "IoT" appears, we will aim to include it in
Signal K.</span></span></span></span></span></blockquote>
<span style="font-family: inherit;"><br /></span>
<div style="line-height: 100%; margin-bottom: 0in;">
<h3>
<span style="font-family: inherit;">Future Direction</span></h3>
<div>
<span style="font-family: inherit;"><br /></span></div>
</div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue; font-size: small;"><span style="font-family: inherit; letter-spacing: normal;"><i>At
this stage Signal K complements rather than replaces NMEA protocols,
with products like iKommunicate providing the necessary bridge. How
much harder / more expensive (if at all) would it be to implement a
sensor (e.g. GPS, Heading) outputting “native” Signal K (in its
current form) than one which outputs NMEA-0183 or N2K (or, dare I
mention, OneNet?)</i></span></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue; font-size: small;"><span style="font-family: inherit; letter-spacing: normal;"><i><br /></i></span></span></div>
<blockquote class="tr_bq">
<span style="background-color: #f3f3f3; font-family: inherit;"><span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="font-style: normal;">Any
"smart" sensor that has a microprocessor, rather than just
a transducer inside, could in theory be a S</span></span></span></span><span style="color: black;">i</span><span style="color: black;">gnal
K sensor. In component cost terms there is a bit of a step up from
NMEA0183 to Signal K, but the difference between an NMEA2000
interface and a Signal K interface is very small and in fact it might
actually be cheaper to do a Signal K interface.</span> </span></blockquote>
<blockquote class="tr_bq">
<span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">You
would really want the Signal K sensor to use PoE (Power over
Ethernet) which will add some additional component cost but it is not
completely out of the question, I am not sure it will be Digital
Yacht, but I am sure we will see Signal K sensors before too long.</span></span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue; font-size: small;"><span style="font-family: inherit; letter-spacing: normal;"><i>If
iKommunicate proves successful, what other Signal K products are Digital Yacht considering?</i></span></span></div>
<blockquote class="tr_bq">
<span style="color: black;"><span style="font-size: small;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">We
intentionally did not include Wi-Fi in the first version of
iKommunicate, as we felt that most early adopters would be pretty
technical users and most likely have their own wireless network
onboard already, but a wireless iKommunicate would be useful for
smaller boats, so that is definitely on our future product roadmap,
as is a J1939 version for direct connection to engines that do not
natively use NMEA2000. As for anything else, assuming Signal K is the
success we hope it will be, let us just say "watch this space"
!</span></span></span></span></blockquote>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="color: blue; font-size: small;"><span style="font-family: inherit; letter-spacing: normal;"><i>As well as implementing Signal K in its products, do you see Digital Yacht (and
indeed other commercial organisations) taking an active role in
Signal K development?</i></span></span></div>
<blockquote class="tr_bq">
<span style="font-size: small;"><span style="letter-spacing: normal;"><span style="background-color: #f3f3f3; font-family: inherit; font-style: normal;">I
hope so and Digital Yacht certainly intend to be an active
contributor to Signal K. There are challenges for commercial
companies to be involved in "Open Source" projects and I am
sure, a certain level of dis-trust from the purist Open Source
community members, but there are benefits for both sides and as long
as commercial companies put in as much (or more) as they take out,
then successful results can be achieved.</span></span></span></blockquote>
<span style="font-family: inherit;"><br /></span>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;"><br /></span></div>
<div style="line-height: 100%; margin-bottom: 0in;">
<span style="font-family: inherit;">Many thanks to Paul for taking the time to share this. As I write this, just 5 days into the kickstarter campaign and with 47 days still to go iKommunicate has reached nearly 4 times its funding target with more than 340 units spoken for and the number climbing all the time. Seems like iKommunicate will be a real product and Signal K does have a commercial market.</span></div>
</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-47138504122449893042015-10-28T06:20:00.004-07:002015-10-29T03:29:08.384-07:00Signal K revisited (part 2)<h3>
Talking 'Bout a Revolution</h3>
<div>
<br /></div>
<a href="http://signalk.org/">Signal K </a>isn't what I was looking for last year when seeking an "NMEA protocol alternative". The problem to be solved is how to interface software with sensors and devices on a boat when those sensors and devices use a closed communications protocol whose owners want a (to many independent developers prohibitively high) fee for its use and forbid its use in free software. Wireless networks, tablets and smart phones are now commonplace on boats. A good solution opens the gateway to even more applications, potentially revolutionising the way many people interact with their vessels.<br />
<br />
I believed the solution was a new protocol satisfying the constraints of current NMEA implementations (compact, friendly to resource-limited devices and low-powered networks, easily implemented in low level languages) but running over Internet Protocol and free and open rather than proprietary. I was initially disappointed that Signal K isn't that thing but I started to like it a lot more once I accepted that and appreciated it for what it is.<br />
<br />
<h3>
Communications Breakdown</h3>
<div>
<br /></div>
<div>
Signal K addresses the same problem in a different way. It's a way of representing the state of a vessel and a format for transfer of all or part of that state to a client application. It isn't oriented to minimal resource on low powered devices. Instead it is built to provide data to applications running on consumer devices over full-fat wifi or ethernet networks and is geared towards functionality rather than minimalism.</div>
<div>
<br /></div>
<div>
A "Signal K server" is an entity which acts as an aggregator for information inputs which can come from a variety of sources using any protocols which the Signal K server understands. It uses these data and static information which the user has manually input to create a model of the "state" of the boat and potentially other vessels around it. In early iterations of Signal K, client applications would update themselves on boat data by regularly transferring the server's internal data model. As Signal K progressed a method of transferring only new data was adopted (the "delta format") and a method of "subscribing" to updates of particular data. The transport by which data are transferred is not mandated, although there is now a method of querying the available transports (over http). A reliable transport is occasionally assumed and the de facto standard transport as used in the reference server implementation seems to be websockets.<br />
<br />
What back-end protocols does a Signal K server understand? This is implementation dependent. The Signal K project defines the architecture and provides a reference implementation (in <a href="https://github.com/SignalK/signalk-server-java">java</a> and <a href="https://github.com/SignalK/signalk-server-node">javascript</a>) but the architecture could be implemented by others differently.<br />
<br />
The reference server includes providers which can interpret NMEA-0183 and the output of the <a href="https://github.com/canboat/canboat/wiki/analyzer">canboat analyzer</a>, the latter enabling those with a method of reading NMEA-2000 PGNs (the A<a href="http://www.actisense.com/products/nmea-2000/ngt-1/ngt-1.html">ctisense NGT-1</a>) to interpret some N2K data.<br />
<br />
<h3>
You're Not the One (I was looking for)</h3>
<div>
<br /></div>
I don't care for monolithic central server architectures, nor of putting extra steps between data producers and data consumers but the data model I initially disliked has many practical advantages. Although the security implementation is a little sketchy at present it offers the potential for sophisticated access control (like a directory server) allowing detailed specification of who has access to what. It allows clients to specify how often they want to update their data rather than being passive consumers. The reality is also that for a while yet our sensors and other marine devices are still going to be talking (a variety of) proprietary protocols rather than open ones so translation will be needed, and the Signal K server provides a straight forward pluggable architecture for that. I'm not a fan of the (to my mind) unnecessary overhead of http / websockets but this is not a concern in the typical Signal K use case, it simplifies coding in the higher level languages that most app developers use, and the Signal K developers would argue that those transports are not <i>required</i> (despite them being de facto standards).<br />
<br />
<h3>
Picture This</h3>
<div>
<br /></div>
<div>
There's currently plenty of details which aren't currently filled in with Signal K. The most common data have standard representations but much does not. In many cases this is just a matter of time and work which but much of this needs to be done for Signal K to realise its potential. It is frequently argued that Signal K's JSON format makes it infinitely extensible but it is not without some challenges.</div>
<div>
</div>
<div>
A problem for current NMEA protocols is that they have no standard way of representing imaging data from RADAR and Sonar, relying instead on individual manufacturer's proprietary protocols. Signal K doesn't yet solve this. Representing image data in a text-based protocol generally requires encoding which makes high bandwidth data even more bloated. One proposal to address this has been to use Signal K only to transport the URL of a binary imaging data source which would then be connected to by other means.</div>
<div>
<br /></div>
<div>
Signal K has had many of its rough edges smoothed in the past six months, but it is still a work in progress.<br />
<br /></div>
<h3>
Safe From Harm</h3>
<div>
<br /></div>
<div>
Security doesn't feature much in traditional marine data communications. Most people are aware that that has to change as marine devices become accessible from outside the closed environment of a boat's internal wiring. There are many aspects to "security" including authentication (proving something says what it says it is), authorisation (saying who can do or see what) and encryption (concealing things from prying eyes). Using a Signal K server rather than devices publishing data directly to the network allows for a great deal of control over who has access to what. This potential is not yet well realised, but the architecture should be well suited to it.</div>
<div>
<br /></div>
<div>
Authentication and encryption are the more glamorous aspects of "security" and have been extensively discussed on the Signal K google group but with no definitive mechanisms yet mandated. The use of web protocols should allow a huge range of well-proven systems to be leveraged but possibly due to a reticence to <i>mandate</i> transports for Signal K, reliance hasn't been put on readily available security mechanisms associated with those transports. I can't help but wonder if standardising on the transports which people are currently using Signal K with and restricting the problem space might result in a more full-featured solution for the common use case rather than an unconstrained but less well defined product.<br />
<br /></div>
<h3>
Welcome to the Machine</h3>
<div>
<br /></div>
<div>
Signal K still has a few details to be filled in but it certainly has great potential in its primary use case: providing data from NMEA devices to mobile and web applications and enabling such applications to communicate with each other using the same, extensible format. I feel confident that it will gain considerably popularity over the next year. It lacks compactness and the tight specification to be ideal as a <i>replacement</i> for NMEA protocols but that's not where it is targeted. It is a complement to those protocols. The biggest initial driver to adoption is likely to be the ability to represent NMEA-2000 data, much of which can't be represented in the currently popular "NMEA-0183-over-IP" format. Due to <a href="https://en.wikipedia.org/wiki/CAN_bus">CAN </a>interfaces (as used by NMEA-2000) being less trivial than <a href="https://en.wikipedia.org/wiki/RS-422">RS-422 </a>interfaces (as used by NMEA-018) and only part of NMEA-2000 having been reverse engineered, this is where commercial NMEA-to-Signal K gateways (whose vendors have access to the complete NMEA-2000 specification) come in as part of the architecture now embraced by the Signal K team and the NMEA alike. The average user will need to buy such a device to link their Signal K applications to their boat network.</div>
</div>
<div>
<br /></div>
<div>
The big news this week is that Digital Yacht have just announced potentially the first commercial NMEA-to-Signal-K gateway: the <a href="http://ikommunicate.com/">iKommunicate</a> Even more exciting (well, for me anyway), Digital Yacht CTO Paul Sumpner has kindly agreed to answer some questions on the new product and Signal K. Stay tuned!</div>
<div>
<br /></div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-49618636093164793982015-09-29T06:56:00.002-07:002015-10-29T15:11:17.484-07:00Marine Data Transports Re-visitedLast year I wrote <a href="http://stripydog.blogspot.co.uk/2014/01/cape-multicast-logical-route.html">a post</a> in which I extolled the virtues of UDP multicast for transmission of sensor information within a boat network. Whilst that conclusion still stands in theory, real world practice is somewhat different when it comes to 802.11 wireless networks.<br />
<br />
In my <a href="http://stripydog.blogspot.co.uk/2015/01/radar-over-wifi-not-always-pretty.html">post on transmission of RADAR data over wireless networks</a>, I mentioned that at layer 2 (the "datalink layer" in the <a href="https://en.wikipedia.org/wiki/OSI_model">OSI network model</a>) "wifi" multicast packets (of which broadcast are a special case) are not acknowledged by the receiving end whereas unicast packets (those explicitly sent to one receiving station) are, so the sending station knows when it must retransmit a dropped packet. Some may say "but isn't UDP <i>always</i> unreliable and unacknowledged?". At the transport layer yes but the 802.11 ("wifi") frames that these packets are transported in don't care about the transport layer. "Wifi" is far more "lossy" than transmission over copper cable, so 802.11 addresses this where it can by acknowledgements and retransmissions. This is not possible for multicast (/broadcast) packets, but is for unicast.<br />
<br />
In using my <a href="http://www.stripydog.com/kplex/examples/piap.html">homebrew Raspberry Pi 2-based access poin</a>t/data server I was noticing the GPS fix regularly dropping out in OpenCPN and AIS targets taking a long time to appear. Some testing showed appallingly bad reliability of transmission using UDP broadcast.<br />
<br />
The test was simple. A MacBook Pro (the receiving station) was a wireless client of the Pi access point and located 2 metres from it in the saloon of my GRP boat. The Pi was running kplex and, at that point, transmitting only GPS information from a directly attached <a href="http://www.adafruit.com/products/746">Adafruit Ultimate GPS</a> at a rate of 6 sentences per second. The access point was not connected to the Internet and thus other traffic was minimal. There are few access points visible on the Mac, and only the Pi transmitting on its chosen channel.<br />
<br />
tcpdump was run simultaneously on the Pi and the Mac to record the number of "NMEA-0183" packets transmitted and received respectively over UDP broadcast during a 10 minute period. Packet loss was then calculated: 96%!<br />
<br />
The test was then repeated but with kplex transmitting packets via UDP unicast. This time packet loss was, as expected, 0%.<br />
<br />
It should be remembered that this was a home-brew access point solution using a low cost USB dongle and I'd be interested to hear of other people's experiences with commercial access points, especially expensive "marine" units like <a href="http://www.simrad-yachting.com/en-GB/Products/NSS-Touchscreen-Navigation/WIFI-1-module-en-gb.aspx">Navico's Wifi-1</a>. I note that Brookhouse Online, manufacturers of the "<a href="http://brookhouseonline.com/imux.htm">iMux</a>" commercial multiplexer, <a href="http://brookhouseonline.com/pdf%20files/Important%20wifi%20considerations%20for%20NMEA%200183%20multiplexers.pdf">state that</a> "UDP is unsuitable for transmission of navigation data" (although I'll argue that actually they mean "UDP broadcast over wifi").<br />
<br />
Meantime though, 96% packet loss clearly makes broadcast/multicast over wifi non-viable. The alternatives?<br />
<br />
<ul>
<li>Use TCP. Easy. Well supported</li>
<li>Use UDP unicast. Client addresses must be known in advance or some (currently non-existent) subscribe/publish protocol needs to be developed for marine data</li>
<li>Use an access point which implements UDP multicast over 802.11 unicast (as discussed in the <a href="http://stripydog.blogspot.co.uk/2015/01/radar-over-wifi-not-always-pretty.html">RADAR post</a>). Support for this is rare, as is support for NMEA-0183 data over multicast.</li>
</ul>
<div>
For most people the solution for now would seem to be to use TCP for delivering marine data over wireless networks.</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com0tag:blogger.com,1999:blog-9190270992063734806.post-84734310160602559902015-08-13T07:24:00.000-07:002017-03-24T02:16:38.269-07:00Navionics SonarChart™ Live on Android<h3>
Skip to the good bit</h3>
<div>
For a quick hack to get SonarChart™ Live on android working with a home-brew or "unsupported" serial-to-wifi solution without the background, jump <a href="#GoodBit">here</a>.</div>
<div>
<br /></div>
<h3>
How Deep Is Your Love?</h3>
<div>
A few months back a kplex user made me aware of a new feature in <a href="http://www.navionics.com/en/mobile-pc-app">Navionics Boating</a>: <a href="http://www.navionics.com/en/sonarchart-live">SonarChart™ Live</a>. This is a new feature in Navionics which enables users to generate bathymetric maps using current (hence, presumably, "Live") depth information from their own instruments. More specifically, data provided via selected partners' products. </div>
<div>
<br /></div>
<div>
Anthony was trying to work out how to feed depth information via kplex to Navionics. He'd done some investigation of the iOS version of Navionics and determined that the app was trying to contact fixed IP addresses and ports associated with the default set-up of the various "supported" partner products. In subsequent analysis of the app I also noticed references to the <a href="https://en.wikipedia.org/wiki/Bonjour_(software)">bonjour</a> services associated with <a href="https://www.gofreemarine.com/media/gofree-tier-1-networking-specification.pdf">GoFree</a> (_nmea-0183._tcp) and <a href="https://www.vespermarine.com/">Vesper</a> (_vesper-nmea0183._tcp).</div>
<div>
<br /></div>
<div>
By setting up his pi to emulate the <a href="http://digitalyacht.net/2015/04/16/digital-yacht-sonar-server-plus-navionics-app-allows-real-time-bathymetry/">Digital Yacht Sonar Server</a>, Anthony managed to feed depth information into Navionics from kplex but I thought that there must be a better way to achieve this so I emailed Navionics to ask how Navionics Boating users with existing serial-to-wifi solutions could realise the benefits of this exciting new feature. Not possible came the reply, and no they wouldn't reveal how their "automatic" connection worked:</div>
<div>
<blockquote class="tr_bq">
<span style="color: #073763;"><span style="font-size: small;">We have developed at code level this features together with our partners. </span><span style="font-size: small;">We do not open it externally at the moment and there's not any future plan to do it.</span></span></blockquote>
I asked for this to be escalated to product management as surely they'd want as many people as possible to enjoy this feature. I was promised a reply but despite several prompts over the following weeks one never came.<br />
<br />
<h3>
Echoes</h3>
<div>
A few days ago my android phone prompted me to upgrade Navionics Boating. The android version previously didn't support SonarChart™ Live but now it does, so despite my disinclination to allow the draconian new permission requirements (access to all my accounts? Make phone calls? Access to my contacts? Why?) I upgraded. With my Raymarine plotter bridging my seatalk-1 depth sounder's data to NMEA, converted to wifi by kplex running on my r<a href="http://www.stripydog.com/kplex/examples/piap.html">aspberry pi access point</a>, I started experimenting.</div>
<div>
<br /></div>
<h3>
Say Hello</h3>
<div>
First up...would advertising _nmea-0183._tcp as Navico's GoFree does tell Navionics to look for depth data in the right place? I installed <a href="http://avahi.org/">avahi</a> (the linux bonjour implementation) and configured a service, creating a file <span style="font-family: "courier new" , "courier" , monospace;">/etc/avahi/services/kplex.service</span> as follows:<br />
<br /></div>
<div>
<div style="font-family: Menlo; font-size: 11px;">
<?xml version="1.0" standalone='no'?><!--*-nxml-*--></div>
<div style="font-family: Menlo; font-size: 11px;">
<!DOCTYPE service-group SYSTEM "avahi-service.dtd"></div>
<div style="font-family: Menlo; font-size: 11px; min-height: 13px;">
<br /></div>
<div style="font-family: Menlo; font-size: 11px;">
<service-group></div>
<div style="font-family: Menlo; font-size: 11px;">
<name replace-wildcards="yes">%h NMEA</name></div>
<div style="font-family: Menlo; font-size: 11px; min-height: 13px;">
<br /></div>
<div style="font-family: Menlo; font-size: 11px;">
<service></div>
<div style="font-family: Menlo; font-size: 11px;">
<type>_nmea-0183._tcp</type></div>
<div style="font-family: Menlo; font-size: 11px;">
<port>11010</port></div>
<div style="font-family: Menlo; font-size: 11px;">
</service></div>
<br />
<div style="font-family: Menlo; font-size: 11px;">
</service-group></div>
<div style="font-family: Menlo; font-size: 11px;">
<br /></div>
</div>
<div>
No joy. For good measure I also tried configuring the _vesper-nmea0183._tcp service. Still nothing.</div>
<div>
<br /></div>
<h3>
Listen Like Thieves</h3>
<div>
<br /></div>
<div>
Some network snooping showed the phone attempting to connect to 192.168.0.10 on port 10110. This was the only address I could see it trying apart from an immense volume of traffic to <a href="https://en.wikipedia.org/wiki/MarkMonitor">MarkMonitor</a> (apparently a "brand protection" company), <a href="https://en.wikipedia.org/wiki/Flurry_(company)">Flurry</a> and <a href="https://aws.amazon.com/">Amazon Web Services</a> (presumably Navionics's servers). Good to know how they're using your bandwidth and exploiting all those security privileges then.</div>
</div>
<div>
<br /></div>
<div>
My pi is set up as a router (so will move traffic from one interface to another) so I ran up a secondary interface, assigned it the address 192.168.0.10, restarted kplex (which was implementing a tcp server on all interfaces), restarted Navionics boating and Bingo! SonarChart™ Live functionality.</div>
<div>
<br /></div>
<h3>
My Name Is</h3>
<div>
By curious co-incidence 192.168.0.10 is the first DHCP address handed out by the Navico GoFree <a href="http://www.simrad-yachting.com/en/Products/NSS-Touchscreen-Navigation/WIFI-1-module-en-us.aspx">Wifi-1</a> in default configuration and would often be the address handed out to a plotter (distributing GoFree data) on a Navico network. Further experimentation whilst attempting to emulate a Navico network revealed something bizarre. Without the 192.168.0.10 address configured, if the SSID of the network the phone connects to contains the string "GoFree" (e.g. "GoFree-1234") and a data service on 192.168.0.10 is not available, the Navionics app throws up a screen asking the user to input the address for the source of depth information. Port is not configurable and seems to be fixed at 10110 but inputting the pi NMEA server's address once again gave me SonarChart™ Live functionality.</div>
<div>
<br /></div>
<div>
This seems to be a very crude method of attempting to limit the data servers which can be used with SonarChart™ Live given that SSID is configurable and some GoFree wifi-1 users will have doubtless changed theirs from default. Knowing less about the set-up of other supported data servers (e.g. <a href="http://www.sonarphone.mobi/">Vexilar T-Box</a>, <a href="http://raymarine.com/view/?id=11198">Raymarine Dragonfly</a>) I have not investigated whether default SSID plays a part in presuming them to be sources of data.<br />
<br />
<h3>
Disco 2000</h3>
So what of UDP? For some reason Digital Yacht's products have used 2000 as a port for their wireless NMEA servers in the past. I've had a hard time finding a manual for their SonarServer (one of the Navionics "SonarChart" supported products). I tried UDP broadcasts from kplex on port 10110 to no avail but changing the port to 2000 once again yielded success.<br />
<br />
<h3>
Where's Your Head At?</h3>
</div>
<div>
Interestingly Navionics Boating seems to be parsing GPS data it is being sent over wifi. Turn off location services on android and the app doesn't know your position when it fires up. Turn on wireless data which includes GPS as well as depth sentences and your position is plotted. This should be of particular interest to people who bought duff mobile devices which don't include an integrated GPS chipset.<br />
<h3>
Different Trains</h3>
</div>
<div>
It seems to be the case that the iOS version of Navionics may well function differently from the android one in how it determines where its data comes from. Bonjour is well established on Apple platforms but Network Service Discovery was only added in android 4.1. On the other hand "wifi multicast reception" is one of the (many, many) privileges Boating requests on android. Sadly I don't have an iOS device with Navionics to play with in order to learn more.</div>
<div>
<br /></div>
<div>
As Navico's use of bonjour as one of the two ways they advertise their GoFree data service isn't a bad plan, I've decided to retain my avahi configuration on the pi for the time being.</div>
<br />
<h3>
<a name="GoodBit">
The First Cut is the Deepest</a></h3>
<div>
So how best to get SonarChart™ Live on android to use our home-brew data server? You could run up an interface on 192.168.0.10 but the easiest solution would appear to be one of the following.<br />
<br />
If you prefer to access your data over TCP, change your SSID to something with the string "GoFree" in it, e.g. "GoFree-1234" and run an nmea server on port 10110. When you open Navionics Boating it will ask you for the address of your server, tell it, and you can start using SonarCharts™ Live.<br />
<br />
Otherwise broadcast your data over UDP port 2000.<br />
<br />
If anyone has a better suggestion on how to achieve this with either the android or iOS versions of Navionics Boating, please do post a comment below.</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com20tag:blogger.com,1999:blog-9190270992063734806.post-6019306695872266642015-05-20T14:24:00.000-07:002015-05-20T16:11:24.933-07:00Signal K Revisted (Part 1)<h2>
NMEA Press Release</h2>
A <a href="http://www.panbo.com/archives/2015/05/nmea_okays_signal_k_a_milestone_in_marine_electronics.html">Panbo article</a> a few days ago announced a <a href="http://www.nmea.org/content/nmea_signal_k/nmea_signal_k.asp">statement on the NMEA's website</a> "recognizing" Signal K. The text is as follows:
<br />
<blockquote class="tr_bq">
<i><span style="font-size: x-small;">NMEA Recognition of Signal K Open Source Project
NMEA recognizes the Signal K Open Source project as it serves the need and creates a method that allows both large and small mobile app developers to get involved with NMEA networking. NMEA will recognize this through the means of a NMEA 2000 certified gateway as it does for all other protocols. Signal K developers will need to use a NMEA 2000 certified and fire-walled gateway for the physical interface- either stand-alone or built within a display. This protects the NMEA Intellectual Property and the investments of years of development by many manufacturers worldwide. This method allows the NMEA Intellectual Property to be locked by the gateway as stated in the NMEA 2000 License Agreement. Only this style gateway can perform the translation from NMEA 2000 to Signal K. The gateway requirements are defined in NMEA 2000 Appendix H "3RD Party Gateway Requirements”. This potential new gateway is treated by NMEA no differently than any other certified gateway on the market, such as a NMEA 2000 to J1939 as an example. If NMEA members wish to get involved in Signal K, more information is available at <a href="http://signalk.org/">http://signalk.org</a> </span></i></blockquote>
<br />
Supporters of Signal K including <a href="http://themarineinstallersrant.blogspot.co.uk/2015/05/signal-k-faqs.html">Bill Bishop</a> are very excited about this "recognition" but what is actually being said here? There has never been a barrier to commercial organisations buying the NMEA 2000 specification and producing an NMEA-to-SignalK (or any other data format) gateway and stumping up the cash to get it certified. The NMEA don't seem to be doing anything new to facilitate production of such a gateway. If anything, this statement appears to be a warning against producing "uncertified" bridges.
A <a href="http://www.nmea.org/Assets/nmea%20signal%20k%20recognition.pdf">memo on the NMEA's web site</a> to the Signal K team clarifies this somewhat. Following discussions with the Signal K team they had agreed to make the web site statement but
<br />
<blockquote class="tr_bq">
<span style="font-size: x-small;"><i>not do a press release or a member mailing regarding Signal K as previously discussed. NMEA will not use the words “Support”, “Endorse”, or “Partner With” in this web announcement. </i></span></blockquote>
The NMEA will be providing the core Signal K developers with a platform at <a href="http://www.metstrade.com/mets/">METS</a> to discuss Signal K with NMEA members.<br />
<br />
What does it all mean? Given the NMEA's reputed affinity for the legal profession, although this web posting doesn't actually <i>say anything</i> it might be as close to the "endorsement" they say it definitely isn't as we might hope to see. Both Actisense (reported in the Panbo article) and Digital Yacht (from conversations at the London Boat Show earlier this year) have been following the Signal K project with interest and tacit acceptance of it by the NMEA is hoped to be the trigger for more concrete product development from such companies.<br />
<br />
For companies making gateways this presents the possibility of new products and hence revenue. For the NMEA this represents revenue from certification of new products and arguably protection of intellectual property as open source and small commercial developers will have an "official" alternative to reverse-engineered data formats.<br />
<br />
For the average boater?
Perhaps a hope would be stimulus to app development but development of boating applications doesn't seem to have been completely hindered to date by the legal grey area surrounding <a href="http://stripydog.blogspot.co.uk/2015/03/nmea-0183-over-ip-unwritten-rules-for.html">NMEA-0183-over-IP</a> which is almost universally used. Commercial availability of NMEA-2000-to-SignalK gateways would doubtless encourage adoption of SignalK by developers but will consumers care if their data arrives on their iThing in a different format?<br />
<br />
Probably not if it's the same data, but possibly if it's data that weren't previously available. NMEA-0183 has no standard representation for many types of data that may exist on an NMEA-2000 bus. NMEA 2000-to-0183 gateways don't tend to convert much of the engine management data, tank level data etc. available on an NMEA-2000 network. Signal K is not so constrained and a commercial NMEA-2000-to-SignalK gateway could pass all these data. More data availability opens the door to more applications.<br />
<br />
More widespread adoption of Signal K may also promote development of apps which exploit novel features of it, such as the "social boating" aspect and sharing of data between craft. Is that a good thing which the punters will be queuing up for? Don't ask me: I'm so anti-social I don't even have a twitter account.<br />
<br />
Although initially sceptical that the announcement really says nothing at all, I do concur that this "recognition" does indeed represent a significant advancement of the Signal K cause.<br />
<br />
Since my <a href="http://stripydog.blogspot.com/2014/09/signalk.html">previous post about Signal K last year</a> have I concluded that it's <a href="http://en.wiktionary.org/wiki/greatest_thing_since_sliced_bread#English">the best thing since sliced bread</a>? More in part two although I confess that I'm not all that keen on sliced bread.Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-69433451400280855882015-03-21T11:35:00.001-07:002015-03-21T12:02:48.434-07:00NMEA-0183 over- IP: The unwritten rules for programmersAn <a href="http://stripydog.blogspot.co.uk/2014/01/the-curious-world-of-marine-data.html">earlier post</a> presented a subjective overview of the current non-standardised use of the application layer of NMEA-0183 by independent and open source developers. As discussed there, NMEA-0183 is a proprietary "whole stack" protocol running over serial lines. While a proprietary standard method for transporting the highest layer of this protocol over IP networks does exist, it is not a standard used by open source programmers or indeed the vast majority of people writing marine data applications today.<br />
<div>
<br /></div>
<div>
This post is aimed at people writing applications which produce or consume marine data and wondering how to maximise their interoperability with other applications. To re-emphasise: there <i>are</i> no agreed rules. The basis for this post is 3 years of observing "how everyone else does it" and hacking and debugging networking with both <a href="http://www.stripydog.com/kplex/">kplex</a> and <a href="http://opencpn.org/">OpenCPN</a> in the context of other data sources and consumers.</div>
<div>
<br /></div>
<h2>
The Basics</h2>
<div>
The canonical publicly-available reference for NMEA-0183 is Eric Raymond's "<a href="http://www.catb.org/gpsd/NMEA.html">NMEA Revealed</a>". This post will not attempt to repeat the contents of that document and familiarity with the structure of NMEA-0183 as explained there will be assumed for the remainder of this post. Here we focus on how other application developers commonly put that information over Internet Protocol.</div>
<div>
<br /></div>
<div>
For open source programmers, purchasing the NMEA-0183 protocol document is probably not an option: publishing source code based on the standard may be considered a violation of copyright in some countries. I attempted to clarify this with the NMEA's legal department but they declined to reply to my email.</div>
<div>
<br /></div>
<h2>
Application Layer Structure</h2>
<div>
Application layer structure tends to be almost identical to the documented serial line standard.</div>
<h3>
Start</h3>
<div>
The starting "$" or "!" is always included as part of the transmitted sentence. You should expect it when receiving and produce it when transmitting.</div>
<h3>
Body</h3>
<div>
Not all applications enforce correct line length but there should be no need to exceed what many sources cite as the maximum of 80 characters including the initial "!" or "$" but excluding terminating line delimiters. Applications should expect longer lines to be rejected by receiving applications and there is generally no reason <i>not</i> to reject longer lines.</div>
<div>
<br /></div>
<div>
At time of writing neither OpenCPN nor kplex makes specific checks for "illegal" characters in sentence bodies. Legal vs. illegal NMEA-0183 characters do not seem well documented in publicly available texts. "$", "!", "*", the line feed character <LF> and carriage return <CR> are all likely to be used by parsers to divide up sentences. </div>
<h3>
Line termination</h3>
<div>
Significant variation seems to exist in what applications transmit. The "correct" NMEA-0183 sentence termination sequence <CR><LF> (carriage-return linefeed, 0x0D0x0A) is most common (and used by OpenCPN), should be accepted by all parsers, and should be used to terminate sentences when transmitting data. Some applications terminate sentences with just a <LF> and I've encountered one android application which transmitted GPS sentences terminated with just a <CR>. For maximum compatibility, receiving applications should accept lines terminated with <CR> <b>or</b> <LF> and ignore subsequent characters until one marking the start of new data of interest (i.e. "$", "!" or (if supporting TAG blocks) "\"). </div>
<h3>
Parsing</h3>
<div>
The <i>wrong</i> way to parse data is to do what kplex did in early iterations: Assume everything between two <CR><LF> sequences constitutes a sentence and and then check this string for "correct" structure. A better way (used by current (at time of writing) versions of OpenCPN and kplex) is to ignore all characters until a "!" or "$" marking the beginning of a sentence (or "\" denoting the beginning of a TAG block if supporting them) then read characters until the end of the sentence and ignore everything after a terminating <CR> or <LF> delimiter until a new start of data character is seen.</div>
<div>
<br /></div>
<div>
Publicly available documents describing the introduction of TAG blocks in version 4 of the standard state that TAG blocks will be ignored by pre-existing NMEA-0183 parsers. This tends to imply that the latter method is "correct". Under that scheme TAG blocks will be ignored if not specifically supported. Use of the latter scheme will also mean sentences are not rejected if inter-sentence line noise results in serial-to-IP converters inserting spurious characters into a data stream and will make accommodation of multiple line terminators (i.e. any combination of <CR> and <LF>) easier to code.</div>
<h3>
TAG blocks</h3>
<div>
TAG blocks as detailed <a href="http://www.nmea.org/Assets/may%2009%20rtcm%200183_v400.pdf">here</a> and <a href="http://www.nmea.org/Assets/0183_errata_tag_block_final.pdf">here</a>, are not widely supported but it has been reported that at least one hardware multiplexer aimed at recreational boaters produces them. OpenCPN's parsing strips TAG blocks. kplex recognises them, validates them, then discards them but is also capable of producing some TAG blocks. If not explicitly supporting them, applications should ensure their parsing routines will silently discard TAG blocks without discarding the associated sentence, as discussed above. If your application produces TAG blocks, providing an option to disable them may be useful in case the user has another application whose parsing rules have problems with them.</div>
<h2>
Transport and Network Layers</h2>
<h3>
Network Layer</h3>
<div>
A well-structured post would work its way down the stack (or up) but let's get the network layer out of the way first. It's IPv4. With the exception of kplex I am not aware of any marine devices or applications which explicitly support NMEA-0183 over IPv6. IPv6 <i>may</i> be <i>implicitly</i> supported on some platforms where the development framework takes care of the dirty networking details. It is not supported by OpenCPN. To date out of hundreds of kplex users I have corresponded with, only one was using IPv6. Do support IPv6 just because it's the decent thing to do. Just don't expect anyone to use it.</div>
<h3>
Transport Layer</h3>
<div>
The majority of applications and devices expect data to be transmitted and received over either UDP broadcast or TCP. For maximum interoperability both of these methods should be supported. In a <a href="http://stripydog.blogspot.co.uk/2014/01/cape-multicast-logical-route.html">previous post</a> I advocated UDP multicast as the optimum transport for NMEA-0183-style data. OpenCPN supports this. Kplex supports it. Very little else seems to. Please do implement it: it really isn't hard (the update to OpenCPN to support it was trivial) but as with IPv6, don't expect people to thank you for Doing The Right Thing.</div>
<div>
<br /></div>
<div>
UDP unicast is supported by some devices and applications. It seems to be the preferred method for sending data to some AIS consolidation sites although most of these (including <a href="http://www.marinetraffic.com/">marine traffic</a>) also seem to support TCP connections.</div>
<h3>
Packetization</h3>
<div>
Is that even a word?</div>
<div>
<br /></div>
<div>
TCP is a stream-based protocol so we simply write to it as we would a serial line and let TCP worry about dividing up the data (with a small caveat discussed later). For UDP the question arises how we should break sentences between datagrams. Should we write one sentence per datagram or fill a datagram with sentences before sending? This question is generally not relevant to interoperability. Receivers I have examined simply read data from a socket without being concerned about packet boundaries. The choice of how to send is usually one of expediency. Sending one sentence per packet incurs a higher degree of network protocol overhead relative to the amount of data sent. Buffering packets to send multiple packets in a single datagram introduces delay. The latter approach is also more difficult as it requires awareness of the maximum size of a datagram if fragmentation is to be avoided. Assuming that a datagram can accommodate 82 bytes of a single NMEA-0183 sentence is not unreasonable. The low data rates generally associated with NMEA-0183 mean that additional protocol overhead from one sentence per packet should not put undue load on a network. As this is easier to code and involves less delay this approach is my choice.</div>
<div>
<br /></div>
<div>
One exception to this is transmission of multi-sentence AIS data. As sentences have to be reassembled, no additional delay is introduced by buffering parts of a multi-sentence AIS message. Some AIS data consolidation sites such as <a href="http://localizatodo.com/">localizatodo.com</a> which do not support separate ports for each client rely on all parts of the message being transmitted in a single packet for the message to be correctly reassembled. Few applications seem to concern themselves with buffering multi-sentence AIS messages to send in a single datagram.</div>
<div>
<br /></div>
<div>
In summary: for maximum compatibility ignore packet boundaries when reading. With the exception mentioned above, how you packetize over UDP shouldn't affect compatibility but one sentence per packet would be my preferred choice.</div>
<h3>
Port</h3>
<div>
10110 is the port the NMEA have <a href="http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml">registered with the IANA </a>for data over both UDP and TCP. 10110 is used as the default port by OpenCPN but there is a wide range of ports used by other devices and applications so this should always be user configurable. Kplex's approach is first to use a user-defined port. If none is specified it looks for "nmea-0183" in the system services database and if not found falls back to a default of 10110.</div>
<h3>
Network Addresses</h3>
<h4>
Broadcast</h4>
<div>
Some devices and applications seem to follow the often-frowned-upon practice of sending broadcast data to the broadcast address of the zero network, i.e. to 255.255.255.255. Better practice is to use the sending system's subnet broadcast address.</div>
<div>
<br /></div>
<div>
Applications and devices receiving UDP are rarely coded to care about the address to which data it receives was sent and with the exception of kplex, every application I have seen simply binds a receiving UDP socket to INADDR_ANY. kplex can of course be told to do things like listen on a particular network interface which OpenCPN cannot. To my knowledge, no-one has raised this as an issue for OpenCPN and in most environments end users simply won't care.</div>
<h4>
Multicast</h4>
<div>
Ignoring the proprietary IEC-61162-4 standard, there is no default or commonly agreed multicast group for NMEA-0183 over IP used by open source applications or devices aimed at recreational boaters. This should therefore be end-user configurable. If picking a default I would choose one from the IPv4 organisation-local range (239.192.0.0/14 as described in <a href="https://tools.ietf.org/html/rfc2365">RFC 2365</a>) or the site-local IPv6 range (ffx5::/16 as described in <a href="http://tools.ietf.org/html/rfc4291#section-2.7">RFC 4291</a>)</div>
<h3>
TCP Considerations</h3>
<h4>
Nagle Algorithm</h4>
<div>
If you accept the arguments given for sending one sentence per UDP packet, you'll also want to set TCP_NODELAY on sending TCP sockets. kplex and OpenCPN do this. Network analysis of some other devices suggests that they don't. To disable the Nagle algorithm or not makes no difference to interoperability.</div>
<h2>
Service Discovery</h2>
<div>
UDP broadcast does not require service discovery. There is no subscribe/publish mechanism for a client to request NMEA-0183 data over unicast UDP from a server so there is no need for service discovery for UDP.</div>
<div>
<br /></div>
<div>
For TCP, finding a server for NMEA-0183 data on the network can be an issue in end users' boat networks where devices are configured with dynamic addresses.</div>
<div>
<br /></div>
<div>
Products intended for use under Navico's "<a href="http://www.navico.com/navico-brands/GoFree/">GoFree</a>" brand are the only ones I am aware of making use of service discovery for locating NMEA-0183 data sources. GoFree uses two service discovery mechanisms. One is Apple's <a href="http://en.wikipedia.org/wiki/Bonjour_(software)">bonjour</a> mechanism with services announced as "_nmea-0183._tcp". The other is Navico's own JSON-based service announcements sent to multicast group 239.2.1.1 port 2052 as detailed in their "<a href="http://www.lowrance.com/Global/Lowrance/Documents/GoFree%20Tier%201%20Networking%20Specification.pdf">tier 1" specification document</a>. </div>
<div>
<br /></div>
<div>
Applications should not assume that any programs other than those specifically designed to work with GoFree support such service discovery. OpenCPN does not (either as client or server). kplex can listen for Navico service announcements in order to locate a server, but does not advertise itself using them.</div>
<div>
<br /></div>
<div>
As a more generic and widely supported protocol, applications which do wish to leverage service discovery should probably opt for bonjour with the service "_nmea-0183._tcp"<br />
<h2>
Miscellaneous</h2>
</div>
<h3>
What about baud rate?</h3>
<div>
The answer may be obvious but I have seen this question asked so it is worth addressing. This isn't an issue. Baud is simply the transmission rate used on a serial line. It is not a property of the data which is transmitted. The slowest rates commonly used on IP networks today, wired or wireless, are many times faster than the fastest speeds NMEA data are commonly transmitted over serial lines. Generally speaking programmers don't have to worry about transmission rates for this kind of data over IP.</div>
<h3>
Is ethernet different from wireless?</h3>
<div>
As far as the average application programmer is concerned? No. In some cases the physical medium over which some kinds of marine data is transmitted can matter as discussed in the <a href="http://stripydog.blogspot.com/2015/01/radar-over-wifi-not-always-pretty.html">previous post</a>. At the kinds of data rates at which NMEA-0183 is transmitted the programmer should not need to care whether their application is running on a wired or wireless network.</div>
<h2>
Summary</h2>
<div>
For maximum interoperability with other applications, applications using the application layer of NMEA-0183 over IP should:</div>
<div>
<ul>
<li>Use UDP broadcast and TCP over IPv4 as transports</li>
<li>Use ASCII strings as they would be sent over a serial line with no additional encapsulation, starting from an initial "!" or "$", ending with the sequence <CR><LF>.</li>
<li>Use NMEA-0183 checksums</li>
<li>Accept sentences terminated with <CR> or <LF> and ignore all subsequent data until the start of a new sentence</li>
<li>Observe a maximum sentence length of 80 characters excluding the line termination characters</li>
<li>Use a default but configurable port of 10110 for both UDP and TCP</li>
<li>Ensure that TAG blocks, if not supported, are gracefully ignored without discarded their associated sentences</li>
</ul>
<div>
But it would also be nice if applications:</div>
</div>
<div>
<ul>
<li>Support UDP multicast</li>
<li>Support IPv6 as well as IPv4</li>
<li>Send data as soon as usable information is available for sending: One sentence or all sentences forming part of a multi-sentence message in one datagram in the case of UDP, Nagle algorithm disabled in the case of TCP</li>
<li>Use subnet broadcast addresses rather than 255.255.255.255 when sending IPv4 broadcast</li>
</ul>
</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com3tag:blogger.com,1999:blog-9190270992063734806.post-62594504240370740262015-01-30T09:55:00.000-08:002015-03-03T04:02:45.380-08:00RADAR over wifi: Not always a pretty picture<a href="http://opencpn.org/ocpn/">OpenCPN</a> plugins support overlay of imaging from some <a href="http://opencpn.org/ocpn/garmin_radar">Garmin</a> and <a href="http://opencpn.org/ocpn/navico_radar">Navico</a> RADAR units. Unfortunately some users attempting to use these plugins over wireless networks on their boats have encountered issues. Not only does it not work very well, it can make the whole wireless network unusable. Moreover where people bridge a wireless segment to their wired network (e.g. with a simple domestic access point/switch/router) the wireless network can become unusable when the radar is switched on even if nothing on the wireless side is using it. What's going on and what can be done to resolve it?<br />
<div>
<br /></div>
<h3>
Why RADAR imaging might not mix well with wireless</h3>
<div>
The problem is with the way images are transmitted by the types of RADAR which OpenCPN plugins support (and probably others). These RADAR images are not transmitted using standard NMEA protocols: The data rate is too high even for NMEA 2000. Instead manufacturers transmit RADAR images using proprietary methods over Internet Protocol running on 100Mb/s copper ethernet. Crucially manufacturers tend to use <a href="http://en.wikipedia.org/wiki/User_Datagram_Protocol">UDP</a> <a href="http://en.wikipedia.org/wiki/Multicast">multicast</a>, sending data to multiple receivers at once (as opposed to "unicast", or sending to a single receiver). In a <a href="http://stripydog.blogspot.co.uk/2014/01/cape-multicast-logical-route.html">previous post</a> I extolled the virtues of multicast for transmission of boat data. It allows all computers who have subscribed to a given multicast group to see the same data without them being replicated to each client. Sending RADAR data over multicast on an ethernet network as the manufacturer intends works well. Sending it over wifi is another matter.<br />
<br />
The issue is not simply that the data rates are too high to be handled by wireless networks. Navico <a href="http://www.simrad-yachting.com/Root/Simrad-Yachting-GoFree/GoFree%20Advanced%20Setup.pdf">state</a> that their RADAR transmits at "up to 8 Megabits per second" which seems to concur with what users have <a href="http://www.cruisersforum.com/forums/f134/opencpn-simrad-lowrance-radar-overlay-plugin-123167-4.html#post1581154">observed</a>. Surely this is within the capabilities of most modern wireless networks?<br />
<br />
Unfortunately a <a href="http://en.wikipedia.org/wiki/Wireless_access_point">wireless access point</a> has a number of "known unknowns" to deal with when transmitting to associated stations on a wireless network including the distance of the station from the transmitter, objects in between and interference in the environment which makes the task more complex than it is with copper wires. The <a href="http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers">IEEE</a> <a href="http://en.wikipedia.org/wiki/IEEE_802.11">802.11</a> standards on which common wireless networks are based each define a <a href="http://www.intel.com/support/wireless/wlan/sb/CS-025321.htm">number of data rates</a>. Transmissions at lower data rates tends to be more robust than those at higher rates. Typically an access point will dynamically adjust the rate at which it sends data to each associated station based on packet loss (where transmitted frames are unacknowledged by the receiver at the <a href="http://en.wikipedia.org/wiki/Link_layer">link layer</a>). The connection between a "150 Mb/s" access point and a "150 Mb/s" laptop may be considerably lower than 150 Mb/s if the laptop is far away from the access point with intervening obstacles and/or there is interference from other devices in the environment.<br />
<br />
Multicast (and broadcast) data must be sent at a rate which all listeners can be assumed to reliably receive. Standards dictate that multicast should generally be sent using a rate in the "basic rate set" (the set of rates which all clients are assumed to support). Although not universally the case, many retail access points will use the lowest of these rates, often 1Mb/s. This of course is the physical data rate. Various overheads mean that the rate of transmission of useful information will be be even less than that.<br />
<br />
On top of this, multicast over wireless is more prone to packet loss than unicast. Unlike ethernet, unicast 802.11 frames are normally acknowledged by receivers allowing them to be re-sent if they are lost in what is an inherently less reliable medium than copper wires. Multicast frames are not usually acknowledged so aren't retransmitted if a receiver loses them. Another potential source of packet loss with high data rate multicast is the buffering that occurs on an access point when some stations on the network are in power saving mode, although without information on the sizes of buffers involved in a given access point it is difficult to assess the likely impact of this.<br />
<br />
Note that these issues don't mean that multicast is a bad choice for "normal" NMEA-0183-style data. In those cases data rates are far lower, should not significantly impact the wireless network, and by the repeated nature of transducer data, occasional dropped packets are not necessarily a problem. Remember also that broadcast data suffers from the same problems on wireless as multicast.<br />
<h3>
Why does RADAR stuff up all your other wireless data too?</h3>
</div>
<div>
If it's only the multicast which is constrained to be transmitted at 1Mb/s, why is your other wireless traffic badly impacted?</div>
<div>
<br /></div>
<div>
When transmitting multicast data the access point is operating at the multicast rate (e.g. 1Mb/s). Not only is there likely much more RADAR data than is involved in the average browsing session, the rules of contention for the radio give the multicast data an unfair advantage. The radio in the access point is likely spending most of its time at the lower data rate.</div>
<div>
<br /></div>
<h3>
Why does <i>wired</i> RADAR stuff up your wireless data when only <i>wired</i> devices are listening to it?</h3>
<div>
Your boat network may use an access point with an integrated <a href="http://en.wikipedia.org/wiki/Network_switch">switch</a> for wired devices or you may have a wireless access point connected to switch to which your wired devices are also connected.</div>
<div>
<br /></div>
<div>
A simple switch has no knowledge of what devices on the network need to receive multicast data, so it will send multicast (and broadcast) data out of all ports. This will include an attached wireless network, even if there are no wireless devices interested in receiving the multicast data.</div>
<div>
<br /></div>
<h3>
Preventing multicast getting onto your wireless segment</h3>
<div>
Some switches do offer a method of ensuring that they only send multicast data out of ports to which a device which wants to receive it is attached: "<a href="http://en.wikipedia.org/wiki/IGMP_snooping">IGMP snooping</a>". Whenever a program tells a computer that it wants to receive a particular group of multicast data, the computer will send an <a href="http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol">Internet Group Management Protocol (IGMP)</a> "report" message on the local network. Such messages are intended for routers which forward Internet Protocol (IP) packets between networks (e.g. your local network and your Internet connection) but some switches (which are generally link layer devices so know little of the higher level protocols carried in their data link frames) can listen for these reports and use the information to decide which switch ports to send multicast data out of.</div>
<div>
<br /></div>
<div>
Many high-end switches will have this functionality. Many low-end devices won't.</div>
<div>
<br /></div>
<h3>
Making RADAR work over wireless</h3>
<div>
Wireless networks are also a problem for those wanting to deliver <a href="http://en.wikipedia.org/wiki/IPTV">IPTV</a> (Television over Internet Protocol) using multicast so the problem has received extensive attention. A number of solutions have been proposed and implemented in various pieces of hardware. Retail access points are less likely to offer a solution than "Enterprise Class" (i.e. unaffordable) devices. Two relevant solutions which require only support from the access point are:</div>
<ul>
<li><b>Multicast-to-unicast translation</b>. Access points send multicast packets to clients requesting them via link layer unicast. In other words, IP packets to multicast groups are delivered in unicast 802.11 frames to the stations interested in receiving them and as such these frames are delivered reliably and at maximum reliable speed. This technique is variously implemented in some enterprise class access points using various methods. It is one of the subjects in the (currently not commonly implemented) IEEE 802.11aa and related 802.11v standards where it is referred to as "Directed Multicast Service" (DMS). Some implementations use IGMP snooping to determine which clients are interested in which multicast data. With 802.11v the client can request multicast to be delivered over unicast with DMS: a cleaner solution as the OSI layers aren't so mixed up but I haven't been able to find any hint of an API for this. DMS does not scale well which can be an issue for IPTV delivery, but on board where no more than two clients are likely to require RADAR data it is ideal.</li>
<li><b>Setting the multicast rate</b>. Some devices will allow you to explicitly set the "multicast rate". Setting this to a high value might make using RADAR over wifi viable. The downside is that as this is the minimum rate at which clients will be allowed to connect to the access point, the range at which the access point is usable will be reduced. In the average GRP yacht this will be a non-issue. Once again, this is more likely to be a feature on higher end equipment but is more likely to feature in consumer units than multicast-to-unicast translation. It may also be possible to implicitly alter the multicast rate by disabling certain modulation types.</li>
</ul>
<h3>
Which access points will work?</h3>
<div>
Without a RADAR unit to test or a multiplicity of access points to test I can only report what might work based on Internet research and reader feedback. Please do let me know if you have any relevant information. This section will be updated as new information is received.</div>
<div>
<br /></div>
<div>
"Enterprise Class" products capable of multicast-to-unicast are not generally found on boats so high end devices from the likes of Ruckus and Cisco are not considered here.</div>
<div>
<br />
<h4>
<a href="https://openwrt.org/">OpenWRT</a></h4>
</div>
<div>
The popular open source alternative firmware for a number of routers implemented multicast-to-unicast in the recent "Barrier Breaker 14.07" release.</div>
<h4>
<a href="https://www.apple.com/airport-extreme/">Apple Airport Extreme</a></h4>
<div>
This <a href="http://superuser.com/questions/255534/how-to-set-multicast-rate-on-apple-airport-extreme">apparently</a> allows the user to set the multicast rate. I will endeavour to test the effectiveness of this using simulated data.</div>
<h4>
<a href="http://www.simrad-yachting.com/en/Products/NSS-Touchscreen-Navigation/WIFI-1-module-en-us.aspx">Navico wifi-1</a></h4>
<div>
The <a href="http://www.simrad-yachting.com/Root/Simrad-Yachting-GoFree/GoFree_web_interface_settings.pdf">manual</a> for Navico's wifi-1 module describes an option of interest:<br />
<br />
<div class="page" title="Page 13">
<div class="layoutArea">
<div class="column">
<blockquote class="tr_bq">
<span style="font-family: 'Calibri'; font-size: 11.000000pt; font-weight: 700;">Multicast-to-Unicast:<br />
</span><span style="background-color: rgb(100.000000%, 100.000000%, 100.000000%); font-family: 'Calibri'; font-size: 11.000000pt;">IGMP snooping. Convert Multicast data to Unicast one.The default setting is "Enable". </span></blockquote>
I contacted Navico to clarify this. It seems that the "Multicast to Unicast" statement is a mistake. The wifi-1 <i>does</i> do IGMP snooping but only to keep unwanted multicast data off the wireless segment. According to Navico's product manager for the wifi-1 it <i>does not</i> do multicast to unicast translation at layer 2 and Navico do not support RADAR data over wireless.</div>
</div>
</div>
</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-57998027629668404742014-09-06T08:20:00.002-07:002014-09-06T08:46:11.598-07:00SignalKI'm one of the many people who believe that there is a desperate need for an open marine communications protocol. Basing communications on an unofficial description of a closed protocol running over lower layers the original was never intended for is a far-from-ideal situation. There are incompatibilities in implementations and no open, solid base to build other features of a protocol stack, like service discovery to eliminate much of the manual set-up involved in the current crop of ethernet/wifi based marine applications.<br />
<br />
The <a href="http://www.catb.org/gpsd/">GPSd</a> project has developed a <a href="http://www.catb.org/gpsd/gpsd_json.html">protocol</a> for transmission of GPS and AIS data. It is based on <a href="http://en.wikipedia.org/wiki/JSON">JSON</a> (Javascript Object Notation) which offers a number of advantages.<br />
<br />
<ul>
<li>It is human readable which is widely regarded as being beneficial when debugging systems</li>
<li>It is extensible</li>
<li>It is easily assimilated into many modern high-level languages, facilitating rapid application development</li>
</ul>
<div>
On the downside it requires more space to transmit than a binary format, requires more processing to parse and most significantly requires dynamic memory allocation which is resource inefficient and complicates processing, although much of that will be hidden from programmers in higher level languages. GPSd imposes some additional constraints on its JSON messages to allow for compact and efficient processing, notably a fixed maximum array size and disallowing the use of the NULL character: legal in JSON but traditionally a string termination character in C and some derived languages.<br />
<br />
GPSd is currently maintained by Eric Raymond, one of the biggest names in the Open Source movement whose work in publicising the details of NMEA-0183 has facilitated much of the software development which has leveraged that still-technically-closed protocol. It has a very large existing user base and would seem ideal as a starting point for a general NMEA-alternative protocol.<br />
<br />
GPSd as it stands is not a general purpose marine data communications protocol and direct <a href="http://stripydog.blogspot.co.uk/2014/01/we-come-onenet.html">OneNet </a>alternative. Most significantly the protocol only documents GPS and AIS related information although extending to other types of data would seem entirely feasible. The protocol is transport-agnostic. The gpsd program itself implements a tcp server although an add-on program (<a href="http://www.catb.org/gpsd/gps2udp.html">gps2udp</a>) can distribute gpsd data via UDP. Being unconcerned by lower layers is certainly good software architecture design and poses no problem for the general use case of gpsd but it may not be ideal in a network of autonomous sensors providing updates over multicast UDP as advocated in a <a href="http://stripydog.blogspot.co.uk/2014/01/cape-multicast-logical-route.html">previous post</a>. Here the imposition of limits on message length in order to fit into a single datagram may increase reliability and simplify processing.<br />
<br />
Other features not relevant to the core functionality of GPSd which might be considered desirable in a complete marine protocol suite would include a standard authentication method which does not require a connection-oriented link and some kind of service discovery mechanism.<br />
<br />
Looking further to investigate whether anyone was working on a more generalised communications protocol I was pointed in the direction of the <a href="http://signalk.github.io/">SignalK project</a>. SignalK, named after the single-flag signal <a href="http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Kilo.svg/220px-Kilo.svg.png">Kilo</a> ("I wish to communicate with you") is a concept being developed by a group which includes <a href="http://signalk.github.io/about.html">the developers of some popular open source marine projects</a>. It is, however, not a communications protocol but a data model for representing all information relating to a vessel and its environment. It proposes the use of JSON to convey information between SignalK systems but conceptually this is not a standalone protocol but a native method of sharing data in the common model. Although an example of the data representation envisaged for SignalK in the form of a <a href="http://signalk.github.io/api/gnss-field-guide.html">GNSS object</a> is given, the bulk of detail in the model has yet to be filled in with much of the discussion currently focusing on higher-level concepts. The project seems geared towards the idea of a central server holding a data representation which can be communicated to other servers locally or on other vessels as well as client applications. Project participants have argued that this does not preclude the concept of a distributed network of sensors providing independent asynchronous data updates but that area does not seem to be of primary concern.<br />
<br />
Does SignalK contain the protocol I'm looking for? It's too early to tell. The project is intended to be far more than a drop-in replacement for proprietary NMEA protocols but could this ultimately be a hinderance to adoption? Marine data communications has traditionally been very engineering-oriented. Implementation of high level object-oriented data models are facilitated by high level languages and communications abstractions (typically over connection-oriented links) but are such concepts going to be readily adopted by those programming limited-resource embedded systems in C? The future would appear to contain sensors with direct network attachment. Not all anemometers or GPS units are on boats. Should the way they communicate with the network be based on their place in a marine-specific data model?<br />
<br />
SignalK is certainly an interesting project with some very capable programmers as participants but it is not a simple OneNet alternative and perhaps this may ultimately be a hinderance to wider adoption.</div>
Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com2tag:blogger.com,1999:blog-9190270992063734806.post-82289181932080301192014-02-07T14:40:00.001-08:002014-02-09T04:15:50.785-08:00Raymarine Replykplex user Cardo posted a link to the previous article on <a href="https://www.facebook.com/Raymarine.EU?fref=ts">Raymarine's Facebook page</a>. Not only did this elicit a response from Raymarine's product support manager, he also copied the response to me in email.<br />
<div>
<br /></div>
<div>
The main part of the reply was a defence of Raymarine's wireless security, which I didn't criticise, saying only:</div>
<blockquote class="tr_bq">
<span style="background-color: white; color: #666666; font-family: 'Trebuchet MS', Trebuchet, Verdana, sans-serif; font-size: 13px; line-height: 18px;">All wireless security was off on the MFDs, presumably for show convenience as according to the manuals this is not the default. </span></blockquote>
My actual criticism was of the apparently redundant services running on the MFDs, but Raymarine's response is to assure us that these are all either part of "show mode" or deliberately enabled as part of the system's operation. The services have been tested and are all "benign". This does slightly miss the point that the objective of running fewest possible services is not to avoid those with known problems but to minimise the threat from the problems which you don't know about yet and can't test for.<br />
<br />
The other part of my criticism and what actually prompted me to write in the first place was the way in which mails to Raymarine simply weren't replied to. Did they really have to wait for someone to post something on social media to get back to me rather than just replying to me in private in the first place?<br />
<br />
I'll have to wait to see how one of these systems looks different in "normal" operation, but if anyone has one of these MFDs please do sick nmap on it and post the results as a comment.<br />
<br />
My guess about this being an off-the-shelf OS with services accidentally left running was incorrect. These services were deliberately enabled. I still find the idea that telnetd <i>and</i> sshd <i>and</i> ftpd are all required intriguing. Perhaps also whatever processes require NFS file sharing could enable the processes only when they have something to share and leave them disabled the rest of the time? <br />
<br />
As well as my Facebook reply, I also replied (at slightly greater length) by email and got a response re-iterating that all running services were necessary and that reasons why could not be discussed as the workings of Raymarine's software were confidential. The issue of default passwords which I raised in both replies was not addressed.<br />
<br />
So how much of a problem is this? <a href="http://www.bbc.co.uk/news/technology-25780908">Recent reports</a> have publicised "smart" devices such as fridges and TVs being targeted to be used as spam relays. A Raymarine MFD isn't a dumb piece of electronics, it's a full blown computer.<br />
<br />
To a large extent though Raymarine are right: this is a lot of fuss about nothing. The effect of idle, unused services like this on performance will be negligible. On the security front their MFDs have been engineered as a gadget which is not designed to be deployed in a "hostile" environment and in the main this is a fair assumption. The wireless networking on Raymarine's MFDs are not designed to play well with an existing wireless network which may be connected to the network: They create an isolated one for the specific reason of communicating with devices running Raymarine's own and partners' apps. Bad news for owners who then need to flip between wireless networks to view their instruments and browse the web, but also bad news for potential malware writers wanting to turn your MFD into a spam bot. Malware which first infects a user's PC, then targets the MFD (probably a different OS and architecture) then adjusts the routing table on the off chance that the user has connected their MFD's ethernet to an Internet connected network is, frankly, tenuous. Most consumers would doubtless prefer rich functionality over unnecessarily paranoid security. Really this is not something to get worked up about.<br />
<br />
It's only a matter of time however before connecting a boat's network to the Internet becomes the norm and MFDs start to be able to leverage data from the Internet in their operation (Grib downloads? Software updates?). Time will tell if the MFD of tomorrow looks a little more secure to the casual observer.Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com0tag:blogger.com,1999:blog-9190270992063734806.post-29310072131483010872014-01-30T10:54:00.000-08:002014-02-09T03:56:59.658-08:00Raymarine: Security FAIL, Customer Services FAILThree weeks ago I visited the London boat show with my laptop. My aim was try and test the <a href="http://www.panbo.com/archives/2013/08/wifi_mfds_navico_gofree_promises_more_than_met.html">GoFree</a> extensions to <a href="http://www.stripydog.com/kplex">kplex</a> but sadly <a href="http://www.navico.com/">Navico</a> weren't at the show. Stopping by the <a href="http://www.raymarine.co.uk/">Raymarine</a> stand I tried to confirm what I'd been told that the new Raymarine MFDs don't have an IP-based nmea-0183 server like the competition. Most of my boat's electronics are Raymarine, but my plotter is one of their older models which I may soon consider updating. Sadly there was no-one on the stand with any knowledge in this area so I asked the rep if he'd mind if I connected my laptop to an MFD to see for myself what services were available. I was told to help myself.<br />
<br />
All wireless security was off on the MFDs, presumably for show convenience as according to the manuals this is not the default. After connecting up to an <a href="http://www.raymarine.co.uk/view/?id=3021">e165</a> I listened for traffic (none), so with the consent of the rep on the stand I did a basic port scan (tcp only) to check for services.<br />
<br />
<pre>PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
111/tcp open rpcbind
2049/tcp open nfs
6000/tcp open X11
6668/tcp open irc
8080/tcp open http-proxy
50000/tcp open ibm-db2 </pre>
<pre> </pre>
I couldn't help but wonder whether services running on assigned ports were really what those ports are officially assigned to. The ftp port does indeed seem to have a copy of <a href="http://freecode.com/projects/tnftpd">tnftpd</a> running which supports anonymous accesss. <a href="https://matt.ucc.asn.au/dropbear/dropbear.html">Dropbear sshd</a> is running on 22 and both it and the telnet daemon running on 23 give a login prompt. There is indeed something serving http on 8080. I didn't poke the (apparent) X11 or irc ports but rpcbind is really a portmapper:<br />
<br />
<pre> program vers proto port service
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 52498 mountd
100005 1 tcp 35944 mountd
100005 2 udp 52498 mountd
100005 2 tcp 35944 mountd
100005 3 udp 52498 mountd
100005 3 tcp 35944 mountd
100024 1 udp 44953 status
100024 1 tcp 52967 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 2 udp 2049 nfs_acl
100227 3 udp 2049 nfs_acl
100021 1 udp 49439 nlockmgr
100021 3 udp 49439 nlockmgr
100021 4 udp 49439 nlockmgr
100021 1 tcp 40926 nlockmgr
100021 3 tcp 40926 nlockmgr
100021 4 tcp 40926 nlockmgr </pre>
<br />
Although running mountd, no network file systems are apparently exported.<br />
<br />
If you installed a standard Linux or other UNIX system from CD 15 years ago it would have come with all the services you would probably ever need running and waiting to be used. In a secure or business environment it would then be someone's job (often mine as it happens) to customise the installation process so that everything that wasn't needed was turned off. These days manufacturers are more security conscious and deliver systems with most services turned off by default and leave it to the customer to enable those which they den necessary.<br />
<br />
There's a lot of apparently unnecessary things here. Everything necessary for sharing file systems but no files shared. Notably, the telnet service is running. Telnet used to be the predominant protocol for command line login to systems up until the turn of the last century. Its problem is that everything, including passwords, is sent unencrypted so passwords are easily snooped by anyone listening in. Consequently it was superseded by the "secure shell" (ssh). ssh encrypts all communications and also performs other functions like file transfer and some nifty port forwarding. Use of telnet is deprecated these days so it is a surprise to see it running, especially when the ssh service is also running: Hard to imagine what telnet is needed for when ssh is there. Ssh also performs file transfer functions, so the ftp service (also running) might also appear to be unnecessary.<br />
<br />
Maybe there was a reason for all of this, but it seemed a sound hypothesis that Raymarine had simply concentrated on their app and forgotten to turn off unnecessary OS services. This is generally considered bad practice both from an efficiency point of view (idle services don't cause much system overhead, but they're still unnecessary) and a security perspective. They may not have any known security flaws, but they may have flaws which will be publicised at some point in the future. The fewer services you run, the less chance that you are running something that could give access to an attacker.<br />
<br />
I posted a question on <a href="http://raymarine.ning.com/">Raymarine's support forum</a> saying that I'd noticed apparently superfluous services running on their MFDs and was this perhaps an oversight. The post was immediately removed and I was contacted by a moderator who told me to post the question privately using their "<a href="http://www.raymarine.eu/knowledgebase/askraymarine.cfm">Ask Raymarine</a>" contact form.<br />
This I did and received a mail telling me that the query had been forwarded to their engineering department and I would receive a reply in due course.<br />
<br />
At this time I started thinking about writing a post about the differing approaches of the established computer industry and the marine electronics industry to software development and network security but thought it appropriate to wait for a response from Raymarine. If there was a sound explanation for these services, or if the issue was simply an acknowledged oversight which would be corrected in the next release then I didn't really have a story: errors happen in all organisations and don't necessarily indicate a problem of ethos. Failure to react on the other hand would indicate a culture that is worth questioning.<br />
<br />
A week went by with no reply so I mailed again, asking when I could expect a reply as I was considering writing an article related to my observations. This got the attention of their press office and I was quickly contacted to ask about my writing qualifications, what I was writing about and who I was writing for. I gave them the information they asked for and asked about the possibility of interviewing their head of product development about the approach to security in current future network-connected products, including any proposed OneNet security strategy.<br />
<br />
I received no reply. Another week passed. I mailed the press office back to ask how things now stood and was told that as my query did not relate to a system I had installed on my boat, I could not expect to receive a reply.<br />
<br />
I left it another week before posting this, just in case they decided to answer my original query. They didn't. <br />
<br />
Clearly I am personally disappointed. I wasted time following a procedure I was told to follow by a Raymarine representative, was told to expect a reply, was grilled for information about my background and then simply ignored. Not encouraging on the customer services front. Not good PR either, as a simple reply wouldn't have encouraged me to write about the company negatively.<br />
<br />
It does make me question their procedure for handling security reports, which large established software vendors will have. Do they have one? Did I not receive a reply because they believed that this was a non-issue but couldn't be bothered to reply to me, or because the question never reached the right people?<br />
<br />
The marine electronics industry has traditionally dealt in closed systems which people did not try to deliberately break for fun and profit. Are they now blundering like naifs into the connected world with the same approach? Unfortunately the system is no longer guaranteed to be closed. It may be connected to the Internet. A customer might unwittingly connect a malware infected PC to it. The person on the next boat may simply enjoy cracking wireless systems.<br />
<br />
For the past quarter century the mainstream computing industry has operated with the constraint that security cannot be simply an afterthought. What customer-impacting events will it take to bring the marine electronics industry into the 1990s?<br />
<br />Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-42101700336325303202014-01-16T10:52:00.002-08:002014-01-16T13:29:43.997-08:00We come OneNetAfter hopefully clarifying IPv6 for the uninitiated in <a href="http://stripydog.blogspot.co.uk/2014/01/wtf-is-ipv6.html">yesterday's post</a> we can move on to <a href="http://www.nmea.org/Assets/20130925%20nmea_presentation%20v7.pdf">OneNet</a>.<br />
<br />
OneNet is the <a href="http://www.nmea.org/">NMEA</a>'s next-generation protocol for marine data "over ethernet". Although the standard is both closed and not yet published, publicly available descriptions suggest that it has an application layer similar to <a href="http://en.wikipedia.org/wiki/NMEA_2000">NMEA 2000</a> but uses an <a href="http://en.wikipedia.org/wiki/Internet_Protocol">Internet Protocol </a><a href="http://en.wikipedia.org/wiki/Network_layer">network layer</a>. The use of Internet Protocol means that OneNet data will be easily transportable over computer networks to PCs, tablets, phones etc.. Given that NMEA standards include the entire <a href="http://en.wikipedia.org/wiki/OSI_model">stack</a> from the physical to application layers, use of non-ethernet networks, the Internet or wired networks not using OneNet connectors might be outside the standard but will almost certainly be an option available to consumers.<br />
<br />
Use of Internet Protocol was almost a given for a new NMEA data communications standard. The interesting thing is the version used: It's IPv6.<br />
<br />
<h3>
Why IPv6? </h3>
In many respects IPv6 is the ideal protocol for this application. A boat network of transducers and other devices is classic "<a href="http://en.wikipedia.org/wiki/Internet_of_Things">Internet of Things</a>" territory. IPv6 provides a <a href="http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/ipv6_autoconfig.html">method for autoconfiguration</a> thereby obviating the need for the NMEA to develop one. IPv6 mandates supports for many features of relevance here which although now widely supported are strictly speaking add-ons to IPv4: <a href="http://en.wikipedia.org/wiki/IP_multicast">multicast</a>, <a href="http://en.wikipedia.org/wiki/IPsec">security enhancements</a> and <a href="http://www.cisco.com/en/US/docs/ios-xml/ios/qos_classn/configuration/xe-3s/ip6-qos-xe.html">quality of service</a>. <a href="http://tools.ietf.org/search/rfc6437">IPv6 flow labels</a> might potentially be leveraged by the NMEA for interaction with the underlying datalink layer to provide reserved bandwidth for lossless delivery in control links. NMEA 2000 took many years to become widely adopted. With the first OneNet products at least 2 years away, widespread market penetration might not occur until such time as IPv4 is starting to retreat towards obsolescence. Using IPv6 for a product which may not be mainstream for more than 5 years avoids the pain of having to change the network layer at a later date.<br />
<br />
Some people may have concerns that OneNet, being IPv6, will not interact with their existing computing devices. As mentioned in the previous post, almost all modern consumer computing devices support IPv6. Marina wifi and mobile providers are rarely configured to transport IPv6, but this is a good thing. Ideally people's boat data networks would be entirely independent of the network they use for checking the weather and looking at <a href="http://icanhas.cheezburger.com/lolcats">LOLcats</a>. In practice it won't be, because the consumer will want to use their PC/tablet to look at both transducer data and cat videos. A logical separation of networks is possibly the next best thing to a physical one.<br />
<br />
On the money-spinning front, while IPv4 remains the predominant global network protocol, use of IPv6 on boats creates a market for "marine" NAT64 products and other devices to facilitate working with both IPv4 and IPv6. "NMEA certified" networking equipment can be sold to those wary of purchasing cheap domestic alternatives with IPv4-only user interfaces.<br />
<br />
My opinion is that IPv6 is undoubtedly the right solution to this problem, but that doesn't make it without challenges<br />
<h2>
The Challenges</h2>
<h3>
Current marine software rarely supports IPv6</h3>
Many people would like to be able to just connect their laptop to their instruments over the network. Their marine software however (e.g. chartplotter program) will likely only take data from an IPv4 source.<br />
<br />
Actually most marine laptop/tablet software uses an <a href="http://en.wikipedia.org/wiki/NMEA_0183">NMEA 0183</a> application layer data which is not what OneNet would be providing. To use OneNet, the application would need updating whatever the network layer used. Adding support for IPv6 should be easy by comparison.<br />
<br />
<h3>
Embedded IPv6 stacks are not as mature as IPv4</h3>
Although the Linux and *BSD network IPv6 stacks are in widespread use, some people have concerns about the maturity of IPv6 stacks for microcontroller-based devices. A lack of widespread use allows the possibility of as-yet unknown problems which can severely impact product development times. Moreover selecting a 3rd party stack to use will involve a repeat of the research which a manufacturer would have already done in bringing IPv4-based products to market. I have insufficient experience in embedded product development to know how much of a problem this will be. Use will obviously bring the maturity of IPv6 stacks into line with that of IPv4 stacks.<br />
<br />
<h3>
Staff skills</h3>
IPv6 expertise exists in many areas of IT but it is the exception rather than the rule. Programmers working for marine technology companies are possibly less likely than those working for network hardware vendors to posses extensive IPv6 experience. None of the large marine electronics companies can be emailed over IPv6 or have IPv6 accessible web sites, which might suggest that their IT infrastructure staff also lack experience in this area. Lack of experience implies increased training and development costs, greater risk and a longer time to market.<br />
<br />
<h3>
The unknown</h3>
An IPv4 network layer for OneNet looked like a safe choice. Challenges would be readily anticipated from existing development work and experiences from existing NMEA-over-IPv4 work with <a href="http://webstore.iec.ch/preview/info_iec61162-450%7Bed1.0%7Den.pdf">IEC 61162-450</a> and various vendor-proprietary solutions. IPv4 would be familiar and readily accepted by consumers and manufacturers alike. IPv6 is not only new to the marine industry, practical use in an application like this is ground breaking. As such the risks may be harder to quantify and in business, unquantifiable risk is bad. What makes an excellent technical decision may not be such a strong business decision.<br />
<br />
<h3>
Conclusion</h3>
Two things I seem to spend a lot of time doing are IPv6 network coding and Sailing. It's no surprise that I'm delighted that IPv6 will form the network layer for OneNet. From a technical perspective I strongly believe it to be a brilliant decision and a bold one.<br />
<br />
The implications of this choice extend beyond the boating industry. If OneNet comes to fruition it will be one of the first true industry-led steps towards the much discussed Internet Of Things. Demonstrable success would diminish risk associated with similar initiatives in other industries and drive adoption. IPv6-connected marine devices would create business opportunities for network connected services which could give impetus to adoption of IPv6 connectivity and change the way in which we all interact with the Internet.<br />
<br />
From a business perspective it seems like a brave move. It would appear to carry more business risk and short-term cost than the safer IPv4 alternative.<br />
Technology is more my department than business, but an industry taking the long view to the ultimate benefit of the consumer makes a refreshing change.<br />
<br />
Another two years or more is a long time to wait for OneNet, even assuming things stay on schedule. Not only do the risks imply delays in themselves, but caution may delay development efforts in some organisations. The CTO of one well-known marine electronics company told me that his organisation were adopting a "wait and see" policy towards the new standard.<br />
<br />
It will be interesting to see what proprietary or open standards might fill the gap between then and now and whether one of those regents may ultimately pretend to OneNet's throne.Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com0tag:blogger.com,1999:blog-9190270992063734806.post-37920708923906023112014-01-15T16:18:00.002-08:002014-01-16T02:04:13.902-08:00WTF is IPv6?The <a href="http://www.nmea.org/">NMEA</a> <a href="http://www.nmea.org/Assets/20130925%20nmea_presentation%20v7.pdf">have announced</a> that their next generation data protocol, OneNet, will run over IPv6 (Internet Protocol, version 6). Before considering what that means for boaters, what the heck is IPv6 anyway?<br />
<br />
"Internet Protocol" is a method of transporting data across computer networks. It's like a shipping container (or "packet") with a label on it for information such as the address of the sender and that of the recipient. For the past three decades we've mostly been using Internet Protocol version 4, or "IPv4" (though more commonly just "IP"). As the number of computers connected to the Internet expanded rapidly during the 1980s, it became apparent that the "address" fields of this shipping container's label (or "header") were soon not going to be big enough to give a unique address to every new potential sender and recipient of Internet data. A new type of shipping container with a different label with space for much longer addresses was required so the <a href="http://www.ietf.org/">IETF</a> started work on a new version of Internet Protocol, eventually dubbed IPv6 (there was no IPv5).<br />
<br />
The differences between IPv4 and IPv6 extend to more than just address size. IPv6 incorporates new mechanisms for auto-configuration (devices assigning addresses to themselves) and standardises many of the features which have been bolted on to IPv4 over the years. Ultimately though these protocols both perform much the same core function: shipping data across networks. However they behave like two independent courier services which although they may put their containers onto the same trucks, trains, ships and planes in the course of delivering a packet, each courier uses postal codes on the address labels which are meaningless to the other courier. You can do tricks like putting an IPv6 packet inside an IPv4 packet for part of the route where the devices connecting networks ("routers") only understand IPv4, but both sender and receiver must ultimately use the same addressing scheme. A single device may have an IPv6 address <i>and</i> an IPv4 address, in the same way that a company can have an account with two courier companies and use whichever one delivers to the whoever they need to send something to. <br />
<br />
The first IPv6 standard appeared in 1995. During that time we've regularly seen news items predicting that we would soon be running out of IPv4 addresses. Google tracks the percentage of <a href="http://www.google.com/ipv6/statistics.html">users accessing their services over IPv6</a> (drilling down by country is interesting and occasionally surprising). Today it's only 2.3%. So why is IPv4 still ubiquitous and IPv6 almost unknown to anyone other than network engineers?<br />
<br />
In the past 20 years a number of effective mechanisms have been adopted to slow the rate at which IPv4 addresses are being depleted. Despite the hype to the contrary, IPv4 addresses are still obtainable and will remain so for a few years yet. The bottom line is that for most Internet-using businesses there simply isn't a business case for using IPv6: IPv4 does what they want, so why endure the cost and risk of change?<br />
<br />
Due in part to <a href="http://en.wikipedia.org/wiki/DoD_IPv6_Product_Certification">US government mandates</a> that all computer equipment they purchase must be capable of running IPv6, all mainstream operating systems (Windows, MacOS, Linux, Android, iOS etc.) are capable of using it. This does not mean other software is. Your Mac may be quite capable of sending and receiving IPv6, but at time of writing, <a href="http://www.opencpn.org/">OpenCPN</a> doesn't understand if you tell it to take a data feed from an IPv6 address. Users in many countries (including the UK) will have a hard time finding a domestic Internet Service Provider whose routers have been configured to correctly forward IPv6 packets even though the machines themselves are capable of it. Without a bit of trickery, home computers can't normally speak to remote web servers using IPv6. Even if they could, practically all web sites are reachable using IPv4. Only a small minority can be reached via IPv6. Most computers which are configured to use IPv6 are also configured to use IPv4 to communicate with sites with IPv4-only connectivity.<br />
<h3>
Internet Of Things</h3>
The buzzphrase "The Internet of Things" is used to describe the interconnection of many different kinds of uniquely identifiable objects which are able to send and/or receive data. Those objects might be toasters, fridges, transducers or cows. Although a concept rather than an implementation and therefore independent of any particular technology, the Internet Of Things is often associated with IPv6 because of the very large number of objects (many billion) potentially requiring identifiers on the network. Other properties of IPv6, particularly its self-configuration mechanisms, make IPv6 particularly appropriate for an internet of things.<br />
<br />
The phrase has recently become so over-used as to be deeply annoying. <br />
<br />
<h3>
Key points for the average leisure boater</h3>
<ul>
<li>IPv6 does the same kind of things as IPv4 and end users shouldn't really notice or care about the difference</li>
<li>Yes your Mac/PC/phone/tablet can use it</li>
<li>Yes it can probably use IPv6 on your existing boat network at the same time as IPv4</li>
<li>Devices can only talk to each other using IPv6 if they both have an IPv6 address. Devices can only talk to each other using IPv4 if they both have an IPv4 address</li>
<li>A device may have an IPv4 address <i>and</i> an IPv6 address and use either protocol</li>
<li>No your Mac/PC/phone/tablet probably isn't <i>configured</i> to use IPv6</li>
<li>No, your marina wifi / mobile data service probably hasn't been configured to transfer IPv6 between you and the Internet</li>
<li>No, apart from "big" applications (e.g. firefox) and those produced by Microsoft, Apple, Google etc., the <i>application</i> you're using doesn't necessarily understand IPv6 addresses you type in.</li>
<li>No your MFD or other marine devices don't work with IPv6: Those companies struggle to get IPv4 right. There is nothing preventing updated firmware from changing that in the future though</li>
<li>You can, of course, put your nmea-0183 data on your network using IPv6 with <a href="http://www.stripydog.com/kplex">kplex</a>. Just thought I'd mention it</li>
<li>No, unless you really want to you probably shouldn't waste your time doing it.</li>
</ul>
The only reason you really need to know anything at all about IPv6 right now is so I can write about NMEA OneNet in the next post. Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com0tag:blogger.com,1999:blog-9190270992063734806.post-28140610169724483402014-01-10T04:35:00.002-08:002015-09-29T06:59:38.916-07:00Cape Multicast: The Logical Route<i>UPDATE September 2015. Practical layer 2 considerations have lead me to change my conclusion on the optimum practical data transmission method over wireless networks as described in <a href="http://stripydog.blogspot.com/2015/09/marine-data-transports-re-visited.html">this later post</a>.</i><br />
<br />
In my last post I touched on the lack of standardisation in the way NMEA-0183 data (strictly speaking, data in a format based on the application layer of NMEA-0183, but we'll use the shorter phrase for readability) is transported over IPv4 networks with current marine software and devices.<br />
<br />
In this post I argue that the way in which most devices and software currently do this using TCP or broadcast UDP is not optimal, propose an alternative solution and discuss the viability of its implementation.<br />
<br />
For the sake of this discussion, the network is assumed to be the de facto standard of IPv4. <br />
<br />
For the sake of brevity I will assume some familiarity with TCP/IP and UDP/IP. If anyone comments to request it I will elaborate on terms more extensively in a later post.<br />
<br />
<h3>
How things stand</h3>
Most devices and software which are designed to send or receive NMEA-0183 data over an IP network do so by one or both of unicast TCP or broadcast UDP. Devices which are data sources on the network (e.g. NMEA-to-network converters) often implement a TCP server though in some cases programming is rudimentary and the server can only support a single client. Data consumers (e.g. mobile apps) using TCP normally act as a client, initiating a connection to the server. Consumers expecting UDP can normally receive unicast or broadcast data as programmers of these apps rarely bind sockets to a particular address.<br />
<br />
Very few devices or programs explicitly designed to send or receive NMEA-0183 data do so using UDP multicast. <a href="http://www.stripydog.com/kplex">kplex</a> will, and as of beta version 3.3.1303, so will <a href="http://opencpn.org/ocpn/">OpenCPN</a>. Software and devices able to send to a configurable UDP address can normally send to a multicast address so long as the underlying network stack supports multicast, which it will in the case of a modern operating system (Linux/Windows/MacOS/*BSD). Software and devices will not be able to receive NMEA-0183 over UDP multicast without explicit support in their code, although such support is normally trivial.<br />
<br />
<h3>
TCP</h3>
<h4>
Why you want it</h4>
TCP has the following advantages in this application<br />
<ul>
<li>With no clients connected, a TCP server consumes no bandwidth. If your server sends unsolicited UDP it neither knows nor cares if any clients are listening: it sends it anyway. This increases power consumption on many types of network if no clients require this data. If your network only intermittently has a client device wanting to receive NMEA-0183 data, TCP may be the most power-efficient solution.</li>
<li>For Internet NMEA-0183 servers such as ones streaming AIS info for various ports, TCP is the most viable option. Multicast over the Internet is rarely an option due to configuration required on intervening routers. Broadcast or unicast UDP would require a separate protocol to request and terminate a datastream from the server and would generally encounter difficulties with firewalls.</li>
<li>Reliably implemented in embedded stacks</li>
<li>Currently supported by most applications </li>
</ul>
<h4>
Why you don't </h4>
<ul>
<li>That reliable delivery you thought was a good idea? In this application it probably isn't. Reliable transmission is not a feature of native NMEA-0183 over serial lines or AIS over VHF and no application should break as a result of a lost sentence. A reliable transport mechanism is not required if reliability is provided by the application layer protocol. In this case, transducers are constantly transmitting their status with the most recent data. If a UDP packet is dropped the result is that an application will not be updated with the information it contained but will be updated with more recent information the next time that sentence is transmitted, possibly 1-5 seconds later. If a TCP packet is dropped, no subsequent packets (sentences of any kind) will be delivered on that data stream to the application until the packet loss has been detected by TCP and the dropped packet has been successfully retransmitted. Instead, any data sent between the dropped packet and the retransmitted one will be queued on the receiver pending the ability to deliver data in the order it was sent: an unnecessary requirement here. The duration of the delay will be influenced by many factors but if it exceeds the frequency of transmission of the data type in the lost packet, the result could be that a subsequent update is delayed waiting for TCP to retransmit the (now obsolete) dropped packet. This will happen in the case where a network cable is disconnected for more than a second, interrupting the flow of data from a transducer outputting at 1Hz. Another case where it should happen is if that 1Hz data is the only thing being sent over a data stream. <a href="http://tools.ietf.org/search/rfc6298">RFC 6298</a> gives a minimum retransmission timeout of 1s so in the absence of other packets being sent to trigger a fast retransmit, TCP will not time out waiting for the dropped packet to be ACKed until after the subsequent packet has been sent. In practice, most OSes implement a lower minimum RTO and in any case, the average NMEA-0183 stream may carry more traffic, triggering fast retransmits. It could be argued that in the case of AIS data where a dropped packet containing a report from a vessel may not be updated for minutes, TCP's retransmission may be a net benefit but in general, TCP's "reliability" is not beneficial in this application. If a LAN is heavily congested for long periods, it is far better to randomly drop data leading to graceful degradation of performance of the end user application than to queue a backlog of stale data.</li>
<li>Protocol overhead. In addition to the actual NMEA data transmitted a TCP connection requires packet exchange in order to set up a connection, packet exchange to take it down and acknowledgements of data received to be sent. Loss of the latter may lead to unnecessary retransmission. In practice protocol overhead is not excessive: data streams are long lived meaning that connection establishment and termination overhead are negligible and not every packet needs ack-ing.</li>
<li>Data are prone to additional delays if programmers neglect to disable Nagle algorithm on sending sockets. There is no need for this to be an issue, but marine electronics companies do not have a good track record of software excellence. <b>UPDATE</b>: In testing this with OpenCPN I realised that most modern operating systems seem to have delayed ACK timers of 200ms or less rather than the traditional 500ms, reducing any impact from this.</li>
<li>Data replication. Any unicast protocol (as TCP inherently is) requires each piece of data to be copied to each client. Two clients necessitate double the data on the network as opposed to a single client. Three clients triple etc. In practice the small number of network NMEA-0183 clients likely to be required on the average pleasure boat is unlikely to exceed the multiple by which network capacity exceeds the capacity of a 38.4k serial line, so whilst wasteful, should not present an obvious problem.</li>
<li>If a server is ungracefully shut down (e.g. the power removed) and restarts, a receive-only TCP client may not realise for some time (or ever if keepalives are not enabled) and data will simply seem to stop, where a UDP-based solution would continue to function as soon as the server came back on line. </li>
<li>Requires users to know the network address of a server in order to configure a client, which can be problematic on links with dynamically assigned addresses. This might be overcome by use of a service discovery protocol (e.g. bonjour, ssdp or a custom protocol). </li>
</ul>
<h3>
Broadcast UDP</h3>
<h4>
Why you want it</h4>
<ul>
<li>Doesn't suffer delays or protocol overheads associated with TCP</li>
<li>No requirement to replicate data: Many clients read the same data packet</li>
<li>Available on the types of network used in this application</li>
<li>Reliably implemented in embedded stacks</li>
<li>Currently supported by many applications</li>
</ul>
<h4>
Why you don't </h4>
<ul>
<li>Not a good solution when crossing network boundaries as will be dropped by routers unless they are configured to do otherwise. Not usually a problem since common applications use a single link.</li>
<li>Inappropriate for Internet use</li>
<li>Can be challenging to program correctly for bi-directional communication with standard APIs. Applications need a method to avoid re-reading their own broadcasts and possibly creating broadcast storms. OpenCPN does this using interface priorities.</li>
<li>Explanation of netmask/broadcast concept needed in documentation if UI requires user to input destination address manually</li>
<li>Requires some processing by all devices on a link regardless of whether any are interested in the data being sent. This is the big problem with broadcast and why it is generally not considered a good solution in modern networking applications.</li>
</ul>
<h3>
Unicast UDP</h3>
<h4>
Why you want it</h4>
<ul>
<li>For streaming data to a single, known, always-connected destination it is ideal. None of the protocol overhead or timing issues of TCP yet easily traverses networks and is universally implemented in IP network stacks. An example might be streaming data to Marine Traffic servers.</li>
</ul>
<h4>
Why you don't</h4>
<ul>
<li>Worst of all worlds in most other respects</li>
<li>Data duplication required with multiple clients</li>
<li>Server must know addresses of all clients </li>
<li>Additional protocol required for clients to dynamically request a data stream</li>
<li>Wasted traffic if server is pre-configured to stream data to fixed unicast addresses which may have no attached client</li>
</ul>
<h3>
Multicast UDP</h3>
<h4>
Why you want it</h4>
<ul>
<li>Doesn’t suffer delays or protocol overheads associated with TCP</li>
<li>No requirement to replicate data: Many clients read the same data packet</li>
<li>Available on the types of network used in this application</li>
<li>Unlike broadcast, sending requires setting of no special flags (assuming a correctly functioning network stack)</li>
<li>Easier to implement bi-directional many-to-many communication with standard networking APIs than with broadcast </li>
<li>Can be efficiently routed across networks</li>
<li>Unlike broadcast, doesn't (in theory) cause processing overhead on systems not interested in receiving those particular multicast data </li>
<li>Reliably implemented in all modern operating systems (Linux/MacOS/Android/IoS/Windows)</li>
</ul>
<h4>
Why you don't</h4>
<ul>
<li>Not currently supported for receiving by many applications. kplex and OpenCPN are two which do</li>
<li>Multicast routing across networks requires support on routers which will likely be unavailable across the Internet or on a small home/boat network, limiting effectiveness to a single link (like broadcast) for many users.</li>
<li>Not a required part of IPv4, although implemented for more than a decade in almost all operating systems</li>
<li>May not be implemented in some basic embedded/microcontroller stacks</li>
</ul>
<h3>
So what's the answer?</h3>
For the most part, TCP is the wrong protocol for delivery of NMEA-0183 data over a boat LAN. The protocol's bandwidth throttling and reliability mechanisms are not required by the nature of the application level data and can have a negative impact on the timeliness of data delivery to client. The data required on the network is a linear function of the number of clients using those data as opposed to a fixed amount as with UDP broadcast and multicast. <br />
<br />
TCP is undoubtedly the best choice for requesting data from a server on a remote network as UDP would require an additional protocol for initiation and termination requests. Although the best choice for servers streaming port AIS information which in turn is often useful for debugging marine data applications without another source of live or simulated data, this facility should not normally be required for navigational purposes.<br />
<br />
Unicast UDP only has utility when sending data to a known endpoint on a remote network. For navigation data within a boat's network, it has little to recommend it over the alternatives.<br />
<br />
Of the current widely implemented solutions, broadcast UDP is perhaps the most appropriate. Clients don't need to know a source address (only a port) so it is useful where servers are dynamically configured. However, its only advantages over UDP multicast are:<br />
<ul>
<li>Current acceptance in the market</li>
<li>Possible lack of multicast support in some embedded network stacks</li>
</ul>
Manufacturers <i>will</i> at some point need to address the latter point (if it even turns out to be a problem) with the 3rd party network stacks they currently use. Service discovery protocols which are increasingly being used in marine applications (e.g. in GoFree, OneNet) require multicast to function correctly. This leaves only the problem of acceptance in the market which will be addressed in a later section.<br />
<br />
Multicast would be used for this application in any commercial computer networking solution and indeed is reportedly the choice for data delivery in formal marine data networking standards IEC-61162-450 and NMEA OneNet. It is possibly only unfamiliarity with IP networking concepts in the marine electronics world which has led to broadcast being adopted. Multicast has the advantages of broadcast but without the unnecessary processing overhead imposed on devices attached to the network which are not interested in receiving data of this sort. The receiving group is a simple address which the user does not need knowledge of netmasks to determine. It could be argued that multicast does not always remove unnecessary processing overhead: The IP-multicast to ethernet-multicast address mappings are not one to one and coarseness of multicast filters on various network cards, particularly at the lower end, may lead to unnecessary CPU interrupts caused by irrelevant multicast traffic. Processing load is, however, <i>reduced</i> by using multicast rather than broadcast.<br />
<h3>
Does any of this even matter?</h3>
Not much. Boat networks are small with few attached devices, perhaps the majority of which will be interested in NMEA-0183 data and the rest will be negligibly affected by using broadcast rather than multicast. It is unlikely that users will notice a difference no matter which delivery method is used. This doesn't mean that it's is a good reason to choose a theoretically inferior solution because in practice there is no observable difference.<br />
<h3>
Conclusion and Stratgey</h3>
Multicast UDP is the most technically correct of the transports considered here for NMEA-0183. The main issue is acceptance in the market place.<br />
<br />
From the product development angle this is easily addressed for products currently supporting unicast or broadcast UDP: Supporting multicast, in addition to unicast and/or broadcast is simple. If the sending/receiving UDP address is not already configurable, the UI needs to be updated to make it so. After this only trivial code changes are required if a user specified address is multicast: When the data connection is initialised if the user-supplied UDP address is a multicast address, the program simply doesn't set the broadcast option on the connection (SO_BROADCAST for the sockets API) if it needs to send data. If it needs to receive data, it simply joins the relevant multicast group, a single function call in most APIs.<br />
<br />
For multicast to be useful, all clients requiring NMEA-0183 data should support it. There is no point in running multicast <i>and</i> broadcast together on the same network: this has no advantage over broadcast alone.<br />
<br />
For new applications all it requires for developers to implement multicast as a transport is awareness as the additional development cost is negligible. For modification of existing applications there is only justification if there is demand, and there will only be demand if other apps support it. We've started the ball rolling with openCPN, perhaps it's time to spread the word.<br />
<br />
But obviously an open standard would be nice.Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com1tag:blogger.com,1999:blog-9190270992063734806.post-90073092587567209392014-01-08T11:25:00.001-08:002014-01-16T10:18:49.764-08:00The Curious World of Marine Data Networking<span style="font-family: inherit;">It's a rum do this marine networking business. For someone who has spent the past quarter century dealing with open Internet protocols the strangeness is not so much in the archaic technology of the standards themselves but the way in which they are defined and administered. The <a href="http://www.ietf.org/">IETF</a> has a variety of funding sources but one of them isn't selling the standards which they define. Their biggest potential cost, the time of those involved, is funded by the organisations which employ them. Corporate altruism aside, it makes good business sense to fund a seat at the decision making table.</span><br />
<br />
<span style="font-family: inherit;">In the world of marine data networking, standards are controlled by the US-based <a href="http://www.nmea.org/">National Marine Electronics Association</a> (NMEA). In data networking, these standards cover the entire stack in the <a href="http://en.wikipedia.org/wiki/ISO_model">OSI model</a>, from physical to application layers. The <a href="http://www.iec.ch/">International Electrotechnical Commission</a> (IEC) formalises standards for the transmission of marine data based on the NMEA protocols (<a href="http://en.wikipedia.org/wiki/IEC_61162">IEC 61162</a>). These are aimed at commercial vessels legally bound to conform to <a href="http://www.imo.org/">IMO</a> requirements.</span><br />
<br />
<span style="font-family: inherit;">Unlike Internet standards, marine networking standards are not publicly published. Anyone wishing to understand or implement the protocols has to buy the standards documents. Not only this but the NMEA keep strict control of their intellectual property. The documents aren't redistributable in any form which reportedly includes software source code. Consequently, NMEA protocols cannot in theory be implemented in <a href="http://en.wikipedia.org/wiki/Open-source_software">open source software</a>.</span><br />
<br />
<span style="font-family: inherit;">Open source evangelist <a href="http://en.wikipedia.org/wiki/Eric_S._Raymond">Eric Raymond</a> has <a href="http://esr.ibiblio.org/?p=801">frankly expressed</a> his opinions about this method of standards control. Not being familiar with US intellectual property laws and keen to not be blinkered by possible hyperbole from those with hard line views on software freedom, I emailed the NMEA in an attempt to clarify their position on the use of legitimately purchased copies of their standards in open source software. I never received a reply.</span><br />
<br />
<span style="font-family: inherit;">The NMEA has other sources of revenue besides selling standards documents: membership fees, conferences, product certification, training etc. Whether revenue from standards is a necessary cornerstone of their funding or whether standards remain closed because of entrenched and ideas about how the marine electronics industry does business is not something I wish to speculate on here. </span><br />
<h3>
<span style="font-family: inherit;">State of the Ark</span></h3>
<span style="font-family: inherit;">The NMEA's most up to date data communications protocol is <a href="http://en.wikipedia.org/wiki/NMEA_2000">NMEA 2000</a>. This is based on <a href="http://en.wikipedia.org/wiki/CAN_bus">CAN bus</a>, the vehicle networking protocol from the 1980s which has only recently started to gain widespread use in the leisure boating market. Still to be found on most marine devices today is the ability to communicate via an older and more widely deployed protocol, NMEA-0183 (a version of which is formalised as IEC 61162-1). NMEA-0183 encodes data from sensors at the application layer as lines of carriage-return-line-feed-terminated ascii characters and transports them over a serial line (<a href="http://en.wikipedia.org/wiki/RS-422">EIA-422</a> in later standards).</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Due to the need to support higher data rates for connections between devices such as radar, sonar, cameras and the multifunction displays they talk to, manufacturers have implemented proprietary protocols (not using NMEA standards) running over ethernet networks.</span><br />
<br />
<span style="font-family: inherit;">There also exists an IEC standard for the transport of IEC 61162-1 (NMEA-0183) data over IPv4 networks known as IEC 61162-450. However I have never seen an implementation of IEC 61162-450 in any software or device available in the marine leisure market.</span><br />
<br />
<span style="font-family: inherit;">The NMEA is currently working on a new standard for transport of marine data over IP-based ethernet networks. "<a href="http://www.nmea.org/Assets/nmea%20introduces%20onenet.pdf">Onenet</a>" is due for publication in late 2014. At the 2013 Southampton boat show and again at the 2014 London boat show I asked on the stands of Raymarine, Garmin and (at Southampton) Navico (who own the B&G, Simrad and Lowrance brands) when we were likely to see OneNet enabled products. Sadly none of the staff were even aware of OneNet, let alone possible products.</span><br />
<h3>
<span style="font-family: inherit;">If you don't build it, they will come anyway</span></h3>
<span style="font-family: inherit;">PC applications which take marine data from an Internet Protocol ("IP") network using proprietary protocols are not new: <a href="http://www.raymarine.com/view/?id=510">Raytech</a> used data from Raymarine equipment and <a href="http://www.maxsea.com/">MaxSea</a> could use Furuno data. Some of the newer tablet and phone apps continue to use proprietary protocols: The Navionics tablet app communicates with Raymarine plotters (or "Multifunction Displays" (MFDs) as they are increasingly being called) using an undisclosed method agreed between the two companies. Most of the current crop of mobile and PC apps using marine data from a network are not tied to a particular manufacturer. The most common method for the transport of marine data over IP (including wireless) networks surprisingly follows no defined standard. </span><br />
<h3>
NMEA-0183 over IP: The Non-Standard</h3>
The majority of current apps sending or receiving data over IP do so using the application layer of NMEA-0183. In other words, the data an application will send or receive will look like a string of ascii characters, starting with a "!" or "$" and ending with an ascii carriage return and line feed. Very few implement the new features in NMEA-0183 version 4 (e.g. TAG blocks).<br />
<br />
There is no standard transport layer but in practice the options are limited anyway. Most software apps and hardware devices use either TCP, UDP or offer the user a choice of either. There is no standardisation for maximum UDP datagram size<span style="font-family: inherit;"> or</span> whether one or several sentences may be carried in a single datagram. There is no common statement that Nagle algortihm should be disabled for tranmission of marine data over TCP.<br />
<br />
There is no standardisation for data transfer at the network layer except a de facto standard that IPv4 is used. My own multiplexer program <a href="http://www.stripydog.com/kplex">kplex</a> is the only marine data application I am aware of which supports data in NMEA-0183 format over IPv6. TCP is inherently unicast. UDP is most commonly used for broadcast. Even there there is no standardisation: Some applications use the broadcast address of the zero network (255.255.255.255), others the network broadcast address. Most applications don't care which broadcast or unicast address is used as they simply listen for any UDP packets the system receives (ie bind to INADDR_ANY). Very few applications use UDP multicast. The only ones I know of are the ones I have put the code in to support it myself: <a href="http://www.stripydog.com/kplex">kplex</a> and <a href="http://opencpn.org/ocpn/">OpenCPN</a>.<br />
<br />
There is no common standard for device addressing and no standard for service discovery. Navico have developed and released a service discovery protocol described in their "<a href="http://www.simrad-yachting.com/Global/Simrad-Yachting/Products/GoFree/GoFree%20Tier%201%20Specification.pdf">GoFree Tier 1</a>" specification. This is a combination of <a href="http://en.wikipedia.org/wiki/Bonjour_%28software%29">bonjour</a> and service information announced using <a href="http://www.json.org/">JSON</a> strings send over UDP multicast. Few of the major applications described as working with "GoFree" currently make use of the service announcements: instructions for <a href="http://www.inavx.com/">iNavX</a> and similar applications involve getting the (dynamic) IP address of the MFD via the MFD's menus then connecting the mobile device to that. Service discovery in OneNet is rumoured to be similar to this. Perhaps unsurprising given that Navico is one of the biggest players in the industry and none of their major competitors has proposed such a protocol.<br />
<br />
So why use a 30 year old protocol instead of the "current" NMEA 2000 at the application layer? I am open to suggestions but here is my speculation.<br />
<ol>
<li>Prior to disassociating the application layer from the lower layers of the protocol stack, it was easier and cheaper to present NMEA-0183 to a PC over a serial port (or via a serial to USB converter) than it was to present NMEA-2000 (via hardware incorporating a CAN controller). Many applications developed prior to the widespread use of IP networks on boats were written to take NMEA-0183 from a serial interface. Simply using the application layer of the already-implemented data communications protocol involves the least implementation effort when network communication is added.</li>
<li>NMEA-0183 is the most common format for data generally available on a pleasure boat. Although NMEA 2000 has become more common over the past 5 years the ubiquity of NMEA-0183 means that most MFDs will have an NMEA-0183 interface in addition to any NMEA 2000 interface. Many boats have older equipment which don't support NMEA 2000. NMEA 0183 interfaces are still more common on some types of new equipment (VHF radios, AIS receivers).</li>
<li>Many of the details of the application layer of NMEA 0183 are known. The details of NMEA 2000 are considerably less widely known.</li>
</ol>
The latter point needs discussing further.<br />
<h3>
NMEA 0183: An Open and Shut case</h3>
As previously mentioned, the NMEA's protocols are "closed". To legitimately use them they must be purchased and not re-distributed in any way, including by open sourcing code written to implement them. However many of the details of NMEA-0183 up to and including version 3 have been widely publicised on the Internet. The document I consulted in writing kplex and possibly the best known publicly available source of information on NMEA-0183 is the <a href="http://www.catb.org/gpsd/NMEA.html">document assembled by Eric Raymond</a>. In this he states that none of the content was directly derived from NMEA standards but was taken from a variety of other publicly available sources. It was written as part of the <a href="http://www.catb.org/gpsd/">gpsd</a> project, but also in part as a political protest against the NMEA's closed standards.<br />
<br />
As a consequence of the details of NMEA-0183 being publicised it has been widely implemented in apps where the developers have not purchased or cannot use (because the application is open source) the official standard. NMEA 2000 has not been publicly revealed in this way. The features added to NMEA-0183 in version 4, although referred to in some publicly accessible <a href="http://www.nmea.org/Assets/may%2009%20rtcm%200183_v400.pdf">presentations</a> and errata are not publicly described in detail and remain largely unsupported by most apps using NMEA-0183 style data over a network.<br />
<h3>
Are we there yet?</h3>
So what are we left with? The leisure market at least has ignored IEC-61162-405. Products implementing OneNet look to be 2 years away. We are left with the application layer of an antiquated and arguably poorly defined protocol which is generally implemented based on non-primary unofficial sources transmitted over an unspecified transport layer in an IPv4 network with whatever method of addressing happens to exist.<br />
<br />
The quite remarkable thing is that it mostly seems to work.Stripydoghttp://www.blogger.com/profile/14795469578141188553noreply@blogger.com0