Select Page

Automated Weather Satellite Ground Station

Project source code at GitHub: wx-ground-station



This project will show you how to create a fully automated ground station that will receive and decode NOAA weather satellite images and upload them to your own website served from an Amazon AWS S3 bucket. With this project you don’t need your own server or have to run your own website infrastructure. Have a look at my AWS site that is updated automatically all day long.

Oh, you want a site like this, too? Full of images you decoded from space? Then let’s get started, my friend.

Here’s what you’ll need:

  • a modern Raspberry Pi (version 3 or 4), probably with Wi-Fi since it may be deployed outdoors. I used a RPi 3 model B. I have heard that a RPi Zero may not be powerful enough.
  • an RTL-SDR dongle. I recommend the RTL-SDR V3 dongle from the excellent RTL-SDR.COM blog.
  • an AWS account for hosting images and web content in an Amazon S3 bucket. You can sign up for the free tier for a year, and it’s still cheap after that.
  • a simple dipole antenna with elements 21 inches (53.4 cm) long and that can be adjusted to have a 120 degree angle between the elements. Here’s a great article on design or you can just buy this dipole kit, also from the RTL-SDR.COM blog.
  • coaxial cable to go from your antenna to Raspberry Pi + RTL-SDR dongle. The dipole antenna kit comes with 3m of RG174 coax, but I used 10 feet of RG58 coax.

This is a very long article with lots of steps, so take your time — I won’t be able to help everyone debug all their issues. I won’t go into the details of using a Raspberry Pi for the first time — this project assumes you know your way around the Pi and are comfortable with installing software on it. If you have never used AWS before, I suggest you set up an account and get familiar with what S3 is.

Weather Satellites and RTL-SDR

This probably isn’t the first you’ve read about using a software defined radio (SDR) to receive weather satellite images. This type of project has been documented before. Sometimes the emphasis is on software defined radio hardware and techniques, sometimes it’s about antenna design, or maybe the article is written by a real weather enthusiast who always use the abbreviation “wx” for weather. I’m not an expert in any of these areas, but the idea of receiving images directly from weather satellites as they fly overhead has intrigued me for many years. This has all gotten a lot easier with RTL-SDR dongles, more powerful Raspberry Pi computers and simpler antenna designs that get the job done. I gave this project a try recently using this well-written Instructables article, a totally hacked-together antenna I made, and a very old rtl-sdr dongle:



and on my very first attempt, I decoded this image from NOAA19 as it passed over my area:



From that moment, I was hooked. I played around with different antennas and such, but found it tedious to always copy the images from my outdoor Raspberry Pi to my computer so I could look at them. I resolved to automate the uploading of images to an S3 bucket and to improve upon the scripts from the Instructables article. This is the overall solution:



Amazon AWS Setup

Your ground station website functionality will be completely in client-side JavaScript. It will use the AWS JavaScript SDK to make API calls to S3. The scripts that run on the Raspberry Pi also use some Node.js scripts to upload to S3. There are a lot of steps to get everything set up:

AWS SDK Credentials

The scripts that run on the Raspberry Pi use some Node.js scripts and the AWS JavaScript SDK to upload to S3. You need to get your credentials. These two articles show you how to get your credentials and store them for Node.js access:
Getting your credentials
Loading Credentials in Node.js from the Shared Credentials File

Your credentials file on the Raspberry Pi ~/.aws/credentials will look like this:

[default]
aws_access_key_id = YOUR_ACCESS_KEY_ID
aws_secret_access_key = YOUR_SECRET_ACCESS_KEY

Also set the default region where your S3 bucket will reside in ~/.aws/config. For example:

[default]
output = json
region = us-west-2

Create an S3 Bucket

Now create an S3 bucket for public website hosting. I’m using the bucket name nootropicdesign.wx for mine. The instructions are in this article:
Setting up a Static Website

At this point you should be able to load a simple web site from your new bucket. You might want to upload a simple index.html file and try to load it in your browser with http://BUCKETNAME.s3-website-REGION.amazonaws.com/.

<!doctype html>
<html>
  <head><title>S3 test</title></head>
  <body>Hello from S3</body>
</html>

