IoT and Smart Systems Engineer: path test

Why each option is right or wrong

• “Whether beekeepers want the weight shown in grams as well as in kilograms on the screen” (Incorrect): Units are a display choice, not what fails in an orchard.
• “Whether the office Wi-Fi is fast enough to carry the readings from all the units” (Incorrect): The orchards don't use the office Wi-Fi.
• “Whether the plastic case looks good enough for photos on the company's website” (Incorrect): Looks don't explain units failing.
• “Heat, rain, weak signal and months without anyone visiting” is correct.

  Field conditions shape the design more than the desk does.

  • Check: test in a hot, damp box with a throttled network.

📖 Revise: Lesson 4: The limits that shape every design

Why each option is right or wrong

• “The size of the screen that shows the parking status on the sensor itself” (Incorrect): A buried sensor has no screen.
• “The number of colours its status light can show to drivers who are passing by on the road” (Incorrect): It's buried; nobody sees a light.
• “How quickly it can run a full web browser” (Incorrect): A sensor doesn't need one.
• “Energy: it can't be reached to charge, so every reading and message must be cheap” is correct.

  Battery life sets the radio, the sleep pattern and the message size.

  • Then: a power budget (IO3).

📖 Revise: Lesson 3: From sensor to dashboard

Why each option is right or wrong

• “Phone, cloud, gateway, sensor, then back to the phone again” (Incorrect): That's the reverse of the data's path.
• “Sensor straight to the phone's screen, with nothing in between” (Incorrect): Most devices pass data through a network and a server.
• “Cloud first, which creates the reading and sends it to the sensor to confirm” (Incorrect): Readings start at the sensor.
• “Sensor, microcontroller, radio, gateway or network, cloud, then the app” is correct.

  Each step can fail, so each needs a plan.

  • Kit: JalSetu's path is sensor, board, Wi-Fi, broker, server.

📖 Revise: Lesson 2: Microcontrollers are not small laptops

Why each option is right or wrong

• “Linux can't send numbers over a network at all” (Incorrect): It can, easily.
• “A Linux board is too small to hold the sensor's code” (Incorrect): It has far more room than needed.
• “A Linux board can't be bought in small enough numbers for a pilot with a few hundred sensors” (Incorrect): Availability isn't the main issue.
• “It uses far more power and takes longer to start than a microcontroller would” is correct.

  A coin cell suits a microcontroller that sleeps.

  • Rule of thumb: a microcontroller for simple, low-power jobs.

📖 Revise: Lesson 1: What an IoT engineer does

Why each option is right or wrong

• “Make the wait longer, so the loop runs fewer times and the processor stays cooler” (Incorrect): Longer waits miss more presses.
• “Remove the button and only use the door sensor, since the two can't work together” (Incorrect): Both can work with the right pattern.
• “Wait twice as often, but for half the time each, so the gaps between waits are smaller” (Incorrect): It still blocks.
• “Check the time on each pass and act when an interval has passed, without blocking” is correct.

  The loop stays free to notice the button.

  • Or: an interrupt for the button (IO4).

📖 Revise: Lesson 3: Time without blocking

Why each option is right or wrong

• “Reset the chip once a day so the list starts empty, and accept losing what's in it” (Incorrect): That throws data away to hide the bug.
• “Use a chip with ten times more RAM, so the list lasts twenty days instead” (Incorrect): It still runs out, just later.
• “Store the readings as text instead of numbers so they take less space in memory” (Incorrect): Text usually takes more space.
• “Keep a fixed-size buffer and move what must be kept to flash” is correct.

  Memory use stays the same however long it runs.

  • Plan: budget memory for each part of the firmware.

📖 Revise: Lesson 4: Memory on a small chip, and what C adds

Why each option is right or wrong

