Firmware Modules has been investigating, for two years now, how blockchain may be used in IoT applications. We have built and maintained the Measurement Earth blockchain-based open-data cloud platform and a few outdoor air-quality (AQ) particulate matter (PM) sensing devices to demonstrate the technology.
The public blockchain platform is used for two key purposes - to ingest and authenticate the sensor data source. With dozens of access points geographically distributed around the world, regular HTTP requests can be used to access the blockchain to submit data. The blockchain authenticates the data source due to the very nature of blockchain itself - only transactions digitally signed by the data sources can be accepted onto the chain. In our case the data sources are our sensors and they securely store a secret key known only to them while performing the transaction generation and signing process on-board.
The public blockchain we're using is called Telos, based on EOSIO blockchain technology launched in 2018 and recently forked into something called Antelope. We chose this blockchain because of its compatibility with low-power IoT devices: standard cryptography for which small C-based libraries are available and a staking-based blockchain resource allocation model. This means that a small fee is paid once and a device can send data to the blockchain indefinitely. This feature is attractive compared to alternatives like Ethereum that require a fee (gas) per transaction (i.e. sensor measurement).
The following infographic offers a high-level view of the entire system.
Our devices use STM32 MCUs at their core and LoRa radios to communicate indirectly with the blockchain. Since blockchain requires HTTP protocol access, we need an intermediary technology to move data between a LoRa radio link and an HTTP cloud endpoint which I discuss below.
The project began using STM32L072Z MCUs bundled with Semtech SX1272 radios in the Murata Type-ABZ modules. For these, we also built a custom over-the-air LoRa protocol and single-channel gateway using NUCLEO-F429ZI boards with Ethernet. The gateway has the same Murata Type-ABZ module attached that runs our LoRa "gateway" firmware to forward packets to/from the F429ZI over UART. The F429ZI acts as a LoRa-to-ethernet bridge, using the LwIP stack to make the HTTP requests to forward the AQ device's signed transactions received over LoRa directly to the blockchain. This solution is still operating to this day for a few of our AQ sensors. For this solution we don't need the Helium network nor the Helium->Telos bridge server, but this tradeoff requires a costlier and more complex rollout than a solution that could use existing gateways.
In early 2022 we took a closer look at the Helium network. Under the hood, Helium differs very little from a LoRaWAN network like The Things Network (TTN). However, Helium has a much smoother onboarding process through their slick Console application, don't impose any "community" limits on data throughput beyond standard regulatory, and has vastly more coverage. It is for these reasons and more that we decided to jump on board and give Helium a go. The prime benefit would be to eliminate the need for our own custom gateway for a field deployment. I will make a note here that there are elements to Helium that are also considered "blockchain", however this part of Helium has nothing to do with our blockchain back-end (Telos) and the Measurement Earth platform. We are only using Helium's radio and packet-forwarding LoRaWAN technology to get our own blockchain transactions to the cloud.
The firmware running on our blockchain AQ sensor devices is a custom-designed solution called Measurement Earth OS (or ME-OS). We added the LoRaMac-node stack from GitHub for the capability to join to and utilize the Helium network. One thing to note here - the blockchain transactions are relatively large, about 195 bytes including all sensor and metadata plus transaction signature. This fits into only the fastest LoRa mode - spreading factor 7. This means we lose a bit of range, but this is where Helium shines again - with such dense deployment coverage the sensor is always within range of a gateway (usually many) in an urban environment.
The last piece of the communications path is to connect the Helium network to the Telos blockchain. Unfortunately there is no built-in way to do this. Even the generic HTTP endpoint integration is not compatible with the Telos blockchain access points. To work around this we partnered with KandaWeather (now AscensionWx) to use their existing MQTT-based Helium to Blockchain binding app server, with some modifications, to complete the "last mile" between our AQ sensors, Helium, and the blockchain itself.
The system has proven to be quite resilient and the data dutifully gets onto the chain visible to all and useable for any purpose.
The extra capability to access LoRaWAN/Helium required more flash and RAM than the Murata modules could offer. Plus, they have been unavailable for quite some time. Our latest iteration of the AQ sensor device - so-called V2 devices - uses the SeeedStudio LORA-E5-MINI board (aka WIO-E5-MINI) that features the new STM32WLE5 MCU. This is an STM32L4 device that integrates the Semtech SX1262 LoRa radio on the same die while offering more than enough SRAM and flash to host ME-OS with Helium and EOSIO transaction generation & signing, along with our STM32 Secure Patching Bootloader to securely manage firmware updates in the field.
Our AQ sensor devices are fully independent - harvesting energy from the sun via solar panels and storing excess energy in a LiPo battery for use overnight and during periods of extended cloud cover. They are using all off-the-shelf available hardware and components, all of which is described in the infographic below. The energy consumption, even with these off-the-shelf components, is low enough that the unit can run for about a week without direct sunlight.