Hi

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,

befinitiv.

Views: 70034

Reply to This

Replies to This Discussion

Sorry for the confusion, it would work just fine.

I know drones are an expensive hobby......   ;) & LOL

Hey Paul

The compute module doesn't have any IO, so you'd either need to buy and fit the IO board/dev kit which is expensive and large, or design your own motherboard with the necessary IO ports.

If you can do that, awesome, let us know as we'll all be interested :)

you can get a Compute module and i/o board for £65 from RS components in UK.

Thank you all for the interest....

My coding skills are below zero that's why I was asking an opinion from the skilled coder in this tread.

I have a compute module with I/O board, and it is really not much bigger than the pi (well, exactly twice the size..)

Also as David posted seems they are on sales now, with Farnell also selling below 70£ (about 100$). (guess they are not moving...)

I do not trust myself to code/implement the 3d, I am struggling to get this befinitiv system going... 

Pritam, now it says WARNING: erroneous pipeline: no property "port" in element "fdsrc0"

Thanks anyway

that shouldn't happen. But may be you are using gst-launch-0.1. There are small difference between 0.10 and 1.0.

Here are my commands that are working flawlessly

camera side:

raspivid -t 0 -h 720 -w 1280 -fps 49 -b 2000000 -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay config-inte
rval=1 pt=96 ! udpsink host=10.10.10.34 port=9000
client side:
gst-launch-1.0 udpsrc port=9000 ! application/x-rtp,encoding-name=H264,payloa
d=96 ! rtph264depay ! h264parse ! avdec_h264 !  autovideosink sync=false
CAPS "application/x-rtp,encoding-name=H264,payloa
d=96" are required on the client side otherwise client side pipeline will only be able to detect these automatically if you start the client side pipeline before server side. If you supply the caps on client side you can stop and start client side pipeline anytime you want without restarting the server side pipeline. 

There is an answer for up to 4 of these maybe...see this:  NOT at all sure if his would "plug-in" to this application but this described as a quad multiplexer for RP:

http://www.ivmech.com/magaza/en/development-modules-c-4/ivport-rasp...

problem with these multiplexers is "you can access only one of the modules at any given time" They don't really allow access to all four at the same time. So for our case they are pretty much useless. And I expect the switching time between modules to be more than 200ms. 

FYI: I just pushed the FEC code for wifibroadcast into mainline. This improves the bandwidth requirements and/or reliability of wifibroadcast significantly. Refer to https://befinitiv.wordpress.com/2015/07/19/forward-error-correction...

awesome, great job!

I flew with my setup for the first time today. 

RPI 2B , TL-WN722 on copter (antenna pointing down) , rpi cam.

Made a hotspot on the quad with TX power at 20.

Video is streamed via RPI WEB CAM INTERFACE (MJPEG?)

I flew ~120 meter far and 50 meter high (rel) and i still had image. However the frame rate dropped significantly from ~25 to 2-3fps (clear image) using my laptop wifi as a reveiver. (note this is not via the method described in this topic) .

I also tried with the alfa nhr on the receiver side and the link strength was ~80% but the link quality in the low 20's which made the fps not go faster.

Now I have to figure out how to get this wifi broadcasting to work. And test if I see an improvement without putting a higher power transmitter on the copter.

 <5 fps is doable when doing missions / flying in loiter mode. But higher is always better ;) 

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service