DEV Community: Rob Lauer

Announcing the Raspberry Pi 50000: The Future of Computing is Just a Mouse

Rob Lauer — Fri, 14 Mar 2025 13:45:06 +0000

Banner image logo most certainly NOT provided by Raspberry Pi!

Welcome fellow Raspberry Pi nerds - and apologies in advance to the Raspberry Pi Foundation for stealing their thunder on Pi Day!

I am thrilled - no, honored - to introduce the next evolution in single-board computing: the Raspberry Pi 50000.

Many of you are aware of the Raspberry Pi 500, the groundbreaking device that was literally just a keyboard (well, and the equivalent internals of a Raspberry Pi 5).

While I don't know if the Raspberry Pi Foundation heard your feedback after the release of the 500, I certainly did.

You want to go smaller. You want to be less productive.

So, I dove into my lab and took a long, hard look at what computing really means and I made a bold decision. A decision that will redefine innovation. You want...a mouse.

I give you the Raspberry Pi 50000:

Yes. Just. A. Mouse.

It's 2025. Keyboards and monitors are barely used anymore. Remember when Apple dropped the headphone jack from the iPhone? This is like that, but even...more.

How do you use it? I assume you'll figure it out. Just like you figured out that the Raspberry Pi 500 was not, in fact, a standalone computer. You adapt. You evolve. I innovate.

What's Inside the 50000?

Prying open the "case" of the Raspberry Pi 50000, we can see the internals include a Raspberry Pi Pico (literally).

Now, and this is where we really blow your socks off, also inside this perfectly normal, borderline disposable mouse...is a Blues Notecard for cellular data access.

Yes, cellular. Because in 2025, why would you need a screen or a keyboard or even a basic computer when you can have a mouse that has full 4G LTE connectivity?

That's right, folks, you can now click your way to the future, no matter where you are. Need to record the number of clicks on your mouse? Maybe send the temperature inside your mouse to the cloud? Boom. Done.

And let's talk specs. It's a mouse. It clicks. It scrolls. But deep inside this unassuming husk, there's that tiny cellular system-on-module that's actually useful.

So How Does the Raspberry Pi 50000 Work?

Now you might be asking: "How do I use it?"

To which I say: "Why are you looking at me?"

However, to get started with that little cellular system-on-module known as the Blues Notecard and your Raspberry Pi, STM32, ESP32, or whatever host you're using, check out the Blues Developer Center for quickstarts, guides, and example apps.

In the meantime, if the Raspberry Pi 50000 is something you're actually interested in...well, best of luck to you in all your future endeavors.

Yes this is satire...yes I work for Blues...and yes I just wrote this for fun...I mean come on people did I really just need to write that? 😅

Sending and Receiving Binary Files with the Notecard and Notehub

Rob Lauer — Tue, 28 Nov 2023 16:13:33 +0000

The Notecard was originally designed as a low-bandwidth and low-power device that effortlessly syncs user-defined JSON payloads (e.g. key/value pairs of strings, booleans, and integers) with any cloud endpoint. However, one of the most-repeated requests we heard from customers is the ability to also sync larger payloads of binary data (most often in the form of images).

With the release of the Notecard developer firmware release v5.3.1, this is now possible using the new card.binary APIs. Even better, our firmware libraries for Arduino/C and Python abstract away the complexity of the card.binary requests for you.

In this article, I'm going to show an example in Arduino/C of how to:

Request a JPEG image from a cloud endpoint.
Write that JPEG image to a Micro SD card.
Send that same JPEG image back to a different cloud endpoint.

Hardware Setup

For this example, I'm using the following hardware:

Blues Swan (STM32L4-based host MCU)
STLINK Programmer/Debugger (optional, but makes working with STM32-based MCUs more pleasant)
Blues Notecard Cellular (any Notecard will do!)
Blues Notecarrier A (a development board for interfacing with the Notecard)
Adafruit's Micro SD breakout board
2 x LiPo batteries

Wiring the Micro SD Breakout to the Swan

First, you'll want to wire up the Swan to the Micro SD breakout. The following table outlines the wiring needed to connect the two:

SD Breakout	Blues Swan
GND	GND
3v	3V3
CLK	CK
DO	MI
DI	MO
CS	A3

Attaching the Notecarrier to the Swan

Next, attach the Notecarrier A to the Swan via a Qwiic cable. Note that the Swan and Notecarrier A also need to be powered separately either over Micro USB or an attached LiPo battery, as Qwiic doesn't deliver enough power to boot the Notecard.

Your hardware should look something like the following (with or without the STLINK debugger of course):

Format the Micro SD Card

If you haven't already, be sure the Micro SD card you're using is already formatted as either FAT16 (if < 2GB) or FAT32. If not, you can use a USB SD card reader with your PC to format it using the SD Association's Memory Card Formatter (available on macOS/Win and Linux).

Now it's time to write the sketch!

Looking for a shortcut? Check out this gist to see the completed sketch.

Setup the Notecard and SD Card Breakout

Include the necessary libraries in your project, including note-arduino for the Notecard and the Arduino SD Library for the Micro SD breakout board. Also, add the variables needed to interface with the components:

#include <Arduino.h>
#include <Wire.h>
#include <Notecard.h>
#include <SD.h>

Notecard notecard;
File myImageFile;
Sd2Card card;
SdVolume volume;
SdFile root;
const int chipSelect = A3;
HardwareSerial stlinkSerial(PIN_VCP_RX, PIN_VCP_TX);
#define usbSerial Serial

int ledPin = LED_BUILTIN; // references onboard LED on Swan

Initialize the Notecard and Micro SD Breakout

Most everything else occurs in the setup() method.

Set the pinMode of the Swan's onboard LED to OUTPUT so we can blink it later. Also, if you're using the STLINK, be sure to initialize it so you can see output in the serial monitor.

pinMode(ledPin, OUTPUT);

Wire.begin();

// if using STLINK debugger
stlinkSerial.begin(115200);
const size_t usb_timeout_ms = 5000;
for (const size_t start_ms = millis(); !stlinkSerial && (millis() - start_ms) < usb_timeout_ms;)
  ;

notecard.setDebugOutputStream(stlinkSerial);

Next, initialize the Notecard, link your Notecard to your project in Notehub via the product key, and reset the Notecard's binary storage area to make sure we have the space required to save an image.

If you haven't set up a Notehub account yet, you should, because it's free to use (up to 5,000 events routed per month!) and only takes an email address.

notecard.begin();

J *req = notecard.newRequest("hub.set");
JAddStringToObject(req, "product", "com.your.project:uid");
JAddStringToObject(req, "mode", "continuous");
JAddBoolToObject(req, "sync", true);
notecard.sendRequestWithRetry(req, 5);

// wait until we are connected to notehub
// this is REQUIRED when sending binary data!
bool connected = false;
while (!connected)
{
  req = notecard.newRequest("hub.status");
  J *rsp = notecard.requestAndResponse(req);
  connected = JGetBool(rsp, "connected");
  delay(2000);
}

// Reset the Notecard's binary storage area, so we can start fresh
NoteBinaryStoreReset();

Next, initialize the connected Micro SD card:

// init the SD card for usage
stlinkSerial.println("Initializing SD card...");

if (!card.init(SPI_HALF_SPEED, chipSelect))
{
  stlinkSerial.println("SD card initialization failed!");
  while (1);
}

// try to open the 'volume'/'partition' - it should be FAT16 or FAT32
if (!volume.init(card))
{
  stlinkSerial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
  while (1);
}

That's it for our initialization tasks. Next up, it's time to request an image file!

Request an Image from the Cloud

For security reasons, the Notecard cannot connect directly to any arbitrary cloud endpoint. It doesn't have a public IP address, nor would you want it to have one. This is where Notehub comes into play, as the Notecard and Notehub work together to form a secure "off the public Internet" link.

To request a binary file from a cloud end point, we'll have to set up a Notehub Route.

Routes allow you to send data from Notehub to a public cloud like AWS, Azure, or Google Cloud, a messaging platform like MQTT, or a custom HTTP/HTTPS endpoint. Routes are defined in a Notehub for a single project, and can target any number of Notecard fleets and devices.

Let's say you have a cloud endpoint that will return binary data (i.e. an image file). Make sure you have the URL of the endpoint available.

In Notehub, navigate to the Routes menu option, and create a new Proxy for Notecard Web Requests route:

Supply an arbitrary Route Name and the URL that Notehub should use to fetch the image with a GET. Also, you'll need to add an arbitrary Alias string, which is how you'll reference this Route in the sketch below.

That's it!

Back in your sketch, you'll use the web.get API to call the newly-created Notehub Route (called GetImage) and store whatever binary data is returned in flash on the Notecard:

J *req = NoteNewRequest("web.get"))
JAddStringToObject(req, "route", "GetImage");
JAddBoolToObject(req, "binary", true);

if (!NoteRequest(req))
{
  notecard.logDebug("Error receiving image\n");
}

uint32_t data_len = 0;
NoteBinaryStoreDecodedLength(&data_len);

uint32_t rx_buffer_len = NoteBinaryCodecMaxEncodedLength(data_len);
uint8_t *rx_buffer = (uint8_t *)malloc(rx_buffer_len);

// Receive the data
NoteBinaryStoreReceive(reinterpret_cast<uint8_t *>(rx_buffer), rx_buffer_len, 0, data_len);
notecard.logDebugf("\n[INFO] Received %d bytes.\n", data_len);

Save the Image to the Micro SD Card

Next, you'll want to write the saved binary buffer from the Notecard to the Micro SD card, using methods provided by the Arduino library:

// save the buffer to the specified file name on the SD card
SD.begin(chipSelect);
SD.remove("logo.jpg"); // remove the file if it already exists
myImageFile = SD.open("logo.jpg", FILE_WRITE);

if (myImageFile)
{
  myImageFile.write(rx_buffer, data_len);
  myImageFile.close();
  stlinkSerial.println("Completed writing the file!\n");
}

You can now pull the SD card out of the breakout board and pop it into your PC to see if the file was saved correctly (in my case I downloaded the Blues logo of course).

Yes you'll just have to take my word that it worked!

Send the Image Back to a Cloud Endpoint

So far you've downloaded a file and saved it to SD, but what about uploading it back to another cloud endpoint?

Welcome to the magic of Notehub Routes (yes, they work both ways)!

Back in Notehub, again navigate to the Routes menu option, and create a new General HTTP/HTTPS Request/Response route (this is different than the Proxy for Notecard Web Requests route type, as this time we will be generating a payload locally using Notes to send data from the Notecard to Notehub).

Provide an arbitrary Route Name and the remote URL that Notehub will use to POST the binary data. In my case, I used the venerable webhook.site for an easy way to inspect outbound data to the cloud.

