Update docs

README.md

@@ -1,14 +1,25 @@
 Wifibroadcast
--------------
+=============
 
-This is transmitter and receiver of UDP packets using raw WiFi radio inspired by https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/ . The main difference is how to data are encapsulated into ieee80211 frames. The original wifibroadcast accepts stream of bytes and split them into packets without attention to x264 stream elements. This can emit up to 100ms latencies.  In my case wifibroadcast accepts UDP stream (for example x264 encapsulated into RTP packets). This provides low latency streaming.
+This is transmitter and receiver of UDP packets using raw WiFi radio inspired by  https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/ . The main difference is how the data are encapsulated into ieee80211 frames. The original wifibroadcast accepts stream of bytes and split them into packets without attention to x264 stream elements. This can emit up to 100ms latencies.  In my case wifibroadcast accepts UDP stream (for example x264 encapsulated into RTP packets). This provides low latency streaming.
+
+Other features:
+---------------
+ - Stream encryption and authentication
+ - Distributed operation. It can gather data from cards on different hosts. So you don't limited to bandwidth of single USB bus.
+ - Aggreagation of mavlink packets. Don't send wifi packet for every mavlink packet.
+ - OSD https://github.com/svpcom/wifibroadcast_osd for raspberry pi (consume 10% CPU on PI Zero)
 
 
-Wifibroadcast puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association. Additionally, it is also possible to receive erroneous frames (where the checksum does not match). This way a true unidirectional connection is established which mimics the advantageous properties of an analog link. Those are:
+Theory:
+-------
+
+Wifibroadcast puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association.
+This way a true unidirectional connection is established which mimics the advantageous properties of an analog link. Those are:
 
  - The transmitter sends its data regardless of any associated receivers. Thus there is no risk of sudden video stall due to the loss of association
 
- - The receiver receives video as long as it is in range of the transmitter. If it gets slowly out of range the video quality degrades but does not stall. Even if frames are erroneous they will be displayed instead of being rejected.
+ - The receiver receives video as long as it is in range of the transmitter. If it gets slowly out of range the video quality degrades but does not stall.
 
  - The traditional scheme “single broadcaster – multiple receivers” works out of the box. If bystanders want to watch the video stream with their devices they just have to “switch to the right channel”
 
@@ -19,8 +30,9 @@ Wifibroadcast puts the wifi cards into monitor mode. This mode allows to send an
 
 
 Sample usage chain:
+-------------------
 ```
-Camera -> gstreamer --[RTP stream (UDP)]--> wifibroadcast_tx --//--[ RADIO ]--//--> wifibroadcast_rx --[RTP stream (UDP)]--> gstreamer --> Display
+Camera -> gstreamer --[RTP stream (UDP)]--> wfb_tx --//--[ RADIO ]--//--> wfb_rx --[RTP stream (UDP)]--> gstreamer --> Display
 ```
 
 For encode logitech c920 camera:
@@ -36,9 +48,17 @@ To decode:
 ```
 
 
-Supported WiFi hardware:  Ralink RT2800. Was tested with ALPHA AWUS051NH v2 in 5GHz mode. To disable ieee80211 autospeed and maximize output power you
-need to apply kernel patches from ``patches`` directory. See https://github.com/bortek/EZ-WifiBroadcast/wiki for details.
+Supported WiFi hardware:
+------------------------
+My primary hardware target is Ralink RT28xx family. These cards are cheap and have best packet injection speed.
+System was tested with ALPHA AWUS051NH v2 as TX and array of RT5572 OEM cards as RX in 5GHz mode.
 
-Wifibroadcast + PX4 HOWTO: https://dev.px4.io/en/qgc/video_streaming_wifi_broadcast.html
+To disable ieee80211 autospeed and maximize output power you need to apply kernel patches from ``patches`` directory. See https://github.com/svpcom/wifibroadcast/wiki/Kernel-patches for details.
 
+Wifibroadcast + PX4 HOWTO:
+--------------------------
+https://dev.px4.io/en/qgc/video_streaming_wifi_broadcast.html
+
+Wiki:
+-----
 See https://github.com/svpcom/wifibroadcast/wiki for additional info

rx.cpp

@@ -265,6 +265,14 @@ int Aggregator::rx_ring_push(void)
     // override existing data
     int idx = rx_ring_front;
 
+    /*
+      Ring overflow. This means that there are more unfinished blocks than ring size
+      Possible solutions:
+      1. Increase ring size. Do this if you have large variance of packet travel time throught WiFi card or network stack.
+         Some cards can do this due to packet reordering inside, diffent chipset and/or firmware or your RX hosts have different CPU power.
+      2. Reduce packet injection speed or try to unify RX hardware.
+    */
+
     fprintf(stderr, "override block 0x%Lx with %d fragments\n", (long long unsigned int)(rx_ring[idx].block_idx), rx_ring[idx].has_fragments);
 
     rx_ring_front = modN(rx_ring_front + 1, RX_RING_SIZE);
@@ -274,13 +282,13 @@ int Aggregator::rx_ring_push(void)
 
 int Aggregator::get_block_ring_idx(uint64_t block_idx)
 {
-    // check if block already added
+    // check if block is already to the ring
     for(int i = rx_ring_front, c = rx_ring_alloc; c > 0; i = modN(i + 1, RX_RING_SIZE), c--)
     {
         if (rx_ring[i].block_idx == block_idx) return i;
     }
 
-    // check if block was already processed
+    // check if block is already known and not in the ring then it is already processed
     if (last_known_block != (uint64_t)-1 && block_idx <= last_known_block)
     {
         return -1;