Go Down

Topic: Frequency measurement  (Read 661 times) previous topic - next topic

armaanuiet

Sep 11, 2018, 06:06 pm Last Edit: Sep 11, 2018, 06:08 pm by armaanuiet
Hi
I wish to measure duration of frequency, say 9khz, using uno. I have connected the frequency input to pin 8, and used pulseIn function to measure high and low time, inverse of the addition of these two time will lead to frequency. But this take around 4 full  Cycles to Estimate the frequency.
 

Kindly help me with another  faster method.
Further, for example, when I receive 9KHz frequency, I want to make pin 12 high, and as long as I receive 9KHz, pin 12 should be high, other wise low.
And when I receive 11 KHz, make pin 13 high otherwise low.
So two frequencies will be isolated by respective pin, 12 and 13.
Kindly provide me a example code for my problem.


hammy

I doubt anyone will sit down and generate some code for you, but will help with your attempts. suggest you post your code for comment , some indication of the project may help too.

Look at how to use the forum and how to post code.

wvmarle

Kindly help me with another  faster method.
Connect your input signal to pin 2 or 3, then use the external interrupt, measure the time between two RISING (or FALLING) interrupts.

Code: [Select]

volatile uint32_t thisInterrupt, previousInterrupt;
volatile float frequency;
void freqISR() {
  thisInterrupt = micros();
  frequency = 1000000 / (thisInterrupt - previousInterrupt);
  previousInterrupt = thisInterrupt;
}


This calculates the frequency based on a single cycle - two interrupts - and stores it in the variable frequency.

You can get 16x better resolution by using timer2 to count clock cycles (at 9 kHz one cycle takes about 111 µs).
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.

MarkT

#3
Sep 14, 2018, 01:47 pm Last Edit: Sep 14, 2018, 01:47 pm by MarkT
Hold on there, do we know if the input signal is even digital?  If its analog the above
isn't really going to help.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

wvmarle

As long as the waveform goes over 0.7*Vcc once and drops below 0.3*Vcc once in each cycle, the actual waveform doesn't matter. Block, sine, sawtooth, whatever - all will work just fine because the RISING interrupt will fire at the same point of the waveform.
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.

ieee488

Connect your input signal to pin 2 or 3, then use the external interrupt, measure the time between two RISING (or FALLING) interrupts.

Code: [Select]

volatile uint32_t thisInterrupt, previousInterrupt;
volatile float frequency;
void freqISR() {
  thisInterrupt = micros();
  frequency = 1000000 / (thisInterrupt - previousInterrupt);
  previousInterrupt = thisInterrupt;
}


This calculates the frequency based on a single cycle - two interrupts - and stores it in the variable frequency.

You can get 16x better resolution by using timer2 to count clock cycles (at 9 kHz one cycle takes about 111 µs).
It isn't a good idea to post code to help a student cheat on his school work
when he hasn't shown any attempt at doing the work himself.

.




wvmarle

No worries - it'll only make them fail harder when they have to do it by themselves.
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.

ieee488

No worries - it'll only make them fail harder when they have to do it by themselves.
good point, though I prefer them failing sooner than later   :)




.

Paul_KD7HB

good point, though I prefer them failing sooner than later   :)




.
Failing later always brings other people into the picture and it is not pleasant. I have had to clean up after so-called systems annalists have screwed up systems so bad I had to basically through the design out and start over. Same with programmers.

My manager spends many hours a week trying to help electronic engineers straighten out their designs so the can actually be built. We always audit every kit brought in by engineers because with very few exceptions, there is something wrong or missing. One customer wanted to purchase the components themselves, but after a year they gave up and pay us to do it.

I would much rather have someone fail early on, so they can learn from their failures before impacting other people.

Paul

Go Up