CPAP clock drift enhancement for OSCAR (multiple time-dependent corrections)

[tungpust]

CPAP clock drift enhancement (multiple time-dependent corrections)
The preference menu for "CPAP clock drift" allows only one time correction. With this single time correction, one can make the displayed time of various events be approximately correct only for a while, and then of course it will drift off again because the CPAP internal clock keeps running at just a little bit different speed than true time. And if you look at older data, any new correction will of course then also be wrong for the older data.

Right now my correction setting is -34min1sec, and since I set that value, another 16min or so of error has accumulated.

So: What is really needed is multiple corrections that should be applied depending on the recorded time. For example, if the machine clock drifts about 10min in a year, the correction specification might end up looking something like

Code:

cpaptime 2020-05-09T12:15:05 walltime 2020-05-09T11:25:05 (10min drift 2019 to 2020)   # newest
cpaptime 2019-05-09T12:15:05 walltime 2019-05-09T11:35:05 (20min drift 2017 to 2019)    
cpaptime 2017-05-09T12:15:05 walltime 2019-05-09T11:55:05 (initial error measurement)  # oldest

The program could then compute (interpolate, lnear interpolation okay) and display the correct walltime for any and all data events as needed. And the user could add a correction spec every year or month or whatever, as needed, to get a satisfactory accuracy.

In modern CPAP machines, with bluetooth/wifi/whatnot, I'm sure the clock gets corrected all the time by a quite accurate network time, but with all older machines, the need for special cables and software makes correcting the clock quite impractical for most people. Hence the need for a VARIABLE software-based time correction that can entered by the user.

How does that sound?

[Crimson Nape]

You would think so but the current CPAPs still use a manual setting, if they have any adjustment at all. The only thing that currently comes to mind would be to encode the time + the offset value into each day's data during import. That way it would only affect the data that is imported with the current offset and not previous data. I know, easy for me to say this.

[tungpust]

@Crimson, if manual machine clock settings are still common in 2021, the scheme I propose is relevant and useful to even more people than I imagined  :-)

[sawinglogz]

This is on my radar for an eventual database redesign. I want to be able to tag individual imports (from any device) with clock adjustments, and allow OSCAR to interpolate between adjustments.

I'll probably experiment with cramming this into the existing database when I resume my work on oximeters, some of which don't have a clock at all.

In general we want to make it easier to align data from multiple sources.

[SarcasticDave94]

FWIW my ResMed AirCurve 10 ASV has manual clock/date settings.

[2SleepBetta]

  The only thing that currently comes to mind would be to encode the time + the offset value into each day's data during import.  That way it would only affect the data that is imported with the current offset and not previous data.  

CN, from my POV, suggests a good way to approach a huge problem for a few of us.  I try to get time adustments applied correctly for Dreem D2, Gulf X2-02 accelerometer, Contec 50I oxmeter and an AirCurve VAuto. 

For my purposes, the D2's resolution is poor but it's all we have for attempting to determine sleep stage. It has 30 second granularity, at best--the best I can tell, so far. I try to judge which patterns of  amplitude and/or frequency disruption in the flow rate do explain sleep stage changes out of Deep or REM to Light, or from any other stage to WAKE. My hope is to get to a point where I can post to an old thread which flow rate disruptions are significantly associated with (yes, probably, only my) sleep stage "downgrades".

Motion data is easiet to synch with Flow Rate because because there are nearly pin-point-coincident graphic signatures of a wave form and its accompanying motion . For example, most all my sigh-wave wave forms will consistently be accompanied by a tiny motion disturbance at either--I don't know which--the time of the second stage of the inhalaton half cycle or at its peak exhalation rate--an uncertainty interval of less than, say, about 0.5 seconds. Use of the sigh for accuracy, requires a first import, a measurement of the wave-motion offset, a correcton of its data log start time, a voiding of the sleep session, a reload of the session and a re-import of corrected motion data. 

Ir's a continuing nightmare trying to close the combined error gaps to a few seconds overall and needing to do it nearly daily--partly because of clock drift and partly because human (my) reaction time varies and introduces errors too (this when atempting simultaneous presses of two start buttons or of pressing one button, "Start Night", on the D2 while doiing a "simultaneous" sharp inhale to trigger the VAuto EASY ON ) . Once done, it's possible to rest in that a few days before adjusting again. Adusting the VAuto drift again for a later session disturbs previous sessions' synchronizaton, so (I believe) it will become necessary to keep a log of what the earleir drift setting was for each session.

The D2 logs stage data close to whatever time our smart phones update to and its time is the most consistent (and its "Start Night" time is the most difficult to adjust by editing the CSV file--which, as discussed elsewhere, requires special  handling for OSCAR after its [Excel] file-opening). Accordingly, I find and use the D2 clock as the correct time and attempt to synchronize to it the other three clock times. I check times every few days, make note of and apply the fast-slow times for the three devices varying drift.

Beyond different start times (button press or EASY ON) and different drift rates, each device has its own lag time, before logging its first data entry.  Synchronization. Bah! I'm still trying to get better at it. The oximeter data synch is, for me, less critical and has lowest priority. Thankfully there is opportunity to adjust ithe 50I's logged start time on import by OSCAR. I always start all devices on the minute mark in the order X2, 50I, and then D2 & Vauto. "simultaneously". Times are "all over the place".

[A KLERK]

Isn't there a way to trigger all machines for synchronization? I try a cough plus movement...
Think of the motion clap board (right name?) used for the same purpose in movie industry...

[tungpust]

@sawinglogz

Glad to hear clock drift enhancements are on the radar. Not sure I would want to enter a new clock drift correction every time I do a flash card dump, though. Just a per-profile set  of voluntary occasional  corrections would work best for me (just as described in OP)

Perhaps I should describe how I do my correction now: Wake up, sit up, grab pen and paper, use accurate time source to write down HH:MM:SS exactly as I turn off the cpap session. After letting the cpap finish writing the data to the sdcard, hand-carry the card and  dump the data into Oscar. Check the timestamp of the end of the session. Compare with the paper note and calculate the correction to enter.

The only automation opportunity for this scenario is to allow entering only the accurate walltime corresponding to the end of the last session, i.e. not having to calculate the correction amount myself.

I imagine for some machines with wifi, the machine clock can be possibly be queried or otherwise observed during download, and compared with computer network walltime. This would be a more automated approach that could easily be done along with each download. But for those of us that hand-carry the card to a computer for download, not having to enter a correction each time is essential.

You probably had thought through a lot of this already...

[tungpust]

@2SleepBetta

Wow, you have super-complicated problem of time-correcting and thereby time-aligning data from 4 different hardware devices, down to sub-second resolution. That is a lot more than my problem.

Device designers and software engineers alert: Allowing your devices to synchronize with a central clock source is essential to make your devices maximally useful. Never make a device without making sure it can set its clock from the network, multiple times per day if possible. Heck why not every 5 minutes. A cheap 100ppm crystal can cause a clock to drift 0.36 seconds in one hour, and for some applications, even a second is too much misalignment.

[sawinglogz]

Isn't there a way to trigger all machines for synchronization? I try a cough plus movement...
Think of the motion clap board (right name?) used for the same purpose in movie industry...

But even armed with that knowledge, OSCAR doesn't make it easy for you to correct the relative timestamps for that night.