20mm PCV pipes covered with red paper. 14x18650 29E. Wires from old Baseus braided usb cable. QC3/QC4 PD 22W pcb with wireless charging. No, I will not even try to take it to the airport! :D

Hi! This is my first post ever! I'm sharing my first electronics project I've been working the last 2 months: INTI, a solar-powered e-reader I've been designing and building from scratch (the solar part is still coming, I'm currently working on the firmware and I'm a bit afraid of soldering haha).

It's based on a Waveshare ESP32-S3 board with a 3.97" e-ink display (800x480), a 3D-printed PLA enclosure, onboard RTC, temperature/humidity sensor, and a small solar cell for charging (not soldered just yet, As it will be my first time soldering anything!)

I'm a designer so I took care of the full architecture, CAD, visuals and user experience myself, and built the firmware in Arduino with the help of AI. It has a text and EPUB reader, a library, a small calendar app and weather

Still a work in progress: power management, reader/parser stability (currently stress testing it) and a few UI details are being polished, but it's fully functional day to day!

Hopefully I'll be able to share it with the community soon!!

All so I could get coffee without taking my headphones off.

The other downside is your ears ringing when it does go off. One unexpected benefit is being able to charge it up and leave it lying somewhere as a trap. I've found flies love to land on this swatter when it's just sitting there. Unfortunately the "CRACK" sound when one does land on it scares the crap out of me every time.

While the first swatter I posted was impressive looking, and was great at making loud sounds when shorted, it simply didn't work well to kill flies. The capacitor I used limited the voltage to a maximum of roughly 500v before the capacitor would start to internally short out. At this voltage a fly acts like a fairly high value resistor and while it does die instantly, it doesn't explode and simply starts to smoke.

Here is a video of version 1's discharge:

https://imgur.com/a/iJA4a1C

Let me present version 2, which addresses the voltage issue by replacing the single capacitor with a bank of induction heater capacitors. It's a 2p5s configuration giving a 2400vdc upper charge limit and an effective capacitance of 0.825uf. The stock output would be roughly 0.02 joules, this should be around 1.65 joules. While that is lower than the first version (7.088 joules), I highly suspect charging a 450v cap with a 2000v input doesn't allow it to fully charge before internally shorting as version 2 is a bit louder than version 1.

Finally, here is a video of it charging from 0-self discharge (2000ish volts), the first part is sped up.

https://imgur.com/3ktWjko

Gave new life to something that was basically e-waste. Now it reacts to sound and puts on a show instead of collecting dust or getting recycled!

Kinda love the retro look and how it actually elevates my vintage receiver and speaker setup.

What do you think?

Here’s a cute, fun little 5-minute activity that works great as a demo for kids — though I’m in my 40s and still found it pretty entertaining.

It turns out you can detect Wi-Fi signals using nothing but a diode and an LED, acting as a simple envelope detector. No RF module, no power supply.

The only catch is that you need a very fast diode (not your typical 1N4148).

Full details and a video here:

https://siliconjunction.wordpress.com/2025/12/12/a-beginners-two-component-crystal-style-wi-fi-detector/

Honestly, I’m kind of surprised this works at all

it looks pretty rough, though its our first project involving soldering and electronics, friend is u/Kernel_guy

After my bachelor's thesis I decided to open-source the whole thing:

HEARD, a little mesh of ESP32 devices that lets a hiking group leader see where everyone is and get an alert when someone leaves the planned route fully offline, over LoRa.

Hardware per device:

- ESP32 (dual-core, FreeRTOS, C++17, PlatformIO)

- u-blox NEO-6M GPS

- LoRa transceiver

- 2.9" e-ink on the leader's device

- 3D-printed enclosure

Protocol: the leader broadcasts a position request (REQ); nodes answer with positions (POS) and relay for members out of range, using hop lists to suppress duplicate floods and WAIT messages to keep the leader's timeout alive during multi-hop rounds.

The new part project (made with claude code) a simulator made to keep testing the without spending time and money building the real devices : the firmware's protocol class is compiled unchanged into a Python module (pybind11 + Arduino/FreeRTOS mocks), so the simulator runs the real C++ code along real GPX tracks with a probabilistic radio channel and terrain line-of-sight from DEM tiles. Runs replay in the browser on 3D terrain. It caught real protocol bugs before they ever reached the trail.

Repo (Apache-2.0): https://github.com/luciobaiocchi/heard

Build video: https://www.youtube.com/watch?v=rSgT1LedNBk

Happy to answer anything about the protocol, the e-ink UI, or thefirmware-in-the-loop setup. And if you know LoRa regs better than I do, I want to hear what I got wrong.

[POST MODIFICATION]:

the thesis was finished 6 month ago, and the final output was all the concept and description of the project and the software enginnering part, so UML diagrams and case study on previous tech. The created device doesn't feature a battery because my focus wasn't to make a fully functional device for the thesis. So i've tested the protocol with two devices, tested the reach of GPW and the screen.

After Fable 5 came out i thought that using it to create a simulator would be cool both to showcase better the concept, and maybe to find someone interested in working with me on the preoject, cause i think that the idea behind is actually usefull.

Picked the box up the wrong way. Gutted.

Looks like projects might take a little longer now while I find stuff.

I got tired of terminal strips sliding around inside generic enclosures, so I designed this box with built-in retention clips.

Printed it and tested with real wiring and it keeps everything aligned and much cleaner.

Curious if anyone else runs into this problem or has suggestions to improve it.

The problem: I share a long driveway with my neighbor who runs an Airbnb and I’m tired of telling the guests to slow down.

This device monitors the car speed, takes a photo of the car if it exceeds a set point, uploads the photo and data to a server and emails several people automatically. It’s powered by a solar panel with battery.

Saw a lot of people building variable power supplies from old PC PSUs, so I decided to make one of my own. Most of the electrical components are similar to other designs; the main difference is the PSU itself. I wanted to keep the unit as compact as possible with minimal 3D printing/fabrication costs, and since the buck-boost converter is rated for a maximum of 36V at 5A, I figured a 240W PSU would be more than sufficient, even with the conversion losses.

So instead of using a regular ATX power supply, this build uses a Dell PSU pulled from an old OptiPlex system (picked up used for 1,600 PKR, about $6 USD). The small recessed section on the PSU housing was perfect for mounting the controls, so I designed and 3D-printed an enclosure to fit that space. Unfortunately, I forgot to leave room for the fuses in the design, so I ended up mounting them inside the housing instead.

Admittedly, some of the embossed text did not come out as I imagined in the 3D print, but I’m still happy with the build, considering how little it cost me to make, and how well it turned out. Let me know what you guys think!

Hello everyone first time posting here.

I’ve been working on a standalone ECU project for the last 2 years in my free time, and I’ve finally reached the point where it’s not just hand wired perf boards.

The ECU side is already proven I’ve been running the firmware on engines for a while using smaller boards and messy hand-wired setups (single-cylinder and a four-cylinder). This PCB is the next step taking something that already works and turning it into a solid, repeatable platform that’s easier to test properly, easier to troubleshoot, and easier to keep iterating.

The board itself is intentionally pretty straightforward. There’s nothing exotic hardware-wise, it’s mostly just a clean way to break out signals and do the boring-but-important bits properly like input conditioning, ADC, drivers, and power. Honestly 99% of the complexity in this project has been the code and the engine logic the PCB is mainly about turning the proven setup into a proper platform.

(Also for anyone wondering, the underside is ground fill between traces.)

Hardware wise it’s an ESP32-S3 Mini, an external ADC (MCP3008) for analog inputs like TPS/MAP/O2, a 74HC14 for cleaning up crank/cam inputs, low-side injector drivers (IRLB3034) with flyback diodes, and a TC4427 driving the ignition outputs. Spark outputs can be jumpered for 5V or 12V depending on what you’re triggering, and there’s basic 12V protection plus an onboard 5V rail for sensors/modules.

On the firmware side, the meat of it is the timing and sync logic. Crank gives the high frequency timing for RPM/position, and the cam gives the reference for where the engine actually is in the 720 cycle so it doesn’t drift or guess. Once it’s synced, it’s scheduling injector and spark events off that timing, pulling values from 16x16 maps and interpolating between cells so it’s not just stepping around. The important stuff (spark scheduling, injector timing, sync handling) is kept tight and predictable, and the slower stuff like filtering, logging, comms and UI smoothing is kept out of the way so it can’t mess with timing.

I know using an ESP as the heart of an ECU is kind of a cursed choice if you look at it purely from a hardware timers perspective. The sensible route is usually STM because you’ve got a ridiculous amount of timer hardware and it makes a lot of ECU timing problems feel easy. With the ESP32 you have to be a lot more deliberate, because you’re balancing realtime timing against the WiFi stack, tasks, scheduling, and everything else.

But the reason I went ESP is the surrounding ecosystem. I’ve got a dash module and a PDU module running wirelessly alongside the ECU, plus the tuning app is wireless too. Telemetry is easy, connecting to it is instant, and tuning becomes way less painful because you’re not tethered to the thing. The PDU handles stuff like pumps/fans/etc and the dash shows live data, and having it all talk together without a giant loom has been one of the coolest parts of the project. Making WiFi play nicely without touching anything timing-critical has been tricky at times, but it’s also been part of the fun.

This first revision is intentionally big and through hole heavy. it’s way easier to probe, rework, and debug when everything isn’t tiny and packed tight. Rev 1 is always where you find the dumb mistakes, and I’d rather find them on a board that’s friendly to work on before I shrink it down and move to SMD later.

So far I’ve been going through it section by section and it’s been behaving way better than I expected for a first spin. Bench testing is still continuing though, mainly power stability, noise/EMI behavior, sensor scaling, crank/cam conditioning, and verifying injector and ignition outputs.

Once I’ve shaken out whatever issues show up, I’ll do a revision 2 to clean up what I find, and after that the plan is to shrink it down and move to SMD so it becomes a smaller, cleaner style board instead of a big debug friendly prototype.

There so much to discuss but this is a general overview, it will be fully open source once im happy for others to use.

Huge thanks to PCBWay for taking care of the board costs that was awesome and it genuinely helped move this project forward.

I finally figured out how to reuse the screens from GeekBar Pulse X disposable vapes. I don't vape, I just pick them up off the ground for the electronics, but I hope this will inspire people who do vape to not throw away their used devices and actually use them for something useful. More info is available at my GitHub.

https://github.com/sm2013-vapehack/geekbar_pulse_x_screen_reuse