MicroPython-based Environment Monitoring with MATLAB-based Anomaly Detection — Seeking Feedback

[kritishmohapatra]

Hi everyone 👋,

I wanted to share a learning project where I combined MicroPython-based IoT data acquisition with MATLAB-based anomaly detection and analysis.

🔧 Project flow:
• MicroPython is used on the microcontroller side to read environmental sensor data
• Sensor data is streamed/logged via serial
• MATLAB is used for visualization and anomaly detection on the PC side

The aim was to explore a hybrid IoT workflow where lightweight edge devices collect data,
and more powerful tools like MATLAB handle data analytics and anomaly detection.

I documented the project focusing on:
• Clean MicroPython sensor handling
• Data consistency and formatting
• MATLAB scripts for detecting abnormal sensor behavior

I’d really appreciate feedback on:
• Best practices for streaming sensor data from MicroPython
• Whether edge-side filtering is preferred over PC-side processing
• How others approach anomaly detection in similar setups

Repo (shared for learning & discussion):
👉 https://github.com/kritishmohapatra/IoT_Environment_Monitoring_With_Anomaly_Detection

Thanks to the community 🙌

[2dof]

questions:

1. what is Your frequency sampling time for sensor?
2. Do You want perofrm processing Your data in real time or off-line (send all data and then detect abmormalities) ?

From my experience in aby fault detecion/Robust control using micropython where microcontroller act as just Data Acquisition system and PC computing/detecting just:

• in short: sent raw (ADC) data + CRC , all data conversion You can do in PC side.

In real live and practical solution You want to for example read ADC from more than 1 analog input, so then Your data frame sould have some identifier etc. Also often You want to send commands to Your DAQ (for seting parematers or just perform simulation in the loop).

I Guest You will not use Matlab for RTW solution - You will just perform data acquisition , save data to file and then perform all computing for fault detection.

In My solutions by the default i used to write solution for typical "simulation in the loop " i.e DAQ made form ESP32/RP2040 , where ussualy i got 2 Analog input, 2 analog output 2 DI and 2 DO as a base.
Data Frame was based on Modbus RTU but like in UDP manner (without). I was sending RAW ADC format data in both ways or just in one way depending form configuration.

What I reccoment:

• you should determine how much AI You need at least 2 Analog input (OR also DI input - depending what type of sensor You will testong
• Since You use matlab - first perform data acquisition/ save data ant then perform analysis

Answer for : How others approach anomaly detection in similar setups.
all depends what type of sensor do You want testing , Sampling time etc. and Your " anomaly detection approuch" for example:
a.) if you can model sensor with relativly simple tansfer function (you can identify all parameters) then you can not only detect sensor fasult but also that type of fault very simple in real time.
b.) You can use Kalman filter or other estimstors to calculate sensor parameters and looking for any deviation (similar like in a)
c.) in any fast sampling systems (like sound, detecting faults in electric engines ) ussualy Frequency/Spectral analysis is first choise.

Note:

• be aware that some Microcontrollers (like esp32) has nonlinear ADC conversion function.

[kritishmohapatra]

Thank you for the detailed and insightful response — I really appreciate you sharing your experience 🙏
It aligns very closely with the direction I’m exploring.

To answer your questions:

• Sampling time:
Currently, the sampling interval is kept relatively low-frequency (order of hundreds of milliseconds), as the initial focus is on environmental sensors (temperature, humidity, gas), not high-speed dynamics. I plan to experiment with different sampling rates as the project evolves.

• Real-time vs offline processing:
At this stage, the system follows an offline / semi-offline approach:

• MicroPython MCU acts primarily as a Data Acquisition (DAQ) node
• Raw (or lightly preprocessed) sensor data is streamed/logged via serial
• MATLAB is used on the PC side for data storage, visualization, and anomaly detection

So yes — as you correctly guessed, MATLAB is not used for RTW; it’s mainly for post-processing and analysis.

• Edge vs PC-side processing:
I completely agree with your approach — keeping the microcontroller lightweight and pushing computation to the PC side is more robust and scalable.
I’m also moving toward sending raw ADC values, and performing calibration, filtering, and anomaly logic on the PC.

Your point about:

• multiple analog inputs
• identifiable data frames
• future bidirectional communication (parameter setting, simulation-in-the-loop)

is very valuable and something I intend to incorporate next.

