Review Reports - Design, Implementation and Functional Verification of an Educational Prototype with a Visual Programming Interface for Contextualized STEM Activities

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

Self-citations: The first author appears on at least five references [8, 10, 11, 26, 31] covering

very similar topics. The manuscript does not explain how the current work differs from

these prior publications.

Ethical concerns: (1) Classroom activities link sensor readings to childhood pneumonia and

acute diarrheal diseases without epidemiological evidence, validated exposure assessment,

or sensor calibration data. (2) The paper names specific communities (Daniel Hern.ndez,

Pampas–Tayacaja) and uses their health problems as educational material without evidence

of community consultation or benefit.

Comments for author File: Comments.pdf

Author Response

Please see the attached point-by-point response to Reviewer 1's comments. We sincerely appreciate the reviewer's valuable feedback. All comments have been carefully addressed, and the manuscript has been revised accordingly.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

My recommendation remains Major Revision. The manuscript presents a tangible and potentially useful technological development; however, several claims currently exceed the evidence documented in the study. The following summary identifies the indispensable corrections required to guide a precise revision. Please feel free to use this condensed version as the main report and retain the previous detailed report only as additional technical support, if considered useful.

Condensed Comments and Priority Recommendations for the Authors

The manuscript presents three customized educational electronic boards, sensors, and Spanish-language visual programming extensions applied in classroom STEM activities. The physical artifact and hardware–software integration constitute a potentially valuable technological contribution. Nevertheless, the available evidence primarily demonstrates prototype implementation and basic functional communication; it does not yet establish metrological measurement validity or educational effectiveness. The following issues should therefore be prioritized:

Align the type of validation with the available evidence. No instrument, rubric, pre/post-test, usability scale, observation protocol, or analysis of student products is reported to support effects on research competencies, computational thinking, technological literacy, or problem-solving skills. The photographs and Table 3 document participation and instructional design, but not learning outcomes. Unless additional educational data exist, the title, objective, abstract, results, and conclusions should reframe the work as a design, functional-verification, and classroom-feasibility study. Educational claims should be expressed as potential uses or outcomes observed during the activities rather than demonstrated effects.
Provide a metrological basis for the reported variables. Soil-moisture percentages, MQ135 concentrations in ppm, and turbidity values in NTU require exact sensor models, calibration procedures, conversion equations, test conditions, replications, observed results, variability or error, and acceptance criteria. For the MQ135, the target gas, R0 calibration, Rs/R0 relationship, warm-up time, and environmental conditions must be specified. If these calibrations were not performed, the outputs should be reported as analog signals or relative indicators, and claims concerning validated quantitative measurements should be removed. Signal variation alone does not demonstrate metrological accuracy or reliability.
Correct the inconsistencies among sensors, blocks, code, variables, and units. Figure 2 associates a DS18B20 temperature sensor with analog code that transforms a reading and stores it in a variable named “humedad.” Figure 1 incorrectly identifies the BH1750 as a pH sensor. Similarly, the BME680 gas resistance should not be presented as a direct air-quality measurement. The authors should audit all three boards and document a coherent chain for every sensor: model, connection, library, graphical block, source code, processed variable, unit, and test result.
Substantiate or moderate the open-source hardware claim. To retain this designation, the authors should provide a persistent repository containing complete schematics, Gerber files, bills of materials, firmware, installable mBlock extensions, dependencies and versions, pin maps, assembly instructions, test records, and an explicit license. If these materials cannot be released, the manuscript should state that the prototype was built using open-source platforms or components and acknowledge the resulting reproducibility limitation.
Strengthen methodological transparency and scientific structure. If the classroom component is retained, the manuscript should report the relevant number and characteristics of participants and groups, academic context, duration and number of sessions, procedure, collected data, and applicable ethical documentation, including consent for image publication. The relationship among Design Science Research, the V-Model, and the Waterfall-inspired process should also be clarified. Finally, design and implementation, evaluation protocol, results, and discussion should be separated; novelty should be demonstrated through a structured comparison with previous systems; and all citations, references, and sources embedded in figures should be audited.

These revisions are substantive but feasible. The manuscript’s strongest defensible contribution is the integration of customized educational boards, sensors, and visual programming in contextualized classroom activities. The scope of the conclusions should remain proportional to the technical and educational evidence ultimately presented.

Comments on the Quality of English Language

The manuscript is generally understandable, and its purpose, prototype components, and implementation sequence can be identified. Nevertheless, the English requires systematic linguistic and terminological revision before the paper can be considered ready for publication. The problems are not limited to stylistic preferences: in several places, grammar, terminology, and verb strength alter or obscure the scientific and technical meaning.

Grammar and sentence structure

In the abstract, “This study aimed to design and validated an educational prototype” contains an incorrect coordination of verb forms. It should read: “This study aimed to design and validate an educational prototype.”

Section 2.3 contains the incomplete sentence “In another study, developed an IoT-based smart agriculture solution…”. This construction lacks a grammatical subject and a clearly associated reference. The relevant author or study must be identified and the sentence reconstructed, for example: “[Author] developed an IoT-based smart agriculture solution…”. Merely adding a pronoun would not be sufficient because the supporting citation must also be provided.

The use of definite and indefinite articles, subject–verb agreement, parallel structures in enumerations, and coordination of verb forms should be systematically reviewed. These corrections are particularly important in the abstract, methodological description, and conclusions, where grammatical ambiguity may affect the interpretation of the objective, procedure, or scope of the findings.

Terminological consistency

The manuscript alternates among “environment board,” “environmental board,” and “environmental monitoring board.” These expressions should not be treated as interchangeable. An official designation should be defined when the three boards are introduced and retained throughout the text, tables, and figure captions. “Environmental monitoring board” is the most precise option for the relevant board.

