Moved!

 This blog has been moved to https://perezmeyer.com.ar/

On configuring RAK LoRa devices, or how to avoid their Windows-only serial application

tl;dr: use a serial terminal which can buffer input and send it all at once, lines should end with \CR\LF.

I'm am currently working on bringing up a LoRa network in Bahía Blanca. Parts of the nodes I need to set up are made by RAK Wireless.

According to their documentation the nodes can be configured by using a serial connection to them. So I quickly turned to minicom for it, with no avail. Somehow I could read whatever the device was writing to my machine but could not write any commands back to it.

In order to get the issue solved I switched to running their RAK serial port tool under wine. Making it work made me download and install a huge amount of Windows libraries and tools, but in the end I wanted a Linux-only solution.

After much  digging the web, trial and error I've found a way to solve this:

1. Commands should end with \CR\LF.
2. The command needs to be sent quickly, all in one go, trough the serial port. This means it can't be typed and sent as normal serial consoles.

The solution for (1) in minicom is easy, but I don't know if minicom is capable of doing the buffering thing, so I went to use cutecom, for which one has to enter the input and send it all at once.

Stepping down as Qt 6 maintainers

After quite some time maintaining Qt in Debian both Dmitry Shachnev and I decided to not maintain Qt 6 when it's published (expected in December 2020, see https://wiki.qt.io/Qt_6.0_Release). We will do our best to keep the Qt 5 codebase up and running.

We **love** Qt, but it's a huge codebase and requires time and build power, both things that we are currently lacking, so we decided it's time for us to step down and pass the torch. And a new major version seems the right point to do that.

We will be happy to review and/or sponsor other people's work or even occasionally do uploads, but we can't promise to do it regularly.

Some things we think potential Qt 6 maintainers should be familiar with are, of course, C++ packaging (specially symbols files) and CMake, as Qt 6 will be built with it.

We also encourage prospective maintainers to remove the source's -everywhere-src suffixes and just keep the base names as source package names: qtbase6, qtdeclarative6, etc.

It has been an interesting ride all these years, we really hope you enjoyed using Qt.

Thanks for everything,

Dmitry and Lisandro.

Note 20200818 12:12 ARST: I was asked if the move has anything to do with code quality or licensing. The answer is a huge no, Qt is a **great** project which we love. As stated before it's mostly about lack of free time to properly maintain it.

 

Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa) - Fighting COVID-19

I have been quite absent from Debian stuff lately, but this increased since COVID-19 hits us. In this blog post I'll try to sketch what I have been doing to help fight COVID-19 this last few months.

In the beginning

When the pandemic reached Argentina the government started a quarantine. We engineers (like engineers around the world) started to think on how to put our abilities in order to help with the situation. Some worked toward providing more protection elements to medical staff, some towards increasing the number of ventilation machines at disposal. Another group of people started thinking on another ways of helping. In Bahía Blanca arised the idea of monitoring some variables remotely and in masse.

Simplified Monitoring of Patients in Situations of Mass Hospitalization (MoSimPa)

This is where the idea of remotely monitored devices came in, and MoSimPa (from the spanish of "monitoreo simplificado de pacientes en situación de internación masiva") started to get form. The idea is simple: oximetry (SpO2), heart rate and body temperature will be recorded and, instead of being shown in a display in the device itself, they will be transmitted and monitored in one or more places. In this way medical staff doesn't has to reach a patient constantly and monitoring could be done by medical staff for more patients at the same time. In place monitoring can also happen using a cellphone or tablet.

The devices do not have a screen of their own and almost no buttons, making them more cheap to build and thus more in line with the current economic reality of Argentina.

This is where the project Para Ayudar was created. The project aims to produce the aforementioned non-invasive device to be used in health institutions, hospitals, intra hospital transports and homes.

It is worth to note that the system is designed as a complementary measure for continuous monitoring of a pacient. Care should be taken to check that symptomps and overall patient status don't mean an inmediate life threat. In other words, it is NOT designed for ICUs.

