LoRaWAN: Mạng cảm biến tầm xa

Nếu bạn đang dựng mạng LoRaWAN đầu tiên, mình khuyên giữ node và payload thật nhỏ cho đến khi đường truyền đã ổn định.

Lần đầu thử LoRaWAN, mình cũng bị hấp dẫn bởi con số “vài kilômét”. Nhưng đem node ra sau hai bức tường, đặt ăng-ten sát pin rồi gửi JSON mỗi 30 giây thì kết quả lại chẳng giống quảng cáo chút nào. Sau vài lần đi bộ quanh khu thử nghiệm để xem packet có về hay không, mình nhận ra phần khó không nằm ở việc làm radio phát được. Nó nằm ở vị trí gateway, ngân sách airtime, cách node ngủ và cách hệ thống sống tiếp khi mất một gói tin.

Bài này là cấu hình mình sẽ dùng cho một mạng nhỏ khoảng 5–50 cảm biến nhiệt độ, độ ẩm, mực nước hoặc trạng thái máy ở trang trại, nhà kho hay khuôn viên. Mục tiêu là dữ liệu mỗi vài phút một lần, pin dùng lâu và không cần SIM cho từng node. Đây không phải là lựa chọn cho camera, âm thanh, điều khiển theo thời gian thực hay thiết bị cần nhận lệnh liên tục.

Phân biệt LoRa và LoRaWAN trước

LoRa là lớp radio dùng để điều chế chirp spread spectrum (CSS - là một kỹ thuật điều chế sóng vô tuyến). LoRaWAN là giao thức mạng phía trên: quy định node tham gia mạng, mã hóa, frame counter, cửa sổ nhận, data rate và cách gateway chuyển packet về network server.

Hai board LoRa gửi chuỗi trực tiếp cho nhau có thể là một thử nghiệm hợp lý, nhưng chưa phải là LoRaWAN. Trong LoRaWAN, node cũng không chọn một gateway cố định và các node không chuyển tiếp packet cho nhau. Mạng có dạng star-of-stars: mọi gateway nghe được uplink đều chuyển bản sao về server; server loại bỏ packet trùng và giữ lại một sự kiện cho ứng dụng.

Node không gắn với một gateway cố định. Mọi gateway nghe được uplink đều chuyển packet về network server để loại trùng và đưa dữ liệu sang ứng dụng.

sensor nodes --LoRa--> one or more gateways
                            |
                    Ethernet / 4G / Wi-Fi
                            |
                 ChirpStack network server
                            |
                         MQTT
                            |
                  database / dashboard / alert

Gateway gần giống một “cầu nối radio sang IP” hơn là nơi chạy logic cảm biến. Decoder, lưu dữ liệu và cảnh báo nên nằm ở application server. Cách tách này cho phép thêm gateway để tăng vùng phủ mà không phải nạp lại firmware cho từng node.

Một bộ MVP vừa đủ để học

Khối	Lựa chọn thực tế
Node	MCU tiết kiệm điện + radio SX1262 hoặc module STM32WL
Cảm biến mẫu	BME280, công tắc phao, công tắc cửa hoặc đầu dò 4–20 mA qua mạch phù hợp
Nguồn	2 pin AA lithium hoặc Li-SOCl₂ có mạch bảo vệ phù hợp
Gateway	Gateway LoRaWAN đa kênh dùng concentrator SX1302/SX1303
Network server	ChirpStack chạy local bằng Docker
Dữ liệu	MQTT sang Node-RED, Home Assistant hoặc database riêng

Đừng dùng một board LoRa đơn kênh để giả làm gateway rồi đánh giá độ ổn định của cả hệ thống. Gateway LoRaWAN thật nghe nhiều kênh và nhiều spreading factor đồng thời. Với pilot nhỏ, một gateway đa kênh đặt đúng chỗ đáng giá hơn nhiều node phát công suất cao.

Mình thường bắt đầu bằng thiết bị Class A. Sau mỗi uplink, node mở hai cửa sổ nhận ngắn rồi ngủ; đây là class tiết kiệm pin nhất và phù hợp với cảm biến. Class C nghe gần như liên tục nên hợp với thiết bị có nguồn cố định. Class B thêm các cửa sổ nhận theo lịch, nhưng làm phiên bản đầu phức tạp hơn mà phần lớn cảm biến chưa cần.

Chọn đúng vùng tần số trước khi cấp nguồn radio