Create an Identity Pool in Cognito

To give public users the ability to access your S3 bucket using the AWS SDK, you need to set up an identity pool and create a policy allowing them read access to your bucket. This is done using Amazon Cognito. A good guide for granting public access to your bucket is described in this article that shows how to serve images from an S3 bucket (just like we are). It’s somewhat confusing to follow the steps, so take your time.

Step 1: create an Amazon Cognito identity pool called “wx image users” and enable access to unauthenticated identities. Be sure to select the region in the upper right of the page that matches the region where your S3 bucket was created! Make note of the role name for unauthorized users, e.g. “Cognito_wximageusersUnauth_Role“.

Step 2: on the Sample Code page, select JavaScript from the Platform list. Save this code somewhere, because we need to add it to the web content later. It looks something like this:

// Initialize the Amazon Cognito credentials provider
AWS.config.region = 'us-west-2'; // Region
AWS.config.credentials = new AWS.CognitoIdentityCredentials({
  IdentityPoolId: 'us-west-2:1d02ae39-3a06-497e-b63c-799a070dd09d',
});

Step 3: Add a Policy to the Created IAM Role. In IAM console, choose Policies. Click Create Policy, then click the JSON tab and add this, substituting BUCKET_NAME with your bucket name.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "s3:ListBucket"
         ],
         "Resource": [
            "arn:aws:s3:::BUCKET_NAME"
         ]
      }
   ]
}

Click Review policy and give your policy a name, like wxImagePolicy.

In IAM console, click Roles, then choose the unauthenticated user role previously created when the identity pool was created (e.g. Cognito_wximageusersUnauth_Role). Click Attach Policies. From the Filter policies menu, select Customer managed. This will show the policy you created above. Select it and click Attach policy.

Step 4. Set CORS configuration on the S3 bucket. In the S3 console for your bucket, select Permissions, then CORS configuration.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedMethod>HEAD</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Raspberry Pi Setup

Most of these instructions are from steps are from steps 2 and 3 of the Instructables article I mentioned earlier.

Install Required Packages

First, make sure your Raspberry Pi is up to date:

sudo apt-get update
sudo apt-get upgrade
sudo reboot

Then install a set of of required packages.

sudo apt-get install libusb-1.0
sudo apt-get install cmake
sudo apt-get install sox
sudo apt-get install at
sudo apt-get install predict

I used Node.js in some of the scripting, so if you don’t have node and npm installed, you’ll need to do that. In depth details are here, and I easily installed with:

curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs

Using your favorite editor as root (e.g. sudo vi), create a file /etc/modprobe.d/no-rtl.conf and add these contents:

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

Build rtl-sdr

Even if you have rtl-sdr already built and installed, it’s important to use the version in the GitHub repo keenerd/rtl-sdr, as this version’s rtl_fm command can create the WAV file header needed to decode the data with sox.

cd ~
git clone https://github.com/keenerd/rtl-sdr.git
cd rtl-sdr/
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make
sudo make install
sudo ldconfig
cd ~
sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
sudo reboot

Install and Configure wxtoimg

The program wxtoimg is what does the heavy lifting in this project. It decodes the audio files received by the RTL-SDR receiver and converts the data to images. The original author of wxtoimg has abandoned the project, but it is mirrored at wxtoimgrestored.xyz.

wget https://wxtoimgrestored.xyz/beta/wxtoimg-armhf-2.11.2-beta.deb
sudo dpkg -i wxtoimg-armhf-2.11.2-beta.deb

Now run wxtoimg once to accept the license agreement.

wxtoimg

Create a file ~/.wxtoimgrc with the location of your base station. As usual, negative latitude is southern hemisphere, and negative longitude is western hemisphere. Here’s my location in Minnesota, USA.

Latitude: 45.0468
Longitude: -93.4747
Altitude: 315

