前陣子在山區(qū)高速上盯一個誘導燈項目團霧一來整排燈帶按著節(jié)奏從遠處逐盞亮過來那種“追光”效果處理得干凈利落?，F(xiàn)場項目經理問我這套東西的無線通信到底是怎么選的是不是直接上LoRa就行說實話高速誘導燈無線通信方案選擇這件事看著是個選擇題實際做起來是需求分析題。很多方案紙面上都能跑一到高速公路上就是另一回事。這篇東西我就把做誘導燈無線通信選型時踩過的坑、拆過的需求、調過的參數(shù)以及現(xiàn)場施工里那些說明書上不寫的事完整梳理一遍。內容不局限于某一個品牌的方案重點講清楚“為什么這么選”“怎么組網(wǎng)”“同步怎么做”“功耗怎么算”適合正在做誘導燈項目的工程師、方案商、還有準備給老項目做無線化改造的運維團隊參考。1. 先搞清楚誘導燈要傳什么數(shù)據(jù)通信需求清單1.1 高速誘導燈現(xiàn)場長什么樣高速誘導燈的安裝形態(tài)大致分幾類路側護欄上的是小功率輪廓燈隧道口和彎道處的是誘導標、警示燈有的路段還會用發(fā)光地釘和霧燈。它們共同的物理特征是沿道路線性分布單燈間距20米到50米不等一個控制區(qū)段動輒幾百盞燈線路長度通常有兩公里左右。這種線性分布對通信方案的影響比很多人想象中大得多。它不是室內那種幾十個節(jié)點簇在一起的星型場景而是一條鏈子延伸幾公里。手機信號在這里不一定好山區(qū)高速尤其如此隧道、橋隧連接段、服務區(qū)前后基站覆蓋經常出現(xiàn)盲區(qū)。而且燈桿旁邊沒有商業(yè)市電是常態(tài)很多路段靠太陽能板和蓄電池供電電壓不穩(wěn)、能量有限通信模塊的功耗就變成了硬指標。這些約束疊在一起基本可以確定一件事有線方案很難做。拉網(wǎng)線或光纖進每一個燈桿材料和施工成本會直接讓項目預算失控而且高速護欄邊上開挖、穿管、破壞路面的改造成本極高。所以無線通信就成了剛需問題只在于選哪種無線。1.2 真正要傳的數(shù)據(jù)只有這四類我最早做通信選型時犯過一個錯誤把誘導燈想成了“視頻監(jiān)控”那種大數(shù)據(jù)量場景一上來就糾結帶寬。后來把需求拆開才發(fā)現(xiàn)誘導燈要傳的數(shù)據(jù)少得可憐一共就四類。第一類是開關控制包括整體開關、分區(qū)分亮滅、單燈故障后的強制點亮。這類數(shù)據(jù)就幾個字節(jié)但要求低時延尤其涉及行車安全時接到指令后若幾百毫秒沒反應司機看到的就是一盞“掉隊”的燈。第二類是模式參數(shù)比如閃爍頻率、亮燈時長、顏色切換、追光方向和速度。這類數(shù)據(jù)是“配置類”的平時不怎么發(fā)改方案的時候才會下發(fā)一次。第三類是狀態(tài)回傳包括在線離線狀態(tài)、電池電壓、LED驅動故障、當前工作模式。這類數(shù)據(jù)是周期性的五分鐘上報一次已經足夠關鍵是不能丟得太離譜。第四類是設備升級一年可能就一兩次對速率有一定要求但可以挑在深夜無人值守時慢慢傳。四類數(shù)據(jù)加在一起單幀最大也就是三四十個字節(jié)。這在任何一種無線方案里都是極其輕量的負載。所以真正的技術矛盾從來不是“傳不傳得過去”而是“在什么時刻送達”“多個節(jié)點怎么不互相打架”“缺少市電時功耗撐不撐得住”。1.3 從需求倒推硬指標把上述業(yè)務需求翻譯成通信指標大概是這樣的表格指標需求值說明單基站覆蓋距離1.5km至2km配合一個控制區(qū)段的長度端點放不下網(wǎng)關時需加中繼控制時延單節(jié)點≤200ms同步誤差≤50ms追光效果不允許肉眼可見的亂跳數(shù)據(jù)速率≥1kbps即可幀長很小低速率完全夠用節(jié)點數(shù)量一個網(wǎng)關帶200至500盞燈并發(fā)上報時必須錯峰不能一擁而上功耗待機平均電流≤1mA太陽能供電場景下通信不能成為用電大頭可靠性單燈誤閃率極低鏈路斷鏈可自愈高速場景下不能接受整段頻繁掉線這里面最坑的就是時延和功耗。前者決定了同步效果后者決定了施工后維護周期。帶著這兩條硬指標再去篩通信方案你會發(fā)現(xiàn)可選的范圍一下子就收窄了。2. 無線方案橫向對比為什么有些方案一上高速就廢2.1 ZigBee和藍牙Mesh為什么只適合室內先拿ZigBee說。ZigBee的優(yōu)點是非常成熟組網(wǎng)靈活支持Mesh多跳節(jié)點成本也低。問題是它的通信距離和頻段屬性在高速場景下很吃虧。ZigBee主要跑在2.4GHz視距通信距離一般只有七八十米到一百米出頭超過這個距離就要靠節(jié)點中轉。誘導燈是沿路一條線排開的中間節(jié)點看起來能“接力”但燈光節(jié)點通常安裝在金屬護欄或燈桿上本身高度不高、位置貼近金屬結構2.4GHz穿透和繞射能力弱車輛經過時還會形成遮擋。實測下來車流密集時段多跳鏈路的丟包率會明顯上升數(shù)據(jù)傳輸路徑頻繁重建控制命令的到達時間完全沒有確定性。再說藍牙Mesh。藍牙Mesh的信號覆蓋和組織能力確實在智能家居里很好用但它本質是泛洪式網(wǎng)絡一個控制命令發(fā)出去消息要在整個網(wǎng)內擴散節(jié)點越多網(wǎng)絡擁塞概率越大時延越不確定。在室內幾十個燈的場景還能接受在高速公路上一個區(qū)段幾百個燈泛洪帶來的就是現(xiàn)場燈光“此起彼伏”該同步的不同步不該重復的反復執(zhí)行。而且藍牙同樣受2.4GHz頻段限制很難覆蓋一兩公里。這兩類方案還有一個共同隱患2.4GHz頻段在高速現(xiàn)場太擁擠了。路邊電子情報板、視頻監(jiān)控網(wǎng)橋、服務區(qū)Wi-Fi、車載藍牙設備全都在這個頻段里搶空間。誘導燈這種性命攸關的控制鏈路不該把命運押在這么擁擠的頻段上。2.2 NB-IoT和蜂窩方案的死角NB-IoT這類蜂窩物聯(lián)網(wǎng)方案看著很省心不用自己架網(wǎng)關用運營商的基站就行。但真正去高速公路現(xiàn)場跑一圈就明白了它有幾個繞不開的死角。第一是覆蓋死角。NB-IoT主要依托運營商基站覆蓋山區(qū)高速、隧道群、偏僻路段經常只有信號弱甚至沒信號。誘導燈偏偏最愛裝在這些地方因為越是這樣的路段越需要誘導。信號都沒有方案直接廢掉。第二是時延死角。NB-IoT的定位是低功耗小數(shù)據(jù)量上報設計上對控制類業(yè)務并不友好典型下行時延在幾秒甚至十幾秒級別。誘導燈的同步追光要求誤差幾十毫秒這完全不在一個數(shù)量級上。第三是成本死角。每一盞燈一張SIM卡每年還有通信費幾百盞燈就是一筆持續(xù)支出。如果最終還是要靠自己的本地控制箱做決策那公網(wǎng)接入僅僅是個“上傳數(shù)據(jù)”的通道用NB-IoT就是在錯誤的位置用錯誤的工具。同樣的邏輯也適用于Cat.1和4G模塊。它們時延比NB-IoT低但功耗明顯偏大太陽能供電的燈桿根本扛不住長期在線。而且一片山區(qū)高速路段如果沒信號再低的時延也是白搭。蜂窩方案不是不能用而是要用對地方放在控制箱或者網(wǎng)關里做遠程平臺到控制箱之間的回傳鏈路而不是放進每一盞燈里。2.3 Sub-1G和LoRa排掉干擾項后剩下的選擇排掉ZigBee、藍牙Mesh和蜂窩方案之后真正適合長距離線性布燈的其實是Sub-1G頻段的私有無線方案其中最具代表性的就是LoRa。LoRa的核心特征是擴頻調制。它跟普通的FSK窄帶方案比最大的優(yōu)勢在于接收靈敏度。以SX1268這類常見LoRa芯片為例靈敏度能做到-137dBm左右而同樣頻段的FSK接收機通常只能到-112dBm上下。差了20多個dB換算成鏈路余量意味著同等發(fā)射功率下通信距離能差出好幾倍。在高速公路這種視距條件普遍較好的場景LoRa的實際通信距離可以輕松覆蓋一兩公里而且它用的是470MHz左右的低頻段繞射能力比2.4GHz好車流遮擋的影響也小。再加上LoRa的調制方式天然抗干擾窄帶干擾對它的影響遠小于對FSK方案的影響。當然LoRa也是有代價的。它的空口速率不高單幀傳輸時間長如果組網(wǎng)和參數(shù)配置不當一樣會翻車。這些坑后面細講但先把結論擺在前面在戶外線性分布、供電緊張、需要遠距離可靠覆蓋的誘導燈場景LoRa基本上是最穩(wěn)的答案。3. LoRa組網(wǎng)設計與參數(shù)設置距離和速率不是單選題3.1 星型加分段網(wǎng)關是高速場景的主干架構定了LoRa之后下一個問題是組網(wǎng)拓撲。有人一聽到LoRa距離遠就想著把幾百盞燈串成一條Link一發(fā)中繼接一發(fā)中繼最末端離網(wǎng)關好幾公里。這個思路理論上成立工程上非常糟糕。鏈式中繼的問題是故障級聯(lián)。中間任何一盞燈斷電、通信模塊異常、天線損壞整條鏈子就斷了而且斷點還特別難排查。高速公路上的燈桿維修本身就麻煩還得一臺一臺去查中繼狀態(tài)維護成本根本沒法控制。另外每一跳都會增加時延追光控制對時延又極其敏感多跳之后的執(zhí)行時間會變得不可控。實際工程項目里我更推薦星型加分段網(wǎng)關的架構每隔1.5到2公里的控制箱里放一個LoRa網(wǎng)關它只管自己這一段范圍的燈光節(jié)點。網(wǎng)關往上是平臺側走運營商網(wǎng)絡或者項目已有的光纖鏈路網(wǎng)關往下是LoRa星型網(wǎng)絡所有燈光節(jié)點直接跟網(wǎng)關通信。這里有個關鍵點LoRa的距離能力足以支撐2公里內的星型覆蓋所以根本不需要讓節(jié)點之間互相中繼。星型拓撲結構簡單、時延可控、單點故障的影響面小某個節(jié)點的天線壞了最多影響那一盞燈而不是拖垮整段路?？刂葡渫ǔ１旧砭陀泄╇姳Ｕ虾头览状胧┚W(wǎng)關放在里面工作環(huán)境比放在燈桿上可靠得多。3.2 擴頻因子、帶寬、編碼率的實際取值LoRa參數(shù)配置是很多團隊最容易翻車的地方。LoRa常見的配置項有三個擴頻因子SF、信道帶寬BW、編碼率CR。這三個參數(shù)共同決定了通信速率、靈敏度和空中傳輸時間它們之間是相互制約的。先給一組常用的取值對應關系配置空口速率約靈敏度水平適合場景SF7 / BW125kHz / CR4/55.5kbps較好近距離高速控制同步追光SF9 / BW125kHz / CR4/51.8kbps很好常規(guī)覆蓋兼顧距離和時延SF12 / BW125kHz / CR4/50.3kbps最好只有遠距離上報不用于實時控制我見過有人為了追求“更遠的距離”把全系統(tǒng)配成了SF12結果一幀控制指令在空中要飄一秒多節(jié)點收到之后要排隊等待信道釋放同步追光根本做不了。反過來也有人為了“更快的速度”全部用SF7結果邊緣節(jié)點信號余量不足一到雨霧天氣就丟包。實際配置建議是動態(tài)控制指令用SF7或SF8優(yōu)先保時延和同步狀態(tài)上報數(shù)據(jù)可以用SF9或SF10來保覆蓋SF12只留作特殊點位調試。帶寬建議固定125kHz因為帶寬越大接收靈敏度越差在戶外場景沒必要用250kHz或500kHz去換那點速率。編碼率保持4/5或4/6即可這是抗干擾和傳輸效率之間比較平衡的位置。還有一個容易忽略的細節(jié)計算單幀空中時間時不只是看有效載荷長度還要加上前導碼時間。前導碼默認是8到12個符號SF7和SF12下同樣字節(jié)數(shù)的幀空中時間差距非常大。我習慣在選型階段就把“最壞情況下的空中時間”算出來再回去核對時延指標別等設備裝到現(xiàn)場才發(fā)現(xiàn)控制響應跟不上。3.3 一幀控制指令怎么設計才不浪費空中時間既然空中時間這么寶貴控制幀的設計就得斤斤計較。我用過的私有協(xié)議里一幀控制數(shù)據(jù)大概長這樣前導碼加幀頭接著是目的地址、指令類型、時間戳、參數(shù)區(qū)、校驗位。目的地址可以區(qū)分單播和廣播廣播地址用于同步追光指令單播地址用于單個節(jié)點的狀態(tài)查詢和參數(shù)配置。廣播控制幀非常關鍵。誘導燈的追光、同步閃爍本質上都是“同一時刻對一批燈下發(fā)同一個命令”。這時候如果一盞一盞去單播就算每幀空中時間只有幾十毫秒兩百盞燈輪詢下來也要好幾秒根本做不到同步。所以同步類指令必須用廣播幀發(fā)地址填廣播地址所有節(jié)點同時收到同時執(zhí)行。單播幀用在狀態(tài)查詢、單燈配電、固件升級這些不需要全網(wǎng)同步的場景。狀態(tài)查詢可以帶ACK網(wǎng)關確認收到才繼續(xù)下一條廣播幀不建議帶ACK因為幾百個節(jié)點同時回ACK會把信道瞬間打爆。廣播幀的可靠性用“重復發(fā)送”來保證這個后面細說。幀里還可以加一個“執(zhí)行延時”字段。比如網(wǎng)關預計所有節(jié)點都在某一時刻收到命令但實際它們接收的時刻總有微小差異所以干脆在幀里寫“從現(xiàn)在起多少毫秒后執(zhí)行”讓所有節(jié)點對齊到同一個時間點。這個字段對同步效果影響很大前面提到的50ms誤差很大程度要靠它來保證。4. 同步閃爍的時延控制最容易被忽視的高頻痛點4.1 追光效果為什么對時延那么敏感誘導燈最直觀的效果是“追光”一排燈按順序從一端亮到另一端形成一種流動的引導感。這種效果看著簡單對同步的要求卻非?？量獭Ｈ搜蹖Φ皖l閃爍很敏感尤其是兩盞相鄰的燈如果切換時間差超過幾十毫秒人眼就能明顯感覺到“波紋”“跳動”或“斷層”。如果一組燈亮起的時間和另一組差了半拍司機看到的不再是流暢的引導光流而是一段混亂的“亂閃”在霧天和夜間不僅起不到誘導作用還可能干擾駕駛判斷。工程上我一般把同步誤差控制目標定在30毫秒以內最多不超過50毫秒。這意味著所有節(jié)點必須在同一個時間窗口內完成狀態(tài)切換而不是“收到命令就切換”。這正是無線方案最容易翻車的地方。很多做過局域網(wǎng)燈光控制的人會用思維慣性來考慮覺得“廣播一發(fā)大家同時收到自然就同步了”。但實際上LoRa的廣播不是瞬間同時到達的節(jié)點因為距離不同、環(huán)境不同接收時刻會有幾十到幾百毫秒的差異。如果收到就執(zhí)行追光效果就是歪歪扭扭的。4.2 廣播時間戳和離線定時兩個可用方案要解決“收到就執(zhí)行”的偏差最直接的辦法是“收到不代表執(zhí)行”。網(wǎng)關在下發(fā)廣播幀時帶一個目標執(zhí)行時間戳所有節(jié)點收到后先不動作等本地時間走到這個時間戳再執(zhí)行。這樣節(jié)點之間的接收差異就被抹平了執(zhí)行時刻由時間戳統(tǒng)一決定。這個方案里節(jié)點本地時鐘的精度非常關鍵。普通晶振一天漂移幾十到幾百ppm換算下來一天能差出幾秒所以需要定期對時。對時也是用廣播幀網(wǎng)關每天固定時間發(fā)一次時間基準幀節(jié)點收到后校正本地RTC。實測在每天對時一次的情況下節(jié)點間時間偏差可以控制在幾毫秒以內完全夠用。另一種方案是離線定時就是施工時把未來一段時間內的閃爍模式寫進節(jié)點存儲比如“每天晚上18點到次日6點按某個配置運行”節(jié)點不需要實時在線也能執(zhí)行。這種方案的優(yōu)點是通信依賴少、穩(wěn)定缺點是靈活性差。臨時交通管制、突發(fā)惡劣天氣、半夜想換個閃爍頻率都得重新下發(fā)配置對通信鏈路的實時性要求反而更高了。實際項目里我傾向于兩者結合離線定時做兜底保證斷網(wǎng)時燈光系統(tǒng)還能按預置方式運行在線廣播時間戳負責實時調整。兩種模式并行現(xiàn)場就不會因為通信故障變成“瞎燈”。4.3 丟包重傳與冗余廣播的取舍LoRa用的是ALOHA類的隨機接入機制多個節(jié)點同時上報時沖突是不可避免的。對廣播控制指令來說重傳策略不能簡單套用“發(fā)一次沒收到再發(fā)一次”因為廣播沒有ACK究竟誰沒收到你根本不知道。我的做法是“三次冗余廣播加統(tǒng)一時間戳”。假設當前是T0我要所有節(jié)點在T5秒時執(zhí)行某個追光動作那么我在T0發(fā)第一幀廣播T03秒發(fā)第二幀T06秒發(fā)第三幀。每幀里都帶同一個目標時間T5秒只不過第一幀的“從當前算起”字段是5秒第二幀是2秒第三幀是負的已經過期但節(jié)點只要收到一次就能判斷目標時刻還沒到就繼續(xù)等如果目標時刻已過就立即執(zhí)行。這樣做的核心邏輯是節(jié)點只要在多次廣播中收到任意一幀就能拿到統(tǒng)一的目標時間而多次廣播的時間錯開了短時信道沖突不會導致所有幀都丟。代價是總時延增加了所以在“實時性要求高”和“可靠到達”之間需要做一個折中。我的經驗是追光切換間隔通常幾百毫秒到一秒冗余廣播間隔控制在幾秒內不會影響效果但丟包率能下降一個數(shù)量級。單播狀態(tài)查詢的重傳就簡單多了用指數(shù)退避。第一次發(fā)了沒收到ACK等1秒再發(fā)然后2秒、4秒最多三次。不要無腦快速重發(fā)否則幾十個故障節(jié)點同時重發(fā)就會把信道擠爆。5. 功耗與供電太陽能和鋰電池的真實續(xù)航賬本5.1 待機功耗無線模塊睡著和醒著的差別誘導燈大多沒有市電供電靠太陽能板加蓄電池。在這種系統(tǒng)里無線通信模塊的功耗地位很微妙它不像LED那樣一工作就是幾十毫安但架不住它需要“長期在線”監(jiān)聽信道。以SX1268系列LoRa芯片為例發(fā)射電流看功率20dBm發(fā)射時大概100毫安以上接收模式大約4到5毫安睡眠模式只有微安級。MCU也一樣STM32L0這類低功耗單片機運行模式幾毫安待機模式幾微安。差距非常大。最大的坑是“長期開啟接收窗口”。有些團隊為了隨時響應平臺指令讓模塊一直在RX模式里監(jiān)聽看似穩(wěn)妥實際上平均電流一直在4到5毫安徘徊太陽能板小一點的燈桿冬天根本充不回來。更合理的方式是“休眠加按需喚醒”。節(jié)點平時深度睡眠只在預設的時間窗口醒來比如每30秒醒一次收廣播或者只在夜間工作時段持續(xù)接收白天除了上報狀態(tài)其余時間睡覺。LoRa芯片的CAD模式也可以用來做低功耗監(jiān)聽芯片醒來后會掃描信道里有沒有前導碼沒有就迅速睡回去平均電流可以壓到微安到毫安之間。5.2 一節(jié)18650能用多久算給你看拿一個典型的太陽能誘導燈來算筆賬。假設LED平均工作電流10毫安閃爍工作不是常亮每天夜間工作4小時那么LED日均耗電40毫安時。通信模塊如果只在工作時段開啟接收平均電流按1毫安估算24小時就是24毫安時如果做得粗糙全天掛網(wǎng)接收平均4毫安就是96毫安時這個差距直接決定太陽能板和電池能不能扛過陰雨天。再算靜態(tài)損耗。MCU待機、電源管理芯片靜態(tài)電流、電容漏電加一起按10微安算一天就是0.24毫安時可以忽略不計。一節(jié)18650電池容量按3000毫安時算如果只靠電池不靠太陽能LED加通信加靜態(tài)損耗一天大約消耗65毫安時理論續(xù)航是46天左右。聽起來還行但在山區(qū)高速連續(xù)陰雨半個多月是常事46天的余量會被直接吃掉一大半再加上冬天日照短、太陽能板效率下降純電池方案是撐不住全年的。所以工程上普遍是“太陽能板加小電池”的組合。太陽能板不需要太大5瓦左右一天有效日照3小時大概能充進2500到3000毫安時的電量基本覆蓋當天的消耗還有富余。電池作為“陰天緩沖”來用容量選10到20安時比較穩(wěn)妥。5.3 太陽能充電與過壓保護的實際做法太陽能充電的電壓管理很多小團隊當作“一個二極管防倒灌就完事”這是不夠的。磷酸鐵鋰或者三元鋰電池都需要充電管理。太陽能板開路電壓往往在6伏甚至更高直接懟到電池上輕則過壓保護頻繁啟動重則電池鼓包。我建議至少用帶PWM功能的充電管理芯片先把太陽能板電壓穩(wěn)下來再按恒流恒壓方式給電池充電。條件允許的話用MPPT控制器冬天收益能多個百分之二三十。過壓保護不只是電子層面的。太陽能板在強光下電壓會飄后級如果突然斷載電壓可能瞬間沖高把通信模塊的電源部分打壞。所以DC-DC降壓的前端要加TVS管或者選用耐壓足夠、帶過壓保護的電源芯片。還有冬天問題。鋰電池在低溫下放電能力明顯下降北方夜間零下十幾度容量直接打六折。選電池時要把工作溫度范圍看仔細必要時給電池做簡易保溫或者選用耐低溫的鋰亞電池方案。不過鋰亞電池雖然低溫性能好充電能力差不太適合“白天充晚上放”的循環(huán)場景這點要提前想清楚。6. 現(xiàn)場部署容易踩的坑天線、防雷、干擾排查6.1 天線安裝高度與極化方向距離差兩倍的根源LoRa模塊本身的靈敏度再高天線裝不好一切都白搭?，F(xiàn)場見過最多的問題是天線貼著燈桿表面安裝或者橫著綁在護欄上通訊距離直接從預期兩公里掉到六七百米。原因有兩個。一是高度不夠二是極化方向不對。天線高度直接影響第一菲涅爾區(qū)是否開闊。高度太低路面和欄體的反射會跟直射波疊加抵消信號質量急劇下降。我一般是盡量把天線裝到燈桿頂部或殼體外部讓天線輻射體高于周圍金屬結構至少半米。如果實在加高不了至少保證天線輻射體不緊貼金屬面用支架讓它離開金屬桿一段距離。極化方向方面常見的吸盤天線默認是垂直極化安裝時就要讓天線軸線保持豎直兩個通信端的天線極化方向要一致。一端的垂直天線另一端橫躺著裝了極化失配帶來的損耗能到20dB以上比擴頻因子的差異還大。SMA接頭做防水也很關鍵很多“雨天丟包率上升”的問題其實就是接頭進水氧化。用防水膠泥把接頭纏好再套熱縮管別只靠那個塑料防水帽。6.2 干擾源排查從頻譜儀看到的現(xiàn)象說起LoRa雖然抗干擾但不是說任何干擾下都穩(wěn)如泰山。高速公路現(xiàn)場有一些容易被忽略的干擾源。我在一個服務區(qū)附近的項目里排查過掉線問題探頭裝上天線頻譜儀在470MHz附近掃了一天發(fā)現(xiàn)夜間11點后突然出來一個高底噪剛好覆蓋了整個工作頻段。后來查了半天是附近工程車輛上一款無線倒車雷達設備白天不啟動夜里工人收工后反而不間斷工作。這種設備功率不大但距離近對LoRa網(wǎng)關的接收會造成明顯的底噪抬升。排查方法不難用頻譜儀加便攜天線在網(wǎng)關位置和區(qū)段中點分別測底噪重點盯工作頻段有沒有突發(fā)強信號。測的時候注意避開自己的設備發(fā)射時間否則看到的是自己的信號。應對干擾的手段也有幾層。首先是選頻點470到510MHz之間不是所有頻點都等價的掃頻后選一個底噪最低的頻點其次是用跳頻把工作頻率在幾個備選頻點之間定時切換但要保證網(wǎng)關和節(jié)點同步協(xié)議復雜度會增加第三是利用LoRa本身的抗干擾能力提高擴頻因子換靈敏度。干擾嚴重時優(yōu)先級最高的還是從物理位置上下手比如把網(wǎng)關天線移開干擾源方向用屏蔽線纜走信號。6.3 雷擊與接地戶外設備的兩道生死線高速公路的燈桿是典型的引雷結構周圍空曠又比較高雷雨季節(jié)很容易被感應雷和直擊雷光顧。無線通信模塊對感應雷尤其敏感天線口和電源口都可能被浪涌打穿。我的做法是三層防護。電源上在電池輸出到通信模塊的鏈路里加裝合適的電源防雷器SPD選響應時間納秒級的那種別為了省幾塊錢裝一個幾十毫秒的開關型防雷器那根本沒反應時間。天線上在天線饋線進入控制箱的位置加裝天線防雷器同時做饋線接地。箱體本身必須可靠接地接地電阻控制在10歐姆以內不能只是接在燈桿上就算完燈桿如果沒做真正的接地系統(tǒng)雷電照樣能從桿體傳導進箱體。還有一件事經常被忽視天線裝在最高點時要確保它在避雷針的保護范圍之內。如果一支避雷針都立不好天線反倒成了引雷點雷雨季節(jié)等著挨打。工程上最簡單的原則是避雷針高于天線并以一定角度形成保護錐天線處于錐形區(qū)域內才安全。防雷這部分的投入看起來不產生直接收益但雷雨季節(jié)一次雷擊燒一片網(wǎng)關維修成本遠超前期防雷投入。做工程的人應該都有體會。7. 選型決策的一張表與幾條經驗7.1 按項目規(guī)模和供電條件快速選型不同項目條件下的最優(yōu)組合不一樣我習慣用下面這張表快速判斷項目場景推薦方案關鍵理由短隧道口、幾十盞燈Sub-1G私有FSK或LoRa點對點范圍小組網(wǎng)簡單成本優(yōu)先主線長距離、幾百盞燈LoRa星型加分段網(wǎng)關覆蓋遠同步可控故障隔離好有市電的隧道和橋梁段可放松功耗約束LoRa或ZigBee均可供電不是瓶頸看成本選型純太陽能、偏遠山區(qū)LoRa低功耗模式加休眠調度功耗和距離必須同時滿足已有平臺需要集中管理網(wǎng)關用4G或光纖上云末端LoRa上傳通道和本地控制分離這套組合不是絕對的但方向是對的。每次選型我都會先問三個問題現(xiàn)場有沒有穩(wěn)定供電區(qū)段長度和節(jié)點數(shù)量是多少同步控制的實時性要求有多高答案不同方案差很遠。7.2 我踩過的坑和個人建議最后聊幾個具體項目里踩過的坑希望能幫后來人省點時間。第一個坑是藍牙Mesh在隧道口的應用。當時節(jié)點數(shù)量不多覺得Mesh很靈活結果隧道口車型復雜車輛進出時遮擋嚴重鏈路在高峰期頻繁重建燈光偶爾出現(xiàn)一兩盞滯后。后來換成LoRa星型才徹底解決。Mesh方案再方便也架不住對時延和穩(wěn)定性的極限要求。第二個坑是全系統(tǒng)用SF12。那是個偏遠山區(qū)項目技術負責人為了讓“信號最好”強制全部用SF12結果控制一條追光指令的空中時間到了一秒以上幾組燈輪流執(zhí)行后追光效果變成了妖艷的四處亂跳。改成SF7之后距離稍微縮了一點但同步效果一下子就好了。第三個坑是天線貼殼安裝。有一批燈出廠時天線直接貼在鋁鎂合金殼體內部殼體形成屏蔽罩出廠測試時距離只有兩三百米。后來把天線引出殼外距離直接翻了幾倍。這一項改動幾乎不增加成本效果卻是質變。如果你現(xiàn)在正要啟動高速誘導燈無線通信方案的選型我的建議是別急著下單買設備先花一周時間做需求拆解和現(xiàn)場勘測弄清楚供電條件、區(qū)段長度、節(jié)點密度、同步要求這四個變量再反過來決定頻段、拓撲和參數(shù)。無線通信方案的成敗往往在選型之前就決定了。