Wifibroadcast is a project aimed at the live transmission of HD video (and other) data using wifi radios. One prominent use 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 regulatories of your country allow such a use of wifi hardware.

- 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.
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)
- Wifibroadcast uses Forward Error Correction to archive a high reliability at low bandwidth requirements. It is able to repair lost or corrupted packets at the receiver.
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 many wifi chipsets. Tests have shown that the ATHEROS AR9172 delivers good performance under wifibroadcast for 2.4GHz. You can find a list of wifi cards using this chip here.
For 5GHz operation Ralink RT5572 based devices are recommended since they work out of the box. The CSL-300 (with two antenna connectors!) and TP-LINK TL-WDN3200 are based on this chips (for more cards refer to here).
The following 2.4GHz 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.
The following 5GHz cards have been successfully tested:
- CSL-300: This is the recommended 5GHz card since it provides external antenna connectors Only the model with two antenna connectors!)
- TP-LINK TL-WDN3200: Wifibroadcast works also with this card. Note, however, that due to the missing external antenna connectors the maximum distance of a video link is limited.
For a basic setup you need two Raspberry PIs, one Raspberry PI camera, a HDMI display and two compatible WIFI sticks.
For your convenience, there are prebuild images available for your Raspberry PIs. You can download them here: https://github.com/befinitiv/rpi_wifibroadcast_image_builder/releases
Put both the TX and RX images on SD cards (as explained here).
Connect the camera and one WIFI stick to your TX Raspberry PI, insert the TX SD card and power it up. After ~30s you should see the LED of the WIFI card blink (this is only true for Atheros cards). This means that you are transmitting your video!
On the RX side, connect display and WIFI stick to the RX Raspberry PI, insert the RX SD card and power it up. When the boot is finished you should see the live image of the camera on the screen.
If you want to use an already existing Raspberry PI image, you can read here how to install everything manually. You’ll find there also information on how to record the video to a thumb drive.
- My 2.4GHz RC disturbs the video transmission You could use 5GHz WIFI equipment. Or if you are brave you can modify your RC system.
- What is the recommended hardware? For the transmitter all the members of the Raspberry PI can be used including the A+. The receiver can also use all members in case of a singe RX WIFI card. If you want to use a diversity setup with bit-rates higher than 3MBPS then the USB part of the first generation of Raspberry PIs is a bottleneck. The Raspberry PI 2 however is more than capable of handling two RX WIFI receivers at high bit-rates.
- What max. range can be expected?Tests showed that you can expect more than 3km +-30° (horizontally and vertically) on 2.4GHz with a double biquad antenna. If you use dipole antennas you can reach up to 900m with a 360° (horiz) coverage
- What about interferece with other networks? The WIFI cards 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 regulatories 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 number of FEC packets.
- How do I transmit telemetry data in parallel to the video stream? Refer to this blogpost.
- 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 number of FEC packets.
