A Slightly Scientific Examination Of Epoxies

July 19, 2018 by Brian Benchoff 31 Comments

Two-part epoxy is one of those must-have items in your toolbox, albeit kept in a ziploc bag to keep all that goo off the rest of your tools. It’s a glue with a million uses, but which brand is best? Should you keep some cheap five-minute epoxy around, or should you splurge for the fancy, long-setting JB Weld. It’s not a perfect analysis, but at least [Project Farm] has done the experiment. This is a test of which two-part epoxy you can find at your local home supply store is strongest.

The epoxies tested include Gorilla epoxy, Devcon Plastic Steel, Loctite Epoxy Weld, JB Weld original, JB Weld Kwik Weld, and JB ExtremeHeat. This more or less covers the entire gamut of epoxies you would find in the glue aisle of your local home supply store; the Gorilla epoxy is your basic 5-minute epoxy that comes in a double barrel syringe, and the JB Welds are the cream of the crop.

The testing protocol for this experiment consisted of grinding a piece of steel clean, applying a liberal blob of each epoxy, and placing three bolts, head down, in each puddle. The first test was simply suspending weights in 2.5-pound increments to each bolt as a quick test of shear strength. Here, the losers in order were the JB Weld ExtremeHeat, JB Weld KwikWeld, Loctite, Gorilla Epoxy, Devcon Plastic Steel, and finally the JB Weld Original. Your suspicions are confirmed: those fancy new versions of JB Weld aren’t as good as the original. The fact that they’re worse than 5-minute epoxy is surprising, though. The second test — torquing the bolts out of the epoxy — gave similar results, with Devcon Plastic Steel beating the JB Weld Original just barely.

So, what do these results tell us? Cheap five-minute epoxy isn’t terrible, and actually better than the fancy new versions of JB Weld. Loctite is okay, and the Devcon and original JB Weld are at the top of their game. That’s not that surprising, as you can cast cylinder heads for engines out of JB Weld.

Continue reading “A Slightly Scientific Examination Of Epoxies” →

Hot Camera Contest: Build A Battery Powered Thermal Camera

July 18, 2018 by Brian Benchoff 36 Comments

Here’s a challenge for all you hardware hackers out there. Peter Jansen has opened up the Hot Camera Contest on Hackaday.io to use a thermal imaging camera in a battery-powered project.

The challenge here is simple. Use a Flir Lepton thermal imaging camera module in a battery-powered configuration. There’s a catch, though: this is a project to use the Lepton in radiometric mode, where the camera spits out an actual temperature value for each pixel. Yes, this is a documented feature in the Flir Lepton module, but so far very few people are using it, and no one has done it with a small, battery-powered device.

The rules for this challenge are to use the Flir Lepton 2.5 in radiometric mode using either the Raspberry Pi Zero W or ESP32. Any software in this challenge must spit out absolute temperature values in a text format, and there must be a demonstration of putting the Flir Lepton into low-power mode. There are two challenges here, one for the Raspi and one for the ESP32; and winner will be named for each.

Getting More from a Fascinating Sensor

The Flir Lepton is a tiny little thermal camera that’s been available to the Maker community for some time now, first through GroupGets and now through Sparkfun. For a pair of Benjamins, the specs are very impressive: the Lepton has a resolution of 60×80 pixels and everything is can be read over an SPI port. The Lepton gives any project thermal imaging, and the PureThermal board turns the Lepton into a USB device.

Peter Jansen is the creator of the Open Source Science Tricorder (yes, it’s a tricorder) which took Fourth Prize in the 2014 Hackaday Prize. You can understand how he became interested in portable, and we’re sure whatever project he has in mind for this battery-powered Flir will be awesome.

This really is a great example of what the Hackaday.io community is capable of. The goal here is to create useful Open Source drivers for some very interesting hardware, and there’s some prizes to sweeten the pot. Peter has a $125 Sparkfun gift card on offer for each of the two winners. And the challenge of solving a tricky problem and making designs easier for others is a powerful motivator. Who doesn’t like a challenge?

How Low Can You Go? Tiny Current Generator

July 18, 2018 by Jenny List 19 Comments

Current limited power supplies are a ubiquitous feature of the bench, and have no doubt helped prevent many calamities and much magic smoke being released from pieces of electronics. But for all their usefulness they are a crude tool that has a current resolution in the range of amps rather than single digit milliamps or microamps.

To address this issue, [Yann Guidon] has produced a precision current source, a device designed to reliably inject tiny currents. And in a refreshing twist, it has an extremely simple circuit in the form of a couple of PNP transistors. It has a range from 20 mA to 5 µA which is set and fine-tuned by a pair of pots, and it has a front-panel ammeter hacked from a surplus pocket multimeter, allowing the current to be monitored. Being powered by its own internal battery (and a separate battery for the ammeter) it is not tied to the same ground as the circuit into which its current is being fed.

[Yann] is a prolific builder whose work has featured here more than once. Take a look at his rubidium reference and his discrete component clocks, for example, and his portable LED flash.

CortexProg Is A Real ARM-Twister

July 17, 2018 by Elliot Williams 32 Comments

We’ve got a small box of microcontroller programmers on our desktop. AVR, PIC, and ARM, or at least the STMicro version of ARM. Why? Some program faster, some debug better, some have nicer cables, and others, well, we’re just sentimental about. Don’t judge.

[Dmitry Grinberg], on the other hand, is searching for the One Ring. Or at least the One Ring for ARM microcontrollers. You see, while all ARM chips have the same core, and thus the same SWD debugging interface, they all write to flash differently. So if you do ARM development with offerings from different chip vendors, you need to have a box full of programmers or shell out for an expensive J-Link. Until now.