• “Wait for the boards, because firmware can only be tested on the chip itself” (Incorrect): Most logic can be tested earlier.
• “Copy the firmware into a web page and test it in the browser by hand” (Incorrect): That changes the code being tested.
• “Test only the parts that don't do anything, so nothing needs a simulated board” (Incorrect): Those parts aren't the risky ones.
• “Keep hardware access behind small functions and replace them with simulated ones in tests” is correct.

  The logic runs anywhere; only the thin layer is hardware-specific.

  • Kit: JalSetu's sim/ board.

📖 Revise: Lesson 5: Testing firmware without hardware

Why each option is right or wrong

• “Nothing, since 40 seconds is too short to matter over a whole day of readings” (Incorrect): It adds up to over an hour a day.
• “The readings come faster than planned, so the battery runs down sooner” (Incorrect): They come slower, not faster.
• “The chip's clock stops after 96 wakes and has to be set again by hand” (Incorrect): Clocks don't stop on a count.
• “The schedule drifts later; it should sleep until the next 15-minute mark” is correct.

  Sleeping a fixed time after work adds the work's time each cycle.

  • Kit: test 05 checks the schedule.

📖 Revise: Lesson 2: The main loop and the wake cycle

Why each option is right or wrong

• “Cutting the sleep current from 0.01 mA to 0.008 mA by choosing a different regulator” (Incorrect): Sleep uses little next to the awake time here.
• “Painting the case white so the electronics stay a little cooler in the sun” (Incorrect): Heat matters for batteries, but not most here.
• “Adding a status light so the user can see it's awake” (Incorrect): That adds current.
• “Cutting the awake time from 2 seconds to 0.5 seconds” is correct.

  Awake charge is 160 mAs per wake; that's most of the total.

  • Method: work out charge per part, then fix the biggest.

📖 Revise: Lesson 1: Current, charge and battery capacity

Why each option is right or wrong

• “The time zone of the cold store, which changes when readings are sent” (Incorrect): Time zones don't change charge.
• “The colour of the tracker's case, which affects how it holds heat” (Incorrect): Not a likely cause of a two-thirds shortfall.
• “The weight of the boxes the trackers are attached to in storage” (Incorrect): Weight doesn't drain a battery.
• “That batteries deliver much less of their capacity in the cold” is correct.

  Real conditions need a margin in the budget.

  • Plan: derate capacity for temperature and age.

📖 Revise: Lesson 5: Designing for a year or more

Why each option is right or wrong

• “Send each reading twice so that the server is sure to receive it at least once” (Incorrect): Twice the radio use.
• “Turn the screen brightness down on the sensor's display between wakes” (Incorrect): Most sensors have no screen; the radio is the cost.
• “Use a longer Wi-Fi password, which makes the join more secure” (Incorrect): Security matters, but not for battery.
• “Store readings and send them in batches every few wakes, or at once for alarms” is correct.

  Joining the network is the most costly step.

  • Kit: JalSetu sends every fourth wake.

📖 Revise: Lesson 4: The radio is the expensive part

Why each option is right or wrong

• “About 1,575 mAs, from 45 times 35 with no change of units” (Incorrect): 45 is in milliseconds, not seconds.
• “About 0.8 mAs, from 35 divided by 45” (Incorrect): Charge is current times time.
• “About 35 mAs, since only the current matters and not the time” (Incorrect): Time matters as much as current.
• “About 1.6 mAs, from 35 mA times 0.045 s” is correct.

  Current times time, in seconds.

  • Then: times wakes per day for the daily total.

📖 Revise: Lesson 3: Measuring power and writing a budget

Why each option is right or wrong

• “A bigger display that shows the word "busy" while the firmware is waiting” (Incorrect): It's still hung.
• “A rule that staff must restart the machine by hand each morning” (Incorrect): That's a person doing a watchdog's job badly.
• “Faster code in the main loop so it reaches the coin sensor sooner” (Incorrect): Speed doesn't stop a hang.
• “A watchdog that resets the chip if the main loop stops feeding it, and a timeout on the wait” is correct.

  The device recovers by itself and records why.

  • Also: report the reset cause.

