Hi,
I have come to really like the T7 and want to use it for a typical data aquisition application in the lab. We need multichannel high- resolution analog inputs and typically acquire entire parametric scans that are HW triggered from another instrument or a clock source. I therefore wrote a lua script to poll a HW LJ counter and when a trigger is detected the lua script scans the selected AINs, then writes the data to the SD card. The trigger period is 250 ms and if I use LJ.Tick to save time-markers to the file (instead of the measured data) I can look at the time spent in the different parts of the loop. The total loop is about 13ms of acquisition and 237ms of idle. The jitter of the timestamp is about 50us (standard deviation value, 300us peak to peak). This is not great but workable. It would be nice to improve this e.g. with a wait_for_trigger_with_timeout function.
Now for a given setting of resolution index and input range I get pretty much the expected delays as per your datasheet. In the specific test case this amounts to 10 ms. The conversion of the floats to strings (for writting to the SD card) takes about 2ms and the rest is done in the roughly 1-2ms that make up the total acquisition period of 13 ms.
However, every so often the SD card write takes 7-8ms longer and leads to spikes in the acquisition period of up to 21ms. ( I should mention that I use the SD card that came with the LabJack as ordered)
I have the following questions in regard to this problem:
1) I could not find details on the SD card write functionallity and related timing. Is this a buffered write and may this depend on the buffer getting full and requiring a flush to the SD card which is slow?
2) I use the lua throttle at a very high value during AIN conversion and then relax it to 5 during the string conversion and file writting in each cycle. Can you recommend a good global value for the throttle? Could the slow writes be due to some background maintenance routines that take longer when running in the system loop from time to time? I've disabled wireless. Is there a way to disable/dactivate more?
3) The most critical to us is the delay between HW trigger and acquisition of the AIN values. How can we optimize the response time of the lua script for this?
4) I have not looked at other ways to store the acquired data since I assumed that memory would be too limited. Is there a better way to do this e.g. with the FIFO registers? I did not see how to do this since I want to acquire up to 14 channels plus timestamp for several hundred trigger cycles.
5) The string conversion is the most time consuming aside from these slow cycles. Is it possible to write the raw data to the SD card in binary format? Ideally I'd like to directly store a register adress range to the SD card and only convert the values on the host computer (in python) once the data is transferred. The same goes for the timestamps.
6) I've not aligned the lua cycle to any Labjack interval using the LJ.CheckInterval function since I assumed that if the LJ clock is not perfectly synchronous with the trigger that would only make things worse. Is this the right approach?
I've attached some of the measurements that I've discussed above. Basically this prevents us from using faster trigger rates since the slow cycles lead to lost triggers which we cannot tolerate. I'd be greatful for some help with this! In the attached example we can run with a period of 30-40 ms without loosing triggers but actually the ADC would allow us to run with a 15 ms period easily.
Thanks for your help or some pointers in the right direction.
P.S. I've already applied some of the recommended code optimizations such as using lots of locals etc.
Could you clarify your goal for this acquisition? Are you trying to externally trigger the AIN to sample a certain number of times/duration or something else?
https://www.lua.org/pil/21.2.html
You could write a 0 to the POWER_ETHERNET register to disable Ethernet.That is the only other module in our main service loop we would recommend/allow to be turned off.
https://labjack.com/support/datasheets/t-series/communication/stream-mod...
If triggered stream does not work for you, the FIFO buffers in conjunction with a host application would likely be faster for logging than writing to an SD card, if you have sufficient memory. You should not need a buffer that is very large since a host application should be able to consume a sample buffer fairly quickly, perhaps even faster than you are sampling the AIN depending on your AIN settings.