The original system allowed for exposure times from 1-99 minutes to be programmed in 1-minute increments. [Heliosoph] though it would be perfect as-is, but the lamp is so powerful that even one minute of exposure was too much. He hoped to find TTL when he opened the thing and was pleasantly surprised to discover a COP410L microcontroller and an MM5484 display driver. Unfortunately, the COP410L’s clock range is too small and he didn’t want to overclock it.

[Heliosoph] built a new board based on the ATMega328P with a salvaged 16×2 LCD, which he was able to easily integrate using the library that ships with the Arduino IDE. He then replaced the BT136 triac lamp switch with a solid state relay, conveniently isolating the electronics from mains power. He re-purposed the unit’s push buttons using the M2tklib, which supports a plethora of common menu functions.

Our guide on this tool hack is [BongoDrummer], who is the co-founder of a group in Wales called the Flowering Elbow, dedicated to imagining and making better futures by helping inspire people with inventions, encouraging project collaborations, and contributing to the community. We think he’s just a wee bit more knowledgeable than our previous grinder-chainsaw inventor…

[BongoDrummer] starts out with a proper note on safety, explaining accident statistics and offering up a refresher guide on proper chainsaw use. From there he gets right into the design and build of the mill. He’s chosen to use aluminum extrusion because it’s strong, light, and easy to work with—not to mention easy to assemble! Videos and more info after the jump.

The title says it all. We need more writers to keep the fresh hacks coming, now’s your chance to apply for the job.

Contributors are hired as private contractors and paid for each post. Writers should have the technical expertise to understand the projects they are writing about, and a passion for the wide range of topics we feature. If you’re interested, please email our jobs line and include:

Details about your background (education, employment, etc.) that make you a valuable addition to the team

Links to your blog/project posts/etc. which have been published on the Internet

One example post written in the voice of Hack a Day. Include a banner image, 150 words, the link to the project, and any in-links to related and relevant Hack a Day features.

Words of encouragement

First off, we won’t be discussing compensation publicly. Want to know what we pay? Send in a successful application and we’ll talk about it.

Secondly, don’t pass up this opportunity. I watched one of these posts go by and waited another year before I saw the next one and applied. Now I’m running the place. Our team is made up of avid readers. If you’re passionate about the stuff here and you have a few hours each week to do some writing you need to apply now!

Why are we hiring more writers?

You may have noticed that we’re starting to send people to events, and continuing our push to develop our own unique original content. Both of these take time and we need more team members to fill in the publishing schedule so that the Hackaday community gets the posts that it deserves.

So what are you waiting for? Ladies and Gentlemen, start your applications!

[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.

This Fail of the Week project comes from one of Hackaday’s own. [Ben] took on the FLED data visualization project as a way to make the SupplyFrame decor a lot more fun. He had quite a bit of help soldering the 96 WS2811 pixels into their custom made 6’x4′ enclosure and the results are really awesome. In addition to showing server load and playing games, FLED has become something of a job interview. Sit the prospective employee down at a terminal and give them an hour to code the most interesting visualization they are capable of.

But two weeks ago [Ben] staggered into the office and found the display was dead. Did he try turning it off and back on again? Yes, but to no avail. The power supply wasn’t the issue and there was no option but to pull the display off the wall and crack it open for a look at all those pixels. Since every one of them had 4 solder joints on either side he figured the problem was with a broken connection. But not so. He resorted to a binary search for the offending pixel by cutting the strand in half, and testing each portion. He tracked it down to the pixel whose underside was blackened as you can see above.

[Ben] thinks one of the capacitors inside the sealed enclosure blew, but isn’t certain. Feel free to tell us what you think failed in this component. But the thing we’d really like to know is if there is a more clever way to sniff out the offensive pixel without cutting the connections? Four hours on the floor with this thing (and no knee-pads) and [Ben] has sworn off sourcing pixels from random Chinese suppliers. He might go with pre-assembled strings next time. We chuckle; this is the high-tech equivalent of trying to get old strands of Christmas lights to work.

If you haven’t seen FLED in action, check it out after the break. It amazing how LED intensity and quality diffuser material can make a perfect grid of LEDs seem to dance in waves and color curves.

TI’s LaunchPad boards have a history of being both low cost and fully featured. There’s a board for each of TI’s major processor lines, and all of them support the same “BoosterPack” interface for additional functionality. Today, TI has announced a new LaunchPad based on their new Tiva C ARM processors, which is designed for connectivity.

The Tiva C Series Connected LaunchPad is based on the TM4C129x processor family. These provide an ethernet MAC and PHY on chip, so the only external parts required are magnetics and a jack. This makes the Connected LaunchPad an easy way to hop onto ethernet and build designs that require internet connections.

This development board is focused on the “Internet of Things,” which it seems like every silicon manufacturer is focusing on nowadays. However, the real news here is a low cost board with tons of connectivity, including ethernet, two CANs, 8 UARTs, 10 I2Cs, and 4 QSPIs. This is enough IO to allow for two BoosterPack connectors that are fully independent.

For the launch, TI has partnered with Exosite to provide easy access to the LaunchPad from the internet. A pre-loaded demo application will allow you to toggle LEDs, read button states, and measure temperature over the internet using Exosite. Unlike some past LaunchPads, this one is designed for easy breadboarding, with all MCU pins broken out to a breadboard compatible header.

Finally, the price is very right. The board will be release at $19.99 USD. This is less than half the price of other ethernet-ready development boards out there. This makes it an attractive solution for hackers who want to put a device on a wired network, or need a gateway between various devices and a network.

No, that’s not a Playstation Vita up there, it’s a “Yinlips YDPG18A” portable game system. [Ian] found that his Yinlips was lacking in the flash memory department, so he fired up his soldering iron. The Yinlips is based on an Allwinner Sunxi series processor, and uses a standard TSOP48 footprint flash. There is some standardization in flash pin out and packages, so [Ian] picked up the largest pin compatible chips he could find – a pair of 256 gigabit (32 gigabyte) chips from Micron. Desoldering the existing flash proved to be a bit of an adventure as the flash was glued down. [Ian] also didn’t have his hot air gun handy, making things even more interesting. Careful work with a razor blade broke the glue bond.

It turns out that the soldering was the easy part. All flash chips have geometry, die count, page size, block count, sector size, etc. The geometry is similar to the geometry in a hard drive. In fact, just like in modern hard drives, a system will read some basic information before accessing the full storage array. In the case of NAND flash, the processor can access the first page of memory, and query the flash for its part number. Once the part number is known, the geometry can be determined via a lookup table. [Ian] checked the NAND table on github, so he knew going in that his flash chips were not supported. Due to the complexities of booting Allwinner processors into Linux or Android, the table and the NAND driver that uses it exist in several places. The bootloader’s axf file, U-Boot, and several flash application binaries sent from the PC based LiveSuit flash app all required modification. Most of these files were packed into a single flash image. [Ian] used imgrepacker to unpack the image, then opened the hex files. The fact that he knew what the original flash parameter tables looked like was key. He searched for an existing Micron flash table entry, and replaced the parameters with those of his new chips.

With all the files modified, [Ian] re-packed his flash image and sent it over. The Yinlips rewarded his hard work by continually resetting in a bootloop. [Ian] wasn’t going to give up though. He wired into the boot console, and discovered that a CRC check failure on one of his modified files was causing the reset. He then disassembled binary issuing the reset. Changing the return value of the CRC to always pass fixed the issue. [Ian’s] now has a collagen infused Yinlips with 58GB of internal storage. Pretty good for a device that only started with 2GB.