06-12-2012 06:27 AM
I am currently trying to measure the the output from a 10 channel hydrophone array at 500kS/s. I thought an easy way to do this would be using one of our USB 6356 daq cards synchronised with a USB 6351 (I've connected between both PF1 terminals).
Our data acquisition is performed through a java third party piece of software (www.pamguard.org) which supports synchronisation between NI daq devices- I have used it before successfully with two USB 6251 cards. However when I try with the current two x-series devices an error is thrown up.
NIDaq Error DAQmxExportSignal Can't configure DAQmx_Val_AIConvertClock to PFI1 c
ode -200375 Signal type requested to be exported is not supported for the specif
ied task running on the given device.
I've looked at the documentation but can't find a satisfactory answer as to whether it is definitely possible to sync these two daq cards.
So my questions are.
1) Is it possible to use these two daq cards to record 10 channels of data at 500kS/s with synchronised clocks.
2) If so, could there an issue with the the library we use in our software libjninidaqmx.so, or am I doing something else wrong?
Thanks for any help.
Solved! Go to Solution.
06-13-2012 11:35 AM
So in answer to your questions,
The 6351 can only sample at up to 1MHz aggregate, this means that you can only have 2 channels on that card. This leave you to use all 8 channels on your 6356 to obtain all your required channels.
One thing I would worry about this is the amount of bandwidth you have over your USB connection to get this amount of data off your card (I assume you want to perform a continuous acquisition). I think it should theoretically be possible but it does depend on your system - generally I would have to test to know for sure. It may require a few software tweaks which I don't know if your Pamguard software is capable of (http://digital.ni.com/public.nsf/allkb/B7B47F50F98
All that said, it should be possible to synchronize these 2 devices - I have mocked up a quick bit of code in LabVIEW which appeared to work with simulated devices. To fully synchronize you will need to use 2 PFI lines, one for the start trigger and one for the clock.
The problem seems to be with your library and the calls it is making to the driver. From the error it is trying to export the DAQmx_Val_AIConvertClock to the PFI line, however this is only valid for M and E Series, for X-Series you are looking to export the DAQmx_Val_SampleClock. (I got this from the NI-DAqmx C Reference help - installed when you install DAqmx) I think the reason is down to the fact that X Series are usually not Multiplexed.
I am not sure how easy it is for you to change that kind of thing for you without extensive knowledge of this software. If you think I can be of any more help please let me know!
I hope this helps.
06-14-2012 04:17 AM - edited 06-14-2012 04:21 AM
Thanks for your detailed reply.
Yes, I agree, the problem is almost certainly with our library and it looks like you've pointed out the solution. I work as one of/closely with the developers of pamguard although I'm not familiar with this part of the code- I should be able to get advice on how to change it.
On the question bandwidth I am awaiting a quad core i7, 8GB laptop. Hopefully this will cope processing wise but we will have to test if we can get that much data through the USB connection(s) using Pamguard (I've tried with six channels at 800kS/s and it all works)- if not we'll either switch to LabvVew or reduce the number of channels used.
I was also curious about your comment on using 2 PFI lines? Previously with M series devices we only connected the PF1 terminals. This would give us synchronised samples which we saved to multi channel .wav files (file names are encoded with the file start time to the nearest ms). Are x-series devices somehow different and what exactly do you mean by 'fully synchronised'?
06-14-2012 05:05 AM
Sounds like you should be ok - make sure your careful about which USB ports you plug into - make sure you are not sharing the bus!
So for 2 tasks to provide completely synchronous measurements they must share both their sample clocks and start triggers. If you don't share the start trigger - the 2 data streams are likely to be offset from each other by a few samples. You need to ensure they both start on the same rising edge of the sample clock, otherwise one task will start return samples before the other and you will not know where the samples match up. Obviously this can be avoided if you know that both tasks have 'started' but no rising edges of the sample clock have yet occurred - you are not in this situation though as the route is performed before the task start.
This is why I think you need two connections. One to share the clock and the other to route the start trigger from one device to the other. (The device can provide this trigger, you don't need to provide it yourself - although you can). What you do is ensure the slave task starts first which then waits for the trigger from the other device so they then both start simultaneously.
Hopefully this is clear,
Here are a couple pages you might find useful though they are quite LabVIEW specific: