Lecture 03 · LED control & timing

1Where Lab 3 Sits in the Course

Labs 1 and 2 were purely analog. You built an LED driver, measured a photodiode current, and multiplied two voltages together with an AD633. In every one of those circuits, the hardware decided what happened: a resistor set a current, a feedback loop set a gain, a multiplier produced a product.

Starting with Lab 3, software decides what happens. The Raspberry Pi is a full Linux computer with a row of pins that a Python program can switch between 0 V and 3.3 V. That single new ability — a line of code changing a voltage — is the foundation of everything left in this course: motor control (Lab 4), sensors (Lab 6), and your final project.

The catch, and the real subject of this lab, is that a general-purpose computer running Linux and Python is a surprisingly poor timekeeper. Asking for a 1-second delay does not give you exactly 1 second. Lab 3 is titled “LED Control and Timing Analysis” because the second half is the part that matters: you will use the oscilloscope to find out exactly how badly the Pi keeps time, and then learn the technique — PWM — that engineers use to get around it.

1.1  Lab 3 task map

Each task in the handout exercises a specific idea from these notes. Use this table to find the section you need while you are at the bench.

2Understanding the GPIO Port

2.1  What a GPIO pin actually is

GPIO stands for general-purpose input/output. These are configurable pins on the processor: the same physical pin can be set up as an input (the processor reads whether the voltage is high or low) or as an output (the processor drives the pin to 3.3 V or 0 V). “General-purpose” means the pin has no fixed job; your program decides.

Internally, an output pin is a pair of transistors acting as a two-way switch. Writing a 1 connects the pin to the 3.3 V rail through a small resistance; writing a 0 connects it to ground. This is called a push-pull output, because it can both source current out of the pin and sink current into it.

2.2  Two numbering schemes: BOARD and BCM

Here is the single most common source of confusion in this lab. The Raspberry Pi has two different ways of numbering the same pins, and a program written in one scheme will light the wrong LED — or nothing at all — if you wire it using the other.

Why are they different? The processor has far more internal I/O lines than the 40-pin header exposes, and the header layout was chosen for wiring convenience and backward compatibility, not to match the chip’s internal numbering. So the processor pin number and the board header pin number will essentially always disagree. Physical pin 11 is BCM 17; physical pin 12 is BCM 18.

2.3  The 40-pin header map

Read this table exactly as the header sits on the board: two rows of twenty, physical pin numbers in the dark centre columns, BCM names on the outside. Alternate functions (I²C, SPI, UART, PWM) are shown in small type — those pins still work as ordinary GPIO as long as the corresponding interface is not enabled.

Yellow = the pins recommended for Lab 3. BCM 12, 13, 18 and 19 are the four hardware-PWM-capable pins (§7.5).

2.4  Electrical limits: the rules that protect the Pi

The Raspberry Pi’s GPIO has no protection circuitry to speak of. There is no fuse and no current limiting between a GPIO pin and the processor. Exceed these numbers and you damage a £60 computer, not a 3-cent component.

2.5  Finding pins at the bench

Never count header pins from memory — the Pi will tell you. Both commands are preinstalled and need no internet connection.

# Print a labelled diagram of the physical header for this exact board
pinout

# Read the current function and level of a single BCM pin
pinctrl get 17

# Force BCM 17 to be an output driven high -- a fast way to test an LED
# circuit with no Python at all. Very useful for debugging.
pinctrl set 17 op dh
pinctrl set 17 op dl      # ...and drive it low again

3Driving an LED from a GPIO Pin

3.1  Why the series resistor is not optional

This is the same argument you met with the LED driver in Lab 1, and it is worth repeating because now the voltage source is inside a computer you do not want to damage.

An LED is a diode. Above its forward voltage V_F, its current rises roughly exponentially with voltage:

A 50 mV change in voltage near the knee can multiply the current several times over. So an LED connected straight across a 3.3 V source has no well-defined operating current: whatever current flows is set by the tiny, uncontrolled series resistances of the pin, the wires and the die. That current is typically far past the LED’s rating and past the pin’s 16 mA ceiling. The LED may survive; the GPIO pin may not.

