I am using CDAQ with a NI9229 4 Channel analgoue input card.
I have a sensor that outputs an analogue 5v square wave signal. The pulses are triggered from eithe a north or south pole of a magnet. I have an aluminium wheel with 30 magnets, all magnets are in opposition to each other. when the wheel is rotated the output is a square wave.
My magnet wheel is rotating at 182° per second. Over 360 degrees there is 30 magnets. Thus making the sensor switch 30 times.
The time to revolve the wheel one revolution is 1.978 seconds.
I have set up the NI9229 to the following
- sampling rate is set to 25kS/s So to record the data for one revolution it works out as 49450 bits.
- Have set the trigger levels for recording a hi or lo pulse to 2.7 and 0.7 volts.
50000 samples would be two seconds worth of data which would be more than 360° of rotation of the magnet wheel.
The problem I am having is that my pulse count changes between 30 and 31. But as I am only recording 1 revolution of data there is physically only 30 switches. Do you know why I am getting a change of 30 and 31.
I think I know what the problem is now but don’t know a way around it.
I have attached two screen shots. One shows that the rising edges are counted as 15 and the falling as 16 the other shows both are 15. This is due to where it starts to take data I believe.
For detecting the rising or falling edge I compare the data to 4.0 or 0.5v If its below 0.5 then sends a hi signal and counts 1, if its above 4.0 it sends a hi signal and counts1.
But depending on when it starts taking data the signal is already a falling or rising edge. Comparing one bit of data on a rising edge to see if its below 0.5 will send a hi as it hasn’t started to rise as shown in the first picture.
Is there a better way to count pulses
A better way is to actually detect the transitions. Use a shift register and the Implies function from the boolean palette in addition to your comparisons to the voltage limits.
However, this may not guarantee that the readings will always be 15 and not 16. The fact that the sampling clock and the signal frequency are not precisely synchronized and that the duration of the acquisition is not exactly an integer multiple of the frequency mean that a 1 count fluctuation will sometimes occur.
This is a common and inherent tradeoff in measuring frequency. If you counted for an hour so that you had > 50000 pulses, a 1 count fluctuation would probably be insignificant. But trying to get ~2 readings per second forces you to use very small counts and the 1 count variation is quite noticeable.
Another option might be to measure period and take the reciprocal to get the frequency. Each period is approximately 66 ms. That means that you have about 1648 samples in each period, resulting in a resolution of about 0.6% in the period.
Looking at your application, it sometimes seems to be starting on a rising edge, and sometimes on a falling edge hence why you are getting different counts.
Have you tried using the "Start Digital Edge" function on the DAQmx pallette? You can choose whether to trigger the signal to start on a falling or rising edge at your discretion. You can refer to the following link as a guide.
I hope this works. If you have any more questions, please do not hesitate in asking.
thanks for your reply
I have tried using the edge trigger but i am getting an error please see screenshots added below.
I have choosen to use analogue trigger as the square wave is an analgoue signal being sampled on an analogue card. i have set the trigger to rising edge and level to 3.2V. i dont think the level matters as it switches so quick the DAQ does not record any data or the rising or fallind edge as this happens to fast when sampled at 25ks/s
i am getting an error code
from the next daqmx start vi.
have i made a stupid mistake.
After a bit of research, unfortunately, your NI9229 module does not support this kind of triggering. I believe the 9205 and 9206 module does support analog triggering if this is any help to you.
But to overcome this problem, you can use a case structure to check if a given input has met a threshold and then sample signals when it does. The only problem with this, is that the latency will be higher and it will not work if your application requires tight synchronisation.
If you have any other questions, please do not hesitate in asking.
Thats ok as the CDAQ i am using uses a 9205, 9411 9474, 9229
I will see what i can figure out today and get back to you.