Ambient data #777
Ambient data #777
Conversation
|
Changes unknown |
|
Regarding the choice of |
There was a problem hiding this comment.
I'm not sure writing binary files in this manner is a good idea. If we can't access hdf5/zarr then I would revert to CSV for the time being.
Here having just numbers in an unspecified shape and without column names is calling for trouble if we need to refactor or version this dataset.
I'll let you judge. If you wish to stick to unspecified binary I would at the very least move the reader to iblutils and document this in Alyx.
| self.bpod_modules.module_write(self.ambient_module, 'R') | ||
| reply = self.bpod_modules.module_read(self.ambient_module, 12) | ||
| self.ambient_module.stop_module_relay() | ||
| data = np.frombuffer(bytes(reply), dtype=np.float16).copy() |
There was a problem hiding this comment.
Is the original data in float32 ? Why do we use float16 here ?
I'm not worried about precision but float16 is not straightforward to manipulate and we reserve the use to very large datasets. I would write float32 for user side convenience.
| if self.hardware_settings.device_bpod.USE_AMBIENT_MODULE: | ||
| sensor_reading = self.bpod.get_ambient_sensor_reading() | ||
| self.ambient_sensor_table.iloc[self.trial_num] = sensor_reading | ||
| self.bpod.write_ambient_data( |
There was a problem hiding this comment.
Yes so here it is worthwhile noting that we get to open/close the file at each trial.
It is not an issue in our case, but for a much faster stream, we would rather open the file at the start of the session, and feed the file pointer to this method.
The idea being that the method can parse the type being fed, if it is a file pointer it writes directly, if it is a file path it opens / closes the file as usual.
| ambient_data.tofile(f) | ||
|
|
||
| @staticmethod | ||
| def read_ambient_data(filepath: Path | str) -> pd.DataFrame: |
There was a problem hiding this comment.
I would put this with the jsonable in iblutils !
No description provided.