Adding a series resistor converts an exponential device into a nearly linear one. Because the resistor drops whatever the LED does not, the current is set by Ohm’s law and is insensitive to the exact value of V_F.

3.2  The design equation

Apply Kirchhoff’s voltage law around the loop. The pin supplies 3.3 V, the LED drops V_F, and the resistor takes the remainder:

Design from the current you want, exactly as you did in Lab 1 — choose the current first, then solve for the resistor:

Then round up to the next standard resistor value. Rounding up lowers the current, which is the safe direction.

3.3  Forward voltage depends on color — and it matters here

An LED’s forward voltage is set by the band gap of its semiconductor, and the band gap sets the photon energy — that is, the color. Blue photons carry more energy than red ones, so a blue LED needs a noticeably higher forward voltage than a red one.

Work the cases with Equation (1), driving from a 3.3 V GPIO pin:

3.4  Sourcing and sinking

There are two ways to wire an LED to a GPIO pin, and you will meet both in published examples.

3.5  Wiring checklist before you apply power

1. LED long leg (anode) toward the resistor and the GPIO pin; short leg (cathode, also the flat side of the rim) toward ground.
2. Exactly one resistor in series with each LED — never one shared resistor for several LEDs (§8.3 explains why).
3. Ground return goes to a header ground pin (physical 6, 9, 14, 20, 25, 30, 34 or 39), and to the same ground rail your oscilloscope probe clips to.
4. Nothing connected to the 5 V pins (physical 2 and 4) — Lab 3 does not need them.
5. Count the header pin twice, from the corner, with the board oriented the same way each time.
6. Show the circuit and the code to the instructor or a TA before you run it — Lab 3, Task 3d requires this.

4Talking to the Pins from Python

4.1  Every GPIO program has the same three parts

1. Set up — declare which numbering scheme you use and which pins are outputs.
2. Drive — write HIGH or LOW, usually inside a loop with delays.
3. Clean up — return the pins to a safe default state when the program ends.

4.2  Which library on the lab Pi?

RPi.GPIO is the library for this course. It is installed and working on the lab Pis, it is the library used in the lecture slides, and it is what the overwhelming majority of Raspberry Pi example code on the internet is written in. Everything in these notes uses it unless stated otherwise.

A second library, gpiozero, is also preinstalled. It wraps RPi.GPIO-style operations in higher-level objects (LED, PWMLED, RGBLED) that handle setup and cleanup for you. It is shown alongside the main examples below so you can recognise it, and you are free to use it — just say which library you used in your report, and do not mix the two in one script.

Confirm your environment in the terminal before you start writing:

# Which Python am I using? (Task 2b asks for this)
python3 --version

# Confirm the GPIO library imports and the board is recognised.
# Prints "RPi.GPIO OK" and the library version if all is well.
python3 -c "import RPi.GPIO as GPIO; GPIO.setmode(GPIO.BCM); print('RPi.GPIO OK', GPIO.VERSION)"

4.3  The RPi.GPIO calls you need

This is the whole vocabulary for Lab 3. Everything in Tasks 3 to 8 is built from these calls; what you build is the assignment.

4.4  A worked example: blinking one LED

This is the example from the lecture slides, written out in full and commented, and it is the only complete program in these notes. Read every line — each one maps onto one of the three steps in §4.1. Use it as the pattern, not as something to copy into a task.

# Blink a single LED on BCM 17 (physical pin 11).
import RPi.GPIO as GPIO
from time import sleep

# ---- 1. SET UP ----
GPIO.setmode(GPIO.BCM)        # interpret pin numbers as BCM names
GPIO.setwarnings(False)     # suppress "channel already in use" noise
GPIO.setup(17, GPIO.OUT)      # BCM 17 becomes an output

print("Device is all set. Watch the light flash!")

