Length
36 classes, 33 of them marked
Who builds
You do. One person, one device
Your client
A real group in this school, chosen by you, outside your own grade
Handing in
16 pieces, all to ManageBac
The end result
A device that works for a real person
Afterwards
You keep your device if you want it
What this unit isYou choose a real group of people in this school, from outside your own grade. They are your client. Your job is to find something they need, and to show that the answer has to be electronic. Then you research it, study four products that already exist, write down exactly what your device must do, draw it, build it, and test it with the people it was made for.
The unit is marked as sixteen separate tasks instead of four big ones. Each task has its own deadline and its own grade. That means one bad week does not ruin the whole project, and it means nothing can be left until the end.
Key Concept, Related Concepts & Global Context
| Key Concept | Related Concepts | Global Context |
|---|---|---|
| Development | Function, Innovation. | Scientific and Technical Innovation. |
Inquiry Questions
| Type | Question | Where it is answered |
|---|---|---|
| Factual | What does it mean for a device to sense, decide and act, and where is the decision in yours? | The two non-negotiables |
| Factual | What parts are available, and what does each one let a device do? | Aiii, with the Electronics Parts Catalog |
| Conceptual | How does a device's function change when it is developed for one specific group rather than for everyone? | Ai to Aiv, then Div |
| Conceptual | Why is iteration important in the design and prototyping process? | Bii, Cii and Civ, then Diii |
| Debatable | Is a problem that a pencil and a sticky note could solve ever worth solving with electronics? | Ai at the start, Dii at the end |
ATL Skills in Focus
Self-management: Organization, Research: Information Literacy
Where to hand your work in
Every task goes to ManageBac as soon as you finish it. Some tasks are also checked in class, such as the code conversation, the plan swap and the cold start test. You still upload what those produce. If it is not on ManageBac, it cannot be marked.
The plan for the 36 classes
This is the shape of the whole unit. Each row links to the task, so you can read ahead whenever you want to know what is coming.
| Class | Task | What you hand in |
|---|---|---|
| 1 | Launch | You choose your client group and get your board. First bench drill |
| 2–3 | Bench block | Basic electronics practice. Not marked |
| 4 | Ai | Need Statement, 1 page |
| 5 | Aii | Research Plan, 1 page |
| 6–8 | Aiii | 4 Black Box Cards and a summary page |
| 9 | Aiv | Design Brief, 1 page |
| 10 | Bi | Design Specification, 8 to 12 rules your device must meet |
| 11–13 | Bii | 6 labelled ideas and 2 breadboard tests |
| 14–15 | Biii | Three checks, a scoring table, and your reasons |
| 16–18 | Biv | Production Pack. Soldering lessons run at the same time |
| 19 | Ci | Build Plan, tested by a classmate |
| 20–29 | Build classes | You build. Covers Cii, Ciii and Civ |
| 30–31 | Di | Test Plan, with the test sheets you made |
| 32–33 | Dii | Client testing, then your results written up |
| 34 | Diii | Improvements, in order of importance |
| 35–36 | Div | Demo to your client, impact report and video |
The bench block: classes 1 to 3
These three classes are not marked. Everything in Criterion B assumes you can do them, so do not skip them. Each drill ends with something working on a breadboard. If you already know this, ask Mr. K for the harder version.
1Blink and measure
An LED, a resistor, a breadboard and your board. Then you measure the power with a multimeter and read the current.
Why it matters. Checking power and ground becomes a habit instead of a step you forget. The multimeter stops being scary.
2Sense, decide, act
An input goes in, such as a light sensor or a button. An output comes out, such as an LED or a buzzer. In between you set a threshold, which is the level where the device changes what it does. You pick that level, then you change it.
Why it matters. This is rule 1 of the unit, felt in your hands before you have to write about it.
3Break it and fix it
Mr. K breaks four circuits and four pieces of code. You work out what is wrong, using the steps below.
Why it matters. Finding faults is a method you can learn. It is not guessing, and it is not asking an AI the same question over and over.
Use this all year
The five steps for finding a fault
You will learn these in bench class 3. They stay on the wall for the rest of the unit. Write them into your bug diary in this order.
- What did I expect, and what actually happened? Say both clearly.
- Is it power, wiring, or code? Prove which one before you change anything.
- What is the smallest test that would tell me? Do that test only.
- Change one thing. Test it. Write down what happened.
- Now ask for help, and bring your answers to steps 1 to 4 with you.
Step 5 is also the rule for using AI. Asking a model to "fix this" before you have done steps 1 to 4 teaches you nothing, and your bug diary will show that you skipped them.
Two rules matter more than anything else in this unit. You will write both into your specification in Bi, and you will test both in Di and Dii. A device that breaks either rule cannot reach the top band, no matter how well it is made.
Rule 1
It senses, decides, and acts
All three parts are needed. If an input goes straight to an output, your device decides nothing. A button wired to an LED is not a design.
Your device must work something out on its own. That could be a threshold, a count, a timer, something it remembers, or a comparison between now and a moment ago. You must be able to point at that decision and say what would happen without it.
Rule 2
It works without you standing there
When you hand it over, your device has to work on your client's desk. No laptop plugged in. No serial monitor open on a screen. No wire held in place by your finger.
Nobody stands next to it explaining how to use it. It is in a case, labelled, switched on, and working. That is the difference between a real project and a demonstration.
The most common mistake
Building something nobody needed
The usual failure in an electronics project is a device that solves nothing. If a pencil, a label, a clock on the wall or an app your client already has would do the job better, then electronics is the wrong answer.
Catch this in Ai, where you will meet the sticky note test. Finding it in Dii, when the thing is already built, is far too late.
You may use AI to write your code. You are expected to. Nobody in this class is required to arrive knowing how to program, and the interesting design work is somewhere else. But Cii asks you to show excellent technical skill, and code you pasted in shows nothing about your skill. So the marks are in four places an AI cannot reach.
1. You design the behaviour first
In Biv you draw a state diagram. That is a map of every mode your device can be in, and what moves it from one to the next. You decide what the device does. The AI writes the code that does it. If you cannot draw the map, you do not have a design yet.
2. The code conversation
Twice during the build, Mr. K will point at three lines of your code and ask three questions. What does this line do? Why is it here? What breaks if I change it? It takes two minutes. Code you cannot explain is code you did not make.
3. The bug diary
You write down every fault you chase: what went wrong, what you thought was causing it, what you tried, what actually happened. An AI can write code for you. It cannot write the record of you finding your own mistake.
4. Hardware cannot be prompted
Wiring, soldering, power, how the case fits, whether a cable pulls loose. No AI helps with any of it. Three of the four skill areas in Cii are physical for exactly this reason.
None of this is a trap. You are being told all four in the first class, in writing, so you know where the marks are before you start. Use AI well and use it often. Just make sure you understand what it gave you, because you will be asked.
You choose a real client group. You argue that they need something, and that the something has to be electronic. Then you plan your research with a limited budget, work out what is inside four existing products without opening any of them, and pull everything together into one brief.
Your client. In class 1 you choose a real group of people in this school. They have to be outside your own grade. Grade 11 works. Grade 5 works. The teachers work. So do the library lunch crowd, the ESL support group, the after school care group, the front office staff, the art room and the PE storeroom. Pick a group you can actually get to, because you will be asking them questions in Aii and handing them a device in Div. Your client cannot be yourself, and it cannot be your own year group. No more than two students may choose the same audience, so decide early in class 1. Two people working on the same group is useful, because you can compare what you each found. Nine is not.
Explains and justifies the need for a solution to a problem for a client/target audience.
The word that matters here is justify. That means giving reasons a reader can check, not just saying what you think. If you only describe your client, you lose easy marks. Proving they need something is the task.
What goes on your page
- What the situation is now, with at least one piece of evidence you actually collected. Not something you assumed.
- Why this has to be electronic. What will your device sense, work out, or remember that a person, a sign, or a phone your client already owns cannot do as well?
- What happens if nobody makes anything. If the honest answer is "not much", you have not found the need yet.
How this task runs
One class with AI, one class with a pen
Class 1 is research, and you should use AI for it. Ask it what a group like yours actually does all day. Ask it for twenty problems worth solving in a school. Ask it to argue against your favourite idea. Ask it what a sticky note would fix. It is fast, it is tireless, and it will find angles you would not.
Take notes as you go, on paper or on screen. Those notes are yours to keep and you hand them in.
Class 2 is the writing, and laptops are closed. You write your need statement by hand, in the room, in one class. Nothing to look at except your own notes.
This is not a trap and it is not a punishment. It is the fastest way to find out whether the research went into your head or only through your screen. If you did class 1 properly, class 2 is easy. If you outsourced it, the blank page will say so, and it will say so now rather than in Dii when the device is already built.
Do this before you write
The sticky note test
Ask yourself one question: would a sticky note do this job? Or a pencil, a label, a sign, a clock already on the wall, or an app your client has on their phone.
If any of those works better, electronics is the wrong answer. You would be building a gadget and then looking for a reason.
A need passes the test when the problem involves sensing, timing, counting or remembering. Something has to be measured that a person cannot watch all day. Or counted, when a person would lose track. Or noticed at a moment when nobody is there to notice it. That is when electronics is genuinely the right answer.
Common mistake
Deciding what to build before you know why
Most people arrive already wanting to build a particular thing, then invent a need that fits it. So there is a rule: do not name a single component in your first draft.
If you cannot write your need statement without the word "sensor", you have written a product advertisement, not a need.
Constructs a detailed research plan, which identifies and prioritizes the primary and secondary research needed to develop a solution to the problem independently.
You are marked on the plan, not on the research itself. The word to notice is prioritizes, which means putting things in order of importance and being able to say why.
Two words you need. Primary research is where you collect the information yourself, by asking, watching or testing. Secondary research is where you read what somebody else already found out.
How this task works
Your research budget: 12 tokens
Every research activity costs tokens. You have 12. You cannot afford everything, so you have to choose, and choosing is the part being marked.
| Activity | Cost | Primary or secondary | What you get |
|---|---|---|---|
| Read a part page in the parts catalog and note what it can and cannot do | 1 | Secondary | What the hardware can really do |
| Any other reading: a datasheet, a repair video, a product page, a guide | 1 | Secondary | Background. Fast, but shallow |
| Questionnaire | 2 | Primary | Numbers, from a lot of people |
| Watching your client, with a plan for what you are counting | 3 | Primary | What people do, not what they say they do |
| Interview | 3 | Primary | Depth, from one person |
| Bench test: build a part on a breadboard and measure whether it does what you need | 3 | Primary | Whether your idea is possible at all |
| Focus group | 4 | Primary | People disagreeing with each other in front of you |
Two spending rules. Spend at least 4 tokens on people, or your plan is nothing but reading. Spend at least 3 tokens on whether it will actually work, meaning a bench test or two part pages. Otherwise your plan is only opinions, and you find out in build class 4 that your sensor cannot do the job.
What you hand in: one page, one row per activity
| What I need to find out | How | Primary or secondary | Cost | Order | What this lets me decide | When |
|---|---|---|---|---|---|---|
| Most people write 8 to 12 rows. The budget is what stops it becoming 20. | ||||||
Then write two short paragraphs underneath:
- Why this order? Which activity had to happen first, and what it allows you to start.
- What did you give up? Name what you could not afford, and say what could go wrong because you skipped it.
Analyses a range of existing products that inspire a solution to the problem in detail.
A black box is anything you can see the outside of but not the inside. Your job is to work out what must be in there, using only what the product does. You do not open anything.
Guessing from the outside is harder than unscrewing something, and far more useful. You will use the parts catalog to name the parts, so your guesses stay specific.
Build the cards in the Black Box Analyzer. It asks you for everything on the list below, draws your block diagram from the parts you name, and prints the four cards and the summary as one PDF.
Choose four products, one of each
- Something in this room, in your bag, or at home, that you can pick up and hold
- Something made for your client group, or that they could use
- Something with no screen, so it has to talk to you with light, sound, movement or vibration
- Something badly designed, chosen on purpose
What goes on each Black Box Card
- What it is, who it is for, what it costs, and how it gets its power.
- What it must be sensing, and your evidence. If it wakes up when you walk towards it, it is sensing something. Which sensors in the catalog could do that? Which ones can you rule out, and how do you know?
- What it must be deciding. Look for behaviour that a direct wire from input to output could not explain.
- What it does back, and which output does it.
- Your block diagram. A simple drawing: what goes in, what happens in the middle, what comes out. Name real catalog parts, so your guess is specific enough to be wrong.
- Power: mains, batteries or rechargeable, and what that choice forced the designer to do.
- Controls and lights: every button and every indicator, and what a user has to already know before they can use it.
- One sentence on what you would copy from this product, and what you would leave behind.
Check your guess. Many products have repair videos, or a page on iFixit, which is a website where people take products apart and photograph the insides. Find one if it exists, and record where you were right and where you were wrong.
Being wrong and saying so scores better than a vague card nobody can check. Do not keep your guesses vague to stay safe. Choose an answer, then go and find out.
The summary page
Compare all four products against the same list of questions. Then finish with three to five numbered design implications. Each one is a sentence in this shape: "Because..., my device should...".
Write these carefully. You will quote them again in Aiv and Bi.
What happens in each class
1One card together, then your first one alone
Mr. K models a full card on the board and checks it against a video. Then you do card 1, on something you can physically hold.
2Two more cards
The product for your client group, and the one with no screen. If you cannot get the real product, work from the catalog, the product page, the manual and videos.
3The badly designed one, then your summary
Card 4, then the comparison and your design implications. This class decides your grade for the whole task, so do not let it be rushed.
Develops a detailed design brief, which summarizes the analysis of relevant research.
Look at the word summarizes. This page pulls your research together. It does not contain measurable rules or numbers. Those go in Bi, next task.
Mixing these two up is the most common mistake between A and B. Your brief says what you learned. Your specification says what your device must achieve.
One page, with an evidence column
| Section | What goes in it | Where it came from |
|---|---|---|
| Your client | Who they are, and what matters about them here | Ai, Aii |
| The need | Said again, in one sentence | Ai |
| What your research showed | Three to five findings, about people and about hardware | Aii, Aiii |
| Design implications | Copied across from your Aiii summary | Aiii |
| What the device must do | What it must sense, what it must decide, what it must do. Where the power comes from. Where it will live | Aii, Aiii |
| Limits | Time, parts available, how much you can spend, the board you were given, the skills you have | Given to you |
| What you intend to make | One paragraph on what you will build and who for | All of the above |
The evidence column is not optional. Every claim points back to where it came from. If a row has no source, you have drifted away from your research and invented something.
Optional, if you want it
Write your last paragraph as the back of a box
Same information, laid out like real packaging: a product name, one line promising what it does, three bullet points, and a strip of specifications along the bottom. It forces you to be brief, and it looks good in your portfolio. The evidence table is still the part that gets marked.
Your research becomes a list of rules with numbers in it. Then a set of real ideas. Then one chosen design that has survived three hard checks. Then drawings good enough to build from. This is the longest criterion in the unit, and it decides whether the build goes smoothly or badly.
Develops detailed design specifications, which explain the success criteria for the design of a solution based on the analysis of the research.
A specification is a list of rules your device must meet, each one written so it can be measured. This is the most important page you will write all year.
In Dii you test your device against this page, line by line. In Di you build a test for every row. The time you spend here saves you time twice later. Write 8 to 12 rows.
| # | The rule | How I will know it passed | How I will test it | Where it came from |
|---|---|---|---|---|
| 3 | Runs all day on its battery | At least 8 hours from one charge | Measure the current it uses, then run it until it dies | Aiii implication 2 |
| 7 | A Grade 6 can use it without being taught | 4 out of 5 first time users finish the main task with no help | Cold start test, counting wrong guesses | Ai, Aii interview |
Two examples, to show the shape. Notice the numbers. You could argue about either row afterwards, but neither one can be faked.
You need at least one rule in each of these areas
| Area | The question it answers |
|---|---|
| Suits the client | Does it fit the people on your card |
| What it does | What it senses, what it decides, what it does |
| Talking to the user | How does someone know it heard them, and know what it is doing now |
| Power | What it runs on, and for how long |
| Size and shape | How big, how heavy, where it sits or mounts |
| Reliability | How often it is allowed to fail, and what happens when it does |
| Safety | Voltage, heat, sharp edges, batteries, small parts |
| Cost | Total build cost, with a limit you set |
| Can you build it | Possible with the skills, tools and time you actually have |
Three rules for this page
What makes a row count
- If you cannot measure it, it is not a specification. "Responsive" fails. "Reacts within 0.5 seconds, tested 20 times" passes. Every row needs a number.
- Write the test column now, not later. In Di you turn these into real test sheets. Writing the test now is what stops you setting a rule that nobody could ever check.
- Link every part you name to its catalog page. For example tools/electronics/#hc-sr04. If a rule depends on a part, point at what that part can really do. It keeps you honest about the hardware.
Coming soon
Specification builder
Build your table row by row. It warns you when a row has no number in it, and reminds you when a row has no test.
Develops a range of feasible design ideas, using an appropriate medium(s) and detailed annotation, which can be correctly interpreted by others.
Two words from the descriptor. Feasible means it could actually be built. Annotation means the notes you write on the drawing, and those notes are the part that earns the marks.
Three parts to this task: a card draw that forces variety, six labelled ideas, and two ideas you actually test on a breadboard.
Part 1
The double draw
You draw two cards, one from the input pile and one from the output pile. Then you invent an idea that uses both. Do this three times.
| Inputs (what it notices) | Outputs (how it responds) |
|---|---|
| Something the user does on purpose: a button, dial, slider, joystick or switch | A screen |
| Something about the room: light, temperature, humidity, sound | Light, one LED or a whole strip |
| Something about a person: are they there, are they moving, how close, are they touching it | Sound |
| Something about an object: tilted, magnetic, heavy, vibrating | Movement, using a servo or a vibrating motor |
| Time itself: how long, at what hour, how many times | Sending information somewhere else, by USB or wireless |
Across all your ideas you must use at least three different input rows and three different output rows. This is what stops you handing in six versions of the first thing you thought of.
Part 2: six ideas, four things on every sheet
Use the A3 template, so your notes have room. Put these four in the same place on every sheet, so it becomes automatic.
- Block diagram. What goes in, what happens in the middle, what comes out, with real catalog parts named. The middle box says what gets decided. Writing "ESP32" there tells the reader nothing.
- Sketch of the object. Roughly to scale, in the place it will live. Show what it mounts to, and how big it is next to a hand.
- Three frame storyboard. What the user does, what the device does back, and what state it is left in. This catches devices that work but that nobody can understand.
- Your notes, explaining how this idea helps your client, and pointing at your Bi rules by number. Plus one risk: the part most likely to fail, and why you think so.
Drawing by hand is usually better here. You will write more notes by hand than you will on a computer, and the notes are what is marked. Digital is fine if your notes are just as full.
Practice and evidence at the same time
The interpretation test
Swap sheets with a classmate. Using your block diagram alone, and with you saying nothing, they have to tell you which pin on the board each part connects to, and what the code would check first.
You write down everything they could not answer. That list gets handed in with your ideas.
It is your evidence for "can be correctly interpreted by others", which is otherwise almost impossible to prove. Saying "my drawings are clear" proves nothing. A list of what a real reader could not work out proves a lot.
What happens in each class
1Draw cards, make ideas fast
Three draws, several quick ideas each, no neatness required. Quantity first. Check your input and output coverage before you start making anything look good.
2Develop and annotate your best six
Onto the A3 template, with all four required parts on every sheet. This is the class where the notes get written, so do not spend it colouring in.
3Breadboard tests and the swap
Twenty minutes on each of your two riskiest parts, then swap sheets for the interpretation test. Both halves produce work you hand in.
Presents the chosen design and justifies fully and critically its selection with detailed reference to the design specification.
Most people write "I picked this one because it is the best" and stop. That is a 3-4. The word critically means you also have to say what is wrong with your choice.
Two things fix this. First, three technical checks that your idea has to survive, so the decision is not just about which drawing looks nicest. Second, a section where you argue against your own winner.
Part 1
Three checks every idea must survive
Run your three best ideas through all three checks, and show your working. You may still choose an idea that failed a check. But then you must say exactly how you will fix it, by when, and what it will cost.
| Check | What you do | What usually goes wrong |
|---|---|---|
| Pins | Give every part a specific pin on your ESP32-S3 SuperMini. Use the pin tables in the catalog and the MacroPad Builder | More parts than pins. Two parts on one pin. Something on a boot pin, which is a pin that controls how the board starts up |
| Power | Add up how much current every part uses at its worst, and compare that with what your supply or battery can give. Then estimate how long it will run | Servos and LED strips. Nearly every time |
| Parts | Check every part is in this room, in the catalog, or can be bought. If it must be bought, write the price and how long delivery takes | Something that has to ship from another country while you are in week three |
The power check teaches you the most. Discovering that your five servos need more current than a USB port can give is a real lesson, and no amount of sketching would have taught it to you.
Part 2: the scoring table
Score your three best ideas against every rule on your Bi page. Some rules matter more than others, so give each rule a weight, meaning a number showing how important it is. Then explain each weight in one sentence.
The weights are what gets marked, not the adding up. You chose those numbers, so you have to defend them.
Part 3: your reasons, one to two pages
- Why your chosen design wins, pointing at your Bi rules by number.
- The argument against it. What does it do worse than the ideas you rejected? What are you giving up? Without this section you cannot go above 5-6, so do not skip it to look confident.
- What you took from the rejected ideas and moved into the final one.
- What is still unsolved, including any check you have not passed yet, and how the build will deal with it.
What happens in each class
1Run the three checks
Bench work and arithmetic on all three of your best ideas. Expect at least one idea to die here. That is the point of checking before you choose, rather than after.
2Scoring table and writing
By now the checks have probably decided more than the scoring table will. If so, say that in your writing. A scoring table that only confirms what the power check already ruled out is doing no work, and noticing that shows exactly the judgement this task is asking for.
Develops accurate and detailed planning drawings/diagrams and outlines requirements for the creation of the chosen solution.
"Planning drawings" is not one drawing. It is a whole pack of them, and together they let you build without stopping every ten minutes to decide something you should have decided already.
| Page | What is on it | Why you need it |
|---|---|---|
| Block diagram | Your final version, every part named, every connection labelled | The one page that shows your whole design at a glance |
| Circuit diagram | Proper symbols, every component, every value, power and ground drawn in | The drawing a real electronics designer makes |
| Wiring list | A table: which board pin, which part, what kind of signal, what colour wire, and any resistor in that line | This is what you follow at the bench, and it is what makes your wiring markable |
| State diagram | Every mode your device can be in, what it does in each one, and what event moves it to the next | The most important page in the pack. See below |
| Code plan | The steps for each mode, written in plain English before you write real code. Plus which code libraries you need and what each does | This is what you hand to an AI. It writes the code; you designed the behaviour |
| Case drawings | Front, side and top views, with measurements. A title block. Every hole for connectors, buttons and screens, placed and sized | If the holes are wrong, the case does not close |
| Parts list | Every part, a link to its catalog page, how many, where from, price each, total, and delivery time | Cost is one of your Bi rules, so it needs a real page |
| What you need | Tools, machines, materials, how long each stage takes, and what must be ordered or printed first | This turns straight into your Ci plan |
| Test points | Where to touch a multimeter probe to check each power line and each signal | Decide this now and fault finding gets far easier later |
The page that matters most
Why the state diagram beats the circuit diagram
A state is one mode your device can be in. Waiting. Measuring. Alarming. Setting up. A state diagram draws all of them as boxes, with arrows showing what moves the device from one box to another.
This page is the answer to the AI question. If you can draw every mode and every arrow, you have done the design work. An AI writing the code afterwards changes nothing about that.
If you cannot draw it, you do not have a design yet, and this is the right week to find that out. Fixing it now costs you a redrawing. Finding out in build class 6 costs you the build.
Mr. K will show you three examples first: a device with two modes, a device with a settings mode, and one that gives up and goes back to sleep after a while.
| Lesson | What you learn | To be signed off |
|---|---|---|
| 1 | Looking after the iron, tinning it (coating the tip in solder), how much heat and how long. What a good joint looks like next to a cold one and a bridge (solder accidentally joining two things that should be separate) | Five joints on scrap board, checked by Mr. K |
| 2 | Keeping rows of pins straight, soldering wire to a pad, heat shrink (plastic tube that shrinks tight when heated), and strain relief (anchoring a wire so pulling it does not break the joint) | A three wire connector that survives a firm pull |
| 3 | Removing solder, fixing a bridge, and rescuing a lifted pad, which is when the metal ring around a hole tears off the board | Repair a joint that Mr. K has ruined on purpose |
If you cannot solder safely, you do not have to. Screw terminals, crimped connectors, plug-in leads and pin sockets earn exactly the same marks in the wiring skill area. You can build a whole device with no solder in it. Everyone gets taught soldering, but nothing in the marking requires it.
Coming soon
Power calculator and pin planner
Add your parts and see the worst case current, how much spare capacity your supply has, and roughly how long it will run. The pin planner does the same job for pins, and catches two parts sharing one before you get to the bench.
What happens in each class
1Block diagram, circuit diagram, wiring list
The electrical half of the pack. Soldering lesson 1 runs at the bench.
2State diagram and code plan
The behaviour half. This is the class that decides whether your build is designed in advance or made up as you go. Soldering lesson 2.
3Case, parts list, requirements, test points
The physical half plus the paperwork. Anything with a long delivery time must be ordered by the end of this class. Soldering lesson 3, and everyone gets signed off.
One planning class, then ten classes of building. You hand in Ci before the build starts. Cii, Ciii and Civ all happen while you build, and you collect the evidence as you go. Leaving them until the end does not work, and it is obvious when you try.
Three things happen in every build class. You reread your specification at the start. You run the power check before you switch anything on. You spend the last five minutes writing your change log. Each takes almost no time, and each one is worth marks in a different task.
Constructs a detailed and logical plan, which describes the efficient use of time and resources, sufficient for peers to be able to follow to create the solution.
Ten build classes to fill, and one person filling them. The columns below are the same for everyone. Your grade comes from what you write in them, not from how the table looks.
| # | Task | Class | Time | What I need (parts, tools, machines) | Can't start until | Finished when | If it goes wrong |
|---|---|---|---|---|---|---|---|
| One row per task. Most of these rows come straight off your Biv requirements page. | |||||||
Four things your plan must have
- Your critical path, marked. That is the chain of tasks that decides your finish date. If one of those tasks is late, everything after it is late too.
- Order deadlines. Anything you buy, print or send to a machine gets a class number by which it must be started. Waiting time is a resource, the same as glue or wire.
- A "finished when" on every row. If a task has no finish condition, nobody can follow it. "Work on the case" is not a task.
- A backup plan on every critical path row. The printer queue is full. The part has not arrived. The sensor does not do what your bench test promised.
Know this before you write
What each band actually looks like
| Band | What the plan looks like |
|---|---|
| 1-2 | A list of jobs, in no particular order, with no times |
| 3-4 | In order and with times, but vague about what you need, and nothing depends on anything else |
| 5-6 | Properly ordered, with real dependencies and named resources. A classmate could mostly follow it |
| 7-8 | All of that, plus a marked critical path, order deadlines, finish conditions, and backup plans that show you thought about what will really go wrong |
Notice that the gap between 5-6 and 7-8 is four specific additions. It is not "try harder". Add those four things and you have moved a band.
Coming soon
Build planner
Enter your tasks, times and dependencies. It marks your critical path automatically, and flags any row with no finish condition or no backup plan.
Demonstrates excellent technical skills when making the solution.
Technical skill is not only about making things by hand. Choosing the right part is a skill. So is wiring that somebody could repair later. So is a screen a Grade 6 can read from across a desk. There are four skill areas.
Circuits and wiring
- Tidy breadboard habits, and always checking power and ground
- Wiring that is colour coded, cut to the right length, and anchored so pulling does not break it
- Choosing the right resistor, and showing the arithmetic
- Adding a capacitor to steady the power where it is needed
- Using a multimeter at your test points to prove a wire really is carrying what you think
Breadboard, jumper wires, resistors and capacitors, multimeter
Soldering and assembly
- Clean solder joints
- Planning the layout of your board before you solder it
- Soldering pin headers and connectors
- Heat shrink and strain relief
- At least one connector you can unplug for repairs without cutting anything
Soldering irons, stripboard, pin headers, plug-in leads, heat shrink
Code and logic
- Your Biv state diagram actually working as code
- Debouncing a button, so one press does not register as five
- Timing that does not freeze everything else while it waits
- Turning a raw sensor number into something meaningful
- Keeping your calibration numbers in one place, not scattered through the file
- At least one fault you found by testing a theory, not by asking an AI again
Your board, a laptop, and AI
Controls and case
- Putting buttons where a hand naturally reaches
- Labels you can read from the distance the device is actually used at
- Feedback the user notices without being told to look for it
- Holes that line up with what goes through them
- How it fits together, how it is finished, and what the edges feel like
3D printers, small laser etcher, art supplies, printer
Your evidence
The making log, and why it needs a failure in it
For each of your three skills, hand in three things. A dated photo of the work in progress, with your hand or your initials visible on it. A photo of the finished result. And a note saying what went wrong, what you changed, and what the second attempt did better.
Here is the reason. Excellent skill has to be excellent compared to something. One tidy photo shows a good result, but it does not show skill. A bad first attempt next to a fixed second attempt shows both. The note is what gets marked. The photos are only proof.
So do not hide your mistakes. In this task they are worth marks.
Two more pieces of evidence, both about your code
The bug diary
You keep this through all ten build classes. One entry every time you chase a fault, using the five steps: what you expected, what happened, whether it was power, wiring or code, the smallest test, what you changed, what happened next. Date every entry. This is the best evidence of skill in the whole unit.
The code conversation
Build class 4 and build class 9. Two minutes. Mr. K points at three lines of your code and asks what each one does, why it is there, and what would break if he changed it. You know it is coming and you know which classes it is in, so there is no surprise.
About the machines. The 3D printers and the small laser etcher are reliable. The big laser cutter is not, so nothing in your plan may depend on it unless you have written a backup. Print shop orders cost money and take time, so anything going there must be finished before everything else. Put that decision on your Biv requirements page.
Follows the plan to create the solution, which functions as intended and is presented appropriately.
"Presented appropriately" means your device survives being handed to a stranger. Here are seven conditions. Someone other than you can check every one of them.
- It does what your specification says it does, including the decision it makes on its own.
- It runs on its own power, with no laptop connected, for as long as your specification claims.
- It is in a case. Or it is deliberately open and neat, with every board fixed down and nothing loose.
- Every button and every light is labelled, in words your client can read.
- There is a way to turn it on and off.
- The wiring is tidy enough to repair, and connectors unplug instead of being cut.
- It comes with a one page user sheet: what it does, how to start it, what each light or sound means, and what to do when it stops working properly.
Your evidence, and practice for Di
The cold start test
Someone who has never seen your device is handed it, switched on, with the user sheet and nothing else. They try to do the main task.
You watch in silence. You write down every wrong guess, every button pressed in the wrong order, and every question they ask.
The silence is the hard part. You will want to help within about eight seconds. Do not. The moment you explain anything, the data is gone, and that data is the whole point of the test.
Fully justifies changes made to the chosen design and plan when making the solution.
No build ever goes exactly to plan. That is normal and it is not a problem. What is marked here is whether you can explain why each change was the right one.
| Date | What I changed | Design, plan, code or part? | What made me change it | Other options I considered | Why I chose this one | What else had to change |
|---|---|---|---|---|---|---|
| One row per change. Ten build classes should give you a lot more than ten rows. | ||||||
The thing that decides this task
Do not write this the night before
Every year, some people write the whole log the night before it is due. It always shows, because the entries have no detail and the dates are invented.
So you get five minutes at the end of every build class to write it, in the room, before you pack up. Use them. An undated log written in one sitting cannot reach 7-8.
That is not a threat. It is the difference between explaining your decisions and trying to remember them three weeks later.
Electronics only
When you swap a part, three documents change
Change a part and you must also update your wiring list, your parts list, and any Bi rule that named that part. Your change log row is not finished until it says which ones you updated.
This habit is what keeps your Biv pack matching the device on your desk. Without it, the pack slowly becomes a description of a device you no longer have.
Coming soon
Change log and bug diary, with real timestamps
Entries record when you actually wrote them. A log written in one evening cannot pretend it was kept across ten classes.
This is a suggested shape, not a rule. Your own Ci plan is what should drive your ten classes. But four things are fixed for everybody, because they are timetabled: the two code conversations, the ordering deadline, and the cold start test.
1Build the whole thing on breadboard
Everything wired up from your Biv wiring list. Nothing permanent yet. The power check starts today, and so does the five minute log stop.
2Code skeleton, modes first
Build the modes from your state diagram, with each one just printing its own name and doing nothing else. Get the shape right before you add any behaviour.
3One input and one output, working properly
Debouncing, converting the sensor number, and a real threshold. This is the decision from rule 1, working for the first time.
4The rest of your inputs and outputs
Code conversation 1. Two minutes each while everyone else keeps building. Anything you are ordering must be ordered by the end of today.
5Come off the breadboard
Move onto stripboard, connectors, or permanent wiring. This is where the soldering skill earns its evidence, and where the no-solder route earns exactly the same marks.
6Make the case
Print it, cut it or build it. Check every hole against the real connectors before you glue or close anything.
7Everything goes in the box
Mount the boards, tidy the cables, fit the on and off switch. Today is the first time your device runs on its own power with the laptop unplugged.
8Labels, finishing, user sheet
The presentation half of Ciii. The label reading check runs at the end of class.
9Cold start test, then fixes
Code conversation 2. Swap devices, watch in silence, write down the wrong guesses. Then spend the rest of the class fixing what the test found.
10Finish, and tidy your documents
Last fixes. Then bring your making log, bug diary and change log up to date and hand them in. Correct your Biv pack so it matches the device you actually built.
Your device meets your client twice. What makes this different from evaluating a poster or a game is that a device can be measured, not only asked about. Half your testing produces numbers from an instrument. That is what lets you write "passed" or "failed" instead of "they seemed to like it".
You get two sessions with your client, and that is all. The Dii session is where you test your rules. The Div demo is where you find out what difference the device makes. Your client does not keep the device for a week, so nothing you plan can depend on that.
Designs detailed and relevant testing methods, which generate data, to measure the success of the solution.
Two kinds of test. Tests with people, where you watch or ask. Tests with instruments, where you measure. The second kind is what makes this an electronics evaluation.
Every rule on your Bi page needs a test. Across the whole plan you need at least three instrument tests that produce numbers and at least two tests with people.
Instrument tests, and what you need for each
| Test | What it measures | What you need |
|---|---|---|
| Current | How much electricity it uses, resting and at its busiest | Multimeter, wired into the circuit |
| Battery life | Hours until it dies, either measured or worked out from the current | Stopwatch, or your arithmetic shown |
| Reaction time | The delay between something happening and your device responding, over 20 tries | Stopwatch, or timestamps printed by your code |
| Accuracy | Your sensor's reading against something you trust. 10 pairs of readings, then the difference | A thermometer, ruler, scale or light meter you trust |
| Reliability | How many times it fails out of 100 tries | A tally sheet |
| Start up | Seconds from switching on to being useful | Stopwatch |
| Real conditions | Does it still work in the dark, in noise, in the actual room it will live in | Your client's room |
Tests with people
The cold start test with a tally of wrong guesses. A task where you time whether they finish. An interview with your client. A short questionnaire. Watching your device being used, with a plan for what you are counting.
Your Test Plan
| Which rule | Method | People or instrument | How many people or tries | Numbers or words | What I need | What counts as a pass |
|---|---|---|---|---|---|---|
| One row per rule. That means 8 to 12 rows, matching your Bi page. | ||||||
The habit to break
Asking people about everything
Most people choose a questionnaire for every single rule, including the ones with numbers in them. Battery life needs a multimeter, not an opinion.
Whether your controls make sense needs you to watch someone get it wrong and count the mistakes. Asking "were the controls clear?" does not work, because someone who struggled will still politely say yes.
One useful pair of words. Qualitative data is words, and it tells you why. Quantitative data is numbers, and it tells you how much. A 7-8 plan uses both, and knows which rule needs which.
What happens in each class
1Give every rule a test
Work down your Bi page one row at a time. Choose people or instrument, and name what you need. Check you have at least three instrument tests and two with people before you write any questions.
2Build the test sheets
Actually write the questionnaire, draw the observation sheet, write the interview questions, and lay out the measurement sheet. Run any instrument test that does not need people today, so your client session is free for the ones that do.
Critically evaluates the success of the solution against the design specification based on authentic product testing.
Class 1: your client tests it
Your device goes to the people on your card and they use it. You run your own test sheets and collect your own data. Leave this class with your sheets filled in, not with a general impression. Next class has nothing to work from otherwise.
Class 2: write up what you found
| Rule | Test used | What I found | Passed, partly, or failed | My evidence | What this means |
|---|---|---|---|---|---|
| Every rule on your Bi page gets a row. You may not leave one blank because the test did not happen. | |||||
Where the top band is won
What "critically" means here
It means finishing with a section about how much your own evidence is worth. Be honest about the limits. You tested one device, not a hundred. You tested it mostly yourself, and you know exactly how to hold it. You had one session. The room was not the room it will live in. Your testers probably wanted to be nice to you.
Saying a rule passed based on four testers, and saying that out loud, shows better judgement than claiming to be certain.
This section is worth more marks than the table above it. Most people expect the opposite and write two lines here. Do not be one of them.
Explains how the solution could be improved.
| Improvement | Type | Which rule it fixes | The Dii evidence behind it | Why it would work | Cost and time | Rank |
|---|---|---|---|---|---|---|
| Ranked by how much it helps against how much it costs. Say which rule you used to rank them. | ||||||
Electronics only
Naming the type is what makes your ranking mean something
Without it, most people rank improvements by how much they would enjoy doing them. Naming the type tells you what each one really costs, and then the ranking follows from that.
| Type | What it would take |
|---|---|
| Code | An evening. Free |
| Wiring | An hour at the bench. Nearly free |
| A different part | Money, and waiting for delivery. Your parts list changes |
| The case | Print it again. A day, plus material |
| The whole idea | Start over. Not happening this unit, but still worth saying |
Two rules
- Every improvement points back to something you found in Dii. An improvement with no evidence behind it is just a preference. Remove it rather than trying to make it sound better.
- Include one improvement for something that passed. Meeting a rule is not the same as being as good as it could be. Noticing that is a 7-8 move, and it is an easy one to make.
Explains the impact of the product on the client/target audience.
Impact means the difference your device makes. It is not the same as whether people enjoyed it. "They liked it" belongs in Dii. Impact asks what changes for the people who have it, for the people around them, and for the room it sits in.
Class 1: the demo with your client
This is a session where they use it, not one where you show it off. Take your device to the place it would live and let it run there for the class. Three parts, in this order.
- Hand it over and say nothing. Let them do the real task while you watch and take notes. Ten minutes at least.
- Ask the six questions below.
- Film your video during the session, while they are actually using it. Not afterwards on a desk.
Ask all six
The impact interview
- What would you stop doing if you had this?
- What would you start doing?
- Who else in this room would notice it, and would they mind?
- What would annoy you about it by the third week?
- Who would charge it, or fix it, or switch it back on when it stops?
- Would you want to keep it? What would have to be true for that?
Every question asks about consequences, not enjoyment. That is the whole difference between this task and Dii.
Be honest about this
One session is not very much evidence
Your client used your device once, for part of one class. Questions 1, 2 and 4 ask them to predict what would happen, not to report what did happen.
So label those answers as predictions in your report. Do not present a guess about the future as something you observed.
Impact that you claim honestly, and describe the limits of, is worth more marks than impact you overstate. Most people assume the opposite, which is why this box is here.
Class 2: your report, in two parts
Part 2: the written report, 2 pages. Six sections. These are what take you past "they liked it".
- Who was affected, including people who never touch it. Who else is in that room? Who has to look at it? Who has to charge it?
- What you intended, against what actually happened. Quote your Ai need statement directly.
- Your evidence, from the demo and also from your Dii session. Quotes, counts, and what people did rather than what they said. Two sessions is not many, and saying so belongs in this section.
- Effects you did not intend, good and bad. Did anyone use it for something else? Did the sound annoy someone two desks away? Did it become a distraction, or something people argued over?
- Wider effects. Choose at least three: what happens when it breaks and who could fix it; where it goes when nobody wants it, including the battery; what it costs in electricity over a year; what twenty of them would cost to make; whether your labels work for someone still learning English; who cannot use it because of the eyesight, hearing, reading or hand movement it assumes.
- Did you meet the original need? Answer plainly. Yes, partly, or no, with reasons.
Why section 5 is here
Repair, waste, and an argument happening right now
Section 5 is the electronics one. Who can repair a device, what happens to its battery, and what twenty of them would cost are live arguments in the electronics industry today. They are not a school exercise.
If you take Design at DP, you will meet all of this again under the circular economy.
Downloads
Images
External Sites
Policies
- Unit policies (e.g., AI use) will be added from the G10 unit plan.