Continue to the Filters section and be sure that you are only routing data from the Notecard that appears in the binary.qo Notefile (this is the name of the Notefile that will contain the binary payload).

All set? Back to your sketch!

const uint32_t notecard_binary_area_offset = 0;
NoteBinaryStoreTransmit(reinterpret_cast<uint8_t *>(rx_buffer), data_len, sizeof(rx_buffer), notecard_binary_area_offset);
notecard.logDebugf("\n[INFO] Transmitted %d bytes.\n", data_len);

// Send the binary data to Notehub
if (J *req = notecard.newRequest("note.add"))
{
  JAddStringToObject(req, "file", "binary.qo");
  JAddBoolToObject(req, "binary", true);
  JAddBoolToObject(req, "live", true);
  notecard.sendRequest(req);
}

// Free the receive buffer
free(rx_buffer);

stlinkSerial.println("Completed sending the file!\n");

Believe it or not, that's all that is required. In this code block, you are using the saved binary buffer that's already stored in flash on the Notecard (the image file just downloaded previously) and sending it to Notehub using the note.add API. Note that you're also supplying the binary:true and live:true arguments of note.add in order to pass the binary data from the Notecard to Notehub!

Viewing the Binary Payload in the Cloud

Depending on how you set up the Notehub Route that POSTs data, you should be able to see the binary data delivered. As mentioned earlier, I used webhook.site which lets me inspect delivered payloads. Here is a snippet of the binary file I delivered:

Wrapping Up with a Blink and a Loop

Since I like to get some visual indication that my sketch has run to completion, in the loop() method, I simply flash the Swan's onboard LED on and off:

void loop()
{
  // Finally, blink the Swan's LED when done!
  digitalWrite(ledPin, HIGH);
  delay(1000);
  digitalWrite(ledPin, LOW);
  delay(1000);
}

For a quick view of the full Arduino sketch, consult this gist.

Next Steps

What I've shown here is a relatively simple way of downloading and uploading binary data with the Notecard. More likely you may be dealing with larger binary files that have to be processed in "chunks" that the Notecard can handle. Be sure to consult our additional example Arduino sketch that shows how to accomplish this more advanced scenario.

If you haven't already, grab your own Blues Starter Kit and see how easy it really can be to sync data from a physical device to the cloud (over Cellular, Wi-Fi, or LoRa!).

Happy Hacking! 💙

The Easiest Way to Upgrade Raspberry Pi OS from Bullseye to Bookworm

Rob Lauer — Tue, 07 Nov 2023 17:26:45 +0000

If you're like me, when a new version of an OS comes out (I don't care of it's macOS, Windows, or Raspberry Pi OS) I feel an irrational need to install it. I'm also exceptionally lazy, so I usually opt for the upgrade path versus a clean install.

Today I want to take a look at how you can update a Raspberry Pi (or compatible single board computer) to the newly released "Bookworm" version of Raspberry Pi OS.

Let me be crystal clear: This is an unsupported upgrade path that is not endorsed by the Raspberry Pi Foundation.

But I also like to live dangerously.

Before continuing, I'm sure at least some of you are wondering: What exactly is Bookworm?

What is Bookworm?

Bookworm is the codename for a new version of Raspberry Pi OS. Based on Debian GNU/Linux 12, Bookworm is a significant new release for Raspberry Pi enthusiasts.

Arguably the three most important updates in Bookworm are:

A switch from the X11 Windowing System to Wayland, which improves security and performance (and includes some pleasing desktop UI updates).
Adopting PipeWire as the default audio backend (replacing PulseAudio).
Use of NetworkManager as the default network suite (replacing dhcpcd).

Bullseye to Bookworm Upgrade Options

The good news is there are multiple upgrade options from Bullseye to Bookworm.

The bad news is there are multiple upgrade options from Bullseye to Bookworm.

Easy Upgrade Path
Better Upgrade Path
Best "Upgrade" Path (the officially recommended path, but that's not why you're here)

WARNING: Regardless of the path you take, be sure to make a full backup of the SD card you're using for your current Raspberry Pi installation. Yes, just in case.

The Easy Upgrade Path from Bullseye to Bookworm

Sorry, one more warning:

WARNING: These instructions are only valid for upgrading from Bullseye. If you are currently running Buster, you'll have to install Bullseye first (but at that point, seriously, just install a fresh version of Bookworm and ignore the rest of this blog post, except for the ending).

Ready? Backup finished? Anxious to get started? Let's begin!

Perform a full upgrade of your existing Bullseye installation. Open a Terminal and enter these commands, sequentially:

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

After rebooting, enter the following command to edit sources.list, which is how your Pi references the archives for the Debian repositories:

   sudo nano /etc/apt/sources.list

Update the first line, replacing bullseye with bookworm and adding non-free-firmware to the end of the line. Your sources.list file should end up looking something like this:

   deb http://raspbian.raspberrypi.org/raspbian/ bookworm main contrib non-free rpi non-free-firmware

Type ctrl-x to exit nano, making sure you save the file on exit. Next, you need to open raspi.list (to update the Debian Bookworm base) with this command:

   sudo nano /etc/apt/sources.list.d/raspi.list

In this file, you only need to change bullseye to bookworm. Again, hit ctrl-x, save your changes, and exit.
Perform another full upgrade, but this time sourcing from the Bookworm repositories!

   sudo apt update
   sudo apt full-upgrade
   sudo reboot

And now you wait. And wait some more.

After this final reboot, confirm that you're now running an almost complete version of Bookworm with this command:

   cat /etc/os-release

Success! 🥳

However, while it looks and feels like this is a full upgrade to Bookworm, some smarter people than I have pointed out that changes like PipeWire and NetworkManager may not be properly configured via this route. That's what the "Better Way" is for:

A Better Way to Upgrade to Bookworm

Yes, there is a better way. It's not for the faint of heart though.

A brave soul on GitHub is actively updating a series of commands for a full in-place upgrade from Bullseye to Bookworm in this gist.

As of the publishing of this blog post in November 2023, here is the full list of commands. Godspeed.

### WARNING: READ CAREFULLY BEFORE ATTEMPTING ###
#
# Credit to anfractuosity and fgimenezm for figuring out additional details for kernels
#

# Make sure everything is up-to-date
sudo apt-get update && sudo apt-get dist-upgrade

# Point to bookworm repos instead
sudo sed -i -e 's/bullseye/bookworm/g' /etc/apt/sources.list
sudo sed -i -e 's/bullseye/bookworm/g' /etc/apt/sources.list.d/raspi.list

# Do actual update
sudo apt update && sudo apt -y full-upgrade && sudo apt -y clean && sudo apt -y autoremove

# Reboot
sudo reboot

# Remove old config files after doing sanity checks
sudo apt purge ?config-files

### Switch to the new kernels ###
# Prep
sudo dpkg --purge --force-depends raspberrypi-kernel raspberrypi-bootloader
sudo umount /boot
sudo fsck -y /boot
sudo mkdir /boot/firmware
sudo sed -i.bak -e "s#boot#boot/firmware#" /etc/fstab
sudo systemctl daemon-reload
sudo mount /boot/firmware
sudo apt install raspi-firmware

# Actually install the kernels. Make sure you pick the right version for your Pi
# sudo apt install linux-image-rpi-v8 linux-headers-rpi-v8      # 64bit
# sudo apt install linux-image-rpi-v7l linux-headers-rpi-v7l    # 32bit
# sudo apt install linux-image-rpi-v6 linux-headers-rpi-v6      

# Append auto_initramfs=1 to the bottom of file where it says [all]
sudo sed -i.bak '$ a\auto_initramfs=1' /boot/firmware/config.txt 

# Reboot
sudo reboot

# Verify using "uname -a" (correct as of 10/2023)
# Old kernel
# Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux
# New kernel
# Linux raspberrypi 6.1.0-rpi4-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.54-1+rpt2 (2023-10-05) aarch64 GNU/Linux

# If you are not converted to using NetworkManager, you might lose networking upon reboot. 
# Check the ARP table to see what the new DHCP assigned IP address is. You may have to manually set the IP address again
# Thanks to solsticedhiver for identifying this
#
# Switch to NetworkManager from dhcpcd
sudo systemctl enable --now NetworkManager
sudo systemctl disable --now dhcpcd
#
# Set up static IP. Adjust as necessary 
sudo nmcli -p connection show 
sudo nmcli -p connection show "Wired connection 1"
sudo nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.1.5/24 ipv4.gateway 192.168.1.1

# Reboot
sudo reboot

#
# Bonus steps
#
# Install btop
sudo apt-get install btop
#
# Update /etc/ssh/sshd_config for up to date, secure by default config. Use ssh-audit to verify
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

The Best Way to "Upgrade" to Bookworm

After all we just went through, do you really want to know what I think is the best way to upgrade to Bookworm?

Well, it's quite simple and foolproof:

Backup all of the directories and files you want to keep from your Pi.
Download and install the Raspberry Pi Imager.
Format an SD card and install a fresh copy of Bookworm.
Copy your files back to the Pi.
Success! 🥳

Easy Cellular, LoRa, and Wi-Fi on the Pi

Now that you're done, if you're in the market for a new way to add swappable Cellular, LoRa, and Wi-Fi to your Raspberry Pi, take a look at the Blues Notecard and the Blues Notecarrier Pi HAT.

The cellular-based Notecards provide 500MB of prepaid data and 10 years of global cellular service. These are commonly used in edge deployments of Raspberry Pis that don't have access to reliable Wi-Fi connectivity.

Learn more about adding low-bandwidth cellular to the Raspberry Pi in many of these project tutorials on Hackster.

Happy Hacking! 💙

Read and Write Images and Text Files with a Micro SD Card and Arduino

Rob Lauer — Tue, 24 Oct 2023 17:01:15 +0000

We've all been there. Well, at least I've certainly been there:

I want to perform what I assume to be a simple task with C (Arduino): "I just want to read and write some data to a Micro SD card! This can't be that difficult can it!?"

Five searches deep on Google, I realize there are far too many ways to skin this particular cat. Different components, different libraries, and even different libraries for the same components.

Time to take a deep breath and channel my internal Bob Ross...

This article is meant cut out the extraneous info and provide a guide for what I consider to be the easiest way to use a Micro SD card with Arduino to read/write text and image files.

In this mini-project, I'm using the following hardware:

Hardware Wiring

Since you're are only wiring a couple of components together this is a relatively simple step, but it's important to get the wiring correct:

SD Breakout	Blues Swan
GND	GND
3v	3V3
CLK	CK
DO	MI
DI	MO
CS	A3

Your wiring should end up looking like something like this:

Prepping the Micro SD Card

