Connecting a SAM R34 SiP/SAM R34 Module LoRaWAN® End Device to a LoRaWAN Network Server
Objective
The SAM R34/R35 is a highly-integrated LoRa® System-in-Package (SiP) family which includes an ultra-low power, high-performance 32-bit microcontroller (MCU), LoRa transceiver, and software stack. SAM R34 devices support LoRaWAN® long-range wireless protocol.
The SAM R34 Xplained Pro is a hardware platform designed to evaluate the SAM R34 family of LoRa devices. This FCC-, ISED-, and RED-certified board is not only an evaluation platform but also an excellent reference design for developing SAM R34-based LoRa end-node applications. This kit is supported by Microchip Studio, an integrated development platform, which provides predefined application examples. The evaluation kit also provides easy access to various features of the ATSAMR34J18B device and offers additional peripherals to extend the features of the board and ease the development of custom designs.
The WLR089U0 modules are based on the ultra-low power, highly integrated SAM R34/35 family of LoRa ICs. This standalone module integrates 256 KB of Flash and 40 KB RAM providing enough memory for the LoRaWAN stack as well as for the application user code. The module includes an on-board u.FL antenna connector for ease of use and comes in a compact 17.5 x 13 mm package making it ideal for space-constrained battery-powered applications.
The WLR089 Xplained Pro is a hardware platform designed to evaluate the WLR089U0 LoRa modules. This kit integrates the FCC-, RED- and ISED-certified WLR089U0 module but also an excellent reference design for developing SAM R34 module-based LoRa end-node applications. This kit is supported by Microchip Studio, an integrated development platform, which provides predefined application examples. The evaluation kit also provides easy access to various features of the WLR089U0 device and offers additional peripherals to extend the features of the board and ease the development of custom designs.
The features of the SAM R34/R35 and WLR089U0 enable their use as end devices in wide-area networks like LoRaWAN. LoRaWAN is a Media Access Control (MAC) protocol for wide-area networks. It is designed to enable low-powered devices to interact with internet-connected applications over long-range connections. LoRaWAN can be mapped to the second and third layers of the OSI model. It makes use of LoRa or FSK modulation in Industrial, Scientific, and Medical (ISM) radio bands. The LoRaWAN protocols are defined by the LoRa Alliance® and formalized in the LoRaWAN Specification which can be downloaded from the LoRa Alliance website.
LoRaWAN Architecture
The accompanying figure shows the typical system architecture of a LoRaWAN application:
End devices are simple objects such as sensors and actuators, and are the “things” in the Internet of Things. An end device communicates to the network server through one or more gateways. The gateway acts as a concentrator for the end devices and relays the data between the end devices and the network server. The wireless connection between an end device and the gateway is set up through a LoRa wireless link. The gateways, network servers, and application servers communicate over an IP backhaul linked using Ethernet, 3G, LTE, and so on.
LoRaWAN® Message Types
- Downlink – The transmission of a packet from a gateway to an end device is known as downlink. These transmissions can be requested by a network or application server.
- Uplink – Transmission of a packet from the end device to a gateway is known as uplink.
LoRaWAN End Device Types
Battery Powered - Class A (All Devices)
Every transaction in a Class A end device starts with an uplink transmission, which is then followed by two downlink-receive windows. The network server sends the downlink message after receiving the uplink. At the end of the downlink message, the end device enters Sleep mode, thereby saving power. Therefore, Class A devices consume the least power and provide a long battery life. All LoRaWAN end devices support Class A by default. The accompanying figure shows the data transmission and reception sequence for a typical Class A end device.
Class A Tx/Rx sequence
Low Latency - Class B (Beacon)
In Class A, the downlink is non-deterministic since it depends on random uplinks from a sleeping end device. In Class B, the end device reduces the downlink latency by opening periodic downlink receive windows. The periodicity of the downlink windows is maintained by synchronizing the clocks of the end device and the network server. For synchronization, the network server commands the gateways to send a beacon at regular intervals. During uplink, the Class B end device behaves similarly to a Class A end device. The Class B end device manages to reduce power consumption and yet reduces the downlink latency. The accompanying figure shows the data transmission and reception sequence for a typical Class B end device.
Class B Tx/Rx sequence
No Latency - Class C (Continuous)
Except for the uplink period, the end device in Class C continuously opens the receive windows, which reduces latency, but increases its power consumption considerably. The accompanying figure shows the data transmission and reception sequence for a typical Class C end device as per LoRaWAN Specification 1.0.2.
Class B Tx/Rx sequence
As per LoRaWAN Specification 1.0.4, a Class C-enabled end device listens as often as possible using a combination of channel/DR parameters referred to as RXC. It opens the RXC window starting from the end of the uplink transmission and the beginning of the RX1 reception window, another between the end of the RX1 window and the beginning of the RX2 window, and it switches to RXC reception parameters as soon as the RX2 reception window is closed, which remains open until the end device begins to send another packet.
Class C Tx/Rx sequence
Join Types
End devices can join a LoRaWAN network using two methods
Over-The-Air Activation (OTAA)
- End device transmits a Join Request to the application server containing:
- Globally unique end device identifier (DevEUI).
- Join server Extended Unique Identifier (JoinEUI)/Application identifier (AppEUI), and
- Authentication with Application key (AppKey).
- End device receives Join Accept from the application server.
- End device authenticates Join Accept.
- End device decrypts Join Accept.
- End device extracts and stores Device Address (DevAddr).
- End device derives security keys:
- Network Session Key (NwkSKey).
- Application Session Key (AppSKey).
Activation by Personalization (ABP)
- The following information is configured at production time:
- Device Address (DevAddr)
- Network Session Key (NwkSKey)
- Application Session Key (AppSKey)
- No over-the-air handshaking.
- Device is ready to communicate on the network without any additional procedure.
In production, we recommend you use OTAA. OTAA is more reliable since the activation will be confirmed and more secure. Session keys are agreed upon with every activation. ABP can be used when doing demos or workshops
Unique 8-byte Address Available on ATSAMR34-XPRO
A unique 8-byte address is available on the back side of SAM R34 XPRO. This can be used as DevEUI when considering an OTAA join type.
Provisioning LoRa End Device to Network Servers
The Things Network
Device communication via The Things Network can be enabled by registering it with an application
Steps to register an end device
Click Register to complete the device registration. You will be redirected to the newly registered device.
The Senet Network
End device communication via The Senet Network can be enabled by registering the SAMR34 XPRO
Steps to register an end device
Click on the Add button and click Register Device.
Click Register New Device to complete the device registration.
You will be redirected to the newly registered device. The App Key and App EUI will be auto-generated.
Actility-TheThingPark
Device communication via TheThingPark can be enabled by creating a device in the ThingPark Developer Portal
Steps to register an end device
Click on Device Manager > Devices > Create.
In the Device identification section, all fields are mandatory. Choose Manufacturer –Generic and Model – LoRaWAN 1.0.2 revA – class A – FCC – Rx2_SF12 us915, au915 option.
For Join EUI/App EUI, enter an application EUI of choice. The application key must be 8 bytes long.
Click Create to complete the device registration.
To view the newly created device, click on Devices > List.
MachineQ™
Device communication via MachineQTM can be enabled by registering a device to the mqcentral portal.
Steps to register an end device
Click on Devices followed by Add A Device.
Choose a name and select Service Profile – default and Device Profile – LoRaWAN-1.0.2-class A-FCC-20dBm.
For App EUI, enter an application EUI of choice. The application key must be 8 bytes long.
Click Submit to complete the device registration.
You will be redirected to the newly registered device.
LORIOT
Device communication via LORIOT can be enabled by registering the end device to a LORIOT application.
Steps to register an end device
Pick a server based on the geographic location preference, login, and open the LORIOT dashboard.
Click on the Application option from the dashboard, then click SampleApp.
If you need to create a new application, this can be done by choosing Application > New Application.
Open the already existing or newly created application and click on Enroll Device.
Choose a LoRaWAN Version – LoRaWAN 1.0.x, and select the Enrollment process – OTAA and Device Location.
For App EUI (Device Details section), enter an Application EUI of choice. The application key must be 8 bytes long.
Click Enroll to complete the end device registration.
You will be redirected to the newly registered end device.
Everynet
Device communication via Everynet can be enabled by registering the end device
Steps to register an end device
Under the Devices view, click on the Add icon.
Click Save to complete the end device registration.
Provisioning Gateway to Network Servers
Provisioning of LoRaWAN gateways to Network Service providers is out of the scope of this tutorial.
LoRaWAN Gateways and their installation guides are supplied by the gateway manufacturer. Your choice of network server drives which commercial LoRaWAN gateway you should purchase.
Here is the sampling of commercial LoRaWAN gateways, available for purchase.
Application Configuration
This section provides you with information on how to configure the SAM R34-based LoRaWAN application examples on Advanced Software Framework 3 (ASF3) to be able to join the network server/join server based on the provisioning parameters used to register/enroll a device.
Every application example on ASF3 pertaining to the SAM R34 device/WLR089U0 module has an application configuration file called conf_app.h, which is available at PACKAGE_ROOT/src/config.
This application provides the method of end device activation.
#define DEMO_APP_ACTIVATION_TYPE OVER_THE_AIR_ACTIVATION //#define DEMO_APP_ACTIVATION_TYPE ACTIVATION_BY_PERSONALIZATION
This application provides the message type for sending data from the end device.
#define DEMO_APP_TRANSMISSION_TYPE UNCNF //#define DEMO_APP_TRANSMISSION_TYPE CNF
This application mentions the port for uplink data.
#define DEMO_APP_FPORT 1
This application can modify or set the DevEUI (64-bit) to be used with OTAA. The SAMR34 Xplained Pro board has the DevEUI stored in its EDBG controller; the user has to define EDBG_EUI_READ as 1 to read the DevEUI from edbg and to set it. Otherwise, the value DEMO_DEVICE_EUI configured in conf_app.h will be used as a DevEUI.
The WLR089 Xplained Pro board has the DevEUI stored in its internal flash; the user has to define MODULE_EUI_READ as 1 to read the DevEUI from Flash and to set it. Otherwise, the value DEMO_DEVICE_EUI configured in conf_app.h will be used as a DevEUI.
By default, MODULE_EUI_READ is defined in the project properties as symbols.
#define DEMO_DEVICE_EUI {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07}
The application can modify or set the AppEUI (64-bit) to be used with OTAA.
#define DEMO_APPLICATION_EUI {0xDA, 0xBB, 0xAD, 0x00, 0xDA, 0xBB, 0xAD, 0x00}
This application can modify or set the AppKey (128-bit) to be used with OTAA.
#define DEMO_APPLICATION_KEY {0xBA, 0xAD, 0xF0, 0x0D, 0xBA, 0xAD, 0xF0, 0x0D, 0xBA, 0xAD,
0xF0, 0x0D, 0xBA, 0xAD, 0xF0,0x0D}
Ensure class A device is defined.
#define DEMO_APP_ENDDEVICE_CLASS CLASS_A
