ModuLab: A Modular Sensor Platform for Proof-of-Concept Real-Time Environmental Monitoring

Abstract

This paper presents ModuLab, a modular, low-cost sensor platform designed to simplify real-time environmental monitoring for laboratory research and educational settings. Centered on the APP-All MCU 2023 development board with an AVR128DA48 microcontroller (Microchip Technology Inc., Taiwan) ModuLab supports plug-and-play integration of multiple sensor types—including temperature, pH, light, and humidity—using a robust I²C communication protocol. The system features configurable sampling rates, built-in signal conditioning, and a Python-based interface for real-time data visualization. As a proof-of-concept, ModuLab was operated continuously for 48 h to evaluate system stability and filtering capabilities. However, due to institutional data ownership and confidentiality policies, the underlying datasets cannot be disclosed in this submission. The architecture and implementation details described herein are intended to guide future users and research groups seeking accessible alternatives to conventional data acquisition solutions. Comprehensive performance validation and open-access data sharing are planned as the next steps in this ongoing project.

1. Introduction

1.1. Background and Motivation

Nowadays, research laboratories work in an environment which becomes more and more dynamic with each passing day, where your experimental setup is continuously evolving to address novel challenges and opportunities [1]. Recent improvements in sensor measurement technologies together with processing data has created opportunities for instrumentation tools that are not only high performance but also flexible and cost-effective [2,3]. Conventional instrumentation platforms have a fixed architecture, and inconvenient user posture must be adapted to experimental conditions [4]. To meet these challenges, a modular concept has shed light as a promising alternative, which can easily adjust to various experimental environments with very little reconfiguration [5,6]. This work is motivated by desire to provide a unified system in which researchers can add, remove, or update sensor modules, while preventing the need to reconstruct the entire setup [7,8]. Its principles of implementation are guided by a number of objectives:

The ModuLab platform emphasizes adaptability, allowing rapid integration of new sensor types and data channels to suit varied experimental needs. Its cost-efficiency stems from the use of readily available, off-the-shelf components, reducing procurement time and expenses. Designed for user-friendliness, it simplifies system setup so that researchers can focus on scientific inquiry rather than complex technical integration.

Our system remedies the inflexible nature of the traditional systems without standard connection interfaces and centralization of data collection; meanwhile, future improvements are enabled. The modular design is very important in interdisciplinary research environment [9] since the quick configuration of experiments may allow for the discovery of new effects and increasing of productivity [10]. In general, our method aims to transfer from high performance instrumentation into realistic, budget-oriented research settings.

1.2. Challenges in Traditional Instrumentation Systems

It is shown that traditional instrumentation systems suffer from a self-limiting inflexibility and intricate integration complexities [11]. A lot of these systems are dependent on specialized hardware with a limited number of interfaces, which takes a lot of time for setup and calibration [12]. Scientists often have to deal with numerous proprietary protocols and non-standardized connectors, which not only causes interoperability problems, but also raises maintenance overheads [13,14]. Furthermore, since most setups are built with rigid components, adding more sensors to an existing system usually requires breakthrough redesign or a redesign of the overall instrumentation package [15,16]. These limitations are critical, especially in dynamic laboratory environments, where experimental conditions and measurement settings are not constant [17]. These problems impede experimental workflows and the possibility for rapid prototyping [18]. Solving these challenging problems is key to progress in flexible lab instrumentation, and our work focuses on a flexible system that addresses these limitations with a substantially more compossible modular design [19,20,21].

1.3. Modular Plug-and-Play Paradigm

The modular plug-and-play paradigm [22] offers a robust solution to the challenges presented by conventional instrumentation systems. This approach is centered on the design of standardized interfaces that allow individual sensor modules to be easily connected or disconnected without the need for extensive reconfiguration [23]. A major advantage of this paradigm is the reduction in system complexity; by relying on off-the-shelf components and uniform communication protocols, the integration process becomes straightforward and less prone to errors [24]. The modular design supports scalability, meaning that the system can be expanded or upgraded as new technologies emerge. Key features of this approach include the following:

Standardized interfaces and uniform communication protocols ensure broad compatibility with a wide range of devices. The platform’s straightforward assembly and disassembly processes reduce setup time and lower technical barriers, enabling seamless adoption by non-specialist users. Its architecture supports future-proofing, allowing new sensor technologies to be incorporated without major hardware overhauls.

This paradigm not only streamlines the integration of diverse sensor modules but also provides a cost-effective solution that enhances experimental efficiency. By minimizing wiring complexity and reducing manual configuration, the plug-and-play approach facilitates rapid prototyping and iterative experimentation. It allows researchers to focus on experimental outcomes rather than technical challenges, ultimately leading to more efficient and reliable data acquisition processes.

1.4. Leveraging the APP-All MCU 2023 Development Board

At the core of our proposed system lies the Microchip Technology’s APP-All MCU 2023 development board [25], which serves as the central hub for sensor integration and data management. This development board was selected for its versatility, robust performance, and comprehensive support for multiple communication protocols, such as USB, I²C, and SPI. Its flexible architecture enables it to interface seamlessly with a wide range of sensor modules, ensuring high precision and rapid data processing. The APP-All MCU 2023 is designed for quick prototyping and customization, which allows for software configurations tailored to specific experimental needs. Advantages of incorporating this board include the following:

• Robust Performance: Reliable processing power that supports high-precision data acquisition.
• Versatility: Compatibility with various sensors and communication interfaces [26].
• Scalability: The ability to expand the system easily [27] as new experimental requirements emerge.
• Cost-effectiveness: Utilizing an off-the-shelf solution that balances performance with affordability [28].

Integrating the APP-All MCU 2023 into our modular system enables a harmonized approach to data acquisition and sensor management. This board’s programmable nature permits rapid adjustments in response to evolving research needs. It also ensures that the system remains adaptable and scalable, allowing for seamless integration of future innovations. By capitalizing on the strengths of this development board, our design offers a compelling balance between technical performance and economic viability, thereby fostering more agile and efficient laboratory workflows.

1.5. Scope and Organization of This Work

This paper describes an in-depth study of a laboratory instrumentation system based on the plug-and-play model. Development, implementation, and testing of a prototype that combines sensor modules in the APP-All MCU 2023 development board is emphasized. This contribution tries to overcome the limitations of current approaches by introducing a more flexible, adaptable, and cheaper framework. We describe the hardware architecture and software frameworks on which the presented system is based in the remaining part of this paper. Particular focus is directed to the impact of standardized interfaces and modular components on integration complexity and time-to-deployment. This paper also discusses the experiments carried out to evaluate the system performance in realistic laboratory conditions including reliability, scalability and operation performance. We systematically compare our method to conventional instruments and emphasize the benefits of flexibility and cost reduction. This all-encompassing evaluation not only validates the design decisions taken but also paves the way for improvement. Our ultimate goal is to establish a robust infrastructure that will be the foundation for the design and implementation of next-generation laboratory instrumentation that will better support the new paradigms of research and innovation in new experimental methods.

2. Materials and Methods

2.1. Hardware Components and System Architecture

The core of our hardware is based on the Microchip Technology’s APP-All MCU 2023 development board, which is used in a real laboratory environment during our experiments. The board integrates a number of environmental sensors (pH, light, temperature and humidity sensors), which are connected to it using I²C. This communication protocol was chosen due to its robustness and apparent ease of use in order to ensure that the data coming from the different sensors are synchronized and processable at the same time. The hardware implementation consists of dedicated sensor conditioning circuits that process the raw analog signals to digital data before they are sent to the MCU. Further, a power management unit (PMU) and signal-buffering circuits are incorporated into the circuit to assure stability and precision in continuous working. Our design focuses on modularity by adopting standardized connectors and interface protocols, which facilitate easy replacement or derivation of sensor modules as experiments vary. The major hardware features are as follows:

The system achieves robust multi-sensor integration through the I²C interface, enabling synchronized measurements across multiple channels. Dedicated signal conditioning circuits enhance measurement precision, while the scalable design supports the addition of new sensors. Stable power and signal management ensure consistent, accurate, and reliable data acquisition in extended operational periods.

Based on the fact of hardware device implementing the specifications, it meets well the demands of collecting the real-time data from the laboratory of dynamic experiments, and is favorable for debugging and maintenance, because of the modularized design.

2.2. Comparison Between APP-All MCU 2023, Arduino Uno, and Recent Open-Source Solutions

Table 1. Comparison of ModuLab (APP-All MCU 2023), Arduino Uno, and Kondaveeti’s work [29] Open-Source DAQ system.

Specification	APP-All MCU 2023 (ModuLab)	Arduino Uno	Kondaveeti et al. (2021)
MCU Core	AVR128DA48 (8-bit, 24 MHz)	ATmega328P (8-bit, 16 MHz)	ATmega2560/328P (8-bit, 16 MHz)
Flash Memory	128 KB	32 KB	256 KB (Mega)/32 KB (Uno)
SRAM	16 KB	2 KB	8 KB (Mega)/2 KB (Uno)
ADC Resolution	12-bit	10-bit	10-bit
Analog Channels	Up to 58 GPIO/analog pins	6 analog inputs	16 (Mega)/6 (Uno)
Sampling Rate	up to 128 Hz (configurable)	10 Hz (practical 1)	1–10 Hz (as reported)
Sensor Modularity	mikroBUS, Arduino header, plug-and-play	Arduino header only	Breadboard/wire-based modularity
Data Visualization	Python Bokeh, real-time interactive plots	Requires custom PC code	Basic web/serial logging
Open-Source Support	Yes	Yes	Yes
Cost (USD)	∼76 (complete)	∼30–40	∼50–80
Main Application	Modular lab monitoring, education, scalable prototyping	Education, basic DIY projects	Bioreactor monitoring, environmental monitoring

¹ 10 Hz under the current visualization pipeline, not the hardware ceiling.

summarizes key differences between the APP-All MCU 2023 platform (based on AVR128DA48), the Arduino Uno (ATmega328P), and a recent open-source low-cost data acquisition system for laboratory-scale bioreactors developed by Kondaveeti et al. [29]. While the Arduino Uno is widely used for educational purposes, it is often limited by its memory, I/O capabilities, and expandability. The APP-All MCU 2023 overcomes these constraints, offering higher memory, more advanced analog features, and a broader voltage range.

Importantly, Kondaveeti et al.’s system provides a practical reference for integrating low-cost hardware into laboratory settings. Their solution, which relies on Arduino-based hardware, focuses on modular sensor input for bioreactor monitoring and basic real-time data logging. In contrast, ModuLab leverages a more powerful microcontroller, adds plug-and-play sensor support, enables higher sampling rates, and features a robust Python 3.12-based visualization suite, positioning it as a scalable and extensible alternative for a broader range of applications. The following table highlights these differences:

Compared to both Arduino Uno and the Kondaveeti et al. system, ModuLab offers significantly higher memory, advanced ADC resolution, and plug-and-play modularity, with integrated software for real-time data analysis. These features extend its utility to a wider array of laboratory and educational environments, promoting adoption beyond single-purpose, ad hoc data loggers.

Unlike wearable sensor systems that emphasize flexibility and wireless data transmission, such as those reviewed by Hussain et al. [30], ModuLab is built to function as a modular, laboratory-capable platform. Hussain et al. categorize flexible respiration sensors based on operational frequency—highlighting high-frequency (e.g., antenna, RFID/NFC sensors) and low-frequency (e.g., capacitive and strain-based sensors) solutions designed for remote physiological monitoring. In contrast, ModuLab prioritizes a plug-and-play architecture using wired I²C communication, robust real-time data visualization, and ease of integration into laboratory workflows—making it especially suited for non-computer-science research environments seeking affordable and expandable environmental sensing solutions.

2.3. Software Implementation and Real-Time Data Acquisition

The software infrastructure is designed to complement the flexible hardware architecture, ensuring efficient, real-time data acquisition and visualization. Custom firmware, written in C/C++, runs on the APP-All MCU 2023 development board and is responsible for managing the I²C communication with the pH, light, temperature, and humidity sensors. Data captured by these sensors are transmitted to an external host computer where they are processed and logged in real time. On the host side, we leverage Python’s Bokeh library to create intuitive, interactive plots that provide immediate visual feedback on environmental conditions. The use of Bokeh allows for dynamic updating of plots, enabling users to monitor sensor outputs continuously and to quickly identify any deviations or anomalies. The software also helps in practice: it logs in detail and makes debugging easier when something goes wrong; all sensor data streams can be easily grepped for troubleshooting, ensuring that any issues in the data acquisition chain are promptly identified and resolved. The integration of these software components creates a robust, real-time monitoring system that is both user-friendly and adaptable, supporting rapid prototyping and iterative experimentation in a live lab environment.

2.4. I²C Bus Robustness

