{"id":"d35e26d2-f3ef-40eb-ad97-5ed9084c14d9","arxiv_id":"2509.00589","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"An FPGA implementation using a 512-point Xilinx FFT core detects and displays the fundamental frequency of single piano notes, with examples near 293.68 Hz and 130.68 Hz.","lead":"This report describes an FPGA system that captures a single piano note, computes its spectrum with an FFT core, and displays the dominant frequency on an LCD. The demonstration shows real-time frequency detection on a low-cost Spartan-3E board, but provides no quantitative accuracy evaluation.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The displayed-frequency claim rests on an unmeasured nominal sample rate and an internal factor-of-two contradiction: §4 computes 8.36 Hz/bin while §5 claims 4.28 Hz/bin at the same F_s. Without calibrating F_s against a known tone, the frequency output is unvalidated.","rationale":"This is a student project write-up; its strongest claim is narrow: an FPGA/FFT pipeline samples a piano note and displays a peak-frequency estimate. I take at face value the evidence that the FFT pipeline functions — ChipScope captures, distinct bins, and scope waveforms all support that. The load-bearing step is not the FFT itself but the conversion from bin index to Hz, which uses an assumed F_s. Section 4 states F_s = 5 MHz/(73×16) ≈ 4.28 kHz and Δf ≈ 8.36 Hz/bin. Section 5 then claims ≈4.28 Hz/bin at the same F_s. Those cannot both be true. This is an internal inconsistency, not a disagreement with field consensus, and it is directly connected to the central claim because the displayed 'frequency' is the product of this scaling.\n\nThe reader's weakest_assumption (unmeasured effective sample rate) is the same root issue; the §5 contradiction strengthens it. My concrete calibration test would settle it: feed a known tone, measure actual sample cadence via ChipScope, and compare the LCD output. If the LCD tracks the known input within one bin after correcting F_s, the claim is salvageable under a conditional verdict; if off by ~2×, the scaling code has a real bug. I do not see grounds for REJECT: the paper makes no quantitative accuracy claim precise enough to falsify beyond this, and the missing code is a reproducibility issue rather than a correctness contradiction. Hence UNCHANGED relative to the reader's CONDITIONAL verdict.","tokens_in":7856,"tokens_out":5820,"duration_ms":69789,"concrete_test":"Feed a known 440 Hz sine (with the same 1.65 V DC offset) into the ADC. Use ChipScope/ILA to count 5-MHz clock cycles between successive ADC sample-ready pulses over a full 512-sample frame, and compute the measured average sample rate. Read the LCD-displayed frequency. If the LCD value is not within one bin (measured F_s/512 ≈ 8.36 Hz) of 440 Hz, or if it is roughly 220/880 Hz, then the F_s assumption or the bin-index-to-Hz scaling is wrong — resolving the §4/§5 contradiction. Also inspect the HDL scaling expression to see whether it divides by 512 or 1024.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central functional claim is that the system detects and displays the dominant piano-note frequency. That claim depends on F_s being known accurately because the LCD frequency is computed as bin_index × F_s/N. The report never measures F_s; it assumes the 5 MHz system clock and the 73×16 downsampling counters are exact (§4). If the actual ADC sampling cadence differs — due to SPI transaction length, debounce logic, or clock-divider behavior — every displayed frequency is scaled by a constant factor. The report also contains a direct internal contradiction: §4 derives Δf = F_s/512 ≈ 8.36 Hz/bin, while §5 claims 'a resolution of approximately 4.28 Hz per FFT bin' at the same F_s ≈ 4.28 kHz. These differ by roughly a factor of two; a 4.28 Hz/bin resolution would require F_s ≈ 2.19 kHz, not 4.28 kHz. Thus either the sample rate is not what §4 says, or the bin-to-Hz conversion in the HDL divides by ~1024 instead of 512. Without a measured sample-rate value and a ground-truth frequency check, the 'frequency output' is unvalidated; distinct FFT bins alone do not establish frequency accuracy. The self-citation block and missing code are secondary; this calibration issue is the load-bearing gap.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript reports an FPGA-based single-note frequency detector built on a Spartan-3E starter kit. Analog piano audio is captured through the board's LTC1407A ADC, downsampled to a nominal effective rate of 4.28 kHz, stored as 512 samples, processed by a Xilinx FFT IP core in Radix-4 Burst I/O mode, and reduced to a peak magnitude bin. The bin index is converted to a frequency in hertz and displayed on a character LCD. The paper describes the module-level design, the FFT core interface, resource-driven choices (1024-point and streaming FFT configurations were abandoned), and ChipScope debugging. The authors conclude that the system meets the core functional requirements of sampling, FFT processing, and dominant-frequency display, with oscilloscope waveforms as evidence.","tokens_in":8263,"tokens_out":3832,"duration_ms":48960,"significance":"If the frequency-detection claim were quantitatively validated, this would be a modest but useful educational demonstration of FPGA-based FFT signal processing on a resource-constrained board. The paper has several genuine strengths: the DFT/FFT mathematics in Section 3 are correct, the description of the Xilinx FFT core handshaking is careful and consistent with the product behavior, and the resource-driven decision to move from 1024-point/streaming implementations to a 512-point burst configuration is clearly documented. The use of ChipScope waveforms and the explicit derivation of the nominal sampling rate also show good engineering discipline. However, the manuscript does not supply reproducible code, a measured sample-rate calibration, or a quantitative comparison of detected frequencies to ground-truth piano-note frequencies. Those missing elements are load-bearing for the central claim.","major_comments":[{"comment":"There is a direct internal contradiction in the reported frequency resolution. Section 4 derives Δf = F_s/512 ≈ 8.36 Hz/bin for F_s ≈ 4.28 kHz. Section 5 states 'a resolution of approximately 4.28 Hz per FFT bin' for the same 512-point FFT and the same sampling rate of roughly 4.28 kHz. These values differ by a factor of two. A 4.28 Hz/bin resolution would require F_s ≈ 2.19 kHz, not 4.28 kHz. Since the displayed frequency is presumably computed as bin_index × F_s/512 (or an equivalent scaling), this discrepancy implies either the actual sampling rate is not 4.28 kHz or the HDL bin-to-Hz conversion divides by ~1024 instead of 512. This must be resolved because it scales every reported frequency and directly affects the accuracy claim.","section":"Section 4 vs. Section 5"},{"comment":"The effective sampling rate is taken as exactly F_s = 5 MHz/(73×16) ≈ 4.28 kHz from the nominal system clock and the chosen downsampling counter values, but the paper never measures the actual sample timing. Any deviation in the ADC SPI transaction length, clock divider behavior, or debounce logic would scale every displayed frequency by a constant factor. The 'Output Calibration' step in Section 2 mentions scaling bin indexes based on the known sampling rate, but no calibration data or measured sample intervals are reported. The authors should either measure the sample cadence with ChipScope or feed a known calibration tone (e.g., a 440 Hz sine) and report the observed bin index and displayed frequency versus the expected value. Without this, the frequency output is unvalidated even if the FFT pipeline works correctly.","section":"Section 4 and Design Flow step 5"},{"comment":"The evidence presented supports only the weaker claim that distinct piano keys produce distinct FFT bin outputs. The conclusion that 'each key press translated into a distinct frequency bin output, confirming correct implementation of the FFT and sampling pipeline' does not establish that the displayed frequencies are accurate. Figures 2-4 show oscilloscope waveforms with annotated frequencies (293.68 Hz, 130.68 Hz, 350.26 Hz), but there is no tabulated comparison to the expected piano-note frequencies, no description of how the annotated values were measured, and no stated error metric. For the central claim of detecting and displaying the dominant piano-note frequency, the authors need to compare the FPGA's LCD output to ground-truth signal frequencies for several notes and report the errors.","section":"Section 5 and Figures 2-4"}],"minor_comments":[{"comment":"The inverse DFT formula is misstated: the left side is written as X(k), but the right side is the synthesis formula for x(n). The 1/N factor is present, but the variable mismatch makes the equation incorrect as written.","section":"Equation (2)"},{"comment":"It is unclear whether the annotated frequencies (293.68 Hz, 130.68 Hz, 350.26 Hz) are oscilloscope measurements, the FPGA's LCD output, or expected note frequencies. Please state the source of these values in the captions and in the text.","section":"Figures 2-4 captions"},{"comment":"The paragraph citing references [3]-[25] is largely unrelated to the technical content of this project, and the claim that FPGA-based systems are 'currently the best option' is unsupported by the cited analyses in the context of this work. This block should be removed or reduced to the few references that directly inform the design.","section":"Section 5 self-citation block"},{"comment":"The term 'real-time' is used loosely. The design uses pushbutton-triggered sampling and a burst FFT, which is not continuous streaming analysis. Please either quantify the end-to-end latency or qualify the real-time claim (e.g., 'near-real-time for single notes').","section":"Section 1 and 5"},{"comment":"The notation F_s is used with inconsistent capitalization (F_s, Fs, fs). Also, the 73×16 downsampling rationale is not explained beyond resource constraints; a sentence on why these particular values were chosen would help.","section":"Section 4"}],"recommendation":"major_revision","confidential_remarks":"The reference list contains an unusual concentration of self-citations (23 of 25), many on topics not used in this design, and the Section 5 'best option' claim is not evidence-based. The manuscript also lacks a code/data repository despite describing a concrete implementation. For an archival venue, the calibration experiment described in major comment 2 is essential; without it, the paper reads as an undergraduate project report rather than a fully validated technical contribution. A short application-style paper with measured frequency errors would be appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The headline: this is a well-written student project report that builds a standard FFT-based single-note pitch detector on a Spartan-3E FPGA. Nothing new algorithmically or architecturally, but the paper is a clear, honest record of a working pipeline: ADC capture, Xilinx FFT IP, peak detection, and LCD output. The DFT math is correct, and the resource discussion (how a 1024-point FFT overflowed the FPGA, forcing a 512-point radix-4 burst configuration) is genuine engineering content.\n\nThe main soft spot is exactly where the stress-test lands. Section 4 computes the frequency resolution correctly: F_s = 5 MHz / (73 × 16) ≈ 4.28 kHz, so Δf = F_s / 512 ≈ 8.36 Hz/bin. Section 5 then claims \"a resolution of approximately 4.28 Hz per FFT bin\" using the same F_s. That is off by a factor of two. Either the sample rate isn't what Section 4 says, or the bin-to-Hz conversion uses N=1024 by mistake. This is not a cosmetic typo: it directly undermines the claim that the system resolves notes. Second, the effective sampling rate is never measured. The frequencies displayed on the LCD are computed from a nominal F_s; if the actual ADC timing deviates, every frequency is scaled by an unknown constant. The paper needs a ground-truth test: feed a known tone from a signal generator, measure the displayed frequency, and report the error. The oscilloscope screenshots show waveforms but not a quantitative comparison to settings.\n\nThere is also a block of self-citations at the end of Section 5 that is irrelevant to the project and reads as padding. It should be cut. No code or detailed timing measurements are provided, which limits reproducibility.\n\nThat said, the paper does what it sets out to do: it demonstrates a working real-time FFT-based detector on a resource-limited FPGA, and the descriptions of module interfaces and debugging are useful for students. The internal contradiction and missing calibration are fixable with a short revision. I would not cite this in my own work, and it is not a research contribution, but it deserves a serious referee if the authors address those two issues; otherwise it is a poster/tech report. If I were the editor, I'd send it back for a revision rather than desk reject, because the implementation is plausible and the flaw is concrete and fixable.","headline":"A student project report on a standard FPGA FFT pitch detector with a fixable factor-of-two error in the resolution and an uncalibrated sample rate; workable as a teaching demo, not a research contribution.","tokens_in":8652,"tokens_out":3937,"would_cite":false,"duration_ms":46261,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper reports that a Spartan-3E FPGA, using a 512-point fixed-point FFT core in burst mode, samples analog piano audio, finds the dominant frequency bin, and displays the frequency on an LCD, with each key press producing a distinct bi","keywords":["FPGA","FFT","piano note detection","frequency estimation","Spartan-3E","ADC sampling","real-time signal processing","LCD display"],"falsifier":"Feed a calibrated sine wave of known frequency, say 440.0 Hz, into the same DC-biased audio input while the system runs, and simultaneously capture the ADC sample clock with a logic analyzer or oscilloscope. If the LCD shows a frequency more than one bin width (about 8.36 Hz) away from 440 Hz, or the measured sample period is not exactly 73 × 16 / 5 MHz, then the nominal sampling-rate assumption is the failure point. Repeating this at 130.68 Hz and 293.68 Hz would test whether the displayed values reproduce the examples in the report.","tokens_in":7830,"feed_emoji":"🎹","tokens_out":7569,"duration_ms":81279,"temperature":0.7,"pith_summary":"This project report describes a hardware-only FPGA system that identifies the fundamental frequency of a single piano note in real time. The authors built a pipeline on a Spartan-3E board: an onboard ADC captures the analog audio, custom Verilog logic stores 512 downsampled samples, a fixed-point FFT core converts them to the frequency domain, a peak detector finds the strongest bin, and an LCD shows the corresponding hertz value. Their central claim is that this resource-constrained design works: each key press translated into a distinct frequency bin output, with example detections around 293.68 Hz and 130.68 Hz. They also claim the configuration achieves about 8.36 Hz per bin at an effective sampling rate of roughly 4.28 kHz, enough to separate common musical notes while leaving close notes and harmonics unresolved. The significance, as the authors frame it, is that real-time frequency-domain analysis is feasible on small FPGAs without software DSP.","feed_headline":"FPGA piano tuner reads note frequencies in real time","feed_subtitle":"A 512-point FFT core turns analog piano audio into an LCD frequency readout on a small FPGA board.","key_machinery":"The central mechanism is the sampling-rate chain feeding a 512-point FFT. A 5 MHz system clock is divided by a 73-clock spacing between ADC reads and a further 16:1 downsample, giving an effective sampling rate F_s ≈ 4.28 kHz; the FFT then yields bins spaced by Δf ≈ 8.36 Hz. The transform itself is a Radix-4 Burst I/O FFT core—it loads all 512 time samples in one burst, computes internally, then unloads bins in natural order—with 14-bit fixed-point inputs. A peak detector squares the real and imaginary parts of each output bin, keeps the largest magnitude and its index, and scales that index to a frequency in hertz for the character LCD. A finite state machine synchronizes the ADC, the FFT c","core_discovery":"On the paper's own terms, the discovery is that a working real-time piano-note frequency detector can be assembled from standard FPGA blocks: a custom SPI master driving the board's ADC, a vendor FFT core configured for a 512-point Radix-4 Burst I/O transform, a peak-magnitude tracker that compares squared real and imaginary outputs, and a finite state machine that coordinates sampling, FFT feeding, and an LCD update. The report states that every key press produced a distinct frequency bin, confirming the sampling and FFT pipeline. Two captured waveforms show the detected fundamentals at approximately 293.68 Hz and 130.68 Hz. The design deliberately trades transform size and throughput for r","pith_inferences":["The paper never verifies the sample clock, so a calibrated-tone test against a measured sample period would tell whether the displayed frequencies are accurate in absolute terms; this is an inference beyond the reported results.","Because the bin spacing is 8.36 Hz, adjacent low-piano notes (e.g., C2 to C#2, about 3.9 Hz apart) would fall in the same or neighboring bins, suggesting low-note accuracy needs interpolation even though the mid-range detections in the report are distinct.","The pipeline should apply to any periodic sound source with a fundamental below the 2.14 kHz Nyquist limit, not just pianos, since the piano only provides the test tones.","Burst-mode FFT means the system takes snapshots rather than streaming continuously; the report's 'real-time' claim is about a complete sample-FFT-display cycle, not sample-by-sample throughput."],"forward_implications":["A single audio source can be reduced to its dominant frequency using only a small FPGA's logic and block RAM, with no software processor or operating system in the signal path.","With the 512-point/4.28 kHz configuration, notes whose fundamentals are separated by more than about 8.36 Hz can be told apart; the report says this distinguishes common piano notes but leaves closely spaced or harmonic-rich cases unresolved.","Raising the transform to 1024 points, or switching to Pipelined Streaming mode, fails on this board, so real-time operation on this class of FPGA depends on burst-mode FFT and deliberate downsampling.","The detected frequency is a linear function of the assumed sampling rate, so any error in the nominal 5 MHz clock or the delay counts shifts every displayed frequency by the same proportion."],"supporting_citations":[{"why":"Defines the FFT core's configuration options and the rfd/dv/busy timing that the interface state machine is written against.","marker":"[1]"},{"why":"Documents the board's ADC, preamplifier, SPI pins, and LCD connections that determine how the analog piano signal enters the FPGA.","marker":"[2]"},{"why":"Cited as evidence that single-chip hardware supports mobile and embedded applications, motivating the hardware-only approach.","marker":"[3]"},{"why":"Cited to justify FPGA-based reconfigurable systems as the best avenue for the compute- and data-intensive algorithms used in the project.","marker":"[4]"}],"fun_headline_variants":["FPGA reads piano notes in real time with FFT","Real-time piano tuning on an FPGA using FFT","FPGA-based FFT detects piano frequencies live","Piano note detection in real time on FPGA","Hardware piano tuner: FPGA and FFT in real time"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The whole frequency readout assumes the ADC really samples at F_s = 5 MHz / (73 × 16) ≈ 4.28 kHz from the nominal 5 MHz board clock; the report never measures the actual sample timing, so a deviation there would bias every displayed frequency.","fun_headline_variants_meta":{"raw":{"variants":["FPGA reads piano notes in real time with FFT","Real-time piano tuning on an FPGA using FFT","FPGA-based FFT detects piano frequencies live","Piano note detection in real time on FPGA","Hardware piano tuner: FPGA and FFT in real time"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000349,"raw_usage":{"total_tokens":1686,"prompt_tokens":625,"completion_tokens":1061,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":369,"completion_tokens_details":{"reasoning_tokens":983}},"tokens_in":369,"tokens_out":1061,"duration_ms":9957,"temperature":1.0,"reasoning_tokens":983,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T13:24:57.227215+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Feed a calibrated sine wave of known frequency, say 440.0 Hz, into the same DC-biased audio input while the system runs, and simultaneously capture the ADC sample clock with a logic analyzer or oscilloscope. If the LCD shows a frequency more than one bin width (about 8.36 Hz) away from 440 Hz, or the measured sample period is not exactly 73 × 16 / 5 MHz, then the nominal sampling-rate assumption is the failure point. Repeating this at 130.68 Hz and 293.68 Hz would test whether the displayed values reproduce the examples in the report.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the FFT core's configuration options and the rfd/dv/busy timing that the interface state machine is written against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the board's ADC, preamplifier, SPI pins, and LCD connections that determine how the analog piano signal enters the FPGA."},{"cited_title":"Analysis of Single-Chip Hardware Support for Mobile and Embedded Applications,","cited_arxiv_id":null,"evidence_quote":"Cited as evidence that single-chip hardware supports mobile and embedded applications, motivating the hardware-only approach."},{"cited_title":"Analysis of Computation Models and Application Characteristics Suitable for Reconfigurable FPGAs","cited_arxiv_id":null,"evidence_quote":"Cited to justify FPGA-based reconfigurable systems as the best avenue for the compute- and data-intensive algorithms used in the project."}],"review_version":1}