Hardware Should Lead Software, Right?

Once upon a time, about twenty years ago, there was a Linux-based router, the Linksys WRT54G. Back then, the number of useful devices running embedded Linux was rather small, and this was a standout. Back then, getting a hacker device that wasn’t a full-fledged computer onto a WiFi network was also fairly difficult. This one, relatively inexpensive WiFi router got you both in one box, so it was no surprise that we saw rovers with WRT54Gs as their brains, among other projects.

Long Live the WRT54G

Of course, some people just wanted a better router, and thus the OpenWRT project was born as a minimal Linux system that let you do fancy stuff with the stock router. Years passed, and OpenWRT was ported to newer routers, and features were added. Software grew, and as far as we know, current versions won’t even run on the minuscule RAM of the original hardware that gave it it’s name.

Enter the ironic proposal that OpenWRT – the free software group that developed their code on a long-gone purple box – is developing their own hardware. Normally, we think of the development flow going the other way, right? But there’s a certain logic here as well. The software stack is now tried-and-true. They’ve got brand recognition, at least within the Hackaday universe. And in comparison, developing some known-good hardware to work with it is relatively easy.

We’re hardware hobbyists, and for us it’s often the case that the software is the hard part. It’s also the part that can make or break the user experience, so getting it right is crucial. On our hacker scale, we often choose a microcontroller to work with a codebase or tools that we want to use, because it’s easier to move some wires around on a PCB than it is to re-jigger a software house of cards. So maybe OpenWRT’s router proposal isn’t backwards after all? How many other examples of hardware designed to fit into existing software ecosystems can you think of?

Erasing EEPROMs Isn’t Always As Easy As It Seems

When is 14 volts not actually 14 volts? Given [Anders Nielsen]’s recent struggles with erasing an old-school EEPROM, it’s when you really need it that things tend to go pear-shaped.

A little background is perhaps in order. [Anders] is working on a scratch-built programmer for ROMs to complement his 65uino project, which puts a complete 6502 computer into the footprint of an Arduino Uno. He wisely started the ROM programmer project at the beginning, which was to generate the correct voltages for programming. This turned out to be not as easy as you might think thanks to the solderless breadboard’s parasitic effects on the MIC2288 switching boost regulator he chose.

The video below is a continuation of the programmer build, which ends up being just as fraught as the first part. Being able to generate the programming voltages is one thing; getting them onto the right pins at the right time using nothing but the 5-volt GPIOs on a microcontroller is another. In true retro fashion, [Anders] tackled that problem with a pair of small-signal transistors, which seemed to work once the resistor values were sorted, at least when applying a 12-volt signal intended to show the ROM’s hard-coded manufacturer ID on the data bus.

But erasing the ROM, which requires 14 volts while the chip enable line is held high for 100 ms, proved a little trickier. Despite multiple tries, the ROM wouldn’t erase thanks to the 14-volt rail being dragged down to around 9 volts. [Anders] fixed that with a new base resistor on the driver, to increase the current and keep the voltage up where it needs to be. Just goes to show you that the data sheets don’t always tell the whole story.

We’ve been enjoying the unfolding story of this programmer, and we’re looking forward to the next installment.

Continue reading “Erasing EEPROMs Isn’t Always As Easy As It Seems”

Arduino Provides No Fuss SNES-To-USB Conversion

Even for those of us who are fans of retrocomputing, it’s fair to say that not everyone plays their old-school games on real old-school hardware. The originals are now fragile and expensive, and emulators are good enough that if the gaming experience is all you’re after there’s little point in spending all that cash.

There’s one place in which the originals sometimes have the edge though, the classic controllers are the personal interface with the game. So when [Dome] found a SNES controller in an Akibahara shop, of course he picked it up. How to make it talk to a PC? Tuck an Arduino Pro Micro inside it, of course!

What we like about this project is that instead of ripping out the original electronics it instead hooks the Arduino board onto the original serial interface. We might have made a Nintendo socket to USB box to keep the original cable, but either way, the SNES (technically Super Famicom, because it’s a Japanese market unit) original stays true to its roots. The Arduino polls the clock line at the speed of the console, reads the result, and translates it to a USB interface for the computer. There’s a full run-down of the code and how it was made, should you wish to try.

Of course, if you don’t always have a PC handy, you could also put the whole computer in the controller.

Testing The Atlas ICBM: A 1958 Time Capsule Video

The control room during the 1958 Atlas B 4B test. (Source: Convair)
The control room during the 1958 Atlas B 4B test. (Source: Convair)

Recently the [Periscope Film] channel on YouTube published a 1960 color documentary featuring the 1958 launch of the Atlas B (SM-65B) ICBM, in its second, Missile 4B iteration. This was the second model of the second prototype, which earned the distinction of being the first truly intercontinental ballistic missile upon its successful test completion, which saw the payload plummeting into its designated part of the Atlantic Ocean. This was a much better result than the previous test of the 3B, which suffered a yaw gyro issue that caused the missile to disintegrate partway into the flight.

