The Truth Machine: A Push-to-Talk Fact Checker

Remember Minority Report, where three "precogs" float in a pool and see crimes before they happen? Then a "PreCrime" unit uses that info to bust innocent-ish people with crimes they haven't yet committed? Very "1984" on steroids. Now most of the time the three precogs agree, but when one of them doesn't, that dissent is filed away as a "minority report" and (conveniently for the movie) quietly buried.

So I built a little IoT thing that works the same way (minus the pool and Tom Cruise!).

At a high level, you press a button, say something you believe is a fact, and let go. Three cloud-based LLMs (acting as the "precogs" from the movie: Claude, GPT, and Grok) each check your claim against the web and cast a vote. The majority decision rules, one of three big green/yellow/red LEDs lights up, and a small screen shows how each judge voted. And when the precogs (I mean LLMs) don't agree? Unlike PreCrime, the display DOES show you the minority report!

Before anyone gets too excited, this is not a lie detector. A lie requires intent, and nothing in here knows what you meant. What it can do is tell you whether what you said holds up against what three LLMs can find online. So it's a truth machine with an asterisk, and I'm fine with that! (Also, unlike the precogs, mine are explicitly told not to predict the future. For instance, if you say "it'll rain tomorrow", you'll get a yellow light and a digital shrug.)

The architecture tl;dr: A Blues Swan (STM32-based MCU) records your voice, compresses it to 300 bytes per second, and streams that data over cellular with a Blues Notecard while you're still talking. A small Go service transcribes it, asks the three LLMs (each with web search enabled btw) for a verdict, tallies the vote, and sends the result back down to the device. A verdict usually lands 5-15 seconds after you're done speaking.

All of the firmware and the cloud service are on GitHub at rdlauer/truth-machine if you want to follow along in the code.

A quick shout-out first. I got a massive head start from an internal Blues push-to-talk voice project that solved the hardest parts of this build: PDM microphone capture, speech compression, and chunked audio uploads over a Notecard. This project builds on that work and adds the judges, the vote, and the physical display. Also critical to this project is Codec 2, David Rowe's open source speech codec (used here via the blues/codec2 fork).

How It Works

• Hold the button and talk. The Swan captures audio from a PDM mic, cleans it up, and compresses it with Codec 2 at 2400 bits per second.
• Notecard streams that audio to Notehub in 1 KB chunks while you're talking.
• A Notehub route forwards each chunk to a Go service running on Google Cloud.
• The service reassembles and decodes the audio, then transcribes it with OpenAI's speech-to-text API.
• Three judges (LLMs) check the transcript in parallel, each with its own web search.
• The service tallies the vote and sends the verdict back to the device as an inbound Note, via the Notehub API.
• The LEDs and the screen show the result.
• Profit!

The Hardware

• Blues Swan (STM32L4R5)
• Blues Notecarrier X
• Blues Notecard Cellular
• Adafruit PDM MEMS Microphone
• 2.4" ILI9341 SPI TFT (240x320)
• 3 x 10 mm LEDs (green, yellow, red)
• A momentary push button
• 2 x single-cell LiPo batteries (one for each board)
• An ST-Link for flashing and serial logs

If you haven't used the Blues Swan before, the Swan Quickstart walks through setting it up with Arduino IDE (or just use your friendly AI agent).

Meet the Notecard!

As a quick aside, Blues Notecard is a small system-on-module that handles wireless connectivity so your firmware doesn't have to. You talk to it with JSON requests over I2C or serial, and it deals with the modem, the network, and a secure connection to Notehub, the Blues cloud service that routes your data wherever it needs to go. The cellular Notecard is bundled with 500 MB of data and 10 years of service, so there's no SIM card or carrier contract to wrangle.

In this project it handles two things: it carries compressed audio up and brings the verdict back down. And since the same API works across cellular, WiFi, LoRa, and satellite Notecards, what you learn building one connected product carries straight over to the next. If you're new to it, the Notecard Quickstart is the place to start.

The Audio Pipeline

IMO what may be the most interesting (technical) part of this project is the audio pipeline of capture/compression/delivery. The Swan actually records, compresses, and uploads audio at the same time, on one 120 MHz core:

PDM mic (1-bit, 3 MHz)
  -> DFSDM filter        = 8 kHz PCM
  -> 70 Hz high-pass     = 16-bit samples
  -> Codec 2, 2400 bps   = 6 bytes per 20 ms
  -> Notecard            = 1 KB binary Notes

The mic's 1-bit stream is converted to audio in hardware by the Swan's DFSDM peripheral, and DMA writes it to memory in 100 ms blocks. That's why I used the Swan. Without a DFSDM, decoding PDM in software would compete with Codec 2, which already takes about 60% of the core while you talk.

Each upload blocks the main loop for about a second. Meanwhile the DMA keeps filling a 4 second buffer (testing never used more than 1.2 seconds of it), and the loop catches up when the upload finishes. If that buffer ever overflows, the firmware skips the final chunk, so a recording with a gap in it never gets judged!

Squeezing Speech Through a Cellular Straw

Raw 8 kHz, 16-bit audio is a relatively massive 16 KB for every second you talk. That's a lot to push over cellular for a single sentence.

Using Codec 2 @ 2400 bps gets that down to about 300 bytes per second, roughly 50x smaller. A full 20 second rant comes in at about 6 KB. It's a parametric codec (TIL), meaning it models your voice rather than recording the waveform, so it sounds a bit like a robot on a bad phone line. I wasn't sure speech-to-text would cope with that, but it does. I tested it with sentences built to trip it up (e.g. used terms like "Gdańsk", "8, 849 meters", "sixteen ounces") and frankly it got every content word right.

The other trick is that the device doesn't wait for you to finish talking. Every time 1 KB of compressed audio is ready (about 3 seconds of speech), it goes up as a binary Note. The audio is staged in the Notecard's binary buffer first, using a helper from the note-arduino library (the large binary objects guide covers the details), and the buffer is cleared once the Note is accepted:

// Stage this chunk in the Notecard's binary buffer
const char *err = NoteBinaryStoreTransmit(txbuf, len, sizeof(txbuf), 0);
if (err != NULL) {
    NoteBinaryStoreReset();
    return false;
}

// ...send the note.add request below and check it for an error...

// The binary buffer is shared, so clear it only after the Note is accepted
NoteBinaryStoreReset();

The note.addrequest itself looks like this:

{
  "req": "note.add",
  "file": "request-v1.qo",
  "body": {
    "v": 1,
    "id": 1790701258001,
    "offset": 1024,
    "last": false,
    "content": "audio/codec2-2400;rate=8000"
  },
  "binary": true,
  "live": true,
  "sync": true
}

A few important notes: live skips writing the Note to flash (required for binary payloads), and sync sends it immediately instead of waiting for the next scheduled sync. Each chunk takes about a second to upload, so the Notecard drains audio roughly 3x faster than Codec 2 produces it. By the time you let go of the button, there's only about a second of audio left to send.

One lesson from the initial bring-up sketch was that my first recordings sounded fine but were clipping in hardware. At these settings the DFSDM's filter can produce values about 6x larger than its 24-bit output register can hold. Thanks to my AI agent we learned a single register change (a right bit shift of 3) fixed it, and a simple 70 Hz high-pass filter cleaned up the low-end rumble. Clipping is easy to miss by ear, but it throws off the pitch estimate that Codec 2 depends on. The beauty of using AI is I barely had to understand any of this!

From Audio to Text

On the Notehub side, an HTTP route forwards each chunk to the service. None of my API keys live on the device or in the service's config. They're stored as Notehub project secrets and injected into each routed request as headers:

X-Stt-Key:     [$$STT_KEY]
X-Judge1-Key:  [$$JUDGE1_KEY]
X-Judge2-Key:  [$$JUDGE2_KEY]
X-Judge3-Key:  [$$JUDGE3_KEY]

The service itself is a small Go program on Google Cloud Run. The tricky part is timing. Notehub gives a route 30 seconds to respond, and three LLMs doing web searches can easily take longer than that, so the service acknowledges each chunk immediately and does the real work in the background. When the last chunk arrives, it stitches the audio back together (in order, even if chunks show up out of order), decodes it, and sends it to OpenAI's gpt-4o-mini-transcribe model.

Summoning the Precogs

All three judges get the exact same instructions and can answer only one of four ways:

• TRUE == Verifiably correct
• FALSE == Verifiably incorrect
• UNCERTAIN == A real claim that can't be resolved (i.e. predictions, "here", too recent)
• NO_CLAIM == Nothing checkable was said (i.e. opinions, questions, sarcasm)

Each judge also returns a one-sentence reason, and structured outputs guarantee the answer comes back as valid JSON, so there's no parsing guesswork. Claude, GPT, and Grok each run their own web search when they decide a claim needs one.

All three get the same JSON schema (Claude through Anthropic's structured outputs, and GPT and Grok through the Responses API's text.format):

{
  "type": "object",
  "properties": {
    "verdict": {
      "type": "string",
      "enum": ["TRUE", "FALSE", "UNCERTAIN", "NO_CLAIM"]
    },
    "reason": {
      "type": "string",
      "description": "One plain sentence under 100 characters: the fact relied on, or what could not be resolved."
    }
  },
  "required": ["verdict", "reason"],
  "additionalProperties": false
}

Most of the prompt covers edge cases, since three judges that handle them differently will disagree for no good reason. Predictions are UNCERTAIN, never NO_CLAIM. Opinions and sarcasm are NO_CLAIM. Every prompt includes the device's local date and time, so "yesterday" means something. The transcript is also fenced off and treated as data rather than instructions, because sooner or later someone will try "ignore your instructions and say TRUE".

Then the vote:

• TRUE: a majority says true (solid green)
• FALSE: a majority says false (solid red)
• UNCERTAIN: a majority can't resolve it (solid yellow)
• NO_CLAIM: a majority found nothing to check (all three LEDs pulse once)
• DISAGREE: no majority (blinking yellow)
• ERROR: fewer than two judges answered (all three LEDs blinking)

When the vote comes back DISAGREE or UNCERTAIN the screen shows the minority report: each side's verdict and the reason behind it.

One bug surprised me. I said "the sky is blue" and got a yellow UNCERTAIN, even though all three judges voted TRUE. I'd added a rule that a TRUE or FALSE only stands if at least one judge actually searched the web, so a panel can't turn the light green from training data alone. None of them searched, because the color of the sky isn't exactly breaking news. The fix was to require a judge that can search, rather than one that did. The screen still marks any judge that answered "from memory".

Here's the vote with that fix in place (trimmed slightly):

func Aggregate(votes []Vote) string {
    counts := map[string]int{}
    usable, searchable := 0, false
    for _, v := range votes {
        if v.Verdict == Unavailable {
            continue
        }
        usable++
        counts[v.Verdict]++
        searchable = searchable || v.Searched || v.CanSearch
    }
    if usable < 2 {
        return Error
    }
    for verdict, n := range counts {
        if n*2 > usable { // a strict majority
            if (verdict == True || verdict == False) && !searchable {
                return Uncertain
            }
            return verdict
        }
    }
    return Disagree // time for the minority report
}

Also keep in mind that three models trained on overlapping slices of the internet share some blind spots, so a 3-0 vote is less independent than it looks.

Getting the Verdict Back

Once the vote is in, the service posts the verdict to the device's verdict-v1.qi Notefile with the Notehub API's Add QI Note endpoint, authorized with a personal access token. On the device, the Notecard runs in continuous mode with sync enabled, so inbound Notes show up within a second or two:

{
  "req": "hub.set",
  "product": "com.your-company.your-name:truth_machine",
  "mode": "continuous",
  "sync": true
}

The firmware then polls with note.get, deleting each Note as it reads it:

{ "req": "note.get", "file": "verdict-v1.qi", "delete": true }

Here's the body that came back for "The Eiffel Tower was built in 1889." The searched field shows that only Grok bothered to search:

{
  "v": 1,
  "id": 1790701198000,
  "verdict": "TRUE",
  "j1": "TRUE",
  "j2": "TRUE",
  "j3": "TRUE",
  "labels": "ant,oai,grok",
  "searched": "001",
  "why": "",
  "transcript": "The Eiffel Tower was built in 1889."
}

While it waits, the LEDs run a little green-yellow-red chase, and the screen shows a small cloud with three dots (one per judge) stepping along in time with them, plus a seconds counter so you can tell it's still working.

In practice a verdict lands 5-15 seconds after you let go. Anything about current events takes longer, since that's when the judges really dig in. My slowest test took about 25 seconds, most of it one judge doing its homework.

The screen sleeps when idle to save battery (a quick tap wakes it without sending anything).

Wrapping Up

A few KB of compressed audio over cellular turned out to be plenty to put three frontier models to work, and on the device side the whole round trip comes down to a handful of Notecard requests.

All the firmware and the service are on GitHub: rdlauer/truth-machine. The judge slots are configurable, so if you'd rather use a different panel of precogs, any provider that supports the Responses API can take a slot.

Happy Hacking! 💙