運用 lora 技術實現 iot...

運用 LoRa 技術實現 IoT 平台之開發

Development of LoRa-based IoT platform

研究生：吳柏穎

指導教授：黃克穠博士

義守大學

電子工程學系

碩士班碩士論文

A Thesis Submitted to

Department of Electronic Engineering

I-Shou University

in

Partial Fulfillment of the Requirements

for the Master degree

with a

Major in Electronic Engineering

June ,2017

Kaohsiung, Taiwan

Republic of China

中華民國一百零六年六月

i

運用 LoRa 技術實現 IoT 平台之開發

研究生：吳柏穎指導教授：黃克穠

義守大學電子工程研究所

摘要

依照目前 IoT 的進展看起來，隨著技術上的突破，這些連接末端的設備將會

在未來幾年內呈現指數性爆炸的成長，但目前所擁有的技術都不適合做為低成本

與距離遠的開發。本論文的目的在建置一套遠距離的 IoT 平台系統，其系統擁有

KM 級的傳輸距離、低功耗、低成本、多種硬體介面溝通和雲端平台連接，並透

過Tree-Star network架構達到網路不斷線安全設計，藉以改善目前技術上的缺陷。

本論文使用 Arduino IDE 作為開發工作，所採用的硬體包括 Arduino Nano、

LinkIt™ ONE 開發版、SX1278 晶片、BMP180 氣壓感測模組、DHT11 溫溼度感

測模組和光敏電阻。各個從端依照不同的傳輸方式將感測器資料回傳給主端並透

過 Internet 上傳至雲端，供使用者能在電腦與手機視窗觀看資料，當有其中的從

端損毀都會透過資料回傳並顯示在介面上，以便檢修與架設。

關鍵字：IoT 平台 ; LoRa ; MediaTek Cloud Sandbox

http://www.semtech.com/images/datasheet/sx1276_77_78_79.pdf

ii

Development of LoRa-based IoT platform

Student: Po-Ying Wu Advisor: Ke-Nung Huang

Department of Electronic Engineering

I-Shou University

ABSTRACT

According to the development of the IoT nowadays, by the technological

breakthroughs, the requirement and the function of these connected devices will

exponentially explode in the last few years. However, the techniques in the present

are not proper to be applied to develop the productions at a low cost and the remote

control. The purpose of this thesis is to build a remote control platform system which

includes the Km level transmission distance, a low power dissipation, a low cost,

many kinds of interface for communication hardware and connection of cloud

platform. As a safe design, it prevents the network being disconnected by using the

Tree-Star network structure. Therefore, those detects of the techniques in the present

can be improved well.

In this thesis, Arduino IDE is used to develop the system, by using the Arduino Nano,

LinkIt™ ONE microcontroller board, SX1278 chip, BMP180 barometric pressure

sensor, DHT11 temperature and humidity sensor and the photoresistor. The Master is

programmed to request, and then read the data of sensor which is sent in different

ways from the uniquely addressed Slave. Then the data will be uploaded to the cloud

on the Internet. Once the message is received, it can be viewed in the users‟ computer

or the cell phone monitor window. If any Slave is broken, it will show the details and

data on the interface for the convenience to check, fix, debug or build.

Key words : IoT plaftform ; LoRa ; MediaTek Cloud Sandbox

iii

致謝

時光流去，就讀碩士的這兩年時間即將結束得以完成論文，首先我要感謝我

的父母提供協助，使我能專注學習；感謝黃克穠老師提供不同的想法與解決方案

是我更加進步；也要感謝口詴委員任善隆教授以及李彥杰經理點出本論文的缺陷

與提供不同的系統架構思維，使我能用不同的角度看待系統，使得本論文更加完

善。

感謝實驗室中的學長，秉杰、駿翔、任皓、德銘、偉綸，在不知道如何起頭

時能給予觀念指導與屁話；也感謝實驗室中的所有同儕民先、柏孝、旺祺、嘉倫

共同參加比賽與實作專案開發，與學妹怜妤、馨葒的食物加持，促進實驗室的傳

承和銜接，也讓我了解自身的不足並加以努力。

最後感謝所有我身邊的人，在我求學期間的體諒與包容，讓我有機會達成目

標，在此獻上我的感激，也祝福所有幫助與關心我的人。

吳柏穎謹誌於

義守大學電子工程所

106年 6月

iv

目錄

摘要................................................................................................................................. i

ABSTRACT ................................................................................................................... ii

致謝.............................................................................................................................. iii

目錄............................................................................................................................... iv

圖目錄........................................................................................................................... vi

表目錄........................................................................................................................ viii

第一章緒論............................................................................................................ 1

1.1. 前言............................................................................................................ 1

1.2. 研究目的與動機........................................................................................ 2

第二章文獻回顧.................................................................................................... 7

2.1 現行物聯網架構........................................................................................ 7

2.2 Wi-Fi、ZigBee、BlueTooth 比較 ............................................................ 8

2.3 LPWAN 簡介 .......................................................................................... 10

2.4 LoRa 簡介 ................................................................................................ 13

第三章研究方法.................................................................................................. 21

3.1 現有架構-Star network 拓墣 ................................................................... 24

3.2 Tree-Star network 拓樸 ........................................................................... 26

3.3 封包規範.................................................................................................. 31

3.3.1 建立網路的封包規範.................................................................. 31

3.3.2 傳輸資料的封包規範.................................................................. 32

第四章系統設計.................................................................................................. 38

4.1 系統架構.................................................................................................. 38

4.2 硬體架構.................................................................................................. 41

v

4.2.1 LinkIt™ ONE 開發版 ................................................................. 42

4.2.2 SX1278 ........................................................................................ 43

4.2.3 感測器.......................................................................................... 51

4.3 軟體架構.................................................................................................. 52

4.3.1 設計封包...................................................................................... 52

4.3.2 主端軟體流程.............................................................................. 57

4.3.3 樹狀從端軟體流程...................................................................... 60

4.3.4 星狀從端軟體流程...................................................................... 64

第五章實驗結果.................................................................................................. 66

5.1 硬體配置.................................................................................................. 66

5.2 實驗設計.................................................................................................. 68

5.2.1 佈點測詴...................................................................................... 68

5.2.2 錯誤檢知與圖表顯示測詴.......................................................... 70

第六章結論.......................................................................................................... 77

6.1 C-type LoRa 模組耗電性問題 ................................................................ 77

6.2 遠距離傳輸資料...................................................................................... 77

6.3 Tree-Star 架構可靠性與成本 ................................................................. 78

6.4 多樣化的硬體溝通方式.......................................................................... 78

6.5 雲端連接.................................................................................................. 78

6.6 應用場合.................................................................................................. 79

第七章、參考文獻...................................................................................................... 80

vi

圖目錄

圖 1-1、Explosion of connected possibility .................................................. 3

圖 1-2、物聯網設備成長趨勢 ...................................................................... 5

圖 2-1、Range vs. data rate for IoT connectivity technologies .................. 12

圖 2-2、Information rate and power consumption performance of wide area

connectivity protocols ............................................................................. 13

圖 2-3、LoRaWAN network layers .............................................................. 14

圖 2-4、LoRaWAN™ Network Architecture .............................................. 16

圖 2-5、LoRaWAN™ Device Classes ......................................................... 18

圖 3-1、Usual network topologies ................................................................ 22

圖 3-2、Star network ..................................................................................... 24

圖 3-3、Tree-Star network ............................................................................ 29

圖 3-4、Tree-Star network ............................................................................ 30

圖 4-1、系統架構圖 ...................................................................................... 40

圖 4-2、硬體架構圖(主端) ........................................................................... 41

圖 4-3、硬體架構圖(從端)........................................................................ 41

圖 4-4、MediaTek Cloud Sandbox ............................................................... 43

圖 4-5、Startup Process ................................................................................. 45

圖 4-6、Sequencer State Machine ................................................................ 46

圖 4-7、LoRa™ Modulation Transmission Sequence ................................ 49

圖 4-8、LoRa™ Receive Sequence .............................................................. 50

圖 4-9、流程碼順序展示圖 ......................................................................... 57

圖 4-10、主端流程圖 .................................................................................... 59

圖 4-11、樹狀從端流程圖 ........................................................................... 63

vii

圖 4-12、星狀從端流程圖 ........................................................................... 65

圖 5-1、系統實體圖 ...................................................................................... 66

圖 5-2、系統實體圖(主端) ........................................................................... 67

圖 5-3、系統實體圖(從端) ........................................................................... 68

圖 5-4、測詴地點 .......................................................................................... 69

圖 5-5、樹狀編碼圖 ...................................................................................... 71

圖 5-6、照度值圖 .......................................................................................... 72

圖 5-7、溫度(攝氏)圖 ................................................................................... 73

圖 5-8、濕度圖 .............................................................................................. 74

圖 5-9、大氣壓力圖 ...................................................................................... 75

圖 5-10、溫度(華氏)圖 ................................................................................. 76

viii

表目錄

表 1-1、THE INTERNET OF THINGS: FUTURE SCENARIOS .............. 2

表 2-1、物聯網網路技術整理 ..................................................................... 20

表 3-1、建立網路的封包規範 ..................................................................... 32

表 3-2、傳輸資料的封包規範-頭碼 ........................................................... 33

表 3-3、錯誤碼的封包規範 ......................................................................... 33

表 3-4、傳輸資料的封包規範-從端碼 ....................................................... 35

表 3-5、n 個從端表格 ................................................................................... 35

表 4-1、Power Consumption Specification ................................................. 44

表 4-2、LoRa™ Operating Mode Functionality .......................................... 44

表 4-3、表格資料 .......................................................................................... 53

表 4-4、從端損毀對照 .................................................................................. 55

表 4-5、流程碼順序對照 ............................................................................. 56

1

第一章緒論

1.1. 前言

物聯網(IoT)是一種藉由網際網路、傳統電信網等資訊的平台，將不同功能

並且獨立運作的物體實現物體互相溝通的互聯網路。這個概念的中心思想是將各

式各樣的事物與物體(例如 RFID 標籤、感測器和收發器等等)，透過其獨特的溝

通協議的方式將資料傳至微控制器與彼此終端的鄰居彼此做數據溝通，並且做出

運算與決策。[1][2]

因此，IoT 的概念在旨互聯網絡無處不在，並且使各式各樣的感測器、微控

器或是主動元件進行溝通協調。例如:家用電器、監視攝影機、顯示器和車輛等

