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.
Strengths
Deployment-ready
The N95S31B is ready to go — it has an IP66 rated weatherproof enclosure, comes pre-packaged with several different sensors, and configurable firmware. There are a lot of prototyping NB-IoT devices available, but there are very few deployment-ready products.
This includes some over-the-air configuration including reset, the transmit interval, and setting the trigger mode.
Factory configuration is still needed, to insert SIM cards and then configure the server details, but this can all be done relatively easily before deployment.
Global NB-IoT support
Narrow Band Internet of Things (NB-IoT) and the related LTE Category M1 (Cat-M1, also called LTE-M) are Low-Power Wide-Area Network (LPWAN) technologies that operate on the telecommunications carrier network.
NB-IoT coverage is significally greater than 4G and 5G mobile coverage, which means devices can operate in many remote areas, and even penetrate underground.
With controlled transmission, such as once a day, devices can operate on battery for years at a time.
Common use cases include agriculture, meter reading, and transport, however they can also be useful in some manufacturing and other supply chain scenarios where you need reliable monitoring even when site power is unavailable, for example power loss at a storage facility where you want to maintain temperature records even though power and network devices are down.
The Dragino uses the Quectel BC35-G modem, which supports global NB-IoT bands, including Telstra.
Open source makes customisation easy
NBSN95 is an open source project, based on the STM32L072CZT6 ultra-low-power micro controller, with the Quectel BC35-G modem. Developers can get completely software and hardware design files and adapter for their projects.
This allows the platform to be customised for your own application if the out-of-the-box configurations are not suitable, allowing you to add different sensors or capabilities. This approach does require some custom development, but the basic platform is available so the effort is much less than developing from scratch.
The source code is available at:
- Dragino firmware: https://github.com/dragino/NBSN95
The hardware is also open source, with full specifications available. The NBSN95 is composed of two PCB modules:
- Mother board: https://github.com/dragino/Lora/tree/master/LSN50/v2.0
- NB-IoT Module: https://github.com/dragino/NB-IoT/tree/master/NB%20ST/BC95
Weaknesses
Lack of security
The NBSN95A firmware does not support TLS (Transport Layer Security) or other encryption. This means to deploy securely you need a private APN (Access Point Name) and private network connection. This is not unusual, as many constrained devices have limited support for security, but needs to be taken into account for any deployment.
Private APN connections are available from Telstra.
The devices also do not have any physical security protection or anti-tamper measures such as enclosure alarms or wire-cut detection. The lack of security needs to be considered against the threat model for you particular usage to determine if it is a significant issue.
No over-the-air (OTA) firmware upgrades
This makes large deployments risky if updates are needed, although a small deployment would be manageable.
No IPv6 support
This may not be an issue in the short term, provided all your system components still support IPv4.
Note, however, that Telstra's consumer mobile network has moved to single-stack IPv6 only, and these changes will be coming to IoT networks in the future, so this needs to be taken into consideration if you are expecting long term usage.
The Telstra Wireless Application Development Guidelines expect any large deployment to be IPv6 single stack, and for smaller deployments it is recommended that IPv6 is used, although if existing devices only support IPv4 then dual stack is available.
Bespoke raw data format
The N95S31B sends readings in a bespoke raw data format; for MQTT these are encoded as a hex string that needs to be decoded into the battery level, sensor readings, and other details.
It does not directly support any standard data formats, such as SenML, or vendor formats such as Cumulocity or Azure IoT.
For a battery powered device a compact data format is often necessary to limit the amount of power required to transmit data in the most compact form possible. Many of the standarised formats can be relatively verbose, requiring a lot more power. Even using TCP (with MQTT on top) is measurably less efficient, with an impact on battery life, than CoAP and UDP.
There are standardised formats that support compact data, such as LwM2M (Lightweight Machine-to-Machine), where the required gateways are readily available.
However, the N95S31B uses a bespoke format, meaning that a custom gateway is needed to translate into a more usable format.
Testing the N95S31B - Preparation
The Dragino N95 can communicate using several protocols, including MQTT, although it does not support TLS. This means communication, including the password, is not secure. Due to limited processing capability some constrained devices are not able to support full security, so alternative protection is required.
In a production deployment you could use a private APN (Access Point Name) for the mobile network, and then a private network tunnel to connect to your server, which would ensure that all communication is private.
For testing, however, we can simply enable insecure access on our MQTT test server. This does mean the password could be vulnerable to snooping, but this is not an issue for a short lived test network.
MQTT test server
To test, you can follow the instructions in a previous article to set up Mosquitto server running in Azure.
The article shows how to set up a secure server, that only supports TLS, however the Dragino does not support encryption, so we need to modify the steps a little to allow insecure access.
If you want a quick start, the scripts available on Github include an -AllowInsecure parameter that you can use to set up a second server. For details see: https://github.com/sgryphon/iot-demo-build/blob/main/azure-mosquitto/README-mosquitto.md
After deploying the network, :
./azure-mosquitto/infrastructure/deploy-mosquitto.ps1 -MqttPassword YourInsecurePassword -ServerNumber 2 -AllowInsecure
The specific differences in the steps needed to allow insecure access are: first, in cloud-init.txt you need to set up full access for the listener on port 1883 by not limiting to localhost (in the Mosquitto default.conf), and then in the initial run commands allow port 1883 through the firewall.
write_files:
- path: /etc/mosquitto/conf.d/default.conf
content: |
...
listener 1883
...
runcmd:
...
ufw allow 1883
...
You also need to allow port 1883 through the network security group firewall in Azure:
az network nsg rule create --name AllowInsecureMQTT `
--nsg-name $dmzNsgName `
--priority 2201 `
--resource-group $networkRgName `
--access Allow `
--source-address-prefixes "*" `
--source-port-ranges "*" `
--direction Inbound `
--destination-port-ranges 1883
This will enable the server listening on port 1883, allow it through the server firewall, and through the Azure network security group firewall.
Follow the MQTT server logs
To see what is happening on the server we can use SSH (Secure Shell) to connect:
ssh iotadmin@mqtt002-purpleiot-dev.australiaeast.cloudapp.azure.com
And follow the Mosquitto logs:
sudo tail -f /var/log/mosquitto/mosquitto.log
MQTT test listener
We can run an MQTT subscriber in a second console, to listen for all messages (this can use TLS, and IPv6). Use the (insecure) password that you assigned to the service.
$mqttPassword = 'YourInsecurePassword'
mosquitto_sub -h mqtt002-purpleiot-dev.australiaeast.cloudapp.azure.com -t '#' -F '%I %t [%l] %p' -v -p 8883 -u mqttuser -P $mqttPassword
Server details
The Dragino firmware only supports configuration by direct IP address, and only supports IPv4, so we need to get the public IP address from the server creation.
Or we can check it directly:
host mqtt002-purpleiot-dev-ipv4.australiaeast.cloudapp.azure.com
Device configuration
Have the server log following and test client subscription running when you configure the modem, because as soon as you configure it, it will send an initial data report.
SIM card
You will need an NB-IoT SIM card from your telecommunications carrier to use in the device.
For example, in Australia you can use one of the IoT Data SIM plans from Telstra
The modem module (blue in the picture below) is the top board inside the device, although with the SIM slot on the underside, so once you have opened it up you can slide the Micro SIM card in below the Quectel chip, and above the main Dragino board (green). It is a bit fiddly, so for easier access you can unscrew and remove the modem. The slot is spring loaded, so push again if you need to remove the SIM.
Serial converter
To configure the device you will need a USB to serial converter or other terminal, connected as the picture below.
For wiring the Sparkfun Serial Basic converter I used has a green LED for TX (transmission) and a yellow LED for RX (receive), so I used a green wire for TXO on the converter (which will be RxD on the device side, the fourth terminal in the connection block).
I used yellow for RXI on the converter (which is TxD on the device side, the third terminal).
For Ground (GND) I used a black wire, piggy backed on the second last (11th) terminal in the block.
I screwed in a couple of leads with sockets on the end, so I could leave them in the enclosure and easily connect/disconnect for testing.
Serial connection
The Dragino NBSN95 manual provides the serial settings: 9600 baud, 9 data bits, 1 stop bit, no parity, no flow control.
You can use a terminal program to connect, e.g. screen.
screen /dev/ttyUSB0 9600,cs8
Once the terminal is running (and your logging and listening terminals are ready), close the jumper to turn the Dragino on, and you will see the bootup sequence with diagnostic messages.
Quectel modem configuration
You may need to manually configure the PDP (Packet Data Protocol) network to use, by specifying the Access Point Name (APN). For me this is telstra.iot, and I also specified dual stack configuration by default (although the device does not currently support IPv6):
Before sending commands, you need to send the device configuration password; the default is 12345678:
12345678
Commands sent to the Dragino firmware that are not recognised are automatically forwarded to the Quectel modem, allowing it to be configured. To configure the Quectel with the Telstra APN, we need to first detach, then change the configuration, then reattach. Enter the following commands one at a time:
AT+CGATT=0
AT+CGDCONT=0,"IPV4V6","telstra.iot"
AT+CGATT=1
After configuring the modem for your network (as needed), you may need to reset the device via commands, or you may even have to press the on board reset and/or disconnect the power:
AT+ATZ
Dragino firmware configuration
You also need to configure the firmware on the N95S31B, that collects sensor readings and then sends the transmission.
There are several connection options: UDP, COAP, TCP, and MQTT. You can query the current configuration:
AT+CFG
For MQTT, we need to set mode 3, and provide a device (client) ID, the server IP address, client ID, name, password, and topics. Note that the password for mqttdevice1 is the specified password with the suffix 3.
Send the following commands, one at a time, over the serial connection to configure the firmware. When completed, you can check the configuration (via AT+CFG).
AT+PRO=3
AT+CLIENT=imei-868411056760283
AT+SERVADDR=20.213.62.66,1883
AT+UNAME=mqttdevice1
AT+PWD=YourInsecurePassword3
AT+PUBTOPIC=s/us
AT+SUBTOPIC=s/ds
Also set the uplink interval to 60 seconds, the minimum, for testing purposes.
AT+TDC=60
Note that MQTT (and TCP) uses more battery than COAP or UDP, so for a production deployment set the uplink interval accordingly, e.g. but 3600 seconds (1 hour) or longer for standard operation. For some applications you may use 86400 seconds (one day).
Aside: Initial connection issues
Initially the device was reporting signal strength 99, which means no signal, the modem was not working, and it kept rebooting.
You can check the radio band configuration via AT+NBAND?. Initiallyit was reporting "5,8,3", which I thought should be okay (as Telstra supports bands 3 and 5), but it wasn't working.
AT+NBAND?
So, I tried configuring for "3,5,28" (the three bands Telstra supports), but that didn't work either. I then changed to just band 28, which did, and then I changed it so that band 28 was first. This disables the radio, changes the band configuration, then re-enables the radio:
AT+CFUN=0
AT+NBAND=28,3,5
AT+CFUN=1
I am not sure exactly which step got the modem working, as I also tried several other commands to turn off and on autoconnect (AT+NCONFIG=AUTOCONNECT,FALSE) and manually detach and reattach (AT+CGATT=1), following the "Manual Network Attachment" example in the BC35 AT Commands Manual. After the various changes and resets I finally got a signal, and think setting the band was key, although I can't reproduce the same issue.
Connection Testing
Once the device is configured, it will start connecting to your test server.
Note that you can remove the jumper to turn the device off, and then on again; or press the reset button, to restart the bootup sequence. This will check the IMEI, IMSI, and signal strength, then if it is all good, gather the sensor readings and then start the MQTT upload.
You will see the connection in the Mosquitto logs, and then the transmitted message in the subscribed client.
Note in the MQTT server logs (top right) that the incoming connection is IPv4, from a carrier grade NAT address, i.e. not the address of the actual device.
Once the device is configured and running, you can change the data collection interval as needed, via AT+TDC=1800 for 30 minute readings. If you leave the jumper on and close up the casing, then the device will continue to wake up on the configured schedule and send data. Beware of battery life if the device is reporting very frequently.
Downlink messages
The N95S31B also has limited support for downlink messages, to change the data transmission interval, reset the device, and set the interrupt mode.
The device also supports cached data mode, for up to 10 sets of data, which will be cached if connection is not possible, and then all data transmitted in the packet during the next connection.
Production deployment considerations
The Dragino N95S31B and the rest of the NBSN95 series are deployment ready weatherproof devices, although they do have limitations.
For security, if required, you will need to use a private APN and private network.
As the data is transmitted in a bespoke raw format, you will also need a gateway to parse and convert to a more usable format. A gateway is ususally used for low-powered devices to support small data formats, however a standardised format such as LwM2M may have better support than a custom format.
Devices also need to be factory/in-house configured before deployment. You need to open cases, insert SIMs, configure, and then close the cases.
For configuring large numbers of devices you can use a custom jig with pogo pins to simplify connecting to each device (accessing into the top of the terminal block), and then use a script to send the configuration commands for each device.
The data transmissions include battery level, so you can monitor device health remotely, however firmware updates or other changes will need you to appropriately plan for field servicing.