Separate Analog and Digital data streams #133
Conversation
|
This isn't necessarily related to the changes that Brandon made, but I noticed that there are little blips in channels 1, 2, and 3 which are floating that are coincident with falling edges (4V -> 0V) on channel 0 from the signal generator. I assume these blips have to do with the behavior of the ADC when nearby inputs are left floating, but I didn't do any further investigation to confirm this at all besides seeing what would happen if I plug in another waveform in channel 1: |
Behavior seems fine to me. At least for visualization purposes, not sure if it makes sense to have binary events and also a binary plot. However, with that said, I suspect that events can also be used to trigger stimuli and stuff like that. I'm saying this with essentially no knowledge about how events in the GUI are used. Brandon pointed out to me that the LFP plots desync over time. Look at how the yellow lines don't line up after a few minutes of acquiring data: 
I assume this has something to do with how the LFP viewer works, and that is why it has the "Sync Displays" button. |
|
Should these streams be independently disable-able? |
You are correct, the reason why we have both is because we needed the digital data stream to ensure that the timestamps are correct, but the events are a separate entity that other downstream plugins can use for time alignment. So now we have both.
@jsiegle Is this normal / expected behavior for two different data streams with the same sample rate to drift over time? Is there anything we can do in the plugin to mitigate this behavior?
During the discussion in the issue we initially decided to leave the enables tied together. @jonnew should we leave this behavior as-is? It would be fairly trivial to separate them, especially now that the
To confirm, are you talking about the label ("Channel X Direction") and the Enable button / device label at the top? It's a little tricky to align those, and the channel direction labels are actually embedded in a separate UI file that got imported here, so the X/Y positions are sometimes difficult to line up. That being said, it might be worth it to work on this alignment anyway |
|
We discussed loading the data after a longer period of acquiring to make sure we can use the timestamps to align these two streams of data. Moreover, since the LFP viewer seems to desync, to just do a sanity check regarding the number of samples that each stream is plotting |
|
Tested this further by letting acquisition run for thirty minutes before recording any data. During that time, the two LFP viewer windows were definitely misaligned, but hitting Sync immediately lined them up again. Recording the data and then opening it to compare the timestamps and number of samples gave the following data for a 1 minute recording: Analog:
Digital:
The number of samples is off by 300 (equates to ~12 ms of data), the start timestamp is ~0.202 ms apart, and the end timestamp is ~0.257 ms apart. |
|
Did you have the same signal connected to analog and digital inputs? Comparing the timestamps of the rising/falling edges is the best way to confirm synchronization. |
|
@jsiegle yes I had the same input going into both analog and digital inputs. I plotted the analog continuous data with the digital event data below for the first rising edge and the last falling edge of the recorded data to see how the synchronization is holding up. First rising edge: Last falling edge: Based on this, it appears that the digital events are lining up with the analog data. |
|
Some more profiling information from the same recording session. The main takeaway is that I had the wrong information above; the digital/analog data was reversed, and if we compute the average difference between timestamps for the digital data we get a very close approximation to the actual number of samples received, indicating that the Difference between consecutive timestampsAnalog timestamps diff: mean = 3.999999999966555e-05 seconds 
Digital timestamps diff: mean = 4.000799735148302e-05 seconds 
Additional statisticsDigital Number of samples: 1507450 Analog Number of samples: 1507750 |
- Digital data is now saved as a continuous data stream with fourteen channels, and also as an event in the same stream - Remove AuxiliaryIO device and tabs - Adjusted OnixSource.cpp to configure DigitalIO and AnalogIO devices directly instead of through AuxiliaryIO. - Made minor UI adjustments in AnalogIOInterface and DigitalIOInterface for button positioning. - Added TypeString for consistency using strings across files - Added method that calculates the passthrough index from the given hub index - Added private method to check if a passthrough index is valid
Instead of overlaying digital events on analog data, which was prone to offsets due to a lack of timestamp alignment, now the digital data is in its own data stream with 14 channels (8 digital inputs / 6 digital buttons). The events are still present but now they are overlaid on the digital data, ensuring that the timestamps for the events are truly accurate.