A handheld Dragon Radar replica driven by CircuitPython

Nov 11, 2026 Last reply: 19 hours ago 4 Replies
Jump to replies (4)

Plenty of fan props take the easy road with an off-the-shelf round module and a stock Arduino sketch. This build goes a different way: a raw TFT panel paired with an ESP32-S3 WROOM, running Adafruit's CircuitPython to drive everything. The maker picked that chip for its built-in RGB666 driver and the memory headroom for the screen graphics, which seems like a sensible starting point for a 720x720 display.



The hardware side stands out. The casing is circular, white, and 3D printed, with the layer lines left visible, and a stem-style push button sits on top. The screen sits recessed under a green gridded overlay, which gives it a convincing finished look. Underneath, the display assembly is an NV3052C built on an HD40015C40-Y raw panel, with octal PSRAM holding the framebuffer. Some of the display initialization goes out over SPI.



In the demo, pressing the button lights up a radar display with a centered triangle and blinking dots, along with electronic beeping sound effects.



The open question is speed. CircuitPython was quick for prototyping but may be too slow to drive the display, and with no optimization done yet the maker believes the screen could update faster. A port to C would probably be needed to match the show's animation speed. ESP-NOW is named as a possible next step, so there is clearly room for this one to grow.


Putting the framebuffer in octal PSRAM is a clever call. A 720x720 panel eats a lot of memory, and keeping it off the main RAM leaves room for the graphics work. The trade-off is that PSRAM is slower than internal RAM, so heavy redraws could suffer, though with no optimization done yet that is hard to judge.

Does anyone know how the panel gets initialized? Is the whole display setup handled inside the CircuitPython script, or does some of it happen over a separate bus before the graphics code starts running?

Both parts check out from what the maker said. CircuitPython drives all the hardware in the demo, and some of the display initialization is sent via SPI, so a bit of setup goes over that bus before the graphics side takes over.

Since the maker already thinks the screen could update faster, a C port seems like the obvious move before adding anything new. Matching the show's animation speed probably needs it anyway. I would get the redraw loop tight first, then look at ESP-NOW as the follow-up experiment.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required