簡介一份面向電子愛好者、嵌入式開發(fā)者與移動測量應(yīng)用學(xué)習(xí)者的安卓藍(lán)牙示波器資料包將手機(jī)轉(zhuǎn)化為便攜式信號檢測與分析工具無需傳統(tǒng)臺式示波器即可在電路調(diào)試、傳感器信號觀察、課堂演示等場景中查看實(shí)時(shí)波形。壓縮包約115KB共8個(gè)文件包含1個(gè)可直接安裝的APK、5個(gè)Java源碼文件、1張硬件原理圖JPG及1個(gè)dsPIC固件RAR包覆蓋信號采集、藍(lán)牙傳輸?shù)桨沧慷瞬ㄐ物@示的完整鏈路。電路圖清晰展示信號采集與ADC模數(shù)轉(zhuǎn)換部分Java源碼便于學(xué)習(xí)Android藍(lán)牙API調(diào)用、藍(lán)牙Socket通信和波形繪制邏輯dsPIC固件則為下位機(jī)采集程序提供參考利用這套資料可自行修改硬件設(shè)計(jì)提升ADC分辨率或增加存儲、回放、參數(shù)設(shè)置等高級功能。已有2383人學(xué)習(xí)下載適用于需要低成本移動測量方案或入門藍(lán)牙示波器開發(fā)的用戶也可作為電子類課程設(shè)計(jì)與畢業(yè)設(shè)計(jì)的參考資料。1. 打開 App 卻不出波形藍(lán)牙示波器的帶寬悖論把手機(jī)放到口袋、點(diǎn)開 App屏幕上應(yīng)該出現(xiàn)一條規(guī)整的正弦波?？珊芏嗳说牡谝淮嗡{(lán)牙示波器體驗(yàn)是波形成了一片馬賽克或者卡在某個(gè)位置一動不動。問題不在 App 寫得爛而在于你讓一條藍(lán)牙鏈路干了它原本干不了的活示波器本質(zhì)是數(shù)據(jù)搬運(yùn)工它要在幾百毫秒內(nèi)把幾萬個(gè)采樣點(diǎn)搬上屏幕而經(jīng)典藍(lán)牙串口或 BLE 通知在理想條件下的有效凈荷也只有每秒幾十 KB。一個(gè) 20KB/s 左右的信道和動輒幾百 kSa/s 的采集率差了整整一個(gè)數(shù)量級。這就是安卓藍(lán)牙示波器最底層的悖論采集端多快都能采瓶頸永遠(yuǎn)在無線鏈路上。搞懂這套機(jī)制不是滿足好奇心。你調(diào)采樣率、改包長度、重畫波形時(shí)遇到的所有玄學(xué)問題——為什么低時(shí)基下波形稀疏、為什么切到雙通道就丟包、為什么長時(shí)間運(yùn)行后 App 卡死——根源全在這條鏈路上。本文從數(shù)據(jù)怎么從 ADC 進(jìn)入手機(jī)內(nèi)存講起拆到安卓端 GATT 回調(diào)里的字節(jié)流處理最后落到協(xié)議設(shè)計(jì)和硬件選型的取舍。理解了這些你和這份資源里的代碼就不再是能跑和看不懂的關(guān)系。2. BLE 鏈路從 ADC 采樣到手機(jī)字節(jié)流中間發(fā)生了什么2.1 GATT 模型才是藍(lán)牙示波器真正的傳輸層藍(lán)牙示波器的硬件端通常是一個(gè) MCU 內(nèi)置 ADC 定時(shí)采樣數(shù)據(jù)通過串口發(fā)給藍(lán)牙模塊模塊再以無線方式傳給手機(jī)。聽起來像一根無線的串口線但工程上和真實(shí)的串口天差地別。藍(lán)牙模塊在手機(jī)側(cè)暴露的是一個(gè) GATTGeneric Attribute Profile服務(wù)它把事情拆成了三層Service服務(wù)、Characteristic特征、Descriptor描述符。你的波形數(shù)據(jù)不是流進(jìn)來的而是手機(jī)主動注冊監(jiān)聽某個(gè) Characteristic 的通知Notification設(shè)備端把數(shù)據(jù)切成一包一包推給手機(jī)。這里最關(guān)鍵的一個(gè)數(shù)字是 MTU最大傳輸單元。Android 上默認(rèn)的 MTU 是 23 字節(jié)減去 3 字節(jié)的 Attribute 協(xié)議頭一次通知最多攜帶 20 字節(jié)凈荷。如果你的硬件用了某款經(jīng)典藍(lán)牙透傳模塊它內(nèi)部會把 UART 流切成 L2CAP 數(shù)據(jù)包依然受這個(gè)限制。20 字節(jié)意味著采樣率 100kSa/s、每個(gè)樣本 2 字節(jié)12 位 ADC 對齊到 16 位一秒鐘產(chǎn)生 200KB 數(shù)據(jù)BLE 在 1Mbps 物理速率下實(shí)測有效吞吐量樂觀估計(jì)在 3050KB/s200KB 顯然是塞不進(jìn)去的于是硬件端必須降采樣率或者軟件端丟點(diǎn)。你看到的實(shí)時(shí)波形背后是一個(gè)被迫砍掉 90% 數(shù)據(jù)的傳輸策略。2.2 硬件原理圖里的信號路徑典型的硬件方案是信號經(jīng)過運(yùn)放調(diào)理分壓、跟隨、抬升到 ADC 量程→ MCU 內(nèi)置 ADC 由定時(shí)器觸發(fā)采樣 → DMA 把結(jié)果搬到內(nèi)存緩沖區(qū) → 固件按幀打包 → UART TX 發(fā)送到藍(lán)牙模塊。原理圖上你會看到三個(gè)關(guān)鍵器件運(yùn)放、MCU、藍(lán)牙模塊它們之間只有幾根走線但每根走線都決定了波形質(zhì)量。運(yùn)放的輸出阻抗和 ADC 采樣電容直接決定了信號建立時(shí)間。如果運(yùn)放到 ADC 引腳之間串了太大的電阻采樣瞬間電壓建立不完全高頻率信號就會幅度衰減俗稱波形糊了。原理圖里如果有 1kΩ 以上的串阻且沒有加采樣保持電容這是第一處要檢查的地方。另一個(gè)隱蔽點(diǎn)是 ADC 參考電壓如果用 MCU 內(nèi)置參考且選擇了 3.3V 供電電池電壓波動會直接讓讀數(shù)漂移所以合格的設(shè)計(jì)會單獨(dú)留一個(gè)精密參考源或至少用 LDO 穩(wěn)壓后給 MCU 供電。2.3 為什么說透傳是一個(gè)黑匣子很多藍(lán)牙透傳模塊對外宣稱串口透傳好像 MCU 寫串口、手機(jī)就能收到流。實(shí)際工作方式是MCU 的 UART TX 進(jìn)入模塊模塊內(nèi)部固件將字節(jié)流切包、加 L2CAP 頭、經(jīng)射頻發(fā)出手機(jī)端 BLE 協(xié)議棧把這些包重組后交給 App。問題在于重組并不完美模塊廠商會設(shè)置一個(gè)打包間隔常見 515ms到點(diǎn)就把緩沖區(qū)的數(shù)據(jù)發(fā)出去沒到點(diǎn)就一直攢著。這意味著你在 UART 側(cè)每次發(fā) 20 字節(jié)到了手機(jī)側(cè)可能三包并成一包到達(dá)也可能一包被拆成兩包。App 側(cè)根本不能假設(shè)一次通知 一個(gè)完整波形幀。這就是后面數(shù)據(jù)幀協(xié)議存在的前提——接收端拿到了是字節(jié)流而不是消息流。從源碼調(diào)試的角度看你可以在模塊的數(shù)據(jù)手冊里找到 PDU 長度和連接間隔Connection Interval參數(shù)。連接間隔 7.5ms30ms它決定了底層多久和主機(jī)同步一次間接影響可達(dá)吞吐量。同一款模塊廠商讓用戶把連接間隔從 30ms 改成 7.5ms吞吐量能翻倍。資源里的固件工程一般在初始化代碼里有一個(gè)連接參數(shù)更新請求修改minInterval/maxInterval就能看到實(shí)際速度變化建議你實(shí)際動手改一改并抓包對比比讀十遍文檔都管用。3. 數(shù)據(jù)幀協(xié)議怎么在亂序字節(jié)流里切出一整屏波形3.1 為什么不能直接讀一個(gè)字節(jié)畫一個(gè)點(diǎn)如果 App 每收到 20 字節(jié)就往屏幕上畫兩個(gè)點(diǎn)理論延遲最小但工程上完全不可行。原因有三第一字節(jié)流沒有邊界。你不知道哪兩個(gè)字節(jié)組成一個(gè)樣本如果 MCU 端是 12 位數(shù)據(jù)右對齊成 16 位高 4 位補(bǔ) 0那么每個(gè)樣本的低字節(jié)可能一直是 0xF0但高字節(jié)可能是任意值。首字節(jié)錯(cuò)位會導(dǎo)致整幀數(shù)據(jù)全亂畫出來的波形是疊加了偽隨機(jī)噪聲的毛刺。第二無線鏈路會重傳。BLE 在鏈路層有 CRC 校驗(yàn)和重傳機(jī)制但重傳導(dǎo)致的延遲抖動會讓包到達(dá)時(shí)間完全不可預(yù)測如果按包到達(dá)時(shí)間推算樣本的時(shí)間間隔你得到的時(shí)基就是一個(gè)不停抖動的擺鐘。第三你不知道 MCU 端此刻處于什么狀態(tài)——是剛開始采樣還是已經(jīng)采了一半還是剛從低功耗模式喚醒。區(qū)分這些信息的唯一手段是在數(shù)據(jù)里顯式聲明邊界和狀態(tài)。3.2 幀協(xié)議的經(jīng)典結(jié)構(gòu)這份資源里的固件和 App 配合使用一套自定義幀格式常見設(shè)計(jì)如下包頭(0xAA 0x55) | 幀長度(1B) | 通道數(shù)(1B) | 采樣率編號(1B) | 樣本數(shù)(2B) | 樣本... | 校驗(yàn)和(1B)對應(yīng)的 C 固件打包偽代碼void pack_and_send_frame(uint16_t* adc_buf, uint32_t sample_count, uint8_t ch_mask) { uint8_t frame[128]; uint8_t idx 0; frame[idx] 0xAA; frame[idx] 0x55; frame[idx] (uint8_t)(2 sample_count * 2 1); // 幀長度 frame[idx] ch_mask; frame[idx] g_sample_rate_code; frame[idx] sample_count 8; frame[idx] sample_count 0xFF; uint8_t sum 0; for (int i 0; i sample_count; i) { frame[idx] (uint8_t)(adc_buf[i] 0xFF); frame[idx] (uint8_t)(adc_buf[i] 8); } for (int i 0; i idx; i) sum frame[i]; frame[idx] sum; uart_write(frame, idx); }注意幾個(gè)細(xì)節(jié)。包頭用0xAA 0x55不是隨便選的0xAA 是二進(jìn)制101010100x55 是01010101在這段字節(jié)流里誤碼后重新同步的概率極低。幀長度字段讓你能區(qū)分這只是半包還是完整一幀傳輸被切分后App 可以先把收到的字節(jié)攢著等湊夠了幀長度再解析。采樣率編號不是直接用數(shù)值如 100000因?yàn)橐粋€(gè)字節(jié)只能表達(dá) 0~255所以定義一張枚舉表01kSa/s, 110kSa/s, 250kSa/s...App 端查表還原真實(shí)采樣率。校驗(yàn)和覆蓋從包頭到樣本最后一個(gè)字節(jié)能擋掉大部分射頻誤碼——BLE 的鏈路層 CRC 只保證單包傳輸正確不能保證你的數(shù)據(jù)幀跨包后依然正確。3.3 App 端的狀態(tài)機(jī)解析安卓端的解析邏輯核心是一個(gè)按字節(jié)轉(zhuǎn)移的有限狀態(tài)機(jī)。它不依賴 GATT 通知的包邊界而是把所有接收字節(jié)喂進(jìn)一個(gè)環(huán)形緩沖區(qū)然后逐字節(jié)輪詢private void parseByte(byte b) { switch (state) { case IDLE: if ((b 0xFF) 0xAA) { state WAIT_HEADER2; } break; case WAIT_HEADER2: if ((b 0xFF) 0x55) { state WAIT_LENGTH; } else { state IDLE; } // 首字節(jié)對但次字節(jié)錯(cuò)回退重找 break; case WAIT_LENGTH: expectedLen (b 0xFF) 2; // 長度字段代表剩余部分 state WAIT_CHANNEL; break; case WAIT_CHANNEL: channelMask b; state WAIT_DATA; break; // ... 繼續(xù)收樣本收滿后校驗(yàn) } }這個(gè)狀態(tài)機(jī)的關(guān)鍵在于失敗回退的設(shè)計(jì)任何一步出錯(cuò)不是丟棄一幀就完事而是回到IDLE狀態(tài)重新尋找0xAA不做計(jì)數(shù)跳過。原因很實(shí)際無線丟包后字節(jié)流里可能出現(xiàn)半個(gè)舊幀 半個(gè)新幀的拼接只有找到完整包頭才算新幀開始才能避免錯(cuò)位越積越深。你會在 App 源碼里看到同樣的邏輯只是用 Kotlin/Java 寫成了可讀性更高的狀態(tài)類。解析完成后把樣本數(shù)組交給顯示層同時(shí)用幀內(nèi)帶的采樣率編號回推每個(gè)樣本的實(shí)際時(shí)間這樣即使包到達(dá)間隔抖動畫出來的波形橫軸依然準(zhǔn)確。從資源的使用角度看如果你想把這套代碼移植到自己的板子上改動只需三處固件里的采樣率編號表、App 端FrameParser里的對應(yīng)關(guān)系、以及校驗(yàn)算法是否一致。這三處都對不上最常見的結(jié)果是 App 能收到數(shù)據(jù)但一直提示幀校驗(yàn)失敗波形永遠(yuǎn)出不來。4. 安卓端實(shí)現(xiàn)GATT 回調(diào)、環(huán)形緩沖與波形繪制管線4.1 BLE 連接與通知注冊的關(guān)鍵步驟安卓端建立 BLE 鏈路有一套固定流程BluetoothLeScanner.startScan掃描設(shè)備找到后connectGatt連接然后在onServicesDiscovered回調(diào)里拿到服務(wù) UUID 和特征 UUID。示波器的設(shè)備端通常暴露一個(gè)服務(wù)下面兩個(gè)特征一個(gè)用于 App 下發(fā)命令Write一個(gè)用于設(shè)備上報(bào)數(shù)據(jù)Notify。關(guān)鍵代碼如下public void onServicesDiscovered(BluetoothGatt gatt, int status) { if (status ! BluetoothGatt.GATT_SUCCESS) return; BluetoothGattService svc gatt.getService(SERVICE_UUID); if (svc null) return; BluetoothGattCharacteristic notifyChar svc.getCharacteristic(NOTIFY_UUID); gatt.setCharacteristicNotification(notifyChar, true); BluetoothGattDescriptor desc notifyChar.getDescriptor( UUID.fromString(00002902-0000-1000-8000-00805f9b34fb)); if (desc ! null) { desc.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE); gatt.writeDescriptor(desc); } BluetoothGattCharacteristic cmdChar svc.getCharacteristic(CMD_UUID); cmdChar.setValue(new byte[]{ (byte)rateCode, (byte)chMask }); gatt.writeCharacteristic(cmdChar); }setCharacteristicNotification只是本地注冊真正讓設(shè)備開始推送的是寫那個(gè)2902描述符里面一個(gè)字節(jié)的0x01告訴鏈路層客戶端已準(zhǔn)備好收通知。很多人漏掉這一步后果是設(shè)備端已經(jīng)在推數(shù)據(jù)手機(jī)卻完全不觸發(fā)回調(diào)。命令特征和通知特征分開是為了避免控制報(bào)文和數(shù)據(jù)報(bào)文搶占同一個(gè)通道。如果你在一個(gè)特征上又寫命令又收數(shù)據(jù)寫操作會打斷正在進(jìn)行的通知流造成周期性丟幀。4.2 回調(diào)里只做拷貝解析放到子線程onCharacteristicChanged是在 Binder 線程上調(diào)用的頻率高的時(shí)候每秒可能被調(diào)用幾十次每次攜帶 20 字節(jié)或協(xié)商后更大的數(shù)據(jù)。如果在這個(gè)方法里直接做狀態(tài)機(jī)解析、數(shù)組拷貝、UI 刷新任何一個(gè)環(huán)節(jié)卡頓都會導(dǎo)致 BLE 棧內(nèi)部緩沖積壓。Android 的 BLE 棧對慢消費(fèi)者沒有流控積壓到一定程度就靜默丟包——不是報(bào)錯(cuò)是直接丟掉。這段資源的實(shí)現(xiàn)采用生產(chǎn)者-消費(fèi)者模型private final ByteArrayRingBuffer ring new ByteArrayRingBuffer(64 * 1024); private final HandlerThread parserThread new HandlerThread(frame-parser); private final Handler parserHandler; public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic ch) { byte[] data ch.getValue(); synchronized (ring) { ring.write(data, 0, data.length); } parserHandler.post(this::parseFromRing); }環(huán)形緩沖區(qū)開 64KB足夠容納幾十幀未解析的數(shù)據(jù)。解析線程每次從 ring 里把所有可讀字節(jié)拉出來跑狀態(tài)機(jī)解出完整幀后通過Handler投遞到 UI 線程。注意其中沒有設(shè)置任何每收 20 字節(jié)解析一次的邏輯而是攢到多少解析多少這樣每幀數(shù)據(jù)的處理只經(jīng)過一次狀態(tài)機(jī)遍歷CPU 開銷被平攤丟幀率大幅下降。4.3 繪制管線波形不是逐點(diǎn)畫的手機(jī)屏幕從刷新到人眼可感知需要穩(wěn)定的幀率但 BLE 數(shù)據(jù)的到達(dá)間隔是不穩(wěn)定的。直接每收到一幀就 invalidate的后果是波形快慢不均。這里的做法是在 UI 層緩存最近 N 幀的樣本然后用一個(gè)自繪的WaveformView以顯示時(shí)鐘比如 30fps主動重繪。繪制核心在onDraw里對樣本做降采樣把 4 萬個(gè)樣本映射到屏幕寬度 1080 像素上每個(gè)像素列取該區(qū)間內(nèi)的最大值和最小值畫一條豎線而不是取平均值。這樣能保留尖峰信息否則窄脈沖會被平均掉看起來像被磨平了。這個(gè)min-max 降采樣策略是數(shù)字示波器顯示引擎的通用做法你在資源里的自定義 View 中能看到對應(yīng)代碼它直接決定你能不能看清一個(gè) 10μs 寬的毛刺。基準(zhǔn)線和電壓刻度則是從幀頭里的量程信息換算出來的App 顯示500mV/div時(shí)實(shí)際上是每格對應(yīng)多少 ADC 碼值。4.4 時(shí)基重建不能用包到達(dá)時(shí)間當(dāng)時(shí)間戳這是最容易翻車的地方。很多人畫波形時(shí)直接用 System.currentTimeMillis() 記錄每個(gè)樣本的到達(dá)時(shí)間畫出來的波在靜止時(shí)能看可一旦信號頻率稍高波形就會橫向抖動看起來像在呼吸。原因很簡單BLE 包的到達(dá)間隔在鏈路層重傳和調(diào)度的影響下可能波動數(shù)十毫秒把這個(gè)抖動當(dāng)作采樣時(shí)間等于給波形加了一個(gè)隨機(jī)時(shí)間噪聲。標(biāo)準(zhǔn)做法是完全信任幀頭里的采樣率編碼。收到一幀時(shí)知道起始樣本序號樣本 i 的真實(shí)時(shí)間為frameStartTick i / sampleRateframeStartTick由前一幀的樣序遞推而來。這樣時(shí)基是數(shù)學(xué)重建的與包到達(dá)時(shí)間無關(guān)。所以如果你的代碼里出現(xiàn)了根據(jù)接包時(shí)間計(jì)算橫軸的邏輯多半就是波形成像不穩(wěn)定的直接原因。5. 藍(lán)牙示波器避坑實(shí)錄采樣率虛標(biāo)、丟包和時(shí)基漂移5.1 波形毛刺密集像一堆頭發(fā)絲現(xiàn)象輸入一個(gè)干凈的正弦波屏幕上卻疊加了大量細(xì)碎跳變用手摸一下探頭線波形更亂。原因最常見的是硬件端 ADC 引腳浮空或參考地噪聲。另一個(gè)隱蔽原因是固件里沒有對 ADC 結(jié)果做軟件濾波以及運(yùn)放輸出端到 ADC 引腳之間缺少 RC 濾波網(wǎng)絡(luò)。藍(lán)牙示波器為了省功耗MCU 的采樣時(shí)鐘可能直接用內(nèi)部 RC 振蕩器頻率誤差在 1%3% 左右觸發(fā)采集的定時(shí)器抖動直接轉(zhuǎn)換為波形上的相位噪聲。解決在原理圖上給 ADC 輸入端加一個(gè) 100Ω 串阻和 1nF 到地的電容構(gòu)成低通濾波器固件里對相鄰樣本做一階滑動平均如new old * 0.25 current * 0.75如果追求更高精度采集時(shí)改用外部晶振或校準(zhǔn)內(nèi)部 RC。這套方案在模擬信號鏈上比對波形的平滑處理要可靠得多。5.2 長時(shí)間運(yùn)行后波形卡死App 無響應(yīng)現(xiàn)象開機(jī)正常兩三分鐘后波形開始斷斷續(xù)續(xù)最后完全不動關(guān)閉 App 重進(jìn)又恢復(fù)正常。原因App 的消息積壓導(dǎo)致onCharacteristicChanged回調(diào)無法及時(shí)執(zhí)行。你的解析邏輯可能卡在同步鎖上或循環(huán)里做了大量對象分配導(dǎo)致 GC 頻繁觸發(fā)一旦回調(diào)堆積BLE 棧背壓丟棄通知但 App 端不知道還在等新數(shù)據(jù)。解決保持回調(diào)線程的職責(zé)單一——只拷貝字節(jié)到緩沖區(qū)并 post 一個(gè)任務(wù)。解析、檢驗(yàn)、繪圖全部移出該線程。如果你已經(jīng)用HandlerThread做了解析就在環(huán)內(nèi)禁止一切日志輸出Log.d在頻繁調(diào)用時(shí)比解析更耗時(shí)。加一條自愈邏輯如果超過 500ms 沒收到任何通知主動重連 GATT。這條邏輯在資源里的連接管理類中有現(xiàn)成實(shí)現(xiàn)。5.3 采樣率設(shè)置成 100kSa/s實(shí)測只有 30kSa/s現(xiàn)象把采樣率檔位調(diào)到最高波形顯示卻依然粗糙橫軸稀疏感明顯。原因不是 App 騙人是鏈路吞吐量到頂了。BLE 有效載荷按 20 字節(jié)/包、連接間隔 15ms 計(jì)算理論 1Mbps 物理速率下每秒只有約 1.3KB/s 可用。100kSa/s × 2 字節(jié) 200KB/s差了快 200 倍。固件可能確實(shí)在 100kSa/s 采樣但發(fā)不出去于是只在緩沖區(qū)滿了之后把最新的數(shù)據(jù)發(fā)出來導(dǎo)致大量數(shù)據(jù)被丟棄。解決先用數(shù)據(jù)包計(jì)數(shù)驗(yàn)證真實(shí)吞吐量——App 統(tǒng)計(jì)每秒收到的有效幀字節(jié)數(shù)顯示為實(shí)際采樣率。然后據(jù)此反推能穩(wěn)定跑的最高檔位。如果必須實(shí)時(shí)就降采樣率如果信號是周期的就讓固件在 MCU 本地緩存一段數(shù)據(jù)一次性發(fā)完App 離線繪制這段波形。這個(gè)分段傳輸思路是許多成品藍(lán)牙示波器的真正工作模式。5.4 電壓讀數(shù)整體偏小 10%現(xiàn)象輸入 1V 直流App 顯示 0.9V換一個(gè)檔位偏差比例不變。原因這是運(yùn)放增益誤差與 ADC 參考電壓誤差疊加的結(jié)果。原理圖里運(yùn)放的分壓電阻精度 5% 就能造成 5% 量級誤差MCU 內(nèi)置參考電壓本身有 ±2% 左右的誤差。藍(lán)牙示波器為了低成本通常省略精密參考所以誤差全部帶進(jìn)了讀數(shù)。解決做兩點(diǎn)校準(zhǔn)。用已知精度的 0V 和一個(gè)基準(zhǔn)電壓比如 1.000V分別采樣算出增益和偏置把校準(zhǔn)系數(shù)燒進(jìn)固件或存到 App 偏好里。資源中的 App 有校準(zhǔn)頁面寫算法就是real (raw - offset) * gain。這個(gè)系數(shù)位數(shù)必須用 float用整數(shù)除法會導(dǎo)致低量程時(shí)階梯狀誤差。5.5 低頻波形出現(xiàn)明顯臺階感現(xiàn)象輸入 50Hz 正弦波波形本來應(yīng)該平滑但屏幕上一段一段地跳像樓梯。原因屏幕刷新率 60HzBLE 推送頻率可能也只有 2030 幀/秒看起來就是一步一個(gè)臺階。不要把這個(gè)誤認(rèn)為信號本身是階梯波。如果一個(gè)包里有 200 個(gè)樣本屏幕卻只在每次收到包時(shí)畫一次那么 50Hz 信號一個(gè)周期只畫了 5 個(gè)點(diǎn)視覺效果就是鋸齒。解決確認(rèn) App 是按幀內(nèi)樣本數(shù)補(bǔ)點(diǎn)即每個(gè)樣本都畫而不是按包畫。同時(shí)檢查WaveformView是否做了偶發(fā)式重繪改為按顯示時(shí)鐘固定 3060fps 重繪。如果 MCU 端的采樣率遠(yuǎn)高于 BLE 能推送的刷新率那每個(gè)包的樣本數(shù)必須足夠多才能保證屏幕上每幀之間有足夠的點(diǎn)覆蓋完整波形周期。6. 設(shè)計(jì)取舍帶寬換體驗(yàn)還是在協(xié)議層做補(bǔ)償藍(lán)牙示波器開發(fā)到最后繞不開一個(gè)二元選擇是讓硬件降低采樣率保證實(shí)時(shí)流暢還是讓 MCU 高速采集、分塊傳輸、App 離線繪制前者體驗(yàn)連貫但看不到高頻瞬態(tài)后者能捕獲細(xì)節(jié)但犧牲了實(shí)時(shí)性。我一般會這么權(quán)衡如果待測信號是持續(xù)輸出且只關(guān)心宏觀趨勢比如電池放電曲線、電源上電時(shí)序那 1kSa/s 的實(shí)時(shí)流就足夠如果要抓一段 5ms 的 I2C 波形毛刺就必須讓 MCU 以 1MSa/s 采集幾百個(gè)點(diǎn)存下來一次性發(fā)走。這也是為什么這份資源里的固件同時(shí)保留了連續(xù)流模式和單次捕獲模式兩個(gè)命令——它們對應(yīng)的協(xié)議幀結(jié)構(gòu)不同App 端根據(jù)幀頭里的模式字段決定是實(shí)時(shí)追加還是整幀替換。第二個(gè)取舍在觸發(fā)機(jī)制上。硬件觸發(fā)需要在 MCU 端做比較器邏輯能精準(zhǔn)定位邊沿但固件復(fù)雜度上升App 端軟件觸發(fā)是收到數(shù)據(jù)后在樣本序列里查找跨閾值點(diǎn)實(shí)現(xiàn)簡單卻需要傳輸大量無關(guān)數(shù)據(jù)。資源里的固件選擇了 MCU 端做一個(gè)簡易上升沿檢測ADC 連續(xù)采樣時(shí)在中斷里比較前后值捕獲到邊沿才啟動 DMA 存儲。這樣做的代價(jià)是你丟掉了邊沿之前的預(yù)觸發(fā)數(shù)據(jù)要做好取舍就必須在內(nèi)存里開一段循環(huán)緩沖區(qū)讓 DMA 始終寫入最新數(shù)據(jù)觸發(fā)后停止寫保留觸發(fā)前的一段記錄。從那以后我每次調(diào)試藍(lán)牙示波器都不先調(diào)采樣率而是先拿一臺信號發(fā)生器輸出一個(gè)固定頻率的方波測量 App 端顯示的實(shí)際采樣率。算清楚有效帶寬再去決定用哪個(gè)檔位、要不要開觸發(fā)、數(shù)據(jù)分塊多大。這套先驗(yàn)證鏈路后寫業(yè)務(wù)邏輯的習(xí)慣幫我省掉了大量無謂的抓包和改參數(shù)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取