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 :)
I tried your images, but i get really short range, anything i could be doing wrong there?
Had some fun in the park today. Camera wobble gone. The lense I'm using doesn't do justice to the cause though and creates an unwanted blur. Overall, I was very pleased with how well things improved with CP antennas. Antennas are everything!
Can someone confirm if you are able to run mavlink telemetry through the raspberry pi while also sending the HD video using this method. http://dev.ardupilot.com/wiki/companion-computers/raspberry-pi-via-...
Should be simple if you follow the latest post from Befinitiv: https://befinitiv.wordpress.com/2015/07/06/telemetry-osd-for-wifibr...
I think it'll work using that method of splitting the pipe into two so video can go down one, telemetry the other (in malkauns's links above). One thing is the pipe is one-way only so the ground station won't be able to send commands to the flight controller and this may upset the mission planner (I'm not sure). As a minimum I think you'll need to set the flight controller's SRX_xxx parameters (i.e. SR0_, SR1_) to "1" (hz) so that it sends out telemetry data proactively (normally Copter waits for the ground station to request a datastream).
Thanks for the replies Malkauns and Randy.
Its a shame that it doesn't do 2 way comms but I understand that it isn't what this project is about.
Two way communication also wouldn't be very good, because it would cause collisions (=video dropouts) when the ground-station sends something at the same moment with the air-station. In this regard wifi works similarly to the "plain old ethernet without switches" (with coax cables or hubs).
But I think it should be possible to set up two wifibroadcasts with two wifi cards on different wifi channels, one that sends stuff from the air-station to the ground-station and one that sends stuff from the ground-station to the air-station.
If one would want to use only one wificard/channel for bi-directional communication, one would have to implement some kind of time division multiplexing, but that's far from being trivial.
Hey befinitiv, I have seen you have started implementing FEC from udpcast. Thanks, thanks, thanks.
Now I feel bad, because I haven't had time to dig into the buildroot stuff further. But I will do that sometime :)
But I have looked into the other options in the meantime, namely this one I wrote about earlier:
"– Make some kind of virtual wrapper-interface using tun/tap or something. So that udpcast speaks to the wrapper-interface that behaves like a normal network interface. The wrapper-interface will then speak to the atheros monitor-mode interface. Also not sure if possible at all and how much effort."
I'd say it is actually possible and probably the cleaner solution because this way, we can use any normal network application we'd like to use and don't need to touch wifibroadcast for new functionality. Drawback would be of course, that it's harder to control buffers and latency because there is more stuff in the chain.
And I had another idea regarding the TX side. One could use two wifi cards on two different channels for the TX side to increasy bandwidth and resiliency against noise/interference and other wifi networks. If the FEC/interleaving occurs before sending out the packets on the physical interfaces, that would mean we have an interleaved and FECed data stream running over two different frequencies. I'd say the probability of both links having heavy interference (that the FEC/interleaving can't deal with) at the same should be around zero, giving a very very stable link even in the worst conditions.
I have attached a diagram of how it could work. The tun0 interface would be a "normal" (i.e. non monitor mode) interface with an IP configured.
Here is a tutorial about tun/tap programming in C:
Perhaps separate processes are a good idea (especially to make use of multiple cores, although I think low latency has the highest priority here) but I don't see much advantage of using a network interface as the IPC mechanism here. Concpetually something simple like a socket or a pipe matches better.
I've tried the two wifi cards idea and it definitely works!
It can do two-way comms although the throughput will obviously be less than optimal. You can run tx and rx on both ends. Worked for me.