All the above done with Free/Libre/Open Source software and hardware designs. Any manufacturing company can then use them for mass production.

The importance of early pneumonia detection

We were already working in MoSimPa when an NYTimes article caught or attention: "The Infection That’s Silently Killing Coronavirus Patients". From the article:

A vast majority of Covid pneumonia patients I met had remarkably low oxygen saturations at triage — seemingly incompatible with life — but they were using their cellphones as we put them on monitors. Although breathing fast, they had relatively minimal apparent distress, despite dangerously low oxygen levels and terrible pneumonia on chest X-rays.

This greatly reinforced the idea we were on the right track.

The project from a technical standpoint

As the project is primarily designed for and by Argentinians the current system design and software documentation is written in spanish, but the source code (or at least most of it) is written in english. Should anyone need it in english please do not hesitate in asking me.

General system description

The system is comprised of the devices, a main machine acting as a server (in our case for small setups a Raspberry Pi) and the possibility of accessing data trough cell phones, tablets or other PCs in the network.

The hardware

As of today this is the only part in which I still can't provide schematics, but I'll update this blog post and technical doc with them as soon as I get my hands into them.

Again the design is due to be built in Argentina where getting our hands on hardware is not easy. Moreover it needs to be as cheap as possible, specially now that the Argentinian currency, the peso, is every day more depreciated. So we decided on using an ESP32 as the main microprocessor and a set of Maxim sensors devices. Again, more info when I have them at hand.

The software

Here we have many more components to describe. Firstly the ESP32 code is done with the Arduino SDK. This part of the stack will receive many updates soon, as soon as the first hardware prototypes are out.

For the rest of the stack I decided to go ahead with whatever is available in Debian stable. Why? Well, Raspbian provides a Debian stable-based image and I'm a Debian Developer, so things should go just natural for me in that front. Of course each component has its own packaging. I'm one of Debian's Qt maintainers then using Qt will also be quite natural for me. Plots? Qwt, of course. And with that I have most of my necessities fulfilled. I choose PostgreSql as database server and Mosquitto as MQTT broker.

Between the database and MQTT is mosimpa-datakeeper. The piece of software from which medical staff monitor patients is unsurprisingly called mosimpa-monitor.

MoSimPa's monitor main screen

Plots of a patient's data

Alarm thresholds setup

And for managing patients, devices, locations and internments (CRUD anyone?) there is currently a Qt-based application called mosimpa-abm.

ABM main screen

ABM internments view

The idea is to replace it with a web service so it doesn't needs to be confined to the RPi or require installations in other machines. I considered using webassembly but I would have to also build PostgreSql in order to compile Qt's plugin.

Translations? Of course! As I have already mentioned the code is written in English. Qt allows to easily translate applications, so I keep a Spanish one as the code changes (and we are primarily targeting spanish-speaking people). But of course this also means it can be easily translated to whichever language is necessary.

Even if I am a packager I still have some stuff to fix from the packaging itself, like letting datakeeper run with its own user. I just haven't got to it yet.

A video showing the software in action

Certifications

We are working towards getting the system certified by ANMAT, which is the Argentinian equivalent for EEUU's FDA.

Funding

While all the people involved are working ad-honorem funding is still required in order to buy materials, create the prototypes, etc. The project created payments links with Mercado Pago (in spanish and argentinian pesos) and other bank methods (PDF, also in spanish).

I repeat the links here with an aproximation to US$.

- 500 AR$ (less than 8 US$)

- 1000 AR$ (less than 15 US$)

- 2000 AR$ (less than 30 US$)

- 3000 AR$ (less than 45 US$)

- 5000 AR$ (less than 75 US$)

You can check the actual convertion rate in https://www.google.com/search?q=argentine+peso+to+us+dollars

The project was also presented at a funding call of argentinian Agencia de Promoción de la Investigación, el Desarrollo Tecnológico y la Innovación (Agencia I+D+i). 900+ projects where presented and 64 funded, MoSimPa between them.