等，IoT 將會促進一些應用程式被開發出來，並且也產生大量的數據資料來作為

分析使用，這些大量的資料又可以被應用在例如:家庭自動化、工業自動化、移

動式醫療、老年人遠端照護、智能能源管理、智能電網、汽車交通管理諸多方案

等等。[1]

然而，看似極具潛力的 IoT 卻在 2008 年被美國國家情報委員會 “Disruptive

Civil Technologies”一報告中列為六項之一對美國國力有潛在的影響[3]。

2

表 1-1、THE INTERNET OF THINGS: FUTURE SCENARIOS

上表為該報告中[3]所提出物聯網在模擬未來世界不同發展的場景，在這些場

景中都有提出未來民間與政府的走向分別帶來什麼優點，但是任何東西都是雙面

刃，有優點的產生就有其缺點的發生。上述四項場景的缺點都不約而同地提出了

一些相同的缺點例如下述幾點:

1.物聯網的普及化及網際網路化將導致被置入惡意軟體及駭客攻擊的機會大

幅提升。

2.隨著革命性的成本降低，大規模的企業轉型和政策制定的趨勢將會是隱憂。

3.工業自動化將導致大量勞工失業與私人安全性的問題大量凸出，這將引發

經濟與社會問題。

4.無處不在的定位技術可能會引發軍事上的問題(恐怖分子)

1.2. 研究目的與動機

依照目前 IoT 的進展看起來，物聯網雖然還有很長一段路要走，但隨著時間

的流逝與技術上的突破得以解決，這些連接末端的設備與周邊應用程式等等將會

在未來幾年內呈現指數性爆炸的成長[4]。

3

圖 1-1、Explosion of connected possibility

4

根據 2016 年 12 月研究數據顯示[5]，在 2021 年，連接物聯網的設備，感測

器和微控制器的數量將達到 460 多億，從 2016 年將開始增加 200％，從這個角

度看在很大程度上降低了硬體的單位成本。以及在 2016-2021 年之間，工業和公

共服務業在此預測時間內將大幅提升，平均每年成長超過 24%。

再來我們依據愛立信這家公司在 2016年 6月的報告[6]中提出:以目前的市場

(2015)來說，手機還是為最多使用的連接設備，但這個情況預計將在 2018 年首

次被物聯網所超越，這當中包括連接的汽車、機器、電表、遠程觀測和消費性電

子產品。物聯網設備預計將以 2015 年至 2021 年的複合年增長率（CAGR）增長

22％。到 2021 年，共有約 280 億台相連設備，其中將近 140 億台設備與物聯網

相關。

5

圖 1-2、物聯網設備成長趨勢

6

最後，我們再根據思科在 2012 年 11 月提出的報告中[7]提出萬物聯網（IoE）

的概念，思科把萬物聯網定義成將人員、流程、數據和事物結合在一起，也就是

說，他將涵蓋住比物聯網還要更大的範圍，這再將影響範圍大大的擴增。其報告

中說明了在萬物聯網的架構下，超過 99%的事物未連接到網路，這個市場的開發

性趨近於零，可見其市場之龐大。

本論文的目的在建置一套 IoT 平台系統，其系統將擁有下列優點:

1.超遠距離(KM 級)之網路架構

2.低功耗、低成本、高效率的軟硬體設計

3.網路不斷線安全設計

4.提供多樣化的硬體介面溝通

5.連接雲端平台，供使用者能在電腦和手機觀測

根據本論文建置的網路架構所提出的優點，預期其架構將覆蓋龐大面積，其

應用場合則適合農漁牧場觀測、山區海洋氣象觀測、路燈自動化系統、智慧城市

等等。

7

第二章文獻回顧

本章節首先會介紹物聯網架構與其網路層所使用的溝通傳遞特性，包

含:Wi-Fi、ZigBee、BlueTooth 無線傳輸技術特性。並且說明分別使用上述無線

傳輸技術的工作原理，經由比較上述三者之間不同的優缺點來說明本論文使用

LoRa 無線傳輸技術之觀點。

2.1 現行物聯網架構

現行物聯網架構分為三層:應用層、網路層和感知層

a. 應用層:應用層在於負責統籌分析並加以處理回收的資料，透過演算

法運算直至產生我們所需要的資料為止。通常應用層多與 Big Data

分析技術、資料收發中心、伺服器、儲存等相關硬體設備有關連。例

如:智慧家庭、智慧交通、城市管理、城市安全、環境監控和農漁牧

場管控…等等。

b. 網路層:網路層在於負責傳遞資訊，將資料透過有線或無線的方式把

資訊接收或發出。通常網路層多與網際網路、區域網路、行動網路、

無線網路等相關硬體設備有關連。例如: LAN、2G/3G/4G、Wi-Fi、

ZigBee、BlueTooth 和 RFID 技術…等等。

c. 實體層:感知層在於負責感測周遭環境和收集資料。通常多與感知

器、監視器和儲存等相關硬體設備有關連。例如:IPCam、LightSensor、

溫度感測器、RFID 卡和讀取器…等等。

8

2.2 Wi-Fi、ZigBee、BlueTooth 比較

1. 拓撲:

看當下的物連網架構如何設計再決定，比如說若物連網架構為距離短和

空曠地點的話就可以使用 Wi-Fi 和 BlueTooth 這種 Star network 的網絡、

反之，若物連網架構為距離長和充滿障礙物地點的話，就需要 ZigBee 和

BlueTooth 這種支援網狀的網絡。

2. 頻段:

無線電波的頻段共有 915MHz、2.4GHz、5.8GHz 三種可供挑選，在挑

選之前我們必頇先了解甚麼是 ISM Band。ISM Band 的全名為: Industrial

Scientific Medical Band，中文亦即工業的(Industrial)、科學的(Scientific)和

醫學的(Medical)頻段，這是 International Telecommunication Union (ITU)(國

際電聯無線電)這個國際組織所定義的全球性無線電規範，他嚴格的將全

球分為三塊(Region 1、Region 2、Region 3)並定義出通用的無線電頻譜以

便統一。而定義 ISM 的用意則是規範各國挪出某一些頻段可供給工業、

科學和醫療單位使用，使用這些頻段不需要申請或是費用支出，只是需要

遵守無線電發射功率和不能干擾其他頻段即可。

以上三種頻段 915MHz、2.4GHz、5.8GHz 只有 915MHz 被規範在 Region

2(美洲)的區域內能使用，後者 2.4GHz、5.8GHz 則是全球通用。

然而目前最為普遍的 2.4GHz 則是根據 1947 年 ITU 第一次制定 ISM 頻段

時的文獻指出[9]當初美國要求各國都能挪出 2.45GHz 這個頻段給 ISM

https://en.wikipedia.org/wiki/International_Telecommunication_Union

9

Band使用，目的是為了新興的微波加熱技術以方便各國通用，所以 2.4GHz

這個頻段是開放最久的，頻段上充斥著各種技術交互使用(上述三者都包

含在內)，也就是說，這個頻段上已經非常壅圔，再加上家中充斥著 Wi-Fi、

BlueTooth、微波爐等等訊號干擾甚多，不適合我們作為 IoT 的通訊使用。

再來，2.4GHz 和 5.8GHz 本身的物理特性不適合傳遠距離，高頻段只適

合在需要高傳輸資料和短距離的應用場合上，頻段也比較容易被阻礙物吸

收。根據上述以頻段的角度看來，Wi-Fi 和 BlueTooth 非常適合用於高傳

輸資料和短距離的場合，但不適合應用在家中或戶外等高汙染的地點，然

而 ZigBee 就比較適合低傳輸資料和長距離的應用場合上。

3. 速率

速率的問題我們在上面頻段的部分已經討論過了，若是頻段越高，速率

也會增加，那麼就以 Wi-Fi、ZigBee、BlueTooth 三者討論，唯有 Wi-Fi

的頻段最高(5.8GHz)，而且以目前市面上最常買到的 Wi-Fi 分享器通常都

支援 802.11 a/b/n/g，其中又以 802.11n 的規範速度最快(248Mbps)[8]。

但是根據規範指出[10]，802.11ac 的規範已經可以在 160MHz 的頻寬下達

到 866.7Mbps 的速度(物理層)，更別說是將來在 802.11 家族的體系下還有

802.11ay 規範支援到 60GHz 的頻段[11]，速度會更加的高速。

就以上述的分析看起來，若是物聯網的架構需要大量資料的話選擇

Wi-Fi 是較好的方法，若是不在乎速度的話，三者都可以使用。

10

從上述分析我們可以得到 ZigBee、BlueTooth、Wi-Fi 這三種無線傳輸的基

本參數，也可以統計出三種的優缺點加以挑選，例如: Wi-Fi 擁有極高傳輸資料

量的優點但非常耗電、ZigBee 則是擁有網絡架構上的優勢，但是面臨傳輸資料

量極低的狀況，最後 BlueTooth 雖然擁有不錯的傳輸資料量和低耗電量等等優

點，但是其頻段應用在 2.4GHz 上，這個頻段容易與其他無線傳輸設備干擾並受

到汙染這個缺點。

2.3 LPWAN 簡介

根據 WiKi[12]上面的定義來說，LPWAN（Low-Power Wide-Area Network，

低功率廣域網路）也稱為 LPN（Low-Power Network，低功率網路）是一種應用

在物聯網上的一種架構，此架構可以實現低傳輸量和遠距離的無線網路。為了達

到低功耗的設計理念，通常 LPWAN 網路架構下的技術基本上為 Sub-GHz 的頻

段，藉此達到 LPWAN 所需要的定義。

再根據 LoRa® Alliance 這個組織所提出的白皮書[13]，當中提出 LPWAN 擁

有的主要特點:

1.電池壽命長（通常超過 10 年，同時支援智慧量測應用）。

2.廣域連接特性，允許開箱即用連接的解決方案。

3.低成本晶片和網路。

4.資料的吞吐量受限。

換句話說，LPWAN 擁有極低的功耗表現、極長的距離傳輸特性(通常為 km

等級)以及價格低廉等等特性，但是缺乏資料乘載量的問題。事實上，LPWAN

https://zh.wikipedia.org/wiki/%E7%89%A9%E8%81%94%E7%BD%91

https://zh.wikipedia.org/wiki/%E7%84%A1%E7%B7%9A%E7%B6%B2%E8%B7%AF

11

的技術剛好補償了現有的蜂巢狀移動式網路短距離技術的不足，縮短了傳輸距離

