For simple cases you can use omnidirectional antennas with linear (that bundled with wifi cards) or circular leaf (circularly polarized Coverleaf Antenna (opens new window)) polarization.If you want to setup long distance link you can use multiple wifi adapters with directional and omnidirectional antennas. TX/RX diversity for multiple adapters supported out of box (just add multiple NICs to /etc/default/wifibroadcast).If your WiFi adapter has two antennas (like Alfa AWU036ACH) TX diversity is implemented via STBC (opens new window).Cards with 4 ports (like Alfa AWUS1900) are currently not supported.
Wifibroadcast
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.
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).
For your convenience, there is a prebuild image available for your Raspberry PIs. You can download it here: _wifibroadcast_image_builder/releases/latestPut the onto two SD cards (as explained here).
The logitech c920 has built in hardware encoder which makes 3mbit h264 video at any resolution (up to 1080p), and so I am looking for a way to easily pipe the camera h264 into wifibroadcast with as little latency as possible.
Yes, every video I posted in this blog is a ground recording. For details about the setup please refer to -about-my-flight-setup-and-first-tests-of-wifibroadcast-in-the-air/ and -of-my-ground-station-and-sample-video-of-a-weak-link/
That is quite strange. The TX restart message says that you lost 14680064 packets which does not make sense. I guess that the packet contents are not well (like something is prepended to the packets content). This way the sequence number (the first 4 bytes of each packet) is assumed to be at a wrong place. The best way to debug this issue is to capture the transmitted packets (maybe with bogus-data instead of actual video data) with wireshark and inspect if the sequence number is where it is supposed to be. Really helpful for this is to setup a display filter for the wifibroadcast MAC address.
You noticed the new branch quite fast ? Udpcast was a very good tip of yours, so thank you on that! I was surprised to see how fast the code is. It can use the full bandwidth (22mbit/s) in case of the Raspi A+ with 1/2 coding. A rough comparison of wifibroadcast retrans vs fec shows that by comparing just the error counts a coding rate of 1/2 with retransmissions is roughly as relieable as a 3/4 rate with FEC. However, this was just at a block length of 4 packets. Using longer blocks significantly improves FEC compared to RETR. So using FEC might open up the possibility of using MCS1 ( ) for increasing the range/relieability.
Regarding wifibroadcast on a Mikrotik device. You mean some kind of wireless AP? Not sure what those Mikrotiks run, but I have read on some other forum that somebody made it work on a wireless AP with OpenWRT.
Your relay approach might suffer from insufficient USB bandwidth on the relay station. Try first to get the relay mode working with a normal linux pc to make sure that it is a wifibroadcast and not a raspberry pi issue.
Ok, so I set wifibroadcast up on an Ubuntu linux pc as a relay. The transmitter is an Rpi A+ sending on ch 8 using an WN722N. Receiver is an B+ on ch 3 using an WN722N. Wlan1 and wlan2 are two WN722N adapters sitting in an external powered USB hub. All are fairly close together physically. On the relay pc I start this script:
I made some experiment by comparing wifibroadcast older version vs. newer version. Sadly to say that newer version (example above) acts with plenty of incorrect decoded frames.I have 4 pics of WN722 adapters they show similar results. In first place when updated to newer version I though that some problems with hardware, but finally I figured out that frame droppings appears in near range 1-2 meters. This same happening 10 meters and 30 meters away. Also when connecting WN722 to 2W dropped frames appears in wider range. Thus changing SD card in Raspberry with older wifibroadcast version this same hardware work totally better. No dropped frames 100-150 meters away picture are crystal clear.
I know that this does not quite add up with your findings. It is strange because there are no fundamental differences between the two versions. So possibly another change between the two SD cards has caused your observations (channel, kernel patches)? You could try this by staying on the same SD card and check out and compile the different wifibroadcast versions.
The time from power off to start loading raspivid and piping to wifibroadcast is about 5-6 seconds. It would be great if there is a way to get libpcap-dev on buildroot, or if there a way to get wifibroadcast compiled with the non-dev version of libpcap-dev (which is compatible with buildroot).
Someone else already realized a two-camera transmission using wifibroadcast. He reported back here on the comments and apparently it worked quite well (refer to -analog-like-transmission-of-live-video-data/#comment-566 ). h265 is not supported by the Raspberry. I think there are other boards around that support this format but it is still unclear what their latency would be.
Very cool project.I am running a Pi B (not +) as TX and a Pi 2 as RX. I have two CSL-300 (two antennas).I downloaded the wifibroadcast 0.4.Yesterday I managed to get the transmission working once, but with a lag of about 10 seconds. Today I get no video on the RX. I noticed several messages in the systemd journal and tx.sh starts and stops endlessly:
When I put the RX on wifibroadcast on channel 14, it seems that wifibroadcast accept this channel 14.(no error messages)The TX seems to be accept channel 14 as well, but its dos not transmit any data(flashes one time and then steady on the dongel).
As far as I understand these Ubiquity-devices are Ethernet to Wifi gateways. Such a gateway does not allow the use of wifibroadcast. The reason for this is that wifibroadcast needs to talk directly to the WIFI chipset to put it into a non-standard mode. Only a few chipsets are capable of doing so. The models are listed on this page.
You are right, I first used wifibroadcast with my 35MHz RC system. This caused some crashes of my quad so I upgraded to 2.4GHz RC. And you are right, that interferes heavily with wifibroadcast. There are basically 3 ways around that:
As a countermeasure you should increase the number of buffered blocks with the parameter -d. If for example -d would be two then in the examples above wifibroadcast would keep block 1566 and 1567 at the same time. Maybe a value of two is a better default setting. This, however, increases latency by one block.
Hello.I just tested the telemetry text overlayed on video with picamera and mavproxy module (MyPiModule) before transmission in wifibroacast (255 chars max).Here you find an example (MyPiCamera.py) of a python script : -telemetry-text-on-video-before-wifibroadcast/This solution is very simple and effective.
In any case if someone at least has guidance on how to change the modulation or wants to help me find out this may be a more viable future option then wifibroadcast in terms of range and reliability (I mean if the Solo works up to 2.5mi with these cards), while offering a full wifi link.
Since you want to integrate wbc into Raspivid: There is a much simpler way that requires no recompiling of raspivid. I already implemented all the required bits and pieces in the low_lat_raspivid_hook branch ( -technologies/wifibroadcast/commits/ca50865f0a5ab4d73b6428e0698308e4c2140a08?at=default#Ltxhook.cT24 ).It basically takes control over the fwrite function calls from raspivid.
For simple cases you can use omnidirectional antennas with linear (that bundled with wifi cards) or circular leaf (circularly polarized Coverleaf Antenna) polarization. If you want to setup long distance link you can use multiple wifi adapters with directional and omnidirectional antennas. TX/RX diversity for multiple adapters supported out of box (just add multiple NICs to /etc/default/wifibroadcast).If your WiFi adapter has two antennas (like Alfa AWU036ACH) TX diversity is implemented via STBC. Cards with 4 ports (like Alfa AWUS1900) are currently not supported for TX diversity (only RX is supported).
A: The original version of wifibroadcast used a byte-stream as input and split it to packets of fixed size (1024 by default). With this scheme if radio packets were lost (and this was not corrected by FEC) the result was random/unexpected holes in the stream. This is especially bad if the data protocol is not resistant to such random erasures.
A: Wifibroadcast is not tied to any GPU - it operates with UDP packets. But to get RTP stream you need a video encoder (with encode raw data from camera to x264 stream). In my case RPI is only used for video encoding (because RPI Zero is too slow to do anything else) and all other tasks (including wifibroadcast) are done by other board (NanoPI NEO2).
osboxes@osboxes:/wifibroadcast$ sudo ./rx -b 8 -r 4 -f 1024 wlan0 gst-launch-1.0 -v fdsrc ! h264parse ! avdec_h264 ! xvimagesink sync=falseDLT_IEEE802_11_RADIO EncapSetting 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/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:sink: caps = video/x-h264, width=(int)1280, height=(int)720, parsed=(boolean)true, stream-format=(string)avc, alignment= (string)au, codec_data=(buffer)01640028ffe1000e27640028ac2b402802dd00f1226a01000528ee025cb0/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt709, framerate=(fraction)25/1ERROR: 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/avdec_h264:avdec_h264-0.GstPad:src: caps = NULL/GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:sink: caps = NULL/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = NULLFreeing pipeline ...osboxes@osboxes:/wifibroadcast$ 2ff7e9595c
Comments