Module 4 - Engineering Practice

13. Practical Fault-Finding & Multimeter Skills

Set up the multimeter safely, check power, then signals, then code, prove each subsystem with a minimal test and keep a fault log.

Estimated time 2 sessions + optional extrasIn class Weeks 4–5 · Sessions 19 and 21

Learning outcomes

Set up a digital multimeter safely for DC voltage, continuity and resistance
Apply a power, then signal, then software fault sequence without guessing
Predict and measure expected HIGH/LOW and 5 V rail readings on an Uno
Isolate a project into subsystems and prove each with a minimal test
Keep an evidence-based fault log suitable for college practical work

Parts and preparation

Arduino Uno, USB data cable, digital multimeter with probes, breadboard, red LED, 330 ohm resistor, push-button (optional), jumper wires, and one previously built circuit or module to diagnose.

Before power: inspect wiring, confirm supply voltage and ensure all connected circuits share GND.

Practical Fault-Finding & Multimeter Skills instructional connection diagram

Why method beats guessing

Random rewiring wastes time and can create new faults. College practical work expects a repeatable process: state the symptom, remove power, inspect, measure, change one thing, then re-test.

Most Arduino faults fall into three layers: power/ground, wiring/signals, then software. Check them in that order. Uploading a fixed sketch while the 5 V rail is dead teaches nothing.

Three layers checked from the bottom up: 1 power and GND (5V pin reads about 5 V), 2 wiring and signals (continuity, HIGH/LOW), 3 software (a minimal known-good sketch); do not upload new code while the 5 V rail is dead — Power first, then signals, then software. Change one thing and re-test.

Fault-finding sequence

Use this order every time. Tick each step in your logbook before moving on.

Eight steps to tick off in order: observe, power off, inspect, power and GND, common GND, one signal, minimal sketch, rebuild, each marked power off or power on — Observe, power off, inspect, measure power/GND, check one signal, minimal sketch, rebuild.

Step	Action	Pass looks like
1. Observe	Write the exact symptom (what works, what does not, when)	Clear one-sentence problem statement
2. Power off	Unplug USB / VIN before moving wires or using continuity	Board fully unpowered
3. Inspect	Check polarity, breadboard rows, loose jumpers, shorts, correct pins	No obvious wiring errors
4. Power / GND	Power on; measure 5 V to GND; confirm ON LED if present	About 4.8-5.2 V on the 5 V pin
5. Common GND	Confirm every module shares GND with the Uno	Continuity (power off) or 0 V difference where expected
6. One signal	Measure one known input or output under a controlled sketch	Reading matches HIGH/LOW or expected analogue band
7. Minimal sketch	Test one device alone with the smallest known-good code	That device works in isolation
8. Rebuild	Add subsystems one at a time; re-test after each	Fault isolated to the last change

Multimeter setup and safety

A digital multimeter (DMM) is your main tool for proving electrical claims. Wrong range or wrong socket can blow the meter fuse or give nonsense readings.

Before every session: inspect probe tips, confirm the black lead is in COM, and put the red lead in the V/ohm socket for voltage, continuity and resistance. Use the dedicated high-current socket only when measuring current in series - and only if your tutor asks for it. This course focuses on voltage and continuity.

A multimeter with the black lead in COM and the red lead in V-ohm; the course uses DC volts with power on and continuity and resistance with power off, while AC volts is not used and current is tutor-only — Black in COM. Red in V/ohm for this lesson. Never probe mains.

Mode	When to use	Power on circuit?	Notes
DC voltage	Rails, pin HIGH/LOW, sensor divider voltage	Yes	Black on GND; red on the point under test
Continuity (beep)	Prove a wire/row connects two points	No - power off	Beep means low resistance path
Resistance (ohm)	Check a resistor or open path (careful)	No - power off	Remove or isolate the part if readings look odd
AC voltage	Not used in this ELV DC course	-	Do not probe mains
Current (A)	Advanced / tutor-led only	Yes, meter in series	Wrong connection can short the supply

How to measure DC voltage on an Uno

Set the meter to a DC range above 5 V (often 20 V). Black probe to Uno GND. Red probe to the test point.

Expected readings on a healthy Uno R3 (USB powered). Rows marked (later lessons) use parts you meet later - skip them for now.

