Finding the right WIFI dongle (And patching its kernel driver and firmware)
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:
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 🙂
Trackbacks & Pingbacks
- Improved retransmission scheme and multiplexing | befinitiv
- FPV range and latency test in a noisy environment | befinitiv
- Drone.mistakes – Aperture Systems
- Can’t control connection bit rate using iwconfig with Atheros TL-WN821N (AR7010) – jihhuj
- Can’t control connection bit rate using iwconfig with Atheros TL-WN821N (AR7010) – Website Information
befinitiv 
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?
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
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.
when I’ve made the modules, what do I need to copy… what are the “necessary” modules?
Good point. I’ve update the description and named those modules. Thanks!
thanks!
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.
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
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 😉
No problem thought I would offer. Any possibility to support the BBB and ubiquiti bullet M5?
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 🙂
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
I tried using that wifi amplifier. I saw NO increase in signal strength AT ALL! I have also tried using the Alfa AWUS036NH wifi adapter. I estimate that its maximum txpower is around 17 dB–nowhere near the 33 dB that Alfa claims. I’m starting to think that perhaps some US governmental agency is secretly forcing manufacturers to limit the power of all wifi adapters to much lower than the legal limit. What else explains the apparent fact that you can no longer buy a powerful wifi adapter or a working wifi amplifier?
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.
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 🙂
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.
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.
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.
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.
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.
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).
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 🙂
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.
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.
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.
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.
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
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.
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?
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 🙂
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 🙂
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.
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 🙂
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!
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 🙂
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!
“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?
Please take a look here: https://bitbucket.org/befi/wifibroadcast/src/62d3d35a2374d2b02d0c77a5b6988f2e96fd5913/patches/AR9271/firmware/?at=default
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
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
git checkout fe4a83540ec73dfc298f16f027277355470ea9a0
Hi befinitiv,
great job! Don’t you know if anybody try 802.11ac chips like RTL8811AU for wifibroadcast? At the first sight features like Beamforming can improve range. Is monitoring mode only condition for running wifibroadcast? Thank you 🙂
Hi befinitiv,
sorry for asking beginner questions, but I’m a beginner. I have here 2 RPI 3 b, 2x16GB SD, a Logitech USB cam and two TL-WN722N. I first tried your wiki recommendation
and flashed
https://github.com/befinitiv/rpi_wifibroadcast_image_builder/releases/tag/v0.4. The unpacked ZIP had a little strange structure, so I finally just took the image and flashed it with Etcher. In fact it unpacked to something like this: home/waltraut/repos/rpi_wifibroadcast_image_builder/data/2015-09-24-raspbian-jessie_2015-12-31.img. Took the image
In result both RPI show colors, which I think was sort of kernel panic. At least it didn’t start.
Then I downloaded WifiBroadcast 1.5, which just unpacked to one image file. And now on both machines a running PI. Hurray.
On the TX machine it says: No wifi cards detected, shortly followed by wifi0 IEEE 802.11bgn ESSID: off/any
On the RX machine it says: No camera detected, shortly followed by the type of the Logitech cam printed.
But more is not working for now. What did I oversee?
Kind regards
Hi befinitiv
whether every wifi hardware surport fix bit rate ,I want to midify the athores ar1021 to fix MCS3 rate , but i dont kown how to modify .can you tell me ,think you
HI. Is there any complete tutorial how to patch the driver of ath ar9271 to work in 2.3ghz with rspberry pi 4?