missing menu items in some modes

[bdarcus]

Some of the modes are missing important, even critical, settings.

In particular, ST, T, PAC are missing the ability to set a "Resp. Rate" or "Backup Rate".

Without those, one can't really use those modes, which are likely the most useful ones for COVID-19 patients.

Also, "Learn Targets" and "Height" are missing from the iVAPS menus.

[gszakacs]

What firmware do you have ? Have you tried compiling/re-flashing with the "all_menu" function enabled ? On AS10v306, settings such as Ti max, Ti min, rise time, resp rate, backup rate, etc. are not editable (some of them not even visible). I agree that editing those variables may be critical for covid19 related ventiltation. In case folks are wondering what are the variables and adjustment range for the possible covid19 related ventilation support modes, you may find the following useful.

[bdarcus]

What firmware do you have ?

-0401.

Have you tried compiling/re-flashing with the "all_menu" function enabled ?

No, in part because I wasn't clear what the purpose of that was. It won't help if items are grayed out.

I agree that editing those variables may be critical for covid19 related ventiltation.

The RR and BR settings are fundamental to those modes; and yeah, likely critical for covid patients.

[nbritton]

I can confirm bdarcus original post, these items are not present on my AS10v306. I'm not using the all_menu feature.

[bdarcus]

It's now confirmed across different machines and fw, including the default autoset and -0401.

I assume this is straightforward to fix, but I don't understand how myself.

[bdarcus]

Someone did try the all_menu option, and while it does disclose the additional necessary menu items noted here, it's not very practical, since it adds all menus, even when not relevant. We don't want that.

So somehow you need to get these specific menu items added to the standard unlocking.

[nbritton]

On my AirCurve S with firmware 0306 all of the setting parameters are visible in iVAPS mode (without enabling the force all menus modification), with the exception of Height.

I have a xxd hex diff of my AirSense 10 AutoSet and AirCurve S, both have firmware version 0306. 626 memory addresses have different values between the two firmwares. I'm analyzing the differences.

diff -u <(xxd stm32.bin.AirSense_10_AutoSet_0306) <(xxd stm32.bin.AirCurve_S_0306)

[nbritton]

I have good news and bad news. The good news is that the decompiled C source code that Ghidra generated are identical, this basically means that the "runtime engine" is entirely intact. Additional good new is that the hardware is also identical as near as I can tell, both my AirSense 10 AutoSet and AirCurve 10 S both have exactly the same mainboard part numbers.

The bad news, the AirCurve 10 S firmware has data structures / header definitions that are not present in the AirSense 10 AutoSet firmware. This is entirely why the missing items in your original post are missing, so if a menu item is missing that means the data structure isn't defined within the firmware. The firmware would have to be patched to add these data structures.

I did flash my AirSense with my AirCurve's firmware, this worked perfectly and all the data structure definitions that the AirCurve had are present and operational. So let me be clear, this issue is entirely an artificial software limitation. If someone had an AirCurve 10 ST-A firmware this device would have all the data structure definitions and flashing its firmware onto virtually any other device, such as an AirSense 10 AutoSet, would enable a device that has 100% functional iVAPS and PAC modes. So if you have access to an AirCurve 10 ST-A, you can clone its firmware onto a base model AirSense or AirCurse device. In an assembly line situation, a machine can be disassembled and re-flashed with ST-A iVAPS / PAC ventilator modes in less than 10 minutes per machine per person.

The serial number and other vital product information are not stored within the firmware, that information is stored in an EEPROM; there is no uniquely identifiable information contained in the stock stm32.bin firmware file that OpenOCD dumps.

[bdarcus]

Hmm ... so in those modes, one is stuck with the fixed default rates.

I imagine that might work for some patients, in some circumstances. But definitely not ideal.

[nbritton]

I'm not sure, but I think it might be more than that. The mode algorithm that the runtime engine is using could simply ignore the parameters that aren't defined. If that's true it would be harder to trust that the algorithm will do the right thing because we don't know how the algorithm uses the sensor and statistical data for making decisions about the flow generation. For instance, my AirSense didn't know how to derived and track Ti, Ti Min, Ti Max, and I:E statistics until I flashed it with the firmware from my AirCurve 10 S. In the diff comparison of the AirSense and AirCurve firmwares, the only noticeable difference was the AirCurve had these Ti and I:E data structures defined... these structures were absent in the AirSense firmware.

GIF of iVAPS operation on AirSense with AirCurve S firmware

GIF of iVAPS operation on AirSense with AirSense firmware (all menus visible mod enabled)

Update: I noticed in the second GIF that "Height" wasn't marked out with a --, so I tried changing the Height setting and it worked... this then implies that all the necessary data structures are present on the AirCurve 10 S to support iVAPS mode.

[bdarcus]

All height does is define a variable to calculate the target Va, which one can do manually also. Why I mentioned it's missing, but not critical.

But RR or BU on the other modes is more important, and what I was referring to when mentioning the "defaults" in my last comment. The modes do run at those default settings without the menus for them.

[ruri-baka]

It ultimately has to do with how the GUI is compiled for certain sets of machines. The actual values though are still present. It should be possible to set the missing variables through the serial console (see the serial to accessory port pcb) as a workaround.

[bdarcus]

It should be possible to set the missing variables through the serial console (see the serial to accessory port pcb) as a workaround.

Probably wouldn't be practical, though, in an emergent hospital environment?

[zhuhongchao]