The I²C bus operated at 400 kHz using 4.7 kΩ  pull-ups on SDA/SCL, consistent with a measured bus capacitance of  120 pF. Each slave (BME280 at 0x76, VEML7700 at 0x10, pH module at 0x4D) was assigned a unique address. In the event of NACK or clock-stretch events exceeding 30 ms, the MCU initiated a retry (up to three times) and logged the error. Recovery from disconnects was handled by re-initializing the affected device on the next cycle.

2.5. Experimental Protocol and Debugging Strategies

Our experimental procedure was well-thought-out to demonstrate not only the performance but also the operational integrity of the modular system for practical application in a laboratory setting. Hands-on testing was performed by putting the sensors into a laboratory environment with varying levels of pH, light intensity, temperature, humidity, etc. Before the collection of data, each of the sensors was calibrated to maintain its precision and unity. The sensors fed the APP-All MCU 2023 with environmental information throughout the experiment through the I²C, and the data were transmitted to a computer to achieve real-time processing. Each sensor was calibrated against known standards to reduce error margins, ensuring reliable measurement accuracy. Real-time monitoring was achieved using a Bokeh-based visualization system, providing instantaneous graphical feedback for rapid detection of anomalies. Comprehensive data logging facilitated the extraction and analysis of sensor readings, enabling swift identification of communication or processing issues. The modular architecture of both hardware and software allowed for isolated testing of individual components, significantly streamlining the troubleshooting process.

These strategies allowed the system to maintain high fidelity in data acquisition and processing while also making for quick iterative improvements. The experimental procedure reported in this paper proves that our system is not only suitable for real-time monitoring and actuation, but is robust against possible drawbacks, it thus constitutes a sound platform for complex experimental apparatus.

2.6. Frame Integrity and CRC16 Specification

To ensure robust data integrity across transfers, each frame generated by the ModuLab system appends a 16-bit cyclic redundancy check (CRC16) value. The implementation follows the widely adopted CRC-16/CCITT-FALSE standard with the following parameters:

• Polynomial: $x^{16}+x^{12}+x^5+1$ (0x1021 in hexadecimal).
• Initial Seed: 0xFFFF.
• Final XOR Value: 0x0000.
• Input Reflection: Disabled (no reflection of input bytes).
• Output Reflection: Disabled.
• Byte Order: The CRC field is transmitted in big-endian format (most significant byte first).

The CRC16 is computed over the entire payload, starting from the fixed two-byte frame header up to and including the status field, but excluding the CRC field itself. Frames failing CRC validation are flagged and excluded from downstream logging and visualization pipelines. In our 48 h continuous run, the exclusion rate stabilized at 0.05%, providing consistent assurance of error detection and reliable communication across the I²C and USB–UART links.

2.7. System Integration and Calibration Procedures

Attaching the sensor package to the entire system systemized the development process, making certain that the hardware and software cooperated with each other. At first, each sensor module (pH, light, temperature, and humidity) was plugged in separately on custom design interface boards to facilitate secure connections and to be connected to the APP-All MCU 2023 through I²C. Precautions were taken in order to protect sensitive areas from electromagnetic interferences through applying proper grounding and signal buffering circuits. The integration was performed in multiple steps: initially, the secure mechanical connection using standardized connectors, followed-up by electrical checks of the interfaces’ characteristics and the integrity of the communication protocols, respectively. Calibration schemes were subsequently applied in the presence of controlled reference backgrounds. For example, the pH sensor was calibrated using standard buffer solutions with a known pH, and the temperature and Humidity sensors were cross calibrated with certified instruments in controlled lab environment with the sample rate 32 Hz (as programmed in the AVR chip), with each sensor sampled in a round-robin loop. The calibration procedures also consisted of the following steps: The calibration workflow began with recording baseline sensor outputs under stable environmental conditions. These outputs were then compared to known reference standards, and discrepancies were used to adjust the sensor readings. The process was repeated iteratively until the outputs stabilized within acceptable error margins, ensuring consistency and accuracy. This systematic soft integration and calibration scheme made each slave available to give precise and uniform data, thus enabling robust follow-up real-time monitoring and diagnosis.

The pH module was calibrated with three standard buffers (pH 4.00, 7.00, 10.00). For calibration, a linear regression function (Nernst equation) was used:

$$E=E^0+S·(pH-p{H}_{ref}),$$

where E is the electrode potential, S the slope (mV/pH), and $E^0$ the intercept. Temperature compensation was applied using concurrent BME280 readings. Typical slopes converged to $-58.5\pm 0.5$ mV/pH at 25 °C. For BME280 and VEML7700, factory calibration coefficients were validated against certified thermometers and lux meters, with errors within ±0.2 °C and ±2.5% lux, respectively. Drift analysis will be addressed in future prospect manuscripts.

2.8. Data Analysis, Post-Processing, and Visualization

The data acquired from the sensor network undergoes extensive post-processing to transform raw measurements into actionable insights. Once transmitted from the APP-All MCU 2023 to the host computer, the data are first subjected to preprocessing routines that involve noise filtering, data smoothing, and outlier detection. Using Python, these routines leverage standard libraries for signal processing, ensuring that the sensor outputs are both reliable and interpretable. The preprocessed data are then analyzed using statistical techniques to determine trends and correlations among environmental parameters. For visualization, the Bokeh library is employed to generate interactive, real-time plots that update dynamically as new data are received. This visualization framework not only presents the current state of the laboratory environment but also allows users to: The visualization system offered the ability to zoom into specific time intervals for in-depth analysis, enhancing the understanding of short-term variations. Historical data could be overlaid to reveal long-term trends, supporting pattern recognition and predictive insights. Additionally, customizable alerts were configured to trigger when sensor readings exceeded predefined thresholds, ensuring prompt responses to critical changes. Furthermore, automated scripts enable batch processing of logged data for comprehensive post-experiment analyses, including regression analysis and anomaly detection. These tools facilitate a deeper understanding of the sensor behavior and overall system performance. The detailed data analysis and visualization pipeline ensure that any deviations are promptly identified and addressed, thereby enhancing the reliability and effectiveness of the experimental system.

The ModuLab system is programmed to sample at 128 Hz, with an alternative selectable rate of 32 Hz depending on application requirements. Data processing involves a moving average filter with a window size of five samples (approx. 40 ms at 128 Hz) to smooth high-frequency noise.

2.9. System Integration and Configuration Overview

Figure 1 presents an in-depth view of the configuration interface within the Microchip development framework. This section details how the hardware components are managed and interconnected using Microchip’s tools, providing a clear mapping of sensor modules, firmware settings, and peripheral pin assignments. The interface displayed in the figure exemplifies the streamlined process for assigning functionalities, ensuring efficient integration of sensors (such as temperature, humidity, pH, and light) with the central control unit. This visual overview is integral to understanding the systematic approach employed for achieving a low-cost, yet high-accuracy, plug-and-play laboratory setup.

