Tuning P3S's wifi link capability.
P3S transmits video packet with fragmentation, and each fragmented packet requires ACK to complete transmission. If ACK does not arrive, drone retransmits packet. So even if some packet lost by any reason, the video can be seen normally, in close range.
Before FCC mod, it was not a problem that this ACK had timeouts, because P3S usually flown at close range. Packets transmitted, and ACK transmitted in return, so there is round trip of packets. The time limit set upon this round trip is 1us by default on most APs, because wifis are used within 10-20m range.
After FCC mod, P3S began to fly further, and problem arisen. At 1km, packets cannot return in 1us. Over 300m, time taken in round trip distance(×2) increases 1us at every 300m. Over this distance, ACK timeouts occured frequently even in ACK has been normally transmitted from RC. Retransmission is frequently occured at longer distance from drone for no purpose, at this time video transmission begins to lag behind, despite of full signal strength and clean radio environment. Combined this, loss of some amount of ACKs makes drone link speed drop, and transmission itself adjusted to less frequent. By the nature of TCP transmission, dropped link speed is slowly recovered over time, because wifi weighs error-less transmission over realtime-ness, and it suggests congested wifi network over dropped link speed.
There is option to increase ACK timeout in wifi command in drone and RC. By tuning this timeout parameter, video can be smoothed in the distance.
Try to run this at the terminal, after boot (essentially at drone, and better apply at RC)
iw phy phy0 set distance 800
By applying this, ACK timeout adjusted 1us to near 3us, and I could feel smoother video over 500-800m. (Where I usually feeling lagged video in clean wifi radio environment ).
Making this option too high, phantom's video signal meter drops, even if the drone is very close to the RC. That signal check method is known for counting successfully received ACK packets in some time window, so loosing the ACK window too much causes that method confusion. Making packets unfragmented (making packet transmission less frequent, for high throughput networking) shows similar result.
I got favorable result for test one or two, but it is still not proven. Same as txpower option, adjusting this parameter considered as not harmful during test. It can be executed at terminal, but as usually, test always should taken at own risk, because I don't know the side effects at the field, or in environment with much interference.
And please let me know when I got wrong at the theory. I feel everything is not evident without proper amount of testing.
Please do update us with any more results and confirmations from further tests. Thank you.