My progress
Menu

IoT and Smart Systems Engineer · Capstone

IO10: Capstone: a tank monitor that lasts, copes and updates safely

Goal: bring the whole path together by completing, testing and presenting the three path projects in the JalSetu practice kit: a battery life of a year or more, readings that survive power cuts and Wi-Fi drops, and safe over-the-air updates, plus design notes on the hardware and firmware approach, more hardware, the split between device, edge and cloud, and running a fleet.

You'll need: everything from IO1–IO9, the JalSetu practice kit (download it from this path's Projects page), and Python 3.11 or later. No board, sensor, soldering iron or cloud account is needed for the tests, and no real person's data is used.

Where this is used: this mirrors real IoT work: making a battery device last in the field, keeping its data through power cuts and network drops, and updating thousands of devices without bricking them. A portfolio with these three, backed by passing checks and honest notes, shows employers more than a photo of a breadboard.

How it differs: each earlier module taught one skill. The capstone tests whether you can combine them: the power project uses the firmware, power and reliability work from IO2, IO3, IO4 and IO6, the buffer project uses the messaging and store-and-forward work from IO7 and IO8, and the update project uses the security and update work from IO9.

Time: reading about 2 hours · practice (the Try it tasks) about 2 hours · projects and capstone about 40 to 50 hours in all.

Lessons

  1. 1Planning the capstoneReading 15–25 minutes, plus practice✓
  2. 2Project 1: a year on one batteryReading 15–25 minutes, plus practice✓
  3. 3Project 2: readings that surviveReading 15–25 minutes, plus practice✓
  4. 4Project 3: safe updatesReading 15–25 minutes, plus practice✓
  5. 5Demo, self-review and case studiesReading 15–25 minutes, plus practice✓

🛠️Assignment: Finish and present JalSetu

  1. Complete Projects 1 to 3 so that pytest passes 28 of 28 in one run.
  2. Write the design notes from the template: the hardware and firmware approach, more hardware, device, edge and cloud, and running a fleet.
  3. Record a 10 to 15 minute demo following the script.
  4. Write three case studies, one per project, with every figure labelled.
  5. Write a self-review against the marking guides, marking anything untried "not verified".

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

What did the three JalSetu projects and the capstone show you can do?

Show a good answer

A good answer mentions: a driver that checks the chip, waits for the conversion, reads bytes in the right order and retries, standby and deep sleep on a schedule, state in RTC memory, the radio used only when needed, and a power budget that matches the measurement; a flash buffer that survives power cuts, QoS 1 batches with resends stored once, the agreed format, backoff, status and a last will, and edge filtering with immediate alarms; signed manifests, image hashes, anti-rollback, a second slot with resume and a battery check, trial boots with rollback, keys kept out of the code, and a staged rollout; design notes on hardware, more parts, device and cloud, and the fleet; and a demo, case studies and self-review with every figure labelled and untried things marked not verified.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A learner changes the buffer code and wants a quick check before moving on. Which command fits best?

Why each option is right or wrong

  • “python tools/simulate.py --days 365, to see a whole year of the device's behaviour at once” (Incorrect): Useful later, but slow and not a pass or fail check.
  • “python tools/broker.py, to check it” (Incorrect): The broker shows messages; it doesn't check them.
  • “pip install -r requirements.txt again, in case the change needs new packages” (Incorrect): Installing packages doesn't test the change.
  • “pytest tests/test_buffer.py, the ten checks for Project 2” is correct.

    It runs only that project's tests, in seconds.

    • Then: run all 28 before finishing.

📖 Revise: Lesson 1: Planning the capstone

Question ID sp-iot-10-q1 · Report a mistake in this question
2. After adding the wait, test 02's driver returns 65,026 mm where the test expects 766 mm. What's the most likely cause?

Why each option is right or wrong

  • “The tank is overflowing, and the sensor is reading the water spilling over the top” (Incorrect): 65 metres is far beyond any overflow.
  • “The sensor is dead, and the bus is returning random values in place of a reading” (Incorrect): A dead sensor gives a bus error, not a swapped value.
  • “The battery is low, so the sensor reads too high while the voltage is dropping” (Incorrect): Voltage doesn't swap bytes.
  • “The two distance bytes are read in the wrong order, high byte first” is correct.

    0xFE02 instead of 0x02FE (766).

    • Fix: low byte first, as the datasheet says.

📖 Revise: Lesson 2: Project 1: a year on one battery

Question ID sp-iot-10-q2 · Report a mistake in this question
3. A learner's power budget says 900 days, but the simulation says 280. What should they do first?

Why each option is right or wrong

  • “Change the budget to 280 days so the two agree and test 10 passes” (Incorrect): That hides the real problem.
  • “Use a bigger battery in the simulation so the figure comes back up to 900 days” (Incorrect): The waste is still there.
  • “Remove deep sleep, since it's confusing the simulator's energy figures” (Incorrect): Deep sleep is what saves the battery.
  • “Find where the code uses more charge than the budget assumes, and fix the code” is correct.

    Here, Wi-Fi was joined on every wake.

    • Then: measure again.

📖 Revise: Lesson 2: Project 1: a year on one battery

Question ID sp-iot-10-q3 · Report a mistake in this question
4. After every deep sleep, JalSetu's wake counter is back at 0. What's wrong?

