0

I've made a question previously but I did not give enough background info so here it goes:

I have been developing a prototype for measuring ground vibrations using three MEMS-accelerometers together with a raspberry pi. I've been recording and sending data that I have analyzing and now we are at the next step where we need to go battery powered. The RPI4 draws way too much power for it to work for this and thus, I'm looking for MCU-alternatives but I'm having trouble knowing which ones are powerful enough for the operation.

The sensor: 4096 samples per second, 3 x 2^20 bits of data per sample. They are SPI connected to the RPI4.

Usercase:

An engineer mounts the instrument, switches it on and the instrument calibrates and uploads a 10 second recording of "silence" to the server. It then actively listens for a trigger value to start recording. A binary recording is then sent to the server. The length of the recording is 15-20 seconds. The battery life should be as long as possible, preferably 2-3 months at least. The sensors have interrupts that triggers when the sensors hit a value so they can be in standby mode (21 μA) until triggered and enters measurement mode (200 μA). Only one sensor is active at a time so the three sensor can be seen as one. Though they do need to all be connected to the MCU. Data is sent via LTE to the server in the form of binary files.

If I left anything out please do ask, I thank you all for reading

Q: How often does the trigger event happen?

A: Depends but let's assume 10 times a day

Q: Do you need any local processing of the data, or is it just store 20 seconds and send them as is?

A: No processing, just store and send

Q: Can the sensors provide an interrupt (i.e. change the state of a pin when the threshold is met)? If yes and you have less than 1 wake-up/hour any MCU that can go to deep sleep and consume a few dozen µA in that state should do.

A: Yes, the sensor does have an interrupt pin. I have not played around with it but I imagine this is the very reasoning for its existence

4
  • 1
    How often does the trigger event happen? Do you need any local processing of the data, or is it just store 20 seconds and send them as is? Can the sensors provide an interrupt (i.e. change the state of a pin when the threshold is met)? If yes and you have less than 1 wake-up/hour any MCU that can go to deep sleep and consume a few dozen µA in that state should do. Watch out for power-hungry LEDs and LDOs on dev boards, though.
    – jcaron
    Oct 26 '21 at 10:30
  • Thanks @jcaron, I edited and answered your questions. Do you have any specific products in mind that would be up for the task?
    – nwretborn
    Oct 26 '21 at 10:54
  • Are you looking for a chip or module to integrate into your own PCB, or a ready-to-use development board at this stage?
    – jcaron
    Oct 26 '21 at 10:56
  • @jcaron I think a ready-to-use-development board would be the simplest implementation. I'm a novice without any real equipment except for a soldering iron ^^^
    – nwretborn
    Oct 26 '21 at 11:37
1

Your case is a pretty straightforward scenario where battery life will come from sleeping a lot.

Let's take a few figures. To last 3 months on a 3 000 mAh battery, you need to draw an average of less than 3000 / (3 * 30 * 24) = 1.4 mA.

If your awake cycle lasts 30 seconds (wake up, get sensor data, connect, send) and you draw an average of 100 mA during that time, and you wake up every hour, then you can draw 500 µA during sleep and still be within specs.

Most MCUs with sleep states will go down to less than 20 µA during deep sleep (sometimes a lot less).

The ever-popular ESP32 will do that easily. What you have to pay attention to, though, is that many dev boards have on-board LEDs (which you sometimes can't disable) and regulators/LDOs that are suboptimal.

Also, as you want to use a cellular modem, you need to make sure that chip as well is powered off or in a deep sleep state most of the time.

To connect your sensors, you'll need:

  • GND, Vcc, shared
  • MOSI, MISO and SCLK for SPI, shared
  • one CS pin per sensor, to pick which one you're talking to
  • either one interrupt pin per sensor if you need to know which one triggered the wake up, or just one if you don't.

That's a total of 7 or 9 data (GPIO) pins.

As you mentioned Python, a logical choice would be Pycom's GPy or FiPy (running micropython and with an LTE-M narrowband modem built-in), but there have been recurring issues with modem stability and deep sleep, I'm not sure I would recommend those at this time.

Otherwise, there are tons of ESP32 dev boards you can use with Arduino, on which you could connect an external LTE modem.

Be aware that your use case implies sending 20 * 4096 * 3 * 20 / 8 = 614 Kbytes on each cycle. With an hourly frequency that's about half a gigabyte of data per month, so it's probably not suitable for NB-IoT, and probably a border case for Cat-M1. You may need a "full" LTE modem rather than a narrowband one. Draws more power, but since it'll be off most of the time...

There's also a tradeoff to select between actually turning off the modem and reconnecting each time (which takes a little while and has an impact on battery life) and keeping the modem in a low power state with the help of PSM/eDRX, which allow the network to consider the device to be still attached even though it only wakes up occasionally.

For boards/devices without the LTE modem you can look at some of the pointers here, like the TinyPICO or Trigboard which actually care about deep sleep power. But there are probably dozens if not hundreds of other boards.

5
  • I am beyond excited by your response and expertise. I am also incredibly grateful and I thank you from the bottom of my heart for writing this lengthy response. There is one master sensor that would be in charge of waking the system so 7 pins would be sufficient. Having a board with LTE built in is preferable as the instrument in itself should be as lightweight and small as possible, glancing over the Pycom GPy it looks perfekt to spec but I am worried about the communication problem you raised. Anything in the same ball park? Also, batterypack can go upwards to 10 000 mah, maybe even above.
    – nwretborn
    Oct 26 '21 at 14:32
  • I'd also like to add something that I forgot. Seeing as the system would be in sleep mode, when a triggering vibration occurs there is 96 entries in the sensors FIFO (which is max) and the time being 96/4096 = about 23 ms. Is that really enough time to wake the system and start recording?
    – nwretborn
    Oct 26 '21 at 14:43
  • I meant to raise that issue but forgot. An ESP32 running micropython will definitely take longer that that to wake up from deep sleep. Not sure what the figures are for a lower-level (e.g. Arduino or ESP-IDF based) solution.
    – jcaron
    Oct 26 '21 at 14:48
  • If you look up "ESP32 SIM7600" you'll find offers from Lilygo, but I've never tried them. There are also Nordic-based boards and devices around the nRF9160 (e.g. the Thingy 91. But you'll probably get the widest choice if you pick you MCU and modem separately.
    – jcaron
    Oct 26 '21 at 14:57
  • Believe it or not, I actually have the nRF9160 in my desk. I'll start there I think. I hope I can get back to you if I have questions. Again, I thank you. I'm a big fan of altruism and you have given me quite the display of those principles today.
    – nwretborn
    Oct 26 '21 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.