I am using the ehswitch_eddystone project on the RSL10 (with the ZF Switch energy harvester on the BLE SWITCH001 dev kit). Where in the code can I change the PHY (data rate)? Does reducing the data rate also reduce th0e power consumption?
When I was calculating the sleep current with the RSL10 Power Consumption and Battery Estimator spreadsheet, I was wondering why the Average Sleep Current increases with a longer Advertisement Interval (ad interval 40ms = sleep current 51 nA, but ad interval 10240ms = sleep current ca. 185 nA). Why does the average sleep current increase when the advertisement interval gets longer?
I noticed that a lot of energy is consumed during the start-up of the RSL10. Is there a way to further reduce energy losses during start-up? I would like to use as much energy as possible to send data.
Thank you reaching out with your questions! Please see our responses below.
The preferred PHY Rate can be specified within the “GAPM_SET_DEV_CONFIG_CMD” of the BLE setup process, but this will only take affect if the BLE Central device asks for this preferred rate and starts the PHY negotiation.
The more reliable way to implement this functionality is executing the “GAPC_SET_PHY_CMD” stack command after the “GAPC_CONNECTON_CFM” has been sent to the Central device, and assuming the Central device is able to accept the negotiation and desired rate, the link will now be operating at the desired PHY Rate.
This is caused by capacitors on the power supply lines of the EVB. When first entering Sleep mode, the power draw is so small that the device’s remaining capacitor charge is able to run a majority of the sleep systems for a short time. Once these capacitors are drained, you will see the true steady-state sleep current over long term periods. The spreadsheet you are using will take the weighted average of the two sleep currents, which is why you will see the Sleep current approach the steady state current as you increase the Advertising Interval.
This is likely not possible as the spike in current that is observed is the re-charging of the now drained capacitors, as well as the starting if the 48MHz XTAL for BLE activity, both of which are requirements for the device to start running again.
One possible option is to use a 32kHz Sleep XTAL that has a better accuracy than the default one use by the EVB, as this will allow you to specify a tighter PPM clock error within the firmware, which will in turn allow the device to sleep for a slightly longer amount of time before waking up for BLE activity. Please note these saving would also be minimal, generally in the order of uS of extra sleep time.
Unfortunately, RSL10 does not support Extended Advertising (Variable Advertising PHY). RSL15 on the other hand does support this feature, so that may also be worth considering as an alternative if this is a hard requirement.
As for the Advertising Rate, this can be controlled by specifying the Advertising Interval used by the firmware. This value can be set in steps of 625uS to a value between 20ms and 10.24s, and on each interval you Advertising packet will be broadcast onto the 3 advertising channels used by BLE. This parameter is passed into the BLE Stack when using the “GAPM_START_ADVERTISE_CMD” command.