Surely a blown light bulb can’t kill a microwave oven, right? You might not expect it to, but that was indeed the root cause of a problem that [mikeselecticstuff] recently investigated; the cascade of failures is instructive to say the least.
While the microwave that made its way to [mike]’s bench wasn’t exactly engineered to fail, it surely was not designed to succeed. We won’t spoil the surprise, but suffice it to say that his hopes for a quick repair after the owner reported a bang before it died were dashed by an arc across the interior light bulb that put a pulse of mains voltage in places it didn’t belong. That the cascade of failures killed the appliance is a testament to how designing to a price point limits how thoroughly devices can be tested before production runs in the millions are stuffed into containers for trips to overseas markets.
Even though [mike] made his best effort to adhere to the Repair Manifesto, the end result was a scrapped microwave. It wasn’t a total loss given the interesting parts inside, but a disappointment nonetheless unless it forces us to keep in mind edge-case failure modes in our designs.
Continue reading “Unlikely Cascade of Failures Leads to Microwave’s Demise”
If you head down to your local electronics supply shop (the Internet), you can pick up a quality true-RMS multimeter for about $100 that will do almost everything you will ever need. It won’t be able to view waveforms, though; this is the realm of the oscilloscope. Unlike the multimeter’s realistic price point, however, a decent oscilloscope is easily many hundreds, and often thousands, of dollars. While this is prohibitively expensive for most, the next entry into the Hackaday Prize seeks to bring an inexpensive oscilloscope to the masses.
The multiScope is built by [Vítor] and is based on the STM32-O-Scope which is built around a STM32F103C8T6 microcontroller. This particular chip was chosen because of its high clock speed and impressive analog-to-digital resolution, which are two critical specifications for any oscilloscope. This particular scope has an inductance meter built-in as well, which is another feature which your otherwise-capable multimeter probably doesn’t have.
New features continue to get added to this scope by [Vítor]. Most recently he’s added features which support negative voltages and offsets. His particular scope is built inside of a model car, too, but we believe this to be an optional feature.
By now it might seem like there’s no new way to build a binary clock. It’s one of the first projects many build to try out their first soldering irons, so it’s a well-traveled path. Every now and then, however, there’s a binary clock that takes a different approach, much like [Stephen]’s latest project which he calls the byte clock.
The clock works by dividing the 24-hour day into half and using an LED to represent this division, which coincidentally works out to representing AM or PM. The day is divided in half over and over again, with each division getting its own LED. In order to use this method to get one-second resolution it would need 16 LEDs, but since that much resolution isn’t too important for a general-use clock, [Stephen] reduced this to eight.
Additionally, since we’re in the Internet age, the clock has built-in WiFi courtesy of a small version of Python called WiPy which runs on its own microcontroller. A real-time clock rounds out the build and makes sure the clock is as accurate as possible. Of course an RTC might not have the accuracy as some other clocks, but for this application it certainly gets the job done.
A big problem with restoring old arcade or pinball machines is finding original parts to get them running again. That’s part of the fun, though; when something finally works after weeks or months of effort. On the other hand, sometimes the only hope for old parts that will never be in a pinball machine again is for [Randy] to come across them. One of those parts he had lying around was a backglass for an old machine, and decided to turn it into a unique word clock.
The original pinball machine was built in 1956, and despite its age the backglass had almost no signs of wear or damage. There are 43 lights on this particular machine which is more than enough for 12 hours, minutes (by the 10s), seconds, and a few extras. An ATtiny85 serves as the controller and drives a fleet of Neopixels hidden in the display. There are also three buttons which control the brightness and allow the time to be set.
Be sure to check out the video below of this one-of-a-kind clock in action. A lot more went into this build as well including framing the glass, giving it a coat of paint and polish, and programming the clock into the microcontroller. Old backglasses from pinball machines seem to be relatively popular to repurpose into more conventional clocks, too, even clocks of an atomic nature.
Continue reading “Antique Pinball Machine Lives as Clock”
Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.
NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.
Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.
I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.
If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.
Your tax dollars at work. Thanks, NIST!
And thanks [acs] for the tip!
A self-balancing robot is a great way to get introduced to control theory and robotics in general. The ability for a robot to sense its position and its current set of circumstances and then to make a proportional response to accomplish its goal is key to all robotics. While hobby robots might use cheap servos or brushed motors, for any more advanced balancing robot you might want to reach for a brushless DC motor and a new fully open-source controller.
The main problem with brushless DC motors is that they don’t perform very well at low velocities. To combat this downside, there are a large number of specialized controllers on the market that can help mitigate their behavior. Until now, all of these controllers have been locked down and proprietary. SmoothControl is looking to create a fully open source design for these motors, and they look like they have a pretty good start. The controller is designed to run on the ubiquitous ATmega32U4 with an open source 3-phase driver board. They are currently using these boards with two specific motors but plan to also support more motors as the project grows.
We’ve seen projects before that detail why brushless motors are difficult to deal with, so an open source driver for brushless DC motors that does the work for us seems appealing. There are lots of applications for brushless DC motors outside of robots where a controller like this could be useful as well, such as driving an airplane’s propeller.
Writing code for embedded applications can be difficult. There are all sorts of problems you can run into – race conditions, conflicting peripherals, unexpected program flow – any of these can cause havoc with your project. One thing that can really mess things up is if your microcontroller is getting stuck on a routine – without the right debugging hardware and software, this can be a tricky one to spot. [Terry] developed a microcontroller load meter just for this purpose.
It’s a simple setup – a routine named loadmeter-task on the microcontroller sends a train of pulses to a mechanical ammeter. The ammeter is then adjusted with a trimpot to read “0” when the chip is unloaded. As other tasks steal CPU time, there’s less time for loadmeter-task to send its pulses, so the meter falls to the left.
Overall it’s a quick and easy bit of code you could add to any project with a spare GPIO pin, that might help you debug. Plus it’s cool to know how hard your project is pushing the silicon.
If you’d like to know more about what your chip is doing, check out this post about the usefulness of in-circuit debugging, or read about Bil Herd’s experiments with ICE and OBD-II.