Lora Iot Masters

21080 IoT3
Connecting your IoT Device

with LoRaWAN™ to YEAP!
© 2017 Microchip Technology Incorporated. All Rights Reserved. 21080 IoT3 Slide 1
Agenda - Argentina
1. Introducción rápida a LoRaWAN
a) Introduccion a Yeap!
2. Herramientas de Microchip para LoRaWAN
a) RN2903A >> Comandos básicos
b) RN2903A >> Planes de frecuencia
3. LoRaWAN en la vida real
a) Alta de cuenta Yeap
b) Alta de dispositivo
c) Flujo de datos
d) DASS
4. My Devices
a) Creación de cuenta
b) Nuevo dispositivo LoRaWAN
5. Node-RED
a) Fundamentos
b) Ejemplo con LoRaWAN
Class Objectives
When you walk out of this class you will be

able to…
 Explain how a regional LoRaWAN™
network like Yeap! works.
 Create a full IoT ecosystem by sending
data through the entire IoT data path
 IoT device  Gateway  Network Server  User Application
Agenda
 What is LoRa® and LoRaWAN™ (20min)
 Microchip’s LoRa® and LoRaWAN™ Solutions
 IoT Sensor: The SmartHuman board (15min)
 Demo 1 – Collect Data (temp and EUI) on SmartHuman (10min)
 Network Server: Yeap! (15min)
 Lab 1 – TTN Account (pre-created accounts) (15min)
 Lab 2 – Connect SmartHuman to Gateway and see data in the
Yeap DASS Interface (40min)
 User Application: Node-RED (20min)
 Demo 2 – Node-RED Application (20min)
Agenda
The IoT with LoRaWAN™
Part 1: Part 2: Part 3:

IoT Sensor Network Servers YEAP! User Apps
Demo 1: Labs 1 & 2: Demo 2:

Read Temp Getting Data from IoT Device
LoRaWAN™ to Server
Servers Creating a
User App
Agenda


Servers Creating a
User App
Agenda


Servers Creating a
User App
Sub-Agenda
 What is LoRa® and LoRaWAN™

 LoRa® Technology Modulation
 How does LoRaWAN™ Technology Work?
 End-Device Classes
 End-Device Activation and Security
 End-Device Data Communication (Class A)
 Adaptive Data Rate (ADR)
Sub-Agenda

LoRaWAN™ Network Protocol
LoRa® Technology Modulation
 Proprietary Spread Spectrum Technology
 Developed by Semtech Corporation (http://www.semtech.com/)
 Chirped-FM
 Processing gain = increased receive sensitivity
 Enables longer range at expense of lower data rate
LoRa® Technology Modulation
 Spreading Factor (SF)
 Programmable SF:
7, 8, 9, 10, 11, 12
 The higher the SF the more information transmitted per bit;
therefore higher processing gain
 Bandwidth (BW)
 Programmable signal BW settings:
125 kHz, 250 kHz, 500 kHz
 For a given SF, a narrower BW = increased receive sensitivity;
however, increased time on air
 Forward Error Correction (FEC) Code Rate (CR)
 Additional coding rate provides more redundancy to detect errors
and correct them
 Great info @ https://youtu.be/T3dGLqZrjIQ?t=2122
LoRaWAN™ Modulation Settings for North America
0 1 2 3 4 Data Rate (DR)
LoRa® Modulation
Range
10 9 8 7 8 Spreading Factor (SF)
125 125
125 125 500 Bandwidth (BW) (kHz)
12500 Bitrate (BR) (bps)
5468
3125
1757
976
Longest Distance on LoRa® Modulation

 Data Rate (DR) = 0
 LoRa® modulation
 Spreading Factor (SF) = SF10
 Bandwidth (BW) = 125 kHz
 Coding Rate (CR) = 4/5
 Bit Rate = 976 bps
 Max Application Payload Size = 11 bytes
 Time On Air = 371 ms
Highest Bit Rate on LoRa® Modulation

LoRaWAN™ Modulation Settings for Europe
0 1 2 3 4 5 6 7 Data Rate (DR)
LoRa® Modulation FSK
Range
12 11 10 9 8 7 7 -- Spreading Factor (SF)
125 125 125 --
125 125 125 250 50K Bandwidth (BW) (kHz)
10937
Bitrate (BR) (bps)
5468
3125
1757
-120
976 -123 -122
292 537 -126
-132
-129 Receive Sensitivity (dBm)
-137 -135
Longest Distance on LoRa® Modulation

Highest Bit Rate on LoRa® Modulation

LoRaWAN™ Channels
 License free Sub-GHz Frequencies
 North America: 915 MHz Band
 Upstream: 64 channels numbered 0 to 63, DR0 to DR3
 Upstream: 8 channels numbered 64 to 71, DR4
 Downstream: 8 channels numbered 0 to 7, DR8 to DR13
Sub-Agenda

 Microchip’s LoRa® and LoRaWAN™ solutions
What is LoRaWAN™ Network Protocol?
 Low Power Wide Area Network (LPWAN)
 Bidirectional
 Simple Star Network Topology Enables simpler network
 Low data rate architecture:
• No repeaters
 Low cost
• No mesh routing complexity
 Long battery life
 Ideal for:
 Internet of Things (IoT)
 Machine-to-Machine (M2M)
 Industrial Automation
 Low Power Applications
 Battery Operated Sensors
 Smart City
 Smart Meter
 Smart Agriculture
http://lora-alliance.org/What-Is-LoRa/Technology
LoRaWAN™ Network
Application
Server
Network
Server
Gateways
End-Devices
How does LoRaWAN™ Technology Work?
Physical Topology
End-Devices Gateways Network Application
Server Servers
* May physically be
one server
Sub-GHz RF IP IP
Advanced Network Topology

Physical Topology
End-Devices Gateways Network Application
Server Servers
Sub-GHz RF IP IP

End-Devices Physical Topology
Gateways Network Application
Server Servers
Sub-GHz RF IP IP

End-Devices Physical Topology
Server Servers
Sub-GHz RF IP IP

Multiple Application Servers Example

Server Servers
Sub-GHz RF
Sub-Agenda

 Lora® Technology Modulation
End-Device Classes
 Each end-device class has different
behavior depending on the choice of
optimization:
 Battery Powered – Class A
 Low Latency – Class B
 No Latency – Class C
End-Device Classes
 Bidirectional communications
 Unicast messages
 Small payloads
 Long intervals
 End-device initiates communication (uplink)
 Server communicates with end-device (downlink) during
predetermined response windows:
Transmit RX1 RX2

RxDelay1
RxDelay2
End-Device Classes
 Pros
 Lowest power consumption = longest battery life
 Cons
 Long latency
 Examples
 Battery powered sensors
End-Device Classes
 Bidirectional with scheduled receive slots
 Unicast and Multicast messages
 Small payloads
 Long intervals
 Periodic beacon from gateway
 Extra receive window (ping slot)
 Server can initiate transmission at fixed intervals
BCN PNG Transmit RX1 RX2 BCN
RxDelay1
RxDelay2
Ping Slot
Beacon Period
End-Device Classes
 Pros
 Deterministic latency
 Cons
 Higher power consumption
 Examples
 Battery powered actuator end-device
LoRaWAN™ Overview
End-Device Classes
 Bidirectional communications
 Unicast and Multicast messages
 Small payloads
 Server can initiate transmission at any time
 End-device is constantly receiving
Transmit RX2 RX1 RX2
RxDelay1
RxDelay2
Extends RX2 until next TX
End-Device Classes
 Pros
 Lowest receive latency
 End-device has continuous receive window
 Cons
 Highest power consumption
(expect end-device to be mains powered)
 Examples
 Mains power low-latency actuator end-device
Sub-Agenda

End-Device Activation (Joining)
 Before an end-device can communicate on the

LoRaWAN™ network, it must be activated
 The following information is required:
 Device Address (DevAddr)
 Network Session Key (NwkSKey)
 Application Session Key (AppSKey)
Let’s look at each of these in detail…
 32-bit identifier
 Unique within the network
 Present in each data frame
 Shared between End-device, Network Server, and
Application Server
 Differentiates nodes within the network,
allowing the network to use the correct
encryption keys and properly interpret the data
 128-bit AES encryption key
 Unique per end-device
 Shared between end-device and Network Server
 Provides message integrity for the
communication
 Provides security for end-device to Network
Server communication
 128-bit AES encryption key
 Unique per end-device
 Shared between end-device and Application Server
 Used to encrypt / decrypt application data messages
 Provides security for application payload
 To exchange this information, two activation

methods are available:
Over-the-Air Activation Activation By Personalization
(OTAA) (ABP)
 Based on Globally Unique  Shared keys stored at production
Identifier time
 Over the air message  Locked to a specific network
handshaking
 Over-the-Air-Activation (OTAA)
 End-device transmits Join Request to application
server containing:
 Globally unique end-device identifier (DevEUI)
 Application identifier (AppEUI)
 Authentication with Application key (AppKey)
 End-device receives Join Accept from application
server
(continued…)
 Over-the-Air-Activation (OTAA)
 End-device authenticates Join Accept
 End-device decrypts Join Accept
 End-device extracts and stores Device Address
(DevAddr)
 End-device derives:
 Network Session Key (NwkSKey) Security
 Application Session Key (AppSKey) Keys
 Activation By Personalization (ABP)
 The following information is configured at
production time:
 No over the air handshaking
 Device is ready to communicate on the network
without any additional procedure.
 Note that the end result is the same, the DevAddr
and security keys are now known to the end-
device
Security
Logical Data Flow (Programmer’s Model)
End-Devices
Gateway Network Application
Server Server
IP IP
Application
Sub-GHz RF
Application
Network Session Key (NwkSKey)
Data Application Session Key (AppSKey) Data
Security
 Based on 802.15.4 Security
 AES-128
 Enhancement
 Network Server authenticates Application Data
 Network Server cannot decrypt Application
Data*
Sub-Agenda

End-Device Data Communications (Class A)
 Uplink Message
 End-Device to Network Server relayed by one or
many Gateways
Network Application
End-Devices Gateways
Server Servers
Uplink
Sub-GHz RF IP IP
 Downlink Message
 Sent by the Network Server to only one End-Device
and is relayed by a single Gateway
Network Application
End-Devices Gateways
Server Servers
Downlink
Sub-GHz RF IP IP
Unconfirmed-Data Message
End-Device Data Message does

not require an acknowledgement
Let’s look at an example…
Server Servers
1. Electric meter transmits data
Server Servers
2. Gateway receives data and passes to Network Server
Server Servers
3. The Network Server authenticates data and

passes it to Electric Meter Application Server
Server Servers
Data
4. Electric Meter Application Server decrypts data
End-Device Data Communications
Confirmed-Data Message
End-Device Data Message has to be

acknowledged by the receiver
Server Servers
1. Vending Machine transmits data.

It is received by two Gateways.
Server Servers
Data
2. Both gateways “pass through”

the data to the Network Server.
Server Servers
3. The Network Server forwards the data to

the Vending Machine Applications Server
Server Servers
4. The Vending Machine Applications

Server sends an acknowledgement
Server Servers
ACK
5. The Network Server selects the best path (gateway) to

transmit the acknowledgement to the end-device.
Server Servers
6. The Gateway transmits the

acknowledgement to the end-device
Application Server Data Message
If the Application Server has a Data Message

for the End-Device…
… the Application Server has to wait until the
End-Device initiates a transmission.
Server Servers
Data
1. The Smoke Detector Application Server has

Data for the highlighted Smoke Detector
Server Servers
Data
Zzz…
2. However, it has to wait until the Smoke Detector

wakes up and transmits a Data Message
Server Servers
Data
3. When the Smoke Detect transmits,

the Data Message moves Upstream
Server Servers
Data
4. Passed through the Gateway…
Server Servers
Data
Data
5. … and the Network Server sends to the

Smoke Detector Application Server.
Server Servers
Data
6. The Smoke Detector Application Server can now

send the data message to the Smoke Detector.
Server Servers
7. The Network Server sends the Data Message

to the appropriate Gateway.
Server Servers
8. The Data Message is transmitted to the Smoke

Detector during one of the two Receive Windows.
Sub-Agenda

 End-Device Data Communication
Adaptive Data Rate (ADR)
 LoRaWAN™ can manage
 data rate and
 RF power output
for each end-device to
 Optimize for fastest data rate,
 Maximize battery life, and
 Maximize network capacity
based on range from gateway
Agenda
 IoT Sensor: The SODAQ ExpLoRer
 Lab 1 – Collect Data (temp and EUI) on ExpLoRer
 IoT Gateway: A LoRaWAN™ Gateway
 Network Server: The Things Network
 Lab 2 – TTN Account (pre-created accounts)
 Lab 3 – Connect ExpLoRer to Gateway and see data in the TTN
Dashboard
 User Application: Node-RED
 Lab 4 – Node-RED Application
 Lab 5 – Bonus: Two-Way Communication
LoRa® Technology Wireless Modules
 RN2483 LoRa® Technology

Transceiver Module
 European (EU) 868/433 MHz
 R&TTE Directive Assessed Radio Module
 TX Power: up to +14 dBm
 Power Consumption: 1.6 uA in Sleep
 RN2903 LoRa® Technology

Transceiver Module
 North American (NA) 915 MHz
 FCC and IC modular certification
 TX Power: up to +20 dBm
 Power Consumption: 2.2 uA in Sleep
Open Module Scheme
 Application & LoRaWAN RN2xx3 Module

Library running on module
 Eliminates external MCU
 LoRaWAN™Class –A & –C
protocol support (rev 1.0)
 Source code library
Open Module Memory Estimation
 Microchip LoRaWAN™ Stack (minimal operation)

takes about:
 31kB of Flash
 1.3kB of RAM
 Estimation for PIC18LF46K22 (64kB ROM & 3kB RAM)
Memory ROM RAM

Estimation 43%
49%
51%
Free 57% Free
EU868 Occupied
Occupied
ROM RAM
NA915 Free 40% Free
45% 55% 60%
Occupied Occupied
LoRa® Roadmap Strategy
ARM-based Module – Available 2H’17
• Easy to use Modules SiP feature set in module form-factor
Size & cost optimized
• LoRa® Alliance Certified SAMR--M Enhanced crypto/authentication options
• Regulatory Certified
• Custom Code Development ARM-based SiP – Available 2H’17
• Reduce Cost and Size • Cortex® M0+ MCU + Radio
• Atmel Studio + ASF LoRa Library
• Low power Sleep
• Smallest form-factor
Open Modules or Discrete MCUs – Available Now!

• Application & LoRaWAN™ Library merged inside module
• Eliminates external MCU
• Delivered via MPLAB® X IDE + Microchip Code
Configurator (MCC)
• Also supports 1000’s of MCUs for discrete designs
Network Co-Processor (NCP) Modules – Certified & Available Now!
• LoRaWAN™ stack running on module
• Application running on external MCU
• Easiest path to integrate LoRaWAN™
Agenda
Part 1: Part 2: Part 3: Part 4:

IoT Sensor IoT Gateway Network Servers User Apps
Lab 1: Labs 2 & 3: Labs 4 & 5:

Read Temp Getting Data
LoRaWAN™ Serversfrom Creating a
IoT Device to User App
Server
Smart Human Board
General Purpose Pins
CCS811 – Air
quality Sensor
ENS210 – Humidity
and temp sensor
RN2903 – LoRa Module
PIC18F26J50
USB bridge
Power LED
Demo 1
Collect Data on
SmartHuman
Demo 1 Objectives
 Understand SmartHuman
 Collects temperature data from the
temperature sensor.
 Collects DevEUI and AppKey of RN2903
 Displays temperature, DevEUI, and
AppKey in terminal
Agenda
 Network Server: YEAP!
 Lab 1 – YEAP! Accounts
 Lab 2 – Connect SmartHuman to YEAP! and see data on the
dashboard
 Demo 2 – Node-RED Application
Lab 2
The Things Network
Lab 2 Objectives
 Create and log in to your TTN

account
 Create the Application that will be
used in future labs.
 Register your device within the
application (using devEUI and App
Key from Lab 1).
 View how gateways can be added.
Lab 2 Summary
 Our IoT gateway is connected to The Things

Network servers.
 A TTN account is required to connect your
device to TTN network servers.
 You create applications in the TTN Console to
collect data from your devices.
 Each device must be registered within an
application.
 You can register your own gateway or connect
to existing gateways.
Lab 3
Connect ExpLoRer to
Gateway and see data in
the TTN Dashboard
Lab 3 Objectives
 Add your appEUI (from TTN Console)

to the existing Arduino® sketch.
 Add code to existing Arduino sketch
in order to send temperature to TTN
Server.
 View your connected device’s data in
TTN Data tab.
Lab 3 Summary
 A network server will collect data from devices are that

are connected to gateways.
 With an appKey and appEUI, you can connect your
device to The Things Network if you are in range of a
gateway.
 The TTN Console allows you to see activity from your
devices and send downlink data to the device.
 The existing Arduino® sketch connected you to TTN.
 What you have so far:
Agenda
 Network Server: The Things Network
 Lab 2 – TTN Account (pre-created accounts)
 Lab 3 – Connect ExpLoRer to Gateway and see data in the TTN
Dashboard
 Lab 4 – Node-RED Application
 Lab 5 – Bonus: Two-Way Communication
Agenda
Part 1: Part 2: Part 3: Part 4:

IoT Sensor IoT Gateway Network Servers User Apps
Lab 1: Labs 2 & 3: Labs 4 & 5:

Read Temp Getting Data
LoRaWAN™ Serversfrom Creating a
IoT Device to User App
Server
LoRaWAN™ API
IoT API
Node-Red
Node-Red
 What is Node-Red
 Node-RED is a programming tool for wiring together
hardware devices, APIs and online services in new and
interesting ways.
 It provides a browser-based editor that makes it easy to
wire together flows using the wide range of nodes in the
palette that can be deployed to its runtime in a single-
click.
 JavaScript functions can be created within the editor
using a rich text editor.
 A built-in library allows you to save useful
functions, templates or flows for re-use.
Node-Red
Node-Red
 Built on Node.js
 The light-weight runtime is built on
Node.js, taking full advantage of its event-
driven, non-blocking model. This makes it
ideal to run at the edge of the network on
low-cost hardware such as the Raspberry Pi
as well as in the cloud.
 With over 225,000 modules in Node's
package repository, it is easy to extend the
range of palette nodes to add new
capabilities.
Node-Red
 What is Node.js?
 Node.js is a server-side platform built on Google
Chrome's JavaScript Engine (V8 Engine).
Node.js was developed by Ryan Dahl in 2009
and its latest version is v0.10.36.
 Node.js is an open source, cross-platform
runtime environment for developing server-side
and networking applications. Node.js
applications are written in JavaScript, and can
be run within the Node.js runtime on OS
X, Microsoft Windows, and Linux.
Node-Red
Image from: https://nodered.org/

 Various Nodes type
 Input
 Output
 Function
 Social
 Storage
 many more…
Node-Red
 Adding TTN node (flows.node-red.org)
Node-Red
 Launching Node-red
 Browsing
Node-Red
 First Demo creating first Flow
Node-Red
Node-Red
 Node “function” adds Javascript

coding
Node-Red
Node-Red
 More info at http://noderedguide.com/
Lab 4
Node-RED Application
Lab 4 Objectives
 Create/modify simple Node-RED

application that
 Runs on your local machine in a browser
 Collects temperature data from the TTN
server
 Graphs temperature data in Node-RED
 Lab 5 Bonus: Change color of RGB LED
on SODAQ.
Lab 4 Summary
 User applications use the data from

an IoT sensor to do something
useful.
 Node-RED applications can run on
your local machine or a server.
 Node-RED applications are quick
way to prototype web applications.
 What you have so far:
Summary
 Today we covered:
 How to collect temperature data with an
ARDUINO® Sketch.
 How a global LoRaWAN™ network like
The Things Network works.
 How to create a full IoT ecosystem by
sending data through the entire IoT data
path
Additional Resources
 LoRa® Alliance Website
 Setting up your own gateway and

endpoint with Microchip’s LoRa®
Technology Evaluation Kit
Dev Tools For This Class
 SODAQ ExpLoRer
 SODAQ ExpLoRer Support Page
 Purchase on MicrochipDirect
 Gateway
 The Things Network
 Microchip
Appendix
LoRa® RN2xx3 Module
Details
 General Features
 Fully integrated module
 On-board LoRaWAN™ Class A protocol stack
 ASCII Command Interface over UART
 UART Device Firmware Upgrade (DFU)
 Integrated MCU and Crystal
 EUI-64 Node Identity Serial EEPROM
 14 GPIOs
 Compact form factor: 17.8 x 26.7 x 3 mm
Block Diagram
Host MCU
RN2483 / RN2903
MCU
UART
Command Interface
LoRaWAN™ Protocol Stack

GPIO
I2C Real Time Clock SPI
14 EUI-64 32768 Hz LoRa® Technology

EEPROM Crystal Radio Transceiver
Status LEDs,
switches, External Antenna(s)
logic IOs, etc.
RN2483 LoRa® Technology Transceiver Module
433 MHz 868 MHz
RN2483
VDD
RFL RFH
GND
TX RX Status LEDs,
RX TX switches,
Host MCU UART GPIOs 14
CTS RTS logic IOs,
RTS CTS etc.
Note: Optional RTS and CTS control lines will be supported in future firmware releases.
RN2903 LoRa® Technology Transceiver Module
915 MHz
RN2903
VDD
RFH
GND
TX RX Status LEDs,
RX TX switches,
Host MCU UART GPIOs 14
CTS RTS logic IOs,
RTS CTS etc.
Note: Optional RTS and CTS control lines will be supported in future firmware releases.
Development Tools
RN-2483-MOTE
RN-2903-MOTE RN-2483-PICTAIL™
RN-2903-PICTAIL
LoRa® Technology Mote Block Diagram

Mote
OLED
Display
USB Host MCU
Mini-B
Connector USB SPI
EUSART
TMR1 RN2483/RN2903
LEDs GPIO Module
ADC
Push Light Temperature

Buttons Sensor Sensor
 Control Interface
 UART (TX/RX) communication
 Default Baud Rate: 57600, 8N1, no flow control
 Supports Auto Baud Detection
 Command Interface
 Human Readable Text
 Command Request => Command Reply / Replies
 Command Request initiated by Host MCU
 Command Reply initiated by the LoRa® Technology
Wireless Module
 Command Syntax
 Key word(s) issued, followed by optional parameter(s)
 Separated by space Character
 Key Word(s) Case Sensitive
 Parameter(s) Case Insensitive
 CR+LF Command Delimiter
 Command Request example:

< mac set devaddr 048E436e\r\n
 Command Reply example:
> ok\r\n
Command Interface
Command Interface
mac
radio LoRaWAN™ Protocol
sys Radio Driver
Hardware (GPIO, System Timer, etc.) Radio Hardware
Command Interface
mac : Issues LoRaWAN™ Class A protocol network

communication behaviors, actions and
configurations commands
Command Interface
mac
sys Radio Driver
mac : Issues LoRaWAN™ Class A protocol
network communication behaviors, actions
and configurations commands
LoRa® Technology Modules
< mac set devaddr 048E436E

> ok
< mac join abp

> ok
> accepted
Command Interface
radio : Issues radio specific configurations, directly

accessing and updating the transceiver setup
Command Interface
mac
sys Radio Driver
radio : Issues radio specific configurations, directly

accessing and updating the transceiver setup
< radio cw on
> ok
< radio get mod

> lora
Command Interface
sys : Issues system level behavior actions, gathers status
information on the firmware and hardware version, or
accesses the module user EEPROM memory
Command Interface
mac
sys Radio Driver
sys : Issues system level behavior actions, gathers status

information on the firmware and hardware version, or
accesses the module user EEPROM memory
< sys sleep 5000

> ok
< sys reset

> RN2483 0.9.5 Mar 24 2015 14:17:03
Appendix MQTT
Appendix MQTT
 machine-to-machine (M2M)/"Internet of
Things" connectivity protocol
 The protocol uses a publish/subscribe
architecture
 TCP/IP
MQTT methods
 Connect
 Waits for a connection to be established with the server.
 Disconnect
 Waits for the MQTT client to finish any work it must do, and for the TCP/IP session
to disconnect.
 Subscribe
 Waits for completion of the Subscribe or UnSubscribe method.
 UnSubscribe
 Requests the server unsubscribe the client from one or more topics.
 Publish
 Returns immediately to the application thread after passing the request to the MQTT
client.
MQTT QoS
 Quality of service
 QoS 0 – at most once
 The minimal level is zero and it guarantees a best effort
delivery. A message won’t be acknowledged by the receiver or
stored and redelivered by the sender.
 QoS 1 – at least once
 It is guaranteed that a message will be delivered at least once
to the receiver.
 QoS 2 – only once
 It guarantees that each message is received only once by the
counterpart.
MQTT LWT
 Last Will and Testament (LWT)

 Notify other clients about an ungracefully
disconnected client
 Broker will store the message until it
detects that the client has disconnected
ungracefully
 Each client can specify its last will
message
Command : MQTT
Device Broker
SUBSCRIBE
/$CMD/group_id/device_id/<cmd>
PUBLISH
/$CMD/group_id/device_id/<cmd>
acknowledgement (based on QoS)
PUBLISH
/$CMD/group_id/device_id/<cmd>/req_id
acknowledgement (based on QoS)
* $CMD as base for topics not

needed
MQTT
■ A topic forms the namespace
– Is hierarchical with each “sub topic” separated by a /
– An example topic space
• A house publishes information about itself on:
– <country>/<region>/<town>/<postcode>/<house>/energyConsumption
– <country>/<region>/<town>/<postcode>/<house>/solarEnergy
– <country>/<region>/<town>/<postcode>/<house>/alarmState
• And subscribes for control commands:
– <country>/<region>/<town>/<postcode>/<house>/thermostat/setTemp
■ A subscriber can subscribe to an absolute topic or can use wildcards:

– Single-level wildcards “+” can appear anywhere in the topic string
– Multi-level wildcards “#” must appear at the end of the string
– Wildcards must be next to a separator
– Cannot be used wildcards when publishing
– For example
• USA/Arizona/Chandler/51224/1/energyConsumption
– Energy consumption for 1 house in Chandler
• USA/Arizona/Chandler/+/+/energyConsumption
– Energy consumption for all houses in Chandler
• USA/Arizona/Chandler/51224/#
– Details of energy consumption, solar and alarm for all houses in 51224
LEGAL NOTICE
SOFTWARE:
You may use Microchip software exclusively with Microchip products. Further, use of Microchip software is subject to the copyright notices, disclaimers, and any license
terms accompanying such software, whether set forth at the install of each program or posted in a header or text file.
Notwithstanding the above, certain components of software offered by Microchip and 3rd parties may be covered by “open source” software licenses – which include
licenses that require that the distributor make the software available in source code format. To the extent required by such open source software licenses, the terms of
such license will govern.
NOTICE & DISCLAIMER:

These materials and accompanying information (including, for example, any software, and references to 3rd party companies and 3rd party websites) are for informational
purposes only and provided “AS IS.” Microchip assumes no responsibility for statements made by 3rd party companies, or materials or information that such 3rd parties
may provide.
MICROCHIP DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ANY IMPLIED WARRANTIES OF
NONINFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL MICROCHIP BE LIABLE FOR ANY DIRECT OR
INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL LOSS, DAMAGE, COST, OR EXPENSE OF ANY KIND RELATED TO THESE MATERIALS OR
ACCOMPANYING INFORMATION PROVIDED TO YOU BY MICROCHIP OR OTHER THIRD PARTIES, EVEN IF MICROCHIP HAS BEEN ADVISED OF THE
POSSIBLITY OF SUCH DAMAGES OR THE DAMAGES ARE FORESEEABLE. PLEASE BE AWARE THAT IMPLEMENTATION OF INTELLECTUAL PROPERTY
PRESENTED HERE MAY REQUIRE A LICENSE FROM THIRD PARTIES.
TRADEMARKS:
The Microchip name and logo, the Microchip logo, AnyRate, AVR, AVR logo, AVR
Freaks, BeaconThings, BitCloud, CryptoMemory, CryptoRF, dsPIC, FlashFlex, flexPWR, Heldo, JukeBlox, KEELOQ, KEELOQ logo, Kleer, LANCheck, LINK
MD, maXStylus, maXTouch, MediaLB, megaAVR, MOST, MOST logo, MPLAB, OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, Prochip
Designer, QTouch, RightTouch, SAM-BA, SpyNIC, SST, SST Logo, SuperFlash, tinyAVR, UNI/O, and XMEGA are registered trademarks of Microchip Technology
Incorporated in the U.S.A. and other countries.
ClockWorks, The Embedded Control Solutions Company, EtherSynch, Hyper Speed Control, HyperLight Load, IntelliMOS, mTouch, Precision Edge, and Quiet-Wire are
registered trademarks of Microchip Technology Incorporated in the U.S.A.
Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BodyCom, chipKIT, chipKIT
logo, CodeGuard, CryptoAuthentication, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching, DAM, ECAN, EtherGREEN, In-
Circuit Serial Programming, ICSP, Inter-Chip Connectivity, JitterBlocker, KleerNet, KleerNet logo, Mindi, MiWi, motorBench, MPASM, MPF, MPLAB Certified
logo, MPLIB, MPLINK, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, PureSilicon, QMatrix, RightTouch logo, REAL
ICE, Ripple Blocker, SAM-ICE, Serial Quad I/O, SMART-I.S., SQI, SuperSwitcher, SuperSwitcher II, Total
Endurance, TSHARC, USBCheck, VariSense, ViewSpan, WiperLock, Wireless DNA, and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A. and
other countries.
SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.
Silicon Storage Technology is a registered trademark of Microchip Technology Inc. in other countries.
GestIC is a registered trademark of Microchip Technology Germany II GmbH & Co. KG, a subsidiary of Microchip Technology Inc., in other countries.
All other trademarks mentioned herein are property of their respective companies.
© 2017, Microchip Technology Incorporated, All Rights Reserved.

Lora Iot Masters

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lora Iot Masters

Uploaded by

Copyright:

Available Formats

21080 IoT3

Connecting your IoT Device

When you walk out of this class you will be

Part 1: Part 2: Part 3:

Demo 1: Labs 1 & 2: Demo 2:

Part 1: Part 2: Part 3:

Demo 1: Labs 1 & 2: Demo 2:

Part 1: Part 2: Part 3:

Demo 1: Labs 1 & 2: Demo 2:

 What is LoRa® and LoRaWAN™

 What is LoRa® and LoRaWAN™

12500 Bitrate (BR) (bps)

Longest Distance on LoRa® Modulation

Highest Bit Rate on LoRa® Modulation

Longest Distance on LoRa® Modulation

Highest Bit Rate on LoRa® Modulation

 What is LoRa® and LoRaWAN™

Advanced Network Topology

Advanced Network Topology

Advanced Network Topology

Advanced Network Topology

Gateways Network Application

 What is LoRa® and LoRaWAN™

Transmit RX1 RX2

Transmit RX2 RX1 RX2

Extends RX2 until next TX

 What is LoRa® and LoRaWAN™

 Before an end-device can communicate on the

Let’s look at each of these in detail…

 To exchange this information, two activation

Network Session Key (NwkSKey)

Data Application Session Key (AppSKey) Data

 What is LoRa® and LoRaWAN™

End-Device Data Message does

Let’s look at an example…

1. Electric meter transmits data

2. Gateway receives data and passes to Network Server

3. The Network Server authenticates data and

4. Electric Meter Application Server decrypts data

End-Device Data Message has to be

Let’s look at an example…

1. Vending Machine transmits data.

2. Both gateways “pass through”

3. The Network Server forwards the data to

4. The Vending Machine Applications

5. The Network Server selects the best path (gateway) to

6. The Gateway transmits the

Application Server Data Message

If the Application Server has a Data Message

Let’s look at an example…

1. The Smoke Detector Application Server has

2. However, it has to wait until the Smoke Detector

3. When the Smoke Detect transmits,

4. Passed through the Gateway…

5. … and the Network Server sends to the

6. The Smoke Detector Application Server can now

7. The Network Server sends the Data Message

8. The Data Message is transmitted to the Smoke

 What is LoRa® and LoRaWAN™

 RN2483 LoRa® Technology

 RN2903 LoRa® Technology

 Application & LoRaWAN RN2xx3 Module

 Microchip LoRaWAN™ Stack (minimal operation)

Memory ROM RAM