SX1262 實驗室 #9：射頻的細節，PA Ramping 與防止接收死鎖的 Rx Timeout 機制

作者：ZeroGrid實驗室

在上一篇日誌中，我們解決了省電設定與暖啟動，我們接著將目光轉向更細微的射頻物理層設定。

在工業級的無線通訊中，「能收到訊號」只是及格線。為了符合法規並確保在複雜電磁環境下的穩定性，我們必須精確控制發射時的能量釋放曲線，以及接收時的狀態機邏輯。

本篇日誌將探討兩個關鍵主題：如何透過 PA Ramping 抑制頻譜噴濺，以及如何正確設定 Rx Timeout 來避免接收死鎖。

1. PA Ramping：抑制頻譜噴濺的關鍵

為什麼不能瞬間全功率發射？

許多開發者在設定 LoRa 參數時，往往只關注頻率、擴頻因子 (SF) 和頻寬 (BW)，卻忽略了 PA Ramp Time (功率放大器爬升時間)。

從物理學的角度來看，如果我們讓射頻晶片在極短時間內（例如 < 10µs）從「靜默」直接切換到「+22dBm 全功率輸出」，這種電流的劇烈階躍變化 (Step Response) 會在頻域上產生寬頻的雜訊，稱為頻譜噴濺 (Spectral Splatter)。這不僅會干擾鄰近頻道的裝置，也會對電源系統造成瞬間的電壓驟降 (Voltage Dip)。

SX1262 的 Ramp Time 設定

根據 Semtech SX1262 Datasheet，SetTxParams (OpCode 0x8E) 指令負責設定發射功率與爬升時間。該指令的第二個參數 RampTime 定義了功率上升的斜率。

SX1262 提供了多種梯形爬升的選項（對應暫存器數值）：

0x00: 10 µs
0x01: 20 µs
0x02: 40 µs
0x03: 80 µs
0x04: 200 µs
0x05: 800 µs
0x06: 1700 µs
0x07: 3400 µs

ZeroGrid 的選擇：200 µs

在早期的 LoRaWAN 規範或一般範例中，常使用 40 µs (0x02) 作為預設值。然而，為了進一步降低對電源的瞬間衝擊，並獲得更平滑的頻譜邊緣，稍微放慢爬升速度是值得的。

ZeroGrid 目前選用 200 µs (0x04) 作為標準設定。雖然這會稍微增加一點點「空中時間 (Time on Air)」，但對於長距離、高功率 (22dBm) 的應用場景來說，這 200 微秒的緩衝能顯著提升系統的電磁相容性 (EMC) 表現。

2. Rx Timeout：防止接收死鎖的最後防線

接收超時的必要性

在 CSMA (載波偵測) 或 P2P 通訊協定中，裝置不能永遠處於接收模式，否則會迅速耗盡電池，且無法處理其他任務。因此，我們需要設定 Rx Timeout。

SX1262 的 Timeout 計算方式

SX1262 的 SetRx (OpCode 0x82) 指令接受一個 24-bit 的整數參數作為超時設定。這裡有一個容易踩坑的細節：它的時間單位並不是毫秒 (ms)。

晶片內部的計時器時基 (Time Base) 是基於 64 kHz 的頻率，這意味著每一個 Tick 代表：

1 / 64,000 = 15.625 µs

因此，若我們要設定 T 毫秒的超時時間，寫入暫存器的數值 N 應為：

N = T × 64 (因為每64個tick等於1ms, 15.625µs x 64 = 1ms)

若寫入 0x000000：代表連續接收模式 (Continuous Mode)，永不超時。
若寫入 0xFFFFFF：代表最大超時時間。

狀態機死鎖與「先暫停、再啟動」

在開發過程中，我們發現了一個嚴重的邏輯陷阱：如果在晶片尚未完全退出上一次 RX 狀態時，直接再次發送 SetRx 指令，Timeout 計時器有時不會重置。

這是因為 SX1262 的 Timeout 計時器是基於狀態進入 (Entry into Rx state) 觸發的。如果晶片狀態一直是 RX (例如正卡在雜訊解碼中)，再次發送 RX 指令並不會觸發「狀態切換」，導致計時器沒有歸零，進而引發「接收死鎖」—軟體以為有在倒數，但硬體其實已經停擺或超時錯亂。

為了解決這個問題，我們實作了一套標準的切換邏輯：

發送 SetStandby (OpCode 0x80)：強制晶片進入待機模式，中斷當前所有動作，並重置內部狀態機。
計算 Tick：將目標毫秒數乘以 64。
發送 SetRx (OpCode 0x82)：帶入計算好的參數。

這個 Standby -> Rx 的動作創造了一個明確的「狀態邊緣 (Edge)」，確保硬體計時器每次都能精準啟動。

3. 實驗驗證

為了驗證上述機制的可靠性，我們在 Console 介面中實作了 /rx 指令，並進行了不同時間長度的壓力測試，觀察硬體中斷 (IRQ) 是否能準時觸發。

測試：長時間超時 (3000 ms)

測試較長的等待時間，確認計數器不會溢位或提早終止。

Plaintext

> /rx 3000
[RX] Listening for 3000 ms...
... (經過 3秒) ...
[RX] Timeout! (No packet received)
[System] Timeout reset to 0.

結果分析：硬體精準地在 3000ms 後拉高了 DIO1 腳位，觸發中斷，系統成功退出接收模式。

4. 結語

魔鬼藏在細節裡。PA Ramping 的 400µs 設定，雖然只是暫存器裡的一個小數值，卻換來了更乾淨的頻譜環境；而嚴謹的 Rx Timeout 計算與狀態機重置邏輯，則確保了系統不會在無止盡的等待鎖死。

解決了射頻層的穩定性問題後，我們終於可以放心地進行更遠距離的通訊測試。

下集預告： 在開發日誌的最終篇，我們將介紹如何使用 Semtech 的 LoRa Calculator 工具來進行科學化的 Link Budget (鏈路預算) 計算，評估不同參數下的理論通訊距離與空中時間。