The program predict is used by the automated scripts to predict weather satellite orbits. Run predict to bring up the main menu:

                                      
                           --== PREDICT  v2.2.3 ==--         
                     Released by John A. Magliacane, KD2BD   
                                    May 2006                 
                                                             


                            --==[ Main Menu ]==--


 [P]: Predict Satellite Passes          [I]: Program Information
 [V]: Predict Visible Passes            [G]: Edit Ground Station Information
 [S]: Solar Illumination Predictions    [D]: Display Satellite Orbital Data
 [L]: Lunar Predictions                 [U]: Update Sat Elements From File
 [O]: Solar Predictions                 [E]: Manually Edit Orbital Elements
 [T]: Single Satellite Tracking Mode    [B]: Edit Transponder Database
 [M]: Multi-Satellite Tracking Mode     [Q]: Exit PREDICT

Select option ‘G’ from the menu to set your ground station location:


                *  Ground Station Location Editing Utility  *



                        Station Callsign  : KD0WUV
                        Station Latitude  : 45.0468 [DegN]
                        Station Longitude : 93.4747 [DegW]
                        Station Altitude  : 315 [m]



            Enter the callsign or identifier of your ground station

You can enter whatever you want for the callsign (I used my amateur radio callsign). When entering the longitude, note that positive numbers are for the western hemisphere and negative numbers are for the eastern hemisphere. This is opposite convention, so make sure you get this right or you’ll be listening when there’s no satellite overhead!

Get the Automation Scripts and Configure

I’ve completely refactored the scripts originally posted in the Instructables article and added Node.js scripts for creating thumbnail images and uploading all images to S3. The git repo can be cloned anywhere on your Raspberry Pi. The configure.sh script sets the installation directory in the scripts and schedules a cron job to run the satellite pass scheduler job at midnight every night.

git clone https://github.com/nootropicdesign/wx-ground-station.git
cd wx-ground-station
sh configure.sh
cd aws-s3
npm install

In the file aws-s3/upload-wx-images.js set REGION, BUCKET, and LOCATION to the correct values. This Node.js script prepares the images for upload by creating thumbnail images, printing some metadata on the images, and creating a JSON metadata file for each image capture. The LOCATION string will be printed on the images that you capture. Here are my values just for reference.

var REGION = "us-west-2";
var BUCKET = "nootropicdesign.wx";
var LOCATION = "nootropic design ground station, Plymouth, Minnesota, USA  45.0468, -93.4747";

Also set the REGION and BUCKET correctly in the files aws-s3/upload-upcoming-passes.js and aws-s3/remove-wx-images.js. Plug in your own values:

var REGION = "us-west-2";
var BUCKET = "nootropicdesign.wx";

Now we need to make some changes to the web content. The web interface uses Mapbox to draw the live maps of the next upcoming satellite pass. You’ll need to create an account at Mapbox to get an access token. Their free tier lets you load 50,000 maps/month, so you are not likely to have any real costs. When logged into Mapbox, get your account token from https://account.mapbox.com/.

Now in the file website/wx-ground-station.js, set your bucket name, AWS region, AWS credentials (the Cognito identity pool info you saved above), Mapbox token, and your ground station info. Some of my values are shown here for reference.

var bucketName = 'nootropicdesign.wx';
AWS.config.region = 'us-west-2'; // Region
AWS.config.credentials = new AWS.CognitoIdentityCredentials({
    IdentityPoolId: 'us-west-2:1d02ae39-30a6-497e-b066-795f070de089'
});

// Create a mapbox.com account and get access token
const MAP_BOX_ACCESS_TOKEN = 'YOUR_MAPBOX_TOKEN';
const GROUND_STATION_LAT =  45.0468;
const GROUND_STATION_LON = -93.4747;
const GROUND_STATION_NAME = 'my ground station';

Upload the Web Content to S3

Upload the the contents of the website directory to your S3 bucket using the S3 console. Since you probably edited the files on your Raspberry Pi, you might need to copy them to your computer where you are accessing AWS using a browser. Whatever the case, these files need to be uploaded to the top level of your bucket. IMPORTANT: be sure to grant public access to the files when you upload them!

index.html
wx-ground-station.js
tle.js
logo.png

Of course, you can replace logo.png with your own, or just remove the <img> tag from index.html.

Test Everything Out

Now that everything is configured, let’s run the scheduling script to schedule recording of upcoming satellite passes. This way you can have a look today instead of waiting until they get scheduled at midnight. This step will also upload a JSON file with the upcoming passes info to your website.

