• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1405 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2541 inconsistent delay before entering PM2 mode

Dan Lazar
Prodigy 50 points
Other Parts Discussed in Thread: CC2541

My company is using TI CC2541 as a ble sensor.

We are using beacon which transmits at 150ms intervals, and our ble sensor is responsible for receiving the advertisements.

We use the latest ble stack 1.4.1.

 

I tried to reduce the ble power consumption by synchronizing the ble receiver to the beacon, i.e. I start the discovery of the ble receiver just before the beacon transmission, and cancel it right after it receives the transmitted packet. 

 

Here is an example sequence of this process (at 150ms intervals):

1. BLE - starts discovery

2. Beacon - advertises packet

3. BLE - receives packet and goes to sleep for 140ms (cancelDiscovery + osal-event)

4. BLE - after 140ms - starts discovery

5. Beacon - advertises packet

6. BLE - receives packet and goes to sleep for 140ms

7. etc…

After implementing the sequence described above, I encountered the following problem - 

No matter when I ask the BLE to stop discovery, it takes it at least 65ms (since start of discovery) before it stops consuming high levels of power.

Attached are pictures of the oscilloscope when performing the following sequences:

Sequence 1:

1. beacon interval 150ms (yellow).

2. ble sleeps 100ms between discoveries (blue), i.e. wakes up ~50ms before the expected advertisement.

3. ble goes to sleep (enters PM2) right after receiving the advertisement.

 

in this sequence you can see that it takes a relative short time period (~10ms) for the power to drop after the ble receives the transmitted packet and stops its discovery phase.

 

Sequence 2:

1. beacon interval 150ms (yellow)

2. ble sleeps 140ms between discoveries (blue), i.e. wakes up ~10ms before the expected advertisement.

3. ble goes to sleep (enters PM2) right after receiving the advertisement.

in this sequence you can see that it takes a longer time period (~50ms) for the power to drop after the ble receives the transmitted packet and stops its discovery phase.

 

My Question:

In both sequences, the power consumption of the BLE is high for ~65ms.

I expected the power consumption to be much lower in sequence 2, since I use longer sleep periods and request discovery to stop immediately after receiving the transmitted packet from the beacon.

1. Did anyone else has encountered something familiar, and can please explain the logic behind this behavior?
2. Is there a way we can guarantee that the delay period prior to entering PM2 will always be short, as can be seen on sequence 1?

Thanks in advance,
Danny

  • 0
    TI__Guru** 106705 points
    Hi Dan,

    Have you looked at the RF traffic with a BLE sniffer? In the latter case it seems to switch to TX to ACK the package and then it stays in TX for a very long time.

    Have you tried any sleep times between 100 ms and 140 ms to see how that affects the system?

    Cheers,
    Fredrik
  • 0 in reply to Fredrik K
    Prodigy 50 points
    Hi Fredrik,

    I looked at the RF traffic using a BLE sniffer - it is consistent with what is seen in the oscilloscope.

    In both cases, the receiver listens to broadcasts of a peripheral device without a connection, so I do not think there is a reason for it to ACK the received package.
    In addition, what do you mean by 'stays in TX for a very long time'? Do you mean that the receiver (blue channel) is active for a very long time?

    I tried several values for sleep between ranges of 10[ms]-140[ms], the behavior is the same, i.e. receiver drops power level after longer period than expected.

    Unfortunately, this issue causes us a huge problem - we use x3 battery than we need in theory, since the receiver does not sleep as much as it can and therefore consumes a lot of power...

    I appreciate your efforts, hopefully we can get to the bottom of this issue and fix it.
    Since we are about to launch our product - time is of the essence.

    Thanks,
    Danny
  • 0 in reply to Dan Lazar
    TI__Guru 56590 points
    Hello Dan,
    Where in your code do you issue GAPObserverRole_CancelDiscovery?
    If you placed it under the GAP_DEVICE_INFO_EVENT case in simpleBLEObserverEventCB you must also set the following on init to actually get notification on receiving another identical packet from the same sender (same address):
    GAP_SetParamValue( TGAP_FILTER_ADV_REPORTS, FALSE);
  • 0 in reply to Eirik V
    Prodigy 50 points

    Hello Eirik,

    Thanks for your reply.

    The packets we transmit are not identical, so we do not believe that packet filtering causes our problem.

    We also did the same as you suggested and used the command:
    GAP_SetParamValue( TGAP_FILTER_ADV_REPORTS, FALSE);

    What do you think?

  • 0 in reply to Dan Lazar
    TI__Guru 56590 points

    Hello Dan,

    What would be interesting to toggle a GPIO when you hit the GAP_DEVICE_INFO_EVENT case in simpleBLEObserverEventCB and actually call GAPObserverRole_CancelDiscovery. The scan duration is the same for the two cases, both at around 60-70 ms which seems a bit odd because that would imply that you cancel the discovery process at different times (relative to start of scan).

    • Could you compare this suggested signal  with your power plot for your observer in blue?
    • What scan duration settings do you use? (GAP_SetParamValue(TGAP_GEN_DISC_SCAN, u16ScanDuration);)

  • 0
    TI__Guru 56590 points

    Hello,

    Disable the halt during RF. This will make sure the CPU is running as normal during RF operations. In this case for when the receiver is running during the discovery process. Issue the following command to disable halt of the CPU during RX:

    LL_EXT_HaltDuringRf(LL_EXT_HALT_DURING_RF_DISABLE);

    I tested this and found the same behavior. As I suggested to you, I added a signal to indicate when the GAP_DEVICE_INFO_EVENT event ran in the callback. The duration of this lasted until the scan window was complete (i.e. for as long as the radio was in active RX) before it ended indicating that the processor was not running during this time. That is why i suspected the HaltDuringRf was the cause.

    case GAP_DEVICE_INFO_EVENT:
    {
    P1_1 = 1;
    //Cancel discovery
    P1_1 = 0;
    }
    break;