The terms “educational electronic board,” “educational board,” “hardware platform,” and “prototype” should also be standardized. If they represent different system levels, that distinction must be explained. If they refer to the same component, a single term should be selected to prevent readers from interpreting them as different artifacts.

The phrase “bilingual programming blocks in Spanish” is semantically contradictory: “bilingual” requires two languages, whereas the manuscript documents only Spanish labels. If only Spanish blocks were implemented, the text should use “Spanish-language programming blocks” or “programming blocks labelled in Spanish.” If a bilingual interface actually exists, both languages and the selection mechanism should be specified.

Precision of technical and metrological language

Some expressions are grammatically possible but scientifically inaccurate. In Table 1, “Reads the air/gas quality value in kΩ” should be revised because kΩ is a unit of electrical resistance, not a direct unit of air quality. A linguistically and technically precise formulation would be “Returns the gas-sensor resistance in kΩ,” provided that this is the variable actually supplied by the BME680.

Similarly, “air quality (ppm)” does not identify the substance whose concentration is expressed in parts per million. If the MQ135 was not calibrated for a specific gas, the language should not imply a physically validated concentration. In that case, “relative MQ135 sensor response” or “uncalibrated sensor output” would be more accurate, depending on the procedure actually performed.

Expressions such as “sound level,” “air quality value,” “ultraviolet index level,” and “CO₂ concentration level” should be accompanied by an unambiguous variable, unit, and definition. “Concentration level” is generally redundant; “CO₂ concentration” is normally sufficient. “Ultraviolet index level” should be distinguished from “UV index value” only if a defined categorical classification was implemented.

Use of verification and validation terminology

The manuscript uses “verification,” “functional validation,” “operational validation,” “classroom validation,” and “educational validation” without consistently defining these terms. This variation is not merely lexical. “Verification” may refer to confirming that a component performs a specified function, whereas “validation” implies establishing that a system is fit for a defined purpose using appropriate criteria and evidence.

When the reported result is limited to confirming initialization, communication, acquisition, and visualization, “functional verification” or “basic functional testing” is more accurate. “Educational validation” should not be used to describe only the completion of classroom activities when learning, usability, acceptance, or competencies were not measured. The English wording must preserve this distinction so that the manuscript does not imply a stronger level of evidence than was actually obtained.

Moderation of claims

Verbs such as “demonstrated,” “confirmed,” “validated,” “strengthened,” “promoted,” “reduced,” and “facilitated” are used in claims that are not always accompanied by quantitative measurements or comparators. The language should calibrate these verbs according to the available evidence.

When the manuscript only documents that a function was executed, formulations such as “showed that the function could be executed,” “supported the execution of,” “enabled data visualization,” or “was successfully demonstrated under the reported classroom conditions” are appropriate. By contrast, “strengthened competencies,” “reduced programming complexity,” or “improved problem-solving skills” require specific assessments. If such assessments were not conducted, these statements should be reframed as intended uses or design objectives rather than demonstrated outcomes.

Clarity, concision, and repetition

The manuscript repeatedly uses phrases such as “educational electronic boards,” “customized programming blocks,” “contextualized STEM activities,” “real-world environment,” and “first-year university students.” This repetition affects readability and produces lengthy paragraphs that restate the same claim without adding new evidence. Once the components have been defined, shorter and stable terms may be used, provided that they do not introduce ambiguity.

Sections 3 and 4 contain several paragraphs that combine procedure, result, and interpretation within the same unit. Although this is primarily a matter of scientific organization, it also affects linguistic clarity. Sentences should clearly indicate whether they describe an action performed, an observed result, an author interpretation, or a potential application.

Consistency of academic register

Promotional or conclusive expressions that are not fully supported should be avoided, including “reliable communication,” “fully functional,” “effective framework,” “viable educational resource,” and “suitable for strengthening competencies,” unless operational criteria and supporting results are provided. The academic register should remain descriptive and proportional. For example, “communication was established during the reported tests” is more verifiable than “reliable communication” when no failure rate, duration, replication, or stability data are presented.

Verb tense should also be used consistently. The past tense is appropriate for procedures performed and observations made during the study; the present tense may be used for permanent features of the artifact or when interpreting tables and figures. Unsystematic tense shifts may blur the distinction among an executed procedure, a current capability, and a future possibility.

Captions, tables, and graphical blocks

Figure captions should be self-contained and use exactly the same sensor, board, and variable names as the main text. The label “pH Sensor BH1750” in Figure 1 must be corrected because it conflicts with the identification of the BH1750 as a light sensor in Table 1.

Text embedded in blocks and figures is part of the scientific content and must also be edited. Capitalization, units, symbols, language, and correspondence with the source code should be checked. Figure 2 should not display DS18B20 temperature blocks together with code that uses a variable named humedad and an analog reading, because this inconsistency cannot be resolved through stylistic editing alone.

English and metadata in the reference list

The reference list contains inconsistent title formatting, journal names, punctuation, capitalization, and metadata. In addition to verifying the bibliographic information, the English presentation should be standardized according to the journal’s style. Reference [8] is incomplete, reference [22] combines incompatible metadata, and several entries contain typographical errors or insufficient publication information. These inconsistencies reduce both clarity and the professional presentation of the manuscript.

The paper does not require only proofreading. It requires comprehensive academic language editing by a person proficient in scientific English and familiar with educational electronics, sensors, and technological evaluation. The revision should preserve technically valid content, correct the grammar, and ensure that every term and verb accurately represents the strength of the available evidence.

Strictly necessary adjustments to strengthen this version:

Correct grammatical errors, incomplete sentences, and agreement problems throughout the manuscript.
Standardize the names of boards, components, variables, and procedures.
Revise the metrological terminology, particularly wording related to kΩ, ppm, NTU, soil-moisture percentage, CO₂, and sound level.
Consistently distinguish among verification, functional testing, technical validation, and educational validation.
Moderate verbs and qualifiers that currently exceed the evidence presented.
Edit all text embedded in figures, tables, and programming blocks.
Perform a complete final academic-English edit after the scientific and technical revisions have been incorporated.

Author Response

Please see the attached point-by-point response to Reviewer 2's comments. We sincerely appreciate the reviewer's valuable feedback. All comments have been carefully addressed, and the manuscript has been revised accordingly.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

Brief Summary

The manuscript addresses a potentially relevant topic at the intersection of educational technology, open-source hardware, visual programming, and contextualized STEM education. Integrating three custom electronic boards (agriculture, environmental monitoring, aquaculture) with an mBlock-based visual programming interface is a reasonable idea, particularly for low-resource institutions and students with little prior programming experience. It targets first-year university students, with classroom activities on soil moisture, air quality, and water turbidity, following a four-stage problem-solving method (understanding, planning, implementation, review). The principal strength is the attempt to integrate open-source hardware, sensor-based experimentation, block-based programming, and locally contextualized STEM problems into a coherent platform. However, the manuscript currently provides evidence primarily for technical functionality and feasibility, not for educational validation or learning effectiveness. The central claims should be substantially narrowed or backed by additional empirical evidence.

Overall, the manuscript substantially overstates what has actually been "validated." The evidence presented just demonstrates that hardware and software components operate and that students used them in classroom activities. It does not, in its current form, support claims of educational effectiveness, competency development, usability, measurement accuracy, or technological maturity. The methodological description is also insufficient for reproducibility.

General comments

Validation. What's reported is a functional verification — sensors produce readings, data transmits, mBlock displays it so regarding technical and software vailidity — not a validation of an educational technology (do sensors accurately measure the intended variables? And, most of all, pedagogical and didactical aspects: do the activities actually support the intended learning objectives? do students show measurable improvement in relevant competencies?). I suggest to the authors to narrow the scope in line with the data - If the objective is purely technological, this should be made clear by, for instance, clarifying the research gap and formulating a research question - and what is written in the paper, also discussing transferability and limitations.

Data. The manuscript infers that because students searched for information, used sensors, built physical models, programmed in mBlock, and analyzed data, they therefore developed research competencies, computational thinking, problem-solving skills, and technological literacy. This is a weak, speculative and unsupported claim given the data presented. To try to support such claims, the authors should specify at least: (1) the total number of participants; (2) the university course in which students were enrolled; (3) students' previous experience with programming, if available; and (4) the number and duration of sessions conducted during the validation process.

Method. The manuscript reports that students used ChatGPT alongside Google Scholar and Scopus for scientific information gathering. First, for first-year university students, navigating scientific databases and understanding academic literature is not a straightforward task; the authors should therefore explain how this process was implemented, what guidance was provided, and what level of support students received. Second, and more critically, the use of ChatGPT as an information-gathering tool needs explicit methodological description. Specifically, the authors should clarify: Was ChatGPT used as a search tool, a generative assistant for synthesizing information, or both? Were students provided with any framework or training for evaluating potential hallucinations, inaccuracies, or source reliability in AI-generated content? Was the use of ChatGPT standardized across groups (e.g., same account, same prompts, same version), or was it an uncontrolled variable that may have introduced inconsistencies in the information students obtained? If ChatGPT use was part of the educational intervention being evaluated, it must be explicitly described as a methodological component, controlled for, and its potential influence on learning outcomes discussed.

Specific comments

Line 43. Why "low cost"?

Author Response

Please see the attached point-by-point response to Reviewer 3's comments. We sincerely appreciate the reviewer's valuable feedback. All comments have been carefully addressed, and the manuscript has been revised accordingly.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

Second-round review of the revised manuscript: the authors fixed the framing — "validation" became "functional verification" throughout, educational claims were pulled back, health claims removed, ethics statements added, and the scope honestly bounded. However, the evidence itself remains unresolved. All five self-citations (8,10,11,26,31) persist without a comparison table, and the list contains duplicates (8=11, 61=65) and malformed entries. Verification is entirely qualitative — no trial counts, no measured values, no failure logs — and the classroom section still lacks participant data. Recommendation: major revision.

Comments for author File: Comments.pdf

Author Response

Dear reviewer, I have attached the feedback I received.

Thank you very much.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

Dear Authors,

I have carefully reviewed the revised manuscript together with the detailed point-by-point response submitted for this second review round. The revision is substantial and has successfully addressed an important part of the conceptual issue identified previously. In particular, I consider the reframing of the work as a study focused on the design, implementation, and functional verification of an educational technological prototype, rather than as a demonstration of educational effectiveness, to be appropriate. This change significantly improves the alignment among the objective, the type of evidence actually available, and the scope of the conclusions. The expanded hardware and software sections, the explicit incorporation of PCB continuity, power-supply, and firmware execution checks, the revised description of the classroom implementation, and the moderation of claims concerning computational thinking, STEM competencies, and other unmeasured educational outcomes are also meaningful improvements.

The current manuscript is therefore considerably stronger than the previous version. Nevertheless, a detailed technical reading indicates that several issues raised during the previous review have been partially, but not fully, resolved. The remaining concerns relate primarily to the traceability of the functional verification process, consistency among the architecture, figures, components, and sensors, the treatment of outputs expressed in physical units, and the proportionality of several statements relative to the tests actually documented. In my view, these issues are correctable without transforming the manuscript into a different type of study or requiring a new educational-effectiveness experiment.

Traceability of the functional verification

Priority: Essential requirement.

Because the title, objective, and main contribution are now explicitly structured around functional verification, the verification process should be documented in a sufficiently auditable manner.

Section 3.2.4 represents a meaningful improvement because PCB continuity, power-supply verification, and firmware execution are explicitly described. However, in several cases the manuscript still provides a procedural description followed by a statement of successful operation, without fully reporting the evidence required to reconstruct the verification.

For example, the power-supply subsection states that measured values were compared with manufacturer-specified operating ranges, whereas Table 1 reports the nominal ranges rather than the actual values observed during the tests. The manuscript subsequently concludes that all electronic modules operated within their specified voltage ranges. The current presentation therefore does not fully allow the reader to reconstruct the evidence underlying this conclusion.

A similar issue appears in Section 4.3 and Table 5. Statements such as “successful sensor initialization”, “successful communication”, “successful acquisition and visualization”, and “operational readiness” communicate the overall outcome but are not systematically accompanied by explicit acceptance criteria, number of executions, test duration, test conditions, or observed values.

I do not consider a large-scale reliability campaign or extensive new experimentation necessary. A proportionate solution would be to include a compact functional-verification matrix for the critical functions of the three boards, including at least:

board/component;
function or requirement being tested;
test condition/procedure;
expected result or acceptance criterion;
observed result;
number of available executions or repetitions;
Pass/Fail outcome.

Where voltage, initialization, communication, or acquisition records are available, the observed values should be reported. If quantitative records were not retained, this should be stated transparently and the language should be limited to an operational check rather than implying undocumented quantitative verification.

Consistency between the revised scope and Figure 1

Priority: Essential requirement.

The response to the previous review appropriately indicates that unsupported statements concerning improvements in computational thinking, STEM competencies, and educational effectiveness were removed. Section 4 also explicitly states that no instruments were administered to assess these constructs.

However, Figure 1 still contains a box labelled “EDUCATIONAL IMPACT”, including “Computational Thinking” and “STEM Competencies”. This visual representation is inconsistent with the revised methodological scope.

I recommend replacing “Educational Impact” with a non-causal formulation such as:

“Potential Educational Applications”;
“Intended Educational Uses”; or
“Educational Affordances”.

The contents of the box should likewise be restricted to functions or possibilities directly supported by the implementation, such as visual programming, sensor-based experimentation, data acquisition, contextualized STEM activities, and hardware–software interaction.

Variables, units, and metrological scope

Priority: Essential requirement.

The authors appropriately distinguish functional verification from metrological validation and explicitly state that the study does not claim full sensor calibration accuracy. This distinction is scientifically acceptable for the current type of manuscript.

Nevertheless, the same caution must be applied consistently across tables, programming blocks, figures, and results.

A particularly clear example occurs in Table 2 for the NDIR CO₂ sensor. The output is described as a “Relative sensor response” while being assigned the unit ppm, although the table itself states that quantitative CO₂ concentration requires calibration. If the output represents only a relative or processed sensor response rather than a calibrated concentration, ppm should not be used as its physical unit.

A similar issue concerns turbidity. Tables 4 and 5 report turbidity in NTU. If these values are intended to represent quantitative turbidity measurements, the manuscript should identify the transfer function, calibration equation, curve, technical procedure, or manufacturer documentation used to convert the electrical output of the sensor into NTU.

A consistent rule should therefore be applied:

(a) if a technically supported conversion exists, report the exact sensor, equation/curve, parameters, manufacturer reference, or calibration procedure;

(b) if such a basis is not available, report the output as raw sensor output, ADC value, sensor voltage, or relative sensor response, rather than ppm, NTU, or another unit implying calibrated quantitative measurement.

I am not requesting a complete metrological validation. The requirement is simply that the reported unit be proportional to the actual level of calibration and evidence available.

Technical inconsistencies remain among figures and the described architecture

Priority: Essential requirement for adequately closing the current revision.

Although the response states that sensor assignments and terminology were corrected, several relevant inconsistencies remain.

In Figure 2, the functional-design block refers to an “ESP32 Processor”, whereas Table 1 and the hardware-verification description refer to an Arduino Nano and an ESP8266 Wi-Fi Module. The same figure contains “pH Sensor BH1750”, although BH1750 is correctly identified elsewhere as an illuminance/light sensor. The notation “DSB1820 Temperature Sensor” also appears, whereas other sections use DS18B20.

Figure 6 should also be checked because its communication layer identifies “Microcontrollers: ATMega4809”; this designation should be reconciled with the hardware architecture described elsewhere.

I recommend first establishing a master hardware-configuration table and then using it as the single source of truth for revising all figures and tables. For each board, this table should include:

microcontroller;
communication module;
sensor;
manufacturer/model or part number where available;
acquired variable;
electrical/communication interface;
signal type;
unit;
corresponding library/driver.

This would allow the remaining nomenclature inconsistencies to be definitively removed.

Software verification should cover all three boards with comparable traceability

Priority: Important improvement.

Section 3.3.4 provides a concrete description of software-extension verification using BH1750, the NDIR CO₂ sensor, ML8511, KY-037, and MQ135, primarily corresponding to the Environment Board.

However, the conclusions and Table 5 also cover the Agriculture Board and Aquaculture Board. To support the claim of integration across all three boards with comparable evidence, the corresponding extensions for Agriculture and Aquaculture should be documented at a minimum equivalent level.

This does not require numerous additional screenshots. A consolidated table could report, for each board:

sensor;
customized block;
function;
input;
output;
unit;
library/driver;
functional test;
result.

Classroom implementation requires additional minimum contextual information

Priority: Important improvement.

The revised version provides a substantially clearer description of the classroom implementation. First-year university students, groups of five students, and contextualized activities in agriculture, environment, and aquaculture are now described.

