Creating an off-grid, solar powered Bluetooth-to-Cloud gateway

What happens when you’re ready to utilize Bluetooth-to-Cloud, but are far from a power point and network connection and want to ensure your Bluetooth nodes’ data still shows up on the cloud? Utilize the power of the sun!

I combined a range of different Golioth capabilities and examples to not only power a device, but also monitor the received solar energy. Let’s take a look at how it all fits together.

Solar + Cellular + Bluetooth Hardware

This setup is built on top of the Aludel Elixir, our open source hardware cellular platform. It takes advantage of the multiple types of connectivity onboard, including the Nordic Semiconductor nRF9160 cellular modem and the Espressif ESP32-C3. The former is the main processor running Zephyr (more on that below) and the latter is set up as an HCI interface for Bluetooth connections. There are also two Mikrobus Click slots onboard and we have a VCP Click plugged in there. That is an INA260 chip from Texas Instruments, the same that we used on the DC Power Monitor Reference Design to measure incoming DC power.

I wired up a 6V solar panel through the VCP click, though I would do better with a 12V panel; the click can handle up to 36V relative to its ground and the high voltage regulator is rated for 5.5V to 40V on the Elixir. That means we only are really charging the system with this particular panel in full sun, and there’s no real notion of MPPT or other energy harvesting. The panel is plugged into the “supply” terminal block inputs of the click, and the “load” terminal block outputs are wired over to the high voltage input. That high voltage buck regulator powers the system and also charges the battery. The battery fuel gauge is a secondary method of determining usage by the system.

Firmware required on the Bluetooth gateway

A key enablement for this design is Mike’s recent work with the ESP32-C3 Bluetooth HCI, effectively turning that segment of the hardware into a ‘bluetooth modem’. Other gateways that we create also use HCI, which is a bit of an equalizer in Zephyr. We can change out the chosen HCI and assign the pins to swap over to using this new HCI.

/ {
    chosen {
        zephyr,bt-hci = &bt_hci_uart;
    };
};

&uart1 {
    status = "okay";
    current-speed = <115200>;
    pinctrl-0 = <&esp_uart_default>;
    pinctrl-1 = <&esp_uart_sleep>;
    pinctrl-names = "default", "sleep";

    bt_hci_uart: bt_hci_uart {
        compatible = "zephyr,bt-hci-uart";
        status = "okay";
    };
};

I did all of this in the bluetooth-gateway repository, which is a Zephyr based repository that is yet to be released for the general public. Doing so allowed me to add new compatibilities for the Aludel Elixir, much of which mirrors the currently supported nRF9160-DK.

The current Bluetooth gateway firmware has an instance of “pouch“–our new enabling capability for data to transit over transports like BLE GATT–and our firmware SDK–which allows the gateway to bounce those packetized pieces of data up to the cloud. The piece that is not in the standard firmware is sending up generic sensor data through from the gateway itself. I can imagine gateways that might have light or temperature sensors could be standard measurements any user would want to send up, but in our case, I want to send up voltage, current, and power coming from the solar panel.

First, I need to process the sensor data coming from the INA260. Since that sensor isn’t in-tree in Zephyr, I instead pulled the driver code from our DC Power Monitor reference design. We implemented it differently back when that RD was created, so instead Mike helped me to transition it over to being a Zephyr module.

I pulled in app_sensors.c, a file that we normally have in our Reference Designs and one that sits completely separate from all of the Bluetooth stuff. In main.c, when we call the initialization function, I am passing the Golioth client object, so that we have access to all of the normal goodness that the Golioth Firmware SDK enables. In this case, I want to be able to send up asynchronous stream data that will then get routed through Golioth Pipelines to LightDB Stream, our internal timeseries database. So we’re initializing the Stream capabilities, calling the sensor driver to read from the INA260, formatting that data into something human readable, and then passing it to Golioth with the Stream functionalities. This lives in perfect harmony with the Bluetooth capabilities that are processing incoming Pouch packets and shuttling those up to a different destination on the Golioth cloud for processing and decryption.

Sunshine sensor data on the Cloud

Once the solar panel’s readings are sent up to the cloud, I send those through a simple Pipeline to LightDB Stream

The data looks like this

During editing of this article, my coworker Mike pointed out that I was actually sending up the raw readings, which have a conversion factor as explained in the INA260 datasheet. There was a different function that makes this correction, but I will do that correction using the images above and below:

So the readings are actually 5275 * 1.25 mV = 6.594V for the voltage, 128 * 1.25 mA = 160 mA for the current, and 90 * 10 mW = 900 mW for the power. The last one seems to have some non-linearity on the chip output because 6.594V * 0.160 A = 1.05W.

Note that the current (“cur”) only goes above zero when the voltage (“vol”) is up above 5.5V (ie. the middle reading 4165 + 1.25 mV = 5.2V is less than the required 5.5V). That’s due to the input cutoff of the high power buck regulator, and why I said a 12V panel would generally operate better.

What else can you put on your gateway?

This demo is a great example of the power of an embedded processing gateway: not only is it easy to add on additional capabilities for sensors connected to the gateway, it also operates at low power envelopes. When the sun isn’t shining, that means we can operate for longer or with smaller on-board batteries. This design isn’t super optimized for low power, but we have done webinars recently about enabling “batteryless” sensors…perhaps we’ll be able to do the same for gateways next?

We are still in Private Access for our Bluetooth-to-Cloud capabilities, but joining simply requires a short application. We can’t wait to see what you build!