Frequency plan không phải là một tùy chọn có thể chọn theo loại ăng-ten đang có sẵn. Nó quyết định kênh, data rate, công suất, dwell time và giới hạn phát theo quy định của từng nơi. Node, gateway và network server phải dùng cùng regional parameters.

Theo tài liệu Regional Parameters của LoRa Alliance, Việt Nam thuộc biến thể AS923-2, dịch frequency plan AS923 gốc xuống 1,8 MHz. Trước khi phát, mình vẫn kiểm tra lại ba nơi: quy định vô tuyến hiện hành, plan mà nhà cung cấp gateway/network hỗ trợ và đúng biến thể được build trong firmware. Một node join mãi không được, đôi khi chỉ vì gateway chạy AS923-1 còn firmware chạy AS923-2.

Không nên copy cấu hình EU868 hoặc US915 từ một tutorial rồi chỉ đổi tên biến. Khác biệt, regional plan còn ảnh hưởng đến channel mask và kích thước payload theo data rate, không chỉ riêng tần số trung tâm.

Firmware node: đo nhanh, gửi gọn, ngủ lâu

Flow của node đầu tiên nên rất chán — và đó là điều tốt:

wake -> read sensor -> validate -> encode binary -> uplink -> open RX1/RX2 -> save state -> sleep

Mình dùng OTAA thay cho ABP để tạo session keys khi join. AppKey hoặc root keys không được đưa lên Git, in ra log hay dùng chung cho cả lô thiết bị. Sau khi join thành công, node nên lưu session context và frame counters ở vùng nhớ bền phù hợp; join lại sau mỗi lần thức vừa tốn pin vừa tạo thêm airtime.

Dòng deep sleep chỉ là một phần. Mình đo cả lúc sensor thức, radio join, uplink, mở RX1/RX2 và khi node không tìm thấy gateway.

Trên bàn thử, mình đo cả chu kỳ chứ không chỉ dòng deep sleep: sensor khởi động, radio join, uplink, hai cửa sổ RX và tình huống gateway mất kết nối. Một node ngủ ở vài microamp nhưng cứ join lại vài phút một lần vẫn có thể hết pin rất nhanh.

ADR hữu ích cho node cố định. Network server quan sát chất lượng của nhiều uplink rồi đề xuất data rate và công suất hợp lý, giúp giảm airtime khi link tốt. Với node di chuyển hoặc chất lượng sóng thay đổi nhanh, mình thận trọng hơn và kiểm tra thực tế thay vì mặc định bật ADR cho mọi thiết bị.

Payload 9 byte thường tốt hơn một chuỗi JSON

LoRaWAN là mạng băng thông thấp. Mình không gửi { "temperature": 27.35 } qua radio; server có thể tạo JSON sau khi decode. Một payload nhỏ cho cảm biến môi trường có thể là:

Byte	Dữ liệu	Kiểu
0	Phiên bản protocol	uint8
1–2	Sequence	uint16
3–4	Nhiệt độ × 100	int16
5	Độ ẩm × 2	uint8
6–7	Điện áp pin, mV	uint16
8	Cờ lỗi/cảnh báo	bit field

uint8_t payload[9];
payload[0] = 1;
payload[1] = sequence >> 8;
payload[2] = sequence & 0xff;
payload[3] = temperatureX100 >> 8;
payload[4] = temperatureX100 & 0xff;
payload[5] = humidityX2;
payload[6] = batteryMv >> 8;
payload[7] = batteryMv & 0xff;
payload[8] = flags;

Version giúp decoder cũ từ chối format không hiểu. Sequence cho mình thấy packet bị bỏ qua hoặc gửi lặp. Byte order, scale, đơn vị và giá trị lỗi phải được ghi cùng source decoder; đừng phụ thuộc vào layout của một struct C rồi hy vọng server hiểu giống compiler.

Đừng xác nhận mọi uplink

Mất một mẫu nhiệt độ thường không nguy hiểm vì vài phút sau sẽ có mẫu mới. Mình dùng unconfirmed uplink cho telemetry định kỳ, kèm sequence và timestamp ở server. Confirmed uplink chỉ dành cho sự kiện thật sự cần biết network đã nhận, và vẫn phải giới hạn retry.

Downlink còn quý hơn uplink: gateway phải phát thay vì nghe, còn node Class A chỉ nhận sau khi vừa gửi. Vì vậy, mình không thiết kế LoRaWAN như một terminal tương tác. Cấu hình ngưỡng hoặc chu kỳ đo có thể xếp hàng và áp dụng ở lần uplink kế tiếp; một lệnh khẩn cấp cần phản hồi tức thời nên dùng đường truyền khác.