# ---- 2. DRIVE ----
try:
    for i in range(10):
        GPIO.output(17, GPIO.HIGH)   # pin -> 3.3 V
        sleep(1.0)                    # ...for about one second
        GPIO.output(17, GPIO.LOW)    # pin -> 0 V
        sleep(0.5)                    # ...for about half a second
# ---- 3. CLEAN UP ----
finally:
    GPIO.cleanup()                  # runs even if you press Ctrl+C

The same thing in gpiozero, for comparison

Shown only so you recognise this style when you meet it. It is the identical circuit and the identical behaviour; the library simply performs the setup and cleanup for you.

from gpiozero import LED
from time import sleep

led = LED(17)          # BCM 17; gpiozero has no BOARD option

for i in range(10):
    led.on()
    sleep(1.0)
    led.off()
    sleep(0.5)

led.close()

4.5  Why cleanup matters on a shared lab Pi

When a Python program exits without releasing its pins, those pins keep whatever state they were left in. An LED can stay lit after the program ends, and the next program that tries to claim the pin may warn that it is already in use — or, if a previous process crashed while holding it, refuse to claim it at all. GPIO.cleanup() returns every pin your program configured to a safe, high-impedance input state. Call it in a finally: block so it runs no matter how the program ends.

A related habit: GPIO.cleanup() with no arguments releases all channels your script set up. You can also release a single pin with GPIO.cleanup(17), which is worth knowing when one script drives several LEDs and you want to hand just one pin back.

4.6  Task 4 — alternating two LEDs

Task 4 asks for a blue LED and a green LED alternating every 2 seconds. The structure you want is: turn one on and the other off, wait, then swap. Do not write two independent blink loops — they will drift apart.

Before you write anything, work out on paper:

• How many pins do you set up, and what does each GPIO.setup() line look like?
• In a single pass of the loop, how many GPIO.output() calls are needed, and in what order, so that exactly one LED is lit at any moment?
• Where do the sleep() calls go, and what is the resulting period of the complete cycle? Predict it before you measure it.
• How will you stop the program cleanly and release the pins?

One piece of structural advice that will save you time later: put the delay in a named constant at the top of the file rather than typing the number into each sleep(). Task 4d asks you to sweep the rate, and a single constant means changing one line per run instead of four.

5Timing: Why sleep() Is Not a Clock

This is the analytical heart of Lab 3. Everything up to here has been about getting an LED to light. Now we ask a harder question: when exactly does it light, and how well can the Pi be trusted to repeat that?

5.1  Vocabulary

5.2  The loop period equation

Take the blink loop from §4.4. You asked for 1.0 s on and 0.5 s off, so you might expect T = 1.5 s exactly. What you actually get is

where t_overhead covers everything the computer does that is not sleeping: executing the Python bytecode, calling into the GPIO library, the kernel switching to your process and back, and any other work the machine happens to be doing. Two consequences follow immediately, and both are testable at the bench:

• The measured period is always longer than the requested one. Overhead only ever adds. There is no mechanism that makes a loop finish early.
• The error is roughly constant in absolute terms, so it matters more as you go faster. A 2 ms overhead on a 1.5 s period is an error of 0.1% — invisible. The same 2 ms on a requested 1 ms period is a 200% error. This is exactly what you will watch happen in Task 4.

5.3  Where the extra time comes from

Five separate mechanisms contribute, and it is worth being able to name them in your report rather than writing “the Pi is slow.”

1. Linux is not a real-time operating system. The kernel runs dozens of processes and shares the CPU by preempting them on a scheduling tick. Your program can be interrupted at any moment, for as long as the scheduler decides. This is the dominant source of large, unpredictable outliers.
2. sleep() guarantees a minimum, not an exact delay. The call asks the kernel to wake the process no earlier than the requested time. When the wake-up actually happens depends on timer resolution and on whether the CPU is free. For short sleeps the rounding is significant: requesting 100 µs commonly yields something noticeably longer.
3. Python interpreter overhead. Every GPIO.output() is a Python function call and a library call before any hardware register is touched — microseconds per operation, not nanoseconds. A higher-level wrapper such as gpiozero adds further layers and is slower still per toggle, which is one reason this course works at the RPi.GPIO level.
4. Garbage collection. Python periodically pauses to reclaim memory. These pauses are short but arrive unpredictably, adding occasional outliers to an otherwise tidy distribution.
5. Everything else on the machine. The desktop environment, network activity, USB polling, and SD-card writes all steal CPU time. A Pi running the full desktop jitters measurably more than one at a bare console — something you can test.