代表著可以以較低的設備成本實現廣域網路，並且擁有更佳的耗電特性，這些特

性解釋了 LPWAN 技術的潛力。因為目前的物聯網市場上主流如 ZigBee、

BlueTooth、Wi-Fi、RFID、2G/3G/4G 行動網路等等的傳輸距離和耗電量都不如

LPWAN 架構裡所要求的，更遑論物聯網的終端元件通常不需要傳輸大量的資

料。

也因為 LPWAN 架構需求是從物聯網發展需求而來，所以 LPWAN 的發展

比物聯網來的晚，在 2013 年年初以前，LPWAN 一詞還不存在，然而現在 LPWAN

變成物聯網發展裡最快的其中一個。物聯網市場證明了 LPWAN 技術難以置信的

潛力。Machina Research[13]預測到 2024 年將有 36 億 LPWAN 連接，從今天的

基數發展到數十億的數字。

根據LoRa® Alliance提出的白皮書[14]裡目前物聯網技術其中的資料傳輸量

和傳輸距離評比(下圖 2-1)分成兩大類，一種是工作於非授權頻段的 LoRa、SigFox

等技術；另一類則是在授權頻段下的 EC-GSM、LTE Cat-m、NB-IoT 等技術。

12

圖 2-1、Range vs. data rate for IoT connectivity technologies

在上圖 2-1 可以看見非授權頻段裡 ZigBee、BlueTooth 和 Wi-Fi 技術的傳輸

距離最短，LoRa 和 UNB 技術距離最遠(在這裡我們只談論非授權頻段，不去對

授權頻段的技術詳加說明)。再依據下圖 2-2[14]各技術的耗電性和傳輸資料量得

出，UNB 技術擁有最省電的性能表現，然而 LoRa 技術則擁有低功耗和傳輸資料

量中等兩項指標性的特性。

13

圖 2-2、Information rate and power consumption performance of wide area connectivity protocols

2.4 LoRa 簡介

LoRa 無線電調製技術一開始由 Cycleo 這家公司在 2010 年發明，這家公司

是為無線世界提供遠程機對機通信的創新無線解決方案的供應商[15]。在 2012

年 Cycleo 被 Semtech(半導體公司)收購並增加 MAC 層，以規範和擴展 LoRa

物理通信層到物聯網上[16]。該 MAC 層被稱為 LoRaWAN™（LoRa for Wide Area

Networks）規範，目前該規範則是由 LoRa® Alliance 支援並開放。

LoRa® 的全名為 Long Rang，它是用於創建遠距離通訊網路的物理層或無線

調製技術。許多傳統無線系統調製使用（FSK）技術作為物理層，因為它是非常

有效的實現低功耗的調製。 LoRa® 基於 chirp spread spectrum 調製，其保持與 FSK

技術調製相同的低功率特性但明顯增加通訊範圍(靈敏度增加)。[17]。

14

圖 2-3、LoRaWAN network layers

上圖 2-3 為 LoRa® Alliance 規範文件裡[17]LoRaWAN™協議的系統架構

圖，其協議規範了 MAC 層協議、耗電等級、LoRa® Modulation 技術和全球不

同區域的 ISM Bands。

下圖 2-4 則是說明 LoRaWAN™的網路架構[17]，可以看出 LoRaWAN™通

常使用”Star”的拓樸，在終端的節點的訊息會被上傳至 Gateway 中繼訊息設備，

再經由有線網路或是其他網路將資料上傳至雲端，供應給後端應用伺服器或是使

用者使用。雖然 Star network 的網路架構會因為 Gateway 中繼訊息設備的建置決

定終端設備的範圍如蜂巢網路，但是 Star network 的拓樸可以有效地排除可能來

自其他的資料接收和轉發，藉以提升電池壽命。也就是說，終端設備不需要挑選

使用哪個 Gateway 收發資料，而是終端設備會向周邊所有的 Gateway 發送資料，

然後由Gateway彼此互相溝通決定由哪個Gateway傳送資料給伺服器和向終端設

15

備送出 ACK 訊號。這樣做的原因不外乎就是省電，把複雜和耗電的事情交給中

繼站處理，這種 Thin client, rich server 是常見的物連網架構, 就是為了讓這些吃

電池的終端設備可以更省電。

16

圖 2-4、LoRaWAN™ Network Architecture

17

接著在我們討論 LoRaWAN™協議下 Class A、B、C 之前，必頇先了解

LoRaWAN™內部網路傳遞資料的協議。首先，LoRaWAN™所使用的是非同步

傳輸 (asynchronous communication)技術的其中之一，ALOHA System。根據 WiKi

的定義[18]，Pure ALOHA 協議定義以下四點:

1.當終端設備有資料需要傳送時，他會立即發送資料。

2.接收點收到資料後，會回傳 ACK 訊號給終端設備。

3.如果接收資料有錯誤，則會回傳 NACK 訊號給終端設備。

4.當網絡上的兩個終端設備(含以上)同時傳輸資料的時候，會發生衝

突，這種情況下，兩個點各自等待一段隨機長度的時間後，再次嘗詴傳送。

也就是說，今天終端設備準備完資料後不用等待直接向周圍發送資料，好處

是不需要等待排程、也不需要時間同步(time sync)等等複雜的技術溝通，直接發

送資料即可。然而壞處則是當兩筆或兩筆以上的資料在同個時間出現在同一個頻

段裡，會發生衝突的現象。變成終端設備必頇彼此等待某一隨機時間再次發送以

避免衝突，雖然還是會有微小機率再一次出現衝突的現象。但是為了滿足

LoRaWAN™架構底下含有大量的終端設備(百萬級)，LoRaWAN™協議則定義了

Class A、B、C 三種不同溝通的協議來解決上述的問題。

下圖 2-5[17]為 LoRaWAN™協議定義了 Class A、B、C 三種不同的溝通協議。

18

圖 2-5、LoRaWAN™ Device Classes

1.雙向終端設備（A 類）：

每個 A 類終端設備都允許雙向溝通(downlink、uplink)，並且每個

終端設備一個上傳鏈路(uplink)的發射窗口帶有兩個下載鏈路(downlink)

的接收窗口。上傳鏈路由各個終端設備自己溝通為基礎，以隨機為時間

基礎的小變化(ALOHA 型協議)上傳。然而 A 類終端設備為最低功率，

適用於僅需要上傳鏈路溝通的應用終端設備系統。為了省電，下載鏈路

只會在上傳鏈路溝通完後開通一小段時間。

2.具有排程接收槽的雙向終端設備（B 類）：

除了 A 類隨機接收窗口，B 類設備將在預定的時間打開額外的接

收口。

這個接收窗口的功能使終端設備接收來自 Gateway 的時間同步信

號。這項功能允許 Gateway 知道哪個終端設備正在聆聽。

3.具有最大接收槽的雙向終端設備（C 類）：

C 類終端設備幾乎連續打開他的接收通道，只在發送時關閉。

19

由上述分析可以得知，A 類終端設備最為省電，但是犧牲上傳資料的穩定性

和增加下載鏈路的延遲時間，尤其當架構越來越龐大使用 A 類當終端設備時，

其下載鏈路延遲時間將會以非線性的方式成長，形成不可預期的資料堵圔。相反

的，C 類的終端設備因為接收通道處於一直開通的狀況，使得此類的終端設備會

比其他類別耗電，但換來的是穩定性和隨時接收等特性，這將使 C 類終端設備

擁有時間上與穩定性的優勢。B 類則是介於這兩者之間，跟 A 類比起來 B 類擁

有時間同步(time sync)的特性，此特性能有效避免資料堵圔的問題，但是相對的

B 類比 A 類耗電，然而跟 C 類比起來 B 類不用一直開啟接收的模式，B 類採用

另外對外的窗口接收 Gateway 的時間同步信號，此特性可以帶來比 C 類更省電

的特性，相對的則是要比 C 類付出更多時間等待。

20

小節:

以上述分析和統計的資料，我們可以以架構物聯網的角度分別對其優缺

點做出表格(表 2-1)比較:

表 2-1、物聯網網路技術整理

ZigBee BlueTooth Wi-Fi LoRa

規範 IEEE 802.15.4 BT3.0前 IEEE 802.15.1

BT4.0後 SIG

IEEE 802.11

認證機構 ZigBee Alliance BlueTooth SIG Wi-Fi Alliance LoRa Alliance

拓撲網狀、星狀、樹狀網狀、星狀星狀星狀

頻段 915M、2.4G 2.4G 2.4G、5.8G、60G Sub-GHz

速率 250kbps 24Mbps(BT5.0) 866Mbps(802.11ac) 300kbps

距離 300m 300m(BT5.0) 300m(802.11n) 15km

功耗 low mid high very low

節點 216

8 32 百萬級

資料來源:Wi-Fi Alliance、ZigBee Alliance、BlueTooth SIG、[8]、WiKi、Institute

of Electrical and Electronics Engineers. IEEE Std

21

第三章研究方法

以前面的分析看來，建構物聯網必頇先了解自身的需求(傳輸資料量、距離、

耗電性等)，方能挑選所需要的物聯網技術。本論文則訴求低功耗、遠距離等特

性，非常適合應用在 LPWAN 架構，LPWAN 架構又分成工作於非授權頻段的

LoRa、SigFox 等技術；另一類則是在授權頻段下的 EC-GSM、LTE Cat-m、NB-IoT

等技術，經過作者的挑選後，以成本考量作者選擇了非授權頻段的 LoRa、SigFox

等技術(非授權頻段不用付費或是申請就可以使用，只需要注意無線電波的發射

功率要在規定的範圍以內，不得蓋頻即可)，再來本論文建構的系統裡，使用 UNB

的 SigFox 等技術因為頻寬的關係，通道數量和資料傳輸量明顯不足，以此本論

文選擇 LoRa 技術為基礎開發。

根據 Orange 公司所給的資料[16]，如圖 3-1 所示一般的網路拓樸可以分成三

大類:Home network、Meshed network 和 Star network 三種。但因為省電與架構的

問題，LPWAN 架構通常都會被建置成 Star network 這種拓樸。

22

圖 3-1、Usual network topologies

23

不管是從 LoRa® Alliance 組織到 Orange 這家法國龍頭電信公司都一致推薦

LoRaWAN™使用 Star network 這種架構，雖然此種架構管理上方便，但是就以

建置像 Gateway 這種中繼站這方面來看，若是所需的範圍較大，成本將會大幅提

