Prevent commits directly to master
Pull requests with review & passing CI

What we need is either a wiki page or a markdown page under the /gui dir with the following
a) build instructions for contributors
b) instructions for running/testing in docker on top of whatever desktop environment a contributors may work on
c) deployment instructions for anyone with actual rpi hardware

You could start by trying some of the script commends found in the Circle CI script here

These are specific sounds triggered by alarms. But first we need to implement basic API #371

Unit testing for GUI is defficient.

• a lot of the existing unit tests are stubs
• some classes totally lack unit tests
• coverage is low

Should be easy enough to pick up by looking at test coverage reports and flling out more of the place-holders under software/gui/tests

#SR-19 Power supply failure shall trigger alarm

Electricity supply failure

• Condition: ventilator unplugged from wall mains
  • Audible alarm and UI text “ELECTRIC SUPPLY FAIL”

Requirement

The UI must display what ventilation is currently being used, including a clear method of showing that the unit is off

Enhancement

• MV (Minute ventilation) High/Low (Optional):
  • Adjustable range: 2 L- 15 L, increments of 1 L
  • Default low setting: 4 L; Default high setting: 8 L
  • "MV HIGH” Condition: MV greater than high MV alarm setting
  • “MV LOW” Condition: MV less than low MV alarm setting

design meaningful multiple-day long run testing

Here are some potential leads on how to do this:
https://docs.travis-ci.com/user/multi-cpu-architectures
http://blog.kragniz.eu/raspbian-on-travis-ci/

Copied thread from inceptionev/FixMoreLungs

@rwilbur We will need the watchdog timer so that we can make sure to reboot if something gets frozen

@lee-matthews In progress!, I've added the framework for this to the new ventilatorController branch

What does "loop leak" mean? Mask disconnected? How is this detected?

On what conditions?

#SR-19: Inlet Gas/Power Supply Failure
#SR-24: Alarm shall trigger when O2 disconnection occurs

• Condition: no supply pressure detected
• Audible alarm and UI text “GAS SUPPLY FAILURE”

Requirement

If multiple alarms simultaneously present and display has one line of text for alarms, display line will toggle through all alarms

• Patient Disconnect
  • Condition: pressure does not rise above 3 cmH2O during inspiration
  • Audible alarm and UI text “LOW AIRWAY PRESSURE”
• High inspiratory airway pressure
  • Condition: airway pressure above alarm setting during inspiration
  • Adjustable range: 15- 60 cmH2O, increments of 5 cmH2O
  • Default setting: 35 cmH2O
  • Audible alarm and UI text “OVER-PRESSURE ALARM”
  • Controller feedback:
    • Inspiratory solenoid valve closes to stop inspiratory flow
    • Exhalation valve opens (if controlled by solenoid)
• TV High/Low
  • Adjustable range: 200-1000 ml, increments of 50 ml
  • Default low alarm setting: 200 ml; Default high alarm setting: 1000 ml
  • Audible alarm and UI text: “TV HIGH”
  • Condition:
    • measured TV exceeds high TV alarm setting
    • “SET TV NOT DELIVERED” Condition: measured TV less than low TV alarm setting
    • “LOW VT, IT SHORTENED” Condition: Inspiration Time (IT) is shortened by reaching high inspiratory airway pressure limit and measured TV less than low TV alarm setting

Requirement

Must be continuously displaying user settings of the Pressure Command mode:

• PIP
• PEEP
• Respiratory Rate
• Inspiratory:Expiratory ratio

Should build on other toolchains or platforms, i.e.: clang, ubuntu, windows, android?
Some of these are easily accessible on Travis at little additional cost. Different compilers might reveal different elusive errors.

Requirement

We must have the ability to display and adjust the Respiratory Rate, Inspiratory:Expiratory ratio, Volume/Pressure (dependent on mode), and alarm limits

Touch screen?
Keyboard?
Buttons to increment?
Slider?
etc.?

What has to be done
The controller talks the following communication protocol, using nanopb.
Essentially: GUI sends GuiStatus containing desired mode parameters, Controller sends ControllerStatus containing sensor readings and other controller-side info.

As of writing, the GUI is stubbed out and not connected to the controller in any way.

Success criterion for this issue is that:

• We have a C++ abstraction somewhere in GUI code encapsulating talking over the protocol, for example: ControllerStatus exchangeStatus(GuiStatus status) (symmetric with the respective controller-side code) - this is a reasonable independent sub-task of this bug. @Miceuz was planning to do this.
• The GUI has a periodic thread that frequently calls that function, giving it parameters somehow obtained from UI element state and storing the resulting ControllerStatus'es in a form from which the UI can be rendered. @jkff is planning to do this.

How do you know it has to be done
That the GUI needs to talk to the controller is self-evident.
The communication protocol is settled, code linked above.
As for whether the exchange should happen periodically or via some other mechanism - I don't know, periodically seems reasonable.

