Alternative to NIDAQ for ephys setup

Support
1

Hi Chris,

We would like to hear your advice on how our lab should move on from NIDAQ for ephys set up. We’ve been using PCI-based NIDAQ for syncing, and for the new reward system, We’ve set up Arduino (Uno). Now we need to change the existing system as new mac doesn’t have PCI slots and our python-based task (MOOG) only works in new os x.
Specific questions are as follows:

  1. Do we know the timing accuracy/delay of the Arduino for putting time stamps in ephys data? I wonder if we can rely on this as Arduino is based on USB (although it’s probably okay with reward delivery).
  2. I heard from Mehrdad/Michael that we can go with Lab Jack, which is based on ethernet and so could be better off in terms of timing. Would you recommend this compared to Arduino? Another thing is the number of digital channels supported and Lab jack seems to have more channels.

Best,
Hansem

2

Hi Hansem,

Apologies for the delay in responding.

  1. Do we know the timing accuracy/delay of the Arduino for putting time stamps in ephys data? I wonder if we can rely on this as Arduino is based on USB (although it’s probably okay with reward delivery).

The timing depends on the board you’re using. The Arduino Uno isn’t a great choice, as it’s based on a very old and limited microcontroller chip. The DiCarlo Lab is moving (maybe has moved by now) to using Arduino Nano 33 IoT boards for digital I/O tasks, including juice pump control and sending sync signals to recording hardware. These boards are very capable and use a much more modern and powerful processor than the Uno. They’re even a few dollars cheaper per board.

As for timing: On my M1 iMac, I just ran a TTL out to TTL in test using a Nano 33 IoT. Over 30,000 trials, the elapsed time between MWorks setting the output and registering the input was either 0.4ms or 0.2ms (mostly the former; see attached plot). The values are in steps of 200 microseconds because that’s the “tick” interval of MWorks’ scheduler. While not a real-world test by any means, this does at least show that the inherent I/O latency for these boards is quite low.

  1. I heard from Mehrdad/Michael that we can go with Lab Jack, which is based on ethernet and so could be better off in terms of timing. Would you recommend this compared to Arduino? Another thing is the number of digital channels supported and Lab jack seems to have more channels.

LabJack support is still a work in progress. I hope to get it in to the MWorks nightly build within the next six months or so, but it’s not there yet.

While I haven’t run timing tests with a LabJack device, my expectation is that it wouldn’t be much better than an Arduino with a modern processor, regardless of whether you connect via USB or Ethernet. The main reason you’d want to go with a LabJack is that it’s a “real” DAQ and has many more capabilities than an Arduino board (e.g. high-quality analog input, buffered analog output, counters, quadrature). On the other hand, if you’re mainly driving pumps and sending sync signals, an Arduino should be more than capable (and much cheaper).

I hope this helps! If you have more questions, please don’t hesitate to ask.

Cheers,
Chris

3

Attachment: Figure_1.png (33.5 KB)