Can atheros 5.8ghz work over distance of 1.5 mile?

pcatiprodotnet

I am attempting to get pfSense on wrap units plus atheros (CM9 & EMP-8602) mini-pci 5.8ghz to function over 1.4 mile distance (clear line of site & Fresnel zone) with the following antennas:
http://www.hyperlinktech.com/web/58ghz_ism_unii_panel_antenna_19dbi.php
And, the two wraps can't see each other yet on 5.8. I assume atheros 5.8 can do this distance easily?
We've checked cables and connections, so it might be the antenna?
We aimed with a customized rifle scope that rests flush with the back of most antennas, which has worked extremely well for us in the past on other runs up to 1/2 mile distance.
( Interestingly, our 2.4ghz 120deg sectors can talk to each other, if desired, with 50% ping loss ).
Yet, the 5.8ghz doesn't even show up in the "arp -a" table.
Any suggestions or tips are appreciated.
Thank you,
-Pete

KiFFuSeR

I've tested 3km 5,8Ghz link with pfsense + CM9's + 19dBi panels and worked well with about 21-23dB of RSSI and the link was balancing from 36 to 54Mbps, those panels were exchanged by 23dBi panels, and link got rock solid at 54Mbps with 30dB RSSI. Have you checked the alignment of the antennas?

lsf