升。因此，本論文提出一個中繼站(包含雲端)加上數個終端設備的 Tree-Star 架

構，此架構既能保留 Star network 的廣域性接收優點，又能彌補 Star network 架

構下擴充檢測範圍需要增加中繼站的這個成本問題。同時 Tree-Star 架構的某些

條件下可以模擬 Meshed network 的尋求最佳節點模式，以及結構簡單等等特性，

這將在下面進行更深入的討論。

24

3.1 現有架構-Star network 拓墣

圖 3-2、Star network

25

上圖 3-2 描述了一個基於 Star network 拓墣下建置的 LoRaWAN™，圖中包

含一個雲端、四個主端、四個虛線的圓圈(LoRa 範圍)和數個從端(資料收集)，粗

線(深藍)代表雲端與主端的連線(透過有線/無線網路)，細線(淺紫)則是代表主端

和從端間的連線(透過 LoRa 溝通)。其工作原理為主端(Master 或 Getway)負責接

收來自從端的資料，但由於此架構講求省電性，所以將所有從端建置成 A 或 B

類終端設備(Class A 只負責發送，資料重疊時隨機延遲後再度發送資料；而 B 類

則是知道何時發送而不會重疊)，但這麼一來若當從端數量太多時，A 類終端設

備可能會導致資料無法使中繼站接收到(因為有很高的機率發生資料重疊)的機

率增高，為因應這種從端數量狀況的發生(因為 LoRa 的中繼站節點被設計成百萬

級)，所以將 LoRa 的中繼站的功能強大化，以前可能需要在從端處理的事情，現

在變成從端只負責發送資料(或者含有聆聽功能)，其他功能則交給中繼站處置。

以上圖 3-2 來說，從端(Slave)只需要負責將資料打包完後上傳即可，不需要

留意時間同步或是資料重疊等等問題，而主端則是在抓取範圍內(藍色虛線圓圈)

的所有從端資料，然後由主端負責上傳至雲端。但是這會發生兩個問題，敞若是

發生一個從端被兩個主端接收到的狀況發生該怎麼處理，又或是同時三個主端、

四個主端又會如何? (圖中的中心點正好說明此狀況)，這種狀況該一起上傳?資料

傳遞會不會互相衝突?或是這該由哪個主端上傳?等等問題浮現…；第二個問題是

若終端設備傳送資料發生資料重疊時該如何處理，而這些問題正是 Star network

架構下需要技術的地方。

26

目前 Star network 採取的方法為:

1.若當從端點剛好位於範圍重疊的位置下時，數個主端(或是中繼站)

接收到資料後主端彼此會進行溝通，將重疊的從端資料作分隔，規範哪

個從端的資料由誰發送。

2.通常主端會開放許多通道(頻寬)供 A 類的終端設備重疊傳送使用，而

B 類的終端設備本身支援時間同步的功能，主端會發射時間訊號給範圍

內的設備同步。也就是說，若是範圍內的從端設備不多的話，以省電為

目的可以使用 A 類的終端設備；若是範圍內的從端過多，而且其資料

也不得延誤接收的話，會建議使用者採用 B 類的終端設備以保持時間

同步，同時也可以省電。

以 Star network 的架構建置，將會遇到建置費用高昂(主端數量多寡)，而且

會以頇檢測的地點越廣，成本越可觀(主端以等比例上升)。再加上主端與主端之

間的協定通訊，則是需要大量的演算法支援，這則無形造成了軟體成本的問題。

有鑑於此，本論文設計了一個架構:Tree-Star network，此架構能有效的減少

主端的設置數目(至多一個)和在特定狀況下可以模擬 Meshed network 的尋求最

佳節點模式，並且流程簡易擴充之設計等等優點…。

3.2 Tree-Star network 拓樸

根據下圖 3-3、3-4 所展示的比上圖 3-2 的 Star network 多出了一個設

備:Slave(checkpointer and data collecter)(綠色五星狀)，此設備在本論文裡的角色

被定義為:介於主端和從端之間的溝通者。

27

首先，在正式讓系統運作之前，我們需要先決定系統的大小與建置的從端數

目多寡，因此本論文設計一套流程使建置系統可簡易實現與擴充。

系統一開始必頇將主端(橙色四星狀)與所需要建置的從端(綠色五星狀、淺藍

五角形)放置在一起並將其中一台上電，此時主端上面會有一顯示介面通知使用

者現在的狀況，然後主端會發送表格收尋周遭是哪個從端(綠色五星狀、淺藍五

角形)，此時主端會跟從端(綠色五星狀、淺藍五角形)要求其擁有的 ID 碼並通知

使用者收尋成功，收尋成功後主端介面會詢問使用者現在這個從端(綠色五星

狀、淺藍五角形)要將它轉變成系統下的哪一個位置(綠色五星狀或是淺藍五角

形)，使用者必頇在介面上輸入編號(從端幾之幾)後主端將會透過表格傳輸給收尋

成功從端並改寫從端裡面的編號，成功後介面將通知使用者配對完成可以將配對

成功的從端關機並且架設到所需要的位置，若要建置新或是加入的話則重新操作

此流程即可。

等待架設完畢後所有的從端都會知道自己是處在系統上的哪個位置，此時主

端也知道連接了多少的從端，此時主端內部則會檢查目前所擁有多少的從端(包

含綠色五星狀和淺藍五角形)，根據此項數目，主端將會運算所需要的表格數目

後將表格依樹狀道路一路依序傳送下去給從端(綠色五星狀)，再由個別的從端(綠

色五星狀)分別向從端(淺藍五角形)索取資料，依序將自身的資料與從端(淺藍五

角形)的資料填入表格內後傳送出去。

傳送出去的資料表格為了能讓下一個從端(綠色五星狀)辨識此筆表格現在

目前的位置以及下一步的動向，作者在其表格內定義了多個檢測密碼，其檢測密

28

碼將能體現目前表格的動向為何。除了檢測密碼外，作者以干擾性防護定義了多

組密碼以防止外部資料的接收導致系統錯誤性的作動。

最後則是穩定性的問題，按照目前樹狀道路的流程下來，若是隨便一個從端

(綠色五星狀)損毀時，將會造成整體系統當機(資料發不出去或是收不回來)的現

象發生，為了阻止這種現象的發生，本論文設計了一個流程確保系統在一個從端

(綠色五星狀)或是連續兩個以上(含)的從端(綠色五星狀)損毀時，系統還能正常工

作並且將損毀的從端(綠色五星狀)編號上傳至雲端已通知使用者。其流程的關鍵

之處在於將從端(綠色五星狀)LoRa 的範圍重疊，可以看見圖 3-3、圖 3-4 中不論

是主端或是從端(綠色五星狀)的範圍，其半徑(樹狀道路)內都含有至少兩個從端

(綠色五星狀)，其用意在於當其中一個從端(綠色五星狀)損毀時，在範圍內的另

一個從端(綠色五星狀)除了將會代替損毀的從端(綠色五星狀)工作之外，其從端

(綠色五星狀)還會將損毀的從端(綠色五星狀)編號記錄下來並填入表中傳送出

去，但若是兩個以上(含)的從端(綠色五星狀)損毀時，屆時因為範圍的關係將不

會有替代的從端(綠色五星狀)代替發射，而是使原本發射的從端(綠色五星狀)往

回傳送資料來保持連線的暢通(但此種狀況將會不收到原本應該繼續往下的資

料)，藉以透過此種方式提升系統的穩定性。

假設當主端發送資料時，從主端往下數第一個與第二個從端(綠色五星狀)將

會收到資料，而第三個從端(綠色五星狀)則不會收到資料，假設第一個從端(綠色

五星狀)損毀時，第二個從端(綠色五星狀)將代替第一個從端(綠色五星狀)繼續工

作並往下傳輸資料；但是當連續相鄰的兩個(第一與第二)從端(綠色五星狀)發生

損毀時，由於第三個從端(綠色五星狀)接收不到資料也無法作動，所以系統將會

在主端這邊自動回報下面連續兩個損毀，然後把資料儲存起來並起回報，不再繼

續往下做傳遞與接收的動作。

29

圖 3-3、Tree-Star network

30

圖 3-4、Tree-Star network

31

3.3 封包規範

資料的傳遞倚靠特定的傳送格式儲存並以封包的方式呈現，由於 Tree-Star

network 的架構下的執行模式分為建立網路與傳輸資料兩種，所以在封包定義上

分別分成兩大類，下列將說明這兩種封包的規範。

3.3.1 建立網路的封包規範

第一種是在一開始建立網路時的定義封包，其功能為配對所有系統上的從端

並給於從端獨一無二的編號，其編號將會告訴配對的從端現在在系統上屬於哪個

位置的從端。其封包也會通知主端現在系統上有幾個從端，以便建置下一個模式

要需要用的封包。

下表 3-1 定義了從端碼的規範，DataForm[0]為系統的運行的模式，此處則為

建立網路的模式； DataForm[1]為表格的判定密碼，唯有密碼驗證通過才能讀取

該表格資料；DataForm[2]為主端判斷有多少從端的代碼；DataForm[3]和[4]為主

端透過使用者輸入的編碼寫入從端的唯一的樹星從端編號；DataForm[5]為從端

回傳的配對成功碼，若為 1 代表配對成功，若為 0 則是配對失敗；DataForm[6]

為從端回傳的 ID 碼； DataForm[7]則是每 8 筆資料的分隔線，其功能定義給主

端拆解表格使用。

32

表 3-1、建立網路的封包規範

矩陣位置 Data Name(8 bit)

DataForm [0] LoRaMode

DataForm [1] Code-Reserve

DataForm [2] SlaveAmount

DataForm [3] LoRaTreeAddress

DataForm [4] LoRaStarAddress

DataForm [5] PairSuccessful

DataForm [6] LoRaSlaveAddress

DataForm [7] StopCode

3.3.2 傳輸資料的封包規範

第二種則是傳輸資料用的格式封包，其功能為定義該封包使用在傳輸資料上

時不同資料的擺放位置，其封包又分為兩種:頭碼與從端碼。

下表 3-2 的頭碼定義了表格的前 8 筆資料為識別碼，DataForm[0]為系統的運

行的模式，此處則為傳輸資料的模式； DataForm[1]為表格的判定密碼，唯有密

碼驗證通過才能讀取該表格資料；DataForm[2]~[5]為錯誤碼(下面會有詳細的說

明)；DataForm[6]為流程碼(下面會有詳細的說明)； DataForm[7]則是每 8 筆資料