5.4  Finding the maximum toggle frequency (Task 4d)

Setting the delay to zero removes the sleep entirely and leaves a loop that toggles the pin as fast as Python can go. The period is then pure overhead:

— the factor of two because one full period needs two writes, one high and one low.

Do not expect a particular number and do not copy one from these notes: the answer depends on your Pi model, your library, and what else the machine is doing, and measuring your own value is the point of the task. What you should expect qualitatively is a ceiling somewhere in the kilohertz range, with gpiozero slower than a lower-level library, and with the jitter growing dramatically in relative terms as you approach it.

To find the ceiling, remove the delays entirely and time a large, known number of cycles. The tools you need are time.perf_counter() — the monotonic high-resolution clock, not time.time(), which is coarser — called once before and once after the loop. Dividing the cycle count by the elapsed time gives the frequency the software believes it achieved.

5.5  Measuring jitter on the oscilloscope

“Check for timing jitter” in Task 4 means producing a number, not an impression. Three methods, in increasing order of rigour:

1. Measurement statistics (best). Turn on the scope’s Period measurement, then enable Statistics. The scope accumulates many measurements and reports mean, minimum, maximum and standard deviation. Then
   jitter_pk–pk = T_max − T_min,     jitter_RMS = σ_T
   Report both, and report the mean period alongside them so the numbers can be interpreted as a fraction.
2. Infinite persistence (most vivid). Set the display to infinite persistence and trigger on a rising edge. The first edge after the trigger stays sharp; each subsequent edge smears into a band. The width of that band, read off the timebase, is the accumulated jitter — and it grows the further you look from the trigger. This produces the single most convincing screenshot you can put in the report.
3. Eyeball comparison (quickest). Set the timebase so one period fills the screen and watch the falling edge wander relative to the graticule. Fine for a sanity check; not a number.

5.6  Things that will wreck your timing

• print() inside the timing loop. Writing to a terminal takes milliseconds and is wildly variable. It is the single most common reason a student’s loop runs a hundred times slower than expected. Collect your data in a list and print after the loop.
• Recomputing things every iteration. Anything constant should be computed once before the loop.
• A busy desktop. Close the browser and any other windows before taking timing data. Consider comparing timing with and without the desktop in use — it is a nice extra result.
• Using time.time() instead of time.perf_counter(). perf_counter() is the monotonic high-resolution clock intended for measuring intervals.

6Flicker Fusion: When Blinking Becomes Brightness

As you sweep the blink rate upward in Task 4, something qualitative happens well before you reach the software limit. Somewhere around 50–90 Hz the LED stops looking like it is flashing and starts looking like it is simply on, but dimmer. This threshold is called the flicker fusion frequency, and it is a property of your eye and brain, not of the circuit.

The retina integrates light over roughly 10–20 ms. Once the flashes arrive faster than that, the visual system averages them and perceives a steady source whose brightness corresponds to the average optical power. Peripheral vision is faster than central vision, which is why a flickering LED at the edge of your field of view can look like it is flashing while the same LED looks steady when you stare at it.

In your report for Task 4, note the frequency at which you stopped perceiving flicker, and compare it with the frequency at which the oscilloscope still clearly shows separate pulses. The gap between the two is a good illustration of why an instrument is more trustworthy than an eye.

7Pulse-Width Modulation

7.1  Definition

A PWM signal is a square wave with a fixed period whose on-time is variable. The controlled quantity is the duty cycle:

Changing the duty cycle does not change the frequency, and changing the frequency does not change the duty cycle. They are independent controls, and Task 7b asks you to vary each one and watch that independence on the scope.

7.2  Average voltage and average current

Averaging the waveform over one period, with the low level at 0 V:

with D expressed as a fraction here. Note carefully what is not happening: the LED’s instantaneous current never changes. When the pin is high the LED runs at its full design current from Equation (1); when the pin is low it is completely off. Only the time-average changes, and since both the LED’s light output and your eye respond to the average, the LED appears dimmer.

7.3  Choosing the PWM frequency

7.4  Software PWM

Software PWM is exactly the blink loop from §5, generated by a background thread, with the on and off delays computed from the requested duty cycle. Everything you learned about jitter in §5 applies directly — the edges are placed by the CPU, so the scheduler can move them.

The RPi.GPIO calls you need are these four. Each line below is the syntax, not a program — assembling them into something that performs Task 7 is the assignment.

The equivalent in gpiozero, should you meet it, is PWMLED(pin, frequency=...) with a .value property and a .frequency property.

7.5  Hardware PWM

The Pi contains dedicated PWM peripherals — small counters in silicon that toggle a pin without any CPU involvement at all. Once configured, the hardware generates every edge on a crystal-derived clock. The jitter is orders of magnitude lower than software PWM, and it does not degrade when the processor is busy.

Hardware PWM is available on four pins: BCM 12, 13, 18 and 19 (physical 32, 33, 12 and 35), arranged as two independent channels. Enabling it requires a device-tree overlay in /boot/firmware/config.txt and a reboot, so check with the instructor or a TA before changing any system configuration on a shared lab Pi. Note that GPIO.PWM() in RPi.GPIO is always software PWM — it never uses the hardware peripheral, whatever pin you give it. That is fine for this lab, as long as you say so in your report rather than claiming a hardware measurement you did not make.

7.6  Measuring PWM on the scope (Tasks 7b and 7c)

Task 7c asks you to report the waveform period and on-time. On the scope, turn on three automatic measurements and read them directly: Period, +Width (the on-time), and Duty Cycle. Verify that they are consistent with Equation (5) — +Width divided by Period should equal the duty cycle.

8RGB LEDs and the Breathing Effect

8.1  What is inside the package

An RGB LED is three separate LED dies — red, green and blue — in one plastic body. It has four legs: one for each color, plus one common leg shared by all three. There are two kinds, and wiring one as if it were the other simply will not work.

8.2  Identifying the legs

1. Find the common leg: it is the longest one, usually the second from one end, not on a corner.
2. Determine the type: use the DMM’s diode-test function. Put the red (positive) probe on the long leg and touch the black probe to each other leg in turn. If colors light up, it is common anode. If nothing lights, swap the probes: if colors now light with the black probe on the long leg, it is common cathode.
3. Map the colors: the same diode test tells you which leg is red, green and blue. Write the mapping down — the standard order is red, common, green, blue, but do not trust it without checking.

8.3  One resistor per color — never one shared

It is tempting to put a single resistor in the common leg and save two components. Do not. Here is why, and it is a genuinely instructive circuit-analysis point:

• With a shared resistor, the three dies are in parallel above it. They have different forward voltages, so the one with the lowest V_F — the red — hogs almost all the current, while blue gets almost none.
• Worse, the current through any one die then depends on how many others are on. Turn on green as well as red and the red visibly dims. Your colors become uncontrollable and unrepeatable, which destroys any hope of color mixing in Task 8.
• With an individual resistor in each color leg, each branch’s current is set independently by Equation (1), and turning on one color has no effect on the others.

Start with the same value in all three legs — 470 Ω each, as elsewhere in this lab. Because the three dies have different forward voltages, they will draw different currents from equal resistors (the §3.3 table, now applied inside one package), so the three colors may not look equally bright. For Task 6 that hardly matters. For the color mixing in Task 8 it does, and you have two ways to correct it: change the resistor in the leg that is too bright, or leave the resistors alone and trim that channel’s duty cycle in software. The second is easier, more precise, and adjustable while the program runs — which is itself a small lesson in why PWM is so useful. Say which you did.

