Skip to content

Finding the right WIFI dongle (And patching its kernel driver and firmware)

February 22, 2015

This post is a follow-up on https://befinitiv.wordpress.com/2015/01/25/true-unidirectional-wifi-broadcasting-of-video-data-for-fpv/ . Here I describe my findings on several WIFI dongles that I have tested.

In the last post I presented my raw sender and raw receiver software. This post focuses on the right hardware to use with that software.

Therefore, I tested the following WIFI adapters:

  • DLINK DWL-G122 (RALINK RT2573)
  • ALFA AWUS036H (REALTEK RTL8187)
  • ALFA AWUS036NHR (REALTEK RTL8192)
  • TP-LINK TL-WN722N (ATHEROS AR9172)
  • My tests focused on tx power and injection rate. I also briefly looked into the receiver sensivity.

    TX power

    Looking into the TX power was an interesting journey. The first thing I did was to google how others change their TX power. I guess most of you know about the wardriving kids changing their regulatory domain to BO for being able to execute “iwconfig wlan0 txpower 30” to get 30dbm. I tried that same command for lowering my tx output power and noticed no difference at all when looking at the receive strength (RSSI) on a second card. That is quite weird. There should be a noticeable difference between 1dbm and 20dbm. I started looking into the device drivers and noticed that the iwconfig command never reaches the power set function of the cards (this was true for all of the tested cards). I haven’t traced down the position where the call gets lost but I was quite stunned. Should all the 1000 “change your regdomain” websites be wrong about this? As an additional check I hardcoded different tx power values in the drivers. This did change the RSSI! To be honest, I only tested the vanilla drivers. I didn’t check if Kali uses modified drivers. But I found no hints on this.

    Let’s look in detail at the extraordinary claims of the ALFA cards (1W, 2W, …). For example the AWUS036NHR (sold as 2W) only contains a 1W amplifier. I increased the tx power in the kernel driver to 200mw and tested the card in a shielded cage (perfect use case for a micro-wave oven πŸ™‚ ). I saw already lots of package drops. I suspect that the power distribution of the card is too bad to supply this amount of power. One indication is that the supply voltage of the tx amplifier dropped from 5V to 4V during the transmission of a packet. I wouldn’t be surprised if this caused the drops. Using a tx power of 1W nearly all packages got dropped. Just a few made in through the air. I noticed the same behaviour on the AWUS036H – although not as bad as on the NHR.

    The TP-LINK TL-WN722N supports only 100mW output power on the paper. My tests showed that this claim is more or less true. The card shows reliable transmission at 100mW and the RSSI suggested that the output power is in that order of magnitude (compared to the AWUS cards RSSI). Nice!

    I did not bother to hack the Dlink cards driver since this card does not have an external antenna connector.

    Injection rate

    I was surprised to see how the injection rates differ from card to card. I was thinking that the packets are injected at maximum rate (obeying free channel). But this is not at all the case. I did not trace the cause of low injection rates because I’m not motivated to optimize a driver stack in that respect. Following is a list of injection rates of the tested cards. I injected packets with 1024 bytes payload and measured the rate. On the left you see the air data rate, on the right you see the net data throughput. Net means 100% user data.

    len: 1024 bytes
    
    REALTEK RTL8187
    ---------------
    54 mbit/s OFDM: 480p/s ~ 3.9mbit/s
    
    
    REALTEK RTL8192
    ---------------
    54 mbits/s OFDM: 80p/s ~ 0.6mbit/s
    
    
    RALINK RT2573
    -------------
    54 mbit/s OFDM: 2500p/s ~ 20.5mbit/s
    
    
    
    ATHEROS AR9172
    --------------
    11 mbit/s CCK:  830p/s ~ 6.8mbit/s
    24 mbit/s OFDM: 1750p/s ~ 14.3mbit/s
    54 mbit/s OFDM: 2700p/s ~ 22mbit/s
    
    6.5 mbits/s MCS0: 630p/s ~ 5.1mbit/s
    13 mbit/s MCS1:  1100p/s ~ 9mbit/s
    26 mbit/s MCS3: 1800p/s ~ 14.7mbit/s
    52 mbit/s MCS5: 2700p/s ~ 22.1mbit/s
    

    Again, the ALFA cards are pretty much crap. Luckily, the TP-LINK card showed excellent results. Depending on your data rate and packet loss reliability requirements (the retransmission flag of the tx program) you can use these numbers to find the right modulation scheme. Assume you have a video stream with 6mbit/s (enough for h264 HD) you can fit that easily into the MCS3 modulation, even with one retransmission.

    RX sensitivity

    The RX sensitivity of the TP-LINK was the best of all the tested cards. I have no numbers available since all the other cards are already disqualified by their injection rate. I measured it by sending packets at a known rate and looked at the reception rate. Again, the ALFA cards were the worst. The public opinion on these cards is really the opposite of my findings… quite interesting.

    The winner

    The winner of my tests is very clear: TP-LINK TK-WN722N
    It has excellent injection rates and also an acceptable tx power level. But it is not only good for transmission: It supports to deliver frames with wrong FCS to user space. These frames are for example the ones where only a single bit is flipped. Normal cards just drop these frames and there is no way to see them from user space. It is quite obvious that a few flipped bits have lesser effect on a video stream than the loss of a whole packet (8*1024 = 8192 bits). This is exactly what I described in the last post: That the link should behave as much as possible as an analogous link. The feature of this card can be enabled by this command:

    sudo iw dev wlan1 set monitor fcsfail
    

    Another advantage of this card is that its firmware is open: https://github.com/qca/open-ath9k-htc-firmware.git

    Lastly, this card is really cheap: 10€. I’m quite happy that I’ve found it.

    Dirty patch-work

    As said before, to change the tx power of the card a change of the driver is necessary. I patched the driver of the TL-WN722N in the raspberry kernel. This patch should set the power to a constant 20dbm (although I haven’t checked the unit of the tx-power value. This is still TODO). Use the following commands to apply it:

    cd /tmp
    hg clone https://bitbucket.org/befi/wifibroadcast/
    git clone https://github.com/raspberrypi/linux.git
    cd linux
    git checkout fe4a83540ec73dfc298f16f027277355470ea9a0
    git branch wifi_txpower
    git checkout wifi_txpower
    git apply ../wifibroadcast/patches/AR9271/kernel/fixed_channel_power_of_ath9k_to_20dbm.patch
    

    From here on you can just compile the necessary modules the usual way (Refer to http://www.raspberrypi.org/documentation/linux/kernel/building.md ). When the compilation is finished you need to copy the following modules to the corresponding folders under /lib/modules/`uname -r`/kernel on the raspi:

    drivers/net/wireless/ath/ath9k/ath9k.ko
    drivers/net/wireless/ath/ath9k/ath9k_hw.ko
    drivers/net/wireless/ath/ath9k/ath9k_htc.ko
    drivers/net/wireless/ath/ath9k/ath9k_common.ko
    

    Changing the tx rate was a bit more complicated. It seems as if the firmware of the card just takes rate suggestions from the kernel driver. But the actual rate is decided by the firmware. Therefore, I needed to patch that as well. You find a pre-compiled firmware that uses MCS3 (26mbit/s) as an injection rate under patches/AR9271/firmware/htc_9271.fw. Copy this file to /lib/firmware and re-insert the card to use the modified firmware. If you want to compile the firmware with a different injection rate you can take look at the patch that I supplied. The easiest way is to replace the first line in the list with a copy of the wanted injection rate. Instructions for compiling the firmware are given in the firmware repo: https://github.com/qca/open-ath9k-htc-firmware.git

    Conclusion

    The TL-WN722N is my choice for the receiving side. I’m still hesitating to buy a second one for the transmitter. Maybe I should give ALFA a second chance with the AWUS036NHA (https://wikidevi.com/wiki/ALFA_Network_AWUS036NHA ) which uses the same chip-set as the TP-Link. The advantage would be that it adds a 1W power amplifier to the output. However, if it is as bad as the other ALFA cards, I would have thrown away 25€… If you want me to test that card, feel free to donate πŸ™‚

    Advertisements

    From → Uncategorized

    60 Comments
    1. Have you looked at the SR71 a/b/g/n dongle?

      • Unfortunately I don’t have one available. If you do, maybe you could use my tx tool and report the results?

    2. Yeah, I’m awaiting a new one (my old one doesn’t have antenna anymore, which makes hacking more difficult) but I’ll give it a try

    3. Hi
      I think that in this case a directional antenna could performe better than an increase in the tx power since you will be directing the beam to the target.

      • Hi

        I guess you are right. My plan is to use a dipole in the air with 20dBm tx power. This antenna needs to be omni. However on the ground station I’ll try a double biquad. The beam characteristics of it is quite fitting for the FPV scenario. I already built one out of some copper wire and had great results. Signal strength was ~10dB better compared to a dipole antenna. I will post some range test results soon.

    4. nicegraham permalink

      when I’ve made the modules, what do I need to copy… what are the “necessary” modules?

    5. nicegraham permalink

      thanks!

    6. nicegraham permalink

      is there any reason the patch would have broken my wifi link? I’m on a pi 2 and the dongle isn’t available after following the instructions here. I see the following on boot:

      [ 3.768511] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      [ 3.781530] usb 1-1.5: Product: 802.11 n WLAN
      [ 3.791516] usb 1-1.5: Manufacturer: Ralink
      [ 3.801297] usb 1-1.5: SerialNumber: 1.0
      [ 3.841800] udevd[175]: starting version 175
      [ 4.250213] uio: disagrees about version of symbol module_layout
      [ 4.306139] uio: disagrees about version of symbol module_layout
      [ 4.332119] uio: disagrees about version of symbol module_layout
      [ 4.333165] uio: disagrees about version of symbol module_layout
      [ 4.342163] uio: disagrees about version of symbol module_layout
      [ 4.360934] uio: disagrees about version of symbol module_layout
      [ 4.389821] rfkill: disagrees about version of symbol module_layout

      • Quote Form stackoverflow: “This indicates you have compiled the module against a different version of the kernel than is running. Note that even if the running kernel and kernel source have the same numerical value (e.g. both are 2.6.31-20-server), if the two use different configuration options, you may see this error. Also check if there are multiple versions of this module on the machine and ensure you are loading the correct one.” The strange thing though is that uio should not be used in you wifi driver. Anyways, if you install the kernel and full set of modules the error should disappear. Sorry that I cant tell you anything specific without knowing the circumstances.

    7. Kendall Wells permalink

      I feel this is an awesome application. I have the need in a Search and Rescue UAV for High Power
      Command and Control with near real time hd video. I am not able to use Raspberry Pi 2 simply because it lacks the UART ports needed for these functions. I would prefer to use Ubiquiti 5ghz High Power devices. I have Ubiquity Bullet 5M. This device has ethernet and UART accessible.

      I intend to use BeagleBone Black simply because of its processing power and it has 5 UART ports.

      UART requirements:

      UART #1 = Mavlink Data to Mission Planner (bi-directional) to Pixhawk Telemetry 1
      UART #2 = USB/RS232 Joystick to Pixhawk Telemetry 2
      UART #3 = Ubiquiti Bullet 600mw 5Ghz bi-directional Wifi Link for command, control and video stream
      UART #4 = Camera Control link

      Is it possible to provide a build for this Scenario

      I am using Debian or Ubuntu on a PC to receive, maybe Android for portable reception later

      I noticed the Bullet 5m is compatible with ath5 Linux driver and supports Monitor Mode and Radiotap.

      I simply do not have the skills to build this… Hell I can barely connect it all : P

      Thanks

      Kendall
      officerkwells@gmail.com

    8. Kendall Wells permalink

      Befinitiv, can I temp you with hardware and US currency?

      • Hi Kendall

        Thank you for the offer but I prefer doing open source things for free πŸ™‚ To me it’s just a hobby and with money it would stop being a hobby. Sorry πŸ˜‰

    9. Kendall Wells permalink

      No problem thought I would offer. Any possibility to support the BBB and ubiquiti bullet M5?

    10. Hi befinitiv,

      did you try this method to increase the power of the WN722n yet?
      https://beatusdeep.wordpress.com/2014/03/13/tp-link-wn722n-tx-power-boost/

      Thanks

      • Hi Schalonsus

        I know that this approach has been around for a long time but apparently most people did not check if this has any real effect. They assume that if iwconfig states 30dBm then this would be actually used. But this is not true. A simple way to prove this is to take a look at the datasheet of the 722N chipset: http://www.cqham.ru/forum/attachment.php?attachmentid=155133&d=1383397504 . On page 143 you find that the maximum output power of that chip is 19dBm. Another approach to prove that such advices are wrong would be to use a second card and watch the RSSI of the packets. If there is no noticeable difference between 20dBm and 30dBm then you know for sure that the method doesn’t work.

        It’s always a good idea to prove things by yourself and not to trust blindly, even in a much broader scope than just technical details πŸ™‚

    11. I do not know a lot about all these but the raeding was very informative

      just a question,

      what happen if I buy a 2w signal boost amplifier like this one

      http://www.amazon.com/Wireless-Broadband-Amplifier-Extender-Repeater/dp/B00HJ1NQLS/ref=pd_sim_147_5?ie=UTF8&refRID=1EN72PH3GPM19SHK5FW8&dpID=414ihMPF-7L&dpSrc=sims&preST=_AC_UL160_SR160%2C160_

    12. There is Atheros chipset AR7010 which supports MIMO and which is coupled with either AR9280 (dual band abgn) or AR9287 (2.4GHz band bgn). https://wikidevi.com/wiki/Atheros_AR7010. According to this, http://rmdavidson.blogspot.cz/2013/10/patch-reject-corrupt-packets-while-in.html
      it supports receiving corrupt packets in monitor mode and the MIMO should in my opinion allow much better RX compared to AR9172 (TL-WN722N) as it should be actually better than just simple diversity (it should be able to take data from both antennas and combine it together), although I am not sure this would work for non-MIMO TX as well. However, it may be difficult to get USB stick with this chipset as for example, TL-WN822N uses 3 different chipsets in differetn versions: https://www.raymond.cc/blog/best-compatible-usb-wireless-adapter-for-backtrack-5-and-aircrack-ng/
      I would be great if somebody could try it at least as RX and compare to TL-WN722N.

    13. According to this page (http://yo3iiu.ro/blog/?p=1301) it is possible to increase output power of the WN722N to 30dBm and it seems to have some real effect. It may require additional cooling, which should be ok on my FPV250 class quadcopter πŸ™‚

    14. Samuel permalink

      Hi,

      can you please tell me how you measured the injection rate? I have found a 5.8Ghz WIFI Stick that looks quite good and i want to compare it to your measurements. Do you have a script that you run?

      Cheers

      Sam

      • Hi Sam

        You can use wifibroadcast to do so:

        cat /dev/zero | sudo ./tx wlan0

        It prints the raw interface packet rate onto the console.

        • Samuel permalink

          Without modifying any wlan0 settings i get an interface rate of 800, Does that mean it is 800p/s and thus a quite good number?

        • It depends on the packet length. If you use 1024bytes that would mean 6.5Mbis/s (800*1024*8). That is a bit on the low side. Assuming 4Mbit/s with 8/4 coding you would be already at 6Mbit/s. And it is always good to have a safety margin so that the transmission is able to catch up after it got blocked for some reason.

        • Samuel permalink

          Ah, i just noticed i did something wrong, i had a look at the interface rate when using with raspivid… Later test with yes instead of /dev/zero had a rate of around 4000. See reply at the bottom.

    15. Samuel permalink

      To me it looks like the interface rate is dependent on the stuff you send. When i just do yes | ./tx … i get values up to 4000. I think yes produces more data then raspivid i think. So that value should be quite good then.

      BTW its the CSL 300 which is internally named MT-WN813N-D.

    16. jholster permalink

      I did my first tests using AWUS036NHA. Do you think it’s normal that I only see 2-3 dBm boost on receiver side when setting txpower to 30 dBm (vs. default 20 dBm). I modded regdom to allow 30 dBm and measure RSSI using the wifibroadcast_status_output branch. Results are consistent over reboots (RSSI -10..-11 dBm for txpower 20 dBm, RSSI -7…-9 dBm for txpower 30 dBm).

      I would expect a boost of ~9 dBm because the power amplifier chip in AWUS036NHA is rated for 29 dBm (for 802.11n). The max 3 dBm boost I saw translates to merely 200 mW of transmitting power.

      • jholster permalink

        Just FYI, although AWUS036NHA is supposed to have good Linux support, including open firmware, the ath9k_htc driver is missing some features found on other drivers, e.g. it *does not* let you set bitrate or (lower) txpower using iw/iwconfig, unlike e.g. rt2800usb driver (for RT5572 / CLS 300 mbit).

        I would love to be able to decrease bitrate on-the-fly when flying further away, because receicing sensitivity of wifi chip is directly dependent on the bitrate used (by several dBm). Using 1 mbps bitrate would maximize range and you can still send mavlink data and even lowres live video over 1 mbps link (~500 kB/s net payload).

        • jholster permalink

          Sorry for miscalculation, 1 mbps bitrate is more like 70 kB/s payload (including FEC), but still enough for lowres h264 if you send mostly i frames.

        • Yes, it is true that the power and rate cannot be set easily. That’s why I have patched the kernel and firmware. Letting TX power stay at max should not be an issue. Also, seeing that with 26mbit/s people were able to fly more that 3km without antenna tracking stuff shows that there isn’t really the need for dynamic switching of the rate. I think the 3km is plenty for the average user. And if one really needs to go further I think it is ok to change the rate before starting your flight. Sure, dynamic changing the rate would be cool, but the work required vs. necessity ratio is too high IMO. But that’s the beauty of free software: If you really need that feature, nothing holds you back to implement it πŸ™‚

        • jholster permalink

          Automatic bitrate would be cool indeed. I’m thinking of a manual system where the ground operator sends a command (e.g. custom mavlink message) causing the air unit to reconfigure nic and restart tx. I already found a fork of ath9k_htc with bitrate change support. In theory the system could automatically switch lower/higher bitrate based on RSSI. But yeah, sounds too complicated / error-prone. This is of course out of scope for wifibroadcast project itself, I wasn’t expecting you to implement this πŸ™‚

      • Yes, I noticed the same thing, hence my kernel patch. Try to play around with the value in the patch, this made a huge difference for me.

        • jholster permalink

          I applied your patch using max_power = 30 but the result was exactly same as with regdom hack[1], max. 2 dBm boost on receiving side (compared to max_power = 20). This is not a surprise given that your patch effectively does the same thing, i.e. disables regulation domain power limit.

          I even tried to increase max_power = 35 and comment out MAX_RATE_POWER limit but it didn’t make further difference. It seems that there’s a hard limit somewhere. Maybe the alfa design is crappy and gives no more than 22 dBm real output.

          I’ve set max_usb_current=1 in boot/config.txt and I’m using 2.4A iPad charger so power shouldn’t be an issue.

          [1] my alfa card thinks it’s on GB regdom, so I patched crda for 30 dBm.

        • jholster permalink

          One possibility is that our cards have different factory-set hard limits. I ordered my card from European seller. The card looks authentic but of course I cannot verify it. But I doubt there are any factory-set limits because it’s cheaper to rely on software limits.

    17. Tom. permalink

      Hi, I need some help with this driver patch to increase tx power in my alfa awus036nha. I have modified power value in patch and followed all commands, and compiled referring to documentation. Here’s what I did:
      (inside /tmp/linux)
      KERNEL=kernel7
      make bcm2709_defconfig
      make -j4 zImage modules dtbs
      sudo make modules_install

      but in directory /tmp/linux/drivers/net/wireless/ath/ath9k/ I don’t see any *.ko files, only bunch of *.h and *.c files.

      Compilation took over 1 hour.

      Sorry for beeing such noob, I have never been doing such things, and I’m confused. And btw, why we are using command:
      git checkout fe4a83540ec73dfc298f16f027277355470ea9a0
      Are we switching to some previous kernel version? My kernel is 4.1.13-v7+
      Thanks for help.

      • Hi Tom

        Could you please do a “find . -name “*.ko” ” in your kernel tree and report the findings back here? Since you ran make modules, there should be .ko files.

        Maybe the automatic image build tool might help you: https://bitbucket.org/befi/rpi_wifibroadcast_image_builder

        This creates you with a single command (./build_images.sh ) a ready-to-use image that you can copy onto your SD card. It also includes the power patches that you could edit before starting the build.

        The specific revision on the checkout was just to make sure that the patch “fits” to the kernel. Future kernels might change here and there so that the patch tool cannot do its work anymore.

        • Tom permalink

          Thanks for reply befinitiv.
          I forgot to:
          Add missing dependencies:

          $ sudo apt-get install bc

          I think that was the cause. I recompiled again, and now I have all the *.ko files needed. I replaced files in /lib/modules/4.1.13-v7+/kernel/drivers/net/wireless/ath/ath9k. But I have another problem, wifi adapter doesn’t work at all. I cannot see it in “ifconfig”. But i can see that it’s attatched correctly via USB

          pi@raspberrypi:~ $ lsusb
          Bus 001 Device 007: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
          Bus 001 Device 005: ID 046d:c31c Logitech, Inc. Keyboard K120 for Business
          Bus 001 Device 004: ID 09da:9090 A4 Tech Co., Ltd XL-750BK Laser Mouse
          Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
          Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
          Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

          pi@raspberrypi:~ $ dmesg

          bla bla bla

          [ 168.379235] usb 1-1.4: USB disconnect, device number 6
          [ 174.503867] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
          [ 174.625047] usb 1-1.4: New USB device found, idVendor=0cf3, idProduct=9271
          [ 174.625075] usb 1-1.4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
          [ 174.625092] usb 1-1.4: Product: UB91C
          [ 174.625109] usb 1-1.4: Manufacturer: ATHEROS
          [ 174.625125] usb 1-1.4: SerialNumber: 12345
          [ 174.651643] ath9k_hw: disagrees about version of symbol module_layout

        • Ronin permalink

          My hardware is a rpi A+ w Alfa NHA (ath9k driver)
          I used the automatic image build tool recommended above– changed the 20 to 30 in the ‘fixed_channel_power…patch’ file and compiled image. I was still at 20dbm according to iwconfig.
          I checked region and it was still GB, so changed it to BO in ‘tx.sh’, still 20dbm. I looked at regional limits with ‘iw reg get’ and BO showed entire 2.4ghz band limited at 20dbm (!?). US can go to 30. Changed region to US, and it wont transmit (confirmed w receiver) If I change it back to BO or GB it will TX fine.

          So: did I build image wrong? do I have to move, copy or do something w the patch file before build?
          do I have to do something else w the region settings? (how do you change default in the rpi?)

          or

          Someone please share a working pi image w 30dbm tx!

        • Hi Ronin

          The patches I wrote update the power on a very low level. You will not see its effect using iwconfig power reports. You could however easily verify their effect by monitoring the receive power on a second card.

    18. seitam permalink

      I am wondering if the capability of giving wrong FCS to the userspace is working in the ALFA NHA adapter (so far I have not been able to see any packet with corrupt CRC). In that case the FEC code implemented in software is certainly meaningless and could be removed or substituted by the former repetition code that is less CPU hungry.
      Has somebody check if the Alfa NHA is passing wrong CRC packets to the userspace?

      • seitam permalink

        I have to retract myself, a bad configuration was not letting me see the corrupted packets. Nonetheless, the idea to disable FEC for adapters that do not support the fcsfail flag and to use come basic channel coding as the repetition code to save CPU still apply.

        • To clarify: the FEC works on WIFI packets. Let’s assume you have a block size of 8 and 4 FEC packets. This means that each FEC packet is able to “repair” one of the 8 data packets that is either lost or corrupted. The fcsfail makes things only better if you have used up all FEC packets. If in that case there is still a damaged data packet left then you are not able to repair it. And a damaged packet should be better than no packet.

          In summary: Having the fcsfail option only brings a small advantage. And this is independent of using FEC or not.

          Hope this explanation was more or less understandable πŸ™‚

    19. seitam permalink

      My bad! I directly related FEC with algorithms that work on “bit/byte” basis as Hamming Codes, Reed-Solomon, TurboCodes or LDPCs.

      After looking at the Wifibroadcast code I have seen that it uses an Erasure-oriented FEC. As you have commented, if after having applied the FEC there is still some corrupted packet (that have not been able to be reconstructed by the FEC algorithm) you face the following dilemma: “remove the packet or use it”. Probably most of the packet info will be OK, so you use it. What if you could really repair this packet (besides the FEC has failed)?

      There is room for improvement! After the information has passed through the first Erasure-oriented FEC (using Vandermonde matrices) it would be possible to apply another FEC to each packet, that case the FEC algorithm would be per byte basis algorithm (like Reed-Solomon).

      This way, if a bit flipping occurs during the transmission of any packet, we would still have the opportunity to recover it, and thus, the erasure-oriented FEC will have more opportunities to recover the whole block intact.

      • Hi seitam

        Yes, you are right. Using a bit-based FEC might improve things a bit. I found that if you are at the end of the range, the bit-errors seem to quite often appear outside of the data (like preamble, headers, …). This means that these packets will never be delivered to wifibroadcast and thus cannot be repaired. Since this effect seemed to start earlier than seeing packets with wrong FECs I suspect that the advantage of a bit-based FEC would be not too good to justify the trouble. But if you are motivated: Feel free to hack around πŸ™‚

        • seitam permalink

          Another point that I didn’t mention is that error-correcting FEC codes such as Reed-Solomon are more CPU intensive than erasure FEC codes as far as I have read. I don’t know if a Raspy would support this double coding…

          I have a question: You say that at the end of the range errors appear in the preamble/header fields and for that reason they will never go through the libpcap interface (arriving then to wifibroadcast). Is that because internally (in hardware) the wireless adapter rejects them? or because of the libpcap filter applied, which is not able to find the correct fields on the IEEE header?

          Probably is the first answer… In case it is because of the libpcap filter, it would be possible to reconstruct the IEEE header, as it is repeated for every packet without changing any byte (only the CRC which is added by the adapter).

          From my point of view this project is quite mature right now, congratulations for your work it is really awesome!

          In my opinion, there is just one thing left that could really boost the performance in long range conditions, and that is to use lower bit rates (MCS0 for n /5.5/2/1 Mbps for b/g). The differences in receive sensitivity may be more than 15dB with comparing a MSCX to the former data rates.

          The use of RaptorQ codes in replacement of the Vandermonde FEC would also be beneficial for wifibroadcast.

          Thanks for your work and make it public!

        • Hi seitam

          Yes, for long range MCS0 would be better. However, this is not sufficient anymore for HD. So if we are getting close to the quality of analog transmission then analog might be the better choice. However, if you take a look here: https://bitbucket.org/befi/wifibroadcast/src/62d3d35a2374d2b02d0c77a5b6988f2e96fd5913/patches/AR9271/firmware/?at=default you’ll find precompiled firmware for MCS1. This is just enough for getting HD with some redundancy.

    20. seitam permalink

      I self-answer my question: Yes, it is possible to inject whatever you want on the pcap interface, the wireless adapter accepts it and injects it. (I though that probably some IEEE format was mandatory but it seems that is not the case).

      This way a minor improvement can be done to Wifibroadcast: Remove the unnecessary IEEE header. It consumes 28 Bytes of data per packet that is absolutely redundant. Only a “key” address (like the 13:22:33:44:55:66 used now) should be used along the port number.

      That would reduce the overhead of the header to almost 1/5 of the original value. The problem that I am struggling is how to define the proper BPF. These packet filters are really efficient, and there is a reason for that: usually when filtering only a small set of the total packets are used and for this reason, a bad performance when filtering compromises the entire software. I am not sure if a bit mask applied at the correct place would be fast enough. How would you do it?

      If we have errors in the preamble, we can do nothing, the wireless adapter will not be able to detect the incoming packet properly. However, in case of using any 802.11b modes short preambles could be used to reduce the size to a half!

      I say all that stuff having in mind that it would really help on reducing the errors on the preamble/IEEE header. This way the aforementioned idea of applying bit error correcting FEC codes would have more sense (as they will protect a great portion of the packet) and that could consequently extend the range of operation.

      Thanks.

      • Mh, the idea of ignoring the headers and filter completely is interesting. You are right, if we are in a noise-free environment, then you could as well do the filtering inside of wifibroadcast. This might indeed (together with the correct FEC as you mentioned) improve the quality a bit. I am already quite happy with the current quality. Some crazy people out there flew already 5km with this setup and I have also read somewhere that 7km works with just omni antennas on RX and TX. Some people out there are crazy πŸ™‚
        So before improving the last bit of transmission I would rather put my energy into the capture and encoding part to reduce latency and improve quality. The raspicam is already quite ok but still a bit laggy. My motivation is still to “kill” analog FPV. And latency is the last requirement towards that goal.
        So far my search has not turned up anything that would be better than the Raspi. There are some very low latency FPGA encoder IP cores but they cost $$$ and require a rather big FPGA. Pretty sad. Low latency capturing of image data from a sensor is extremely easy to do on an FPGA. If only the compression would not be such a pain in the ass πŸ™‚

        • seitam permalink

          I see your point of view. I do not have the equipment (drone/raspis/camcorder) and I just took a look a the code in order to try to improve it. For that reason I didn’t noticed that the latency was the main problem to solve. This project really poses the hardware and software to the limit, low cost, low weight, low CPU power but high performance!

          Keep pushing!

          Kind regards.

        • Wow, you gained quite an insight without having the hardware! Might I ask about your motivation? Do you see another interesting application of wifibroadcast.
          Anyways, thank you very much for your valuable ideas!

    21. seitam permalink

      Hi befinitiv,

      I was studying the viability of removing the 802.11 Layer 2 for applying the Wifi technology for long-range links (for avoiding RTS/CTS/ACKs timeouts). I though that it was doable by means of using wireless adapters in injection/monitor mode. Then I came across your project and I was amazed that somebody just already implement it! (If you check your mail probably you will see a long e-mail that I send you like 20 days ago with a more detailed explanation and a lot a bullshit too, sorry 😦 ).

      So basically, wifibroadcast was one of the few examples on receiving and sending packets in a raw manner. Other projects like Lorcon, or the one you used as base (packetspammer) where also interesting pieces of software.

      Wifibroadcast joins some very unique features that can be of high interested when developing some applications:

      1 – It is applicable to a large quantity of , they need to support monitor and injection mode: It is true that for having high throughput in injection mode you had to modify the firmware and that is something that can be done in some specific chipsets. Anyway, the legacy bitrate of 1Mbps could be more than enough for a myriad of applications.

      2 – The transceivers (wireless adapters) are truly cheap-ass compared with the range and performance they have (due to economies of scale).

      3 – One to many communications with no control messages (unreliable)! That is a really nice feature. Wifi links working on Ad-Hoc mode need a certain control flow in order to work, what if you just one to suppress that control?

      About some new applications… The most that come to my mind would be related with the deployment of motes/sensors at long distances. Also for surveillance. An amateur broadcast radio channel at 2.4GHz would be possible too πŸ™‚

    22. seitam permalink

      Hi befinitiv,

      You reported some packet drops when increasing the TX power to 200mW or superior values on the ALFA AWUS036NHR and AWUS036H. Have you ever tried to apply the same changes to the ALFA NHA? Does it react the same way?

      Thanks.

      • Hi Seitam

        Sorry, I have not done any detailed tests on this card regarding TX power.

        • What a pitty! The NHA seems to be superior in sensitivity than other ALFA flavours (NHR/H/etc) but the counterpart is the lack of high TX power (that is limited to 20dBm by default with the register set to GB).

          After having inspected the NHA it features a SE2576L power amplifier (Datasheet: http://www.skyworksinc.com/uploads/documents/202428A.pdf) which has a max output of 29dBm in 802.11b or 26dBm in order modes. That figures surpasses the 20dBm limitation by far. And being able to bypass them will make this card really attractive and suitable to use.

          As you pointed out, the Internet is flooded by numerous sites that claim different ways to increase the TX power. As far as I have seen, non of them seems convincing up to now.

          Do you thing that there is some possibility to increase the TX power with a driver patch? Or I better surrender?

          Thanks!

    23. “You find a pre-compiled firmware that uses MCS3 (26mbit/s) as an injection rate under patches/AR9271/firmware/htc_9271.fw. ”

      I don’t see the patch anymore in the github for the atheros firmware. or am i looking for it in the wrong place?

    24. joe permalink

      Hey great article i want to ask how to do this in openwrt im using TL-WN722N with tplinklogin tl-mr3020 help would be much appreciated thanks

    25. Sani permalink

      hey ,
      I am quite interested in your project i made an attempt to try your solution , but i didn’t find the commit you mentioned above

      <> i found this commit in completely different repositories not related with linux

      is it a must to use exactly this commit ? or i can change it ?
      Thanks

      • Sani permalink

        git checkout fe4a83540ec73dfc298f16f027277355470ea9a0

    Trackbacks & Pingbacks

    1. Improved retransmission scheme and multiplexing | befinitiv
    2. FPV range and latency test in a noisy environment | befinitiv

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: