(04-21-2021, 12:16 AM)cathyf Wrote:

(04-20-2021, 09:04 AM)Dog Slobber Wrote:

(04-19-2021, 03:06 PM)cathyf Wrote: Ah, well. it was a thought...

The ResMed engineers who didn't think to put the code in to sync the clock using the cell phone network are idiots! Maybe they'll fix that in the AirSense11?

The cellular networks don't serve time, nor do cell devices use the network to use a more traditional time protocol like NTP or PTP, though one can use an app for that. Cell phones capable of time syncing use GPS Network Time Synchronization.

I was thinking more along the lines of the machine is talking to the ResMed network and could ask what time it is. From there it would be simple to write that information somewhere in the data stream. The clock doesn’t drift very far very fast, so that would fix most problems well enough. 

Having been a bemused bystander to the great network time religious wars, I can say that the takeaway is that it’s not that hard to do something reasonably intelligent, and then developers can figure out what to do from there. 

I’m wondering if you could use the FlashAir syncing to keep reasonable track. There are a whole bunch of files being created with times embedded in the names, and everything has creation times in the metadata. You ought to be able to run a script that would keep track of which flies first appeared when and then you should be able to zero in on the clock drift after watching files pop up all night. 

But, anyway, the computer nerds had invested an extraordinary amount of thought into managing times over far-flung networks, and had it pretty well figured out long before GPS was even dreamt of. The ResMed engineers obviously put some considerable thought into how to manage the problem that the date rolls to the next day in the middle of the night which you want to be all part of “one night’s sleep”. And what they came up with is not stupid. So they solved the hard problem but didn’t think about the easy problem!

(04-21-2021, 04:41 AM)biorn Wrote: So on the flashair you could do a simple trick. That need some investigation but on the main lines for the signal when a new file is created the flashair will change the reference time in the file to the actual time know by the flashair. Maybe there is better solutions but it's the first I got.

(04-21-2021, 03:33 PM)biorn Wrote: I hope I understood all you said, cause my english is worst.

First thing is, timestamp creation of a file should never be used. (to much possiblities of corruption)
so don't care about it.

I don't remember this part of acquisition but Oscar don't should be car about the file name (the time include in the name) because each file include the start time of the data and that in this way edf format was created. Maybe I'm wrong and oscar use it as baseline. In all case it's better to have the name corrected and the crc too. (I mean oscar check it)

this part of the file:




And the last thinks as I can see in your screenshot, the time isn't instant so the script should be care about hours difference and not the minutes or secondes I think.

Sorry if I missunderstoud something

(04-22-2021, 09:11 AM)Crimson Nape Wrote: I don't mean to rain on your parade, but I haven't read any ideas to addressing the following.

The FlashAir card is nothing more than a storage device with wireless connectivity.   It doesn't possess the logic to know when the data was actually created.   Creation time has to be provided by the device creating the data.  If a file was created a 3AM but wasn't written to the FlashAir until 7AM, are the times inaccurate at the time of creation and/or at the time the data is being transferred?  How does the FlashAir determine when data being written to it is in real-time as opposed to being historic data?

Then we have the CPAP itself.  For a Resmed, all reporting parameters are not totally functional up to one minute after the displayed starting time. When all parameters are reporting, when was the observation made as opposed to when it is being reported?  

Another consideration are time variables provided by the oximeter's sensor location and the patient's pulse rate.  Even if you were able to synchronize the CPAP and the oximeter to the exact second,  there is a lag time from when an event occurs and the time as to when the sensor reads this change.   If a patient was wearing the sensor on a toe and is experiencing bradycardia, there is going to be a larger time delta as opposed to having tachycardia and wearing the sensor on a finger.

Both the CPAP and oximeter have a ramp, or normalization period, after pressing the start button.  On the CPAP, there is a blower pressure ramp-up after staring that is separate from the Ramp option.  When does the actual start time occur?   As soon as you press the start button, or when the blower is at full pressure?   For the oximeter, it takes several seconds for it to acquire and report a pulse and SpO₂ value.  How long is the normalization time for any given recording session?  

Viatom/Wellue data files provide a starting time and date, a time duration, and file size in their header.  Based on file size and time duration determines the sampling rate of the data.  Based on the math proving this, the reported start time is that of the first recorded sample.  Since there isn't any value, that I'm aware of, for the time between power-up and sensor normalization, this is the unknown.

Based on all the variables I listed above, I don't believe that a time synchronization is feasible or possible.  I am interested on your ideas as how to address these unknowns.  It may be something simple that I'm not seeing.

Please take into consideration that I have been known to march to a different drummer though.    
- Red