Show me the Data: Year #02 has just turned two today and we couldn’t be more excited about how far we’ve come. What started out as a simple proof-of-concept, inspired by ye-olde idea of a “virtual hackerspace,” has truly evolved into a global playground for some of the best, brightest, and most creative minds you have ever met. It also became a home and the place to spend sleepless nights for many of us on the team, and we’re excited to share a few ideas on where we are headed going forward.

But before we do that, let’s look at some data.

The Data

We’re thrilled to report that over the last two years, has grown from zero to a 121,158-member strong community, who have together created a total of 9,736 projects. To put this in context, it is more than a two-fold growth from last year’s milestone of 51,838 users / 4,365 projects. And it doesn’t seem to be showing any signs of slowing down.



Though these “vanity” metrics sure are a nice validation, the number that gets us the most excited is the fact that the 9,731 projects currently on the site have been created by a total 4,966 different users. What’s even better is the fact that 949 projects are a result of collaboration between two or more people. Altogether, a total of 7,170 different users have participated in the creation of the vast body of engineering knowledge currently residing on

Continue reading “Show me the Data: Year #02”

Logging Engine Temperature For RC Models

[Rui] enjoys his remote-controlled helicopter hobby and he was looking for a way to better track the temperature of the helicopter’s engine. According to [Rui], engine temperature can affect the performance of the craft, as well as the longevity and durability of the engine. He ended up building his own temperature logger from scratch.

The data logger runs from a PIC 16F88 microcontroller mounted to a circuit board. The PIC reads temperature data from a LM35 temperature sensor. This device can detect temperatures up to 140 degrees Celsius. The temperature sensor is mounted to the engine using Arctic Alumina Silver paste. The paste acts as a glue, holding the sensor in place. The circuit also contains a Microchip 24LC512 EEPROM separated into four blocks. This allows [Rui] to easily make four separate data recordings. His data logger can record up to 15 minutes of data per memory block at two samples per second.

Three buttons on the circuit allow for control over the memory. One button selects which of the four memory banks are being accessed. A second button changes modes between reading, writing, and erasing. The third button actually starts or stops the reading or writing action. The board contains an RS232 port to read the data onto a computer. The circuit is powered via two AA batteries. Combined, these batteries don’t put out the full 5V required for the circuit. [Rui] included a DC-DC converter in order to boost the voltage up high enough.

Manual Data Recovery With A Hex Editor

Let’s say you use an SD card-base portable audio recorder for work – doing an interview, perhaps. Things go well until one day, you turn the recorder off before stopping the recording. Without pressing that big red Stop button, the file doesn’t close, and you’re left with a very large 0kB file on the SD card. How do you get it back?  There are tools that will do it for you, but they cost money. You can do it yourself with a hex editor, though, and it’s actually pretty easy.

The software required for this feat of data recovery is Roadkil’s Disk Imager to dump all the bits on the SD card to an image file, the free version of ISO Buster to show the block addresses and length of each file, and the hex editor of your choice. The process starts as simply an experiment for hot to create an MP3 file by cutting and pasting bits into a hex editor. A good file was found in the hex editor, copied to a new file, and played. Everything works so far; great.

For the actual data recovery, a spreadsheet was created to make an educated guess as to where the lost file should be. Starting at this address, about 90MB of data was copied into a new hex editor window. This is where the recovery hit a snag. Because the SD card was plugged into a Mac before, a bunch of data was written on the card. This went into the first available place on the disk, which just happened to be the header of the lost MP3 file.

That’s not a problem; there’s already the header from an MP3 file sitting in a hex editor from the first experiment to see if this was possible. By copying a few hundred bytes to the front of the lost file, the file was corrected just enough that an MP3 player could reconstruct the file.

It’s not perfect – the first fifty seconds of the interview was garbled. The rest of the interview was saved, though, and that’s much better than losing the entire thing. Thanks [Lewin] for sending this one in.

Continue reading “Manual Data Recovery With A Hex Editor”

Show me the Data: Year #01

Today marks exactly one year since we announced to the world the first product from our software lab – In what has been an incredibly exciting year for all of us, we evolved from a simple idea and a prototype to a truly massive community that’s making its mark on the world. Day after day, carefully listening to the invaluable feedback from our users, we have improved and moved forward, one line of code at the time.