You'll want to make sure the Micro SD card is formatted as either FAT16 (if <= 2GB) or FAT32. If not, simply get ahold of a USB SD card reader and use your PC to format it using the SD Association's Memory Card Formatter (macOS/Win and Linux).

Slide that Micro SD card back in the breakout board and we are ready to write some code.

Arduino Micro SD Breakout Library

One of the reasons I chose Adafruit's Micro SD breakout board (aside from the generally high quality of their hardware) is because they offer well-supported and well-documented libraries. This one is no exception.

Consult this GitHub repository for the latest version of the Arduino SD Library.

Let's look at how we might perform some typical file-based tasks with an SD card, in particular:

Writing and reading text files.
Writing and reading images (PNGs).

Writing a Text File

Using a Micro SD card as a data logger is very common in our industry. They are inexpensive and a relatively stable medium.

You didn't ask, but if you want my opinion, your data should only be saved to SD as a backup. I'll always recommend you sync data with the cloud using the Cellular, Wi-Fi, or LoRa-based Notecard, but I digress...

The following sketch will initialize the SD card breakout board and write a string to a text file:

#include <SD.h>

File textFile;
Sd2Card card;
SdVolume volume;
const int chipSelect = A3;

void setup()
{
  Serial.begin(9600);

  Serial.println("Starting SD card init...");

  if (!card.init(SPI_HALF_SPEED, chipSelect))
  {
    Serial.println("SD card initialization failed!");
    while (1)
      ;
  }

  // try to open the 'volume'/'partition' - it should be FAT16 or FAT32
  if (!volume.init(card))
  {
    Serial.println("Could not find FAT16/FAT32 partition.");
    while (1)
      ;
  }

  SD.begin(chipSelect);

  Serial.println("SD initialization complete!");

  // open a new file for writing
  textFile = SD.open("hello.txt", FILE_WRITE);

  if (textFile) {
    textFile.println("Hello World!");
    textFile.close();
    Serial.println("Completed writing a text file!");
  }
}

void loop()
{
}

Note that there are a few things to be aware of when working with files:

You'll want to keep filenames short and use the 8.3 format (e.g. MYFILE.TXT).
Filenames are NOT case sensitive, so in code, myfile.txt == MYFILE.TXT.
Always close() your files when done to make sure any pending writes are properly saved.

Reading from a Text File

Now that you've written a simple text file to a Micro SD card, let's see how easy it can be to read data from an existing file (specifically the hello.txt file we just created).

Add the following code snippet after the file is created:

// open the existing file for reading
textFile = SD.open("hello.txt");
if (textFile)
{
  Serial.println("here's the data in hello.txt:");

  // read until there's nothing else in it:
  while (textFile.available())
  {
    Serial.write(textFile.read());
  }
  // close the file:
  textFile.close();
}

If you're using the serial monitor to see the output, you may be surprised to see "Hello World!" repeated many times. What's up with that?

Starting SD card init...
SD initialization complete!
Completed writing a text file!
here's the data in hello.txt:
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!

This is because writing to an existing file appends data by default and doesn't overwrite existing data. In my case, I had clearly tested the write sequence a handful of times before I read the data out.

To fix this, you can always remove() the file first:

SD.remove("hello.txt");

Other Useful Functions When Working with Files on SD

Before writing to a file, you might want to see if it already exists by using the SD.exists("thefile.txt") function.

Create directories and subdirectories with the SD.mkdir("/newdir") function.

Use the aforementioned SD.remove("thefile.txt") function to delete files.

Be sure to consult Adafruit's full tutorial for additional information on using this breakout board with a Micro SD card.

Working with Images

Let's switch gears and ramp up the complexity a little bit by writing and reading images to/from the Micro SD card.

As with every complex Arduino task, we first need to ask: "Is there library for this?". The answer is almost always "yes", and this time is no exception.

When working with image files on host microcontrollers with a relatively small amount of memory and processing power, we usually want to try to work with small files. Bitmap (.bmp) is a good format for lossless, but simple, images. Modern hosts are more often dealing with higher fidelity images that can't reasonably be sent uncompressed over the wire. This is where the usage of a format like JPEG or PNG come in handy.

Choosing the optimal type of compression to use will depend on the image itself (e.g. photos usually compress best with JPEG while drawings/line art are best compressed with PNG or WEBP).

Example of thermal camera images saved as BMP, PNG, and JPG:

And yes there are libraries for these options as well! JPGenc and JPGdec for encoding/decoding JPG images, and PNGenc and PNGdec for encoding/decoding PNGs.

Looking for a functional example of image compression in action? Check out this project on Hackster that uses a thermal camera to capture images, show them on a TFT display, and save them to a Micro SD card.

Writing an Image to a Micro SD Card

While this is a bit of a contrived example, let's strip down a code example to its bare minimum and look at how you might draw a basic image and save it to the SD card.

The following sketch creates a 128x128 image with a green border and green "x" going through it, like so, using the PNGenc library:

#include <PNGenc.h>
#include <SD.h>

PNG png;
File myPNG;
Sd2Card card;
SdVolume volume;
const int chipSelect = A3;

void *myOpen(const char *filename)
{
    Serial.printf("Attempting to open %s\n", filename);
    myPNG = SD.open(filename, O_READ | O_WRITE | O_CREAT);
    return &myPNG;
}
void myClose(PNGFILE *handle)
{
    File *f = (File *)handle->fHandle;
    f->close();
}
int32_t myRead(PNGFILE *handle, uint8_t *buffer, int32_t length)
{
    File *f = (File *)handle->fHandle;
    return f->read(buffer, length);
}
int32_t myWrite(PNGFILE *handle, uint8_t *buffer, int32_t length)
{
    File *f = (File *)handle->fHandle;
    return f->write(buffer, length);
}
int32_t mySeek(PNGFILE *handle, int32_t position)
{
    File *f = (File *)handle->fHandle;
    return f->seek(position);
}

#define WIDTH 128
#define HEIGHT 128

uint8_t ucPal[768] = {0, 0, 0, 0, 255, 0}; // black, green
uint8_t ucAlphaPal[256] = {0, 255};        // first color (black) is fully transparent

void setup()
{
    int rc, iDataSize, x, y;
    uint8_t ucLine[WIDTH];
    long l;

    Serial.begin(115200);

    Serial.println("Starting SD card init...");

    if (!card.init(SPI_HALF_SPEED, chipSelect))
    {
        Serial.println("SD card initialization failed!");
        while (1)
            ;
    }

    // try to open the 'volume'/'partition' - it should be FAT16 or FAT32
    if (!volume.init(card))
    {
        Serial.println("Could not find FAT16/FAT32 partition.");
        while (1)
            ;
    }

    SD.begin(chipSelect);

    Serial.println("SD initialization complete!");

    l = micros();

    rc = png.open("/testimg.png", myOpen, myClose, myRead, myWrite, mySeek);

    if (rc == PNG_SUCCESS)
    {
        rc = png.encodeBegin(WIDTH, HEIGHT, PNG_PIXEL_INDEXED, 8, ucPal, 3);
        png.setAlphaPalette(ucAlphaPal);
        if (rc == PNG_SUCCESS)
        {
            for (int y = 0; y < HEIGHT && rc == PNG_SUCCESS; y++)
            {
                // prepare a line of image to create a red box with an x on a transparent background
                if (y == 0 || y == HEIGHT - 1)
                {
                    memset(ucLine, 1, WIDTH); // top+bottom green lines
                }
                else
                {
                    memset(ucLine, 0, WIDTH);
                    ucLine[0] = ucLine[WIDTH - 1] = 1;     // left/right border
                    ucLine[y] = ucLine[WIDTH - 1 - y] = 1; // X in the middle
                }
                rc = png.addLine(ucLine);
            } // for y
            iDataSize = png.close();
            l = micros() - l;
            Serial.printf("%d bytes of data written to file in %d us\n", iDataSize, (int)l);
        }
    }
}

void loop()
{
}

This is a lightly-edited version of the example sketch from the PNGenc repository.

The devil is always in the details when dealing with images, as every project has differing requirements. You likely either have images pre-loaded on an SD card or you are capturing new images with a camera. If using a camera, you'll need a host MCU with enough memory to encode/compress/save the image AND you'll have to find a library specific to the camera you are using.

Reading an Image from an SD Card

Now that we can write a simple PNG image, let's see how we might read PNGs using the PNGdec library.

Your mileage may vary, but at the time of this writing, both PNGenc and PNGdec cannot be used at the same time in the same project.

The following sketch will read all PNG files from the root directory of an SD card and load them, one at a time, into memory. Again, this is not very functional because it doesn't actually "do" anything with the images, but it's a good first step:

#include <PNGdec.h>
#include <SD.h>

PNG png;
File myPNG;
Sd2Card card;
SdVolume volume;
const int chipSelect = A3;

void setup()
{

    Serial.begin(115200);

    Serial.println("Starting SD card init...");

    if (!card.init(SPI_HALF_SPEED, chipSelect))
    {
        Serial.println("SD card initialization failed!");
        while (1)
            ;
    }

    // try to open the 'volume'/'partition' - it should be FAT16 or FAT32
    if (!volume.init(card))
    {
        Serial.println("Could not find FAT16/FAT32 partition.");
        while (1)
            ;
    }

    SD.begin(chipSelect);

    Serial.println("SD initialization complete!");
}

void *myOpen(const char *filename, int32_t *size)
{
    Serial.printf("Attempting to open %s\n", filename);
    myPNG = SD.open(filename);
    *size = myPNG.size();
    return &myPNG;
}
void myClose(void *handle)
{
    if (myPNG)
        myPNG.close();
}
int32_t myRead(PNGFILE *handle, uint8_t *buffer, int32_t length)
{
    if (!myPNG)
        return 0;
    return myPNG.read(buffer, length);
}
int32_t mySeek(PNGFILE *handle, int32_t position)
{
    if (!myPNG)
        return 0;
    return myPNG.seek(position);
}

// Function to draw pixels to the display
void PNGDraw(PNGDRAW *pDraw)
{
    uint16_t usPixels[320];

    png.getLineAsRGB565(pDraw, usPixels, PNG_RGB565_LITTLE_ENDIAN, 0xffffffff);
}

