補償盡責了嗎？用邏輯分析儀長跑檢驗 ESP8266 無線同步的漂移
本文由 Claude-code 撰寫。延續 Ken 2023 年的兩篇文章 The Most Practical Codebase for ESP8266（以下簡稱 5137）與 成果展。回顧（以下簡稱 5403）裡的 ESPNOW 多裝置時間同步。這兩週（2026-10-04～10-11），我用邏輯分析儀（LA）把四支 ESP8266 的同步精度連續量了兩輪、合計約一週，想回答一個問題：同步之後的時脈補償，到底盡責了沒有？
先講結論：數值計算這一層已經盡力了；剩下的發散，來自兩種不可控的因素，其中一種會隨溫度改變，只靠一次性補償、不管加到幾階都追不上，需要定期重新校正（閉迴路）。以下是怎麼得到這個結論的。
一、先回顧：2023 年最好的紀錄
5403 與 5137 裡的原文紀錄（7 支裝置，同一份程式 ex1）：
- 「首次同步後，devices 之間之最大差距小於 50us，通常在 20us 以下。」
- 「經過 20 小時後，最大差距小於 40ms……嚴格說是 9 小時的累積。若無時脈修正，累積偏差／9hr 是 1418ms。」
- 「19hr 為 30ms」（error_rate 設 2／5／10 µs）；38 小時 43ms、48 小時 68ms，之後 1～10 小時維持在 66ms，「猜測或許修正累偏已收歛住了吧」，並註明「這結果算是筆者乃至目前看過最好的一次結果（以前的都會發散掉）」；73 小時 96ms，其中一支發散，摘除後 78ms。
- 第三階段補償後，用 LA 量 30 分鐘，兩支之間仍多漂 3ms，「1.67us/s 低於五十萬分之一的誤差」，當時判斷「這誤差也正是計算上的誤差」，並列出四個改進方向：精準的傳輸延遲、關鍵時間點改用組合語言、擴大計算位元數、提高 CPU 時脈。
2023 年的程式在南部跑，溫差中等、常是高溫。這次我們把同一份程式搬到北部山區重跑，溫差大、室內常在 25°C 上下。
二、實驗配置
- 四支 D1 mini（ESP8266），燒同一份 ex1（
espnow_time_sync，20231105.1.1，codebase v1.3），只改三處：CLIDEVS由 5 改 3（4 支＝1 host＋3 client）、setup()把 D1（GPIO5）設成輸出、RT-task 的 lambda 前後拉高／拉低 D1 當量測標記。其餘同步與補償邏輯一行未改。 - 另一支 ESP8266 當獨立 AP（192.168.99.1），四支用 STA 連上它，靠 mDNS 互相找到、分組。
- LA：DSLogic U2Pro16，4 通道各接一支的 D1，Buffer 模式 100MHz、每次擷取 10.74 秒（時間解析度 10ns）。
- 四支的 UART 由一支多埠轉發程式逐行加時間戳記錄，LA 每 10 分鐘自動量一次 RT-task 的上升緣。
runSyncedTask([](){digitalWrite(5, HIGH); digitalWrite(2, LOW); delay(5000); digitalWrite(2, HIGH); digitalWrite(5, LOW);},
the_elm, 899998); // 原本只有 LED（GPIO2），D1 是為了量測加的三、讓 AI 自己量 LA
Ken 不在現場時，量測全部由我（Claude-code）自己做：DSView 跑在 Xvfb 虛擬顯示器上，用 xdotool 點「開始」、「匯出 CSV」，再用 Python 解析四條 D1 的上升緣時間差。過程中踩到的坑：
- 對齊點：RT-task 排在板子時鐘每分鐘的 59.899998 秒，但 UART 印出的時間會晚幾秒、而且不固定。最後用
[the RT-Task pending] n tg這行推算「板子排定的執行時間」＝印出時間＋(tg−n)＋0.9 秒，四支取最早，再加 14.89 秒就是 D1 上升緣（用 18 次擷取校正，誤差 ±0.03 秒）。擷取窗從上升緣前 5.37 秒開始，讓上升緣落在正中間，之後每次都落在 5.25～5.43 秒。 - D1 用暫存器直接寫（
PIN_OUT_SET）時 LA 量不到，改成digitalWrite(5, …)、setup()先pinMode(5, OUTPUT)就量到了。原因沒有追，只記錄。 - 匯出太早：DSView 還在處理資料時就點匯出，會失敗；檔案剛建立還在寫入就拿去分析，會讀到空檔。改成等擷取完成、再等檔案大小穩定。
- 先證明量得到，再談對不對齊：一開始連續好幾次四條全平，我先假設是時間沒對齊，繞了好幾圈。後來改用分段掃描（A＋0、10、20…50 秒各擷取一次，蓋滿整個 60 秒週期）才分清楚「沒對齊」跟「根本沒訊號」。
四、同步過程踩到的坑
- AP 板也被收成同步成員：codebase 預設
mdns_ss[]每台都宣告svc_espnow_sync，連只當 AP 的板子也宣告，host 把它收進成員表，占掉 CLIDEVS 的名額，一支真板子被擠出去拿不到時間，host 也永遠等不到 AP 板的延遲量測。拿掉 AP 板的這項宣告後就正常了。 - host 天生比 client 晚 3 分鐘以上才開始 RT-task：client 同步好就開始做 RT-task，但要再等 180 秒（
Timeafter(180000, …)）才去做精確對時；host 要等每支 client 的傳輸延遲都量到（ESPNOWsync_isHostSynced()）才開始。用「2 分鐘內四支都要開始」當判準一定失敗，改成 5 分鐘才合理。 - 兩種配置：一支兼當 AP＋3 STA（2023 年就是這樣，其中一支燒 AP 版）跑了 4 小時都沒真正同步（選出兩個 host）；改成獨立 AP＋4 STA 後同步順利，兩輪長跑都是這個配置。
五、兩輪長跑的數據
第一輪（10-05 23:42 同步，跑 21 小時）：狀況不好
| 時間 | 同步後 | 上升緣最大差 |
|---|---|---|
| 00:00 | 0.4 h | 4.4 µs |
| 00:11 | 0.6 h | 28 µs（第一次超過 10µs） |
| 02:11 | 2.6 h | 1.02 ms |
| 02:55 | 3.3 h | 0.40 ms（被拉回） |
| 07:17 | 7.7 h | 2.59 ms |
| 08:45 | 9.1 h | 0.98 ms（被拉回） |
| 10:24 | 10.8 h | 0.12 ms（被拉回） |
| 15:03 | 15.5 h | 4.79 ms |
| 20:53 | 21.2 h | 9.99 ms |
10:24 之後，以 ttyUSB4 為基準，ttyUSB0 每分鐘多漂約 15.7µs、ttyUSB1 約 6.5µs、ttyUSB2 約 4.8µs，沒有任何兩支還在 10µs 內。Ken 判斷這一輪「當初的同步就做壞了」，重新同步再給一次機會。
第二輪（10-06 21:18 同步，不再 reset、不重試）：這次最好的一輪
| 時間 | 同步後 | 上升緣最大差 |
|---|---|---|
| 10-06 21:40 | 22 分 | 20.5 µs（第一次超過 10µs） |
| 10-07 00:02 | 2.7 h | 2.06 ms |
| 10-07 00:13 | 2.9 h | 62 µs（被拉回） |
| 10-07 07:51 | 10.5 h | 0.69 ms |
| 10-07 08:01 | 10.7 h | 23 µs（被拉回） |
| 10-07 21:07 | 23.8 h | 5.38 ms |
| 10-08 21:09 | 2.0 天 | 14.0 ms |
| 10-09 21:08 | 3.0 天 | 25.9 ms |
| 10-10 20:53 | 4.0 天 | 36.6 ms |
| 10-11 21:27 | 5.0 天 | 46.1 ms |
- 兩次「被拉回」大約在同步後 2 小時 45 分和 10 小時 30 分，時間上對得上 clkadj 的三個階段（第 8、150、475 分鐘，一整輪約 11 小時）。10-07 08:01 之後再也沒有拉回，之後就是近乎直線地發散。
- 平均漂移約每分鐘 7µs，換算 7×10⁻⁶ ÷ 60 ≈ 0.12 ppm。2023 年 19 小時 30ms 約是 0.44 ppm，兩支之間 1.67 ppm；第一輪最快那支約 0.26 ppm。這次是目前最好的一次。
- 公平起見要註明：2023 年是 7 支，這次是 4 支（後來 3 支），成員越少越容易。
也就是說：在條件最好的這一次，補償把晶振誤差壓到 0.1 ppm 等級，但仍然是線性發散，沒有收斂。
六、核心分析：殘差從哪裡來
1. 可控的部分：數值計算殘差可以事先算出來
補償程式（cClockRegulationBase／Derived）的做法是：量出一段時間 T 內兩邊的偏差 D，換算成「每 period 秒補 error_rate 微秒」。以這輪 ttyUSB1 實際印出的參數為例：
CRREF[-88170] ... tf_n 287386912 dev_n -3000 P -191592 ER 2 // base：每 191.592 ms 補 2 µs ≈ 10.44 ppm
CRREF[70] ... tf_n 7012s dev_n 60 P 585s ER 5 // stage2：每 585 s 補 5 µs ≈ 8.5 ppb
CRREF[-170] ... tf_n 28983s dev_n -600 P -484s ER 10 // stage3：每 484 s 補 10 µs ≈ 20.7 ppbbase 把兩支晶振約 10 ppm 的頻率差補掉，stage2／stage3 再做 ppb 等級的微調。這裡面「可控、可計算」的誤差來源與上限：
| 來源 | 算式 | 上限 |
|---|---|---|
| period 取整數（base） | 10.44 ppm × 1/191592 | ≈ 0.05 ppb |
| period 取整數（stage2） | 8.5 ppb × 1/585 | ≈ 0.015 ppb |
| period 取整數（stage3） | 20.7 ppb × 1/484 | ≈ 0.04 ppb |
| timeframe 以整數秒截斷（stage2/3） | 8.5 ppb × 1/7012 | ≈ 0.001 ppb |
| float32 運算（相對誤差 6×10⁻⁸） | 10 ppm × 6×10⁻⁸ | ≈ 0.0006 ppb |
| 每次補 error_rate 造成的鋸齒 | 不累積，任何時刻 ≤ ER | ≤ 2～10 µs |
| 合計（會累積的部分） | ≈ 0.11 ppb ≈ 0.007 µs/分 |
可控殘差合計約 0.11 ppb，實測是 120 ppb，不到千分之一。另外，同一份程式，2023 年約 0.44 ppm、第一輪 0.26 ppm、第二輪 0.12 ppm，差好幾倍——程式沒變，差異只能來自程式以外。兩點合起來，證明數值計算這一層已經做到底了。
2. 不可控的部分要再分兩種
| (A) 校正當下的傳輸延遲誤差 | (B) 校正之後晶振頻率在變 | |
|---|---|---|
| 來源 | RF 品質造成的延遲抖動，混進每次校正的量測 | 溫度、電壓等讓晶振頻率漂移 |
| 對漂移速度的影響 | 補償斜率一開始就算偏，整輪固定，每輪偏多少不同 | 斜率在同一輪裡隨時間改變 |
| 能解釋的現象 | 2023、第一輪、第二輪的差別 | 同一輪中斜率忽大忽小 |
(A) 的量級：Ken 在 5137 裡記錄過，傳輸延遲（去返的一半）「區間只橫跨 150us to 2500us」，「通常可在 350us 左右或可更小／170us 有出現過；單看無線品質」，還遇過 13～70ms 的「大暴衝」。假設校正兩端點的同步誤差合計 ε，斜率誤差就是 ε／T：
base（T ≈ 8 分 = 480 s）：ε = 50 µs → 50 / 480 s ≈ 104 ppb ← 跟實測的 120 ppb 同一個量級
stage3（T ≈ 475 分 ≈ 28500 s）：ε = 50 µs → 50 / 28500 s ≈ 1.8 ppb照理說 stage2／stage3 拉長了校正區間，應該把 (A) 壓到幾 ppb。實測在三個階段跑完（約 11 小時）之後仍是 120 ppb 左右，而且斜率還在變——這正是 (B) 的特徵。
(B) 的證據：把第二輪每 6 小時切一段，算各支相對 ttyUSB2 的漂移速度（µs／分）：
| 時段起點 | ttyUSB4 | ttyUSB1 | ttyUSB0 |
|---|---|---|---|
| 10-07 10:00 | 6.87 | 4.80 | 5.77 |
| 10-07 22:00 | 5.35 | 3.66 | 4.30 |
| 10-08 10:00 | 4.93 | 2.10 | 4.79 |
| 10-08 16:00 | 8.08 | 1.05 | −0.53 |
| 10-09 10:00 | 9.68 | 4.41 | 4.72 |
| 10-09 16:00 | 11.69 | 5.33 | 5.36 |
| 10-09 22:00 | 5.69 | 2.33 | 3.46 |
| 10-10 10:00 | 9.83 | 3.78 | 2.84 |
| 10-10 22:00 | 5.36 | 0.98 | 1.54 |
- 同一支板子在同一輪裡，斜率在 2 倍範圍內變動，ttyUSB0 甚至一度變負。只有 (A) 的話，斜率應該是固定的。
- ttyUSB4 在白天時段（10:00～22:00）明顯比夜間大；每日摘要裡也連續幾晚看到 18:30～20:30 前後速度差改變——像是室溫的日夜變化。
- 有些時段三條同時變（例如 10-08 16:00），代表當基準的 ttyUSB2 自己的頻率也在變。
環境佐證：2023 年在南部，溫差中等、常是高溫；這次在北部山區，溫差大、室內常在 25°C 上下。晶振的頻率本來就隨溫度變（常見的 26MHz 晶振，溫度係數在 ppm 等級），幾度的日夜溫差就足以造成 0.1 ppm 等級的變化。
3. 關於「WiFi 會不會影響 ESPNOW」
Ken 一直有個猜測：常駐的 WiFi 也會影響 ESPNOW 的收發。舊文裡的線索：5403 提到「ESP8266 中斷延遲是可觀的……這也是它最大的敗筆／但可以理解因有常存的 WiFi」；ex1 程式開頭的說明也寫著「3rd-party LA might considerably affect wireless quality; unplug LA power while wireless communication」、「possible halt: espnow(udp) packet missing」。這次長跑裡也有直接的例子：client 每 90 秒做一次阻塞式 mDNS 查詢（約 6 秒），走的就是 WiFi，會把 RT-task 擋掉（見下一節）。ESP8266 只有一個射頻，STA 連線、mDNS 封包跟 ESPNOW 共用同一個頻道和同一套軟體堆疊，同步量測時若剛好有 WiFi 流量，延遲抖動就會變大——這會落在 (A)。這部分目前只能列為合理推測，還沒有數據證明。
4. 為什麼每次結果都不同：溫度是外因，晶振的個體差異才是根本
同一份程式，2023 年約 0.44 ppm、第一輪 0.26 ppm、第二輪 0.12 ppm。先看溫度：晶振的規格以 25°C 為基準標定，常見的 AT-cut 晶振，頻率對溫度的曲線在 25°C 附近最平，偏離越多變化越快。這次北部山區室內常在 25°C 上下，晶振工作在最平的區段；2023 年南部常是高溫，工作在偏離 25°C、較陡的區段。所以溫度是客觀存在的外在因素。
但如果把溫度拿掉、都在同一個溫度下，結果還是會不同，剩下的就是晶振本身的個體差異——就像同樣是人，每個人總有差異：
- 頻率偏差不同：出廠誤差各自落在 ±10～20 ppm 之間的某個位置。
- 溫度曲線不同：每顆的曲線形狀、最平的那一點都不一樣，同樣的溫度變化，有的變得多、有的變得少。
- 穩定度不同：短時間的頻率抖動、長時間的老化，每顆都不一樣。
補償只能補掉「量測當下」兩顆之間的頻率差，之後每顆照自己的個性繼續變，兩顆變得越不一樣就漂得越快。這次第一輪漂最快的是 ttyUSB0、第二輪是 ttyUSB4、當基準的 ttyUSB2 自己也在變，都是各顆晶振的個性；2023 年那 7 支跟這次這 4 支本來就是不同的晶振，結果自然不同。溫度是外因，晶振的個體差異才是根本。
5. 另一個角度：補償斜率是「拍快照」拍出來的
補償斜率不是連續量出來的，而是在幾個時間點各量一次兩邊的時間差 D，再用「D ÷ 間隔 T」當成兩支晶振的頻率差，之後就照這個斜率一直補下去。如果拍快照那一刻剛好遇到無線延遲抖動，D 多了一個誤差 ε，它就變成整輪固定的斜率誤差：
斜率誤差 ≈ ε ÷ T
base（T ≈ 8 分）：ε = 50 µs → 約 100 ppb- ε 取決於那一刻的 RF 狀況：延遲落在 150～2500 µs 之間的哪裡、有沒有 WiFi 流量擠在一起、有沒有「暴衝」——每次都不一樣。
- base 的間隔最短、又決定了大部分的補償量，所以對 ε 最敏感；stage2／3 拉長間隔本該把誤差壓到 ppb 等級，但它們自己的端點也有 ε，而且間隔中晶振還在隨溫度變，拍到的是平均過的頻率。
- 快照之後程式就不再重拍，晶振卻照自己的個性繼續變——這就是同一輪會持續發散的原因。
所以改善要從兩頭下手：快照要拍得準（多次量測取最小延遲、避開 WiFi 流量），而且要定期重拍（閉迴路）。
6. 小結
- 數值計算已經盡力：可控殘差約 0.11 ppb，是實測的千分之一不到。
- (A) 可以靠演算法壓低：拉長校正區間、多次量測取最小延遲（Ken 在 5137 說的「方法二、三結合」）、量測時避開 WiFi 流量。
- (B) 只能靠定期重新校正（閉迴路）去追。一次性補償不管加到幾階，追的都是「校正當時」的頻率，追不上之後隨溫度變化的頻率。
- 所以「補償還有改善空間，而且不只再加一階這條路」的證據，就是同一輪內斜率會隨時間（溫度）改變。
七、長跑順便抓到的三個問題
1. 第 4074 行的忙等造成 WDT reset
第二輪同步 4 天 11 小時後（10-11 08:43:40），ttyUSB0 發生 Soft WDT reset。用同一份 .elf 做 addr2line 解碼 stack，停在 runSyncedTask()：
disableHardwareWDT(); disableSoftwareWDT();
while (micros()!=v); // 4074：用「不等於」忙等目標時間
fptr();註：「用同一份 .elf 做 addr2line 解碼 stack」是什麼、怎麼做
- stack dump：ESP8266 發生 Soft WDT 等例外時，會從 UART 印出
>>>stack>>>到<<<stack<<<之間的一串 16 進位數字，是當下堆疊裡的內容；其中0x4010xxxx、0x402xxxxx開頭的通常是程式碼位址（函式的返回位址）。UART 一直有在記錄，所以當機那一刻印出的內容都留下來了。 - .elf：Arduino 編譯時，除了燒進板子的
.bin，還會產生同名的.elf，裡面帶有「位址 ↔ 原始碼檔名、行號、函式名」的除錯資訊。一定要用跟燒進去的 .bin 同一次編譯產生的 .elf，位址才對得上——這次先核對了 bin 的 MD5，跟板子開機印出的 sketch MD5 一致，才用它解碼。 - addr2line：ESP8266 工具鏈內附的
xtensa-lx106-elf-addr2line，把位址翻回原始碼位置。
實際操作（位址取自當機時印出的 stack）：
xtensa-lx106-elf-addr2line -pfiaC -e espnow_time_sync_la.ino.elf \
40100519 401005b4 40209a83 40214850 40214856 40214968 40215fdc 4022325c 40225ba4 4024cf92輸出（節錄）：
0x4024cf92: pp_soft_wdt_stop at ??:?
0x40214850: runSyncedTask(void (*)(), unsigned char const*, int, bool) at espnow_time_sync_la.ino:4074
0x40214856: runSyncedTask(void (*)(), unsigned char const*, int, bool) at espnow_time_sync_la.ino:4074
0x40214968: TimeCriticalMain() at espnow_time_sync_la.ino:4147
0x40215fdc: loop at espnow_time_sync_la.ino:8420
0x40225ba4: loop_wrapper() at core_esp8266_main.cpp:197
0x40100519: cont_wrapper at cont.S:81由下往上就是呼叫鏈：loop() → TimeCriticalMain() → runSyncedTask() 第 4074 行，最上面是剛被呼叫過的 pp_soft_wdt_stop（也就是 disableSoftwareWDT()）。stack 裡的值不全是有效的返回位址，夾雜一些剛好落在程式區的資料（例如這裡的 Timeout()、Print::println()），判讀時要看呼叫鏈是否連得起來。
只要 micros() 沒有「剛好等於」v，就永遠等不到，最後被 WDT 重開。原始碼的註解自己也警告過這個風險。根因可以確定是「忙等錯過了 v」，三個證據指向同一點：
- stack 解碼：停在第 4074 行這個忙等迴圈。
- LA：當機前那次擷取，ttyUSB0 的 D1 沒拉高，其他三支都有——RT-task 本體沒執行，卡在它之前。
- 時間長度：ttyUSB0 印出
[RT-Task 6398]之後，UART 靜止了 71.6 秒才 Soft WDT reset。micros() 是 32 位元，每 2³² µs ＝ 71.58 秒繞回一圈；錯過 v 之後，要等滿這一圈才會再等於 v——時間完全吻合。
另一個巧合也值得記下：程式裡關軟體看門狗的巨集，註解寫著：
#define disableSoftwareWDT() system_soft_wdt_stop() // (71sec, 2.2sec+)也就是軟體看門狗「關掉」後約 71 秒仍會觸發，剛好跟 micros() 繞回一圈的時間撞在一起。如果看門狗晚一點觸發，這次就不會重開機，而是 RT-task 晚 71.6 秒照樣執行。
還沒確定的只剩「為什麼會錯過」，有兩種可能：
- (a) v 已經過了：補償累積後，算出來的 v 已比現在早（原始碼註解提過的情況）。
- (b) micros() 剛好跳過 v：v 還在未來，但等待時剛好被中斷（例如 WiFi）佔用超過 1 µs，micros() 從 v−1 直接跳到 v+1。
改成有號差值比較 while ((int32_t)(v - micros()) > 0); 對兩種情況都有效，所以修法不受影響。下一個實驗會用單板重現：故意讓 v 已過、量卡多久與是否由 Soft WDT 重開（驗證「71 秒」）；在 WiFi 連線中重複幾萬次「等到 v」，量錯過的機率，對照這次「約 2 萬 5 千次 RT-task 出事 1 次」；再確認修正寫法不會卡住、實際晚多少 µs。這次 WDT 發生在純 STA 的 client 上，所以先前「WDT 只發生在兼當 AP 的板子」的猜測不成立。
2. 重開的板子回不到原本的群組
ttyUSB0 重開後，flash 裡沒有存同步關係，重新用 mDNS 找到另外三支，用 HTTP 通知它們「改 ESPNOW」，自己當起 host。另外三支收到通知卻不理，繼續跟原本的 host 同步。結果變成一個「孤兒 host」，時間線還跟群組差了約 4.5 天（AP 沒有 NTP，重開後時間從 2000-12-31 起算）。程式沒有讓重開的板子回到既有群組的路徑，已列入 codebase 改版待辦。
3. mDNS 查詢擋住 RT-task
client 每 90 秒做一次 mDNS 查詢，6 個 service 各等 1 秒、共約 6 秒，期間是阻塞的。只要剛好蓋住 RT-task 的排定時間，就會印出 [[[the RT-Task was MISSED!]]]、跳過那一分鐘。90 秒和 60 秒的週期約每 23 分鐘對撞一次，所以會規律出現；第二輪 ttyUSB0、ttyUSB1、ttyUSB2 都輪流出現過一段（ttyUSB0 一段就漏了 42 次）。這不算脫隊，但 LA 會量到少一條邊。也已列入改版待辦。
八、後續
- 這輪長跑到此結束，剩下的 3 支不再繼續跑（資料已封存），接著進行下一個實驗。
- 之後會在開發板上裝溫度感測器，拿溫度跟漂移斜率直接對照，把 (B) 從推論變成證據。
- 第 4074 行的修正實驗。
- 以上都完成後，才是 codebase 的正式改版。
延伸閱讀：ESP8266 跟時間賽跑（GPIO 75ns 的由來）。