• State Verified Answer
  • Replies 2 replies
  • Subscribers 73 subscribers
  • Views 154 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 340585
Options

Quiescent current - Thingy:91X vs. Thingy:91 with BLE enabled

Achim Kraus

I measure the quiescent current of Thingy:91X (v1.0.0) with enabled BLE connectivity bridge.

To my surprise, this seems to be significant larger than that of a Thingy:91 (v1.6.0) with BLE enabled.

The used connectivity bridge for the Thingy:91X is "thingy91x_nrf53_connectivity_bridge_v2.0.1.hex".

I used a PPK II and replaced the battery with an adapter in order to measure the overall consumption when sleeping.

My values:

Thingy:91X with BLE enabled: 100µA

Thingy:91 with BLE enabled: 30µA

Is that considered to be at that 100µA? Or will that be improved towards to values of the Thingy:91 in the future?

(Just to mention, without BLE enabled, both values are pretty fine with about 25µA. So I consider, this depends on the BLE connectivity bridge.)

Parents
  • +1

    Hello,

    In short, yes, this is expected. Minimal power consumption while BLE is enabled on the interface MCU was not prioritized in the design.

    They are seeing ~100 µA total when BLE is enabled, and ~25 µA total when BLE is disabled.

    A difference of 75 µA lines up well with measured extra consumption at VBAT when the short range RF switch (U22, BGS12WN6) is turned on. according to the datasheet, that switch will pull around 100 µA from the 3.3V rail it is on.

    This switch is used to select whether the 2.4 GHz antenna is used for Wi-Fi or BLE. When BLE is enabled in the connectivity bridge, the switch is continuously powered, since the time to turn on the load switch U5, which in turn powers the RF switch, is too long (hundreds of µs) to toggle it dynamically using the BLE stack.

    The open-drain signal VDD_RF_FE_SR_EN controls the load switch. It can be asserted by both MCUs and is asserted by the connectivity bridge in the function short_range_rf_front_end_enable in src/modules/ble_handler.c, which is triggered by the BLE_CTRL_ENABLE event, which in turn is triggered when the configuration is read in src/disk/config.c.

    If minimal power consumption is needed while BLE is enabled in the connectivity bridge, software and/or hardware modifications would be needed.

Reply
  • +1

    Hello,

    In short, yes, this is expected. Minimal power consumption while BLE is enabled on the interface MCU was not prioritized in the design.

    They are seeing ~100 µA total when BLE is enabled, and ~25 µA total when BLE is disabled.

    A difference of 75 µA lines up well with measured extra consumption at VBAT when the short range RF switch (U22, BGS12WN6) is turned on. according to the datasheet, that switch will pull around 100 µA from the 3.3V rail it is on.

    This switch is used to select whether the 2.4 GHz antenna is used for Wi-Fi or BLE. When BLE is enabled in the connectivity bridge, the switch is continuously powered, since the time to turn on the load switch U5, which in turn powers the RF switch, is too long (hundreds of µs) to toggle it dynamically using the BLE stack.

    The open-drain signal VDD_RF_FE_SR_EN controls the load switch. It can be asserted by both MCUs and is asserted by the connectivity bridge in the function short_range_rf_front_end_enable in src/modules/ble_handler.c, which is triggered by the BLE_CTRL_ENABLE event, which in turn is triggered when the configuration is read in src/disk/config.c.

    If minimal power consumption is needed while BLE is enabled in the connectivity bridge, software and/or hardware modifications would be needed.

Children
Related
Terms of service