Can atheros 5.8ghz work over distance of 1.5 mile?



  • 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



  • 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?



  • 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.



  • 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.



  • 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.



  • 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



  • 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



  • 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?



  • 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



  • @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.



  • 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.



  • 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



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



  • 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>



  • 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



  • 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.



  • 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



  • 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,…)



  • "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



  • 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



  • Pigtails, connectors and such are not necessarily working on 5.X even if they work great on 2.4.
    A lot of connectors have different specs. Be sure to get wires/connectors/pigtails that are made for operation up to 6ghz, or you might find yourself in all sorts of weird trouble. And if you keep testing with 2.4 antennas on the same cables you might find yourself even more lost  ???, since everything seems to perform nicely on 2.4  :-\


Locked