hardware

1807 Articles

A Better Battery Arduino

October 1, 2018 by 5 Comments

We’ve seen [Johan]’s AA-battery-sized Arduino/battery crossover before, but soon (we hope!) there will be a new version with more MIPS in the same unique form factor! The original Aarduino adhered to classic Arduino part choices and was designed to run as the third “cell” in a 3 cell battery holder to relay temperature readings via a HopeRF RFM69CW. But as [Johan] noticed, it turns out that ARM development tools are cheap now. In some cases very cheap and very open source. So why not update an outstanding design to something with a little more horsepower?

The Aarduino Zero uses the same big PTH battery terminals and follows the same pattern as the original design; the user sticks it in a battery holder for power and it uses an RFM69CW for wireless communication. But now the core is an STM32L052, a neat low power Cortex-M0+ with a little EEPROM onboard. [Johan] has also added a medium size serial flash to facilitate offline data logging or OTA firmware update. Plus there’s a slick new test fixture to go along with it all.

So how do you get one? Well… that’s the rub. It looks like when this was originally posted at the end of 2017 [Johan] was planning to launch a Crowd Supply campaign that hasn’t quite materialized yet. Until that launches the software sources for the Zero are available, and there are always the sources from the original Aarduino to check out.

What’s The Cheapest Way To Scan Lots Of Buttons?

September 30, 2018 by 33 Comments

So you’re building a new mechanical keyboard. Or attaching a few buttons to a Raspberry Pi. Or making the biggest MIDI grid controller the world has ever know. Great! The first and most important engineering question is; how do you read all those buttons? A few buttons on a ‘Pi can probably be directly connected, one for one, to GPIO pins. A mechanical keyboard is going to require a few more pins and probably some sort of matrix scanner. But the grid controller is less clear. Maybe external I/O expanders or a even bigger matrix? Does it still need diodes at each button? To help answer these questions the folks at [openmusiclabs] generated a frankly astounding map which shows, given the number of inputs to scan and pins available, which topology makes sense and roughly how much might it cost. And to top it off they link into very readable descriptions of how each might be accomplished. The data may have been gathered in 2011 but none of the fundamentals here have changed.

How do you read this chart? The X axis is the number of free pins on your controller and the Y is the number of I/Os to scan. So looking at the yellow band across the top, if you need to scan one input it always makes the most sense to directly use a single pin (pretty intuitive, right?). Scrolling down, if you need to read 110 inputs but the micro only has eight pins free there are a couple choices, keys E and F. Checking the legend at the top E is “Parallel out shift register muxed with uC” and F is “Parallel in shift register muxed with uC“. What do those mean? Checking the table in the original post or following the link takes us to a handy descriptive page. It looks like a “parallel out shift register” refers to using a shift register to drive one side of the scan matrix, and “parallel in shift register” refers to the opposite.

Continue reading “What’s The Cheapest Way To Scan Lots Of Buttons?” →

These 3D Printed Supports Can Take Hard Use, Thanks To Resin Filling

September 29, 2018 by 16 Comments

Liquid two-part resins that cure into a solid are normally used for casting, and [Cuddleburrito] also found them useful to add strength and rigidity to 3D printed pillar supports. In this case, the supports are a frame for some arcade-style buttons, which must stand up to a lot of forceful mashing. Casting the part entirely out of a tough resin would require a mold, and it turns out that filling a 3D print with resin gets comparable benefits while making it easy to embed fastener hardware, if done right.

Cap design shows how the nut will be encased and the cap anchored even if the pillar is slightly underfilled with resin. The screw can be backed out after the resin cures.

Filling the inside of an object with some kind of epoxy or resin to reinforce it isn’t a new idea, but [Cuddleburrito] learned how a few small design considerations can lead to less messy and more successful results. The first is that resin can be poured with screws in place without any worry of trapping the screws in the resin, if done correctly. As long as only the threads of the screw are in the resin, they can be backed out after the resin has cured. Embedding nuts into the resin to act as fasteners becomes a much easier task when one can simply pour resin with both nut and screw in place, and remove the screw afterwards. A thin layer of a lubricant on the threads to act as a release may help, but [Cuddleburrito] didn’t seem to need any.