Meter on DC volts with black on GND and red on the Uno's 5V pin reading 5.0 V, then expected readings: 5 V rail 4.8 to 5.2 V, D8 HIGH 4.5 to 5.0 V and D8 LOW 0 to 0.2 V, timed by the Serial messages — Rail first. Then match Serial HIGH/LOW phases on the worked sketch pin.

Test point	Typical reading	If wrong, check
5V pin to GND	About 4.8-5.2 V	USB cable, port, board power LED, short on 5 V rail
3.3V pin to GND	About 3.2-3.4 V	Regulator / board damage (less used in early labs)
Digital OUTPUT HIGH to GND	About 4.5-5.0 V	pinMode OUTPUT, correct pin, series load not shorting to GND
Digital OUTPUT LOW to GND	About 0-0.2 V	Code stuck HIGH; short to 5 V; wrong pin
INPUT_PULLUP open button pin	Near 5 V	Missing INPUT_PULLUP; wire floating
INPUT_PULLUP pressed to GND	Near 0 V	Button not to GND; wrong pin
Pot wiper (A0) mid-travel (later lessons)	Roughly mid-rail (varies)	Missing 5 V/GND on pot ends; wiper not on A0

Continuity and resistance (power off)

Switch power off and unplug USB before continuity or resistance tests. Measuring resistance on a live circuit can damage the meter and produce false values.

Useful checks: breadboard row continuity, jumper end-to-end, resistor value (330 ohm should read near 330 ohm out of circuit), and that two nets that should be separate are not shorted.

Unplug USB first; a beep means connected and OL means open; useful checks for a breadboard row, a jumper end to end and a 330 ohm resistor out of circuit; 5V to GND beeping means a short — Power off first. Beep means connected. 5 V shorted to GND must be fixed before power-up.

Symptom to likely cause

Match what you see to a first measurement before changing lots of wires. Rows marked (later lessons) cover sensors and motors - skip them for now.

Symptom	Likely cause	First check
Board dead / no power LED	USB/cable/port or short on 5 V	Measure 5 V to GND; try known-good data cable
Uploads but nothing happens	Wrong pin, missing GND, dead breadboard row	Continuity to the device; voltage on the driven pin
LED never lights	Reversed LED, missing resistor, wrong pin	Polarity; measure pin HIGH; check resistor in series
LED always on / pin hot	Short, no resistor, wrong polarity drive	Power off; inspect; add series resistor; stay within pin current
Button random / stuck	Floating input or wrong polarity test	INPUT_PULLUP; measure open vs pressed
Sensor stuck at 0 or 1023 (later lessons)	Open wire or rail short on divider	Measure divider mid-point voltage; confirm 5 V and GND
Motor resets the board (later lessons)	Motor current from USB/pin alone	External motor supply + common GND + driver
Serial garbage / silent	Baud mismatch or charge-only cable	Match baud; TX/RX LEDs; data cable
Works alone, fails when combined	Pin clash, shared bus conflict, power droop	Minimal tests; one module at a time; measure 5 V under load

Minimal test strategy

