Connecting the AVR-IoT Cellular Mini Board to the Internet

The featured image of this blog post is based on a picture by Gerd Altmann from Pixabay.

When you want to connect a sensor or actuator to the Internet and there is no WLAN around, then the next best option is LPWAN (Low-Power Wide Area Network). In this blog post, I will describe how to connect a sensor to a website using the AVR-IoT Cellular Mini board by Microchip.

Motivation

Recently, I started a project, where I want to sense some bits and display the result on a Web page. With wireless LAN and an ESP32 or similar, this looks like an easy exercise. In my case, I do not have access to WLAN.

So, how do you get the few bits to the Web page? First, we have to decide, which kind of wireless network technology we are going to use. Then, we need to choose a network protocol to deliver the data and implement a way to display the data as part of a web page. Finally, we need to shop for the appropriate hardware. And maybe, these decisions are all connected with each other.

Low-Power Wide Area Networks

There exist meanwhile a number of different technologies and wireless network operators that allow connecting individual sensors to the Internet. These kinds of network technologies focus on low-power and low-bandwidth connectivity.

For example, LoRaWAN is a technology using spread spectrum modulation in license-free sub-GHz bands (868 MHz in the EU). The Things Network is a collaborative, community-based LoRaWAN network, which everybody can use for free. If you want to know whether there is network coverage, where you plan to use it, there is a coverage map. If there is not enough signal strength, you could run your own LoRaWAN gateway.

A similar project that uses LoRaWAN is Helium. Here you receive payment when you operate a gateway, but in turn you have to pay for using the network.

In both cases, one depends on other people’s willingness to provide a gateway or one has to set up one’s own gateway. Although I like the community-driven networking, I do not want to rely on it.

Another technology is ultra narrowband, which uses the same sub-GHz bands as the ones mentioned above. Sigfox is a network operator, which provides wireless connectivity using this technology. Here, you have to pay for transmitting data. And if I interpret it right, it is around €5-€10 per device per year for sending just a few bytes per day.

Finally, the cellular network operators, such as Deutsche Telekom, provide LPWAN technologies, such as LTE-M and NB-IoT. The data rates are much higher than in the above cases. In addition, the service fees are very competitive. At 1NCE, for instance, you pay €10 for 500 MB over 10 (!) years. The only downside is that you can purchase SIM cards only if you can prove that you are a company or self-employed (using, e.g., your tax return statement). I settled for this, in particular, because there is the very interesting AVR-IoT Cellular Mini board, that supports this kind of networking.

AVR-IoT Cellular Mini board

The AVR-IoT Cellular Mini board is quite a thing! It looks as if it has been designed having in mind that Makers should use it. The basic design of the board is Adafruit Feather compatible. The MCU is a AVR128DB48, which is supported by Spence Konde’s DxCore. And Microchip provides Arduino libraries for this board, which you can install using the Arduino library manager.

From a hardware point of view, you get the above-mentioned MCU, a temperature sensor (MCP9808), a color sensor (VEML3328), a CryptoAuthentication™ Device (ATECC608B), a serial EEPROM (25CSM04), an antenna (824MHz-2170MHz), a Nano SIM cardholder, a Li-Ion/LiPo Battery Charger, and more. In particular, you get additionally a SIM card by Truphone (valid for 90 days).

Including VAT, the board costs around €80 when you buy it in Germany.

First steps

For making first steps, I used the Hackster.io post by Keenan Johnson. Almost everything worked out of the box. But then, I ran into problems. After having activated the Truphone SIM, I tried to establish a connection to the operator by running the http example from the AVR-Iot-Cellular library that can be installed using Arduino’s library manager. What I got, was this, however:

[INFO] Starting HTTP example
[INFO] Connecting to operator....................................................................................................................................................... OK!
[INFO] Did not get time from operator, doing NTP sync. This can take some time...
[WARN] Got disconnected from network whilst doing NTP sync
[ERROR] Failed to connect to the operator