[Dmitry] keeps his options open by loading up the flash-specific portion of the code as a plugin, which lets the programmer figure out what chip it’s dealing with and then lookup the appropriate block size and flash memory procedures. One Ring. He also implements a fast printf-style debugging aid that he calls “ZeroWire Trace” that we’d like to hear more about. Programming and debugging are scriptable in Lua, and it can do batch programming based on reading chip IDs.

You can build your own CortexProg from an ATtiny85, two diodes, and two current-limiting resistors: the standard V-USB setup. The downside of the DIY? Slow upload speed, but at least it’ll get you going. He’s also developed a number of fancier versions that improve on this. Version four of the hardware is just now up on Kickstarter, if you’re interested.

If you’re just using one vendor’s chips or don’t mind having a drawer full of programmers, you might also look into the Black Magic Probe. It embeds a GDB server in the debugger itself, which is both a cool trick and the reason that you have to re-flash the programmer to work with a different vendor’s chips. Since the BMP firmware is open, you can make your own for the cost of a sacrificial ST-Link clone, about $4.

On the other hand, if you want a programmer that works across chip families, is scriptable, and can do batch uploads, CortexProg looks like a caviar programmer on a fish-bait budget. We’re going to try one out soon.

Oh and if you think [Dmitry Grinberg] sounds familiar, you might like his sweet Dreamcast VRU hack, his investigations into the Cypress PSOCs, or his epic AVR-based Linux machine.

ERRF 18: New Products Make Their Debut

July 13, 2018 by Tom Nardi 6 Comments

While ostensibly the purpose of the recent East Coast RepRap Festival (ERRF) was to celebrate the 3D printing community and culture, it should come as no surprise that more than a few companies decided to use the event as an opportunity to publicly launch new products. Who can blame them? It’s not as if every day you have a captive audience of 3D printing aficionados; you might as well make the best of it.

Many creations were being shown off for the first time at ERRF, and we surely didn’t get a chance to see them all. There was simply too much going on at any given time to be sure no printed stone was left unturned. But the following printers, filaments, and accessories caught our attention long enough to warrant sharing with the good readers of Hackaday.

Keep in mind that much of this information is tentative at best, and things could easily change between now and when the products actually go on sale. These events serve as much as a sounding board for new products as they do a venue for advertising and selling them, so feedback received from show attendees may very well alter some of these products from what we saw at ERRF.

Continue reading “ERRF 18: New Products Make Their Debut” →

Shoehorning A Slick Spotify Remote Into An ESP8266

July 11, 2018 by Kerry Scharfglass 9 Comments

In 2017 Spotify finally deprecated their public vanilla C SDK library, libspotify, and officially replaced it with dedicated SDKs for iOS and Android and this new-fangled web thing we’ve all heard so much about. This is probably great for their maintainability but makes writing a native application for a Linux or a hardware device significantly harder, at least without an application process and NDA. Or is it? Instead of using that boring slab of glass and metal in their pocket [Dani] wanted to build a handy “now playing” display and remote control interface but was constrained by the aforementioned SDK limitations. So they came up with a series of clever optimizations resulting in the clearly-named ESP8266 Spotify Remote Control.

The Spotify Remote Control has a color LCD with a touchscreen. Once attached to a Spotify account it will show the album art of the currently playing track (with a loading indicator!) and let you play/pause/skip tracks from its touch screen, all with impressively low latency. To get here [Dani] faced two major challenges: authorizing the ESP to interact with a user’s Spotify account, and low latency LCD drawing.

If you’re not on iOS or Android, the Spotify web API is the remaining non-NDA’d interface available. But it’s really designed to be used on relatively rich platforms such as fully featured web browsers, not an embedded device. To that end, gone are the days of asking a user to enter their username and password in a static login box, the newer (better) way is to negotiate for a per-user token (which is individually authorized per application), then to use that to authenticate your interaction. With this regime 3rd party applications (in this case an ESP8266) never see a user’s password. One codified and very common version of this process is called OAuth and the token dance is called a “workflow”. [Dani] has a pretty good writeup of the process in their post if you want more detail about the theory. After banging out the web requests and exception handling (user declines to authorize the device, etc) the final magic ended up being using mDNS to get the user’s browser to redirect itself to the ESP’s local web server without looking up an IP first. So the setup process is this: the ESP boots and displays a URL to go to, the user navigates there on a WiFi connected device and operates the authorization workflow, then tokens are exchanged and the Remote Control is authorized.

The second problem was smooth drawing. By the ESP’s standards the album art for a given track at full color depth is pretty storage-large, meaning slow transfers to the display and large memory requirements. [Dani] used a few tricks here. The first was to try 2 bit color depth which turned out atrociously (see image above). Eventually the solution became to decompress and draw the album art directly to the screen (instead of a frame buffer) only when the track changed, then redraw the transport controls quickly with 2 bit color. The final problem was that network transfers were also slow, requiring manual timesharing between the download code and the display drawing routing to ensure everything was redrawn frequently.

Check out [Dani]’s video after the break, and take a peek at the sources to try building a Spotify Remote Control yourself.

Continue reading “Shoehorning A Slick Spotify Remote Into An ESP8266” →

Diode Recovery Time Explained

July 11, 2018 by Al Williams 19 Comments

There are at least two phases to learning about electronics. In the first phase, you learn about how components are supposed to work. In the second phase, you learn about how they really work. Wires have resistance and inductance. Adjacent wires have capacitance. Capacitors leak. Inductors have resistance. All of these things matter. [Learnelectronics] has a recent video that explores recovery time for a diode — a phase two conversation.

If you haven’t run into recovery time before, it is the amount of time the diode takes to shut off after it is conducting. This manifests itself as a little undershoot where the signal that the diode should block leaks through briefly.

Continue reading “Diode Recovery Time Explained” →