When a full project fails, do not debug everything at once. Unplug unrelated modules. Load the smallest sketch that only exercises the suspect part (this lesson's pin HIGH/LOW test, Blink, or a single-sensor Serial print).

If the minimal test passes, the device and basic wiring are fine - the fault is in integration (wrong pin define, shared pin, library conflict, timing, or power under load). If the minimal test fails, fix that layer before reconnecting the rest.

A failing full project is cut down to one LED on D8 with a known-good sketch; if it works the fault is in combining parts, so add them back one at a time, and if it fails fix that part first — Minimal pass means integration fault. Minimal fail means fix this layer first.

Practical evidence and logbook

Assessment marks depend on evidence, not luck. For each fault session record:

A filled-in fault log: the LED never lights, the guess of a reversed LED is wrong, D8 reads 4.9 V but the cathode row does not beep to GND, the jumper is moved from row 15 to row 14 and the retest passes — Write measurements with mode, probe points and value - not only what you think went wrong.

Log field	What to write
Circuit / version	Lesson or project name and date
Symptom	What failed, and what still worked
Hypothesis	What you thought was wrong before measuring
Measurement	Meter mode, points probed, value read
Cause found	The actual fault (be specific)
Correction	What you changed
Retest result	Pass/fail with a measured value if relevant
Photo (optional)	Clear shot of wiring labels and the meter display

Wiring and safe build sequence

Build a known-good LED test: Uno D8 -> 330 ohm -> LED anode; LED cathode -> GND
Set multimeter to DC volts; black probe on Uno GND; confirm about 5 V on the 5 V pin
Upload the worked sketch; measure D8 to GND during the HIGH message (about 5 V) and LOW message (about 0 V)
Power off; set continuity; confirm D8 jumper continuity to the resistor row and cathode path to GND
Optional: add an INPUT_PULLUP button from D2 to GND; measure open (about 5 V) and pressed (about 0 V)
Then diagnose a completed earlier project using the full sequence and log each step

Power rule: switch off before moving wires. Arduino I/O pins are control signals; high-current loads require a driver and suitable external supply.

Worked sketch

Download .ino

const int TEST_PIN = 8;

void setup() {
  pinMode(TEST_PIN, OUTPUT);
  Serial.begin(9600);
  Serial.println("Fault-finding pin test");
  Serial.println("Measure TEST_PIN to GND with meter on DC volts");
}

void loop() {
  digitalWrite(TEST_PIN, HIGH);
  Serial.println("HIGH - expect about 5 V on pin 8");
  delay(3000);

  digitalWrite(TEST_PIN, LOW);
  Serial.println("LOW - expect about 0 V on pin 8");
  delay(3000);
}

How the code works

TEST_PIN is a named constant so the driven pin is obvious in wiring and in the logbook.
Serial messages tell you when to take each meter reading so software and measurement stay in sync.
If Serial is silent but the pin still toggles, you can still measure; fix USB/baud separately.

Test and record evidence

Expected result: With the LED wired, it lights for about three seconds and goes off for three seconds. The meter on D8 to GND reads approximately 5 V during HIGH and 0 V during LOW. Serial prints match those phases.

Practical evidence checklist

Labelled wiring or block diagram Uploaded sketch and observed result At least one measured/tested value Fault or improvement recorded in logbook

Common faults and checks

No 5 V on the 5 V pin: fix USB/power before any signal tests.
Pin stays near 0 V on HIGH: wrong pin number, pin not set OUTPUT, or short to GND.
Pin near 5 V but LED dark: reversed LED, open breadboard row, or missing series resistor path.
Continuity always beeps between 5 V and GND: short - power off and find the bridge before powering again.
Readings jump wildly: poor probe contact, wrong meter range, or floating probe (keep black on GND).

Challenge (extension - optional): Partner exercise: one person introduces a single safe fault (open jumper, swapped LED, missing GND, or wrong pin in code). The other diagnoses it using the written sequence and completes a full log entry with at least one meter reading.

Check your understanding

Q1. In what order should you usually investigate an Arduino fault?

Show answer

Power and ground first, then wiring/signals, then software.

Q2. Can you measure continuity with the Uno still powered from USB?

Show answer

No. Remove power first.

Q3. Black probe on GND, red on a digital OUTPUT driven HIGH - roughly what should you read?

Show answer

About 5 V on a 5 V Uno.

Q4. Why use a minimal sketch when a big project fails?

Show answer

It separates a single device/wiring fault from integration and software interaction faults.

Q5. Name three fields that belong in a practical fault log.

Show answer

Examples: symptom, measurement, cause found, correction, retest result.

Code Along 9: Finding & Fixing Faults

Practise in your browser

Write and test this lesson's code on a virtual Uno. Work through the 6 exercises in order. Press Test and each one checks itself.

Exercises passed 0 / 6About 60-80 minOpen as its own page

Start from the symptom

Guessing wastes time and adds new faults. Work the same way every time:

Write down exactly what happens - the compiler message, or what the board does and does not do.
Decide which fault class fits that symptom.
Change one thing, then run it again.

The code-correction assessment asks for exactly this: a fault inventory written before you fix anything, and an explanation of each fault class. This chapter practises every class on its own, then all of them together.

Symptom	Likely fault class
expected ';' before ...	Missing semicolon on that line - the real IDE often points at the line just after it
'serial' was not declared	Capitalisation - C++ names are case-sensitive
expected '}' before 'else' / 'else' without a previous 'if'	Braces that do not match
Compiles with a warning; the if always or never runs	= used where == was meant
A button does nothing, or acts on its own	Pin mode does not match the wiring
Nothing lights, no errors at all	Pin number in the code does not match the circuit
Serial Monitor scrolls too fast to read	Printing every loop instead of on a change

Exercise 9.1

It will not compile

Not started

This start-up message will not compile. Press Run, read the first error only, fix that one fault, and run again. There are two faults. Do not change the text in quotes.

Sample output

Greenhouse controller
Starting up

void setup() {
  serial.begin(9600);
  Serial.println("Greenhouse controller")
  Serial.println("Starting up");
}

void loop() {
}

Turn on JavaScript to edit, run and test this code in the browser.

Exercise 9.2

Braces that do not match

Not started

The fan message should say Fan ON above 30 degrees and Fan OFF otherwise, but the sketch does not compile. Find the brace fault. The test also tries a temperature of 25.

Sample output

Fan ON

int temperature = 31;

void setup() {
  Serial.begin(9600);
  if (temperature > 30) {
    Serial.println("Fan ON");
  else {
    Serial.println("Fan OFF");
  }
}

void loop() {
}

Turn on JavaScript to edit, run and test this code in the browser.

Exercise 9.3

The tank that empties itself

Not started

This pump check compiles, but it prints the wrong level - the sketch is changing tankLevel itself. Read the compiler warning, then fix it so an empty tank (level 0) switches the pump off and any other level keeps it running.

Sample output

Pump running
Level: 40

int tankLevel = 40;

void setup() {
  Serial.begin(9600);
  if (tankLevel = 0) {
    Serial.println("Tank empty - pump off");
  } else {
    Serial.println("Pump running");
  }
  Serial.print("Level: ");
  Serial.println(tankLevel);
}

void loop() {
}

Turn on JavaScript to edit, run and test this code in the browser.

Exercise 9.4

The button is ignored

Not started

The LED should light while the button on pin 2 is held. The button is wired from pin 2 to GND, like every button on this course. The code compiles and looks right, but the LED does not follow the button. Find the one word that does not match the wiring.

const int BUTTON = 2;

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(BUTTON, INPUT);
}

void loop() {
  if (digitalRead(BUTTON) == LOW) {
    digitalWrite(LED_BUILTIN, HIGH);
  } else {
    digitalWrite(LED_BUILTIN, LOW);
  }
}

Turn on JavaScript to edit, run and test this code in the browser.

Exercise 9.5

Right code, wrong pin

Not started

No errors, no warnings - and the LED on pin 13 never lights. The circuit is correct and was checked with a multimeter. Compare the pin numbers in the code with the board, and fix the code to match the circuit.

const int BUTTON = 2;
const int LED = 12;

void setup() {
  pinMode(LED, OUTPUT);
  pinMode(BUTTON, INPUT_PULLUP);
}

void loop() {
  if (digitalRead(BUTTON) == LOW) {
    digitalWrite(LED, HIGH);
  } else {
    digitalWrite(LED, LOW);
  }
}

Turn on JavaScript to edit, run and test this code in the browser.

Exercise 9.6

Six faults, five classes

Not started

A garage parking light: the LED on pin 13 must be on while the car switch on pin 2 is closed (wired to GND). This sketch has six faults from five fault classes - the five the code-correction assessment covers: semicolons, capitalisation, braces, = versus == and pin mode versus wiring. One class appears twice.

Before you change anything, list each fault with its line number and fault class, the way the code-correction assessment asks. Then fix them one at a time, running after each fix.

const int SWITCH = 2;
const int Light = 13;

void setup() {
  pinMode(Light, OUTPUT);
  PinMode(SWITCH, INPUT);
}

void loop() {
  int switchState = digitalRead(SWITCH)
  if (switchState = LOW) {
    digitalWrite(Light, HIGH);
  else {
    digitalWrite(light, LOW);
  }
}

Turn on JavaScript to edit, run and test this code in the browser.

Try it on a real Uno

Download Six faults, five classes, upload the broken version and write your fault inventory on paper before fixing anything. Then wire a button from D2 to GND and prove the repair on real hardware.

Add one fault of your own - swap a pin number or delete a brace - and swap boards with a classmate. Time how long it takes each of you to find the other's fault by method rather than by guessing.

Want more? Code Along chapter 9 has a Deeper exercise that goes further than this lesson. It is optional.