OSCAR: Questions regarding a potential import for Garmin data

[littleyoda]

Hi

I am currently considering writing an importer for data from Garmin devices into OSCAR.

In the first development step, I would get the data from Garmin Connect as a JSON file via a Python script and an importer integrated into OSCAR would import the JSON file.
Later, the data could then be downloaded from Garmin Connect directly from within OSCAR.

After looking through the source code a bit, I have a few questions.

1) When checking the ChannelID, I found the following existing channels that are relevant for Garmin devices:
OXI_Pulse, OXI_SPO2
Journal_Weight
ZEO_SleepStage, ZEO_ZQ, ZEO_TotalZ, ZEO_TimeInWake, ZEO_TimeInREM,
ZEO_TimeInLight, ZEO_TimeInDeep, ZEO_Awakenings,
POS_Movement

The loader_plugin only implements one MachineType at a time. But I had ChannelID from different MachineType.

What is the best way to deal with an import that imports a wide range of channels?
If I see it right, no import supports this scope so far.

2) The data is provided in different frequencies.
While measurement values for pulse are available every 2 minutes, time frames are always given for the sleep level, which can sometimes be 1 1/2 hours long.
Can the data structures in OSCAR handle this if the measured values are available in different time intervals and types (measured values at time X vs. time ranges).?

3) Some Garmin data is only available for the sleep time (sleep level) while others are available for the whole day (pulse).
A few tests with CVS files showed that it can lead to strange effects when measurements are suddenly available for the whole day. My guess is that OSCAR is actually designed so that only measurements for the sleep time should be imported.
What would you recommend? Is there a way to determine the sleep time based on the CPAP so that I don't import the pulse outside of these times, for example?


I think that's enough questions for the first round.
 

lg

[Crimson Nape]

#1. I believe you would need to create the additional channel declarations to address this.
#2. & #3. If each observation is timestamped, then it would be easy to parse the data to compare against a sleep session. Otherwise, that could be a biddy.

Have you looked at the Somnopose loader? It parses a CSV file.
- Red

[littleyoda]

Have you looked at the Somnopose loader?  It parses a CSV file.
- Red

yes, I have look on different loaders. I had already written a Python program that transforms the garmin data into Zeo and md300w1/somnopose files. But handling so many files is no fun.
And in the end, every file format had its limitations and problems.

My main "concerns" are that each loader only supports one machine type and I am not sure what role the machine types play in OSCAR or how I can implement a loader that would fill so many channels over different machine types.

I hope that one of the developers can say something about this.

[bedeee]

any progress on the Garmin import?

I've been experimenting with getting the data from the garmin api too ... didn't get far on the formatting in e.g. .csv yet...

[littleyoda]

[I'm not allowed to post links]
Hi

I have a working fork of Oscar where you can import Garmin data.
Currently you have to run a Python programme which generates data and which you can later import into OSCAR.

github.com/littleyoda/oscar/tree/garmin

And the issue in the gitlab repository:
gitlab.com/CrimsonNape/OSCAR-code/-/issues/5

As the approach works for me and no one has shown any further interest so far, I have not developed it any further.
I'm not sure if I really want to port relevant parts of the Python garmin connect library[/url] to C++.


Attached an example with movement and stress level from a garmin watch.

[bedeee]

I'm impressed!

[rpalmer68]

I'm definitely interested in getting my Garmin sleep data into OSCAR.  I also have an Airsense 11.

[bedeee]

Notes:
- Compiling OSCAR from source is straight forward on Ubuntu (- it took a bit of effort to figure out what packages to install on Fedora though)
- Garmin .json downloader works fine, and the importer too
- i have a DST or timezone offset of one hour I need to straighten out - I'll tinker a bit aournd and possibly add a command-line switch to the python downloader, to sort this out.

Unresolved:
I suspect the time in my AirSense is a few minutes off - Is it a known phenomenen, that the time drift on these devices?
(the fact that the normal Oximeter import has fineadjust on the imported timestamps kind of hints to this)

I would like to get as-precise-as-possible sync between Airsense and Garmin data, to try to identify patterns.
An error in sync of the clocks of e.g. 10 seconds could be a problem if I want to distinguish between 1) i move because I wake up or 2) I wake up because I move.

[littleyoda]

Thank you for trying out my changes.

Yes, time zones is still a problem with the Airsense 11. My source code tries to corrected it for Europe (CET/CEST), but I couldn't test it outside of Europe yet.
I also thought about correcting the timestamp in the Python script, but I wasn't happy with this approach. Best way is to correct it in oscar, but since oscar stores the time as local times, as I understand it, this is not easy either.

I have not yet tested how accurate the time is in Airsense 11. Since it had a GSM module built in, I assumed that it should be accurate to the second.

Unfortunately, your desired accuracy in the seconds range will not be achievable. Garmin only provides the information for one minute at a time:

Code:

       "sleepMovement": [
           {
               "startGMT": "2024-12-17T20:34:00.0",
               "endGMT": "2024-12-17T20:35:00.0",
               "activityLevel": 5.632591481062802
           },
           {
               "startGMT": "2024-12-17T20:35:00.0",
               "endGMT": "2024-12-17T20:36:00.0",
               "activityLevel": 5.165337991594701
           },
           {
               "startGMT": "2024-12-17T20:36:00.0",
               "endGMT": "2024-12-17T20:37:00.0",
               "activityLevel": 4.674585791470192
           },
           {

[bedeee]

Let me repeat: This is great :-)

   

A lot of things to observe here (nothing related to the quality of the software):

• Garmin Sp02 is always 3~5% off on me (I have two samples of this from the sleep lab, where I was allowed to try a medical Ox sensor while awake)
  
• I suspect the difference between the plateaus of 90 and 95% is because I'm sleeping on the arm, thus restricting flow a bit to/near the skin, where Garmin measures. Or just sleeping on that side moves the watch a bit. But I have no data to back that claim.
  
• The resolution is 2 minutes for heart rate on my Phenix 6
  
• The (3D) accelerometer-data is aggregated into "movement-data", and with a resolution of 1 minute.
  
• There is no (3D) magnetometer data available at all. I was planning on having a second cheap garmin on my chest, to show sleep position (right/left side, back). But that seems not possible.
  

But hey - the watch was free (I had it already) so the possibility of having this data integrated for free is great.