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.


Photo

U3 stops occasionally sending data during consecutive AIN read calls?

U3 apple matlab AIN input exodriver

  • Please log in to reply
2 replies to this topic

#1 chr1s

chr1s
  • Members
  • 2 posts

Posted 26 March 2015 - 08:55 AM

I am new to the forum, so greetings to all of you out here. :)

 

I received my Labjack U3 (v1.30 / newest exodriver) a few weeks ago and I am very happy with it. Being not an engineer or physicist I expected it to be much harder to convince it to work but in fact with the help of the great forum and the U3 user guide I managed to get where I wanted it to be. :)

 

Well, almost. My problem is a quite special one, I am afraid, because I have to communicate with the U3 via Mac (newest Macbook, USB3) and MatLab (2014b). This is unfortunately non-negotiable. :(

 

Anyway, using exodriver/calllib from within Matlab and a derivative of the feedback(AIN, IOType1) low level function from mhopeng’s U6 Matlab class, I can scan the analog input on AIN0 in a for-loop with a interscan delay of about 1 ms. This delay is comparable to what you write in the user guide 3.1. (I use Matlabs software timing), so that’s cool.

 

Everything looks fine, no errorcodes, checksums seem valid etc. I see my periodic signal on the Mac screen the same way I can see it on my oscilloscope. It seems to have the right voltage values (after calibration) and the timing is also like it should be.

 

Well, almost.

Without any obvious pattern I observe sometimes (maybe every 10000 to 20000 runs inside the loop, i.e. 10-20s) that a single difference between the timestamps of consecutive samples taken from AIN0 is unusually long (up to 250ms instead of 1ms). During this time existent signal data is either not acquired or not sent to the mac. I know the data exists because I verified that with my oscilloscope (so it is at least being sent from the source to the U3). The software timestamps are still valid and the data's temporal integrity is thus intact but missing data would seriously screw up the post-processing of my signal (like finding peaks; missing data for 250ms is not good when your signal is at around 4Hz). btw, pausing the for-loop from within Matlab for 10ms to give the U3 some time between write/read calls also does not help.

 

I know it’s not much to go on and I apologize for that. But do you guys happen to know of any circumstance where the U3 would just shut down for a while, takes ages to process write/read just to continue after 100-250ms at the normal rate without giving any errorcodes? For instance if an internal buffer overflows or whatever… 

i know it could also be on the other (mac) end or in between (usb) but just wanted to make sure its not the U3 because reading an analog signal is not supposed to be that difficult for it, right? I wonder what i do wrong....

 

Kind of desperate here after what was otherwise a nice experience. please let me know if you need more info on what i do, like the matlab code etc.

 

thanks for the good work, i already learned a lot. :)

chris



#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 26 March 2015 - 04:04 PM

That large delay is probably caused by USB or MATLAB overhead. The U3 hardware is consistent with operations time-wise, and an analog input read should not reach 250 ms. You can cause delays in the Feedback response, but you would need to use the wait IO types:

 

http://labjack.com/s...s-guide/5.2.5.2

http://labjack.com/s...s-guide/5.2.5.3

 

If a problem does occurs in the U3 hardware/firmware it can reset itself, but that takes longer than 250 ms. Also, in the case of a reset you'll probably lose your U3's USB handle and see an error.

 

If you are unsure exactly where in your code this 250 ms delay is occurring, you could use the tic and toc functions to time chunks of code. Also, if you are using large arrays try preallocating them to help performance. Here's a "Techniques for Improving Performance" MATLAB page which discusses this:

 

http://www.mathworks...erformance.html

 

As for USB try a different port on your Mac if it has one or a different USB cable, and see if that makes a difference.

 

Last, if you can't resolve the 250 ms delay you could look into using stream mode. It performs U3 hardware timed sampling and you read the buffered data from the U3. So the software delay will not affect sample times. Here's the general stream mode documentation:

 

http://labjack.com/s...users-guide/3.2

 

Here's the C example (we do not have a MATLAB example for the Exodriver):

 

https://github.com/l...s/U3/u3Stream.c

 

Here's the stream low-level functions documentation:

 

http://labjack.com/s...rs-guide/5.2.10

http://labjack.com/s...rs-guide/5.2.11

http://labjack.com/s...rs-guide/5.2.12

http://labjack.com/s...rs-guide/5.2.13



#3 chr1s

chr1s
  • Members
  • 2 posts

Posted 30 March 2015 - 03:01 AM

the U3 itself was indeed not the problem and the solution quite easy.

i found the culprit to be one of the USB ports on my mac.  after changing to another one, i dont see any delays above 5ms anymore, with which i can live given my signals properties. this solves my immediate needs. :)

 

thanks for the fast answer, i appreciate it.

c





Also tagged with one or more of these keywords: U3 apple matlab AIN input, exodriver

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users