Clarification for Power calibration feature on RCP side.

[aashu216]

As we understood, Power calibration feature enabled calibration of power and support to set power per channel.

I have few queries on set target power per channel:

1. otPlatRadioSetChannelTargetPower() is similar to otPlatRadioSetTransmitPower() API only difference is otPlatRadioSetChannelTargetPower() set power per channel by reading configuration file from host and send to RCP while otPlatRadioSetTransmitPower() set power for current channel (assuming for all channel even if switch to different one) using ot-ctl command from host to RCP. Is it correct?

2. Can I use otPlatRadioSetChannelMaxTransmitPower() to define maximum limit of power per channel along with otPlatRadioSetChannelTargetPower() API?

3. Feature mentioned otPlatRadioSetTransmitPower() API should be disabled if otPlatRadioSetChannelTargetPower() is defined in RCP.
   May I know why it needs to be disabled? Why we can't maintain both feature? otPlatRadioSetTransmitPower() can configured power while host is running. otPlatRadioSetChannelTargetPower() only set power per channel when host is initialized stack. To update power table, we need to stop host and again required to re-run.

4. Why we can't provide new CLI to update power per channel using ot-ctl as well ? or can't we update existing ot-ctl txpower CLI to update power per channel and completely obsolete otPlatRadioSetTransmitPower() API?

[zhanglongxia]

1. Correct. The otPlatRadioSetChannelTargetPower() is used to set the power for a given channel. The otPlatRadioSetTransmitPower () will set all channels to use the same power.
2. For historical reasons, we have these two similar functions. Function otPlatRadioSetChannelTargetPower can provide a higher precision power settings. I recommend using the otPlatRadioSetChannelTargetPower() to replace otPlatRadioSetChannelMaxTransmitPower .
3. Use otPlatRadioSetChannelTargetPower() and otPlatRadioSetTransmitPower() at the same time will cause displaying wrong power value. For example, the user sets the power to a fixed value via otPlatRadioSetTransmitPower(), then an app calls the otPlatRadioSetChannelTargetPower() to change the power of another channel. The cli command still show the power value set by otPlatRadioSetTransmitPower, this power value is different with the actual set power value in Thread radio chip. It will be very confusing. So we suggest not enabling them both at the same time. If you are not care about this issue, you can implement these function at the same time. Note: otPlatRadioSetChannelTargetPower() also could be called in non-initial stage.
4. It should be fine to add a new cli to set power per channel.

[aashu216]

Thanks @jwhui @zhanglongxia ,
can target power limit set in negative value (i.e., -5 dBm)?

[jwhui]

Yes, of course. The API specifies the type as a signed integer.

[aashu216]

Thanks @jwhui , @zhanglongxia

for example, I have set power limit to 20 dBm for channel 11 using otPlatRadioSetChannelTargetPower() and now I have configured power level 18 dBm, Radio should send packet on 18 dBm power in range but if I configure power level 21 dBm, Radio will set power level to 20 dBm correct?

And as I know I think no any regulatory region supports negative TX power limit so why API has support for negative limit value?

[jwhui]

The API may be used to limit transmit power for other reasons, including testing.

We also designed the API to support future compatibility with other RF bands and regions.

[zhanglongxia]

for example, I have set power limit to 20 dBm for channel 11 using otPlatRadioSetChannelTargetPower() and now I have configured power level 18 dBm, Radio should send packet on 18 dBm power in range but if I configure power level 21 dBm, Radio will set power level to 20 dBm correct?

The current description of the API otPlatRadioSetChannelTargetPower() and otPlatRadioGetTransmitPower() doesn't define how to process this case. It depends on how the platform implements them.

[zhanglongxia]

Refer to the latest update of the platform power related APIs: #10839

[aashu216]

Thanks @zhanglongxia