The first board version had provisions both for both sound-based machine learning (using an analog MEMS microphone), and motion-based machine learning (using a digital MEMS accelerometer). However, to be below the 1 USD BOM target, one would have to populate one of these options.
As I have worked a bit more on motion-type use-cases lately, I saw that there is a need for a dedicated board revision for this use-case. The main painpoint was the large size and a lack of battery.

Revision 2 board for motion

The main changes are as follows:

• Size is now 20x40mm (including USB Type A for charging), down from 26x52 mm.
• Has connector for a LIR button cell battery. LIR1220 or LIR1632 should both fit
• Has a button in addition to RGB LED, to support basic user interactions

Also fixed a couple of design issues, like there was no 3.3V regulator (I thought running off battery would be OK, but the voltage was too high for some components).

I might do a couple of more tests on the rev1 board to make sure there are no other issue. But otherwise, I think this is ready to send to production.

Human Activity Detection with accelerometer

Over the last 6 months I have worked mainly on the MicroPython support in emlearn. This is now getting into a usable shape and I am focusing on practical examples and demos. One of them is for analyzing accelerometer data for Human Activity Detection. The example can detect/classify activities such as walking/standing/lying (using standard dataset), or one can collect custom data to implement exercise classification (squats/jumpingjacks/lunges/other). This is a good starting point for our low-cost board, and we can port the feature extraction code from (MicroPython) to C. And then we can collect more data to enable specialized use cases.

Transmitting raw accelerometer data over BLE advertisements?

For training, we will need to collect raw accelerometer samples. I transmit this data over BLE, ideally at 50 Hz sample rate, but 25 Hz might also be acceptable. However, the BC7161 supports only the advertisements part of the BLE stack, and a single advertisement only has 29 bytes of payload. Which is 0.375 seconds of data at 25 Hz (3 axes, 8 bytes per sample). And only 0.180 seconds at 50 Hz. That is theoretically doable with advertisements, but it is not typical to change the advertisement data so rapidly - so we will have to see if it works in practice when connected to a phone or computer.
The backup plan is to use a cable to a computer for data collection, or to have a more powerful device piggyback via the extension headers to store or transmit the data, over a BLE connection (not just advertisements) or WiFi connection.

More RAM, same cost

The Puya PY32F003 is now available from LCSC with 8 kB RAM and 64 kB FLASH. That is double what we had previously, and it actually has the same cost (15 cents @ 3k). Specifically, I switched to the PY32F003F16U6, which is QFN-20 - so it also takes much less space than the TSSOP20 used on the previous board. The extra RAM is not critical for analyzing accelerometer data, but it will come in very handy for doing audio analysis (which was a little cramped in 4 kB RAM).

Designing a rev2 board for audio will probably come some time later though.