DHT22 telemetry that survives an uplink cut

Repair the gateway cable and add local buffering to a DHT22 sensing path.

Physics Phoebe, your practice guide

Physics Phoebe
Predict which checkpoint will change, then test the connection.

IoT Ideator

Design Studio

Simulation — built in · No account

Version tested: 36435f99ff6788e8acd2e3d1fb9309cd97b4f2e4. Date: 2026-09-05.

Open the prepared mission; follow the guide and live checkpoints.

Open this design in the Design Studio (new tab)

Steps

Screens captured against IoT Ideator 36435f99ff6788e8acd2e3d1fb9309cd97b4f2e4 on 2026-09-05; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    In the Working View canvas, select Temperature Sensor (DHT22) and inspect its connection to the ESP32.
    You will see
    Input: Selected Temperature Sensor (DHT22) in Working View. Observed: The canvas links the DHT22 node to ESP32 DevKit V1. Expected: The prepared design should show a digital sensor path to the controller. Interpretation: This is a topology result; the app shows no measured temperature accuracy.
    Why it matters
    Evidence: The node and link are live IoT Ideator catalogue objects. Boundary: A digital connection cannot establish accuracy against a trusted reference. Reason: Sensor accuracy, resolution, and timing are separate specification claims. Next check: Inspect the gateway cable before relying on the cloud route.

  2. Step 2

    Do
    In the Working View canvas, select Fog Computing Node and inspect its Physical placement cable-length field for Protocol Translation Gateway.
    You will see
    Input: Selected Fog Computing Node in Site view and inspected Physical placement. Observed: Cable length to Protocol Translation Gateway is configured as 120 m. Expected: The Ethernet teaching maximum is 100 m; the configured run exceeds it by 20 m. Interpretation: The edge carries an Over max length warning despite a 0.500 m map gap.
    Why it matters
    Evidence: The configured cable field, not the visible map gap, drives this warning. Boundary: A drawn cloud path remains physically refused in the design model. Reason: Installation conditions belong with a sensor specification claim. Next check: Change only that configured cable length and re-read the verdict.

  3. Step 3

    Do
    In the Physical placement panel, set Cable length to Protocol Translation Gateway to 80 m.
    You will see
    Input: Set Cable length to Protocol Translation Gateway to 80 m in Physical placement. Observed: The field shows 80 m and the over-length edge warning clears. Expected: 80 m is 20 m below the 100 m Ethernet teaching maximum. Interpretation: The repaired edge can support the modelled cloud route.
    Why it matters
    Evidence: One cable field changed between the warning and cleared verdict. Boundary: The app does not test installed cable quality or field uptime. Reason: A passing design length addresses only one connection condition. Next check: Add a local buffer for interruptions upstream.

  4. Step 4

    Do
    In the Storage panel, add SD Card Module, place it beside ESP32 on the Site canvas, and link them by SPI.
    You will see
    Input: Added SD Card Module from Storage, moved it beside ESP32 in Site view, and connected SPI. Observed: The canvas labels the new ESP32-to-SD Card edge SPI. Expected: The connected-buffer checkpoint requires storage linked to the controller. Interpretation: The mission now reports a connected SD card buffer.
    Why it matters
    Evidence: The SD card is a catalogue component connected through the SPI bus. Boundary: This architectural check does not show firmware writing a sample. Reason: A buffer path helps retain data when the upstream service is unavailable. Next check: Read the full route and physical-link checkpoints.

  5. Step 5

    Do
    In the Scenarios panel, read the three checkpoints for the buffer, edge-to-cloud route, and physical links.
    You will see
    Input: Read the Scenarios checkpoints after the cable and SPI repairs. Observed: Buffer, sensor-to-cloud through edge compute, and physically valid links all pass. Expected: The DHT22 route must continue through ESP32 and the edge gateway to AWS IoT Core. Interpretation: The associated scenario shows 5 of 5 lab checks met.
    Why it matters
    Evidence: The app says every cold-chain segment is within its physical limit. Boundary: Catalogue checks do not measure DHT22 accuracy, calibration, or latency. Reason: Storage, route, and link validity cover different design claims. Next check: Use the chapter knowledge check for resolution versus accuracy.

  6. Step 6

    Do
    In a browser tab, open the linked chapter knowledge check and answer the sensor specification questions.
    You will see
    Input: Opened the linked Sensor Specifications knowledge check and chose answer A. Observed: The browser says Correct and awards +5 XP for the 0.01-degree-step question. Expected: A fine output step is resolution, not proof of absolute accuracy. Interpretation: Accuracy still needs calibration and reference evidence for the decision threshold.
    Why it matters
    Evidence: The live chapter check distinguishes resolution from accuracy. Boundary: Passing a quiz is not a DHT22 field measurement. Reason: Extra displayed decimal places cannot narrow an accuracy claim. Next check: Retain reference readings and test conditions for any installed sensor.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A sensor reports temperature in 0.01 degree steps, but its accuracy claim is much wider than the decision threshold. What should the review conclude?

    Return to the chapter’s knowledge check

  2. A team chooses a sensor because it is inexpensive, but the field environment causes frequent drift and replacement visits. Which specification review was incomplete?

    Return to the chapter’s knowledge check

Return to Sensor Specifications · Browse Tutorials