ElectronicZoology

Who is the tech-ologist

We stand on the shoulders of giants when we build with knowledge gained from others' efforts. That doesn't make us giants. Be humble. Create with care. Open source is the way.

I'm Josh, a maker, tinkerer, and self-described tech-ologist based on the Bellarine Peninsula (Bellawiyn Country). The garage out back is the lab. The workbench is permanently occupied. The floor has more project boxes on it than I'm prepared to admit.

I've been pulling things apart since I was a kid, long before I had any idea how to put them back together. These days I mostly put them back together, usually into something they were never meant to be. Motors become controllers. Salvaged panels become displays. A toy train becomes a WiFi-enabled rolling experiment in embedded systems.

Do I know what I'm doing? Not really. I'm kinda just making it up as I go along. If you're looking for a professional maker page this is not it, but I'm learning, growing, and building fun stuff. Stick around and together we can have some fun and maybe learn something in the process.

My tools of choice are microcontrollers, my preferred language is C++ (Arduino flavour), and my preferred debugging method is staring at something until it confesses. I run Arch Linux, work from a home garage, and have a wife and son who remain admirably tolerant of the whole operation.

How I approach a build

Making things is easy. Making things that actually work, that you understand, that you can fix when they break. That's the interesting part. A few principles I keep coming back to:

• 01 Break it into steps small enough to test The fastest way to build something complicated is to never build anything complicated. Get the LED blinking before you wire the motor driver. Flash a known-good sketch before you trust the hardware.
• 02 Know your hardware Datasheets exist for a reason. A pinout diagram is worth three hours of debugging. If you're guessing at I2C addresses, you've already gone wrong.
• 03 Salvage is not a compromise Some of the best parts come from e-waste. Laptop screens, motors from old appliances, heatsinks from dead PSUs. The question is always what it can become, not what it was.
• 04 Proprietary protocols are just puzzles Anything with an undocumented protocol is an invitation, not a wall. Logic analysers, a bit of patience, and the willingness to read someone else's reverse engineering work. Most things give up their secrets eventually.
• 05 Document what you build Future you will not remember why you chose those pins. Future someone else might need exactly this. Write it down. Draw the wiring. Explain the why, not just the what. This site is as much about sharing that record as it is about keeping it. If something I figured out saves someone else the same three hours, that's the point.

How I use AI

I use AI as a coding and technical collaborator, not as an oracle and not as a shortcut. The distinction matters. But I'll be straight about it: AI has me punching well above my class. Projects that would have taken me months to figure out, or that I simply wouldn't have attempted, are now within reach.

The workflow is deliberate: break a project into small, testable steps, then work through them one at a time with AI as a pair-programming partner. I bring the hardware knowledge, the physical intuition, and the ability to catch when something is technically plausible but electrically wrong. The AI brings speed, breadth, and the ability to draft code I can then read and try to understand.

The best way I can describe AI is an extraordinarily well-read assistant who has never actually touched anything, because it's got no hands. The knowledge is genuine and vast, but so is the confidence, and the two don't always match. The thing nobody tells you is that AI is most useful when you already know enough to recognise when it's wrong, and you mostly learn that by having it go wrong on you. A hallucinated pin number you didn't catch, a library that doesn't exist, a timing assumption that falls apart on real hardware. You find out the hard way, and next time you know to check. If you haven't been through enough of those cycles yet, it just won't work and you'll be chasing your tail for months.

So the guides here are genuinely mine. The AI helped write code and draft documentation. I built the circuit, ran the sketch, debugged what didn't work, and corrected what was wrong. Nothing gets published because the AI said it was right. It gets published because I tested it and it worked. At the end of the day AI is just another tool in the build, the same as the IDE or the oscilloscope.

• ✦ AI as collaborator, not author I direct the work. The AI drafts. I review, correct, test, and own the result.
• ✦ Hardware knowledge is the sanity check Enough time building real circuits means you develop a feel for when something is off, before you wire it up. That instinct is what AI can't replicate, and it's what makes the collaboration actually work.
• ✦ Confirmed working means confirmed working Every guide on this site has been built on real hardware, run, and verified. The badge means something.

Find the tech-ologist

If you've found something here useful, spotted an error, or you're working on something weird and want to compare notes, get in touch. Instagram is the best place to catch me.