Code for acquireBoard and releaseBoard in Mac OS X

[JGF]

Hello,

First of all, apologies if this has been covered elsewhere. I am new to all this and my searches have either proved fruitless or have confused me further!

Due to limitations in DAQmx Base, I would like to utilise the DDK for DMA access to the buffer on a PCI-6251 board. As I understand it, the two important OS dependent functions that need to be tailored for Mac OS X are acquireBoard and releaseBoard in osiUserCode.cpp.

I was wondering, is OS X specific code for these functions available anywhere, or will it be necessary for me to attempt them myself?

It was mentioned in an older thread that the code is available somewhere in VISA, and therefore nothing should need to be rewritten. I have the latest version of VISA installed, but have had no luck finding this code. I'm pretty confused about how the DDK and VISA relate to each other to be perfectly honest.

I'd be very grateful if someone could try to shed some light on all this for me!

Kind regards,
Jon

[Tom_W_[DE]]

Hi Jon-

O/S interfaces for NI-VISA (and many others) are provided with the MHDDK.  You should be able to install NI-VISA for Mac OSX and then use the M Series MHDDK examples and the osinterface files ( ftp://ftp.ni.com/support/daq/mhddk/osinterface/nimhddk_visa.zip  ) without additional modifications.

That aside, I would be interested to hear more about the issues you saw with NI-DAQmx Base.  The preferred solution would be to find a workaround or some tips to help use NI-DAQmx Base rather than go to the trouble of developing your own driver.  What issues specifically are you seeing?

Thanks-

Message Edited by Tom W [DE] on 04-10-2007 04:00 PM

[JGF]

Hi Tom, thanks for replying.

I managed to download the osinterface files you provided the link for shortly after I posted yesterday, and I have had a little more luck with them. I will work on it today. It is not obvious from the MHDDK download page that these osinterface files are suitable for Mac OS X, as only Windows platforms are listed with their link. I orginially downloaded the files through the 'Other' link, and these do not contain implementations of acquireBoard and releaseBoard.

Regarding NI-DAQmx Base, the issue we've found, which has been mentioned a couple of times on these forums before, relates to functionality of the ReadAnalogF64 function. We are performing psychophysical experiments and recording neurophysiological activity. We need to be able to read all samples from the buffer up to and including the latest sample, allowing us to time stamp the latest sample accurately, and then all the previous samples in relation to this. Basically, we need to be sure that we can match our data exactly to the timing of our stimulus presentations. As ReadAnalogF64 requires the number of samples to read to be specified each time, and will wait until acquiring that number before returning, we would not be confident in our time stamping.

As I said previously, I am relatively new to this area, and the conception of this problem with DAQmx Base is mostly due to a colleague with more experience than myself. If you can suggest a strategy that would allow us to accurately time stamp samples in continuous acquisition, while at the same time taking into account our real-time stimulus presentation overheads (I believe our current OS9 system performs the acquisitions during the video interrupt), then I am certainly open to suggestions.

Kind regards,
Jon

Message Edited by JGF on 04-11-2007 03:17 AM

[Tom_W_[DE]]

Hello Jon-

Your colleague's impression of the inability to query a count of buffered samples with NI-DAQmx Base is correct.  However, this should not affect your ability to accurately timestamp buffered values that are returned by NI-DAQmx Base.

First, let me say that this advice assumes that you are less concerned about being able to grab the most recent sample immediately when the DAQmxBaseRead is called but rather that accuracy in timestamping is more important.  That said, the fact that the DAQ board is using a precise onboard timing signal to buffer the samples should be sufficient to timestamp buffers that are returned by the DAQmx Read.  Assuming you're able to accurately timestamp the starting point or trigger time of the acquisition, you can simply timestamp the values based on the sample period you have chosen. 

One important consideration with this approach- the M Series board uses a 20MHz timebase and a 32-bit counter to generate onboard timing signals.  So, if you request an AI sampling rate of 10005Hz the board will actually sample at 20MHz/2000 = 10kHz.  Aside from this, you should be able to accurately timestamp the values based on the sample period of interest.

Please let me know if I have misunderstood the requirements of your app.  If you do indeed need the ability to grab all available samples "now," then unfortunately your earlier assessment of this issue with NI-DAQmx Base is correct.  Otherwise it may be an attractive option to developing your own driver from scratch.

Hopefully this helps-

[JGF]

Hi Tom,

Your suggestion for time stamping seems reasonable. I think the problem lies in the masses of code that we would have to adapt to this new approach!

Regardless, I have managed to produce a nice driver for reading samples using the DDK and VISA, and using the provided DMA analogue input example as a template. It works well, seens fast, and has the functionality we require.

Thanks again for your advice,
Jon

[JGF]

Actually, I have another query if you don't mind.

To what extent can DAQmx Base and the DDK be used in conjunction with each other? For example, could I use my driver for analogue input and then DAQmx Base for analogue/digital output? Would there be a fundamental conflict, or is there just certain things I should avoid doing?

Thanks,
Jon

[Tom_W_[DE]]

Hi Jon-

That's a tough question.  NI-DAQmx Base and MHDDK are not exlicitly incompatible with one another, but neither makes any guarantees or precautions to avoid clobbering device settings made by the other.  Each "driver" takes steps to reset device settings before operation, so it's very likely that using the two concurrently may result in unexpected behavior.  My recommendation would be to add functionality to your AI driver based on the AO and DIO examples included with the MHDDK. 

Thanks-

[JGF]

Hello again,

I'm having a problem with time stamping, and I'm wondering if it may be due to incorrect settings for the DMA analogue read.

Basically, I'm taking a time stamp (using gettimeofday) immediately after the aiStart command, and then giving all samples a time stamp in relation to this that is derived using the sampling frequency (typical value is 10kHz).

Also, I'm giving each sample a second time stamp which is derived from the time that it is read from the buffer, i.e. I call dma->read(0, NULL, &bytesAvailable) to determine the number of bytes available, take a time stamp, then read that many bytes from the buffer. Every sample is then time stamped in relation to that time stamp, again making use of the sampling frequency.

My problem is that as the acquisition continues, these two time stamps become increasingly out of step with each other. The first time stamp (relative to start) gradually outpaces the second stamp (relative to buffer read), which I'm interpreting to mean that the actual sampling frequency is higher than it should be, i.e. the expected number of samples are being read in a shorter than expected time.

I haven't changed any of the timing settings from the DMA example except the sampleRate and by consequence the samplePeriodDivisor (timebase/sampleRate), where a sampling frequency of 10kHz gives a samplePeriodDivisor of 2000. The other settings that may or not not be important but which I have left unchanged are:

sampleDelayDivisor = 3
covertPeriodDivisor = 280
convertDelayDivisor = 3

I know it may be difficult to diagnose my problem from this information, I'd be very grateful for suggestions as to what might be going wrong!

Many thanks,
Jon

[Tom_W_[DE]]

Hi Jon-

How much does the absolute timestamp seem to lead the relative timestamp by?  How long does it take for the effect to become noticable?

I would suggest that the absolute timestamp would be more reliable than the relative timestamp, simply because the absolute timestamp is based on the DAQ device running independently of the software.  The relative timestamp, on the other hand, could be affected by things like slowing in execution of your software loop or lagging/incorrectness in the system time itself as reported by gettimeofday().

Since 10kHz is an even factor of the 20MHz timebase, the board should be able to operate very reliably (50 ppm accuracy) at the 10kHz sampling rate.  I would be interested to hear the severity of the offset as well as the amount of time it takes to appear.

Thanks-

[JGF]

Hi Tom,

If you can forsee no problem with the accuracy of the sampling frequency then the problem must indeed derive from the software loop or gettimeofday. I will not be able to look at it again until Friday, but I will test a few things and then get back to you.

Thanks again,

Jon