A Benchmark Reference for ESP32-CAM Module

Fathi Amsaad; Nermeen M. Saleh; Sayed T. Nowroz; Sean Banerjee; Siam Shakur

REVIEW 4 major objections 6 minor 23 references

A Benchmark Reference for ESP32-CAM Module

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Measured ESP32-CAM frame rates: 50+ FPS below 320x240, 1.29 FPS at 1600x1200.

desk verdict Useful consolidated benchmark for ESP32-CAM with a real bug fix and open dataset, but the absolute FPS numbers need an independent timing check before you trust them. read the letter →

arxiv 2505.24081 v1 pith:WROG2WCP submitted 2025-05-29 cs.RO cs.SYeess.IVeess.SY

Sayed T. Nowroz , Nermeen M. Saleh , Siam Shakur , Sean Banerjee , Fathi Amsaad This is my paper

classification cs.ROcs.SYeess.IVeess.SY

keywords ESP32-CAMOV2640imagesensorframeratebenchmarkembeddedvisionIoTvideostreamingHTTPWiFisupplyvoltagevariationthermalcharacteristics

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper attempts to establish a measured performance baseline for the ESP32-CAM module, a low-cost embedded camera, by logging over six hours of live video streaming over HTTP WiFi across all 15 supported OV2640 resolutions and eight voltage levels. Its central finding is a steep resolution cliff: average frame rates hold above 50 FPS up to 320x240, then fall to 14.19 FPS at 640x480 and 1.29 FPS at 1600x1200. The paper also finds that chip temperature stays near 70 degrees Celsius regardless of resolution and that supply voltages from 2.958 V to 3.5 V shift average FPS by only a few frames. It presents these numbers as a trustworthy reference for engineers and researchers choosing operating points for the module.

What carries the argument

The central object is the benchmark setup: the official Arduino CameraServer example firmware, patched to correct the FPS logging bug and to emit per-frame comma-separated log lines over UART containing instantaneous and average FPS, runtime, bytes transmitted, temperature, frame size, and voltage. These UART logs are captured over USB, parsed and stored as CSV by a flow-based tool, then analyzed to produce the tables. The FPS fix is the load-bearing mechanism, because the measured averages are only as trustworthy as the logging that generated them.

What would settle it

Set up a second device at the receiver that timestamps each arriving frame using its own clock, then compare those inter-frame intervals against the logged instantaneous FPS from the UART stream; any systematic difference shows the logging path distorts timing, and a resolution-dependent gap would specifically implicate serial logging overhead.

Watch

Extended reading notes

Core claim

In the paper's own terms, the ESP32-CAM paired with the OV2640 sensor, streaming JPEG over an HTTP server on a local WiFi network, delivers a resolution-dependent frame-rate envelope: 51.17 FPS at 96x96, 52.59 FPS at 128x128, 44.44 FPS at 320x240, 14.19 FPS at 640x480, and 1.29 FPS at 1600x1200. The authors attribute the steep decline to sensor readout time, image signal processor load, and JPEG DCT operations with O($n^{2}$) complexity. Thermal readings stay stable at 69.73 to 74.18 degrees Celsius across resolutions, and over eight voltage settings between 2.958 V and 3.5 V the average frame rate stays within roughly 37 to 40 FPS, with the highest mean at 3.5 V. The paper also claims to fix a long-standing bug in the Arduino ESP32 core's CameraServer example that reported incorrect FPS values, and it releases the logs as a public dataset.

Load-bearing premise

The reported frame rates are only as good as the patched logging: the firmware that measures FPS also streams the video, so if the UART logging perturbs timing or the fix is wrong, every average in the tables is systematically off rather than just noisy.

Editorial extensions

If this is right

Any ESP32-CAM application needing smooth video should stay at or below 320x240, where measured averages exceed 50 FPS.
At 640x480 the envelope is about 14 FPS, making it workable for periodic analysis but not fluid preview.
The highest resolution, 1600x1200, is effectively a still-image mode at 1.29 FPS.
The stable roughly 70 degree Celsius temperature across all resolutions indicates thermal throttling is not driving the frame-rate drop.
Voltage in the tested 2.958 to 3.5 V range is a minor lever: the spread of average FPS across all eight settings is under 4 FPS.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

An untested extension is network dependence: because FPS is measured after WiFi transmission, the envelope should be re-measured under different signal strength, channel congestion, and client load to separate sensor limits from network limits.
The O(n^2) DCT explanation suggests a CPU-bound JPEG path; a test that streams uncompressed RGB at low and high resolutions would isolate whether the drop is compression or sensor readout.
The public dataset enables unit-to-unit reproducibility checks; rerunning the same firmware on several boards would reveal whether the envelope is a property of the chip or of one sample.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the short version: this is the closest thing to a consolidated benchmark for the ESP32-CAM, and the dataset plus the FPS-logging fix are real contributions. But the paper's central numbers rest on the authors' own patched firmware, and there's no independent check on whether those FPS values are true. That's the one thing to verify before using Table I as a reference.

What's actually new: the paper streams at all 15 OV2640 resolutions for 15 minutes each, logs per-frame metrics over UART, publishes the dataset and firmware, and fixes a genuine bug in the Arduino ESP32 core that had misreported FPS since 2018. That bug fix (PR #10921) is independently valuable for the community. The empirical envelope—low resolutions holding above 50 FPS over WiFi, steep drop beyond 320x240, chip temperature around 70C, voltage sensitivity within a few FPS—is plausible and matches what users report anecdotally. The temperature curves and transmission volume figures are useful.

Soft spots, in order of seriousness. First, the FPS numbers are self-measured: the logs that define 'instant FPS' come from the modified CameraServer firmware itself. The logic analyzer in the setup decodes UART, but it doesn't verify the firmware's frame-timing math. If PR #10921 is wrong, or if per-frame UART logging at 50+ FPS drops records or perturbs pacing, every average in Table I carries the same systematic bias. This is testable with a WiFi packet capture or a client-side timer, and the paper would be much stronger with such a check. Second, the reporting inconsistencies: the abstract says five voltage conditions, Table II shows eight; Table I has no error bars or repetition counts; and the 2.985V threshold in the conclusion is not supported by the data in Table II, where the lowest voltage still gives 39.25 FPS. That threshold is a post hoc guess. Third, the DCT complexity statement is a hand-wavy aside, not central.

None of this sinks the paper. The qualitative relationship between resolution and FPS is externally checkable and almost certainly correct. But because the paper bills itself as a definitive performance reference, the absolute numbers matter, and the missing verification is a load-bearing gap.

Who should read it: anyone deploying ESP32-CAM in a time-sensitive application and looking for a starting point on resolution vs. FPS. It's a practical reference, not a scientific breakthrough. It deserves a serious referee: the dataset is reproducible, the work is honest, and the issues are fixable. I'd send it out, with a request for an independent timing check and cleanup of the voltage/reporting mismatches.

Referee Report

4 major / 6 minor

Summary. This paper reports an experimental benchmark of the ESP32-CAM module (OV2640 sensor, ESP32S) streaming JPEG over HTTP on a local WiFi network. The authors collected 15-minute logs for 15 resolutions and 8 supply voltages, using firmware based on Arduino's CameraServer example plus a fix to the FPS logging code (PR #10921). They report average FPS and chip temperature per resolution, a steep FPS drop beyond 320x240, thermal stability around 70 C, and a weak dependence of FPS on supply voltage. The dataset, firmware, and analysis tools are released on GitHub.

Significance. If the measurements are accurate, the paper provides a useful, citable baseline for ESP32-CAM performance, and the public release of logs, firmware, and analysis tools is a genuine strength. The headline resolution-to-FPS relationship is an external hardware behavior that is plausible and checkable. However, all FPS numbers come from the authors' own patched firmware without an independent timing reference, and the voltage section has unresolved specification and reporting inconsistencies. These gaps currently limit the reliability of the stated performance envelope.

major comments (4)

[Section IV, Table I] All FPS averages in Table I are computed from UART logs emitted by the authors' modified CameraServer firmware, with the FPS calculation patched in the first author's PR #10921. The manuscript provides no independent timing verification (e.g., external frame counter, WiFi packet capture, logic-analyzer measurement of the camera VSYNC, or client-side timestamps), nor does it quantify the overhead or loss rate of per-frame serial logging at high FPS, where a log record is produced every ~19 ms. If the patch is incorrect or the logging perturbs frame pacing, every value in Table I is systematically biased rather than merely noisy. This is load-bearing for the paper's central claim, so I ask for an independent validation experiment or a quantitative bound on the measurement error.
[Abstract, Section VI, Section VII] The abstract states that testing was done under "five distinct voltage conditions," but Table II lists eight voltages: 2.958 V, 2.98 V, 3.0 V, 3.1 V, 3.2 V, 3.3 V, 3.4 V, and 3.5 V. The conclusion additionally claims a threshold at 2.985 V, a value that does not appear in Table II. The authors should state the exact voltage set used and either justify the 2.985 V threshold with data or remove it, since it currently appears unsupported by the tabulated results.
[Section VI, Table II] The voltage-sweep experiments do not specify which resolution, codec, or WiFi settings were used. The FPS values in Table II (37-40 FPS) do not match any row in Table I (e.g., 44.44 at 320x240, 48.49 at 240x176), so readers cannot interpret the voltage sensitivity or reproduce the experiment. Please specify the test configuration for Table II and, ideally, report voltage sweeps at more than one resolution.
[Table I, Figure 2] Table I reports only point averages for FPS and temperature, with no sample size, standard deviation, or confidence intervals. Given the small differences among low-resolution rows (51.17 vs 51.30 vs 52.59 FPS) and the variability shown in Figure 2, the reader cannot tell which differences are significant. Please provide the number of runs, the number of frames per run, and dispersion measures for each row of Table I.

minor comments (6)

[Figures 2-6] Several figure captions contain garbled text with sequences such as "/uni0000001c/uni00000019/..." and appear corrupted; please regenerate the PDF and replace these captions with readable text.
[Author affiliations] There is a typo in the affiliations: "Enggineering" should be "Engineering."
[Section V] The text states JPEG compression involves DCT operations with "O(n 2)" complexity; this should be formatted as O(n^2).
[Section IV] The methodology says logs were collected via USB and Node-RED, but later states "UART logs were decoded and collected using a logic analyzer." Please clarify whether this is a second collection path or a different description of the same setup.
[Table I] The column "File Size (Bytes)" should define what is being measured; if it is the mean frame size, say so explicitly and give units per frame rather than just bytes.
[Reference [3]] Please state the current status of PR #10921 (e.g., merged, open, or superseded) and whether the fix is available in a released version of the Arduino ESP32 core; this is important for reproducibility.

Circularity Check

1 steps flagged · score 2.0 of 10

The reported FPS values rely on the authors' own unverified FPS-logging fix, but the central resolution-versus-FPS trend is an external, checkable hardware behavior.

self citation load bearing [Abstract and Section IV (Methodology), with supporting reference [3]]
"A long standing bug in the official Arduino ESP32 driver, responsible for inaccurate frame rate logging, was fixed. ... The firmware used is based upon Arduino's CameraServer example code, with corrected longstanding FPS logging bug in the example code. ... [3] S. T. Nowroz, 'fix(logging): incorrect fps logging.' GitHub Pull Request #10921, 2025."

Every FPS average in Table I is computed from logs emitted by firmware that includes the first author's own bug fix, and the only cited authority for the correctness of that fix is the first author's own pull request. No independent timing reference, such as an external frame counter or logic-analyzer measurement of the camera sync line, is provided to validate the corrected FPS calculation. Thus the paper's central data-quality premise rests on a self-citation that is not independently verified. This is a load-bearing validity concern, but it is not a case where a derived quantity reduces to an input by construction: the resolution-versus-FPS relationship is an external hardware behavior that any user can reproduce with the same module, so the circularity score remains low.

full rationale

This paper is an empirical benchmark, not a mathematical derivation. It contains no equations in which an output is defined in terms of the claimed prediction, and no fitted parameter is relabeled as a prediction. The main relationship reported, higher resolution leading to lower FPS, is a physical property of the ESP32-CAM and OV2640 sensor that is externally checkable and independent of the paper's own assumptions. The only notable circularity-adjacent issue is that the accuracy of the FPS measurements depends entirely on the authors' patched firmware, supported by the first author's own pull request [3], without independent validation. This makes the reported absolute FPS numbers potentially dependent on an unverified self-citation, but it does not make the central empirical trend circular. Accordingly, a score of 2 reflects one minor load-bearing self-citation while recognizing that the benchmark has independent content that can be reproduced externally.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

This is an empirical benchmark with no fitted model. The only free parameter is a post hoc voltage threshold. The remaining inputs are hardware/datasheet assumptions and the authors' own bug-fix PR. No new particles, forces, or abstract entities are introduced.

free parameters (1)

minimum safe input voltage threshold = 2.985 V
The conclusion states that performance degrades below 2.985 V, but no data below 2.958 V are presented; this threshold appears inferred post hoc from the tested range.

assumptions (4)

domain assumption The ESP32-CAM and OV2640 sensor behave as specified in the AI-Thinker documentation, and the UART logs faithfully represent real-time streaming statistics.
Sections II and IV rely on datasheet behavior and on UART logs being accurate real-time measurements; no independent verification of the logging path is provided.
domain assumption The patched CameraServer firmware computes true FPS, and the FPS logging bug fix in PR #10921 is correct and does not introduce measurement bias.
Section I and Section IV use the patched firmware as ground truth, citing the first author's own pull request; no external timer or independent test confirms the corrected FPS.
domain assumption One 15-minute streaming session per condition is representative of steady-state performance.
Section V reports average FPS and temperature from logs without repeated runs; run-to-run variance and the effect of environmental factors are unknown.
domain assumption The local WiFi/HTTP setup represents the intended use case, and the client computer and network are not performance bottlenecks.
Section IV describes an HTTP server over local WiFi, but gives no details about the router, client hardware, or network load, all of which could affect FPS and transmission volume.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A Benchmark Reference for ESP32-CAM Module." pith.science (2026). https://pith.science/paper/WROG2WCP

@misc{pith2026250524081,
  author       = {Pith},
  title        = {Pith review of: A Benchmark Reference for ESP32-CAM Module},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WROG2WCP}},
  note         = {Machine review of arXiv:2505.24081}
}

read the original abstract

The ESP32-CAM is one of the most widely adopted open-source modules for prototyping embedded vision applications. Since its release in 2019, it has gained popularity among both hobbyists and professional developers due to its affordability, versatility, and integrated wireless capabilities. Despite its widespread use, comprehensive documentation of the performance metrics remains limited. This study addresses this gap by collecting and analyzing over six hours of real-time video streaming logs across all supported resolutions of the OV2640 image sensor, tested under five distinct voltage conditions via an HTTP-based WiFi connection. A long standing bug in the official Arduino ESP32 driver, responsible for inaccurate frame rate logging, was fixed. The resulting analysis includes key performance metrics such as instantaneous and average frame rate, total streamed data, transmission count, and internal chip temperature. The influence of varying power levels was evaluated to assess the reliability of the module.

Figures

Figures reproduced from arXiv: 2505.24081 by the authors.

**Figure 2.** Average FPS and FPS Distribution for each Resolution. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Temperature Deviation across Different Resolutions. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Temperature standard deviation across different voltages. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]

**Figure 5.** Figure 5: Transmission Rate over time for all resolutions 0 100 200 300 400 500 600 700 800 900 Time (seconds) 6 8 10 12 14 Transmission Rate (KB/s) Resolution - Avg Temp 2v958 - 66.4°C 2v98 - 66.2°C 3v0 - 66.1°C 3v1 - 67.5°C 3v2 - 67.1°C 3v3 - 67.7°C 3v4 - 67.8°C 3v5 - 67.9°C …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

23 extracted references · 23 canonical work pages

[1]

Protothread and cooperative multitasking scheduler on the arduino framework,

B. Y . L. ´Avila, C. A. G. V ´azquez, O. P. Baluja, M. Alexandru, D. T. Cotfas, P. A. Cotfas, and L. A. Q. Dom ´ınguez, “Protothread and cooperative multitasking scheduler on the arduino framework,” in 2024 International Conference on Applied and Theoretical Electricity (ICATE), pp. 1–5, 2024

