Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Lowest possible digital input latency on FIOx

  • Please log in to reply
1 reply to this topic

#1 chuckb

  • Members
  • 23 posts

Posted 28 December 2012 - 12:09 PM

I've read though various other postings on latency of AIN, DO, etc... I have an application where I need to detect the change of a single digital input as fast as possible, even if it means totally gross inefficiencies :rolleyes: . Some options that occur to me: 1) Stream channel 193 at 50kHz with only 1 sample per packet, and LJ_swNONE retrieval. Yes I know the User's Guide warns about potential Host PC processing limitations, but what are today's limitations on ever-faster machines? 2) Submit multiple BitStateRead commands in Feedback function. How does that compare to 50kHz streaming? If I were to do that, what kind of idle gap time would I suffer between between Feedback calls as compared with the regularity of Streaming? I am concerned about worst-case here. Are there any other best-known methods for minimizing DI latency? Thanks!

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 03 January 2013 - 01:36 PM

With command/response feedback functions, the gap time is going to line up with the times from Section 3.1:


So you could have a typical gap time of 600us, but sometimes you might have a much higher gap if Windows decides to do some other higher priority task.

As for stream with a single scan per packet and read, it might do a little better. I tested with one of our low-latency stream examples for LabVIEW and was able to go as fast as 3000 scans/second. That was actually with a 4-channel scan, so might be able to do even better with a 1-channel scan.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users