Iterative Development Path for Low Power IoT Device - Page 1
Forum section: electronics / projects

author: davegravy
author_rank: Regular Contributor
timestamp: June 10, 2022, 03:44:10 am
content: I'm building a low-power IoT device and I'm trying to decide on an iterative development path. My goal is to achieve functionality quickly and then to work towards lower power.I'm starting with a sensor that requires a USB host. If I'm not mistaken this means I need a Single Board Computer that has an OS with USB host drivers to be able to interface with it. I'll likely use Python and this will be the first iteration.Eventually I hope to replace the USB sensor with my own sensor that has an SPI or UART interface. Although the sensor needs to remain powered constantly, the computer only needs to read from it on a 15 minute interval. With the need for a USB host eliminated, the SBC could now sleep most of the time and wake just for sensor and backend comms.The problem is I can't seem to find an SBC that anyone has hailed as being suited for sleeping and waking reliably and quickly (wake speed is critical), or that gets considerable power saving while sleeping. I'm wondering at this stage if there would be much point in trying to power-optimize an SBC. It would make more sense to move to an MCU, correct?If indeed my destiny is an MCU, is it worth considering writing my application in MicroPython from the beginning, instead of CPython, so that I might have an easier transition to an MCU?Is there an alternative path I should consider?

author: TiN
author_rank: Super Contributor
timestamp: June 10, 2022, 04:25:33 am
content: Python is in very most cases is a bad choice for anything low power. Iterating on bad choices in futile hopes to get magically good results is not a good approach in a first place.You don't need OS for running USB host either. So I'd say find a suitable MCU (that you can also buy in 2022 and not in 2032 year) with USB host/otg capability and decent documentation and start working from there, writing in C/C++. If you didn't have any experience with embedded firmware stuff, start easy with "blink a LED, send a data to USART, talk to sensor in SPI". After x months, you can try use vendor library examples for USB device/host operation, then build from there.

author: davegravy
author_rank: Regular Contributor
timestamp: June 10, 2022, 04:35:09 am
content: Quote from: TiN on June 10, 2022, 04:25:33 amAnd this includes MicroPython? I thought it was intended for constrained systems.Quote from: TiN on June 10, 2022, 04:25:33 amI'm finding the lerning gap between blinking a LED, using USART+SPI to working with USB is a big one. I was also warned that making an MCU into a USB host would be quite challenging for someone experienced let alone a beginner like me, but maybe I was mislead?FWIW I've been learning on the STM32U5 for the past 6 months.

author: davegravy
author_rank: Regular Contributor
timestamp: June 10, 2022, 11:38:40 am
content: Also I just found this which seems way lower power than any other SBCs I've come across:https://www.acmesystems.it/roadrunner

author: ajb
author_rank: Super Contributor
timestamp: June 10, 2022, 03:11:48 pm
content: What sort of sensor is it?Getting USB functionality (either side!) up and running *from scratch* will be a significant undertaking as someone new to the subject. Using an existing project as a starting point--whether this is something open source or using the MCU vendor's libraries--would be a much easier path. Be warned that a lot of vendor libraries are monstrous and can be very difficult/finicky/fragile/just plain shitty in various ways, but they can get the job done. Open source projects for USB host functionality can be...well, as good or as bad as any other open source project. It might be worth checking the likes of Adafruit or Sparkfun to see if they have decent dev boards/example projects, at least with those you are more likely to get direct or community support and good documentation.However, getting data out of the sensor may be more or less difficult depending on what sort of USB device it is. If it's not something class-compliant, you'll need to do a fair bit of work to write a driver for it, and unless the device is unusually well documented you'd need to start by reverse engineering the PC driver for it. If it *is* class-compliant then you have a decent chance of finding native support in an existing project, but you'll still need to understand what actual data is exchanged between the sensor and the host--is it just turn it on, enumerate, and start pulling data out of it, or are there some setup commands required first, etc. The sensor may use a class-compliant implementation, but may not make that obvious in how it enumerates, for example if the manufacturer provides a custom API for it on top of the class implementation.The need to keep the USB sensor running while the rest of the system is hypothetically sleeping may also be a bit of a hurdle. You would need to investigate the behavior of the USB peripheral in the MCU's sleep modes, and if it's possible to keep the sensor attached while in sleep. The host is meant to send a Start-of-Frame token every millisecond, so you will need to wake up quite frequently to do that, unless the sensor supports being disconnected and reconnected without also being power cycled. That will depend a lot on the software running in the sensor, if it only has a USB connection (as opposed to a USB connection plus a separate power connection) the developer may have assumed that a USB disconnect always comes with a power cycle.If the USB functionality in the sensor is provided by an ASIC (like a USB to UART bridge IC) then you may have some options to modify the device to allow the sensor portion to remain operational while logically disconnecting the USB connection. This sort of design is not unusual if the manufacturer offers both USB and RS232 versions of their sensors, or if they updated an RS232 version to USB, since it's just a matter of fitting a bridge IC and a few passives to add USB. And if you *do* find some naked UART Rx/Tx traces between an ASIC and the rest of the sensor, well, you now have a MUCH simpler reverse engineering situation on your hands!

