-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No Activity Data Parsed #19
Comments
Thanks @muschellij2. This is a robustness issue, somewhat similar to #10. In this file the accelerometer packets are in ACTIVITY format, whereas One of the limitations for me has been that I haven't encountered certain packet types in the wild. This file has both ACTIVITY and LUX packets (neither of which I've dealt with), so it will potentially serve as a nice way to get those set up. That said, it's going to be months before I can get to it. |
I agree - definitely an enhancement. The lessons from this example is |
Just a note that if more examples with with the newer activity format and LUX would help I have plenty and would be happy to share some. In sleep research, the lux data could be very interesting and would be neat to get through |
Just experienced this - good to know it's because of the ACTIVITY packets!
|
You can try read.gt3x.
https://github.com/THLfi/read.gt3x
On Fri, Aug 28, 2020 at 1:18 AM Tom Stewart ***@***.***> wrote:
Just experienced this - good to know it's because of the ACTIVITY packets!
> df <- read_gt3x(file, verbose = T)
Processing Laura (2020-08-16).gt3x
Unzipping ............. COMPLETE
Checking components ............. COMPLETE
Retrieving info from the zip archive ............. COMPLETE
Will parse the following packet types, if available:
METADATA, PARAMETERS, SENSOR_SCHEMA, BATTERY
EVENT, TAG, ACTIVITY, HEART_RATE_BPM
HEART_RATE_ANT, HEART_RATE_BLE, LUX, CAPSENSE
EPOCH, EPOCH2, EPOCH3, EPOCH4
ACTIVITY2, SENSOR_DATA
Reading log.bin ............. COMPLETE
Getting record headers ............... COMPLETE
Parsing PARAMETERS packet(s) ............. COMPLETE
Parsing EVENT packet(s) ............. COMPLETE
Parsing METADATA packet(s) ............. COMPLETE
Parsing BATTERY packet(s) ............. COMPLETE
Parsing ACTIVITY packet(s)
Parsing LUX packet(s)
Processing complete. Elapsed time 0.08 minutes.
Warning messages:
1: In parse_packet_set.default(X[[i]], ...) :
No method exists yet for parsing ACTIVITY packets -- returning NULL.
2: In parse_packet_set.default(X[[i]], ...) :
No method exists yet for parsing LUX packets -- returning NULL.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIGPLXDO5ORRCXJSZTABSTSC44ZXANCNFSM4KUDXXUA>
.
--
Best,
John
|
Thanks for all this feedback. I've now had a first go at introducing an ACTIVITY packet parser, which you can invoke when you set I haven't done a lot of testing on it, but so far it's looked alright. I'd recommend comparing outputs against My guess is read.gt3x is still faster. Not sure I'll solve that... But this fits right into the recent parser design update, so I do think it flows well. Let me know if anything isn't working. The build is failing right now on Travis, but it looks like that's due to rJava configuration. Shouldn't be a problem if you install with |
Travis is (apparently) configured in both repos to install all packages (including those in Looks like there's already a request for the Travis folks to look into it. |
Issue
Example
gt3x
data has no parsed Activity - maybe Activity2 packet?I'm adding @THLfi to the mix because I want to note that
AGread
parses a lot of additional, likely useful information fromgt3x
compared toread.gt3x
. Also, the timing differences are quite different, but again the amount of info parsed is very different.Created on 2020-02-12 by the reprex package (v0.3.0.9001)
Session info
The text was updated successfully, but these errors were encountered: