Wingbits, The DePIN FlightRadar24, ADS-B setup review

Wingbit is a new DePIN blockchain whose goal is to collect ADS-B information provided by aircraft in flight to enable precise tracking, similar to what we know from FlightRadar24, but with a more massive, dense, and global approach. The underlying business model is the resale of this information to companies interested in exploiting it. It remains to be seen how large the demand for this will be in the long term.

However, this project is quite engaging, centered around a topic that resonates with many people, even outside the blockchain and geek spheres. Since it involves radio reception, the choice of hardware is an important consideration when starting the project. As a result, I conducted a small benchmark of various easily accessible equipment to design an efficient, low-cost receiver.

This article will interest anyone who wants to receive aircraft information (ADS-B), including for other projects, as Wingbit has just closed the possibility of building your own receiver.

Continue reading

Critical Analysis of the Meshtastic Protocol

Meshtastic is a mesh protocol (peer-to-peer, network by proximity) based on LoRa technology. LoRa is not LoRaWan, just as WiFi is not IP. It is therefore possible to use LoRa for networks without infrastructure.

Meshtastic was designed for communication outside of any public infrastructure, with a survivalist spirit of autonomous and (more or less) secure communication.

Due to its structure, it is difficult to estimate the size of such a community, but the map seems to indicate that more than 10,000 nodes are currently active. However, it seems that there are actually around 40,000 active nodes, with strong participation from the global ham radio community. In practice, the network is composed of clusters of nodes communicating locally with each other and expanding as clusters become visible to one another. In reality, without linking infrastructure, it won’t be possible to connect from one cluster to another but some MQTT relay features exists.

The use and development of the network require very few resources, as simple DIY nodes based on widely available devkits, such as the T-beam, are sufficient. The user interface works via a mobile application interacting through Bluetooth. The investment is just a few dozen euros. In a previous Meshtastic blog post, I detailed its implementation with small LoRa modules.

Continue reading

Meshtastic another way to use LoRa

You may be familiar with LoRa, not that girl, but the LOng RAnge communication solution that is used for long-distance, low-power point-to-point communications. It was invented by the Grenoble-based company Cycleo in 2009 and later sold to the semiconductor giant Semtech.

You might have heard more about it in its usage with an infrastructured network: LoRaWan, which allows public or private networks to connect thousands of sensors. In this blog post, I am going to talk about another implementation of LoRa, this time in a mesh architecture named Meshtastic. Multiple mesh, LoRa based solution are rising, this is one of them.

Continue reading

The Hidden Side of LoRa

While I was working on a blog post about Meshtastic (which will be online soon), I started questioning the time on air in a non-LoRaWAN context, where the online simulators I usually use did not work. This led me to investigate the LoRa frame format (not LoRaWAN, just LoRa, the underlying layer), and to confront the “sync word”, the functioning of a chirp… a whole range of concepts for which I expected to find abundant documentation. After all, in the LoRaWAN world, the open nature of the technology has been emphasized since its inception. However, after quite a bit of research, I still remain somewhat uncertain about the basic workings of LoRa, which at the very least calls for a blog post to compile the information I have found.

I invite those with a solid understanding of the subject to enrich this post with comments, and I will incorporate the key elements accordingly.

Continue reading

Proxmox cluster setup

I recently created a Proxmox cluster for some physical machine … for making it short, it sometime more efficient to run its own machine that going to cloud, in particular when you can manage a lower service level. So I use a mix of solutions, some on VM running on cloud provider solution like for critical production (Helium services as an example) and I have some bare-metal machine for high computation service (like Helium ETL) where cloud provider would invoice $3000 a month and for the rest I decided to run a Proxmox cluster to have an intermediate low cost infra with a minimum of redundancy I can master.

I started with 2 nodes with the ability to move workload from one to the other and as recently i got a corruption on one of my ZFS storage loosing one of the NVME, I’ve been happy of this setup. Unfortunately, when restarting the damaged node after being repaired, the second one restarted all the VMs causing an unexpected service failure. Let’s see how to setup a Proxmox cluster for not getting into this.

Continue reading

STM32WL and Flash memory usage in a LoRaWan / Sigfox use-case

The choice of an STM32WL microcontroller precludes the use of internal EEPROM, requiring the use of either an external EEPROM or the internal Flash memory for storing persistent data. The latter option is often favored in many designs (and modems) for cost reasons, though it comes with certain implications.

Using networks like LoRaWAN and Sigfox involves regular persistent writes. In the case of LoRaWAN, using OTAA (Over-The-Air Activation) mode, the devNonce must be recorded during each join procedure to ensure its uniqueness over network connections. Here, the number of persistent memory writes will theoretically be low (except for the battery end-of-life scenario discussed later). For an ABP (Activation By Personalization) connection, the situation differs significantly; the frame counter (FCnt) must be recorded so that it does not reset to zero in the event of a reboot. The same applies to Sigfox and its SeqId, which must increment with each communication. Without specific logic, LoRaWAN ABP and Sigfox will write to persistent memory with each data transmission.

While an EEPROM memory area has a lifespan of about 100,000 to 1,000,000 cycles (still potentially lower than the number of messages sent during the object’s lifecycle), a Flash memory area lasts only 10,000 writes, a number quickly reached in IoT communications. Therefore, using Flash as persistent storage requires a different approach compared to EEPROM in this context.

Continue reading

Install UniFi-controller on Raspberry-Pi

UniFi is a really good brand from Ubiquiti for network equipment (no sponsorship, just my feeling) in particular for home and small businesses. It comes with a controller to manage the whole network. This controller can be deployed on a small computer like raspberry Pi. It runs mongoDB, Java, so I recommend to use a PI4.

I was running a UniFi controller on my RPI4 since a while… But I had the wrong idea to apt-get upgrade the system and it crashed… Why ? Mostly because the controller distribution is a bit a mess with the MogoDB version and the 32b / 64b, but at the end you’re stuck.

So I’ll describe here how to install the controller in a proper way with docker.

Continue reading

Let’s Get Started with Helium & RAK11300 (RP2040 + SX1262)

In this blog post, we are going to see the steps to get started on Helium, with Chirpstack LNS using a RAK11300 module on a RAK wisblock board.

We are just going to setup a device with a LoRaWAN heartbeat to display it on Chirpstack.

Continue reading