Precision in recording events

[praneethnamburi]

Hi, I was wondering what the precision of recorded events are. Are they accurate to a few hundred microseconds?

I am using the open-ephys system for "phototagging" cells, and I'm sending triggers for pulse trains using an arduino. I'm bifurcating the arduino output between a laser and channel 8 of the HDMI break-out I/O board in the open-ephys system. After I analyze my data, I'm finding cells that respond to light 'before' the light. Here is an example raster - the X-axis is in seconds.

I have recorded from this animal on a different day, and all the phototagged cells are firing after the onset of the light. Here is an example -

I was wondering what could cause small shifts in registering events, on the order of a few ms.

What is the guaranteed precision while recording events?

If this value is greater than 1 ms, would it be more reliable (if even possible) to add a "channel" to the acquisition which just samples a TTL input along with the ePhys channels coming from an Intan headstage? If so, is there a resource available that can guide us in this direction?

[aacuevas]

That's weird. The hardware does sample the TTL inputs at the same frequency as the neural channels (so the uncertainty on the edges is 1/fs, which equals 33us for 33KHz) with the delay added by the external circuitry being in the order of 6ns. Definitely nothing near what you're seeing.

How are you splitting the digital signal? Try feeding the TTL signal into the analog input (which is also sampled at the same rate as the ephys channels) instead of the digital one to check that your digital impulse isn't being deformed by some cable mismatch, causing wrong activations.

[chriswin2015]

Personally I would use multiple signals in the terminal so it is modulated
then you will have more channels that you can compare and tap into. I
manufacture proton diodes that work very well for modulation. They are very
affordable.

On Wednesday, July 15, 2015, Aarón Cuevas López notifications@github.com
wrote:

That's weird. The hardware does sample the TTL inputs at the same
frequency as the neural channels (so the uncertainty on the edges is 1/fs,
which equals 33us for 33KHz) with the delay added by the external circuitry
being in the order of 6ns. Definitely nothing near what you're seeing.

How are you splitting the digital signal? Try feeding the TTL signal into
the analog input (which is also sampled at the same rate as the ephys
channels) instead of the digital one to check that your digital impulse
isn't being deformed by some cable mismatch, causing wrong activations.

—
Reply to this email directly or view it on GitHub
#302 (comment).

[praneethnamburi]

Thanks Aaron. I plugged my input into the analog channel, and that seems to have fixed the offset issue.

Chris, I'm not sure I understand the solution you are proposing. I'd appreciate it if you can explain it in more layman terms.

[galenlynch]

I'm curious, did you try plugging the TTL into both the analog and digital channels, to see if the issue is "real"? It seems like that would be a more direct way of detecting a latency problem, rather than looking at neural responses to the TTL triggered photstim.

[praneethnamburi]

I haven't done this test yet. I've been having another problem with the digital triggers (although there is nothing plugged into the Digital IN, I've switched over to analog triggers). The software starts registering spurious digital triggers, SO many that it causes the software and computer to crash. And the continuous.events file gets to be ~100 MB about 5 minutes after this starts. Any thoughts on how to ignore the digital IN would be greatly appreciated. I haven't been able to pin point anything specific that is triggering this phenomenon.

[galenlynch]

Does explicitly grounding the digital IN ports (e.g. with a HDMI breakout board and BNC terminators) solve the problem? Seems like you'd want to figure out if it's hardware or software before proceeding.

[jvoigts]

If you're getting very high rates of spurious triggers, this indicates a hardware issue.
Either you have noise coming into the level converter (that converts the 5V level logic to 3.3V that the FPGA can handle) from a very long cable etc, or maybe there's an issue with the pulldown resistors that usually keep the level at 0 unless voltage is applied. As galen said, grounding the inputs would be a good first test.

[arnefmeyer]

I have a similar problem when I try to align analog inputs, TTL pulses, and signals from the headstage. Thus, I connected two output channels of my RME soundcard to the digital and analog inputs of the board and played the same 10ms pulses on both channels. Aligning TTL pulses and the analog signal using the 'start_time' attribute in the kwd file resulted in a constant offset (left panel; solid blue line: analog signal; dashed black line: TTL trigger; 120 pulses). Note that the soundcard outputs are not dc coupled and therefore only the pulse onsets and offsets appear in the TTL-triggered analog signal. Using the time sample of the software time event ("Software time: xxx@1000000Hz") in the kwe file as reference the TTL pulses and the analog signal were nicely aligned (right panel).

As I understand TTL, analog and headstage signals are using the same sample clock. Is there a simple and reliable way to align all three signals for the HDF5 format? When using the original OE file format the alignment is correct.

[arnefmeyer]

OK, it seems that the processor starting event time is what I was looking for. In this case, the maximum jitter is about 0.033 ms -- this corresponds to one sample at 30000 Hz sampling frequency and is almost two orders smaller than what Praneeth observed.

[aacuevas]

Just to be clear.
Arne: using the "Processor start time" as reference, the analog and TTL signals get properly aligned, right? there is a known delay between that one and the start_time attribute. I'll probably modify the kwd format so it also stores a timestamp array so it's easier to align data.

Praneeth: Have you solved anything grounding the TTL inputs?

[praneethnamburi]

Hi Aaron,
I'm not using the digital inputs anymore. I'm using the analog inputs to get my TTL pulses, and I haven't noticed any errors so far.

[praneethnamburi]

However, during some recording sessions, sometimes I start getting spurious event triggers, even if I don't use the digital inputs. I don't think this is a grounding issue, because if I stop the recording, and press the play button again, everything works just fine. Hope this helps in suggesting that this may not be a hardware issue.

[arnefmeyer]

Yep, using the "Processor start time" event everything works as expected. Adding the processor timestamps (and ideally also the node IDs) as arrays would be great.

Praneeth: How do the spurious events look like? Some time ago I did behavioral recordings without headstage and got some kind of TTL avalanches at random time points during the experiment. After stopping and restarting the recording everything worked fine (at least for some time). However, after connecting the headstage the problem was completely gone.