In this historic documentary, the Atlas B’s manufacturer – Convair – takes us through all the elements of the test range, including all the downrange stations, their functions and how all the data from the test is captured, recorded (on reel to reel tape) and integrated into one coherent data set. This includes radar data, telemetry received from the missile, as well as the data tape that the ICBM ejects from the payload section shortly before impact.

Although it’s also a promotion piece for Convair Astronautics, this does little to mar the documentary aspect, which is narrated by William Conrad, who manages to both instill a sense of technological wonder and grim foreboding against the scenery of 1950s military high-tech in the midst of a heating up Cold War.

Continue reading “Testing The Atlas ICBM: A 1958 Time Capsule Video”

A black plastic trim piece from a vehicle interior. It has slight flecking in its texture. It is sitting on an off-white bench overlooking a workshop.

Can Car Parts Grow On Trees?

Cars don’t grow on trees, but Ford is designing car parts from olive tree cuttings. [via Electrek]

Ford is no stranger to designing parts from plants for their vehicles. Henry famously liked to beat on the Soy Bean Car with a blunted axe to tout the benefits of bioplastic panels. Researchers at Ford’s Cologne, Germany facility have detailed their work to use waste from olive orchards as part of a new biocomposite from the LIVE COMPOLIVE program.

Fibers from the olive tree cuttings are mixed with recycled plastic and injection molded to form panels. The video below features interior panels that are currently made with traditional plastics that could be swapped over to the new composite. Since these cuttings are a waste product from food production, there isn’t the tension akin to that presented via biofuels vs food. We’re curious what Precious Plastics could do with this, especially if the fibers are able to reinforce the matrix.

If you want to see some other unusual uses for waste wood, why not checkout a “paper” bottle or 3D printing with sawdust?

Continue reading “Can Car Parts Grow On Trees?”

Alarm Panel Hack Defeats Encryption By Ignoring It

As frustrating as it may be for a company to lock you into its ecosystem by encrypting their protocols, you have to admit that it presents an enticing challenge. Cracking encryption can be more trouble than it’s worth, though, especially when a device gives you all the tools you need to do an end-run around their encryption.

We’ll explain. For [Valdez], the encrypted communication protocols between a DSC alarm panel and the control pads on the system were serious impediments to integration into Home Assistant. While there are integrations available for these alarm panels, they rely on third-party clouds, which means that not only is your security system potentially telling another computer all your juicy details, but there’s also the very real possibility that the cloud system can either break or be shut down; remember the Chamberlain MyQ fiasco?

With these facts in mind, [Valdez] came up with a clever workaround to DSC encryption by focusing on physically interfacing with the keypad. The device has a common 16×2 LCD and a 25-key keypad, and a little poking around with a multimeter and a $20 logic analyzer eventually showed that the LCD had an HD44780 controller, and revealed all the lines needed to decode the display with an ESP32. Next up was interfacing with the keypad, which also involved a little multimeter work to determine that the keys were hooked up in a 5×5 matrix. Ten GPIOs on the ESP32 made it possible to virtually push any key; however, the ten relays [Valdez] originally used to do the switching proved unwieldy. That led to an optocoupler design, sadly not as clicky but certainly more compact and streamlined, and enabling complete control over the alarm system from Home Assistant.

We love this solution because, as [Valdez] aptly points out, the weakest point in any system is the place where it can’t be encrypted. Information has to flow between the user and the control panel, and by providing the electronic equivalents to eyes and fingers, the underlying encryption is moot. Hats off to [Valdez] for an excellent hack, and for sharing the wealth with the HA community.

‘Radar’ Glasses Grant Vision-free Distance Sensing

[tpsully]’s Radar Glasses are designed as a way of sensing the world without the benefits of normal vision. They consist of a distance sensor on the front and a vibration motor mounted to the bridge for haptic feedback. The little motor vibrates in proportion to the sensor’s readings, providing hands-free and intuitive feedback to the wearer. Inspired in part by his own experiences with temporary blindness, [tpsully] prototyped the glasses from an accessibility perspective.

The sensor is a VL53L1X time-of-flight sensor, a LiDAR sensor that measures distances with the help of pulsed laser light. The glasses do not actually use RADAR (which is radio-based), but the operation is in a sense quite similar.

The VL53L1X has a maximum range of up to 4 meters (roughly 13 feet) in a relatively narrow field of view. A user therefore scans their surroundings by sweeping their head across a desired area, feeling the vibration intensity change in response, and allowing them to build up a sort of mental depth map of the immediate area. This physical scanning resembles RADAR antenna sweeps, and serves essentially the same purpose.

There are some other projects with similar ideas, such as the wrist-mounted digital white cane and the hip-mounted Walk-Bot which integrates multiple angles of sensing, but something about the glasses form factor seems attractively intuitive.

Thanks to [Daniel] for the tip, and remember that if you have something you’d like to let us know about, the tips line is where you can do that.