This note was originally posted on extralongdivision.com
Previously on Dragon Ball Z!
In the last installment of this project I proved the concept with a Frankenstein dragon radar. I’ve actually got something that looks like the real deal now. Keep reading to learn about the development since the last update. In a future post I’ll detail the steps to reproduce the project.
Electrical Design
This section will be short. I had two action items since the last update and I only did one of them. Originally I wanted to make the board 0.8 mm1 instead of 1.6 mm. I decided to keep the PCB2 the same size since that’d lower the USB-C3 connector coming out the back of the enclosure (ominous noises). Also, even if the mounting pins weren’t soldered into place, the SMT4 pads would still adhere the connector to the board.
The only electrical change I did was flip the battery connector polarity to match the ones I already have.

Left: Version 1 battery connector with reversed polarity. Right: Version 1.1 battery connector with correct polarity.
Mechanical Design
Last post, I said I’d wait until new PCBs arrived before redesigning the enclosure. This cost me a couple days of messing with clearance just to mount the PCB. Ultimately I had to make the enclosure’s diameter bigger to correct this. Ironic, since that’s what I was trying to avoid during the original design phase described in the last post.
The button actuator was another issue that I would’ve recognized sooner if I tried to assemble the radar.

The actuator interferes with the user button such that it’s impossible to mount the PCB, even with the aforementioned clearance. Cutting a slot for the user button fixed the issue.

Once I fit the PCB inside the enclosure, I couldn’t actually press the user button because the actuator interfered with the board.

I fixed this by making the enclosure thicker and mounting the PCB in a deeper recess. But now the whole radar is too large to palm in one hand and press the button at the same time. I mentioned a wrist strap in the last post, but using one doesn’t actually help, or at least the ones I have don’t. Here’s me holding the radar as best as I can with a wrist strap on.

A consequence of a thicker enclosure is the USB-C connector not being flush with the slot in the back. Said slot is larger to accommodate a more recessed connector.

So it didn’t matter if the PCB was 0.8 mm or 1.6 mm. Again, I did this mechanical work after the boards arrived. Lesson learned.
Lastly, the speaker nest was so tightly toleranced that removal caused disassembly.

The speaker still works, thankfully. This mishap is actually a feature. A friction fit makes foam tape unnecessary to keep the speaker in place.
Board Bring up
Everything was plug and play with the updated PCB (version 1.1). I followed the
same steps to put CircuitPython on the board and my code ran with no problem. This proves that the SD_MODE pull up resistor I changed to 1M ohms didn’t affect the sound quality from the first round of board bring up.
I did see some differences between PCB version 1 and version 1.1 though. For V1, uploading new code only worked after a hard power reset. Pressing the reset button on the board didn’t help. This problem never happened with version 1.1. Also, the screen would glitch as if the signal timing was off whenever the heartbeat LED5 was on. Again, only for version 1 of the PCB. Not an issue for version 1.1. I haven’t reproduced this on camera yet.
I’m also seeing streaks of discoloring on the display that I wasn’t seeing earlier. It doesn’t show up in photos well, but soft peach/orange vertical blotches overlay whatever’s being shown. It’s especially visible when the screen powers off. Not sure if this is a result of me driving the display incorrectly or some other problem. Either way, it’s negatively affecting the replica’s authenticity.
Cosmetics
If the cover photo didn’t give it away, I didn’t do any post processing on the enclosure. I don’t like the aesthetics, but I’m de-prioritizing looks over other projects/potentially adding more features.
One practical cosmetic issue is screen brightness in direct sunlight. Here’s a side-by-side of the radar in the shade vs the sun.

Left: dragon radar in shade. Right: dragon radar in direct sunlight
The two images accurately represent the difference between shaded and direct light to the naked eye. For the latter, the display acts more like a mirror than a screen. I believe I’m driving the backlight at 100% brightness, but it is still not the most readable in the sun. Using the project for an outdoor scavenger hunt would be very difficult. I might have to source a different screen for future iterations.
Next Steps
I consider the first phase of this project done. The design files are available on the, still undocumented, repository. I promise to have a proper README there once I post the build tutorial here. Be on the lookout for some video content with the radar too.
This page (Dragon Ball Radar: Devlog 2 - Prototype!) was last updated on October 05, 2026.
Text editor powered by tinymce.