cd wx-ground-station
./schedule_all.sh

You can now visit your AWS S3 website endpoint at

http://BUCKETNAME.s3-website-REGION.amazonaws.com/

Once again, mine is here: http://nootropicdesign.wx.s3-website-us-west-2.amazonaws.com/

Even though you don’t have any images captured, you should be able to see the next upcoming pass. The next thing to do is make sure the scripts work correctly to record the audio file, process it into images, and upload to your bucket. You can watch the logs in the wx-ground-station/logs to debug any errors.

The wxtoimg enhancements that are displayed depends on what sensors were active when the images were captured. If sensors 3 and 4 were active (usually at night), then the thermal enhancement will be shown. Otherwise a multispectral analysis enhancement will be shown.

Not all images you capture will be good. I feel lucky if even half of my satellite passes produce recognizable images. You can clean up bad ones by using the script aws-s3/remove-wx-images on the Raspberry Pi. Just provide the key to the particular capture as an argument to remove all the images and the metadata from the S3 bucket.

node aws-s3/remove-wx-images NOAA19-20191108-162650

Hopefully in the next few hours you’ll be able to see some images uploaded, depending on when satellites are scheduled to fly over. You may get up to 12 passes per day, usually 2 for each of the NOAA satellites in the morning, then 2 more for each of them in the evening. Let us know if this project worked for you!

Fine Tuning

The script receive_and_process_satellite.sh uses the rtl_fm command to read the signal from the RTL-SDR receiver. The -p argument sets the PPM error correction. I have mine set to 0, but you may want to adjust. See this article for details.

I have also installed a low noise amplifier (LNA) to improve my reception (results are mixed). My LNA can be powered with a bias tee circuit and controlled with the rtl_biast command. If you are using an LNA like this, you can install rtl_biast as documented here and uncomment the rtl_biast lines in receive_and_process_satellite.sh which turn the LNA on and off.

Iridium Satellite Communication with Arduino

When deploying a microcontroller-based IoT solution or just doing experiments gathering data in the field, you often need a way to get the data back to your home base or to the cloud somehow. You’ve probably used WiFi, maybe dabbled with cellular solutions, but what about satellite communication? Sometimes satellite is the only option if you are in a remote area. Transmitting data via satellite has been possible for quite some time using a satellite modem like the RockBLOCK 9603 from Rock Seven Communications. I recently used this technology to build a solution for a customer, and it was SO FUN I wanted to write up something about it because there’s not very much info out there.

Here is the basic architecture of the solution. Data is transmitted to one of the 66 Iridium satellites and then downlinked to Rock Seven where it will then be sent over the Internet to your server via HTTP or even email. I’m using a Node-RED server as the destination endpoint.






One barrier is cost: the RockBLOCK 9603 costs $250, you’ll pay a monthly fee to keep the modem activated, and each message costs money. I’ll give more details on cost later, but if you have a mission critical system that needs to be monitored or controlled in a remote area, it can be easy to justify the costs. From a development perspective, the good news is that there is an excellent Arduino library called IridiumSBD that makes it very easy to send Iridium short burst data messages (full documentation here). You will also want to keep in mind that messages need to be short (few hundred bytes at most) and that sending a message can take several minutes. We’re not streaming video with this stuff.

Hardware

After I learned this technology, I decided to make a simple development board to make it easier to deal with the wiring and make it more portable. The RockBLOCK modem has a 10-pin Molex “PicoBlade” connector, but it was fairly easy to solder to the board. I used a SAMD21 microcontroller (the SparkFun SAMD21 mini breakout board is a great choice) because it is more powerful than a simple Arduino Uno and it has more hardware serial interfaces. I need one serial interface for a GPS module and one for the satellite modem. You might want one for serial communication to some other device, too! It’s good to have lots of hardware serial interfaces. I have grown tired of using software serial, as it can introduce problems and I don’t have time for that.



The board also has an Adafruit GPS breakout board for plug-n-play GPS. I just put female headers on the board so I can redeploy the SAMD21 and GPS boards in other solutions someday. I also added an OLED display for output and a few LEDs, along with some buttons and a pot for input.

