Inconsitent trigger pulse (TTL) durations with firmata device (teensy)

Support
1

Hi Chris,

I need a synchronization between a task controller running MWorks, a multi-camera and a neural data recording systems. I have a trigger device which sends pulses 100 times per second via BNC cables. The cameras take images at incoming pulses and neural data recording system uses the pulses to synchronize its clock too. To synchronize MWorks and the rest of the set-up I thought to use a Teensy board to forward the pulses to MWorks. I flashed the board with the Firmata software (MWorks fork) and I have been able to forward trigger pulses in my MWorks task. However, I have observed that there is a problem with consistency of intra-pulse time by analyzing times of events in a .mwk2 file.

TaskController_trigger_test
TaskController_trigger_test1229×448 15.6 KB

This is a plot of time intervals between consecutive trigger pulses. You can see that the intervals deviate a lot from 10 ms and, surprisingly, most of the deviation are at ±5 ms. Some are at +1 ms and occasionally there are even bigger jumps. MWorks was configured to sample every millisecond from the Firmata device. I would be okay with ±1 ms jumps and few occasional max. ± 3ms jumps to be sure that the system is reliable.

Camera_trigger_test
Camera_trigger_test1277×448 111 KB

I have verified that the trigger device is working properly and other devices record pulses reliably. Above is the plot from camera-recording system, which shows that pulses are send and received consistently without any jumps.

Interestingly, non pulses were lost by the Firmata device, even though the inter-pulse times are sometimes multiples of 10 ms. It looks like the system compensates for over-due pulses with early pulses.

I have tried using different BNC, USB cables, different versions of Teensy (LC and 3.6), but nothing changes the behavior from the first plot. I assume that the problem might originate from how the Firmata device works.

Would you have an idea how to solve the issue? Is there maybe another way to pass trigger pulses to MWorks with lower latency?

Best, Vladyslav

2

Hi Vladyslav,

I’m not sure what to make of the apparent 5ms quantization of the pulses.

You’re using a digital input to receive the pulses, correct? The Firmata firmware reads and sends updates about digital inputs as quickly as possible, and MWorks is continually receiving messages from the device. There are no built-in waits on either end that would cause messages to “stack up” at 5ms intervals. (Note that the data_interval parameter sets the rate at which the Firmata firmware reads analog inputs. It has no effect on how often digital inputs are checked, and it has no effect at all on the MWorks side.)

The first thing I’d do is make sure that the Arduino IDE is closed when MWorks is running. It doesn’t need to be open unless you’re updating the board’s firmware, and if it is open, it may be interfering with serial communication between the board and MWorks.

Assuming the Arduino IDE isn’t causing the issue, I’d next consider whether something about the Teensy hardware or its supporting firmware libraries is causing this behavior. Do you have a non-Teensy device (e.g. an Arduino board) that you could test with MWorks instead? I don’t know why the Teensy would behave this way, but it would be good to know whether you see this behavior with other boards, too.

As for alternative ways to get the trigger pulses to MWorks: You could try using a LabJack. However, I’d expect the latency to be higher than with a Firmata device, since MWorks must poll the LabJack at a fixed interval to learn about input changes.

I hope that helps!

Cheers,
Chris