Everything left to build, and why each circuit works.

Every lesson below is built the same way, so you can jump to any of them and know where to look.

• The wiring map. A drawing of your UNO with only the pins you need lit up, and a coloured wire to every part. Wire colours are consistent everywhere in this document: red is 5 V, black is ground, blue, amber, green and purple are signals, orange is 3.3 V. Where a resistor belongs, it is drawn on the wire itself with its real colour bands, so you can match it against the part in your hand.
• The pin table. The same information as a checklist. Wire from the table, then check against the map.
• Why it works. The part you actually asked for. Not the procedure, the reason.
• The catch. The one mistake that costs people an hour on that particular circuit.

The maps deliberately show connections rather than a photo of a breadboard. A photo hides half the wires behind the components; a map never does. What the map does not show is which breadboard row you use, because that part is free choice: any two holes in the same row are the same electrical point. The next section explains that.

Nothing here is fussiness. Each rule maps to a specific way beginners destroy a board.

1. Unplug the USB cable before you change wiring. Rewiring a live circuit is how you short 5 V to ground with your fingers still on the jumper.
2. Never wire 5 V straight to GND. That is a short circuit. The USB port will shut itself off if you are lucky, and the board's polyfuse will get hot if you are not.
3. Never connect a motor, relay coil or anything with a magnet directly to an Arduino pin. A pin can supply about 20 mA comfortably and 40 mA absolute maximum. A motor wants ten times that. See Lesson 17.
4. The whole 5 V pin can supply roughly 400–500 mA over USB, shared by everything. Add up your parts before you plug in.
5. Every LED gets a resistor. An LED has no internal resistance to speak of; without a resistor the only thing limiting current is the pin itself, and the pin loses.
6. 3.3 V parts get 3.3 V. The RFID reader in your kit (Lesson 23) is destroyed by 5 V on its power pin. It is the single most commonly killed module in this kit.
7. Everything shares one ground. If you power a motor from a battery and the Arduino from USB, the battery's negative terminal must still connect to an Arduino GND pin. Signals are measured against ground; two circuits with no shared ground have no agreed zero, so the signal means nothing.

Three quantities, one relationship, and the whole kit falls out of it.

Voltage is a difference in electrical pressure between two points. That word difference is the important one. There is no such thing as the voltage at a point, only the voltage between two points. When we say "pin D13 is at 5 V" we always mean 5 V above ground, and ground is simply the point everyone agreed to call zero. This is why every circuit in this manual has a black wire in it: without a shared zero, "5 V" is a sentence with no subject.

Current is the flow of charge, measured in amps. Current is what actually does the work and what actually destroys things. Heat in a component is proportional to current squared, which is why a small mistake in current is a large mistake in temperature.

Resistance is how much a material objects to that flow, in ohms. Ohm's law ties them together:

V = I × R   →   I = V / R   →   R = V / I

The useful mental habit is this: voltage is applied, current is the consequence. You choose what voltage to put across something; the circuit decides how much current results. A 220 Ω resistor with 3 V across it will pass 3/220 = 0.0136 A = 13.6 mA, whether or not that suits you. Your only lever is the resistance.

The water analogy holds up well as long as you keep it honest: voltage is pressure difference, current is litres per second, resistance is the narrowness of the pipe. A pump raises pressure but the pipe decides flow. The place the analogy fails is that water can leak out of an open pipe, while current cannot flow unless there is a complete loop back to where it came from. There is no such thing as half a circuit.

Power is the fourth quantity you meet as soon as motors appear: P = V × I, in watts. It tells you how much energy per second is being turned into heat, light or motion, and it is the number that decides whether something gets warm or gets destroyed.

A breadboard is a grid of holes with metal clips hidden underneath, and those clips are connected in a specific pattern. Almost every "my circuit does nothing" problem is a misunderstanding of this pattern.

The two long rails at the top and bottom (marked with a red line and a blue or black line) run the full length of the board. Every hole along the red line is one single electrical point; the same for the blue line. These are for power and ground, and they exist because nearly every part needs both, so it would be miserable to run a separate wire back to the Arduino each time. You run one red wire from 5 V to the red rail and one black wire from GND to the blue rail, and now power is available everywhere.

The main area is completely different: it is connected in short rows of five holes, running across the board, and the channel down the middle breaks the connection. So holes A1 B1 C1 D1 E1 are one point, and F1 G1 H1 I1 J1 are a different point, even though they are in the same numbered row. The gap is not decoration.

That centre channel is exactly the width of a DIP chip like your 74HC595, and this is why: the chip straddles the channel so that its left row of legs and its right row of legs land on different, unconnected groups. If the channel were not there, every leg would be shorted to the one opposite it and the chip would do nothing.

Two habits that pay for themselves: put components across the channel or across separate rows so their legs never share a row by accident, and keep your rails consistent across every project — red on top, black on the bottom, always. Muscle memory prevents reversed-polarity mistakes better than care does.

You already noticed this pattern and it is worth stating as a rule, because from here on almost every resistor you place is one of these three, and knowing which one tells you how to choose its value.

Job 1 — Current limiter

Placed in series with something that would otherwise take too much current. The classic case is an LED. An LED is not a resistor: once it reaches its forward voltage it conducts almost freely, so the current is set entirely by what else is in the loop. You size it with Ohm's law using the leftover voltage:

R = (V_supply − V_LED) / I_desired

For a red LED on 5 V: (5 − 2.0) / 0.015 = 200 Ω, so 220 Ω is the nearest standard value and that is why the kit ships so many of them. Blue and white LEDs drop about 3.2 V, so the same 220 Ω gives them less current and they look dimmer — that is expected, not a fault.

Job 2 — Pull-down (or pull-up)

A digital input pin that is not connected to anything does not read zero. It floats: it is a tiny capacitor with no one driving it, so it picks up mains hum and your hand's static and reports random values. A pull-down resistor ties that pin weakly to ground so it reads LOW when nothing else is happening, but weakly enough that when your button connects it to 5 V, 5 V wins. 10 kΩ is the standard compromise: strong enough to beat the noise, weak enough to waste almost nothing (5 V across 10 kΩ is 0.5 mA when the button is pressed).

A pull-up is the same idea, upside down: tie the pin to 5 V, and let the button connect it to ground. The pin then reads HIGH when idle, LOW when pressed. The ATmega328P has pull-up resistors built into every pin, which you switch on with pinMode(pin, INPUT_PULLUP), and that is why most of the later lessons in this manual use pull-ups: it is one fewer part and one fewer wire.

Job 3 — Half of a voltage divider

Here the resistor is not protecting anything, it is a reference. Two resistors in series across 5 V split that voltage in proportion to their resistances, and the point between them can be measured:

V_out = 5 V × R_bottom / (R_top + R_bottom)

This is how every resistive sensor in your kit is read: the photoresistor, the thermistor, the flame sensor. The sensor is one of the two resistors, the fixed resistor is the other, and the Arduino measures the point between them. Your tug-of-war picture is exactly right — the fixed resistor pulls the midpoint toward ground, the sensor pulls it toward 5 V, and the reading tells you who is winning.

The value of the fixed resistor sets where the circuit is most sensitive. The divider gives its biggest voltage change per unit of sensor change when the two resistances are roughly equal, so you pick the fixed resistor near the middle of the sensor's working range. A 10 kΩ photoresistor gets a 10 kΩ partner for exactly this reason, not by tradition.

Reading the bands

Four-band resistors: first two bands are digits, third is the number of zeros, fourth (gold) is tolerance.

brown black orange = 1, 0, +3 zeros = 10,000 Ω = 10 kΩ
red red brown = 2, 2, +1 zero = 220 Ω

Digits in band order: black 0, brown 1, red 2, orange 3, yellow 4, green 5, blue 6, violet 7, grey 8, white 9. When in doubt, measure it — but the gold band always goes on the right.

Four ideas that are constantly confused with each other, so it is worth separating them cleanly.

Digital output

digitalWrite(pin, HIGH) connects that pin to 5 V through a transistor inside the chip. LOW connects it to ground. There is nothing in between. The pin is a switch, not a supply — it can source or sink about 20 mA before its output voltage starts to sag, and it is permanently damaged around 40 mA.

Digital input

digitalRead(pin) compares the pin voltage against thresholds. On a 5 V ATmega328P, above roughly 3 V reads HIGH, below roughly 1.5 V reads LOW. In between is undefined — the pin will report something, but not reliably the same thing twice. This gap is exactly why floating inputs are a problem and why pull-ups and pull-downs exist.

Analog input, and what the ADC really does

Pins A0 to A5 feed an analog-to-digital converter. It compares the incoming voltage against a reference (5 V by default) and reports where it falls, as a whole number from 0 to 1023. That is 10 bits of resolution, so one step is 5 V / 1024 = about 4.9 mV.

volts = analogRead(pin) × 5.0 / 1023.0

Two things follow from this that catch everyone. First, the ADC measures voltage, not resistance — which is precisely why a bare sensor plugged into A0 does nothing useful, and why you always need the divider. Second, the reading is relative to the 5 V reference, so if your 5 V rail sags because a servo just started moving, every analog reading in your sketch shifts at the same moment. If your temperature readings jump whenever a motor runs, this is why.

PWM is not analog output

analogWrite(pin, 128) does not produce 2.5 V. It produces a square wave that is at 5 V half the time and 0 V the other half, switching about 490 times per second on most pins. The average is 2.5 V, and anything slow enough to respond only to the average — your eye looking at an LED, a motor's inertia, a speaker cone — behaves as if it received 2.5 V. Anything fast enough to see the individual pulses does not. Only the pins marked with a tilde (~3, ~5, ~6, ~9, ~10, ~11) can do this.

The value you pass is 0 to 255, which is 8 bits. Note the asymmetry that trips people up: analog in is 0–1023, analog out is 0–255. Converting between them, or to any other range, is what map() is for.

An LED is a diode, which means it conducts in one direction only. Wire it backwards and it will not light and will not complain — it just quietly does nothing, which is why a dead-looking LED is nearly always a reversed one. The long leg is the anode and goes toward positive; the short leg is the cathode, and the case has a flat spot on that side for when the legs have been trimmed.

