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:

1. Request a JPEG image from a cloud endpoint.

2. Write that JPEG image to a Micro SD card.

3. 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:

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! 💙

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...

GIF

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:

1. STM32-based Blues Swan.

2. Adafruit Micro SD breakout board.

3. SanDisk 32GB Micro SD card.

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:

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:

1. Writing and reading text files.

2. 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:

1. You'll want to keep filenames short and use the 8.3 format (e.g. MYFILE.TXT).

2. Filenames are NOT case sensitive, so in code, myfile.txt == MYFILE.TXT.

3. 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! 💙

In this article, we will perform a high-level comparison of Tadiran (i.e. Li-SOCl₂) 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-SOCl₂ 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-SOCl₂) battery. Tadiran Li-SOCl₂ 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-SOCl₂ 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-SOCl₂ batteries.

While Li-SOCl₂ 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-SOCl₂ Tadiran Batteries Work?

Li-SOCl₂ 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-SOCl₂ 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-SOCl₂ Tadiran Batteries

Li-SOCl₂ 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-SOCl₂ batteries.

However, Li-SOCl₂ 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-SOCl₂ 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-SOCl₂ Tadiran Batteries

Thanks to their unique properties, Li-SOCl₂ 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-SOCl₂ 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-SOCl₂ 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-SOCl₂ ⛔️ 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-SOCl₂ ⛔️ 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-SOCl₂ ✅ LiPo

Cost

Comparing the cost of Tadiran Li-SOCl₂ 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-SOCl₂ 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-SOCl₂ ✅ 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-SOCl₂ 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. 🔋