Need help with a data acquisition microcontroller.

[mwnafee]

Hi, everyone
So, my team is making a uterine contraction monitoring belt using Arduino. Now, the plan is to make it patient-ready. An Arduino board is not suitable for this plan. So, I need a microcontroller to acquire the data from the velostat sensor (piezoelectric).
I looked at ARM Cortex Microcontroller LPC1769 by NXP semiconductors. But I don't know if I can use MicroPython with it. So, it would be really great if you suggest me a microcontroller that can:

• be compatible with Micropython.
• acquire data from Velostat sensor at 4-20 Hz sampling rate
• be compatible for wireless transmission with nRF (or any other microcontroller you suggest)
• optional: GSM Transmission.

I'm pasting the Arduino code below and attaching a picture of our belt, so that you can get a better idea.
[code]
void setup() {
pinMode(A0, INPUT_PULLUP);
pinMode(A1, INPUT_PULLUP);
pinMode(A2, INPUT_PULLUP);
pinMode(A3, INPUT_PULLUP);
pinMode(A4, INPUT_PULLUP);
pinMode(A5, INPUT_PULLUP);

Serial.begin(9600);
}

void loop() {

float sum = 0;

float Matrix_1 = analogRead(A0);
float Matrix_1_voltage = Matrix_1*(5.0/1024.0);
float Matrix_1_pressure = 10.69*pow(Matrix_1_voltage, -1.773);

int Matrix_2 = analogRead(A1);
float Matrix_2_voltage = Matrix_2*(5.0/1024.0);
float Matrix_2_pressure = 25.09*pow(Matrix_2_voltage, -1.224);

int Matrix_3 = analogRead(A2);
float Matrix_3_voltage = Matrix_3*(5.0/1024.0);
float Matrix_3_pressure = 9.692*pow(Matrix_3_voltage, -1.691);

int Matrix_4 = analogRead(A3);
float Matrix_4_voltage = Matrix_4*(5.0/1024.0);
float Matrix_4_pressure = 10.72*pow(Matrix_4_voltage, -1.453);

int Matrix_5 = analogRead(A4);
float Matrix_5_voltage = Matrix_5*(5.0/1024.0);
float Matrix_5_pressure = 9.956*pow(Matrix_5_voltage, -1.638);

int Matrix_6 = analogRead(A5);
float Matrix_6_voltage = Matrix_6*(5.0/1024.0);
float Matrix_6_pressure = 5.562*pow(Matrix_6_voltage,-1.941);

float final_pressure=Matrix_1_pressure+Matrix_2_pressure+Matrix_3_pressure+Matrix_4_pressure+Matrix_5_pressure+Matrix_6_pressure;float f_p=Matrix_4_pressure+Matrix_5_pressure;
Serial.println(f_p);
delay(250);

}
[/code]

[SatoshisDesciple]

Hi - We are desiging a board that is much more capable than the one you mentioned above . Would you be interested in trying it out ? . We will ship you our product . Secondly , if you dont need it now , can you please suggest me any other people who might be interested in trying it out ?

[andrewleech]

What are you transmitting data to on the other end of the link?

We use stm32wb55 for a few of our medical devices with Bluetooth running on micropython, it's quite well supported.

Almost any chip in the STM32 range will likely be supported quite well.

The rp2040 / Pico / pico-w have also proven quite reliable, low cost and great if you'd like wifi access.

The mimxrt and samd ports are newer, but very actively developed. I don't have much experience with them personally though.

Esp32 family is very popular with hobbyists, but in my opinion not suitable for reliable production use as Espressif change a lot in their libraries version to version and features often get broken.

I don't know of any micropython platforms with GSM support myself, but haven't had cause to look either.

[karfas]

Esp32 family ... not suitable for reliable production use as Espressif change a lot in their libraries version to version and features often get broken.

I disagree. Any production use of whatever hardware+software will need to lockdown the used versions to those tested anyway, so upstream changes (in micropython, ESP-IDF or any of the 20 micropython submodules) don't cause any harm.
Isn't this a "best practice" development process ?

[andrewleech]

Esp32 family ... not suitable for reliable production use as Espressif change a lot in their libraries version to version and features often get broken.

I disagree. Any production use of whatever hardware+software will need to lockdown the used versions to those tested anyway, so upstream changes (in micropython, ESP-IDF or any of the 20 micropython submodules) don't cause any harm.
Isn't this a "best practice" development process ?

In our development process we keep micropython as a pinned submodule for reliable builds certainly, however we also regularly want to update that pin to a later micropython version to bring in new features.

On ports like stm I can do this with a very high level of confidence, only needing up update application code for any micropython specific changes from the update.