A point of ambiguity is, exactly how is the GUI connected to the controller - I (@jkff) was assuming it will be over serial port but it should be clarified, as I know nothing about serial ports.

Code pointers
I (@jkff) think the whole thing should look roughly like this:

interface ConnectedDevice {
	ControllerState exchangeState(GuiState state)  // nanopb protos
}
main() {
	ConnectedDevice device = ConnectedDeviceOverSerialPort(...serial port parameters...);  // but initially a fake
	History<ControllerState> state_history(30 seconds);  // just a vector that pushes out too old stuff
	GuiState desired_state;
	on timer separate from QT {
		history.Add(device.ExchangeState(desired_state))
	}
	...bind desired_state to parameters set in the UI...
	...bind state_history to graphs and alarms displayed in the UI...
}

The current bug is about doing the ConnectedDevice stuff.

Copied thread from inceptionev/FixMoreLungs

@rwilbur: We need to figure out if this is going to use UART or SPI

@lee-matthews: Indeed. Was planning on making possible to set those too. Maybe create some kind of "engineering/debug" mode on the interface module so that we can play with these values directly that's protected from a typical user.

@rwilbur Looking at the clock rate and from what people have said online it appears to be capable of 2Mbps. I agree the differential UART link would be nice to have because of the robustness to noise. I have used RS232 in quite noisy environments and have never had noise issues with it so in practice it might be perfectly acceptable. I think the fewer the parts the better.

@lee-matthews I presume the Arduino only has a UART output (0 to 3.3V) instead of +-12V? To add RS232, we may need to add an extra module anyway, a MAX232 perhaps? Maybe these come in premade modules for rpi / arduino.

@rwilbur I meant 3.3v when I said 232 but that is incorrect. I think the 3.3v UART would probably be fine. The UART on the PI is also 3.3v so they should play nicely together. If these 2 devices are super close together we can probably do a good job keeping noise down by just having a super connection.

Requirement

The UI must be able to display the pressure and calculated or measured flow rate in a graph format that updates in (near) real time

valgrind
cppcheck
clang-tidy
google sanitizers
etc.?

Should log some amount of historical sensor data to file, arguably for some period the patient would be left unsupervised that the attending doctors could review?
There should be a way to display and review it?

Tidal volume by body mass (height)

Requirement

Must have 3 readouts displaying Tidal Volume, Positive End-Expiratory Pressure, and airway pressure in numerical format

Copied thread from inceptionev/FixMoreLungs:

@rwilbur We will need to change the PID #defines to variables so they can be changed via the communications to the raspberry pi

@lee-matthews Indeed. Was planning on making possible to set those too. Maybe create some kind of "engineering/debug" mode on the interface module so that we can play with these values directly that's protected from a typical user.

@rwilbur That makes sense. I am pretty sure that all these will need to be set in the UI but open to a user since nurses and doctors will need to be changing all of these based on the patient and their progress.

#define INSPIRE_TIME 1600
#define INSPIRE_RATE 1
#define PIP 142
#define INSPIRE_DWELL 800
#define INSPIRE_DWELL_PRESSURE 140
#define EXPIRE_TIME 1000
#define EXPIRE_RATE 1
#define PEEP 130
#define EXPIRE_DWELL 600

Perhaps with these we won't have these values being set directly but have it be a certain unit on the display and it gets converted to whatever these units are in the command.

@lee-matthews I was thinking of an engineering mode for the parameters for the PID for example, I don't think the medical personnel should have access to these. Same for any potential calibration parameters.

Copied thread from inceptionev/FixMoreLungs

@rwilbur We will need the variables to be stored in EEPROM so that in case of a reboot we still have the correct values for the variables

@lee-matthews Indeed, this functionality shall be provided by the eeprom module in the software.

Read the pressure sensor voltage
Apply calibration data to scale this to SI units

I'm stuck on RespiraWorks/OpenSourceVentilatorGUI#13 because I need to modify the Raspbian image to make it more easy to automate VM-based testing the Qt-based GUI app.

In particular, sshd isn't enabled by default (which is peculiar, I know.) For now, all I need to do is run sudo systemctl enable ssh.service and reboot. I'm not a QEMU expert by any means, but it appears the disk image changes are persisted, so that's nice. I just need a place to save the modified image so that it's accessible to our Travis-CI instance and any developers.

We have the following algorithms present in our code:
Volume calc is #636
Inspiratory detection related work is in #669 #388 #373 #374 #828
RR detection is #827
PIP #829
PEEP #830
I/E #831

This task is to document them in a centralised place in repo that will be the source of truth for what those algs are. With precise definitions of those algorithms in narrative form.

Compliance trends?
Apnea events?
Cough frequency?
Should find some good ones in the medtronic specs