Acquiring 4 or more channels with a NIDAQ

Known Issues and Problems with BCI2000
Locked
sinverso
Posts: 8
Joined: 02 Aug 2003, 17:27

Acquiring 4 or more channels with a NIDAQ

Post by sinverso » 29 Jan 2004, 12:32

Hi,

Has anyone acquired 4 or more channels using BCI2000 and
a National Instruments A/D board.

I can acquire 3 channels, but when I try to acquire 4 or more channels a
Time out error occurs in the BCI2000 error window.
After putting the NIDAQ status checks after each NIDAQ
method called in NIADC.cpp, it looks like DAQ_DB_Transfer
is returning the Time out error.

The parameters in BCI2000 I'm using are:
BoardNumber 1
SampleBlockSize 16
SamplingRate 256
SoftwareCh 4

The NIDAQ is a PCMCIA DAQCard-6036E 16 inputs 200kS/s

The other modules used in BCI2000 are Oddball and DummySignalProcessing.

Thanks in advance for any help.

-Sam

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

DAQ Issue

Post by gschalk » 02 Feb 2004, 09:40

Hi Sam,

I've successfully used PCI-MIO-16-1 and PCI-6024E boards. In both cases, I used 16 channels. Have you tried using more than 4 channels? How many channels does the DAQcard support?

Gerv

sinverso
Posts: 8
Joined: 02 Aug 2003, 17:27

Post by sinverso » 10 Feb 2004, 05:32

Hi Gerv,

I have tried using more channels with the same problem resulting. The board supports 16 channels total.
Do you recall the parameters you used to record 16 channels? Was it with BCI2000 or other code?

Thanks for the reply,

-Sam

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

Some ideas ...

Post by gschalk » 10 Feb 2004, 08:28

Hey Sam,

I used the NISource with BCI2000 on a number of occasions - also quite recently.

I could think of two more things:

1) You might have to manually set the referencing mode in NI's Measurement and Automation to 'Single Ended' as opposed to 'Bipolar.' Otherwise, you'll only have 8 instead of the 16 channels. This does not explain why it won't work with 4, but I'd at least check on this.

2) As I think about it, I seem to recall that people at NASA had a problem with BCI2000 when they used some kind of DAQcard. It worked flawlessly with E series boards.

If (1) doesn't help, I would carefully go through the documentation for the DAQcard. Maybe they support only certain combinations of sampling rate, block size, and channel number. I've seen this in devices from other manufacturers.

Keep me posted on the progress,
Gerv

sinverso
Posts: 8
Joined: 02 Aug 2003, 17:27

Seems to be an E series problem

Post by sinverso » 13 Feb 2004, 14:39

Hi Gerv,

It seems the problem is generic to the E series. The 6.9.x driver and library in BCI2000 was released before the E series so DAQ_Rate doesn't take into account that the E series only uses timebases -3 and 2.

It looks like there is a larger problem though; where the E series gets into a weired state where events fire but the half buffer is never filled when the sampling rate frequency is close to a power of 2 and the number of channels acquired from is also a power of 2. e.g. 256Hz and 2, 4, 8, and 16 channels.

I'm writing a work around for this, and talking to National Intruments to verify the problem. I will keep you updated.

Regards,

-Sam

gschalk
Posts: 615
Joined: 28 Jan 2003, 12:37

NISource issue ...

Post by gschalk » 13 Feb 2004, 15:43

Hey Sam,

Please do keep me updated. It would be great if we could incorporate the updated version of NISource into BCI2000. It is interesting that I have never seen this problem before, though.

I do know that the NIDAQ manual states something about a FIFO buffer. We've had some problems with DT boards and the FIFO on the board. These problems might be somehow related.

Gerv

sinverso
Posts: 8
Joined: 02 Aug 2003, 17:27

Post by sinverso » 30 Mar 2004, 09:25

After working with an NI engineer it looks like the problem is with the NIDAQCard. The PCMCIA bus uses IRQs to transfer data between the card and memory, while PCI uses DMA, which is much faster.

Because of this, NI PCMCIA cards need to transfer larger blocks of data than PCI cards to achieve the same effective sampling rates. For example, the PCMCIA 6036E we are using can only transfer blocks of 81 samples or larger, while the PCI cards can transfer blocks as small as 1 sample.

Needing to transfer large sample blocks is a problem because BCI2000 timing is done in units of sample blocks. One solution NI suggested, but I haven't explored, was to break up the blocks in software.

We are exchanging the PCMICIA card for a NI PCI 6024E, as this the most straight forward solution.

Regarding my previous post about not using DAQ_Rate for E series
cards because it returns the wrong timebase. I've verified it still
returns the wrong timebase in the the 7.1 drivers. I have written
a DAQ_Rate function for the E series, I'll merge it with the current BCI2000 NIDAQ driver after testing it.

If you need a working DAQ_Rate function for the E series now,
email me and I'll send you the code: sam.inverso (at) medialabeurope.org

Thanks for everyone’s help.

-Sam

mellinger
Posts: 1052
Joined: 12 Feb 2003, 11:06

Post by mellinger » 07 Jun 2004, 08:29

Because of this, NI PCMCIA cards need to transfer larger blocks of data than PCI cards to achieve the same effective sampling rates. For example, the PCMCIA 6036E we are using can only transfer blocks of 81 samples or larger, while the PCI cards can transfer blocks as small as 1 sample.

Needing to transfer large sample blocks is a problem because BCI2000 timing is done in units of sample blocks. One solution NI suggested, but I haven't explored, was to break up the blocks in software.
I'd suggest to use a hardware sampling rate that is a multiple of the actually desired sampling rate. Choose the hardware sampling rate such that the card's data buffer gets filled quickly enough, and that data are transferred in the intervals you desire. For EEG purposes, where sampling rates are typically much lower than what AD hardware can deliver, this should always be possible.
Then, in the source module, take every n-th sample, and ignore the others. This style of operation is adopted by the DAS source module, and it works fine there.

"Breaking up blocks in software", in comparison, has two disadvantages: It introduces a separate time base to determine when the sub-blocks will be released, with synchronization/interference problems, and it doesn't remove the considerable delay resulting from infrequent card IRQs.

Locked

Who is online

Users browsing this forum: No registered users and 1 guest