Keeping the LiPo Smoke Where It Belongs

Nothing brings joy to a hacker’s heart like taking a cheap gizmo and making it useful. Over at [AndyHull] popped open some cheap LiPo battery power packs to see if he could power a Canon Powershot camera. The entire shebang would be left in the wilderness for photography so keeping it inexpensive was a big goal since it might be destroyed or lost.

The power packs [Andy] looked at have a TP4221 controlling the charge cycle for up to four 18650 LiPo cells connected in parallel. The controller also boosts the voltage to 5 volts for one or two USB ports while providing automatic shutdown if the LiPo cell voltage drops below 3.2v. Below that voltage the cells can be damaged and might possibly cause a fire.

The packs [Andy] used also had a torch output to drive an LED almost directly from the cells. That output is a nominally 3.8 V at 100 mA which is just what he needed to power the Canon Powershot. It could be used to power small micros or other low power devices.

The LED was removed and replaced by a connection to outside the pack. The torch output is triggered by two quick presses on a switch that was also replaced with a connector to allow remote control.

If you’re looking for powerful battery options, give LiPo a try and have a look at [Andy]’s LiPo battery safety issues post, also on For a broader LiPo overview, see this obsessive rundown of various batteries.





Winning the Console Wars – An In-Depth Architectural Study

From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.

The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.

In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.

Continue reading “Winning the Console Wars – An In-Depth Architectural Study”

Fail of the Week: OpenMV Kickstarter Project Hits Manufacturing Snag

Making stuff is hard, especially when you are making lots of stuff. The OpenMV Cam project knows this, because it has hit a problem while putting together their cheap machine vision module. The problem is with the BGA solder balls that connect the image sensor to the main board.

openmv-thumbWe’ve covered this intriguing project before: the aim is to build a small, cheap module that can run image processing algorithms to easily give robots sight. The sensor is a Ball Grid Array (BGA) package, which means there are a grid of small solder balls on the back that form the electrical connections. It seems that some of these solder balls are oxidized, preventing them from melting and fusing properly with the board. This is called a head-in-pillow defect, because the ball behaves like your head when you lie down in bed. Your head squishes the pillow, but doesn’t merge into it. There are 38 balls on the OV26040 image sensor and even a single bad link means a failure.

The makers of the project have tried a number of solutions, but it seems that they may have to remake the ball links on the back of each sensor. That’s an expensive process: they say it will cost $7 for each, more than the actual sensor cost initially.

A few people have been posting suggestions in the comments for the project, including using solvents and changing the way the sensors are processed before mounting. We’d like to see them overcome this hurdle. Anybody have any suggestions to quickly and cost effectively move the manufacturing process forward?

Continue reading “Fail of the Week: OpenMV Kickstarter Project Hits Manufacturing Snag”

Developed on Hackaday – HaDge is back to the drawing board

A couple of days back, we wrote about the HACK – a prototyping platform designed by [Michele Perla] based on the Atmel SAM R21 MCU. It’s one of the new breed of devices consisting of an ARM Cortex-M0 MCU + IEEE 802.15.4 Wireless radio bundled together. This was exciting since we could pack a lot of punch in the HaDge hardware. We planned to use the same design later to power the HaDge. Building HACK would have allowed us to get it in the hands of the software team, while the hardware folks worked on the real HaDge layout.

The HACK design was ready for review and we asked around to verify the antenna layout, which was the part we were not too sure about.  We asked Atmel for help with verifying the layout. That’s when we had the facepalm moment. They asked us – “What about FCC certification?” Since we plan to build the badges in quantities of a few hundred at the very least, it’s obvious we cannot escape from FCC certification. A design based around the R21 is ruled out – the cost of obtaining approval is pretty high. This means we need to punt the R21 and instead use an off-the-shelf radio module which is already FCC certified. Sigh.

Now the good news. This is a setback in terms of time, and effort put in by [Michele]. But beyond that, we’re good to go back to the drawing board and start afresh. First off, we decided to revert back to the Atmel D21 as the main controller. It’s a fairly decent MCU, and there’s a fairly robust tool chain available that a lot of people are familiar with. For the Radio, we are looking at some of these available options :

The last one from Microchip looks quite promising. But we’re open for better and cheaper suggestions, so please chime in with your comments.

Superbike gets Bootstrapped Instrument Refit

[Josh] got rid of the standard, factory gauges on his GSXR Super-bike and installed a custom built instrument panel which displays some additional parameters which the regular instrumentation cluster did not. He was working on converting his bike in to a Streetfighter – a stripped down, aggressive, mean machine. The staid looking gauges had to go, besides several other mods to give his bike the right look.

GSXR_03Luckily, he had the right skills and tools available to make sure this DIY hack lives up to the Streetfighter cred of his bike. The important parameter for him was to log the Air / Fuel mixture ratio so he could work on the carburation. Along the way, he seems to have gone a bit overboard with this build, but the end result is quite nice. The build centers around a Planar 160×80 EL graphic display lying in his parts bin. The display didn’t have a controller, so he used the Epson S1D13700 graphic controller to interface it with the microcontroller. An Atmel ATmega128L runs the system, and [Josh] wrote all of his code in “C”.

Continue reading “Superbike gets Bootstrapped Instrument Refit”

Flashed the wrong firmware? Swap out the LCD to match!

We always joke about the hardware guys saying that they’ll fix it in firmware, and vice-versa, but this is ridiculous. When [Igor] tried to update his oscilloscope and flashed the wrong firmware version in by mistake, he didn’t fix it in firmware. Instead, he upgraded the LCD display to match the firmware.

See, Siglent doesn’t make [Igor]’s DSO any more; they stopped using the 4:3 aspect ratio screens and replaced them with wider versions. Of course, this is an improvement for anyone buying a new scope, but not if you’ve got the small screen in yours and can’t see anything anymore. After playing around with flashing other company’s firmware (for a similar scope) and failing to get it done over the JTAG, he gave up on the firmware and started looking for a hardware solution.

It turns out that a few SMT resistors set the output screen resolution. After desoldering the appropriate resistors, [Igor] bought a new 7″ LCD screen online only to find out that it has a high-voltage backlight and that he’d need to build an inverter (and hide the noisy circuit inside his oscilloscope). Not daunted, he went digging through his junk box until he found a backlight panel of the right size from another display.

Yet more small soldering, and he had frankensteined a new backlight into place. Of course, the larger LCD won’t fit the case without some cutting, double-sided tape, and a healthy dose of black tape all around insulates the loose electricals. Et voilá!

We have to hand it to [Igor], he’s got moxie. It’s an ugly hack, but it’s a definite screen upgrade, and a lesser hacker would have stopped after flashing the wrong firmware and thrown the thing in the trash. We’d be proud to have that scope sitting on our desk; it’s a definite conversation starter, and a badge of courage to boot.

Developed on Hackaday – It’s a Badge. No, it’s the HaDge

Sometime back, we announced start of a new project under the “Developed on Hackaday” series – a Badge for the Hackaday community. At its core, this badge is a single node in an Internet of Badges. At every event this badge is deployed at, a Hackaday Sub-Etha mesh network will be created, and each badge will be able to transmit and receive messages from other badge wearers. There are plans for an Sub-Etha to Internet gateway, so even if badge wearers are on the other side of the world, they’re still connected through the HaDge network.

Things have been moving along quickly, so I thought of doing a quick round-up and share progress with the community. First off, it has a name. HaDge, as in HackaDay Badge. Our objectives up until now were to set up a team, name the project, set up repositories and lock down on a working bill of materials. Within a few weeks, we’ve got all of that tied down. The HaDge group chat channel has been super active, and everyone’s been pitching in with ideas and suggestions. A spreadsheet seemed like a good idea – it let everyone add in their suggestions regarding candidate parts, create a feature list and then talk about it on the channel.

We realized early on that building the hardware is going to take some time. So in the interim, we need a dev kit platform to get in to the hands of the software developers so they can start working on the smarts that will power the HaDge. [Michele Perla] had already built JACK (Just another Cortex kit) – a development kit powered by the Atmel SAM D21. It’s pretty bare bone with just the bare minimum of parts to make it work while keeping an eye on reliability. The microcontroller+radio on the HaDge is the Atmel SAM R21 – a close relative of the D21, so it made sense to respin the JACK and create HACK (Hackaday Cortex kit) – a development kit powered by the Atmel SAM R21 that is going to be used as the core of the HaDge. [Michele] has worked hard single-handedly to complete the design and it is now ready to go for PCB fabrication soon. We are just awaiting some feedback and review of the Antenna part of the design. None of us on the hardware team have a strong RF-fu so we don’t want to make an avoidable mistake. If you’d like to review and help vet the HACK design, grab the design files from the github repo and let us know.

Once HACK board layout is cleared for fabrication, we’ll work on building kits that can be sent out to the software folks. We will also be working on porting the HACK design in to KiCad and this is something I have already stared work on. I started by using the neat Eagle2KiCad conversion tool by [LachlanA]. It’s not perfect, but it does reduce the work involved in porting over from Eagle to Kicad. Once that is done, hardware development for the actual HaDge will see some progress – keep a watch on the project page.