Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

75%
+4 −0
Q&A Standardized way of measuring AC line frequency

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...

posted 7mo ago by Olin Lathrop‭  ·  edited 7mo ago by Olin Lathrop‭

Answer
#2: Post edited by user avatar Olin Lathrop‭ · 2024-05-04T13:17:07Z (7 months ago)
  • 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 &plusmn;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 &plusmn;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 by user avatar Olin Lathrop‭ · 2024-05-04T13:14:27Z (7 months ago)
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 &plusmn;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.