Rock Seven Account

To use the modem, it has to be registered with Rock Seven Communications. You have to pay a monthly line rental fee to keep it active on the network, and you have to buy credits that are used up as you send messages. Rock Seven is a British company, so all the prices are in GBP. Line rental costs £12 per month (click for conversion to U.S. dollars), and 100 credits costs £13. It costs one credit for every 50 bytes in a message. A message sent from a modem can be up to 340 bytes, and that would cost you 7 credits. As a system designer, I was highly motivated to keep my messages under 50 bytes!

You also use your Rock Seven account to tell Rock Seven what to do with the messages when they get them from the Iridium constellation. This is called a “delivery group”. I’m having Rock Seven do an HTTP POST to my Node-RED server. Note that there doesn’t seem to be any security; I can’t specify a username and password for my server, so “security by obscurity” is the simple approach. That’s why I’m not showing you my AWS server name in this image. All the info you need about the integration between Rock Seven and your application can be found here.





Communication Experiments

For my experimentation I use an external antenna but the default configuration is to use a built-in patch antenna which works fine. You will need a clear view of the sky — satellite communication typically won’t work indoors (although I have successfully sent messages from indoors very near a window). For power, I’m using a portable 5V supply.



My Arduino program just lets you input a number from 1-100 using a potentiometer to show how data can be transmitted. I’m also transmitting the GPS coordinates and the time of the sensor reading. Keep in mind that sending a message can take several minutes. The IridiumSBD library can call a callback function you specify so you can do things during the long transmission time, like control an LED and print output. Once you tell the library to send a message, it will keep trying to contact an Iridium satellite, as it may take a while for one of the 66 satellites to fly over your area. The default timeout in the library is 5 minutes. If my program fails to send the message in 5 minutes, the red LED comes on. If successful, the green LED is lit.



The payload of my message to the satellite is 16 bytes: 6 bytes for the timestamp (year, month, day, hour, minute, second), 4 bytes each for latitude and longitude, and two bytes for the data value. The Rock Seven management console lets you see the messages received by Rock Seven and forwarded to your destination server. The payload is sent as hexadecimal, so my 16 byte message is actually sent as 32 HEX characters to my server.





Processing Messages

After receiving the data over the Internet from Rock Seven, you can do whatever you want with it. I am processing the messages with a Node-RED server and displaying the received value on a web dashboard.



Along with the payload, Rock Seven delivers metadata, including the time at which the satellite received the message. I compare this to the time that the microncrontroller started sending the message so we know how long the process really took. In this case, it took 3 minutes and 48 seconds to successfully transmit to a satellite. The data also provides an approximate GPS location where it thinks your modem is. This is the CEP parameter in the metadata. This can be off by several kilometers, so if you are interested in actual location, you will need to use a real GPS module, like I am.



Here is the JavaScript code in the function node “parse data”. The decoded data is passed along to the dashboard display widgets.

var data = msg.payload.data;

var p = 0;
var year = parseInt(data.substr(p,2), 16);
p += 2;
var month = parseInt(data.substr(p,2), 16);
p += 2;
var day = parseInt(data.substr(p,2), 16);
p += 2;
var hour = parseInt(data.substr(p,2), 16);
p += 2;
var minute = parseInt(data.substr(p,2), 16);
p += 2;
var second = parseInt(data.substr(p,2), 16);
p += 2;

var latString = data.substr(p,8);
var lat = parseInt(latString, 16);
// can be negative, so check for sign bit
if (lat & 0x80000000) {
    lat = lat - 0x100000000;
}
lat = lat / 10000000.0;
p += 8;

var lonString = data.substr(p,8);
var lon = parseInt(lonString, 16);
// can be negative, so check for sign bit
if (lon & 0x80000000) {
    lon = lon - 0x100000000;
}
lon = lon / 10000000.0;
p += 8;


var valueString = data.substr(p,4);
var value = parseInt(valueString, 16);


// time that the message was created and ready to send
var msgTime = new Date(year+2000, month-1, day, hour, minute, second);
msg.payload.message_time = msgTime;

