Navionics

[Anthony Doud]

The Navionics iPad app now supports a few different wifi sources including t-box, digital yacht sonar server, and the gofree wifi wireless module. Any idea if there is a way to get it working with kplex? I've tried a little bit and I can't figure out how to get the app to recognize the pi.

Awesome work btw!!!

[Anthony Doud]

I just found a "NMEASource-Template.plist in the Navionics application directory on my JB iPad. Looks like some awesome info in there to connect to the app. Hopefully I'll have good news soon!

[Anthony Doud]

So, I've tried setting the raspberry pi ip address and Kplex port to a few of the settings listed in the plist file I found as well as the support info for the gofree & digital yacht products, and nothing worked. I've also toggled an "enable" button on the plist on the JB ipad, and used the corresponding settings i supposedly "enabled" but no luck there either. According to Navionics documentation, the depthfinder info should just automatically popup once it finds a compatible unit (and a couple of these are pretty simple units just spewing plain nmea over tcp/ip so I'm currently at a loss. If anyone has any more info on this it would be great! I would love to try out the Navionics Sonarcharts Live mapping feature. (Why oh why Navionics can't just have a manual connect like iNavx.........)

(Gofree default Settings)

192.168.0.1

255.255.0.0

port 2051

(Digital Yacht Settings)

IP Address - 169.254.1.1

Subnet - 255.255.255.0

Port 2000

[Keith Young]

Can't see any mention of Navionics Boating taking external data sources except their plotter sync thing for waypoints.  I note that they've added the GoFree support but as that's two way it'll probably be using websockets which is what I think navico use for mobile->MFD communication.

Got a link for a statement of the capabilities?  Yes does look like a lot of their documentation is out of date: plotter sync page says it's Raymarine only but elsewhere I turned up a press release talking about the GoFreee support (only for plotter sync)

[Anthony Doud]

Sure thing!

http://digitalyacht.net/2015/04/16/digital-yacht-sonar-server-plus-navionics-app-allows-real-time-bathymetry/

http://www.navionics.com/en/sonarcharts-live-compatibility-guide

[Anthony Doud]

and also:

http://sonarserver.com/

[Keith Young]

Thanks for that.  I've mailed Navionics to ask if they have any info.  Not sure about the format of this plist file: I'll investigate that more later but doing a strings on it makes me think that at least one of the methods t's using to look for a data source announced via bonjour.  One of the services listed used the name gofree uses (_nmea-0183._tcp) the other service mentioned in that file is _vesper-nmea0183._tcp which I'd take a wild guess is what the vesper gateway uses.

One thing I'd be included to try might be to install avahi and do static service configuration for _nmea-0183._tcp.  Having kplex register with avahi/bonjour was something I considered but didn't go ahead with as I wanted to keep it cross-platform and minimal with no dependencies on optional libraries.  Might reconsider that in any version 2.0 but in the meantime I'll revisit static Avahi configuration sometime this week.

In my experience Navionics can take weeks to reply if they reply at all, but I'll post as soon as I get anything from them.  When I get to some decent wifi I'll re-install Xcode on my recently-rebuilt mac which might let me examine that plist file in more detail.

[Anthony Doud]

It's also possible that it's UDP. I tried getting UDP going on Kplex and didn't have any luck with inavx linking up to it (changed tcp flag in the config to UDP). Do you have a config file you could share for UDP?

The Plist file is somthing like a registry file, only for iOS. You should be able to view much more once you open it with the tools in Xcode. In addition to the methods you mentioned above, there is a regular "tcp" protocol described in the file.

The only other thing I can think of is if there is some sort of handshake that happens between the app and wifi box before it will read the nmea stream over wifi, but I doubt that also, as Digital Yacht mentions somewhere on their page that Navionics works with their (more expensive) legacy wifi adapters, not just the sonar server.

I may have to get wireshark installed on the pi and see if the Navionics app is searching for anything.

[Keith Young]

It's also possible that it's UDP. I tried getting UDP going on kplex and didn't have any luck with inavx linking up to it (changed tcp flag in the config to UDP). Do you have a config file you could share for UDP?

