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 ( 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)
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 :

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 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) : un exemple simple

L’ULP est un coprocesseur à très faible consommation (Ultra Low Power) intrégré au MCU ESP32. Il s’agit donc d’un tout petit processeur qui fonctionne quasiment indépendemment des coeurs principaux et qui peuvent accéder aux GPIO, à certains périphériques et qui dispose aussi d’un contrôlleur I²C.

L’ULP est aussi capable de fonctionner alors que l’ESP32 est en mode deep-sleep. Dans ce mode, quasiment tous le MCU n’est plus alimenté, excepté le domaine RTC, dans lequel se trouve l’ULP. L’ULP est aussi capable de réveiller l’ESP32 (wake-up).

On pourrait envisager d’utiliser l’ULP pour effectuer une mesure de température et réveiller l’application si on dépasse un certain seuil, par exemple.

Programmer cet ULP semble donc très intéressant, mais malgré la documentation toujours très complète de Espressif, j’ai eu du mal à trouver un exemple simple et complet expliquant la programmation de ce coprocesseur.

Voici donc en détail un exemple ultra-simple : le traditionel « blink« , qui consiste à faire clignoter deux LEDs du kit WROVER-KIT V3!

Continuer la lecture de « ULP (ESP32) : un exemple simple »

ESP32, ESP-IDF, CMake & CLion

Cela fait un moment que je travaille avec les processeurs ESP8266 et ESP32. Jusque maintenant, j’utilisais par le framework Arduino, surtout par facilité : il fournit pas mal de services et de librairies me permettant d’aller droit au but et d’écrire rapidement mon propre code.

Mais j’aime bien aller au fond des choses, me rapprocher du métal, des transistors, des périphériques et des registres. Pour cela, Espressif fournit un SDK qui semble bien documenté, et pour lequel on trouve énormément de ressources en lignes.

Ce framework, nommé ESP-IDF (« Espressif IoT Development Framework ») fournit des toolchains, API et outils permettant le développement d’applications pour les processeurs ESP32. Le framework Arduino intègre, emballe, ce SDK pour fournir un API d’un peu plus haut niveau, et surtout compatible pour d’autres plateformes.

Losque j’ai installé l’IDF, quelle ne fut pas ma (bonne) surprise de trouver des fichiers CMake ?! CMake est un outil opensource permettant de gérer le processus de build d’un projet, notamment des projets C++. Et CMake est supporté nativement par mon IDE préféré : CLion.

Du coup, il devrait être possible de créer, éditer, compiler et exécuter un projet utilisant l’ESP-IDF dans CLion, non? C’est ce que nous allons voir (TL;DR : la réponse est ‘oui’!).

Continuer la lecture de « 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é. Continuer la lecture de « Un bot pour Mastodon écrit en Micropython »

L’instance Mastodon est ouverte!

Comme je l’avais annoncé dans un article précédent, j’ai décidé d’ouvrir les inscription sur mon instance Mastodon !

Cette instance est ouverte à tout ceux qui souhaite s’y inscrire, et plus particulièrement à ceux qui souhaite parler de leurs projets de développements logiciel, de leurs découvertes avec les RaspberryPi, de leurs idées originales à développer sur un ESP8266, de nouvelles technologies, du web, du DIY,…

Allez-y donc, inscrivez-vous, et venez me faire un petit coucou :

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.

Continuer la lecture de « Backup d’une instance Mastodon (fonctionnant sous Docker) »

Une instance Mastodon pour Codingfield

Vous avez certainement entendu parler ces derniers jours de Mastodon, ce nouveau réseau social open-source et décentralisé apparu fin 2016 et dont la croissance est fulgurante depuis quelques semaines maintenant.

Je ne vais pas écrire ici un article présentant Mastodon en détails, beaucoup d’autres sites et blogs l’ont déjà décrit en long et en large, mais je vais plutôt expliquer brièvement pourquoi je suis enthousiaste vis-à-vis de ce réseau, et je vais aussi en profiter pour vous présenter l’instance que j’ai moi-même lancée il y a maintenant 2 semaines.

Continuer la lecture de « Une instance Mastodon pour 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.

Continuer la lecture de « 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. Continuer la lecture de « 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. Continuer la lecture de « Neopixels sur SMT32F4 : pilotage avec un timer et DMA »