Strategies for offline data collection?


(I’ll preface this by saying I’m new to building IoT solutions so excuse any obvious missed points)

I was curious what kinds of strategies folks had deployed for collection of offline data with a Helium Atom. The specific use case I’m trying to tackle is tracking temperature fluctuations of a package after it’s been shipped from origin to destination.

Specifically, a friend of mine runs a perishable foods company (they make pierogis) and to date they’ve been limited to delivering product in person because they’ve been hesitant to experiment with chilled or frozen shipping. What she’s interested in doing is dropping Atom’s into shipments, experimenting with different cooling methods, including a prepaid return envelope, and then retrieving the temperature data after the Atom syncs with the Element at the origin.

I’d love any insight in how to approach this and happy to provide any additional details.


Excellent question - and excellent use case. We certainly can’t have pierogis going bad in transit. :slight_smile:

The first question would be what hardware platform and OS would you be using to drive the Atom?


I’d be open to any platform/OS combo but probably learn towards a Raspberry Pi w/ Linux to be able to code in Python vs. C++.


We’ve seen folks develop off-line approaches using the Helium Atom for various reasons, ranging from increasing battery life to not being near a basestation for long periods of time, like you mention.

The idea is to queue up the data in your application and only occasionally sending data up. For example, for long battery life take a reading every minute, but send it every hour or even just once per day for compliance reporting.

In your case I’d queue up the readings either in RAM or in a file and try to connect to the Helium network every so now and then. If that connect succeeds, you transmit the readings, if not just continue down the normal path.

Since you’re thinking of using a Raspberry Pi, you’re likely not on a battery. If you’re going to want to be battery powered I would recommend trying a lower powered board and managing power carefully. They exist with both C/C++ and microPython as programming environments.

Finally, be aware of dropping batteries and electronics in cold environments. Batteries don’t do well at all in cold situations and most cold environments are not great for RF propagation.

Reach out if you need more details or want to talk through various options. We’re here to help!


(Embarrassingly hadn’t even considered power)

Have you guys had success with a specific microPython board? It looks like the pyboard is a good bet, would be easy to power on a battery, and can write out to an SD card to support offline storage. But wanted to make sure there’s a clear path to plugging a Helium into it.



The pyboard may work but you’d have to look at power APIs to see if you can go into low power states, but that’d be a more advanced project in any board/OS you pick.

While there is no XBee adapter for the pyboard that I could find you could wire the Helium Atom up pretty easily if you have some basic soldering skills.

The Helium Atom XBee uses 4 pins to communicate with the host MCU (3.3V, GND, TX, RX) using standard XBee pins.

Hope that helps!