Discussion: Channel data types

[aacuevas]

The intention of this post is to start a conversation on what I believe should be one of the next points of improvement for the GUI at large.

Historically, the GUI has had support for 3 "channel types", all derived from what the acquisition board could produce: "headstage" (in the uV range), "ADC" in the V range and "AUX" in the "mv" range, even if this last one represented the accelerometer values, so the actual output is somewhat arbitrary.

However, the GUI is steadily expanding towards supporting more and more devices, each with different kinds of continuous streaming data.

An existing example is the plugin that @bparks13 is developing, which include IMU data. This device produces 4 channels of quaternion data, 3 channels of linear accelerometer data, 3 channels of gravity vector and 3 channels of Euler angles, with units being either m/s^2 or angular degrees.

The first point to address would be how to distribute these data. One idea is to create an independent stream for each data type, thus redefining a stream as a specific type. However, in my opinion, this could lead to having too many streams when multiple devices are attached. Another way is to actually using the same scheme the GUI uses now, in which streams do not care about the data type but the source. In this case, in the IMU all data is produced by the same device and at the same exact rate (i.e.: they are "fields" of a larger sample structure sent by the device), so all data is packed into the same stream, using the channel metadata to distinguish it, exactly the same as now all data coming from an acquisition board is in a single stream, but channels can be DATA, ADC or AUX. We need to discuss which approach would be preferable here.

The second point would be to expand the data definition behind these three. Instead of a fixed Type enum, I believe we should use the identifier field, an extension of it, or something akin to it, to declare the type. We would define a set of "known" or "official" types for typical data, but any plugin could create their own data type if needed. Downstream processors like the LFP viewer would then list all the data types available in a stream. Eventually, the channel settings could be expanded to include a field indicating the units, and how the bitVolt field relate to this conversion, so all data types could be properly represented.

These are just a couple of thoughts, but this should be the start of a conversation going forward. In summary, the GUI is expanding to support more devices and data types, always constrained to analog continuous data streams (events aside, of course), which could and would include different ranges for neural data (eg. amplifiers for EEG) and I believe a more general approach to data types should be discussed.

[jsiegle]

It's important to make a decision about this soon, because after the v1.0 release it may be a long time before any API-breaking changes are possible.

The main motivation for the continuous channel type is to allow channels within the same stream to be displayed at different ranges. There is already an InputRange field that could be used to track this without relying on the channel type. I think it would also be helpful to add a units field to specify the meaning of the sample values.

So my preference would be to keep the existing channel types, use the InputRange and new units fields to specify what was previously implicit for each channel type, and take advantage of the channel identifier string for more granular type designations. For example, the channels from the IMU would all be AUX, but could be identified as e.g., imu.accelerometer.x.

[aacuevas]

I agree that for now, adding an units field is useful enough and will allow us to see how things develop before the next API-breaking change, as between that and the other fields, we can have enough data to enable a meaningful visualization. That should be the first change before releasing 1.0, and it's a relatively quick one.

We should have some table of ids so the processors can agree of it. This way, for example, the commutator plugin can look for any stream that has quaternion data and use it to turn, whatever its origin is.

[jsiegle]

Not sure how I missed this, but the ContinuousChannel class already has getUnits and setUnits methods. So we would just have to update the LFP Viewer to be able to use this information when available.

[aacuevas]

Nice! So no API update needed, then. We just need to make more extensive use of what it's already there moving forward.