Discovering the Pine64 LoRa gateway

Pine64 has been mentionning LoRa on their monthly community update (in February, for example) for a few months now and it is now becoming a reality : TL, founder of Pine64 sent an engineering sample of the future Pine64 LoRa gateway to a few people from the community (myself included), and I received mine in the beginning of April.

Since then, the whole “Lora” project has been named PineDIO (Pine + Radio), and Pine64 and RAK officially announced their collaboration for developping opensource LoRa hardware and software!

In this article, I’ll present you the hardware and some of my experiments with the gateway connecting to TTN (The Things Network) and Chirpstack.

The hardware

The Pine64 Lora Gateway is based on the Pine A64-LTS SBC. This is a relatively under-powered board by current standards (quad-core ARM Cortex A53 @1.1Ghz, 2GB RAM) but it should be more than powerful enough to run a LoRa/LoRaWAN gateway. The relatively low-power CPU has also the big advantage that it doesn’t heat a lot, which will be appreciated by people who want to run an outdoor gateway!

What’s under the hood of the Pine64 LoRaWAN gateway?

The LoRa contentrator is a RAKWireless module : the RAK2287. It’s a mini-PCIe based on the SX1301 digital baseband chip. The RAK2287 is fitted on an adaptator board to connect the mini-PCIe module onto the Pine A64-LTS board via the “PI-2 bus connector”.

The RAK2287 module has 2 antenna connectors : one for the LoRa radio (it was shipped with the gateway) and one for the GPS radio (not shipped, I use a amplified one to get a better signal from the inside oh my house).

The gateway was also shipped with the WiFi addon and its antenna. The whole hardware is installed into a nice white plastic box.

The Pine64 LoRaWAN gateway

My first steps with the gateway – Linux distributions

After the initial discovery of the hardware, all I wanted to do is start a Linux system and see how to access the LoRa hardware from there.

Unfortunately, it didn’t went as smoothly as I thought is would be : the support from the distributions for this board is not as wide as for other hardware from Pine64 like the PinePhone or the PinebookPro. This is a bit surprising as the PinePhone is based on the same CPU than the A64-LTS…

I focused mainly on Armbian because it looks like most of the software support from RAK (https://github.com/RAKWireless/rak_common_for_gateway) targets the RaspberryPi and Debian based distributions.

I had many frustrations with newer versions of Armbian (based on kernel 5.10 and 5.11) : filesystem issue on builds from late 2020, and network (wired and WiFi) issues on newer builds. There are workarounds documented on their forums but I couldn’t manage to get them working. Finally, I decided to stick with an older release based on kernel 5.9, and everything went smoothly. I hope someone will find the time and energy to fix these issues, as the Pine A64-LTS is supposed to be a widely used board (in SOPine boards and cluster, and now in the LoRa gateway). So, if you don’t want to spend time fixing network issues, I recommend you use Armbian 20.11.3 “buster” based on kernel 5.9.14.

Hardware ‘mapping’

Ok, now I have a running Linux, I need to figure out how the hardware is connected to the board so that I can enable the corresponding drivers. It took me some time to figure that out from the schematic, so here’s the result of my researches:

RAK2287 modulePI-2 connectorPINE A64-LTS
SX1302 SPIPin 19 = MOSI / PC0
Pin 21 = MISO/PC1
Pin23 = CLK/PC2
Pin24 = CS/PC3
SPI0 (/dev/spidev0.0)
SX1302 RESETPin 11 = GPIO17/PC7GPIO71 (/sys/class/gpio/gpio71)
GPS UARTPin 8 = TX
Pin 10 = RX
UART2 (/dev/ttyS2)
GPS RESETPin 33 = GPIO13/PC5GPIO69 (/sys/class/gpio/gpio69)
GPS StandbyPin 35 = GPIO19/PC9GPIO73 (/sys/class/gpio/gpio73)

Now, we can run armbian-config to enable the SPI0 and UART2 devices. You can even listen to UART2 to read the NMEA frames from the GPS receiver.

Gateway software

A LoRa gateway needs to be able to receive LoRa/LoRaWAN messages using its LoRa concentrator and to forward them to a LoRa application server. For that, you need software that will drive the hardware (LoRa radio, GPS,…) to receive the LoRa frames from the air and that will process and send them to the application server. Fortunately, RAK is very open source friendly and provides all this software online, on Github : https://github.com/RAKWireless/rak_common_for_gateway.

This repo contains code and scripts for multiple platforms and hardwares. The platform “RAK7248 no LTE (RAK2287 + raspberry pi)” is the one that is the most similar to the Pine64 hardware. And, as we (me and other users from the community chat, wiki and forum) found out, it’s quite easy to adapt to run on the Pine A64-LTS board. You just need to modify a few files to specify the correct SPI and UART devices.

User RTP (Right To Privacy), who also have a Pine64Lora Gateway, forked the repo from RAK and modified the necessary file, so that you can just run the installation script and that’s it! You have a LoRa gateway!

The Things Network and Chirpstack

The Things Network (TTN) is a public LoRaWAN network based on open-source techology. Everyone is free to use the network (by connecting to TTN gateways setup by other users) and/or to setup and connect their own gateway to the network to extend the coverage. I like the philosophy of this project : good technology, open-source friendly, very innovative, and no money involved unless you need “professional” support and integration.

Connecting to TTN was easier than I expected : the installation script from RAK pre-configures the packet forwarder to connect to TTN. All you have to do is add your gateway on the TTN Console.

As you can see on the picture below, I used my good old Pycom Lopy4 board as a LoRaWAN node to test the gateway.

The gateway connected to TTN on the left, the Lopy4 board as a LoRaWAN node on the right

Chirstack is an open source LoRaWan network server stack. You can use this project to self-host your own LoRaWAN stack and infrastructure (gateway -> application server -> integrations and application). And the good thing is that RAK provides a script that easily install the whole Chirpstack software on the gateway directly. You just need to run the gateway-config utility to switch to/from TTN/Chirpstack

The gateway connected to the local installation of Chirpstack on the left, the Lopy4 board as a LoRaWAN node on the right

Wrap up

That it for my first experiments with the Pine64 LoRa Gateway. I’ll probably experiment more, and build actual applications using this hardware in the future.

All in all, I would say that the Pine64 LoRa gateway is nearly ready to be used an actual gateway : all the software needed to start a LoRa gateway and connect it to major LoRaWAN network exists and works! We probably need a bit of polishing so that people who’ll buy the gateway can easily setup the software and run their gateway in a matter of minutes!

I would say I’m pretty excited by the collaboration between Pine64 and RAK, and I can’t wait to see what amazing hardwares, softwares, devices and applications will come up from this collaboration!

ULP (ESP32) : a simple example

The ULP is a low-power coprocessor (Ultra Low Power) integrated into the ESP32 MCU. It’s a very small processor that can run independently from the main cores and that has access to the GPIOs, some peripheral and an I²C controller.

The ULP is also able to run when the ESP32 is is deep-sleep mode. In this mode, nearly the whole MCU is powered-off, except the RTC domain, in which the ULP is built. It is also able to wake the ESP32 up.

A possible application of the ULP is to acquire temperature while the ESP32 is in deep-sleep and to wake it up once it reaches a specified threshold.

Programming the ULP seems very interesting, but even if the documentation from Espressif is very complete, I couldn’t find a simple and easy example to learn how to use it.

Here is then in details an ultra simple exemple : the traditional blink, which blinks 2 LEDs on the WROVER-KIT V3.

Continue reading “ULP (ESP32) : a simple example”

ESP32, ESP-IDF, CMake & CLion

I’ve been working with ESP8266 and ESP32 for some times now. Until now, I used the Arduino framework, mostly because it’s easy : it provides a lot of services and libraries, allowing me to go straight to the point and concentrate on my own code.

But I like to understand what lies underneath the top-layers, get closer to the metal, the transistors, the peripherals and the registers. For that, Espressif provides a well-documented SDK, and for which a lot of resources are available online.

This framework, name ESP-IDF (“Ce framework, nommé ESP-IDF (“Espressif IoT Development Framework”) provides toolchains and tools allowing the development of application for ESP32 MCU. In fact, the Arduino framework integrates this SDK to provide a higher-level API, and compatible with other platforms

When I installed the IDF, I was surprised (in a very good way) to find CMake files! CMake is an open-source tool to manager the build process of a project, especially for C++ projects. And CMake is natively supported by my favorite IDE : CLion.

So, shouldn’t it be possible to create, edit, build and run an ESP-IDF project in CLion ? That’s what we are going to see! (TL;DR : the answer is ‘YES’!).

Continue reading “ESP32, ESP-IDF, CMake & CLion”

Un bot pour Mastodon écrit en Micropython

Il existe déjà sur Mastodon, le réseau social libre et décentralisé dont j’ai déjà parlé à plusieurs reprises, toute une série de bots plus ou moins intéressants. Certains donnent l’évolution du nombre d’utilisateurs et d’instances sur le réseau, d’autres tootent automatiquement un résumé d’articles de blogs quand ils sont publiés, ou publient régulièrement des photos coquines. Bref, il y en a pour tous les goûts.

Moi, j’ai décidé d’écrire un bot… qui ne sert à rien! Non, l’intérêt de mon bot ne se situe pas dans sa fonctionnalité, mais plutôt dans sa conception : il va s’exécuter sur un processeur embarqué.

Dans le but de rendre le travail simple et rapide, j’ai choisis de le développer en Micropython. Et pour l’exécuter, mon choix s’est porté sur la carte Lopy de Pycom, basée sur un processeur ESP32, avec WiFi intégré. Continue reading “Un bot pour Mastodon écrit en Micropython”

Registration to the Mastodon instance is open!

As I had announced in a previous article, I decided to open the registration on my Mastodon instance!

This instance is open to anyone who wishes to register, especially those who want to talk about their software development projects, their discoveries with RaspberryPi, their original ideas to develop on an ESP8266, new technologies, the web, DIY, …

So go ahead, sign up, and come and send me a little toot: https://mastodon.codingfield.com/@JF

Backup d’une instance Mastodon (fonctionnant sous Docker)

Dans l’article précédent, je vous ai parlé de ma découverte de Mastodon et de mon enthousiasme à propos de ce nouveau réseau social.

J’ai donc rapidement mis en place une instance Mastodon. Cette instance me permet de participer à ma façon au réseau Mastodon. Mais surtout, elle me permet de rendre concret ma vision du réseau social idéal, où tout le monde est libre de choisir où il s’héberge: chez lui ou chez quelqu’un d’autre.

Personnellement, j’ai décider d’appliquer l’adage “On est jamais bien servit que par soi-même”. Il s’agit d’une solution qui apporte beaucoup d’avantages, dont le contrôle total sur les données. Mais ce contrôle a un prix : je suis responsable de mes données.

Que se passera-t-il le jours où un problème majeur se produit sur mon serveur? En cas de petite erreur de frappe lors d’une manipulation en console root? Et bien mes données disparaîtront, purement et simplement! Je perdrai mon compte, mes toots, mes followers, je n’existerai plus sur le réseau.

Cela serait bien dommage! Il faut donc mettre au point une stratégie de backup permettant de sauvegarder régulièrement les données du serveur, et de les restaurer en cas de soucis, sur le même serveur, et même sur un autre serveur chez un autre hébergeur.

Continue reading “Backup d’une instance Mastodon (fonctionnant sous Docker)”

A Mastodon instance for Codingfield

You have certainly heard about Mastodon, the new open-source and decentralized social network that appeared at the end of 2016 and which has been growing rapidly in recent weeks.

I am not going to write here a detailed article about Mastodon; many other sites and blogs have already described it broadly but I will rather explain briefly why I am enthusiastic about this social network, and I will also take this opportunity to introduce you to the insance I myself launched two weeks ago.

Continue reading “A Mastodon instance for Codingfield”

ESP8266, la petite star de l’IoT, de la domotique et du DIY

Depuis quelques temps, je remarque que les projets basés sur l’ESP8266 (et sur l’ESP32, maintenant) se multiplient.

Au départ, je n’y ai prêté que très peu d’attention, je pensais qu’il s’agissait d’une plateforme semblable à l’Arduino, avec un framework de très haut niveau qui mâche tout le travail. Enfin, c’étaient là des aprioris d’un développeur habitué à programmer son microcontrôleur registre par registre, et qui peut maîtriser au byte près l’utilisation de sa mémoire.

Mais à force de voir des ESP8266 par-ci, et des ESP32 par-là, j’ai fini par m’y intéresser… Et ce que j’ai découvert m’a fortement intéressé, au point de me procurer un petit kit et de commencer quelques petits développements.

Continue reading “ESP8266, la petite star de l’IoT, de la domotique et du DIY”

Une image Docker pour Web2py

J’ai récemment découvert Docker. Docker permet d’empaqueter une applications et tout son environnement dans un “conteneur” afin de pouvoir le déployer facilement sur une autre machine, serveur,…

Il est par exemple possible de créer une image Docker pour un serveur Web, une autre pour une serveur de base de données et une troisième pour une application spécifique. Ces images pourront servir à développer l’application. Une fois l’application prête à être déployée sur un serveur de test puis sur un serveur de production, il suffira de copier les conteneurs correspondant à ces applications sur le serveur de test et de production. Ainsi, lors de toutes les étapes de développement, le même environnement d’exécution est utilisé.

Il s’agit là d’un exemple assez complexe, mais moi, je commence simple : j’ai mis au point une petite image Docker permettant de créer un conteneur  exécutant Web2Py, le framework Python que j’utilise pour mes développements web. Continue reading “Une image Docker pour Web2py”

Neopixels sur SMT32F4 : pilotage avec un timer et DMA

Dans l’article précédent concernant les Neopixels, je vous ai montré ma solution “quick’n’dirty” pour piloter un anneau de 16 Neopixels. Cette implémentation utilise une boucle vide dont le nombre d’itérations permettra de générer des timings + ou – précis. Cette solution, qui a le mérite d’être simple et fonctionnelle, n’est pas du tout précise, optimisée et évolutive. En effet, même si la boucle de Delay() ne fait rien, elle occupe le processeur pour ne rien faire, justement. De plus, si la fréquence du processeur devait changer dans le future, tous les timings deviendraient invalides.

C’est pour cela que j’ai décidé de réimplémenter le contrôle de mes Neopixels en utilisant un timer du micro-contrôlleur. Ce timer va générer en hardware (sans intervention du programme, à part lors de l’initialisation) des timings très précis. De plus, l’utilisation du DMA va permettre de générer toute une trame de données vers les LEDs en consommant très peu de ressources du processeur. Continue reading “Neopixels sur SMT32F4 : pilotage avec un timer et DMA”