2.10. System Flow and Timing Coherence

Table 2. End-to-end timeline of the ModuLab acquisition pipeline. Compact representation of stage function, timing, payload, and integrity.

Stage	Function	Timing	Payload	Integrity/Notes
Sensors (BME280, VEML7700, pH) [31,32]	Raw measurement (T/H/P, lux, pH) with on-sensor/AFE conditioning	128 Hz (BME280), 32 Hz (VEML7700, pH); local averaging (16×/3×)	2–4 B per channel per sample	Factory calibration constants (BME280); pH AFE high-Z input
I2C Bus @ 400 kHz	Register reads/writes from MCU TWI host	Scheduled per 100 ms cycle; bus slots < 1% utilization	∼24–32 B per frame (all channels)	Retry on NACK; bus watchdog; fixed slave addresses
MCU main loop [33]	Timestamp, validate, decimate to 10 Hz, frame assembly	100 ms cycle (interrupt-driven); jitter < 5 ms	∼32 B per channel per 100 ms	CRC16 appended; error flags on bounds/timeout
USB–UART Bridge (MCP2221A @115200) [34]	Packetize and stream frames to host	10 Hz effective output (all channels)	∼32 B/ch; ∼100–150 B total/frame	Link load < 2%; OS virtual COM, no drops in nominal load
Host Parser	Read, verify CRC, log CSV, queue to visualizer	Service interval ≈ 100 ms	CSV rows (timestamp + fields)	p50/p95 latency ∼70/95 ms end-to-end
Python Visualization (Bokeh) [35]	Update plots; threshold alerts	10 Hz refresh; sub-second UI response	N/A	Back-pressure tolerant (drops frames, not samples)

Explanation. Sensors acquire at their native rates (BME280 128 Hz; VEML7700/pH 32 Hz) with local averaging; the MCU schedules I²C reads within a 100 ms control cycle, assembles CRC16-protected frames, and emits a consolidated 10 Hz stream via USB–UART. The host verifies integrity, logs CSV, and refreshes the visualization at 10 Hz. Median end-to-end latency is ∼70 ms (95th percentile ∼95 ms), with I²C utilization $<1\%$ at 400 kHz and serial link load $<2\%$ at 115,200 baud. This tabular timeline replaces a graphical diagram while preserving the requested timing coherence and throughput detail.

provides a sequential view of the ModuLab data path with consolidated timing, payload, and integrity details. This resolves the previously noted ambiguity between raw sampling, decimation, and host-side update rates without relying on a schematic figure.

2.11. Test Conditions and Measurement Protocol

The aggregate metrics reported (mean/p95 latency, jitter, FER, RMS noise) were derived from a 48 h run with $N=1,728,000$ samples.

Table 3. Test conditions for ModuLab performance evaluation.

Parameter	Value/Condition
I2C bus speed	400 kHz, 10 cm ribbon cable
USB-UART bridge	MCP2221A at 115,200 baud
PC/OS	Intel i5-11400, Windows 11 Pro, 16 GB RAM
CPU load during test	12% (Python/Bokeh running)
Sample size	1.728M frames (48 h run)
Exclusion rule	CRC-failed frames (0.05%) removed

summarizes the setup. Analysis excluded frames with corrupted CRC values (0.05%).

2.12. Reproducibility Materials: Synthetic Dataset and Minimal Parser

We tried to provide detail in implementation on both of the CSV structure arrangement and the C programming language structure for the reference.

2.12.1. Synthetic CSV Schema

• t_unix_ms (int64): UNIX epoch time in milliseconds
• temp_C (float32), humid_% (float32), press_hPa (float32)
• lux (int16), pH (float32)
• crc_ok (bool)

2.12.2. Minimal C++ Example (Firmware-Side Framing/Logging)

 int main(void) {
     SYSTEM_Initialize();
     RTC_SetOVFIsrCallback(RTC_OVF_Callback);
     WeatherStation_initialize();
     ph2_calibrate();
	  
     // Configure VEML7700 (example)
     uint8_t W[3] = {0x00, 0x00, 0x18};
     I2C0_Host.Write(VEML7700_ADDR, W, 3);
     while (I2C0_Host.IsBusy());
      
     while (1) {
         if (bRTCOverflow) {
             bRTCOverflow = 0;
			  
             WeatherClick_readSensors();
             float tC  = BME280_getTemperature();
             float pHP = BME280_getPressure();
             float hR  = BME280_getHumidity();
              
             // Read VEML7700 result register (2 bytes)
             uint8_t reg = 0x04, R[2] = {0};
             I2C0_Host.WriteRead(VEML7700_ADDR, &reg, 1, R, 2);
             while (I2C0_Host.IsBusy());
             int lux = ((int)R[1] << 8) | R[0];
             lux /= 4;
              
             float ph = 0.0f;
             ph2_calculate_ph(&ph);
			  
             // CSV frame: t_ms, temp_C, humid_%, press_hPa, pH, lux
             printf("%lld,%.2f,%.2f,%.2f,%.2f,%d\n",
                    (long long)millis(), tC, hR, pHP, ph, lux);
         }
     }
 }

2.12.3. Minimal Python Parser (COM Port to CSV)

Providing the structure of the Python script demonstrating how the data been streamed into the host, then to the visualization.

def main():
    ser = serial.Serial(PORT, BAUD, timeout=0.1)
    print(f"Opened {PORT} @ {BAUD}. Logging to {OUT}")
    with open(OUT, "w", newline="") as f:
        w = csv.DictWriter(f, fieldnames=["ts_ms","temp","hum",
            "press","ph","lux","status","ver"])
        w.writeheader()
        buf = b""
        while True:
            chunk = ser.read(256)
            if not chunk:
                continue
            buf += chunk
             
            # Try to find binary frames
            while True:
                idx = buf.find(HDR)
                if idx < 0:
                    # No header: try ASCII fallback on full lines
                    if b"\n" in buf:
                        line, buf = buf.split(b"\n", 1)
                        rec = try_ascii_line(line)
                        if rec:
                            w.writerow(rec); f.flush()
                    break
                if len(buf) - idx < FRAME_LEN:
                    # Wait for more data
                    buf = buf[idx:]
                    break
                frame = buf[idx:idx+FRAME_LEN]
                buf = buf[idx+FRAME_LEN:]
                rec = parse_binary_frame(frame)
                if rec:
                    w.writerow(rec); f.flush()

3. Results

Before delving into the specific implementation details, we present a high-level overview of our experimental workflow and hardware connections as shown in Figure 2. This flow chart illustrates how sensor data, collected by the AVR128DA48 microcontroller on the Microchip Technology’s APP-All MCU 2023 development board, is routed through the I²C bus, processed by the onboard firmware, and ultimately transmitted to the host computer for real-time visualization and analysis. Each of the following subsections describes one or more key stages in this flow, from firmware-level data handling to the Python-based monitoring system. Please refer to the Pseudocode below (Algorithm 1).

Algorithm 1 ModuLab Real-Time Data Acquisition and Processing Routine

1: Initialize MCU and configure I2C communication   2: Initialize onboard sensors: temperature, pH, light intensity, humidity   3: Initialize USB bridge interface (MCP2221A)   4: Initialize tri-color LED indicators for system feedback   5: while The system is powered on do   6:       Read data from all sensors via I2C bus   7:       if sensor data are valid then   8:             Calibrate raw sensor readings using internal reference values   9:             Filter data using a moving average to suppress high-frequency noise 10:             Package calibrated data into a structured frame 11:             Transmit data to host computer via USB (MCP2221A) 12:             Update tri-color LEDs based on current system status 13:       else 14:             Log sensor communication issue and set error flag 15:       end if 16:       Wait for next sampling interval (e.g., 100 ms) 17: end while

3.1. Microchip APP-All MCU 2023 Code Implementation and Sensor Data Acquisition

This subsection focuses on the planning and execution of the firmware that runs on the Microchip Technology’s APP-All MCU 2023 development board, specifically, on the embedded AVR128DA48 microcontroller. The firmware is developed in C/C++ and is structured around a main control loop with interrupt-driven routines for sensor data capture. All sensors—pH, light, temperature, and humidity—communicate via the I²C protocol, simplifying wiring and minimizing potential signal conflicts. Figure 2 highlights the firmware flow, starting with sensor initialization, followed by periodic data sampling at user-defined intervals. A built-in calibration routine adjusts sensor readings based on predefined offsets or slope values to account for drift and manufacturing tolerances. Once the microcontroller gathers stable readings, it packages these values for transmission via the board’s serial interface. Error-checking mechanisms, such as CRC checks or simple CHECKSUM, are implemented to detect corrupted data frames. In the event of a sensor or communication failure, diagnostic flags are set, and the system logs the event for post-experiment debugging. This layered approach ensures high data fidelity and supports the rapid prototyping needs typical in dynamic laboratory settings. Sensor speed and sampling rates are listed below:

• Sampling interval: 100 ms per loop.
• Max rate: 10 Hz total system throughput, evenly multiplexed across each sensors.
• Sensor response: BME280 and VEML7700 update internally at 1–5 Hz, buffered in firmware.

3.2. Python Real-Time Data Acquisition, Visualization, and Debugging

After the sensor data are packaged by the microcontroller, they are forwarded to a host computer for further analysis and display. In this subsection, we detail the planning behind the Python-based software stack, which leverages the Bokeh library for real-time visualization (in Figure 3). A dedicated Python module handles serial communication with the APP-All MCU 2023, parsing the incoming data packets and applying filtering or smoothing algorithms where needed. The processed data are then fed into interactive plots that update dynamically, providing lab administrators with immediate insight into environmental parameters such as pH, light intensity, temperature, and humidity. The real-time aspect is particularly valuable for catching anomalies or abrupt changes in experimental conditions. Additionally, the software includes a robust logging mechanism, allowing users to “grep” through historical data files to diagnose anomalies or sensor misbehavior. This modular design ensures that each component—data parsing, filtering, visualization—can be refined independently, thereby promoting maintainability and extensibility for future enhancements, such as automated alerts or cloud-based data storage. Data transmission speed and storage/sampling time are listed below:

• Transmission: USB CDC via MCP2221A [34], baud equivalent 115,200;
• Data are parsed in Python every 100 ms (10 Hz);
• Each record is logged locally (CSV format) in real time; no data are stored on the MCU. We are also working on adding time-stamped buffer management in future updates.

3.3. Host Interface—MCP2221A for UART and I²C Full LED Indicator

A critical component of our design is the MCP2221A interface, which facilitates seamless communication between the microcontroller and the host computer via both UART and I²C. As shown in the schematic snippet (Figure 4), the MCP2221A is connected to the AVR128DA48 on the APP-All MCU 2023 board through dedicated signal lines. This interface provides the following:

• USB-to-Serial Conversion: Enabling a straightforward bridge from the microcontroller’s UART to a USB COM port on the host PC.
• I²C Pass-Through: Allowing direct I²C transactions for diagnostic or configuration tasks.
• Full LED Indicator: Providing real-time feedback on data transmission, power status, and I²C activity.

In the highlighted P20 jumper block (dashed yellow bracket in Figure 4), users can select whether signals are routed to the mikroBUS connector or the Arduino-style header, granting flexibility for various expansion modules. When configured for UART communication, the AVR128DA48 bundles sensor readings into a serial data frame, which the MCP2221A then translates into USB packets recognizable by the operating system as a virtual COM port. On the host side, any standard serial terminal or Python-based script can open this COM port to read sensor data in real time. By providing a user-friendly interface layer, the MCP2221A significantly reduces the complexity of bridging between embedded hardware and PC-based data analysis, ensuring that the collected sensor data flow smoothly from the microcontroller to the host software environment.

In summary, the MCP2221A host interface not only offers a reliable, high-speed link between the microcontroller and the host PC, but also provides additional diagnostic capabilities through LED status indicators. This design choice simplifies troubleshooting, enabling researchers to quickly verify active data transfer or identify communication bottlenecks. By supporting both UART and I²C, the MCP2221A ensures maximum flexibility for future expansions or specialized sensor requirements, further solidifying the system’s modular and adaptable nature.

3.4. Final Device Setup and Sensor Configuration

We prototyped the full workflow in an all-in-one, integrated prototype for validation in a real-world lab environment. As depicted in Figure 5, the system is built around the Microchip AVR128DA48 MCU located on the APP-All MCU 2023 board, and it communicates with various sensors on a common I²C bus. More precisely, we used a BME280 sensor to detect temperature, humidity, and pressure, a VEML7700 sensor to capture ambient light intensity, and a specially designed pH sensor module (commonly identified as “pH2” over the mikroBUS interface) for immediate pH values. The pH probe can be connected to a BNC connector, which is commonly used for cables and meters, to simplify the handling and maintenance of the probe. For this final arrangement, the sensors are connected to their corresponding interface- or mikroBUS board, and their outputs are connected to I²C pins of the AVR128DA48 microcontroller.

