TTL freq measurement w/ variable trigger level

[mlang]

I have a TTL signal that I'd like to measure the frequency of, but there's a blip on the front end of the pulse and the default trigger level for a TTL pulse results in an erroneous measurement. This is fixed by changing the trigger level to, say, 2V. The way I did this with traditional DAQ was to setup a continuous analog acquisition, set the trigger level to 2V and route the AI start trigger to RTSI0. A counter period measurement would then find the time interval between pulses on the RTSI0 line. The attached screenshot is how I would think DAQmx would accomplish the identical measurement. However, apparently my PCI-6221 does not accept "Analog Edge" as a trigger start type for the task "AI voltage" (only options, it seems, are Digital Edge or None). The second problem is that it seems that I can't use the RTSI 0 line as the input for a frequency measurement, just ctr0 and ctr1. This is weird as it seems (as with traditional DAQ w/ legacy hardware) that I should be able to measure the frequency of any PFI/RTSI line that I want, but it's perhaps not a show stopper. While I can't test it unless I figure out how to setup the analog trigger and how to route it to the correct signal, I'm guessing this second problem might be fixed by routing the eventual AI trigger signal to PFI8 (usually ctr0 source). In any case, it seems as though DAQmx is being obfuscating in trying to be easy to use in my case.

[mallorim]

Hi mlang,

Your way of getting around the blurb in your TTL signal is quite clever. M-series cards like your 6221 do accept analog triggers. However, the string input for the trigger function is picky and will return errors if the correct format is not entered. For the string input, instead of 0, you would want to enter Dev2/ai0.

The Counter Source Inputs are, by default settings, where you would physically connect the signal you want to find the frequency of. However, by using a DAQmx Channel Property Node, we can find the frequency of any digital line we want. When you place down the property node, you can select the input terminal that the frequency measurement will be taken on as seen in the following screenshot.

I am attaching a modified example program that I believe will perform the retriggering analog input and the frequency measurement of the AI Start Trigger. In this example, my M-series card is named “M-series” instead of “Dev2” and my TTL signal is wired to ai1 instead of ai0.  I hope this helps and good luck on your transition from Traditional DAQ to DAQmx. I find DAQmx a lot easier to use once you become familiar with the flow of the programs.

Mallori M.

Message Edited by mallorim on 01-10-2008 01:36 PM

[mlang]

Ah, the property node is golden. Seems like everything is going property nodes these days. As for the analog trigger, though, everything you say makes sense, but I still get a -200077 "Requested value is not a supported value for this property" (Property: Start.TrigType, YouHave Requested: Analog Edge, You Can Select: Digital Edge, None).

It seems to me there should be at least one example (that works) of analog input where the trigger is a threshold on that analog input (that's what the examples I remember used to be of). But the majority of examples I find either have a very similar flow to your program using the analog trigger and throw that -200077 error (as for the Acq&Graph Voltage-Int Clk-Analog Start w Hyst example), or they use digital lines as a trigger for acquisition. Any reason why I wouldn't be able to select analog trigger for an analog input task?

[mallorim]

Hi mlang,

I want to apologize. While I used an M-series card in my example, after looking at the specifications of your PCI-6221, you are correct that this card does not support analog triggering.

Can I ask if you recently changed cards, or did your PCI-6221 work in your Traditional DAQ application?

Also, can you give me a better description of your TTL signal and the blurb that is causing the difficulties? Does the blurb occur once or is it recurring? If it only occurs once at the beginning of the TTL signal, then you can just perform the regular counter input frequency task and then throw out the first frequency measurement from the data array. The rest of the measurements should be correct.

My other suggestions include finding a way to attenuate the signal so that the blurb was below 0.8 V but the TTL signal was above 2 V. Also, you can look at purchasing a PCI-625x M-series card that supports analog triggering, which is the card I used with the example, or a PCI-654x High Speed DIO card that is expensive but it lets you configure what is considered high and low.

Regards, Mallori M.

[mlang]

The card used in the older setup is a PCI-MIO-16E-1. I thought the 6221 was the current analog of that card (pardon the pun), but I guess it's the little details that end up biting you in the rear.

I don't have the motor spindle to see the exact form of the 'blip', but from what I can recall there were several 'blips' of ringing before the actual motor index pulse which varied in number and size, though all of them usually below 2V.

In the system there's a PCI-5114 high speed DAQ card performing the data acquisition and this card's 'raison d'etre' is essentially just to measure the spindle frequency and to turn a laser on/off, so it probably won't be replaced with something fancier since I already have the 6221 card.

It looks like I'll just have to attenuate the index signal and send it into the Ctr0 input, do a vanilla frequency measurement on it, and hope the blips don't get large enough to mess things up. It was kind of nice to be able to specify the trigger level of an analog acquisition. I guess I'll be looking at specs like those more carefully next NI equipment acquisition.

[mallorim]

Hi mlang,

Something you might want to consider is, if the ringing is guaranteed to have a smaller pulse width than the motor pulse, then you can use a counter task with the channel property node of Minimum Pulse Width.  This can be seen in the following image.

With each rising edge of the signal, the timebase will begin counting, and if the signal drops off before a certain amount of time has passed, that portion of the signal is discarded. Only pulses of a certain duration are passed on to have the frequency measurement taken. However, this will only be effective if your TTL signal has a longer duration then the ringing noise you are seeing.

Other than this, I would suggest finding the cause of the noise and trying to reduce that. Everything we have previously discussed is more of a bandage, instead of addressing the root problem.

Hope this helps, Mallori M.

Message Edited by mallorim on 01-15-2008 04:44 PM