// time that the message was actually successfully transmitted to satellite
var txTime =  new Date("20" + msg.payload.transmit_time);
msg.payload.transmit_time = txTime;

var txMilliseconds = txTime.getTime() - msgTime.getTime();

var txMinutes = Math.floor(txMilliseconds / 60000);
var txSeconds = (txMilliseconds % 60000) / 1000;
var txTimeString = txMinutes + ":" + txSeconds;
msg.payload.txTime_ms = txMilliseconds;
msg.payload.txTime = txTimeString;

msg.payload.decoded_data = {
   year: year,
   month: month,
   day: day,
   hour: hour,
   minute: minute,
   second: second,
   lat: lat,
   lon: lon,
   value: value
}
return msg;


Resources

GitHub repo with the code used in this project and the board design files

RockBLOCK 9603 modem documentation

GitHub repo for IridiumSBD library

Detailed documentation for IridiumSBD library

Going Further

There are some things I haven’t tried yet. A satellite modem can actually receive messages from your server via Rock Seven. I also think it is important to design a security solution. A shared secret between the modem and Internet application may be sufficient, but deploying secrets to IoT devices has its own complexity. I could send a security token to the modem securely because sending a message to a modem requires Rock Seven credentials. The modem could then present the security token in each message, and the endpoint processor could require it. I think this would be reasonably secure, but the security token would take up valuable bytes in each message.

Summary

Using a Rock Seven Iridium modem is a lot of fun and it can be an important part of an IoT solution when you don’t have other connectivity options. It’s not cheap, you need a clear view of the sky, and it can take several minutes to send a short message. But if you can design a solution within those constraints like I have, it’s completely viable. And special thanks to Mikal Hart for writing the awesome Iridium SBD library!

Arduino Audio Hacker Realtime Voice Changer

Here’s another fun but simple project using the Audio Hacker shield for Arduino. This is a realtime voice changer, which is an improvement upon the original voice changer example I provided with the Audio Hacker library.

This project uses a technique called granular synthesis to change the pitch of the input. Granular synthesis is rather complex, but it involves dividing the sample up into small fragments called “grains”. When playing back a sample, if we want the pitch higher, we play the grain at a higher speed, but we play it over and over again until it takes the same amount of time as the grain played at original speed. Likewise, to lower pitch, we play each grain at a slower speed, but move onto the next grain sooner so that the overall sample has the same duration.

This realtime voice changer only lowers pitch. Raising pitch would require a lag to record something and play snippits of it faster. Lowering the pitch is accomplished by recording the input and then simultaneously playing it slower. That is, the “play head” moves slower than the “record head”. Occasionally, the play head needs to skip ahead over some of the input and catch up to the record head. This way, the playback takes the same amount of time as the recording, making it seem realtime. It is realtime, we are just playing only part of what was input (slowly) and skipping the rest so that the overall time is the same.

The example is in the Audio Hacker Library examples folder so you can load it into the Arduino IDE with

File->Examples->Audio Hacker->RealtimeVoiceChanger

As always, get the Audio Hacker library from GitHub: https://github.com/nootropicdesign/audio-hacker

Arduino Audio Hacker Realtime Reverser

Here’s a fun project using the Audio Hacker shield for Arduino – a realtime audio reverser! This program records the audio input to the Audio Hacker’s memory but plays it back in reverse. The “play head” jumps ahead a bit, then plays recorded audio backwards, then jumps ahead to the next snippet, plays it backward, and so on. There is a bit of lag between the input signal and reversed output, but this is unavoidable: we have to record something before playing it backward. There’s no way to play something backward in perfect realtime. This audio snippets are about a half-second long, so the lag is pretty small.

It’s great to hook up to a TV signal and just reverse all the audio. Using this effect, spoken English sounds like Russian to me!

 

The example is in the Audio Hacker Library examples folder so you can load it into the Arduino IDE with

File->Examples->Audio Hacker->RealtimeReverser

As always, get the Audio Hacker library from GitHub: https://github.com/nootropicdesign/audio-hacker

 

Arduino Shield for CAT M1 and NB-IoT Modems

