TX Power Concerns between Firmware

TX Power Concerns between Firmware

[Pushpal Sidhu]

Hi all,

I haven't seen this brought up before, but has anyone done power meter
readings on ath10k with the various firmware? If anyone has, can you
verify my findings below? There seems to be an issue between the two
firmware. Please note that I've tested both the latest ath10k
git/master as well as a version a few months back.

I just compared 10.1.467.2-1 and 999.999.0.636 firmware versions on
several WLE900VX cards (to verify consistency). Reading the datasheet
(http://www.compex.com.sg:809/Datasheets/WLE900VX_Dsv1.0.3-271013-I.pdf)
shows that at the highest MCS rate it supports at the 5GHz range, the
max txpower per chain is 10dBm, and aggregate txpower is 15dBm (+/-
2dB).

My test setup was as follows (please excuse my ascii art):

----------
|dut(ap) |
|           |
|C C C   |
|H H H   |
|0 1 2    |
----------
 | | |_______[power-meter]
 | |
----------
|0 1 2    |
|H H H   |
|C C C   |
|            |
|dut(sta) |
----------


If the above art is unreadable, that's two WLE900VX radios, one
configured as an AP, the other as a STA. CH0 and CH1 were connected
via 30dBm attenuators and the third chain of the radio configured as
an AP was connected to the power meter via a 10dB attenuator. With
cabling etc, there was probably about a 15dB attenuation between the
power meter and radio.

I used software (iw) to configure the txpower of the ap radio and
performed an iperf test to generate traffic (if anyone knows how to
get a single radio into continuous transmit mode, please let me know,
it will help this test immensely).

The follow are my results:
| Firmware     | txpower (software) | reading | +15dBm offset |
| 10.1.467.2-1 | 15                       | -6         | 9                     |
| ''                  | 10                       | -10.6     | 4.4
             |

Then same radio(s), different firmware:
| Firmware        | txpower (software) | reading | +15dBm offset |
| 999.999.0.636 | 15                        | 10.3     | 25.3                |
| ''                    | 10                        | 7.5       | 22.5
               |


As you can see, the results are wildly different. Is this something
that the driver can fix? Or is this a firmware problem? It goes
without saying that this is a big danger for devices etc connected to
the radio.

- Pushpal

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: TX Power Concerns between Firmware

[Michal Kazior]

On 29 October 2014 23:56, Pushpal Sidhu <psidhu@gateworks.com> wrote:
> Hi all,
>
[...]
> The follow are my results:
> | Firmware     | txpower (software) | reading | +15dBm offset |
> | 10.1.467.2-1 | 15                       | -6         | 9                     |
> | ''                  | 10                       | -10.6     | 4.4
>              |
>
> Then same radio(s), different firmware:
> | Firmware        | txpower (software) | reading | +15dBm offset |
> | 999.999.0.636 | 15                        | 10.3     | 25.3                |
> | ''                    | 10                        | 7.5       | 22.5
>                |
>
>
> As you can see, the results are wildly different. Is this something
> that the driver can fix? Or is this a firmware problem? It goes
> without saying that this is a big danger for devices etc connected to
> the radio.

Thanks for reporting.

My rough guess is the 999.999.0.636 blob has an old otp binary
embedded inside which doesn't support the XB140 design. We probably
need to update it.

@Kalle: Now that I think about it - do we really need to embed otp binaries?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: TX Power Concerns between Firmware

[Kalle Valo]

Michal Kazior <michal.kazior@tieto.com> writes:

> @Kalle: Now that I think about it - do we really need to embed otp binaries?

In theory we could release otp.bin separetely. But that would be error
prone from user's point of view (they need to update two files instead
of just one), more work for us to track otp.bin releases etc.

So I'm not really fond of the idea. I would rather update otp.bin and
create a new firmware version.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k