I assume when you refer to 'serial link' you mean that you are using Rpi UART interface to communicate with the STM32.

I can see the convenience of using UART but as a very cautionary advice, hospital environments are electrically quite harsh in terms of EM noise. A serial line even a short one can absolutely suffer from interference.

You already made it relatively fail-safe with the heartbeat/watchdog but please consider upgrading your design to use comms with a differential signal, anything like CAN or even RS-485 in that Rpi/STM32 link would be a significant improvement.

I'll be very happy for my industrial projects if BCM2711 come with CAN or RS485 built-in, but for the moment, there is nothing planned by Raspberry...

A low speed 115200 baud link does the job, with applicative CRC on both side to be sure there is no corruption.

My method to test communication robustness: I inject pulses through a capacitor directly on the UART lines. I did it on this project, no problem. The four bytes CRC32 prevents random EM noise errors.

STM32 telemetry code is here:

https://github.com/makers-for-life/makair-firmware/blob/mast...

Pierre, author of the article.

I think the problem OP is referring to is that if you were proposing this design for a approved medical device for use in say US & EU, you might have trouble passing e.g. 60601 because of the communication channel. I haven't looked over the design in detail but EMI etc. can be quite tricky to manage in this sort of device.

You're right. We will see. EMC tests are part of our program.

Are you working with a test house? They can really help pin down issues quickly.

Sounds like a fun project!

Yes we are :) The first days were fun. Then the french government pushed the project. Challenging, crazy, but exhausting. 25 days without coming back home! Then the lockdown did the job, and the project was not so urgent, so the ANSM (french equivalent of US FDA) was not so in a hurry. And now it seems to take ages for us between two administrative steps, but it is still fast for ANSM. Development of a ventilator take normally a few years!

Good stuff! Device projects typically take a while. Industry average for a device like this is something like 3-5 years start to finish, so you are right it's pretty quick (although other ventilator efforts have been similarly fast - it's almost like there was extraordinary motivation).

I've seen 18 months before, but that was primarily software. I think the FDA clock on evaluation is 120 days now, that's after all the i's are dotted and t's crossed. EU MDD/MDR is similar, iirc.

Congrats on getting something together quickly!

If your embedded stack supports USB you could use CDC ACM for possibly more robust comms (checksummed by USB, no need for RTS/CTS).

Also there are CAN hats for rPi (SPI) or USB<->CAN bridges (using slcan protocol and Linux driver).

This is good systems design. I've made a system with a similar design (RPI for display and UI, one STM32 for hardware control, another as watchdog) for an industrial marking system, and it's run almost daily for 3 years without any issues.

The great thing about the Pi in this case is that it's non-critical, and if it ever does die, you spend $35 and put in a new SD card.

As soon as ANSM (french equivalent of US FDA) hears "linux", "wifi", "connected", they see a scary green monster...

And to be honnest, I understand their point. How can you certify Linux ? So much code behind... It is not a car multimedia center, it is a ventilator, a class III vital device.

In this project, what was really impressive is the gap between the bare minimum (a 4 lines lcd screen + a few buttons + a pressure sensor, and you can make people breath), and the doctors expectations (curves, flow meters, statistics, O2 sensors...).

This is the same for lots of activity: experts cannot work with basic tools anymore. Only High level experts still can.

Conclusion: do not work with high level experts to build your specifications. Also listen to normal experts and doctors that needs more UX assistance.

Thank you for this valuable insight.

Do you think relying on something like a hospital-provided tablet would have worked? Was this considered?

I mean, having that many screens may be a bit redundant, if you can have a single high-quality one. That said, I understand it introduces some complexity due to wireless protocols, paring with the right ventilator, etc.

You're welcome.

In our initial requirement list, it was designed to be used in temporary hospitals (any public hall for example).

Screen convergence is not for now in hospitals. Behind one sensor, there is one company that sells its monitor with the sensor. Some old well known sensors now converge to one monitor (philips, edwards life science...), but there is a still one screen for every other functions.

Gathering data (when the constructor made it available) is a mess... look at HL7 specs! To build a medical datalogger, you sometimes must interface to an analog output (it is part of my job).

By the way, most monitors runs windows CE behind. Which is also a problem now: https://www.integrasources.com/blog/windows-ce-end-of-life-m...

Why use the Rpi at all (Nothing against them, I have a few)? If the Pi is just writing graphics to a screen, why not handle that directly with the STM32? Running an RTOS, it should be able to manage a low priority GUI task along with the real-time ventilator tasks.