Stellarmetrics - remote asset monitoring using satellites

A common issue that we used to run into at my previous job was remote data monitoring. The majority of our work sites were in extremely remote areas without mobile coverage; during operations we would often have a generator, and satellite internet (Starlink) set up to provide internet access and telemetry data.

The issue comes when long term monitoring of a remote asset(s) is required, either for governmental compliance reasons or simply for data collection. It's uneconomical to leave a generator on site just to power a single Starlink, not to mention maintenance and refuelling. For mature developments, mains power is run to each individual well to provide connectivity, data, and analytics. However, for newer installations this is obviously not feasible.

Once on-site activities have ceased, the amount of data that needs to be transferred is relatively small, think wellhead pressure readings, tank water levels, salinity, temperature, etc. A coworker and I decided that we could provide semi-realtime data collection for remote assets at a fraction of the current cost by using established small-satellite networks such as the SWARM (recently acquired by SpaceX) satellite network - and specifically the Swarm M138 Modem.

The Swarm modem would allow us to offer global satellite connectivity for drastically lower prices. Small scale satellite IoT connectivity is not a new concept, and there are several companies out there creating a similar product, so we wanted to do something differently. The vast majority of the time, assets in remote areas are not located next to each other, and are often spread out over several kilometers. I had the idea to have a single Hub that act as a LoRa gateway, as well as a transceiver for the Swarm network. Each asset would then be equipped with a LoRa Node that would transmit data to the Hub. The Hub would then collate the data into a single packet that would then be transmitted to the network.

This would allow us to even further reduce costs by removing the need to have a separate Swarm modem for each asset (which made up the majority of the cost of the Hub). Through testing with long range fiberglass LoRa antennas, and by using the nodes as relays, we figured we could service an area of 15km^2 with a single Hub.

Early prototypes and proof of concept.

As with most of my electronics projects I started out with a simple breadboard, an ESP32, LoRa Module, a 3.7v LiPo battery, and a couple of OLED screens. Once I had successfully got the Swarm module to transmit to the satellite network, I pulled everything together into some EDA software and had some prototype PCBs manufactured. Luckily my struggles learning to build the the Ream Tile had finally paid off and I was able to get them mostly right the first time round (somehow).

In the image above you can see early prototypes of the Hub (in red) and a node (black). The node takes distance measurement using an ultrasonic sensor, combines the data with device UID and a timestamp, then sends it over the LoRa network to the Hub.

The Hub is continuously listening for incoming data from the nodes, and stores any incoming messages in memory. When the Swarm module detects there is a satellite overhead, it transmits it's backlog of messages all at once.

The Swarm network provides an API interface which you can setup a webhook to listen for new incoming messages. I ended up building a simple backend to listen to changes in the webhook, and save the data into a database. I then built a dashboard with react to display everything, which I talk about later.

I was stoked to finally get a working system. However, I realised that having two separate PCB designs for both the Node and the Hub was redundant, and that I could achieve the same thing with a single design, but running different firmware on each device.

The Stellarmetrics Hub

I ended up coming up with a design that could act as both a Hub or Node depending on firmware and the presence of a Swarm Module. The physical design requirements of the Hub are fairly straight forward, it needed:

• Some sort of mounting system - I figured the easiest place to start was just mounting the whole system on a star picket.
• A battery and solar panel for long-term use.
• An IP-67 rated housing.
• IP-67 rated connectors for reading multiple sensors (pressure, temperature, water level etc.) from one device.
• A custom PCB with a microcontroller to allow us to interact with the LoRa & Swarm M138 modules, any attached sensors, and a battery management/charge system.
• LoRa and satellite transmission antennas.

You can see examples of the housing I came up with below, which include 4x I2C or PWM inputs, 2 antenna ports, a power in port, a GPS module, indicator lights, and a TFT Screen.

You can see an interactive 3D model of my proposed design below. Unfortunately I never got the chance to physically build the latest version of the Hub since I moved to London shortly after designing it.

I realise that having both antennas next to each other would never work in practice due to interference, but it certainly makes the model look cooler. The Swarm network provides an API interface which you can setup a webhook to listen for new incoming messages. I ended up building a simple backend to listen to changes in the webhook, and save the data into a database.

The Stellarmetrics Dashboard

The dashboard reads the data transmitted via the sensors to the API then displays it through maps, plots, and tables. In theory the user would be able to directly control each individual sensor i.e. turning them off or on, entering sleep mode, or troubleshooting - completely remotely. The website is still very much unfinished, and is currently using example data sets that I made as a proof of concept.

I think if I was ever going to pursue the project properly I'd make the interface not so flashy, less gradients/bright colours.

The recent acquisition of Swarm by SpaceX means they have discontinued the M138 Modem in favour of a "direct to cell" system. This offers the potential of using simple 4G modems, which are ubiquitous and significantly cheaper, to provide remote connectivity instead of specialised hardware.