Qt 4 removed from Debian Sid (unstable)

The day has finally arrived: Qt 4 is no longer part of Debian unstable. It's gone.

Thanks should go to many people. You know who you are, and I really appreciate the support and time you put into this. **Thanks**

Qt 4 removed from Debian bullseye (current testing)

Today Qt 4 (aka src:qt4-x11) has been removed from Debian bullseye, what as of today we know as "testing". We plan to remove it from unstable pretty soon.

Developing Nordics' nRF9160 DK using Qt Creator

So I've got my hands into a nRF9160DK (development kit). Like I did with the nRF51822 I would love to develop software for this board using as much FLOSS tools as possible to avoid any kind of vendor lock-in.

This board actually has two interesting ICs: the nRF9160 which anyone would expect and a nRF52840. At first I'm targeting the first one.

The nRF9160's firmware is based on Zephyr which uses CMake. This is great as my preferred IDE is Qt Creator which has quite nice CMake integration.

Preparing the toolchain and proprietary code

There is of course some Nordic proprietary code to put in the mix. So the first step is to setup Nordic's SDK. For that one needs to follow the "Get started with development" section in their web page. One needs to download an nRFConnect AppImage binary and start it. How safe it is to run proprietary code in our machines? Now that's an interesting question.

Once there, and still following Nordic's documentation, we need to install the "Getting started Assistant" and run it. We will follow all steps in it except the last ones for installing a proprietary IDE. We want to code using Qt Creator after all.

Building the asset tracker example from the command line

So let's start by trying to build the example (the only one so far?) from the command line. After some trial and error I've got the following:

mkdir build
cd build
GNUARMEMB_TOOLCHAIN_PATH="/opt/gcc-arm-none-eabi-7-2018-q2-update" \

ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb ZEPHYR_BASE="$NCS_BASE/zephyr" \

cmake -DBOARD_ROOT="$NCS_BASE/zephyr/boards/arm/nrf9160_pca10090" \

-DBOARD="nrf9160_pca10090ns" ../

Where NCS_BASE is the path to the previously downloaded SDK. In this case I selected the non secure version build for this board.

The next step is then easy.

Building the asset tracker example from within Qt Creator

Once we've got to compile the example from the command line switching to Qt Creator is easy. First of all we want to set up a Kit as I did for the nRF51822. Follow the instructions there but this time set up the new GCC version required by this development kit.

The next step is to provide as much definitions as possible as part of the kit itself. Got to Tools → Options... and then to Kits. Select the newly created kit (I called it nRF9160) and then change "CMake Configuration" settings. The resulting text should look like:

BOARD:STRING=nrf9160_pca10090ns

BOARD_ROOT:STRING=path/to/ncs/zephyr/boards/arm/nrf9160_pca10090

CMAKE_CXX_COMPILER:STRING=%{Compiler:Executable:Cxx}

CMAKE_C_COMPILER:STRING=%{Compiler:Executable:C}

CMAKE_PREFIX_PATH:STRING=%{Qt:QT_INSTALL_PREFIX}

GNUARMEMB_TOOLCHAIN_PATH:STRING=/opt/gcc-arm-none-eabi-7-2018-q2-update

ZEPHYR_TOOLCHAIN_VARIANT:STRING=gnuarmemb

Some of those definitions are not really necessary in there. ZEPHYR_BASE needs to be set as an environment variable. This is the only akward part of this setup, as the only way I could find to do so from within Qt Creator is to set it up in a per-project fashion.

Once the above is done open $NCS_BASE/nrf/applications/asset_tracker/CMakeLists.txt. The configuration will fail, as we haven't suplied ZEPHYR_BASE yet. To do so go to "Projects" on the right, Select "Build" within the kit and set up ZEPHYR_BASE within the "Build Environment" section at the bottom.

That's is, you are now ready to use "Run CMake" from within the "Build" menu and you are ready to go.