的分隔線，其功能定義給主端拆解表格使用。

33

表 3-2、傳輸資料的封包規範-頭碼




DataForm [2] ErrorSlaveCode_1




DataForm [6] ProcessCounter


錯誤碼:其功能為記載哪個樹狀從端毀損，此資料可供使用者快速判斷樹狀

從端的損毀狀況，其資料由於是每個樹狀從端代表 1 個位元，由最高的

DataForm[2.0]代表樹狀從端 3的狀況依序到最低的DataForm[5.7]代表樹狀從端 1

的狀況。下列表 3-3 將說明其定義方式:

表 3-3、錯誤碼的封包規範

DataForm[2] DataForm[3] DataForm[4] DataForm[5] 定義

0b00000000 0b00000000 0b00000000 0b00000000 無損毀

0b00000000 0b00000000 0b00000000 0b00000001 樹狀從端 1 損毀

0b00000000 0b00000000 0b00000000 0b10000000 樹狀從端 8 損毀

0b00000000 0b00000000 0b00000100 0b00000000 樹狀從端 11 損毀

0b00000000 0b00000000 0b00000110 0b00000010 樹狀從端 11、10、2 損毀

34

流程碼:其功能為告訴系統現在資料傳遞與接收的時序將要在哪個從端運

行，流程定義如下(n 為第 n 個樹狀從端(主端算 1)，若是遇到回傳資料的話，n

必頇乘以 2):

1. 主端一開始會發送表格(包含流程碼為 n-1)出去，其流程碼 n-1 的功

能為通知主端範圍內的樹狀從端說輪到他們。

2. 當範圍內的樹狀從端收到訊息時，若是較內圍的樹狀從端成功接收

將會改寫流程碼為 n 並發送(流程碼 n 的功能為通知星狀從端必

頇回傳資料以及較外圍的樹狀從端說較內圍的樹狀從端是好

的)。

3. 此時星狀從端將會依序把資料回傳但不改寫其流程碼

4. 當樹狀從端判定星狀從端的資料接收完畢或損毀發生並判斷完畢

時，樹狀從端將發送表格(包含流程碼為 n-1，因為此步驟與第一

個步驟相同但第 n 個從端的 n 已經加 1，所以此時的 n-1 與第一

個步驟的數字不一樣)並重複第二步驟一直動作直到傳回主端並

改寫為 0 為止。

第二種為從端碼，從端碼定義了表格裡每 8 筆資料為一個從端所回傳的資

料，如下表 3-4 所示(其中 n 為若干個從端(包含樹狀與星狀道路)裡的第幾個)，

DataForm[8n]為隸屬從端之編號，其資料紀載下列感測器資料是由哪個樹狀道路

下從端的資料；DataForm[8n+1]則為從端之編號，其資料紀載下列感測器資料是

哪個星狀道路上從端的資料，若為零則代表此樹狀道路上從端的資料；

DataForm[8n+2]~ DataForm[8n+6]為感測器儲存的資料，此表格可以看出封包規

範只能攜帶總共 5 Byte 的資料量； DataForm[8n+7]則是每 8 筆資料的分隔線，

其功能定義給主端拆解表格使用。

35

表 3-4、傳輸資料的封包規範-從端碼


DataForm [8n] LoRaTreeAddress

DataForm [8n+1] LoRaStarAddress

DataForm [8n+2] Sensor1_Value





DataForm [8n+7] StopCode

若我們需要建置 n 個從端時(包含樹狀與星狀道路)，我們的表格必頇把頭碼

放置在表格的最前面，下面依序接著 n 個從端碼。由於不論是頭碼或是從端碼每

個資料量都為 8 Byte，所以若建置 n 個從端的話，其表格資料量將為(n+1)*8

Byte。下表 3-5 為建置 n 個從端時的表格編排方式。

表 3-5、n 個從端表格

36








DataForm [6] ProcessCounter


DataForm [8] LoRaTreeAddress

DataForm [9] LoRaStarAddress

DataForm [10] Sensor1_Value






DataForm [8n] LoRaTreeAddress

DataForm [8n+1] LoRaStarAddress





37


DataForm [8n+7] StopCode

38

第四章系統設計

由於此系統能建置的架構大小受到 SX1278封包大小(256 Byte)、C-type LoRa

Device 的 MCU RAM 大小(2 K)所限制，所以我們將規範樹狀道路上的從端上限

為 15 個，星狀道路上的從端上限為 8 個。

4.1 系統架構

本論文使用 Arduino IDE 作為開發工作，所採用的硬體包括 Arduino Nano、

聯發科技公司的 LinkIt™ ONE 開發版、Semtech 公司的 SX1278 晶片、BMP180

氣壓感測模組、DHT11 溫溼度感測模組和光敏電阻。LinkIt™ ONE 開發版負責

上傳雲端和負責與 LoRa 晶片(SX1278)溝通、Arduino Nano 負責與 LoRa 晶片

(SX1278)溝通和接收外界感測器的數值、LoRa 晶片則負責 LoRaWAN™的協議

與頻段調變，本論文採取操作 EU 433MHz 的頻段以及 Class C 的終端設備類別。

根據系統架構圖(圖 4-1)的流程表示，藍色粗線(從端 1、2、3（C-type LoRa

Device）之間)代表樹狀道路的主幹；淺紫細線(從端 1-1、2-1（C-type LoRa Device）)

則代表星狀道路。一開始主端（LinkIt™ ONE 開發版）對從端 1 的 LoRa 晶片透

過索取資料，從端 1 在發射表格給從端 2，從端 2 在發射表格給從端 3，當表格

資料傳至末端時(從端 3)，系統會自動判定將從端 3 的感測器資料送到從端 2，

此時從端 2 因為知道它在星狀道路上擁有從端 2-1，從端 2 會跟從端 2-1 索取資

料並把資料傳回從端 2，再來把資料傳送至從端 1 上，而從端 1 也擁有從端 1-1，

所以當從端 1 接收到資料後會跟從端 1-1 索取資料並回傳至從端 1 上再傳回主端





39

並保存，直到 LinkIt™ ONE 開發版下一次索取資料時才會將資料全部回傳至

LinkIt™ ONE 開發版，並透過網路的方式將資料上傳至雲端，供使用者使用電腦

或是手機查詢。

40

圖 4-1、系統架構圖

41

4.2 硬體架構

圖 4-2、硬體架構圖(主端)

圖 4-3、硬體架構圖(從端)

42

如上圖 4-2、4-3 表示，硬體架構區分為兩塊:主端和從端。首先，本論文定

義了 Arduino Nano 和 SX1278 的組合稱作 C 類 LoRa 模組(採用 Class C 的終端

設備類別)，會這麼定義是因為在功能和說明敘述上較為方便。

主端由 LinkIt™ ONE 開發版和 C 類 LoRa 模組組成，LinkIt™ ONE 開發版

藉由 I2C 介面與 C 類 LoRa 模組的 Arduino Nano 下達指令，此時 Arduino Nano

會依照指令藉由 SPI 介面使 SX1278 模組發射表格，接著數個從端(與距離有關)

的 C 類 LoRa 模組將會收到表格資訊和指令，根據指令內的資料決定數個從端 C

類 LoRa 模組會將如何反應，除了時序發射接收和補償模式外，C 類 LoRa 模組

通常處於接收模式，直到指令令他行動才會將他收集的外部感測器資料打包與表

格資訊一起上傳並回到接收模式等待下一次作動。外部感測器的介面則是仰賴

Arduino Nano 所提供的 I/O、I2C 和 ADC 硬體溝通，這些多樣的硬體可以確保日

後擴增或是替換感測器不必為溝通介面煩惱。待全部資料收集完畢後，LinkIt™

ONE 開發版會將所有的資料透由 WiFi 把資料上傳至雲端裡，供使用者可以在

電腦或是手機窗口遊覽資料。

4.2.1 LinkIt™ ONE 開發版

LinkIt™ ONE 開發版是專門為物聯網所設計的 32 位元開發版，其核心為聯

發科技 MT2502A 系統單晶片，支援多種通訊晶片和多媒體功能，包

括:GSM(850/900/1800/1900MHz)、GPRS(Class 12)、BlueTooth2.1 和 4.0、

WiFi(802.11b/g/n)、衛星定位系統(GPS,GLONASS 和 BeiDou)、SD Card(32GB)

和 MP3/AAC 音訊等等硬體功能[19]。然而以上條件硬體雖然符合基本物聯網平

台所需要的硬體，但真正令作者選擇 LinkIt™ ONE 開發版作為主控的關鍵條件

43

在於聯發科技公司開發了一套稱作 MediaTek Cloud Sandbox(簡稱 MCS)(下圖 4-4)

的雲端服務平台[20]，其服務平台除了免費使用和擁有視覺化開發環境的優點之

外，更能有效的將資料統整與分析，再也不需要另外建構自己的伺服器或是寫資

料統整的軟體。聯發科技公司開發上至雲端軟體，下至主控硬體的這種方式，完

美的實現了軟硬體整合的優點，提供使用者完善且舒適的開發環境。

圖 4-4、MediaTek Cloud Sandbox

4.2.2 SX1278

SX1278 收發器具有 LoRa™遠程調製技術，可以提供超長距離擴頻通訊和高

抗干擾能力，同時減少大幅度的電流消耗。其晶片使用 Semtech 半導體公司的專

利 LoRa™調製技術與低成本晶體和元件達到超過-148dBm 的靈敏度，以及

+20dBm 功率放大器的結合，產生比業界領先的鏈路預算，使其能應用於所需要

的範圍。與傳統調製技術相比，LoRa™在阻圔和選擇性方面也具有優勢，解決

了感測器範圍、抗干擾能力和電池消耗之間折衷的問題[21]。下表 4-1[21]可以看

出在不同模式下的電源消耗程度。



44

表 4-1、Power Consumption Specification

在操作之前，我們必頇先了解此晶片的工作原理，首先根據表 4-2、圖 4-5

和圖 4-6[21]說明此晶片有哪幾種模式和流程。

表 4-2、LoRa™ Operating Mode Functionality

45

圖 4-5、Startup Process

46

圖 4-6、Sequencer State Machine

47

一開始，晶片上電後處於最低電流的狀態(初始化包含睡眠與待機模式)，可

以看出睡眠模式較待機模式省電，其原因在於待機模式將外部晶振開啟，而睡眠

