Also update the leak calculation logic to depend on the set of reported
events rather than hard-coding it based on machine family and version.
No change in functionality.
This commit adds a mapping from PRS1 events to the OSCAR channels that
should receive the data, along with the necessary supporting code to
allow for generic handling of PRS1 events as a result.
The F3V6 importer has minimal changes to partially use the new
plumbing, enough to make sure that it works and causes no change in
the imported data.
This fixes 960P-960T, which was importing both values at each interval, presumably
trampling each other. 950P didn't report it, and DreamStation never calculated it.
Also fix timed breath gain for pre-DreamStation autoSV.
F3V3 is unusual. Its events are recorded at fixed intervals like a waveform.
Its summary is recorded with absolute timestamps. Slices are each given their
own chunks in the event file.
This last oddity isn't yet handled.
While examining this, a few other importing issues have been cleaned up:
PRS1DataChunk::ParseEvents no longer needs the mode passed in as an argument,
F5V012 importers should quietly eat the newly parsed pressure
adjustment events until we can import both those and average pressure
statistics, and F5V012 importers should handle real VS events and treat
VS statistics like the other importers do.
This is very incomplete since we currently have only limited sample
data for F5V2. The events that have been verified will parse
correctly, and the rest will result in a parsing error.
There are some very strange changes in the event numbers compared
to F5V1 and F5V3, it's unclear why.
Note that F5V2 uses a gain of 0.125 like F5V3 instead of 0.1 like F5V1.
F5V1 introduces a new Hypopnea variant (event 8) with 2 data bytes.
This was previously seen in F5V3, and it's unclear how this is
different from the usual Hypopnea event (event 7, 1 data byte).
Parsing used to stop when it encountered this event, but now it
can continue through the end of the session.
F5V1 also adds a leak value in its periodic stats, also previously
seen in F5V3. PB start time and duration are now correct.
As with F5V0, now VS, LL, and EPAP adjustment are correctly parsed,
and timestamps and durations are now accurate.
The handlers were essentially copied from F5V3 and F5V0 for
consistency and cross-checking.
This fixes a lot of issues with event parsing. Now VS, LL, and EPAP
adjustment events are now correctly parsed.
And as a result the timestamps for events and overall session durations
are now accurate.
The handlers were essentially copied from F5V3 and F0V12 for
consistency and cross-checking.
No changes were intended in the imported data, but the parsers
were fantastically broken, so touching anything in the code
results in lots of differences in the output.
As a result, the imported data for F5V012 is now unstable.
On the plus side, the parser no longer bails on event 8 for F5V1.
This will almost certainly need to be split into 3 separate
functions.
F0V4 is unsurprisingly a midpoint between the two. PB/LL durations are
doubled as in F0V6 and, in fact, the contents of all events seem
identical between F0V4 and F0V6, apart from the new hypopnea events 0x14
and 0x15 in F0V6. We haven't encountered event 0 in F0V4 or F0V6 data
yet, but it would be an interesting comparison to F0V23.
It's now clear that PRS1PressureAverageEvent can't just be the average
overall pressure, at least not for CPAP: it's too low. This needs
further study.
Import changes:
- As with F0V23, apneas/hypopneas now have a (correct) duration of 0.
- PB/LL will now be drawn at the correct time, instead of starting when
they end. This was already fixed previously in F0V23.
- The EPAP graph is removed from CPAP data until we understand what
the underlying data is.
It also turns out that every sample machine that claims to be F0V3 in its
property file contains only F0V2 data, so there appears to be nothing
additional to test, but now there are more warnings in case we ever do
actually encounter F0V3 data.
Also warn if we ever encounter oximetry.
The only difference so far is the lack of doubled duration for PB/LL, slightly rearranged
events 0-3, and the absence of events 0x14 and 0x15 in F0V2 (so far).
The only change in import functionality is that apneas/hypopneas now have a (correct)
duration of 0.
Next step is to test against more samples and particularly F0V3 samples.
It turns out each familyVersion has records of different sizes, including
the first one containing the settings. It may make more sense to split
summary and/or settings parsing into multiple familyVersion-specific functions.
Also it looks like the F0V4 humidifier settings are actually 60 Series
settings, and the "V2" settings are original System One settings, not
all fileVersion 2 machines.
"Support" in this instance means that it will quietly ignore the events, since there's really
nothing to import. But this means that parsing will correctly continue past the events, even
though so far they're the only events in a session. There are diagnostics to log if that
assumption turns out not to be correct.
Still trying to figure out timestamp event.
Other summary parsers will need review, since there was an initial
filter that was dropping sessions that began with event 5 or 6,
now commented out.
Based on the F0V23 loop and F0V6 switch statement, along with manual review of
several sample files to determine record length.
Split ParseHumidifierSettingF0V4 out from ParseSettingsF0V4.
These are events that are in the PRS1 files but which OSCAR doesn't know how to present:
- An F0V6 event with duration that looks like PB or LL but doesn't appear on any official reports
- The Auto-CPAP pressure to use at the beginning of a session
- A report of the snores detected at each pressure/EPAP/IPAP
- Apnea alarms on F3V6
Rather than bury the understanding in commented-out sections of the parser, these events
will now be parsed and added to the internal event stream, which allows them to be dumped
to YAML. Whenever OSCAR eventually supports these data, the importer will have ready
access to them.
Again, no change to external behavior.
This only affects the parser at this point, and the importer has been updated so that
there is no externally visible change to the imported data.
Eventually we'll need to figure out how to display the two differing kinds of
pressures, at which point we'll need to fix the importer to use the right channels,
instead of the inconsistent treatment now.
The next step will be to split parsing from mode interpretation, so that
we can at least accurately identify all of PRS1's modes. Then we can
work on mapping that to OSCAR's notion of modes, which probably then needs
to be augmented.
They are stored in two separate locations (Contents/translations
for QT and Contents/Resources/translations) because
QLibraryInfo::location(QLibraryInfo::TranslationsPath) returns
the former only after macdeployqt has run, and returns Qt's
installed location prior to that.
And Contents/Resources/translations is the better location,
so we use it where we can.
to act differently from profiles after a subsequent application launch.
It was only getting set at the end of Profile::OpenMachines, which was only
called by the Profile constructor, and which wouldn't succeed on a newly created
profile, having no files to open. Therefore, the only way for the flag to be set
was to quit and re-launch the application after creating the profile.
The flag's only remaining use was to make sure that OpenMachines() wasn't
getting called twice and trampling an existing list of machines, so the check
there was changed from looking at a brittle flag to looking at the actual list
of machines.
A critical warning was also added to the check, since OpenMachines() is
only getting called from the Profile constructor and therefore can't
be invoked twice unless a new bug has been introduced.
duplicate sessions being added when making preference changes to a brand new
profile with existing data.
Preference changes trigger a reload, see PreferencesDialog::Save and
needs_reload, leading to MainWindow::reloadProfile -> MainWindow::CloseProfile
-> Profile::UnloadMachineData.
This is the root cause of the duplicate sessions, but the fact that it only
happened with newly created profiles, rather than on subsequent launches,
demonstrates an inconsistency in state of Profile. It should be identical when
initially created and when loaded via subsequent application launch.
This prevents duplicate sessions from being added to Day during a rebuild, but is still not
the root cause. The next step will be to address the attempted duplication in Machine.
