Post History
There is no "standard". Do whatever works best for the situation at hand. In a microcontroller, it's usually easier to measure period than frequency, especially for "low" frequencies like the pow...
Answer
#2: Post edited
- There is no "standard". Do whatever works best for the situation at hand.
- In a microcontroller, it's usually easier to measure period than frequency, especially for "low" frequencies like the power line. If you are doing things in the micro related to the power line, then often it's the period you care about anyway, or perhaps the problem can be transformed into working with the period instead of the frequency. If you really need to know the frequency, like to display to a user, you do the divide to convert period to frequency.
- In a recent project, I not only had to report the line frequency to a computer communicating with the microcontroller, but also had to control relays to switch close to a power line zero crossing.
I used two back to back opto-isolators to create a digital square wave from the power line going into a capture input of the micro. The hardware would capture the value of a free-running clock once per cycle. That made the period available every cycle to plenty high resolution. I did a little low-pass filtering on the period to use as the predicted time from the start of one cycle to the start of the next. The micro therefore always know how much time there was before the next power line zero crossing.- This was used to switch the relays a few ms before the next start of cycle, based on measurements made of the relay response time. Of course the relay delay wasn't exact, but in tests the relays switched when the power voltage was within ±20 V. That's a lot better than the possible 170 V peak, and reduced our inrush current significantly.
- Note that all this computation was done in the time domain, not the frequency domain. That's what microcontrollers are better suited to work with. When we do have a frequency-related problem, it is often transformed into the equivalent time domain problem for addressing in a micro. That's pretty much the basis for DSPs, which are optimized to perform convolutions.
- In the case above, we actually reported the power line period to the host computer, and let it do the divide to show frequency to the user.
- There is no "standard". Do whatever works best for the situation at hand.
- In a microcontroller, it's usually easier to measure period than frequency, especially for "low" frequencies like the power line. If you are doing things in the micro related to the power line, then often it's the period you care about anyway, or perhaps the problem can be transformed into working with the period instead of the frequency. If you really need to know the frequency, like to display to a user, you do the divide to convert period to frequency.
- In a recent project, I not only had to report the line frequency to a computer communicating with the microcontroller, but also had to control relays to switch close to a power line zero crossing.
- I used two back to back opto-isolators to create a digital square wave from the power line going into a capture input of the micro. The hardware would capture the value of a free-running clock once per cycle. That made the period available every cycle to plenty high resolution. I did a little low-pass filtering on the period to use as the predicted time from the start of one cycle to the start of the next. The micro therefore always knew how much time there was before the next power line zero crossing.
- This was used to switch the relays a few ms before the next start of cycle, based on measurements made of the relay response time. Of course the relay delay wasn't exact, but in tests the relays switched when the power voltage was within ±20 V. That's a lot better than the possible 170 V peak, and reduced our inrush current significantly.
- Note that all this computation was done in the time domain, not the frequency domain. That's what microcontrollers are better suited to work with. When we do have a frequency-related problem, it is often transformed into the equivalent time domain problem for addressing in a micro. That's pretty much the basis for DSPs, which are optimized to perform convolutions.
- In the case above, we actually reported the power line period to the host computer, and let it do the divide to show frequency to the user.
#1: Initial revision
There is no "standard". Do whatever works best for the situation at hand. In a microcontroller, it's usually easier to measure period than frequency, especially for "low" frequencies like the power line. If you are doing things in the micro related to the power line, then often it's the period you care about anyway, or perhaps the problem can be transformed into working with the period instead of the frequency. If you really need to know the frequency, like to display to a user, you do the divide to convert period to frequency. In a recent project, I not only had to report the line frequency to a computer communicating with the microcontroller, but also had to control relays to switch close to a power line zero crossing. I used two back to back opto-isolators to create a digital square wave from the power line going into a capture input of the micro. The hardware would capture the value of a free-running clock once per cycle. That made the period available every cycle to plenty high resolution. I did a little low-pass filtering on the period to use as the predicted time from the start of one cycle to the start of the next. The micro therefore always know how much time there was before the next power line zero crossing. This was used to switch the relays a few ms before the next start of cycle, based on measurements made of the relay response time. Of course the relay delay wasn't exact, but in tests the relays switched when the power voltage was within ±20 V. That's a lot better than the possible 170 V peak, and reduced our inrush current significantly. Note that all this computation was done in the time domain, not the frequency domain. That's what microcontrollers are better suited to work with. When we do have a frequency-related problem, it is often transformed into the equivalent time domain problem for addressing in a micro. That's pretty much the basis for DSPs, which are optimized to perform convolutions. In the case above, we actually reported the power line period to the host computer, and let it do the divide to show frequency to the user.