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 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 – | Eval Kit.

SAMR34.png

The WLR089U0 modules are based on the ultra-low power, highly integrated SAM R34/35 family of LoRa ICs. This standalone module integrates 256KB of Flash and 40 KB RAM providing enough memory for 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 (figure 2) 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 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 – Eval Kit.

WLR089XplainedPro.png

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 layer 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 following figure shows the typical system architecture of a LoRaWAN™ application:

LoRaWANArchitecture.png

End-devices are simple objects such as sensors, 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 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 server, and application servers communicate over an IP backhaul linked using Ethernet, 3G, LTE, and so on.

LoRaWAN® Message Types

  • Downlink – 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 following figure shows the data transmission and reception sequence for a typical Class A end-device:

ClassA.png
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 the 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 following figure shows the data transmission and reception sequence for a typical Class B end-device:

ClassB.png
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 following figure shows the data transmission and reception sequence for a typical Class C end-device as per LoRaWAN Specification 1.0.2:

ClassC.png
Class C 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 shall switch 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.

ClassC.jpg
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 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)
OTAA.png

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
ABP.png

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.

8byteAddress.png
Board2.png

Provisioning LoRa End-Device to Network Servers

Provisioning.png

The Things Network

Device communication via The Things Network can be enabled by registering it with an application.

Steps to register an end-device

1

Log in and open the console.

2

If an application is not created, you need to create one.

3

Open the already existing or new application created and click on Register Device.

4

Choose a Device ID.

5

For Device EUI, enter the 8-byte unique MAC address available on the SAMR34 XPRO.

6

The App Key can be generated by The Things Network, leave this option to auto-generate the App Key.

7

There will be a predefined App EUI, leave this option.

8

Click Register to complete the device registration. You will be redirected to the newly registered device.

Default join procedure for The Things Network server is OTAA.

TheThingsNetwork.png

The Senet Network

End-device communication via The Senet Network can be enabled by registering the SAMR34 XPRO.

Steps to register an end-device

1

Log in and open the senet developer portal.

2

Click on the Add button and click Register Device.

Add.png

3

For Device EUI, enter the 8-byte unique MAC address available on SAMR34 XPRO.

4

Activation Type is OTAA by default.

5

Enter the description of the end-device.

6

Choose other as the Device Type.

7

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.

SenetNetwork.png

Actility-TheThingPark

Device communication via TheThingPark can be enabled by creating a device in the ThingPark Developer Portal.

Steps to register an end-device

1

Log in and open the ThingParkDeveloper portal, then click on Dashboard.

2

Click on Device Manager > Devices > Create.

CreateDevice.png

3

A new pop-up window with four sections appears– Administrative data, Device identification, Network parameters, and Application layer handling. Fill in all the information for the Administrative data section.

4

In the Device identification section, all fields are mandatory. Choose Manufacturer –Generic and Model – LoRaWAN 1.0.2 revAclass AFCCRx2_SF12 us915, au915 option.

Model needs to change based on Microchip LoRaWAN™ stack being used.

Default join procedure for TheThingPark Network server is OTAA.

5

For Device EUI, enter the 8-byte unique MAC address available on SAMR34 XPRO.

6

For App Key, enter an application key of choice. The application key must be 16 bytes long.

7

For Join EUI/App EUI, enter an application EUI of choice. The application key must be 8 bytes long.

When entering Device EUI, App Key, and Join EUI/App EUI - each byte must be separated by a hyphen.

8

In the Network Parameters section, choose Connectivity plan – DEV Connectivity Supplier / Unlimited Dev (5) and DevAddr – Allocated by the network server.

9

Click Create to complete the device registration.

NewDevice.png

To view the newly created device, click on Devices > List.

DeviceList.png

Machine Q

Device communication via Machine QTM can be enabled by registering a device to the mqcentral portal.

Steps to register an end-device

1

Log in and open the mqcental dashboard.

2

Click on Devices followed by Add A Device.

AddDevice.png

3

