Accelerate Long-Range Wireless Connectivity Design with a LoRaWAN System-in-Package

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

In remote sensing applications that require low-cost, long-range, low-power wireless connectivity, LoRa technology has found favor over alternatives such as Bluetooth and Wi-Fi. Still, developers continue to struggle with the nuances of RF design to cost effectively and quickly implement LoRa designs that maximize range and data rates without violating the limited power budgets available to typical IoT systems.

To accelerate LoRa-based design, silicon vendors have developed full system-in-package (SiP) modules and related LoRaWAN software stacks as near drop-in solutions for long-range connectivity.

This article will briefly discuss the LoRa approach before introducing suitable hardware and software solutions and how designers can use them to get a design up and running quickly.

Long-range IoT networks

LoRa, short for long-range, defines an ultra-efficient, low-cost, low-power, proprietary, spread spectrum radio. Its ability to support battery-operated sensors and other low-power applications makes it particularly well suited to IoT applications operating at distances beyond Wi-Fi or Bluetooth ranges. LoRa-based designs can operate for years on a small battery while reliably providing secure connectivity to very large networks stretching across kilometers.

LoRaWAN is a media access control (MAC) layer that sits atop the LoRa radio interface that defines how the network operates and sets the data rates (typically up to 50 Kbits/s) (see, LoRaWAN Part 1: How to Get 15 km Wireless and 10-Year Battery Life for IoT). Operating in a star network topology, the LoRaWAN wide area network architecture uses gateways to relay messages between multiple end devices such as IoT sensors and a host server (Figure 1). A LoRa radio can be used separately, with an alternative MAC layer to LoRaWAN, but that interface will not be compliant with the LoRaWAN specification.

Diagram of LoRaWAN specification

Figure 1: The LoRaWAN specification provides for authenticated, encrypted communications between end devices and network servers, using gateways to bridge long-range connectivity with end devices and wide area connectivity with network hosts in the cloud or dedicated environments. (Image source: LoRa Alliance)

In this architecture, end devices and host servers communicate through gateway devices, which can be configured to serve simply as communication bridges. To communicate with host servers, the gateway uses conventional connectivity options such as Wi-Fi, Ethernet, or cellular. To communicate with end devices, the gateway relies on the ability of the Semtech proprietary LoRa physical (PHY) layer to achieve reliable long-range connectivity using sub-gigahertz (GHz) bands. In either case, LoRaWAN protects end-to-end communications with AES encryption using network session or application session keys that can be created during production, during commissioning, or through over-the-air (OTA) activation.

In a LoRaWAN network, all communication with end devices is bidirectional, but the LoRaWAN protocol specification provides three different end device classes that let developers essentially balance power consumption against response latency. Class A end devices can receive only during two short downlink receive windows following each of their transmissions. By limiting active receiver periods, Class A devices serve well for power constrained devices such as IoT sensors. Class B combines Class A with additional receive windows. As such, this class is appropriate for IoT actuator devices that need to respond with reduced latency to host requests even at the cost of increased Rx power consumption. Finally, Class C devices provide nearly continuous open receive windows and are well suited for use in LoRaWAN gateways.

In looking to optimize LoRaWAN security, power reduction, and long-range connectivity, developers can find their efforts delayed by the myriad details required to configure the hardware platform and software systems. However, hardware and software from Microchip Technology simplifies implementation of LoRaWAN networks, providing a near drop-in solution for deploying LoRa technology.

Low-power integrated solution

The SAM R34/35 system-in-package (SiP) modules from Microchip combine a low-power Arm® Cortex®-M0+ , Semtech SX1276 transceiver, flash, RAM, special low power (LP) RAM, and a comprehensive collection of the kinds of peripherals typically required in sensor systems (Figure 2). Along with custom configurable logic modules, the SAM 34/35 include a multichannel 12-bit analog-to-digital converter (ADC), analog comparators, and multiple serial communication modules that can be programmed to support I2C, SPI, and other serial interfaces. The SAM R34 and R35 SiPs differ only in that the R35 does not provide the USB interface included with the R34. Other than that difference, the 6 x 6 millimeter (mm) SAM R34/35 modules are the same in three different memory configurations:

Diagram of Microchip Technology SAM R34/R35 system-in-package module

Figure 2: The Microchip Technology SAM R34/R35 system-in-package module combines a low-power Arm Cortex-M0+ processor core, Semtech SX1276 transceiver, memory, and multiple peripherals, excluding USB in the SAM R35. (Image source: Microchip Technology)

Designed specifically for low-power applications, the SiP modules provide multiple software selectable options for reducing power during periods of lower functional activity. Developers can set the SAM R34/R35 to operate at two different performance levels. At the higher performance level, PL2, the device core operates at the highest voltage, allowing the device to run at high clock speeds. At the lower performance level, PL0, the core voltage level is scaled with reduced operating frequency, reducing overall power consumption.

At a given performance level, developers can also programmatically switch the device to operate in different power modes. In idle mode, the module consumes only 4.5 milliamperes (mA) with short periods of peak demand reaching 28 mA for Tx and 10.3 mA for Rx. Developers can drop module power consumption to 1.4 microamperes (µA) by placing the module in standby mode, which turns off all clocks and functions except those specifically programmed to maintain their activity. Additionally, the modules support SleepWalking operation which allows selected peripherals to respond to events independently of the processor, perform peripheral operations, and wake the processor only if required. To reduce power during extended periods of inactivity, developers can place the module in sleep mode, which consumes only 790 nanoamperes (nA). Microchip cautions against placing the device in its off state due to metastability conditions arising from high impedance on the internal SPI bus.

Design implementation

Thanks to the modules’ integration functionality, hardware interface requirements are simple. Other than decoupling capacitors for the SAM R34/R35 SiP, developers only need to add a signal switch such as the Skyworks Solutions SKY13373 and passive components required to complete the transmit and receive RF signal paths (Figure 3).

Diagram of Microchip Technology SAM R34/R35 module (click to enlarge)

Figure 3: With a Microchip Technology SAM R34/R35 module, developers need a few additional components beyond those required for the RF signal path and associated RF switch, such as the Skyworks Solutions SKY13373. (Image source: Microchip Technology)

Developers can avoid even these simple additional hardware requirements by using the Microchip Technology DM320111 SAM R34 Xplained Pro evaluation kit. Developers can use the kit to begin immediately evaluating the SAM R34 or extend the hardware reference design for their custom devices.

Microchip also helps speed software development through a combination of SAM R34/R35 module firmware and sample software which is available with the Atmel Studio 7 integrated development environment. Building on the integrated Semtech SX1276 LoRa transceiver and PHY, the SAM R34/R35 SiPs provide a certified LoRaWAN implementation through their built-in Microchip LoRaWAN Stack (MLS) (Figure 4).

Diagram of Microchip LoRaWAN Stack (MLS)

Figure 4: Through a set of application programming interfaces (APIs), the Microchip LoRaWAN Stack (MLS) provides developers with firmware services for MAC, PHY, persistent storage, power management, and more. (Image source: Microchip Technology)

Based on the Microchip Advanced Software Framework (ASF) of device drivers and core modules, MLS firmware provides application programming interfaces (APIs) for each of its services including:

  • LoRaWAN MAC, which provides the LoRaWAN MAC layer functionality
  • LoRaWAN Radio Layer (TAL), which provides access to the LoRa transceiver
  • Persistent Data Server (PDS), which provides a service layer to Flash memory, reducing access time and access cycles for retrieving MLS parameters
  • Power Manager Module (PMM), which places the processor in sleep mode during inactive periods
  • Hardware Abstraction Layer (HAL), which shields code from hardware specifics
  • Timer libraries
  • Scheduler, which allocates processor resources to the different modules

Using API functions, developers can exert fine control over every aspect of the module’s functionality. For example, to put the module in sleep mode, developers call the PMM API function, PMM_Sleep(), which takes a sleep request structure containing sleep time, sleep mode (idle, standby, sleep, or off), and a completion callback function (Listing 1). Within an application, developers would typically call this function after each task. For example, the Microchip ASF distribution includes a sample end device application that uses this approach within an endless loop (Listing 2). Each MLS API provides similar entry points to MLS firmware services.

/* Structure of sleep request */
typedef struct _PMM_SleepReq_t
       /* Sleep time requested to PMM. Unit is milliseconds */
       uint32_t sleepTimeMs;
    /*  Sleep Modes */
       HAL_SleepMode_t sleep_mode;
       /* Callback from sleep request */
       void (*pmmWakeupCallback)(uint32_t sleptDuration);
} PMM_Sleep

Listing 1: The Microchip Advanced Software Framework (ASF) distribution provides sample software that demonstrates key design patterns and data structures such as this struct used in putting the Microchip Technology SAM R34/R35 module into a sleep state. (Code source: Microchip Technology)

    while (1)
        if (false == certAppEnabled)
            if(bandSelected == true)
                PMM_SleepReq_t sleepReq;
                /* Put the application to sleep */
                sleepReq.sleepTimeMs = DEMO_CONF_DEFAULT_APP_SLEEP_TIME_MS;
                sleepReq.pmmWakeupCallback = appWakeup;
                sleepReq.sleep_mode = CONF_PMM_SLEEPMODE_WHEN_IDLE;
                    deviceResetsForWakeup = false;
                if (true == LORAWAN_ReadyToSleep(deviceResetsForWakeup))
                    if (PMM_SLEEP_REQ_DENIED == PMM_Sleep(&sleepReq))

Listing 2: Microchip sample software illustrates how developers can use a few API calls to return a Microchip Technology SAM R34/R35 module to a low-power state during inactive periods. (Code source: Microchip Technology)

Sample code available through Studio 7 or separately through the ASF distribution provides a comprehensive demonstration of use of MLS API calls in implementing a LoRaWAN application. A demonstration of end device implementation illustrates important high level operations including initializing a device by retrieving previously stored MLS attributes and parameters from the PDS persistent data server service (Listing 3). Other sample software provides a suite of test routines that allow developers to examine detailed LoRaWAN performance characteristics and the MLS API calls used to extract those values. Using the Microchip software samples in combination with the SAM R34 Xplained Pro evaluation kit, developers can quickly gain experience with LoRaWAN operations in general and the Microchip firmware service in particular.

\brief    Initialization the Demo application
void mote_demo_init(void)
    bool status = false;
    /* Initialize the resources */
       /* Read DEV EUI from EDBG */
       startReceiving = false;
    /* Initialize the LORAWAN Stack */
    LORAWAN_Init(demo_appdata_callback, demo_joindata_callback);
    printf("\n\rMicrochip LoRaWAN Stack %s\r\n",STACK_VER);
    printf("\r\nInit - Successful\r\n");
    status = PDS_IsRestorable();
        static uint8_t prevBand = 0xFF;
        uint8_t prevChoice = 0xFF;
        for (uint32_t i = 0; i < sizeof(bandTable) -1; i++)
            if(bandTable[i] == prevBand)
                prevChoice = i;
        printf ("Last configured Regional band %s\r\n",bandStrings[prevChoice]);
        printf("Press any key to change band\r\n Continuing in %s in ", bandStrings[prevChoice]);
        SwTimerStart(demoTimerId,MS_TO_US(1000),SW_TIMEOUT_RELATIVE,(void *)demoTimerCb,NULL);
              appTaskState = DEMO_CERT_APP_STATE;

Listing 3: This snippet from a Microchip end device sample application illustrates the basic design pattern associated with initializing a device, including restoring LoRaWAN attributes if available (PDS_IsRestorable()) from the PDS persistent data server. (Code source: Microchip Technology)


LoRa technology is particularly well suited for addressing an emerging need for long-range connectivity for battery powered IoT sensors. In the past, however, developers were left to develop significant portions of hardware and software subsystems. With their integrated hardware and firmware, Microchip SAM R34/R35 SiP modules effectively eliminate many of the detailed design requirements associated with earlier approaches. Used in combination with Microchip LoRaWAN-based hardware and software, developers can rapidly implement battery powered IoT devices and low-power gateways able to achieve long-range, secure communications with host servers in the cloud or in dedicated environments.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors