Softdevice s140 radio power

RE: Softdevice s140 radio power

Jørgen Holmefjord — Tue, 12 Jan 2021 13:48:17 GMT

[quote user="kalpino"]By the way, I wonder if there is a way to temporarily disable the BLE timeslot, leaving all the radio to the Thread side.
Or at least, is there a way to manually set the timeslots dedicated to BLE and Thread?[/quote]

No, not with multiprotocol enabled in the application. But with no BLE roles enabled in the softdevice, all timeslot requests from the Thread stack/802.15.4 driver should be granted.

I would recommend you to read the details about the implementation in the above posted link:

"The SoftDevice RAAL client tries to constantly allocate timeslots with length of 6400 us. The time has been chosen to be longer than the longest single transaction on IEEE 802.15.4 protocol, and also to be a multiple of 200 us. The second requirement results from the smallest possible extension length, which is 200 us."

When any BLE roles are active, the softdevice will prioritize scheduling according to this table.

RE: Softdevice s140 radio power

kalpino — Tue, 12 Jan 2021 10:08:46 GMT

Thank you Jorgen! So I am actually changing radio power!

By the way, I wonder if there is a way to temporarily disable the BLE timeslot, leaving all the radio to the Thread side.
Or at least, is there a way to manually set the timeslots dedicated to BLE and Thread?

Thanks!

RE: Softdevice s140 radio power

Jørgen Holmefjord — Mon, 04 Jan 2021 12:58:15 GMT

Hi,

You need to set the output power for both protocols independently in a multiprotocol application. The Softdevice and OpenThread stacks are not aware that the other exists in the device, all handling of radio-sharing is handled by the softdevice timeslots and 802.15.4 radio driver arbiter.

Both the OpenThread stack/802.15.4 radio driver and the softdevice stores the configured output power internally, and reconfigures the radio in/after each timeslot, to make sure the radio is configured correctly for the protocol in use. This means that the value you read in the TXPOWER register of the radio may not reflect the value configured in the stack, you will have to capture the register at the exact moment before a frame is transmitted to get the correct value.

After you call otPlatRadioSetTransmitPower to set a new transmit power, you can call otPlatRadioGetTransmitPower to check that the value was set correctly.

Best regards,
Jørgen