Installing firmware on the ATS Mini

Every ATS Mini firmware release ships three archives, and only one of them belongs on your radio. Nothing inside the images says which is which, so picking the right one is the part worth getting right — the writing itself is the easy half. The firmware installer on this site reads the answer off the chip, and a mismatched archive is refused unless you deliberately override it; this page explains what it is checking, and how to do the same by hand.

Three archives, one of them yours

A release publishes an ospi archive, a qspi archive and a lilygo-t-embed archive. Each one expands to a single folder named ats-mini-v<version>-<variant> — for example ats-mini-v2.38-ospi. That folder name is the only reliable marker of what is inside.

It has to be, because the images themselves barely differ. The bootloader and the partition table are byte-identical across all three archives — confirmed here by hashing them. Only ats-mini.ino.bin, the application image, changes, and it changes by roughly 2 kB of PSRAM driver configuration. That is the whole difference between the builds, and it is why a loose .bin separated from its folder can never be traced back to the hardware it was meant for.

The lilygo-t-embed archive is not a third PSRAM variant. It is built for the LILYGO T-Embed SI4732, a different receiver. The firmware project’s own warning is that flashing it to an ATS Mini can damage the receiver, so treat that archive as belonging to someone else’s radio.

OSPI or QSPI: telling them apart

The two ATS Mini builds differ only in how the ESP32-S3 module’s PSRAM is wired: octal (OSPI), 8 MB, or quad (QSPI), 2 MB. Same board otherwise, same radio chip, same display, and nothing on the outside tells them apart — the question comes up often enough that the firmware project has a discussion thread titled “OSPI vs QSPI: How can I see what I have?”.

The installer does this in its second step: it reads the PSRAM capacity out of the chip’s eFuse and names the build the board needs. To check by hand, run esptool flash-id (flash_id on esptool 4.x) and read the Features: line. An 8 MB reading means OSPI, a 2 MB reading means QSPI. The first direction is the firmware maintainer’s own, from the project’s discussion #174: “Embedded PSRAM 8MB … is only available via OSPI”; the second was checked against a QSPI radio while this page was written — capacity code 2, reported as Embedded PSRAM 2MB. Read the capacity, never the vendor: the same vendor string (AP_3v3) turns up on both an 8 MB and a 2 MB part, so it tells you nothing about which build you need.

There is a third check, but only after the fact: on a radio that already boots, Menu → Settings → About shows a PSRAM figure, and that figure is non-zero when the running build matches the hardware. Useful for confirming you got it right; no help at all in choosing, since it needs working firmware to read.

Installing from this site

The firmware installer writes to the radio over its USB cable from the browser, with nothing to install. It needs the same Chromium-based browser the controller needs, and a data-capable USB-C cable — see Connecting your ATS Mini. Five steps:

1. Connect over USB. You pick the radio’s port in the browser’s chooser. If the controller is already connected over USB, that connection is closed and the port handed over.
2. Identify the hardware. The app reads the chip and its PSRAM capacity, and names the build this board needs. This is the step everything else depends on.
3. Download the matching release. The live release list from the firmware project, with the archive that matches your board marked and the ones that do not flagged as mismatches.
4. Load and verify the image. Drop the archive back in. The app reads the version and variant out of the folder name and compares them with what step 2 found. A mismatch is refused unless you deliberately override it.
5. Back up, then write. Read a copy of the current flash first, choose three-file or merged, accept the risk, write.

The archive is read in the browser and never uploaded anywhere. Bluetooth cannot do any of this: the ESP32-S3’s bootloader is only reachable over the USB serial link, so the radio has to be on a cable.

Two things to do once the write finishes

Neither is optional, and skipping the second one looks exactly like a failed flash: the radio works, and the app cannot see it.

1. Switch the radio off and on. The installer asks the chip to restart itself when the write completes, but that request travels on a control line the board has to wire up, and not every one does. Where it is not wired the request still succeeds and the radio simply stays on the flasher until you power it off. A dark screen after a write is not a failed write.
2. Set USB Port → Ad hoc on the radio again. From firmware 2.34 the USB remote interface is off by default. A merged write always clears that setting, and a three-file write can. Until you switch it back on the radio ignores the app completely — see Connecting your ATS Mini.

Both of these were seen on a real radio while this page was written, on a board whose reset line is not wired.

What goes where

An archive contains a CHANGELOG.md and four images. You write either the first three at their own addresses or the fourth on its own — never both.

The choice is not only about convenience. The merged image is 8 MB, and about 6.3 MB of it is padding — the real payload is around 1.7 MB. Writing it covers the entire flash chip, including the region where the radio keeps its own settings, so the merged write always resets them. The three-file write transfers only the payload, roughly 1.7 MB, and leaves everything outside those three regions alone, so your settings usually survive.

“Usually” is the honest word, and it is upstream’s word too: the firmware documentation says the receiver settings might be reset in some versions on the three-file route. Treat surviving settings as a bonus rather than a guarantee, and write down anything you would hate to re-enter.

Doing it without this site

The firmware project documents three routes of its own, and all three want the same files at the same addresses. Use one of these if you would rather work with the tool the firmware authors use — and the last two if your browser has no Web Serial at all.

esptool-js, in a browser

Espressif’s own web flasher at espressif.github.io/esptool-js. Connect, add the files at their addresses, press Program, and wait for Leaving... Hard resetting via RTS pin... in the log. Windows, macOS and Linux; Chromium-based browsers only, the same limit this site has.

Flash Download Tool, on Windows

Espressif’s desktop tool. Chip Type ESP32-S3, WorkMode Develop, LoadMode UART; add the files, tick the box next to each one, set the COM port, press START. It is finished when the log says is stub and send flash finish.

esptool.py, on the command line

One command with --chip esp32s3 and --baud 921600, then the addresses and file names. The firmware documentation gives the exact line for both the three-file and the merged route.

Whichever you use, power the radio off and back on afterwards, then check Menu → Settings → About for the version — and for that non-zero PSRAM figure.

Before you write anything

• Take a backup. It is the only way back to the firmware the radio has now, and you can only take one while it still runs. Firmware backup and recovery covers it.
• Use a data cable, and keep the radio powered. An interrupted write is the failure that turns a five-minute job into a recovery job.
• Look for BOOT and RESET buttons on the board before you start, not after. With them, forcing the radio to listen to a flasher is a two-button sequence; without them it is considerably more awkward.
• Do not flash the T-Embed archive to an ATS Mini.

What a new version actually changes for you is in Firmware versions — the 2.34 threshold for Bluetooth and fast tuning, and the CB band range that gets narrower when you cross it. If you are considering something other than the official firmware, start at Alternative firmware.