Period to Hz Conversion: Formula, PWM Timing, and Bench Examples

Period is the exact time it takes for one complete cycle of a waveform to occur, and converting period to Hz (Hertz) simply means calculating how many of those cycles fit into one second using the inverse formula f = 1/T. If you are reading an oscilloscope cursor measurement in milliseconds or microseconds and need to configure a microcontroller timer or an analog filter, you must convert that time-domain value into the frequency-domain value (Hz) that most software APIs and component datasheets expect.

The Core Math: Converting Period to Hz in One Step

The relationship between period and frequency is strictly inverse. Think of a rotating AC generator shaft: the period is the time it takes to complete one full 360-degree physical rotation, while Hertz is how many full rotations it completes in one second. The mathematical bridge between them is:

f = 1 / T

Where:
f = Frequency in Hertz (cycles per second)
T = Period in seconds (time per cycle)

The most common mistake on the bench is forgetting to convert your oscilloscope or logic analyzer readings from milliseconds (ms) or microseconds (µs) into base seconds before doing the math. Here is a worked numeric example using real bench values:

What This Actually Changes on Your Workbench

Why does this conversion matter? Because mixing up period and frequency fundamentally alters how your circuit behaves in three critical areas:

1. Microcontroller Timer Prescalers: When configuring hardware timers on an ATmega328P (Arduino Uno) or an STM32, you often calculate the overflow rate based on the timer's period. If your target is a 1 kHz interrupt (1 ms period), but you accidentally program the prescaler for a 1 Hz interrupt (1 second period), your control loop will effectively freeze.
2. RC Filter Cutoff Points: The cutoff frequency of a low-pass filter is calculated as fc = 1 / (2πRC). This formula strictly requires Hertz. If you plug a period value into this equation, your calculated resistor and capacitor values will be off by orders of magnitude, resulting in a filter that either passes all noise or blocks your actual signal.
3. Motor Synchronization: AC induction motors and BLDC commutation routines rely on exact frequency matching. A 60 Hz grid expects a 16.67 ms period. Feeding a motor drive a 60 ms period (16.67 Hz) will cause the motor to stall and overheat.

The Most Common Confusion: Period vs. Pulse Width

Hobbyists frequently confuse period with pulse width (the time the signal is HIGH). The period is the total time of the HIGH state plus the LOW state. If a PWM signal is HIGH for 5 ms and LOW for 15 ms, the pulse width is 5 ms, but the period is 20 ms. Therefore, the frequency is 1 / 0.020 = 50 Hz, not 200 Hz. Always measure from rising edge to rising edge on your scope to capture the true period.

Where You Meet This in Practice

You will constantly bounce between period and Hz across different electrical domains. Here is where the conversion dictates your design choices:

• AC Mains Power: In North America, the grid is 60 Hz, meaning the period is 16.67 ms. In Europe and the UK, it is 50 Hz, meaning the period is 20.0 ms. If you are designing a zero-crossing detector circuit for a TRIAC dimmer, your software debounce window must be tuned to these exact period values to avoid false triggers from line noise.
• I2C and SPI Clock Lines: Standard I2C runs at 100 kHz (10 µs period), while Fast Mode runs at 400 kHz (2.5 µs period). If your pull-up resistors are too large, the RC time constant stretches the rise time, effectively eating into your 2.5 µs period and causing data corruption at 400 kHz.
• Servo Motor Control: Standard RC servos (like the ubiquitous SG90) demand a 50 Hz PWM signal. This translates to a strict 20 ms period. The pulse width (1 ms to 2 ms) dictates the angle, but if the overall 20 ms period drifts, the servo's internal feedback loop loses its reference and jitters.

Bench War Story: The 50Hz Servo Jitter Disaster

To illustrate what happens when you mix up period and frequency in firmware, here is a scenario from the bench that cost me an afternoon of debugging and nearly fried a development board.

The Setup: I was building a pan-tilt camera mount using an ESP32-WROOM-32 and two standard SG90 micro servos. The ESP32 uses the ledc (LED Control) hardware peripheral to generate PWM signals. According to the Espressif LEDC API documentation, the setup function requires you to define the frequency in Hz.

The Numbers: I pulled up the SG90 datasheet, which prominently states the control signal requires a "20 ms period." I opened my Arduino IDE and wrote the following initialization code:

// Flawed logic: passing period instead of frequency
ledcSetup(servoChannel, 20, 16); 
ledcAttachPin(servoPin, servoChannel);

The Outcome: The moment the ESP32 booted, the servo twitched violently, slammed against its internal mechanical hard stop, and began drawing massive current spikes. My bench power supply showed the ESP32 was pulling 800mA during the spikes, causing the 3.3V rail to brownout and the ESP32 to endlessly reboot.

What Went Wrong: I passed 20 into the frequency parameter. The ESP32 dutifully generated a 20 Hz signal (which has a 50 ms period). The servo's internal potentiometer and comparator circuit expected a pulse every 20 ms (50 Hz). Because the pulses were arriving at half the expected rate, the servo's error amplifier integrated the error over too long a time, driving the motor at full voltage into the physical plastic stop. The stalled motor drew maximum stall current, collapsing the voltage.

The Fix: I had to mentally convert the 20 ms period to Hz.
T = 20 ms = 0.020 seconds.
f = 1 / 0.020 = 50 Hz.
I changed the code to ledcSetup(servoChannel, 50, 16);. The servo immediately centered, drew a nominal 15mA, and operated silently. Always check whether your API expects Hz (cycles per second) or period (seconds per cycle).

Quick Reference: Period to Hz Conversion Table

Keep this table handy when configuring oscilloscope triggers, function generators, or microcontroller timers. It covers the most common benchmarks you will encounter in audio, power, and digital logic.

Frequently Asked Questions