CC2340R5: Power consumption variability while using ble central+peripheral

Hi Luca !

I'm not sure I completely understand your question, could you provide me with the following information :
- Which SDK version are you using ?
- What is the difference in your setup between the two pictures ?
- What is the exact issue you're facing, I don't quite understand what you mean by "missed tx/rx sleep transition"

Kind regards,
Maxence

Hi Lea 

SDK: 8.20.00.119

If the device is connected as peripheral only or central only the power consumption is constant and under 0.4mA, which is good.

If the device is connected at the same time as peripheral and central (2 ble connections) with different connection parameters, the power consumption is fluctuating with a period of 1 minute. It start at 0.4mA and then gradually it rises to 0.8mA (after ~1 minutes), then it decreases back to 0.4mA and then rises up and go down with same pattern.

My assumption is that happens due to shift and interleave in the radio tx/rx which depends on the different connection parameters. When the radio tx/rx happen at the same time for central and peripheral the power consumption is higher (maybe because the radio skip the sleep phase)

I would like to know if my assumption is correct and if there is a way to avoid that radio behaviour to have a constant power consumption when the device is connect both as central and peripheral.

Hi !

Can I ask what are your connection parameters ? It's likely that at some point the TX/RX from your peripheral will overlap the TX/RX from your central if they have different connection intervals, and that you will have a higher average in some periods and a lower average in other periods.

I'm not aware of any way to always separate the radio events of the central and the peripheral, but in any case the global consumption of your device should not change, the only difference is that you may have higher peaks in consumption.

Kind regards,
Maxence

Good morning,

Central can be in range of 30 to 45 ms 

Peripheral can be in range of 15 to 45 ms

A common configuration for connection interval is Central 30ms and peripheral 20ms

Hi,

I've tried to replicate your issue but I was unable to. I have a energy consumption similar to your graph on the right where the events are separated and never similar to the other graph. Are you using the basic_ble example for your test ?

Kind regards,
Maxence

No, the test is executed with our production firmware.

Lea  Hello,

I can replicate using the DK.

Here a video and the fw used.

In function EstablishConnection change the ble address th central shall connect.

5008.basic_ble_LP_EM_CC2340R5_freertos_ticlang.zip

Hi Luca !

I think you might have some drift in the clocks used for BLE. Could you tell me which clocks you are using, and if you're using the external clock ?

Kind regards,
Maxence

In the example I sent you above, the fw runs with development kit:LP-EM-CC2340R5

Lea  Hi, any update on this?

Hi Luca !

What I think is happening is that the timing for one of your connection is drifting a little bit (it could also be both connections drifting in different directions).

In your video, I assume that you have a connection A with 30ms of connection interval and connection B with 15ms of connection interval. At first, connection A and B are synchronized, and the radio events of connection A happen almost simultaneously as the radio events of connection B. But with time, those two connections get de-synchronized, and the radio events of connection A happen slightly before the radio event of connection B. This can be seen by having half of the energy consumption spikes being large (connection A and B happening, with a delay in between), and the other half being small (only connection B).

The delay between connection A and B is getting larger and larger as the connections are drifting apart. When this delay is under a few milliseconds, the power manager of your board makes the decision to not go to sleep, because a radio event if happening very soon. This is why you see a higher consumption in this case. When this delay is large enough (more than around 5ms), the power manager decides to go to sleep between radio events of connection A and B. However, this still causes higher consumption compared to when the connections are synchronized, as this wakes up and shuts down the CC2340R5 one more time than before.

In order to make sure that what I'm thinking is really what is happening, you could compare the energy consumption graphs to the Power Amplifier (TX) and Low Noise Amplifier (RX) graphs in a logic analyser, to see when is your device actually in a RX state or TX state. Here is a chapter of the user guide on how to enable the PA and LNA pins.

I think that the amount of drift in the BLE packets is surprisingly large, and I am not sure of what is causing it. It could be a bug where missed packets drift the connection interval by a little bit in time, which over time accumulates, it could be defective clock hardware, or something else entirely. One way could be to reduce the clock drift of your device, either by switching the clock used, by adding an external clock with less drift or to compensate for temperature. But even with that solution, if the clock of the devices that the CC2340R5 is connected to happen to shift, the same problem might arise.

I will spend time trying to reproduce your issue today and tomorrow, as I don't have the same dongles as you so it's a bit harder to reproduce.

Kind regards,
Maxence

Thanks for feedback.

I am able to reproduce using a phone or laptop to establish ble connection with unit acting as central+periperal. So it looks like it does not depend on the client connected to DK.

Hi !

I'm able to reproduce your issue. The only difference is that my delay is growing slower than you, it took me just below 15 minutes to have one "cycle", using 15ms for the central and 30ms for the peripheral. I still don't know what is causing this drifting, but I will continue to investigate.

Kind regards,
Maxence

Thank you

Hi,

I have opened a ticket to our R&D team to ask them about the situation. I will keep you updated.

Kind regards,
Maxence

Lea  any update on that?

Hi, 

R&D has not updated the situation.

Kind regards,
Lea