📖 Revise: Lesson 3: Watchdogs and recovering by yourself

Why each option is right or wrong

• “The rain gauge sends too few pulses for the interrupt to count correctly each hour” (Incorrect): Few pulses don't crash anything.
• “MQTT can't be used on devices that also have interrupts enabled” (Incorrect): They work together when the work is in the right place.
• “The flash chip needs a larger capacity for interrupts to write to it safely” (Incorrect): Size isn't the problem.
• “Handlers should be short: set a flag or count, and do slow work in the main loop” is correct.

  Slow work in an interrupt breaks timing and other code.

  • Rule: no waiting, no flash, no network in a handler.

📖 Revise: Lesson 1: Interrupts: reacting on time

Why each option is right or wrong

• “Give one task a much higher priority, so that it runs before the other one does every time” (Incorrect): Priorities don't stop both changing it at once.
• “Make the counter a much bigger number type so it has room for every count” (Incorrect): Size isn't the problem.
• “Remove one of the tasks and hope the other does both jobs on time” (Incorrect): That hides the design problem.
• “Protect the counter with a mutex, or let one task own it and send it messages” is correct.

  Only one task then changes it at a time.

  • Name: a race condition.

📖 Revise: Lesson 2: RTOS tasks, queues and priorities

Why each option is right or wrong

• “Asking users to describe what the light on the device did before it reset” (Incorrect): Users rarely see it, and can't say why.
• “Turning off the watchdog, so devices stop resetting” (Incorrect): Hung devices would then stay hung.
• “Recalling every device to read its flash in the lab” (Incorrect): Costly and slow when the devices can report.
• “Each device recording its reset cause and last error, and reporting them in its status” is correct.

  The fleet tells you what's going wrong.

  • Then: group by cause and firmware version.

📖 Revise: Lesson 5: Diagnosing faults in the field

Why each option is right or wrong

• “The reading will be twice as accurate, since 5 V gives a stronger signal to the pin” (Incorrect): Higher voltage doesn't improve the reading.
• “The pin will read 0, since 5 V is too high to count as "on" for a 3.3 V chip” (Incorrect): It reads as high, and may be damaged.
• “The sensor will run slower, because the chip pulls its voltage down to 3.3 V” (Incorrect): Speed isn't the risk.
• “The pin can be damaged; use a level shifter or a divider” is correct.

  Inputs have a maximum voltage.

  • Check: the datasheet's absolute maximum ratings.

📖 Revise: Lesson 1: Digital pins: inputs and outputs

Why each option is right or wrong

• “Reading the pin with a digital input instead, since digital inputs don't jump” (Incorrect): That loses the analog value.
• “Sampling once a day so there are fewer jumps” (Incorrect): Fewer samples don't remove noise.
• “Turning up the light near the sensor so the reading is larger” (Incorrect): The noise is still there.
• “Averaging several samples, and adding a small capacitor if the wiring is noisy” is correct.

  Noise averages out; the trend stays.

  • Also: know the ADC's real resolution.

📖 Revise: Lesson 2: Analog readings with the ADC

Why each option is right or wrong

• “Reading the fan's speed with the ADC and hoping it settles where it should” (Incorrect): Reading isn't controlling.
• “Changing the chip's own supply voltage up and down in the firmware” (Incorrect): That would upset the chip itself.
• “Turning the fan on for an hour and off for an hour to set an average” (Incorrect): That's on and off, not speed.
• “PWM: switching power on and off fast, with the on share setting the speed” is correct.

  The duty cycle controls the average power.

  • Safety: drive the fan through a transistor, not the pin.

📖 Revise: Lesson 3: PWM and driving loads

Why each option is right or wrong

