Reddit:Electronics

Hello everyone! About 2 months ago on a whim I ordered 6x of these IV-11 VFD tubes from eBay, and decided I wanted to design and build my very own VFD tube clock! After getting good tips and feedback on reddit, prototyping everything on a breadboard, designing a custom PCB, and soldering it all together, here's the finished result! This is my first real personal project as a new EE major and I'm thrilled with how it turned out.

The clock runs on an Arduino Nano Every with 6x daisy-chained 74HC595 shift registers and UDN2981A high-voltage source drivers, one pair per tube. The anode and grid rails run at 25V from a boost converter, and the filament runs at 1.5V from a buck converter, all from a single 5V USB supply.

A full writeup covering design decisions, schematic, and PCB layout is on my GitHub Repo. Stars are appreciated! :)

Work in progress! I was inspired by numerous #Minecraft inspired IRL compass and the fact i could not buy it was the driving force to develop one.

The needle animation works fine; it is the first step in order to make the final product.

I built it from ground up (Custom LED matrix, 3d printed housing), if anyone needs more details on the hardware or anything related to the project feel free to comment and ask away.

P.S. It is still a prototype so it's a little a little janky and the custom PCB is held by some tape.

I designed DC spot welder controller up to 4kA+ which can be powered from high current source or extrenal 12VDC source. I want to setup it with 4s or 2p2s LEV40 pack.

If it passes the tests I will make it open-source.

Functions:

- Settable amount of energy into the weld in reasonable time with 50us control loop

- Autopulse with settable delay for example pulse will be send after 300ms after shorting electrodes

- Manual trigger (no delay)

- Measuring source voltage

- And maybe others

Made a simple online tool for minimizing Boolean logic: https://www.logic-solve.com/

Drop in a truth table or PLA and it gives you the optimized version along with Verilog/VHDL/C output and a K-map view. Runs locally in the browser for smaller designs.

Figured it might be useful for some of you working on digital stuff. Especially folks working with hardcore, transistor or relais computers. With this you can minify your designs.

For more detail: https://blog.mehmetasaf.me/bts7960/

The image quality isn't great, but considering I got them for free, it's not bad.

These are a couple of auxiliary sensor enclosures I made for my Farmbot. The first box is power distribution and housing for i/o of the RS485 7 in 1 soil sensor and an array of moisture sensors. All through USBC ports and RJ45. 24v for the 7 in 1, 5v for the extra USB power ports and the Max485. Not pictured is the max485 circuit and the associated wiring. Box two is a relay enclosure to control 120v pumps and lights.

All with custom faceplates to identify the ports so nobody mistakes the RS485 port for a standard USBC. Pretty simple stuff but it's still fun.

Built this last year based on Ben Eater’s 8-bit computer design using 74LS series ICs on breadboards.

Implemented core modules including registers, ALU, program counter, memory address register, and control logic. The LEDs are used to visualize bus states and output during execution.

Biggest challenges were signal stability and debugging wiring issues across multiple modules. Getting consistent clock behavior also took some iteration.

Overall, it was a great hands-on way to understand how a simple CPU operates at the hardware level.

I found a piece of a laptop with a fingerprint scanner from 2007 in a junk bin. Surprisingly, it works perfectly with Windows 11 and reads my fingerprint without any problems. It requires a 3.3-volt voltage regulator to power it. I 3D-printed the enclosure and came up with a pretty good device.

Thing of beauty! Wanted to clean it before testing it but its so pristine inside :O

If you saw my last post about accidentally frying my CH32V006 dev board into a working state, this is the next chapter of that mess.

Quick recap: I'm building a custom CH32V006 dev board for OpenServoCore, my project to turn cheap MG90S-class servos into smart actuators with a Dynamixel-style single-wire UART. After the 0.84V rail saga, I had a working board. Time to bring up the Rust bootloader (tinyboot) over UART.

Except UART didn't work.

Specifically, TX worked perfectly. I could blast "Hello world" out of the chip all day. But sending anything into the MCU? Total silence. The HAL driver is essentially the same as the V003, which works fine, so I was pretty sure this was hardware, not firmware.

I scoped the RX line while shoving a stream of 0x55 (UUUUUU…) into it from the host. Quick one-liner if you've never used it:

Alternating 1s and 0s, perfect for scoping.

What I expected: a clean 0V to 3.3V square wave. What I got: a 180 mV ripple sitting on top of 3.3V. Min 3.20, max 3.38. The line was being held high so hard that my USB UART adapter could only sag it by a couple hundred millivolts when it tried to send a zero. Touching RX directly to ground snapped it cleanly to 0V, so the wiring was fine. The driver just couldn't drag it all the way down.

Back to the schematic. The RX line passes through a 74LVC2G241 tri-state buffer that handles the half-duplex direction switching. TX_EN low = listen (DATA -> RX), TX_EN high = talk (TX -> DATA). I'd been picturing this buffer as a passive switch, like a piece of wire that conditionally connects two nets.

By now you electronics gods here probably already figured out what's the issue by now, but I didn't...

Anyways, when TX_EN is low, that buffer is actively driving RX with whatever it sees on DATA. And DATA sits at 3.3V via its own 10K pullup when the bus is idle. So the buffer was reading 3.3V on DATA and pushing 3.3V back out of its high-side MOSFET onto RX with ~24 mA of drive and very low R_DS(on). I was fighting a CMOS push-pull output stage with a USB UART chip. The buffer won. Always.

The firmware workaround is to assert TX_EN while reading. That disables the DATA -> RX path and lets RX fall back to its own pullup, which the host can actually drive. Confirmed it live by poking 3.3V onto the TX_EN pad and watching the ripple snap into a clean rail-to-rail square wave. It's such a satisfying flip on the scope.

The real takeaway, however, is thatTX_EN isn't really a transmit enable. From firmware's view it looks like one, but electrically it's a mux select that picks which buffer drives the bus. Calling it "transmit enable" is what put me in this mental hole in the first place.

For Rev B, the actual fix is a hardware jumper that lets RX bypass the buffer for plain UART mode. Why hardware and not just firmware? Because tools like wchisp use the UART to read/write the CH32's Option Bytes outside of any firmware I control. If my UART depends on my firmware to function, a fresh chip or a half-flashed bootloader can lock me out of recovery. Recovery-path peripherals shouldn't depend on firmware to work.

If you want a more details with scope photos, the schematic, a video of the workaround in action, here is the full writeup.

Teardown video does go over the related PCBs at the component level, with plenty of components being discussed and pointed at. Discussion of various board sections. Thought it might be of interest to some folks here.

Ordered these a few weeks ago and honestly expected the usual first-spin disasters. Instead after hand-placing components and a reflow session everything came up clean on first power-on which is a rare event, so I had to share.

The board is built around an ESP32-S3 as the main controller, talking over SPI to an AD74416H (4-channel 24-bit ADC/(IV)DAC combo, honestly the heart of the whole thing) and five ADGS2414D octal SPST switches that form a 40-point MUX fabric. A DS4424 handles fine iDAC trimming of the 3 output rails, a HUSB238 negotiates USB-PD, and a PCA9535 expands the I²C-controlled GPIOs. Four e-fuses sit in the power path for output protection.

The whole point of the design is to expose all of this as an MCP server and as Python API so AI assistants or scripts can autonomously probe, drive, and debug real hardware, measure voltages and currents, sweep outputs, capture ADC waveforms without a human in the loop for each step. Since handing an AI real control over hardware is a bit nervewracking, there are hard guardrails baked into the firmware and Python API, you can define a board profile for the DUT and it physically can't exceed the defined voltage limits or drive the wrong outputs.

There's also an optional RP2040 HAT that adds a 125 MHz logic analyzer and CMSIS-DAP probe.

Surprised it worked without any bodge wires, I'm now starting to polish the tools and firmware for it.

Full schematics, firmware, and build instructions: https://github.com/lollokara/BugBuster

Anything radio never gets old to me. Somehow I missed this TA7642 radio on a chip until I came across it via surplus. I thought this might make a neat project for for an EMI sniffer. AM is great at detecting the various noise/trash thrown off by modern digital electronics. I find it a fascinating alternate world that you can explore, given the right tool.

There are various plans around the internet for projects with the TA7642, including an application example in the datasheet. So, coming up with a design is really easy.

Keep in mind that this is a prototype and there's tons of room for improvement.

On the left side of the board is the power/audio section, to the right is the RF.

I opted to exclude a tuning capacitor and go with fixed SMD capacitors on a dip switch. I know it's dirty, but for my application it's fine. Now I can switch-tune to various frequencies to get the best response to EMI and keep the overall footprint smaller.

It runs on a single AAA battery with about 1.3mA of current draw, which means it will run a very long time, some 500+ hours.

What became apparent while I was building it is how tiny you can actually make it. With custom boards and SMD components, this sucker will shrink down a ton. I'll probably revisit this idea sometime in the future.