When D13 goes HIGH, the pin is connected internally to 5 V. Current leaves the pin, passes through the resistor, through the LED, and returns to the GND pin. Around 2 V is dropped across the LED itself (this is the diode's forward voltage and it barely changes with current), which leaves about 3 V across the resistor. 3 V across 220 Ω gives 13.6 mA, comfortably inside what the pin can supply.

Remove the resistor and the arithmetic becomes ugly: the LED still insists on dropping only about 2 V, so the remaining 3 V appears across the wire and the pin's internal transistor, whose resistance is a few tens of ohms. Current shoots to a hundred milliamps or more. The LED may survive briefly; the pin may not.

Why delay() is a problem you will meet later. delay(1000) does not schedule anything. It parks the processor in a counting loop and refuses to do anything else for a full second. Nothing else in your sketch runs — no button is noticed, no sensor is read. This is fine for one blinking LED and completely unworkable the moment you want two things happening at once, which is why Lesson 13 replaces it with millis().

A four-legged tactile button is really two pairs of legs. Within a pair the legs are permanently joined; pressing connects one pair to the other. If your button seems always pressed, you have wired two legs that were already connected — use legs on opposite corners.

The floating input problem. Suppose you skip the resistor and wire only 5 V through the button to D2. Pressed, D2 sees 5 V and reads HIGH. Released, D2 is connected to nothing at all. It does not read LOW; it reads whatever charge happens to be sitting on it. The pin is a tiny capacitor with an extremely high input impedance, so the mains hum radiating through your body and the wire is more than enough to swing it back and forth across the logic threshold. You get a button that appears to work until you move your hand near it.

What the pull-down does. The 10 kΩ resistor to ground gives the pin a definite path to zero at all times. Released, no current flows through it (the input pin draws essentially nothing), so there is no voltage drop across it and the pin sits at a solid 0 V. Pressed, the pin is connected to 5 V through the button's near-zero resistance and to ground through 10 kΩ. Look at it as a voltage divider: R_top is near zero, R_bottom is 10 k, so the pin reads essentially the full 5 V. The button wins because it is far stronger.

Why 10 kΩ and not something else. Too large (say 10 MΩ) and it becomes too weak to overcome the noise it was meant to defeat. Too small (say 100 Ω) and it works fine, but pressing the button now burns 5 V/100 Ω = 50 mA straight to ground for nothing. 10 kΩ costs 0.5 mA and is immune to any noise you will meet on a desk.

Bouncing. A mechanical button does not close once. The metal dome flexes and makes contact several times over roughly 1–20 ms. The Arduino is fast enough to see every one of those as a separate press. If you are counting presses and the count jumps by three, you are seeing bounce, not a bug in your logic. The fix is to ignore any change that arrives within a few tens of milliseconds of the last one.

Nothing new electrically — this is Lesson 1 eight times — but two ideas appear that matter later.

Why every LED needs its own resistor. It is tempting to put one resistor on the shared cathode line. Do not. Resistors limit current, and a shared resistor limits the total. Turn on one LED and it gets the full 13 mA and is bright; turn on all eight and they share that current, so each gets under 2 mA and all eight are dim. Worse, LEDs of different colours have different forward voltages, so the one with the lowest forward voltage hogs the current and the others barely light. Individual resistors give each LED its own independent budget.

The current budget. Eight LEDs at 13.6 mA is 109 mA if they are all on at once. That is fine for the 5 V rail, but note the other limit that is not printed on the board: the ATmega328P has an absolute maximum of 200 mA total through all its pins combined, and a per-port limit of 100 mA. Eight LEDs is close enough to that per-port figure to be worth knowing about, and it is the reason Lesson 14 exists — a shift register drives LEDs from its own supply rather than from the microcontroller's pins.

Arrays. The reason to write int leds[] = {2,3,4,5,6,7,8,9}; instead of eight separate variables is not brevity, it is that an array turns "which LED" into a number you can compute with. Once the pin number is an index, a sweep is a loop, a bounce is a loop that counts backwards, and a random sparkle is a random index. The wiring did not get smarter; the addressing did.

Your kit has two buzzers that look nearly identical and behave completely differently. This one, the active buzzer, has an oscillator circuit built into it. Apply a steady DC voltage and it produces its own fixed tone — typically around 2 kHz — for as long as the voltage is there. You cannot change the pitch, because the pitch was decided at the factory.

Telling them apart. The active one is usually the taller of the two, is sealed on top, and if you briefly touch it across a 3 V coin cell it will beep. The passive one has an exposed disc visible underneath and will only click. If you check resistance with a meter, the active buzzer typically reads as an open circuit or a high value, while the passive one reads around 8–16 Ω like a small speaker.

The current question. A small active buzzer draws roughly 25–30 mA, which is right at the edge of what a pin should supply. It works, and every starter kit does it this way, but it is not a habit to generalise: this is the point where "drive it straight from a pin" stops being obviously safe. For anything hungrier, you switch it with a transistor and the pin only controls the transistor. That is the entire idea behind Lessons 16 and 17.

Buzzers also contain a coil, which means they are inductive: when you switch one off, the collapsing magnetic field briefly generates a reverse voltage spike. It is small enough here not to matter, but keep the phrase in mind — it becomes very important with relays and motors, where the same effect is large enough to destroy a transistor.

A passive buzzer is a piezoelectric disc with no electronics inside. A DC voltage makes it flex once and hold — a click, then silence. To get a sustained note you have to keep flexing it, which means feeding it an alternating signal at the frequency you want to hear.

tone(pin, 440) tells one of the ATmega's hardware timers to generate a 440 Hz square wave on that pin and then returns immediately. The timer keeps running in the background while your sketch carries on, which is why tone() does not block the way delay() does. It runs until you call noTone() or start a different tone.

Why this is not analogWrite(). Both produce square waves, and that is where the resemblance ends. PWM holds the frequency fixed (about 490 Hz) and varies the duty cycle — the proportion of time spent HIGH — because what you want to control is average power. tone() holds the duty cycle fixed at 50% and varies the frequency, because what you want to control is pitch. Try analogWrite() on a passive buzzer and you will hear one unchanging 490 Hz buzz that only changes volume slightly.

Notes are frequencies. Musical pitch is logarithmic: each octave doubles. A4 is 440 Hz, A5 is 880 Hz, A3 is 220 Hz. Each semitone multiplies by the twelfth root of two, about 1.0595. The pitches.h header that ships with the Arduino examples is just that table pre-computed, which is why every melody sketch includes it.

One limitation worth knowing. tone() uses Timer 2 on an UNO, and Timer 2 also generates PWM on pins 3 and 11. While a tone is playing, analogWrite() on those two pins will not behave. If your RGB LED misbehaves whenever music plays, that is the cause, and moving the LED to pins 5, 6, 9 or 10 fixes it.

A photoresistor is a strip of cadmium sulphide whose resistance falls when light hits it: roughly 1 kΩ in bright light, hundreds of kilohms in darkness. The Arduino cannot measure resistance. It can only measure voltage. So the entire job of this circuit is to convert a changing resistance into a changing voltage.

What happens without the 10 kΩ. Wire only 5 V through the LDR to A0 and the reading pins at 1023 in all conditions. The reason is that the ADC input draws almost no current — its input impedance is in the megohms. With no current flowing through the LDR, there is no voltage drop across it (V = I × R, and I is essentially zero), so A0 sees the full 5 V no matter what the LDR's resistance is. The sensor is doing its job; there is simply nothing to read.

What the 10 kΩ changes. Adding it to ground creates a complete path from 5 V through the LDR, through the 10 kΩ, to ground. Now current flows, now each resistance drops a share of the 5 V, and now the midpoint is a real number that moves:

V_A0 = 5 × 10k / (R_LDR + 10k)

Bright light, R_LDR = 1 k: V = 5 × 10/11 = 4.5 V, reading about 930.
Darkness, R_LDR = 200 k: V = 5 × 10/210 = 0.24 V, reading about 49.

The tug-of-war picture you had is exactly the mechanism: the fixed resistor pulls the midpoint toward ground, the LDR pulls it toward 5 V, and the reading reports the balance of the contest.

Which side to put the sensor on. Swap the LDR and the resistor and everything still works — but the reading inverts, going up in darkness instead of down. Neither is more correct. Pick one and know which you picked.

Calibrate, do not guess. Do not hunt for the "right" threshold number in a tutorial. Print analogRead(A0) to the Serial Monitor, cover the sensor, uncover it, note the two extremes in your room, and put your threshold between them. Those numbers depend on your specific LDR, your resistor's tolerance and your lighting, so nobody else's numbers are meaningful.

An RGB LED is three separate dies in one plastic package, sharing one leg. Which leg they share determines the type. In a common cathode part all three cathodes are joined and that leg goes to ground, so a HIGH on a colour pin lights it. In a common anode part all three anodes are joined and that leg goes to 5 V, so the logic inverts completely: 0 is full brightness and 255 is off.

How to tell which you have without a datasheet: wire the long leg to GND through a 220 Ω resistor and touch one of the other legs to 5 V. If it lights, you have common cathode. If nothing happens, try the long leg on 5 V and a short leg to ground instead. This takes ten seconds and saves an hour of confused debugging.

Colour is a timing trick. There is no circuitry inside doing colour mixing. Each PWM pin switches its die on and off hundreds of times a second, and your eye — which cannot resolve changes that fast — integrates the pulses into an apparent brightness. Three apparent brightnesses land on your retina from nearly the same spot, and your visual system reports a single blended colour. The LED is only ever fully on or fully off.

Why the colours never look right at first. Setting all three to 255 rarely gives clean white. Three reasons: the human eye is far more sensitive to green than to blue, so equal drive does not look equal; the three dies have different forward voltages (red about 2 V, green and blue about 3 V) so identical 220 Ω resistors deliver different currents; and brightness perception is not linear in drive. Fixing it means using different resistor values or scaling the channels in software. Reaching for a bigger resistor on the red channel is a legitimate engineering answer, not a hack.

Three resistors, not one. Same reasoning as Lesson 3, and here it is worse: a shared resistor on the common leg means the three colours steal current from each other, so the colour visibly shifts as you change any single channel.

A hobby servo is a closed loop in a box: a small DC motor, a gearbox, a potentiometer geared to the output shaft, and a control circuit. The potentiometer tells the circuit where the shaft currently is. Your signal tells it where the shaft should be. The circuit drives the motor in whichever direction reduces the difference, and stops when it reaches zero. This is why a servo holds its position against a push, and why it buzzes if you ask for an angle it cannot reach — it never stops trying to correct an error it cannot eliminate.

The signal is a pulse width, not a voltage and not PWM in the usual sense. Every 20 ms the servo expects a pulse. A pulse about 1 ms long means one extreme, about 1.5 ms means centre, about 2 ms means the other extreme. What carries the information is entirely the duration of the pulse; the gap between pulses just tells the servo you are still there. The Servo library generates these using a hardware timer, which is why it does not block your sketch and why it takes over PWM on pins 9 and 10.

Speed is not directly controllable. write(90) means go to 90 degrees, at whatever speed the servo can manage. To make motion look slow and deliberate you step the angle a little at a time with a short pause between steps, so what you are really controlling is the rate of change of the target, not the motor.

Power is the real gotcha. A servo's current draw is not steady — it spikes at the instant it starts moving and again if it meets resistance. That spike pulls the 5 V rail down for a moment, and everything else sharing that rail feels it. Symptoms: the Arduino resets when the servo starts, an LCD fills with garbage, or analog readings jump. The fix is a separate 5 V supply for the servo with its ground tied to the Arduino's ground, plus a large capacitor across the servo's supply if you have one.

The HD44780 controller behind this display is from 1980 and it shows, which is educationally useful: you can see the whole bus operating.

Why the wiring order looks scrambled. The display has eight data lines D0 to D7, but it can be operated using only the upper four. Each byte is sent as two nibbles, high half first, then low half. That is twice as many operations but it saves four Arduino pins, and the display is so much slower than the processor that the cost is invisible. In 4-bit mode D0–D3 are simply left unconnected, and the library's constructor LiquidCrystal(12, 11, 5, 4, 3, 2) reads as RS, E, then the four Arduino pins that connect to the display's D4, D5, D6, D7 in that order.

RS, RW and E. RS answers "is this byte data or an instruction" — a character to display, or a command like "clear" or "move the cursor". RW chooses read or write; you tie it to ground permanently because reading back from an LCD is almost never useful and it costs a pin. E is the clock: you place your bits on the data lines, then pulse E, and the falling edge is the moment the display commits to reading them. This pattern — set up data, then pulse a line to say "now" — is the same idea as the latch pin on your 74HC595 in Lesson 14. Once you see it, you see it everywhere in digital electronics.

Contrast is not brightness. V0 sets the bias voltage for the liquid crystal itself, which decides how dark the pixels appear against the background. It needs a fraction of a volt, adjustable, and the potentiometer supplies it. If V0 is left floating or at 5 V you get a blank screen; at 0 V you get a row of solid black boxes. Solid boxes on the top row is the display's way of saying "I am powered but nobody has initialised me" — so it usually means a data or E wire is wrong, not that the display is broken.

The backlight is a separate circuit. Pins A and K are just an LED behind the glass, electrically unrelated to everything else. It needs its own current-limiting resistor — many modules include one, many do not, and 220 Ω is safe either way.

The circuit is Lesson 6 with a different resistor in the top position, and that is the point worth noticing: every resistive sensor is read the same way. Once you own the divider, adding a new sensor is a datasheet problem, not a circuit problem.

NTC means negative temperature coefficient: resistance falls as temperature rises. "10 k thermistor" means 10 kΩ at 25 °C, which is also why the partner resistor is 10 kΩ — the divider is then most sensitive around room temperature, where you will be testing.

The hard part is that it is not linear. A photoresistor being non-linear does not matter much because "brighter" is usually enough. A temperature reading in degrees has to be right. The relationship between resistance and temperature is exponential, and the standard model is the Steinhart-Hart equation. The simplified B-parameter version is what almost every sketch uses:

1/T = 1/T₀ + (1/B) × ln(R/R₀)

with temperatures in kelvin, T₀ = 298.15 K (25 °C), R₀ = 10 kΩ, and B around 3950 for these parts. Subtract 273.15 at the end for Celsius. If your readings are consistently off by a few degrees, B is the number to adjust — it varies between manufacturers and the value is a specification, not a constant of nature.

Where the error comes from. Your 10 kΩ reference resistor probably has a 5% tolerance (gold band), so it might really be 9.5 k or 10.5 k. That error passes straight into the calculated resistance and then through a logarithm into your temperature. Measuring the actual resistor and putting the true value in your code is the single highest-value calibration step available to you. The ADC's own resolution, by contrast, contributes well under a tenth of a degree here — the reference resistor dominates.

Self-heating is real but small. Current through the thermistor warms it slightly. With a 10 k divider on 5 V you are dissipating well under a milliwatt, which is negligible. It becomes a genuine concern only with much smaller resistances.

You skipped this one and it is a five-minute build, but it earns its place because it makes the divider tangible: a potentiometer is a voltage divider whose two halves you can change by hand. The resistive track goes from leg 1 to leg 3; the wiper is a contact that slides along it. Turn the knob and you move the boundary — R_top grows as R_bottom shrinks, and their sum stays 10 kΩ. The wiper voltage sweeps smoothly from 0 V to 5 V.

Reading it and converting gives you a working voltmeter for the range 0–5 V:

volts = analogRead(A0) × 5.0 / 1023.0

Why 1023 and not 1024. The ADC reports 0 for 0 V and 1023 for a voltage at (or above) the reference. There are 1024 possible codes but only 1023 gaps between the endpoints, so dividing by 1023 makes full scale read exactly 5.00 V. Dividing by 1024 is defensible on other grounds and the difference is one part in a thousand; it is not worth an argument, but it is worth knowing why you see both.

The honest limitation. This voltmeter is only as accurate as its reference, and the default reference is your 5 V rail — which over USB is usually more like 4.7–4.9 V and moves around as the board's load changes. So the instrument's zero point drifts with whatever else your circuit is doing. Two fixes: measure the real 5 V with a multimeter and use that number in your formula, or switch to the internal 1.1 V reference with analogReference(INTERNAL), which is far more stable but limits you to 0–1.1 V unless you add a divider in front.

Measuring more than 5 V. Never put more than 5 V on an analog pin. To measure a 9 V battery you put a divider in front — two 10 kΩ resistors halve it, so 9 V becomes 4.5 V — and then multiply by two in software. That is the third resistor job doing exactly what it is for.

Your kit does not contain this module, so this entry is here for two reasons: so the lesson numbering matches the official course, and because the technique — measuring time to infer distance — is worth understanding even if you never buy the part.

The module emits a burst of 40 kHz sound, above human hearing, and listens for the reflection. Sound travels about 343 m/s in room-temperature air, which is 0.0343 cm per microsecond. The module raises its Echo pin for exactly as long as the sound was travelling, so:

distance = (echo duration in µs × 0.0343) / 2

The division by two is the part people forget: the sound made a round trip, out and back, so the pulse measures twice the distance to the object.

What is interesting here is that this is the first sensor where the information is carried by time rather than by voltage. No divider, no ADC. pulseIn() blocks the processor and counts microseconds until the pin changes, which makes it accurate and also makes it a poor citizen in a busy sketch — a reading that times out can stall you for a full second unless you pass a shorter timeout.

Why it is temperature dependent. The speed of sound rises roughly 0.6 m/s per degree Celsius. Between a cold room and a hot one the error is over 2%. If you ever pair this with your DHT11, you can correct for it — a genuinely satisfying two-sensor project.

Soft, angled or fabric surfaces scatter the pulse instead of reflecting it, so the module will simply see nothing. That is a limitation of the physics, not a fault.

Four digits of seven segments plus decimal points is 32 LEDs. Wiring each one individually would need 32 pins, which an UNO does not have. The display solves this with a matrix: the segment pins are shared across all four digits, and each digit has its own common pin that acts as an enable.

So the segment lines say what shape, and the digit commons say which digit gets it. Enable digit 1, put the pattern for "3" on the segment lines, and digit 1 shows 3 while the others show nothing — they are receiving the same pattern but are not enabled, so no current flows through them.

Multiplexing. You cannot show four different digits at once, so you cycle: light digit 1 with its pattern, turn it off, light digit 2 with its pattern, and so on, fast enough that your eye cannot follow. Above roughly 50–60 refreshes per second the flicker disappears and your visual system reports four steady digits. Nothing is steady; you are being fooled, deliberately and reliably. This is exactly the same effect that makes film and screens work.

The brightness consequence. Each digit is only lit a quarter of the time, so it is dimmer than a single digit driven continuously. This is why multiplexed displays often use lower-value resistors than you would calculate for a static LED — you are compensating for the duty cycle. Do not push it too far: the peak current during the on-quarter is what stresses the pins.

Why this is where millis() becomes non-negotiable. A stopwatch has to refresh the display roughly every 4 ms and keep counting time and watch for a button. Any delay() longer than a few milliseconds makes the display visibly flicker. The pattern that replaces it:

if (millis() - lastTime >= interval) { lastTime = millis(); ... }

You are not pausing, you are checking whether it is time yet, and returning immediately if not. The loop keeps spinning and every task gets a chance on every pass. Once you have written this once, delay() starts to look like what it is: a blunt instrument that only ever suits a program with one job.

Subtracting like that also survives the moment millis() overflows back to zero after about 49 days, provided you use unsigned long. The subtraction wraps correctly. Comparing millis() > target instead does not.

The 74HC595 contains two separate eight-bit registers, and understanding why there are two is the whole lesson.

The shift register is a chain of eight flip-flops. Each rising edge of SH_CP makes every stage hand its value to the next one down the line, and whatever is on DS at that moment enters the first stage. Eight clock pulses and eight bits later, your byte is sitting in the chain. But notice what happens during those eight pulses: the contents are being shoved sideways, one position at a time. If those stages drove the outputs directly, the LEDs would visibly scramble on every update — you would see the data marching across.

The storage (latch) register is the fix. It sits between the shift register and the output pins and holds its own separate copy. A rising edge on ST_CP copies all eight bits across in one instant. So the sequence is: shift in quietly, then latch once, and the outputs change cleanly and simultaneously. This is the same "set up the data, then pulse a line to say now" pattern as the LCD's E pin in Lesson 9.

What you are really trading. Parallel is fast and expensive in pins; serial is slower and cheap in pins. Eight outputs cost three pins here, and — this is the good part — sixteen outputs also cost three pins, because you can daisy-chain: connect QH' (pin 9, the overflow output) of the first chip to DS of the second, share the clocks, and now sixteen bits shift through. The pin count stops growing entirely.

OE and MR. Both are marked with a bar over the name because both are active low. OE (output enable) grounded means outputs are on; taken HIGH it puts all outputs into a high-impedance state, disconnected — useful for blanking a display instantly without touching the data. MR (master reset) tied HIGH means "do not clear"; pulling it LOW empties the shift register. Beginners leave these two floating and get random behaviour, so tie them deliberately.

Bit order and your digit table. shiftOut(data, clock, LSBFIRST, value) sends the least significant bit first. Because bits keep shifting along, the first bit sent ends up furthest down the chain — at QH — and the last bit sent stays at QA. So with LSBFIRST, bit 0 of your byte lands on QH and bit 7 lands on QA. Wire your segments in order QA to QH and the mapping between a byte and a shape is fixed by that geometry alone. The table you derived experimentally was never arbitrary; it is a direct consequence of your wiring order plus the bit order you chose. Switch to MSBFIRST and every entry in the table reverses, which is a satisfying thing to verify once.

There is nothing new inside this module — it is two 10 kΩ potentiometers mounted at right angles with a gimbal, plus a momentary switch under the stick. Moving the stick turns both wipers. You already understand every component; the interesting part is what you do with the numbers.

The centre is never 512. Springs return the stick to approximately centre, and approximately is the operative word. Your particular joystick might rest at 508 on one axis and 517 on the other, and the resting value drifts slightly with temperature and wear. Never hard-code 512. Read the resting value at startup and store it as your zero.

Dead zones are mandatory, not a refinement. Even at rest the reading jitters by a few counts from electrical noise and mechanical slop. Feed that straight into a motor or a cursor and it creeps constantly. The fix is to treat anything within about ±20 counts of your measured centre as exactly zero. Every game controller ever made does this.

Why SW uses the internal pull-up. The switch connects the SW pin to ground when pressed and to nothing when released — a floating input, which you know from Lesson 2 is unreadable. Rather than adding an external pull-up resistor, INPUT_PULLUP switches on a resistor of roughly 20–50 kΩ inside the chip. The logic inverts as a result: HIGH is idle, LOW is pressed. Slightly awkward to read, one less component to lose.

A useful shape for the reading. Mapping each axis to a signed range centred on zero, say −100 to +100, makes everything downstream easier: sign gives direction, magnitude gives speed, and zero means stop. That single conversion turns a raw sensor into a control input.

A relay is a switch operated by an electromagnet. Current through a coil makes a magnetic field, the field pulls a metal armature, and the armature drags a set of contacts across. The critical property is that the coil circuit and the contact circuit share no electrical connection at all — they are coupled only by a magnetic field across an air gap. That is why a 5 V Arduino can switch a much larger circuit without that circuit ever having a path back into the microcontroller.

The three terminals. COM is the common pole, the wire that gets switched. NO (normally open) is disconnected from COM when the coil is off and connects when it is on. NC (normally closed) is the opposite: connected at rest, disconnected when energised. "Normally" always means "with no power applied", and this matters for safety-critical design — you generally wire things so that the safe state is the unpowered state.

Why a bare relay cannot go on a pin, and what solves it

A relay coil needs roughly 70–80 mA. An Arduino pin can supply about 20 mA comfortably and 40 mA absolute maximum, so a coil is somewhere between two and four times over the limit. It also needs a flyback diode, for the reason below. A pre-made relay module contains both of those things — a transistor and a diode — which is exactly why modules exist.

With a bare relay and no transistor, the ULN2003 board that came with your stepper motor is the answer, and it is a genuinely good one rather than a workaround. That chip is seven Darlington transistor pairs, each rated 500 mA, with flyback diodes already built in. It is quite literally a chip designed for driving relay coils; relay driving is the first application on its datasheet. Your pin drives IN1 with about 1 mA, the Darlington pulls the other end of the coil down to ground, and the coil current flows entirely within the driver circuit.

The flyback diode

This is the piece worth carrying to every future project. An inductor resists changes in current. When you cut the current to a coil, the collapsing magnetic field tries to keep the current flowing, and to do so it generates a reverse voltage that can reach hundreds of volts for a few microseconds. That spike destroys whatever transistor just switched it off. A diode across the coil, reverse-biased in normal operation, gives that current a harmless loop to circulate in until it dies away.

Inside the ULN2003 these diodes all connect to one pin called COM, and on your driver board COM is already wired to the plus terminal of the power header. So as long as you power the board through its own power header, the protection is present and connected. You do not need to add a diode, and this is precisely why the ULN2003 lets you build this lesson without buying anything.

Why 6 volts and not 5

A Darlington pair does not switch all the way down to zero — it drops about 1 V while conducting. Feed the board 5 V and your coil only sees about 3.9 V, which is below the 75% of nominal that most 5 V relays need in order to pull in reliably. It may click, it may chatter, it may work on a fresh battery and fail on a tired one. Four AA cells give 6 V, the coil sees about 5 V, and it latches solidly every time. Try the Arduino 5 V pin first if you like, but if the relay is unreliable this is why, and it is not a wiring fault.

Finding the right output pin

The board only brings its outputs out through the white 5-pin plug. Nothing can be damaged by guessing, so find it empirically: power the board, set IN1 HIGH, and watch which of the four LEDs lights. Then move one coil wire between the plug's pins until the relay clicks. If you happen to land on the plug's common pin, both coil wires are on plus and nothing happens — harmless.

One board, one job at a time. The stepper motor uses the same four outputs through the same plug, so the stepper and the relay cannot both be connected at once. Plan around that, or buy a second ULN2003 board — they cost very little.

Mains voltage. Relays like this are often rated for it. Do not use yours for that unless you already know what you are doing with mains wiring, because the failure modes are not "the LED does not light". Switching a 12 V strip or a battery-powered lamp teaches exactly the same principles at no risk.

This is the lesson where "just plug it into a pin" finally stops working, and understanding exactly why is worth more than the project itself.

Three numbers. An Arduino pin can supply about 20 mA comfortably, 40 mA absolute maximum. A small DC motor running free draws around 100–200 mA. The same motor with the fan blade held still — stalled — draws far more, often 500 mA to over an amp, because a stalled motor is electrically just a short piece of copper wire. And a motor is stalled every single time it starts, for the first few tens of milliseconds, before it gets moving. So even a motor that "only" needs 150 mA hits the pin with a much larger surge at every switch-on.

Back EMF. A motor is a coil rotating in a magnetic field, which means it is also a generator. Spinning, it produces a voltage that opposes the one you applied — this is what limits its current at speed, and why current is highest at stall when there is no opposing voltage. And when you cut the power, the collapsing field produces the same reverse spike a relay coil does, only larger. Motors also generate constant electrical noise from their brushes sparking, which propagates down the power rails and upsets everything else.

So the pin must not carry the motor current at all. The pin's job is to carry information, and something else carries the power.

Why the ULN2003 is the right part for this

Your kit's driver board is seven Darlington transistor pairs in one chip. A Darlington is two transistors arranged so the first one's output drives the second's input, which multiplies their amplification: a microamp at the input controls hundreds of milliamps at the output. Each channel is rated 500 mA, and — crucially — the flyback diodes are already inside the chip, wired to the COM pin, which your board connects to the plus terminal of its power header. You own everything this circuit needs.

Low-side switching. Notice what the driver actually does: it does not connect the motor to the supply, it connects the motor to ground. The motor's other end sits permanently on plus. The switch is on the low side, between the load and ground, which is how nearly all simple transistor switching is done because it is easier to turn a transistor on when its reference is ground.

What it cannot do. It can only switch on and off. Reversing a motor means being able to swap which end is positive, and that needs four switches in an H-bridge (an L293D or L9110S). If you want the fan to run both ways, that is the part to buy.

Speed control, and stiction

Because a Darlington switches in microseconds, analogWrite() works properly here. The motor is far too slow to follow the individual pulses, so it responds to their average — exactly the PWM idea from the foundations section, applied to something with real inertia.

You will find the motor does not start below roughly 90–110 out of 255, but once turning it will keep going at a much lower value. That gap is stiction: static friction in the bearings and brushes is greater than sliding friction, so it takes more force to start moving than to keep moving. Every small motor has it, and a common trick is a brief full-power "kick" to break away before dropping to the speed you actually want.

Power

Do not run the motor from the Arduino's 5 V pin. The startup surge will drag the rail down and reset the board. Three AA cells give 4.5 V, the Darlington drops about 1 V, and your 3 V motor sees roughly 3.5 V — close to its rating. Four cells will run it faster and hotter.

The shared ground rule, concretely. Battery negative connects to the board's minus terminal and to an Arduino GND pin. Not because the Arduino needs the battery's current, but because "HIGH" and every other voltage in the system is measured against a zero that both circuits have to agree on.

Finding the right output pin

The outputs only come out through the white 5-pin plug. Power the board, set IN1 HIGH, and see which of the four LEDs lights. Then move the motor's black wire between the plug's pins until it spins. Landing on the plug's common pin puts both motor wires on plus, so nothing happens — nothing can be damaged by guessing.

If the chip gets hot or the motor stalls, parallel two channels: jumper IN1 and IN2 to the same Arduino pin and connect the motor's black wire to both OUT1 and OUT2. The current splits between two Darlingtons and your headroom doubles. Warm is normal; too hot to touch is not.

Keep the fan blade clear of fingers, and push it onto the shaft gently — forcing it can bend the shaft.

A DC motor spins when you apply voltage and stops somewhere unpredictable. A stepper does not spin at all in the usual sense — it moves in fixed increments, one per electrical pulse, so if you count your pulses you know exactly where the shaft is without any sensor. That is the whole appeal: precise position, no feedback loop, no encoder.

How stepping works. Inside are four coils arranged around a toothed magnetic rotor. Energise coil 1 and the rotor aligns to it. Energise coil 2 and it steps around to that one. Walk through the coils in order and the rotor follows. Reverse the order and it goes backwards. The speed is set entirely by how quickly you walk the sequence, and the position by how many steps you have taken.

The gearbox is why it is slow and strong. The 28BYJ-48 has a 64:1 reduction gearbox. Its internal motor makes 64 steps per revolution, so the output shaft needs 64 × 64 = 4096 half-steps, or 2048 full steps, for one turn. That is why it moves at a leisurely pace and why it has surprisingly good torque for its size. It also means one step of the output shaft is about 0.176 degrees, which is finer than you can see.

The pin order trap. With the Arduino Stepper library the constructor is Stepper(2048, 8, 10, 9, 11) — note that the middle two are swapped relative to IN1..IN4. This is not a typo. The library expects the coils in the order it energises them, and the ULN2003 board's IN numbering does not match that order. Wire it as IN1..IN4 to D8..D11 and swap the numbers in the constructor. If your motor buzzes and vibrates without turning, this is almost always the reason.

Open loop has a failure mode. Because nothing reports back, a stepper that is asked to move faster than it physically can will simply miss steps — and your code will never know. Your count and reality quietly diverge. If your project needs to be sure, you add a limit switch and return to a known home position occasionally.

Holding current. A stepper holds its position by keeping a coil energised, which means it draws current while doing nothing at all, and gets warm. If your application does not need holding torque, de-energise the coils when idle: it saves power and heat.

Your remote has an infrared LED in the end of it. It is a perfectly ordinary LED, just emitting at about 940 nm where your eye has no sensitivity. Point it at a phone camera and press a button — most phone sensors can see it, and you will get a free way to check whether the remote's battery is alive.

Why the light is flickering at 38 kHz. The world is full of infrared: sunlight, incandescent bulbs, your own body heat. If the remote just switched its LED on and off, the receiver could not distinguish it from the room. So the remote switches its LED on and off about 38,000 times a second, and the receiver contains a filter tuned to that exact frequency. Anything that is not flickering at 38 kHz is ignored as background. This is the same trick a radio uses: put your information on a carrier, and tune to the carrier.

So there are two layers. The carrier is the 38 kHz flicker, and the data is bursts of that carrier separated by gaps. A long burst might mean one, a short burst zero, depending on the protocol. The VS1838B does the hard part: it strips off the carrier and hands you a clean digital line that goes LOW during each burst. Your Arduino only has to time the pulses.

Protocols. NEC is the most common for cheap remotes and encodes 32 bits: an address, its inverse, a command, and its inverse. The inverted copies are an error check — if they do not match, the transmission was corrupted and gets thrown away. The IRremote library recognises the common protocols and hands you a code number per button.

Do not look up your remote's codes online. They vary between remotes that look identical. Run the library's receive-and-print example, press every button, write the codes down. That list is your remote's, and it is a five-minute job.

Range and interference. Expect a few metres, line of sight. Sunlight and some fluorescent or LED lamps produce enough 38 kHz-ish noise to reduce range significantly, which is a real effect and not a broken sensor.

Version warning. IRremote changed its API substantially at version 3. Sketches written for version 2 will not compile against version 3 and vice versa. If an example fails to compile, check the version before rewriting anything.

This is a different species from the thermistor, and the difference is worth dwelling on. Your thermistor is a passive component: it changes resistance, and you build the divider, read the ADC and do the maths. The DHT11 contains its own sensing elements, its own ADC and its own small microcontroller. It does the measuring and sends you a finished number.

The trade. You give up the ability to see inside and you gain simplicity — three wires, a library call, a number in degrees. This is the pattern for nearly every module you will ever buy: it packages the analog messiness behind a digital interface. Knowing how the thermistor works is what lets you understand what the DHT11 is doing on your behalf.

How the single wire works. The line idles HIGH, held there by a pull-up resistor (already fitted on your module version — you would need to add a 10 kΩ one yourself with a bare four-pin DHT11). The Arduino pulls it LOW for at least 18 ms to say "wake up and send me a reading", then releases it and switches to being an input. The sensor answers with 40 bits, encoding each bit as a HIGH pulse whose length means zero or one — about 26 µs for a zero, about 70 µs for a one. Both devices take turns on the same wire, which is why it is called a bidirectional bus.

The 40 bits are five bytes: humidity integer, humidity decimal, temperature integer, temperature decimal, and a checksum which is the sum of the first four. If the checksum does not match, the library returns a failure rather than a wrong number. That is why isnan() checks appear in every DHT sketch — occasional failed reads are normal and expected, not a sign of a broken sensor.

It is slow, and this is not negotiable. The DHT11 needs about two seconds between readings. Poll it faster and you get stale data or errors. The humidity element physically needs time to equilibrate with the air; this is a property of the sensor, not the code.

Accuracy, honestly. The DHT11 is the cheapest device in its class: roughly ±2 °C on temperature, ±5% on humidity, whole-number resolution, and a range of 0–50 °C. It is fine for "is the room humid", useless for anything demanding. Its sibling the DHT22 is several times more accurate for a little more money and wires identically.

Your Arduino already counts time with millis(), so why add a chip? Two reasons. First, millis() resets to zero every time the board is powered up or reset — it measures elapsed time since boot, not time of day. Second, it is derived from a ceramic resonator that is accurate to about 0.5%, which sounds fine until you work out that 0.5% is roughly seven minutes of drift per day.

What the crystal buys you. The DS1302 uses a 32.768 kHz quartz crystal. That odd-looking number is 2¹⁵, so a simple chain of fifteen binary dividers turns it into exactly one pulse per second — no arithmetic, just flip-flops. Quartz is used because it is piezoelectric and mechanically resonant: it vibrates at a frequency set by how it was cut, and that frequency barely changes with voltage or age. Typical drift is a few seconds a week rather than minutes a day.

The coin cell. The DS1302 draws under a microamp in backup mode, so a CR2032 keeps it running for years. Unplug the Arduino, come back tomorrow, and the time is still right. That is the entire point of the module — everything else it does, your Arduino could do.

The three-wire bus. Unlike the LCD's parallel bus, this sends one bit at a time. RST (better named CE, chip enable) must be held HIGH for the whole conversation; dropping it aborts the transfer. Each clock pulse on CLK moves one bit on DAT, and the same DAT wire is used for both directions — the chip switches from listening to talking partway through. This "assert enable, clock the bits, release enable" shape is exactly the same idea as the 74HC595's latch pin, and the same idea again in the SPI bus you will meet in Lesson 23. Three different chips, one recurring pattern.

BCD, and why the numbers look wrong raw. The DS1302 stores time in binary-coded decimal: each decimal digit gets its own four bits. The number 25 is stored as 0x25, not as 25 decimal (which would be 0x19). This is a convenience for driving digit displays directly, and a nuisance if you read the registers yourself — libraries convert for you, but if you ever see a clock reading 37 when it should read 25, you are looking at unconverted BCD.

Setting the time. Most sketches set the clock once from a hard-coded value, then comment that line out and re-upload. Leave it in and the clock resets to that fixed moment every time the board restarts, which is a confusing bug to chase because everything looks like it is working.

The microphone is an electret capsule: a thin diaphragm with a permanent electrostatic charge, so sound pressure changes its capacitance and produces a tiny voltage — microvolts to a few millivolts. Far too small for the ADC, which resolves 4.9 mV steps, so the module has an amplifier stage first. That is what the small IC on the board is for.

What the digital output really tells you. After amplification, a comparator asks a single question: is this signal louder than the reference level set by the trimmer potentiometer? Louder, and DO flips. That is all. It reports that a threshold was crossed, with no information about pitch, direction or what made the sound. A clap and a door slam are indistinguishable. Calling this a sound sensor is fair; calling it a microphone input is not.

Setting the threshold. The trimmer is not a volume control, it is the comparison level. Turn it until the onboard LED is just barely off in a quiet room, then test with a clap. Too sensitive and it triggers on your own breathing; too insensitive and only a shout works. It is a mechanical adjustment and it takes patience.

Why the analog output is less useful than it looks. Audio is a waveform oscillating hundreds or thousands of times per second. analogRead() takes about 100 µs, giving roughly 9,600 samples per second at best, and only if your loop does nothing else. By the Nyquist limit that caps you at about 4.8 kHz — enough for the general envelope of a sound, nowhere near enough to record or analyse speech or music. What you can usefully do with AO is measure loudness over a window: sample for 50 ms, take the difference between the highest and lowest readings, and treat that spread as a volume level. That works well and is the basis of any VU-meter project.

Detecting a clap properly. A clap is a sharp peak followed by silence, and it will trigger DO several times as the sound rings. Take the first trigger and then ignore the input for 200 ms or so — the same debouncing idea as the button in Lesson 2, applied to sound. For a double clap, look for two triggers separated by a gap in a plausible range, roughly 150 to 600 ms.

Start with the rule that matters. The RC522 is a 3.3 V device with no regulator on board. Connect its power pin to 5 V and you will destroy it, usually permanently and usually immediately. This is the most frequently killed module in kits like yours. Its signal pins tolerate 5 V logic well enough in practice, which is why the wiring above works without level shifters, but the power pin has no such tolerance.

How a card with no battery answers. The reader's flat spiral antenna transmits a 13.56 MHz field. The card contains its own coil, and a changing magnetic field through a coil induces a voltage in it — the same physics as a transformer. The card harvests that energy, powers its tiny chip, and replies by changing how much energy it absorbs from the field, which the reader detects as a change in its own antenna's load. The card is not transmitting in the usual sense; it is modulating its absorption. Range is a few centimetres because induction falls off very steeply with distance.

SPI, the fourth version of the same pattern. You have now met four buses. The LCD used eight parallel wires. The 74HC595 used shift-plus-latch. The DS1302 used enable-clock-data. SPI is that idea properly standardised: SCK is the clock, MOSI carries data from Arduino to module, MISO carries data back, and SS selects which device is being addressed. Data goes both ways simultaneously, one bit per clock edge. It is fast and it costs pins, which is the same trade you have seen every time.

On an UNO, SCK, MOSI and MISO are wired to fixed pins (13, 11, 12) because they connect to dedicated hardware inside the chip. SS and RST can be any pins. Multiple SPI devices can share the three bus wires as long as each has its own SS line — that is what chip select is for.

UIDs, and what they are not. Every card has a unique identifier, typically four or seven bytes, and reading it is what almost every project does. Be clear that a UID is an identity, not a secret: it is broadcast to anything that asks, and cloneable cards are sold openly. MIFARE Classic cards do have encrypted sectors you can write to, but the encryption was broken years ago. This is excellent for a project that recognises which fob is which; it is not a security system, and it is worth knowing the difference.

Soldering. These modules usually ship with the header strip loose in the bag. It has to be soldered on. Pressing a header into the holes and hoping is the source of most "my reader does not respond" reports.

By now you should be able to predict this circuit before reading it, and that is the point of including it: your kit's flame sensor is a bare two-legged photodiode, so it is read exactly like the photoresistor in Lesson 6. Same divider, same 10 kΩ, same analog pin. Three lessons, one circuit.

What is different is the physics of the part. A photoresistor changes resistance. A photodiode generates a current proportional to the light falling on it, and it is polarity-sensitive. It is used reverse biased — cathode toward the positive supply — which sounds backwards but is correct: reverse bias widens the depletion region inside the junction, making it a bigger target for photons and giving a faster, more linear response. Almost no current flows in darkness, and light produces a small current proportional to intensity. That current through your 10 kΩ produces the voltage you read.

Why it responds to flame specifically. This diode's lens is tinted to pass roughly 760–1100 nm, the near-infrared. Flames emit strongly there. So do sunlight, incandescent bulbs and your TV remote, all of which will trigger it — the sensor detects near-infrared, and "flame" is an interpretation you impose. A real fire detector uses two wavelengths and compares them, or looks for the characteristic flicker of a flame around 10 Hz. You could implement that flicker check yourself with the analog reading and a bit of maths, which would be a genuinely interesting project.

Getting the orientation right. If you cannot tell the legs apart, wire it up, note the reading, then reverse it and note the reading again. The orientation that gives a large swing when you bring a lighter near it (from a safe distance) is the correct one. Experiment beats guessing, and it costs nothing here because a photodiode is not damaged by being reversed at 5 V.

Safety. Test with a lighter or candle at arm's length, on a clear desk, with nothing flammable nearby. The sensor works from a surprising distance — you do not need to hold a flame close to it.

The board has two interleaved combs of copper traces. One comb is connected to the supply, the other through a resistor to the signal pin. Water bridges the traces, and because water conducts (thanks to dissolved ions, not the H₂O itself — genuinely pure water is a poor conductor), current crosses between them. The deeper the water, the more pairs of traces are bridged, the lower the resistance, the higher the voltage at the signal pin. It is a voltage divider whose top resistor is made of water.

It measures conductivity, so it measures the water too. Tap water, distilled water and salt water give different readings at the same depth. So do temperature and dissolved minerals. This means the sensor gives you a relative reading in your water, not an absolute depth in millimetres. Calibrate by dipping it to known depths in the actual liquid you care about.

The corrosion problem, and the good fix. Passing DC through water electrolyses it. Ions migrate, gas forms at the electrodes, and metal is stripped from the positive trace. Leave this sensor powered continuously in water and you can watch the copper visibly degrade within days.

The fix is elegant and worth internalising: do not power the sensor from the 5 V rail. Power it from a digital pin. Then your code turns the pin HIGH, waits about 10 ms for the reading to settle, takes the measurement, and turns the pin LOW again. If you sample once a minute, the sensor is energised for a hundredth of a percent of the time, and it lasts effectively forever instead of weeks. The sensor draws under 20 mA so a pin can supply it comfortably.

This trick — power a sensor from a pin so you can switch it — generalises to any sensor that degrades, drifts when warm, or wastes power in a battery project. It is one of those small techniques that separates a project that works from one that keeps working.

Keep the electronics dry. Only the striped trace area is meant to be wet. Submerging the header pins shorts things and corrodes the joints.

Inside the metal can is a small conductive ball and two contacts. Tilt it one way and the ball rolls onto both contacts, closing the circuit. Tilt it the other way and the ball rolls off. It is a switch operated by gravity, with no electronics whatsoever.

Wiring is identical to a push button using the internal pull-up: one leg to the pin, the other to ground, pinMode(2, INPUT_PULLUP), and LOW means closed. No external resistor, no polarity to get wrong.

What it can and cannot tell you. It reports one bit: past a certain angle, or not. It cannot tell you the angle, the direction of tilt, or how fast you moved. A mounting orientation is therefore a design decision — you choose which way to point it so that the transition happens where you want it. If you need real orientation, that is an accelerometer, a different part entirely.

It bounces badly. Much worse than a button. A rolling ball rattles as it settles, so a single tilt produces a burst of open-close transitions over tens of milliseconds. Reading it in a tight loop gives you dozens of false triggers. The remedy is the same as Lesson 2: ignore any change within, say, 50 ms of the previous one. Shaking the switch produces a rapid stream of transitions, and counting those transitions over a short window is actually a decent shake detector — turning the bounce from a defect into the measurement.

Where it is genuinely useful. It is a wake-up trigger. A battery project can sleep until motion occurs, using this switch on an interrupt pin (D2 and D3 on an UNO) to wake it. That is more valuable than it looks: the cheapest, lowest-power motion detector available.

Electrically this is Lesson 7 again, which makes it a five-minute build and a good chance to notice something about modules generally.

SMD means surface mount. Instead of legs pushed through holes, the component is a tiny block soldered onto pads on the surface of the board. Nearly all modern electronics is built this way — it is smaller, cheaper to assemble by machine, and better at high frequencies. The trade-off is that it is not breadboard-friendly, which is exactly why it arrives already mounted on a little carrier board with normal pins.

The dangerous assumption. A part arriving on a board makes people assume the board takes care of things. Sometimes it does — your ULN2003 board has flyback diodes built into the chip, your DHT11 module has its pull-up fitted. The KY-009 has nothing. It is an LED on a carrier, and without external resistors you will be driving three LED junctions straight from three pins.

So the habit worth forming: when you meet a new module, ask what it includes. Look for resistors near the pins, look for a regulator, look for a diode across any coil. If you cannot see them, assume they are not there and provide them yourself. Reading the small printed part number (KY-009 here) and searching for its schematic takes two minutes and settles the question.

A small practical note. The SMD emitter is physically tiny and very bright at close range, and the three dies are packed closer together than in the 5 mm through-hole LED. That makes the colour mixing look better from a short distance — the individual colours blend more convincingly. Put a scrap of paper or a ping-pong ball over it and the effect improves further.

Doing this after Lesson 13 rather than before is the right order, because now you can see plainly what the four-digit display was hiding. This is eight independent LEDs sharing one common leg, arranged in the shape of a figure eight. There is no controller, no decoding, no cleverness — you turn on the segments you want and a digit appears.

The lettering is a standard. Segment a is the top bar, then b, c, d, e, f run clockwise around the outside, and g is the middle bar. dp is the decimal point. Every 7-segment datasheet in the world uses this convention, which is what makes segment tables portable between projects.

Digits are patterns. The number 7 is segments a, b and c. The number 4 is f, g, b and c. Because the mapping is arbitrary from the processor's point of view, you store it as a lookup table — a byte per digit, one bit per segment — and displaying a number becomes an array index rather than ten branches of logic. This is exactly the table you derived for the 74HC595 in Lesson 14, and the reason it worked there is the reason it works here: the bit-to-segment relationship is fixed the moment you choose your wiring order, so any consistent order gives a valid table.

Determining the type. Two of the pins (usually 3 and 8, at the middle of each side) are the common, joined internally, so you can use either. Put 5 V through a 220 Ω resistor onto any segment pin and touch the common to ground. If a segment lights, it is common cathode. If not, try it the other way. Ten seconds, no ambiguity.

Worth doing next. Drive this display through your 74HC595 instead of directly. Eight segments is exactly eight outputs, so it fits perfectly, and it drops the pin cost from nine to three. That combination — shift register plus display — is the foundation of every multi-digit driver, including the four-digit module you already used.

Once a project works, you want it off the desk and off the USB cable. Understanding the board's power path makes that safe.

Two ways in, and they are not equivalent. The barrel jack and the VIN pin both feed the onboard regulator, but the jack passes through a reverse-polarity protection diode first. Wire a battery backwards into VIN and you can destroy the board; do the same into the jack and nothing happens. Use the jack.

The 5 V pin is an output, not an input. This trips people up. When the board is powered from USB or the jack, the 5 V pin supplies 5 V to your circuit. Feeding 5 V into that pin from an external supply bypasses the regulator and the protection entirely — it works, and it is what people mean by "powering through the 5 V pin", but there is nothing standing between your supply and the processor. A mistake there is not recoverable.

Why 7 to 12 volts. Below about 7 V the linear regulator cannot maintain 5 V and the board becomes unreliable in ways that look like software bugs. Above 12 V it overheats. The reason is what a linear regulator actually does: it burns off the excess as heat. It is not efficient, it is a controlled waste. At 9 V input with the board drawing 50 mA, the regulator is dissipating (9 − 5) × 0.05 = 0.2 W. Feed it 12 V and that becomes 0.35 W and the chip runs hot to the touch. This is exactly why 9 V is the sweet spot and why the regulator, not the battery, sets the upper limit.

A 9 V battery is a poor power source and it is worth being blunt about it. A PP3 alkaline holds around 500 mAh, and it delivers that only at low current. An Arduino with a couple of LEDs draws about 50 mA, so expect a handful of hours. Add a servo or a motor and you will be measuring the life in minutes. For anything that has to run, four AA cells in series give you 6 V with several times the capacity, or a USB power bank gives you regulated 5 V and far more energy — plugging a power bank into the USB socket is genuinely the most practical answer for a portable project.

Budget before you build. Add up the current: the board itself is roughly 45 mA, each LED 15 mA, a servo 100–250 mA while moving, a relay coil 75 mA, the RC522 about 25 mA. If the total approaches 400 mA you are at the limit of what a USB port or the onboard regulator will deliver, and things start browning out in confusing, intermittent ways. Motors and servos always get their own supply.