Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1659 (new defect)

Opened 14 years ago

Last modified 12 years ago

Periodic Calibration must disable DMA engine during calibration

Reported by: mtaylor Assigned to: mtaylor
Priority: major Milestone:
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

The HAL doesn't disable the DMA engine when doing periodic calibration. Periodic calibration actually floats the tx antenna connection while the DMA engine is transmitting concurrently. This causes some very weak packets to go out. We need to work around this by disabling transmission during calibration, and possibly moving the calibration logic so that it happens when the transmission queue is empty and actually causes transmissions to be requeued until the calibration is finished. This would actually make more sense, as the calibration is for transmission and is ok to do when not transmitting and in between transmissions.

From Karol Kowalik:

Thanks a lot for your response. In the mean time I have also identified that these strange power drops are caused by the calibration.

Thus, commenting call to HAL function "ath_hal_calibrate" stops these strange power drops. However, I have read in Atheros patent (Titled: "Method and system for noise floor calibration and receive signal strength detection") that during calibration the antenna is in an open position or in the Rx position, when calibrating for the temperature/environmental changes. This disconnected antenna would explain the power drops. However, I was thinking that the card should not be allowed to transmit any frames during the calibration procedure. However, in my case it looks like it is indeed sending frames. I'm only not sure if it is an error or is it intentional? - Karol Kowalik

Thanks go to Karol Kowalik for isolating and reporting this defect!

Attachments

3nodes-5min.png (6.8 kB) - added by mtaylor on 11/21/07 05:04:14.
comparison-of-power-control.png (6.4 kB) - added by mtaylor on 11/21/07 05:04:30.
madwifi.remove-power-drops-after-calibration.diff (1.7 kB) - added by karol.kowalik@cnri.dit.ie on 12/17/07 15:17:50.
This patch corrects the value written to AR5K_PHY_PAPD_PROBE register by calibration procedure

Change History

11/21/07 05:04:14 changed by mtaylor

  • attachment 3nodes-5min.png added.

11/21/07 05:04:30 changed by mtaylor

  • attachment comparison-of-power-control.png added.

11/21/07 05:05:24 changed by mtaylor

And here's the original message from Karol:

"Dear Mike,

I have been recently testing tpc feature of Madwifi on my wireless cards. I think you are an expert in this area, thus I have a question for you. The TPC works fine, but I have a two problems with it which I do not know how to resolve.

1) After specifying the tx power over 63 mW its values falls down. I have observed this effect on a three different cards. Please have a look at attached figure "comparison-of-power-control.png". Do you know if this can be disabled?

2) The cards often exhibit strange tx power drops. I have observed this phenomenon in the following scenario with three nodes: A - receiver, B - monitor, C - transmitter. As you can see in Figure "3nodes-5min.png", every 1 sec there is drops of the tx power for a data frame, and every 30 sec there is a drop of tx power for an ack frame. Do you know what may be causing this? (the antenna diversity and transmission rate were fixed during this experiment).

Many thanks Karol "

11/21/07 05:12:16 changed by mtaylor

We can either

A) try to use HAL functions to pause transmission (even if stuff is in the hardware queue)

B) arrange it so that we run these steps when the transmit queue is empty and block acceptance of outbound packets from the kernel until calibration returns.

I *believe* concurrent receive in hardware and DMA engine operation is fine during calibration, and there's every reason to leave rx enabled as often as possible. Karol thinks the antenna is connected to receive circuitry during calibration, but either way, we should take anything we get.

- M

11/21/07 06:22:44 changed by mrenzmann

  • description changed.

12/17/07 15:17:50 changed by karol.kowalik@cnri.dit.ie

  • attachment madwifi.remove-power-drops-after-calibration.diff added.

This patch corrects the value written to AR5K_PHY_PAPD_PROBE register by calibration procedure

(follow-up: ↓ 5 ) 12/18/07 10:38:16 changed by karol.kowalik@cnri.dit.ie

Signed-off-by: Karol Kowalik <karol.kowalik@cnri.dit.ie>

(in reply to: ↑ 4 ) 03/04/10 17:04:59 changed by liubin@net.pku.edu.cn

Replying to karol.kowalik@cnri.dit.ie:

Signed-off-by: Karol Kowalik <karol.kowalik@cnri.dit.ie>

Hi,

I applied the patch provided by Karol on the latest Mawifi driver(reverison 4119). Then I found two problems with it in my testbed:

1) The reported signal strengths(by several different monitoring cards) of the affected frames don't drop any more, but are higher than those of unaffected frames by 4 - 10db. I'm not sure whether it's because the patch code fails to get the real txpower OR

2) In spite of the increased RSSI, those affected frames are more likely to corrupt because of FCS check failures. This phenomenon is easy to be reproduced when we set the card with the highest bitrate - 54M. All other packets can be successfully decoded at a nearby monitor except for those during power calibration.

I searched for this problem and found some are using this patch. However, my above findings show that the patch code didn't really solve the problem. Does any one still working on this ticket?

Thanks, Bin Liu