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: 70263

Reply to This

Replies to This Discussion

I think it's the alfa dongle that's the important bit - the tx side needs to be powerful and there don't seem to be many (any) alternatives for 5.8ghz.  The rx adaptors can probably be anything that supports monitor mode and the right frequencies.  The CSL adaptors are cheap and cheerful - I guess they're probably rebranded cheap shenzhen units - but oddly the usb connector is quite slippery and slides out of the laptop easily.  They're not very powerful even at 30dbm and don't run reliably at this level anyway, they keep resetting.  Given a choice I'd take a better made dongle with a single rp-sma.  On the rx side the most important bit is the antennas.  I sure hope amazon will return some of the many boxes of dongles, adaptors and antennas I've accumulated in the past week :)

Just a few more details about the setup.  Note that this combination of dongles works out of the box with any of the raspberry OS images and should work with any of the model a/b/2 hardware.  No kernel or firmware hacks are necessary.  Just use this script on the tx side (I simply call it from /etc/rc.local, possibly a more elegant init script could be devised)

!/bin/sh
/sbin/ifconfig wlan0 down
/sbin/iw dev wlan0 set monitor otherbss fcsfail
/sbin/ifconfig wlan0 up
/sbin/iw reg set BO
/sbin/iwconfig wlan0 rate 18M fixed
/sbin/iwconfig wlan0 txpower 30 fixed
/sbin/iw dev wlan0 set txpower fixed 30mBm
/sbin/iwconfig wlan0 channel 149

/usr/bin/raspivid -ih -t 0 -w 1296 -h 730 -fps 30 -b 2000000 -n -g 30 -pf high -o - | /usr/local/bin/tx -b 8 -r 2 wlan0 >/var/log/raspitx.log 2>&1

On the rx side, I use this script:

#!/bin/sh

/usr/bin/sudo /sbin/ifconfig wlan0 down
/usr/bin/sudo /sbin/iw dev wlan0 set monitor otherbss fcsfail
/usr/bin/sudo /sbin/ifconfig wlan0 up
/usr/bin/sudo /sbin/iw reg set BO
/usr/bin/sudo /sbin/iwconfig wlan0 rate 18M fixed
/usr/bin/sudo /sbin/iwconfig wlan0 channel 149

/usr/bin/sudo /sbin/ifconfig wlan1 down
/usr/bin/sudo /sbin/iw dev wlan1 set monitor otherbss fcsfail
/usr/bin/sudo /sbin/ifconfig wlan1 up
/usr/bin/sudo /sbin/iw reg set BO
/usr/bin/sudo /sbin/iwconfig wlan1 rate 18M fixed
/usr/bin/sudo /sbin/iwconfig wlan1 channel 149

/usr/bin/sudo /usr/local/bin/rx -b 8 wlan0 wlan1 | gst-launch-1.0 -v fdsrc ! h264parse ! avdec_h264 ! autovideosink sync=false

These values were quite randomly chosen and I haven't done much tuning/experimentation yet.  The rate is set to 18M before I got the alfa dongle because I was trying somehow to increase the range of just using the CSL adaptors, and receiver sensitivity is heavily dependent on rate - the slower the rate, the greater the range.  The raspberry is running in a binned full sensor mode but only using 30fps, it should run up to 49fps which will decrease latency.  I've decreased the bit compression stream rate (2mb) to fit into the decreased wifi rate.  Decreasing key frame frequency, blocks and retransmits will no doubt help latency at the expense of reliability.

Indeed. I would ditch all my 5.8 analog tomorrow if I could only plug on my AP cameras.

Can somebody comment on Awus052NH chipset Ralink RT3572 ?

MIMO 2T2R, up to 30 dBm or 1000 mW

Thank you in advance.

If latency is a big factor one should consider dropping to lower resolutions and higher framerates. I haven't yet jumped to wifi broadcast. But I have had very good results with 640x320 90fps. Unfortunately the project says 90fps is highest the sensor can do and its cropped not full sensor areas is used. This considerably reduces the latency on the player side. Its imperceptible now. If its too much data, one may also consider dropping down on bitrate to have better range and smoother video. 320p anyway is very close to what we currently fly with analog transmitters

Ah, one more thought...Mobius speaks h.264 on webcam mode. Might there is a shorter way to send the compressed video to 802.11x?

Hello !

I have the system working on my 250 FPV Racing quad !

I have a Pi A+ on the quad and an old Pi B as a receiver, both connected to the CSL 300, running on the same script as Fnoop Dogg.

The range is somewhere around 200m before the first drops, wifi some crappy antennas, it could be improve with better antennas and diversity, and latency is somewhere between 200ms and 150ms.

Next step is the HD HMD for real FPV !

Thanks a lot befinitiv, the system is really promising !

@uttameflight,

Yes, there are two images, one for tx side and one for rx side.

I accidentally turned off "following" of this thread so missed this question.

Is it possible to use a smartphone camera module which has built in OIS instead of Pi camera in order to get steadier videos?

RPi can already do video stabilization. Use -vs parameter in raspivid.

Did you get it to work on Linux ?

I always have the same error on the receiver side :

DLT_IEEE802_11_RADIO Encap
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, width=(int)1280, height=(int)720, parsed=(boolean)true, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)01640028ffe1000e27640028ac2b402802dd00f1226a01000528ee025cb0
ERROR: from element /GstPipeline:pipeline0/GstFdSrc:fdsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2865): gst_base_src_loop (): /GstPipeline:pipeline0/GstFdSrc:fdsrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = NULL
Freeing pipeline ...

Any idea ?

But it is not physical stabilization.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service