Different information about latency of UDP over WFB about wfb-ng HOT 3 CLOSED

1. Yes. Original wifibroadcast pack incoming data from the pipe and send a new wifi packet only if it is full. This affects to latency because x264 frame size is not equal to wifi packet size.

2. Video stream use 8/12 fec rate (only 50% overhead). This mean that for recover one or more lost packet you need to receive 12 packets. Video has constant packet rate so delay will be small. But for example TCP stream for ssh connection will not have constant rate, so you will got freezes in case of packet lost. Due to this IPoverWFB use 1/2 fec rate (100% overhead). This allow to recover one packet lost without awaiting other packets.

For you case it depends: How frequently you will get lost packets? If there is noisy environment with burst noise - you can use 8/12 or (for example) 80/120, but you will need to send additional traffic (or modify wfb sources to emit empty packets) to close fec block.

from wfb-ng.

Thanks for quick response.

1. Does all differenting consist in the FEC coefficient? (I want to ask you. If I will be used UDP w 8/12 FEC is it will be same that if I will be used Video Stream w 8/12 FEC)? My basic message in the last question consist in why we are don't using UDP for RTP or MAVLink traffic? Because we can change FEC coefficient.

2. And I can't understood if I send data a lot (for example 100 JPEG files by 4MB each in the one queue), why I get a gap in queue packages? I guess it will just one queue. Is it correct?

from wfb-ng.

1. Yes. WFB doing injection of RSSI packets into MAVLink traffic. Also raw mavlink stream could be unidirectional (for example if vehicle is TX only and ground station is RX only) but UDP link require to be bidirectional
2. WFB doesn't use retransmissions (i.e. don't use ACK's as ordinary WIFI) for error correction. It use FEC instead. If FEC unable to recover data - you will got a gap. Using different FEC coding rate you could achieve immunity to different types of interference.

from wfb-ng.