簡(jiǎn)介一份面向電子愛好者、嵌入式開發(fā)者與移動(dòng)測(cè)量應(yīng)用學(xué)習(xí)者的安卓藍(lán)牙示波器資料包將手機(jī)轉(zhuǎn)化為便攜式信號(hào)檢測(cè)與分析工具無需傳統(tǒng)臺(tái)式示波器即可在電路調(diào)試、傳感器信號(hào)觀察、課堂演示等場(chǎng)景中查看實(shí)時(shí)波形。壓縮包約115KB共8個(gè)文件包含1個(gè)可直接安裝的APK、5個(gè)Java源碼文件、1張硬件原理圖JPG及1個(gè)dsPIC固件RAR包覆蓋信號(hào)采集、藍(lán)牙傳輸?shù)桨沧慷瞬ㄐ物@示的完整鏈路。電路圖清晰展示信號(hào)采集與ADC模數(shù)轉(zhuǎn)換部分Java源碼便于學(xué)習(xí)Android藍(lán)牙API調(diào)用、藍(lán)牙Socket通信和波形繪制邏輯dsPIC固件則為下位機(jī)采集程序提供參考利用這套資料可自行修改硬件設(shè)計(jì)提升ADC分辨率或增加存儲(chǔ)、回放、參數(shù)設(shè)置等高級(jí)功能。已有2383人學(xué)習(xí)下載適用于需要低成本移動(dòng)測(cè)量方案或入門藍(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è)位置一動(dòng)不動(dòng)。問題不在 App 寫得爛而在于你讓一條藍(lán)牙鏈路干了它原本干不了的活示波器本質(zhì)是數(shù)據(jù)搬運(yùn)工它要在幾百毫秒內(nèi)把幾萬個(gè)采樣點(diǎn)搬上屏幕而經(jīng)典藍(lán)牙串口或 BLE 通知在理想條件下的有效凈荷也只有每秒幾十 KB。一個(gè) 20KB/s 左右的信道和動(dòng)輒幾百 kSa/s 的采集率差了整整一個(gè)數(shù)量級(jí)。這就是安卓藍(lán)牙示波器最底層的悖論采集端多快都能采瓶頸永遠(yuǎn)在無線鏈路上。搞懂這套機(jī)制不是滿足好奇心。你調(diào)采樣率、改包長(zhǎng)度、重畫波形時(shí)遇到的所有玄學(xué)問題——為什么低時(shí)基下波形稀疏、為什么切到雙通道就丟包、為什么長(zhǎng)時(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ī)主動(dòng)注冊(cè)監(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)牙透?jìng)髂K它內(nèi)部會(huì)把 UART 流切成 L2CAP 數(shù)據(jù)包依然受這個(gè)限制。20 字節(jié)意味著采樣率 100kSa/s、每個(gè)樣本 2 字節(jié)12 位 ADC 對(duì)齊到 16 位一秒鐘產(chǎn)生 200KB 數(shù)據(jù)BLE 在 1Mbps 物理速率下實(shí)測(cè)有效吞吐量樂觀估計(jì)在 3050KB/s200KB 顯然是塞不進(jìn)去的于是硬件端必須降采樣率或者軟件端丟點(diǎn)。你看到的實(shí)時(shí)波形背后是一個(gè)被迫砍掉 90% 數(shù)據(jù)的傳輸策略。2.2 硬件原理圖里的信號(hào)路徑典型的硬件方案是信號(hào)經(jīng)過運(yùn)放調(diào)理分壓、跟隨、抬升到 ADC 量程→ MCU 內(nèi)置 ADC 由定時(shí)器觸發(fā)采樣 → DMA 把結(jié)果搬到內(nèi)存緩沖區(qū) → 固件按幀打包 → UART TX 發(fā)送到藍(lán)牙模塊。原理圖上你會(huì)看到三個(gè)關(guān)鍵器件運(yùn)放、MCU、藍(lán)牙模塊它們之間只有幾根走線但每根走線都決定了波形質(zhì)量。運(yùn)放的輸出阻抗和 ADC 采樣電容直接決定了信號(hào)建立時(shí)間。如果運(yùn)放到 ADC 引腳之間串了太大的電阻采樣瞬間電壓建立不完全高頻率信號(hào)就會(huì)幅度衰減俗稱波形糊了。原理圖里如果有 1kΩ 以上的串阻且沒有加采樣保持電容這是第一處要檢查的地方。另一個(gè)隱蔽點(diǎn)是 ADC 參考電壓如果用 MCU 內(nèi)置參考且選擇了 3.3V 供電電池電壓波動(dòng)會(huì)直接讓讀數(shù)漂移所以合格的設(shè)計(jì)會(huì)單獨(dú)留一個(gè)精密參考源或至少用 LDO 穩(wěn)壓后給 MCU 供電。2.3 為什么說透?jìng)魇且粋€(gè)黑匣子很多藍(lán)牙透?jìng)髂K對(duì)外宣稱串口透?jìng)骱孟?MCU 寫串口、手機(jī)就能收到流。實(shí)際工作方式是MCU 的 UART TX 進(jìn)入模塊模塊內(nèi)部固件將字節(jié)流切包、加 L2CAP 頭、經(jīng)射頻發(fā)出手機(jī)端 BLE 協(xié)議棧把這些包重組后交給 App。問題在于重組并不完美模塊廠商會(huì)設(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ù)手冊(cè)里找到 PDU 長(zhǎng)度和連接間隔Connection Interval參數(shù)。連接間隔 7.5ms30ms它決定了底層多久和主機(jī)同步一次間接影響可達(dá)吞吐量。同一款模塊廠商讓用戶把連接間隔從 30ms 改成 7.5ms吞吐量能翻倍。資源里的固件工程一般在初始化代碼里有一個(gè)連接參數(shù)更新請(qǐng)求修改minInterval/maxInterval就能看到實(shí)際速度變化建議你實(shí)際動(dòng)手改一改并抓包對(duì)比比讀十遍文檔都管用。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ù)右對(duì)齊成 16 位高 4 位補(bǔ) 0那么每個(gè)樣本的低字節(jié)可能一直是 0xF0但高字節(jié)可能是任意值。首字節(jié)錯(cuò)位會(huì)導(dǎo)致整幀數(shù)據(jù)全亂畫出來的波形是疊加了偽隨機(jī)噪聲的毛刺。第二無線鏈路會(huì)重傳。BLE 在鏈路層有 CRC 校驗(yàn)和重傳機(jī)制但重傳導(dǎo)致的延遲抖動(dòng)會(huì)讓包到達(dá)時(shí)間完全不可預(yù)測(cè)如果按包到達(dá)時(shí)間推算樣本的時(shí)間間隔你得到的時(shí)基就是一個(gè)不停抖動(dòng)的擺鐘。第三你不知道 MCU 端此刻處于什么狀態(tài)——是剛開始采樣還是已經(jīng)采了一半還是剛從低功耗模式喚醒。區(qū)分這些信息的唯一手段是在數(shù)據(jù)里顯式聲明邊界和狀態(tài)。3.2 幀協(xié)議的經(jīng)典結(jié)構(gòu)這份資源里的固件和 App 配合使用一套自定義幀格式常見設(shè)計(jì)如下包頭(0xAA 0x55) | 幀長(zhǎng)度(1B) | 通道數(shù)(1B) | 采樣率編號(hào)(1B) | 樣本數(shù)(2B) | 樣本... | 校驗(yàn)和(1B)對(duì)應(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); // 幀長(zhǎng)度 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é)流里誤碼后重新同步的概率極低。幀長(zhǎng)度字段讓你能區(qū)分這只是半包還是完整一幀傳輸被切分后App 可以先把收到的字節(jié)攢著等湊夠了幀長(zhǎng)度再解析。采樣率編號(hào)不是直接用數(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é)對(duì)但次字節(jié)錯(cuò)回退重找 break; case WAIT_LENGTH: expectedLen (b 0xFF) 2; // 長(zhǎng)度字段代表剩余部分 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ò)位越積越深。你會(huì)在 App 源碼里看到同樣的邏輯只是用 Kotlin/Java 寫成了可讀性更高的狀態(tài)類。解析完成后把樣本數(shù)組交給顯示層同時(shí)用幀內(nèi)帶的采樣率編號(hào)回推每個(gè)樣本的實(shí)際時(shí)間這樣即使包到達(dá)間隔抖動(dòng)畫出來的波形橫軸依然準(zhǔn)確。從資源的使用角度看如果你想把這套代碼移植到自己的板子上改動(dòng)只需三處固件里的采樣率編號(hào)表、App 端FrameParser里的對(duì)應(yīng)關(guān)系、以及校驗(yàn)算法是否一致。這三處都對(duì)不上最常見的結(jié)果是 App 能收到數(shù)據(jù)但一直提示幀校驗(yàn)失敗波形永遠(yuǎn)出不來。4. 安卓端實(shí)現(xiàn)GATT 回調(diào)、環(huán)形緩沖與波形繪制管線4.1 BLE 連接與通知注冊(cè)的關(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只是本地注冊(cè)真正讓設(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ù)寫操作會(huì)打斷正在進(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é)卡頓都會(huì)導(dǎo)致 BLE 棧內(nèi)部緩沖積壓。Android 的 BLE 棧對(duì)慢消費(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主動(dòng)重繪。繪制核心在onDraw里對(duì)樣本做降采樣把 4 萬個(gè)樣本映射到屏幕寬度 1080 像素上每個(gè)像素列取該區(qū)間內(nèi)的最大值和最小值畫一條豎線而不是取平均值。這樣能保留尖峰信息否則窄脈沖會(huì)被平均掉看起來像被磨平了。這個(gè)min-max 降采樣策略是數(shù)字示波器顯示引擎的通用做法你在資源里的自定義 View 中能看到對(duì)應(yīng)代碼它直接決定你能不能看清一個(gè) 10μs 寬的毛刺?；鶞?zhǔn)線和電壓刻度則是從幀頭里的量程信息換算出來的App 顯示500mV/div時(shí)實(shí)際上是每格對(duì)應(yīng)多少 ADC 碼值。4.4 時(shí)基重建不能用包到達(dá)時(shí)間當(dāng)時(shí)間戳這是最容易翻車的地方。很多人畫波形時(shí)直接用 System.currentTimeMillis() 記錄每個(gè)樣本的到達(dá)時(shí)間畫出來的波在靜止時(shí)能看可一旦信號(hào)頻率稍高波形就會(huì)橫向抖動(dòng)看起來像在呼吸。原因很簡(jiǎn)單BLE 包的到達(dá)間隔在鏈路層重傳和調(diào)度的影響下可能波動(dòng)數(shù)十毫秒把這個(gè)抖動(dòng)當(dāng)作采樣時(shí)間等于給波形加了一個(gè)隨機(jī)時(shí)間噪聲。標(biāo)準(zhǔn)做法是完全信任幀頭里的采樣率編碼。收到一幀時(shí)知道起始樣本序號(hào)樣本 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è)隱蔽原因是固件里沒有對(duì) ADC 結(jié)果做軟件濾波以及運(yùn)放輸出端到 ADC 引腳之間缺少 RC 濾波網(wǎng)絡(luò)。藍(lán)牙示波器為了省功耗MCU 的采樣時(shí)鐘可能直接用內(nèi)部 RC 振蕩器頻率誤差在 1%3% 左右觸發(fā)采集的定時(shí)器抖動(dòng)直接轉(zhuǎn)換為波形上的相位噪聲。解決在原理圖上給 ADC 輸入端加一個(gè) 100Ω 串阻和 1nF 到地的電容構(gòu)成低通濾波器固件里對(duì)相鄰樣本做一階滑動(dòng)平均如new old * 0.25 current * 0.75如果追求更高精度采集時(shí)改用外部晶振或校準(zhǔn)內(nèi)部 RC。這套方案在模擬信號(hào)鏈上比對(duì)波形的平滑處理要可靠得多。5.2 長(zhǎng)時(shí)間運(yùn)行后波形卡死App 無響應(yīng)現(xiàn)象開機(jī)正常兩三分鐘后波形開始斷斷續(xù)續(xù)最后完全不動(dòng)關(guān)閉 App 重進(jìn)又恢復(fù)正常。原因App 的消息積壓導(dǎo)致onCharacteristicChanged回調(diào)無法及時(shí)執(zhí)行。你的解析邏輯可能卡在同步鎖上或循環(huán)里做了大量對(duì)象分配導(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 沒收到任何通知主動(dòng)重連 GATT。這條邏輯在資源里的連接管理類中有現(xiàn)成實(shí)現(xiàn)。5.3 采樣率設(shè)置成 100kSa/s實(shí)測(cè)只有 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í)就降采樣率如果信號(hào)是周期的就讓固件在 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% 量級(jí)誤差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)頁(yè)面寫算法就是real (raw - offset) * gain。這個(gè)系數(shù)位數(shù)必須用 float用整數(shù)除法會(huì)導(dǎo)致低量程時(shí)階梯狀誤差。5.5 低頻波形出現(xiàn)明顯臺(tái)階感現(xiàn)象輸入 50Hz 正弦波波形本來應(yīng)該平滑但屏幕上一段一段地跳像樓梯。原因屏幕刷新率 60HzBLE 推送頻率可能也只有 2030 幀/秒看起來就是一步一個(gè)臺(tái)階。不要把這個(gè)誤認(rèn)為信號(hào)本身是階梯波。如果一個(gè)包里有 200 個(gè)樣本屏幕卻只在每次收到包時(shí)畫一次那么 50Hz 信號(hào)一個(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í)性。我一般會(huì)這么權(quán)衡如果待測(cè)信號(hào)是持續(xù)輸出且只關(guān)心宏觀趨勢(shì)比如電池放電曲線、電源上電時(shí)序那 1kSa/s 的實(shí)時(shí)流就足夠如果要抓一段 5ms 的 I2C 波形毛刺就必須讓 MCU 以 1MSa/s 采集幾百個(gè)點(diǎn)存下來一次性發(fā)走。這也是為什么這份資源里的固件同時(shí)保留了連續(xù)流模式和單次捕獲模式兩個(gè)命令——它們對(duì)應(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)簡(jiǎn)單卻需要傳輸大量無關(guān)數(shù)據(jù)。資源里的固件選擇了 MCU 端做一個(gè)簡(jiǎn)易上升沿檢測(cè)ADC 連續(xù)采樣時(shí)在中斷里比較前后值捕獲到邊沿才啟動(dòng) DMA 存儲(chǔ)。這樣做的代價(jià)是你丟掉了邊沿之前的預(yù)觸發(fā)數(shù)據(jù)要做好取舍就必須在內(nèi)存里開一段循環(huán)緩沖區(qū)讓 DMA 始終寫入最新數(shù)據(jù)觸發(fā)后停止寫保留觸發(fā)前的一段記錄。從那以后我每次調(diào)試藍(lán)牙示波器都不先調(diào)采樣率而是先拿一臺(tái)信號(hào)發(fā)生器輸出一個(gè)固定頻率的方波測(cè)量 App 端顯示的實(shí)際采樣率。算清楚有效帶寬再去決定用哪個(gè)檔位、要不要開觸發(fā)、數(shù)據(jù)分塊多大。這套先驗(yàn)證鏈路后寫業(yè)務(wù)邏輯的習(xí)慣幫我省掉了大量無謂的抓包和改參數(shù)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取