The last statistics events in each slice are now correctly imported.
Previously, in the surprising edge case where two statistic periods are
reported with the same end-of-slice timestamp, they were both being duplicated
when marking the end of the slice.
Also, there were scattered instances where the final statistics in a slice
weren't being imported at all or were being imported incorrectly. These are
now fixed as well.
No change in import behavior yet, but this will be needed to deal with a weird edge
case in which two statistic periods are reported with the same end-of-slice timestamp,
the first one intended to cover the preceding 2 minutes, the second one presumably
intended to cover the fractional second after the previous interval, though all
values are 0, so it's hard to be sure.
Also add support for parsing and proceeding past a previously
unseen F5V0 event, though for now it's just getting swallowed
since its meaning isn't entirely clear.
This adds BND flagging to machines without waveform data, such as F3V3 (1160P)
and bricks (250P, 200X), as well as sessions for which waveform data was
unavailable. It also catches BNDs at the end of a session, which were
previously missed.
By duplicating the last reported event at its originally reported
event (clamped to the slice end time for F3V3), charts will now
correctly show the value during that last interval.
Also fix some slice sanity checks so they don't yell when F3V3
skips an event chunk.
This now correctly shows gaps in therapy and statistics when the
mask is off. It also corrects the initial statistics for some sessions
to 1 second later, when the initial mask-on slice begins 1 second
after the session starts.
Weird zero-length PB and LL events are now dropped on import, since
they wouldn't get drawn anyway and seem to be peculiar artifacts.
If there are no mask-on slices of nonzero duration, then there's not any
meaningful event or waveform data for the session. There is occasionally some
fragmentary data, but it's always less than 1 second.
When such fragmentary waveform data is present, it only contains 1-3 nonzero
samples, corresponding to 0.2s - 0.6s of data, which suggests that the
mask-on slice was really that long rather than precisely 0. As a result,
it appears that the timestamps of the mask-on/mask-off slices are just the
current value of the machine's internal clock, which only has 1-second
resolution.
But rather than embark on herculean efforts to derive a sub-second slice
duration from (only occasionally present) event or waveform data, we just
treat the session as having no detailed data.
Because summaries used to be parsed incorrectly, there was a bunch of ugly
logic that was designed to infer the session start & end times from other data.
Now that the summary parsers work, that can all go away. The only change to
imported data is that sessions ending with the mask off are now longer, to
reflect that extra time before the machine was turned off.
This now correctly shows gaps in therapy and statistics when the
mask is off. It currently only works for F3V3, since it has a
separate event chunk per slice. Other machines, which have only
a single large event chunk, will need to track the slices as
they import events.
This also highlights the issue with the last statistics in a
slice: only one data point is imported indicating the start of
a measured value, and so it appears that the data terminates then
instead of at the end of the slice (seconds to minutes later).
This fixes a regression introduced by fda9fcd1, which fixed import for
all the other machines but broke F3V3.
Also move the generation of HY/CA/OA events out of the parser and into
the importer.
This will let us create "duplicate" statistical events at the end of
a session (and eventually slice) to reflect the end time of each
measurement channel.
PRS1 statistics are reported at the end of a 2-minute interval,
but OSCAR assumes the timestamp for the statistics is their
starting timestamp.
This resolves the issue where statistics wouldn't appear for the
first two minutes of a session, and then would consistently be
2 minutes delayed.
There are still some edge cases to deal with, but the general
case is much improved.
Also clean up unused PRS1 channels and fix a regression from
9a25647c that broke unintentional leak calculation for CPAP/APAP.
Also add PRS1PressureAverageEvent to F0V4 list of supported events.
Right now this results in slightly confusing graphs, since sometimes
the IPAP/EPAP data for a machine is primarily reported by its settings
events, and for other machines by its statistics events. Also, the
"average" pressure on F0 looks like it might be effectivley EPAP in
single-pressure mode rather than the true average in bi-level mode.
Once we decide on the best presentation, we can either update the importer
or the display to show the most helpful channels for a given session.
Occasionally waveforms in a DreamStation session can be split into
multiple files. This behavior resulted in a report of missing waveform
data, and upon investigation was found 15 times out of 10,000 sample
sessions.
It looks like this happens when the machine begins writing the waveform
file before realizing that it will hit its 500-file-per-directory limit
for the remaining session files, at which point it appears to write
the rest of the waveform data along with the summary and event files
in the next directory.
The previous commit added better testing support and warning messages
for when this is encountered. This commit fixes the issue, and so
the warning is no longer necessary.
Also warn when waveform files are being skipped on import due to this
kind of splitting.
The chunks YAML now emits all unique chunks found in files with the
same session ID.
Note that a single file can contain multiple chunks covering multiple
sessions. These will all be saved in the YAML file corresponding to the
original file's name, rather than the session ID encoded in any chunk.
This slight discrepancy is intentional, since the chunk YAML is meant
to test the parsers, to verify that they correctly decode a specific
input file. When importing data into a session, we use the actual
session ID specified by each chunk. Thus the session YAML files will
be derived from the proper chunks, regardless of their original
containing file. (Well, except for waveforms, but they don't appear
to have more than one session ID per file.)
F3V3 events are formatted as waveforms (rather than a series of timestamped
events), with one chunk per mask-on slice. The previous assumption of only
a single event chunk per session meant that all events after the first slice
were getting dropped.
BiPAP AVAPS 30 (System One 60 Series) now works much better, although the data
doesn't yet show any gaps where the mask is off. Fixing that requires changes
throughout the code and not just in the PRS1 loader.
Also, LL calculation seems wrong. Perhaps the automatic calculation of
unintentional leak from total leak doesn't work for AVAPS, throwing off
automatic LL calculation? (F3V3 reports neither unintentional leakage nor
large leak events.)
This fixes the start/end times of such compliance sessions, but their
total_time is broken due to the presence of a 0-length slice.
That will require a more extensive fix of the slice system throughout
the program.
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.
Also fix an issue with initializing the model names, since QObject::tr
won't work at global initialization time. And series detection needs
the untranslated names anyway.
Also clean up brick detection.
The official names don't yet appear anywhere, since there's a question
of how to juggle manufacturer, series, and model name in the various
places they're (inconsistently) displayed.
Series is also used to pick the machine icon.
This fixes the mask pressure graph as well as many of the events.
There are still some issues with presentation: some of the events are
being drawn at the wrong time, and certain events and statistics
don't really behave the way they're displayed.
Also several events have yet to be encountered in sample data.
Pressure settings are now properly being found and decoded, but there are lots
of unknown fields to figure out.
It turns out it uses the same humidifier setting encoding as F0V6, and the first
several slices seem to be the same. But pressure encodings are different, with
a gain of 0.125 instead of 0.1, presumably to allow for a maximum pressure of
30 cmH2O.
This one's slice 8 is shorter than anything else we've seen before!
Also add support for a new slice type and noted possible values
for other data, including a possible lead on the CPAP mode.
Interestingly, it looks like settings and other slices can be of
varying length, even on the same machine. Stranger still, sometimes
the list of possible slices can change on the same machine.
Mostly this is commenting out warnings about values that are different
for every session. They can be sorted out later.
Humidifier status and tube temperature are cleaned up as well.
Fixed a bug in the ramp pressure setting, identified the mask resistance
setting, and found the summary equivalent of the humidifier setting change
slice.
This is mostly a cut-and-paste of the ParseComplianceF0V6,
but the some of the slice codes and sizes are different.
Also start adding machine names for tested models.
The new slice type appears when humidifier settings have changed during
the session, and includes a timestamp. The session time now matches
reports.
Otherwise just comments to indicate other values seen in the sample data,
including a lead on humidifier encoding.
Lots of debug messages and unknown values, but the structure seems right.
This is largely based on a combination of the mainblock parsing for fileVersion 3
as found in ParseSummary() and the switch statements of ParseSummaryF0V6,
based on our understanding of slices from F0V23. The slice types here
come from sample 200X files.
Also add some debug messages to FV3 parsing. It's clear the current
approach is wrong. This looks a lot like the slices seen earlier,
since hbdata values appear more than once in a given file.
Also turn off summary YAML since the next bit of work will focus on
parsing.
It turns out the session end time was intentionally not being set in ParseSummary,
probably due to its unreliability. This may be revisited once things are more
stable, but for now the old behavior is retained.
This doesn't have much observable effect, other than reducing a
day's total usage time if there are periods with no breathing
detected. Most of the shortcomings were obscured by information
gleaned from the events and waveform files.
A PB event obviously can't start so late that its duration ends in the future!
The fix hasn't been applied to F0V4 or F0V6 yet, since those haven't been
tested yet.
Also fix a sign bug in EventList::AddEvent when there *is* unordered data.
Remarkably, this resulted in nearly no changes to the test output.
Only one session with 0 duration had its start/end times reset to 0,
since it will no longer get imported.
This doesn't fix the bigger bug where files are skipped based on
their filename rather than the actual chunk session IDs. That's
a trickier challenge for another day.
This introduces a very slight change UI behavior, where the user
will receive an alert if their machine has a supported family/version
but is a model number for which we don't have any test data.
Also, the user alert for an unsupported machine has been updated
to align with the actual underlying parsing limitations. It's
possible this will create some new warnings, but it doesn't seem
like any such machines would have worked anyway, in which case
an explanatory message is an improvement.
The "untested" alert will happen on import once per launch of OSCAR.
Ideally this would only happen the first time an untested machine is
imported, but that will require figuring out how to serialize an
additional value in the user's machine profile.
