"FYI: I just pushed the FEC code for wifibroadcast into mainline. This improves the bandwidth requirements and/or reliability of wifibroadcast significantly. Refer to https://befinitiv.wordpress.com/2015/07/19/forward-error-correction..."

"True, but the preparational tasks from raspistill are excluded from my measurements. I measured the time from capture (which is after the preparational tasks) to arrival in memory."

"Using the same technique I also timestamped capture and encode. This was just a quick hack so no guarantees for correctness. But:

Encode of a 1280x720 from memory to memory frame takes 10ms (hello_encode)
Capture of a frame using raspistillYUV…"

"1280x720 @ 700kbsp in case of 2 fps, 3mbsp otherwise.

I've found where in the pipeline the last frame gets stuck. Raspivid uses fwrite to output the h264 data to stdout. Since fwrite is buffered, not all data received from the encoder has been…"

"Ok, so I have some initial results. The method of obtaining them was:

- Let a timestamp (aka stopwatch) run on the PC screen
- Capture the PC screen with the Raspi camera and transfer the data
- On the receiver (PC) parse the received data stream…"

"Thanks for the results! How exactly did you measure the latency? Using the stopwatch+screenshot approach?
Currently I'm diving into the main source for the latency. So far I've found that there are most likely no frames "stuck" in the raspi encoder…"

"Could you please post the command line?"

"That is amazing! Thanks a lot for the detailed results!"

"Hi Fnoop

Yes, the 300m were with the white omnis that came with the 722s."

"I looked into that issue and resolved a sharp edge from tx. It wasn't catching EOF at input, leading to zero sizes packets being flooded at maximum rate. That's why you observed 0B/s at the rx side. If you pull from my repo you'll get the patch."

"Could you please show us as well the output of tx right at the beginning? It might be a problem with your video data from raspivid. Your high tx rate reminds me a bit of an effect that occurs when the data source process (in this case raspivid)…"

"Hi uttameflight

I think you are almost there :) Could you post us the complete command lines you are using for both tx and rx side?"

"Patching the kernel definitely helps increasing the range. I made the instructions on my page a bit more clear on that point. By default the patch sets the output power to 20dBm. Depending on your country and hardware you could set this value…"

"Hi

Some hints that might help you to reproduce the ranges I measured:

- I heard rumors that the Alfas are good at TX but pretty bad at RX. In my tests I used the Alfa for TX and the TP-LINK 722 for RX.
- Did you apply the my kernel patch on the TX…"

"The range tests on my blog (except the very first ones) are made with the Alfa as tx. With that I could reach 900m omni2omni and 3km+ omni2doublebiquad. with two wn722n I reached 300m (more or less) omni2omni and 1km with omni2doublebiquad."