LTE CAT M1 (sometimes called LTE-M) and NB-IoT are both exciting new cellular technologies targeting IoT applications. While there are many modems being built with this new technology, there are not many choices for hobbyists. There are a few Arduino shields and breakout boards based on the SIMCOM SIM7000 modem, and a few with u-blox SARA modems.

Nimbelink is a cellular technology provider that takes the unique approach of offering a variety of different modems as interchangeable modules. No matter what the actual cellular modem is, the 20-pin Nimbelink Skywire modules with the familiar “XBEE” footprint all have the same pinout and electrical characteristics. The interchangeable nature of these modem modules allows product designers to future-proof their products, allowing new modules to be plugged in later. Another huge benefit is that the Nimbelink modules are already certified on their respective cellular networks (Verizon, AT&T, etc.) so you don’t have to.

Nimbelink has a development kit for use by product developers, but it’s rather expensive. I wanted to try out a Nimbelink CAT M1 modem without the dev kit, and since there are so many hobbyists using Arduinos out there, I wanted to provide a nice Arduino library for the modem. I chose the Nimbelink module based on the Sequans Monarch CAT M1 modem and got to work designing an Arduino shield to hold it.

Skywire Shield with Nimbelink Skywire module with Sequans Monarch CAT M1 modem



Hardware Design

The shield is quite simple, and really just provides an appropriate switch-mode power supply for the modem. The input power for the shield can be 5-12V, and provides a stable 3.8V at up to 1.7A to the modem. I used a TI TPS5402 for this. Jumper settings allow you to connect the modem’s UART to the Arduino hardware UART on pins 0 and 1 or to software serial on digital pins 2 and 3. I typically use software serial at 19200 so that I can use the Arduino serial interface for debugging. The buttons labeled “Func 1” and “Func 2” are connected to digital pins 4 and 5.

Software Interface

What about actually using the modem in software? Every modem has its own AT command set, and although there are similarities, a developer must know the details of the modem they are using. Luckily, the excellent TinyGSM Arduino library provides an Arduino Client interface for a variety of underlying modems. The Arduino Client interface is widely used by networking libraries to abstract away the underlying hardware. That is, when you code to the Client API, it doesn’t matter if the hardware underneath is an Ethernet shield, an ESP8266, a cellular modem, or whatever. Examples of libraries that code to this interface and therefore work with many kinds of hardware are ArduinoHttpClient for web clients and PubSubClient for MQTT clients. Even HTTPS and MQTT over TLS work! Security is important.

TinyGSM did not have an implementation for the Sequans modem, so I wrote one. It’s in my forked repo of TinyGSM (it has not been merged into the parent yet). To use the TinyGSM examples with the Nimbelink module with a Sequans modem, simply add this to your source code:

#define TINY_GSM_MODEM_SEQUANS_MONARCH

I also bought a Nimbelink module with the Quectel BG96 CAT M1 and NB-IoT modem on it. Luckily, TinyGSM already has an Client interface implementation for this modem. After plugging it into my shield and simply changing my HTTP and MQTT test clients to use this modem, everything just worked! That is, I was able to change the modem to a different manufacturer (and completely different AT command set) and make my code work with a one line change:

#define TINY_GSM_MODEM_BG96

Skywire Shield with Nimbelink Skywire module with Quectel BG96 CAT M1/NB-IoT modem



So the lesson here is that with thoughtful design of software and hardware abstractions, one can achieve a lot of flexibility.

  • the Arduino Client interface defines a standard software API for network clients so that an implementation for any hardware can be written and expose its functions through this same interface
  • useful libraries like ArduinoHttpClient and PubSubClient code to this interface so that HTTP and MQTT are easily used with lots of hardware
  • and finally, Nimbelink has defined a standard Skywire module pinout so that it’s easy to swap out the hardware

This is all getting pretty easy, right?! I hope you agree.

I haven’t decided if I’ll make this shield available as a product because there has to be some real demand for that to be worth it. Let me know if you are interested in an easy way to get started with modern cellular technology using Nimbelink modules.

Schematic and board design files at GitHub: skywire-cat-m1-modem-shield
Arduino library for controlling the Sequans Monarch and Quectel BG96 modems: TinyGSM