The Dragino NBSN95/NBSN95A family is a deployment-ready range of water resistant NB-IoT (Narrow Band Internet of Things) devices that are available pre-packaged with various sensors such as soil moisture, distance detection, liquid level, and temperature/humidity sensors.
NB-IoT is a Low-Power Wide-Area Network (LPWAN) technology that allows devices to be accessed in remote locations and operate on battery for long periods of time, up to many years.
In this article we will look a the N95S31B, the model with the pre-packaged temperature/humidity sensors, the strengths and weaknesses of the device, and then walk through configuing the device and see it connect to an MQTT test server. Our previous article showed you how to set up an MQTT test server on Azure if needed.
The NBSN95 is an open source project, with both the software and hardware specifications available, if you need to customise the application. We have also previously reviewed the Dragion LDDS75 LoRaWAN device.
MQTT (originally Message Queuing Telemetry Transport) is an important protocol for IoT that has been widely adopted. Devices deployed to the field may be connecting to existing MQTT endpoints, however you may also want to deploy your own MQTT server for testing purposes.
This article shows you how to deploy an Eclipse Mosquitto MQTT server onto Azure, configured for secure connections (MQTTS, which is MQTT over TLS), accessible over the internet, and including support for both IPv6 and legacy IPv4.
First we will configure a network in Azure, then deploy the server, and then test the deployment.
To deploy the network and then server components via the scripts:
az account set --subscription <subscription id>
$VerbosePreference = 'Continue'
In this post we will cover how to the the built in support for OpenTelemetry in modern .NET to instrument your distributed application for tracing and logging, how the OpenTelemetry Collector can be used to simplify instrumention, and how the OpenTelemetry Protocol is building a (brilliant) connected future.
We will now go further than logging and look at tracing. Tracing looks at the different units of work (spans) done during an operation (trace), how they are connected, and the timings of the different components. This is an important tool for investigating performance issues in distributed systems.
An example distributed trace timeline, across multiple components, viewed in Jaeger, one of many supported tools:
As well as looking at individual traces timings can be aggregated across the system to find the slowest areas, and identify anomalies.
LoRaWAN devices are a popular solution for IoT, with many benefits, but they cannot connect directly to Azure IoT.
LoRaWAN devices communicate using LoRa to a local LoRaWAN gateway, which then communicates using standard protocols to a LoRaWAN network server. Only then can it be converted to a suitable IP-based protocol to connect to Azure IoT.
Even if they did share a common network, LoRaWAN IoT devices are often small, low-power, battery operated devices that operate in short bursts of minimal communication, and not the verbose communication expected by Azure IoT, so you would want to use a gateway anyway.
To test out connecting field-ready LoRaWAN devices to Azure IoT, I ordered a Dragino LDDS75 LoRaWAN Distance Detection Sensor, used to measure the distance between the sensor and a flat object. It can be used for both horizontal and vertical distance measuring, such as liquid level measurement or object detection (e.g. parking space).
3G (3rd generation mobile technology) networks for the major telecommunication companies are due to shut down over the next few years. This includes Telstra, whose network is now in the sunset phase and due to close in June 2024.
This will mean the end of 3G for Internet of Things deployments, and they will need to migrate to either LPWAN (Low-Power, Wide-Area Networks) or new generation cellular mobile, depending on the use case.
As pointed out in this article on Why you need to migrate your devices now! that does not give a lot of time. If you have 15,000 devices in the field you need to be replacing 30 devices per day — if you start tomorrow; more if you take long to commence your project.
The are three main options for migration, in two categories:
NB-IoT (Narrow-Band Internet-of-Things)
Cat-M1 (Category M1), also known as LTE-M (Long Term Evolution, Category M)
4G LTE (4th Generation) mobile
This post will explore those options in a bit more detail, as well as what other alternatives there might be. 5G NR (5th Generation New Radio) does not yet have wide enough coverage to be a viable option for IoT in most cases.
If this seems a bit overwhelming, given the short time frames and what you need to do, then you can also approach our consulting services, Telstra Purple, for advice and help.
The open source gateway runs a variant of OpenWRT and the latest version supports a range of LoRaWAN features including Basic Station. You can use it for a private network or set it up with a community as I did for The Things Network (TTN).
Read on for details of how easy it was to set it up securely.
The team recently took some core bits out of project they are working on with code first Azure Digital Twins and have released it as an open source library, so I thought I would share an initial look at the project.
Why code first? Using a code first approach can make accessing Digital Twins easier for developers. They can use their native programming language and tools to develop their models, without having to learn the intricacies of DTDL (Digital Twins Definition Language) or the REST APIs for interacting with Azure Digital Twins.