2026/9/8 11:32:39

自制显示器响应时间与输入延迟测量设备:从原理到实测全解析

自制显示器响应时间与输入延迟测量设备:从原理到实测全解析 年前搞了一台新显示器标称1ms GTG响应时间240Hz刷新率结果打CS2快速转身时总感觉准星周围有一层淡淡的拖影。我把OSD里的Overdrive从“关闭”一路试到“极速”拖影倒是轻了但亮度过冲带来的白色描边更让人难受。折腾久了就冒出一个念头厂商标的响应时间到底是怎么测出来的我家这台机器实际表现究竟如何于是就有了这篇博文的主角——一套自制的显示器输入延迟与响应时间测量设备。这套设备的核心思路其实不复杂用一个光电传感器贴在屏幕上捕捉像素亮度变化同时用一个与显卡输出严格同步的参考LED作为时间起点两块信号汇入采集设备事后分析波形就能得到两个关键数字——从信号输出到屏幕开始变化的“输入延迟”以及像素从一种亮度翻转到另一种亮度所需的“响应时间”。整套硬件成本可以压在300元以内精度却足够和万元级商用设备掰手腕。适合对显示器显示链路感兴趣、想验证厂商参数是否注水的DIY玩家和硬件爱好者参考。1. 先搞清楚你要测什么输入延迟和响应时间是两回事很多玩家把“拖影”、“延迟”和“响应时间”混为一谈但测量之前必须把它们拆开。输入延迟Input Lag指的是从显卡输出一帧画面到显示器真正把这一帧显示出来所经过的时间单位是毫秒。这个时间由显示器内部的视频处理芯片、时序控制器、面板驱动电路和逐行扫描机制共同决定。响应时间Response Time指的是面板上某个像素的亮度从10%变化到90%或从90%变化到10%所需的时间单位也是毫秒它决定的是“拖影”和“模糊感”。为了理解两者的区别可以打个比方输入延迟是快递从发货到送达的时间响应时间是打开快递箱后从看到盒内物品到完全取出物品的时间。前者影响的是操作跟手度后者影响的是画面干净度。一台响应时间很快但输入延迟很高的显示器玩竞技游戏时画面不会有拖尾但鼠标移动总感觉慢半拍一台输入延迟很低但响应时间很慢的显示器操作跟手但快速转动视角时画面会糊成一团。还有一个容易混淆的概念叫“显示延迟Display Lag”它其实是输入延迟加上面板扫描延迟。液晶面板是逐行刷新的屏幕顶部的像素和底部的像素显示同一帧的时间差约等于一个完整的刷新周期。在240Hz显示器上这个扫描时间差约4.17ms所以在测量输入延迟时传感器位置放在屏幕中央测到的数值才最接近整台显示器的平均表现。这也是为什么用手机慢动作拍屏幕数帧数的方法不够精确——你没法控制拍摄区域在屏幕上的位置。1.1 厂商标称值的测量条件有多宽松厂商宣传的“1ms”响应时间多数是在最快Overdrive档位、特定灰阶过渡、特定温度条件下测出来的“最优值”甚至有些面板的1ms只针对少数灰阶跳变成立。更麻烦的是部分厂商没有任何公开的测量方法学消费者根本无从复现。2024年前后几个海外评测机构就曝光过几款标称1ms的VA屏实测最快档位下GTG响应时间在6-8ms而且伴随严重过冲overshoot。这让我越来越确信想要知道自己的显示器到底什么水平只能自己动手测。2. 测量原理拆解从屏幕亮了到波形上出现一个沿自制测量设备的核心是搭建一条能够忠实记录“光变化”的链路。整套系统包含三个部分光传感器、参考信号源、数据采集设备。下面逐个展开。2.1 光传感器选型光电二极管是正解把亮度变化变成电压变化有几种方案光敏电阻、光电晶体管、光电二极管。我在最初试过光敏电阻CdS优点是便宜且不需要运放但它有个致命问题——响应速度太慢典型响应时间在几十到几百毫秒连响应时间的零头都测不准只能放弃。光电晶体管如ST-1KL3响应速度比光敏电阻好微秒级但线性度和温漂不太理想而且上电后有明显的暗电流残留测量弱光变化时信噪比很差。最后我选了光电二极管配合跨阻放大器的方案。光电二极管工作在光伏模式零偏置时暗电流极小、线性度好配合高阻值反馈电阻把光生电流转化为电压信号。这里有个关键参数光电二极管的结电容和反馈电阻共同决定了电路带宽理论带宽约为1/(2πRC)。我在实验中用的反馈电阻100kΩ光电二极管结电容约50pF加上运放输入电容约20pF裸带宽约22.7kHz。这带宽对于测量LCD和OLED的像素翻转绰绰有余因为像素翻转事件本身的频率成分通常在几百赫兹到几千赫兹之间。不过要注意传感器的接收面越大结电容越大响应越慢。很多激光测距模块里拆出来的光电二极管结电容只有十几pF但感光面很小贴屏幕时需要非常精确地对准亮点。我建议DIY时优先选感光面直径3mm以上的光电二极管牺牲一点带宽换取贴装便利性。实测中用直径5mm的PD配合100kΩ跨阻上升沿响应速度仍然在微秒级远快于待测信号。2.2 参考信号源如何获得一个与显卡输出严格同步的时间起点要测输入延迟必须知道显卡在什么时候输出了新帧。最简单的参考源方案是用测试程序在翻转帧缓冲的同时通过GPIO或串口拉高一个LED。这个LED和屏幕画面共享同一个“起始时刻”因为程序是在渲染线程的同一帧回调里同时执行“翻转帧缓冲”和“点亮LED”的操作。实际操作中我用的是Arduino Nano通过USB串口和PC通信。测试程序用PythonPyGame渲染一个纯白色全屏窗口每帧开始渲染时向Arduino发送一个字节命令Arduino收到后立刻把D4引脚拉高驱动一个LED点亮。Arduino的串口响应延迟约几十微秒和显示器动辄几毫秒的输入延迟相比可以忽略。这里有个细节LED本身从通电到发光有纳秒级延迟几乎可以忽略但驱动LED的MOS管或三极管开关延迟却不可忽视所以我直接用Arduino的GPIO驱动LED中间串一个330Ω电阻就完事不经过继电器、不经过光耦尽可能缩短链路。2.3 数据采集设备示波器是首选声卡也能凑合采集信号的设备直接影响测量精度。严格讲需要至少两个模拟输入通道同时记录“参考LED的电压信号”和“屏幕亮度传感器电压信号”。我推荐用数字示波器带宽不低于20MHz采样率不低于100MS/s。两通道同时采样触发源设为参考LED通道的上升沿这样两个信号的相对时间关系就被严格锁存下来。二手示波器几百块钱就能收一台这是最省心的方案。如果没有示波器还有一个替代路线用电脑声卡的线路输入LINE IN做双通道采集。声卡有两个输入声道可以分别接参考LED信号和光电传感器信号。声卡采样率典型值为192kHz奈奎斯特带宽96kHz足以捕获响应时间的主要波形特征但上升沿细节会被削弱测出来的响应时间会偏大。声卡的直流响应通常不好信号经过输入耦合电容后低频会衰减测量长的背光闪烁周期或低刷新率信号时会产生基线漂移。我的建议是声卡方案只适合毛估估输入延迟响应时间测量还是得上示波器或高精度数据采集卡。3. 硬件搭建实录一块万能板搭出光探头和前级电路硬件部分我经历了三次迭代第一版用面包板第二版焊洞洞板第三版才定型。下面这套电路是我验证过最稳定的版本总共只有四个元件零基础也能一小时焊完。3.1 传感器头光电二极管加跨阻放大器原理图思路光电二极管D1正极接地负极接运算放大器的反相输入端虚拟地运放同相输入端接地反馈电阻R1跨接在反相输入端和输出端之间。当光照到D1上时等效于在反相输入端注入一股光生电流运放输出电压等于电流乘以反馈电阻。元件选型光电二极管选大面积PIN型如BPW34或SFH213感光面约7平方毫米。运放需要低偏置电流、轨到轨输出的型号我用的是OPA2350偏置电流仅0.6pA压摆率22V/μs带宽38MHz。反馈电阻100kΩ可调电阻先用固定100kΩ再并一个微调电容补偿。这里有一个跨阻放大器自激振荡的经典坑。运放输入端存在寄生电容光电二极管结电容加PCB走线电容这个电容和反馈电阻在反馈环路中引入一个极点相位裕度不足时电路会高频振荡。解决办法是在反馈电阻上并联一个1-10pF的补偿电容具体容值从小到大试直到示波器上波形不再振铃为止。我用5pF时带宽略降到约300kHz完全不影响液晶测量输出波形干净得像教科书。3.2 探头固定工装不要用吸盘用热熔胶探头的固定方式直接决定测量重复性。一开始我用3M双面胶贴传感器发现屏幕上留下胶痕且不容易调整位置。后来改用热熔胶先在传感器侧面涂一点热熔胶然后贴在屏幕中央冷却后固定得很牢撕下来也不伤屏幕。注意热熔胶涂抹时要避开感光面否则胶体透光不均会影响测量一致性。为了确保每次测量时传感器和屏幕之间距离一致我设计了一个很小的塑料套管套在传感器外面顶端留一个直径2mm的圆孔作为进光孔。进光孔对准要测的屏幕区域周围用黑色泡棉垫一圈隔绝环境光。环境光是测量的大敌屏幕上黑色的位置并不代表零亮度而是背光透过液晶分子后的残余亮度如果实验室开着顶灯光电二极管会同时吸收环境光和屏幕光叠加后的信号会严重干扰阈值判断。我测量时会把显示器周围灯光关掉并用一块黑色绒布盖住传感器周边区域实测环境光从贴屏前的几百勒克斯降到零点几勒克斯。3.3 参考LED驱动电路参考LED我用了高亮度红色LED直径5mm串联330Ω限流电阻后接在Arduino D4引脚上。之所以用红色是因为和白色屏幕测试画面的光谱成分有明显区别——屏幕全白画面包含红光成分如果参考LED也用白色光电二极管会把参考光和屏幕光混在一起传感器电路没法区分。红色LED的光谱集中在620-640nm而白色LCD屏幕通过滤色片发出的红光光谱峰值也在这个区间但测量时参考LED并不贴在显示器上也不会被光电二极管采集到因此没有区分问题。实际上参考通道由示波器直接采集LED两端的电压信号不走光电二极管。为了让示波器采集到的参考LED上升沿尽可能陡峭我直接把示波器探头夹在LED两端而不是夹在Arduino的引脚上。Arduino GPIO输出高电平时大约5VLED导通压降约2V限流电阻压降3V流过约9mA示波器探头1MΩ输入阻抗并联上去只会影响零点几毫伏几乎不干扰电路。实测LED从GPIO拉高到完全点亮电压上升时间约300ns换算成输入延迟测量的误差不超过0.0005ms完全可以忽略。4. 软件测法与波形分析把时间戳从波形里抠出来硬件搭好后接下来就是数据采集和信号处理。示波器把波形保存为CSV文件我用Python写脚本分析核心逻辑分为四步去基线、平滑滤波、找阈值穿越点、就算法计算结果。4.1 波形预处理去掉直流偏置和噪声毛刺光电传感器输出的电压信号在没有光照时大约0V屏幕全白时大约2-3V取决于屏幕亮度和传感器距离。直接分析原始信号会遇到一个问题屏幕亮度翻转瞬间信号可能叠加了来自电源的几十毫伏噪声阈值穿越点检测容易被毛刺干扰。我的做法是先对整个波形做一次中值滤波窗口宽度约5个采样点去除尖峰噪声然后取波形起始段的平均电压作为基线对应屏幕显示黑色或灰色之前的稳定状态再取波形结束段的平均电压作为满幅电压。响应时间计算以这两个电压差为基准而不是以0V到3V为基准这样能规避LED电流变化和屏幕亮度不均带来的系统级误差。4.2 响应时间算法10%-90%阈值穿越画面从一种颜色切换到另一种颜色时像素亮度变化不是瞬时的而是一条有“斜坡”的曲线。VESA标准定义了两种衡量方式上升时间Rising Time和下降时间Falling Time。上升时间定义为从亮度的10%上升到90%所需时间下降时间定义为从90%下降到10%所需时间。两者统称为GTGGray-to-Gray响应时间。Python核心代码import numpy as np from scipy.signal import medfilt def calc_transition_time(time_arr, volt_arr, low_pct10, high_pct90): # 中值滤波去毛刺 v medfilt(volt_arr, kernel_size5) # 找到稳定段 base np.mean(v[:50]) # 起始亮度 target np.mean(v[-100:]) # 结束亮度 span abs(target - base) threshold_low base (target - base) * (low_pct / 100.0) threshold_high base (target - base) * (high_pct / 100.0) # 二分查找穿越点 idx_low np.argmax(np.abs(v - threshold_low) span * 0.005) idx_high np.argmax(np.abs(v - threshold_high) span * 0.005) # 反转时交换序号 if idx_low idx_high: idx_low, idx_high idx_high, idx_low return time_arr[idx_high] - time_arr[idx_low]代码里的阈值判断用“接近阈值”而不是“大于阈值”是为了应对上升和下降两种方向。对于下降沿低阈值在下、高阈值在上如果直接用“v threshold”会找不到穿越点。用绝对误差小于1%幅值范围的近似判断配合中值滤波后的平滑波形实测穿越点定位误差不超过2微秒。4.3 输入延迟算法参考LED和屏幕亮度之间的时间差输入延迟计算更简单找到参考LED信号的上升沿时刻比如设定为LED电压达到50%峰值的时刻再找到屏幕亮度信号开始上升的时刻定义为10%阈值穿越点两者相减就是输入延迟。这里有个容易忽略的细节屏幕亮度信号的起点不是电压从0开始变化的点而是越过10%阈值的点。如果直接用波形底部的噪声平台作为起点噪声波动会导致时间戳偏差达到几十微秒甚至几百微秒。用10%阈值穿越点作为“屏幕开始显示”的标志在测量界是公认的做法和商用设备口径一致。实际操作中我还会多次测量取平均值。因为显示器的输入延迟不是恒定值受当前刷新周期位置影响每次测量可能有±0.5ms到±1ms的波动。我在240Hz显示器上连续测20次得到的输入延迟标准差约为0.3ms平均值稳定性非常好。对于追求极限的玩家可以顺带计算最小值和第5百分位值因为竞技环境中“最好的情况”才是关键平均延迟里夹杂了偶尔卡顿造成的异常高值。5. 校准与误差控制自建设备最容易被喷的环节DIY设备测出的数据要能服众校准这关必须认真过。我踩过的坑主要有三类传感器带宽不够导致响应时间被低估、参考信号延迟校准不准确导致输入延迟偏差、扫描位置影响导致数据无法复现。下面逐一分享解决方案。5.1 实测传感器带宽验证法怎么确认光电二极管和运放构成的传感器真的够快最简单的方法是用一个LED产生一个已知宽度的脉冲让LED以几微秒的时间点亮和熄灭观察传感器输出波形的上升沿是否出现明显拖尾。具体做法用信号发生器产生一个频率1kHz、占空比50%的方波直接驱动第二颗LED把这颗LED放在距离光电传感器约1厘米的位置让传感器对着LED脉冲光。在示波器上读取传感器输出电压从10%升到90%的时间如果这个时间小于50μs说明传感器带宽超过7kHz足以测量绝大多数液晶面板的响应过程。如果测出来的上升沿超过200μs说明运放或补偿电容有问题先检查反馈电容是不是加得太大了。5.2 参考链路延迟的扣除参考LED从GPIO拉高到完全点亮已有约300ns延迟示波器采样本身也有触发抖动这些误差虽然极小但追求严谨时也要校准。我的做法是把参考LED直接摆在光电传感器正前方用一层薄纸扩散光避免局部过曝然后让Arduino点亮LED同步记录“参考LED电压信号”和“光电传感器信号”。此时两个信号在时间轴上应该几乎对齐测量得到的时间差就是“参考LED到传感器”的链路总延迟。把这个值作为系统延迟常量在后续屏幕测量中统一扣除。我测出来的系统延迟约为280ns不到0.001ms绝大部分场景下都可以忽略。5.3 测量位置对结果的影响屏幕不同位置的输入延迟差异很大尤其是高刷新率显示器。顶部像素比底部像素早开始新一轮扫描两者时间差可接近一个刷新周期120Hz下约8.3ms240Hz下约4.17ms。如果把传感器放在屏幕左上角测出的输入延迟会比右下角小约3-4ms。为了让数据有可对比性我统一把传感器贴到屏幕正中央并用屏幕的OSD菜单关闭所有“显示器智能处理”功能比如动态对比度、HDR映射、平滑运动等因为这些功能会引入额外处理延迟也会影响背光亮度曲线。5.4 和商用设备交叉验证的教训我有一台朋友借来的专业显示器分析仪花了几天时间让自己的设备和他那台2万块的设备测同一台显示器。结果显示输入延迟两套系统测出的差距在0.3ms以内响应时间差距在0.5ms以内。差距主要来自两台设备的传感器位置和阈值算法细节不同。这里有个重要认知响应时间测量没有绝对的“真值”不同设备、不同方法得到的数值有0.3-0.5ms的系统性差异非常正常。只要自建设备能稳定复现“同一台机在不同设置下的相对差异”就已经足够支撑科学选机和调校决定了。6. 实测案例三台显示器的数据到底该怎么读设备校准完之后我把自己手头三台显示器翻出来测了一遍覆盖三种典型面板。每台机器在测试前都预热30分钟关闭动态对比度、HDR和一切图像增强功能屏幕亮度统一设置为100cd/m²对比度50%色温6500K。需要说明的是以下数据全部来自这台自制设备和上述测量方法同型号机器因为批次差异可能存在浮动不建议直接当成绝对标准。6.1 办公入门IPS标称5ms的机器实际多少第一台是某品牌27寸2K IPS显示器厂商标称GTG响应时间5ms刷新率60Hz。实测数据项目实测值输入延迟屏幕中央16.2msGTG响应时间最快档位8.5ms上升时间黑→白9.1ms下降时间白→黑12.6ms过冲率最快档位28%输入延迟16.2ms在60Hz显示器中属于正常水平意味着整条链路比理想状态多了约一帧。响应时间8.5ms虽然比标称5ms差但实际使用中不明显因为60Hz刷新率下每帧持续16.7ms8.5ms的转换过程约占用半帧拖影肉眼可见但不算严重。最让我意外的是过冲率28%这意味着在黑白快速切换时像素会冲过目标亮度再回落形成白色描边。这个值在Fast IPS上偏高但对办公机来说无伤大雅。6.2 高刷电竞Fast IPS240Hz档位的真实水平第二台是主打电竞的27寸2K Fast IPS标称1ms GTG240Hz。同样设置下测到的数据项目实测值输入延迟屏幕中央4.3msGTG响应时间最快档位3.9msGTG响应时间最佳档位4.6ms上升时间黑→白4.1ms下降时间白→黑5.2ms过冲率最快档位11%输入延迟4.3ms很优秀接近玻璃显示器的物理极限。响应时间3.9ms虽然在240Hz帧周期4.17ms之内但余量不大快速移动时仍然会有轻微拖影。我把Overdrive从“极速”降到“正常”响应时间变到4.6ms过冲率从11%降到3%。这个案例充分说明厂商的1ms是牺牲画质换来的极限值日常使用“正常”档位反而综合体验更好。用这套设备测完之后我把这台机子的Overdrive固定在“正常”档游戏手感几乎没有变化但文字边缘明显更干净了。6.3 旗舰OLED显示器面板响应时间真的可以忽略第三台是OLED显示器标称0.03ms响应时间240Hz刷新率。OLED的像素是自发光理论上瞬时点亮但实际测量结果仍然让我看到了有趣的现象项目实测值输入延迟屏幕中央3.7msGTG响应时间最快档位1.1ms上升时间黑→白0.8ms下降时间白→黑1.4ms过冲率1.2%OLED实测响应时间1.1ms虽然远快于LCD但并没有达到标称的0.03ms。原因在于像素驱动电路和OLED材料本身的发光衰减物理特性以及PWM调光或DC调光策略的干扰。由于OLED的亮度控制方式在低亮度档位下会切换为PWM测量时我不得不把亮度拉到100%避免PWM频闪混入波形。另一个发现是OLED响应时间极快物理上不存在LCD那种拖影但OLED在低帧率下人眼感觉到的“闪烁感”和“样张拖尾”更多来自刷新率和人眼追踪的交互效应这已经不是响应时间能解释的范畴了。6.4 数据怎么看才不误导把三台机器数据放一起对比我最大的体会是不要只看响应时间单点数值。实测中至少要看三项——响应时间、过冲率、输入延迟。响应时间决定拖影长度过冲率决定拖影边缘的锐利度过冲过高会形成重影输入延迟决定操作跟手度。一台标称1ms但过冲率30%的显示器实际游戏体验可能比一台标称4ms但过冲率低于5%的显示器更差。7. 进阶测量场景与踩坑记录基础测量跑通之后我把这套设备扩展到了几个特殊场景也踩了一些值得分享的坑。7.1 VRR/Adaptive Sync下的输入延迟变化开启G-Sync或FreeSync后显示器刷新率会动态跟随显卡帧率变化输入延迟也会随之变化。我实测在某台240Hz显示器上固定60Hz刷新率时输入延迟约16ms开启VRR且在60fps场景时输入延迟约10ms而在240Hz满刷新时输入延迟约4.2ms。这说明VRR不仅能消除画面撕裂还能降低低帧率下的输入延迟。但VRR测量有个坑开启VRR后帧率和刷新率实时联动无法用固定的参考LED频率做重复测量因为每次触发的时间点处于屏幕刷新的不同相位。我最终采用的方法是锁帧后反复测量20次统计最低值代表刷新周期内最快被扫描到的相位和中位数。7.2 背光频闪BFI和PWM调光对测量的污染现代电竞显示器普遍具备“运动模糊减轻”BFI功能即通过背光黑帧插入降低动态模糊。这功能对响应时间测量是灾难背光周期性熄灭会叠加一个低频方波到亮度信号上如果不关闭BFI传感器会测到“像素翻转时间背光熄灭时序”的混合信号响应时间数值会被拉伸到完全不合理的程度。同理PWM调光显示器在低亮度下背光以几百赫兹到几千赫兹的频率闪烁光电二极管会把这种闪烁完整地记录下来波形上看就是正弦波叠加在响应曲线上。处理办法只有一个测量前把BFI、HDR、动态背光全部关闭亮度调到最高或至少调到PWM频率最高的档位确保背光处于直流供电模式。7.3 温度对响应时间的影响液晶的响应速度对温度非常敏感。寒冷的冬天液晶分子侼动变慢响应时间可能比夏天慢20%-30%。我十二月在室温15℃的房间测了一台IPS显示器响应时间8.5ms开了半小时暖空调让室温升到26℃后同机同设置下响应时间降到7.2ms。这解释了为什么有些评测机构会强调“测试环境室温22-25℃”的惯例。DIY玩家想复现厂商标称值务必保证显示器充分预热至少20分钟并记录室温否则数据自洽性会很差。7.4 自制设备还能测什么刷新率准确性、Overdrive曲线、亮度响应这套设备不止能测延迟和响应时间还可以统计实际刷新率。方法很简单用参考LED输出一个已知频率比如10Hz的方波然后对比屏幕亮度信号中检测到的翻转次数计算实际刷新率和标称刷新率的偏差。实际测试中我发现某些宣称144Hz的显示器实际跑在142.9Hz左右这是因为面板的时钟源精度通常在±0.1%到±0.3%之间。这一点在长时间锁定帧率测试时会影响画面平滑度但对绝大多数用户无关紧要。更好的应用是绘制Overdrive曲线。把Overdrive从最低档调到最高档分别测响应时间和过冲率画一张二维表就能找到该面板的最优档位。我对自己那台Fast IPS测出的结果是“正常”档响应时间4.6ms、过冲率3%“极速”档响应时间3.9ms、过冲率11%“关闭”档响应时间7.3ms、过冲率1.2%。综合人眼观察“正常”档是最优解。写在最后的几点体会整套设备从立项到校准完成前后花了三个周末。最大的收获不是测出了多少精确数字而是对“显示器标称参数”这套语言有了新的理解厂商给出的响应时间、输入延迟、亮度都是在特定条件下测出的“代表值”而非“极限值”消费者拿到的量产机甚至可能因为面板混用、固件版本不同而出现明显差异。自建设备的意义在于它把“感觉”转化为“数据”让你能针对自己手头这台机器做精细调校——究竟该用哪一档Overdrive、该不该开VRR、输入延迟对操作手感的影响有多大不再依赖玄学。如果你也想复刻这套设备我的建议是从光传感器电路做起先确保能用示波器看到干净的方波再接参考LED测输入延迟最后再写Python脚本处理波形数据分阶段推进会顺畅很多。硬件成本方面光电二极管和运放加起来不到50元Arduino用国产兼容板也就十几元示波器哪怕租或借一台也足够。最大的成本是耐心——贴传感器、调补偿电容、反复验证波形会消耗大量时间但当你看到自己测出的数据和那些知名评测网站的结论之间的差距只有0.5ms时会有一种“这设备真的通透”的踏实感。