martes, 2 de junio de 2020

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

System schema

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-monitor
MoSimPa's monitor main screen

mosimpa-monitor plots
Plots of a patient's data


mosimpa-monitor-alarms-setup
Alarm thresholds setup


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

mosimpa-abm
ABM main screen


mosimpa-abm-internments
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.



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$.


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.

sábado, 7 de marzo de 2020

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**

jueves, 9 de enero de 2020

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.



viernes, 9 de agosto de 2019

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 ToolsOptions... 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.

sábado, 17 de noviembre de 2018

Using libgps instead of libQgpsmm within a Qt application

I was in need of creating a Qt application using current Debian stable (Stretch) and gpsd. I could have used libQgpsmm which creates a QTcpSocket for stablishing the connection to the gpsd daemon. But then I hit an issue: libQgpsmm was switched to Qt 5 after the Strech release, namely in gpsd 3.17-4. And I'm using Qt 5.

So the next thing to do is to use libgps itself, which is written in C. In this case one needs to call gps_open() to open a connection, gps_stream() to ask for the needed stream... and use gps_waiting() to poll the socket for data.

gps_waiting() checks for data for a maximum of time specified in it's parameters. That means I would need to create a QTimer and poll it to get the data. Poll it fast enough for the application to be responsive, but not too excessively to avoid useless CPU cycles.

I did not like this idea, so I started digging gpsd's code until I found that it exposes the socket it uses in it's base struct, struct gps_data_t's gps_fd. So the next step was to set up a QSocketNotifier around it, and use it's activated() signal.

So (very) basically:

// Class private:
struct gps_data_t mGpsData;
QSocketNotifier * mNotifier;

// In the implementation:
result = gps_open("localhost", DEFAULT_GPSD_PORT, &mGpsData);
// [...check result status...]

result = gps_stream(&mGPSData,WATCH_ENABLE|WATCH_JSON, NULL);
// [...check result status...]

//  Set up the QSocketNotifier instance.
mNotifier = new QSocketNotifier(mGpsData.gps_fd, QSocketNotifier::Read, this); 

connect(mNotifier, &QSocketNotifier::activated, this, &MyGps::readData);

And of course, calling gps_read(&mGpsData) in MyGps::readData(). With this every time there is activity on the socket readData() will be called, an no need to set up a timer anymore.

viernes, 2 de noviembre de 2018

Cross compiling CMake-based projects using Ubuntu/Debian's multi arch

As you probably already know Ubuntu (and then Debian) added Multi-Arch support quite some time ago. This means that you can install library packages from multiple architectures on the same machine.

Thanks to the work of many people, in which I would like to specially mention Helmut Grohne, we are now able to cross compile Debian packages using standard sbuild chroots. He even was kind enough to provide me with some numbers:

We have 28790 source packages in Debian unstable.
Of those, 13358 (46.3%) build architecture-dependent binary packages.
Of those, 7301 (54.6%) have satisfiable cross Build-Depends.
Of those, 3696 (50.6% of buildable, 27.6% of sources) were attempted.
Of those, 2695 (72.9% of built, 36.9% of buildable, 20.1% of sources) were successful.
633 bugs affecting 772 packages (7.23% of 10663 unsuccessful) are reported.

Now I asked myself if I could use this to cross compile the code I'm working on without the need of doing a full Debian package build.

My projects uses CMake, so we can cross compile by providing a suitable CMAKE_TOOLCHAIN_FILE.

And so the first question is:

How do we create the necessary file using what Multi-Arch brings to our table?


I asked Helmut and he did not only provide me with lots of tips, he also provided me with the following script, which I modified a little:

Now we can run the script providing it with the desired host arch and voilá, we have our toolchain file.

#!/bin/sh

#set -x

ARCH=$1

DEB_HOST_GNU_TYPE=$(dpkg-architecture -f "-a$1" -qDEB_HOST_GNU_TYPE)
DEB_HOST_GNU_CPU=$(dpkg-architecture -f "-a$1" -qDEB_HOST_GNU_CPU)
case "$(dpkg-architecture -f "-a$1" -qDEB_HOST_ARCH_OS)" in
        linux) system_name=Linux; ;;
        kfreebsd) system_name=kFreeBSD; ;;
        hurd) system_name=GNU; ;;
        *) exit 1; ;;
esac

cat <> cmake_toolchain_$1.cmake
# Use it while calling CMake:
#   mkdir build; cd build
#   cmake -DCMAKE_TOOLCHAIN_FILE="../cmake_toolchain_.cmake" ../
set(CMAKE_SYSTEM_NAME "$system_name")
set(CMAKE_SYSTEM_PROCESSOR "$DEB_HOST_GNU_CPU")
set(CMAKE_C_COMPILER "$DEB_HOST_GNU_TYPE-gcc")
set(CMAKE_CXX_COMPILER "$DEB_HOST_GNU_TYPE-g++")
set(PKG_CONFIG_EXECUTABLE "$DEB_HOST_GNU_TYPE-pkg-config")
set(PKGCONFIG_EXECUTABLE "$DEB_HOST_GNU_TYPE-pkg-config")
EOF


Can we improve this?

Helmut mentioned that meson provides debcrossgen, a script that automates this step. Meson is written in python, so it only needs to know the host architecture to create the necessary definitions.

CMake is not interpreted, but maybe it has a way to know the host arch in advance. If this is true maybe a helper could be added to help in the process. Ideas (or even better, patches/code!) welcomed.

miércoles, 23 de mayo de 2018

Running MPLAB X with a PickIt 3 on Debian sid

Due to $JOB I need to work with MPLAB X (I wish I could simply open Qt Creator...). MPLAB X's installation went straightforward, but I could not make the PickIt 3 to work.

So I ran MPLAB X from a console and got:

$ /opt/microchip/mplabx/v4.15/mplab_ide/bin/mplab_ide  
libusb couldn't open USB device /dev/bus/usb/006/013: Permission denied.


Yes, I rebooted my machine previous to running MPLABX (a udev restart would have been enough though) but something is not yet working.

Quick and dirty solution: chmod lisandro:lisandro /dev/bus/006/013

Yes, I'll have to re do this every time I plug the PickIt, but at least I've got it working.