WiGig for Radar, AIS & Nmea stream

[rgleason]

Superfast Wireless Heading to Laptops and Smartphones in 2015 | MIT Technology Review

10xs current speeds. 2015. So wait to get mux?

[NahanniV]

Originally Posted by rgleason

Superfast Wireless Heading to Laptops and Smartphones in 2015 | MIT Technology Review

10xs current speeds. 2015. So wait to get mux?

From the article:

"The 60-gigahertz signals also have some disadvantages compared to Wi-Fi. They are blocked by walls, ceilings, and floors (although they can be picked up after bouncing off obstructions). This means they can generally only be used between devices in the same room."

[rgleason]

Yes, I think I could live with that, boats are small and you might find a straight shot to a big wireless tablet. -People walking between might interrupt, sure, but it would be very convenient to have radar overlay without wires, so the display/tablet could be located conveniently dependent on conditions.

[RhythmDoctor]

Originally Posted by rgleason

Superfast Wireless Heading to Laptops and Smartphones in 2015 | MIT Technology Review

10xs current speeds. 2015. So wait to get mux?

Your instruments likely transmit at 4800 or 38400 bps. Not sure you would need all that extra bandwidth for any marine mux.

There will always be newer, faster, fancier electronics coming out. But the bleeding edge is costly. It's hard to beat something like vYacht for ~$150.

FWIW, my vYacht mux/router is in and I just wired up some connectors to it tonight. I'll test it on the boat with my Seatalk and DSC tomorrow.

My GPS and AIS signals are going to continue to transmit to my primary computer on Bluetooth COM ports, since those have worked flawlessly for 4 years. But I'll have O send those back to the router via UDP over WiFi, so that they'll be available to other computers onboard.

[rgleason]

How i


Rick
What is your Ais over bluetooth? That would be the 38400 bps I think. How do you get the Ais onto bluetooth? Maybe there's room on bluetooth to put the instruments 4800 baud, leaving wifi for radar only.

There does not seem to be anyone doing radar over wifi due to some tech problems.

The other concern I have is the tablet or whatever recieving radar stream via wifi will need to have a strong wifi I think and be powerful enough or it will be slow and overwhelmed. Also the radar over wifi may make the tablet work overtime, get hot and fail, and if it doesn't fail it might shorten battery life so much that it needs to be plugged in! Which of course was not the goal.

If having the radar image on the tablet or computer is going to require more power and a cord, say.recharge in less than 4 hours... then we might as well plan on a fixed location and require an ethernet network plug in the device!

If I want to get radar overlayed eventually..

Too many knowns to know how it will work. Unless someone here has some sense of radar data and demands...

Maybe it would be best to get O, gps, and ais going wirelessly. Then get another hardwired device in fixed location running O for radar overlay, ais and gps.

Seems like a duplicatipn with redundant equipment and the hardware like the mux is different.


Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[RhythmDoctor]

My AIS (receive only) comes from my SH GX2150 radio. I covert it (and Garmin 18x LVC GPS) to Bluetooth with two industrial serial-Bluetooth adapters.



I have absolutely no experience with radar. I've never even looked at them at the store. So my comments here are based solely on theoretical knowledge of communications protocols:

You need to get an understanding of the data throughput of your radar. What protocol does it use to communicate via wire? If it communicates via NMEA 0183, then the data stream is so slow that current Bluetooth or WiFi technology would work with no problem. If it only communicates via NMEA 2000, then it's more difficult because of its higher thoughput and more important, it sends binary data packets instead of ASCII characters, so a lot of legacy technologies will not work. There are companies that sell NMEA 2000 - WiFi converters, and you should check with them about what the bandwidth limitations are before purchasing.

For anything wireless, having a reliable connection is critical. You may find that slower is faster in a marine environment, since lower frequency radio signals will penetrate walls (and sails and cabin tops) better and are less susceptible to shadowing from things like spars.

I would plan on having an electrical wire available for a tablet. Even with my Miix2, which gets ~8 hours battery life, I plug it into a microUSB power wire at the helm for any daysail over a couple hours. (Not because I need to, just to reduce the cycling of the battery.) The wireless data is still nice because I only have one small cable to disconnect if I want to walk around the boat with the tablet.

