Gino,
You should definitely be getting many more values in your buffer. You should actually be getting 500,000 values every second because a measurement is being taken for every pulse. I found a couple knowledgebases that describe error -10920 and how to remedy it. One is pasted below and the other can be found through the link.
But I'm not sure if you're going to be able to fix this problem because you're measuring pulses at a very high rate. What is happening is every time a pulse width measurement is taken it is put into an onboard (DAQ board) FIFO buffer that is 9 samples long. The computer then reads these samples out of the FIFO and into an a buffer that you can see in LabVIEW. I think the FIFO is filling up too fast and the computer is not able to read the data out fast enough. Therefore you are losing samples because they are being overwritten. This is all dependent on your system.
Here are some benchmarks for pulse measurements:
The following numbers were derived from a Gateway with 128 MB-RAM and an Athlon 700 for ONE counter of the PCI-6602. The number of counters you are using will affect these numbers.
Finite Buffer
Buff Period - 7.25 MHz
Buff Pulse Width - 7.25 MHz
Buff Semi-Period - 3.35 MHz
Continuous Buffer
Buff Period - 250 kHz
Buff Pulse Width - 250 kHz
Buff Semi-Period - 140 kHz
You should still be getting many more samples than 26 though. Try using this example with a very slow frequency pulse to make sure it operates correctly. Then start speeding up the pulse and determine when you get error -10920.
Here is an internal knowledgebase that may help you:
Title:
After Long Periods of Acquisition with AI and Counters, a -10920 Error Occurs
Problem:
A customer has a PCI-MIO-16E-4 and his application is acquiring analog input signals and performing event counting with the buffered event counting mode. The problem is that the buffered event counting is at some arbitrary amount of time (e.g., after 2 days) getting an error with the number -10920. The questions are:
1. Why is he getting this error?
2. Do you know how big the FIFO is for this buffered event counting?
3. When he shares a DMA channel with the floppy controller, how can we make sure they use separate DMA channels?
Solution :
Here are the answers to the above questions:
1. There is probably just some noise on the signal line coming in at some point. The STC is VERY sensitive, so if there is any fast glitching, it will attempt to transfer all of these. This can also happen if the signal does not ramp up fast enough, resulting in double-triggering in the middle region. Use a filter, or a Schmidt trigger*, to clean up the signals. Another suggestion is to use the PCI-6602 with filtering.
2. There is no FIFO used for the counters. The mMite has its own FIFO, but it is only about 9 samples long.
3. PCI does not "share" DMA channels. It may technically be the same DMA channel number, but this is just for reference. PCI cards use Bus Mastering. With Bus Mastering, the operating system gives up control of the PCI bus so that the hardware (in this case, our DAQ board) can handle its own data streaming, eliminating the extra step of having the OS monitor the transfers. The DMA channel numbers are just the "channels" that are supported by the mMite chip. You can have 3 PCI cards in the PC, each with DMA 1, 2, 3, and none of them will actually be sharing any resources.
And another knowledgebase about error -10920
http://digital.ni.com/public.nsf/websearch/8FB9091CB9BB452B8525642000554799?OpenDocument
Hopefully this all helps,
Erick D.
NI Applications Engineer
