From this investigation it appears there are still differences between read_gt3x and read_AG_raw.
Some observations:
Running read_gt3x with verbose = TRUE seemed to devote a lot of time to filling in gaps in the time series.
The differences occur in runs that are multiples of the sampling frequency, which suggests that the problem is with post-processing
Limited inspection shows the differences are occurring when read_gt3x indicates a string of 0's while read_AG_raw indicates a latched packet.
All of this seems to point to an issue with the way idle sleep mode and/or USB connection events are handled in read_gt3x. I suspect the current approach (latch one packet and fill the rest with 0's) applies only at the end of the file, and that any other gaps in the time series are filled exclusively by latching.
That suggested approach doesn't quite work. In the file shared in #7, there is one gap in the middle of the file where the first packet is latched and the rest are filled with 0.
From this investigation it appears there are still differences between
read_gt3x
andread_AG_raw
.Some observations:
Running
read_gt3x
withverbose = TRUE
seemed to devote a lot of time to filling in gaps in the time series.The differences occur in runs that are multiples of the sampling frequency, which suggests that the problem is with post-processing
Limited inspection shows the differences are occurring when
read_gt3x
indicates a string of 0's whileread_AG_raw
indicates a latched packet.All of this seems to point to an issue with the way idle sleep mode and/or USB connection events are handled in
read_gt3x
. I suspect the current approach (latch one packet and fill the rest with 0's) applies only at the end of the file, and that any other gaps in the time series are filled exclusively by latching.