Over the last couple of months I have been working on a project that might be of interest to you: https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmiss...

Basically it is a digital transmission of video data that mimics the (advantageous) properties of an analog link. Although I use cheap WIFI dongles this is not one of the many "I took a raspberry and transmitted my video over WIFI"-projects.

The difference is that I use the cards in injection mode. This allows to send and receive arbitrary WIFI packets. What advantages does this give?

- No association: A receiver always receives data as long as he is in range

- Unidirectional data flow: Normal WIFI uses acknowledgement frames and thus requires a two-way communication channel. Using my project gives the possibility to have an asymmetrical link (->different antenna types for RX and TX)

- Error tolerant: Normal WIFI throws away erroneous frames although they could have contained usable data. My project uses every data it gets.

For FPV usage this means:

- No stalling image feeds as with the other WIFI FPV projects

- No risk of disassociation (which equals to blindness)

- Graceful degradation of camera image instead of stalling (or worse: disassociation) when you are getting out of range

The project is still beta but already usable. On the TX and RX side you can use any linux machine you like. I use on both sides Raspberrys which works just fine. I also ported the whole stack to Android. If I have bystanders I just give them my tablet for joining the FPV fun :)

Using this system I was able to archive a range of 3km without any antenna tracking stuff. At that distance there was still enough power for some more km. But my line of sight was limited to 3km...

In the end, what does it cost? Not much. You just need:

2x Raspberry A+

2x 8€ wifi dongles

1x Raspberry camera

1x Some kind of cheap display

Happy to hear your thoughts/rebuild reports :)

See you,


Views: 70433

Reply to This

Replies to This Discussion

Great work!! Really appreciate the effort! Even a 10-20 ms reduction is worth it.

True, but the preparational tasks from raspistill are excluded from my measurements. I measured the time from capture (which is after the preparational tasks) to arrival in memory.

Yes, like the others have said, that's really great work.  Really detailed analysis and fixes.  No pressure but once you've checked in you changes, I'm happy to repeat some latency tests.

My TP-Link receivers and antennas have arrived now so I hope to do another range test perhaps next weekend.

I've also been trying to reproduce Jaime Machuca's work to get a webcam working but so far the wifi transmitter seems to go offline the moment the webcam starts up.  I originally thought it was a power issue but I don't think so anymore.  Anyway, Jaime's going to get an RPI2 and see if he can figure it out.

In befinitiv's setup instructions there's an optional step to set the TX dongle's output power to 30db.  I was wondering if anyone's done that and if they could post (maybe in dropbox or whatever) the compiled binaries?  I'd just like to save the trouble of having to do that build myself.  Ideally I'd like to have a 10db and a 30db binary (10db is the legal limit here in Japan I think).

10db is the legal limit here in Japan I think

Doubtful, that would be 10mW.

I think you need a bit of work on your dB figuring.  30dB = 1W BTW.

Ah yes, txs for the correction.

I'm actually not sure if the limits in Japan.  This web page says 10mW / Mhz but the "/Mhz" part confuses me.. surely it can't mean "per Mhz" or the limit would be very high.

Hi all, I've got the link working between 2 Pi's but it's not overly practical as I have a laptop with the latest Ubuntu and I don't have a screen to use in the field with the Pi.

I've having trouble getting the streamgoing with gstreamer:

jem@jem-N51Vf:~$ sudo ./rx -b 8 wlan2 | gst-launch-1.0 -v fdsrc ! h264parse ! avdec_h264 !  xvimagesink sync=false
sudo: ./rx: command not found
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstH264Parse:h264parse0: No valid frames found before end of stream
Additional debug info:
gstbaseparse.c(1155): gst_base_parse_sink_event_default (): /GstPipeline:pipeline0/GstH264Parse:h264parse0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Any ideas? Cheers

All fixed - silly mistake! Wasn't in the wifibroadcast directory so the .rx/ command wasn't working. CD $wifibroadcast fixed it for anyone else in same boat. Test flight soon! 

Any progress on OSD??

Been getting decent results using 2 CSL's and 1 TPLink for rx and 1 Alfa for tx.  Still running on 2.4GHz for now.  I was getting a lot of break ups before in the video but I made a couple of 2.4GHz omni bi-quad antennas and things improved a lot!  Thought I'd post a video:


Great!  nice to see the video!  I've got a bunch of new antennas as well that I hope to try in the near-ish future.

Did first test flight today. Worked pretty well when very close to the ground and within 15m's or so.

The setup:

Alien H4 Pixhawk with Frsky 2.4Ghz TX/RX

Video TX WN722 w standard omni

Video RX WN722 w standard omni

Wifibroadcast setup Ch7

Resolution: 1280x720





I was getting a lot of this happening when I went further than 15m's away:

I moved the antenna so it was pointing below the quad and that improved it slightly.

What do the experts think? I'm thinking the antenna's need to be changed over to something different and do you think the TX/RX running at 2.4GHz will be adding to this. I've ordered a UHF Rx/Tx but haven't got it yet...

Thoughts/comments welcome..


You should definitely increase the intra frame frequency (-g). Try 10 or below. I found 3 to be a good value - any artifacts are quickly removed. Also, try setting the intra refresh type (-if) parameter to cyclic or both.

raspivid ... -g 3 -if both

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service