How Can You Read Actiwatch Spectrum Plus CSV Files?
ugGit opened this issue · comments
According to the docs, PyActigraphy supports reading in CSV files containing data from Actiwatch Spectrum Plus.
Sadly, the 'assosciated functions' described below are not referencing the method which would handle such input.
Thus, how can you read these CSV files?
Associated functions according to the docs:
| read_raw_agd(input_fname[, start_time, period]) | Reader function for raw AWD file. |
|---|---|
| read_raw_atr(input_fname[, mode, ...]) | Reader function for .txt file recorded by ActTrust (Condor Instruments) |
| read_raw_awd(input_fname[, header_size, ...]) | Reader function for raw AWD file. |
| read_raw_bba(input_fname[, name, uuid, ...]) | Reader function for files produced by the biobankAccelerometerAnalysis package. |
| read_raw_dqt(input_fname[, name, ...]) | Raw object from .csv file recorded by Daqtometers (Daqtix, Germany) |
| read_raw_mesa(input_fname[, time_origin, ...]) | Reader function for MESA files |
| read_raw_mtn(input_fname[, start_time, ...]) | Reader function for raw MTN file. |
| read_raw_rpx(input_fname[, language, ...]) | Reader function for raw Respironics file. |
| read_raw_tal(input_fname[, name, sep, ...]) | Raw object from .txt file recorded by Tempatilumi (CE Brasil) |
If it is not yet supported, I would be interested in the steps necessary to extend PyActigraphy to support CSV files from Actiwatch Spectrum Plus as data source.
Hello @ugGit
Actiwatch Spectrum Plus is a device manufactured by Philips Respironics, if I am not mistaken.
As such, .csv files from devices of the Actiwatch family can be easily read with the read_raw_rpx function, the penultimate line in your table.
Probably, it should be clarified in the doc. Any suggestion?
Hope that helps.
Now, it feels like an information I should have found myself...
However, I think, it would be consistent to use the same format as for .csv files from Daqtix. I.e.:
Reader function for .csv file recorded by Actiwatch 2 and Actiwatch Spectrum Plus (Philips Respironics).
That means, a structure along: Reader function for {file type} file produced by {device(s)} ({manufacturer}).
What do you think?
I'll make a PR once we agree on the structure :)
Now, it feels like i should have formatted the doc the way you proposed. Indeed, systematically reporting file type / device (manufacturer) is the most informative way.
Having a fresh look on the doc/code is really helpful.
Thanks again.
Greg
Cool. I'll update the docs briefly.
Any reason why read_raw_alu() is not included in the liste, despite being implemented?
Well, I'll started a PR to improve the doc. I'll ask further questions there.