Battery powered B-U585I-IOT02A

[franksacco]

I'm building a simple application that collects environmental data from sensors (pressure, temperature and humidity) using the B-U585I-IOT02A development board. Since I want to deploy the node directly on the field, I'm planning to power the board using several AA batteries through the VIN pin.

In order to estimate the battery life, I tried to measure the power consumption of the chip only using JP3, and of the entire board with a source meter in VIN.

Regarding the consumption of the chip alone, I get an average of 2 mA, a value that seems consistent with what is stated in the manual. While for the whole board, I get about 170 mA on average with a 5 V supply. Also, I notice that the ST-LINK debugger remains unnecessarily powered.

Why is the total consumption of the board so high? What can I do to reduce the consumption and have a longer battery life?

Thanks in advance.

[Andrew Neil]

---

@franksacco wrote:

 Since I want to deploy the node directly on the field,.

---

Not sure that board is intended for deploying to the field?

Perhaps look at SensorTile.box:

https://www.st.com/content/st_com/en/campaigns/sensortile_box.html

or similar?

[franksacco]

Thanks for the reply.

In my case the MCU used is not so important. However, I'm comparing several environmental sensors, so I need the LPS22HH and HTS221 sensors on the board. In addition, the sensor node is composed of the B-U585I-IOT02A board with the X-NUCLEO IKS4A1 extension attached, 3 external sensors (via I2C) and an external LoRaWAN modem (via UART).

Do you have any suggestion regarding the development board to use?

[Andrew Neil · Accepted solution]

The thing with development boards, as the name suggests, is that they're intended for use during development - not deploying to the field.

That's why they have things like ST-Link built in, which are great for development, but unnecessary - or even a disadvantage - in deployment.

If you're just looking for LoRaWAN, then I've had success with the B-L072Z-LRWAN1:

https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html

It did take some fighting to get the power consumption down:

https://community.st.com/t5/stm32-mcus-wireless/excess-current-consumption-running-b-l072z-lrwan1-from-battery/td-p/322961

For something more recent, you could try an STM32WL Nucleos:

https://www.st.com/en/evaluation-tools/nucleo-wl55jc.html

[franksacco]

I agree with you when you say that some development boards are not intended for field use. However, I am building a prototype for a university research project and we do not have the skills or time to design a custom PCB board.

I think I will proceed with the following configuration: NUCLEO-WL55JC + X-NUCLEO-IKS01A3 (embedding LPS22HH and HTS221 sensor) + X-NUCLEO-IKS4A1 + 3 external sensors (connected via I2C).

Also, since I am using Rust and the Embassy framework, the platform change will be painless: I will only have to update some pins and clock management.

Thank you for your response and suggestions.

[Guillaume K]

Note that on the B-U585I-IOT02A there is a WiFi chip (EMW3080) that may explain the power consumption.

[Guillaume K]

---

@franksacco wrote:

I think I will proceed with the following configuration: NUCLEO-WL55JC + X-NUCLEO-IKS01A3 (embedding LPS22HH and HTS221 sensor) + X-NUCLEO-IKS4A1 + 3 external sensors (connected via I2C).

Also, since I am using Rust and the Embassy framework, the platform change will be painless: I will only have to update some pins and clock management.

Hello

When you have finished to implement this new hardware configuration with Rust + Embassy, could you come back to tell us if it was indeed easy and what problems you had, if any ? Thanks