Driving oscillations with square waves

What happens when you drive a vibrating system with a square wave rather than a sine wave? Do you still see the same kinds of behavior, such as beats and resonance? When does the difference between a square wave and a sine wave matter most? Those are the questions this post will address.

Background

Basic mechanical oscillations are modeled by the equation

m u'' + γ u' + k u = F sin(ωt + φ)

You can think of m, γ, and k as mass, damping, and spring constant. The same equation describes non-mechanical oscillations, such as electrical systems. Sometimes the terms such as “mass” are still used when they are metaphorical rather than literal. I wrote a four-part series of posts on mechanical vibrations a while back starting here.

The term on the right hand side is the forcing function. F is the amplitude of the driving force and ω is its frequency.

The natural frequency of a system modeled by the equation above is

ω02 = k/m.

When F = 0, the solutions to the differential equation will have this frequency. When F is not zero, the solutions a component with the natural frequency and a component with the driving frequency. When the two frequencies are different, you get beats. When the two frequencies are the same, you get resonance. More on beats and resonance here.

In this post we will look at solutions to the equation above where the forcing function is a square wave rather than a sine wave. That is, we will replace

sin(ωt + φ)

with

sign( sin(ωt + φ) )

where

sign(x)

is 1 when x is positive and -1 when x is negative.

Exploration

To simplify things a little, we will set the damping term γ to zero, and set the phase φ in the driving function to zero. Also, we will set m, k, and F all equal to 1. We will focus on varying only the driving frequency ω.

We need initial conditions for our differential equations, so let’s pick u(0) = 1 and u‘(0) = 0.

When we drive the system at its natural frequency, i.e. with ω = 1, we get the same kind of resonance from a sine wave and a square wave.

Square wave resonance

Update: There are more resonant frequencies [1].

When we lower the driving frequency to ω = 0.5 we see more of a difference.

Square beats omega = 0.5

In general we see more difference as ω gets smaller, and more difference when the period 1/ω is not an integer. For example, here is ω = 0.25, period T= 4:

Square wave beats omega = 0.25

And here is ω = 0.3, period T = 1.66.

Square wave beats, omega = 0.3Here’s an example of driving a system with a square wave at a frequency higher than the natural frequency.

Square wave beats, omega = 1.7

Here the difference between the solutions for the square wave and sine wave are closer together. Apparently the higher frequency makes more difference than the non-integer period.

In the examples above, the solution with a square wave forcing function starts out flat. That’s because of our initial conditions u(0) = 1 and u‘(0) = 0. If we change the initial velocity condition to u‘(0) = 1, we get smoother solutions.

Here are the solutions with u‘(0) = 1 and ω = 0.25

Square wave beats, omega = 0.25, initial velocity 1

and ω = 0.3.

Square wave beats, omega = 0.30, initial velocity 1

Changing the initial velocity made more of a difference when the period was an integer.

See the next post for systems driven by a sawtooth wave rather than a square wave.

Related posts

[1] Sine-driven systems exhibit resonance if and only if the driving frequency matches the natural frequency. While writing the next post on sawtooth forcing functions, I accidentally discovered resonance at lower frequencies. The same can happen here with square wave-driven systems if ω = 1/(2n + 1). For example, here’s a plot with ω = 1/5. The reason resonance shows up for odd periods is that the square wave has Fourier components at every odd frequency.

2 thoughts on “Driving oscillations with square waves

  1. Blessed bovine! Once again, an awesomely timely and relevant post.

    Two years ago I switched from embedded/real-time software design and development to systems engineering. As a systems engineer, a large part of my job is bringing new technologies onboard, understanding their strengths and limitations, ensuring they can support our needs, then turning them over to the product development teams.

    I then take the resulting systems and test them to their limits, starting with the first alpha-level hardware and software, ensuring they can meet the applicable standards, specifications and requirements.

    I’m presently shepherding a complex system through FCC Class B radiated emissions testing (others are handling conducted emissions testing and safety testing). The system consists of a “smart” chassis/enclosure into which can be inserted a wide variety of “smart” function-specific blades. Typical system configurations can easily include 20 or more embedded Linux systems, with individual blades hosting up to 6 independent processors.

    The prior generation system passed, and the new system was primarily a halving of the size of the chassis with a doubling of the capability of key blades, including the retirement of less-capable or obsolete first-generation blades. And, of course, simultaneously reducing the net cost to the customer.

    The initial alpha system passed pre-certification emissions check scans (“pre-scans”), though it was far from fully functional. The first beta system also passed pre-scans, but still had a long way to go.

    For the late-beta system, with full hardware functionality but lacking the final UI, we decided to skip another pre-scan and go straight for certification.

    The system failed miserably because of an unlikely coincidence: We had two blades, each of which alone generated some radiated harmonics that were well within certification limits. But the fourth harmonic of one blade and the third harmonic of another landed within 20 KHz of each other near 7 GHz, combining to make a ginormous peak on the spectrum analyzer that totally killed our certification effort.

    We first went through the normal efforts to “tighten up” the chassis, to find and correct RF leakage paths, but the enclosure was designed to isolate 5 GHz and below: The 7 GHz spur (short for “spurious signal”) cut through it with minimal attenuation. Still, the efforts did serve to make the spur less egregious, despite still being a hard fail.

    Still, two spurs landing together should make the sum worse by only 3 dB, right? Yet our initial violation was 6 dB. Consulting with RF specialists while “tightening” the chassis (a whole ‘nother story) helped us coax that down to a “barely fail”. However, due to variations between certification facilities, a “solid pass” should have all spurs be at least 4 dB below the limit. (Yes, some of our customers retest our products when they question the robustness of our certification, especially when we’re entering new markets.)

    The next step is to try to mute the emissions at the source, rather than merely contain them. One of the blades (the one with odd harmonics), a new design, quieted somewhat with simple modifications, mainly in software and the FPGA. But that improvement alone did not provide the margin we needed.

    Unfortunately, the other blade (with even harmonics) already has thousands of units in the field, as it was the last blade developed for the first-generation system. Changing that blade could, in the worst case, result in an RMA storm that could threaten our market viability (we run on very thin margins).

    Even and odd harmonics typically have different causes, such as even from amplification and odd from clipping. Then there are circuits that can generate either, such as filters. Every single oscillator and clock generator on our boards feeds directly into a low-pass filter specifically to limit harmonics.

    Using near-field probes, we isolated the source to the low-pass filter after a 2.33 GHz clock generator. That filter had been used on prior blades. But the clock generator was updated to avoid EOL concerns, and while equivalent in specifications, it clearly was “doing something” to make the filter very unhappy.

    Probing the circuit yielded nothing, as even high-impedance/low-capacitance FET probes muffled the harmonics. Fortunately, near-field probes come in two types: H-field and E-field probes. H-field probes can detect emission polarization, but aren’t so great at localization. E-field probes are unaware of polarization, but with careful use can isolate an emission source to about a square millimeter.

    The E-field probe immediately showed the filter inductors were screaming at 7 GHz. Clearly, the filter was being over-driven by the clock generator, yet the clock signal itself looked fine on the scope.

    Then this post arrived. First thing Monday I’ll feed the clock generator output to a spectrum analyzer: I now suspect the new chip is making a sharper square wave than the prior chip, which we may be able to manage by reducing the output drive current.

    Fingers crossed! A software fix would be the best-possible remedy.

Leave a Reply

Your email address will not be published. Required fields are marked *