Why each option is right or wrong

  • “The counter is in RTC memory, which is cleared by every deep sleep on this board” (Incorrect): RTC memory is the part that's kept.
  • “The device isn't deep sleeping at all, so the counter is reset on every wake” (Incorrect): Not sleeping wouldn't reset it.
  • “The broker resets the counter each time the device connects to send its readings” (Incorrect): The broker doesn't touch device state.
  • “The counter is in ordinary memory, which deep sleep clears; it belongs in RTC memory” is correct.

    RTC memory keeps it between wakes.

    • Kit: test 06 checks it.

📖 Revise: Lesson 2: Project 1: a year on one battery

Question ID sp-iot-10-q4 · Report a mistake in this question
5. A learner's buffer fails test 2: a power cut part-way through writing leaves a broken file. What's the likely cause?

Why each option is right or wrong

  • “The buffer holds too many readings for the flash, so the file overflows when power returns” (Incorrect): Size isn't the cause.
  • “The CRC32 check is too strict and rejects records that are fine after a power cut” (Incorrect): The check is what finds damaged records.
  • “The device sends readings with QoS 1, which writes to the flash file more often” (Incorrect): QoS is about the broker, not flash.
  • “The whole log is rewritten in place each time a reading is acknowledged” is correct.

    A cut mid-rewrite leaves a mix.

    • Fix: append to the log; rename small files.

📖 Revise: Lesson 3: Project 2: readings that survive

Question ID sp-iot-10-q5 · Report a mistake in this question
6. During the demo, Wi-Fi is switched off for a day. What should the audience see when it's back?

Why each option is right or wrong

  • “Only the newest reading, since older ones are out of date by the time Wi-Fi returns” (Incorrect): The committee needs the full record.
  • “Every reading arriving twice, since the device resends everything to be sure” (Incorrect): Dedup keeps one copy each.
  • “No readings at all for that day, since the device switched off its buffer to save power” (Incorrect): Readings are kept in flash.
  • “The backlog arriving oldest first, each reading stored once” is correct.

    The buffer and dedup working together.

    • Also: few attempts during the outage.

📖 Revise: Lesson 3: Project 2: readings that survive

Question ID sp-iot-10-q6 · Report a mistake in this question
7. Test 07 fails because a signing seed is in firmware/ota.py. What's the right fix?

Why each option is right or wrong

  • “Move the seed to a comment so the test doesn't see it as code” (Incorrect): It's still in the repository.
  • “Encode the seed in base64 so it doesn't look like a key” (Incorrect): Anyone can decode it.
  • “Split the seed across two files so neither one holds the whole key on its own” (Incorrect): Together they're still the key.
  • “Remove it, keep the private key outside the project, and pass it to the tools by path or variable” is correct.

    The device needs only the public key.

    • Also: treat a key that was in a repository as exposed.

📖 Revise: Lesson 4: Project 3: safe updates

Question ID sp-iot-10-q7 · Report a mistake in this question
8. After a rollback, a learner's device downloads the same bad version on every wake. Which test fails?

Why each option is right or wrong

  • “Test 1, because the bad version's signature must be wrong if it failed on trial” (Incorrect): The signature is valid; the firmware is faulty.
  • “Test 8, because the rollout should have stopped the device getting that version” (Incorrect): The rollout plan is a separate check.
  • “Test 5, since repeated downloads drain the battery” (Incorrect): The battery test checks the minimum before starting.
  • “Test 6, which expects a rolled-back version not to be reinstalled” is correct.

    The device should remember the failed version.

    • Fix: record it and check before downloading.

📖 Revise: Lesson 4: Project 3: safe updates

Question ID sp-iot-10-q8 · Report a mistake in this question
9. A case study says "my monitor runs for over two years and loses no data at all". What's the best rewrite?

Why each option is right or wrong

  • “Keep it, since bold claims stand out to hiring managers more than careful ones do” (Incorrect): Unchecked claims lose trust in interviews.
  • “Remove all figures from the case study so that nothing in it can be questioned” (Incorrect): Labelled figures make the work credible.
  • “Change it to "runs for about two years and rarely loses data"” (Incorrect): It's still unmeasured on real hardware.
  • “Give the simulated figure as practice-kit data, say what the tests checked, and mark the real board not verified” is correct.

    Every claim then says where it comes from.

    • Measured: a few days on the starter, about 870 days after.

📖 Revise: Lesson 5: Demo, self-review and case studies

Question ID sp-iot-10-q9 · Report a mistake in this question
10. What should the demo show besides the finished firmware?

Why each option is right or wrong

  • “Only the tests passing, since anything else could go wrong in front of the audience” (Incorrect): A demo without failures shows little.
  • “A long walk through every line of the firmware so that nothing is left out” (Incorrect): The audience needs the behaviour, not every line.
  • “The private signing key, to prove that the updates are really signed” (Incorrect): A private key isn't for showing to anyone.
  • “Failures and how they're handled, such as Wi-Fi down, a power cut and a refused update” is correct.

    Seeing the device cope builds trust.

    • Also: what couldn't be verified.

📖 Revise: Lesson 5: Demo, self-review and case studies

Question ID sp-iot-10-q10 · Report a mistake in this question

ProLearners Assist