模式只保留 SPI 和暫存器的訪問權限而已。接著不論是睡眠或是待機模式，這些

模式會等待其各自的中斷旗標被改寫，差別是睡眠模式被喚醒則是進入待機模

式，而待機模式則會讀取暫存器來決定進入接收或是發射模式，由圖 4-5 中發現，

在進入接收或是發射模式之前，分別會進入 FSRX 與 FSTX 模式，這些事前工作

為頻率合成模式，可以看出這些模式下的耗電量比接收發射模式還少，其原因為

這些模式下在調頻未做完之前，將最為耗電的無線射頻給除能，節省電量消耗。

由表 4-2 可以發現，接收模式下區分為兩種模式:連續接收和單次接收模式，

連續接收模式將會處理接收進來的所有資料，直到模式被要求更換，此模式符合

先前到的 LoRaWAN™的 Class C 協議。然而單次接收模式則是只要收到有效的

資料封包(或是等到 RXTimeout)後返回待機模式，此模式則是符合 LoRaWAN™

的 Class A 和 B 的協議。

了解大致的流程後，緊接著我們討論發射和接收模式的細部流程。下圖 4-7

和圖 4-8 為發射和接收的方塊圖，我們先以圖 4-6 說明，其圖可以看出首先需要

初始化傳送的功能，再將把要傳送的資料寫進晶片內置的資料暫存器中後傳送出

去，但晶片不知道何時已經傳送完畢，所以晶片等待 IRQ 被改寫後讀取另外一

個暫存器的數值(IRQ 的功能為旗標的一種，其功能為通知晶片讀取 RegIrqFlags

這個暫存器的狀態，確保下一步該進入哪一種狀態)，若是需要繼續傳送則是回

到寫資料進 Data FIFO 的狀態裡，若是無資料需要傳輸則跳出此方塊圖關閉無線

電後跟晶片要求下一步的模式。

48

圖 4-8 說明了接收模式分成兩種:連續接收與單次接收，一開始接收模式初

始化後會依內部暫存器的數值決定該執行其中哪一種模式。首先我們先討論單次

模式，當決定哪一種模式後也是等待 IRQ 被改寫，被改寫的那一瞬間該模式會

先讀取 RegIrqFlags 這個暫存器的狀態，此模式需要判斷兩種狀態:RxTimeout 和

RxDone，當暫存器內部為 RxTimeout 這個 Bit 為 1，此晶片判斷對方無資料傳送

或是超過時間未接到資料，跳出接收模式關閉無線電後進入待機模式。當暫存器

內部為 RxDone 這個 Bit 為 1，此晶片判斷資料已經接收完畢，然後以 CRC 的方

式檢查資料對錯，如果資料正確的話就讀取次筆資料並儲存，若是不正確的話資

料直接被捨棄，進入跟晶片要求下一步的模式。連續模式下與單次模式並沒有差

異太大，其差異僅在被通知 IRQ 被改寫後只讀取 RxDone 這個 Bit 與檢查資料對

錯後繼續等待 IRQ 被改寫的訊息而已。

然而，不論是連續接收或是單次接收模式，他們都有一個極其重要的共通

點，其晶片在接收完後，如果資料遺失、錯誤或是超過時間的話，會一併將這種

狀況直接排除或是進入下一個階段，並沒有像 BlueTooth 或是 Wi-Fi 一樣必頇要

把資料確實正確或是比對成功為止的這個重要特性。然而這是因為上述那些技術

與 LPWAN 所設計的方式與應用層面和完全不相同的關係導致，LPWAN 當初的

設計理念為給物聯網使用，但是物聯網的設計通常不需要大量資料或是短時間要

求資料的這兩個重要因素決定了就算一筆資料不正確或遺失也無所謂，反正下一

筆資料正確就好的這個重大前提，這造就了 LPWAN 與 BlueTooth 或是 Wi-Fi 所

組成的物連網架構決定性的結構與省電差異。

49

圖 4-7、LoRa™ Modulation Transmission Sequence

50

圖 4-8、LoRa™ Receive Sequence

51

4.2.3 感測器

本論文感測器的採用原則為多樣化的硬體溝通介面為主來測詴MCU未來的

擴展能力與溝通能力，經過挑選，本論文根據研究文獻中[22][23]提出天氣會影

響心情之間的關係，指出需多天氣因素中其三種天氣變化對情緒最明顯的預測因

素：濕度，溫度和日照時數，找出量測天氣所需要的基本參數:濕度、溫度和照

度三種，以及加上氣壓(氣壓影響了雲的生成，而雲的生成與否都與上述三中參

數息息相關)這四種參數測詴。

4.2.3.1 DHT11 溫溼度感測模組

DHT11 模組融合了感測溫度和濕度為一體的感測器，其傳輸介面倚靠序列

連續資料溝通(I/O)，其感測器溫度感知範圍為 0~50℃，量測精準度為正負 2℃。

而濕度感知範圍為 20％～90%RH(附帶 0～50℃溫度補償)，量測精準度為正負

5% RH。

4.2.3.2 光敏電阻

本論文採用一般 5mm CDS 的光敏電阻，其特性允許在-30~+70℃之間運作，

當無光時阻值達到 10MΩ，當照射在 10 流明下的光時，其阻值為 45~140KΩ。

光敏電阻需搭配一固定電阻以達到分壓的作用，其傳輸介面倚靠類比電壓

(ADC)。

52

4.2.3.3 BMP180 氣壓感測模組

BMP180 氣壓感測模組融合了感測氣壓和溫度為一體的感測器，傳輸介面

倚靠 I2C 溝通，其感測器支援 300~1100hPa(相當於海平面 9000~-500 公尺)，在

最高精度模式下，其解析度可達 0.03hPa (相當於 0.25 公尺)。

4.3 軟體架構

首先，本論文設計為一個主端(LintIt ONE 加上 C 類 LoRa 模組)、三個樹狀

從端與兩個星狀從端(從端包含 Arduino Nano 加上 C 類 LoRa 模組)的架構，每個

從端分別都有三種感測器(DHT11 溫溼度感測模組、光敏電阻、BMP180 氣壓感

測模組)。在下面我們依據在上一章所提到的規範，我們將會得到所需要 48 組資

料(Byte 形式)的表格並回傳至主端，以及主從端的軟體流程都不一樣，在下面我

們把流程圖分為三大類講解(主端、樹狀從端、星狀從端)。

4.3.1 設計封包

本論文依規範定義了一筆 48 Byte 長度的資料作為表格，並將資料拆成五

區，依序分別為頭碼、從端 1、從端 2、從端 3、從端 1-1 和從端 2-1(從端 1、2、

3 為樹狀道路上的從端，而從端 1-1 和從端 2-1 則是所屬星狀道路上的從端)，其

資料依規範填入表格，以便主端分析資料並做計算後上傳。下面將對規範所生成

表格內的資料做說明:

53

表 4-3、表格資料

矩陣位置名稱名稱

DataForm[0]: LoRaMode: 該系統模式

DataForm[1]: Code-Reserve: 辨識碼

DataForm[2]: ErrorSlaveCode_1: 錯誤碼 1




DataForm[6]: ProcessCounter: 流程碼

DataForm[7]: StopCode: 停止碼

DataForm[8]: LoRaTreeAddress1: 隸屬從端之編號

DataForm[9]: LoRaStarAddress1: 從端編碼

DataForm[10]: LightSensorValue1: 照度值

DataForm[11]: Temperature-D1: 溫度(攝氏)

DataForm[12]: Humidity-D1: 濕度

DataForm[13]: AirPressure-B1: 氣壓

DataForm[14]: Temperature-B1: 溫度(華氏)









54










DataForm[32]: LoRaTreeAddress1-1: 隸屬從端之編號

DataForm[33]: LoRaStarAddress1-1: 從端編碼

DataForm[34]: LightSensorValue1-1: 照度值

DataForm[35]: Temperature-D1-1: 溫度(攝氏)

DataForm[36]: Humidity-D1-1: 濕度

DataForm[37]: AirPressure-B1-1: 氣壓

DataForm[38]: Temperature-B1-1: 溫度(華氏)


DataForm[40]: LoRaTreeAddress2-1: 隸屬從端之編號

DataForm[41]: LoRaStarAddress2-1: 從端編碼

DataForm[42]: LightSensorValue2-1: 照度值

DataForm[43]: Temperature-D2-1: 溫度(攝氏)

DataForm[44]: Humidity-D2-1: 濕度

DataForm[45]: AirPressure-B2-1: 氣壓

DataForm[46]: Temperature-B2-1: 溫度(華氏)


55

下列四個區塊依照規範填入的資料大同小異，在這裡我們合併說明:

LoRaTreeAddress(DataForm[8]、[16]、[24]、[32]、[40])為隸屬從端之編號，此編

號若代表從端 1、2、3 的話，其資料依序分別填入 1、2、3； LoRaStarAddress([9]、

[17]、[25]、[33]、[41])為從端編號，由於此系統裡只有從端 1-1 和 2-1 的星狀道

路從端，所以此筆資料將只有 DataForm[17]和[33]填入 1 的資料，其餘則為 0；

LightSensorValue([10]、[18]、[26]、[34]、[42])為照度值，該資料分別代表不同

從端的照度，其經過轉換後的數值區間為 0~255； Temperature-D([11]、[19]、

[27]、[35]、[43])為溫度值，該資料為 DHT11 所測得的溫度值，其預設單位為攝

氏； Humidity-D([12]、[20]、[28]、[36]、[44])為濕度值，該資料為 DHT11 所測

得的溼度值，其預設單位為%； AirPressure-B([13]、[21]、[29]、[37]、[45])為大

氣壓力值，該資料為 BMP180 所測得的大氣壓力，其預設單位為百帕；最後則

是 Temperature-B([14]、[22]、[30]、[38]、[46])，其資料為 BMP180 所測得的溫

度，其預設單位為華氏。

最後，為了避免混淆在此獨立說明 DataForm[2]~[5]和 DataForm[6]矩陣裡面

資料的設計與作動方式。首先，DataForm[2]~ [5]矩陣裡面定義為錯誤碼，錯誤

碼為負責記錄哪個樹狀從端損毀的資料，說明如下:

表 4-4、從端損毀對照

56

DataForm[2] DataForm[3] DataForm[4] DataForm[5] 說明

0x00 0x00 0x00 0x00 為正常狀況無損毀

0x00 0x00 0x00 0x01 為從端 1 損毀

