Skip to content

Test a TinyML gesture acceptance gate

Compare baseline, int8-style, pruning, and noise behavior against a visible on-device acceptance gate.

Edge Eddie: I want you to keep the memory, latency, sensor-match, and confidence gates visible before approving a real-device trial., your practice guide

Edge Eddie: I want you to keep the memory, latency, sensor-match, and confidence gates visible before approving a real-device trial.
Predict the reading, then compare it with the measurement.

Wokwi ESP32

Third party Tool

Tier 1 · Web · No account

Version tested: Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-09. Date: 2026-09-09.

Open the ESP32 editor, paste diagram.json, then paste sketch.ino.

Open Wokwi to paste in the files (new tab)

Get the files

Use both prepared files. This is a paste-in setup; saving a project requires a Wokwi account.

diagram.json

2,015 bytes · Circuit connections

Download

sketch.ino

12,305 bytes · ESP32 program

Download

  1. Use the launch button above to open the ESP32 editor in Wokwi.
  2. Select the editor’s diagram.json tab and replace all its text with the supplied diagram.json.
  3. Select the sketch.ino tab, replace all its text with the supplied sketch.ino, then click Start Simulation.

Steps

Screens captured against Wokwi ESP32 Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-09 on 2026-09-09; the tool may have moved on — the text steps are the contract.

  1. 1 Step 1

    Do
    Paste diagram.json and sketch.ino into a new Wokwi ESP32 project, then inspect the four LED paths, mode button, and noise control.
    You will see
    Shake and tap LED paths start at ESP32 GPIO12 and GPIO13 through r1 and r2 (diagram.json lines 21, 24). Tilt and circle LED paths start at ESP32 GPIO14 and GPIO15 through r3 and r4 (diagram.json lines 27, 30). Each of the four LED cathodes returns to ESP32 ground (diagram.json lines 23, 26, 29, 32). Button connects ESP32 GPIO4 to ground when pressed (diagram.json lines 33–34). Potentiometer signal connects to ESP32 GPIO34 (diagram.json line 35). Potentiometer power connects to ESP32 3.3 V and ground (diagram.json lines 36–37).
    Why it matters
    The four resistor-protected LEDs identify later gesture classes. GPIO4 changes mode and GPIO34 reads the noise control, so prediction changes can be traced to separate inputs.
    Step 1: Four class LEDs, a mode button, and a noise potentiometer connect to the ESP32. The ring marks the classifier controls and outputs.
    Step 1 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  2. 2 Step 2

    Do
    In Wokwi's sketch editor, inspect the model constants, input profiles, and float and int8 weight arrays before starting.
    You will see
    Set input width: #define INPUT_SIZE 12 (sketch.ino line 19). Set hidden-layer width: #define HIDDEN_SIZE 8 (sketch.ino line 20). Set class count: #define CLASS_COUNT 4 (sketch.ino line 21). Map shake LED to GPIO12: #define PIN_LED_SHAKE 12 (sketch.ino line 23). Map tap LED to GPIO13: #define PIN_LED_TAP 13 (sketch.ino line 24). Map tilt LED to GPIO14: #define PIN_LED_TILT 14 (sketch.ino line 25). Map circle LED to GPIO15: #define PIN_LED_CIRCLE 15 (sketch.ino line 26). Map button to GPIO4: #define PIN_BUTTON 4 (sketch.ino line 27). Map potentiometer to GPIO34: #define PIN_POT 34 (sketch.ino line 28). Allocate first-layer weights: float w1[INPUT_SIZE][HIDDEN_SIZE]; (sketch.ino line 45). Allocate output-layer weights: float w2[HIDDEN_SIZE][CLASS_COUNT]; (sketch.ino line 47). Allocate quantized first-layer weights: int8_t qw1[INPUT_SIZE][HIDDEN_SIZE]; (sketch.ino line 50).
    Why it matters
    The dimensions fix the 12-input, 8-hidden, 4-class model used later. The visible GPIO defines class LEDs and controls, and the float and int8 arrays make the two weight representations explicit.
    Step 2: The sketch declares 12 inputs, 8 hidden units, 4 classes, and float and int8-style storage. The ring marks the visible model budgets.
    Step 2 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  3. 3 Step 3

    Do
    On Wokwi's simulation toolbar, start the simulation with the supplied potentiometer setting and wait for Mode 0 in Serial Monitor.
    You will see
    Input: start Mode 0 with the potentiometer near its supplied setting. Observed: "Target: SHAKE | Noise: 52%". Observed: "Prediction: SHAKE | Confidence: 73.4% | Latency: 414 us". Observed: "Accepted: yes".
    Why it matters
    The target and prediction match in this run. Confidence exceeds the sketch's acceptance threshold. The latency is reported in microseconds. The observed 52% noise belongs to this run, not a fixed promise.
    Step 3: real Wokwi Mode 0 prints SHAKE, 52% noise, 73.4% confidence, 414 us, and Accepted yes; the ring marks the prediction.
    Step 3 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  4. 4 Step 4

    Do
    Press the mode button once, or send 1 in Serial Monitor, and wait for Mode 1.
    You will see
    Input: send 1 in the Wokwi Serial Monitor. Observed: "Float bytes: 560 | Int8-style bytes: 184". Observed: "Float: SHAKE | 68.4% | 414 us". Observed: "Int8-style: SHAKE | 68.4% | 208 us".
    Why it matters
    Both representations predicted SHAKE in the displayed comparison. The Int8-style fixture reports fewer bytes. Its displayed latency is 208 us versus 414 us for float. One matching run does not establish deployment accuracy.
    Step 4: real Wokwi Mode 1 reports 560 versus 184 bytes and matching SHAKE predictions at 68.4%; the ring marks both latency rows.
    Step 4 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  5. 5 Step 5

    Do
    Press the mode button again, or send 2 in Serial Monitor, and wait for Mode 2.
    You will see
    Input: send 2 in the Wokwi Serial Monitor. Observed: "Prune 0% -> TAP 46.7% | 412 us". Observed: "Prune 30% -> TAP 35.3% | 463 us" and "Prune 60% -> TAP 34.9% | 587 us". Observed: "Prune 85% -> TILT 25.8% | 428 us".
    Why it matters
    Confidence falls across the first three displayed levels. The class changes from TAP to TILT at 85%. Latency is not monotonic in this fixture. The displayed gate warns that heavy pruning can change class or confidence.
    Step 5: real Wokwi Mode 2 prints the 0%, 30%, 60%, and 85% pruning rows; the ring marks their differing class, confidence, and latency.
    Step 5 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  6. 6 Step 6

    Do
    Send 3 in the Wokwi Serial Monitor and wait for Mode 3 at the current potentiometer setting.
    You will see
    Input: send 3 with the potentiometer at its current setting. Observed: "[MODE 3] Threshold and noise test". Observed: "Noise: 51% | Threshold: 70%". Observed: "Passes: 3/12".
    Why it matters
    The run reports the same 70% threshold for this mode. Three of twelve fixture windows pass at 51% noise. The setting and count are visible in the same monitor group. The gate requests repetition across other noise settings.
    Step 6: real Wokwi Mode 3 shows 51% noise, a 70% threshold, and 3/12 passes; the ring marks the two value rows.
    Step 6 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  7. 7 Step 7

    Do
    Turn the potentiometer to its high end, or send H in Serial Monitor, and wait for the next Mode 3 result.
    You will see
    Input: send H in the Wokwi Serial Monitor. Observed: "Noise override: 100%". Observed: "Noise: 100% | Threshold: 70%". Observed: "Passes: 4/12".
    Why it matters
    The H command changed the noise input to 100%. The threshold remained 70%. This run reported four passes out of twelve. The count changed under noise while the decision rule stayed fixed.
    Step 7: real Wokwi Mode 3 shows the 100% noise override, unchanged 70% threshold, and 4/12 passes; the ring marks the result.
    Step 7 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)

Chapter checks

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

  1. A team has a quantized model that fits in flash, but the tensor arena plus audio feature buffer leaves almost no SRAM for stack, logs, and firmware state. What should the team do before approving the TinyML deployment?

    Return to the chapter’s knowledge check
  2. A TinyML model has 80,000 INT8 weights. Where do the weights live, and what separately bounds SRAM use?

    Return to the chapter’s knowledge check
  3. A vibration anomaly model performs well in the notebook, but field firmware samples the accelerometer at a different rate and uses a different FFT window. What is the most likely problem?

    Return to the chapter’s knowledge check

Caution

This readable dense network uses synthetic gesture profiles and int8-style storage; it is not a trained or production TensorFlow Lite Micro model. Simulator latency is not hardware certification. Retest with representative physical sensor windows, the actual sample rate and preprocessing, full SRAM headroom, power, operators, and update path before deployment.

Return to TinyML on Microcontrollers · Browse Labs