Bozoma Innovation Hub · Arduino Ladder
Facilitator Guide
For anyone running this course with a group: how a band is passed, what to collect, and the small number of faults that account for most of the trouble.
Learners do not need this page. It is for you.
What this course assumes
The pages carry the teaching. A learner working alone, with a kit and a laptop, can complete every band without asking anybody anything. That was the design goal and it is the standard every page is written to.
But one of the twelve pedagogy principles this course is built on cannot be delivered by a page, and that one is working together. Nor can the thing a person does that no page can: asking a learner a question at the moment they are about to go wrong. Those two need you.
The thin layer that makes it work
The design assumes a small amount of human contact around the self-paced pages:
- A build buddy each, so there is always one person to show something to
- Posting each band's build to a shared group as a condition of passing
- One code review swap per band
- A 60 minute clinic each week
That is roughly one facilitator hour per cohort per week, and in our judgement it is the difference between a course people finish and a course people start.
Every activity that needs another person also has a written alternative for a learner who genuinely has nobody. Nothing in the course is impossible alone. It is just harder, and slower.
How a band is passed
Four kinds of evidence, and all four are needed. There is no half a band. Band 8, the capstone, asks for a fifth: an honest evaluation against criteria the learner wrote before building.
The table below is the shape, not the list. Every band ends with its own Before you move on panel naming the specific artefacts it wants under each heading, and those are what you collect: the calibration walk in Band 4, the ruler-accuracy table in Band 7, the six PWM pin numbers in Band 2, the resistor values read off the board on a module build. Collect the band's list rather than this table, or you will miss the measurement work that is the whole point of Bands 4 and 7.
There is also no failing. The only two results are passed and not yet, and "not yet" always comes with the one specific thing that would change it.
| What they hand in | Passed when | Not yet when |
|---|---|---|
| The thing they built | It does everything on the list in the Make step, and the video shows it working start to finish | Something on the list is unmet, or the video is too short to show the whole behaviour |
| The build log | It names at least one real fault and what fixed it, and admits at least one guess they got wrong | It only describes the finished thing, with no history in it |
| Check yourself | Five of six correct, including the question marked as the important one | The marked question is wrong, however good the rest are |
| Explain it out loud | In 90 seconds they can point at one line of their own code and say why it is there and what would break without it | They narrate what each line does but cannot say why it is needed |
The nine questions that actually decide it
Each band's check has one question marked as the one that matters. Each goes after the exact wrong idea that its band exists to correct. A learner can pass everything else by pattern matching; they cannot pass these.
| Band | The question | The wrong idea it catches |
|---|---|---|
| 0 | Does loop stop when the light stops changing? | That a program with no visible effect has stopped running |
| 1 | Both LEDs are in backwards. Is that a code problem? | Reaching for the sketch when the fault is physical |
| 2 | Would the same sketch behave the same on pin 7? | That any pin can fade a light |
| 3 | One equals sign instead of two. What happens? | That = and == are interchangeable |
| 4 | An analog pin with nothing wired to it. What does it read? | That an unconnected pin reads 0 |
| 5 | A delay hidden inside a function | That using millis outside makes a sketch non-blocking |
| 6 | The knob is turned slowly back down and the arm will not follow it | That a deadband can compare a difference without abs |
| 7 | It is pointed out of a window at open sky, so no echo ever comes back. What does the device do? | That a missing timeout gives a wrong number, rather than silently stopping the whole board |
| 8 | A state the device enters, whose branch enterState never mentions | That having named states is by itself enough |
Moving faster or slower
- Already knows it. A learner may attempt any band's check and Make task cold. Pass both and they are awarded that band and everything below it.
- Missed a few weeks. Nothing is lost. Bands are passed on evidence, not attendance, so they resume where they stopped.
- The kit. If you run the loan model, Bands 0 to 7 use a loaned kit and completing Band 8 converts it to ownership. That is a completion incentive and an equipment recovery mechanism in one move.
The build log
One entry per band, written as they go, not afterwards from memory.
The most important part is what went wrong. A log with nothing broken in it is a log from somebody who copied, and it should be marked that way.
Band and date
What I set out to build. One sentence, in my own words.
My guesses, and which ones were wrong. Copied from the Guess step.
What went wrong. Every fault, including the embarrassing ones.
What I tried, in order. Including the things that did not work.
What fixed it, and why that worked. If I do not know why, say so.
What my tester said. Their words, not my summary.
One thing I would do differently.
A photo or video.
The faults that account for most of it
Bands 0 to 2 are almost entirely physical faults, visible in a photograph. From Band 3 the balance shifts and more of them are thinking faults, where the wiring is right and the code compiles and the thing still does the wrong job.
| Fault | What they see | Where it is covered |
|---|---|---|
| Charge-only USB cable | No port in the Tools menu; looks exactly like a dead board | Band 0, Part 11. The most common first-week fault of all. |
| LED in backwards | Nothing lights, nothing looks wrong | Band 1, Part 3. Turn it round before anything else. |
| No shared ground | A servo twitches, buzzes, or does nothing at all | Band 6, Part 7. One wire from the battery’s minus to an Arduino GND pin. The commonest fault in Band 6 by a wide margin. |
| LCD contrast wrong | A completely blank screen that looks dead | Band 7, Part 6b. Turn the knob or the blue screw end to end before checking anything else. Ask this first, every time. |
| Servo on the 5V pin under load | Board resets, or the arm moves in jerks | Band 6, Part 7. It needs its own battery once it has to push something. |
| Both legs in one column | Nothing lights, nothing looks wrong | Band 1, Part 11 checklist item 2. |
| Rail never reaches GND | All lights dead at once, everything else perfect | Band 1, Part 11 checklist item 5. |
analogWrite on a pin with no ~ | A fade that snaps instead | Band 2, Parts 2 and 8. |
| Two button legs from the same side | The button reads as pressed all the time | Band 3, Part 2. The diagonal rule fixes it permanently. |
| No debounce, or no edge detection | One press counts as several, or as thousands | Band 3, Part 9. Two different faults, two different fixes, easily confused. |
| Whole-number division | A calculation stubbornly gives 0.00 | Band 4, Part 9. |
| Mixing 0–255 with 0–1023 | A lamp that never gets bright | Band 4, Parts 2 and 6. |
A delay hidden inside a function | Timing looks right, the board still misses things | Band 5, Part 7. |
Reading a photograph of a breadboard
This is the thing a page cannot do and you can. Check these six, in this order, before you reply. Resist naming the fault until you have been through all six, because boards often have two.
- Does every LED have its long leg on the pin side?
- Does any component have both legs in the same column of five?
- Does the − rail actually reach a GND pin?
- Is anything sitting across the middle channel that should not be, or not across it when it should be?
- Are any bare legs touching each other?
- Is every leg pushed fully in, or is one resting on top of a hole?
Ask before you tell
From Band 3 onwards a learner starts being able to find their own faults, and that ability is worth more than any single fixed circuit. Three questions are usually enough:
- What did you expect to happen, and what happened instead?
- What does the serial monitor say? If the answer is "I did not look", that is the next step, not your diagnosis.
- What was the last thing that worked?
Preparing to run it
- Work through all nine bands yourself as a learner, handing in the same evidence you will ask of them. It is the cheapest quality control available and it produces your first set of worked examples. Band 5 especially: the
delaylesson is far easier to teach once you have watched it fail on your own bench. - Check the kits you actually bought. Band 3 needs an active buzzer, Band 5 needs a passive one, and Band 5 needs a full-size breadboard or two small ones. Every one of those has a documented fallback, but find out before a cohort starts, not during.
- Check the four late-band parts before Band 5 ends. Band 6 needs an SG90 servo and a four-cell AA battery holder; Bands 7 and 8 need an HC-SR04 ultrasonic sensor; Band 7 needs an LCD1602. The servo has no substitute and the band cannot run without it. The screen has two fallbacks: the four-digit TM1637 display project, which is a complete route through the band, or the serial monitor. Either one costs the band’s best design exercise, the sixteen-character writing, so ask for that on paper either way. Turn every LCD over and check which kind it is before Band 7 starts: those with a four-pin board on the back need the LiquidCrystal_I2C library installed, which needs internet once, and those without take twelve more wires. A cohort with a mix of both is normal and the band covers both paths in full.
- Set up the proof side before the first cohort, not after. Every band ends with a sixty-second video and a five-line post, and that artefact is both the band's evidence and the learner's portfolio piece. Decide three things now: where posts go, what the tag is, and who reviews a first post before it is public. The Show your work page carries the template and the consent checks. Get the first post out of every learner in week one, on whatever they have built by then, because the first one is the hard one and it gets harder the longer it waits.
- Do the part identification once, for the whole hub, and label the bags. Two components in these kits come in two kinds that look alike and behave completely differently: the buzzer (active or passive) and the RGB light (common cathode or common anode, and modules with or without their own resistors). The Which part have I got? page has two sketches that answer all of it in about twenty-five minutes. Doing this once saves every learner in the cohort a wasted evening, and it is the single highest-value hour of preparation on this list. Write the answers and the date on a slip of paper and put it in each box.
- Decide which alternative builds you are offering, and buy for those only. Most bands now have a second route: a keypad lock for Band 3, a rain alarm or a room monitor for Band 4, a stepper dial or a transistor fan for Band 6, a four-digit display for Band 7, and module versions of Bands 1 and 2. None is required. They exist so that six people and two keypads is a timetable rather than a queue, so that a kit without a servo does not close Band 6, and so that somebody working alone can do a band twice by two roads and find out what they actually understood. Each project page lists its own parts.
- If anybody is building the transistor fan, check there are diodes in the box. That build switches a motor about a thousand times a second and every switch-off throws a spike at the transistor. There is no visible symptom, so nobody will report it: parts simply wear out. If you have no diodes, direct those learners to the ULN2003 route on the same page, which has the diodes built in. This is the only build in the whole course where a missing part causes silent damage rather than a build that does not work.
- Budget consumables. LEDs and servos die, and jumper wires fail more often than anything else in the box, producing faults that look exactly like code bugs. Assume around 15% annual replacement.
- Test the cable. Charge-only USB cables cost more first-week hours than any other single thing. Check every cable before it goes in a kit.
The pedagogy underneath
The course is built on the Raspberry Pi Foundation's twelve principles of computing pedagogy. Rather than list them, here is where each one is actually enforced, so you can hold the course to them.
| Principle | The mechanic that delivers it |
|---|---|
| Add variety | Bronze, Silver and Gold tiers; open Make briefs; optional bounty builds using unused kit parts |
| Challenge misconceptions | The Guess step forces a commitment that can be wrong; each band has a planted bug and a marked check question |
| Create projects | Every band ends in a named artefact with success criteria and a real user |
| Foster program comprehension | Trace tables, shuffled-line problems, spot-the-bug and "explain this line" in every band |
| Get hands-on | A physical build in every band; craft housings in Bands 1, 2 and 5 |
| Lead with concepts | A Words to Know box per section and recall questions at the start of each band |
| Make concrete | Build briefs set in Aiyinasi: borehole pumps, poultry brooders, water tanks, market stalls, school bells |
| Model everything | A worked example in every band, including the debugging rather than a clean take |
| Read and explore code first | Nobody writes code before reading, predicting and explaining working code for the same idea |
| Structure lessons | The six steps are PRIMM fused with Use–Modify–Create, identical in every band |
| Unplug, unpack, repack | Step 1 unplugs the idea with rope, a door, a torch or a bottle cap; the Make brief repacks it |
| Work together | Build buddies, cohort posting, code review swaps and the weekly clinic. This is the one the pages cannot do alone. |