BLE unexpected power consumpption

Hey, I have a problem understanding BLE behavior

I had a product was running in BLE phy 1M, and I wanted to convert it into PHY CODED.

It just sniffs all the advertisement around and choose specific devices to get the data from using filter match.

PHY 1M 6.20 mA
PHY CODED and 1M 8.04 mA
PHY CODED 6.17 mA

I managed to successfully convert the phy 1M into coded (thanks to your great libraries it was so easy)

But using ppk2 to compare the power, I've found that the power is lower in the CODED one, and I expected the opposite. 

in the initialization i use the following struct in the BLE PHY 1M

 const struct bt_le_scan_param scan_param = {
 .type = BT_LE_SCAN_TYPE_PASSIVE,
 .options = BT_LE_SCAN_OPT_FILTER_DUPLICATE,
 .interval = BT_GAP_SCAN_FAST_INTERVAL,
 .window = BT_GAP_SCAN_FAST_WINDOW,
 };

and in the CODED BLE I used

  const struct bt_le_scan_param scan_param = {
      .type = BT_LE_SCAN_TYPE_PASSIVE,
      .options = BT_LE_SCAN_OPT_FILTER_DUPLICATE | BT_LE_SCAN_OPT_CODED | BT_LE_SCAN_OPT_NO_1M,
      .interval = BT_GAP_SCAN_FAST_INTERVAL,
      .window = BT_GAP_SCAN_FAST_WINDOW,
  };

Lastly I tried to sniff both 1M and CODED

  const struct bt_le_scan_param scan_param = {
      .type = BT_LE_SCAN_TYPE_PASSIVE,
      .options = BT_LE_SCAN_OPT_FILTER_DUPLICATE | BT_LE_SCAN_OPT_CODED,
      .interval = BT_GAP_SCAN_FAST_INTERVAL,
      .window = BT_GAP_SCAN_FAST_WINDOW,
  };
Parents
  • Hello,

    Taking these scan parameters as an example:

      const struct bt_le_scan_param scan_param = {
          .type = BT_LE_SCAN_TYPE_PASSIVE,
          .options = BT_LE_SCAN_OPT_FILTER_DUPLICATE | BT_LE_SCAN_OPT_CODED,
          .interval = BT_GAP_SCAN_FAST_INTERVAL,
          .window = BT_GAP_SCAN_FAST_WINDOW,
      };

    The length that you are scanning is BT_GAP_SCAN_FAST_WINDOW occurring every BT_GAP_SCAN_FAST_INTERVAL, so seeing that you have these in all scenarios, I wouldn't expect it to change. However, scanning, using only one PHY, and not doing much else, requires very little CPU activity (only when advertisements are being picked up, and forwarded to your application). While scanning both PHYs, I imagine it is scanning one scan window for CODED_PHY, and the next one for 1MBPS PHY. And it uses the CPU to switch between these.

    Is this the only change you did between the runs in your tests?

    If so, can you try to only mark the part where you are doing the scanning:

    What is the current consumption when you compare these? And to get a better view, try to limit the scope to only e.g. half a second. And make sure that your selection starts from the beginning of one spike orccuring periodically, until right before the next spike, so that you get an accurate estimate. This way, it is easier to see both the hight, width, and make some sense of what is going on on the chip. So really, more like this: (make sure the scope is zoomed in visually as well):

    What looks interesting is that it seems that your CODED_PHY+1MBPS looks like it has a base current around 6-9mA. It would be interresting to see what that looks like up close, compared to the other ones.

    Also, I am not sure what's going on at the end of all your traces:

    Are you entering a connection? If so, it may very well  be that the difference in average current consumption that you are seeing is more dependent on how long it takes before this occurs, rather than what's happening during the scanning in the first place.

    Theoretically, there is no significant difference in scanning using CODED_PHY or 1MBPS. While you are scanning (during the scan window) the radio is on, and the current is essentially the same, regardless of the PHY. 

    Best regards,

    Edvin

Reply
  • Hello,

    Taking these scan parameters as an example:

      const struct bt_le_scan_param scan_param = {
          .type = BT_LE_SCAN_TYPE_PASSIVE,
          .options = BT_LE_SCAN_OPT_FILTER_DUPLICATE | BT_LE_SCAN_OPT_CODED,
          .interval = BT_GAP_SCAN_FAST_INTERVAL,
          .window = BT_GAP_SCAN_FAST_WINDOW,
      };

    The length that you are scanning is BT_GAP_SCAN_FAST_WINDOW occurring every BT_GAP_SCAN_FAST_INTERVAL, so seeing that you have these in all scenarios, I wouldn't expect it to change. However, scanning, using only one PHY, and not doing much else, requires very little CPU activity (only when advertisements are being picked up, and forwarded to your application). While scanning both PHYs, I imagine it is scanning one scan window for CODED_PHY, and the next one for 1MBPS PHY. And it uses the CPU to switch between these.

    Is this the only change you did between the runs in your tests?

    If so, can you try to only mark the part where you are doing the scanning:

    What is the current consumption when you compare these? And to get a better view, try to limit the scope to only e.g. half a second. And make sure that your selection starts from the beginning of one spike orccuring periodically, until right before the next spike, so that you get an accurate estimate. This way, it is easier to see both the hight, width, and make some sense of what is going on on the chip. So really, more like this: (make sure the scope is zoomed in visually as well):

    What looks interesting is that it seems that your CODED_PHY+1MBPS looks like it has a base current around 6-9mA. It would be interresting to see what that looks like up close, compared to the other ones.

    Also, I am not sure what's going on at the end of all your traces:

    Are you entering a connection? If so, it may very well  be that the difference in average current consumption that you are seeing is more dependent on how long it takes before this occurs, rather than what's happening during the scanning in the first place.

    Theoretically, there is no significant difference in scanning using CODED_PHY or 1MBPS. While you are scanning (during the scan window) the radio is on, and the current is essentially the same, regardless of the PHY. 

    Best regards,

    Edvin

Children
No Data
Related