8.4  Color mixing with three PWM channels

Three PWM channels driving three dies gives three independent duty cycles, and the eye fuses the result into one perceived color. This is additive mixing, the same principle every display uses.

“White” from a three-die LED at equal duty cycles usually looks tinted, because the three dies do not have equal luminous efficiency and your resistors are not matched to compensate. Correcting it by trimming the duty cycles is a good optional experiment.

8.5  Task 6 — flashing three colors in sequence

Task 6 needs no PWM at all: switch each color fully on for a fixed time, in turn, at a rate slow enough to see (0.3–1 s per color). Treating the three pins as a list keeps the loop short.

Points to settle before you write it:

• Which three BCM pins, and which physical pins do they correspond to? Write both down.
• GPIO.setup() accepts a list of pins, and so does GPIO.output() — worth knowing, because it shortens this task considerably.
• What must happen to the other two colors each time you turn one on? A sequence that only ever turns colors on ends with all three lit and looking white.
• For a common-anode LED, what changes?

8.6  Task 8 — the breathing effect, and why a linear ramp looks wrong

“Breathing” means the brightness rises and falls smoothly and continuously. The obvious implementation is to ramp the duty cycle linearly from 0 to 1 and back. Try it — and then notice that it does not look smooth. It appears to brighten very quickly at the start, then hold nearly constant near the top, and it snaps off abruptly at the bottom.

The reason is human, not electrical. The eye’s response to luminance is strongly compressive: doubling the light does not look twice as bright. The standard engineering model treats perceived brightness as roughly a power law,

To make brightness appear to change linearly, you must therefore command a duty cycle that is the inverse of that curve — this is called gamma correction:

So for a perceived half-brightness, command D = 0.5^2.2 ≈ 0.22, not 0.5. Applying this one line transforms the breathing effect from mediocre to convincing, and it is exactly the kind of detail that distinguishes a thoughtful Task-8 submission.

Implementing this needs three PWM objects, one per color channel, all created at a frequency above flicker fusion — a couple of hundred hertz is ample. Then a loop steps a brightness variable through a smooth path, converts it with Equation (8), and writes the result to ChangeDutyCycle().

The design decisions are yours, and they are what Task 8 is actually assessing:

• What function of time gives a smooth ramp with no jump when it wraps around? A linear ramp reversing at the ends has a discontinuity in slope; a raised cosine, b = ½(1 − cos 2πt/T), does not.
• How many steps per breath, and how long does each step sleep? These two numbers together set the breath period — and §5 tells you the period will come out slightly long.
• How do the three channels relate to each other? Driving them in phase gives a white breath; offsetting them in phase walks around the color wheel.

9Oscilloscope Technique for This Lab

Lab 3 requires oscilloscope screenshots for Task 4 (LED timing) and Task 7 (PWM waveform). These settings will get you there quickly.

Saving screenshots: write them to a USB drive from the scope, then copy them to your own computer. Give each file a name you will still understand next week — task4_1kHz_persistence.png, not scope_07.png.

10Common Mistakes and Bench Safety

10.1  Things that destroy hardware

• 5 V into a GPIO pin. Instantly fatal to the processor. The pins are 3.3 V only and are not 5 V tolerant. Nothing in Lab 3 requires the 5 V pins, so the safest habit is to leave them alone entirely.
• An LED with no series resistor. Exceeds the pin’s current rating immediately.
• Shorting a power pin to ground. Physical pins 1, 2, 4 and 17 are supplies. A stray wire from one to a ground pin can brown out or damage the board.
• Rewiring with the Pi powered. Shut down cleanly (sudo shutdown -h now), wait for the activity LED to stop, and unplug before changing the circuit.
• Connecting a motor, relay or long wire directly to a pin. Inductive loads generate voltage spikes far outside the safe range. That is what Lab 4’s MOSFET is for.

