Developing for IoT

The purpose of this page is to gather together the various development topics from across this site – and with the scope being to introduce a range of topics, rather than presenting exhaustive information on particular topics. The breadth and depth of the fields of IoT-related development make it a vast subject. But we hope that for those just beginning development targetting our IoT networks will find the material here to be useful.

Hardware and Firmware Development

If you are just beginning to develop your own end-device hardware then one of the evaluation boards listed below may be a good place to start. And when developing firmware, full sourcecode is available for many of these boards – though regulatory requirements of other regions mean that some of the radio-protocol firmware is not available for some of these devices. Custom devices may need to be certified before they can be sold, and modifications to end-device firmware may also require compliance testing; e.g., to ensure that an end-device is still (LoRaWAN) AS923 compliant.

Evaluation Boards

A first step to beginning to develop end-devices for our LoRaWAN and/or CatM1 networks is to source suitable development modules that support our regional & network parameters. This section presents modules that we have evaluated ourselves, though they may not necessarily be suitable for your particular application – there can be many factors to consider when selecting a development platform, including non-hardware related issues like familiarity with certain programming languages, environments, and toolchains.

We are always evaluating new end-devices and development modules, and there are more devices to come. And the current list of EVB’s that we have evaluated ourselves includes the following devices:

LoRaWAN Evaluation Boards

LoRaWAN modules that have achieved AS923 LoRaWAN compliance, and that we have used, are listed here – these modules should serve as excellent development platforms. Their manufacturers provide thorough documentation, sourcecode & examples, and there are active online communities for users of these devices.

LTE CatM1 Evaluation Boards

This section contains information and how-to articles on how to use specific CatM1 modules. Below are the list of evaluation boards that has been provisioned and tested to work with Spark’s LTE CatM1 network.

Spark Certified IoT Cellular Modules

This section contains information of the IoT Cellular Modules that have completed Spark’s permit to connect process. Below are the list of modules that have been provisioned and tested to work with Spark’s IoT cellular network - Spark’s LTE CatM1 network.

LTE CAT M1 Modules

4G LTE Modules

3G UMTS Modules

Provisioning the Evaluation Modules

Below are links to guides that show how to provision LoRaWAN end-devices to work on our network. In addition to this general provisioning information provided:

on this site, there are also instructions for each EVB – these provide additional, device-specific tips when using one of the LoRaWAN modules listed above.

A general tip is that (except for the MultiTech mDot which does have a device profile), you should select Generic for the device manufacturer, and LoRaWAN 1.0.2 - class A - Rx2_SF10 as923 for the model. Because each end-device needs both an AppEUI and a AppKey to be provisioned (to connect via OTAA), you should refer to the instructions that are given on each of the pages for these modules.

LoRaWAN Firmware Development

LoRaWAN modules that we have used, and that have achieved AS923 LoRaWAN compliance are listed above. Whether you are just starting out learning LoRaWAN, developing IoT end-devices, or even contributing to the development of LoRaWAN MAC firmware – these modules should serve as excellent development platforms. Their manufacturers provide thorough documentation, sourcecode & examples, and there are active online communities for users of these devices.

The full source code is available for the both the Semtech SX1276 driver, and for the firmware of the LoRaWAN MAC layer (LoRaMac Github repository) and its API. Along with other manufacturers, STMicroelectronics provide a STM32Cube Expansion LRWAN distribution that includes a modified version of this source-code that can be used to develop LoRaWAN firmware for their hardware.

A suitable AS923 EVB (Evaluation Board) will allow you to begin to develop your own custom firmware for your LoRaWAN end-devices. A suitable compiler toolchain, along with board description files, and suitable libraries, will be required to develop your own firmware. These are covered below.

Note on AS923 Compliance

For some devices; e.g., the STMicroelectronics Discovery B-L072Z-LRWAN1, the full source code is available for the both the LoRa transceiver driver (e.g., SX1276), and for the LoRaWAN MAC and its API, whereas other manufacturers may provide just a binary file for this functionality. Full availability of the source code allows the behaviour of the MAC & LoRa transceiver to be modified, and potentially resulting in non-AS923 behaviour for an end-device. Therefore, any (non-approved) modifications to the source code of the MAC and/or the SX1276 driver will require that any devices using this modified firmware to be re-certified for AS923 compliance.

Toolchains for Firmware Development

There are some examples of how to configure embedded development toolchains to generate AS923 firmware images given in the section on toolchains and development environments – including free and open source development tools. To configure your chosen build-system and project to use the correct LoRaWAN regional settings, AS923, typically requires that you just set a project or compilation flag.

LoRaMAC Firmware Updates & Fixes

Spark has identified and fixed a couple of problems with the LoRaMac firmware, and with release v1.0.3 of the LoRaWAN regional parameters. Many of our customers have been affected by these problems and Spark has raised these issues with manufacturers, provided fixes & workarounds, and future releases are scheduled to include these fixes:

See the downloads page for patches and more documentation on these issues. Additional Spark IoT news & updates can be found at:

and this will be updated as we find more issues that affect our customers.

As far as we know, all current and previous versions of the AS923 firmware for Murata CMWX1ZZABZ-based modules, along with earlier versions of the Multitech mDot/xDot firmware have problems with their firmware related to network rejoins and dwell-time limits1.

Multitech firmware releases from v3.1.0 onwards are capable of rejoining the network by issuing an AT+JOIN . But as of 18-02-2019 , all firmware for Murata-based LoRaWAN end-devices that we have tested, and that has been derived from the STMicrolectronics STM32Cube LoRaWAN Expansion (v1.2.1 or earlier), has this rejoin bug.

Additionally, the firmware from the primary LoRaMAC firmware development repository also has a dwell-time limit issue, and this can be a problem in certain situations. But this is not a bug in the firmware, it is an edge-case in the (AS923) protocol that needs an additional fix. A new version of the LoRaWAN specification will remedy the situation. More information, and code that fixes these problems, can be found on our Downloads page.

LTE CatM1 End-Device Development

While many manufacturers do not make the source-code available for their CatM1 modules, these modules will often be paired with a separate microcontroller that you may have to develop firmware for.

Further Development Topics

The partners section of the home page provides some information on platforms and services for IoT-related development. This includes suppliers of hardware, cloud services, IoT platforms, and sensor/device dashboards. In addtion, we present a brief introduction to scripting using Python2, in the following list of development-related pages:

This is a summary of the external sources of information that were mentioned above:

  1. Many other LoRaWAN modules and end-devices are likely to have one (or both) of these problems – though some device manufacturers have now found and fixed these issues. A forthcoming version of the LoRaMAC firmware release (v4.4.0) will fix the rejoin bug, and the LoRa Alliance is looking at releasing an updated specification to fix the dwell-time limit flaw.↩︎

  2. The choice of Python is essentially arbitrary – but it has become a popular language in many fields including big data & data science, machine learning, scientific computing, and is even starting to be used for embedded development (via MicroPython).↩︎

Copyright Spark NZ © 2019 Spark