However, several minimum contextual parameters are still needed to interpret the phrase “functional verification under authentic classroom conditions”, including:

total number of students;
number of groups;
number of sessions;
approximate duration;
course or subject;
number of boards available;
board allocation across groups;
approximate number of executions of each activity;
level of instructional/technical assistance provided.

The term “heterogeneous groups” should also either be operationally defined or replaced by the more neutral “groups of five students”.

These details are not requested to transform the manuscript into an educational-outcomes study or to support statistical inference. Their purpose is solely to improve the auditability of the functional-verification setting.

Clarify the methodological status of DSR, the V-model, and waterfall

Priority: Important improvement.

Section 3.1 states that Design Science Research served as a conceptual reference, the V-model guided hardware development, and waterfall was adopted as a sequential reference for software development.

This combination may be reasonable, but the current manuscript does not fully establish whether these frameworks were formally implemented or simply used to inform the engineering workflow.

Please clarify:

which stages specifically derive from DSR;
which design–verification correspondences of the V-model were actually implemented;
which software-development phases correspond to waterfall;
how the three references are integrated within a single engineering process.

The supporting references should also be checked carefully to ensure that they directly substantiate the methodological claims. If the frameworks were not formally implemented in their entirety, a more accurate formulation may be that the workflow was “inspired by” or “informed by” these engineering references.

Add a technical discussion and explicit limitations

Priority: Important improvement.

The manuscript currently provides extensive implementation and integrated-verification results but moves from Section 4.3 directly to the Conclusions. A concise Discussion and Limitations subsection would substantially strengthen the paper.

This section should interpret rather than repeat the results and should address:

the technical advantage of the customized PCBs compared with conventional development-board/external-wiring configurations;
the specific contribution of the customized mBlock extensions;
which components of the architecture are reusable;
which limitations remain;
how the proposed solution relates to the technological approaches reviewed in the literature.

At minimum, the limitations should acknowledge:

absence of complete metrological validation/calibration;
absence of educational-outcomes assessment;
absence of long-duration reliability/stress testing;
implementation limited to the reported classroom setting;
restricted availability of complete manufacturing/reproduction files for the customized PCBs, if applicable.

Figure 8 and reference traceability

Priority: Important improvement.

The clarification introduced for Figure 8 is appropriate because the text now explicitly states that the cause-and-effect diagram summarizes literature-derived factors rather than causal relationships measured in this study.

Nevertheless, the figure contains author/year references such as NESTARES (2024), OLAIZ (2019), ORTEGA & RUIZ (2021), BENITES et al. (2024), VALDEZ et al. (2021), and WHO/OMS (2024). These sources should be fully and unambiguously traceable in the final reference list.

I recommend:

ensuring that every source appearing in the figure is present in the references;
verifying exact author/year correspondence;
citing the relevant sources in the figure caption or surrounding text;
explicitly identifying the figure as a student-generated classroom artifact based on reviewed literature, rather than an empirically derived causal model produced by the authors.

Use of the term “open-source hardware”

Priority: Important precision improvement.

The authors' response appropriately clarifies that the manuscript no longer implies that complete manufacturing files are publicly distributed. This distinction should be consistently preserved throughout the paper.

Where openness relates specifically to Arduino, libraries, development tools, or other underlying platforms, wording such as:

“prototype based on open-source hardware platforms”

would be more precise than implicitly characterizing the entire customized PCB design as open-source hardware if schematics, Gerber/BOM files, CAD sources, and a hardware license are not publicly available.

Moderate claims concerning stability and reliability

Priority: Important scope improvement.

Terms such as “stable interface”, “stable system operation”, and “stable and functional technological platform” should be used only when specific stability, duration, failure-rate, or reliability evidence is available.

The current evidence supports the conclusion that the system operated successfully during the reported tests and classroom activities. This is not necessarily equivalent to demonstrated engineering stability.

More proportionate wording would include:

“operated correctly during the reported tests”;
“functioned as intended under the evaluated conditions”;
“demonstrated successful hardware–software interaction during the reported implementation”.

This issue can be addressed through language calibration and does not necessarily require new experiments unless specific stability data are already available.

Final reference and editorial-statement audit

Priority: Important improvement.

A final citation → claim → reference audit is recommended, with particular attention to:

sources supporting DSR, the V-model, and waterfall;
references embedded in Figure 8;
incomplete or potentially duplicated entries;
DOI and bibliographic metadata;
consistency between in-text citations and the reference list.

The Data Availability Statement should also be reviewed. “Data is contained within the article” should be retained only if the data underlying the reported verification are actually contained in the article. If the work primarily generated technical verification evidence rather than a distinct research dataset, the statement should be adapted accordingly.

Finally, because participant photographs are included and informed consent is reported, the authors/editorial office should ensure that the consent obtained covers image publication where required. No additional ethical statement should be added unless it accurately reflects the procedure that was actually followed.

The authors have responded substantively to the previous review, and the revised scope represents an important methodological improvement. I do not consider it necessary to reopen the requirement for an educational-effectiveness study, because the manuscript now appropriately positions itself as a technological-development and functional-verification study.

The remaining concerns are principally related to engineering traceability, internal technical consistency, and proportionality of claims. They are important because functional verification is now the core claim of the paper, but they appear reasonably correctable through improved technical documentation, harmonization of figures and tables, appropriate treatment of measurement units, moderation of terminology, and an explicit discussion of limitations.

For these reasons, my recommendation remains Major Revision.

The highest-priority actions for the next version are:

document functional verification using a requirement–test–criterion–result matrix;
resolve all hardware/sensor inconsistencies across Figures 1, 2, and 6, tables, and text;
justify or correct ppm, NTU, and any other units requiring calibration;
remove “Educational Impact” and unmeasured constructs from Figure 1;
document the software extensions for all three boards with sufficient traceability;
complete the minimum contextual information for the classroom implementation;
clarify the use of DSR, the V-model, and waterfall and audit their supporting references;
add a technical discussion and limitations;
ensure full reference traceability for Figure 8 and perform a final citation/reference audit.

Author Response

Dear reviewer, I have attached the feedback I received.

Thank you very much.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The revised manuscript has addressed the main concerns raised in the first review. The authors have also clearly outlined the principal changes in the cover letter. The revised version substantially improves the alignment between the research aims, methodology, evidence, and claims.

In particular:

1) Educational claims have been moderated throughout the manuscript; the research gap has been clarified, better positioning the contribution with respect to existing educational technology and STEM-oriented platforms; and the research question and study objectives have been better aligned with the actual evidence collected, making it clearer that the study focuses primarily on the design, implementation, and functional verification of the prototype, rather than on measuring its effects on students' learning.

2) Transferability has been addressed more explicitly, discussing the contextual nature of the prototype and the extent to which the proposed approach could be transferred to other educational settings, while acknowledging that broader validation is still required.

3) The limitations have been substantially clarified, acknowledging the absence of quantitative measures of learning outcomes, usability, technology acceptance, and educational effectiveness, as well as the need for validation with larger and more diverse student populations.

4) The methodology and verification procedure have been strengthened. The revised version distinguishes more clearly between hardware verification, software verification, integrated functional verification, and classroom implementation, providing a more coherent account of how the prototype was tested. The technical contribution is now more clearly documented; additional details concerning the hardware architecture, software architecture, communication layers, programming blocks, and functional testing improve the reproducibility and technical clarity of the study.

5) The conclusions are better aligned with the results. The revised manuscript avoids drawing strong conclusions about educational impact that are not directly supported by the study design, and instead focuses on the demonstrated technical feasibility of the proposed system.

Author Response

Dear reviewer, thank you very much

Round 3

Reviewer 1 Report

Comments and Suggestions for Authors

Thank you for this third revision. I have verified it point by point against my second-round comments, and I am pleased to confirm that the two critical issues and most of the remaining concerns have been resolved. In particular:

The citation problem has been fixed: the duplicated reference (Sustainability paper cited twice), the duplicated ISO/IEC 15288 entries, the malformed author lists, and the stray "]" in reference [1] have all been removed, and the self-citations were reduced from five to none (65 → 57 references).
The verification sections are now honest and structured: Tables 2 and 6 document test procedure, acceptance criterion, observed result, record availability, and outcome, and the text clearly states that the records correspond to documented operational checks rather than a repeated-trial reliability campaign. Table 1 is correctly presented as specified operating-voltage requirements.
The classroom section now reports participant information (69 first-year Nursing students, UNAT, 16 weekly sessions of four hours, groups of approximately five members) and is explicitly framed as a feasibility demonstration, with the corresponding limitations discussed in the new Discussion section.
Sensor outputs are consistently interpreted as indicative responses, with calibration caveats stated in the tables, in Section 4.3, and in the limitations paragraph.
The claims regarding novelty and performance have been appropriately tempered: the manuscript now explicitly states that no controlled quantitative comparison with conventional Arduino-based configurations was conducted and makes no superiority claims.
The incorrect ISO 15288 / V-model / Waterfall citations were removed.

The manuscript is close to being publishable in its present form. The following changes are required before final acceptance. They are all minor and do not require additional experimentation:

Report measured values where records exist. In Sections 3.2.4 and 4.3, include a representative sample of measured values from the retained laboratory records and classroom screenshots (e.g., voltages, soil-moisture readings, turbidity responses, MQ135 responses), with the conditions under which they were taken. If no measured-value records were retained, state this explicitly in one sentence in each section.
Clarify the relationship with your prior work. Since the previous self-citations were removed, please add one or two sentences (Introduction or Discussion) stating whether the boards described in this manuscript are the same as those reported in your earlier publications, iterations of them, or a new development.
Describe the ChatGPT verification procedure (Section 4.1). Please add a short paragraph explaining how the information generated by ChatGPT was verified against scientific publications: who performed the verification and by what procedure. Please also include the required acknowledgement of AI tool use in the design of the classroom activities.
Reframe "public-health implications" (Section 4.1, Figure 8). Please change this wording to "environmental and drinking-water quality implications."
Informed Consent Statement. Please specify whether participation was opt-in or opt-out.
Literature review synthesis. Please add a brief paragraph at the end of Section 2.4 connecting the functional-verification frameworks discussed in the review to the verification protocol adopted in Section 3.
Reference formatting and language. Please correct the remaining errors in the reference list (e.g., "REvista de Educación Superior," reference [49]; the author field of reference [50]) and perform a final language pass.

I am confident these changes can be completed without further experimentation, and I will be happy to recommend acceptance once they are incorporated.

Author Response

Dear Reviewer,
Thank you for your careful review and constructive comments. We have addressed all the observations and revised the manuscript accordingly. The corresponding changes are highlighted in the revised manuscript, and detailed responses are provided point by point.

We appreciate your valuable suggestions, which have helped improve the clarity and technical precision of the manuscript.

Sincerely,
The Authors

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

Dear Authors,

I have carefully reviewed the revised manuscript together with the response to Reviewer 2 and the supplementary ethical documentation. The new version shows substantial improvement compared with the manuscript previously evaluated. In particular, the authors have more accurately defined the nature and scope of the contribution: the work is now consistently presented as the design, implementation, integration, and functional verification of a technological prototype at the hardware, software, and integrated-system levels, rather than as evidence of educational effectiveness, complete metrological validation, long-term reliability, or superiority over conventional configurations.