And as it turned out, it is not the NTP sync that causes the problem. I disabled it in the LTE library, and then I got the error message that the operator name is unknown. With a SIM card from 1NCE, everything worked out, though. Since the Truphone SIM is valid only for 90 days, I am not too upset about this problem. After switching the SIM cards, all the example sketches worked flawlessly. Well, the temperature sensor seems to return slightly to high values.

To MQTT or not to MQTT?

Once the basic networking is in place, there is the question of how to transfer the bits to the website, where it should be displayed. The protocol of choice for IoT devices is MQTT, and there are a few example sketches in the AVR-IoT-Celluar library that show how to work with it. MQTT is a publish-subscribe protocol meant for devices that are not always online. While this sounds indeed like a perfect fit, it would imply a lot of implementation and administration overhead. You need a server that provides the message broker, which keeps the state of the devices. Google, Microsoft, and Amazon provide such services and there are others that also host such services. In addition, you need to implement a client using Javascript that visualizes the state of a device. It all sounds like a lot if all what you want to do is displaying a few bits.

Using HTTPS, CGI, and Javascript

I decided to use a CGI bash script on the web server on which the webpage will be displayed. This CGI script is addressed using the POST request method. The script looks (slightly simplified) as follows.

#!/bin/bash
read POST_STRING

echo "Content-type: text/html"
echo ""

IFS="="
set -- $POST_STRING
if [ "$1" == "TICKETS" ]
then
    echo "function tickets() { return $2 }" > ../data/newdata.js    
    echo "OK"
else
    echo "FAIL"
fi

The Javascript file newdata.js needs then to be included and used by the webpage that displays the data.

I tested it with a curl command and it worked beautifully. Since the HTTPS example for the AVR-IoT board had worked as well, I expected that everything works out, which it did not. Addressing the website from the AVR-IoT board resulted in the following output.

[INFO] Starting HTTPS example
[INFO] Connecting to operator.. OK!
[INFO] Connected to operator: Telekom.de
[INFO] Configured to HTTPS
[ERROR] Timed out whilst waiting on delivering the HTTP payload. Is the server online? If you're using HTTPS, you might need to provision with a different CA certificate.
[INFO] POST - HTTP status code: 0, data size: 0

HTTPS and CA certificates

These days, almost all traffic between browsers and web servers is done using HTTPS, the secure version of HTTP, which uses Transport Layer Security (TLS). And since it all works, one never asks, how it works. If you are interested in that, Robert Heaton wrote a very nice blog post explaining the mechanics of HTTPS. The main point for my purpose is that there are a number of different certificate authorities (CA), which issue cryptographic certificates that allow to verify the authenticity of web servers. Each browser contains a store of such certificates, which can be used for such a purpose. When the AVR-IoT board wants to establish an HTTPS connection, it also needs access to these certificates. And this is where the provision mentioned in the error message above comes into play. Instead of a store of certificates, only one certificate can be stored.

You need to provide the right CA certificate in order to be able to communicate with a particular web server. However, how do you find out which is the right one? Clicking on the lock symbol in the URL line can help. That leads you to the certificates that are used by the web server. And here one wants to use the root certificate that has a lifetime of 10 years or so. In my case, it is the certificate named ISRG Root X1. And, of course, in ten years time, one has to change this certificate!

After having provisioned the AVR-IoT board with the right CA certificate using the provision example sketch of the AVR-IoT-Cellular library, the HTTPS connection works without any hitch and I can work on building the remaining pieces in order to finish the project, which I will describe in a future blog post in detail.

Summary

It is easy to make first steps with the AVR-IoT Cellular Mini board by Microchip. Perhaps, you need to buy an LTE-M SIM card from your local network operator, though. When you want to send data using the HTTPS protocol, you need to find out which CA certificate your web server uses, and to provision the board with it. And then you are ready to rock and roll.