We still have a long way to go, but we’ll pause for a second now and reflect on how far we’ve come. Then get right back to fixing bugs and developing new features.

It all started with a simple idea – building a better project hosting website. Though there are project and content websites galore out there, with new ones popping up every day, it all still felt too bland. We thought we could do better. After all, the medium is the message. The place where something lives sooner or later becomes a key part of its identity. So in order to prevent a dystopian future in which we’re all hosting our projects using the (fictional) Microsoft Maker Suite 2020 and simply don’t care, we started to work on providing an alternative.

We quickly realized that we had a much bigger mission on our hands. Sure, a better project hosting website would be nice, but what we felt we really needed was something [Brian Benchoff] has been talking about for quite some time – a “virtual hackerspace.” Not just a place where you can post your builds once you’re done (and hope someone sees it), but a living, breathing community: a place where you can start with an idea and get feedback as it develops, find collaborators, iterate, and ultimately end up building something way more amazing than you would have accomplished on your own.

This has been the aim of Hackaday for many years, but most of the collaboration was constrained to the limited space of post comment threads and biased by the editorial choice of articles and topics. With the introduction of, we open up a space for anyone to unleash their creativity and expertise, and together, change the way people build things.

The Data

Unfortunately, making bold claims about how we’re out there changing the world is pretty much a commodity these days. As most Web startups can testify, it doesn’t take more than a simple landing page with nice photography and some uplifting message for any arbitrary claims to appear credible.

So instead of trying to convince you with words about how awesome the last year had been, we’ll just stick with the data.

Continue reading “Show me the Data: Year #01”

Transferring Audio to an AVR at 12kbps

Back in the bad ‘ol days of computing, hard drives cost as much as a car, and floppy drives were incredibly expensive. The solution to this data storage problem offered by all the manufacturers was simple – an audio cassette. It’s an elegant solution to a storage problem, and something that has applications today.

[Jari] was working on a wearable message badge with an 8-pin ATTiny. To get data onto this device, he looked at his options and couldn’t find anything good; USB needs two pins and the firmware takes up 1/4 of the Flash, UART isn’t available on every computer, and Bluetooth and WiFi are expensive and complicated. This left using audio to send digital data as the simplest solution.

[Jari] went through a ton of Wikipedia articles to figure out the best modulation scheme for transferring data with audio. What he came up with is very simple: just a square wave that’s changed by turning a pin off and on. When the audio is three samples long without crossing zero, the data is 0. When it’s five samples long without crossing zero, the data is 1. There’s a 17-sample long sync pulse, and with a small circuit that acts as a zero crossing detector, [Jari] had a simple circuit that would transfer data easily and cheaply.

All the code for this extremely cheap modem is available on GitHub.

Paper ROM

This low-resolution memory device packs in just a few bytes of data. But it’s enough to spell out [Michael Kohn’s] name. He’s been experimenting with using paper discs for data storage.

His technique becomes immediately clear when you view the demo video below. The disc spins multiple times with the sensor arm reading one track. This gives the system the chance to measure the black band in order to get the data timing figured out. Once the outer track has been read the servo controlling the read head swings it to the next until all of the data is captured.

An Arduino is monitoring the QTR-1RC reflectance sensor which makes up the reading head. It uses the black band width in order to establish the size of an individual byte. Interestingly enough, the white parts of the disc do not contain data. Digital 0 is a black area 1/4 the width of the large black strip, and digital 1 is half as wide.

[Michael’s] set up the generator which makes the discs so that he can easily increase the resolution. The limiting factor is what the reading hardware is able to detect.

Continue reading “Paper ROM”

Receiving asynchronous data bursts

[Johan’s] been working on a chunk of code for about seven years and he thinks it’s ready to help you with your next project. He calls it D1 (The One) and it lets you receive asynchronous data without the need for a hardware USART. It’s capable of working with signals from an IR or RF remote, as well as tangentially related transmissions like RFID and magstripe readers.

It uses timer and port interrupts to sample the incoming data. Once it’s captured a transmission, the code sets a flag so that you can pull what it got into your own application. If you’re expecting to receive a protocol that sends packets several times in a row a verification module is also included which runs as a precondition of setting the received flag. The package is written in PIC assembly, but with all the information that [Johan] included in his post this shouldn’t be hard to port over to other chip architecture.