An Open Source Tool To Document Your Wiring

Most of us are familiar with the tools available to create circuit diagrams, as generally that’s the first step towards producing a custom PCB. But that about the cables and wiring harnesses that don’t live on your board? How do you easily document the rat’s nest perfectly logical wiring of your latest and greatest creation?

That’s precisely the question that led [Daniel Rojas] to create WireViz. This open source Python tool takes human readable input files and turns them into attractive and functional visualizations of where all the wires in your project are going. It can even be used to generate a Bill of Materials that documents the lengths of wire required and types of connectors needed to hook everything up.

If you’re still using pre-made cables to connect all of your components together, than you might not immediately see the benefit of a tool like this. But as we’ve talked about in the past, the creation of custom wiring harnesses is something that serious hardware hackers should become familiar with. Yes it takes more effort, but the end result is worth it. With a tool like WireViz, the creation of a bespoke harness for your next project just got a little bit easier.

[Daniel] has done a fantastic job documenting this project, providing not only a tutorial on how to feed and care for your WireViz, but a gallery of examples that shows off the kind of complex wiring the tool can help make sense of. But there’s plenty more to be done, and he’s happy to get feedback or code contributions from anyone who wants to get involved.

Beautiful Sourdough Bread At Home Thanks To Dynamic Recipe Parameterization

More people are making sourdough at home than ever before, and while it may not take a lot of effort to find a decent recipe, it’s quite another thing to try using recipes to figure out how and why bread actually works. Thankfully, [Makefast Workshop] has turned copious research and hundreds of trials into a dynamic sourdough (and semi-sourdough) bread recipe chock-full of of drop-down options to customize not just ingredients, but baking methods and other recipe elements as well. Want to adjust quantities or loaf styles? Play with hydration or flour type? It’s all right there, and they even have quick-set options for their personal favorites.

In order to do all this, [Makefast Workshop] needed to understand bread at a deeper level than is usually called for. During research, they observed that the format of recipes was often an obstacle to understanding how good bread actually gets made. The reason for this is simple: recipes are presented as standalone documents describing a fixed process; a set of specific steps that, when followed, yield a particular result. What they do not normally do is describe the interplay and balance between ingredients and processes, which makes it difficult to understand how and why exactly the recipe produces what it does. Without that knowledge, it’s impossible to know what elements can be adjusted, and how. The dynamic recipe changes all that.

[Makefast Workshop] performed hundreds of tests, dialing in parameters one by one, to gain the insights needed to populate their dynamic recipe. It’s got clear processes and drop-down options that dynamically update not just the recipe steps, but also the URL. This means that one can fiddle the recipe to one’s desire, then simply copy and paste the URL to keep track of what one has baked.

When it comes to thoughtful approaches to food, this certainly isn’t [Makefast Workshop]’s first rodeo. We covered their beautiful directions for creating delicious speculoos, complete with effective 3D printed molds for a modern twist on a Belgian classic.

It Ain’t Over ‘Til The Paperwork Is Done: Test Driving TiddlyWiki

Working on projects is fun. Documenting them is often not so much. However, if you want anyone to duplicate your work — or even just want to remember what you were doing a few years ago when something needs upgrading or repairing.

There’s a ton of ways to keep track of the details of your projects. We love seeing how things come together and of course we’re happy to suggest documenting on But sometimes, you just want to keep your own notes to yourself. There’s always a notebook, of course, but that seems kind of old fashioned. A lot of projects are on Wikis but you hate to stand up a web server and a Wiki instance just to keep notes. But what if you could have a local Wiki with minimal setup?

I recently came across TiddlyWiki and decided to take it for a spin. Join me after to break to see what it’s all about.

Continue reading “It Ain’t Over ‘Til The Paperwork Is Done: Test Driving TiddlyWiki”

“Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself

Code documentation — is there anything more exciting than spending your time writing extensive comments? If I had to guess, your answer is probably somewhere along the lines of “uhm, yes, everything is more exciting than that”. Plus, requesting to document your code is almost like an insult to your well thought out design, this beautiful creation you implemented so carefully that it just has to be obvious what is happening. Writing about it is just redundant, the code is all you need.

As a result, no matter if it’s some open source side project or professional software development, code documentation usually comes in two flavors: absent and useless. The dislike for documenting ones code seems universal among programmers of any field or language, no matter where in the world they are. And it’s understandable, after all, you’re in it for the coding, implementing all the fun stuff. If you wanted to tell stories, you would have chosen a different path in life.

This reluctance has even formed whole new paradigms and philosophies claiming how comments are actually harmful, and anyone trying to weasel their way out of it can now happily rehash all those claims. But, to exaggerate a bit, we’re essentially villainizing information this way. While it is true that comments can be counterproductive, it’s more the fundamental attitude towards them that causes the harm here.

In the end, code documentation is a lot like error handling, we are told early on how it’s important and necessary, but we fail to understand why and instead grow to resent doing it again for that same old teacher, supervisor, or annoying teammate. But just like error handling, we are the ones who can actually benefit the most from it — if done right. But in order to do it right, we need to face some harsh truths and start admitting that there is no such thing as self-documenting code, and maybe we simply don’t understand what we’re actually doing if we can’t manage to write a few words about it.

So let’s burst some bubbles!

Continue reading ““Good Code Documents Itself” And Other Hilarious Jokes You Shouldn’t Tell Yourself”

Easy Time-lapse Video Via Phone And Command Line

A good time-lapse video can be useful visual documentation, and since [Tommy]’s phone is the best camera he owns he created two simple shell scripts to grab time-lapse images and assemble them into a video. [Tommy]’s work is just the glue between two other things: an app that turns the phone into an IP camera with a web server on the local network, and the ability to grab a still image from that server on demand.

The app he uses for his iPhone normally serves video but has an undocumented feature that allows single frames to be downloaded by adding ‘/photo’ to the end of the URL, but the ability to get a still image is a common feature on IP camera apps for smartphones. His capture script (GitHub repository here) should therefore need only minor changes to work with just about any IP camera app.

Perching a phone over a workspace and using it to create a time-lapse with a couple of shell scripts is a great example of combining simple tools to get better functionality. It could be a good way to get additional use out of an older smartphone, too. Heck, even older dumbphones can still get some use out of them; Shmoocon 2017 brought us details on rolling your own 1G network.

Winch Bot Records Hacks And Cats

Some people are better than others when it comes to documenting their hacks. Some people, like [Micah Elizabeth Scott], aka [scanlime], set the gold standard with their recordings. Hacking sessions with the Winch Bot have been streamed regularly throughout the build and this is going to lead to a stacking effect in her next projects because the Winch Bot was designed to record hacking sessions. Hacking video inception anyone? Her Winch Bot summary video is after the break.

The first part of this build, which she calls the Tuco Flyer, was [Micah Elizabeth Scott]’s camera gimbal hack which we already covered and is a wonderful learning experience in itself. She refers to the gimbal portion as the “flyer” since it can move around. The Winch Bot contains the stationary parts of the Tuco Flyer and control where the camera will be in the room.

Continue reading “Winch Bot Records Hacks And Cats”

Hackaday Prize Entry: FabDoc Is Version Control For Project Images

FabDoc is an interesting concept that attempts to tackle a problem many of us didn’t realize we had. There are plenty of version control systems for software, but many projects also have a hardware element or assembly process. Those physical elements need to be documented, but that process does not easily fit the tools that make software development and collaboration easier. [Kevin Cheng] sums FabDoc up as “a system to capture time-lapse pictures as pre-commits.”

With FabDoc a camera automatically records the physical development process, allowing the developer to focus on work and review later. The images from the camera are treated as pre-commits. Upon review, the developer selects relevant key images (ignoring dead ends or false starts) and commits them. It’s a version control and commit system for the physical part of the development process. The goal is to remove the burden of stopping the work process in order to take pictures, automatically record the development process and attach it to a specific project, and allow easy management of which images to commit.

The current system uses a Raspberry Pi Zero with a camera mounted on safety glasses, and some support software. Some thought has certainly gone into making the system as easy to use and manage as possible; after setting up a repository, scanning a QR code takes care of telling the system what to do and where to put it. The goal is to make FabDoc fast and easy to use so that it can simply work unattended.

We saw a visual twist on version control some time ago with a visual diff for PCBs, which was a great idea to represent changes between PCB designs visually, diff-style. It’s always exciting to see someone take a shot at improving processes that are easy to take for granted.