[TOC]
## 大部分通訊軟體間的溝通
目前大部分通訊軟體間的溝通多數是建構於 HTTP(S) 或 WebSocket 等基於 TCP 的通訊協定來進行 API(Application Programming Interface) 呼叫，意味著在送出請求前必須先得知伺服器或請求對象 IP 位址才可順利傳遞封包

**Star topology**
[Ref.](https://en.wikipedia.org/wiki/Star_network)

各電腦間的通訊必須經由中央裝置(可能是大型主機、集線器、交換器)聯繫，一般是使用雙絞線作為傳輸媒體。

所有的網路節點將資料送給 Hub，並由 Hub 轉送至目的節點，不會有碰撞 (Collision) 和餓死 (starvation) 的問題，易於管理、維護及架設，缺點是中央裝置故障時整個網路就會癱瘓，但若某部電腦故障則不會影響其他電腦運作。

**Network Infrastructure layout**
[Ref.](https://www.electroniclinic.com/network-topologies-start-ring-mesh-bus-tree-hybrid-ad-hoc-and-wireless-topology/#Network_topologies)

此拓撲結構使用 **有線 + 無線** 的組合。這與星型拓樸非常相似。電腦可以透過網路線連接到 Switch，也可以透過 **無線 Access Point(AP)** ，該 AP 最終也會透過網路線連接到 Switch。
AP 的出現方便筆電、平板、手機等無線裝置可以無線連接到網路。因此，AP 可以說是無線和有線網路之間的橋樑。

缺點與星型拓樸一樣，中央裝置故障時整個網路就會癱瘓，但若某部電腦故障則不會影響其他電腦運作。

然後就有這機八人
意思就是，如果海底電纜切斷，兇手就是...

---

# 戰時網路
## 情境
1. 海底電纜被切斷了，對外溝通受阻
2. 國內電信機房線路故障或損毀，導致城市間網路無法連線
3. 大規模停電後 → 基地台備援用電用完 → 人們傳遞訊息的方式剩下無線電 → 屆時的無線電頻道應該跟上班時的日本地鐵一樣擠

## 低軌道通訊衛星
- 台灣面積約 36,000 平方公里
- 一顆 550 公里高的 LEO 衛星，其即時可見地面投影半徑大約是 1200 公里（理論最大值），但考量通訊效能，實際有效覆蓋半徑約 500～600 公里。

假設每顆衛星有效覆蓋半徑 600 公里，從台灣中心出發覆蓋的圓形面積為：
$$
A=πr^2≈3.14×(600)^2≈1,130,400\ km^2
$$
這已遠遠大於台灣的面積（約 36,000 km²），因此：
> 只需 1 顆衛星，即可瞬間覆蓋整個台灣地區，前提是它正好在台灣上空。

若要 24 小時連續覆蓋台灣地區，大約需要部署 30～50 顆 LEO 衛星，放在不同的軌道面。

---

### 深入比較下
頻寬 / 傳輸量
- LEO 衛星：單一衛星的頻寬有限，約數百 **Mbps～Gbps** 級別。
- 海底電纜：一條主幹級光纖電纜（如 SEA-ME-WE 6）總容量可達 **數百 Tbps**，遠超衛星，適合大流量資料交換。

延遲（Latency）
- LEO 衛星延遲低於傳統 GEO（地球同步）衛星，但仍需經過上行→中繼→下行，約為 **20～50ms**。
- 海底電纜傳輸速度雖略低於真空中的光速，但光纖直連且裝置少，跨洲連線延遲可低至 **60–150ms**。

穩定性與安全性
- LEO 衛星系統易受太陽風、太空碎片、干擾器影響，但不易完全癱瘓，且不依賴特定地理結構。

> 文章被刪掉了，點進去會被轉到首頁

### 實際案例分析
烏克蘭戰爭中的 Starlink
- Elon Musk 提供烏克蘭使用 Starlink 支援軍通，但 **曾限制其用於攻擊行動（如無人機控制）**。
- 據報導，部分區域的民用使用者因**戰區需求**而出現**連線不穩或被限制使用**。
- 即便有裝置，衛星服務商也可透過 地面網關系統進行使用者控管（例如白名單技術）

---

## g0v 提出的解方
1. 島內 Mesh 網路
2. 事先建立無線的 community-based mesh network
Meshtastic
3. 假設目前有五個使用者，分別是 $A B C D E$
今天即便 $A$ 因爲距離限制，沒辦法傳給 $E$
也可以透過轉發的方式，$A → B → C → D →$ 最後把訊息送到 $E$
4. Meshtastic 裝置：以臺灣目前可以快速買到的 Heltec ESP32 來說，一支只要 $760，如果是自己跟自己測試的話需要買兩支 $1,520、支援藍牙的 Android or iOS 手機、一顆行動電源並以 USB Type C 的方式供電給 Meshtastic 裝置

[台灣鏈網](https://g0v.hackmd.io/ugNkTFLARwK4rmH7jCdO-g) Meshtastic 社團版主 @dryden

## 我們的想法
- 運用裝置對裝置 (D2D) 通訊技術，讓裝置之間直接點對點鏈接，獨立於固定網路基礎設施運作。
- 它要既可以彌補現有的網路基礎設施的不足，也可以用作獨立網路來提供服務。

:::info
g0v 是誰
g0v 零時政府是臺灣程式設計師在 2012 年底組成的網路社群，致力於推動政府資訊透明化，開發公民參與社會的資訊平台與工具，**公共政策網路參與平臺** 就是他們促成的專案之一。

防範未然，事先盤點各種斷網情況下的數位備援方案，提升公民社群的數位韌性！
:::

---

# [Meshtastic](https://github.com/meshtastic)
Meshtastic 是一個基於 LoRa 技術的開源專案，具有低功耗、低成本的特性，同時具有 AES 加密，以此建立長距離可靠的無線網狀網路。


:::info
Features
- Long range (**331km** record by MartinR7 & alleg)
- No phone required for mesh communication
- Decentralized communication - **no dedicated router required**
- **Encrypted** communication
- Excellent battery life
- Send and receive text messages between members of the mesh
- Optional **GPS based** location features
- And more!
:::

---

## 背景知識
### MESH 是什麼
MESH 網路（網狀網路）是一種特殊的無線網路結構，其中每個節點都直接與多個其他節點連接，形成一個網路。

在 Meshtastic 系統中，這種結構使得每個裝置**既是通訊終端也是中繼站**，能夠接收並轉發其他裝置的訊息。這樣的設定允許訊息能夠跨越更廣泛的範圍，並透過連鎖反應達到最遠的接收者

> A -> B -> C -> D -> E

[Ref.](https://hackmd.io/@fL8pq60EQsG3RplVzWfGWA/S1m_x-AOA/%2FsyeEwZQOTZyeVa2R1eXrMg)

**Partially connected mesh network**

**Fully connected mesh network**

網狀拓撲的優點是它能提供較高的 redundancy。因為如果一個或多個連接失敗，電腦仍然能夠相互通訊。
網路就是網狀拓撲的一個很好的例子，因為整個網路是由世界各地的路由器組成，這些路由器相互連接以將資料路由到預定的目的地。因此，即使幾個路由器發生故障，資料也會通過不同的路徑最終到達目的地。
#### B.A.T.M.A.N. 協定介紹
##### B.A.T.M.A.N.的由來與設計理念
B.A.T.M.A.N.（Better Approach to Mobile Ad-hoc Networking）是來自德國的一個叫做 Freifunk 的社群於 2006 年 12 月開發的一種用於多跳行動隨意網路的路由協定，目的是要取代 OLSR(ptimized Link State Routing Protocol)，弭補傳統協定的缺點。
[Ref.](https://en.wikipedia.org/wiki/B.A.T.M.A.N.?utm_source=chatgpt.com)
:::info
討論 B.A.T.M.A.N 之前必須了解 OLSR，畢竟 B.A.T.M.A.N 誕生的目的在於改善並取代原本的 OLSR 路由協定
:::
###### Optimized Link State Routing Protocol（OLSR）
OLSR 是一種專為 MANET（Mobile Ad-hoc Networks）所設計的主動式路由協定，是對傳統連結狀態協定的最佳化版本。

核心概念：
1. 主動式路由協定
每個節點會定期與所有節點以 Routing Update Packets 交換路由資訊，並在網路拓撲變化時立即更新，所以節點的路由表中隨時都有最新的路由資訊。
- Neighbor set（鄰居節點集合）：記錄所有雙連結的直接鄰居節點。
- MPR selector set（MPR 選擇者集合）：紀錄選我當 MPR 的鄰居節點。
- Two-hop neighbor set（兩跳鄰居節點集合）：通過直接鄰居節點。
- Topology Set（拓撲集合）：經 Topology Control（TC） 封包散佈的遠端連接資訊。
2. 鄰居節點偵測
- Hellow 封包：與鄰居節點傳遞更新鄰居節點集合。下圖為工作原理
　

- Sym：對稱點
- Asym：非對稱點

3. MPR（Multipoint Relay）的選擇
- MPR（Multipoint Relay）：指定的最佳鄰居節點，減少 Routing Update Packets 的傳播數量。

根據鄰居節點集合可以選擇 MPR 作為後續傳遞 Routing Update Packets 的 MPR ，達到控制洪泛的目的。

1. 先標記出所有的兩跳節點，選則能夠覆蓋只能透過單一一跳鄰居可達的兩跳鄰居節點的鄰居節點。

2. 先找到連接孤立按照連接的節點數由高至低選擇，直到覆蓋所有兩跳節點，後更新節點的 MPR 選擇者集合。


4. 拓樸管理
- MPR 會定期發送 topology control（TC）封包更新所有節點的路由資訊，包含選擇這個節點作為 MPR 的節點。
- 更新節點的拓樸表

##### 主要協定介紹
###### B.A.T.M.A.N.（Better Approach To Mobile Ad-hoc Networking）
- 是一種設計用於 MANET。
- 作用於 OSI 模型的第三層。
- 它的運作不需要節點隨時掌握網路的狀態或拓撲資訊。
1. 工作原理：
- 分散式路由決策
- 每個節點僅需記住「通往所有其他節點的最佳下一跳」，不需全網拓撲知識，降低計算與同步負擔。
- 事件驅動
- 不依賴排程或逾時機制。
- 減少拓撲泛洪次數，控制流量開銷。
2. 協定是如何運作
- 來源節點會建立一個 OGM (Originator Messages，來源節點訊息)。
- 定期廣播來源節點訊息（OGM）到直接的鄰居節點。
- 更新節點的滑動視窗
- 整個網路將會被 OGM 所淹沒（flood）。

**第四代 OGM 介紹**

- **Version（版本）**
由協議定義的數值；如果封包的版本號與預期的不同，該封包將會被忽略。
- **Is-direct-link Flag（Flags，直接鏈接標誌）**
表示該鄰居節點是否是原始發送者的直接鄰居。
- **Time to Live（TTL，生存時間）**
OGM 封包在被丟棄之前可經過的最大跳數。
- **Gateway Flags（GWFlags，閘道標誌）**
如果節點不是網際網路閘道，則設置為 0；否則，這個欄位包含連接頻寬（上行/下行）。
- **Gateway Port（GWPort，閘道通訊埠）**
如果節點不是網際網路閘道，則設置為 0；否則，這個欄位指定用於通道的通訊埠。
- **Sequence Number（序列號）**
用來唯一標識在某一時間範圍內的 OGM 封包。
- **Originator Address（原始發送者地址）**
生成 OGM 的 B.A.T.M.A.N 介面所使用的 IPv4 位址。
- **Transmission Quality（TQ，傳輸品質）**
- 接收品質（Receive Quality, RQ）= 某鄰居轉發的 OGM 實際接收數量 / 預期應收到的數量（在特定時間內）
- 表示鄰居發送封包的成功率
- 舉例：
每個節點每秒發送 1 次 OGM，在 10 秒內節點 B 應該會也會發 10 個 OGM 給 A 我實際從 B 收到 7 個 OGM
RQ = 7 / 10 = 0.7（或 70%）

- 回音品質（ Echo Quality , EQ） = 從某鄰居回傳回來我自己發出的 OGM 數量 / 我自己實際廣播的 OGM 總數
- 表示本節點發出的封包經由該鄰居返回的成功率
- 舉例：
來源節點 A 每秒發送 1 次 OGM，在 10 秒內，A 傳出去自己 OGM 的總數為 10 其中，來自鄰居 B 的回傳有 5 次
EQ(B) = 5 / 10 = 0.5（或 50%）

- TQ = EQ / RQ
反映了鄰居連結的封包傳送成功率
- EQ 高、RQ 高 → 雙向穩定，TQ 高
- EQ 低、RQ 高 → 我能收、對方收不到，TQ 低
- EQ 高、RQ 低 → 我送得到、卻常收不到對方，則 TQ 因 asym 懲罰而降，TQ 低
asym = （100% − (100% − RQ)³）
是根據接收品質（RQ）計算出來的調整因子，這個因子會降低 TQ 值，補償因為接收品質較差所導致的非對稱連線影響。
- loss = 1 - RQ
- loss 取立方放大損失，懲罰加重
- 轉換為百分比並取反
- EQ 低、RQ 低 → 雙向不穩定，TQ 低
- OGM也被更新以攜帶 1 位元組長度的 TQ 值，TQ 值會設置為最大值，並且隨著每次跳躍，這個值會進行調整。
1. 節點的本地傳輸品質：TQ = TQ_incoming(異地連接品質) × TQ_local(本地連接品質)
2. 由於非對稱連線所帶來的懲罰：避免選擇那些雖然「收到封包很穩定（RQ高）」，但「發出去卻容易失敗」的非對稱連接作為路由；如果某個節點知道向某個鄰居傳送封包的接收品質較低，它會在將 OGM 發送給該節點之前調整其 TQ 值
3. 新增全域滑動視窗
- 會包含每個不同鄰居通往該特定來源節點的平均 TQ 值。
- **Previous Sender（先前發送者）**
重新廣播 OGM 的節點的 IP 位址
- **HNA length（HNA 長度欄位）**
告訴接收端這個 OGM 後面接了多少個 HNA (Host Network Announcement) 子訊息。

**鄰居排序機制（Neighbour Ranking System）**
- 每個節點都會維護一份已知來源節點（Originators）的清單並記錄OGMs中的重要資訊，
- 建立一個稱為滑動視窗（sliding window）的框架，且區分為全域與本地兩個類型。
- 滑動視窗儲存收到的 OGM 資訊，並記錄每封 OGM 是經由哪一個鄰居節點來的。
- 系統會不斷重新評估「最佳鄰居」並選出最佳下一跳。

5. 第五代
- 這一代的重點轉向封包的吞吐量，因為前幾代在處理擁有少量或無封包損失但吞吐量差異較大的網路時並不理想。所以將OGMs拆分為兩種類型的封包：ELP（Echo Location Protocol）和 OGMv2（Originator Message version 2）。
1. ELP
與 OGMs 類似，擁有版本號、序列號和來源節點的地址。
用來更新鄰居節點和鄰居列表(已知來源節點的清單)
僅用來保持接收節點的鄰居列表更新
- Num Neigh：此鄰居已透過傳送此封包的介面發現的鄰居數量。
- Interval：設定為此介面的目前 ELP 間隔（以毫秒為單位）。
2. OGMv2
代替了 TQ 值，新增了一個吞吐量測量。
檢查其序列號是否在「保護視窗」範圍內。
記錄最新序號：這是用來辨識封包新舊與防止重播。
記錄時間戳：更新「上次見到該來源」的時間，有助於判斷來源是否仍然活躍。
跳躍懲罰：
因為一條多跳路徑的效能會受到最弱那一跳影響
new_throughput = min（local_throughput, ogmv2_throughput × 0.942）的跳躍懲罰
- TVLV length：加到 OGM 的 TLVL 資料的長度
- TVLV data：加發起者的 TVLV 資料。
- Throughtput：目前連線的吞吐量。

[ref](https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2024-09-1/NET-2024-09-1_02.pdf)

---

### LoRa 是什麼

**LoRa**（來自 "Long Range"，a long-range radio protocol）是一種 **長距離無線電協定**。它基於展頻調變技術，源自 **線性調頻擴展頻譜（CSS，Chirp Spread Spectrum）** 技術。

:::info
#### 線性調頻展頻（CSS/chirp spread spectrum）是什麼？
波形上一個由低頻到高頻的波形，在頻率變化上就是一個”線性”的頻率變化

當然音調也可以由高到低

LORAWAN 實際調變後的訊號

{%youtube nfH6tO0VnJc%}

:::

:::success
#### 一般的手機、電腦也能作為 LoRa 節點嗎？
簡單來說—— **不行**
LoRa 使用的是一種低功耗、遠距離、但低資料率的無線通訊技術，需要依賴專門的晶片組來處理
- **手機與筆電** 的無線模組（如 Wi-Fi、藍牙、4G/5G）**不支援 LoRa 頻率與 modulation 技術。**
- 除非使用額外硬體（例如 USB LoRa Dongle 或透過開發板橋接），否則無法與 LoRa 節點溝通。

LoRa 本質上是一種將 Physical 與 Data link Layer 結合而生的獨立技術
- 使用 Sub-GHz 頻率（如 433/868/923 MHz）進行無線資料傳輸
- 與 Wi-Fi、Ethernet 不同，獨立於 TCP/IP 網路協定堆疊運作的無線通訊技術，無需 Wi-Fi、4G、光纖等傳統網路基礎設施的情況，依然能在遠距離進行資料交換與訊息傳遞。
:::

**LoRaWAN**（Long Range Wide Area Network，長距離廣域網）則 **定義了通訊協議和系統架構**。

> [Ref](https://delorescetleh.medium.com/lora-vs-lorawan-2-635db22c7786)

換句話說，LoRa 是基礎，而 LoRaWAN 則是基於這個基礎建構的完整網路應用方案。

LoRa 和 LoRaWAN **共同定義了一種低功耗廣域網（LPWA）協議**，將 **電池供電的裝置** 透過大小型網路連接至 **網際網路**，並針對 **物聯網（IoT）** 的關鍵需求進行設計，例如 **雙向通訊、端到端安全性、移動性和定位服務**。

與傳統的 WAN 相比，LoRaWAN 具有 **低功耗、低傳輸速率** 的特點，專門用於 **物聯網應用**。它的數據傳輸速率範圍為 **0.3 kbit/s ~ 50 kbit/s**。

> [Wiki](https://en.wikipedia.org/wiki/LoRa)

Meshtastic 則是一個利用 LoRa 技術實現長距離、低功耗的數據傳輸的通訊系統。


---

### 電磁波是什麼
電磁波是一種能量的傳遞形式，可以在空間中傳播而不需要介質。

前面提到 Meshtastic 使用到 LoRa 技術，而 LoRa 就是利用電磁波在晶片組之間互相溝通。

在台灣，LoRa（Long Range）的合法使用頻率是 920 MHz 至 925 MHz。這個頻率範圍內的使用是由國家通訊傳播委員會（NCC）規定和監管的，以保不同的無線裝置之間不會相互干擾，同時也確保無線通訊的效率和安全性。

---

### 天線是什麼

天線可以轉換電訊號為電磁波，這使得訊號能夠透過空氣或其他介質傳播。
同樣地，天線也可以接收來自遠處的電磁波，並將其轉換為電訊號供裝置進一步處理。

- 全向天線適用於廣播訊號到多個方向
- 定向天線則適用於將訊號聚焦到特定方向，但要精確對準目標方向，否則會導致訊號遺失或衰減。

> [Ref.](https://www.fbnews.jp/202205/workbench/)

另外天線可以為訊號傳播帶來增益，若想將訊號傳至遠處的接收器，最佳選擇絕對是高增益天線。由於訊號必須通過很長距離，所以必須加強訊號，並且直接指向目標。

:::danger
#### 切記：先天線，後開機
雖然我們為 Meshtastic 使用的 LoRa 模組是相對低功率的通訊晶片，但要注意 **絕對不要** 在 **沒有天線或天線未正確安裝** 的情況下操作任何無線電傳輸裝置。不使用天線發射的電磁坡會反射回來並在晶片內部不斷反射加熱，導致裝置損壞。

請務必注意，供電前一定要先連接天線，否則可能會損壞設備。
:::

> 如何提高傳輸距離？可參考
> [提高傳輸距離](https://hackmd.io/@fL8pq60EQsG3RplVzWfGWA/S1m_x-AOA/%2FzUS_8nCHSbWBBi0NTLZ3-g) by Bashcat

---

### IIC $I^2C$ 是什麼
像 Meshtastic 這類使用 LoRa 的裝置，它的 IC 之間常會使用 $I^2C$（也叫 IIC） 來進行通訊，這在微控制器（像 ESP32）跟一些外部元件（像感測器、螢幕、GPS 模組）之間非常常見，用來讓多個 IC 在同一條匯流排上互相溝通。。

$I^2C$ 特性就是只需要兩條線：**SDA（資料線）** 和 **SCL（時鐘線）**，舉例 Meshtastic 來說：
- ESP32 是主控晶片
- GPS 模組 用 $I^2C$ 傳送定位資料
- OLED 螢幕 用 $I^2C$ 傳送要顯示的訊息
- 環境感測器（如溫溼度、氣壓） 也可能透過 $I^2C$ 傳輸數據

這樣所有元件可以**共用同一對 SDA/SCL 腳位**，省腳位又省線，這就是 $I^2C$ 超方便的地方。

:::info
有興趣可以搜尋關鍵字 **硬體通訊協定、UART、$I^2C$、SPI、1-Wire**
:::

---

### MQTT 是什麼
> 「誰要什麼訊息，就訂閱那個主題（topic）」

MQTT 是 Meshtastic 的內建功能，透過乙太網路或 WiFi 將節點連接到本地網路。

MQTT（Message Queuing Telemetry Transport）是一種輕量級的訊息傳遞協議，專為小型裝置和有限頻寬、不穩定的網路環境設計。這種協議是基於 **「發布/訂閱（publish/subscribe）模式的通訊協定」**，使得多個裝置可以通過共享主題彼此交換訊息。

1. Broker（訊息伺服器）：
負責管理所有連線、主題和訊息轉發。
常用的 Broker 有：Mosquitto、HiveMQ、EMQX
2. Publisher（發布者）：
發布訊息到某個主題（topic），比如 `meshtastic/gateway/data`
3. Subscriber（訂閱者）：
訂閱某個主題，收到該主題上的所有訊息

Meshtastic 網路可以透過 MQTT 進行橋接，連接不同地理位置的節點。
- 每次收到 LoRa 資料，它就會上傳到 MQTT Broker
- 用手機、Web 前端或伺服器程式去訂閱該 Topic
- 即可實現 LoRa ↔ MQTT ↔ Cloud 的橋接功能

可以使用公用 MQTT 伺服器 OR 自己架設一個 MQTT 伺服器：
1. 公共 MQTT 伺服器：
- 由 Meshtastic 的官方 MQTT 伺服器提供
- 這使得我們的裝置可以在世界地圖上顯示，並將我們的 mesh 流量以 JSON 格式複製。
https://meshmap.net/
- 使用公共 MQTT 伺服器時，預設使用加密。
- 注意：預設頻道（LongFast）流量很大，裝置有機會過載無法正常工作。建議使用不同的頻道或使用自己架設的私人 MQTT 伺服器。

2. 私有 MQTT 伺服器：
- 可以指定自己的私人 MQTT 伺服器來橋接網路，通過物聯網或局域 IP 網路實現。
- 自建伺服器可以使用 Mosquitto 等開源軟體，在 Raspberry Pi 或其他低功耗裝置上運行。
- 自訂隱私保護政策及對伺服器完全控制權。

---

### 評量網路常用的幾個依據
{%youtube hYFk1alRnvQ%}
#### Transmission Range

flowchart LR
    Node_A ---> Node_B
    Node_B ---> Node_A

- 發射器發送的訊號可以被接收器讀取而不會造成重大干擾
- 無線網路還需要雙向皆通

#### Range Extension

flowchart LR
    style Router_1 fill:#e9b41b, stroke:#4f3d09, stroke-width:3px, stroke-dasharray:5 4
    style Router_2 fill:#e9b41b, stroke:#4f3d09, stroke-width:3px, stroke-dasharray:5 4
    Router_1((Router_1))
    Router_2((Router_2))
    Node_A <-..-> Router_1
    Router_1 <---> Router_2
    Router_2 <-..-> Node_B

With relay nodes, repeater or router

#### Influences

flowchart LR
    House's_Roof[/House's_Roof\]
    Tree[(Tree)]
    Transmitter ---> Wall
    Transmitter ---> House's_Roof
    Transmitter ---> House's_Body
    Transmitter ---> Tree
    Wall --->|Reflection| Reciever
    House's_Roof --->|Diffraction| Reciever
    House's_Body -..->|Penetration| Reciever
    Tree --->|Scattering| Reciever

1. Reflection（反射）
- 當無線訊號遇到一個光滑且大的表面（如牆壁、建築物或水面）時，會被反射回來，就像光線照到鏡子一樣。
- 可促成 **多重路徑傳輸（multipath transmission）**，也就是同一訊號從不同路徑到達接收端，可能會造成 **訊號干擾或衰減**。
- 在某些情況下，反射其實有幫助（例如在視線被遮擋的情況下提供替代路徑）。
2. Diffraction（繞射）
- 當無線電波遇到障礙物邊緣（例如建築物轉角或山丘），訊號會彎曲繞過障礙物繼續傳播。
- 使得訊號能夠「轉角遇到你」，在無法直視發射器的情況下仍能接收到訊號。
- 但繞射通常會降低訊號強度。
3. Penetration（穿透）
- 指無線訊號穿過某些材料（如玻璃、牆壁或木門）的能力。
- 穿透力取決於訊號的頻率（高頻通常穿透力較弱）和材料的性質（例如混凝土比玻璃更難穿透）。
- 穿透會造成訊號 **衰減（attenuation）**，導致訊號變弱。
:::warning
抽考！ WiFi 2.4 GHz v.s. WiFi 5 GHz
:::
4. Scattering（散射）
- 當訊號遇到粗糙、不均勻或小於波長的物體（如樹葉、雨滴、灰塵）時，訊號會向各個方向散開。
- 會造成訊號分散，降低主訊號強度。
- 散射也會導致多重路徑干擾，但有時可增加可接收訊號的範圍（在一定程度上補強死角區域）。

無論是反射、繞射、穿透或是散射，都有可能導致訊號失真。
#### Simplifies Friis' Formula 簡化的弗里斯傳輸公式
**弗里斯傳輸公式** 是在無線通訊中非常重要的一個公式，用來估算 **兩個天線之間的理論最大接收功率**

$$
P_r=P_t+G_t+G_r−20log_{10}(d)−20log_{10}(f)−32.45
$$

- $P_r$：接收功率（dBm）
- $P_t$：發射功率（dBm）
- $G_t、G_r$：發射與接收天線增益（dB）
- $d$：距離（km）
- $f$：頻率（MHz）
- $K=−32.45$：常數，僅在距離單位為公里、頻率為 MHz 時成立。

不考慮天線增益（即假設 $G_t=G_r=0$ ）時，可以簡化成 **Simplifies Friis' Formula**：
$$
P_r=P_t−20log_{10}(d)−20log_{10}(f)−32.45
$$
- 粗略預估兩裝置之間的最大傳輸距離
- 比較不同頻率下的傳輸表現（如 WiFi vs LoRa）
- 計算訊號衰減程度

:::info
**為什麼是 -32.45？**
弗里斯傳輸公式（對數形式）
$$
FSPL (dB)=20log_{10}(d)+20log_{10}(f)+K
$$

又因**原始的線性形式**為：
$$
FSPL (linear)=(\frac{4πdf}{c})^2
$$

轉為 dB（對數）形式後，加上單位換算：
- $d$：從米 → 公里（除以 1000）
- $f$：從 MHz → Hz（乘以 $10^6$）
- $c$：光速 ≈ $3×10^8$ m/s

整合之後，出現了這個單位校正項：
$$
K=20log_{10}(\frac{4π}{c}×10^6÷1000)≈−32.45
$$

若用 **米/Hz** 則改用 **−147.55**
:::

---

#### Example calculation
假設條件：
- $P_t=14 dBm$（LoRa 常用最大功率）
- $G_t=G_r=0 dBi$（簡化）
- $d=1 km$
- 比較兩種頻率下的路徑損耗（FSPL , Free-space path loss）

**WiFi 2.4 GHz（= 2400 MHz）**
$$
\begin{gather*}
FSPL=20log_{10}(1)+20log_{10}(2400)+32.45\\
=0+67.6+32.45=100.05 dB
\end{gather*}
$$

**LoRa 923 MHz（= 923 MHz）**
$$
\begin{gather*}
FSPL=20log_{10}(1)+20log_{10}(923)+32.45\\
=0+59.3+32.45=91.75 dB
\end{gather*}
$$

**結論：同樣距離下，低頻率（LoRa）訊號衰減較小！**
> 每 6 dB 差距大約代表功率差一倍 → LoRa 傳更遠更穩。

**理論最大距離（同樣 RSSI 閾值時）**
假設接收器靈敏度都是 $−120 dBm$，從公式反推最大距離 $dmax$：
WiFi：
$$
\begin{gather*}
d=10^\frac{(P_t−P_r+G_t+G_r−32.45−20log_{10}(f))}{20} \\
= 10^\frac{(14−(−120)−32.45−20log_{10}(2400))}{20}≈49.8 km
\end{gather*}
$$

LoRa：
$$
= 10^\frac{(14−(−120)−32.45−20log_{10}(923))}{20}≈129.6 km
$$

然而 LoRa 模組的接收靈敏度極高，常可達 **−137 dBm ~ −148 dBm**
> 每 6 dB 差距大約代表功率差一倍 → LoRa 傳更遠更穩。

用 −137 dBm 再計算一次距離：
$$
d = 10^\frac{(14−(−137)−32.45−20log_{10}(923))}{20}≈917.3 km
$$

若靈敏度進一步下降至 −145 dBm：
$$
d≈2304 km
$$

換言之，我們前面的 **129.6** 公里計算是在**保守設定**與中等靈敏度下的距離。實際環境中若條件非常良好，確實可能達到跨國連接的效果。

---

### Meshtastic 裝置選購

| 特性 | ESP32 | nRF52 | RP2040|
| ---- | -------- | -------- | ---- |
| 續航力 | 高功耗（100-120 mA），適合持續供電場景，如家用節點或車輛中並透過 USB 電源供電 | 超低功耗（9-12 mA），適合電池供電、便攜裝置和遠端節點 | 功耗稍高於 nRF52，無內建無線功能，適用於不常維護的遠端節點 |
| 無線連線 | 支援 Wi-Fi 和藍牙，能透過 MQTT 伺服器同步訊息，適合連網需求 | 僅支援藍牙低功耗，適合電池續航場景 | 無無線連接功能，僅能透過 USB 完成所有設定 |
| 價格與性價比 | 低成本，適合需要連網功能的使用者 | 高成本，適合追求低功耗和便攜性的使用者 | 中成本，適合預算有限且對無線連線需求較低的使用者 |
| 適用場景 | 附近有電源、需要 MQTT 或 Wi-Fi 功能的連網場景 | 需要長續航力、便攜的場景 | 預算有限的遠端部署節點或低維護場景

---

## [概述](https://meshtastic.org/docs/overview/)
> 無論是 Meshtastic 還是 LoRaWAN，兩者的通訊協議與運作邏輯，都可以完全獨立於現有的 TCP/IP 網路環境運行。

### 運作原理
當我們透過手機應用程式或電腦（例如 CLI 工具）發送訊息時，訊息會透過下列其中一種介面進入 Meshtastic 裝置：
- 藍牙低功耗（BLE）
- Wi-Fi / Ethernet（若已連線）
- USB 串列埠（serial connection）

隨後透過廣播播出。若在指定時間內未收到 ACK，則最多**重傳三次**（共發送最多四次）

每個接收的 Meshtastic 節點會先檢查封包的 **唯一 ID（Packet ID）** 是否已收過：
- 若已收過 → 忽略（避免重複轉發）
- 若未收過 → 進行以下操作：
- 儲存封包（若本地有應用程式連線則轉交給它）
- 若 hopLimit > 0，將其 **減 1 並重新廣播**
- 若 hopLimit = 0，則**不再轉送**

若此時裝置沒有連接到應用程式使用者端，它會將接收到的重要封包暫時快取在記憶體中。預設最多快取約 **30 筆封包**，新封包會覆蓋最舊者

---

### Radio Settings
Meshtastic 使用每個區域指定給 LoRa 技術的各頻譜頻率範圍。像是在美國地區就有數百個頻道。

#### 數據速率

| 預設名稱 | 顯示名稱 | 數據速率 | 展頻因子/符號 | Coding rate | 頻寬(kHz) | 鏈路預算 | 最適用場景 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SHORT_TURBO | 短距離/極速 | 21.88 kbps | 7 / 128 | 4/5 | 500 | 140dB | 近距離、需要快速回應 |
| SHORT_FAST | 短距離/快速 | 10.94 kbps | 7 / 128 | 4/5 | 250 | 143dB | 近距離、需要快速回應 |
| SHORT_SLOW | 短距離/慢速 | 6.25 kbps | 8 / 256 | 4/5 | 250 | 145.5dB | 近距離、較佳穩定性
| MEDIUM_FAST | 中距離/快速 | 3.52 kbps | 9 / 512 | 4/5 | 250 | 148dB | 中等距離、平衡速度
| MEDIUM_SLOW | 中距離/慢速 | 1.95 kbps | 10 / 1024 | 4/5 | 250 | 150.5dB | 中等距離、更佳穩定性
| LONG_FAST | 長距離/快速 | 1.07 kbps | 11 / 2048 | 4/5 | 250 | 153dB | 預設值，一般用途
| LONG_MODERATE | 長距離/慢速 | 0.34 kbps | 11 / 4096 | 4/8 | 125 | 156dB | 長距離、穩定連接
| VERY_LONG_SLOW | 超長距離/慢速 | 0.18 kbps | 12 / 4096 | 4/8 | 125 | 158.5dB | 極遠距離、慢速傳輸

> Short Turbo 是最快的頻道，也是唯一具有 500kHz 頻寬的頻道。由於頻寬較寬，因此在其他地區不一定能合法使用。

- Spreading Factor 改變的是「每一個 LoRa 符號」的時長與可攜帶資訊量
- 一個 LoRa 符號（symbol）要「擴散」成 2^SF 個無線波形時間單元（chirp）來傳送，SF = 訊號「拉長來傳」，時間長、頻率低、容錯高。

$$
SF=log_2(每個\ symbol\ 表示的位元數)
$$

| SF 值 | 意思 | 說明 |
| ---------------- | ----------------- | ------------------- |
| **高 SF（SF12）** | **慢速傳輸，長距離，抗干擾強** | 傳輸時間長、空中佔用久，但訊號容錯率高 |
| **低 SF（SF7）** | **快速傳輸，短距離，抗干擾弱** | 傳輸快、省時，但訊號需較強 |

- Coding Rate - 我們 coding 多少冗餘來抵抗雜訊，使得即使部分資料被干擾破壞，仍能 **「靠冗餘自動修正一定數量的錯誤」** 而不是丟包。
- 無線晶片在調變時就帶入一種 **前向錯誤更正碼（FEC）**
- LoRa 把每 4 位元的「資訊符號」 配上 1 ~ 4 位元的「奇偶檢查位元」
$$
CR=\frac{k}{n}
$$
- $k$：實際有用的資料位元數
- $n$：總傳送的位元數（含冗餘）

| Coding Rate | 抗干擾力 | 傳輸速度 | 說明 |
| ----------- | ---- | ---- | ------------ |
| 4/5 | 最低 | 最快 | 僅提供輕微錯誤更正 |
| 4/8 | 最強 | 最慢 | 高冗餘，抗干擾強，但耗時 |

- 頻寬 - 是訊號擴散的範圍
- 若選用 125 kHz → 訊號會覆蓋從 922.9375 MHz 到 923.0625 MHz（大約 ±62.5 kHz）
- 除非擁有高品質的石英振盪器，否則小於 31 KHz（7.8, 10.4, 15.6, 20.8 kHz） 會造成反效果讓訊號不穩定
- 頻寬每增加一倍，預算就會減少近 3db。

:::info
**LoRa 簡化的調變順序**
1. 送出前，LoRa 先把每個 4‑bit 資料組 進入一個小型線性碼產生器 (G matrix)，產出 4 + CR 位元。
2. 生成的 bit 會「縱向」交織到 SF 個 symbol 序列 中（Spread‑spectrum 對干擾最敏感位元被分散）。這一步讓連續的雜訊脈衝不會一次毀掉整組 parity。
3. 晶片在解調時將符號對映回 bit，先反交織，再用同一組 (n,k) 校驗矩陣做 syndrome 計算，若錯誤數在能力範圍內就直接更正。超過可修正數量 → 以 CRC 錯誤呈現給上層，Meshtastic 視情況重傳

**縱向的意思是？**
假設我們有以下的資料位元序列（每行代表一個符號）：

符號1: b1 b2 b3 b4
符號2: b5 b6 b7 b8
符號3: b9 b10 b11 b12
...

在縱向交織後，資料會被重新排列為：

列1: b1 b5 b9 ...
列2: b2 b6 b10 ...
列3: b3 b7 b11 ...
列4: b4 b8 b12 ...

:::

:::success
可以透過 Web Client 或 CLI 調整參數

meshtastic --set radio.frequency 923000000          # 中心頻率（台灣用 920~925 MHz）
meshtastic --set radio.spreadingFactor 12           # 擴展因子 SF7~SF12
meshtastic --set radio.bandwidth 125000             # 頻寬 125/250/500 kHz
meshtastic --set radio.tx_power 20                  # 發射功率 (最大視韌體/區域限制)
meshtastic --set radio.coding_rate 5                # （代表 4/5）

:::

---

### [Mesh Broadcast Algorithm](https://meshtastic.org/docs/overview/mesh-algo/)

根據 Meshtastic 官方的 Protobuf 說明，在 Meshtastic 中：
- 只有一種主要封包格式：**MeshPacket**
- 所謂的 Layer 1~3，並不是把封包一層層包起來（不像 TCP/IP 那樣封裝成 stack）
- 而是 **根據用途設定欄位行為、控制欄位、轉發邏輯的不同，形成功能上的分層效果**

#### MeshPacket 長什麼樣子？
| 區段 | 長度 | 備註 |
| ---------- | ----------------- | ------------------- |
| Raw Header | 16 bytes | 固定格式 |
| Payload | 最多 237 bytes | Protobuf + 加密後的資料 |
| **總長度** | 最多約 **253 bytes** | 不可超過 LoRa 封包極限（255） |
> 預留 2 bytes 給 LoRa 模組內部處理或 CRC 校驗

[Ref.](https://buf.build/meshtastic/protobufs/docs/main:meshtastic#meshtastic.Config)

**Raw Header + Payload**
| Offset | Length | Type | Usage |
| ------ | ------ | ---- | ----- |
| 0x00 | 4 bytes | Integer | **目的節點的 NodeID。** 若為 0xFFFFFFFF 表示廣播（所有人都會收） |
| 0x04 | 4 bytes | Integer | **來源節點的 NodeID** |
| 0x08 | 4 bytes | Integer | **封包 ID**，由傳送者產生的唯一識別碼，用於辨識與去重 |
| 0x0C | 1 byte | Bits | 旗標欄位（Flags），**HopLimit、WantAck、ViaMQTT** |
| 0x0D | 1 byte | Bits | **頻道 Hash**，用來快速判斷接收端是否能解密此封包（頻道對不對） |
| 0x0E | 1 byte | Bytes | **下一跳節點 ID（Next-hop）**，轉發時由上一站提供 |
| 0x0F | 1 byte | Bytes | **目前這一跳的轉發節點 ID（Relay）** |
| 0x10 | 最多 237 bytes</br>[Ref.](https://meshtastic.org/docs/overview/mesh-algo/) | Bytes | **實際 payload 資料**（通常是加密的 SubPacket Protobuf）

**Raw Header 是給「收訊設備」快速做決策用的，而 Protobuf 是給「人類與應用層」理解資料用的。**
「我是不是目標」 → 用 Raw Header 快速判斷
「真正的內容是什麼」 → 之後再來打開 Protobuf 看

:::info
這樣設計的理由
- LoRa 裝置資源有限（慢速、低功耗）
- 解 Protobuf 非常「耗電」，若每個封包都解很浪費
- 所以先看 Raw Header：
- 是我要收的嗎？（to ID）
- 頻道對嗎？（channel hash）
- 是不是重複？（packet_id）
- 如果不符合 → 不解、直接丟掉（省電）
- 如果符合 → 再解開 payload 裡的 Protobuf
:::

---

#### **Layer 0：LoRa 通訊模組**
> 把整包封包（MeshPacket）進行 LoRa 調變，轉為實體電波

前面提到 LoRa 是一種以「擴頻調變」（Spread Spectrum Modulation）為基礎的無線技術。
當 Meshtastic 或其他應用層傳送資料時，這些資料會經過 LoRa 晶片進行調變，轉換成「LoRa symbols」：

- 每個 symbol 是一種代表特定位元組（bits）的波形模式。
- symbol 的數量與「擴展因子」（Spreading Factor）有關，例如 SF=7 時，每個 symbol 可以代表 $2^7$ = 128 種波形。
- 這些 symbols 不包含邏輯性的 header/payload，純粹是調變結果。

你可以視為「黑盒子」，上層只需丟進位元資料，它會負責實體傳輸。

傳輸前先傳送：
- 前導碼（Preamble）：讓接收器同步
- 同步字（Sync Word）：區分網路
- LoRa PHY Header：封包長度、CRC

最終將封包（MeshPacket）轉換成 LoRa symbol
- 內容會在 Layer 1~3 中詳細定義欄位值、控制行為、節點處理邏輯，但對 LoRa 模組來說，它只是一連串位元資料。

:::success
這一層的行為幾乎不可自定，因為是由硬體自動處理，Meshtastic 只是設定其參數。
:::

---

#### Layer 1: 不可靠的零跳訊息傳遞（Unreliable One-Hop Messaging）
> 你把一封信貼在電線桿上，希望有人看到，但你**不在意有沒有人回應。**

這是 Meshtastic 中最基本、最輕量的通訊方式：
單純把訊息發出去，然後什麼都不管。
不會確認對方有沒有收到、不會重傳、不會經過其他節點轉送，因此稱為「不可靠」。
它是 Meshtastic 封包處理的核心基礎。
- 快速判斷封包去向與來源
- 讓接收方硬體在不解 Protobuf 的情況下就能判斷是否要理會此封包
- 節省頻寬與功耗

| 欄位 | 處理不處理 | 做什麼 |
| ----------------------- | ----------- | ------------------------------------------- |
| **to NodeID (0x00)** | ✔️ | 讓節點能快速判斷封包是不是給自己的 |
| **from NodeID (0x04)** | ✔️ | 讓節點知道是誰送來的 |
| **packet\_id (0x08)** | ❌ | 固定格式即包含，但在 Layer 1 模式中**不會用來去重複或做 ACK 對應** |
| **flags (0x0C)** | ✔️ | 用來表示這是不是加密封包、是否有 ACK 需求（在 L1 WantAck 為 false） |
| **channel hash (0x0D)** | ✔️ | 用來判斷頻道是否正確，以加密用 |
| **next-hop (0x0E)** | ❌ | 因為 Layer 1 不設 hop，不經由中繼轉送 |
| **relay node (0x0F)** | ❌ | 不涉及多跳轉送，所以無需記錄是哪個中繼節點 |

**傳輸協定：CSMA/CA（載波感測多重存取／碰撞避免）**
Meshtastic 採用與 Wi-Fi 類似的 CSMA/CA 無線傳輸技術，確保在擁擠的網路中減少碰撞：
1. **頻道活動偵測（CAD）**
- 發射端先執行一次 LoRa 頻道掃描，以判斷目前是否有其他裝置在發射。
- 若頻道忙碌 → 進入等待階段。
2. **隨機時槽延遲（Random Backoff）**：
- 等待時間以「隨機時槽（timeslot）」單位延遲。
- 所選等待時間取自 爭用視窗（Contention Window, CW），其大小依目前頻道繁忙程度而動態調整。
- 頻道越繁忙 → CW 越大 → 減少碰撞機率。

---

#### Layer 2: 可靠的一跳訊息傳遞（Layer 2: Reliable One-Hop Messaging）
> 你請人「傳遞信」給鄰居，並說：「收到了請回個短信」
若沒收到回覆你會**再寄一封**（最多 3 次）

這一層在第 1 層（不可靠傳輸）之上，提供**針對直接鄰近節點**的可靠資料傳遞功能。其核心是：**加入 ACK 回應與重傳邏輯**，確保單跳之間的封包**不是丟了就算了**。

**可靠訊息的觸發：`WantAck` 標誌**
- Meshtastic 使用 `MeshPacket` protobuf 結構中的 `WantAck` 欄位來決定封包是否需要可靠傳送：`WantAck` 標誌被設為 true 時，代表這封訊息是可靠訊息。
- 原始發送者期望接收者送回一個 ACK（確認）或 NAK（否定確認）。
- 若未收到 ACK，則會進入重傳機制。

| 欄位 | 處理不處理 | 做什麼 |
| ----------------------- | ----------- | ------------------------------------------- |
| **to NodeID (0x00)** | ✔️ | 讓節點能快速判斷封包是不是給自己的 |
| **from NodeID (0x04)** | ✔️ | 讓節點知道是誰送來的 |
| **packet\_id (0x08)** | ✔️ | 封包 ID 必須儲存、等 ACK |
| **flags (0x0C)** | ✔️ | `WantACK = True` |
| **channel hash (0x0D)** | ✔️ | 用來判斷頻道是否正確，以加密用 |
| **next-hop (0x0E)** | ❌ | 還不需要中繼 |
| **relay node (0x0F)** | ❌ | 不涉及多跳轉送，所以無需記錄是哪個中繼節點 |

**廣播封包的特殊處理：隱式 ACK**
如果每個收到廣播的節點都送一個 ACK 回來，會造成災難性的頻道擁塞（ACK storm）。
> 全部人回覆 → 頻道爆炸 （嚴重碰撞）

因此 Meshtastic 的 Layer 2 廣播有一種特別處理：

- 發送節點不等每個人 ACK
- 而是「聽看看有沒有人把我的封包轉送（重播）出去」
- 這樣也算是「有人收到了」，就當作成功 → 這叫做隱式 ACK
- 若一段時間內都沒聽到 → 啟動重傳機制。

這段邏輯實作於 `FloodingRouter.cpp` 中：
1. A 節點發送一筆廣播封包（Layer 2、WantAck = true）
2. B 節點收到該封包 → 對所有人轉送（因為是 flooding）
3. A 節點再度「聽到」這封包（但不是自己剛發的版本）
4. FloodingRouter.cpp 判斷這是 同一筆 packet_id、不是自己送的、但別人重送了

**ACK 封包與 NAK 行為**
對於需要確認的封包，目標節點會：
- 若成功接收 → 回傳 ACK 封包（明確回應）。
- 若格式錯誤、無法處理 → 回傳 NAK 封包（Negative ACK）。
- 若都沒收到 → 發送者會最多重傳 3 次。

超過 3 次仍未成功，則本地節點會產生內部 NAK 事件，供應用程式處理（例如顯示錯誤或記錄）。

**重傳邏輯簡要流程**
1. 發送封包（WantAck = true）
2. 計時等待 ACK
3. 若逾時未收到：
- 若未超過 3 次重傳 → 再次發送封包
- 否則 → 停止發送，產生內部 NAK

:::success
| 機制 | 說明 |
|------|------|
| `WantAck` 標誌 | 啟動可靠傳送流程 |
| 明確 ACK 封包 | 直接回應封包成功接收 |
| 隱式 ACK | 廣播封包改以監聽再轉發判斷是否成功送達 |
| 重傳機制 | 最多重傳 3 次 |
| Timeout 計算 | 考慮空中時間、碰撞延遲等 |
:::

:::info
**分享個有趣事**
當我拿著天線繞著學校跑時：
為啥我手機顯示 NAK，但 Moli 有收到我的訊息？

:::

---

#### Layer 3: 多跳可靠傳輸（Multi-Hop Routing）
> 你寫一封信寄給另一個城市的朋友，信封上寫好**轉交地點與最終收件人**。郵差會依地址轉送。
途中每一站都會回報「已轉交」，或在失敗時讓你知道。

Meshtastic 在第 1 層提供了基礎廣播能力、第 2 層建立了可靠的單跳訊息傳遞技術。
第 3 層是 Meshtastic 網狀協定中實現「真正網狀網路功能」的核心所在。

==目標：讓封包「跳過」中繼節點傳送至遠端節點==

| 欄位 | 處理不處理 | 做什麼 |
| ----------------------- | ----------- | ------------------------------------------- |
| **to NodeID (0x00)** | ✔️ | 讓節點能快速判斷封包是不是給自己的 |
| **from NodeID (0x04)** | ✔️ | 讓節點知道是誰送來的 |
| **packet\_id (0x08)** | ✔️ | 用於多跳一致性、防重複 |
| **flags (0x0C)** | ✔️ | wantAck + HopLimit |
| **channel hash (0x0D)** | ✔️ | 用來判斷頻道是否正確，以加密用 |
| **next-hop (0x0E)** | ✔️ | 用於動態路由時的轉發依據 |
| **relay node (0x0F)** | ✔️ | 可記錄這一跳中繼是誰 |

**1. 透過「氾洪式路由（Flooding Routing）」讓訊息跳來跳去**
- 所有收到封包的節點都會：
- 檢查封包是否已看過（根據 id 過濾重複）
- 若沒看過 → 轉發一次（只一次） → hopLimit - 1
- 持續傳遞直到 hopLimit 被達到。

**2. 每次跳轉都要重傳確認（靠 Layer 2）**
- A → B → C → D
- 每一站之間，其實還是用「我要等你回應」的方式進行（Layer 2 的可靠機制）
- `WantAck` 在多跳環境中一樣適用：
- 最終目的地仍會嘗試回傳一個 ACK 封包；
- `from = D`, `to = 原始 sender A`, `WantAck = false` (通常), `hopLimit` 按預設
- 它「看起來」常常走回原路，只是因為在多數靜態/半靜態拓撲下，回程的“最佳路徑”恰好仍是剛才的反方向而已。
- 如果 B 沒收到 A 的訊息 → A 會重送
- 如果 C 沒收到 B 的訊息 → B 會重送

**3. 使用「跳數限制」防止無限轉送**
- 每個訊息都會帶著一個「還可以跳幾次」的計數器
- 每轉送一次就減 1
- 如果跳數用完了 → 這個訊息就不再被傳下去
- 這就是所謂的 hopLimit → 控制範圍與資源佔用

---

### [Meshtastic Managed Flooding](https://meshtastic.org/docs/overview/mesh-algo/)

Meshtastic 網狀協定為了支援各種使用情境，大部分的資料傳輸都基於 **氾洪式廣播（flooding）**，也就是每個節點在收到封包後會轉發（rebroadcast）該封包，直到封包的跳數限制（hop limit）用完為止。

但與傳統氾洪不同，Meshtastic 採用的是 **「託管氾洪（Managed Flooding）** ，更節能、更智慧、更避免網路壅塞。

---

#### 核心概念

- **HopLimit ≠ 0**：只要封包的 HopLimit 不為零，節點就會考慮是否要中繼。
- **先聽再轉發**：節點在準備轉發前，會「短暫監聽」一下看看有沒有人**已經轉發了這個封包**。
- 有人轉發了 ➜ 不再轉發（避免重複）；
- 沒人轉發 ➜ 就進行廣播（中繼）；
- 因此稱為「託管（Managed）」，不是盲目一律中繼，而是有條件地做判斷。

---

#### Rebroadcast 流程詳解

1. 節點收到封包；
2. 檢查封包的 `HopLimit`：
- 若為 0 ➜ 不處理；
- 若 > 0 ➜ `HopLimit - 1`，準備中繼；
3. 在短時間內「監聽」其他節點是否已有轉發該封包；
4. 若無其他轉發 ➜ 執行中繼；
5. 若有其他轉發 ➜ 停止自己轉發。

---

#### 新技術：Signal-to-noise ratio（SNR） 與Contention Window（CW）

為了**優先讓遠距節點進行轉發**，Meshtastic 將「訊號雜訊比（SNR）」用來調整等待時間：

| **SNR 狀態** | **競爭視窗（CW）大小** | **轉發機會** |
|--------------|--------------------------|--------------|
| 低（代表距離遠、訊號弱） | 小（較快發送） | 高 |
| 高（代表距離近、訊號強） | 大（等待較久） | 低 |

如此一來，遠距節點更可能轉發出去，讓封包「跳得更遠」近距節點收到時，如果已經聽到有人轉發了，就不再重複轉發。

#### Example
下面你可以看到一個由四個節點組成的範例拓撲 `CLIENT` 模式，在某個點，節點 0 想要發送廣播訊息。由於覆蓋範圍有限，它只能到達節點 1 和 2。且由於節點 2 距離較遠，其 SNR 較低，因此 2 比 1 更早開始重新廣播。
節點 0 收到此重新廣播後，其訊息被確認。一旦收到來自任何 Meshtastic 節點（無論是否具有相同的加密金鑰）的重新廣播，即表示已確認訊息。節點 2 把 hopLimit 減 1（變成 2），並廣播封包這個封包被 節點 3 接收到，同時，節點 1 在 延遲期間也聽到了來自節點 2 的轉發，由於節點 1 聽到了 2 的重播，因此它不會再次重播。節點 3 第一次聽到該訊息，並且 HopLimit 尚未為零，因此它開始向潛在的其他接收者重新廣播。

那如果實際場景其實節點 1 後方有更多節點 4, 5, 6，且節點 4, 5, 6 是節點 2 通訊距離外的、節點 0 也無法直接與節點 4, 5, 6 溝通，若透過同樣的 SNR 技術來決定等待時間，節點 2 比 1 更早開始重新廣播，這樣封包不就到不了節點 4, 5, 6 沒辦法讓封包跳更遠了？

整個 Flooding 邏輯其實是 「先讓遠的試傳、但永遠保留讓近的補傳的機會」只要節點 1 後方更多節點 4, 5, 6真的還沒聽到，網路最終仍會產生至少一次 來自 1 方向的重播。

1 與 2 不會每次都是 100 ms vs 500 ms，CW 裡有隨機 jitter。有機率 1 先於 2 發射，此時 2 就會偵測到 1 的包而閉嘴，這一輪就換 1 當「遠端覆蓋擴張者」，讓另一側仍能拿到訊息。

### [Meshtastic 2.6+ 採用的新技術 Next-Hop Routing](https://meshtastic.org/docs/overview/mesh-algo/)

在過去版本中，Meshtastic 的所有訊息（無論是廣播還是私人訊息）基本上都透過 **託管洪氾（Managed Flooding）** 的方式來傳送，也就是所有節點會有條件地轉發封包來「漫灑」整個網路。

這種方式對於保證資料傳遞到每個角落的「廣播型任務」很有效，但對於「點對點」的私人訊息就顯得：
- 效率低（整個網都收到）、
- 頻寬浪費（所有節點都要參與中繼）、
- 風險高（訊息被非目標節點中繼）。

因此從 **v2.6 開始，Meshtastic 採用 Next-Hop Routing 來傳送私人訊息（direct messages）**，提升效能與機密性。

---

#### 什麼是 Direct Message？

Direct Message 是 Meshtastic 用於「一對一」通訊的訊息類型。例如：
- A 發訊息給 B（非廣播）；
- 想傳遞的資料只需由特定接收者獲得。

---

#### Next-Hop Routing 的工作原理

這種方式有點像 IP 網路中的路由傳送，具體如下：

建立路由表（Routing Table）
每個節點會**持續蒐集關於鄰近節點與遠端節點的連線資訊**，例如：
- 我知道誰在哪裡
- 到那個人，我要經過哪一個節點最有效

這些資料來自：
- 節點廣播自己的存在；
- 網路中正常封包傳遞過程中的觀察。

#### Example

1. A 要對 D 傳送資料
- A 不知道如何到達 D，所以這次訊息會透過洪氾方式發送
- A 透過中繼節點 B、E 廣播此訊息。
- B 收到後，會再經由其中繼節點（C 和 D）進行轉發。
- D 終於收到訊息。
2. D 回覆 A
- D 回覆給 A（例如 ACK 或是回覆訊息）
- 若 D 還不確定「怎麼走回 A」，可能也會使用洪氾
- 此時 B 可能再次轉發此回覆
- A 收到後更新其路由表：「原來可以透過 B → D」
3. 從 A 精確傳送到 D
- 現在 A 知道傳送給 D 的最佳下一跳是 B（因為上次回覆走這條路回來）。
- A 不再使用洪氾，而是直接將訊息送給 B。
- B 再發送給 D，傳送完成。

**補充說明：動態調整與容錯**
- 若某次訊息失敗（例如 B 掛了），系統會**回退到 flooding** 模式作為備援。以尋找新路由。
- 所以 Meshtastic 是 **混合型洪氾與路由架構**，靈活適應網狀網路的不穩定特性。

:::success
| 功能 | 說明 |
|------|------|
| 多跳 | 封包可以跨多個節點傳遞至目標 |
| Routing 欄位 | from/to/via/hopCount/hopLimit |
| 路由機制 | Flooding（傳統）與 Next-Hop（新技術） |
| 重傳與 ACK | 每一跳都需確認，避免封包遺失 |
| 去重機制 | 快取封包 ID，避免重複處理 |
:::

---

### Meshtastic roles setting
Meshtastic 有多種角色，包括：
- 客戶端（CLIENT）
- 靜音客戶端（CLIENT_MUTE）
- 中繼器（REPEATER）
- 路由器（ROUTER）

> [Ref.](https://pole1.co.uk/meshtastic-roles/xrecomended-meshtastic-roles-1200-630.png.pagespeed.ic.95dbankPaO.png)

#### 客戶端（CLIENT）
客戶端角色是 Meshtastic 預設的節點角色 ，適合大多數使用者的使用場景。
- 高層公寓陽台
- 商業大樓陽台
- 山區屋子
- 單棟房屋的三樓以上

選擇此角色時，節點可以透過藍牙與應用程式進行通訊，這意味著你可以使用手機或其他支援 Meshtastic 應用程式的裝置與節點進行互動。同時，節點會將其接收到的流量重新路由到其他節點，從而擴展整個網路的覆蓋範圍。

#### 靜音客戶端（CLIENT_MUTE）

- 建議用於：移動設備，例如徒步、車載或無人機節點。
- 接收附近節點的訊息，但不會轉送流量。
- 避免移動節點頻繁變換位置導致網路路由問題。

在使用中，當一個節點的地理位置不斷變化時，重新路由會對網路的效能造成嚴重干擾。因此，靜音客戶端角色是確保網路穩定性的最佳選擇。

例如，當你徒步穿越森林或山區時，攜帶一個輕便的 Meshtastic 節點並將其設定為 `CLIENT_MUTE` 是非常合適的。這樣一來，你可以即時接收網路中的訊息，而不會對整體網路路由造成乾擾。

#### 中繼器（REPEATER）

- 專門用於擴展網路覆蓋範圍。不會顯示在節點清單中。
- 同樣要求安裝在高處。
- 類似路由器 `ROUTER` 角色，但更注重於訊號的中繼和延伸。適合地形開闊但需要擴展網路範圍的場所。

專門作為中繼節點。會幫忙轉送封包，但不發出訊息。適合裝在高處的固定節點。

#### 路由器（ROUTER）

- 位於戰略性高點，例如山頂或大樓天台。
- 必須具有清晰的視野。
- 配備最佳的天線和設備設定。
- 誤用ROUTER 角色可能會導致網路無法正確路由訊息。

在高山頂端設定一個 `Router` 角色的節點，可以覆蓋山谷和周邊地區的大範圍訊號，為低地的 `Client` 節點提供支援。在城市環境中，可以將節點安裝在高樓的天台上，確保其具有良好的視野和訊號傳播能力。

同時支援中繼與處理封包，也可以發送自己的訊息。像 CLIENT + REPEATER 的混合體。

---

## Meshtastic 與 MQTT 橋接
> 無論是 Meshtastic 還是 LoRaWAN，兩者的通訊協議與運作邏輯，都可以完全獨立於現有的 TCP/IP 網路環境運行。
> https://meshtastic.org/docs/software/integrations/mqtt/


LoRa（含 LoRaWAN）本質上是一種物理與資料鏈路層技術
- 使用 Sub-GHz 頻率（如 433/868/923 MHz）進行無線資料傳輸
- 與 Wi-Fi、Ethernet 不同，它不依賴 IP 封包格式、TCP/UDP 協定

Meshtastic 同樣是非 TCP/IP 網路
- Meshtastic 使用的是自訂的 mesh protocol，在 MeshPacket 格式中並沒有任何 IP、MAC、Port 等欄位
- 節點透過 LoRa 廣播 + 多跳 routing（例如 flooding + next-hop routing）來傳輸訊息
- 全部都在自訂的層級與封包設計下實作，根本不需要 TCP/IP 協定來傳送訊息

Meshtastic 是一種低功耗、去中心化的 LoRa Mesh 網路，非常適合無基礎建設的場景，但在日常生活中，整合現有網路能強化其應用面：
- 提供與外部網路（如手機、電腦）的即時同步
- 支援遠端監控、傳感器數據回傳
- 作為斷網備援，提升韌性

:::success
### 敘事情境
凌晨 3 點，一場規模 8.2 的地震撼動了整座城市。幾分鐘之內，電力中斷，網際網路消失，行動基地台倒塌，城市彷彿被從世界地圖上抹去。人們無法打電話，無法傳訊，外界也無從得知這座城市發生了什麼。

但在一個社區的防災中心裡，微弱的 LED 還亮著。這不是因為有電，而是因為他們預先部署了一套低功耗、獨立於網路的 **Meshtastic + 本地 MQTT 系統**。

幾個核心志工啟動了背包中內建 LoRa 模組的 Meshtastic 節點，可以彼此透過無線電方式溝通，組成一個不需要基地台、不需要網路的自組通訊網路。這個網狀網路迅速延伸到醫院、學校、各個避難所，甚至是仍被瓦礫困住的人手上的小型裝置。

在防災中心內，志工透過接在 Raspberry Pi 上的 MQTT 伺服器整合了所有節點傳來的資訊。即使沒有網際網路，這個區域 MQTT Server 仍然能接收並整理所有訊息，包括：
- 傷患回報與資源請求：某避難所傳來消息，缺乏醫療用品與飲用水，透過 MQTT topic 發佈給所有人。
- 倖存者定位：有居民用手機連上 LoRa node，發出求救訊號，被臨近節點接收後中繼至中心。
- 志工派遣與人員調度：指揮中心透過 MQTT 下達任務，通知就近的志工節點。

甚至連裝有簡易螢幕的裝置，也能實時顯示資訊公告與緊急通知。整個系統的通訊範圍可達數公里以上，透過節點中繼甚至可橫跨整座城市。
:::

### [MQTT 模組與雲端橋接原理](https://meshtastic.org/docs/software/integrations/mqtt/)
Meshtastic 原生支援透過 WiFi 將節點連接至 MQTT Broker，實現 LoRa 網路與 TCP/IP 網路的橋接。此橋接基於 MQTT 的發布/訂閱機制，使節點之間的訊息能同步至本地或雲端伺服器，進一步整合儀表板、監控系統或遠端控制。

### Meshtastic MQTT 橋接架構解析

#### LoRa ↔ MQTT ↔ Cloud 流程
1. Meshtastic 節點透過 LoRa 傳送訊息至具備 Wi-Fi 功能的「橋接節點」。
2. 橋接節點將封包轉送至指定的 MQTT Broker（可為本地 Raspberry Pi 或雲端服務）。
3. MQTT Broker 將訊息發佈至指定的 topic，供其他應用程式訂閱（如 Home Assistant、Node-RED）。
4. 來自 MQTT 的控制訊息亦可傳入，透過橋接節點發送至 LoRa 網路。

#### 端點裝置（Gateway）的角色與需求
- **角色**：LoRa ↔ TCP/IP 的橋梁節點
- **硬體建議**：具備 Wi-Fi 的 ESP32（如 T-Beam、T-Echo）或 Raspberry Pi + LoRa 模組
- **軟體需求**：已開啟 MQTT 模組、正確設定 Wi-Fi 參數與 MQTT topic
- **電力建議**：建議使用穩定電源或太陽能模組，提升長期穩定性

---

### 實作教學最低成本方案：Raspberry Pi + SX126x 系列 LoRa 模組

#### 一、硬體需求與接線
| 組件 | 說明 |
|------|------|
| Raspberry Pi | 建議使用 Pi 3/4（具備 Wi-Fi） |
| LoRa 模組 | SX126x（如 SX1262） |
| 杜邦線 | 使用 SPI 模式連接 GPIO |
| 天線 | 依模組頻率選擇（如 923 MHz） |

SX126x ↔ Raspberry Pi 接線對照（SPI 模式）
| SX126x 引腳 | Raspberry Pi GPIO | 說明 |
|-------------|-------------------|------|
| MISO | GPIO 9 | 資料輸入 |
| MOSI | GPIO 10 | 資料輸出 |
| SCK | GPIO 11 | 時脈 |
| NSS / CS | GPIO 8 | 裝置選擇 |
| DIO1 | GPIO 25（可調） | IRQ 中斷 |
| RESET | GPIO 22（可調） | 重設 |
| GND | GND | 地線 |
| VCC | 3.3V | ⚠ 請勿接 5V |

#### 二、安裝 Meshtastic Gateway（Linux）
1. 安裝必要工具

sudo apt update
sudo apt install -y python3-pip git
pip3 install meshtastic
pip3 install meshtastic[linux]

#### 三、啟動 Gateway 並連接 MQTT
1. 使用 meshtastic-gateway 啟動 LoRa Gateway + MQTT 模組

meshtastic-gateway --port /dev/spidev0.0 \
                   --mqtt-host localhost \
                   --mqtt-port 1883 \
                   --mqtt-username youruser \
                   --mqtt-password yourpass

若如使用外部雲端 MQTT（如 HiveMQ 或 AWS IoT）：

--mqtt-host broker.hivemq.com
--mqtt-port 1883

#### 四、Meshtastic 節點設定 Wi-Fi 與 MQTT

meshtastic --set wifi.enabled true \
           --set wifi.ssid "YourWiFiSSID" \
           --set wifi.pass "YourWiFiPassword" \
           --set mqtt.enabled true \
           --set mqtt.broker_host "192.168.1.100"  # 替換為你的 MQTT IP

#### 本地 MQTT Broker 架設（Raspberry Pi）

sudo apt install mosquitto mosquitto-clients
sudo systemctl enable mosquitto
sudo systemctl start mosquitto

訂閱：

mosquitto_sub -t "meshtastic/received" -v

發送測試訊息：

mosquitto_pub -t "meshtastic/received" -m "Hello from MQTT"

#### MQTT Bridge 測試與除錯方法
- 使用 CLI 測試：
- `mosquitto_sub -t "meshtastic/received" -v
`
- `mosquitto_pub -t "meshtastic/write" -m '{"payload": "hello"}'
`
- 檢查 Meshtastic Console 訊息是否出現：
- `MQTT connected`
- `MQTT publish successful`
- 打開 Debug 訊息：
- `meshtastic --info`
- `meshtastic --set logging.debug true`

:::warning
| 問題 | 除錯建議 |
|------|-----------|
| 沒有收到 MQTT 訊息 | 檢查 `mosquitto` 是否啟動、主機名稱是否正確 |
| LoRa 模組未回應 | 確認 SPI 設定、引腳接線、SX126x 是否支援 SPI 模式 |
| 無法啟動 `meshtastic-gateway` | 使用 `--verbose` 模式查看詳細錯誤 |
| Protobuf 解碼失敗 | 使用 Meshtastic Python 套件解密 MQTT 訊息 |
:::

#### Meshtastic Software Configuration
若所在區域的 Meshtastic 覆蓋率還不高，或是因爲四周都是高樓大廈導致無法穩定的收到其他裝置的 LoRa 訊號，那你就需要需要開啓 MQTT，來利用網際網路傳送訊息，設定方法如下：

Android app
- Radio configuration(裝置設定) → Lora → 取消選取 Ignore MQTT → 按下 Send → 裝置會重開機，等它開完機並重新連上手機
- 回到 Radio configuration(裝置設定) → 往下捲動找到 MQTT → 打開 MQTT enabled → 打開 Encryption enabled → 打開 Proxy to client enabled （以此讓裝置透過手機的網路來接收與傳送訊息） → （其他的開關都不用開）→ 按下 Send → 裝置會重開機，等它開完機並重新連上手機即完成
- 同樣在 MQTT 的設定頁面，Root Topic 的部分確保設定爲 msh/TW，不要是 msh/TW/XXX 之類的，只要 msh/TW 就好，不然會收不到其他人的訊息

iOS app

- 設定頁 → LoRa → 取消選取 Ignore MQTT → 按下儲存 → 裝置會重開機，等它開完機並重新連上手機
- 設定頁 → 往下捲動找到 MQTT → 打開、MQTT 客戶端代理、是否與客戶端連線、Encryption Enabled 共四個開關打開。
- 同樣在 MQTT 的設定頁面，Root Topic 的部分確保設定爲 msh/TW，不要是 msh/TW/XXX 之類的，只要 msh/TW 就好，不然會收不到其他人的訊息
- 確認後按下儲存 → 裝置會重開機，等它開完機並重新連上手機即完成

或點下方跳轉到 Meshtastic 官方文件說明
- [Android App](https://meshtastic.org/docs/category/android-app/)
- [Apple Apps](https://meshtastic.org/docs/category/apple-apps/)
- [Web Client](https://meshtastic.org/docs/software/web-client/)
- [Meshtastic Ul](https://meshtastic.org/docs/software/meshtastic-ui/)
- [Python CLI](https://meshtastic.org/docs/software/python/cli/)
- [Meshtastic Site Planner](https://meshtastic.org/docs/software/site-planner/)
- [Meshtasticator (Simulator)](https://meshtastic.org/docs/software/meshtasticator/)
- [Linux](https://meshtastic.org/docs/category/linux/)
- [InkHUD](https://meshtastic.org/docs/software/inkhud/)

---

## Meshtastic 加密技術總覽（Encrypt）

Meshtastic 使用 **端對端加密（E2EE）** 來保護通訊內容，即使中繼節點看到資料包，也無法解讀內容。

### 加密對象：SubPacket Payload

- **加密範圍：** Meshtastic 並非對整個封包（MeshPacket）加密，而是只對內部的 **SubPacket protobuf 負載** 加密。
- **未加密部分：**
- PacketHeader（封包頭，包含 NodeID、UniqueID、HopLimit 等）是明文的。
- 為什麼？這樣中繼節點才可以不解密就知道是否需要轉發（符合 mesh 網路特性）。

---

### 加密技術細節
#### 加密演算法
- 使用 **AES-256-GCM**（Authenticated Encryption with Associated Data）：
- **256-bit key** 對稱式加密 + 內建完整性認證
- **GCM 模式**：加密的同時提供認證保護（防止封包被竄改）。
- 避免重放攻擊與資料包竄改。

#### 金鑰協議
- 預設使用基於 **ECDH（Elliptic Curve Diffie-Hellman）** 的會談金鑰交換。
- 使用 Curve25519 進行金鑰交換（與 Signal、Matrix 等安全協議類似）。
- 由使用者透過 App / CLI / QR URL 手動設定或掃碼。
- 同一頻道的節點共享一條 256‑bit 秘鑰。

#### 裝置金鑰與頻道金鑰
- 每個通訊頻道使用：
- 自己的金鑰 **Channel Key**（可設定為公開或機密）
- 公開頻道：所有人可聽取，但加密資料仍需要金鑰才能解密。
- 私人頻道：只有知道金鑰的節點才能加入、加密與解密資料，可透過 CLI、手機 App、或 JSON config 設定頻道名稱與金鑰。

meshtastic --setchannel name secretchannel \
           --setchannel psk ab12cd34ef56ab12cd34ef56ab12cd34

---

# Meshtastic CLI 指令速查表

適用於 Windows / Linux / macOS
請先安裝 CLI 工具：`pip install meshtastic`
連線裝置時可使用 `--port COMx` 或 `/dev/ttyUSBx` 指定序列埠

---

## 裝置基本資訊

| 功能 | 指令 |
|------|------|
| 顯示裝置資訊 | `meshtastic --info` |
| 查看串流封包記錄 | `meshtastic --seriallog` |
| 韌體版本/節點 ID | `meshtastic --version` |

---

## 頻道與加密設定

| 功能 | 指令 |
|------|------|
| 設定頻道名稱與金鑰 | `meshtastic --ch-set name "MyChannel" --ch-set psk "MySecret"` |
| 顯示目前頻道設定 | `meshtastic --ch-show` |

---

## Wi-Fi / MQTT 設定

| 功能 | 指令 |
|------|------|
| 打開 Wi-Fi 並設定 | `meshtastic --set wifi.enabled true`<br>`meshtastic --set wifi.ssid "YourSSID"`<br>`meshtastic --set wifi.pass "YourPassword"` |
| 打開 MQTT 並設定伺服器 | `meshtastic --set mqtt.enabled true`<br>`meshtastic --set mqtt.broker_host "mqtt.meshtastic.org"` |

---

## 無線電參數（Radio Settings）

| 功能 | 指令 |
|------|------|
| 設定頻率（Hz） | `meshtastic --set radio.frequency 923000000` |
| 設定擴展因子（SF） | `meshtastic --set radio.spreadingFactor 12` |
| 設定頻寬（Hz） | `meshtastic --set radio.bandwidth 125000` |
| 設定發射功率（dBm） | `meshtastic --set radio.tx_power 20` |

---

## 固定位置（無 GPS 時使用）

| 功能 | 指令 |
|------|------|
| 使用固定位置 | `meshtastic --set fixed_position.enabled true` |
| 設定座標（台北為例） | `meshtastic --set fixed_position.lat 25.0418`<br>`meshtastic --set fixed_position.lon 121.5463` |
| 設定高度（公尺） | `meshtastic --set fixed_position.alt 10` |

---

## 訊息傳送

| 功能 | 指令 |
|------|------|
| 廣播一則訊息 | `meshtastic --sendtext "Hello Mesh!"` |
| 傳送給特定節點 | `meshtastic --dest <node_id> --sendtext "Private message"` |

---

## 韌體更新與重置

| 功能 | 指令 |
|------|------|
| 更新韌體 | `meshtastic --flash` |
| 重置所有設定 | `meshtastic --set factory_reset true` |

---

## 其他說明

| 功能 | 指令 |
|------|------|
| 查看所有設定項目 | `meshtastic --get` |
| CLI 指令說明 | `meshtastic --help` |

---
# Ref.
## g0v
[20231104 DigiResiTh0n 第零次數位韌性松](https://g0v.hackmd.io/oyNRfe4lTuaZ5RbcPSS7TQ)
[台灣鏈網 Meshtastic](https://g0v.hackmd.io/ZGuA7fUZQi-fbD06EenmGQ)
[[懶人包] 寫給對於還不熟悉 Meshtastic 的朋友](https://g0v.hackmd.io/V8ozO9RQS4ieWC1th3fleg)
[數位韌性情境分級](https://g0v.hackmd.io/SYTBWVohTyuCgPGUqfAl9g)
[Meshtastic / DigiResiThon](https://g0v.hackmd.io/0bR8-LvHRMaNaR97YaXpnQ)
[Meshtastic Taiwan](https://hackmd.io/@fL8pq60EQsG3RplVzWfGWA/S1m_x-AOA/%2FUAmGpkIzQy-Fc5xKmcyBtQ)
[Meshtastic docs](https://meshtastic.org/docs/introduction/)
https://hackmd.io/@fL8pq60EQsG3RplVzWfGWA/S1m_x-AOA

https://freebsdfoundation.org/our-work/journal/browser-based-edition/networking-10th-anniversary/batman-the-better-approach-to-mobile-ad-hoc-networks/

https://www.researchpublish.com/upload/book/Mobile%20Ad-Hoc%20Networks%20Its%20Advantages%20and%20Challenges-1736.pdf