Several previous concerns have been adequately addressed. These include correction of inconsistencies in the hardware architecture; revision of Figure 1 to remove unsupported claims concerning “Educational Impact”; clarification that Figure 8 is a student-generated classroom artifact and that the references visible within the figure are not citations introduced by the manuscript authors to support the study findings; clarification of the Environment Board as a representative case for software-level functional verification; more complete reporting of the classroom implementation conditions; appropriate moderation of the metrological interpretation of the MQ135, turbidity, and soil-moisture sensor outputs; and the addition of a Discussion section explicitly acknowledging the main limitations of the study.

Overall, these revisions have substantially improved the alignment among the objective, evidence, results, discussion, and conclusions. Nevertheless, several specific issues remain and should be addressed before the revision can be considered complete. These issues do not require redesigning the study or conducting an extensive new experimental campaign. They primarily concern documentary traceability, technical reproducibility, alignment between the available evidence and the wording used, and a small number of residual inconsistencies.

1. Traceability of the functional-verification matrices (Tables 2 and 6)

The addition of the verification matrices is an important improvement. However, the evidence underlying each “Pass” outcome is not yet fully auditable. In Table 2, several rows identify the available evidence only as “One documented laboratory test record”, whereas Table 6 uses the wording “Functional execution documented; repetition count not retained”. These statements indicate that some documentation exists, but they do not allow the reader to identify unambiguously which specific record supports each board, function, test procedure, and outcome.

Because the central contribution of the manuscript is explicitly framed as “functional verification”, the traceability among the test procedure, acceptance criterion, observed result, supporting record, and Pass/Fail outcome is technically important.

I do not consider new experimental repetitions necessary if repetition data were not retained. The minimum required correction is to identify the available evidence through an unambiguous reference for each applicable test, for example Figure X, supplementary record H01, photograph/test record, log file, laboratory record, or another suitable identifier. If an individual record was not retained for a particular function, this should be stated explicitly and the corresponding claim should be limited accordingly rather than implying a greater degree of documentary traceability than is actually available.

In particular, the authors should verify that each “Pass” reported in Tables 2 and 6 can be traced directly to an observed result and a previously defined acceptance criterion.

2. Residual wording still exceeds the evidence provided by a non-repeated functional-verification exercise

In their response, the authors appropriately state that the manuscript was revised to avoid characterizing the experimentally demonstrated performance as stable, reliable, or robust because no repeated-trial reliability campaign, long-duration operation, or stress testing was performed. This methodological decision is appropriate. However, several expressions that are not fully consistent with this limitation remain in the revised manuscript.

For example, Section 3.2.3 states that the dedicated PCBs “improved system stability” and “increased operational safety”. Section 3.3.4 states that the extensions provide a “stable interface”. Section 4.3 further states that the prototype “consistently executed” sensor initialization, data acquisition, and real-time visualization, and refers to “operational readiness”.

These expressions respectively imply comparative stability, improved safety, interface stability, consistency across executions, or a level of operational maturity that cannot be established from functional records without retained repetition counts, failure rates, long-duration testing, or an appropriate comparator.

I recommend a final manuscript-wide search for terms such as “stable”, “stability”, “reliable”, “reliability”, “robust”, “robustness”, “consistent”, “consistently”, “safety”, and “operational readiness”. These terms should be retained only where they clearly describe a design objective or architectural property and are not presented as an experimentally demonstrated performance outcome.

Where the statements refer to observed results, more evidence-proportional wording would be preferable, such as “operated as intended during the documented test conditions”, “successful functional operation was observed”, or “the hardware–software interaction was successfully demonstrated under the reported conditions”. This change would not diminish the contribution; it would align the strength of the wording with the actual study design.

3. Power Supply Verification: distinguish nominal compatibility from experimental voltage measurement

The revision of Table 1 is an important improvement because the manuscript now clarifies that the listed values correspond to specified operating-voltage requirements and should not be interpreted as a complete record of experimentally measured voltages.

However, the text immediately following the table still states that the verification “confirmed that all electronic modules operated within their specified voltage ranges”. If quantitative voltage measurements for each component or board were not retained, this statement remains stronger than the evidence presented.

The manuscript should clearly distinguish among:

(a) continuity/short-circuit checking;
(b) verification that the nominal 5 V and 3.3 V power architecture is compatible with the specified operating requirements of the installed components; and
(c) experimental measurement of the voltages actually delivered to the components.

If only (a) and (b) are documented, the text should be restricted to those two verification steps. The statement that the modules “operated within their specified voltage ranges” should be retained only if experimental measurements are available to support it.

4. Minimum technical reproducibility of the hardware–software implementation

The architecture is described substantially more clearly in the revised version. Nevertheless, because the contribution depends on the integration of customized boards, firmware, libraries, extensions, and the mBlock environment, several minimum implementation details should still be reported to support reasonable technical reproducibility.

Where applicable to the system actually used, the authors should identify:

- the mBlock version;
- the mBlock Extension Builder version or equivalent development environment;
- the firmware version or identifier;
- the principal C++ libraries and relevant versions when these affect reproducibility;
- relevant communication configuration or parameters; and
- the identifiers of the customized extension files or associated source code.

I am not requesting an exhaustive description of the development environment or mandatory public release of all technical files. The objective is to allow a technically competent reader to determine which configuration was actually implemented and to distinguish it from later or alternative configurations.

This point is also related to the Data Availability Statement. The wording “These resources may include relevant PCB design documentation, bill of materials, and software resources” is too indeterminate. The authors should state specifically which resources exist and which can actually be provided upon reasonable request. If schematics, Gerber files, BOMs, firmware, mBlock extension files, customized libraries, or functional-test records are available, only those resources that can genuinely be provided should be identified. Materials that are not available should not be implicitly promised.

