linking kplex to FURUNO WiFi Radar (DRS4W)

[Igor Sarychkin]

Dear All,

According to TimeZero their ipad app can overlay Furuno's WiFi radar chart together with NMEA data where Furuno's WiFi radar works as Access Point and NMEA data is supplied by a serial-to-WiFi bridge.

Can RPi connect to the AP via WiFi and feed NMEA frames?

Where in kplex config file should I start looking to make it join other wifi network?

More info on MaxSea TimeZero here

http://www.maxsea.com/maxsea_timezero_ipad_app  (user guide link on the right)

Cheers

Igor

[joachim bakke]

Hi,

That would not be in kplex configuration, but to make the rpi connect to an existing wifi ap such as this: https://learn.adafruit.com/adafruits-raspberry-pi-lesson-3-network-setup/setting-up-wifi-with-occidentalis

Joachim

[Keith Young]

Can RPi connect to the AP via WiFi and feed NMEA frames?

Where in kplex config file should I start looking to make it join other wifi network?

As Joachim has said, the connection to the radar's AP network as a client is not part of kplex: see his link.

I was initially concerned that the app would be looking for data in NavNet format which seems to have some non-NMEA preamble attached to it:

http://www.cruisersforum.com/forums/f134/opencpn-and-furuno-navnet3d-119421.html

...however the manual linked to suggests that the app will just be looking for a simple NMEA data source so you should be OK.

The manual suggests that the app can use data over TCP (with address/port) or UDP (with port).  If you're using DHCP to configure the raspberry pi's address with the radar's AP you won't know in advance what the address is to use.  If you can tell the access point to assign a particular address to the pi (by configuring it to assign a particular IP address when the pi's MAC address associates), or if there's an address outside the access point's DHCP range but within its subnet which you can statically assign to the pi, then you can configure kplex to act as a tcp server and have the app connect to that address.

In all other cases you're best using UDP broadcast, which you may prefer to use anyway.  You don't need to tell kplex in advance the broadcast address: it can work it out if you tell it what interface to use, so in your config file you could say:

[udp]

device=wlan0

direction=out

type=broadcast

port=10110

This would broadcast data over wlan0 (whatever its address) on port 10110.  You configure the app to receive NMEA data over UDP broadcast on port 10110.  Actually "port=10110" is the default: you only *need* "port=" if you use a port other than 10110.  If you don't give an address you don't need "broadcast=" either: kplex can work out that that's what you mean, so you could just say:

[udp]

device=wlan0

direction=out

[Igor Sarychkin]

Cheers, Joachim
That's exactly what I needed to start in the right direction.

[Igor Sarychkin]

Thanks Keith ever so much for the detailed explanation. Now I have no excuse - I HAVE to buy an iPad :). Ordered one for pickup tomorrow, so come a rainy day and I will put it to test.
After a couple of hours I managed to assemble a simple RPI WiFi AP test base and have kplex up and running, serving GPS nmea from RS232-USB port.
From initial tests I noticed that not all NMEA apps are happy with the UDP connection, while TCP works really well. Only OpenCPN on Windows worked fine via UDP, but iRegatta, EDO instruments and NKE on Android would only connect via TCP (NKE crashes after showing lat/lon for one sec). Anyway, one can't please everyone! Thanks again.

Igor Sarychkin

[Keith Young]

From initial tests I noticed that not all NMEA apps are happy with the UDP connection, while TCP works really well.  Only OpenCPN on Windows worked fine via UDP, but iRegatta, EDO instruments and NKE on Android would only connect via TCP (NKE crashes after showing lat/lon for one sec).

That's concerning.  iRegatta *should* work.  The "udp" interface type is new.  Could you do me a favour and try two things?

1. Change the udp configuration to a "broadcast" interface (this is the "legacy" method for this)

[broadcast]

device=wlan0

direction=out

2. If that still doesn't work for those android apps, try the same "broadcast" config as above but add "address=255.255.255.255".  This will force use of the broadcast address of the zero network rather than the subnet broadcast address. I can't imagine why anyone would explicitly program their app to receive that but it's worth a try for completeness.

Thanks 

[Keith Young]

That's concerning.  iRegatta *should* work.

I installed the free version of iregatta on my phone and hooked my plotter up to my pi access point.  It worked with both UDP and TCP however...

I ran tcpdump on my macbook (also a client of the pi access point) and also on the pi.  I noticed that there was a fair amount of data which the pi thought it was sending but was not being received by the macbook.  I don't seem to be dropping packets on the pi (although my cheap wifi device doesn't provide ethtool with any stats) so I'm guessing this is a wireless issue.