Một chiến lược dễ sống cho cảm biến chậm là:

• Lấy mẫu nội bộ thường xuyên hơn nhưng chỉ gửi min/avg/max mỗi 5–15 phút.
• Gửi sớm khi trạng thái đổi, ví dụ: phao nước chuyển từ đầy sang cạn.
• Thêm heartbeat để biết node còn sống ngay cả khi giá trị không đổi.
• Nếu uplink thất bại, giữ bản tóm tắt gần nhất; không tạo hàng đợi vô hạn trong flash.

Vị trí gateway quan trọng hơn công suất phát

Tầm xa chỉ xuất hiện khi link budget và Fresnel zone hợp lý. Mình đặt gateway cao, thoáng, tránh nằm sau mái tôn, bồn nước, tủ điện hoặc sát một bó cáp nguồn. Dây coax càng dài càng mất tín hiệu, nên thường đặt gateway gần ăng-ten rồi kéo Ethernet/PoE về sẽ hợp lý hơn là kéo RF cable dài.

Đặt gateway cao và thoáng thường hiệu quả hơn tăng công suất node. Khảo sát vùng phủ nên ghi lại packet delivery rate, SNR và data rate ở đúng vị trí lắp thật.

Với gateway ngoài trời, mình kiểm tra hộp chống nước, cable gland hướng xuống, drip loop, chống sét/tiếp địa theo điều kiện công trình và không để đầu RF hở. Tuyệt đối không bật transmitter khi chưa gắn ăng-ten đúng dải tần.

Để khảo sát vùng phủ, mình mang một node test phát payload có sequence theo chu kỳ an toàn, đi qua các điểm dự kiến lắp cảm biến rồi lưu:

• Tỷ lệ packet nhận được, không chỉ RSSI của một packet đẹp nhất.
• SNR, data rate/spreading factor và gateway nào đã nghe được.
• Kết quả khi cửa kho đóng, trời mưa hoặc xe tải đỗ ở vị trí thường ngày.
• Biên dự phòng: link vừa đủ hôm nay thường sẽ không đủ cho một deployment lâu dài.

RSSI thấp không tự động là lỗi nếu SNR vẫn đủ để giải điều chế, nhưng packet delivery rate mới là thứ trả lời hệ thống có dùng được hay không. Mình ưu tiên thêm gateway hoặc đổi vị trí ăng-ten trước khi ép mọi node sang spreading factor cao, vì airtime dài làm giảm dung lượng toàn mạng.

Checklist trước khi lắp hàng loạt

• Node, gateway và server dùng đúng regional plan; tại Việt Nam, kiểm tra đúng AS923-2 và quy định hiện hành.
• OTAA keys là duy nhất cho từng thiết bị và không nằm trong repository.
• Session/frame counter sống qua reset hoặc có chiến lược rejoin rõ ràng.
• Payload có version, sequence, đơn vị và decoder được test bằng vector cố định.
• Unconfirmed uplink là mặc định; confirmed message và downlink có ngân sách riêng.
• Đo dòng qua một chu kỳ hoàn chỉnh, kể cả lúc mất gateway.
• Test anten khi hộp đã đóng và ở đúng vị trí lắp thật.
• Theo dõi packet delivery rate nhiều ngày trước khi kết luận về vùng phủ.
• Cảnh báo pin yếu, node im lặng và gateway mất backhaul.
• Giữ một node “golden sample” để so sánh khi firmware hoặc hạ tầng thay đổi.

Với mình, LoRaWAN đáng dùng khi mỗi node chỉ có vài byte quan trọng nhưng nằm quá xa Wi‑Fi và cần chạy lâu bằng pin. Một deployment tốt không phải là deployment khoe được khoảng cách xa nhất. Nó là mạng vẫn nhận đủ dữ liệu vào ngày mưa, biết node nào đã im lặng và không phải thay pin chỉ vì firmware nói quá nhiều.

Tài liệu tham khảo

• ChirpStack — open-source LoRaWAN Network Server
• RadioLib — LoRaWAN support and starter notes
• MCCI Arduino LoRaWAN — OTAA BME280 sensor example
• Zephyr LoRaWAN Class A sample
• LoRaWAN network architecture — The Things Network
• LoRaWAN limitations and airtime guidance — The Things Network
• LoRa Alliance Regional Parameters — AS923 variants