For personal projects I've used esp32 chips on this is often not the case, with regressions in performance and deprecated APIs often complicating the upgrade process. I also often hit intermittent kernel panic / guru meditation issues... particularly when using wild features like Bluetooth...

It's not just me either, a very high proportion of issues raised here in the last few months is reports of things not working properly on esp32xx chips after the idf 5 upgrade. Like me, others were suckered into buying new esp chips like the S6 months before even IDF could be used to compile anything for this chip, and micropython still can't run on it due to more deprecated APIs that still work on other esp chips but not the S6.
When a company ( like Espressif ) releases and sell chips months before their own software support is usable at all, it drastically reduces my trust in the brand.

[SatoshisDesciple]

Can you try our Board for the issues you have mentioned above . Please share your address and we will send our board for testing ?

…

On Tue, Dec 5, 2023 at 4:59 AM Andrew Leech ***@***.***> wrote: Esp32 family ... not suitable for reliable production use as Espressif change a lot in their libraries version to version and features often get broken. I disagree. Any production use of whatever hardware+software will need to lockdown the used versions to those tested anyway, so upstream changes (in micropython, ESP-IDF or any of the 20 micropython submodules) don't cause any harm. Isn't this a "best practice" development process ? In our development process we keep micropython as a pinned submodule for reliable builds certainly, however we also regularly want to update that pin to a later micropython version to bring in new features. On ports like stm I can do this with a very high level of confidence, only needing up update application code for any micropython specific changes from the update. For personal projects I've used esp32 chips on this is often not the case, with regressions in performance and deprecated APIs often complicating the upgrade process. I also often hit intermittent kernel panic / guru meditation issues... particularly when using wild features like Bluetooth... — Reply to this email directly, view it on GitHub <#10232 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A72T3IW3QR7SH7D6WGKWSBDYHZPVXAVCNFSM6AAAAAATAC27XSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONJYG4ZTS> . You are receiving this because you commented.Message ID: ***@***.*** com>

[2dof]

@mwnafee some suggestions about data acquisition from multiple ADC:

• first perform ADC read from multiple input, then perform any dsp processing, also

• depending on your system architecture: if your board is a just a measuring acquisition card, and you have some front-end application ( PC/server etc) then consider do all signal processing (pressure calculation on the end-side of system (you need then send 6 values of ADC register directly (also for any test application you can save all data further analysis (noise analysis , etc))).

• You didn't specify if You want do real time processing or just do batch processing, but since you plan use GSM, in my opinion batch processing/data storing is the best solution for that type of applications).

I will not suggest what type of platform (board) you should choose, but from my experience 4-20 Hz is not a problem for popular micropython based platforms, more like you should perform some technical analysis (floating point calculation support , where and what type of dsp i need ( noise filtering, value scaling/ calculation etc)

note: 5/1024 (=0.004878049) is a constant ( no need calculate every time)

[SatoshisDesciple]

Would you guys want to try our Board for the issues you have mentioned above . Please share your address and we will send our board for testing ?

[SatoshisDesciple]

Yes absolutely , we custom designed it for running MicroPython . We are making custom libraries for multiple type of sensors as well.
Below are the key specifications

[SatoshisDesciple]

USB-C Connector: Onboard for programming and power, featuring an OTG footprint for hosting external devices
Main Processor: Powered by i.MXRt1064 with a clock frequency of 600MHz.
Wireless Connectivity: Utilizing u-blox Nina-W series for Bluetooth and Wi-Fi capabilities
Camera Interface Connector: Available on the board, compatible with any Raspberry Pi camera in the market.
LVDS Connector: Facilitating external display connectivity.
SD Card Connector: Providing the option to connect external SD cards to the board

Also we are creating custom libraries for multiple types of industrial sensors . Also working for making it compatible to run edge applications as well

[robert-hh]

@SatoshisDesciple That sounds like an interesting board. If you need support in adapting the board files for MicroPython, I can assist you. I did a lot of work for the MIMXRT port. You may also be interested in PR #12937, which integrates WiFi and BLE support for the MIMXRT port based on as ESP32 module like the U-Blox-W ones, using the espressif esp-hosted firmware for the ESP32.

[SatoshisDesciple]

Hey Robert . Yes we definitely can use your help . When do we get started ?

[robert-hh]

Whenever you like after Christmas. Just contact me directly by E-Mail at [email protected].

[SatoshisDesciple]

@SatoshisDesciple That sounds like an interesting board. If you need support in adapting the board files for MicroPython, I can assist you. I did a lot of work for the MIMXRT port. You may also be interested in PR #12937, which integrates WiFi and BLE support for the MIMXRT port based on as ESP32 module like the U-Blox-W ones, using the espressif esp-hosted firmware for the ESP32.