0x00 0x00 0x00 0x02 為從端 2 損毀

0x00 0x00 0x00 0x04 為從端 3 損毀

DataForm[6]矩陣裡面定義則為流程碼，流程碼的用意在其資料可以供系統

讀取表格目前樹狀道路上從端所屬於的狀態，其狀態則表示該表格現在該由哪個

樹狀從端接收和更改表格內容，其流程碼說明如下:

表 4-5、流程碼順序對照

DataForm[6] 說明

0x00 為主端發送表格，供從端 1、2 判讀

0x02 為從端 1 發送表格，供從端 2、3 判讀

0x04 為從端 2 發送表格，供從端 3 或 4 判讀

0x06 為從端 3 發送回傳資料，供從端 1、2 判讀

0x07 為從端 2 發送表格，供從端 2-1 判讀

0x08 為從端 2 發送回傳資料，供從端 1 和主端判讀

0x09 為從端 1 發送表格，供從端 1-1 判讀

0x0A 為從端 1 發送回傳資料，供主端判讀

57

圖 4-9、流程碼順序展示圖

4.3.2 主端軟體流程

主端是由一個 LinkIt ONE 開發版和一個 C 類 LoRa 模組所組成，首先主端

上電後會先初始化(WiFi 和 I2C、SPI Bus 的啟用，SX1278 被喚醒至待機模式)，

WiFi 會將預先設定好的帳號密碼建立網路連線，連線成功後 LinkIt ONE 會連線

至 MCS 網站裡，將預先設定好的 Device ID 和 Password 上傳並要求訪問我們建

置的 MCS 專案，待比對成功進入專案完後 C 類 LoRa 模組將命令 SX1278 設置

58

為發射模式，並將表格傳送出去(此時表格內已經含有流程碼的初始狀態:0)後馬

上將 SX1278 設置為接收模式並等待下一次的回傳資料進來。

依本論文系統的設計來看，主端 C 類 LoRa 模組的涵蓋範圍包括從端 1 和 2

的 C 類 LoRa 模組裡面，使主端 C 類 LoRa 模組會收到來自從端 1 和 2 的 C 類

LoRa 模組所傳送的資料，利用這個特性我們可以設計出判斷從端 2 的 C 類 LoRa

模組的狀況。也因此本論文在每個 C 類 LoRa 模組都設置了這種功能，也就是說

處在接收模式下不只收集樹狀道路上的上一層或下一層的資料，更是收集了更上

一層與更下一層的資料，使系統更具有資料收集的穩定性。

依照時序來看，下一次接收到資料已經是從端 1、2 回傳資料的時候，此時

將會有兩種情形發生:1.從端 1 正常回傳資料。2.從端 1 損毀，改接收從端 2 的資

料。下列我們將分開說明這兩種情況。

1. 設定 SX1278 為接收模式後以時序上來說在接收到從端 1(下家)的資料前

會最先收到來自從端 2(下下家)的回傳資料，這個流程判定(判斷下家從

端回傳資料是否損毀)就是在判斷在接收到來自從端 2 的回傳資料後，系

統則會再次等待接收來自從端 1 的回傳資料成功後，將資料填入表格並

放入Arduino Nano本身的記憶體裡面等待LinkIt ONE的索取資料並上傳

至雲端。

2. 若是系統等待從端1的回傳資料的期間超出我們所設置的時間(此時間為

一個既定的常數，其數值設置取決於使用者需要設置多久的時間確認損

毀的狀況發生)，此時系統將判定從端 1 的損毀狀況發生，改寫錯誤碼並

把資料填入表格並放入 Arduino Nano本身的記憶體裡面等待 LinkIt ONE

的索取資料並上傳至雲端。

59

上傳完成後，其流程將回到等待 MCS 的回應等待下一輪的作動。

其主端的作用為建立雲端連線、發送命令、建立主從的連接橋梁、接收發送

資料表格和判斷從端 1 的損毀狀況這五種功能。

開始

初始化

設定LoRa為發射模式

傳送表格

設定LoRa為接收模式

判斷下家從端回傳資料是否損毀

紀錄資料

記錄錯誤訊息與資料

將資料上傳至雲端

NO

YES

等待MCS是否回應

YES

NO

圖 4-10、主端流程圖

60

4.3.3 樹狀從端軟體流程

接著我們說明樹狀從端的流程(圖 4-12)；一開始樹狀從端上電後會先執行初

始化(SPI、I2C Bus、I/O、ADC 功能的啟用，SX1278 被喚醒至待機模式)，初始

化完後便會使 SX1278 轉換成接收模式並且收集感測器的資料，等待下一次的指

令進來，由於樹狀從端依照系統設計所處的位置在中間(上承主端或樹狀從端，

下接其他樹狀從端)，在第一次等待指令時至少就會有主端的指令出現(或是加上

其他樹狀從端的指令)。假設我們設定有其他樹狀從端的存在，依照時序來看，

這兩筆指令依據時序先後分別為來自主端(或是上上家樹狀從端)與來自上家樹

狀從端的指令，這將會有兩種情形發生:1.上家樹狀從端正常傳送格式。2.上家樹

狀從端損毀，改接收主端(或是上上家樹狀從端)的表格。下列我們將分開說明這

兩種情況。

1. 設定 SX1278 為接收模式後以時序上來說會最先收到來自主端(或是

上上家樹狀從端)的傳送格式，也就是說第一個流程判定(判斷上家

傳送表格是否損毀)正常是肯定的，在接收到來自主端(或是上上家

樹狀從端)傳送資料的表格後，系統則會再次等待接收來自上家樹狀

從端傳送資料的表格，若是成功後使 SX1278 轉換成發射模式，並

將更動後的資料填入表格傳送出去，且返回接收模式等待下一筆回

傳資料的開始。

2. 若是系統等待上家樹狀從端的回傳資料的期間超過我們所設置時間

的話(此時間為一個既定的常數，其數值設置取決於使用者需要設置

多久的時間確認損毀的狀況發生)，此時系統將判定上家樹狀從端的

61

損毀狀況發生，並將更動後的資料和錯誤碼，填入表格傳送出去，

且返回接收模式等待下一筆回傳資料的開始。

不論樹狀從端有無判讀到上家樹狀從端否損毀，最終流程都會走到 SX1278

為接收模式下等待下一筆回傳資料的指令出現，由於樹狀從端所處位置的關係，

使得樹狀從端必頇得判斷下家樹狀從端和下下家樹狀從端損毀的狀況。設定

SX1278 為接收模式後我們可能會接收到來自下家樹狀從端和下下家樹狀從端的

回傳資料。下列我們將分開說明這兩種情況。

1. 設定 SX1278 為接收模式後以時序上來說會最先收到來自下下家樹

狀從端的回傳資料，若是下下家樹狀從端回傳資料的期間超過我們

所設置時間的話(此時間為一個既定的常數，其數值設置取決於使用

者需要設置多久的時間確認損毀的狀況發生)，此時系統將判定下下

家樹狀從端的損毀狀況發生，並將更動後的資料(包含接收星狀的資

料)和錯誤碼，填入表格傳送出去並回到 SX1278 為接收模式等待下

一輪接收資料表格的開始。若是系統判定下下家的樹狀從端尚未損

毀，此處系統將進入下一個階段判斷。

2. 此處系統將進行判斷下家的樹狀從端是否損毀，首先若是下家樹狀

從端回傳資料的期間超過我們所設置時間的話(此時間為一個既定

的常數，其數值設置取決於使用者需要設置多久的時間確認損毀的

狀況發生)，此時系統將判定下家的樹狀從端的損毀狀況發生，並將

更動後的資料(包含接收星狀的資料)和錯誤碼，填入表格傳送出去

並回到 SX1278 為接收模式等待下一輪接收資料表格的開始。若是

正常運作則將資料(包含接收星狀的資料)填入表格傳送出去並回到

SX1278 為接收模式等待下一輪接收資料表格的開始。

62

其樹狀從端主要為判斷上上家樹狀從端、上家樹狀從端、下家樹狀從端、下

下家樹狀從端的損毀狀況以及接收發送資料表格和接收星狀的資料這六項功能。

63

開始

初始化

儲存感測器資料


判斷上家從端傳送表格是否損毀


紀錄資料(含星狀)


YES

判斷下下家從端傳送表格是否損毀

記錄錯誤訊息與資料(含

星狀)YES

NO

判斷下家從端回傳資料是否損毀


紀錄資料(含星狀)

YES

NO



NO

NO

回傳資料

傳送表格

圖 4-11、樹狀從端流程圖

64

4.3.4 星狀從端軟體流程

最後我們說明星狀從端的流程(圖 4-13)；由於星狀從端為星狀道路上的從

端，不需要接收來自其他樹狀道路上從端的資料，只需要接收隸屬於哪個樹狀道

路下的從端即可，所以其狀況較為單純:

一開始星狀從端一樣上電後會先執行初始化(SPI、I2C Bus、I/O、ADC 功能

的啟用，SX1278 被喚醒至待機模式)，初始化完後便會使 SX1278 轉換成接收模

式並且收集感測器的資料，等待下一次的指令進來，其指令為來自所屬樹狀從端

的回傳資料的指令並索取本身的資料，若收到則將等待一段時間(此時間為一個

既定的常數，其數值設置取決於其星狀從端所屬的順序位置，若順序越後面其等

待時間則越長)後使 SX1278 轉換成發射模式並將資料填入表格傳送出去，並返

回接收模式等待下一輪指令的開始。

65

開始

初始化

儲存感測器資料


判斷是否為所屬樹狀從端資料

記錄資料

NO

等待時間是否超過

NO


YES

回傳資料

圖 4-12、星狀從端流程圖

66

第五章實驗結果

5.1 硬體配置

圖 5-1 顯示此系統上 1 個主端與 5 個從端(3 個樹狀，2 個星狀，樹狀與星狀

從端硬體沒有差別)的實體圖。

圖 5-1、系統實體圖

圖 5-2 則為主端的硬體實體圖，可以看到，主端上含有 LinkIt ONE 開發版、

MCU(Arduino Nano)、LoRa 模組(SX1278)、電源、升壓板、充電版、開關和指

示燈。LinkIt ONE 開發版、MCU(Arduino Nano)、LoRa 模組(SX1278)的功能已

經在前面的章節說明過，所以下列將說明電源、升壓板、充電版和指示燈的功能。

電源我們採取使用 18650 的電池，其優點為鋰電池可充放的特性；然而 18650

的滿電壓只有 4.2V，不足以供給 MCU(Arduino Nano)使用，所以我們使用

XTU-SY-8 的升壓板將電壓升至 9V 供 MCU 作動；而鋰電池本身需要充電，在

67

此處則採用 TP4056 的晶片模組充電；指示燈的功能則為系統建置配對之時所需

要的信號燈和系統流程運作時需要的狀況判定(感測器和 LoRa 模組故障狀況、接

收資料表格狀況和 MCU 重置提醒狀況)。

圖 5-2、系統實體圖(主端)

圖 5-3 為從端的硬體實體圖，可以看出主端與從端的差別只有從端沒有

LinkIt ONE 開發版和多了感測器而已，由於上述已經說明過這些硬體的功能，故

此處不再冗述。

68

圖 5-3、系統實體圖(從端)

5.2 實驗設計

本論文的核心主體為遠距離、傳遞資料的替代行為和其資料再藉由主端回傳

至雲端顯示圖表供使用者觀測這三種功能，依據功能來設計實驗檢測其功能是否

運作。下列我們分成三種測詴方法: 佈點測詴、錯誤檢知與圖表顯示。

5.2.1 佈點測詴

此次測詴我們選在義守大學內佈點(圖 5-4)分別在科技大樓(主端)、理工大樓

(樹狀從端)、體育館(樹狀從端)和宿舍的全家前(樹狀從端)；距離則分別為 120

公尺、150 公尺和 300 公尺，點與點之間則有需多障礙物(樹木、大樓、斜坡等等)

的存在。

69

圖 5-4、測詴地點

70

5.2.2 錯誤檢知與圖表顯示測詴

在錯誤檢知的檢測項目裡我們將設計依造順序每隔一段時間模擬損毀狀況

發生(關機) 以便模擬替代性的功能，其順序為從端 1、2、3 分別損毀以及從端 1、

3 同時損毀時的狀況。下列實驗我們分別挑出樹狀編碼、照度值、溫度(攝氏)、

濕度、大氣壓力和溫度(華氏)的數值顯示，若數值為 0 則代表那段時間的資料或

從端已經損毀。

可以看出下面的圖(圖 5-5 到圖 5-10)不論是從端 1、2、3 分別損毀或是從端

1、3 一起損毀發生，其他從端的資料也可以回傳，代表其替代功能有在運作。

71

圖 5-5、樹狀編碼圖

72

圖 5-6、照度值圖

73

圖 5-7、溫度(攝氏)圖

74

圖 5-8、濕度圖

75

圖 5-9、大氣壓力圖

76

圖 5-10、溫度(華氏)圖

77

第六章結論

透過上面實驗可以驗證本論文所提出的 Tree-Star 架構功能，不論是傳遞資

料的替代行為得到了解決；又或是其資料再藉由主端回傳至雲端顯示圖表供使用

者觀測與除錯等都證實 Tree-Star 架構是可行的，下列我們將分成幾個要點做總

結與討論。

6.1 C-type LoRa 模組耗電性問題

本論文將 LoRa 設置在 Class C 的模式下進行運作是為了解決非同步傳輸資

料接收的問題，但由於 LoRaWAN™協議定義了 Class A、B、C 三種不同的溝通

協議，其中在 Class C 是最耗電的模式，依照 SX1278 的說明文件[21]來看，就以

待機模式與接收模式的耗電量進行比較就差了 10 倍之多；所以本論文所設計的

架構會比原本 LoRaWAN 的架構更為耗電，未來必頇針對這點使用更為謹慎的

軟體設計時序進行修正。

6.2 遠距離傳輸資料

根據實驗結果我們在校園內建置的點相隔數百公尺仍然可以接收資料且正

確，相較於其他物聯網主流的技術而言其優點顯而易見；但由於此次的實驗我們

採用的天線(彈簧天線)與功率(+17 dBm)較為次等，所以並無法實現十公里級以上

的實驗，若需要加長距離值則需要較專用的天線與解除晶片的功率限制。

78

6.3 Tree-Star 架構可靠性與成本

對於星狀網路架構來說，不論是不同的主端不僅需要處理來自相同的從端資

料接收並彼此溝通決定誰該上傳資料，又需要處理多個從端同時回傳資料時所需

要的對應方式；而從端則是需要面對彼此同時傳輸失敗時再次傳送還會發生資料

重疊的可靠性問題；又或是星狀網路的主端價格昂貴(數萬至數十萬元)，面對需

要擴增範圍時所花費的資金將會等比例上升的成本問題。

而 Tree-Star 架構則解決上述的問題，從可靠性來說，Tree-Star 架構規定從

端的資料回傳並無任何時間上的衝突，所以並無任何資料無法傳送，無法傳送的

狀況只有從端損毀一種，若是發生損毀系統也會將此消息存在資料裡並且透過本

論文所設計樹狀從端的替代行為代替損毀的樹狀從端回傳資料以確保連接性；再

從成本來說，Tree-Star 架構無論架構有多龐大，其系統的主端也只會有一個的存

在，而且主端也只需要僅僅數千元的花費支出，再者，系統架構越龐大，增加的

也只有樹狀與星狀從端的建置而已，而樹狀與星狀從端的花費也僅僅需要數百

元，而且樹狀從端本身就可以收集資料進而省去星狀從端的建置。

6.4 多樣化的硬體溝通方式

此系統完成了不同的硬體溝通方式，其硬體資源透過 C-type LoRa Device 上

的 MCU(Arduino Nano)提供，其硬體包括 SPI、IIC、I/O、ADC。

6.5 雲端連接

79

本論文使用 MCS 來做為雲端平台並得到實現，MCS 提供簡單的操作方式與

電腦手機的介面使使用者方便觀測；其平台亦提供圖表統計使使用者能更快速的

統計資料的曲線來做分析使用，而且 MCS 為免費使用，成本低廉。

6.6 應用場合

依照本論文所設計的樹狀從端最大 15 個，星狀從端最大限制為每 1 個樹狀

從端配置 8 個星狀從端的這個規範加上若以每個 LoRa 能傳 10 公里的距離這兩

個條件來看，此系統最大能建置覆蓋 70*20 平方公里的面積和最大乘載

135*8Byte 的資料量，如此龐大的面積與極少資料量的組合較適合作為大面積檢

測但不需要資料量小的應用場合，例如:農漁牧場觀測、山區海洋氣象觀測、路

燈自動化系統、智慧城市等等。

80

第七章、參考文獻

[1] A. Zanella, “Internet of Things for Smart Cities,” IEEE INTERNET OF

THINGS JOURNAL, FEBRUARY 2014.

[2] Luigi Atzoria, Antonio Ierab, Giacomo Morabito, “The Internet of Things: A

survey,” Computer Networks, p. 2787–2805, 28 October 2010.

[3] “Disruptive Civil Technologies-Six Technologies with Potential Impacts on US

Interests Out to 2025,” National Intelligence Council, 2008.

[4] "Internet of Things: the complete IoT guide – benefits, risks, examples, trends,"

[Online]. Available:

https://www.i-scoop.eu/internet-of-things-guide/#The_exponential_growth_of_t

he_Internet_of_Things.

[5] "„Internet of Things‟ Connected Devices to Triple by 2021, Reaching Over 46

Billion Units," [Online]. Available:

https://www.juniperresearch.com/press/press-releases/%E2%80%98internet-of-

things%E2%80%99-connected-devices-to-triple-b.

[6] “ERICSSON MOBILITY REPORT-ON THE PULSE OF THE NETWORKED

SOCIETY,” Ericsson, 2016.

[7] D. Evans, "How the Internet of Everything Will Change the World…for the

Better #IoE [Infographic]," Cisco, 7 November 2012. [Online]. Available:

http://blogs.cisco.com/digital/how-the-internet-of-everything-will-change-the-w

orldfor-the-better-infographic.

[8] J. M. Tjensvold, “Comparison of the IEEE 802.11, 802.15.1,802.15.4 and

81

802.15.6 wireless standards,” 2007.

[9] “ALPHABETICAL INDEX of· the contents of the documents of the

International Radio Conference,” International Telecommunication Union,

1949.

[10] “IEEE802.11ac: The Next Evolution of Wi-Fi Standards,” QUALCOMM

Incorporated, 2012.

[11] "OFFICIAL IEEE 802.11 WORKING GROUP PROJECT TIMELINES," the

Institute of Electrical and Electronics Engineers, Inc. (IEEE), 15 05 2017.

[Online]. Available:

http://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm.

[12] WIKIPEDIA, "LPWAN," [Online]. Available:

https://en.wikipedia.org/wiki/LPWAN.

[13] “LPWA Technologies-Unlock New IoT Market Potential,” LoRa Alliance,

2015.

[14] “Mobile Experts White Paper for LoRa Alliance-Where does LoRa Fit in the

Big Picture?,” LoRa Alliance, 2015.

[15] L. Brewton, "Semtech Acquires Wireless Long Range IP Provider Cycleo,"

Semtech Corporation. [Online].

[16] “LoRa Device Developer Guide-Orange Connected Objects & Partnerships,”

Orange S.A., 2016.

[17] “LoRaWAN™ What is it?-A technical overview of LoRa and LoRaWAN™,”

LoRa Alliance, 2015.

[18] WIKEIPEDIA, "ALOHAnet," [Online]. Available:

https://en.wikipedia.org/wiki/ALOHAnet.

82

[19] "LinkIt™ ONE - Overview," MediaTek Inc, 2016. [Online]. Available:

https://labs.mediatek.com/en/platform/linkit-one.

[20] "MediaTek Cloud Sandbox," MediaTek Inc, 2016. [Online]. Available:

https://labs.mediatek.com/en/platform/mediatek-cloud-sandbox.

[21] "DATASHEET-SX1276/77/78/79 - 137 MHz to 1020 MHz Low Power Long

Range Transceiver," Semtech Corporation, 2015.

[22] Matthew C. Keller, Barbara L. Fredrickson, Oscar Ybarra, Ste´phane Coˆte´,

Kareem Johnson,Joe Mikels, Anne Conway, and Tor Wager, “AWarm Heart

and a Clear Head,” American Psychological Society, pp. 724-731, 2005.

[23] E. Howarth, M. S. Hoffman, "A multidimensional approach to the relationship

between mood and weather," British Journal of Psychology, pp. 15-23, 1984.

運用 lora 技術實現 iot...

Documents