TX-Power limits for ath10k based card on Linux 3.18.24 (offlist)

[Ben Greear]

On 11/18/2015 01:01 AM, Joerg Pommnitz wrote:
> Michael, Ben,
> thanks for the illuminating answers. From Michaels latest reply I gather that the hardware is actually capable of transmitting with full power on a single chain/antenna, but that the current firmware or driver limits the tx power on a single chain in a way that makes sure that the combined tx power of all available chains is within the regulatory limits. Is this correct?
> What would it take to enable full tx power for a single chain?

My firmware should at least ask the hardware to transmit at full requested power
on a single chain when using legacy rates (or 1x1 HT/VHT rates).

I think you need to test with fixed rates so that you know what
rate you are sending, and make sure you are 99%+ duty cycle so that
you can trust your measurement tools...

Thanks,
Ben


>
>   -- Regards       Joerg
>
>
>
>> Michael Rex <mrex at tranzeo.com> schrieb am 21:22 Dienstag, 17.November 2015:
>>> Ben,
>>
>> That is definitely a good way to do it.  That seems to be the way lab
>> engineers have been configuring ART during the tests, but as you can see
>> from Compex datasheet, they are marketing the combined power of 2 and 3
>> chains, not making them the same regardless of chains. So they are marketing
>> it higher than their approved certificate says... I think nearly all MFG's
>> are doing that 'false' advertising.  Well, perhaps maybe not your
>> customer
>> who went through approvals...
>>
>> Since an individual chain is capable of full power, and companies want to
>> market and sell the highest power, I think it would be better (better
>> meaning max power achievable) to allow all 3 chains to go full power rather
>> than 1/3 power, but it would have to be done in time for the certification.
>> Not sure how complex the code would have to be to allow both methods of
>> target power setting, but you're kind of stuck for the people who already
>> approved on that driver behaviour.  It probably would increase power density
>> and other things and perhaps fail unless target power decreased to pass the
>> limit.
>>
>> Hard to say which way is better, but your method is the safer method of
>> passing approvals.  Given the expense of approvals, having it pass first try
>> might be more critical than squeezing out every dBm for the datasheet (tech
>> vs sales argument).
>>
>> Regards,
>> Mike
>>
>>
>> -----Original Message-----
>> From: Ben Greear [mailto:greearb at candelatech.com]
>> Sent: November 17, 2015 11:48 AM
>> To: Michael Rex; pommnitz at yahoo.com
>> Subject: Re: TX-Power limits for ath10k based card on Linux 3.18.24
>> (offlist)
>>
>> On 11/17/2015 11:20 AM, Michael Rex wrote:
>>>   Joerg,
>>>
>>>   The power at 11g is 15-19dBm, not 20dBm as shown in this screenshot.
>> There is no such thing as 2 chains power in 11g (they have diversity, which
>> means A port
>>>   or B port, there is no MIMO processing going on there to sum the powers).
>> That is a fallacy but they won't remove it from their datasheet.
>>>
>>>   The power will fluctuate, depending on the data rate used.  So when you
>> had less attenuation, it likely transmitted at 54M. When you added
>> attenuation, it
>>>   adapted to 6M and output 4dBm more.  You'd have to see the received
>> data
>> rate on the receiver, or test equipment that can detect it (I believe there
>> is still an
>>>   issue reporting data rate in Ath10k?).  The power for 48M is likely 16,
>> and 36M is likely 17dBm, so you kind of have to know what data rate is being
>> sent to
>>>   know how close to expected you really are. Otherwise, you could be 4dBm
>> off from your expectation, but its exactly as designed.
>>
>> You can force the data-frame transmit rate in ath10k firmware, and, at least
>> with my hacked kernel and firmware,
>> you can also force the management and broadcast/mcast frames to a specific
>> legacy rate.
>>
>> So, you should be able to force to 6Mbps, do a test, and then force to
>> 54Mbps, and do
>> another test to verify the tx-power at different rates.
>>
>> The change I made to my firmware regarding tx power is something like this:
>>
>> Original code took total-requested-power, and basically divided by 3 if NIC
>> was 3x3 capable.
>>
>> I changed it to set up tx-power based on the number of chains that a
>> particular rate would use, so
>> legacy rates got full power, 2x2 got 1/2 power, and 3x3 got 1/3 power per
>> chain.
>>
>> I'm not 100% sure this is correct, but it seems to work, and at least one
>> company using
>> my firmware passed regulatory testing with no problems related to tx
>> power...
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>>   Power accuracy is also not guaranteed and commonly outside of +/- 2dBm.
>> However, Compex is /usually/ one of the good ones you can usually count on
>> within -2dBm
>>>   of accuracy (I wouldn't bet money on it, quality varies for all
>> manufacturers).  So it is important to have accurately calibrated test
>> setups with measured
>>>   losses of cables and connectors, as NOTHING (short of $$$ parts) is ever
>> their rating.  For example, ALL my mini circuits 20dBm attenuators are
>> closer to 21dBm
>>>   than 20dBm.  All the cheap splitters have more than 4.3dBm of insertion
>> loss where people often expect 3dBm.  The attenuators like Aeroflex that are
>> 6X the cost
>>>   will be like 10.1dBm and 20.2dBm on their respective ratings as a
>> comparison of quality, in my experience.
>>>
>>>   In an earlier previous gen 11n Compex card, when you put the card in 11g
>> mode and used left chain (their firmware using the closed Qualcomm fusion
>> driver), you
>>>   got full output power. When you used right chain, there was like 7dBm
>> less.  Compex couldn't explain it to me, we just had to note it and move on.
>> Who knows if
>>>   something like that is part of the problem.  It could have been an antenna
>> misconfiguration in their calibration.  Likely, they often just accept the
>> Qualcomm
>>>   reference platform for the most part.
>>>
>>>   How accurate is your test setup and measurements? If you don't have
>> tested
>> losses, you can probably only say +/- 3dBm on your numbers, or just relative
>>>   measurement testing.
>>>
>>>   Best regards,
>>>
>>>   Mike
>>>
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com