I think your fears of a tablet overheating because of excessive WiFi data rates is a little overblown. The most significant added battery drain will likely occur from setting the tablet to stay awake all the time (since you don't want to cut off the data stream) and turning the backlight all the way up. Check this thread for my power readings, which are amazingly low for the tablet vs. my old netbook, and note that low power draw equates to low heat.

[NahanniV]

Originally Posted by rgleason

Yes, I think I could live with that, boats are small and you might find a straight shot to a big wireless tablet. -People walking between might interrupt, sure, but it would be very convenient to have radar overlay without wires, so the display/tablet could be located conveniently dependent on conditions.

The problem with RADAR over WiFi is not lack of bandwidth. It's the way most routers handle the type of addressing used by the RADAR systems OpenCPN connects to.

Others here know way more than me, but my understanding is that data sent by UDP Multicast is limited to a slower speed so that all possible clients can receive it.

A dedicated boat router could possibly be configured to overcome this limitation.

Cheers,
JM.

[rgleason]

Yes, Nahannini I found it. Thank you.

Robbie W reported:
http://www.cruisersforum.com/forums/...-123167-2.html

...have a 3G Navico radome + the Simrad NSS8 MFD...
...at present the laptop is on a wired connection, looking at my router displays throughput is peaking around 70Mb/sec with the radar active...more than 11g can do but should be within 11n's capability.

Later Douwe Fokkema
http://www.cruisersforum.com/forums/...ml#post1554165

...Navico is using UDP multicast protocol. This will require some adjustments to my on-board router as normally UDP is restricted to the subnet it is transmitted on. I expect I can sort this out...August.

Håkan directly after

Douwe... Please make a try without any adjustments to the router. My experiances by running through a R is also straight forward without change of settings as long you use wired connections. (wire less is not feasible for a scanner in master mode.) What I didn't mention before is that Win XP-7-8 need changes to the firewall. The easiest is to disable all internal and external firewalls if possible.

Robbie W

...running radar wired thru' a router works for the wired devices but breaks the connection for wireless devices. There may be options to use IGMP/udpxy (ref: http://wiki.openwrt.org/doc/howto/udp_multicast) to make the multicast work wirelessly to required clients and mitigate the effect on other devices

Nahanni wrote

It seems like UDPXY could work, but it would require a bit of configuration to be added to the plugin.

udpxy - for Linux
http://wiki.openwrt.org/doc/howto/udp_multicast

Host wants to start receiving UDP multicast traffic...subscribes itself to a "UDP multicast group". Control of multicast groups is archived with IGMP protocol. Once a host is subscribed, all the traffic for this group is sent to it using broadcast L2 frames. and ... common bridges just pass all the broadcast traffic to all the ports. So if you use Linux to bridge wireless and wired networks (home LANs) and you subscribe to a multicast group from one of the wired clients, the wireless will be hogged too. Luckily, starting from 2.6.34, the kernel has IGMP snooping feature for the software bridges (disabled by default in OpenWrt) which should prevent unnecessary traffic on ports that were not actually subscribing.
Another important consideration is that multicasting over wireless doesn't usually work as one might expect since it uses the lowest possible bitrate (to enable all clients to "hear" it) and also employs special tricks for power-saving. Basically, this makes multicasting useless for IPTV.

udpxy
This is an alternative way which allows you to access udp multicast streams over TCP connection. As such, it works nicely both over wired and wireless links.

udpxy - Home
udpxy | SourceForge.net
https://www.mankier.com/1/udpxy
https://github.com/pcherenkov/udpxy Pavel Cherenkov

Good description: https://www.mankier.com/1/udpxy#Description
udpxy listens (on a dedicated address/port) for HTTP requests issued by clients. A client request should be structured as:
http://{address}:{port}/{cmd}/{mgroup_address}[SEP]{mgroup_port}

Examples given
192.168.0.12:5056/udp/224.0.2.26:24012
192.168.0.12:5056/rtp/224.0.2.26:24012
192.168.0.15:5056/rtp/224.0.2.26^24055
192.168.0.15:5056/status/
----------
Conditions
--Hard wired- | <----wifi--router ---->|---wifi 802.11n
one radar --->| UDP <--- udpxy------>| one OpenCPN Client
one radar --->| UDP <----udpxy----->| several OpenCPN Clients

As I understand it udpxy would merge data into the NMEA stream on a given IP (192.168.0.12)

Maybe our friend (and great help) Muttnick will see this and explain?
---------

Regarding Throughput
RobbieW says "throughput is peaking around 70Mb/sec"
IEEE 802.11 - Wikipedia, the free encyclopedia

802.11n is an amendment that improves upon the previous 802.11 standards by adding multiple-input multiple-output antennas (MIMO). 802.11n operates on both the 2.4 GHz and the lesser-used 5 GHz bands. Support for 5 GHz bands is optional. It operates at a maximum net data rate from 54 Mbit/s to 600 Mbit/s.

---------
So wifi 802.11n should be adequate and this appears to be a Network "wiring" problem due to UDP being used by the Radar, and kicking the wifi clients off.

It appears Rhythm Doc was right.
---------

As far as the tablet choking, overheating or failing due to excessive radar wifi data, I guess we'll find out someday. I still don't have a sense of the heat and loads. I'll guess the quad core processors in tablets today are perfectly capable of crunching this stuff.
---------
RD advises that I am going to have to accept that a power wire will be run to the device. I will need to wait for the network wiring to be worked out, but the first step is to get a tablet, gps, ais setup on board!

It appears some kind of a wifi router will eventually be needed, unless the computer part is kept below (miniPC?) and the radar is directly wired to that which would avoid the problem.

Would it help at all to get AIS, Nmea etc of the wifi and just have the radar using wifi?

Thanks RD and Nahannini, RobbieW, Hakan and others.
RD that looks like a pretty nice arrangement thanks for sharing it.
What are your "two industrial serial-Bluetoothadapters"? I seem to remember your post of a diagram for this?

[CarCode]

Originally Posted by rgleason

What are your "two industrial serial-Bluetoothadapters"? I seem to remember your post of a diagram for this?

I use the Firefly of Roving Networks for this task.
Gerhard

[petter5]

Originally Posted by rgleason

It appears some kind of a wifi router will eventually be needed, unless the computer part is kept below (miniPC?) and the radar is directly wired to that which would avoid the problem.

It might bee that a router should be avoided and instrad use a accesspoint ( Most routers can be configured as a accesspoint) The network in a boat is of limited size and a router only makes sense for accessing internet from the local(boat) network. By using a accesspoint instead of a router, all devices will be on the same subnet avoiding problems with multicast packages not able to pass to other networks. Almost all routers is configuered for doing NAT ( network address translation) witch will complicate network and add unwanted features in a mall local network onboard a boat. I will strongly recomend to make a properly configured wireless network without a router, and test that all devices can communicate properly through this network before trying to get radar work over wifi.

[NahanniV]

Originally Posted by rgleason

Regarding Throughput
RobbieW says "throughput is peaking around 70Mb/sec"

As often happens erroneous data lives on forever on the internet while the corrections get forgotten:

Originally Posted by RobbieW

Mea culpa, had another look and I clearly cant do mental arithmetic or read properly! My router gives data in kbits/sec, it was recording a peak of 1500 kbits/sec with a 3G radar on 1/2 mile range just now. If I have the math right this time, thats about 190 Kb/sec. I'm pretty sure I've seen peaks of 6000 kbits/sec previously but even that comes in under 1 Mb/sec.

Thanks for the double check

The data rate is well within WiFi G or N capability.

Cheers,
JM.

[RhythmDoctor]

Originally Posted by NahanniV

As often happens erroneous data lives on forever on the internet while the corrections get forgotten:

Of course, even his correction is incorrect. 6000 kb/sec is well over 1 Mb/sec (megabit/second). It is well under 1 MB/s (megabyte/second).

[rgleason]

Thanks all for verifying!

Radar -----> Access Point <----- Tablet (s)

An access point could be a Computer, AP Access Point device, Router, etc
A ship does not usually have access to the internet so security is not as much of an issue, NAT and DHCP is not needed.

Now I hope we can get Muttnick to comment about the UDP and udpxy! He's always go some good ideas and huge knowledge.

[muttnik]

Disclaimer: 802.11 is not something I know much about. It smells of Magick conjuring things through thin air. I know more about the network and transport layers so I'm bluffing this layer 1/2 stuff: Please, anyone who knows more about the state of play with 802.11 implementations about today and coming soon, please correct/augment anything below.

The article in the OP appears to be talking about 802.11ad. "wigig" being the marketing name of the trade alliance pushing it.

I think the question being asked in this thread is will a new standard facilitate "radar over wireless". I don't think additional unicast throughput will help as NahanniV previously stated:

Originally Posted by NahanniV

The problem with RADAR over WiFi is not lack of bandwidth. It's the way most routers handle the type of addressing used by the RADAR systems OpenCPN connects to.

Others here know way more than me, but my understanding is that data sent by UDP Multicast is limited to a slower speed so that all possible clients can receive it.

This is exactly my understanding. The radars OpenCPN supports transmit data via UDP multicast. At the network/transport layers that's a really good plan. It's still a really good plan when used with the datalink and physical layers the manufacturer intended (i.e. ethernet/copper wires). Unfortunately the way 802.11 (i.e. "wifi") handles broadcast and multicast throws a spanner in the works, just as NahanniV describes. As well as transmitting at a far lower rate than clients can handle, there are other problems. At lower data rates the multicast will be hogging the radio for longer and due to the way contention is resolved, will have an unfair advantage, thus stuffing all your other wireless traffic. Multicast over wireless *in general* doesn't benefit from acknowledgement/retransmission at the datalink layer (which unicast wireless will tend to benefit from and is not related to transport layer reliability, so no shouts of "But UDP isn't reliable anyway!" :-), so you may well get more packet loss.

Originally Posted by NahanniV

A dedicated boat router could possibly be configured to overcome this limitation.

Again, this too is what I believe. Aside from various protocol enhancements which have been proposed, some access points seem to offer the ability to set the multicast rate (I've seen reference to this being a possibility to the apple airport but not been near one today to confirm) and some higher end kit seems to be able to send multicast IP packets to stations via unicast at the datalink layer (avoiding the issues but possibly at the expense of more traffic). From what I've read there are also opportunities some for tuning (notably reducing DTIM interval) which may be available even on domestic kit.

Given the commercial lure of video over multicast I can't imagine that the problem is going to hang around forever. Whether implementations of a 802.11ad will bring will them a common solution is something I don't have enough information to speculate. Someone reading this hopefully does :-)

Regarding udpxy, if I understand correctly from the blurb (if I'm wrong, someone please say :-) we'd send it a request over http to listen for multicast packets on a given address and port which it would then forward back over the http (unicast tcp) connection. The primary problem with this is that OpenCPN has no mechanism to request data from udpxy in this way. It could be coded up but is udpxy a sufficiently "standard" solution to bother doing it? Secondly you'd have to have a device to run udpxy on which isn't on your wireless network as well as some way of stopping multicast from your radar/sonar (wired network) from getting onto your wireless network. You could do this by segmenting your network or using a switch which implements IGMP snooping. Those using open source firmware on routers would be fine (run udxpy on the router which also implements igmp snooping). Regular folks using a cheap domestic switch will probably be SOL.

Anyway, that's my understanding which is undoubtedly flawed and inadequate :-)

EDIT: Note that broadcast and multicast will suffer from the same issue over wireless, but at the kinds of data rate involved in pumping out typical NMEA-0183 streams (including AIS), use of broadcast/multicast for regular boat data (not radar/sonar image data requiring high rates) shouldn't pose a problem.

[rgleason]

Muttnik
That really puts it into perspective. Thank you!
1. Wait for stanards to solve it.
2. Get at least a router or other device and run udpxy AND modify O to make requsts.
3. Hardwire the radar.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app