5. Residual metrological inconsistency in Table 3

The revision of the metrological scope is an important improvement. The MQ135 output is now appropriately interpreted as a relative response where no calibration against a reference gas concentration was performed, and the turbidity sensor output is no longer presented as a validated NTU measurement when no reference calibration was conducted.

However, Table 3 still appears to require clarification regarding the DFRobot CO₂ NDIR sensor. The table uses the label “Relative sensor response” together with the unit “ppm”, while the accompanying description states that quantitative CO₂ concentration requires calibration.

These statements should be reconciled. The authors should specify what the output generated by the implemented block actually represents:

- an ADC reading or relative response;
- a voltage;
- an estimated ppm value obtained using a manufacturer-provided conversion or algorithm but not independently calibrated in the present study; or
- a quantitatively calibrated concentration.

Only the last category should be presented as a validated quantitative concentration measurement. If the software produces a nominal ppm estimate using a manufacturer-provided conversion, this may be reported as such, but it should be explicitly distinguished from an independently calibrated concentration measurement. If the variable is strictly a relative sensor response, assigning “ppm” as its unit is conceptually inconsistent.

6. The clarification regarding previous programming experience provided in the response should also appear in the manuscript

The response to the reviewer states that previous programming experience was not used as a participant-selection criterion and was not formally assessed as part of the study. This is an appropriate methodological clarification, but it should also be explicitly incorporated into the manuscript section describing the participants and classroom implementation conditions.

This is relevant because the manuscript also states that the graphical programming blocks were intended to be easily understood by first-year university students. Since ease of understanding was not formally evaluated and previous programming experience was not assessed, this statement should be presented as a design intention rather than as a demonstrated outcome.

For example, rather than stating that the blocks “could be easily understood by first-year university students”, it would be more precise to state that “the blocks were designed to facilitate their interpretation and use by first-year university students”.

7. Final citation-to-claim audit

I recommend a final systematic review of the correspondence between individual claims and the references attached to them. The issue does not appear to be an overall lack of references, but rather that several specific references do not appear to provide direct support for the particular statements to which they are linked.

Three examples that warrant verification are:

- Reference [9], cited in relation to the research gap concerning integrated educational prototypes, corresponds in the reference list to a study on the adaptation of Technology Readiness Levels for implementation sciences.
- Reference [26], cited in the context of mBlock capabilities and the development of customized extensions or functionalities, corresponds in the reference list to a study on computational thinking and gender.
- Reference [50], cited to support a list of technical aspects of functional verification, corresponds to a usability-testing study of a microlearning system.

I do not imply that these references have no indirect relevance to the broader topic. The issue is whether they directly support the specific proposition for which they are cited. Where they do not, the authors should replace them with an appropriate source, relocate them to a statement that they actually support, or moderate/reformulate the corresponding claim.

There is no need to increase the number of references artificially. The objective should be to ensure that every citation serves a verifiable function and that no claim is more specific than the supporting source.

8. Ethical statement: clarify the timing and nature of the exemption letter

The supplementary documentation indicates that the UNAT Research Ethics Committee issued an Ethical Exemption Letter stating that formal ethical approval was not required because the research was conducted as part of standard academic activities, involved no clinical, biomedical, or invasive procedures, and used anonymously and voluntarily collected data.

However, the classroom implementation took place during the 2025 academic year, whereas the Ethical Exemption Letter is dated 20 August 2026. This temporal difference does not, by itself, demonstrate an ethical problem. Nevertheless, the sequence should be described precisely so that the Institutional Review Board Statement cannot be interpreted as indicating prospective ethical approval obtained before the classroom implementation.

If this accurately reflects the actual sequence, the manuscript should state that the committee subsequently issued an exemption letter confirming that formal ethical approval was not required for the study. This exemption should remain clearly distinguished from the separate statement concerning informed consent.

I do not consider a new ethical approval necessary on the basis of the documentation provided; the required correction concerns transparency and precise reporting of the documentary sequence.

9. Consistent terminology for the four activity phases

A minor terminology inconsistency remains between the general description of the classroom activities and Section 4.1. One part of the manuscript describes the sequence as “Problem Understanding, Activity Development, Activity Execution, and Solution Review”, whereas Section 4.1 refers to “problem understanding, planning, implementation, and solution review”.

If these formulations represent the same four-stage procedure, a single terminology should be used consistently throughout the manuscript, associated tables/figures, and response to reviewers. If they represent different procedures, the distinction should be explicitly explained.

The revised manuscript has reasonably addressed the substantive concerns raised in the previous review and now presents a substantially more appropriate scientific delimitation of its contribution. The available evidence supports the design, implementation, and functional integration of the prototype under the documented conditions. It does not establish educational effectiveness, complete metrological performance, long-term reliability, robustness, or superiority over alternative architectures, and the revised version now appropriately acknowledges most of these boundaries.

The remaining issues are specific and correctable. Priority should be given to ensuring that every “Pass” outcome is traceable to the evidence actually available; removing the remaining statements concerning stability, consistency, comparative performance, or operational maturity that exceed the tests performed; correcting the residual metrological inconsistency; providing the minimum technical information necessary for reproducibility; verifying citation-to-claim correspondence; and harmonizing the methodological and ethical clarifications between the response letter and the final manuscript.

I do not consider it necessary to transform the manuscript into an educational-effectiveness study, conduct a new participant intervention, or perform an extensive new reliability campaign to resolve these points. Where additional evidence does not exist, the scientifically appropriate solution is to delimit the claim and state precisely what was actually verified.

Author Response

We appreciate your valuable suggestions, which have helped improve the clarity and technical precision of the manuscript.

Sincerely,
The Authors

Author Response File: Author Response.pdf