Clarification on Power calibration feature

[hemanth-silabs]

I was looking into the power calibration feature and there are two different macros that are provided, OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE and OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE. From the code it looks like the following combinations are possible.

1. If both macros are disabled, feature is disabled.
2. Only OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE is enabled, feature is disabled.
3. Only OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE is enabled, power_updater is enabled and vendor needs to implement the platform APIs.

• Stack now support set region commands and calls the otPlat__ APIs to update the Tx power.
• This needs to be implemented by the device manufacturers/vendors.

4. Both OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE and OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE enabled, both power_updater and power_calibration is enabled.

• Stack now support set region commands and calls the otPlat__ APIs to update the Tx power.
• This is now implemented in power_calibration.cpp and stack maintains the power table.
• Not sure where this will be used, raising the question to the community.

Is my understanding correct? If so where and how is option 4 useful. I see that all the platform APIs are already implemented in power_calibration.cpp (And not as weak functions). So, I see no way these values reaching the RCP/device for configuring the power.

[zhanglongxia]

The OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE is used to enable the OpenThread implemented power calibration feature on the RCP side.

The OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE is mainly used to enable the power calibration feature on the host side. The power calibration related spinel operations are also guarded by OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE.

So the OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE and OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE should not be enabled at the same time on POSIX platform (eg. Thread host).

Both the OPENTHREAD_CONFIG_POWER_CALIBRATION_ENABLE and OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE can be enabled on the RCP side. So that the RCP can use the power calibration feature and the power calibration related spinel code. RCP won't be the POSIX platform, the power_updater will not be enabled in this case.

[hemanth-silabs]

Thanks for the response @zhanglongxia. So if I understand correctly, both the macros can be enabled on RCP and only the OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE should be enabled on the host. Now the host will use the SPINEL commands to set the power reqs on the RCP, and the default implementation on the RCP (in power_calibration.cpp) maintains the power table. Now the platform can pull these configurations run-time, to calibrate the radio/FEM to achieve the desired Tx Power using otPlatRadioGetRawPowerSetting.

If this is the case, is there a way for platforms to know when the table is updated? Also would it make sense to update the function documentations to indicate that there is a default implementation of the APIs like otPlatRadioSetChannelTargetPower, and platforms can use it. Right now the documentation just says that the platforms need to implement them.

[hemanth-silabs]

@zhanglongxia can you confirm my assumptions above?

[zhanglongxia]

Thanks for the response @zhanglongxia. So if I understand correctly, both the macros can be enabled on RCP and only the OPENTHREAD_CONFIG_PLATFORM_POWER_CALIBRATION_ENABLE should be enabled on the host. Now the host will use the SPINEL commands to set the power reqs on the RCP, and the default implementation on the RCP (in power_calibration.cpp) maintains the power table. Now the platform can pull these configurations run-time, to calibrate the radio/FEM to achieve the desired Tx Power using otPlatRadioGetRawPowerSetting.

If this is the case, is there a way for platforms to know when the table is updated? Also would it make sense to update the function documentations to indicate that there is a default implementation of the APIs like otPlatRadioSetChannelTargetPower, and platforms can use it. Right now the documentation just says that the platforms need to implement them.

I think your understanding is correct. We assume that the calibration table and the target power table are fixed, and the Thread host sends the calibration table and the target power table to the RCP at the beginning of the Thread stack starts. So the RCP doesn't need to care about whether the table has updated. If you want to update the table after thread stack is working, you may need to add an extra feature to implement it. That's a good idea to add extra comments to the API documentations to let the developer know the default implementation.

[hemanth-silabs]

Thanks for the reply @zhanglongxia

[hemanth-silabs]

@zhanglongxia when power calibration is enabled the documentation states that otPlatRadioSetTransmitPower should not be enabled, but how about otPlatRadioSetChannelMaxTransmitPower? Is the expectation that the power table is maintained both in power calibration module and the RCP? How do we intend to reconcile this?

Cc: @jwhui @romacdon

[zhanglongxia]

In general, when we enabled the power calibration feature, we won't implement the function otPlatRadioSetChannelMaxTransmitPower. The power table is handled by the power calibration feature in RCP. But I think the RCP could implement both the power calibration and otPlatRadioSetChannelMaxTransmitPower, which feature is used could be determined by the host configuration (via config file or url).

[hemanth-silabs]

Thanks for the clarification @zhanglongxia. This is also one of the documentation item that we can update. I will try to raise a PR to add a note to this effect.

[hemanth-silabs]

@zhanglongxia is there any documentation to understand the power configuration in openthread.conf.example? I wanted to check if there is way to modify the conf file to provide different power calibration based on the RegulatoryDomain. Something similar to what we have for channelMask.

[zhanglongxia]

There is no other doc to describe the power configuration in openthread.conf.example. You can set different target powers for different RegulatoryDomains. The power calibration table should be unique, it is determined by the radio hardware.