Pitch script – 5 minutes (pitch-deck-5min.html)
Spoken text for the 5-minute deck (cover + 12 slides). [click] = push the clicker one time (same slide, next step). → = the click that goes to the next slide. The times are targets. The run ends at about 4:20 to 4:25, so you have at least 35 seconds of buffer. Speak to the jury, not to the slides. Say the numbers slowly.
Before you start:
- Show the cover on the screen (slide 1).
- Open
/finalin a second tab as a backup. - Push N if you want the presenter notes.
1 · Cover (before the clock starts)
Say nothing. When the moderator tells you to start: →
2 · Without Wi-Fi, the line control gets no torque values · 0:00 (15 s)
A torque tool tightens each screw. It sends the torque over Wi-Fi to the line control. Now the Wi-Fi connection of the tool breaks. The line control gets no torque values, so the car must not move. The line stops.
→
3 · Each minute of line stop costs €50,000 · 0:15 (10 s)
The line makes one car each minute. So each minute of line stop costs about fifty thousand euros.
→
4 · We must know when a connection breaks, and why · 0:25 (8 s)
We must know in seconds why a connection breaks. And we must tell the one person who can fix it.
→
5 · A connection has five steps · 0:33 (18 s)
Tesla already records the Wi-Fi with its own sensors. The sensors keep only the headers, not the content. Gearbox reads these recordings. A connection has five steps: find the network, join the access point, log in, agree on keys, talk.
[click]
This tool finds its network.
[click]
After that, nothing occurs.
→
6 · Gearbox shows the step where the connection broke · 0:51 (22 s)
The step where the connection breaks shows the cause.
[click]
Here, the device scans, but it does not join: its access point is off.
[click]
Here, sixty-three devices stop at log in: the login server does not answer.
[click]
Here, the access point disconnects the device on a fixed timer.
[click]
Here, T-03 says "I am leaving" and then stays silent. Four causes, and each cause needs a different fix.
→
7 · We merge the records of all 8 sensors · 1:13 (20 s)
Tesla gave us the recordings of eight sensors, each on its own channel. Seven of the eight sensor clocks are off by up to 1.2 seconds.
[click]
So we put all sensors on one clock. For this, we use the timestamps in the beacons of the access points.
[click]
Then we follow each device through its five steps.
→
8 · Three questions find the cause · 1:33 (35 s)
The engineers on the jury give points for this slide. Speak slowly. The columns on the screen show the three questions: Which step is missing? · What does it affect? · Who sent the last frame?
Three questions find the cause.
[click]
Only T-03 has this fault. Its last frame comes from the tool itself: "I am leaving."
[click]
Only devices of silent access points have this fault. No device tries a second access point.
[click]
Twenty-six access points on all eight channels have this fault at the same time. A radio fault cannot do that. The cause is the login server, or the path to it.
[click]
All 1,477 disconnect frames continue the counter of the access point. So the access point itself sends them. The cause is a controller job or a client policy, not an attacker.
→
9 · Gearbox finds the cause and the owner · 2:08 (15 s)
In summary: 1.1 million frame headers become eleven findings. Two of these findings can stop the line. Each fault has an owner and evidence frames. Now I show you the dashboard.
→ (the dashboard opens)
10 · Live demo on /final · 2:23 (75 s)
Do not read the screen aloud. Say what it means. This version has no replay. The cues in italics are the clicks.
The first line on the screen says that 2 problems can stop the line.
Open "3 devices on TESLA-TOOLS cannot connect" in "Most important warnings".
First, the screen tells the shift lead what to do: do not replace the device, because that does not help. The owner of this fault is IT. For IT, the recommendation is: switch the missing access point on again. Then remove the binding to one access point, so that devices can use the next one. Then the evidence: each claim has its sensor and its frame number.
Click "Copy Wireshark filter".
With one click, a Tesla engineer gets a filter and finds the same frames in the original pcap.
Open the "18 devices …" finding in "Findings".
This finding looks like an attack. The sensors show a fixed timer. The frame counter and the signal level match the access point. So the task for IT is: find the controller job or the client policy that sends these frames, and stop it. 802.11w cannot help here, because the access point itself sends them.
Move the mouse away from the page. Then → (or Next › at the top right)
11 · Gearbox checks 16 fault classes · 3:38 (15 s)
Gearbox checks sixteen fault classes. It found seven. It did not find the other nine, for example congestion, an evil twin or a deauth flood. We show all sixteen, so you see what we checked, not only what we found.
→
12 · Each link has methods that make it reliable · 3:53 (20 s)
Gearbox must not fail when the Wi-Fi fails. It checks the clocks of the sensors, and it finds gaps that only one sensor has. Each fault links to its evidence frames. A second parser, without tshark, reads all 77 evidence frames again. All 77 match. The analysis of the 30 minutes took about fifty seconds.
→
13 · Close · 4:13 (10 s)
This is Gearbox. It finds why a Wi-Fi connection breaks, and who can fix it. It shows tool faults first and phone faults last. Thank you.
End at about 4:20–4:25.
If you are late
| Late at | Cut |
|---|---|
| slide 6 starts after 1:00 | click through the four rows. Say only: "Four causes, and each cause needs a different fix." |
| slide 8 starts after 1:45 | say "Three questions find the cause" and only the disconnect case. Click through the other rows. |
| the demo starts after 2:35 | do not open the "18 devices …" finding |
| slide 11 starts after 3:50 | say one sentence: "Gearbox checks sixteen fault classes and found seven." |
All numbers, with their source
Source: the live analysis https://bmt26.skimu.de/api/datasets/ff1d9f54dee9, unless the line names another source.
- Tesla's recordings: 8 sensors, one on each 5 GHz channel, 30 minutes, 1,118,853 frames (headers only)
- 7 of the 8 sensor clocks are off by up to 1.22 s
- 11 findings · 2 of them can stop the line
- T-03 sent "leaving" (deauth reason 3) at 12:36:32. Then it stayed silent for the last 18 minutes. The analysis says "switched off or restarted", with medium confidence
- 12 devices do not join (3 on TESLA-TOOLS, 9 on TESLA-CORP). Their access point is off. No device uses a second access point (0 of 87)
- login server: 63 devices on 26 access points, all 8 channels · 1,692 identity requests · 0 successful logins
- disconnects: 18 devices on 18 access points · 1,477 of 1,477 frames continue the access point's counter
- 16 fault classes on the slide · 7 found · 9 not found
- 77 of 77 evidence frames match with the second parser (
airframe-pitch-film/pitch-v4/source/check_evidence.py, run again on 26 Sep 2026) - analysis time of the 30 minutes: about 51 s (ingest 25 s, fuse 5 s, detect 21 s)
- €50,000 each minute is a scenario (1 car each minute), from the challenge brief
What Gearbox does not do (do not say it)
- Gearbox does not install sensors. Tesla records the air. Gearbox reads the recordings.
- Gearbox does not send messages to IT. The dashboard shows the owner of each fault.
- Gearbox does not fix the connection. It finds the cause and the owner.
- Gearbox analyses a recorded capture today. Real-time streaming and the scale to thousands of sensors are a design.