Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Frequency divider and sine wave generation

Dear all,

I'd like to ask a short question to

1. receive external TTL clock at 233 kHz through a counter input,

2. divide its frequency by 10

3. and generate a sine wave at 23.3 kHz that is synchronized with the incoming TTL signal.

 

1 and 2 were already done by counting ticks and it is possible to output 23.3 kHz TTL pulse. By using the incoming DI of 233 kHz as a source clock for AO of the step 3, a synchronized sine wave can be generated.

However, it is not smooth at all, I guess because the frequency I want (23.3 kHz) is just 1/10 of the clock frequency (233 kHz).

 

Would you please let me know if there is any other good methods to do this or I may set something wrong in the step 3?

 

Much appreciated for your help.

best regards,

0 Kudos
Message 1 of 6
(3,309 Views)

Hi sugar7,

 

There are many different reasons that your sine wave could look poor based on what you have described. Would you mind attaching your code and detailing what hardware you have available to you?

 

Could you also clarify what you mean by synchronized? Do you need synchronization on the order of seconds? milliseconds? microseconds? There are different ways of achieving each, depending on how much hardware you have and how much code you would like to write.

 

Could you also post a picture of the rough wave that you are seeing?

 

With this information, we'll be able to help debug your system and make a better recommendation as to how you might be able to achieve the requirements you have described.

 

Best,

 

Duncan W.

Applications Engineer

National Instruments

0 Kudos
Message 2 of 6
(3,290 Views)

Hello Duncan,

 

Thank you for your reply.

I use NI PCIe-6363 with attached vi to try to do the processes 1-3.

 

   FrequencyDivider.vi is used to count ticks of an incoming TTL pulse and generate a frequency divided TTL. A picture, DividedTTL.gif shows input and output TTL. An orange pulse train is the input at 262.8 kHz to PFI1 and a blue one is the frequency divided TTL from the counter 0. "Synchronization" means the phase relationship between the orange and blue pulses are same (in this case jittering should be less than microsecond).

 

FrequencyDivider_AO.vi was written based on some ideas in the community forums.

Clock source was set to PFI1. DividedSine1.gif shows the input TTL and an output sine wave from A0. The phases of two are fixed, so synchronization is fine in this method, but the sine waveform is really ugly.

 

I also noticed that the divided frequency should be fed as an input parameter for the sine waveform, but have not implemented it yet.

 

Your ideas and suggestions are highly appreciated.

If you need more input, please let me know.

best regards,

0 Kudos
Message 3 of 6
(3,283 Views)

It sounds like you're doing what you're able, that's just the nature of what you get with only 10 samples per sine wave cycle.  It'll look ragged due to the piecewise-constant nature of AO on most DAQ boards.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 6
(3,275 Views)

I agree with Kevin that your current method will not give you any better resolution. You would need to use a faster clock source to get a cleaner sine wave.

 

It seems that the goal here is to generate a sine wave of 1/10th the frequency of the pulse train that is phase-aligned. I'm not sure exactly what your requirements are in regards to phase error or clock drift, but you could use a separate clock to drive the sine wave output and configure a hardware trigger to start it in phase with the TTL signal. That process could look more-or-less like the following:

 

1. Detect TTL frequency

2. Set frequency of sine wave task to 1/10th TTL frequency

3. Once task is configured, use the TTL signal as a start trigger through a PFI line (similar to now, but as a trigger instead of a clock)

 

This implementation would be susceptible to clock drift over time, since they are not running off the same clock, but I would expect this effect to be negligible in most applications and can be reset periodically during program execution as well. Does this system need to be extremely well phase-aligned or need to run for extended periods of time?

 

-Duncan

0 Kudos
Message 5 of 6
(3,259 Views)

Thank you for your suggestion.

 

In my application, there is no chance to restart the program and synchronization should continue for hours.

I will still try your method and see whether it works or not and come back later.

 

Much appreciated for your kind support.

 

0 Kudos
Message 6 of 6
(3,248 Views)