10.2  Things that waste your afternoon

• BOARD/BCM confusion (§2.2). Check this first, always.
• LED in backwards. It will not light and gives no other symptom. Flip it.
• Blue LED with a 330 Ω resistor (§3.3). It is not broken; it has no headroom.
• A breadboard row misread by one hole. Confirm with continuity on the DMM.
• range(1, 10) when you meant ten iterations.
• print() inside a timing loop (§5.6).
• A previous script left running and still holding the pin. Check with ps aux | grep python and stop it.
• Editing one file and running another. Check the filename in the VS Code title bar and in the terminal command.

10.3  Before you leave (Task 9)

The lab Pis are shared. Copy your whole YourFirstName_python directory to your own computer — via USB drive, or with scp if networking is available — then delete it from the Pi. Verify the copy opens on your machine before you delete the original. Also power down the bench supply and the scope, and return components to their bins.

11Self-Check

Work these before lab. If you can answer all nine, you are ready for the bench.

1. State the difference between BOARD and BCM numbering, and give the BCM name of physical pin 11.
2. A GPIO pin is at 3.3 V. Find the current through a red LED (V_F = 1.9 V) with a 470 Ω series resistor, and confirm it is within the per-pin limit.
3. Why can the Raspberry Pi not drive a small DC motor directly from a GPIO pin? Support your answer with a number.
4. Write, from memory, the three steps every GPIO program contains, and say what goes wrong if the third is skipped.
5. A blink loop requests 0.5 ms high and 0.5 ms low. The scope reads a mean period of 1.31 ms. Compute the overhead and the frequency error, and name two mechanisms that produce it.
6. Define jitter, and describe two different ways to measure it with an oscilloscope.
7. A PWM signal runs at 200 Hz with a 35% duty cycle. Find the period, the on-time, and the average voltage from a 3.3 V high level.
8. Explain why hardware PWM has far lower jitter than software PWM, in terms of what generates each edge.
9. Why does a linear duty-cycle ramp not produce a linear-looking brightness ramp, and what should you command instead for a perceived half-brightness?

12Practical Engineering Connections

Every idea in this lecture is load-bearing in real hardware:

1. GPIO and logic levels. Every embedded product mixes chips with different supply voltages. Knowing that a pin is 3.3 V and not 5 V tolerant — and reaching for a level shifter when it is not — is a daily task in embedded design.
2. Current-limited LED drive. Status indicators, backlights, optical encoders, IR remotes, fiber-optic transmitters and the photodiode sources you used in Lab 1 all rely on a defined LED current.
3. PWM dimming. Phone and laptop screen backlights, stage and architectural lighting, automotive tail lamps and every LED dimmer switch work exactly this way, for exactly the efficiency reason in §6.
4. PWM as power control. The same waveform driving a MOSFET is how switching regulators, class-D audio amplifiers, induction cooktops and electric-vehicle motor drives control power with almost no loss. Lab 4 is your first version of this.
5. PWM as a communication signal. Hobby servos are positioned by pulse width, and PWM feeding an RC filter is a cheap digital-to-analog converter — a technique you may want for your final project.
6. Timing and jitter. Jitter budgets determine the maximum data rate of every serial link, the phase noise of every oscillator, and the resolution of time-of-flight measurements in lidar and ultrasound. The measurement you make in Task 4 is a simple version of an analysis done on every high-speed board.
7. Real-time versus general-purpose computing. The reason aircraft, medical and automotive controllers use real-time operating systems, dedicated microcontrollers or FPGAs — rather than Linux and Python — is precisely what you will measure in this lab.
8. Gamma correction. Every display, camera and image file format encodes brightness with a gamma curve for the same perceptual reason you will apply it in Task 8.

PHYS 351 · Lecture 03 Notes · © Ran Yang, Ph.D. · yangran.org/teaching/phys351/
Companion documents: the Lab 3 handout and the course Linux Commands Guide.