I'm not sure, but I think it might be more than that. The mode algorithm that the runtime engine is using could simply ignore the parameters that aren't defined. If that's true it would be harder to trust that the algorithm will do the right thing because we don't know how the algorithm uses the sensor and statistical data for making decisions about the flow generation. For instance, my AirSense didn't know how to derived and track Ti, Ti Min, Ti Max, and I:E statistics until I flashed it with the firmware from my AirCurve 10 S. In the diff comparison of the AirSense and AirCurve firmwares, the only noticeable difference was the AirCurve had these Ti and I:E data structures defined... these structures were absent in the AirSense firmware.

GIF of iVAPS operation on AirSense with AirCurve S firmware

GIF of iVAPS operation on AirSense with AirSense firmware (all menus visible mod enabled)

Update: I noticed in the second GIF that "Height" wasn't marked out with a --, so I tried changing the Height setting and it worked... this then implies that all the necessary data structures are present on the AirCurve 10 S to support iVAPS mode.

I have modified the AIRSENSE AUTOSET firmware according to the instructions and added some new modes, but some parameters are missing. Is it possible to give me the firmware for aircurve?

[jayhathaway]

Does anyone have the aircurve vauto firmware they are willing to share privately?

[shaareable]

@jayhathaway I have a new vauto. You'd need to walk me through it maybe?

[jayhathaway]

Ahh well you'd need to dump the firmware according to the steps outlined in the airbreak guide

On Fri, Mar 10, 2023, 7:20 AM ShareableApps @.***> wrote:

@jayhathaway https://github.com/jayhathaway I have a new vauto. You'd need to walk me through it maybe?

— Reply to this email directly, view it on GitHub https://github.com/osresearch/airbreak/issues/42#issuecomment-1463957041, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGWCPGPHZUQ4SLSFLS3IR5LW3NBE7ANCNFSM4MYCWFSA . You are receiving this because you were mentioned.Message ID: @.***>

[jayhathaway]

I actually just got my hands on the firmware. Thank you for offering!

On Fri, Mar 10, 2023 at 9:19 AM Jay Hathaway @.***> wrote:

Ahh well you'd need to dump the firmware according to the steps outlined in the airbreak guide

On Fri, Mar 10, 2023, 7:20 AM ShareableApps @.***> wrote:

@jayhathaway https://github.com/jayhathaway I have a new vauto. You'd need to walk me through it maybe?

— Reply to this email directly, view it on GitHub https://github.com/osresearch/airbreak/issues/42#issuecomment-1463957041, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGWCPGPHZUQ4SLSFLS3IR5LW3NBE7ANCNFSM4MYCWFSA . You are receiving this because you were mentioned.Message ID: @.***>

[DocFreeman]

I actually just got my hands on the firmware. Thank you for offering! On Fri, Mar 10, 2023 at 9:19 AM Jay Hathaway @.***> wrote: …

I'm also looking for this .bin file. Would love it if you could help me out.

[jayhathaway]

https://drive.google.com/file/d/1fFEThG_DEakaaTcObgKXwwoApSy2G3RU/view?usp=drive_link

On Sun, Jun 25, 2023 at 8:13 AM DocFreeman @.***> wrote:

I actually just got my hands on the firmware. Thank you for offering! On Fri, Mar 10, 2023 at 9:19 AM Jay Hathaway @.***> wrote: … <#m2111309945124482534>

I'm also looking for this .bin file. Would love it if you could help me out.

— Reply to this email directly, view it on GitHub https://github.com/osresearch/airbreak/issues/42#issuecomment-1606128577, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGWCPGKVWMA7WDCD464QNMLXNBIPZANCNFSM4MYCWFSA . You are receiving this because you were mentioned.Message ID: @.***>

[DocFreeman]

… On Sun, Jun 25, 2023 at 8:13 AM DocFreeman @.> wrote: I actually just got my hands on the firmware. Thank you for offering! On Fri, Mar 10, 2023 at 9:19 AM Jay Hathaway @.> wrote: … <#m2111309945124482534> I'm also looking for this .bin file. Would love it if you could help me out. — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGWCPGKVWMA7WDCD464QNMLXNBIPZANCNFSM4MYCWFSA . You are receiving this because you were mentioned.Message ID: @.***>

Much appreciated! I think the repo maintainers would appreciate it as well if you got rid of the link, airbreak does not distribute copyrighted files.

[BravoIndia]

I did flash my AirSense with my AirCurve's firmware, this worked perfectly and all the data structure definitions that the AirCurve had are present and operational. So let me be clear, this issue is entirely an artificial software limitation. If someone had an AirCurve 10 ST-A firmware this device would have all the data structure definitions and flashing its firmware onto virtually any other device, such as an AirSense 10 AutoSet, would enable a device that has 100% functional iVAPS and PAC modes. So if you have access to an AirCurve 10 ST-A, you can clone its firmware onto a base model AirSense or AirCurse device. In an assembly line situation, a machine can be disassembled and re-flashed with ST-A iVAPS / PAC ventilator modes in less than 10 minutes per machine per person.

The serial number and other vital product information are not stored within the firmware, that information is stored in an EEPROM; there is no uniquely identifiable information contained in the stock stm32.bin firmware file that OpenOCD dumps.

@nbritton Any chance I could contact you about your experimentation flashing AirCurve 10 S firmware onto the AirSense 10 AutoSet? Very much hoping you see this, thanks.