• “That the sensor reads to 0.1 °C, so it's accurate to 0.1 °C as well” (Incorrect): Resolution isn't accuracy.
• “That accuracy doesn't matter as long as the alarm fires at some point” (Incorrect): For vaccines it matters a lot.
• “That a sensor with ±2 °C is fine if readings are averaged over a week” (Incorrect): Averaging doesn't fix an offset.
• “That a more accurate or calibrated sensor is needed for that alarm” is correct.

  Accuracy has to fit the decision being made.

  • Plan: calibrate against a reference.

📖 Revise: Lesson 4: Sensors and how far to trust them

Why each option is right or wrong

• “I2C allows only one device per bus, so the second sensor must be removed” (Incorrect): I2C supports many devices.
• “The bus is too fast; slow it down so the two take turns” (Incorrect): Speed doesn't fix a clash.
• “The sensors are faulty, since they shouldn't answer at all” (Incorrect): Answering is correct; sharing an address isn't.
• “Both have the same address; change one with its address pin, or use a second bus” is correct.

  Each device needs its own address.

  • Check: the datasheet's address options.

📖 Revise: Lesson 1: I2C: two wires, many chips

Why each option is right or wrong

• “Read twice in a row and keep whichever value is bigger” (Incorrect): Neither may be ready.
• “Wait 10 seconds every time to make completely sure it has finished” (Incorrect): Far too long; wastes battery.
• “Skip the start command entirely, so that the sensor keeps measuring all of the time by itself” (Incorrect): That uses more power and may not be supported.
• “Poll the ready bit, or wait about 20 ms, and give up after a timeout” is correct.

  It reads only finished results, without hanging.

  • Kit: LV-20's status register.

📖 Revise: Lesson 4: Reading a datasheet

Why each option is right or wrong

• “Use a longer cable so the signal has time to slow down to the right speed on its way” (Incorrect): Cables don't change baud rate.
• “Send each command to the module twice, so it understands at least one of them” (Incorrect): The speed is still wrong.
• “Switch to I2C, since UART can't carry GPS data reliably” (Incorrect): UART carries GPS data fine.
• “Set the UART to 9600 baud to match the module” is correct.

  Both ends must agree on the speed.

  • Also: check voltage levels and TX/RX wiring.

📖 Revise: Lesson 3: UART: serial lines to modems and GPS

Why each option is right or wrong

• “The sensor is broken and needs to be replaced with one from a different batch” (Incorrect): The value is just swapped.
• “The bus is running too fast, which shifts bits along by eight places in transit” (Incorrect): Too fast gives errors, not a clean swap.
• “The value needs dividing by two, as most sensors report double” (Incorrect): A swap isn't a scale.
• “The bytes are combined in the wrong order for this chip” is correct.

  Check whether the datasheet says low or high byte first.

  • Kit: LV-20 is low byte first.

📖 Revise: Lesson 4: Reading a datasheet

Why each option is right or wrong

• “QoS 2, so each message is delivered exactly once to the app” (Incorrect): That doesn't help a new subscriber.
• “A shorter keepalive, so the plugs send their state more often to the broker” (Incorrect): More traffic, and still a wait.
• “Longer topic names, which the broker stores for longer” (Incorrect): Topic length doesn't affect storage.
• “Retained messages, so the broker gives each new subscriber the last state at once” is correct.

  New viewers see the current state straight away.

  • Also: a last will for unexpected drops.

📖 Revise: Lesson 2: MQTT: topics, QoS, retained messages, wills and keepalive

Why each option is right or wrong

• “sensor1, sensor2 and so on, with the floor written in each message” (Incorrect): Subscribers can't filter by floor.
• “One topic for the whole building, with every sensor publishing there” (Incorrect): Nothing can be filtered.
• “temperature/<the tenant's name>, so people know whose office it is” (Incorrect): Names don't belong in topics.
• “bldg/floor3/<sensor>/temperature, subscribed with bldg/floor3/+/temperature” is correct.

  General to specific lets a wildcard pick the floor.

  • Also: IDs, not people's names, in topics.

📖 Revise: Lesson 3: Designing topics and payloads

Why each option is right or wrong

• “HTTP over TLS, opening a full connection for each reading it sends” (Incorrect): Heavy for a tiny device.
• “FTP, uploading a file of readings once a month to a server” (Incorrect): Too heavy and too slow.
• “A permanent MQTT connection over TCP, kept open all day and all night” (Incorrect): Costly on a lossy, low-power network.
• “CoAP over UDP, with confirmable messages where they matter” is correct.

  Small messages and no long connection.

  • Often: with a gateway that speaks MQTT onward.

📖 Revise: Lesson 4: CoAP and UDP for the smallest devices

Why each option is right or wrong

• “One shared username and password, changed once a year for the whole fleet” (Incorrect): The stolen one exposes all of them.
• “No password, but a secret broker address only the team knows” (Incorrect): Addresses get found.
• “A password written in the firmware, so it can't be read without tools” (Incorrect): Tools exist; it's still one for all.
• “Per-device credentials, ACLs to each device's own topics, and TLS” is correct.

  One device can be blocked alone and can't pose as others.

  • Plan: revoke the stolen one's credential.

📖 Revise: Lesson 5: Securing the connection and the broker

Why each option is right or wrong

• “Tunnels erase readings that were sent while the van was underground” (Incorrect): Tunnels drop the connection, not the data.
• “Mobile data can only carry one reading every minute” (Incorrect): It can carry many.
• “The logger's clock runs slow in tunnels” (Incorrect): Clocks don't cause missing readings.
• “A reading should leave the store only after the broker confirms it” is correct.

  "Sent" isn't "received".

  • Fix: QoS 1 and remove on PUBACK.

📖 Revise: Lesson 1: Store first, send later

Why each option is right or wrong

• “Write the file more slowly, so the power cut is less likely to hit” (Incorrect): It can still hit.
• “Keep the buffer in RAM instead, so there's no file to break during a power cut” (Incorrect): RAM loses everything on a cut.
• “Stop writing when the battery is below half full, to reduce the risk of a cut” (Incorrect): Cuts happen at any level.
• “Append records with lengths and checksums, and rename small files into place” is correct.

  A cut leaves the good records readable.

  • On start: drop a damaged tail.

📖 Revise: Lesson 2: Surviving power cuts and torn writes

Why each option is right or wrong

• “Making every meter reconnect at 2:21 instead” (Incorrect): The wave just moves a minute.
• “Making the meters send all their stored readings in one large message” (Incorrect): That makes each reconnect heavier.
• “Turning off the meters' buffers so there's nothing to send when they're back” (Incorrect): Readings would be lost.
• “Backoff with random jitter, and draining backlogs in batches” is correct.

  Reconnects spread out and load stays steady.

  • Name: avoiding a thundering herd.

📖 Revise: Lesson 3: Reconnecting without draining the battery

Why each option is right or wrong

• “A bigger change threshold, so even fewer readings are sent overnight” (Incorrect): Fewer readings make it worse.
• “A second sensor beside it, sending the same readings as the first one” (Incorrect): The same filter hides the same problem.
• “A rule to send every reading during the night only” (Incorrect): That wastes battery for nothing.
• “A heartbeat, so a quiet sensor and a dead one can be told apart” is correct.

  Silence then means a problem.

  • Also: alarms that skip the filter.

📖 Revise: Lesson 4: Edge computing: deciding on the device

Why each option is right or wrong

• “Checking that the update came from the usual web address over HTTPS” (Incorrect): The attacker controls that server.
• “Checking that the file is about the same size as the last update” (Incorrect): Sizes can be matched.
• “Checking that the version number is higher than the current one” (Incorrect): The attacker can pick any number.
• “A signature check with the maker's public key, whose private key isn't on that server” is correct.

  The attacker can't sign without the private key.

  • Then: check the image's hash against the signed manifest.

📖 Revise: Lesson 2: Signing firmware so devices trust only you

Why each option is right or wrong

• “Download faster, so the time in danger is shorter” (Incorrect): A cut can still hit.
• “Download at night, when power cuts are less likely to happen in most places” (Incorrect): Cuts happen at night too.
• “Download twice and compare the two copies before writing over the running one” (Incorrect): It still writes over the running firmware.
• “Download into a second slot and switch only after a complete, checked image” is correct.

  The running firmware stays safe until the new one is ready.

  • Also: resume and a battery minimum.

📖 Revise: Lesson 3: Downloading safely: two slots, resume and battery checks

Why each option is right or wrong

• “Nothing, because an encrypted image can only be opened by devices that hold the right key” (Incorrect): Opening isn't the same as proving who made it.
• “A faster encryption method, so the image downloads in less time on slow links” (Incorrect): Speed isn't the gap.
• “A bigger key, so that the encryption is harder to break by guessing” (Incorrect): The key can be read from a device, however big.
• “Proof of origin: anyone who extracts that key from one device can make images others accept” is correct.

  A signature needs a private key that no device holds.

  • Encryption: optional, for hiding the contents.

📖 Revise: Lesson 2: Signing firmware so devices trust only you

Why each option is right or wrong

• “Push to all at once but on Monday morning, so staff are at work if it goes wrong” (Incorrect): Every doorbell is still exposed at once.
• “Push to all at once, and email customers to restart their doorbell if it stops working” (Incorrect): Customers become the test.
• “Skip the update, since any update is too risky for a fleet of this size” (Incorrect): Bugs and weaknesses then stay.
• “Stages from a few percent, a wait at each, and halt rules on rollbacks and offline devices” is correct.

  A fault shows up on a few devices first.

  • Also: stages chosen from a hash of the device ID.

📖 Revise: Lesson 5: Rolling out to a fleet

Why each option is right or wrong

• “That 28 of 28 pass, since the final result is the only thing that matters to an employer” (Incorrect): The simulator is part of the brief.
• “Nothing about it, since nobody will look at the sim/ folder anyway” (Incorrect): Hiding it would make the self-review untrue.
• “That the simulator was wrong, without checking the datasheet first” (Incorrect): The datasheet and tests are the brief.
• “That the change breaks the brief; undo it and fix the firmware instead” is correct.

  Changing the simulator hides the real problem.

  • Rule: change firmware and documents, not tests or sim/.

📖 Revise: Lesson 1: Planning the capstone

Why each option is right or wrong

• “The battery test itself is broken, since it passed last week before Project 2 was started” (Incorrect): The tests didn't change; the firmware did.
• “Project 1 and Project 2 can't pass together, by design of the kit” (Incorrect): All 28 are meant to pass together.
• “The simulator's battery wore out after many runs” (Incorrect): The simulated battery starts fresh each run.
• “The new sending code keeps the radio on longer or more often than the budget allows” is correct.

  Each project affects the others' measurements.

  • Fix: run all 28 tests after each change.

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

Why each option is right or wrong

• “A longer list of every test name, so the friend knows what each one checks in detail” (Incorrect): Names don't help if nothing runs.
• “A photo of the learner's screen showing all 28 tests passing” (Incorrect): That proves nothing on the friend's computer.
• “A note that the tests only work on the learner's own laptop” (Incorrect): That would be a problem to fix, not explain.
• “The setup steps: the folder, the virtual environment and the install” is correct.

  Without them, the tests can't start.

  • Check: acceptance test 2, a friend following it alone.

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

Why each option is right or wrong

• “Keep it, since confident claims are more convincing to readers” (Incorrect): Unchecked claims lose trust.
• “Change it to "will last at least ten years", to leave room for error” (Incorrect): It's still unmeasured.
• “Remove the battery section, so nobody can question it” (Incorrect): The notes need a battery plan.
• “Give the estimate's basis, label it illustrative, and mark real hardware not verified” is correct.

  Claims then say where they come from.

  • Then: say what you'd measure on a real board.

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