You’re staring at a datasheet. Maybe it’s a vibration sensor, a high-end audio processor, or a brushless motor controller. One value is in Hertz. The other is in radians per second. If you mess up the conversion, your control loop oscillates, your filters cut off at the wrong frequency, and basically, everything breaks. It’s a simple shift, but hz to rad sec is where the physical world of "how many times per second" meets the mathematical world of "how far did it rotate."
Most people think of frequency as a ticker tape. Click, click, click. That’s Hertz. But physics doesn't really work in clicks; it works in circles.
The Geometry of the Spin
To understand why we even bother with two different units, you have to look at a circle. One full rotation is $360^{\circ}$. But in calculus and physics, degrees are kind of a nightmare. They're arbitrary. Why 360? Why not 400? This is why we use radians. A radian is the angle created when the arc length equals the radius. It’s "natural." Because there are $2\pi$ radians in a full circle, any time you talk about something spinning, you’re dealing with multiples of $2\pi$.
Hertz ($Hz$) measures cycles. Radians per second ($rad/s$) measures angular velocity.
Think about a vinyl record. If it spins at 33.3 RPM, that’s a frequency. But if you want to calculate the centripetal force acting on the needle, you need the angular velocity. You need those radians. The bridge between these two worlds is the constant $2\pi$, which is roughly 6.283185.
Doing the Math (Without Making a Mess)
The formula is deceptively easy. To get from hz to rad sec, you multiply by $2\pi$.
$$\omega = 2\pi f$$
Here, $\omega$ (omega) is your angular frequency in $rad/s$, and $f$ is your frequency in $Hz$.
Let’s say you have a 60 Hz power grid. You’re trying to model the voltage sine wave. You can’t just plug "60" into a sine function and expect it to work with time in seconds. You have to convert it. So, $60 \times 2\pi$ gives you roughly 377 $rad/s$. That’s the number that actually goes into your equations. Honestly, if you’ve ever wondered why 377 pops up in electrical engineering textbooks constantly, that’s why. It’s just 60 Hz wearing a different hat.
👉 See also: Mac Auto Key Presser: What Most People Get Wrong
Conversely, if you’re looking at an angular velocity and need to find the frequency, you divide.
$$f = \frac{\omega}{2\pi}$$
It sounds simple. It is simple. Yet, in the heat of a design review or a late-night coding session, people flip them. I’ve seen it happen in professional robotics labs. Someone divides when they should multiply, and suddenly a drone is trying to spin its motors at 1/40th the speed it needs to stay airborne.
Why Does This Keep Happening?
Dimensional analysis is your best friend here. Hertz is technically "1/seconds" or $s^{-1}$. Radians are technically dimensionless (it’s a ratio of length over length), so $rad/s$ is also just $s^{-1}$.
This is the trap.
Because both units technically have the same base dimension in the SI system, software compilers won't always catch the error. If you pass a value meant for $rad/s$ into a function expecting $Hz$, the computer won't complain. It'll just give you the wrong answer. This is a classic "silent failure."
In signal processing, especially when using Fast Fourier Transforms (FFTs), the x-axis is almost always in Hz. But the moment you move into the Laplace domain or start working with transfer functions ($s = \sigma + j\omega$), you’re in radians territory. This constant context-switching is where the errors creep in.
Real-World Stakes: From Audio to Aerospace
In audio engineering, we talk about the 20 Hz to 20 kHz range. We don’t say "125 radians per second to 125,000 radians per second." It sounds clunky. But if you’re designing a digital Butterworth filter, the math happens in the $z$-domain or $s$-domain. You must convert those audible frequencies to angular ones.
If you're off by a factor of 6.28, your "bass boost" is suddenly in a frequency range only whales can hear.
In aerospace, the situation is even tighter. Control surfaces on an aircraft have resonant frequencies. If the flight control computer is processing sensor data in the wrong unit, it might try to compensate for a vibration that isn't there, or worse, create a feedback loop that leads to structural failure.
Look at the history of the Mars Climate Orbiter. That was a metric-versus-imperial unit mix-up, but the "unit error" ghost is the same. Whether it's pounds vs. newtons or hz to rad sec, the math only works if the units match the physical reality.
Practical Tips for the Field
If you're working in Python or C++, don't just hardcode 6.28. Use the built-in constants. In Python, use math.pi. In C++, use M_PI. It’s more precise and makes your intent clear to the next person reading your code.
Actually, write wrapper functions.
Don't just write angular_v = freq * 6.28. Write a function called hertz_to_radians(hz). It takes two seconds. It saves hours of debugging later. When you see hertz_to_radians in the source code, you know exactly what the developer was thinking. You don't have to guess if that random float multiplier was $2\pi$ or some other correction factor.
Also, keep a "sanity check" number in your head.
1 Hz is roughly 6 rad/s.
10 Hz is roughly 63 rad/s.
100 Hz is roughly 628 rad/s.
If your calculation for 100 Hz gives you 15.9, you divided by $2\pi$ instead of multiplying. You’re off by a factor of nearly 40. Catching that early is the difference between a successful prototype and a pile of expensive, smoking electronics.
Addressing the Misconception: Is it Just "Angular Speed"?
Some people use "angular frequency" and "angular velocity" interchangeably. In many contexts, that's fine. But technically, angular velocity is a vector. It has a direction (the axis of rotation). Angular frequency is just the magnitude.
When you convert hz to rad sec, you are usually finding the angular frequency. You’re describing how fast the phase of a sine wave is changing. It doesn't necessarily mean something is physically spinning in a circle, though it's often represented that way on a complex plane.
This distinction matters in electromagnetics. When you’re looking at a rotating magnetic field in an induction motor, the $Hz$ tells you the electrical frequency, but the $rad/s$ describes the actual physical rotation of the magnetic flux. If you have multiple pole pairs, the relationship gets even more complex, but it still starts with that fundamental conversion.
Actionable Steps for Precision
- Verify your library defaults: Before using a library like NumPy, SciPy, or MATLAB’s signal processing toolbox, check if the functions (like
butterorlsim) expect frequencies in Hz or rad/s. MATLAB usually defaults to normalized frequency or $rad/s$ for system objects, while many Python libraries expect $Hz$ for filter design but $rad/s$ for internal math. - Standardize your variables: Adopt a naming convention. Use
f_hzfor frequency andw_radoromegafor angular frequency. This makes unit mismatches visually obvious in your code. - Check the $2\pi$ vs $\pi$ trap: Some people accidentally multiply by just $\pi$ (the "half-circle" error). Remember, a cycle is a full trip around the circle. Always $2\pi$.
- Document the conversion in your spreadsheets: If you’re doing calculations in Excel, label your columns clearly with the unit. Don't just put "Frequency." Put "Frequency (Hz)" and "Angular Freq (rad/s)."
Precision isn't just about having a lot of decimal places. It's about knowing which unit you're holding. Whether you’re tuning a PID loop or just trying to pass a physics exam, the move from hz to rad sec is the most common place to trip up. Master that $6.28$ multiplier, and you’ve cleared one of the biggest hurdles in technical literacy.