Author Archives: Paul

LoRaWan one-channel, Heltec solution

Posted on by
Reply

While researching my previous article on how a Single Channel LoRaWAN gateway works, I came across an interesting solution developed by Heltec. Their approach consists of reusing the enclosure and potentially some of the hardware of a small environmental sensor, which already integrates most of the components required to build a Single Channel gateway. They may have adapted or simplified the original hardware to create this dedicated product.

What makes this solution particularly interesting is its price and form factor. At less than $20, it is extremely affordable and compact. Compared to the development boards I used in my previous experiments, it also offers a much cleaner and more professional design, making it better suited for actual deployments rather than just laboratory testing.

I contacted Heltec to purchase one of these devices, but they explained that the product was not currently commercially available. Fortunately, they still had a few units in stock and kindly agreed to send me some samples.

My next step is therefore to deploy the LonaWan Single Channel gateway solution on this device and evaluate how well it performs. Given its low cost, compact size, and installation-friendly design, it looks like a particularly promising platform for the use case I am exploring.

Continue reading →

LoRaWan Single Channel Gateway

Posted on by
Reply

I wanted to explore whether a simple ESP32 could be used to build a LoRaWAN gateway.

To be clear from the start, the goal is not to replace a proper LoRaWAN gateway with an ESP32. Such a setup comes with significant limitations: the ESP32-based gateway will only be able to listen on a single channel. This makes it unsuitable for deploying an actual LoRaWAN network, especially when compared with standard gateways capable of listening simultaneously on multiple channels and spreading factors.

Still, there are situations where such a limited gateway can be useful.

The most obvious one is a home or lab environment. If you have an ESP32-based device that you want to connect to LoRaWAN but do not have a gateway available, building a simple single-channel gateway can be an inexpensive way to get started.

My interest, however, is also in a slightly more professional use case. Within an existing fleet of LoRaWAN devices, there may be a few devices located outside the current coverage area, or devices experiencing persistent coverage issues. Deploying an additional full LoRaWAN gateway to cover only a handful of devices can be relatively expensive and may be difficult to justify or to deploy with B2C products like smart home appliances.

In that situation, a small ESP32-based gateway could provide an interesting temporary solution. It may also be more practical than introducing LoRaWAN relays, considering that relay support and deployment models are still not as mature as conventional gateway-based architectures.

I therefore see this approach primarily as a lightweight or transitional solution: something that can provide local connectivity for a limited number of devices without requiring the immediate deployment of another full-featured gateway.

Continue reading →

LILYGO T-Deck Plus with Meshcore

Posted on by
Reply

The challenge with mesh networks such as MeshCore, Meshtastic, or similar systems is that a phone is still the most practical device for reading information, sending messages, and typing on a keyboard. However, the phone also needs to be connected to a node that can act as the bridge to the LoRa network. In practice, this means carrying several devices, which is not always convenient.

That is why I wanted to test the LILYGO T-Deck Plus. It is a LoRa device with the useful addition of a built-in screen and keyboard. This makes it possible to have a standalone device for communicating on these networks, and it should make mobile testing much easier.

I tried one, and in this post I will share the different steps I followed to get it working.

Continue reading →

Seeed Spartan Edge Accelerator Board, low cost FPGA

Posted on by
Reply

About 20 years ago, I started working on the design of a microprocessor. The goal was mostly to have fun building a small 32-bit RISC CPU, make it open source, and, most importantly, explain the process behind it. I abandoned the project roughly 18 years ago as I moved on to other things.

This year, I want to bring the project back. Processor design was something we used to learn in univerity at the time, but today it has become much more abstract. Even understanding what actually happens inside a processor is now often treated as a fairly distant concept.

That old work is a good foundation for explaining these ideas again. For that reason, I wanted to refresh the hardware I used years ago to build the processor, which was based on an FPGA that I will discuss in more detail later. Because this is relatively professional hardware, access to FPGA development kits is usually quite expensive. And while it was honestly worth the investment, Seeed Studio has since created a development kit looking like an Arduino, includes an ESP32, and remains much more accessible. It integrates a Xilinx Spartan FPGA. It is not one of the high-end models, but it is still roughly ten times larger than the one I was using around 20 years ago, which makes it a very good fit for this project.

Continue reading →

MeshCore, the new Kid on the LoRa Mesh Block

Posted on by
3

A while ago, I wrote about Meshtastic. At the time, Meshtastic was the thing everyone was talking about: tens of thousands of nodes sold, many products packaged by HELTEC, LILYGO, RAK, and Seeed Studio, and a large international community building a LoRa-based mesh network for long-range communication.

But Meshtastic was yesterday’s trend. Today, the new momentum is around MeshCore, with a significant part of the community migrating to it, especially because the required hardware platforms are largely the same. However, as we will see, MeshCore and Meshtastic are not the same thing. They are not really meant to replace each other, except perhaps for specific use cases where Meshtastic was not particularly well suited and where MeshCore provides more appropriate solutions.

This article introduces MeshCore from a technical and operational point of view, to help clarify what it is and how it works.

Continue reading →

ShellHub, not a new CVE, just a nice tool to manage remote RPI devices

Posted on by
2

I think, like me, you have often encountered the problem of having to manage Raspberry Pi devices that are deployed remotely and behind a NAT. In previous articles, I discussed solutions using SSH, SSH tunnels, and port forwarding. It is a solution I like, but it is somewhat complex to set up and not always very stable. I eventually found a tool that I find interesting and that can be deployed, called ShellHub, which makes this a bit easier to do.

Continue reading →

The End of IoT Platforms — Why the Future Is the IoT ERP

Posted on by
1

IoT platforms emerged early in the history of IoT, arguably too early. At the time, the industry was driven by momentum and the urgency to provide ready-to-use solutions.

Over the past decade, however, many of these platforms have been discontinued, transformed, or fundamentally redesigned. This evolution is not accidental; it reflects a deeper structural issue in how the first generation of IoT platforms was conceived.

Continue reading →

Meshtastic, solar nodes

Posted on by
Reply

Meshtastic is a network without infrastructure—a true mesh network. However, if the goal is to achieve wide-area coverage, relying solely on portable nodes or devices installed at home is not enough. Deployment on elevated sites, ideally outside urban areas, becomes essential. One of the major advantages of this technology is that it does not require an Internet connection and consumes very little energy, making solar-powered operation a realistic and sustainable option. This also opens the door to deployment in open countryside or remote locations. With that in mind, I explored autonomous solar-powered solutions designed to extend network reach. I was able to test two of them, which turned out to be very different in both quality and price—unsurprisingly, the two aspects are closely linked.

Continue reading →