10-21-2009 01:43 PM
Oops! Good catch AK2DM. But yeah, the point still stands that the frequency should still easily pass the filter.
-John
10-21-2009 03:08 PM
Thank you, John, for your reply!
Here are the corresponding setting I used:
Timeout: 10s as default.
Samples to read: I tried 1,10,100.
With 1 sample read, the glitches are more easily seen from the display chart and array indicator, some 20MHz, some 10MHz, some 5MHz, et al, basically one or a few ticks of the timebase. I also tried to use a timebase defined by the pulse train generated by a separate counter, say 10MHz, then I saw glitches of 10MHz, 5MHz, 2.5MHz, and so on. Of course, that is in another vi.
I'll post the code and some snapshots tomorrow when I go to my lab. Also I'll try your suggestion to increase the timeout setting. Maybe I'll have more questions about the programmable filter settings.
Best regards,
LTong
10-22-2009 04:53 AM - edited 10-22-2009 04:56 AM
Hi John and everyone who may kindly concern,
Here I attached snapshots and a vi.
In the vi, I borrowed the low-frequency measurement example and extended it a little. Ctr 2 generates a pulse train as timebase for ctr0 for freq measurement. One can also choose 20MHz or 80MHz as timebase of course. To use this vi, the signal is connected to the gate of ctr 0.
The signal I used for test today is of ~1kHz. From the snapshots, one can see the glitches at 1MHz (user defined timebase) and 20MHz (internal timebase), respectively. With digital filter enabled and1us minwidth, the task errors as I mentioned before: seems no samples are read.This is even the case when I use the example for high freq measurement use 2 ctrs (connect the signal to source of ctr0, of course), pls see the last two shots.
It seems only three attachments are allowed in one post, please see the following reply for the others.
Any suggestions are appreciated!
Best,
LTong
10-22-2009 04:54 AM
10-30-2009 07:56 AM
It seems I made a little mess in getting the time information of the measured frequency...
But I hope the digital filter issue is still under consideration. The noise source is the single/several ticks of the timebase, I'm more sure about it now. So all I need would be a digital filter suppressing the timebase ticks.
I appreciate any suggestions/comments!
BR,
LT
10-31-2009 12:52 AM
If we were worried about noise on the external timebase, it is possible to implement a digital filter here as well:
However, it sounds like you're seeing the same problem using the internal 20 MHz timebase which should be a relateively clean signal so I don't think the problem is noise on your timebase signal. You're noise spikes show at 20 MHz since we are counting a single timebase tick during the digital bouncing. The driver is going to calculate this frequency to be 20 MHz. If we were to count 2 timebase ticks this would be measured as 10 MHz.
I still think the signal might just be noisier than we expect. Would it be possible to acquire it on a high speed oscilloscope to take a look at the characteristics a bit more?
For good measure, I went ahead and verified that the following code works properly for me. Using another counter to generate output pulses to measure, I verified that the filter does indeed block pulses 2.5 us and below (resulting in the timeout error). When generating pulses greater than 5 us I was able to acquire all of my data.
10-31-2009 01:28 AM
11-05-2009 04:18 PM
Hi John,
Thank you very much for your suggestions!
I also tried to apply the digital filter to a task measuring a pulse generated by another counter, it works well! You are right that the noise is from the source of the signal. When output to an oscilloscope, the singal shows strange behavior as shown below.
The TTL signal (~5V high) is hardly observable (not seen in the image, but it exists anyway, very weak) and I could adjust it to display stably. Perhaps because there is no constant frequency, it varies slightly even using a stable light source to the APD. So I couldn't tell how the duty cycle is. However, the baseline stuff is hard to understand. I'm not familiar with the mechanism of APDs, so I don't know if it is normal for APDs or not, and we don't have any new APDs to test. There is a strange wave of ~2MHz (with amplitude of ~50mV). Maybe this is the source of the noise? Anyway what is more strange is that if the digital filter is enabled, no signal is passed no matter how the minwidth is set (even to ns)...
Anyone has any hints?
Thanks a lot!
Best regards,
LT
11-05-2009 07:47 PM - edited 11-05-2009 07:53 PM
Hi LT,
From your quote "The TTL signal (~5V high) is hardly observable", it seems like the 5V signal might be too short to pass through the filter after all (i.e. nowhere near a 50% duty cycle).
We might need to get creative here, do you have any extra counters available? If so, you could generate a single re-triggerable pulse off of the external signal (duplicate edges would be ignored while the pulse was still being generated). If configured in this manner, the frequency of the counter output should be equal to the frequency of your input signal but will not be susceptible to duplicate edges.
You can filter out duplicate edges by changing the pulse width of the signal to be generated.
I don't think the problem is with the baseline noise we are seeing but rather noise that occurs during a high voltage state (or possibly during the transition region).
Best Regards,
John
11-06-2009 02:53 AM
Cool idea! Thanks John!
Actually I was thinking that the duty cycle was too short. The "high" signal is seeable at intense input, say 100kHz, but it is impossible to distinguish single pulses.
I'll try it and come back here as I have anything.
Best regards,
LT