It is driven by a regulable supply to which are connected onboard conditioning circuits that maintain a constant tension which is equal for all sensor modules. The sensor data are then streamed through the MCP2221A interface, which interfaces the microcontroller’s UART signals to the USB-COM port of the host computer. The Python-built service consumes these values with Bokeh—a library for advanced data visualization to support real-time readings and quick identification of anomalies. This complete sensor suite can be utilized in many different applications, including those covering temperature, humidity, pressure, light intensity, and pH. Additionally, modularity and standard connectors enable rapid replacement of 8-MX sensors or system reconfigurations to match the continuing research needs with minimal system down time. The list of the manufacturers is as follows:

• BME280 (Bosch via SparkFun breakout);
• VEML7700 (Adafruit);
• pH Sensor (DFRobot pH2 with BNC connector via mikroBUS board).

3.5. pH Analog Front-End and Validation

Analog front-end. The pH electrode is buffered by a high-impedance input stage (>${10}^{12}\mathrm{\Omega }$) with an anti-alias RC filter ($f_c\approx 10$ Hz), digitized by a 12-bit ADC (2.048 V reference). The effective ENOB is estimated at 10.7 bits under operating conditions.

Calibration procedure. A three-point calibration was performed with certified buffers (pH 4.00, 7.00, 10.00 at 25 °C). A linear model derived from the Nernst relation was fitted:

$$E=E^0+S·(pH-7.00),S\approx -59.16\mathrm{mV}/\mathrm{pH}\mathrm{at}{25 }^{\circ }\mathrm{C},$$

with temperature compensation applied using concurrent BME280 readings. Acceptance criteria were $\left|S\right|\in [57.5,60.0]$ mV/pH and $R^2\ge 0.995$.

Repeatability and drift. Repeatability was assessed by three consecutive calibration runs; drift was checked by measuring pH 7.00 before/after a 48 h run (

Table 4. pH calibration summary (example run at 25 °C).

Run	Slope S (mV/pH)	Intercept ${\mathit{E}}^0$ (mV)	${\mathit{R}}^2$	Residual (pH, RMS)
Cal 1 (pre)	$-58.6\pm 0.5$	$+0.21$	0.998	0.05
Cal 2 (pre)	$-58.4\pm 0.5$	$+0.23$	0.997	0.05
Cal 3 (pre)	$-58.7\pm 0.5$	$+0.20$	0.998	0.05
Post 48 h	$-58.2\pm 0.6$	$+0.23$	0.997	0.06

).

Expanded uncertainty (coverage factor $k=2$) for reported pH under these conditions is $U\approx \pm 0.10$ pH, dominated by electrode slope tolerance and temperature compensation residuals. The drift at pH 7.00 over 48 h remained within $\pm 0.03$ pH.

3.6. Cost Breakdown of the Final Prototype

To address reviewer concerns regarding system affordability, we provide here a detailed bill of materials (BOM) for the complete ModuLab prototype. This breakdown confirms that the entire system can be assembled for under 80 USD, using only off-the-shelf components. The modular design not only reduces cost, but also supports easy replacements and upgrades as research needs evolve (

Table 5. Component cost breakdown of the modulab prototype.

Componen/Part #	Description	Estimated Cost (USD)
APP-All MCU 2023 Board/1	Includes AVR128DA48 MCU with mikroBUS/Arduino headers	$28–$40
BME280 Sensor/1	Temperature, Humidity, and Pressure combo sensor	$7–$15
VEML7700 Sensor/1	High-sensitivity ambient light sensor	$6–$15
pH2 Sensor Board/1	pH amplifier board with BNC probe	$25–$35
MCP2221A interface/1	USB-to-UART/I2C bridge with supporting accessories	$10–$20
Total Estimated Cost	Full hardware BOM for one ModuLab setup	$76–$100

Costs reflect publicly available pricing from Digikey, Mouser, or AliExpress as of Q2 2025. Tax/Shipping exclusions.

).

This low-cost design ensures ModuLab is accessible for academic and research labs with constrained budgets, especially in vocational, agricultural, or environmental fields where conventional instrumentation may be cost-prohibitive.

Compared to conventional commercial laboratory instrumentation, which often incurs expenses ranging from hundreds to several thousand dollars, ModuLab’s modular setup significantly lowers financial barriers—particularly important for resource-limited laboratories such as those in educational or synthetic biology settings.

3.7. Performance Metrics and Synthetic Dataset

Complete raw institutional datasets from long 48-h tests are not available for publication, but we obtained the primary performance measures from these smaller efforts. The average end-to-end latency of the system was 100 ms; the p95 latency was 100 ms; the frame error rates were less than 0.3% and the analog noise is below 0.5 mV RMS on the pH channel. The sample-to-sample timestamps still had less than 5 ms jitter on all the sensor channels. In order to increase reproducibility, we shared a simulated dataset modeling the system frame format, timing delays and error models, enabling readers to reproduce the acquisition pipeline in controlled conditions.

4. Discussion

4.1. Hardware and Firmware Performance

The integration of Microchip Technology’s APP-All MCU 2023 development board and the AVR128DA48 microcontroller has demonstrated remarkable reliability and precision in environmental data acquisition. Utilizing the I²C protocol, the firmware efficiently initializes, calibrates, and samples from multiple sensors, including those measuring temperature, pH, light intensity, and humidity. The firmware architecture, built upon a robust, interrupt-driven data capture mechanism, ensures consistent performance and real-time responsiveness. The comprehensive implementation of error-checking algorithms, such as cyclic redundancy checks (CRCs) and checksum validations, significantly enhances the integrity of data across prolonged experiments. Furthermore, calibration routines incorporated within the firmware mitigate sensor drift and manufacturing discrepancies, ensuring accuracy over extended operational periods. The system’s high fidelity is particularly valuable in laboratory scenarios where experimental conditions fluctuate dynamically. This setup successfully addresses key limitations of traditional rigid systems, highlighting the significant advantages of modular and flexible design methodologies in contemporary research environments. Overall, the hardware and firmware layers have proven to be robust, scalable, and highly effective in diverse experimental configurations.

4.2. Real-Time Data Visualization and Host Interface

