Søger teknisk råd/looking for an expert - nano 33 ble - København/Copenhagen

International Scandinavia
1

Hey there,

I will write in English as I think more people will understand this post that way.

I have over the last month or so been taking a deep dive into the world of Arduino, I am loving it, but it is somewhat of a big world and not something that one can learn fast. My reason for entering this world so abruptly is due to the fact that I am the CTO of a small start-up here in Copenhagen, and one of my tasks is to make a prototype device with the nano 33 BLE.

I have made the device successfully and it works as intended. However, I cannot seem to properly conserve energy on the device. I have started a thread that documents some of my attempts and, I'm also sure, how little I currently know about how to solve it. Information seems so scarce on this topic and quite scattered. Seeing as I have many other tasks to undertake in my position I would be very interested in finding someone that could take a personal interest in this topic and become a technical advisor for me on this. I would happily pay you for your time.

Please let me know, here on the forum, if you are interested.

thank you for your time.

2

Hi Steen.

Interesting quest you've involved yourself in here ;). I can see you've come a long way from the details in the thread. Low power is not a usual objective with Arduino as you've found out.

I have no specific experience with the Nano 33 BLE (or much BT at all for that matter), but studying the schematic a bit with my hardware googgles on I think the designers have put up some roadblocks (putting software aside for the moment) for you regarding using the IMU to wake up the MCU from a low power state.

As you've found out, for the purpose of waking up the MCU from a sleep state the IMU needs to be able to signal an event. This is normally done by dedicated interrupt lines from peripheral to MCU, but none of the 3 interrupt lines (pins 10, 11 & 12) of the IMU sensor (U2, LSM9DS1) are connected to the MCU (U1, nRF on the NINA-B3x).
So even though the IMU contains a complex and very configurable interrupt generator (the way to tell it how much movement is enough to interrupt) I can't see any possibility for the sensor to wake up the MCU from a sleeping state when something of interest happens.
Well, IMU could theoretically interrupt MCU via SCL1/SDA1 on GPIOs P0.14/P0.15 which are able to trigger the DETECT signal, but that would require IMU support for reversing the normal slave role to master, and IMU datasheet says explicitly its interface is slave only (ch. 5.1).

To me it looks like the design of the external circuitry on the Nano 33 only leaves open the possibility for waking the MCU on proximity, light and gesture events as the only constantly powered and interrupt connected sensor is the APDS-9960.

Additionally, all other external sensors are powered directly from two GPIOs (MIC_PWR=P0.17 & VDD_ENV=P0.22) which seems a bit odd to me, but if not outside of current specification for the GPIO could be fine. However, I assume that all GPIOs will go low in the System OFF state causing them to be shut down. If that is true the IMU is never going to be functional in the Power OFF state.

Looking at the power rail associations for the peripherals it is also evident that to power the IMU you'd also be powering the HTS221 and LPS22 which is not good if on a power budget (haven't studied their actual consumption or possible low power states, links are to manufacturer's product pages):

VDD_ENV: LSM9DS1 (accelerometer, gyroscope, magnetometer), HTS221 (temperature, humidity), LPS22HB (pressure)
MIC_PWR: MP34DT06J (microphone)
3V3: APDS-9960 (light and proximity)

I think the only power conservation strategy for sensing using IMU with this hardware would be to wake up the MCU from a low power state periodically (using internal timer interrupts/RTC) and then polling the IMU to find out if it should keep sleeping. This is if course not as efficient as if the IMU was able to wake up the MCU specifically when needed, but that would require changes to the circuitry of the board.

Note that the LSM9DS1 consumes considerable power compared to sub-mA when enabled; between 1.9 and 4.3 mA according to datasheet (table 10, p. 20), so fighting the MCU to go to the 0.4 uA System OFF state might not be worth the battle.

Also note that System OFF state is very deep, essentially a prolonged reset, and will NOT retain RAM and registers and thus on wakeup requires the application program to reinitialise everything, this is not normally what you'd do unless knowing the sleep to be for longer periods and accepting a prolonged wakeup time. There are softer system sleep states available (fx. full GPIO wake capability @ 17 uA, see nRF52840 Product Specification, ch 5.2.1.1, p. 56).

I hope this is not a complete wash-off to using standard Arduino hardware. When you mention this is for prototype purposes, is this meant to go into production using Nano 33 BLE, or do you plan on making your own custom hardware spin?

I could be willing to elaborate further or peruse your requirements with respect to the Nano 33 BLE in more detail if we can find an arrangement for that. Check my CV and homepage if you need more information.

Regards,

Mikkel

3

Hi Mikkel,

Thank you so much for getting in touch. I am in the middle of some applications for funding here the next few days but I will most definitely be getting in contact with you. I have also come to the conclusion that using the IMU is out of the question and I have temporarily settled on using the built-in reset button for the prototype as it seems to work quite well for my purposes. Just wondering about how long it is stable for. Otherwise, I will need to set up an external interrupt using a button on a GPIO using the DETECT. Still not quite sure how to do that, more confident on how to solder it correctly than I am about how to, in the Arduino IDE, make a call to set up the interrupt before sleeping. All my initial tests have immediately interrupted the sleep state.

The prototype that we are making will be asleep for approximately 24 hours between uses so I assume the deeper sleep the better.

I am all ears to other ways of waking the device from 'deep sleep', even a RTC wake up would be better as we just need the batteries (cr2032) to survive for minimally 4-5 days.

Again this is just a quick post to thank you for your attention and to let you know that I will be getting in contact asap.

kind regards,

Steen