Regarding anomaly detection, my current focus is on:

• threshold + trend-based detection for slow-varying sensors
• later exploring estimators (Kalman-style) for parameter deviation
• frequency-domain methods only if I move to faster signals (sound, vibration, motors)

Also, thanks for the note on ESP32 ADC non-linearity — that’s an important practical detail I’ll definitely account for during calibration.

This project is primarily a learning-oriented exploration of hybrid IoT workflows (MicroPython + PC-side analytics), and your suggestions give a very clear roadmap for making it more realistic and scalable.

Thanks again — this was extremely helpful 🙌

[2dof]

I check Your code ( micopython part) and some sugestions from my side:

1. in Your code You are using wifi - so Nu need be aware that active wifi (also BT/BLE) can corrupt ADC reading (noise ) when You read smal voltage values . if You want use Wifi (or BT/BLE) then best way is to first perform series of measuremets and save to bufer then turn on communication (wifi. BT) or just ensure that all analog part is is shielded.
   for sensors withbuild in I2C there should be no problem (but always do some tests).

2. For any method : threshold + trend-based detection for slow-varying sensors - You need know input/output to measure basic characteristic - for example for Your LDR sensor input is intensity of light , output : change in voltage ( as function of resistance) .

In this case I would consider 2 methods:

• use second sensor to measure light intensity
• use controlled light source to peform ( best automatic) characteristic measurement

3. For LDR ( for practical solutions) consider using wheatstone bridge with OMP-AMP measutment configuration (You can control sensitivity and amplification) - all depends from Your sensor target application but always keep in mind that any change in temperature affect characteristic.

4. You are using DHT module as sensor - keep on mind that as a module it is DHT (physical) sensor + dedicated mcirocontroller and and build in NTC temperature sensor as a whole module is already calibrated and has already some programmed sensor fault indication. Samling time for Your DHT module should be >= 1 sec ( see datasheet)

5. You should use constant sampling time - in Your code You do all in "while" loop so no constant sampling time. For "slow" systems it shoud be no problem but for faster and dynamic measutment -> always constant sampling time ( use ISR form timer) .
   if You perform measurment of many sensor simultaneously - sampling time shoould be chosen for "slowest" sensor .

[kritishmohapatra]

Thank you very much for taking the time to review the MicroPython code in detail — I really appreciate these practical insights 🙏
Your comments highlight several real-world considerations that are extremely valuable for me.

• WiFi / ADC interference:
You’re absolutely right — WiFi/BT activity introducing noise into ADC readings is something I need to handle more carefully.
So far, I’ve observed this mainly when working with low-voltage analog sensors.
Your suggestion to buffer measurements first and enable communication afterward makes a lot of sense, and I’ll experiment with that approach.
For future iterations, I’ll also look into better analog shielding and separation.

• I²C sensors:
Agreed — digital sensors (I²C-based) are far less sensitive to RF noise, but as you said, validation testing is still essential.

• Threshold & trend-based detection:
Yes, currently the project assumes simplified sensor behavior.
I fully agree that proper anomaly detection requires understanding the input–output characteristic of each sensor (e.g., light intensity vs. LDR resistance/voltage).

Your suggestions regarding:

• using a reference sensor for light intensity
• performing controlled characteristic measurements
  are excellent and would significantly improve model accuracy.

• LDR conditioning:
The Wheatstone bridge + op-amp measurement configuration is a very good point.
I haven’t implemented analog front-end conditioning yet, but this is definitely something I want to explore as I move toward more practical and robust designs, especially considering temperature effects.

• DHT module behavior:
Thanks for pointing this out — I completely agree.
Since the DHT module includes its own internal MCU and calibration, I treat it as a high-level sensor.
I’m already respecting the ≥1 s sampling interval per the datasheet, but I’ll make this clearer and more explicit in the code and documentation.

• Sampling time consistency:
Good observation.
At the moment, the code uses a simple loop structure, which is sufficient for slow-changing environmental signals.
However, for dynamic systems I agree that constant sampling time is critical, and I plan to refactor this using timer-based interrupts or scheduled sampling to ensure deterministic timing.

Overall, my current focus is on learning-oriented, hybrid IoT workflows, but your feedback gives a very clear path toward making the system more realistic and industry-aligned.

Thanks again — this was extremely helpful and insightful 🙌