Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
MR_Riley

Junior Member
Registered:
Posts: 10
Reply with quote  #1 
I've run into an interesting problem in regards to the TTL pulse output for eventmarkers.

Sometimes when we send an eventmarker/behavioral code to our Neuralynx hardware it registers as two events. When I looked at which bits were “active” in the second event, they were always the odd-numbered bits from the previous signal. Upon testing the bits' output with our digital oscilloscope, I noticed that sometimes the odd-numbered bit begin signaling before the even-numbered bit and thus the signal is sent longer. However, when I tested the channels via the button on the I/O part of the GUI, there was no such pattern/effect. This pattern is only whenever the program sends the information during the trials.

I'm curious if anyone else has run into this issue when sending behavioral events and what they were able to do to resolve it. Since I know it's only affecting the odd-numbered bits, I can choose numbers from even number bits or what numbers are likely to have repeated odd-numbered bits to exclude from analysis, but I'd like to see if this could be fixed first.

The attached images are from the strobe test (left) and eventmarker (right) for comparison.

Attached Images
png Strobe test example.png (776.23 KB, 5 views)
png Eventmarker example.png (888.92 KB, 5 views)

0
Jaewon

Administrator
Registered:
Posts: 971
Reply with quote  #2 
Do you know whether your Neuralynx hardware reads eventmarkers on rising edges or falling edges? And did you set up the Strobe option of NIMH ML accordingly?

Your oscilloscope test is inconclusive. First, your trigger level is zero, which is the same as the base line of CH1, so you are not picking up the pulses at the right moment. Second, the duration of the afterimages is pretty long in your oscilloscope, but the intervals between eventmakers are too short. In addition, the first binary digit of the eventmarkers you sent out was all 1, while the second digit alternated between 0 and 1.

I suggest: 1) change the Strobe option to the opposite of your current setting (rising to falling; or falling to rising) and see if you still get two events. 2) For your oscilloscope test, use a fixed number and a longer interval, like eventmarker(511); idle(1000); And raise the trigger level to 2 or 3V.
0
MR_Riley

Junior Member
Registered:
Posts: 10
Reply with quote  #3 
The hardware reads markers on rising edges according to documentation, but mostly detects for any change at all. I had previously simply used "send and clear" for the eventmarkers without using any strobe bit, but for the sake of figuring this out, I've experimented heavily with it.

I've been able to use both rising edge and falling edge for detection. Whenever I've tested changing eventmarkers without clearing the bits, the hardware detects both the addition of new bits for the second marker and the offset of bits from the first marker. For example, when it's shifting from 675 (0000001010100011) to 18 (0000000000010010), it'll trigger 691 (0000001010110011) between the pulses combining all the active bits. Whenever I attempt to clear the bits, it'll have a similar mid-range activation where there's a number of bits still active (not always odd bits either) during detection.

Since the hardware is sampling at 34 kHz, I tried setting the times in spec to 32.15 us as a way to best match the period from the hardware. This didn't have any effects either. I tried a shorter range or setting one or both to 1 us and the effects still happened. I tested the Matlab digital output using the nidaq digitalio_putvalue function to measure 1000 onsets of 255 and zeroing and saw that most of the time the value was put in 0.15 ms with some spikes increasing the mean to 0.4 ms.

I attempted both the idletime you recommended and a shorter one around 0.5 ms (with the hardware limitation) and still observed that the hardware detected a mid-range change.

I've spoken with the support from that side and we can't do anything other than use the strobe bit detection method for it. On the bright side, we are getting the eventmarker values, so it's not that they're missing, we just have too many changes detected.
0
Jaewon

Administrator
Registered:
Posts: 971
Reply with quote  #4 
If your hardware detects any change, you should fix it first. The purpose of using the strobe bit is to give a tiny bit of time to data bits so that they can be stabilized before being recorded. If your hardware does not read exactly on the strobe bit or reads on both rising and falling edges, nothing in this discussion will be useful.

Some of your words are confusing. You are not talking about change detection in data bits, are you? If your hardware detects changes in data bits, it should be disabled when you use the strobe bit.

Also your cable may be too long. The latency of digital output that you mentioned is way too long. See the following post.
https://forums.monkeylogic.org/post/synchronizing-time-stamps-across-machines-9915483?pid=1308685053

If you understood what the strobe time setting is for, you should have increased it. The T1 and T2 must be longer than the maximum possible latency of your digital output. But again it may be due to your cable, so check your cable length first.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.