A new pop-up window appears which requires you to enter the following mandatory information- Name, DevEUI, Service Profile, Device Profile, Dec, Application Key, and Application EUI.

4

Choose a name and select Service Profile – default and Device Profile – LoRaWAN-1.0.2-class A-FCC-20dBm.

Device Profile needs to change based on the Microchip LoRaWAN stack being used.

5

Select Over the air activation.

6

For Device EUI, enter the 8-byte unique MAC address available on SAMR34 XPRO.

7

For App Key, enter an application key of choice. The application key must be 16 bytes long.

8

For App EUI, enter an application EUI of choice. The application key must be 8 bytes long.

When entering Device EUI (16 characters), App Key (32 characters), and App EUI (16 characters) – hexadecimal values are only allowed with no separation between the consequent bytes.

9

Click Submit to complete the device registration.

Submit.png

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

1

Pick a server based on the geographic location preference, log in and open the LORIOT dashboard.

Dashboard weblink will be created based on geographic location preference chosen when registering an account.

2

Click on the Application option from the dashboard, then click SampleApp.

SampleApp.png

If you need to create a new application, this can be done by choosing Application > New Application.

You need to upgrade your account for creating a new application.

3

Open the already existing or newly created application and click on Enroll Device.

EnrollDevice.png

4

The Enroll a new device window will appear. It is mandatory to enter the following information - LoRaWAN Version, Enrollment process (join type), Device Location, Device Details – Title, Device EUI, Application EUI, and Application Key.

5

Choose a LoRaWAN Version – LoRaWAN 1.0.x, select the Enrollment process – OTAA and Device Location.

LoRaWAN version needs to change based on the Microchip LoRaWAN stack being used.

6

In the Device Details section, choose a Title for the end-device.

7

For Device EUI (Device Details section), enter the 8-byte unique MAC address available on SAMR34 XPRO.

8

For App Key (Device Details section), enter an Application Key of choice. The application key must be 16 bytes long.

9

For App EUI (Device Details section), enter an Application EUI of choice. The application key must be 8 bytes long.

When entering Device EUI (16 characters), App Key (32 characters), and App EUI (16 characters) – hexadecimal values are only allowed with no separation between the consequent bytes.

10

Click Enroll to complete the end device registration.

Enroll.png

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

1

New users of Everynet will receive an email invitation to the portal. On first entry, the portal will prompt you to create a password and log in to the console.

2

Under the Devices view, click on the Add icon.

EverynetAdd.png

3

Enter a name for ‘tag’. All objects/end-devices in the server can be assigned tags for easy search. Multiple tags can be assigned to a device.

4

For Device EUI, enter the 8-byte unique MAC address available on SAMR34 XPRO.

5

Choose an App Key for the application.

6

Choose an App EUI for the application.

7

Choose join type – OTAA.

8

Click Save to complete the end device registration.

EverynetSave.png

For more information, click here.

Everynet.png

Provisioning Gateway to Network Servers

Provisioning of LoRaWAN gateways to Network Service providers is out of scope for 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.

ProvisioningGateway.png

Here is the sampling of commercial LoRaWAN gateways, available for purchase. These links also include instructions to provision them.

  1. The Things Gateway
  2. Laird™ RG1xxProvisioning Steps
  3. Kerlink®
  4. Multitech®Provisioning Steps
  5. Cisco® LoRaWAN GatewayProvisioning Steps

Application Configuration

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.

AppConfig.png

1

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

2

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

3

This application mentions the port for uplink data.

#define DEMO_APP_FPORT 1

4

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.

By default, EDBG_EUI_READ is defined in the project properties as symbols.

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}

5

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}

6

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}

7

Ensure class A device is defined.

#define DEMO_APP_ENDDEVICE_CLASS CLASS_A

8

Gateways usually only support 8+1 channels (also known as a SUBBAND). The NA/AU Regional band has 64+8 channels. Therefore, there are eight SUBBANDs in the case of NA/AU region. The application by default is configured to work in SUBBAND 1. Change the SUBBAND value according to the gateway/NS configuration.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.