Try to manually adjust the ACK timers to some overkill values, establish link and work from there. The timer values calculated by the distance tuning sh script (that is used in GUI) is not that good (it's a bit wrong actually). Also make sure you have the power settings at max, and get rid of as much of the Coax cables as you can. You might als want to try and tilt the antennas (90 deg.) to change polarisation.

pcatiprodotnet

Do the following shell commands change these values instantly?
sysctl dev.ath.1.acktimeout=48 {was 25}
sysctl dev.ath.1.ctstimeout=48 "
sysctl dev.ath.1.tpack=98 {was 63}
sysctl dev.ath.1.tpcts=98 "
(If not, I'll download the entire config xml, modify, then upload, because sometimes when I change interface values in the pfSense gui, the units lockup and report their IP as 255.255.255.255, and then require a power cycle to revive)
Thank you,
-Pete

[update] trying to change tpack and tpcts caused them both to be set to 0, and I couldn't change both of them back.

MAuVE

Before going to the ack timeout setting you must check that you have a good rf link.

From what you write I come to the conclusion that your problem resides within the rf component of the link.

50% ping loss @ 2,4GHz is way too much.

A reliable link should have less than 1% packet loss tested with packets of 1400 bytes (normal ping uses much shorter packets 32 or 64 Bytes)

For the distance you specify I would suggest a pair of parabolic dish antennas.
Something like this : http://www.hyperlinktech.com/web/51ghz_to_58ghz_dish_antenna.php

In our community network (wind.awmn.net) we use hundreds of ordinary satellite dish antennas coupled to homemade circular waveguide feeders.

After you have achieved an RSSI value of approx. 40 than you can start wondering about ack timeout settings.

My longest link, more than 4,00 km away, has an RSSI of 39 without using maximum power.

pcatiprodotnet

Thanks for all the tips and advice. Coincidentally, I ordered that 5.1-5.8 dish a few days ago, and it just arrived; that dish is huge… nearly a yard tall! I couldn't find any wind load data on their website; it must have been too insane to print.

We don't actually intend for the 2.4 sectors to communicate/ping each other, I just mentioned that because it seemed funny that they could, whereas our 5.8 directionals couldn't.

Off topic... I read somewhere that operating a wireless card with no antenna attached may damage the card? Is this true? And if so, should terminators be used?
Thank you,
-Pete

aldo

personal impression of working with freebsd on 5.8 ghz the ap mode does not work as exected client mode is very good.
we are still not 100% sure of where the issue is but i mention this based upon what you are trying with another ap all is fine
with another client on pfsense ap problem is still prevelent.

poor connection signal
tx but not rx

just two cents worth

pcatiprodotnet

It is good to hear of others experiences. Thank you, aldo. We have been using Ad-Hoc mode for both 2.4 and 5.8. Aldo, do you know if Ad-Hc mode is similarly bugged like AP mode? I guess that means 5.3 and 5.4 may also be bugged?

aldo

have no experiance with this mofde can run up some tests over the weeked for you we do lots of 5 to 15 km stuff
cpe is good for 25 km with 23 dbi antenna in 5.8 35 km in 2.4 with 21 dbi antenna.

it is a great cpe with pfsense but as an ap not the best

be sure to turn burst off with -burst this definately helps

MAuVE

@pcatiprodotnet:

Off topic… I read somewhere that operating a wireless card with no antenna attached may damage the card? Is this true? And if so, should terminators be used?

Not with the tx power wlan boards use.

The problem with unterminated antenna feeds is that the rf power gets reflected at the open end of the feedline and returns to the transmitter end where it's dissipated on the tx active element(s).

This mechanism can overload the tx output either in power dissipation rating or rf voltage due to standing waves.

By design wlan rf outputs are not hard driven (for high output efficiency) in favor of better linearity and low spurious emissions.

It is also a simplex mode transmission i.e tx is pulsed with in-between rx periods.

To wrap it up, terminating is always a nice thing to do, but if you occasionally forget doing so you will not damage your board.

lsf

The changes are instant yes.
Have any of you tried to turn on TPC ?
dev.ath.0.tpscale: 0,1,2,3,4 (size of increment that TPC will use to up/down the power, normally 1 is the best choice, atleast that is my experience)
dev.ath.0.tpc: 0,1 (0=disable 1=enable)

I have noticed that TPC sometimes seem to fix low output power.

pcatiprodotnet

Would adding this startup shell script also work just as well?

/usr/local/etc/rc.d/my_startup_script.sh
ifconfig ath1 -burst
sysctl dev.ath.1.tpc=1
sysctl dev.ath.1.tpscale=1

I would prefer not to edit system config files unless necessary.
But, if that is required, I'm not sure exactly what to type into
/etc/inc/interfaces.inc function interfaces_wireless_configure

Thanks, -Pete

sullrich

Yes, that will work just fine. You can also utilize <shellcmd>as well from config.xml.</shellcmd>

pcatiprodotnet

Here is my current 5.x interface. Are there any additional commands/flags that could improve it?
I notice odfm is off. In another thread, it was suggested to enable "ofdm on 802.11a"; what command enables this? In the GUI, when I try to turn on odfm for this 5.x 802.11a interface, the wireless card appears to stop functioning.

ifconfig -v ath1

ath1: flags=8843 <up,broadcast,running,simplex,multicast>mtu 1500
inet6 fe80::202:6ffe:fe3f:4357%ath1 prefixlen 64 scopeid 0x3
inet 10.138.1.1 netmask 0xffff0000 broadcast 10.138.255.255
ether 00:02:6f:3e:43:57
media: IEEE 802.11 Wireless Ethernet autoselect mode 11a <adhoc>status: associated
ssid test149 channel 149 (5745) bssid 02:02:6f:3f:43:57
authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF
powersavesleep 100 txpowmax 26 txpower 63 rtsthreshold 2346
mcastrate 1 fragthreshold 2346 -pureg protmode OFF -wme -burst
roaming AUTO bintval 100

sysctl dev.ath.1

dev.ath.1.%desc: Atheros 5212
dev.ath.1.%driver: ath
dev.ath.1.%location: slot=17 function=0
dev.ath.1.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x168c subdevice=0x2063 class=0x020000
dev.ath.1.%parent: pci0
dev.ath.1.smoothing_rate: 95
dev.ath.1.sample_rate: 10
dev.ath.1.countrycode: 0
dev.ath.1.regdomain: 0
dev.ath.1.slottime: 9
dev.ath.1.acktimeout: 48
dev.ath.1.ctstimeout: 48
dev.ath.1.softled: 0
dev.ath.1.ledpin: 0
dev.ath.1.ledon: 0
dev.ath.1.ledidle: 270
dev.ath.1.txantenna: 0
dev.ath.1.rxantenna: 2
dev.ath.1.diversity: 1
dev.ath.1.txintrperiod: 5
dev.ath.1.diag: 0
dev.ath.1.tpscale: 1
dev.ath.1.tpc: 1
dev.ath.1.tpack: 63
dev.ath.1.tpcts: 63
dev.ath.1.monpass: 24

wicontrol ath1

NIC serial number: [ ]
Station name: [ test-10-130-10-1.olsr ]
SSID for IBSS creation: [ test149 ]
Current netname (SSID): [ test149 ]
Desired netname (SSID): [ test149 ]
Current BSSID: [ 02:02:6f:3e:43:57 ]
Channel list: [ 0 0 1110 1111 1 0 0 0 0 2220 22 ]
IBSS channel: [ 149 ]
Current channel: [ 149 ]
Comms quality/signal/noise: [ 0 36 0 ]
Promiscuous mode: [ Off ]
Intersil-Prism2 based card: [ 1 ]
Port type (1=BSS, 3=ad-hoc): [ 0 ]
MAC address: [ 00:02:6f:3e:2d:5c ]
TX rate (selection): [ 0 ]
TX rate (actual speed): [ 36 ]
RTS/CTS handshake threshold: [ 2346 ]
Create IBSS: [ On ]
Access point density: [ 1 ]
Power Mgmt (1=on, 0=off): [ 0 ]
Max sleep time: [ 100 ]
WEP encryption: [ Off ]
TX encryption key: [ 0 ]
Encryption keys: [ ][ ][ ][ ]

Antennas are set to the pfSense default currently (auto tx + receive diversity). Also, on our linksys/openwrt units, devs suggested setting rts=250, but in pfSense trying to set rtsthreshold=250 gives "badvalue" error?
Thank you, -Pete</adhoc></up,broadcast,running,simplex,multicast>

aldo

experiance with long links is plug nearest the middle on cm9 is =2 plug to the edge is =1 so

sysctl dev.ath.0.txantenna=2
sysctl dev.ath.0.rxantenna=2

would be the inner antenna plug on cm9

=0 is for both

lsf

Pete, you settings look fine, nothing seems "wrong".
Just for testing, could you set it up as AP and client ? adhoc mode seems to perform bad compared to client/AP mode. I havent tested it much, but from what others seem to experience, adhoc is not working properly. If you can confirm this, meybe you can work a little with Sam Leffler to figure this out ? Mail some feedback to the freebsd-mobile ML perhaps ?
Only testing I have done with adhoc is olsr in lab, and units have been like 2-5meters apart, and even then performance is not what it should be. So I suspect a driver bug of some sort.

PS. you can set sysctls in sysctl.conf, as for bursting i would just hardcode that in /etc/inc/interfaces.inc or modify the source to add a checkbox for it. All the code you need already exists, just rename some parameter (like copy the intrabss code section and rename the parameter to something like "bursting". You need to do this two places, /etc/inc/interfaces.inc and /usr/local/www/interfaces_wlan.inc. Should be very easy to add this.

aldo

setting the sysctls in sysctl.conf does not hold if you change a setting in the gui of the ath interface maybe this has changed since last we tried it. but this was previous experiance.

ifconfig seems to do something to it.

will test this again today

MAuVE

When a link is not stable and constantly switches modes (say 36-48 Mbps or 48-54Mbps) it is better to lock it to the lowest stable mode instead of leaving it flactuating up and down.
The reason is that the time wasted in negotiating with the other end the higher mode counterbalances any gain from the latter.

The command is :

ifconfig ath_x_ media OFDM/_yz_Mbps (x=0,1,2,…, yz=54, 48, 36,…)

pcatiprodotnet

"ifconfig ath0 -burst" cleared up all of the known issues we had with our existing 2.4 wireless network. Amazing. Thanks aldo!! Also, batching a command such as this to run every so often reducing ping times (interface reset?).
So far, we discovered our 5.x troubles were cause by three contributing factors: poor antenna (the antenna I linked to above has not performed well for us - replaced), bad wireless card (replaced), and imperfect installation cables/attachments/securing/etc (a cable/attachment that works well on 2.4 will not necessarily be good enough for 5.x), new-to-wireless installers, etc.
I really appreciate all the help and great tips!
Thank you,
-Pete

aldo

excellent pleaased to here it i really think there is something wrong with 5.8 Ghz in freebsd in AP mode please be warned
you could waste a lot of time it should be ok with short links and in client mode