Clarification on Trigger Logging
Posted: Tue Jun 17, 2025 2:22 pm
I understand that open-drain connections to the USB2 receiver should begin trials in the all open/low state in order to avoid loosing triggers, and that the trigger levels are recorded as 16 bit binary numbers.
In the case of a microcontroller activating and deactivating open drain outputs in correspondence to physical events, does that mean that every time any bit changes from low to high, say at event onset that a trigger is logged, and its id is the composite of the state of the lines at after the transition ? However when a pin falls a trigger may or may not be logged, and its id could be the id before or after the transition ?
For my own convenience with generating triggers, I envisioned starting all lines as low/open, then switching individual lines to high/closed while a trial is active, while sounds are played and while buttons are pressed - which obviously overlap and interact. Would this risk loosing the triggers at trial, sound and button press offset ? Is it necessary to have brief pulses on different lines to identify onset and offset ?
In the case of a microcontroller activating and deactivating open drain outputs in correspondence to physical events, does that mean that every time any bit changes from low to high, say at event onset that a trigger is logged, and its id is the composite of the state of the lines at after the transition ? However when a pin falls a trigger may or may not be logged, and its id could be the id before or after the transition ?
For my own convenience with generating triggers, I envisioned starting all lines as low/open, then switching individual lines to high/closed while a trial is active, while sounds are played and while buttons are pressed - which obviously overlap and interact. Would this risk loosing the triggers at trial, sound and button press offset ? Is it necessary to have brief pulses on different lines to identify onset and offset ?