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.