// Main loop, scan for all .PNG files on the card and display them
void loop()
{
    int rc, filecount = 0;
    File dir = SD.open("/");
    while (true)
    {
        File entry = dir.openNextFile();
        if (!entry)
            break;
        if (entry.isDirectory() == false)
        {
            const char *name = entry.name();
            const int len = strlen(name);
            if (len > 3 && strcmp(name + len - 3, "PNG") == 0)
            {
                Serial.print("File: ");
                Serial.println(name);
                rc = png.open((const char *)name, myOpen, myClose, myRead, mySeek, PNGDraw);
                if (rc == PNG_SUCCESS)
                {
                    Serial.printf("image specs: (%d x %d), %d bpp, pixel type: %d\n", png.getWidth(), png.getHeight(), png.getBpp(), png.getPixelType());
                    rc = png.decode(NULL, 0);
                    // do something...anything..with the PNG file!
                    png.close();
                }
            }
        }
        entry.close();
    }
}

And what does the output look like in the serial monitor?

File: TESTIMG.PNG
Attempting to open TESTIMG.PNG
image specs: (128 x 128), 8 bpp, pixel type: 3

Success! 🥳

Summary

Hopefully you've seen how easy your first steps can be when using a Micro SD card to read and write images and text files with Arduino/C.

As mentioned above, every project scenario is different (whether you're just reading images pre-loaded to the SD card, creating PNGs from a thermal camera module, or most likely taking a picture with an attached camera module and storing them as JPEGs).

Including a Micro SD card as a data logger is a simple and effective way to store data (which of course you'll later end up syncing to the cloud via Cellular, Wi-Fi, or LoRa using the Notecard!).

Happy Hacking! 💙

When to Use Tadiran (Li-SOCl2) vs Lithium Polymer (LiPo) Batteries in IoT Applications

Rob Lauer — Mon, 10 Jul 2023 17:52:26 +0000

As a product designer or embedded engineer, selecting the appropriate battery technology is crucial for ensuring the best performance/longevity combination to power your embedded device or IoT application.

In this article, we will perform a high-level comparison of Tadiran (i.e. Li-SOCl2) batteries and Lithium Polymer (LiPo) batteries, helping you to decide which is best suited for your deployment scenario.

Specifically, we will answer the following questions:

What are Tadiran Li-SOCl2 batteries?
What are LiPo batteries?
What are the optimal temperature ranges for Tadiran and LiPo batteries?
What are the self-discharge rates of Tadiran and LiPo batteries?
What are some valid use cases for Tadiran vs LiPo batteries?
And why aren't we talking about alkaline batteries!?

What is a Tadiran Battery?

Tadiran is the brand name of a type of Lithium Thionyl Chloride (Li-SOCl2) battery. Tadiran Li-SOCl2 batteries are known for their long shelf-life (up to 40 years in optimal conditions), relatively high voltage (3.6V), low self-discharge rates (~0.7% per year), and the ability to operate in extreme temperature ranges (-80°C to 125°C).

Yes, Tadiran likes to acknowledge these "extreme" capabilities in their marketing materials!

NOTE: While known for their Li-SOCl2 batteries, Tadiran does offer Li-ion batteries as well. However, for the purposes of this article we are going to focus only on their Li-SOCl2 batteries.

While Li-SOCl2 Tadirans are not rechargeable, they are often used in low-power, long-life applications such as remote monitoring systems, smart meters, asset tracking, and IoT deployments in relatively harsh environmental conditions.

How do Li-SOCl2 Tadiran Batteries Work?

Li-SOCl2 battery technology takes advantage of the high reactivity of lithium, the lightest of all metals, and a highly electronegative chlorinated compound, thionyl chloride (SOCl2).

Two types of Li-SOCl2 battery structures. Image credit gebc-energy.com.

In these batteries, lithium serves as the anode, and thionyl chloride serves as the cathode active material. When the battery discharges, the lithium is oxidized, and the thionyl chloride is reduced. The resulting reaction generates a high nominal voltage (again, typically around 3.6V).

Pros and Cons of Li-SOCl2 Tadiran Batteries

Li-SOCl2 Tadirans shine in scenarios where a long shelf-life, low self-discharge rate, high pulses, and ability to function in wildly varying temperature ranges are key requirements. Their high cell voltage also may allow fewer batteries to be used in a series, potentially saving space and reducing complexity in the design of device enclosures.

The Tadiran PlusesPulse series of Li-SOCl2 batteries.

However, Li-SOCl2 batteries are not without their limitations. Since they are not rechargeable, once they are depleted they must be manually replaced. Therefore, they aren't suitable for high-power applications that discharge rapidly, nor in remote scenarios where solar/wind/hydro power is readily available for recharging purposes. Likewise, Tadirans are not inexpensive! Li-SOCl2 Tadiran batteries often cost considerably more than LiPo batteries when comparing $ per amp hour (though the total cost of ownership may vary, depending on the use case).

Common IoT Applications for Li-SOCl2 Tadiran Batteries

Thanks to their unique properties, Li-SOCl2 Tadiran batteries are often found in a variety of IoT deployments, including:

Utility Metering Systems: Gas, water, and electricity metering systems often use Tadirans due to their long operational lifespan and reliability.
Emergency Devices: Devices like fire/smoke detectors and alarm systems often use these batteries due to their long shelf-life.
Edge Computing Devices: Devices deployed in remote or difficult-to-access locations may want to use Tadrian batteries due to their high energy density and long operational life.

When it comes to integrating with the Blues Notecard, this specific Tadiran is ideal for the high current pulses the Notecard requires when used in a region that requires access to a GSM network:

The Blues version of the Tadiran TLP-93111 battery.

NOTE: This battery is based on the Tadiran TLP-93111 and was modified for Blues to include a JST connector so that you can easily use this battery with any of our Notecarriers.

What is a Lithium Polymer (LiPo) Battery?

Lithium Polymer (LiPo) batteries are a type of rechargeable battery that utilize a polymer electrolyte instead of a liquid electrolyte found in other lithium-ion batteries. This unique composition allows LiPo batteries to be lightweight and flexible, making them a popular choice for low-cost powering of embedded/IoT devices, consumer electronics, and devices that require custom battery sizes.

An example LiPo battery.

How do LiPo Batteries Work?

LiPo batteries work on the same fundamental principles as other lithium-ion batteries. They move lithium ions from the negative electrode (anode) to the positive electrode (cathode) during discharge - and move them back while charging. The anode in a LiPo battery is typically made of a type of lithium compound (e.g. lithium cobalt oxide), which can readily give up lithium ions.

LiPo battery structure. Image credit dnkpower.com.

Pros and Cons of LiPo Batteries

Like other lithium-ion batteries, LiPo batteries have a high energy density, meaning they can store a large amount of energy for their size and weight. Unlike Tadiran batteries, LiPo batteries can be recharged hundreds of times, making them a popular choice for many electronics devices. LiPo batteries are also lightweight, can deliver power quickly with high discharge rates, and as mentioned are very flexible in their shape and size.

LiPo batteries can be manufactured in virtually any shape or size. Image credit lipolbattery.com.

LiPo batteries are no silver bullet though - they do have some disadvantages! Care must be taken not to over-charge or over-discharge them, as this can significantly reduce their lifespan, or even cause them to catch fire. But it's important to note that most devices using LiPo batteries include safety circuits to prevent these issues from happening.

Finally, while LiPo batteries can be recharged many times, each charge and discharge cycle slightly reduces their capacity. After numerous cycles, the maximum capacity will be significantly reduced, at which point the battery may need to be replaced.

Common IoT Applications for LiPo Batteries

While there is plenty of overlap between LiPo and Li-SOCl2 Tadiran batteries in terms of use cases, lower-power and more cost-sensitive applications tend to use LiPo battery technology:

Remote Monitoring Systems: Remote systems for weather monitoring, wildlife tracking, and other environmental sensors often use LiPo batteries for their longevity, ability to be recharged, and operation in somewhat unpredictable conditions (but less "extreme" conditions than a Tadiran).
Smart Agriculture: In smart farming, sensors and devices are used for monitoring soil moisture, weather conditions, and livestock tracking. These devices often use LiPo batteries because they can provide low-cost reliable operation for an extended period.
Backing Up Home Automation Devices: Devices like smart locks, security cameras, and other IoT home automation systems are often line-powered, but also utilize LiPo batteries as a backup in case of a power outage.

So...Which Should I Choose?

The answer, as you may expect, is: "it depends on your use case!". Which of the following are most important for your deployment scenario?

Operating Temperature Range

When comparing the operating temperature ranges of Tadiran and LiPo batteries, Tadiran batteries have a clear advantage of -80°C to 125°C. Their Li-SOCl2 chemistry enables them to perform well in extreme temperatures, making them suitable for applications in harsh environments.

While LiPo batteries have a more limited temperature range (-20°C to +60°C) compared to Tadiran batteries, they still offer a wide operating range suitable for many implementations.

✅ Tadiran Li-SOCl2 ⛔️ LiPo

Longevity (Self-Discharge Rate)

The self-discharge rate of a battery refers to the percentage of charge it loses over time when not in use. This is an important factor to consider, especially for applications requiring long periods of inactivity. Tadiran batteries offer an extremely low self-discharge rate (~0.7% per year) while LiPo batteries self-discharge at a rate of up to 5% per month when not in use.

✅ Tadiran Li-SOCl2 ⛔️ LiPo

Flexibility

The unique composition of LiPo batteries allows them to be not only lightweight (which is critical for many solutions) but also flexible and able to be shaped into virtually any size or shape. Tadirans, on the other hand, are limited to very specific shapes (though considering their higher voltages, may consume less physical space in an enclosure depending on the power requirements).

⛔️ Tadiran Li-SOCl2 ✅ LiPo

Cost

Comparing the cost of Tadiran Li-SOCl2 batteries and LiPo batteries can be complex because the true cost of a battery depends on many different factors. You need to factor in its capacity along with recharge cycles/total power delivered, and the specifics by manufacturer/model (not to mention quantity purchased!).

In general, Tadiran Li-SOCl2 batteries are considered "specialty batteries" that aren't as widely available. They tend to be more expensive than LiPo batteries, as they possess the unique properties noted previously. When comparing total energy delivered between Tadiran and LiPo batteries, LiPo tends to come out ahead when it comes to total cost of ownership.

WARNING: Please note that the specifics can vary, and for an accurate and up-to-date comparison, you would need to look at the prices from various suppliers or directly from the manufacturers.

⛔️ Tadiran Li-SOCl2 ✅ LiPo

What about Alkaline Batteries?

Generally speaking, alkalines are the "worst of both worlds" in comparison with LiPo and Tadiran batteries. Aside from their low cost and wide availability, alkalines have a very low energy density (when compared to LiPo and Tadiran). This primarily impacts longevity, as devices won't last as long under comparable usage conditions. Alkalines also perform more poorly at high current-drain rates, aren't rechargeable, and their capacity decreases dramatically in low temperatures.

The venerable Duracell AA alkaline battery. Image credit Duracell.

Conclusion

When choosing between Tadiran Li-SOCl2 and LiPo batteries for an embedded device or IoT application, it is crucial to consider factors such as energy density, operating temperature range, self-discharge rate, and the specific requirements of your application.

Tadiran batteries excel in low-power, long-life applications, and in extreme temperature environments, while LiPo batteries are ideal for lower-cost deployments, scenarios where they may be recharged, and devices requiring custom battery shapes.

If you need help determining the best battery tech for your individual solution, feel free to reach out via the Blues community forum. 🔋

Use Cell Tower and Wi-Fi Triangulation to Achieve Pin-Point Locations, without GPS

Rob Lauer — Thu, 04 Aug 2022 19:00:14 +0000

Many IoT solutions include one basic requirement: to know precisely where they are in the world.

While ascertaining location is usually handled with a GNSS/GPS module, there are scenarios where GPS is not reliable or practical. In fact, I'll give you three exact scenarios:

Indoor deployments where getting a GPS satellite fix is impossible.
Use of a physical enclosure that prevents a GPS fix.
Low-power solutions that can't afford the power drain of GPS.

Here at Blues Wireless, when we talk about gathering lat/lon coordinates, we usually refer people to the onboard GPS capabilities of the Cellular Notecard, which we highly recommend as the first (and often only) way of ascertaining location.

However, today I want to look more closely at a lesser-known capability of the Notecard: Cell Tower and Wi-Fi Triangulation.

Triangulation

If you've taken basic trigonometry or geometry courses, you already know that triangulation is the process of determining a location by forming triangles to the point of interest, from a series of other known points.

The Notecard provides built-in capabilities of utilizing triangulation in a few different ways: cell tower triangulation, Wi-Fi triangulation, or both!

Cell Tower Location

If you're experienced with the Cellular Notecard, you've likely noticed the tower_ parameters that show up in Notehub events:

"tower_when": 1656000634,
"tower_lat": 43.074087500000005,
"tower_lon": -89.44282812499999,
"tower_country": "US",
"tower_location": "Shorewood Hills WI",
"tower_timezone": "America/Chicago",
"tower_id": "310,410,17169,77315594",

The tower_lat and tower_lon values are an approximate location of the single cell tower this Notecard was connected to at the given tower_when timestamp. While this is a nice (rough) location, it's not useful on its own when trying to determine the precise location of a device.

For example, here is the approximate position of the cell tower used in a recent request, relative to my location:

Cell Tower Triangulation

In scenarios where GPS is unusable, performing cell tower triangulation with the Notecard can provide a massive improvement, thanks to the magic of the card.triangulate API.

To enable cell tower triangulation on a Cellular Notecard, simply issue this request:

{
  "req": "card.triangulate",
  "mode": "cell"
}

The next time the Notecard establishes a new session with Notehub, information about every visible cell tower will be uploaded and processed. A new set of location data will appear in every Notehub event, prepended with tri_, like so:

"tri_when": 1656011112,
"tri_lat": 43.07113895,
"tri_lon": -89.43272533,
"tri_location": "Shorewood Hills WI",
"tri_country": "US",
"tri_timezone": "America/Chicago",
"tri_points": 16,

Here is the updated location estimate, based on cell tower triangulation only:

As you can see, the actual location has improved significantly, and will only improve as more cell towers are visible.

NOTE: It's important to know that cell tower triangulation comes with a non-trivial power penalty because the modem scan for nearby cell towers can take almost as long as an entire sync. Triangulation also only occurs during a connection to Notehub and there is no way to "re-triangulate" during a continuous Notehub session.

Wi-Fi Triangulation

If your host MCU has an onboard Wi-Fi module (like the ESP32), you can perform a Wi-Fi access point (AP) scan and send this data to the Notecard to perform Wi-Fi triangulation.

NOTE: Wi-Fi triangulation is an experimental, technical preview feature from Blues Wireless that is free
for use today, but may use Consumption Credits in
the future.

The format of the card.triangulate call is a little different when using Wi-Fi triangulation. Note that you can use cell, wifi, or both with wifi,cell when enabling triangulation.

{
  "req": "card.triangulate",
  "mode": "wifi",
  "text": "+CWLAP:(4,\"Blues\",-51,\"74:ac:b9:12:12:f8\",1)\n+CWLAP:(3,\"AAAA-62DD\",-70,\"6c:55:e8:91:62:e1\",11)\n+CWLAP:(4,\"Blues\",-81,\"74:ac:b9:11:12:23\",1)\n+CWLAP:(4,\"Blues\",-82,\"74:ac:a9:12:19:48\",11)\n+CWLAP:(4,\"Free Parking\",-83,\"02:18:4a:11:60:31\",6)\n+CWLAP:(5,\"GO\",-84,\"01:13:6a:13:90:30\",6)\n+CWLAP:(4,\"AAAA-5C62-2.4\",-85,\"d8:97:ba:7b:fd:60\",1)\n+CWLAP:(3,\"DIRECT-a5-HP MLP50\",-86,\"fa:da:0c:1b:16:a5\",6)\n+CWLAP:(3,\"DIRECT-c6-HP M182 LaserJet\",-88,\"da:12:65:44:31:c6\",6)\n\n"
}

What's that scary-looking text field? It's a newline-terminated list of Wi-Fi access points that follows a pattern similar to the ESP32's AT+CWLAP command output.

Deriving Access Point Data with Arduino

If you're comfortable issuing AT commands to your host MCU, you can send AT+CWLAP and format the response per the above requirements. However, not many of us are so cozy with AT syntax, which is why we provide the
Notecard Auxiliary Wi-Fi Arduino library
for an easier way of programmatically pulling a list of Wi-Fi access points with
your Wi-Fi enabled host MCU, and sending them to the Notecard in one command:

// Update Notecard Triangulation Data
aux_wifi.updateTriangulationData();

Deriving Access Point Data with CircuitPython

Developing with CircuitPython? Here is an example function that uses the built-in wifi library to gather the same WAP data when used with an ESP32 MCU:

import wifi
import binascii

def get_wifi_access_points():
    """ returns a set of visible access points, corresponds to esp32 AT+CWLAP format """
    # https://docs.espressif.com/projects/esp-at/en/latest/esp32/AT_Command_Set/Wi-Fi_AT_Commands.html#cmd-lap

    all_wifi_aps = ""

    for network in wifi.radio.start_scanning_networks():

        wifi_ap = "+CWLAP:("

        if wifi.AuthMode.ENTERPRISE in network.authmode:
            wifi_ap += "5"
        elif wifi.AuthMode.PSK in network.authmode:
            wifi_ap += "6"
        elif wifi.AuthMode.WPA3 in network.authmode:
            wifi_ap += "6"
        elif wifi.AuthMode.WPA2 in network.authmode:
            wifi_ap += "3"
        elif wifi.AuthMode.WPA in network.authmode:
            wifi_ap += "2"
        elif wifi.AuthMode.WEP in network.authmode:
            wifi_ap += "1"
        else:
            wifi_ap += "0"

        bssid = binascii.hexlify(network.bssid).decode("ascii")
        bssid = ':'.join(bssid[i:i+2] for i in range(0,12,2))

        wifi_ap = wifi_ap + ",\"" + str(network.ssid) + "\"," + str(network.rssi) + ",\"" + bssid + "\"," + str(network.channel) + ")\n"

        all_wifi_aps += wifi_ap

    wifi.radio.stop_scanning_networks()

    return all_wifi_aps

Wi-Fi Triangulation in Action

How different are my results when using Wi-Fi triangulation? Well the only access point my ESP32 was able to find was my own router. However, even with just that one AP, here are the results:

"tri_when": 1656011112,
"tri_lat": 43.07113895,
"tri_lon": -89.43272533,
"tri_location": "Shorewood Hills WI",
"tri_country": "US",
"tri_timezone": "America/Chicago",
"tri_points": 16,

Which becomes amazingly accurate when displayed on a map!

Wi-Fi triangulation becomes even more valuable when you realize the power requirements are minimal, and it adds only 1-2 seconds to the sync time with Notehub.

Be sure to consult the developer documentation on Cell Tower and Wi-Fi Triangulation as there are additional settings in Notehub that you may want to change, depending on how you use triangulation in your solution.

Triangulation with Wi-Fi Notecard

Up until now, all of these instructions have revolved around using the Cellular Notecard. What about if you're using the Wi-Fi Notecard (which doesn't have an onboard GNSS/GPS module)?

Luckily enough, Wi-Fi triangulation is enabled on the Wi-Fi Notecard by default, no configuration changes required!

After setting up a Wi-Fi Notecard, here were the results in a given event:

"tri_when": 47,
"tri_lat": 43.07121864,
"tri_lon": -89.43263674,
"tri_location": "Shorewood Hills WI",
"tri_country": "US",
"tri_timezone": "America/Chicago",
"tri_points": 3,

Which, again, when plotted on a map, comes shockingly close to landing on my location:

Summary

While GPS is the de facto standard for identifying the precise location of an IoT device, and should always be the first option when gathering location data, the Notecard's triangulation capabilities provide options when GPS isn't available.

Happy Mapping with the Notecard and Notehub! 📍🗺

Easiest Way to Add Cellular to an ESP32 IoT Project

Rob Lauer — Mon, 02 May 2022 18:45:55 +0000

I've come to appreciate the ESP32 line of microcontrollers from Espressif Systems, mostly due to a combination of low-cost, low-power, yet solid MCU performance. In particular, the ESP32-based HUZZAH32 Feather from Adafruit is a board you'll routinely see in some tutorials we post on Hackster.

Adafruit HUZZAH32

While Wi-Fi and Bluetooth are integrated into some ESP32 MCUs, adding cellular to the mix broadens the deployment options of any IoT project. Having a combination of connectivity options also enables you to use Wi-Fi when available, but fall back on cellular should Wi-Fi be unavailable or the physical location require it.

Developer-Friendly Cellular with the Notecard

The key to success with cellular IoT connectivity on the ESP32 is a secure and reliable System-on-Module, the Blues Wireless Notecard.

The Notecard is a 30mm x 35mm device-to-cloud data pump. With the included cellular and GPS capabilities (and a Wi-Fi option), the Notecard is an easy choice for securely syncing data with the cloud over a variety of global cellular protocols (specifically Cat-1, LTE-M, and NB-IoT).

And the cost? The Notecard comes prepaid with 10 years of global service and 500MB of data, starting at just $49.

But...what about the M.2 edge connector on the Notecard? How does that connect to an ESP32 microcontroller?

Probably not like this:

Easy Integration Options

Let me introduce you to the Blues Wireless Notecarriers. These are development boards that make it dead simple to connect virtually any MCU or SBC to a Notecard. You place the Notecard into the provided M.2 slot and the Notecarrier exposes all of the pins on the Notecard to the MCU.

Now it gets even easier if you're using a Feather-based ESP32 (like I often do). The Notecarrier-AF (part of the Feather Starter kit) has a Feather-compatible socket so you can insert your MCU directly onto the board, for wire-free connectivity.

The Notecarrier-AF also includes onboard antennas, two Grove I2C ports, and JST connectors for solar and/or LiPo batteries.

Notecard + Notecarrier-AF + ESP32 = ❤️

From Device To Cloud, Securely

A key component of the Notecard's security architecture is that it doesn't live on the public Internet. The Notecard doesn't have a publicly-accessible IP address. You must use a proxy, accessed via private VPN tunnels, to communicate between the Notecard and your cloud application.

This is where the Blues Wireless cloud service Notehub comes into play.

Notehub is a thin cloud service that securely (over TLS) receives, processes, and routes data to your cloud endpoint of choice. This could be a big cloud like AWS, Azure, or Google Cloud - or any IoT-optimized platform like Losant, Datacake, or Ubidots. Your own self-hosted custom RESTful API is fine as well!

As an added bonus, Notehub provides OTA firmware update capabilities along with full device fleet management and cloud-based environment variables for easily sharing data across fleets of Notecards.

When to Use Notecard, and When Not

It's important to note that the cellular Notecard is a low-power, low-bandwidth, and high-latency device. Its design center is focused on sending small packets of data (e.g. accumulated sensor readings, generated ML inferences, and the like) on an occasional cadence to the cloud.

👍 Scenarios when the Notecard makes sense:

Any low-bandwidth transfer of data over Cat-1, LTE-M, or NB-IoT cellular
Low-power edge computing deployments (agriculture, smart meters, environmental monitoring, and so on)
High-latency remote control solutions
When secure and encrypted communications are critical
When turnkey cloud integrations are desired

👎 Scenarios when the Notecard doesn't quite work:

As an "always connected" drop-in replacement for Wi-Fi
When you need sub-millisecond latency
Streaming HD video or high res images

Ready to See How it All Works?

With a Blues Wireless Feather Starter Kit for ESP32 you can follow the remainder of this blog post for a quick and easy getting started experience.

Be sure to browse our full developer site for Notecard datasheets and additional technical information.

After creating a free account at Notehub.io and initializing your first project, copy the provided unique ProductUID from the project and save it for the next step.

Programming ESP32 Firmware

The ESP32 supports commonly used languages like Arduino/C and MicroPython. While I'm an avid Python lover, most ESP32 developers are likely writing Arduino or C/C++, so we'll stick with that path for now.

The API that powers the Notecard is completely JSON-based. So technically speaking, it doesn't matter what programming language you use. We provide SDKs for Arduino, Go, C/C++, and Python and our community has built SDKs for .NET and Rust.

Whichever route you take, open up your preferred IDE and paste in this basic sketch:

// Include the Arduino library for the Notecard
#include <Notecard.h>
#define productUID "com.your-company.your-name:your_project"

Notecard notecard;

void setup() {
  delay(2500);
  Serial.begin(115200);
  notecard.begin();

  J *req = notecard.newRequest("hub.set");
  JAddStringToObject(req, "product", productUID);
  JAddStringToObject(req, "mode", "continuous");
  notecard.sendRequest(req);
}

void loop() {
  J *req = notecard.newRequest("note.add");
  if (req != NULL) {
    JAddStringToObject(req, "file", "sensors.qo");
    JAddBoolToObject(req, "sync", true);

    J *body = JCreateObject();
    if (body != NULL) {
      JAddNumberToObject(body, "temp", 25.6);
      JAddNumberToObject(body, "humidity", 48.2);
      JAddItemToObject(req, "body", body);
    }

    notecard.sendRequest(req);
  }

  delay(15000);
}

What exactly is happening in this sketch?

We are using a hub.set request to associate the Notecard with the Notehub project.
We are sending a JSON object (a Note) with mock temperature and humidity data to the cloud, over cellular.
Wait 15 seconds and do it all again!

You can build and upload this sketch to your ESP32 now, then check your Notehub project to see it in the cloud.

Cellular Data in the Cloud

Once that note.add request is initiated, your Note is queued on the Notecard for syncing with the cloud. Since we are keeping this example simple, we are also using the sync:true option in the note.add request to immediately initiate a cellular connection and send the data to Notehub ASAP.

Go ahead and head back to Notehub.io and take a look at the recently uploaded events in the Event panel for your project:

But we don't want your data to live on Notehub! The most important part of the story is securely routing your data to any cloud endpoint. Take a look at our extensive Routing Tutorials and pick your favorite cloud, such as Ubidots, and create an engaging cloud dashboard to interpret your data:

TIP: Communication with the Notecard is bi-directional in nature. This means the Notecard can also receive data from the cloud. See Inbound Requests & Shared Data Guide for more details.

Next Steps

We've barely even started our journey with cellular IoT and the ESP32! Hopefully you've seen that with minimal hardware and minimal firmware, you can easily add cellular connectivity to a new or existing IoT project.

Looking for some good next steps?

If you haven't already, pick up your own Feather Starter Kit for ESP32.
Next, the real Notecard Quickstart does a MUCH better job getting you started.
Consult the Notecard API reference to get a full grasp of the capabilities of the Notecard.
Check out all the awesome Blues Wireless projects on Hackster for inspiration.

Happy hacking on the ESP32! 👩‍💻

Thermal Image Anomaly Detection with TinyML

Rob Lauer — Wed, 16 Feb 2022 20:55:45 +0000

When I say "anomaly detection" you may imagine an overly complicated process, something exclusive to deep learning algorithms and indecipherable coding. In reality, the concept of uncovering anomalous behavior in a system is really just the act of identifying an unclassified or uncertain state.

In this Hackster project, I created a basic anomaly detection ML model with Edge Impulse that processes thermal images to detect unknown states of thermal readings and relays collected data to the cloud with the Blues Wireless Notecard.

By using the "edge ML" capabilities provided by Edge Impulse, the cellular Notecard device-to-cloud data pump from Blues Wireless, a Raspberry Pi Zero 2 W, and an Ubidots dashboard, I was able to create a simple, low-power, thermal monitoring station with only a small bit of Python coding required 🐍.

Animation of all the recorded thermal images.

Be sure to view the full tutorial on Hackster to see how this project was built from scratch!

.NET Developer? You're an IoT Developer Too!

Rob Lauer — Mon, 10 Jan 2022 18:41:08 +0000

Like many software engineers, I cut my proverbial teeth on the web. Showing off cutting edge ASP.NET web apps with the occasional AJAX request and JavaScript mouseover effect really got heads spinning back in the early `00's!

Eventually my career took a new path as I found myself in the embedded space, writing firmware with Arduino and CircuitPython to control tiny devices with microcontrollers. While I'm still a complete noob, I've had the pleasure of building everything from a solar-powered crypto miner, to a hot tub water quality monitor, to a speed trap powered by machine learning.

However, I've always lusted after combining my love for C# with the embedded world.

Lo and behold, I learned about a couple of frameworks geared towards this scenario: .NET nanoFramework and TinyCLR.

Before we look more closely at these tiny .NET frameworks, let's take a short step back and better define the concepts of "embedded development" and "IoT".

What is Embedded Development and the IoT?
The Tiniest .NET Frameworks
The "Tiny" Hardware
Getting Started with TinyCLR OS
Adding IoT to the Mix
Next Steps

What is Embedded Development and the IoT?

Embedded programming is the concept of writing code for incredibly small computers (a.k.a. microcontrollers) that communicate with sensors (e.g. temperature, gas, humidity) or power servo motors that in turn control other devices. In the embedded space, we often talk about programming "firmware", which is essentially semi-permanent software loaded into non-volatile memory on a device (it's not software or hardware, it's firmware!).

An example programmable microcontroller from Blues Wireless, the Feather-compatible Swan:

The most common languages used to write firmware for embedded devices are C/C++, Arduino (a simpler form of C), and Python derivatives like MicroPython and CircuitPython.

Embedded development is directly related to the Internet of Things (IoT) as these "things" we are building often need an Internet connection to upload the data they are gathering or the calculations they are creating.

For instance a smart...belt?

Getting slightly more practical, think about the following common devices, as they are all IoT projects at their core:

Irrigation systems that measure rainfall and only turn on when needed;
Gas/electric utility meters that can relay home energy usage remotely;
Home health monitoring devices that provide insights previously only available in a hospital setting.

This is what makes the IoT so fascinating: there are countless applications for the IoT to impact our lives in positive ways.

Now let's learn how to build something fun with C#!

The Tiniest .NET Frameworks

Both nanoFramework and TinyCLR are free frameworks for building .NET applications meant for deployment on resource-constrained embedded devices. They make it easy (or at least easier) to use C# instead of Arduino, C/C++, or a Python derivative when programming firmware on microcontrollers.

For .NET developers, this opens up an entire new world of embedded development. We can use the tools (Visual Studio) and languages (C#) that we've been using for years, all without worrying about the low-level hardware issues that can easily confound even the most dedicated embedded engineer.

It does come with a catch though. Neither nanoFramework nor TinyCLR provide access to the full .NET Common Language Runtime (CLR), and they only provide a subset of the .NET base class libraries and APIs. This is primarily because of the memory constraints on these microcontrollers. Specifically for TinyCLR, you can find a list of limitations in their docs.

What about the differences between nanoFramework and TinyCLR? At a high level they boil down down to the following:

.NET nanoFramework provides:

Support for a variety of popular ESP32- and STM32-based microcontrollers.
A fully open source offering.
Support from the .NET foundation.

TinyCLR provides:

Tight integration with specific proprietary microcontrollers.
A superior getting started experience.
An easier integrated debugging solution.

While I did some experimentation with both platforms, as an IoT and embedded engineer noob, I did find the TinyCLR experience preferable (though I know of plenty of folks who are nanoFramework fans!). Therefore, the rest of this article is going to walk through the experience of getting started with .NET on the TinyCLR OS.

The "Tiny" Hardware

As just mentioned, TinyCLR OS only runs on microcontrollers (MCUs) provided by GHI Electronics. My MCU of choice is for this exercise is the FEZ Feather:

NOTE: The Feather aspect comes from the fact that it is compatible with the Adafruit Feather specification. This means you can connect it to virtually any carrier board with header pins meant to accept a Feather-compatible MCU.

Getting Started with TinyCLR OS

Let's walk through some (relatively) simple steps to get the TinyCLR OS loaded onto your FEZ Feather microcontroller and write an embedded program using C#.

Installing the TinyCLR OS

Our first step is to install the latest version of the TinyCLR OS on the device. TinyCLR OS includes the .NET CLR which converts your compiled C# into instructions for the microcontroller. It's also used for interacting with Visual Studio (critical for loading the program onto the device and debugging).

Connect your FEZ Feather to your Windows PC via a USB-C cable:

Download the latest version of TinyCLR Config and SITCore SC20xxx firmware from the GHI electronics download page.

Open TinyCLR Config, choose the connected device in the Port dropdown, and click Connect:

To update the device firmware, click on the ... button next to the Update Firmware button. A dialog will open allowing you to select the firmware file you previously downloaded and click on Update Firmware to flash your device:

Once it's done, disconnect and reconnect the device and confirm that your firmware was updated:

Setting up Visual Studio

You also need to perform a one-time configuration of Visual Studio (these instructions are compatible with both VS 2019 and 2022 community editions).

TIP: Make sure you've already installed the ".NET Desktop Development" requirements in Visual Studio.

Within Visual Studio, navigate to Extensions --> Manage Extensions. Search for "tinyclr" to find and install the TinyCLR OS Project System.

Restart Visual Studio to enable the installer to complete the installation.

Your First "Tiny" .NET Project

Re-open Visual Studio and create a new project, choosing TinyCLROS from the platform dropdown list and selecting the C# TinyCLR Application template:

Your project will be pre-loaded with some boilerplate code and a Program.cs file. This will be the starting point of your application.

Next, we're going to perform the "Hello World!" of embedded programming: blinking an LED!

Start by replacing everything in Program.cs with the following code. Have no fear, we'll walk through what's happening in this code:

using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Pins;
using System.Threading;

namespace TinyCLRApplication
{
    class Program
    {
        static void Main()
        {
            var LED = GpioController.GetDefault().OpenPin(SC20100.GpioPin.PE11);
            LED.SetDriveMode(GpioPinDriveMode.Output);

            while (true)
            {
                LED.Write(GpioPinValue.High);
                Thread.Sleep(100);

                LED.Write(GpioPinValue.Low);
                Thread.Sleep(100);
            }
        }
    }
}

So what exactly is happening in this code?

In the Main() method we are creating a reference to the onboard LED.
In LED.SetDriveMode(GpioPinDriveMode.Output) we are configuring the LED's pin as an output, meaning it'll be in a state to manage the voltage (i.e. lighting) the LED.
Next, we get in an infinite loop (don't worry, this is very common in embedded land!) with a while (true).
We set the LED pin to High (lighting it), wait 100 ms, then set the pin to Low (turning it off), and waiting another 100ms, forever. This blinks the LED. 💡

Before you deploy the program to your device, you might notice that there are two NuGet packages to be installed first:

GHIElectronics.TinyCLR.Devices.Gpio
GHIElectronics.TinyCLR.Pins

Make sure the device is still plugged into your PC's USB port. Click the Start or F5 button in Visual Studio to compile and deploy the program. If everything works (should take 10-20 seconds) an LED on the board will blink until you unplug it or flash a new program:

Congratulations! You've literally just used C# code to control a microcontroller. This is huge! 💪

Adding IoT to the Mix

Now that you're (relatively) comfortable with building a simple C# app for deployment on a tiny microcontroller, it's time to take the next step by adding the "I" to your IoT project.

While some embedded systems can get away with storing data on an SD card for later retrieval, it's far more useful to actively transmit data as it comes in. Wi-Fi, LoRa, and Bluetooth are common technologies used in the IoT, but there is no more ubiquitous global solution for remotely transmitting data than cellular.

It's also important to consider not only the raw technical ability of communicating over cellular, but also how you then get this data to a cloud endpoint, such as Microsoft Azure.

Introducing the Blues Wireless Notecard

Cellular has traditionally scared developers due to its archaic AT command syntax (it's an awful developer experience) and likewise businesses have been afraid of the price (per-device monthly plans add up fast). So the key to cellular success lies in a tiny pre-paid device-to-cloud data pump called a Notecard.

With both cellular and GPS capabilities (and 10 years + 500 MB of data included) the Notecard is a no-brainer for when you want to start pushing data to the cloud over LTE-M, NB-IoT, or Cat-1 cellular.

But what about that strange M.2 edge connector at the bottom of the Notecard? How do you use this with the microcontroller we just programmed? The answer comes in the form of the Notecarrier:

The Notecarrier acts as a bridge between your MCU and the Notecard. It includes an embedded antenna, header connectors, and battery ports to allow you to easily connect it to your prototype.

Here is the FEZ Feather wired up to a Notecard + Notecarrier, ready to send data to the cloud over cellular!

The white board you see is called a breadboard, and is used to quickly create connections between the MCU and the Notecarrier.

If you're following along at home, here are the connections being made with those jumper wires:

Supplying power to the Notecarrier from the FEZ via the V+ and GND pins (the black/blue and orange/red wires).
Communicating over I2C by connecting the SCL and SDA pins (the longer orange and green wires).

All JSON, All the Time

To me, the real beauty of the Notecard comes from its developer experience. Every command to (and every request from) the Notecard is JSON.

For example, here is an API command that will tell you the current GPS location of a Notecard:

{"req": "card.location"}

And an example response from the Notecard:

{
  "status": "GPS updated (58 sec, 41dB SNR, 9 sats) {gps-active}
            {gps-signal} {gps-sats} {gps}",
  "mode":   "periodic",
  "lat":    42.577600,
  "lon":    -70.871340,
  "time":   1598554399,
  "max":    25
}

Adding Wireless Capabilities

Knowing all of this, let's see how easy it can be to send a small packet of data, over cellular, to the cloud.

Once again, you can remove everything in your Program.cs file and replace it with the following:

using Bytewizer.TinyCLR.Drivers.Blues.Notecard;
using GHIElectronics.TinyCLR.Devices.I2c;
using GHIElectronics.TinyCLR.Pins;
using System.Diagnostics;

namespace TinyCLRApplication
{
    class Program
    {
        static void Main()
        {
            // setup I2C bus for Fez Feather
            var controller = I2cController.FromName(SC20100.I2cBus.I2c1);
            var notecard = new NotecardController(controller);

            // associate this Notecard with a Notehub.io project
            var request1 = new JsonRequest("hub.set");
            request1.Add("product", "com.blues.me:some_project"); // replace this with your product uid!

            var results1 = notecard.Request(request1);
            if (results1.IsSuccess)
                Debug.WriteLine(results1.Response);

            // create a mock JSON body object
            var body = new JsonObject();
            body.Add("temp", 35.5);
            body.Add("humid", 56.23);

            // create a "note" with the JSON body from above
            var request2 = new JsonRequest("note.add");
            request2.Add("body", body);
            request2.Add("sync", true);

            var results2 = notecard.Request(request2);

            if (results2.IsSuccess)
                Debug.WriteLine(results2.Response);
        }
    }
}

If you look carefully, you can see that to program the Notecard, we are simply building JSON objects that correlate to commands available in the Notecard API:

The hub.set request associates the Notecard with a project on Notehub.io (more on Notehub in the next section!).
We are creating a JSON object that stores some mock temperature and humidity data.
We are sending this data (a Note in Blues Wireless speak) to the cloud with a note.add request.

Before running this program, there is one more NuGet package to include:

Bytewizer.TinyCLR.Drivers.Blues.Notecard

Go ahead and click Start or hit F5 in VS to build and deploy your cellular-connected IoT project!

In the debug output, you should see {"total":1} which is the Notecard telling you that there is a single event being sent to the cloud.

To the Cloud

Yes, I got ahead of myself. We started pushing data to the cloud without fully understanding where in the cloud the data was going!

We first need to understand that a key benefit of the Notecard is security. The device itself lives off of the public Internet. It's a cellular data pump, meaning it needs to connect to secure proxy to deliver data over the Internet.

This is where Notehub comes into play. Notehub is a thin cloud service that securely receives and syncs data with virtually any cloud (think AWS, Azure, Google Cloud, or even your own custom MQTT or RESTful endpoint).

To start, we can simply see this mock data appear in Notehub, ready to be routed to its final home on a big cloud ☁️:

Routing Data to Azure

Since Notehub is not the final resting place of our data, naturally we will want to automatically sync this data with a big cloud such as Azure.

To do so, you can follow the in-depth routing tutorial for Azure that walks through building your own cloud-based dashboard using data delivered with the Notecard.

Finally, while it's outside the scope of this article, as data is being passed to Azure you can alter and optimize your JSON payloads with JSONata on-the-fly. Using JSONata you can write server-side functions that can alter data to conform to whatever structures your endpoint is expecting.

Next Steps

If this has piqued your curiosity, I highly recommend taking the following steps in your C# IoT journey:

Read more about what the .NET nanoFramework and TinyCLR have to offer to .NET developers.
If you want to follow this tutorial, grab your own FEZ Feather, Notecard, and Notecarrier-AL.
If you want to tinker with cloud connectivity with Python on a Raspberry Pi or by writing some Arduino, check out the Blues Wireless starter kits.

Happy hacking with C# and the IoT! 👩‍💻

Easiest Way to Add Cellular to the Raspberry Pi Zero 2

Rob Lauer — Mon, 20 Dec 2021 15:08:47 +0000

This holiday season I'm thankful for many things, not the least of which is the fact that I got my hands on the new Raspberry Pi Zero 2 W! And I have to say, it's been an absolute dream to work with.

Building on the foundation of the original Raspberry Pi Zero, the 2 W includes a significantly improved CPU (a quad core Cortex-A53 @ 1 GHz to be precise) and improved wireless performance over its Wi-Fi enabled predecessor.

Now while Wi-Fi is a great connectivity method for the IoT, adding cellular access to the Zero can turn it into a truly "off-grid" Raspberry Pi. You may also want to enable cellular as a fallback connectivity method in case Wi-Fi goes down. Either way, read on for a quick tutorial on the easiest way to add cellular connectivity to the Raspberry Pi Zero (1 or 2!).

Introducing the Notecard

The key to your success with adding cellular communication capabilities to the Raspberry Pi Zero is the Notecard.

The Notecard is a tiny 30mm x 35mm device-to-cloud data pump. With both cellular and GPS capabilities (and predictable pricing that starts at $49 for 10 years and 500 MB of data) the Notecard is a no-brainer for when you want to start pushing data to the cloud over LTE-M, NB-IoT, or Cat-1 cellular.

But what about that M.2 edge connector at the bottom of the Notecard? How on earth do you use this with a Raspberry Pi single-board computer (SBC)? The answer comes in the form of a HAT (the Notecarrier-Pi HAT that is).

The Notecarrier-Pi is a HAT (Hardware Attached on Top) that's compatible with every Raspberry Pi SBC. It includes pass-through headers for stacking multiple HATs, a Grove I2C port, and an external antenna.

Installing the Notecard and Notecarrier-Pi HAT

I'm not here to insult your intelligence, nor do I want to waste your time. I state this because the physical installation steps are about as simple as you might expect when working in the Raspberry Pi ecosystem!

1) Slot the Notecard into the provided M.2 slot and screw the Notecard onto the HAT:

2) Plug the Pi HAT into your Raspberry Pi Zero's 40-pin header:

3) Plug the provided molex antenna into the MAIN u.FL connector on the Notecard:

And yes, that's the end of the installation tutorial!

Get the Raspberry Pi Zero Ready

There are a few one-time configuration steps to make the development experience as seamless as possible.

First, open up the "Raspberry Pi Configuration Tool" with:

sudo raspi-config

...and enable the I2C interface if it isn't already enabled.

Verify that the Pi HAT is correctly installed by using i2c-tools:

sudo apt-get install -y i2c-tools
sudo i2cdetect -y 1

The second command should show the Notecard on the correct I2C address (0x17).

Install the note-python and python-periphery libraries:

sudo pip3 install note-python python-periphery

And you are good to go!

Send Some Data to the Cloud Over Cellular

Since the Notecard API is 100% JSON-based (literally, everything is JSON in and JSON out), it doesn't matter what programming language you use. But since we are on a Raspberry Pi, we are going to stick with Python.

Open up your preferred text editor (Thonny is a nice one for Python development on the Pi) and paste in this entire code block. We'll go through a few important bits afterwards:

import notecard
from notecard import hub, card, note
from periphery import I2C

productUID = "com.gmail.something:pizero"
port = I2C("/dev/i2c-1")
nCard = notecard.OpenI2C(port, 0, 0)

# associate Notecard with a project on Notehub.io
rsp = hub.set(nCard, product=productUID, mode="continuous")

# send a single "note" to the cloud over cellular!
rsp = note.add(nCard, file="pi.qo", body={"Hello":"World!"})

Now what's all going on here?

We are opening a communication port on the I2C bus (/dev/i2c-1).
We are using the hub.set API to associate the Notecard with a Notehub project (more on Notehub below).
We are sending the JSON "Hello World!" object to the cloud, over cellular.

Viewing Your Cellular Data in the Cloud

Yes, we did put the cart before the horse by going through the Python code prior to setting up the cloud service that receives data. So now is a good time to run through what Notehub is all about.

Notehub is a cloud service from Blues Wireless that provides the ability to securely receive, process, and route data to your cloud endpoint of choice. This could be AWS, Azure, Google Cloud, or any number of IoT platforms like Datacake or Ubidots (or even your own custom RESTful API).

Notehub also provides OTA firmware update features, fleet management, and cloud-based environment variables for easily sharing data across fleets of Notecards.

After creating a free account at Notehub.io and setting up your first project, you'll want to copy the provided ProductUID and paste that into the product parameter in the hub.set call in the Python script above.

Upon running the Python script, the note.add function will be executed. You can then log into the Notehub project and view related events in the Event panel:

From here you can set up a Notehub route to start relaying data to any cloud endpoint.

TIP: The Notecard can also receive data as documented in the Inbound Requests & Shared Data Guide.

Next Steps with the Pi

Clearly we've only just scratched the surface with the Notecard and Raspberry Pi Zero. Hopefully you've witnessed how ridiculously easy it is to add cellular connectivity and send data to the cloud in a matter of minutes.

If you're looking for some good next steps, I can recommend:

Grabbing your own Raspberry Pi Starter Kit.
Following the complete Notecard Quickstart Tutorial.
Learn how to route data to your cloud of choice.

Happy hacking on the Pi Zero! 👩‍💻🥧0️⃣

The Idiot-Proof Guide to Upgrading Raspberry Pi from Buster to Bullseye

Rob Lauer — Tue, 07 Dec 2021 17:20:54 +0000

Title photo by [Silvan Arnet (https://unsplash.com/@silvanarnet) on Unsplash

A couple of weeks ago I enjoyed a very traditional Thanksgiving at home: I spent the day avoiding my extended family and proceeded to upgrade my home computers to their latest OS versions!

While migrating to macOS 12 Monterey and Windows 11 were relatively painless point-and-click procedures, upgrading my Raspberry Pi 4 model B single-board computer from the Buster release to Bullseye involved a few extra steps. I'll admit the difficulty of this process was exacerbated by the fact that I wanted to perform an in-place upgrade to maintain all previously installed packages and stored files.

A New Raspberry Pi OS?

You heard that right, a new version of Raspberry Pi OS (codenamed Bullseye 🎯) was released a few weeks ago. It's based upon Debian 11 and on the right hardware can provide a significant speed boost with certain tasks. There are numerous updates and enhancements to be found in Bullseye, not the least of which include:

An updated PiCamera driver (which will require re-writing your code BTW);
Replacing GTK+2 with GTK+3 to provide an improved GUI;
Using Mutter instead of Openbox for window management (if your Pi has >= 2GB of RAM);
A fresh new notification manager in the taskbar;
A better updating experience for installed packages;
An update to the Chromium browser (v92), which supports hardware-accelerated video playback.

For a complete list of Raspberry Pi Bullseye updates, consult this article from the folks at Raspberry Pi.

This new release of Raspberry Pi OS does technically work with any Raspberry Pi SBC (yes, including the Raspberry Pi Zero). However, unless you need features from Bullseye specifically, you might want to stay on your current release. Owners of a "4.x" Raspberry Pi (e.g. the
Raspberry Pi 4, Compute Module 4, or the Raspberry Pi 400)
will likely choose to upgrade regardless.

Upgrading Caveats

Before you begin, I can't stress enough that the best (and frankly, supported) way to upgrade to Bullseye is to backup all of your critical files and perform a clean install using the Raspberry Pi Imager. However, if you're like me and choose to live dangerously, be sure to backup your files anyway and buckle up for the ride.

Please be aware that the following process is not officially supported AND may temporarily disable Wi-Fi (see the note below) or lead to other unintended issues. Backup any critical files on your RPi before proceeding!

Step-by-Step Installation of Bullseye

Disclaimers aside (did you read the warning above?), here is a step-by-step set of steps for you to upgrade from Buster to Bullseye via the Raspberry Pi terminal.

1) Open your Raspberry Pi terminal and update the repository lists:

$ sudo apt update

2) Install all of the latest packages (and their dependencies):

$ sudo apt full-upgrade

3) Reboot your Pi to activate any packages that require a reboot:

$ sudo reboot

4) Optional, if you like to live on the edge! Update to the latest version of the Raspberry Pi firmware:

$ sudo rpi-update

Another reboot may be necessary after updating your firmware.

5) Next, edit your sources.list file to switch your repository list from Buster to Bullseye:

$ sudo nano /etc/apt/sources.list

Locate the following line and change buster to bullseye:

deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi

Save your changes and proceed to the next step.

6) Update your repository lists again (this time it will be using the Bullseye-specific repositories):

$ sudo apt update

7) Install the latest version of Node.js (this helps avoid an error you may receive when running apt full-upgrade in step 9). This step may take several minutes.

$ sudo apt install nodejs

Note that you may receive a prompt to "Restart services during package upgrades without asking". If so, choose "Yes".

8) Update to the latest version of GCC 8 (this also helps avoid an error in the next step).

$ sudo apt install gcc-8-base

9) Run another full upgrade to install any additional Bullseye requirements and downstream dependencies:

$ sudo apt full-upgrade

NOTE: It's at this point your Wi-Fi may go out! We'll fix that in a bit.

10) Clean up your packages to remove any that are obsolete or no longer used:

$ sudo apt autoclean
$ sudo apt autoremove

11) Next, you need to alter your /boot/config.txt file to enable KMS (the new standard video driver). This is done by default with a clean install, but our
upgrade process requires this change to be performed manually. Thanks to Linux Uprising for this tip!

$ sudo sed -i 's/dtoverlay=vc4-fkms-v3d/#dtoverlay=vc4-fkms-v3d/g' /boot/config.txt
$ sudo sed -i 's/\[all\]/\[all\]\ndtoverlay=vc4-kms-v3d/' /boot/config.txt

12) When you're all done, reboot your Pi:

$ sudo reboot

13) After a reboot, check to see if everything was updated properly:

$ cat /etc/os-release

This should return the following:

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Wi-Fi Not Working?

To reclaim your Wi-Fi, go to "Preferences" --> "Connman Settings" --> "Wireless" and then click on the SSID to which you want to connect. You may also want to click the ⚙️ icon next to the SSID and enable "autoconnect".

If any wireless or network panels are missing from the taskbar, you can re-add those by right-clicking on the taskbar, choosing "Add/Remove Panel Items", then adding the appropriate panels.

If those suggestions didn't work, consult some forum threads
here and here that may help.

Great Success...?

It should be stated again here (at the end, when you've already made the mistake of performing an in-place upgrade 😅) that this process is not officially supported by Raspberry Pi. Rather the supported upgrade path is a clean installation of Bullseye using the Raspberry Pi Imager.

While you're here, if you're curious about adding wireless cellular capabilities to your Raspberry Pi, check out the Notecard and get 10 years and 500 MB of cellular data using the Raspberry Pi starter kit!

Happy Hacking on the Pi! 👩‍💻

Debugging a Hot Tub Time (Series) Machine

Rob Lauer — Thu, 11 Nov 2021 15:21:38 +0000

I don't mean to sound like a prude or anything, but when a neighbor invites me over for a hot tub party, I'm gonna hope the hot tub itself looks a little more like the one on the left, than the one on the right:

You might not know it, but even a clean-looking hot tub or pool can still harbor nasty bacteria! So how can we make hot tubs and pools around the world safer, and frankly, more fun? In this Hackster project, I walk through how I built an IoT project with:

A variety of water quality sensors from DFRobot;
A new Feather-compatible microcontroller (spoiler: Swan);
A cellular device-to-cloud data pump (another spoiler: Notecard);
A cloud-based dashboard from Losant populated by time series data;
PLUS an SMS notification from Twilio for chlorine emergencies!

Interested in a preview of this project? Check out the project trailer on YouTube:

As an owner (or even user) of a hot tub, it's a pain to keep your water clean. You have to maintain the proper chlorine and pH levels by regularly sampling the water, running tests, waiting for the results, adding chlorine, sampling again, and repeating until your levels stabilize appropriately.

This whole process of sampling the water, running tests, waiting for the results, adding chlorine, sampling again, and repeating until your levels stabilize appropriately is dying for automation. The beauty of the IoT too, is that we can take a semi-traditional sensor project and build it out into a robust cloud-based dashboard with proactive SMS text messages for alerting.

Check out the completed project on Hackster!