For UDP broadcast (which I'm guessing you mean) there's several ways to configure kplex to do exactly the same thing. The old way was to use the "bcast" interface type.  Hopefully the new way works (no complaints so far but that's not to say anyone's using it :-).  If you want to broadcast outbound on wlan0 port 2000, and wlan0's broadcast address is 192.168.1.255 you could say in your config file:

[udp]

type=broadcast

address=192.168.1.255

direction=out

device=wifi0

port=2000

But that's more complex than it needs to be.  kplex would note that 192.168.1.255 is a broadcast address for one of it's interfaces and work out from that that you mean broadcast, so you can leave "type=broadcast" out.  In fact you could also leave out the "device" part as kplex can see which device this is the broadcast address for.  Personally though I'd leave out the address part but keep in device: If you specify a "device" but no address or type, kplex will assume "broadcast" as that's the only thing which makes sense so our minimal config is:

[udp]

direction=out

device=wifi0

port=2000

If you want the default 10110, you can leave out the "port" statement.

From email I know that Anthony has found a solution to his problem, but I'll let him post it....

[Anthony Doud]

Navionics App works with Kplex!

The following setting worked for me - the key was getting UDP to work. Live Charting works also! The configs below are from Keith's "Raspberry Pi NMEA Wifi Multiplexer" example page, with small changes to get Navionics Ipad app working. 

/etc/kplex.conf:

[serial]

filename=/dev/ttyUSB0

direction=in

baud=4800

[tcp]

mode=server

port=2000

direction=out

[udp]

device=wlan0

port=2000

direction=out

/etc/dhcp/dhcpd.conf:

ddns-update-style none;

default-lease-time 600;

max-lease-time 7200;

authoritative;

log-facility local7;

subnet 169.254.1.0 netmask 255.255.255.0 {

        range 169.254.1.129 169.254.1.191;

}

/etc/network/interfaces:

auto lo

iface eth0 inet dhcp

iface lo inet loopback

allow-hotplug wlan0

iface wlan0 inet static

        address 169.254.1.1

        netmask 255.255.255.0

        post-up /usr/local/bin/startap

        pre-down /usr/local/bin/stopap

Once your pi is configured as above, reboot and provide it with a NMEA in stream with DBT strings and you'll automatically get a depth window showing on the bottom of the app. It will also enable a "live sonar chart" which basically updates depth information on the chart as you move your boat, as well as a few more configuration options under the map settings. 

Kudos again to Keith for a great little program!     

[Keith Young]

Note that in my previous example I said "wlan0" then erroneously put "wifi0" in the config. It was only example but should have checked for consistency :-)

great that it's working.  Small point though is that 169.254/16 is actually the IPv4 zero config link local subnet. If it's working though then great.  I'll update with any info Navionics send me in response to my query on getting NMEA data into sonar charts.

[Anthony Doud]

Quick note - although it's working and I'm not going to touch it for a bit - are there any potential problems caused by the above configuration defining [tcp] and [udp] both to port 2000 and the same interface? 

[Keith Young]

On Wednesday, June 17, 2015 at 2:54:40 AM UTC+1, Anthony Doud wrote:

Quick note - although it's working and I'm not going to touch it for a bit - are there any potential problems caused by the above configuration defining [tcp] and [udp] both to port 2000 and the same interface? 

No problem with that: they're different transports, so it's like using the same apartment number in two different buildings: shouldn't confuse the post office :-)

RFC 3927 ("Dynamic Configuration of IPv4 Link-Local Addresses") says that DHCP "should not" be used to configure hosts with 169.254/16 addresses, but it's a "should" rather than a "must" and the reasons stated aren't an issue for an isolated, un-routed boat network using the ISC DHCP server which does do conflict detection before handing out addresses). And hey, we all got on just fine when this was microsoft-specific and even before that. I confess to having little experience with IPv4 zero conf but I can't immediately think of anything bad that would happen with your set-up. And of course it works. Unlike IPv6 where you'll have a link-local address in addition to other addresses, IPv4 link local addresses are used if and only if an interface has no address assigned by other means so with an active dhcp server the zero conf address assignment shouldn't (unless someone can tell us differently) kick in.

[Keith Young]

Time for an update, largely on just how rubbish Navionics are.

Their sales address (which they have as the contact on their web site) I had no reply from, so I mailed the support address. After a few days I got a reply back and entered into a discussion, the gist of their response being that they supported a set list of devices and wouldn't discuss any details, nor would they even confirm use of bonjour.  I asked them to escalate this to management as people would love to use their product more widely and there was really no "Intellectual Property" being protected and was told that my query would be passed to the product owners.  After 2 weeks, no reply so I mailed again asking if there was an update. No reply.

My previous experience with Navionics support has been similarly unimpressive...

[Anthony Doud]

Thanks for the update Keith! On my end, the raspberry pi survived 2000 miles of boat trailer vibrations and a week of tent camping on remote islands in Ontario while being installed in a small boat the whole time. We were able to get some good lake trout areas charted with kplex and the iPad link, so the effort to get it working was well worth it. No problems to report - it all worked great! The Navionics app even generated the chart while it was running in the background (we used a topo map app for primary orientation).

[Keith Young]

SonarCharts™ Live are now now part of Navionics on android (which I have on my phone) so I thought I'd do some investigation on how to get depth data in there.  I strongly suspect that the android and iOS implementations may differ.  Write up here:

http://stripydog.blogspot.co.uk/2015/08/navionics-sonarchart-live-on-android.html

Short answer: bonjour did no good.  Broadcasting data over udp port 2000 works (which I suspect is "supporting" the Digital Yacht Sonar Server).  Running a tcp server on 192.168.0.10 port 10110 works.  Alternatively if and only if your SSID has the string "GoFree" in it, Navionics Boating will pop up a dialogue box asking you for the address of your server (which must be running on tcp port 10110).

If I can find someone with an iThing for some hackery I'll see if bonjour works with that.  Love to hear form anyone who's done their on investigations....

[B. Parastar]

Hello Keith,

Has anything in relation to send the NMEA data to Navionics changed with the latest version of Kplex? Last season with the older version of Kplex I followed your instruction and I got everything to work with Navioncs. This season I started updating my Kplex to the latest version and it seems I'm not able to read NMEA data on Navionics. Is there anything that I need to be aware of?

Thanks
Kind regards
Behzad

[Keith Young]

>  Is there anything that I need to be aware of?

Oh dear.  The latest version *does* have some changes to the UDP code but it *should* simply be fixes rather than breakages....

What does the relevant part of your config look like and I'll see if I can replicate it

[B. Parastar]

Hi Keith, first of all thank you in advance for looking into this. Below is my conf.

dhcpd

sudo nano /etc/dhcp/dhcpd.conf

ddns-update-style none;

default-lease-time 600;
max-lease-time 7200;

authoritative;

log-facility local7;

subnet 192.168.129.0 netmask 255.255.255.0 {
range 192.168.129.129 192.168.129.191;
}

sudo nano /etc/network/interfaces

#loopback
auto lo
iface lo inet loopback

#wired connection
iface eth0 inet dhcp

#wifi hot spot

allow-hotplug wlan0
iface wlan0 inet static

address 192.168.129.1

netmask 255.255.255.0
post-up /usr/local/bin/startap
pre-down /usr/local/bin/stopap

Sudo nano /etc/kplex.conf

#Multiplexer
[serial]
filename=/dev/ttyUSB0
direction=both
baud=4800
optional=yes
#Nexus server
[serial]
filename=/dev/ttyUSB1
direction=both
baud=4800
optional=yes
[serial]
filename=/dev/ttyUSB2
direction=both
baud=4800
optional=yes
[tcp]
mode=server
port=2000
direction=both
[udp]
device=wlan0
port=2000
direction=both

[B. Parastar]

Anybody can help what I need to change in my conf. In order to be able send nmea data to navionics with the latest version of kplex? In the previous mai (above) you can see my existing conf.

Thank you in advance

[Keith Young]

Try changing "direction=both" to "direction=out" on that last "udp" stanza.  Any difference?

If you know how to use tcpdump, do you see anything being sent out to udp port 2000?

If not, is there another linux/unix/OS X host you can run kplex up on, connect it to the wireless hotspot and run:

kplex -f- udp:port=2000,direction=in file:direction=out

Anything?

Are you sure the device you're connecting to the wireless access point is actually connected to that access point successfully?

[B. Parastar]

I changed "direction=both" to "direction=out", no changes.
I checked whether anything be sending out to udp port 2000, nothing is sent out.
I re-installed kplex, still no luck.
I'm sure that the device I'm connecting to the wireless access point is actually connected to that access point successfull, as tcp port is connected perfectly to iNavx through the same access point.

At one point I made a back-up of the kplex v. 1-3-1 in my computer, so I replaced kplex 1-3-3 with 1-3-1 on my sd and now everything is working again with navionics.

I use navionics on my iphone and ipad, so is there anything on the latest udp update that might be conflicting with apple devices?

Thanks

[Keith Young]

At one point I made a back-up of the kplex v. 1-3-1 in my computer, so I replaced kplex 1-3-3 with 1-3-1 on my sd and now everything is working again with navionics.

I use navionics on my iphone and ipad, so is there anything on the latest udp update that might be conflicting with apple devices?

There shouldn't be and I use a mac for testing but if you're saying you replaced 1.3.3 with 1.3.1 and it all started working then clearly I need to look at this because I *have* changed the udp code.  In fact I would have expected 1.3.3 to work where 1.3.1 didn't.  Can you try one more thing?  add and "address=" line to the udp interface and add the broadcast address of the interface (192.168.129.255 if I understand the rest of that configuration correctly).

I'm a bit busy at the moment so it may take me a couple of days before I get to revise this but I will look at it.

[B. Parastar]

Hi Keith,

Thanks for the answer. I have tried with the address as you suggested. However, still no nmea data send out. One more time I removed kplex 1.3.3 and installed it again and still nothing came out.
In iNavx I can monitor if any data is sending out on the udp port 2000, however, on the iNavx data screen appears "-->connecting (UDP)-waiting for NMEA...".

Now I'm back to v.1.3.1 and no hurries as things are working fine. But I'm interested to hear about your feedback.

[Keith Young]

I'm guessing you're running this on something like a raspberry pi, yes?

I don't have an ARM computer with me at the moment. I've checked on linux/x84_64 and can't reproduce the problem.  I'm not using an identical configuration because I don't have serial to usb connectors with me either but the udp declaration is effectively the same.

My next thought is that maybe there's something different about your network devices than the ones I'm testing with.  Can you do 2 things?

1. post the output form ifconfig -a

2. With 1.3.3 installed (sorry to ask) run kplex with "-d3": either run kplex in the foreground and post the output of grep it out of syslog.

Thanks

[B. Parastar]

Hi Keith,

Thanks for looking into this.

That is correct I'm using raspberry pi.

Following as requested:

sudo ifconfig -a
eth0 Link encap:Ethernet HWaddr b8:27:eb:40:7a:ff
inet addr:192.168.0.185 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:345 errors:0 dropped:0 overruns:0 frame:0
TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22407 (21.8 KiB) TX bytes:7382 (7.2 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76 (76.0 B) TX bytes:76 (76.0 B)

wlan0 Link encap:Ethernet HWaddr 74:da:38:58:3c:4d
inet addr:192.168.129.1 Bcast:192.168.129.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2302 errors:0 dropped:4 overruns:0 frame:0
TX packets:3571 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:124244 (121.3 KiB) TX bytes:449516 (438.9 KiB)

sudo kplex -d3
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyUSB0 for input/output
Could not stat /dev/ttyUSB1: No such file or directory
Failed to initialize Interface _serial-id2
Could not stat /dev/ttyUSB2: No such file or directory
Failed to initialize Interface _serial-id3
Failed to open tcp server for (null)/10110: Address already in use
Failed to initialize Interface _tcp-id4
kplex DEBUG: Cleaning up data for exiting output interface _serial-id1 id 10000
kplex DEBUG: Cleaning up data for exiting output interface _serial-id1 id 10000

[Keith Young]

Thanks for taking the time to post this.  There's definitely a bug in here: I've forced a crash in my own testing.  I don't have much time over the next few days but I'll try my best to look.

[Keith Young]

I've found a horrible bug which was introduced with the new scheme for giving interfaces a default name when none is specified and kicks in when an interface is specified as "optional" but doesn't get initialised.  If you comment out any interfaces which you know won't get initialised (because you don't have a serial to usb converter attached for example) then the problem should be avoided.

I'll look at this further tomorrow.  I can't rule out something else being wrong but this in itself would cause weirdness.

Thanks again for spotting this

[B. Parastar]

You are welcome.

I just want to let you know that I changed my config. to the following (without any "optional" and only with one serial to usb connection from a gps to the pi) and still no data from UDP port.

#Multiplexer
[serial]
filename=/dev/ttyUSB0
direction=both
baud=4800

[tcp]
mode=server
port=10110
direction=both
[udp]
device=wlan0
port=2000
direction=out

[Keith Young]

I just want to let you know that I changed my config. to the following (without any "optional" and only with one serial to usb connection from a gps to the pi) and still no data from UDP port.

Oh dear.  One problem was bad enough.  Any chance you could post the output with "-d3" and the new (no "optional") config? 

[B. Parastar]

Hereby as requested ( "-d3" without "optional" in config.):

/etc/kplex.conf

#Multiplexer
[serial]
filename=/dev/ttyUSB0
direction=both
baud=4800
[tcp]
mode=server
port=10110
direction=both
[udp]
device=wlan0
port=2000
direction=out

-------------------------------------------------------------

sudo kplex -d3
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyUSB0 for input/output

Failed to open tcp server for (null)/10110: Address already in use

Failed to initialize Interface _tcp-id2

[B. Parastar]

Last part once again, in a correct way.

[B. Parastar]

Sorry I try once again

[Keith Young]

In the develop branch on github I have fixed the problem I saw with optional interfaces.

Unfortunately I don't immediately see how this would cause a problem when no interfaces have failed.That's not to say it wouldn't, it's just I haven't had an "Ah yes...I see how that would be a problem..." moment..

If it's easy for you to clone the develop branch and see if your problem is resolved by this (with the original config).  If you're not happy with using git then I'll work on this some more over the weekend and see if I spot something else

[Keith Young]

Oh wait! Duh.  Sorry. It's been a hard week.

From the debug info above your tcp server is failing which means the whole process bombs out before it initialises the udp interface.  It's probably not initialising because there's already a kplex process running.

So *first* stop the already-running kplex.  Then run as you did above with -d3..  With no "optional"s if everything initialises OK it should all work and then my fix should fix the optional bit...

[B. Parastar]

Thanks for the answer. Unfortunately I'm not so familiar with git and coloning etc. but I will try to see if there is a guideline for that somewhere.
If not, then I will need to wait until a new version of kplex is released.

By the way, I ran "-d3" while kplex was not running in the background and without "optional" in config. Following is the outcome, if it can help for some reason.

kplex -d3
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyUSB0 for input/output

kplex DEBUG: _tcp-id2: initialised
kplex DEBUG: _udp-id3: BINDTODEVICE failed on device wlan0
kplex DEBUG: _udp-id3: output address 192.168.129.255, port 10110

[Keith Young]

Thanks for the answer. Unfortunately I'm not so familiar with git and coloning etc. but I will try to see if there is a guideline for that somewhere.

I'll see what I can send you.  Are you OK with compiling from source?  If not I'll see what I can sort out.

 

By the way, I ran "-d3" while kplex was not running in the background and without "optional" in config. Following is the outcome, if it can help for some reason.
kplex -d3
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyUSB0 for input/output
kplex DEBUG: _tcp-id2: initialised
kplex DEBUG: _udp-id3: BINDTODEVICE failed on device wlan0
kplex DEBUG: _udp-id3: output address 192.168.129.255, port 10110

That's pretty much what we'd expect to see: note that the udp interface gets initialised.  Except....The port is wrong (your config file has 2000, yes?).  Let me look at that...

Thank you for your continuing help

[B. Parastar]

Hi Keith,

I haven't tried compiling from source, but it doesn't seem to be complicated.
Yes my udp port in config has 2000.

Thanks

[Keith Young]

I haven't tried compiling from source, but it doesn't seem to be complicated.

I've reproduced your problem which is half way to fixing it: don't compile anything yet... 

[Keith Young]

Bug found and fixed.  There isn't a workaround.  The problem is not that kplex is not sending out udp traffic but that it's sending it on the wrong port (10110) and whether it choses the port you specify or the default port may vary between invocations with the same configuration file (which is why I hadn't encountered this in testing). Users who go with the default port are unaffected.

The fix is in the develop branch on github.  I'll do a bit more testing then see if I can compile a test raspbian binary and send you a link

[Keith Young]

I've uploaded an armhf binary compiled on a pi model v1 with an old version of raspbian which should work for most pis.  I've sent a mail to the email address you're registered with here giving the url.  Let me know if it works.

If anyone else is experiencing the same problem let me know and I can supply the link.

If you could confirm this resolves the issue I'll work on releasing a new version.

[Keith Young]

My thanks to B. Parastar for reporting this and testing the fix (which works).  To summarise:

1.3.3 contains bugs which:

- mean possible memory corruption leading to unexpected results or crashes if an "optional" interface fails on startup

- udp interfaces using a non-standard "port" *may* erroneously use 10110 instead.

This is fixed in 1.3.4 which was released last night