-85 is a good tradeoff between sensitivity and false alarm
-95 will result in lots of non necessary decoding action (false alarm), and sometimes it leads to abnormal receiver state (stuck, etc)
-95 should be set manually while doing conductive test with wifi tester
1. Confirmed by CMW270 in OFDM mode (10us is for 11b where viterbi decoder is not needed)
2. See Signal Extension in 18.3.2.4 ERP-OFDM PPDU format of 802.11-2020
the issue of Let openwifi work at arbitrary frequency: ./sdrctl dev sdr0 set reg rf 1/5 NMPQ
the wpa_supplicant scanning does scan those not allowed channel (originally reported by our driver capabilities), but hostpad already actually uses a not allowed channel (by sdrctl) while beacon still indicates an allowed channel (hostapd rejects to run on not allowed channel). So, after wpa_supplicant discovers the beacon on a not allowed channel while the beacon contains an allowed channel, it gets confused
Create helper function ad9361_tx_calibration() and openwifi_rf_rx_update_after_tuning() for frequency tuning. No matter it is from Linux request or rf register 1 (Tx freq override MHz) and 5 (Rx freq override MHz)
1. Consider more corner cases: interrupt missing will cause a bd in the driver ring will never be cleaned. this need to be considered in the openwifi_tx()
2. Another corner case in openwifi_tx_interrupt: a packet is just sent and an interrupt calls the routine, but it finds that the bd in the driver ring has been cleared somehow
3. The driver ring and FPGA queue are always 1 on 1 mapping. User needs to map the higher level Linux priority to the driver ring idx instead of FPGA queue idx
4. Record the information about which FPGA queue (driver ring) has stopped which Linux priority before, and do exhausted search after a packet is sent (in the interrupt routine) to wake that Linux priority queue (in mac80211) up
5. Reserve more room before the FPGA queue full to adopt the last packet before we decide to stop the mac80211 queue. In this way, the last packet before the queue stop will still be put into FPGA and is expected to be sent (not lost/drop actively)
When pkt_cnt is 1, it is also possible the aggregation case (single packet aggregation). So the reporting type (non aggregation or aggregation) should be decided automatically based on a dedicated use_ht_aggr flag instead of pkt_cnt, otherwise the Linux minstrel_ht link adaptation can not get correct TX status report in the aggregation case and will keep using the lowest MCS0
