> -----Message d'origine----- > De : quozl@xxxxxxxxxx [mailto:quozl@xxxxxxxxxx] > Envoyé : jeudi 15 février 2018 08:21 > À : Kalle Valo > Cc : Jean Pierre TOSONI; linux-wireless@xxxxxxxxxxxxxxx; ath9k- > devel@xxxxxxxxxxxxxxxx > Objet : Re: [PATCH v2] ath9k: mark RSSI as invalid if frame received > during channel setup > > On Thu, Feb 15, 2018 at 07:51:28AM +0200, Kalle Valo wrote: > > James Cameron <quozl@xxxxxxxxxx> writes: > > > >> On Wed, Feb 14, 2018 at 04:26:42PM +0000, Jean Pierre TOSONI > wrote: > >>> ath9k returns a wrong RSSI value for frames received > >>> in a 30ms time window after a channel change. The > >>> correct value is typically 10dB below the returned value. > >> > >> How was your correct value determined? > >> 1) test setup: Connecting the AP through coax and attenuators, then making 500 passive scans off-channel, then drawing an histogram of the beacon signals found by the chip. The off-channel period is 108 ms. The probability of being in the 30 ms window is 28%. The histogram shows 2 spikes, one large with the expected value, one small at around +10dB above. 2) value determination Adjust the delay (CONFIG_HZ=250) by trial and error. 25ms was not enough to completely absorb the +10dB spike in the histogram, while 30ms was enough. Do you think of a better approach? Maybe the guys at Qualcomm know the correct value? > >>> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / > >>> JWX6083 cards), during offchannel scans. > >>> > >>> Mark the signal value as invalid in this case. > >> > >> Why not adjust by 10dB? I considered that also. But, 1) during how much time should I do this adjustment? Around 30 ms after channel switch? 2) The histogram shows a scattering of the measures in a +/- 3dB range around the mean value. So I could not decide for sure if it needed -9dB, -10dB or -11dB? > >> > >> Speculating: in a typical card, RSSI is calculated by firmware > from > >> readings of ADCs attached to the receiver. Firmware may average > >> several readings. Firmware may apply other offsets or > calibrations, > >> based on frequency and temperature. This sounds like a firmware > >> problem. > > > > ath9k does not have firmware, only ath9k_htc has it. > > Heh. s/firmware/silicon implementation/g Oh well, if it's silicon problem, then it's a hardware problem, and I am right to correct it that way, since there is no other way :-) > > -- > James Cameron > http://quozl.netrek.org/