The Python-based software stack leveraging the Bokeh visualization library significantly enhances the usability and operational efficiency of the ModuLab system. Real-time visualization provides researchers and laboratory administrators with immediate insights into the monitored environmental parameters, including temperature fluctuations, pH variations, light intensity changes, and humidity levels. The dynamic visualization capability is crucial for detecting anomalies and ensuring rapid intervention, thereby enhancing the reliability of experimental outcomes. The seamless integration of the MCP2221A interface bridges data flow between the microcontroller and the host computer, ensuring minimal latency and data loss. Additionally, the modular nature of the software architecture simplifies maintenance tasks, allowing isolated updates to the parsing, filtering, or visualization modules without extensive system downtime. The embedded logging mechanism further empowers users to retrospectively analyze historical data through comprehensive searching capabilities (“grepping”), crucial for diagnosing intermittent issues. These software features not only complement the hardware robustness but significantly advance the system’s practical utility, making real-time monitoring both accessible and effective for laboratory personnel.

4.3. Timing Coherence and Throughput

Each sensor acquires internally at 128 Hz with oversampling. The firmware applies decimation and filtering, reducing the update rate to 10 Hz per channel. For example, with four sensors (pH, temperature, humidity, light), each frame contains four data fields plus a timestamp, yielding an average frame width of 32 bytes. At 10 Hz per channel, the aggregate throughput is 320 bytes/s, well within both the I²C and USB-UART bandwidth limits.

4.4. Future Improvements and Research Opportunities

While the present ModuLab implementation exhibits robust performance, several potential enhancements remain. Optimizing the firmware to reduce data acquisition latency represents one critical area for development, potentially through integrating advanced processing algorithms or parallel computing techniques. Introducing wireless communication capabilities, such as Bluetooth or Wi-Fi integration, would significantly enhance the system’s flexibility and scalability. Additionally, further expansion of the software analytics framework, particularly through the incorporation of automated anomaly detection, predictive analytics, or AI-driven decision-making tools, would elevate the system’s diagnostic capabilities. Moreover, exploring cloud-based data management solutions could enhance collaborative research environments by facilitating easier data sharing and remote access. Extending sensor compatibility to encompass additional environmental variables or specialized analytical sensors could further broaden the applicability of the ModuLab platform. Addressing these opportunities would not only enhance overall system performance but also ensure continued relevance and adaptability to emerging research challenges and technological advancements.

4.5. Scalability and Adaptability of the System

The modular nature of the ModuLab Interface System allows for a high degree of scalability and flexibility. Using standard interconnects, communication protocols, and modular sensor setups, the platform greatly simplifies the interfacing of new sensors or peripheral devices. Its flexibility enables quick prototyping and iterative testing, allowing researchers to change setups rapidly as research demands evolve. The ability to easily attach or detach sensors without significant system re-designs demonstrates the longevity of the system, especially for interdisciplinary research situations. Additionally, the use of standardized hardware and software interfaces facilitates integration and expands the potential of new developing technologies, thereby future-proofing your investment in the laboratory. In contrast to conventional fixed systems, this modular design offers investigators an enduring and flexible platform capable of accommodating a broad array of current and future scientific questions.

4.6. System Robustness, Reliability, and Operational Efficiency

Laboratory equipment must be solid and dependable in the diverse conditions encountered in experiments. ModuLab realizes these characteristics through the combination of careful design and iterations in its implementations. The deeply embedded firmware and comprehensive error-checking, in conjunction with live sensor diagnostics and calibration routines, result in reliable data and system performance. Moreover, special power management and signal conditioning circuits greatly increase long-term reliability. The system uses extensive data logging and error checking capabilities to ensure that unforeseen issues can be quickly resolved, keeping downtime and service calls to a minimum. The modular aspect of the hardware also makes troubleshooting components a breeze, making it simple to test and maintain a sensor or module without disturbing the full experimental set up. In combination, these design features serve to maximise system efficiency and thus minimise the cost of operation and guarantee reproducible performance, thereby fulfilling the most demanding requirements of today’s laboratory settings.

4.7. Comparison to Traditional Instrumentation Systems

Compared to conventional, non-modular instrumentation, the ModuLab Interface System offers substantial benefits in terms of flexibility, ease of integration, and cost-effectiveness. Traditional laboratory instrumentation frequently relies on proprietary, rigid hardware solutions that restrict customization and scalability, often necessitating extensive and costly modifications when experimental parameters change. In contrast, ModuLab’s modular architecture facilitates easy and cost-efficient modifications, allowing laboratories to adapt rapidly to new research directions without substantial additional investments. The standardized communication protocols and interfaces employed by ModuLab significantly reduce complexity and compatibility issues, simplifying the integration process, even for users with limited technical expertise. Furthermore, the overall operational costs, including initial setup and ongoing maintenance, are markedly reduced, making the ModuLab system particularly advantageous for resource-constrained research environments. This comparative analysis highlights the clear advantages of modular, flexible instrumentation over traditional fixed systems, emphasizing the value of adaptability in contemporary research infrastructure.

4.8. Impact on Laboratory Workflow and Research Productivity

ModuLab Interface System implementation has had a significant positive change in laboratory productivity and overall research output. The easy and intuitive setup of the Klarite sensor on the sample stand along with a simplified and intuitive real-time monitoring layout with plug and play sensor integration cuts down hours in experiment preparations. This would allow researchers to rapidly prototype experiments, iterate over experiment conditions, and manage data acquisition process in a more streamlined way. The possibility to have immediate data visualization via Python–Bokeh interface further hastens the experimental process of decision making, i.e., premature decision-making based on data assisted by intervention and prevents any delay to interfere. As a result, ModuLab users claim increased throughput, decreased error rates and better usage of resources in their labs. By reducing the technical overhead associated with instrument configuration and maintenance, researchers can focus more on science, thereby increasing productivity and potentially speeding up scientific discovery cycles.

4.9. Importance of Pre-Scale-Up Validation

A dedicated pre-scale-up stage is essential but also necessary considering that we need to de-risk full-scale deployments, as well as the reproducibility of experiments. In the ModuLab, the phase is used to iteratively validate sensor accuracy, firmware stability, and data-flow integrity over controlled stress (e.g., demonstrating that they are no stressed mechanical, electric, or software issues that must be resolved before the rollout of larger instruments). By subjecting the platform to long-term thermal cycles, live module swaps, and repeated calibration routines, we expose potential failure modes (e.g., connector wear, I²C bus contention, or firmware memory leaks) significantly before they have a larger application severity (i.e., low-stakes). Such early validation guides design refinements like improved grounding strategies or more sophisticated retry logic, all without inflating hardware or software costs. Additionally, the early-scale-up proof-of-concept acts as a shared reference between the engineers, plant operators, and end users to help ensure a common understanding with respect to performance, service, and total cost of ownership. In the end, the investment in pre-scale-up testing will not only save us from the time-to-deployment delays inherent in late-stage redesign but also increase our confidence that the final scaled system will satisfy not only laboratory throughput requirements but also longer term reliability requirements.

5. Conclusions

5.1. Summary of Work and Contributions

This paper presents the ModuLab Interface System, a new modular platform to meet the changing requirements of laboratory instrumentation. Based on Microchip Technology’s popular APP-All MCU 2023 development board (which contains an AVR128DA48 microcontroller), ModuLab enables easy sensor integration via the ubiquitous I²C protocol to a variety of environmental sensors, such as temperature, pH, light intensity, and humidity. The C/C++-based firmware stores extensive initialization procedures, accurate calibration routines, and real-time sampling algorithms optimized for minimal data distortion. The system comprises a Python-based visualization interface created with the Bokeh library, which supports live data interaction and is coupled with real-time visualisation of the monitored parameters. The connection between the microcontroller and the host computer is achieved via this interface, MCP2221A, and helps to maintain a constant transfer speeds, even in the long run, as well as avoiding issues with data logging. The modular hardware architecture, combined with common connectors and communication protocols, makes the task of adding new sensors or measuring additional channels easier. ModuLab reduces the needed technical knowledge to be able to use this kind of instrumentation and thus allows labs, especially ones with a weak CS expertise, to start their flexible high-performance ambient monitoring without being limited by the fixed function of an expensive dedicated instrument.

5.2. Implications and Benefits

The benefits of the ModuLab Interface System go far beyond traditional laboratory instrumentation configurations. This design is naturally modular, which means changing sensors and subsystems takes only a few minutes—in contrast to it taking weeks to adapt to new experimental requirements. The MCP2221A interface guarantees the integrity of data transmission over long acquisition sessions between the microcontroller and host computer, even in the face of interruptions or signal degradation. It provides real-time visualization using the Python–Bokeh framework to help users detect anomalies, analyze trends over time, and respond without delay. It is this proactive ability that averts expensive experiment delays in investigations where environmental stability is absolutely key. In addition, the system is inexpensive, as it uses over-the-counter hardware, greatly reducing capital costs which, when combined with low maintenance costs, allows sophisticated monitoring to be achieved in resource-poor settings. A wide range of users can benefit from ModuLab thanks to its dependency on standardized communication protocols for any third-party sensors or laboratory systems. In the end, this effectively leaves a price–performance window that, as cited earlier, is hard to find in practical applications and at the research level for this level of robustness coupled with ease of operation.

5.3. Future Directions and Final Remarks

While the current form of ModuLab has a strong proof-of-concept track record, there are obvious areas in which it can be improved upon and expanded. Optimization at the firmware level to decrease data acquisition latency could facilitate applications with increased temporal resolution. Extended support for additional communication protocols—Bluetooth Low Energy, Wi-Fi, or LoRa—could make the system much more versatile and potentially allow researchers to observe their experiments from anywhere in a remote or distributed-sensing scenario. Adding compatibility for new sensor modalities (for example dissolved gases, volatile organic compounds or advanced spectroscopic data) would simplify the deployment of FlyPi in environmental monitoring, biotechnology and materials science applications. They could also improve the existing Python-based software with automatic anomaly detection, predictive analysis and user-controllable dashboards, which would serve to increase both diagnostic capability as well as user experience. This manuscript should be contextualized to demonstrate how ModuLab is (1) currently only intended as a proof of concept and (2) strictly with the focus on ease of integration, modularization, and affordability. Future studies will include a structured performance evaluation program with comprehensive quantitative validation, covering stability metrics, error analyses, and noise characterization.

5.4. Integration with Emerging Technologies

The versatility of ModuLab makes it an ideal platform for interfacing with new technologies that are revolutionizing laboratory instrumentation. Add-on support via Internet of Things (IoT) connectivity would allow ModuLab to be monitored remotely and controlled, making it easier for research teams to observe as well as amend experiments in real time from any location. This capability would be particularly important for long-duration studies and field deployments. Edge computing could increase performance even more by allowing fundamental data filtering and analysis to be performed directly on the microcontroller, in turn reducing bandwidth requirements and lowering latency for applications that require faster transmitting times between the device and server. Integration with artificial intelligence brings another strong approach, such as the use of algorithms that are capable of predictive maintenance, adaptive calibration, and intelligent anomaly detection, which can all drastically increase the reliability of the system and bring down the need for manual oversight. By integrating IoT, edge treatment, and AI, ModuLab could be evolved from an agile instrumentation tool into a self-optimizing analytic platform that is almost semi-autonomous. Such a technological direction would advance the capabilities of ModuLab for more broad trends in laboratory automation and smart-sensing systems.

5.5. Educational and Training Implications

Outside its role in research, ModuLab works great as a teaching device to familiarize students and novice investigators with the fundamentals of instrumentation design, data acquisition, and sensor incorporation. Being modular increased its ability to assemble and reconfigure a system by students, but also led to a better understanding of component interaction and overall system architecture. This instant feedback mechanism allows students to realize the consequences of changes in environmental conditions or system settings immediately with real-time data visualization. Teachers and educators can make use of it because the platform consists of affordable off-the-shelf components, allowing lower-budgeted institutions to also embrace hands-on lab training. Despite having limited programming experience, the user-friendly interface and simplified programming model of ModuLab make it accessible to users, making it an inclusive teaching resource. It links the theoretical aspects with practical implementation, allowing students to learn by doing, build technical skills, and obtain hands-on experience of a laboratory while preparing themselves for a professional STEM career with the requisite modern lab skills.

5.6. Future Work for the Project

MBS will now enter the next phase of development, focusing on a more substantial increase in functionality and production readiness for broader deployment. We are planning to augment the hardware by installing sensor modules for dissolved O₂, CO₂, and a range of electrochemical analytes, providing advanced functionalities in environmental science, bioprocess monitoring/diagnostics, and chemical analysis. These will provide remote oversight of experiments and the ability for over-the-air firmware updates so that deployed units can be updated without needing to be collected in person. We will develop a RESTful API to make the integration trouble-free with any laboratory information management systems (LIMS) for automated data archiving and workflow. Feedback will inform iterative enhancements to the visualization interface, such as configurable dashboards and mobile support, and extended data export options. Additionally, we will discuss manufacturing considerations including enclosure design, component standardization and assembly automation to create a plug-and-play device for pilot deployments. This will set the stage for future commercialization, all whilst maintaining its core identity of modularity TDF-like adaptability that are inherent to ModuLab.