Skip to content

FPV range and latency test in a noisy environment

March 1, 2015

This post presents some range and latency test results using my wifibroadcast software together with two TL-WN722N wifi sticks transferring a video signal from a raspberry pi.

Latency

I did some latency tests using the usual “recursive” approach:

stopwacht

The results (using a block retransmission size of 8 packets) were mostly identical with the findings of PilotGary. At a resolution of 768×480 I was able to get 80ms and with 720p I got around 130ms. This is what I’ve expected.

Range

The range tests I did are not quite representative of a typical FPV scenario. I used my balcony (~18m above ground) for the transmitter. My street is full with flats of which most have their own wifi. This is what the street looks like:

IMG_20150301_174921
The transmitter is right at the end of the street at a distance of 450m.

Following is list of networks on the least used channel 13:


APs:
PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH
-70   3       26        5    0  11  54e. WPA2 CCMP   PSK  
-71  29      111        8    0  12  63e  WPA2 CCMP   PSK  
-73   0        0        0    0  11  54e  WPA2 CCMP   PSK  
-73   0      196        8    0  13  54e  WPA2 CCMP   PSK  
-74   7       42        1    0  11  54e  OPN              
-74   0       15        0    0  11  54e. WPA2 CCMP   PSK  
-76  18       10        0    0  11  54e. WPA2 CCMP   PSK  
-77   0       16        0    0  11  54e  WPA2 CCMP   PSK  
-78   0       19        0    0  12  54e  WPA2 CCMP   PSK  
-78   0        2        0    0  11  54e. WPA2 CCMP   PSK  
-80  39      174        5    0  13  54e  WPA2 CCMP   PSK  
-81   3       39        6    0  13  54e. WPA2 CCMP   PSK  
-81   0       31        0    0  12  54e  WPA  TKIP   PSK  
-81  11       43        0    0  13  54e  WPA2 CCMP   PSK  
-82  20      152        0    0  13  61e  WPA2             
-82  55      253       41    0  13  54e  WPA2 CCMP   PSK  
-82  33      137        0    0  13  54e  WPA2 CCMP   PSK  
-82   0        4        0    0  11  54e  WPA2 CCMP   PSK  
-80   0       33        0    0  13  54e. WPA2 CCMP   PSK  
-83   2       57        1    0  13  61e. WPA2 CCMP   PSK  
-84   0       63        0    0  13  54e  WPA2 CCMP   PSK  
-83  16       46        0    0  13  54e. WPA2 CCMP   PSK  
-83   0       17        4    0  13  54e. OPN              
-83  11       46        0    0  13  54e  WPA2 CCMP   PSK  
-83   0       47        0    0  13  63e. WPA2 CCMP   PSK  
-83   3       32        0    0  13  54e. WPA2 CCMP   PSK  
-83   0       11       11    0  13  55e  WPA2 CCMP   PSK  
-84   1       22        0    0  13  54e. WPA2 CCMP   PSK  
-86   0        2        0    0  13  54   WPA2 CCMP        
-86   0        7        0    0  13  54e  WPA2        PSK  
-87   0        0       15    0  13  -1   WPA              
-65   0        0        0    0  -1  -1                    
 -1   0        1        0    0  -1   0   OPN              
 -1   0        0        2    0  13  -1   WEP  WEP40       
                                                                                                                        
CLIENTS:

PWR   Rate    Lost  Packets 
                            
 -1    2e- 0      0        4
 -1    1e- 0      0        1
 -1    1e- 0      0        1
-75    0 - 1      0        1
 -1    2e- 0      0        1
-71    0 - 1      0        1
-30    0 - 1      0        2
-70    0 - 1      0        4
-70    0 - 1      0        1
-70    0 - 1      0        1
-70    0 - 1      0        4
-71    0 - 1      0        1
-72    0 - 1      0        2
-72    0 - 1      0        5
-72    0 - 1      0        1
-72    0 - 1     41        2
-74    0 - 1      0        2
-75    0 - 1     51        9
-75    0 - 2      0        4
-75    0 - 1      0        1
-76    0 - 1      0        2
-77    0 - 1      0        1
-77    0 - 1      0        1
-77    0 - 1      0        1
-77    0 - 1      0        2
-78    0 - 1     54        4
-78    0 - 1      0        1
-79    0 - 1      0        3
-80    0 - 1      0        1
-81    0 - 1      0        1
-81    0 - 1      0        1
-81    0 - 1      0        1
-81    0 - 1      0        4
-82    0 - 1      0        1
-82    0 - 1      0        2
-82    0 - 1      0        1
-83    0 - 1      0        1
-83    0 - 1      0        2
-83    0 - 1      0       12
                                

It is even worse than it looks since channel 11 overlaps with channel 13. I won’t spam you with the network list of channel 11. In summary: Around 50 networks with 100+ clients. And that is just what I’ve received using the standard 3dBi dipole that came with the TL-WN722N. All this traffic on channel 11 increases the noise level on channel 13 (that is the one that was used in this test).

Antenna setup

The transmitter used the standard dipole that came with the TL-WN722N. For the receiver I’ve built a double biquad antenna:
DSCF1110

