Max sample rate with NI 9205 - Problems

[subir]

Dear Friends, 

i am developing a lv project, that makes and controls an engine dyno system. Hardware is CRio 9022 with other cards and also 9205 for the AI. There is an angle encoder attached to engine shaft with 3600 devisions per revolution, and also an index to indicate completion of one revolution. the encoder output is measured by card 9411. The engine speed is 1500 RPM. I have to measure the pressure data and torque data when i recieve a 'tick' from the rotary encoder. this means my sampling rate for pressure and torque each is 90K/sec.

but i have not been successful in implementing this. The program is large and i can show them, but i feel there is a problem in the hardware selection for the task. Along with pressure and torque data from the 9205, i also measure the other channels for temperatures and mass flow controller outputs. Thus in all i am using 8 channels of the 32 available. But only the pressure and torque are aquired at sample rate governed by rotary encoder. the rest are aquired about 5 times a second.

Since the 9025 is a multiplexing ADC, the sample rate 250K is devided into the number of channels being accessed = 250K/8 = 31K samples/channel. With this observation i decided to acquire the data of pressure and torque with every 3rd tick from the rotary encoder, basically sampling at 30K samples/sec. However i see a great amount of noise.

So i decide to average the cycles over 1 second (so the engine rotates at about 25 cycles/sec, i average over this number). The resulting pressure and torque graphs do not match with those measured by an oscilloscope in terms of amplitude but the frequency and shape is correct.

I notice an interesting feature in the graphs. When i switch of interpolation between the points, i see many curves made by points instead of a continious locus of points. Thus i conclude that the aquisition is slower than required, and so there are less number of points being sampled than required. these points are un-synchronized over the 25 cycles which i average and hence the seperate 'curves'. this is due to the possibility that some points repeatedly recieve higher number of 'contributions' (while adding), than neighbouring points.

so i conculde that the 9205 is not fast enough to do the job. also the noise maybe due to crosstalk or gosting when the mux changes channels. the impedences of the pressure and torque outputs are in the range of 10 K ohms.

the outline of Labview code: Well there is an FPGA vi, that takes ticks from rotary encoder, and sends a signal when every 3rd tick occurs. The signal contains of a 16bit integer, indicating the tick number. this signal is sent to a 1 element FIFO. This fifo is read in a parallel while loop, where it keeps waiting for a new element. The while loop reads the fifo when data is available, takes a measurement from pressure channel. A memory method node is called to provide data according contained in index number equal to the fifo signal tick number. Then it adds the current pressure reading to the reading from memory, and stores the sum in the same memory location.  thus an array of 1200 elements is formed, where each elemnt is a sum of values taken over 25 cycles. Then this memory is transferd to a dma fifo and read on the host side. same is done for torque measrement. on the host side the fifo is read and devided by 25 to get average. this average is displayed on a waveform graph.

please check the attached file to get an idea of the problem. Sorry for the lengthy post.

Please suggest if you understand the problem, and have suggesstions or solutions.

[christian_w]

When your encoder triggers a measurement each 3rd tick (~33µs) you have not enough time for sampling 8AI's from your NI9205 module. I think the default integration time is 8µs per channel. Try to set the 'Minimum time between conversions' to 4µs using the modules properties in your project. In addition you should use pipelining for your AI's to process the AD conversion and the code in parallel.

Hope it helps

Christian

[subir]

thanks for the reply.

yes i could use 4 micros instead of 8, but NI doesnt gaurantee the accuracy of the measurements below 8 musec. also, sorry if i have been mistaken, 8 AIs are not read simultaneously, but only 2. The rest are taken at sample rate of 5 samples /second. the 2 that re really critical to the problem, pressure and torque are to be taken at atleast 30 KHz each.

i tried to use pipelining and all loops are parallel. but i doubt if the multiplexer is fast enough.

also i built a small program to see the max sampling rates. in one while loop i put a for loop, with 2 AIs from 9205. the for loop will make the 9205 take 90K samples. there is also a tick counter to count the ticks required to complete the for loop. no inputs are connected to the AIs.

in the same vi, there is another while loop with 8 other AIs, sampled at 5 samples/sec. these 2 loops run parallel.

i placed the tick counter indicator on a waveform chart and monitored it. the clock speed is 40MHz. but the graph showes that it takes 57M ticks to complete the for loop, meaning it takes more than a second to complete the sampling. 

