Thx to Rybat for finding this great information.
Copy pasted from this site.
Wifibroadcast – Analog-like transmission of live video data
Wifibroadcast is a project aimed at the live transmission of HD video (and other) data using wifi radios. One prominently used case, is to transmit camera images for a first person view (FPV) of remote controlled aircrafts.
In contrast to a normal wifi connection, wifibroadcast tries to mimic the advantageous properties of an analog link (like graceful signal degradation, unidirectional data flow, no association between devices).
Note: Before using wifibroadcast you have to check if the regulations of your country allow such a use of wifi hardware.
Why normal wifi is a bad choice for FPV applications
Association: Video transmitter and receiver need to be associated. If one device looses association (for example due to too weak signal strength) the video transmission stops instantly.
Error-free transmission: Wifi transmits either data that is correct or no data. In an FPV scenario this means that even if you received data with just small errors it would be rejected completely. This could result in stalling video although you have received useful data.
Two-way communication: Even if you are sending data only from source to sink, a bi-directional data flow is required using wifi. The reason for this is that a wifi receiver needs to acknowledge the received packets. If the transmitter receives no acknowledgements it will drop the association. Therefore, you would need equally strong transmitters and antennas both on the aircraft and on the ground station. A setup with a strong transmitter in the air using an omnidirectional antenna and a weak device on the ground using a high-gain antenna is not possible with normal wifi.
Rate control: Normal wifi connections switch automatically to a lower transmission rate if signal strength is too weak. Due to this, it is possible that the (automatically) selected rate is too low to transfer the video data. This way the data would queue up and introduce an unpredictable latency that can be up to several seconds.
One to one transfers: Unless you use broadcast frames or similar techniques, a normal wifi data flow is a one to one connection. A scenario where a bystander just locks onto your “channel” as in analog video transmission to watch your stream is not easy to accomplish using traditional wifi.
Limited diversity: Normal wifi limits you to the number of diversity streams that your wifi card offers.
What wifibroadcast makes different
Wifibroadcast puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association. Additionally, it is also possible to receive erroneous frames (where the checksum does not match). This way a true unidirectional connection is established which mimics the advantageous properties of an analog link. Those are:
The transmitter sends its data regardless of any associated receivers. Thus there is no risk of sudden video stall due to the loss of association
The receiver receives video as long as it is in range of the transmitter. If it gets slowly out of range the video quality degrades but does not stall. Even if frames are erroneous they will be displayed instead of being rejected.
The traditional scheme “single broadcaster – multiple receivers” works out of the box. If bystanders want to watch the video stream with their devices they just have to “switch to the right channel”
Wifibroadcast allows you to use several low cost receivers in parallel and combine their data to increase probability of correct data reception. This so-called software diversity allows you to use identical receivers to improve relieability as well as complementary receivers (think of one receiver with an omnidirectional antenna covering 360° and several directional antennas for high distance all working in parallel)
What hardware is required?
A typical setup looks like this:
GNU/Linux computer
The choice of the embedded computer is free. However, Raspberry Pi’s are highly recommended due to the low price and easy camera integration. Normal PCs running GNU/Linux are also supported. An experimental port to Android has been shown here .
Wifi card
Not all wifi cards are compatible with wifibroadcast. This is because wifibroadcast uses injection mode which not fully supported by most wifi chipsets. Tests have shown that the ATHEROS AR9172 delivers good performance under wifibroadcast. You can find a list of wifi cards using this chip here . Two of these cards have been successfully tested:
- TP-LINK TL-WN722N : This card delivers 19dBm output power and is affordable (9€).
- Alfa AWUS036NHA : This card is more expensive than the TP-LINK but it includes a 30dBm power amplifier. Using this card on the aircraft should give you a better range.
Using wifibroadcast
The following section assumes the use of Raspberry Pi’s running raspbian on both the tx and rx side.
Transmitter
As a first step you need to clone the wifibroadcast repository on your tx raspberry pi:
sudo apt-get install mercurial
hg clone https://bitbucket.org/befi/wifibroadcast
Next, you need to install a patched firmware for the wifi card that sets the data rate of the injected packets to 26mbit/s:
sudo cp wifibroadcast/patches/AR9271/firmware/htc_9271.fw /lib/firmware
Optinally, you can also patch the kernel driver to set the output power of the card to a fixed level as described here .
Now the wifibroadcast project needs to be compiled:
sudo apt-get install libpcap-dev iw
cd wifibroadcast
make
To transmit video into the air you need to put the wifi card into monitor mode and start the tx program:
sudo killall ifplugd #stop management of interface
sudo ifconfig wlan0 down
sudo iw dev wlan0 set monitor otherbss fcsfail
sudo ifconfig wlan0 up
sudo iwconfig wlan0 channel 13
raspivid -ih -t 0 -w 1280 -h 720 -fps 30 -b 4000000 -n -g 60 -pf high -o – | sudo ./tx -b 8 -r 2 wlan0
The LED of your wifi card should blink indicating that you are transmitting video data of your camera into the air.
Receiver
On the receiver side you also need wifibroadcast installed:
sudo apt-get install mercurial libpcap-dev iw
hg clone https://bitbucket.org/befi/wifibroadcast
cd wifibroadcast
make
Additionally, you need a program to decode and view the video stream:
cd $HOME
hg clone https://bitbucket.org/befi/hello_video
cp hello_video/video.c /opt/vc/src/hello_pi/hello_video
cd /opt/vc/src/hello_pi/
./rebuild.sh
Then you can go back to wifibroadcast and start the application:
cd $HOME/wifibroadcast
sudo killall ifplugd #stop management of interface
sudo ifconfig wlan0 down
sudo iw dev wlan0 set monitor otherbss fcsfail
sudo ifconfig wlan0 up
sudo iwconfig wlan0 channel 13
sudo ./rx -b 8 wlan0 | /opt/vc/src/hello_pi/hello_video/hello_video.bin
And voilà, you have finished your wifibroadcast setup 🙂
You can also watch the stream on a normal GNU/Linux PC using gstreamer:
#setup of wifi card is identical to that of the PI (see above)
sudo ./rx -b 8 wlan0 | gst-launch-1.0 -v fdsrc ! h264parse ! avdec_h264 ! xvimagesink sync=false
Starting things automatically
Coming soon
FAQ
What max. range can be expected? Tests showed that you can expect more than 3km +-30° (horizontally and vertically) with a double biquad antenna. If you use dipole antennas you can reach up to 900m with a 360° (horiz) coverage
Does it work on 5GHz? The ATHEROS AR9172 is a 2.4GHz-only chipset. However, there have been reports that the CSL 300Mbit card also works on 5GHz with wifibroadcast. Another user reported that the ALFA AWUS051NH is suitable for tx and the TP-LINK TL-WN721N for rx.
What about interferece with other networks? The ATHEROS AR9172 still obeys to the standard wifi CSMA/CA (collision avoidance). This means that using wifibroadcast will use free slots in the channel and does not disrupt other users (at least not more than someone transferring the same amount of data using normal wifi). As said above it is up to the user to check the regulations of his country.
If I have packet drops the image is disturbed too long until it recovers. Try to decrease the interval between the h264 key-frames. You can do this by using the “-g” option of raspivid.
What can I do to make reception more robust? Several options depending on the source of the problem: Switch to a less frequented channel, use software diversity, use better antennas, increase the retransmission rate.
How do I transmit telemetry data in parallel to the video stream? The wifibroadcast tools rx and txbehave just like a unix pipe over wifi. This means that the data you write into tx will be outputted by rx. For example, if you start both programs directly, you can type into the tx window and the output should appear in the rx window. Wifibroadcast also supports several data pipes in parallel. The parameter “-p” of both rx and tx defines a port that is used to address different pipes. A typical example would be: You receive telemetry data through a serial port and want to forward the data to the ground. All you need to do is: “cat /dev/ttyUSB0 | ./tx -p 1 wlan0″. This transports the serial data over port 1. To receive it and write it to a file you could use “./rx -p 1 wlan0 > /tmp/telemetry”. This simple technique can be used for every other data you need. It also works in the opposite direction (for example to control the quad via wifibroadcast).
My latency is high and seems to be increasing over time . This is usually caused by insufficient throughput at the tx side. Try to switch to a less frequented channel or lower the data rate and retransmission rate.