unicast 802.11 packets get layer-2 acked and retransmitted if dropped.  multicast/broadcast packets don't get acked/retransmitted.  Note this isn't a UDP vs TCP thing: it's a wireless-specific unicast vs multicast/broadcast thing. Perhaps the wireless network being created by your DRS4W is quite lossy and broadcast UDP data is simply getting lost.  I strongly suspect that this device, unlike most wired RADARs which send image data over multicast, uses unicast TCP to overcome the various issues with multicast radar over wireless: I'd be interested if you could confirm that (Furuno didn't reply to my requests for information).

That's just a guess though.  You could always test it by running tcpdump on the pi and then tcpdump/wireshark on a laptop joined to the wireless network.

[Igor Sarychkin]

Hi,Keith
Looking at the live nmea stream on the iPad MaxSea, UDP does seem to come through with a lag compared TCP, with a latter running faster.

I've got my iPad now, but Furuno radome is still under the bed on the boat - it goes on the mast for passages only. So I made an Arduino nmea simulator connecting to RPI/kplex via a TTL-to-USB cable.

The Rpi now is configured to connect to my home WiFi AP and feed NMEA data to my home lan. Kplex configs are similar to the ones shown as working in the neighbouring thread on Navionics Sonarcharts Live. By the way, in this setup Navionics shows DBT only when I relay the UDP stream from iPad via a free app 'MID WiFi' - there's a setting inside the app to do exactly that where one can set a port number (2000).

The whole rigmarole with Furuno Radar is due to its refusal to join an existing boat's WiFi by design - that would be way too logical. But if you make your main AP on Furuno, then you need to run the radar all the time to be able to access your data, which is stupid.

Kplex is the answer!

Best regards,

Igor

[Igor Sarychkin]

Just to confirm, Furuno WiFi radar, iPad MaxSea chartplotter with RPi based kplex feeding boat data inc IAS - all working happily together.

Cheers, Keith!

[Keith Young]

Thanks for the feedback!

[Jose Luis de Lara]

Could somebody explain to me slowly (like to a dumb person), how to joint together the Furuno radar (designed to work as AP) with a WiFi network?, so any other application connected to the network can see NMEA data from the Furuno Radar?
I have an RPi-4 device (running OpenPlotter package) and a openWrt router (also running kplex).

Thanks a lot for the feedback!

[Keith Young]

Could somebody explain to me slowly (like to a dumb person), how to joint together the Furuno radar (designed to work as AP) with a WiFi network?, so any other application connected to the network can see NMEA data from the Furuno Radar?
I have an RPi-4 device (running OpenPlotter package) and a openWrt router (also running kplex).

First question: Do you really mean *NMEA data* (ie RSD/TLL/TLB/TTM sentences) or do you mean RADAR image data (which will be in proprietary format, not NMEA)?.  I'm somewhat hampered in answering this by not really knowing much about the DRS4W and the manuals not giving much away about how it works.  I can however make some guesses and suggest how I'd approach the problem if I had one of these radars to experiment with.  Is it the case that your "main" network uses the openWRT router as an access point and the pi is normally a client of this?

[Arthur Lamiral]

Bonjour Jose Luis,

sur Raspberry Pi OS (previously called Raspbian), c'est le service wpa_supplicant qui connecte la carte réseau wifi (wlan0) sur un AccessPoint .

Vous devez paramètrer le service en modifiant le fichier /etc/wpa_supplicant/wpa_supplicant.conf avec nano

exemple :

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

# votre code de Pays

country=FR #( ES ?)
network={
        ssid="ssid du radar Furuno"
        psk="Le mot de passe demandé par Le radar Furuno"
        }
redémarrer le client DHCP pour obtenir une adresse réseau du radar Furuno :

systemctl restart dhcpcd.service

 Controle :

ifconfig

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.10  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::e7c7:133f:f86e:6696  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:e0:61:b9  txqueuelen 1000  (Ethernet)
        RX packets 4145  bytes 676799 (660.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1508  bytes 172445 (168.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0 a reçu une adresse IPv4 valide

Ceci pour répondre à cette question :

Could somebody explain to me slowly (like to a dumb person), how to joint together the Furuno radar (designed to work as AP) with a WiFi network?

Pour répondre à celle ci :

so any other application connected to the network can see NMEA data from the Furuno Radar?

Il faut bien lire la notice du radar Furuno pour savoir ce qu'il peut faire, et dans quelles conditions ???

Bonne chance

Arthur

[Jose Luis de Lara]

Merci Monsieur Arthur

[Jose Luis de Lara]

Hi Keith,

I am assuming Radar is working with NMEA data (we’ll see...) 

Yes the openWR Router is the main WiFi, RPI is a client, Ethernet connected to router (RPI WiFi is not being used, so it could be Radar’s client).

What is your suggestion?

Thanks a lot!

[Keith Young]

Radar image data is not transported in NMEA sentences.  It's all proprietary, which is why raymarine radar only works with raymarine plotters, garmin with garmin etc.  The Garmin and Navico formats have been reverse engineered by the OpenCPN folks.  There doesn't seem to be much info about on the DRS4W.  Garmin/Navico/Raymarine radars use multicast for their imaging data. This works rather badly with wifi (see http://stripydog.blogspot.com/2015/01/radar-over-wifi-not-always-pretty.html ) so I'll guess the DRS4W will use a TCP connection (I did ask Furuno this when it came out, once directly and once via a dealer and never got a reply).

Many radar units will also put out NMEA sentences, but these contain target tracking and radar system data, NOT radar images.  If you just wanted that NMEA data my approach would be:

* Join the Pi wifi to the DRS4W network. Arthur describes wpa_supplicant configuration above but there's probably a graphical tool for configuring things easily (sorry haven't played with that part of raspbian for a long while).  You will save yourself some hassle by using a static IP address (and therefore not worrying about any weirdness like having the furuno's dhcp adding static routes or dns servers which may or may not happen).  This doc:

https://mytimezero.com/tz-iboat/faq

...in the "How can I use external instruments (GPS, Heading, etc.) and the DRS4W at the same time?" section suggests using 172.31.3.100 with a subnet mask of 255.255.0.0, so your /etc/network/interfaces file would need additional lines something like: (**Anyone feel free to contradict this: I don't have a pi to experiment wth at the moment and they change this stuff**).  Check your actual wireless device name: it may not be wlan0 depending on your OS.

auto wlan0

iface wlan0 inet static

address 172.31.3.100

netmask 255.255.0.0

wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

* You could restart networking or just reboot

* If you have kplex providing a tcp server with no address specified (ie just mode=server so it will listen on all interfaces), If you join an ipad or something to the furuno network you should be able to get your boat data from kplex on 172.31.3.100.  If you didn't reboot your pi above, you'll need to restart kplex.

* Assuming you have kplex running on the pi, add in a new stanza:

[tcp]

address=<address>

port=<port>

persist=fromstart

...replacing <address> and <port> as appropriate

This assumes (a) that you're interested in NMEA target tracking data (you might not be), (b) that the device uses TCP (a good bet), (c) that it does actually produce NMEA target tracking sentences (maybe) and that these are available on a fixed address and port (if they're produced, this is also a reasonable assumption).  So what's the value of <address> and <port>?  I've mailed furuno support again.  Maybe I'll get an answer this time.  Some screen shots I've seen of the firmware update process makes me suspect the address is 172.31.3.17.  If Furuno tell us what port (if any) NMEA data are available on, we plug that in there.  If not we'll have to use nmap to do some port scanning and experiment (but let's leave that for the time being).  If the drs4w does provide nmea data and it does it on a separate port to the image data then all good.  If it's somehow interleaved with the image data then the pi will be doing a log of unnecessary processing throwing out the image data.

If anyone has the technical details of the drs4w in this respect, do post and make our lives easier :-)

So how do we get an ipad on the "main" network to speak to the radar?  Well that depends on how the app finds the radar.  If it's via some service discovery mechanism then that may be tricky.  If it's by simple IP address (e.g. a known value like "172.31.3.17") then we might have more luck.

First you'd have to add a static route on your router directing traffic for 172.16.0.0/16 to the pi (I'm not sure if you can add a static route into an ipad but I'm sure it'll respond to redirects)

Then you need to set up the pi to route traffic, and because I very much doubt we can add a route back to your main network onto the furuno, you'll need to set up the pi to NAT any connections from the main network.

Assuming you have no current iptables rules, add the following to /etc/sysctl.conf:

net.ipv4.ip_forward=1

Then:

sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

...you'll need to save that so it persists across a reboot and that's different on all flavours of Linux.  I've seen a note that:

sudo netfilter-persistent save

...will achieve this, but it may be different on different raspbian versions and like I said, I haven't played with raspbian for a while.

Note I didn't address adding a static route into your router: I'm not familiar with your router but this should be straightforward.

Apologies: You'll see there's a lot of "unknown"s in here and I'm a little rusty on raspbian.  Really I could do with getting my hands on one of these furuno units to play with and come up with a definitive step by step answer.  Perhaps I can ask around at my marina to see if anyone has one although with covid-19 stepping aboard a stranger's boat for a beer and a play with their technology is not so straightforward any more.

[Keith Young]

Furuno UK kindly replied to my queries.

* The DRS4W has no NMEA output.  It doesn't do any target tracking

* They've indicated that apps access it via a fixed address

So there's no point in trying to get any NMEA data from it because there isn't any.

I will argue that trying to route between your main network and the furuno network is going to be more effort than it's worth for most people

Providing boat data (GPS/Heading) on the furuno network however would be a good goal.  Follow the advice in the time zero faq referenced above.  Join the pi to the Furuno network as described above.  Assuming you have tcp server interface already configured in kplex with no specific address on it, it should be available on all interfaces after you restart everything and you can use the data in the app on a tablet on the furuno network by telling it that data is at 172.31.3.100, port 10110 (or whatever if you use something non-default).  Note that heading and GPS are beneficial to the app