author: davegravy
author_rank: Regular Contributor
timestamp: June 10, 2022, 03:41:44 pm
content: Quote from: ajb on June 10, 2022, 03:11:48 pmThanks for the insight. Yes the STM32U5 USB example project I found was enormous and intimidating but if that's really the place to start I may just have to bite the bullet.The sensor is this:https://convergenceinstruments.com/product/sound-level-meter-data-logger-with-type-1-microphone-nsrt_mk3-dev/Says it requires a platform that has a generic USB CDC driver. It exposes a VCP through which you can get summary sound level data as well as a USB Audio device for streaming raw samples. I'll need both though 99% of the time I don't need the stream. FWIW the vendor told me not to bother trying to sleep my host and expect the meter to remain powered, and I won't be able to physically modify the meter, so my expectation is that I won't be able to achieve the lowest power until I replace the meter with my own but that's a lot of added development effort I'd rather punt to Future Me.This is the dilemma. The OTS meter offloads a bunch of development effort in terms of getting something functional sooner (which I need), but is limited in terms of the power performance it can deliver even though the meter itself is low power. The application logic I need to handle the meter's output is pretty simple for a Python application but pretty complicated for an MCU (to a novice at least). I question the point of going to the trouble of implementing USB on a MCU for a sensor I want to replace in the end with my own having a friendly interface - that's effort I'll eventually discard.I could create two devices: today a higher power device with Python using this 3rd party meter and a SBC running Linux, and then later a very low-power MCU-based device with my own sensor. I was hoping there might be a decent iterative path from one to the other so I can reuse some of my effort.

author: grantb5
author_rank: Regular Contributor
timestamp: August 31, 2023, 03:12:12 pm
content: Quote from: davegravy on June 10, 2022, 03:41:44 pmA little late, but I'm also looking at the STM32U5 and STM32H5. ST has a legacy BSP on their github but I haven't looked at it yet. I believe it has some USB device peripherals. I agree the RTOS based default in STMCube is way overkill and intimidating. I'm hoping libusb_stm32 pick up this MCU because it is very lightweight and I've used it on older STM32's. You might want to also look at alternatives like TinyUSB, but to me it looks anything but tiny these days.Anyway, what did you end up using?

author: davegravy
author_rank: Regular Contributor
timestamp: August 31, 2023, 03:23:16 pm
content: Quote from: grantb5 on August 31, 2023, 03:12:12 pmI was too rushed getting to production to go the MCU route. I found an embedded linux SBC with low power relative to most SBCs and tentatively there won't be any further iterations to drop consumption. If there are, probably it'll be to replace the sensor so that I don't need USB at all, and the MCU side will be a lot simpler.I.e it will be less of an iteration and more of a from-scratch product.

author: eutectique
author_rank: Frequent Contributor
timestamp: August 31, 2023, 03:23:55 pm
content: Quote from: davegravy on June 10, 2022, 03:44:10 amWake up 10 seconds in advance.