Wireless outages over water

The wireless link between me and the point of presence runs 8.0 km over water.

Planning and installing the link,buying the radios and antennaehas been pretty much a trial and error affair, with me learning as I go. The original plan was to buy two linksys wap11 bridging access points, build two cantennae, modify two expressview DSS dishes with a cantenna for each dish as a feed point, and enjoy a high speed wireless link to ADSL service. I have to say that though the modified dish and cantenna operated fairly well, I went commercial for the dish and driven element to have characterised antenna components.

The present setup still uses the wap11 version-2.2 access point radios with flashed to dlink-900AP+ firmware; two commercial 24db grid parabolic dishes, one on a tower at about 85 feet above high tide and the other dish at a site about 240 feet elevation in the town with ADSL (co-ordinates). Horizontal polarization is used.

Fresnel zone calculator found on the net yields 50 feet (15meters) as the first Fresnel zone halfway along the path This path has at least that clearance.Using a wlan budget calculator for 15dBm radios 24dBi dishes, path loss of -120 dB, 3dB cable loss at each end, and -78dB receiver sensitivity leaves me with a 27dB margin.

This configuration provides a usable link most of the time, with a data rate about ten times faster than my dialup rate of 49000 bps. The wireless link fails though. At some times in the day the link dies for up to three hours. At first I attributed the outages to local interference, then to remote interference, then to atmospheric ducting, then to malicious jamming.

Then I decided to log the outage events. After a few days of logging time vs outage, I plotted the results. The plot made little sense; the outages still appeared random through the days. Replotting to show the daily outages in one 24 hour period showed the outages to be progressing later in each day, and changing in duration. A little thought provided a correlation to the tide cycle; the outages were in step with the tides -- the low tides. The link went down at low tide! To show this dependence on the tide cycle I put a little more effort into the logging routine, using the xtide program to plot the value of the tide every five minutes (crontab) when the link was up. Plotting this data gave me a daily tide table with gaps in the curve when the wireless link was down.Take a look at large plot of October or November.

Be aware that the tide curve is generated by tidal harmonic tables for the nearest tide site, Alert Bay, which is about 8 mi (13 km) away. Tide heights as plotted have corelational value for my outages, not for navigational accuracy.

September 2003 was the first month I collected data on the outages; the tide range here is rather moderate in September. The tidal range reaches its maximum here in late November. The increasing extremes of tide level have shown further outage events; now the high tide levels are causing outages, and even more interesting, the low tide extremes now show the link functioning again. This behavior I attribute to classical multipath destructive interference. Another feature shown on the plot is that some low tide events do not result in an outage. These events correlate to the state of the water surface: when the wind is blowing and a storm is causing choppy water, the water surface is rough and scatters the reflection from its surface, preventing the outage. Conversely, when the water surface is glassy smooth, the outages begin sooner and last longer.

Lloyd's mirror, a variation on the classical two-slit experiment:

Microwave experiment that demonstrates the multipath interference condition.

http://www.physics.uq.edu.au/people/mcintyre/phys2090/documents/microwaves.pdf

http://www.ph.unimelb.edu.au/staffresources/lecdem/wc6.htm

Duplicate Packets, Ping DUP!

EXAMPLE:

PING 192.168.0.251 (192.168.0.251) 56(84) bytes of data.

64 bytes from 192.168.0.251: icmp_seq=1 ttl=127 time=0.080 ms
64 bytes from 192.168.0.251: icmp_seq=1 ttl=127 time=0.313 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=1 ttl=127 time=2.62 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=1 ttl=127 time=3.54 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=1 ttl=127 time=9.59 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=2 ttl=127 time=2.85 ms
64 bytes from 192.168.0.251: icmp_seq=2 ttl=127 time=15.7 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=2 ttl=127 time=17.0 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=2 ttl=127 time=17.2 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=3 ttl=127 time=0.085 ms
64 bytes from 192.168.0.251: icmp_seq=3 ttl=127 time=0.407 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=3 ttl=127 time=0.573 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=3 ttl=127 time=0.731 ms (DUP!)
64 bytes from 192.168.0.251: icmp_seq=3 ttl=127 time=10.0 ms (DUP!)

--- 192.168.0.251 ping statistics ---
3 packets transmitted, 3 received, +11 duplicates, 0% packet loss, time 2028ms

This example shows about 4 duplicate packets for each ping; at times the ping would return up to 50 DUPs per ping. You can imagine what the throughput of the wireless link was with all those duplicate packets in the pipeline! Use of a packet sniffer like tcpdump showed that the duplicate packet problem was present in all TCP protocols, too. I monitored the link bandwidth with the "iperf" tool. At worst,the bandwidth was about 200 kilobits/second. Some firmware flashing improved the bandwidth to about 400kbit/sec. After some further firmware fiddling, I could demonstrate a bandwidth of around 700kbits/sec, but I could not pinpoint just what the problem was that caused the duplicate packets.

Let me be more specific about the hardware involved. In July, 2002 I bought two linksys WAP11, ver-2.2 access points. These are still the units operating the link. The lowest bandwidth was with the linksys firmware. I discovered the linksys to Dlink firmware hack and when I had given uphope of getting anywhere with that junk Linksys sells I risked it all and flashed the units to the Dlink firmware. After the firmware flash, the bandwidth was up to around 400kbits/sec. I could then use Dlink firmware and changed the firmware to ver-2.57 on one end and ver-2.60 on the other end of the link. The bandwidth was 700kbits/sec after that change, and I was pleased with the improvement. The duplicate pings were running around 12 duplicates per ping.

I fiddled with antenna pointing, clearing the line of sight (big bucks to top some spruce and cedar trees), postings to wireless user groups, etc. No improvement..

In November, Dlink released ver-2.61 firmware so I tried that in both units. My bandwidth dropped back to 400 kbit/sec! Duplicates were back to 22. What had gone wrong?

Each time I flashed the units, I went through a fixed procedure: 1) restore to defaults; 2) power cycle; 3) flash firmware; 4) power cycle; 5) customise settings; 6) power cycle. I had customized the speed of the radios to the "1-2, 5.5, 11" before doing any testing believing that Faster is Better. For lack of any better ideas, I changed the default setting of "long preamble" to "short preamble', and got better bandwidth and fewer DUPs - just 4 DUPs. I was on a roll.... I changed both radios to "short preamble" and speed settings to 1-2 mbits; the bandwidth went up to 1.44mbits/sec, with NO duplicate packets at all. Slower is faster! Slower is better.

These improvements were made on November 22; the plot of time vs tide shows a more defined pattern of outage after that date. Notice the right hand side of the graph; the outage begins at a lower tide, has a shorter duration, and ends at an even lower tide. The window of outage lasts a shorter time with the radio speed set to 1-2 mbit.

The lesson learned in all of this is that the setup parameters are very important in cheap consumer wireless products when using them over long distances. The slow speed settings are much more robust than the high speed settings, and can deliver much better bandwidth.

Last update December 7, 2003

andyb at
eskimo.com