this says that the 9205 is not able to match the requirements. there are no calculations, no storage of information, yet it is not able to match the rates. i tried with 4 musec, and it takes 29.35 M ticks to complete the operation. but im not sure if the data which it will generate will be OK. but thanks for the suggestion, atleast its managable i think. but the crosstalk issue is still quiet a big problem, forget accuracy of the measurements. 

thanksm but looking for more ideas.

Regards

[ThiCop]

Hello Subir,

Is this forum post related to the e-mail you recently sent to us?

If yes, then please also share the benchmarking code you made with us (through mail preferably), but of course you can also post it over here.

Thanks in advance!

[christian_w]

crosstalk issue:

If you use the NI9205 inputs in differential mode check the connection of the modules COM pin to the ground of your unit under test. I suggest to short unused inputs too.

Christian

[subir]

Yes sir, this post is the same as the question i sent to NI direclty and got an answer from you. thanks 🙂

Let me first restate the end application:

Well the end application is a test bench system, containing a modified diesel engine, being turned by an electric motor. the operation is also reversed when the engine produces more power than the electric motor. various fuels will be used and the performance will be measured by the pressure curve obtained inside the engine cylinder. this pressure curve must be sampled precisely according to the degree of rotation of the engine crank shaft. There is a rotary encoder containing 3600 marks per revolution. It gives a 0 or 5 V output, that is sensed by NI 9411. The pressure and torque must be sensed precisely at each rising edge of the encoder output, and recorded. and this is the challenge.

now the speed of the engine and motor is 1500 RPM. this boils down to 90 K samples per second for pressure. However torque can be sensed independently and acquired at 30 K samples/second. the rest of analogue aquisition can be done twice a second as they are not critical but important.

i am attaching the benchmarking fpga code here:

As you can see this is the simplest test possible, and in this the FPGA takes 57 M clock cycles to complete 90K samples. I even increased the FPGA clock to 80 MHz from 40MHz, and yet this number of 57 MClock cycles has not changed. this indicates the bottelneck lies with the 9205 hardware due to multiplexing.

If 'time between conversions' is reduced to 4 micro sec, as suggested by christian_W, the same benchmarking takes 14.5 Mega cycles to complete! this is great improvement. I am not sure if this will also improve my real code's performance.

In your reply you also mentioned that 4 micro sec is OK to be used, but can you explain why it is 8 microsecond by default? is there an accuracy benifit?

I quote your mail here to answer the questions better:

Do you exactly need 90 kS/s or would 83.333 kS/s (=250/3) also fulfill your
needs?
This would improve performance of the code and also simplify the example.

If you would absolutely need 90 kS/s, can you provide me with how much
jitter can maximally be on the sample clock?
Should the samples be taken at equidistant time points?
If yes, how much deviation can be on this?

my answers:

Ye i would require the 90 K samples/sec, atleast for pressure. For torque measurements i can use 30 K samples per second. and for the other measurements i can use 2 samples per sec scan rate.So in all there are three sampling rates.

No the sampling points are not equidistant in time, since the engine RPM varies throughout the cycle and so does the frequency of encoder output. I am not sure how much difference would occur between the encoder outputs(and hence the samples). this is due to the experimental nature of the work. A good estimate would be twice the origianl, i.e. 180 Khz. Just a distant guess.

One last question: suppose i want to read only one of the 32 channels, will this reading also scan all the other channels? in other words, is the scanning of channels in NI 9205 sequential starting form channel 0 upto channel 31. 

thanks 

Subir

[subir]

dear christian_w,

thats an interesting solution, can you explain how it will help the aquisition speed? maybe it will help in reducing noise only. just guessing, but will try it out for the sake of noise in my inputs..

regards,

Subir

[subir]

With regards to this discussion i found the following article that is also a contributing factor to my problems:

http://digital.ni.com/public.nsf/allkb/31BD009EE156E6BC8625753B000478A2

regards,

Subir

[ThiCop]

Hello Subir,

I'm back at the office now.

Are there any changes since last week?

[subir]

dear Sir,

i have just recieved a new 9215 card, for simultaneous aquisition. will do some testing this week and update the post.

am using a second computer to generate signals with NI Daqpad 6016 ( haveing some problesm with these too, but its ok).. and then ill simulate the real setup to check the capabilities.

more updates, soon

thanks and regards,

Subir