work page 2024
[2]

Esp32-cam documentation

AI-Thinker, “Esp32-cam documentation.” Online, 2025. Accessed: Feb 23, 2025

work page 2025
[3]

fix(logging): incorrect fps logging

S. T. Nowroz, “fix(logging): incorrect fps logging.” GitHub Pull Request #10921, 2025. Accessed: Feb 23, 2025

work page 2025
[4]

Esp32-cam performance reference benchmark

“Esp32-cam performance reference benchmark.” https://github.com/ TNeutron/ESP32-CAM-Performence-Reference-Benchmark. Accessed: May 22, 2025

work page 2025
[5]

Ubidots,Live Video Stream Monitoring using ESP32-CAM and Ubidots,

work page
[6]

Coding arduino programming language: A comprehensive guide,

Emeritus, “Coding arduino programming language: A comprehensive guide,” 2025. Accessed: May 11, 2025

work page 2025
[7]

An experimental comparison of arduino ide compatible platforms for digital control and data acquisition applications,

O. E. Amestica, P. Melin, C. Duran-Faundez, and G. Lagos, “An experimental comparison of arduino ide compatible platforms for digital control and data acquisition applications,” in2019 IEEE CHILEAN Conference on Electrical, Electronics Engineering, Information and Communication Technologies (CHILECON), pp. 1–6, 2019

work page 2019
[8]

About node-red,

Node-RED Project, “About node-red,” 2025. Accessed: May 11, 2025

work page 2025

Show all 23 references

[9]

Chicken health detection system using edge impulse with esp32-cam,

Y . R. S. Rao and H. A. Majid, “Chicken health detection system using edge impulse with esp32-cam,”Progress in Engineering Application and Technology, vol. 5, no. 2, pp. 330–339, 2024

2024
[10]

New model to monitor plant growth remotely using esp32-cam and mobile application,

K. Elhattab, K. Abouelmehdi, and S. Elatar, “New model to monitor plant growth remotely using esp32-cam and mobile application,”2023 10th International Conference on Wireless Networks and Mobile Com- munications (WINCOM), pp. 1–6, October 2023

2023
[11]

Riddance of weed using an agri-robot employed by arduino and esp32 cam,

D. N. Vinod, B. Bhaskar, B. R. Teja, and A. Kamalesh, “Riddance of weed using an agri-robot employed by arduino and esp32 cam,” 2022 13th International Conference on Computing Communication and Networking Technologies (ICCCNT), pp. 1–6, June 2024

2022
[12]

Iot based farm protection system from animals and humans theft using esp32 with camera module,

P. Manikandan, G. Ramesh, P. Lokesh, P. N. Raju, M. D. Prasad, and P. Madhu, “Iot based farm protection system from animals and humans theft using esp32 with camera module,”2022 2nd International Conference on Advance Computing and Innovative Technologies in Engineering (ICACI...

2022
[13]

A face recognition application for alzheimer’s patients using esp32-cam and raspberry pi,

T. A. Kadhim, W. Hariri, N. Smaoui Zghal,et al., “A face recognition application for alzheimer’s patients using esp32-cam and raspberry pi,” Journal of Real-Time Image Processing, vol. 20, no. 100, 2023

2023
[14]

Towards a novel wearable solution for citrus inspection using edge ai,

J. C. Ferreira da Silva, M. C. Silva, and R. A. Oliveira, “Towards a novel wearable solution for citrus inspection using edge ai,” in2022 IEEE 46th Annual Computers, Software, and Applications Conference (COMPSAC), pp. 966–971, 2022

2022
[15]

Home security system using esp32-cam and telegram application,

G. C. Manjunath, B. Mahendra, M. Rashmi, M. G. Bhuvana, and M. Keerthi, “Home security system using esp32-cam and telegram application,”International Journal of Advanced Research in Science Communication and Technology, pp. 580–582, June 2022

2022
[16]

Home security with iot and esp32 cam - ai thinker module,

R. R. Pbv, V . S. Mandapati, S. L. Pilli, P. L. Manojna, T. H. Chandana, and V . Hemalatha, “Home security with iot and esp32 cam - ai thinker module,”Proceedings of 2024 International Conference on Cognitive Robotics and Intelligent Systems (ICC - ROBINS 2024), pp. 710–714, A...

2024
[17]

Design of a smart home door security system with face detection and smart bell using esp32-cam,

N. Salsabila, A. Siswanto, and L. Bayuaji, “Design of a smart home door security system with face detection and smart bell using esp32-cam,” Proceedings of the 6th International Conference on Mobile Computing and Sustainable Informatics (ICMCSI-2025), pp. 124–129, January 2025

2025
[18]

Tinyml: Analysis of xtensa LX6 microprocessor for neural network applications by ESP32 soc,

M. Z. H. Zim, “Tinyml: Analysis of xtensa LX6 microprocessor for neural network applications by ESP32 soc,”CoRR, vol. abs/2106.10652, 2021

2021 arXiv
[19]

A low-power low-cost system for disaster locations detection using esp32 cam and tinyml,

R. Samanta, B. Saha, and S. K. Ghosh, “A low-power low-cost system for disaster locations detection using esp32 cam and tinyml,” in2025 17th International Conference on COMmunication Systems and NET- works (COMSNETS), pp. 907–910, 2025

2025
[20]

Tinyml-on-the-fly: Real-time low-power and low-cost mcu-embedded on-device computer vision for aerial image classification,

R. Samanta, B. Saha, and S. K. Ghosh, “Tinyml-on-the-fly: Real-time low-power and low-cost mcu-embedded on-device computer vision for aerial image classification,” in2024 IEEE Space, Aerospace and Defence Conference (SPACE), pp. 194–198, 2024

2024
[21]

Esp32-cam github repository,

Prusa3D, “Esp32-cam github repository,” 2023. Accessed: Feb 23, 2025

2023
[22]

Network anomaly detection for iot using hyperdimensional computing on nsl-kdd,

G. Ghajari, A. Ghimire, E. Ghajari, and F. Amsaad, “Network anomaly detection for iot using hyperdimensional computing on nsl-kdd,” 2025

2025
[2025]

Accessed: May 11, 2025

2025

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Protothread and cooperative multitasking scheduler on the arduino framework,

B. Y . L. ´Avila, C. A. G. V ´azquez, O. P. Baluja, M. Alexandru, D. T. Cotfas, P. A. Cotfas, and L. A. Q. Dom ´ınguez, “Protothread and cooperative multitasking scheduler on the arduino framework,” in 2024 International Conference on Applied and Theoretical Electricity (ICATE), pp. 1–5, 2024

work page 2024

[2] [2]

Esp32-cam documentation

AI-Thinker, “Esp32-cam documentation.” Online, 2025. Accessed: Feb 23, 2025

work page 2025

[3] [3]

fix(logging): incorrect fps logging

S. T. Nowroz, “fix(logging): incorrect fps logging.” GitHub Pull Request #10921, 2025. Accessed: Feb 23, 2025

work page 2025

[4] [4]

Esp32-cam performance reference benchmark

“Esp32-cam performance reference benchmark.” https://github.com/ TNeutron/ESP32-CAM-Performence-Reference-Benchmark. Accessed: May 22, 2025

work page 2025

[5] [5]

Ubidots,Live Video Stream Monitoring using ESP32-CAM and Ubidots,

work page

[6] [6]

Coding arduino programming language: A comprehensive guide,

Emeritus, “Coding arduino programming language: A comprehensive guide,” 2025. Accessed: May 11, 2025

work page 2025

[7] [7]

An experimental comparison of arduino ide compatible platforms for digital control and data acquisition applications,

O. E. Amestica, P. Melin, C. Duran-Faundez, and G. Lagos, “An experimental comparison of arduino ide compatible platforms for digital control and data acquisition applications,” in2019 IEEE CHILEAN Conference on Electrical, Electronics Engineering, Information and Communication Technologies (CHILECON), pp. 1–6, 2019

work page 2019

[8] [8]

About node-red,

Node-RED Project, “About node-red,” 2025. Accessed: May 11, 2025

work page 2025