Serial Studio Spec 0016 深读对数频率轴上的多分辨率 FFT 频谱——设计原理、取舍权衡与归宿【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-Studio本文基于 Serial Studio 仓库中的规格文档 0016-multires-fft完整还原多分辨率 FFT 显示这一功能的设计动机、十项需求R1–R10、验收准则与工程约束并结合配套 plan.md、tasks.md 以及当前仓库源码讲清为什么低频需要更长观测窗Δf 1/T 这条物理约束如何左右方案取舍以及该方案最终为何在发布当天被规格 0018 取代。读完你会掌握从频谱分辨率与响应速度的物理耦合出发设计显示层 DSP 分析路径的完整方法论。背景对数频率轴上的信息密度反转前置规格 0014-log-axes 为 FFT 组件提供了对数频率轴在 project 编辑器中把 FFT 数据集的频率轴设为对数后每个八度占据相等的水平宽度。但对数轴只改变了显示底层分析仍产出均匀间隔的频率 bin。这个组合在对数轴上把信息密度完全反转了以 44.1 kHz 采样率、典型窗口为例bin 间隔约 10 Hz200 Hz 以下的区域——恰好占据对数轴大约一半的宽度——却只由几十个 bin 支撑渲染出来是肉眼可见的、近似直线的方块段维护者在运行中的应用上于 2026-07-17 截图确认而最高一个十倍频程把数千个 bin 压缩到几个像素里细节大量浪费。音频与振动分析恰恰最关心低频段。spec 0016 给出的参照是专业音频工具维护者引用的参照某商业 DAW 的 EQ/频谱视图它们用多分辨率分析——低频用更长的时间窗更细的频谱细节高频用更短的窗——使渲染出的频谱在整个对数范围内细节均匀、曲线平滑。spec 明确了一条底线这必须是真实分辨率而不是插值。两个间隔很近的低频正弦例如 100 Hz 126 Hz相距三分之一八度应当被分辨为两个峰稀疏 bin 之间做任何曲线平滑都做不到这一点。目标与非目标spec 0016 的目标原文完整继承启用对数频率轴的 FFT 组件渲染出录音室分析仪风格的频谱每个八度的细节量在整个轴上大致均匀低端没有方块状直线段也不丢失高端各十倍频程已有的包络细节真正的低频分辨率提升今天合并成一团的邻近低频分量变为可分辨的峰渲染曲线在任何组件尺寸和缩放下都平滑无可见的 bin 阶梯行为全自动——对数频率轴打开 多分辨率打开。不新增任何 project 键、编辑器行或 API 字段spec 0014 的 schema 视为定稿。非目标同样明确不改动线性轴 FFT对数轴关闭 今天单窗管线的 bit-for-bit 行为不改动 Waterfall瀑布图声谱图保持单窗行可作为后续跟进不新增配置面窗口大小/采样率/窗函数保持原义没有分辨率旋钮不承诺精确的 constant-Q 变换目标是分析器风格的均匀视觉细节来自真实多窗分析而非数学上恒 Q 的输出不改变 FFT 的告警/导出语义——FFT 目前仅为显示用途保持这一状态。核心设计抽取级联 同尺寸 FFT 拼接plan.md 给出的架构是抽取级联 同尺寸 FFT 拼接全部位于FFTPlot组件内、以 UI 绘制节奏运行。当dataset.fftLogX置位时Dashboard::configureFftSeries把该组件的采样环扩容为配置窗口的E 16倍带上限每样本摄入 push 是 O(1)、不变。每个updateData时刻组件取环的尾部产出三个分析级级数据有效采样率频率分辨率 Δfstage 0最新 N 个原始样本fsfs/Nstage 1最新 4N 个样本抽取 ×4fs/4fs/(4N)stage 2最新 16N 个样本经两级 ×4 抽取fs/16fs/(16N)三级跑的是同一个N 点 FFT一个 kissfft plan、一个窗缓冲、同一个1/N²功率归一化因此 stage 2 在低端提供 16 倍真实分辨率增益例如 44.1 kHz / N1024 时约 2.7 Hz而 stage 0 保留短窗的响应速度。三级频谱在固定交叉频率处按频率区域拼接归一化对齐使 dB 迹线在接缝处连续拼接后的 bin 序列再进入 spec 0014 既有的 log10-X 推送、平滑、降采样与渲染管线不做任何改动。对数轴关闭时所有分支短路回今天的路径。整个方案零 schema、零编辑器、零 API、零 QML 变更。几个关键设计决策及其理由交叉频率每级只使用到其自身奈奎斯特的 0.4 倍f_k 0.4·(fs/D_k)/2把抽取滤波器的过渡带排除在显示范围之外抽取滤波器单一 constexpr 对称 windowed-sinc FIR ×4两级复用。tasks.md T3 记录最终落地为 39 抽头 Blackman 窗 sinc统一 DC 增益、线性相位、每时刻无状态reconfigure 不会残留滤波器状态在混叠折叠带处约 -77 dB接缝处理先硬切换——相同的窗 归一化 0.4·Nyquist 余量加平滑后接缝应不可见若 AC3 仍显示台阶后备方案是在拼接函数内加短线性 crossfade平滑跨接缝3-bin 箱式平滑按段per-segment执行绝不跨越 4 倍 bin 间隔跳变平均否则会在接缝处偏置电平并破坏需求 R3/R4历史扩容放在哪规格原约束是额外历史必须来自组件自身的保留但最终设计改为在 configure 时加长 Dashboard 既有的采样环——因为组件无法从环快照检测自上次 tick 以来有多少新样本环上没有单调 push 计数器组件侧增量累积反而要给摄入热路径加计数器。plan 明确将此偏差标记出来请求门禁批准而非静默重解释。FixedQueue::push的代价与容量无关摄入路径对热路径基准是可证明的 no-op内存上限kMaxExtendedFftSamples 262144最坏 2 MB/组件典型音频配置 N8192 约 1 MB所有分析缓冲在 configure 时定尺寸稳态免分配。对照当前仓库源码可以看到这套设计的落点。configureFftSeries 负责为 FFT 系列分配采样环并建立 push 表plan 中唯一允许改动的一行就在此函数内ring 容量按fftLogX决定FFTPlot.h 声明了m_plankiss_fftr plan、m_window、m_logBinX、m_pchipSlope等成员QML 契约仅暴露minX/maxX/minY/maxY/logX均为 CONSTANT与 carrier 系列——与 specQML 合同不变的约束一致。需要说明spec 中引用的app/src/UI/...路径是当时的目录布局当前代码树中对应位置为core/Ui/UI/Widgets/FFTPlot.cpp等仓库后续做了模块化重组见 0076-modular-core 系列。需求 R1–R10完整清单R1— 启用对数频率轴时FFT 组件用比高频更长的有效时间窗分析低频使每八度的显示分辨率在整个轴上大致均匀。R2— 100 Hz 处相距三分之一八度的两个正弦如 100 Hz 126 Hz在默认设置下采样率与窗口允许时渲染为两个独立峰——今天是渲染为一个。R3— 分析区域之间的过渡不引入人为不连续扫频正弦谱在频段边界无台阶宽带噪声只呈现物理上预期的噪声密度台阶每细化 4 倍约 6 dB——正弦标定2026-07-17 选定不同 bin 宽度下正弦平坦且噪声平坦互斥。R4— 幅值标定在全轴一致恒幅正弦扫频在 50 Hz 与 5 kHz 处描出同一 dB 电平容差内。R5— 对数轴关闭时分析路径与输出与今天完全一致单窗、既有平滑。R6— 多分辨率路径在 44.1 kHz 音频源、默认刷新率下不引入可感知的 UI 迟滞总分析代价不超过当前单次 FFT 代价的约 3 倍。R7— 既有 FFT 配置窗口大小、采样率、窗函数、dB 范围继续有效窗口大小继续界定延迟/历史配置的窗函数应用于所有分析区域。R8— 对数轴上的缩放、平移、十字线、光标读数在多分辨率谱上继续工作读数为真实 Hz/dB与 0014 一致。R9— 低端手感实时最细分析级受响应时间约束约 0.4 s 观测目标——分辨率与响应是同一个物理旋钮Δf 1/T按窗口大小与采样率自适应伸缩而非固定倍数2026-07-17 在实测发现固定 16 倍扩展对音频级窗口手感迟钝后加入。R10— 对数轴从最细分析级的第一个 bin 开始——这是对数轴能逼近 0 Hz 的极限——分析捕获到的一切都不被裁剪2026-07-17 决定取代了临时的 ~100 Hz 默认下界。其中 R9 值得单独展开Δf 1/T 意味着想要更细的 bin就必须看更长的时间代价是谱的变化到得更晚。plan 中的实现是kMaxFinestWindowSec 0.4——级数 min(容量允许, 时间允许)于是音频级窗口不再盯数秒的历史而用户若主动配置了一个已经 ≥ 0.4 s 的窗口则保持单级——预算本身就是用户的分辨率选择。tasks.md T6 指出这个时间预算还结构性地化解了评审中大 N 时每 tick 代价的担忧只有当整个 span ≤ 0.4 s 的样本量时才存在 3 级。验收准则 AC1–AC9 与验证手段所有 9 条验收准则在实施期均标记通过maintainer check 基准门禁AC1运行中的应用、44.1 kHz 音频源音乐/宽带音频低端平滑有细节200 Hz 以下无直线段气质接近参照分析仪截图AC2双音测试100 Hz 126 Hz对数轴打开显示两个峰关闭对数复现今天的单峰渲染证明线性路径未被触碰AC3白噪声渲染为连续谱唯二的电平变化是两个接缝处预期的平滑噪声密度台阶无单 bin 突变扫频正弦完全没有接缝AC450 Hz → 5 kHz 恒幅扫频峰 dB 电平全程稳定无逐频段增益跳变AC5--benchmark-hotpath在既有门禁下通过分析运行在 UI 节奏摄入未动——门禁证明无回归AC6既有线性轴 FFT 项目渲染一致fftLogX: true的项目无需重新编辑即获得新渲染AC7一个对数轴 FFT 组件、默认刷新的 CPU 占用与改动前同量级任务管理器抽查AC8低端在半秒内可见地跟踪节目内容变化——相对高端无多秒级滞后AC9对数轴从最低可分辨 bin 开始低端无裁剪轴范围对话框仍可进一步收窄视图。验证手段组合维护者视觉检查音频源 双音 白噪 扫频、--benchmark-hotpath热路径门禁、python scripts/code-verify.py --check静态检查见 scripts/code-verify.py、代码评审与sanitize-commit.py提交清洗。本功能为纯显示路径无新增 API/schema因此没有可运行的 pytest 目标。约束与工程不变量仅显示侧摄入、环与 256 kHz 热路径门禁均不触碰新增分析工作全部运行在组件层的 UI 绘制节奏与 0014 同层零 schema/API 增量无新 project 键、无编辑器项、无 API 字段功能完全挂在既有fftLogX标志上历史扩展是被动且有界的更长的低频窗口来自既有 FFT 采样环在 configure 时的有界扩展plan 门禁于 2026-07-17 批准每样本摄入代码路径必须 byte-identical——无新摄入逻辑、计数器或逐帧工作确定性内存新增分析缓冲在 configure 时定尺寸稳态免分配与 0014 scratch 环同纪律无新依赖既有 FFT 库——kissfft——足够见 lib/KissFFTQuickPlot 自动生成的音频 FFT在对数轴开启时自动获得该改进无特判。Tasks T1 还记录了一条代码评审遗留configureFftSeries中针对恶意fftSamples输入的 clamp未裁剪的 project 输入可能让 16 倍扩展溢出为负环容量——该 clamp 在功能移除后依然保留在 0018 的代码中当前 Dashboard::configureFftSeries 中。为何同日下架延迟物理与规格 0018 的接棒这是本 spec 最有价值的部分。0016 完整实施、按规格工作然后在同一天被 0018-smooth-log-fft 取代状态标记为shelved见 spec.md 头部 front-mattersuperseded by 0018-smooth-log-fft (2026-07-17): uniform latency beat multi-res low-band resolution; implementation removed same day。原因回到那条物理约束低端的长观测窗使低频天然滞后于高频Δf 1/T。AC8 的 0.4 s 时间预算与 0017 ballistics释放时间常数都无法消除起攻延迟差——实测中它反复暴露。0018 调查了参照工具后得出结论专业 DAW 频谱分析仪并不做多分辨率——它们跑一个中等尺寸的单一 FFT处处延迟一致把稀疏的低端 bin 渲染成对数空间中的平滑插值曲线再加 ballistics。于是决策改为接受单 FFT 的低频分辨率让它画得平滑手感保持均匀且实时。0018 的落地对照当前源码移除 0016 机制抽取级联、FIR 抽头、级布局/拼接、各级 scratch 缓冲以及 Dashboard 环扩展——对数与线性 FFT 重新共享一条代码路径环容量 clamp 后的fftSamples新增FFTPlot::buildLogRenderCurveFFTPlot.cpp#L678在 log-x 空间用 Fritsch-Carlson 单调三次PCHIP绝不过冲、峰位诚实穿过各 bin重采样到均匀 2048 点对数网格rebuildLogBinTable 在 ctor/plan 重建时缓存每 bin 的 log-x 位置稳态免分配每 tick 管线computeBinSpectrumdB 箱式平滑 可选 0017 ballistics→ 线性轴走emitLinearSpectrum形状不变或对数轴走buildLogRenderCurve。值得注意的是 0016 有两项遗产活在了当前代码里R10 的轴下界原则applyLogFrequencyBounds 中m_minX clampedLog10(freqStep)freqStep fs/N——对数轴从第一个 FFT bin 开始分析捕获到的一切都不被裁剪注释原文几乎照搬 0016 的表述一致的1/N²功率归一化computeBinSpectrum 中normFactor N·N的归一化纪律正是 0016 用来保证跨接缝标定一致R4的同一机制现在服务于单一路径的电平稳定性。架构文档 doc/claude/architecture/dashboard.md 中对应的段落先由 0016 的 T5 写入扩展环 三级拼接随后由 0018 改写为单窗 平滑渲染的描述。实践启示与适用前提从这份当天立项、当天实施、当天退役的 spec 可以提炼出几条可复用的经验Δf 1/T 是硬约束频谱分辨率与响应速度是同一个旋钮任何多分辨率方案都必须显式回答低频能慢多少。0016 用 0.4 s 时间预算R9回答了但实测表明用户在意的是各频段间的延迟差而非绝对延迟——这个洞察直接改变了方案方向接缝是拼接类 DSP 的主要风险面0016 用统一窗 统一1/N²归一化 0.4·Nyquist 交叉 分段平滑四件套预防接缝可见性并用扫频正弦AC4作为标定门禁热路径零侵入的可证明性把 ring 扩容做成 configure 时的一行 O(1) 无感变更用--benchmark-hotpath门禁而非代码评审来证明摄入路径无回归保留被取代的设计文档是严肃的工程实践0016 的 R3/R4 标定分析、交叉余量与 stage 数学在 plan 中明确标注若日后以可选高分辨率低端模式重审该方案时仍然有效。适用前提本 spec 的时间线为 2026-07-17创建、批准、实施、验收、下架同日完成文中路径引用以当时仓库布局为准app/src/UI/...当前代码树中对应实现位于core/Ui/UI/Widgets/FFTPlot.cpp与core/Ui/UI/Dashboard.cpp。阅读时请以 0018 spec 为现行行为的权威描述0016 作为其设计史与取舍依据阅读。【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-Studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Serial Studio Spec 0016 深读：对数频率轴上的多分辨率 FFT 频谱——设计原理、取舍权衡与归宿
Serial Studio Spec 0016 深读对数频率轴上的多分辨率 FFT 频谱——设计原理、取舍权衡与归宿【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-Studio本文基于 Serial Studio 仓库中的规格文档 0016-multires-fft完整还原多分辨率 FFT 显示这一功能的设计动机、十项需求R1–R10、验收准则与工程约束并结合配套 plan.md、tasks.md 以及当前仓库源码讲清为什么低频需要更长观测窗Δf 1/T 这条物理约束如何左右方案取舍以及该方案最终为何在发布当天被规格 0018 取代。读完你会掌握从频谱分辨率与响应速度的物理耦合出发设计显示层 DSP 分析路径的完整方法论。背景对数频率轴上的信息密度反转前置规格 0014-log-axes 为 FFT 组件提供了对数频率轴在 project 编辑器中把 FFT 数据集的频率轴设为对数后每个八度占据相等的水平宽度。但对数轴只改变了显示底层分析仍产出均匀间隔的频率 bin。这个组合在对数轴上把信息密度完全反转了以 44.1 kHz 采样率、典型窗口为例bin 间隔约 10 Hz200 Hz 以下的区域——恰好占据对数轴大约一半的宽度——却只由几十个 bin 支撑渲染出来是肉眼可见的、近似直线的方块段维护者在运行中的应用上于 2026-07-17 截图确认而最高一个十倍频程把数千个 bin 压缩到几个像素里细节大量浪费。音频与振动分析恰恰最关心低频段。spec 0016 给出的参照是专业音频工具维护者引用的参照某商业 DAW 的 EQ/频谱视图它们用多分辨率分析——低频用更长的时间窗更细的频谱细节高频用更短的窗——使渲染出的频谱在整个对数范围内细节均匀、曲线平滑。spec 明确了一条底线这必须是真实分辨率而不是插值。两个间隔很近的低频正弦例如 100 Hz 126 Hz相距三分之一八度应当被分辨为两个峰稀疏 bin 之间做任何曲线平滑都做不到这一点。目标与非目标spec 0016 的目标原文完整继承启用对数频率轴的 FFT 组件渲染出录音室分析仪风格的频谱每个八度的细节量在整个轴上大致均匀低端没有方块状直线段也不丢失高端各十倍频程已有的包络细节真正的低频分辨率提升今天合并成一团的邻近低频分量变为可分辨的峰渲染曲线在任何组件尺寸和缩放下都平滑无可见的 bin 阶梯行为全自动——对数频率轴打开 多分辨率打开。不新增任何 project 键、编辑器行或 API 字段spec 0014 的 schema 视为定稿。非目标同样明确不改动线性轴 FFT对数轴关闭 今天单窗管线的 bit-for-bit 行为不改动 Waterfall瀑布图声谱图保持单窗行可作为后续跟进不新增配置面窗口大小/采样率/窗函数保持原义没有分辨率旋钮不承诺精确的 constant-Q 变换目标是分析器风格的均匀视觉细节来自真实多窗分析而非数学上恒 Q 的输出不改变 FFT 的告警/导出语义——FFT 目前仅为显示用途保持这一状态。核心设计抽取级联 同尺寸 FFT 拼接plan.md 给出的架构是抽取级联 同尺寸 FFT 拼接全部位于FFTPlot组件内、以 UI 绘制节奏运行。当dataset.fftLogX置位时Dashboard::configureFftSeries把该组件的采样环扩容为配置窗口的E 16倍带上限每样本摄入 push 是 O(1)、不变。每个updateData时刻组件取环的尾部产出三个分析级级数据有效采样率频率分辨率 Δfstage 0最新 N 个原始样本fsfs/Nstage 1最新 4N 个样本抽取 ×4fs/4fs/(4N)stage 2最新 16N 个样本经两级 ×4 抽取fs/16fs/(16N)三级跑的是同一个N 点 FFT一个 kissfft plan、一个窗缓冲、同一个1/N²功率归一化因此 stage 2 在低端提供 16 倍真实分辨率增益例如 44.1 kHz / N1024 时约 2.7 Hz而 stage 0 保留短窗的响应速度。三级频谱在固定交叉频率处按频率区域拼接归一化对齐使 dB 迹线在接缝处连续拼接后的 bin 序列再进入 spec 0014 既有的 log10-X 推送、平滑、降采样与渲染管线不做任何改动。对数轴关闭时所有分支短路回今天的路径。整个方案零 schema、零编辑器、零 API、零 QML 变更。几个关键设计决策及其理由交叉频率每级只使用到其自身奈奎斯特的 0.4 倍f_k 0.4·(fs/D_k)/2把抽取滤波器的过渡带排除在显示范围之外抽取滤波器单一 constexpr 对称 windowed-sinc FIR ×4两级复用。tasks.md T3 记录最终落地为 39 抽头 Blackman 窗 sinc统一 DC 增益、线性相位、每时刻无状态reconfigure 不会残留滤波器状态在混叠折叠带处约 -77 dB接缝处理先硬切换——相同的窗 归一化 0.4·Nyquist 余量加平滑后接缝应不可见若 AC3 仍显示台阶后备方案是在拼接函数内加短线性 crossfade平滑跨接缝3-bin 箱式平滑按段per-segment执行绝不跨越 4 倍 bin 间隔跳变平均否则会在接缝处偏置电平并破坏需求 R3/R4历史扩容放在哪规格原约束是额外历史必须来自组件自身的保留但最终设计改为在 configure 时加长 Dashboard 既有的采样环——因为组件无法从环快照检测自上次 tick 以来有多少新样本环上没有单调 push 计数器组件侧增量累积反而要给摄入热路径加计数器。plan 明确将此偏差标记出来请求门禁批准而非静默重解释。FixedQueue::push的代价与容量无关摄入路径对热路径基准是可证明的 no-op内存上限kMaxExtendedFftSamples 262144最坏 2 MB/组件典型音频配置 N8192 约 1 MB所有分析缓冲在 configure 时定尺寸稳态免分配。对照当前仓库源码可以看到这套设计的落点。configureFftSeries 负责为 FFT 系列分配采样环并建立 push 表plan 中唯一允许改动的一行就在此函数内ring 容量按fftLogX决定FFTPlot.h 声明了m_plankiss_fftr plan、m_window、m_logBinX、m_pchipSlope等成员QML 契约仅暴露minX/maxX/minY/maxY/logX均为 CONSTANT与 carrier 系列——与 specQML 合同不变的约束一致。需要说明spec 中引用的app/src/UI/...路径是当时的目录布局当前代码树中对应位置为core/Ui/UI/Widgets/FFTPlot.cpp等仓库后续做了模块化重组见 0076-modular-core 系列。需求 R1–R10完整清单R1— 启用对数频率轴时FFT 组件用比高频更长的有效时间窗分析低频使每八度的显示分辨率在整个轴上大致均匀。R2— 100 Hz 处相距三分之一八度的两个正弦如 100 Hz 126 Hz在默认设置下采样率与窗口允许时渲染为两个独立峰——今天是渲染为一个。R3— 分析区域之间的过渡不引入人为不连续扫频正弦谱在频段边界无台阶宽带噪声只呈现物理上预期的噪声密度台阶每细化 4 倍约 6 dB——正弦标定2026-07-17 选定不同 bin 宽度下正弦平坦且噪声平坦互斥。R4— 幅值标定在全轴一致恒幅正弦扫频在 50 Hz 与 5 kHz 处描出同一 dB 电平容差内。R5— 对数轴关闭时分析路径与输出与今天完全一致单窗、既有平滑。R6— 多分辨率路径在 44.1 kHz 音频源、默认刷新率下不引入可感知的 UI 迟滞总分析代价不超过当前单次 FFT 代价的约 3 倍。R7— 既有 FFT 配置窗口大小、采样率、窗函数、dB 范围继续有效窗口大小继续界定延迟/历史配置的窗函数应用于所有分析区域。R8— 对数轴上的缩放、平移、十字线、光标读数在多分辨率谱上继续工作读数为真实 Hz/dB与 0014 一致。R9— 低端手感实时最细分析级受响应时间约束约 0.4 s 观测目标——分辨率与响应是同一个物理旋钮Δf 1/T按窗口大小与采样率自适应伸缩而非固定倍数2026-07-17 在实测发现固定 16 倍扩展对音频级窗口手感迟钝后加入。R10— 对数轴从最细分析级的第一个 bin 开始——这是对数轴能逼近 0 Hz 的极限——分析捕获到的一切都不被裁剪2026-07-17 决定取代了临时的 ~100 Hz 默认下界。其中 R9 值得单独展开Δf 1/T 意味着想要更细的 bin就必须看更长的时间代价是谱的变化到得更晚。plan 中的实现是kMaxFinestWindowSec 0.4——级数 min(容量允许, 时间允许)于是音频级窗口不再盯数秒的历史而用户若主动配置了一个已经 ≥ 0.4 s 的窗口则保持单级——预算本身就是用户的分辨率选择。tasks.md T6 指出这个时间预算还结构性地化解了评审中大 N 时每 tick 代价的担忧只有当整个 span ≤ 0.4 s 的样本量时才存在 3 级。验收准则 AC1–AC9 与验证手段所有 9 条验收准则在实施期均标记通过maintainer check 基准门禁AC1运行中的应用、44.1 kHz 音频源音乐/宽带音频低端平滑有细节200 Hz 以下无直线段气质接近参照分析仪截图AC2双音测试100 Hz 126 Hz对数轴打开显示两个峰关闭对数复现今天的单峰渲染证明线性路径未被触碰AC3白噪声渲染为连续谱唯二的电平变化是两个接缝处预期的平滑噪声密度台阶无单 bin 突变扫频正弦完全没有接缝AC450 Hz → 5 kHz 恒幅扫频峰 dB 电平全程稳定无逐频段增益跳变AC5--benchmark-hotpath在既有门禁下通过分析运行在 UI 节奏摄入未动——门禁证明无回归AC6既有线性轴 FFT 项目渲染一致fftLogX: true的项目无需重新编辑即获得新渲染AC7一个对数轴 FFT 组件、默认刷新的 CPU 占用与改动前同量级任务管理器抽查AC8低端在半秒内可见地跟踪节目内容变化——相对高端无多秒级滞后AC9对数轴从最低可分辨 bin 开始低端无裁剪轴范围对话框仍可进一步收窄视图。验证手段组合维护者视觉检查音频源 双音 白噪 扫频、--benchmark-hotpath热路径门禁、python scripts/code-verify.py --check静态检查见 scripts/code-verify.py、代码评审与sanitize-commit.py提交清洗。本功能为纯显示路径无新增 API/schema因此没有可运行的 pytest 目标。约束与工程不变量仅显示侧摄入、环与 256 kHz 热路径门禁均不触碰新增分析工作全部运行在组件层的 UI 绘制节奏与 0014 同层零 schema/API 增量无新 project 键、无编辑器项、无 API 字段功能完全挂在既有fftLogX标志上历史扩展是被动且有界的更长的低频窗口来自既有 FFT 采样环在 configure 时的有界扩展plan 门禁于 2026-07-17 批准每样本摄入代码路径必须 byte-identical——无新摄入逻辑、计数器或逐帧工作确定性内存新增分析缓冲在 configure 时定尺寸稳态免分配与 0014 scratch 环同纪律无新依赖既有 FFT 库——kissfft——足够见 lib/KissFFTQuickPlot 自动生成的音频 FFT在对数轴开启时自动获得该改进无特判。Tasks T1 还记录了一条代码评审遗留configureFftSeries中针对恶意fftSamples输入的 clamp未裁剪的 project 输入可能让 16 倍扩展溢出为负环容量——该 clamp 在功能移除后依然保留在 0018 的代码中当前 Dashboard::configureFftSeries 中。为何同日下架延迟物理与规格 0018 的接棒这是本 spec 最有价值的部分。0016 完整实施、按规格工作然后在同一天被 0018-smooth-log-fft 取代状态标记为shelved见 spec.md 头部 front-mattersuperseded by 0018-smooth-log-fft (2026-07-17): uniform latency beat multi-res low-band resolution; implementation removed same day。原因回到那条物理约束低端的长观测窗使低频天然滞后于高频Δf 1/T。AC8 的 0.4 s 时间预算与 0017 ballistics释放时间常数都无法消除起攻延迟差——实测中它反复暴露。0018 调查了参照工具后得出结论专业 DAW 频谱分析仪并不做多分辨率——它们跑一个中等尺寸的单一 FFT处处延迟一致把稀疏的低端 bin 渲染成对数空间中的平滑插值曲线再加 ballistics。于是决策改为接受单 FFT 的低频分辨率让它画得平滑手感保持均匀且实时。0018 的落地对照当前源码移除 0016 机制抽取级联、FIR 抽头、级布局/拼接、各级 scratch 缓冲以及 Dashboard 环扩展——对数与线性 FFT 重新共享一条代码路径环容量 clamp 后的fftSamples新增FFTPlot::buildLogRenderCurveFFTPlot.cpp#L678在 log-x 空间用 Fritsch-Carlson 单调三次PCHIP绝不过冲、峰位诚实穿过各 bin重采样到均匀 2048 点对数网格rebuildLogBinTable 在 ctor/plan 重建时缓存每 bin 的 log-x 位置稳态免分配每 tick 管线computeBinSpectrumdB 箱式平滑 可选 0017 ballistics→ 线性轴走emitLinearSpectrum形状不变或对数轴走buildLogRenderCurve。值得注意的是 0016 有两项遗产活在了当前代码里R10 的轴下界原则applyLogFrequencyBounds 中m_minX clampedLog10(freqStep)freqStep fs/N——对数轴从第一个 FFT bin 开始分析捕获到的一切都不被裁剪注释原文几乎照搬 0016 的表述一致的1/N²功率归一化computeBinSpectrum 中normFactor N·N的归一化纪律正是 0016 用来保证跨接缝标定一致R4的同一机制现在服务于单一路径的电平稳定性。架构文档 doc/claude/architecture/dashboard.md 中对应的段落先由 0016 的 T5 写入扩展环 三级拼接随后由 0018 改写为单窗 平滑渲染的描述。实践启示与适用前提从这份当天立项、当天实施、当天退役的 spec 可以提炼出几条可复用的经验Δf 1/T 是硬约束频谱分辨率与响应速度是同一个旋钮任何多分辨率方案都必须显式回答低频能慢多少。0016 用 0.4 s 时间预算R9回答了但实测表明用户在意的是各频段间的延迟差而非绝对延迟——这个洞察直接改变了方案方向接缝是拼接类 DSP 的主要风险面0016 用统一窗 统一1/N²归一化 0.4·Nyquist 交叉 分段平滑四件套预防接缝可见性并用扫频正弦AC4作为标定门禁热路径零侵入的可证明性把 ring 扩容做成 configure 时的一行 O(1) 无感变更用--benchmark-hotpath门禁而非代码评审来证明摄入路径无回归保留被取代的设计文档是严肃的工程实践0016 的 R3/R4 标定分析、交叉余量与 stage 数学在 plan 中明确标注若日后以可选高分辨率低端模式重审该方案时仍然有效。适用前提本 spec 的时间线为 2026-07-17创建、批准、实施、验收、下架同日完成文中路径引用以当时仓库布局为准app/src/UI/...当前代码树中对应实现位于core/Ui/UI/Widgets/FFTPlot.cpp与core/Ui/UI/Dashboard.cpp。阅读时请以 0018 spec 为现行行为的权威描述0016 作为其设计史与取舍依据阅读。【免费下载链接】Serial-StudioOpen-source telemetry dashboard. Supports UART, BLE, MQTT, Modbus, CAN Bus and more.项目地址: https://gitcode.com/GitHub_Trending/se/Serial-Studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考