For the past four months, we’ve been taking a deeper look into Narrowband as a mobile/M2M technology, some of the modules currently available and its applications in general.

From the perspective of boards and modules, we’re really excited about Arduino’s offering there. The folks from Arduino already introduced their new MKR series, small boards with different connectivity options plus a bunch of shields and integrations. The MKR NB 1500 is the one with support for LTE-NB and LTE-M, and we’ve been very happy to receive one sample board! So, we’re giving it an intense test-drive and let you know about the details of programming it, starting with this very blogpost and upcoming ones.

Let’s take a look at the board first.

Tech Specs

The board (as all MKR boards) features the SAMD21, an ARM Cortext M0+ microcontroller. You can find all specs on Arduino’s Product Page, and they’re comparable to the other MKR boards. In a nutshell, this board is flashed/powered via Micro USB, it has a JST connecting and can be powered by a LiPo cell. There is a „CHRG“-LED near the USB/JST, so the Li-Po battery can be charged via USB. Of course, it features Digital I/O, Analog I/O, PWM, a free UART besides the USB-one, SPI, I2C, I2S, so pretty much everything to connect peripherals.

At the heart of the MKR 1500 lies the LTE module from ublox, the swiss-based company known for their wireless and GPS products. It’s a SARA-R410M-02B model, which supports LTE Cat M1 and NB1, with multiple bands and for multiple regions. LTE-Cat M seems to be more used in the US, LTE Cat NB is more used in Europe, and the latter is what we’re going to test.

Recalling from the previous NBIoT post, LTE-M offers higher data rates (>300 kbits/s for up- and downlink), whereas LTE-NB has lower data rates and is asymmetrical (module spec: 27.2 kbits/s downlink, 62.5 kbits/s uplink). Moreover, LTE-NB has a higher latency (up to some seconds), which makes it harder to use TCP due to its three-way handshake. So within LTE-NB, applications using UDP, and protocols on top of it such as CoAP, are preferred.

The typical implementation for GSM modems works via serial communication. So within the firmware, a serial communication channel is established using a Uart (or sometimes a SoftwareSerial), where one can forward modem commands to the module, and read and interpret everything that comes back from the modem. This is a bit in contrast to programming networked communication on, say Linux, using sockets and a standardized sockets API that has been developed and matured a long time ago. On embedded, we’re instead working on a level that looks at bite rawer.

Luckily, Arduino has already developed some abstractions into their Framework (with classes like Client, Server, UDP, etc.), so they’re able to offer adaptions to new underlying communication types. We’ll look at that later.
First, let’s look at the hardware definition variants for the MKR 1500. It includes a global (well-known) SerialUSB object, mostly used for debugging purposes, a Serial1 object for the Uart on Pins #13/#14, and a SerialSARA, which talks to the ublox SARA module. Additionally, some constants are defined, which specify additional Uart pins such as RTS, CTS, DTR and a reset line.

Let’s give it a try. The minimum functionality we want to test is serial communication with a module, so we take a small sketch to „connect“ whatever we type on the SerialUSB monitor to the SARA module and vice-versa (picture below).

In setup(), the HIGH/LOW writes on the Reset line force the module to reset itself (which takes some seconds). Then, both Serial and SerialSARA are initialized with 115200bps. According to its specification, the module supports autobauding, so other values should work as well.
In loop(), both sides are read from if a character is available there, and this is forwarded to the other side. Let’s compile and flash it from the Arduino IDE, open the Serial Monitor and try out some commands:
AT
OK
AT+CGMI
u-blox
OK
AT+CGMM
SARA-R410M-02B
OK
AT+CFUN=1
OK
AT+CFUN?
+CFUN: 1
OK

AT COMMANDS

It works well, but looks quite cryptic - all commands are essentially abbreviations. They all start with AT (short for attention), followed by the actual command. The module responds with OK, or ERROR, and typically some response details (sometimes starting with a +).

The complete list of commands can be found in the AT Commands Manual, which is a 300 page reference manual. This is a bit of paper, but it is definitely interesting. The table of contents shows some chapters about general commands, network services and SIM management, but also how to control UDP/TCP, as well as higher-level protocols such as TLS, FTP, HTTP and MQTT. So the module itself can issue HTTP calls, or handle the TLS connection setup, meaning you do not need to do this in firmware.

Libraries and more

One of the beautiful aspects of the Arduino Framework lie within the easy abstractions within their libraries. This way, we would expect something such as Narrowband.begin(), and NarrowbandClient.connect(server, port). This makes it combinable with many other, higher-level Arduino libraries which are already around, e.g. for HTTP, MQTT or CoAP.

Or if you'd like to have the code to copy it - don't hesitate to contact me!