The second thing learned was that, for a pillar that needs a cap and embedded nut on both ends, it can be tricky to fill the object’s void with the perfect amount of required resin before capping it off. On [Cuddleburrito]’s first attempt, he underfilled and there wasn’t enough resin to capture the nut on the top lid of the pillar he was making. The way around this was to offset the nut on a riser, and design in either a witness hole or an overflow relief. A small drain hole or a safe area for runoff allows for filling things right up without an uncontrolled mess in the case of overfilling.

Something worth keeping in mind when experimenting in this area is that in general the faster a resin cures, the more it heats up in the process. It may be tempting to use something like 5 minute epoxy in a pinch, but the heat released from any nontrivial amount of it risks deforming a thin-walled 3D print in the process. For cases where resin would be overkill and the fasteners are small, don’t forget we covered the best ways to add fasteners directly to 3D printed parts.

Inductance In PCB Layout: The Good, The Bad, And The Fugly

September 28, 2018 by 39 Comments

When current flows through a conductor it becomes an inductor, when there is an inductor there is an electromagnetic field (EM). This can cause a variety of issues during PCB layout if you don’t plan properly, and sometimes we get burned even when we think we have planned for unwanted inductance and the effects that come with them.

When doing high speed logic we need to be able to deliver sudden changes in current to the devices if we want to have proper switching times and logic levels. Unfortunately inductance is usually not a friend in these circumstances as it resists those sudden changes in current. If the high speed devices are driving capacitive loads, which themselves are resisting changes in voltage, even more instantaneous current is needed.

Simply put, inductors resist a change of current, and can act as a low pass filter when in series with the signal or power supply flow. Inductors do this by storing energy in the flux surrounding the conductor. Alternatively capacitors resist a change in voltage (again by storing energy) and can act as a high pass filter when in series with the signal. This makes them a valuable tool in the fight against unwanted inductance in power supply distribution.

In the video below, and the remainder of this article, I’m going to dive into the concept of inductance and how it affects our design choices when laying out circuit boards.

Continue reading “Inductance In PCB Layout: The Good, The Bad, And The Fugly” →

The Exquisite Badges Of Open Hardware Summit

September 27, 2018 by 6 Comments

The past few years have been all about electronic conference badges and this year is no different. Right now, we’re setting up at the Open Hardware Summit at MIT, and this year’s badge is nothing short of extraordinary. It’s a WiFi and Bluetooth-enabled e-paper badge, individually programmed for every attendee. The 2018 Open Hardware Summit badge is a work of art, and it was all created over on hackaday.io.

This board is based on the ESP trINKet designed by [Mike Rankin] with additional hardware design from [Alex Camilo]. The badge is based around the ESP32-wroom-32 module with a 2.13 inch e-paper display with a resolution of 250 x 122 pixels. To this, the badge adds an I2C accelerometer and support for add-ons. There’s also pads for an SD card holder — a soldering challenge, if you will — and few additional pads for bits and bobs.

But a badge is nothing without software, and that’s where this really gets good. The ESP32 module is a powerhouse, capable of emulating NES games or serving as a file server. Here, the stock configuration of the badge is rather simplistic: you can start a WiFi AP, log onto a web page, and change the name displayed on the badge. You can also start an FTP server, which is where things get really fun. Drop an application on that FTP server, and you can run Micro Python.

The badge is great, but the programming jig is awesome

The boards were made through OSH Park, and Screaming Circuits took care of the assembly. Anyone who has ever built a badge will tell you it isn’t the assembly that gets you — it’s the programming and provisioning. This is especially true since the Open Hardware Summit badge is distributed with the attendee’s names already preloaded. That’s a few hundred badges, all with unique firmware. This is a nightmare by any definition.

However, there’s always a good solution to a problem, and [Drew] from OSH Park showed me the best programming jig I’ve ever seen during the Summit pre-game at Artisan’s Asylum.

What you’re looking at is a 3D printed box loaded up with a touch-screen display, a Raspberry Pi Zero W, and a few pogo pins. This Raspberry Pi does all the heavy lifting by connecting to the Internet, pulling down the current version of the firmware, and loading that firmware onto the badge. There are a few more options thanks to the touch-screen interface, including provisioning all the badges with the names of the attendees — this can be done by reading a list of attendees and uploading the next one to the badge in the jig. All of this is wrapped up with a nice laser-cut cover that securely holds each badge exactly where it needs to be for the pogo pins to make contact.

This is, without question, the best programming jig I’ve seen. Any badge makers out there should take note: this is how you program a few hundred badges. The badge, itself, is great and just as this post is published there will be hundreds of eager hackers futzing about with this remarkable piece of hardware. If you want to check out the current progress of the badge hacking, check out the updates on Twitter

Building A Hardware Store Faraday Cage

September 26, 2018 by 78 Comments

Most Hackaday readers are no doubt familiar with the Faraday cage, at least in name, and nearly everyone owns one: if you’ve ever stood watching a bag of popcorn slowly revolve inside of a microwave, you’be seen Michael Faraday’s 1836 invention in action. Yet despite being such a well known device, the average hacker still doesn’t have one in their arsenal. But why?

It could be that there’s a certain mystique about Faraday cages, an assumption that their construction requires techniques or materials outside the realm of the home hacker. While it’s true that building a perfect Faraday cage for a given frequency involves math and careful attention to detail, putting together a simple model for general purpose use and experimentation turns out to be quick and easy.

As an exercise in minimalist hacking I recently built a basic Faraday cage out of materials sourced from Home Depot, and thought it would be interesting to not only describe its construction but give some ideas as to how one can put it to practical use in the home lab. While it’s hardly a perfect specimen, it clearly works, and it didn’t take anything that can’t be sourced locally pretty much anywhere in the world.

Continue reading “Building A Hardware Store Faraday Cage” →

Trials And Tribulations In Sending Data With Wires

September 25, 2018 by 14 Comments

When working on a project that needs to send data from place to place the distances involved often dictate the method of sending. Are the two chunks of the system on one PCB? A “vanilla” communication protocol like i2c or SPI is probably fine unless there are more exotic requirements. Are the two components mechanically separated? Do they move around? Do they need to be far apart? Reconfigurable? A trendy answer might be to add Bluetooth Low Energy or WiFi to everything but that obviously comes with a set of costs and drawbacks. What about just using really long wires? [Pat] needed to connect six boards to a central node over distances of several feet and learned a few tricks in the process.

When connecting two nodes together via wires it seems like choosing a protocol and plugging everything in is all that’s required, right? [Pat]’s first set of learnings is about the problems that happen when you try that. It turns out that “long wire” is another way to spell “antenna”, and if you happen to be unlucky enough to catch a passing wave that particular property can fry pins on your micro.

Plus it turns out wires have resistance proportional to their length (who would have though!) so those sharp square clock signals turn into gently rolling hills. Even getting to the point where those rolling hills travel between the two devices requires driving drive the lines harder than the average micro can manage. The solution? A differential pair. Check out the post to learn about one way to do that.

It looks like [Pat] needed to add USB to this witches brew and ended up choosing a pretty strange part from FTDI, the Vinculum II. The VNC2 seemed like a great choice with a rich set of peripherals and two configurable USB Host/Peripheral controllers but it turned out to be a nightmare for development. [Pat]’s writeup of the related troubles is a fun and familiar read. The workaround for an incredible set of undocumented bad behaviors in the SPI peripheral was to add a thick layer of reliability related messaging on top of the physical communication layer. Check out the state machine for a taste, and the original post for a detailed description.