Skip to content

Getting used to FPV

May 16, 2015

This post presents just another FPV video transmitted using wifibroadcast

After my last crash I rebuilt my quad and tried it out today. And I am getting more and more used to the FPV feeling. I am still a total noob compared to others but there is progress 🙂
Since I was a bit afraid to crash again I went for maximum safety: triple retransmissions, 5MBPS, 30fps with a keyframe every 15 frames (thus 2Hz). Due to that and a dirty lens the image quality is not optimal. Again, I had the receiver in my pocket and my body occasionally blocked the line of sight. Therefore, there are some disturbed video frames. I really need something to put the antenna on!

Here is the video (recorded at the ground station):

From → Uncategorized

  1. malkauns permalink

    Are you confident enough to be going behind objects like trees etc? If so, I would love to see how the stream recovers from obstacles blocking the signal. I will be testing this soon on my quad as soon as a UBEC that actually does its job properly without blowing my Raspberry Pi’s arrives. 🙂

    • After my last crash I am still too afraid to risk something. But I will try this when I have more pratice with the system.

      Do you want to power the Pi through tge BEC? Afaik most BEC provide 5V by a linear regulator. These devices are probably not powerful enough. It is best to use a Dc/Dc converter.

  2. malkauns permalink

    I actually succeeded in getting it powered by a 4S Lipo today :). It’s too late now so will work on getting it on my quad tomorrow. One thing to note was that the Alfa card needs more power than what the Pi gives it by default. The interface was not coming up at all due to “usb 1-1-port2: over-current change” found in dmesg. After some research I found that adding max_usb_current=1 to /boot/config.txt gives the Pi’s USB hub enough power for the card to come up everytime without a problem. 🙂

  3. malkauns permalink

    Here’s a very short clip of me flying with wifibroadcast (2.4GHz) on my miniquad:

    Pretty much 90% of the glitches are due to my Frsky Taranis controller transmitting on 2.4GHz. Lots more work to do to get everything working on 5GHz. By the way I got diversity working with the code so I can use a number of wifi adapters. The code will switch to the adaptor with the least lost blocks in real time whenever there is packet loss. I’ll post it soon.

    • Wow, great! Now you are officially the first adoptor of wifibroadcast 🙂 Could you remove the “private” flag from the video? I’m really curious to see it! I’ll reply later to the other points when I have a real keyboard in front of me…

    • Very cool! Maybe there is an alternative for you instead of using 5GHz. Someone in the comments here pointed out that the TL-WN722 chipset can work on a wider frequency range. Your TX is sending on 2405-2477 MHz according to its CE specs. I don’t know where you are located but maybe your regulatories allow you to go above or below that. The changes required are covered in detail here:

      And the diversity thing: I am really curious. Do you have any code to share?

      • malkauns permalink

        Here’s the code:

        It uses 1 thread per adapter and basically filters the output to stdout to the one with the least recent packet loss. I didn’t think much about the algorithm so let me know of any potential improvements.

      • Wow, really, that is a great idea. And it makes so much sense since the wifi sticks are so cheap! Thank you a lot! I integrated your idea into wifibroadcast, although I modified it a bit. I always receive all packets on both adapters and assemble out of all available packets my “retransmission blocks”. So basically there is no switching anymore and it is always used the best data available. And I am /SO/ amazed about the results!! Without diversity I had a packet loss rate of around 1%. With two adapters the loss rate is basically zero. I had a single lost packet out of 300.000! And my environment is really really noisy. I’m really excited. If you want to test that by yourself you can check out the “diversity” branch in wifibroadcast. There are still some open issues (refer to the commit messages) but it already works quite well. Have fun! 🙂

      • malkauns permalink

        I have tried the new code but do not get the same results as you. I too had the same idea of combining the data provided by both adapters but did not get decent visual results. With the new code if I put one of the adapter antennas next to the source of interference (eg. Taranis 2.4GHz TX) I get garbled visual output even though the other adapter is getting a perfect signal. This is not the same behavior as the diversity code I posted on pastebin which basically switches to the adapter with the least recent errors. One issue that comes to mind in this testing is that I am using wifi adapters from 2 different manufacturers. It could be that one adapter is faster than the other at sending received packets to the kernel and is causing the latest blocks to be written out before the other adapter with better signal has had a chance to provide cleaner data. I think you are seeing better results because you are possibly using the same adapters at each end. Let me know what you think.

      • malkauns permalink

        I just tested my theory on adapter speed and it appears to hold true. I modified the code to count which adapter caused the write to stdout by incrementing block_num. My Alfa AWUS051NH adapter caused this 88% of the time indicating that it is alot faster at passing on data to the kernel than my TP-Link TL_WN722N. Therefor if my Alfa is the adapter that is dropping packets but still quicker at receiving a packet here or there with the latest block_num it results in garbled video. I guess the solution for me is to use the exact same adapters at my station.

      • Yes, that sounds very plausable. Maybe the software should keep a window of retransmission blocks instead of just the current one. If the window is big enough to span over the delay between the cards then that problem should be solved. This would increase the latency a bit (since we are buffering more packets) but it would be still more or less the same latency compared to only using “slow” cards (since we are effectively only delaying the “fast” packets). That doesn’t sound too complicated to implement. Unfortunately, I’m current short of time to implement that. What do you think about that idea? Maybe you would have some spare time to try it out? 🙂

  4. malkauns permalink

    oops, done.

  5. moviles baratos

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: