Cordwood Puzzle Kit Without Instructions

March 14, 2014 by Brian Benchoff 24 Comments

What you see above is a cordwood circuit, an interesting circuit construction technique from before the days of integrated circuits. The circuit consists of two circuit boards arranged parallel to each other with components holding them apart. This was, for its day, the densest circuit construction technique, used in everything from late 50s aerospace tech to huge computers that filled rooms.

The folks over at Boldport have a love for interesting PCBs and are apparently aficionados of antiquated tech, leading them to create their own cordwood circuit. Here’s the best part: it’s a kit, without assembly instructions.

The cordwood puzzle assembles into a bunch of LEDs that will light up when power is applied. Not much, but there’s a few FETs in there that allow you to control them all individually with a microcontroller. The real fun is trying to assemble the kit: both sides of the cordwood circuit are identical, meaning there’s going to be holes that aren’t meant to be filled, components that will need to be soldered, and most likely a bit of swearing.

Still, this is an exceptionally small circuit for something using this construction technique. If you know of a denser and more modern cordwood circuit out there, leave a note in the comments. If you want to know what the kit looks like when it’s built, [Phil Wright] has your back.

Developed On Hackaday: Coding Conventions And GitHub Pull Requests

March 12, 2014 by Mathieu Stephan 100 Comments

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

main(void)

{

if (foo)

{

functionCall();

}

else

{

foo = 0;

anotherFunctionCall();

}

}

– 79 characters line length as a soft requirement

– 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.

I Can Fix The Space Station With A Metronome, A Metronome, A Metronome

March 7, 2014 by Brian Benchoff 42 Comments

ISS

If the space station were left to its own devices, the living quarters would get incredibly hot. There are computers, hardware, and six crew members, all generating heat that must be gotten rid of. To do this, there are two heat exchangers inside the station that take warm water, dump that heat to ammonia, and send that ammonia out to panels outside the station. On December 11, 2013, Loop A of the thermal control system shut down, putting the station one failure away from evacuation. Plans for a spacewalk were tabled, but the ground crew managed to fix this hardware failure by telling the astronauts to push buttons, a metronome, and a software patch.

The problem with Loop A of the Internal Thermal Control System was a flow control valve that regulated the amount of ammonia flowing through the heat exchange. Too much ammonia, and the station would be far too cold. Too little, and it would be too hot. This valve is electronically controlled and takes exactly 13 seconds to move from open to closed. The first attempt at fixing the problem was having ground crew send the command to open the valve and cut the power halfway through. This involved using a metronome app on a phone to send two commands 6.5 seconds apart. It worked, but not quite well enough.

The failure of the metronome technique led [Todd Quasny] to write a script to turn the ‘on’ and ‘off’ commands from the ground to the ISS with millisecond resolution. This meant the commands to control the valve could be sent with the right delay, but they weren’t received with the right delay. This is a problem that had to be fixed from the station’s computers.

To finally solve the problem, ISS software engineer [Steve Joiner] was called in to write a software patch for the thermal control system. This is spaceflight and writing software is a long a laborious process of testing and code reviews. Nevertheless, the team managed to write and upload a patch in just two days.

This patch gave controllers the ability to control the valve with a resolution of 100 milliseconds, good enough for very fine control of the thermal system, and all without requiring the massive amount of planning that goes into a spacewalk or resupply mission.

Ups to [Ed Van Cise] for this tip. If you’re curious about the headline….

The Mystery Of Zombie RAM

March 6, 2014 by Brian Benchoff 61 Comments

[Josh] had a little project where he needed to keep a variable in RAM while a microcontroller was disconnected from a power source. Yes, the EEPROM on board would be able to store a variable without power, but that means writing to the EEPROM a lot, killing the lifetime of the chip. He found an ATTiny can keep the RAM alive for a variable amount of time – somewhere between 150ms and 10 minutes. Wanting to understand this variability, he decided to solve the mystery of the zombie RAM.

The first experiment involved writing a little bit of code for an ATTiny4313 that looked for a value in RAM on power up and light up a LED if it saw the right value. The test circuit consisted of a simple switch connected to the power pin. Initial tests were astonishing; the ATTiny could hold a value in RAM for up to 10 minutes without power.

With the experiment a success, [Josh] updated his project to use this new EEPROM-saving technique. Only this time, it didn’t work. The value hidden away in RAM would die in a matter of milliseconds, not minutes. After tearing his hair out looking for something different, [Josh] rigged up an Arduino based test circuit with humidity and temperature sensors to see if that had any effect. It didn’t, and the zombie RAM was still not-undead.

The key insight into how the RAM in an ATtiny could stay alive for so long came when [Josh] noticed his test circuit had a LED, but the actual project didn’t. Apparently this LED was functioning as a very tiny solar cell, generating a tiny bit of current that kept the RAM alive. A dark room with a flashlight confirmed this hypothesis, and once [Josh] gets his uCurrent from Kickstarter he’ll know exactly how much current this LED is supplying.

Turning A Tiny CRT Into A Monitor

March 1, 2014 by Brian Benchoff 18 Comments

[GK] picked up a few tiny 2″ CRTs a while back and for the longest time they’ve been sitting in a box somewhere in the lab. The itch to build something with these old tubes has finally been scratched, with a beautiful circuit with Manhattan style construction.

[GK] has a bit of a fetish for old oscilloscopes, and since he’s using an old ‘scope tube, the design was rather simple for him; there aren’t any schematics here, just what he could put together off the top of his head.

Still, some of [GK]’s earlier projects helped him along the way in turning this CRT into a monitor. The high voltage came from a variable output PSU he had originally designed for photomultiplier tubes. Since this is a monochrome display, the chrominance was discarded with an old Sony Y/C module found in a part drawer.

It’s a great piece of work that, in the words of someone we highly respect is, “worth more than a gazillion lame Hackaday posts where someone connected an Arduino to something, or left a breadboard in a supposedly “finished” project.” Love ya, [Mike].

The Credit Card Sized GameBoy

March 1, 2014 by Brian Benchoff 60 Comments

Think you’ve seen every possible type of Arduino based hand held video game? [Kevin] managed to coax something new out of the theme with a very clever credit card sized console that uses some very interesting construction techniques.

The inspiration for this project began when [Kevin] dropped an SMD resistor into a drill hole on a PCB. This resistor fell right through the hole, giving him the idea creating a PCB with milled cutouts made to fit SMD components. With a little experimentation, [Kevin] found he could fit a TQFP32 ATMega328p – the same microcontroller in the Arduino – in a custom square cutout. The rest of the components including a CR2016 battery and OLED display use the same trick.

The rest of the design involved taking Adafruit and Sparkfun breakout boards, and modifying the individual circuits until something broke. Then, off to Eagle to create a PCB.

[Kevin]’s experiment in extremely unusual PCB design worked, resulting in a credit-card sized “Game Boy” that’s only 1.6 millimeters thick. The controls are capacitive touch sensors and he already has an easter egg hidden in the code; enter the Konami code and the Hackaday logo pops up to the tune of [Rick Astley]’s magnum opus.

Now [Kevin] is in a bit of a bind. He’d like to take this prototype and turn it into a crowd sourced campaign. In our opinion, this “Game Boy in a wallet” would probably do well on a site like Tindie, but any sort of large scale manufacturing is going to be a rather large pain. If you have any wishes, advice, of complaints for [Kevin] he’s got a few links at the bottom of his project page.

Breadboardable WS2812 LEDs

February 22, 2014 by Brian Benchoff 21 Comments

LED

Hackaday sees a ton of projects featuring the WS2812 series of digitally controllable RGB LEDs, in the form of bare chips, RGB LED strips, or some form of Adafruit’s NeoPixels. All these WS2812 LED products have one thing in common – they’re chip LEDs, making some projects difficult to realize. Now there’s a new member of the WS2812 family – a through-hole LED version – that should be available through the usual sources sometime later this year.

The key difference between these and the usual WS2812 LEDs is the packaging; these are 8mm LEDs with pins for power, ground, data in, and data out. With the preexisting libraries, this 8mm LED should work just the same as any other WS2812 LED.

Aside from a through-hole package, these new LEDs are very diffuse and aren’t as blinding as the normal chip LEDs. If you want to pick up a few of these LEDs, they’re available here, 13 LEDs for $15. There’s a lot of potential here for RGB LED cubes, something we hope to see sooner rather than later.