You can find instructions to build one here.

The performance of that antenna is quite impressive. The RSSI was always around 10dB better compared to the dipole (assuming the unit the card showed to me was in dB. Often it is not). Still its beam is not too narrow for FPV (in contrast to most yagis and dish antennas).

To not look like a tinfoil head that runs through the street with that weird antenna and a laptop I put both laptop and antenna into my backpack. The laptop streamed its image to my phone via a second wifi network. Because of that I wasn’t able to align the antenna correctly. It always looked a bit downward instead of up to the transmitter. Also, it had no direct view to the transmitter. A plastic box, several shirts (for protecting the antenna) and the backpack were in between the direct line of sight. On top of that the line of sight was blocked by some trees. All in all pretty bad circumstances.

Results

Since the channel was so occupied I managed only to transfer 3mbit/s. Because of that I limited the image resolution to VGA. These were my test conditions: 768×480@30fps, 1mbit/s video rate, 26mbit/s air rate, retransmission block size of 8 packets, 1024 bytes of payload, triple retransmissions.

200m: Perfect image
300m: Noisy image but still flyable
400m: Very noisy images, not usable
600m: Still lots of packets received but most of them with bad FCS

Conclusion

300m of usable range might not sound like a lot. But I was really surprised it still worked at that distance. Imagine more than 200 networks and even more clients polluting the air around transmitter and receiver with noise. Together with the bad antenna alignment I am quite confident that this solution could reach at least 1km+ @ 720p with a direct line of sight and lesser networks in between.

Advertisements

From → Uncategorized

6 Comments
  1. I am really wondering how this will perform indoors in a small equestrian arena

    Your range limitations fit the arena size perfectly, the crowding would be limited.

    Have you tried this on non raspberry pi hardware? the OMX h.264 can be picky. Likewise testing streaming FROM a PC is difficult sans OMX. The Bellagio replacement can be finicky of course.
    -d0tslash (KF)

  2. I had perfect reception in my appartment over 20m with 4 concrete walls in between. So I think the only problem in your application might be multipath. Would be great if you could report your experiences if you use wifi there.

    I used the raspi exclusively (for tx). There were no problems using the h264 encoder. Have you experienced some difficulties?
    Out of curiosity, why would you want to stream from a PC to somewhere?

    • “Out of curiosity, why would you want to stream from a PC to somewhere?”
      Consider broadcasting other data *to* a heads up display, think non FPV applications. Or think of broadcasting to a display that a crowd was watching for example. (A multiplexed image, with some stats overlay, etc.) Just wanting to not be limited by the Raspberry PI. the USB bus for example is VERY fragile. I don’t care for the RasPI camera and perhaps want to use other USB based solutions that may hammer the Pi’s USB bus.

      “There were no problems using the h264 encoder.”
      The issue for me was compiling for NON raspberry PI based linux embedded distress. Not everyone can use the OMX h.264 plugins.

  3. I was hacking something like this back in October. I stopped because I couldn’t select the injection rate and didn’t digged why. Great work you did.

    Just one note that I think you missed. When you get away from a router it doesn’t just increase the number of retries to try to get the data to you. It decreases the rate. Decreasing the rate gives a better noise tolerance on the receiver, so the range increases.

    So the ideal solution is to use the slowest air-rate in which your data-rate will fit.

    Then, you have to play with some kind of FEC. So your data-rate might be 4mbps, and you can add 1mbps of FEC, and then transmit at MCS 0.

    With MCS 0 you probably can stream good Full HD video.

    So, there actually you don’t want more than MCS 0. You would want less if it was available in 802.11 MAC, because you could stream lower quality video much further.

    Since your hardware is still respecting CSMA/CA (regardless of monitor mode/injection), your actual air-time will not be 100% if there are any other ISM devices on the frequency. This probably will be a major issue while flying in urban areas. There will be a huge packet flood from other devices.

    • You are absolutely right! Actually I choose the data rate to be as low as possible (for my requirements. I wanted to have at least 720p). I think you might be able to squeeze that into MCS0 without any redundancy at maybe 3 to 4 mbps. However, in my experiments I found that both redundancy and key-frame rate are very important. My way of redundancy (just retransmitting the same data) has definitively some room for improvement. But it already increased the video quality a lot. And that would not have been possible with MCS0. The second issue is the key-frame rate. We have to be prepared for lost data or corrupted data. The default key-frame rate of (if I remember correctly) 10s was unusable for flying. If corrupted data has been received it was quite often the case that the whole image was disturbed for up to 10s. Unfortunately, increasing the key-frame rate requires a much higher bandwidth to keep the same quality level. The video you find in my latest post was shot with 7mbps @ 720p.
      So these are the experiences that led me to choose MCS3 in the end 🙂

      Your second point about CSMA/CA is also a very important issue. In urban environments you would have to decrease the video quality a lot. In this post I was able to transfer 500kbps with 2x retransmission. And I think this is probably the worst case scenario concerning channel business. It might be a good idea to monitor at the sender the throughput and eventually switch to a lower video quality automatically.

Trackbacks & Pingbacks

  1. FPV range test in a park | befinitiv

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: