Tidal effects on signal strength

[tim]

I am seeing some strange signal strength changes over long marine links. Periodically I lose about 20 dB of signal for about 60 minutes. The period varies but is usually once every about 11 - 12 hours.

I have been assuming this is a tidal affect but the period does not map nicely onto the tide times and it is so variable (the weather at sea has been fairly consistent).

http://southwell.wdi.co.uk/stats/radio/radio_wlan2_62.72.160.70-day.png

In the graph above the green area is the signal strength and the blue line is the noise level. The white area between the blue line and the green area represents the snr. The y scale is the power level inverted (ie 90 dB is -90 dB)

Both ends of the link show similiar patterns, so it is definitely something affecting signal strength in both directions. none of my non marine links show anything like this.

For the graph above, both the radios are about 60 metres above sea level and there is clear LoS between them.


I am planning some even longer marine links and I'm a little worried that this phenomenon will get worse with distance.

Tim

[rasimoes]

Hi Tim!

How you create this MRTG graph? It's via SNMP or a special script?

PS: Sorry for the off-topic... 8)

Thanks!

[tim]

Special script :


#!/bin/sh
#
#
STAR=/home/mrtg/conf/starutil15

case $4 in

ap)
$STAR $1 $2 -ai $3 |
grep -v Client |
head -n 1 |
sed -e 's/ */ /g' -e 's/-//g' |
cut -d" " -f8
sleep 1
$STAR $1 $2 -ai $3 |
grep -v Client |
head -n 1 |
sed -e 's/ */ /g' -e 's/-//g' |
cut -d" " -f9
sleep 1
;;

infra)
$STAR $1 $2 -ci $3 |
grep Signal |
sed -e 's/ */ /g' -e 's/-//g' -e 's/dBm//g' |
cut -d" " -f7
sleep 1
$STAR $1 $2 -ci $3 |
grep Signal |
sed -e 's/ */ /g' -e 's/-//g' -e 's/dBm//g' |
cut -d" " -f10
sleep 1
;;
esac

echo
echo $5


Its a shell call out to starutil and then use the unix tools to extract the relevant numbers from resulting output (bit of a hack I'm afraid but it works)

The only tricky bit is that starutil15 does not always report the name of associated stations so I treat ap links and infra links differently. For ap links I use a starutil15 -ai and for infra I use starutil15 -ci.

The code is not correct for ap links, as it assumes only 1 association (all my point to points are 1 association) so more work is needed to fix that bit.


The Target info for one of my links is :


############################################
################## GLOBALS #################
############################################
#
WorkDir: /home/mrtg/html/radio
Options[_]: growright, nopercent, noinfo, gauge
MaxBytes[_]: 120
WithPeak[_]: ymwd
Suppress[_]: y
YSize[_]: 100
XSize[_]: 350
Unscaled[_]: dwmy
YLegend[_]: SNR -dBm
ShortLegend[_]: -dBm
Legend1[_]: Signal Level (-dBm) per 5 minute interval
Legend2[_]: Noise Level (-dBm) per 5 minute interval
Legend3[_]: Peak Signal (-dBm) Level per 5 minute interval
Legend4[_]: Peak Noise Level (-dBm) per 5 minute interval
LegendI[_]: Signal
LegendO[_]: Noise
#
#
############################################
################## RADIO LINKS ############
############################################
#
#
#################### RADIO TEST FOR bournemouth-poole ###############
#
Target[radio_wlan1_62.72.160.6]: `/home/mrtg/conf/mrtg-radio-probe 62.72.160.6 password wlan1 ap bournemouth-poole`
Title[radio_wlan1_62.72.160.6]: Signal/Noise Monitor for bournemouth-poole
PageTop[radio_wlan1_62.72.160.6]: <H1>62.72.160.6/wlan1  &nbsp&nbsp bournemouth-poole &nbsp&nbsp WDS</h1>
#


In the above extract the line starting Target is the one that calls out to my special script. The only change, I've made in the example above, is to change the password for my staros box to password - for obvious reasons.

Tim

[dkii]

what area do you live in? You're not trying to link across the bermuda triangle are you? :) One possibility, I've been monitoring the humidity via mrtg and notice on the graph 2 peaks, one in the early morning, and one in late afternoon, appx 12 hours apart. I don't really think that would affect signal strength, since it is almost unaffected by rain, however I'll set up you're script and see if there is a connection between humidity and signal strength. Possibly it could be causing condensation on the antenna elements. I doubt it, but I don't see many other possible explanations.

[rasimoes]

Cool! :D

Thanks!

[georgew]

Signals over water are prone to multipath.

The multipath interference is probably going to appear as noise.

If you are having tides, then the multipath reflector is moving in a cycle that could very well cause the interference to get better or worse.

The size of the waves will also have an effect. If the water was perfectly calm and mirror like, you would probably see
a peak when the water was at a specific level, and with each rise and fall of the tides you will see it cross that level twice. Since waves are also a variable, some peaks will be at different times and different amplitudes.

On telecom links over water thay usually employ two antennas at each end of the link, and the radios automatically fail over to another antenna when multipath causes a problem. The antennas have vertical separation so that each one will have a different position relative to the reflection.

Also, horizontal polarization is supposed to work better where you have a lot of vertical reflective surfaces, so a vertical polarization will work better where you have a horizontal reflective surface.

[tim]

Thanks George, but I am still puzzled as there is almost no change in noise level. The 20 dB drops are occurring for the signal level only !!!

Also with a multipath interference pattern I'd expect to see maxima as well as minima.

The antenna is vertically polarized, so that could explain why the phenomena is so marked. I am seeing notches in some of the peaks so that confirms your comment about passing in & out of maxima.

What I suspect is that rather than a simple intereference pattern affecting noise levels, this is a more subtle affect. In certain conditions there is a catastrophic breakdown of the carrier signal, so there are no peaks and troughs, just troughs. This IMO has implications for terrestrial deployment as it suggests that under certain topological circumstances the same situation "could" arise on land (reflections from buildings). I suspect there maybe a research paper here somewhere !

Interestingly over the last 24 hours the wave action has increased and the peaks have disappeared. They were worst when the sea was mirrorlike

What I will try next is running another longer link with a vertically & a horizontally polarised signal. I cannot do much about the vertical placement but I will see if I can find some alternative sites at different vertical heights.

What I really want to do now, is sort out my ospf routing so I can policy route around the problem :D

Tim

[tim]

what area do you live in? You're not trying to link across the bermuda triangle are you? :).

It is almost the British equivalent to the Bermuda Triangle - Lyme Bay, more ships have been lost in this area than just about anywhere else, due to wreckers (putting false lights up), weather (strong SW gales), the shape of the coastline meant that the old square riggers once in the Bay could not escape, if the winds were from South West. The wreckers used to put false lights up to lure ships into the Bay, once in they were doomed. You may have heard of the book Moonfleet - that is just down the road.

And of course there is the local sea monster - Veasta :wink: it does exist, but I somehow don't think Lonnie & the team would buy this as an explanation !!!! George might though, Austin has it's bats (millions of bats), and I would imagine it quite possible that bats in your LoS could cause signal loss.


One possibility, I've been monitoring the humidity via mrtg and notice on the graph 2 peaks, one in the early morning, and one in late afternoon, appx 12 hours apart. I don't really think that would affect signal strength, since it is almost unaffected by rain, however I'll set up you're script and see if there is a connection between humidity and signal strength. Possibly it could be causing condensation on the antenna elements. I doubt it, but I don't see many other possible explanations.


The graph is currently showing flat (because it is a live URL link) and the signal was not being monitored over the weekend. So unfortunately all the peaks are gone. The wind is up now, wave heights are about 4 or 5 feet so I will predict that the peaks will not come back.

Here is the SNR being monitored from the other end :

http://southwell.wdi.co.uk/stats/radio/radio_wlan2_62.72.160.69-day.png

Previously this monitor showed a VERY similiar pattern to its partner. Now it is showing a longer flatter pattern.

I too have been wondering about weather, but I have not been running the monitors long enough to get a feel for this. There does appear to be a very small day/night rhythm of 1 or 2 dB, peaking mid-day. This seems to be more obvious when Fresnel effects are in play, ie when the LoS skims the ground. But I have seen nothing as dramatic as the peaks on this 15 mile marine link.

Humidity is not an issue here, as we get fairly constant sea breazes but fog and low clouds are. I have been running the link now for nearly a year without any noticeable problems so now I've got the monitors in I cannot wait for bad weather.

Tim

[georgew]

Oops...

Actually after I look back at the chart I see I misread it.

The peaks I saw were actually dips in signal.

Perhaps I'm wrong and the multipath is not appearing as noise, rather causing standing wave cancellation. It is a type of noise, but it is in phase so it could easily show up as a drop in signal rather than as noise.

Obviously misinterpreting the graph caused me to formulate a bad theory.... but graphs aside, shooting over water is a classic worst-case for microwaves.

I'm confident that you can probably predict the period, and it will be related to tidal level and wave conditions. You are going to need to work it into your fade margin.

If you are using a radio with two antenna jacks, you may be able to improve your signal using diversity antennas.

A proper diversity antenna set-up is a identical pair of antennas aimed in identical directions, with slightly different distances from the target, on the order of 2 to 8 inches. In your case you should be able to tune the diversity antennas during a dip so that each antenna sees the dip at slightly different times. A vertical separation of several feet should probably make the desired difference.

[dkii]

The agere antennaless short cards have diversity antenna jacks, I agree with George, that might just solve your problem.

[WISP]

OT: Your awesome, I have been running your scripts to graph SNR for about an hour and it is working great.

Wayne

[bkehoe]

I agree; thanks a lot for the scripts! :D

[tim]

The agere antennaless short cards have diversity antenna jacks, I agree with George, that might just solve your problem.

Thanks guys, I'll order the bits and do some experiments. I found the Agere World PC Card Integrated on the YDI site is that the one to use ?

Tim

[dkii]

those are the ones I like to use, if you don't specify the chipset, they'll sell ya the ruby version, so make sure you tell em which one you want.

[tony]

Just a FYI for others on the forums who are not familiar with the Hermes and Ruby chipsets you are referring too. The Ruby chipset is the successor to the Hermes which is in all the 802.11b ORiNOCO and ORiNOCO OEM (such as YDI, Avaya, etc) wireless cards. There is no operational differences, however the Ruby chipset does offer a slightly higher WEP throughput. Some prefer the Hermes (original) chipset due to it's mature nature, and the fact that you can 'cut off' the internal antenna, reducing noise. The Ruby-based cards all have an embedded SBC antenna which cannot be cut off, or bypassed when using an external connector.

Both chipsets offer the same benefits, such as long operational reliability, long rang link support and a very good WDS implementation due to the mature firmware that two cards use.

Thanks!

[tim]

This was not clear from the specs on the YDI site. So when I place the order I need to specify the Hermes chip set and when I receive the cards I will need to discoonect the internal antenna ?


Something else I want to do Tony. is to use the two antenna diversity system for rx ONLY. I am using two radio pairs. One for each direction :

Each pair will consist of a low power transmitter & two high gain receivers.


By using high gain receive antennas, I am hoping to keep my transmit power levels down in legal limits and also double the circuit bandwidth capacity by making it full duplex. For this to work (correctly) I need to be sure that the rx end does not transmit. So my questions to you Tony are, is this possible and which protocol should I use on the rx end

Tim

[tim]

I agree; thanks a lot for the scripts! :D

I'm glad you found them useful.

[georgew]

Something else I want to do Tony. is to use the two antenna diversity system for rx ONLY. I am using two radio pairs. One for each direction :

Each pair will consist of a low power transmitter & two high gain receivers.


By using high gain receive antennas, I am hoping to keep my transmit power levels down in legal limits and also double the circuit bandwidth capacity by making it full duplex. For this to work (correctly) I need to be sure that the rx end does not transmit. So my questions to you Tony are, is this possible and which protocol should I use on the rx end

Tim

Back in the "olden" days of 802.11, this was a popular tact. The wavelan cards had an external amp available that also had a pair of receive and transmit antenna jacks for the purpose of keeping transmit signals legal while pumping up the gain for receive.

But here is the problem with your plan... The receive radio has to transmit too in order for the protocol to run. Each radio needs to receive and transmit, so each radio will need a pair of antennas and a receive/transmit switch between them.

I don't know if anyone makes these any more. In the wavelan case, it was part of the amp.

If you could write your own firmware and network drivers for the cards, you might could do what you want, but lacking custom software you will need a special external circuit, and I don't know if anyone makes these any more.

[dkii]

The integrated cards from YDI do not have antennas at all, just 2 jacks to connect external antennas to. IIRC Diversity works only on recieve, so the second antenna would never be transmitting. however like georgew said, the first antenna would still need to transmit. For the s/w side, I would think you could set something like this up:

Xmit AP(192.168.1.1)------Recv Client(192.168.1.2)Local(192.168.3.0/24)

Recv AP(192.168.2.1)------Xmit Client(192.168.2.2)


Set the gateway for the 192.168.3.0 subnet as 192.168.1.2 on the Xmit AP, and set the default gateway on the xmit client to 192.168.2.1 Any traffic destined for 3.0 should take the upper link, and any return traffic should take the lower link. Again, both recieves will still need to transmit, for acks, and such, but the majority of the traffic will be full duplex. Also I've noticed AP's seem to transmit a little faster than they recieve, so you may want to keep both of the xmitters as AP's, and the receivers as clients.

[georgew]

Since the diversity antenna jack is receive only, you might try putting a high-gain antenna on the diversity port. However I'm told the two antennas should be identical... but I'm not sure why. It can't hurt to try it to see what happens. Since the diversity port does not transmit, it should be legal.

The last time I saw this discussed, an expert chimed in and shot the idea down, but he didn't say why.

[tim]

dkii - routing via different routes (as you describe) is what I had intended to do and I have been playing around with for sometime, so no problem on that front.

george - damn damn and damn, I was hoping I could get the infra side of a link to operate without EVER xmitting, turn RTS off etc. but if the protocol does not support it - it does not support it :cry:

I guess the only way to do this correctly will be to cut your own protocol using two seperate circuits. This is exactly what most of the satellite systems do with asymetric pathways and multicast transmission, so I know it can be done. Never mind, if I do it anyway (put in 2 seperate circuits), it will mean that the RTS/CTS handshake and the MAC ACK packets go down the wrong path. Given an average packet size of 1000, that means 0.1 % of the data will go down the wrong (high power transmit) path. This may not be strictly speaking legal, but it minimises spectrum use and I get my full duplex link :D So look out for my 3 element antenna config, I'm going to do this !

George - re your suggestion to use different antennas.

my understanding of diversity switching is that the two antennas have to be balanced (ie exactly the same) in order for the switch to work correctly. Otherwise there will be a bias towards one over the other. I have my own experts so I will check with them to see if this bias can be overriden with some electrickery. The other thing I thought might work was to put some delay line between the two out of phase rx antennas, so that even though the antennas were displaced by 4 to 8 inches the delay line compensates for this and effectively the two antennas then function as a single antennna, no diversity switching is necessary, and you get round the multipath problem.


Tim

[georgew]

my understanding of diversity switching is that the two antennas have to be balanced (ie exactly the same) in order for the switch to work correctly. Otherwise there will be a bias towards one over the other. I have my own experts so I will check with them to see if this bias can be overriden with some electrickery.

Since the diversity is on receive only, and if the bias is for the high-gain antenna, then that is what you want anyway. It is my understanding that the transmit side will always use the same antenna.

There are diversity designs where both receive and transmit switch between antennas, but those are usually really expensive bridge/T1 link systems, not pcmcia card radios.

You should try it, it just may work as expected, with the diversity switch bias working in your favor.

[tim]

Yes, of course you are right, I had not spotted that.

Tim