{"id":"efa1595d-52a7-4b84-8dba-7e2c626952b4","arxiv_id":"2411.17733","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Raw-signal neural networks are the most energy-efficient option for embedded acoustic emission classification, beating feature-based models by 52-71x on energy because feature extraction dominates the total time.","lead":"This paper compares two ways of classifying acoustic emission signals on a small microcontroller: feeding the raw waveform into a neural network versus first extracting hand-crafted features. It finds that the raw-signal approach uses far less total time and energy because feature extraction is very expensive, at the cost of a larger memory footprint.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Reported feature-extraction times (e.g., 344 ms for eight O(n) time-domain features on 1000 samples) are implausibly high for optimized C on a 64 MHz Cortex-M4, suggesting the custom C implementation is not comparably optimized to the TFLM int8 inference kernel; if so, the raw-signal speed/energy…","rationale":"The reader's verdict is CONDITIONAL, and our stress-test supports that conditionality, but for a different primary reason. The reader focused on the energy estimate assuming constant datasheet power. That is a valid concern, but the energy ratios are so dominated by the time ratios (50–70x) that even a 2x power difference during feature extraction would not overturn the qualitative ordering. The more load-bearing issue is the fairness of the feature-extraction time itself: the reported 344 ms for eight simple O(n) features is implausibly high for optimized code on the target MCU, suggesting the comparison may not be apples-to-apples with the heavily optimized TFLM int8 inference kernel. If the feature-extraction C code is unoptimized (e.g., using pow() and double precision), the central claim that 'embedded feature extraction is computationally expensive' is an artifact of implementation rather than a robust property of the feature-based approach. This is directly testable by reimplementation, and the paper currently provides no evidence of optimization effort beyond a self-description. We therefore keep the CONDITIONAL verdict, with the additional condition that the authors either provide the feature-extraction implementation details/optimization flags or rerun the comparison with a demonstrated optimized implementation. Our agreement with the reader is partial because we share the sense that the headline claim is not yet fully supported, but we identify a different—and we believe more decisive—weak link.","tokens_in":8575,"tokens_out":7051,"duration_ms":71020,"concrete_test":"Reimplement the 8 time-domain features (mean, std, skewness, kurtosis, zero-crossing rate, RMS, peak-to-peak distance, positive turning) in optimized C on the same Arduino Nano 33 BLE Sense (nRF52840 at 64 MHz), using single-pass variance and explicit multiplication for integer powers, and with all features computed from the same 1,000-sample inputs as the paper. Measure total feature-extraction time with micros() exactly as in Section II-E. If the optimized time is below, say, 10 ms (vs. the reported 344,106 µs), the paper's total-time and energy comparisons are not representative of well-optimized feature extraction; the authors should either replace their C code with a comparably optimized implementation and rerun the complete comparison, or explicitly document the algorithm choices that make their 344 ms figure a fair baseline.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central quantitative claim in Table II is that raw-signal models have total times of 6,656 µs versus 345,036 µs (8-feature) and 472,704 µs (6-feature), leading to 52–71x energy differences. The raw-signal time comes from an optimized int8 TFLM kernel, while the feature-model times come from custom C feature-extraction code whose optimization is not demonstrated. For eight O(n) time-domain features (mean, std, skewness, kurtosis, ZCR, RMS, peak-to-peak, positive turning) over 1,000 samples, 344 ms is roughly 200x slower than a straightforward floating-point implementation on the same 64 MHz Cortex-M4F. The likely cause is the use of software double-precision math and generic pow() calls (e.g., pow(x,4) for kurtosis), which is not representative of carefully optimized embedded feature extraction. The paper states feature extraction was 'optimized C-code' but reports no clock frequency, compiler flags, or algorithm complexity, and it never benchmarks against CMSIS-DSP or other standard optimized libraries. If feature extraction were implemented with single-pass integer/float algorithms and explicit multiplications (x*x*x*x), its time could drop by one to two orders of magnitude. That would shrink the total-time gap and the derived energy gap, undermining the conclusion that embedded feature extraction is inherently computationally expensive and that raw-signal models are overwhelmingly better on speed/energy. This is more load-bearing than the reader's constant-power energy concern: even with the datasheet power assumption unchanged, the headline 'fastest processing speed' depends directly on the feature-extraction timing, which is the measured quantity most vulnerable to implementation artifact.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript compares three approaches for classifying acoustic emission (AE) signals on a low-power embedded platform (Arduino Nano 33 BLE Sense / nRF52840): (i) a fully-connected ANN operating on 1000 raw signal samples, (ii) an ANN on six selected time/frequency-domain features, and (iii) an ANN on eight time-domain features. All models are trained with Keras, quantized to int8 with TFLM, and deployed. The paper reports test accuracies of 0.996, 0.992, and 0.991, respectively. The central quantitative claim (Table II) is that the raw-signal model has a total processing time of 6,656 µs and energy 0.073 mJ per inference, versus 472,704 µs / 5.19 mJ for the 6-feature model and 345,036 µs / 3.79 mJ for the 8-feature model, leading to the conclusion that feature extraction dominates and that raw-signal models are overwhelmingly faster and more energy-efficient at the cost of larger memory.","tokens_in":8927,"tokens_out":5878,"duration_ms":52871,"significance":"If the reported comparison is fair, the paper provides a valuable practical result for TinyML-based structural health monitoring: an int8-quantized fully-connected network on raw waveforms can outperform a feature-engineering pipeline on the same microcontroller, and excluding frequency-domain features can give a better accuracy/energy trade-off than including them. The work uses a public dataset, reports confusion matrices, and evaluates on a real deployment target, which are all strengths. The main caveat is that the headline speed/energy advantage depends on two premises that are not yet demonstrated: (1) the feature-extraction C code is comparably optimized to the TFLM inference kernel, and (2) power consumption is constant across both phases. As written, these premises are asserted rather than verified, so the quantitative conclusions are not yet established at the level the paper claims.","major_comments":[{"comment":"The feature-extraction timings in Table II (471,937 µs for six features, 344,106 µs for eight features) are implausibly high for the stated workload. Eight O(n) time-domain features over 1,000 samples (mean, std, skewness, kurtosis, ZCR, RMS, peak-to-peak, positive turning) should take on the order of milliseconds on a 64 MHz Cortex-M4F with straightforward floating-point code; 344 ms is roughly two orders of magnitude slower, suggesting either a software double-precision / pow()-heavy implementation or unoptimized loops. The paper states 'optimized C-code' but reports no clock frequency, compiler flags, algorithm complexity, or comparison against a standard optimized library such as CMSIS-DSP. Because the headline comparison is total time and energy, the raw-signal model's advantage may be an artifact of the particular feature-extraction implementation rather than an intrinsic property of feature extraction. Please benchmark the feature extraction against an optimized reference implementation, report the implementation details, or substantially temper the conclusion.","section":"Section II-E and Table II"},{"comment":"Energy consumption is estimated from datasheet power values, but no datasheet current/power value is reported, and no measurement is taken. The energy columns in Table II are obtained as power × time under an implicit constant-power assumption. If the floating-point feature-extraction code draws more current than the int8 TFLM kernel, the 52–71x energy ratios would shrink; if it draws less, they would grow. Please provide the assumed power value, add a sensitivity analysis, or include direct current measurements for both the inference and feature-extraction phases.","section":"Section II-E and Table II"},{"comment":"The 6-feature model is not well defined. The text lists only five features ('variance', 'kurtosis', 'peak-to-peak distance', 'negative turning', 'FFT mean coefficient'), while the architecture in Fig. 3b and Table I refer to a 6-dimensional input. Please identify the missing feature; as written, the model input is ambiguous and the experiment cannot be reproduced.","section":"Section II-D and Fig. 3"},{"comment":"The feature-selection step does not state whether RFE was performed on the training partition only. The phrase 'conducted on the entire set of 28 features' appears to refer to the feature set rather than the data samples, but the text does not explicitly rule out using the test partition for feature selection. If the test partition influenced the choice of the 6- and 8-feature sets, the accuracies in Table I would be optimistically biased. Please clarify the data partitioning used for RFE and, if necessary, re-run feature selection within the training set only.","section":"Section II-C"}],"minor_comments":[{"comment":"The x-axis label 'Value (log)' in panel (a) is ambiguous; specify the base of the logarithm and the exact transformation applied.","section":"Fig. 2"},{"comment":"The statement that each C feature function was 'meticulously evaluated against the initial Python code' would benefit from a tolerance or verification protocol to support reproducibility.","section":"Section II-E"},{"comment":"The phrase 'energy consumption of 71x and 52x of the raw-signal model' should read '71x and 52x that of the raw-signal model' for clarity.","section":"Conclusions"},{"comment":"The Flash/RAM sizes are reported for the deployed models, but it is not stated whether the feature-extraction code is included in the Flash size for the feature-based models; please clarify what is included in the reported memory numbers.","section":"Table II"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is within scope for an embedded/TinyML venue. The main risk is that the central comparison is not apples-to-apples: the feature-extraction implementation appears far slower than expected, and the energy estimates rest on an unverified constant-power assumption. The authors should be encouraged to provide the feature-extraction implementation details, an optimized reference benchmark, and current measurements. I would also verify that feature selection does not leak test-set information."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The useful nugget in this paper is the first apples-to-apples comparison of raw-waveform and hand-crafted-feature ANNs for acoustic emission classification on a Cortex-M4, with accuracies, model sizes, and timings. The dataset is public, the confusion matrices look consistent, and the result that eight time-domain features match a set containing an FFT feature is a nice, reproducible observation.\n\nBut the central speed/energy claim has a fairness problem. The raw-input model runs on int8 TFLM, a heavily optimized inference engine. The feature models run on hand-written C that the paper calls 'optimized' but gives no clock frequency, compiler flags, or microbenchmark. Eight O(n) time-domain features over 1000 samples taking 344 ms is roughly two orders of magnitude slower than a straightforward float implementation on the same 64 MHz M4F. That points to double-precision math and pow(x,4) for kurtosis rather than any inherent cost of feature extraction. If the features were implemented with single-pass integer arithmetic or CMSIS-DSP, the 52-71x speed and energy gap would shrink dramatically, and the paper's main conclusion would wobble.\n\nThe reader flagged the constant-power energy assumption, which is real but secondary: energy is time times a datasheet current, so it inherits the timing problem. More minor issues: the 6-feature set lists only five features, leaving the model input ambiguous; and RFE appears to run on the full dataset before the train/test split, which could leak test information into feature selection. Both are fixable.\n\nCredit where due: the classification results themselves (all over 99%) are plausible, the models are small enough for the target node, and the comparison of memory footprints is useful. The paper is honest in that it reports its methods, but the missing benchmark details are exactly what matters for an empirical claim like this.\n\nBottom line: this deserves peer review, but only if the authors are pushed to redo the feature-extraction timing with a properly optimized implementation and to report measurement conditions. I would not cite the energy conclusion until that is done. Worth a reading-group discussion, though, because the failure mode is instructive.","headline":"Useful empirical comparison, but the headline speed/energy claim likely rests on an unoptimized feature-extraction implementation that makes the comparison unfair.","tokens_in":9472,"tokens_out":2413,"would_cite":false,"duration_ms":24469,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that for embedded acoustic-emission classification, feeding raw waveforms to a tiny neural network yields 52-71x lower energy per prediction than feature-based inputs, at the cost of a larger memory footprint.","keywords":["TinyML","acoustic emission","structural health monitoring","feature extraction","embedded machine learning","energy consumption","edge inference","concrete damage classification"],"falsifier":"Measure the nRF52840's current draw separately during int8 inference and during floating-point C feature extraction, then recompute energy per prediction using the per-phase currents and the durations in Table II; if feature extraction's current substantially exceeds inference current, the raw-signal model's energy advantage shrinks toward or below the time ratio of 52-71x.","tokens_in":8392,"feed_emoji":"⚡","tokens_out":5573,"duration_ms":50726,"temperature":0.7,"pith_summary":"This paper asks a practical question for deploying machine learning on battery-powered structural-health sensors: should a microcontroller classify acoustic-emission signals from raw waveforms, or from a small set of engineered features? On a standard Arduino-class board, the authors find that all three compared models classify concrete damage types with over 99% accuracy, but the choice is decided by the whole pipeline, not the neural network alone. The raw-signal model, which skips feature extraction, completes a prediction in about 6.7 ms and consumes about 0.073 mJ, while feature-based models spend 345-473 ms extracting features and consume 3.79-5.19 mJ per prediction. The paper concludes that raw-signal input is the preferred TinyML approach for this application when the larger memory footprint is acceptable.","feed_headline":"Raw-signal AI beats feature extraction 52-71x on energy","feed_subtitle":"On a low-power microcontroller, feature extraction dominates processing time; skipping it makes structural health monitoring…","key_machinery":"The comparison's load-bearing mechanism is the embedded feature-extraction pipeline: custom C implementations of statistical, temporal, and frequency-domain features (with an FFT library for the frequency features) running on the microcontroller before the neural net. Because this pipeline runs in floating point on every captured signal, its execution time dwarfs the int8-quantized inference kernel, making feature extraction the bottleneck that determines total time and energy. The models themselves are feed-forward ANNs with two hidden layers, optimized by hyperparameter search and quantized to 8-bit integers for microcontroller deployment.","core_discovery":"On an Arduino Nano 33 BLE Sense (nRF52840, Cortex-M4), the authors deploy three int8-quantized feed-forward neural networks for classifying acoustic emissions from a concrete block as tensile, shear, or mixed damage. The raw-signal model takes 1000 samples per waveform as input and reaches 99.6% test accuracy with 66,243 parameters; the 6-feature and 8-feature models reach 99.2% and 99.1% accuracy with 6,979 and 9,283 parameters. Pure inference is faster for the feature models (767-930 microseconds vs 6,656 microseconds), but the embedded feature-extraction code dominates: 471,937 microseconds for the six time/frequency features and 344,106 microseconds for the eight time-domain features. Consequently the raw-signal model's total processing time is 6,656 microseconds versus 345,036-472,704 microseconds, and its estimated energy per inference is 0.073 mJ versus 3.79-5.19 mJ, a 52-71x advantage.","pith_inferences":["If the energy estimate were refined by measuring actual current during feature extraction and inference separately, the qualitative ranking would likely stand, but the 52-71x margin is only as accurate as the fixed-power assumption.","The same 'preprocessing dominates' effect should generalize to other edge-sensing applications: any expensive signal-conditioning step on a microcontroller can outweigh a small neural network, so system cost, not model cost, should drive architecture choices.","A direct testable extension would replace the custom floating-point C feature extraction with fixed-point or hardware-accelerated FFT; if feature extraction then dropped below raw inference time, the preferred-input conclusion could reverse on other hardware."],"forward_implications":["Raw-signal TinyML models are a practical option for real-time structural health monitoring on common low-power microcontrollers, as long as roughly 223 KB of flash and 126 KB of RAM are available.","Total pipeline time, not model inference time, is the deciding metric for battery-powered IoT; optimizing the model alone can be pointless if feature extraction dominates.","Dropping frequency-domain features and the FFT reduces total processing time by roughly 127 ms and energy by about 27% compared with the 6-feature model, while keeping accuracy essentially unchanged.","The high accuracies of all models (at least 99.1%) show that both raw waveforms and a carefully selected small feature set carry enough information for damage-type classification."],"supporting_citations":[{"why":"Supplies the acoustic-emission dataset of 15,000 concrete damage events with three labeled classes that all models are trained and tested on.","marker":"[15]"},{"why":"Demonstrates a lightweight convolutional neural network operating on raw AE waveforms, motivating the raw-signal input approach.","marker":"[11]"},{"why":"Shows AE and machine learning for concrete damage classification on embedded devices, providing the feasibility baseline the paper extends.","marker":"[13]"},{"why":"Introduces TinyML for concrete damage classification, serving as the prior raw-signal deployment result this work compares against.","marker":"[14]"},{"why":"Provides the Time Series Feature Extraction Library used to define the 28 initial features that are later ported to C for the feature-based models.","marker":"[16]"},{"why":"Supplies the hyperparameter optimization method used to search the neural network architectures for each input scenario.","marker":"[17]"}],"fun_headline_variants":["Raw AE input cuts energy 52-71x vs feature models","Skipping feature extraction saves 52-71x energy in AE AI","Fastest AE model: raw waveform beats handcrafted features","On-chip AE: raw signal wins 52-71x on energy","Raw-signal ML: 99% accuracy with 52-71x less energy"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The energy comparison assumes the microcontroller draws a constant power from the datasheet, so energy is just processing time scaled by one fixed current; if feature-extraction code draws more or less current than the int8 inference kernel, the reported 52-71x energy advantage changes.","fun_headline_variants_meta":{"raw":{"variants":["Raw AE input cuts energy 52-71x vs feature models","Skipping feature extraction saves 52-71x energy in AE AI","Fastest AE model: raw waveform beats handcrafted features","On-chip AE: raw signal wins 52-71x on energy","Raw-signal ML: 99% accuracy with 52-71x less energy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000819,"raw_usage":{"total_tokens":3598,"prompt_tokens":971,"completion_tokens":2627,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":587,"completion_tokens_details":{"reasoning_tokens":2530}},"tokens_in":587,"tokens_out":2627,"duration_ms":18758,"temperature":1.0,"reasoning_tokens":2530,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:35:31.262253+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure the nRF52840's current draw separately during int8 inference and during floating-point C feature extraction, then recompute energy per prediction using the per-phase currents and the durations in Table II; if feature extraction's current substantially exceeds inference current, the raw-signal model's energy advantage shrinks toward or below the time ratio of 52-71x.","supporting_citations":[{"cited_title":"Automatic Crack Classification by Exploiting Statistical Event Descriptors for Deep Learning,","cited_arxiv_id":null,"evidence_quote":"Supplies the acoustic-emission dataset of 15,000 concrete damage events with three labeled classes that all models are trained and tested on."},{"cited_title":"A Lightweight Convolutional Neu- ral Network Model for Concrete Damage Classification using Acoustic Emissions,","cited_arxiv_id":null,"evidence_quote":"Demonstrates a lightweight convolutional neural network operating on raw AE waveforms, motivating the raw-signal input approach."},{"cited_title":"Leveraging Acoustic Emission and Machine Learning for Concrete Materials Damage Classi- fication on Embedded Devices,","cited_arxiv_id":null,"evidence_quote":"Shows AE and machine learning for concrete damage classification on embedded devices, providing the feasibility baseline the paper extends."},{"cited_title":"Tiny Machine Learning for Damage Classification in Concrete Using Acoustic Emission Sig- nals,","cited_arxiv_id":null,"evidence_quote":"Introduces TinyML for concrete damage classification, serving as the prior raw-signal deployment result this work compares against."},{"cited_title":"TSFEL: Time Series Feature Extraction Library,","cited_arxiv_id":null,"evidence_quote":"Provides the Time Series Feature Extraction Library used to define the 28 initial features that are later ported to C for the feature-based models."},{"cited_title":"Hyperparameter Tuning of Deep Learning Models in Keras,","cited_arxiv_id":null,"evidence_quote":"Supplies the hyperparameter optimization method used to search the neural network architectures for each input scenario."}],"review_version":1}