The 20th century saw a great many cheap, utilitarian vehicles enter the marketplace. Cars like the Mini and the original Jeep offered low-cost, no-frills motoring. However, they were also decidedly low-tech, and not as reliable as modern cars by a long shot. The Citroën Mehari fits into this category neatly, and when [FVFILIPPETTI] grew tired of the unreliable points ignition system, he decided to build a more modern replacement.
The system is based around at ATmega328, the venerable chip many are familiar with from its starring role in the Arduino Uno. The chip tracks engine position with a magnet mounted on the flywheel combined with a hall-effect sensor, passed through an optocoupler to avoid nasty high-voltage spikes from the spark system interfering with the microcontroller. The chip then charges the ignition coil and fires it at the necessary time to ignite the air fuel mixture.
Old-school mechanical ignition systems were, if we’re honest, terrible compared to more modern solutions. This build has rewarded [FVFILIPPETTI] with a far more reliable ride, which we’re sure is very satisfying. If all this hacking has you thirsty for an automotive project of your own, dive into our primer on how to get into cars!
While the de facto smartphone design ultimately went in a different direction, there’s no denying the classic BlackBerry layout offered some compelling advantages. It was a gadget primarily designed to send and receive emails and text messages, and it showed. So is it really any wonder [MSG] would build his pocket-sized LoRa messengers in its image?
Of course, he did have some help. The communicators use the Keyboard FeatherWing by [arturo182], which puts a surplus BlackBerry Q10 keyboard on a custom PCB designed to accept a board from Adafruit’s Feather collection. [MSG] ended up pairing his with a Feather M4 because he wanted to work with CircuitPython, with a 900 MHz LoRa FeatherWing along for the ride. He notes that switching his code over to Arduino-flavored C would allow him to use the Feather M0 that features integrated LoRa; a change that would allow him to make the gadget a bit thinner.
Inside the 3D printed enclosure, He’s made room for a 3.7 V 1800 mAh pouch battery that should provide plenty of runtime. There’s also an external antenna with a uFL pigtail for connecting to the radio. The case is held together with heat-set inserts, which should make it more than robust enough to handle a few adventures.
[MSG] says slight variations in hardware versions means his STLs might need a little tweaking to fit your components, and warns that his code is basically just a mashup of examples he found online, but he’s still sharing the goods for anyone who wants to reach out and touch someone without all that pesky infrastructure in the way.
As [Luuk Esselbrugge] explains in a recent blog post, his 2002 Volvo S60 had an optional GPS navigation system and backup camera that used a motorized display that would rise out of the dashboard when needed. His particular car didn’t come with the hardware installed, but after getting his hands on a display module and doing some research, he figured out how he could drive it with the Raspberry Pi and a couple of microcontrollers.
Given the age of the display, you probably won’t be surprised to hear that it uses composite video. Not exactly high resolution, but in the demonstration after the break, we have to admit it looks more than up to the task. [Luuk] is running Android Auto on the Raspberry Pi 3 through the openauto project, which gives him a nice big display and access to all the navigation and media applications you’d expect. The display doesn’t support touch, but thanks to an ESP32 plugged into the CAN bus, he’s able to control the software by reading the buttons built into the Volvo’s steering wheel.
Composite video sources are switched with a simple relay.
To actually raise and lower the display, [Luuk] found you just need to fire a few bytes down the 1,200 baud serial bus that’s built into the display’s wiring harness. The ESP32 handles this duty as well, at least partly because it’s already plugged into the CAN bus and can tell when the vehicle is in reverse. This lets it bring up the screen to show the video feed from the newly installed backup camera in the event that the Pi hadn’t already asked to raise the display. Incidentally plugging in the phone normally triggers the system to wake up and raise the screen, and disconnecting it will command the screen to lower back into the stowed position.
The attentive reader or Volvo aficionado may be wondering how [Luuk] got the audio working. Since his car’s sound system doesn’t feature an auxiliary input, he’s using an Arduino to spoof the existence of a CD changer, which allows him to inject an audio signal into one of the pins on the back of the radio. Eventually he wants to move this task over to the ESP32, but he says a big change like that will have to wait until warmer weather.
This isn’t the first time we’ve seen the Raspberry Pi used to add enhanced features to a somewhat older vehicle. While some bemoan the increased complexity of modern vehicles, it seems some hackers can’t get enough of it.
One aspect of working for Hackaday comes in our regular need to take good quality photographs for publication. I have a semi-decent camera that turns my inept pointing and shooting into passably good images, but sometimes the easiest and quickest way to capture something is to pull out my mobile phone.
It’s a risky step because phone camera modules and lenses are tiny compared to their higher quality cousins, and sometimes the picture that looks good on the phone screen can look awful in a web browser. You quickly learn never to zoom on a mobile phone camera because it’s inevitably a digital zoom that simply delivers grainy interpolated pictures.
That’s not to say that the zoom can’t be useful. Recently I had some unexpected inspiration when using a smartphone camera as a magnifier to read the writing on a chip. I don’t need an archival copy of the image… I just needed a quick magnifying tool. Have I been carrying a capable magnifier for soldering in my pocket or handbag for years without realising it? I decided to give it a try and it worked okay with a few caveats. While I have seen optics turn these cameras into pretty good microscopes, my setup added nothing more than a phone tripod, and will get you by in a pinch.
What’s Your Magnifier Of Choice?
A pin-sharp image delivered by Elliot’s optical microscope.
There was a time when I was much younger in which I remember being able to read the text on a SOT-23 transistor, but sadly even now wearing glasses those days are long past. Fortunately for me though I have a huge variety of options for soldering magnification. At various times I’ve used desktop magnifiers and headband magnifiers, but I’ve settled upon a large lens on an Anglepoise-style arm — you know, the springy lamp kind. These lens-on-an-arm are very common with beauty therapists and the like, utilizing a powerful ring of LED lights and providing ample magnification even for my eyes. I’ve also used various different LCD magnifiers belonging to friends and hackerspaces, but while I an extremely impressed by them I’ve so far been put off by the price for decent ones (even if I’ve brought you a super-cheap alternative via the unexpected medium of an ear cleaning camera in the past). My colleague Elliot meanwhile uses a very high quality 1970s binocular examination microscope that delivers exceptional quality, an instrument he swears by and which you will sometimes see being used in his work like the recent Raspberry Pi Pico review.
With all this very usable and capable equipment to hand it’s very clear that a mobile phone would have to be an exceptionally good alternative if it were to supplant them. But how about as a quick in-the-field option to sit alongside what you already have? Time to give it a try, and solder something with it.
Useful For More Than Cat Pictures? We give Our Phone A Try
Soldering in close-up, a phone camera view.
The phones I had to hand were nothing special, the mid-range Huawei and Motorola Android devices that are my constant companions for both business and personal use. No high-end flagship cameras here, but the current generation of decent-ish phone cameras with which they gave similar results. I’m guessing that almost any smartphone made over the last few years could be pressed into service here. I put it on the mini tripod I use for Hackaday close-up shots, and pulled out a half-finished kit for a bit of soldering practice.
The image on maximum zoom provides plenty of magnification, and provides a high quality view of the work. In that context it’s better than my big magnifier, as it can deliver a closer view. The positive news ends though when the work starts, as a small but noticeable delay between action and screen leads to something of a learning curve as your soldering technique adapts. Perhaps more disconcerting is an unexpected disorientation in what I can only describe in perspective terms if that’s possible on a 2D display. These effects hold a fascination for me as someone who can’t see stereoscopic 3D, so why does a real 2D LCD microscope not have this problem? I am theorising when I say this, but I suspect that the solution lies in the camera’s depth of field. A mobile phone is designed to take reasonable pictures of everything in its field of view, so it has a particularly wide depth of field. The microscope meanwhile is designed to bring objects at a particular distance into sharp focus, so with its narrow depth of field it transmits some depth information in terms of focus. Our brains subconsciously process this, making depth placement of a soldering iron an easier process.
So I was able to solder a few components successfully through my phone’s view of the world. The slight delay and lack of perspective took a little getting around, and I can’t honestly recommend this technique for anybody’s bench. It does however remain a just-about-viable solution for impromptu SMD soldering in the field, but I’d advise you to practice a little before working on anything you care about. Perhaps a better bet would be to put one of those ear cameras I mentioned in your field toolkit alongside your miniature soldering iron, and use the mobile phone instead as its display. Everything is worth trying once, but perhaps a phone as an SMD soldering aid isn’t worth trying twice.
Hackaday editors Elliot Williams and Mike Szczys spin the wheel of hardware hacking brilliance. We’re enamored with the quest for a root shell on a Nissan Xterra infotainment system, and smitten with a scanning microscope that uses a laser beam and precision positioning from DVD drives. We speculate on the future of artificial intelligence in the culinary arts. And this week turned up a clever way to monitor utility usage while only changing the battery on your sensor once per year.
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
One of the selling points of the Arduboy is how slim [Kevin Bates] was able to get the Arduino-compatible game system, which is perhaps less surprising when you realize that it originally started out as a design for an electronic business card. But compared to the recently unveiled Nano version, it might as well be the old school “brick” Game Boy.
Now to be clear, [Kevin] isn’t looking to put these into official production. Though it does sound like the bare PCBs might be going up for sale in the near future. This was simply an experiment to see how far he could shrink the core Arduboy hardware while still keeping it not only playable but also code-compatible with the full-size version. While “playable” might be a tad subjective in this case, the video after the break clearly demonstrates that it’s fully functional.
Inside the 3D printed case is the same ATmega32U4 that powers the Arduboy, a 64×32 0.49″ OLED display, and a tiny 25 mAh pouch battery. There’s even a miniature piezo speaker for the bleeps and bloops. All of the pinouts have remained the same so existing code can be moved right over, though the screen is now connected over I2C. [Kevin] has released the schematics for the board in keeping with the general open nature of the Arduboy project, though for now he’s decided to hold onto the board files until it’s clear whether or not there’s a commercial future for the Nano.
I’ve seen a couple of theories tossed around about how the domains were stolen. With multiple domains being moved, it initially seemed that the registrar had been compromised in some way. One of the other victims was told that a set of official looking documents had been supplied, “proving” that the attacker was the rightful owner of the domain. In any case, the damage is slowly being unwound. Perl.com is once again in the proper hands, evidenced by the proper SSL certificate issued back in December.
The Great Suspender, Suspended
I was greeted by a particularly nasty surprise on Thursday of this week. One of the Chrome extensions I’ve come to rely on was removed by Google for containing malware. The Great Suspender automatically hibernates unused tabs, saving ram and processor cycles that would otherwise be spent on those 150 open tabs that should really be bookmarks. What happened here?
I’ll point out that I’m extremely careful about installing extensions. It’s code written by a third party, often very difficult to inspect, and can view and modify the sites you visit. You can manage what sites an extension has access to, but for a tool like the Suspender, it essentially needs access to all of them. The solution is to use open source extensions, right? “Well yes, but actually no.” Suspender is open source, after all. The link above goes to the project’s Github page. In that repo you’ll find an announcement from last year, that the founding developer is finished with the project, and is selling the rights to an unknown third party, who took over maintainership. If this sounds familiar, there are echoes of the event-stream debacle.
It’s not clear exactly what malicious behavior Google found that led to the extension being pulled, but a more careful look at the project reveals that there were potential problems as early as October of 2020. An addition to the extension introduced execution of code from a remote server, never a good idea. For what it’s worth, the original maintainer has made a statement, defending the new owners, and suggesting that this was all an innocent mistake.
The lesson here? It’s not enough to confirm that an extension checks the “open source” box. Make sure there is an active community, and that there isn’t a 6 month old bug report detailing potentially malicious activity.
Libgcrypt
It’s not everyday you see a developer sending out a notice that everyone should stop using his latest release. That’s exactly what happened with Libgcrypt 1.9.0. Our friends over at Google’s Project Zero discovered an extremely nasty vulnerability in the code. It’s a buffer overflow that happens during the decryption process, before even signature verification. Since libgcrypt is used in many PGP implementations, the ramifications could be nasty. Receive an encrypted email, and as soon as your client decrypts it, code is executing. Thankfully, an update that fixes the issue has already been released.
Android Botnet
A new botnet is targeting Android devices in a peculiar way — looking for open ADB debug ports exposed to the Internet. Google makes it very clear that ADB over the network is insecure, and should only be used for development purposes, and on controlled networks. It’s astounding that so many vendors ship hardware with this service exposed. Beyond that, it’s surprising that so many people give their Android devices public IP addresses (or IPv6 addresses that aren’t behind a firewall). The botnet, named Matryosh, has another unique feature, as it uses Tor for command and control functions, making it harder to track.
Google Solution to Open-Source Security
Google published a post on their open source blog, giving an overview for their new framework for the security of open source projects. “Know, Prevent, Fix” is their name for the new effort, and it must have been written by management, because it’s full of buzzwords. The most interesting elements are their goals for critical software. They identify problems like the ability of a single maintainer to push bad code into a project, and how anonymous maintainers is probably a bad idea. It will be interesting to see how these ideas develop, and how Google will help open source communities implement them.
Microsoft in My Pi
And finally, I was amused by an article lamenting the inclusion of the VSCode repository in the default Raspberry Pi OS images. He does raise a couple legitimate points. Amont them, you do send a ping to Microsoft’s servers every time you check for new updates.
The larger point is that the official VSCode binaries have telemetry code added to them — code that isn’t in the open source repository. What is it doing? You don’t know. But it probably violates European law.
Want to use VSCode, but not interested in shipping info off to Microsoft? VSCodium is a thing.
It may have been designed for a sewing machine, but [Haris Andrianakis] found his imported DC brushed motor was more than up to the challenge of powering his mini lathe. Of course there’s always room for improvement, so he set out to reverse engineer the motor’s controller to implement a few tweaks he had in mind. Unfortunately, things took an unexpected turn when plugging his AVR programmer into the board’s ISP socket not only released the dreaded Magic Smoke, but actually tripped the breaker and plunged his bench into darkness.
Studying how the Hall-effect sensors in the motor are wired.
Upon closer inspection, it turned out the board has no isolation between the high voltage side and its digital logic. When [Haris] connected his computer to it via the programmer, the 330 VDC coming from the controller’s rectifier shorted through the USB bus and tripped the Earth-leakage circuit breaker (ELCB). The good news is that his computer survived the ordeal, and even the board itself seemed intact. But the shock must have been too much for the microcontroller he was attempting to interface with, as the controller no longer functioned.
Now fully committed, [Haris] started mapping out the rest of the controller section by section. In the write-up on his blog, he visually masks off the various areas of the PCB so readers have an easier time following along and understanding how the schematics relate to the physical board. It’s a nice touch, and a trick worth keeping in mind during your own reverse engineering adventures.
In the end, [Haris] seems to have a good handle on what the majority of the components are up to on the board. Which is good, since getting it working again now means replacing the MCU and writing new firmware from scratch. Or perhaps he’ll just take the lessons learned from this controller and spin up his own custom hardware. In either event, we’ll be keeping an eye out for his next post on the subject.
Creating your own PC board is a rite of passage for many. These days, though, you can order super inexpensive boards and have them in very little time, so it doesn’t always make sense to build your own. Still, some people like the challenge, and others don’t want to wait even a few days. Probably everyone has dreamed of a 3D printer-like machine that would just crank out beautiful PCBs. The Voltera V-One isn’t quite at that level of sophistication, but it isn’t too far from it. [Great Scott] shows us how he built two different boards using the system in the video below. While the results were impressive, you can also see that there are several limitations, especially if you are not designing your board with the machine in mind.
One thing that is obvious is that the machine does need your help. In addition to aligning holes, you’ll need to install tiny rivets for vias and slightly less tiny rivets for through-hole components. The last time we looked at the machine, it didn’t do holes at all, but [Scott] shows the drill attachment which allows the machine to produce vias and support leaded components.
The system relies on interchangeable heads and conductive inks. Mechanically, it doesn’t differ much from a 3D printer. The ink, however, appears to be a little temperamental. On the first test board, one side did not cure properly since [Scott] forgot a step. While it looked fine, it had problems soldering. Because the traces are not copper, the machine comes with its own recommended solder, too.
The most interesting part, though, was when [Scott] tried to port an existing board into the system. He had to make several changes for things like copper fills and via hole sizes. Close spacing required some hand rework, so he probably should have spaced the traces wider in the design.
The printer isn’t cheap and the consumables are rather expensive, too. It is hard to justify the cost just to get fast prototypes that aren’t very representative of a final board. Keep in mind the conductive ink isn’t as conductive as copper and you don’t get niceties like solder mask or silk screening. If you had an active hacker space, a school, or a busy lab it might be worth it to get one-off boards. However, for prototyping production boards, it is unlikely that you’ll want to constrain your final design to the restrictions necessary for the printer. Besides, if you don’t mind waiting for boards — keeping in mind that you can pay to get boards made and shipped quickly if you don’t mind paying more — the breakeven point on the printer is very high.
On the other hand, 3D printers used to be expensive and now they are everywhere. The quality of 3D printing isn’t as good as some other production methods, but it still has a place. So if this technology improves a little and gets a lot cheaper, it could find its way to your workshop one day.
Back in 2015, we predicted that making your own PCBs was getting harder to justify. At the time, many people were unhappy with that prediction, but further decreases in the cost of having boards made for you continue to chip away at the value proposition of making your own boards. Sure, sometimes you just want to do something despite the economics — we’ve all done that. But it does make the economics of PCB printers even harder to work out.
It’s long been common wisdom that one of the safest places to keep your cryptocurrency holdings is in a hardware wallet. These are small, portable devices that encrypt your keys and offer a bit more piece of mind than holding your coins in a soft or web wallet.
But of course, as we know, nothing is totally secure.
It’s worth noting that the hack does require physical access to the wallet — albeit only about fifteen minutes worth. And by “physical access” we mean that the hack leaves the device thoroughly mutilated. The Kraken team started by desoldering the heart of the wallet, a STM32 processor. They then dropped it into a socket on an interface board, and got to glitching.
The hack relies on an attack known as voltage glitching. Essentially, at a precisely-timed moment during the device’s boot sequence, the supply voltage is fluctuated. This enables the chip’s factory bootloader, which can read out the contents of it’s onboard flash memory. The memory is read-protected, but can be accessed 256 bytes at a time through a second voltage glitch. Neither of these attacks work 100% of the time, so if the device fails to boot or the memory remains locked, the FPGA performing the attacks simply tries again. After enough iterations, the Kraken team was able to fully dump the chip’s flash memory.
There’s one more hurdle here — the memory dump is encrypted. Enter brute forcing. Trezor devices allow a maximum pin code length of nine digits, but if you assume the average user’s pin is only four digits then it can be guessed via an automated script in a matter of minutes. Even a longer pin can be worked out in a matter of days or weeks — certainly within the realm of possibility. This yields the seed, which could then be entered into a new hardware wallet to effectively steal any cryptocurrency assets that lived on the original device.
So, aside from some cool hardware hacking techniques, what can we learn from the Kraken Security Lab’s work? First up, for any designers out there, the STM32 is not suitable for high-security applications. For all the end users, this doesn’t mean you need to trash your Trezor (even though this isn’t the first wallet hack we’ve seen). It does mean that you should keep it away from other people, and that you should enable the BIP39 passphrase, which Kraken says can protect against the attack. Perhaps most importantly, this serves to remind us all that nothing is 100% secure.
It’s long been common wisdom that one of the safest places to keep your cryptocurrency holdings is in a hardware wallet. These are small, portable devices that encrypt your keys and offer a bit more piece of mind than holding your coins in a soft or web wallet.
But of course, as we know, nothing is totally secure.
It’s worth noting that the hack does require physical access to the wallet — albeit only about fifteen minutes worth. And by “physical access” we mean that the hack leaves the device thoroughly mutilated. The Kraken team started by desoldering the heart of the wallet, a STM32 processor. They then dropped it into a socket on an interface board, and got to glitching.
The hack relies on an attack known as voltage glitching. Essentially, at a precisely-timed moment during the device’s boot sequence, the supply voltage is fluctuated. This enables the chip’s factory bootloader, which can read out the contents of it’s onboard flash memory. The memory is read-protected, but can be accessed 256 bytes at a time through a second voltage glitch. Neither of these attacks work 100% of the time, so if the device fails to boot or the memory remains locked, the FPGA performing the attacks simply tries again. After enough iterations, the Kraken team was able to fully dump the chip’s flash memory.
There’s one more hurdle here — the memory dump is encrypted. Enter brute forcing. Trezor devices allow a maximum pin code length of nine digits, but if you assume the average user’s pin is only four digits then it can be guessed via an automated script in a matter of minutes. Even a longer pin can be worked out in a matter of days or weeks — certainly within the realm of possibility. This yields the seed, which could then be entered into a new hardware wallet to effectively steal any cryptocurrency assets that lived on the original device.
So, aside from some cool hardware hacking techniques, what can we learn from the Kraken Security Lab’s work? First up, for any designers out there, the STM32 is not suitable for high-security applications. For all the end users, this doesn’t mean you need to trash your Trezor (even though this isn’t the first wallet hack we’ve seen). It does mean that you should keep it away from other people, and that you should enable the BIP39 passphrase, which Kraken says can protect against the attack. Perhaps most importantly, this serves to remind us all that nothing is 100% secure.
It’s long been common wisdom that one of the safest places to keep your cryptocurrency holdings is in a hardware wallet. These are small, portable devices that encrypt your keys and offer a bit more piece of mind than holding your coins in a soft or web wallet.
But of course, as we know, nothing is totally secure.
It’s worth noting that the hack does require physical access to the wallet — albeit only about fifteen minutes worth. And by “physical access” we mean that the hack leaves the device thoroughly mutilated. The Kraken team started by desoldering the heart of the wallet, a STM32 processor. They then dropped it into a socket on an interface board, and got to glitching.
The hack relies on an attack known as voltage glitching. Essentially, at a precisely-timed moment during the device’s boot sequence, the supply voltage is fluctuated. This enables the chip’s factory bootloader, which can read out the contents of it’s onboard flash memory. The memory is read-protected, but can be accessed 256 bytes at a time through a second voltage glitch. Neither of these attacks work 100% of the time, so if the device fails to boot or the memory remains locked, the FPGA performing the attacks simply tries again. After enough iterations, the Kraken team was able to fully dump the chip’s flash memory.
There’s one more hurdle here — the memory dump is encrypted. Enter brute forcing. Trezor devices allow a maximum pin code length of nine digits, but if you assume the average user’s pin is only four digits then it can be guessed via an automated script in a matter of minutes. Even a longer pin can be worked out in a matter of days or weeks — certainly within the realm of possibility. This yields the seed, which could then be entered into a new hardware wallet to effectively steal any cryptocurrency assets that lived on the original device.
So, aside from some cool hardware hacking techniques, what can we learn from the Kraken Security Lab’s work? First up, for any designers out there, the STM32 is not suitable for high-security applications. For all the end users, this doesn’t mean you need to trash your Trezor (even though this isn’t the first wallet hack we’ve seen). It does mean that you should keep it away from other people, and that you should enable the BIP39 passphrase, which Kraken says can protect against the attack. Perhaps most importantly, this serves to remind us all that nothing is 100% secure.
When it comes to safely riding a bike around cars, the more lights, the better. Ideally, these lights would come on by themselves, so you don’t have to remember to turn them on and off every time. That’s exactly the idea behind [Jeremy Cook]’s latest build — it’s an automatic bike light that detects vibration and lights up some LEDs in response.
The build is pretty simple — a coin cell-powered ATtiny85 reads input from a spring vibration sensor and flashes the LEDs. This is meant to complement [Jeremy]’s primary bike light, which is manually operated and always on. We especially like that form follows function here — the board shape is designed to be zip-tied to the spokes so it’s as close to the action as possible. He cleverly used cardboard and a laser cutter to mock up a prototype for a board that fits between the spokes. Pretty cool for your second professionally-fabbed PCB ever, if you ask us. Ride past the break to check out the build video.
A few weeks ago, a video went viral on social media that depicted a rather unsavory individual receiving what could be described as a “percussive reminder” of social norms courtesy of a bystander armed with a can of Twisted Tea. The video served as inspiration for many a meme, but perhaps none more technically intricate than this air cannon that launches 24 ounces of hard iced tea at better than 100 miles per hour built by [Greg Bejtlich].
It’s all fun and games until somebody brings out the weaponized bead seater.
Technically we’re looking at two different hacks here. The first is the pneumatic launcher put together using a low-cost eBay tire bead seater. These tools are designed to unleash a large volume of air into a tire so it can be properly seated onto the rim, but it doesn’t take much more than a few pieces of PVC pipe from the hardware store to turn it into an impromptu mortar. It’s even got a convenient trigger and a handle to help control the recoil. Though as you can see in the video after the break, it still ends up being a bit too energetic for [Greg] to keep a grip on.
For the projectiles, [Greg] has 3D printed a nose cone and tail fin that snap onto the 24 oz cans in hopes of making them more aerodynamically stable. The slow motion video seems to indicate they aren’t terribly effective, but they certainly look impressive. Spring-loaded control surfaces that deploy after the can leaves the muzzle could be the answer, though at some point you have to ask yourself how far you’re willing to go for an Internet meme.
We have to admit that in the hardware hacking universe, there aren’t generally too many chances to hack elevators. Well, at least not opportunities that don’t also include the risk of incarceration. But fortune favors the bold, and when he found the remains of an elevator control panel in an abandoned Croatian resort hotel, [Davor Cihlar] undertook an extensive and instructive reverse-engineering of the panel.
The video below highlights his efforts, which were considerable given the age and state of the panel. This is a relay-only control panel, after all, with most of the relays missing and a rat’s nest of wires connecting the sockets. So [Davor] put his “RevIng” concept to work. This uses a custom PCB with a microcontroller on-board that plugs into each relay socket and probes the connections between it and every other socket. Very clever stuff, and it presented him with the data needed to develop a ladder-logic diagram of the board, with the help of some custom software.
With the original logic in hand, [Davor] set about building a simulator for the panel. It’s a lovely piece of work, with buttons and lights to mimic the control panel inside the elevator car, as well as the call stations that would have graced each lobby of the hotel. Interestingly, he found logic that prevented the elevator from being called to some floors from anywhere but inside the car. The reason remains a mystery, but we suppose that a hotel built by Penthouse publisher [Bob Guccione] would have plenty of secrets.
We love the supremely satisfying clickiness of this build, and the reverse engineering prowess on display, but we can’t find much practical use for something like this. Then again, DIY elevators are a thing.
In 2018, when KiCad Version 5 modernized the venerable 4.X series, it helped push KiCad to become the stable and productive member of the open source EDA landscape that we know today. It has supported users through board designs both simple and complex, and like a tool whose handle is worn into a perfect grip, it has become familiar and comfortable. For those KiCad users that don’t live on the bleeding edge with nightly builds it may not be obvious that the time of version 6 is nearly upon us, but as we start 2021 it rapidly approaches. Earlier this month [Peter Dalmaris] published a preview of the changes coming version 6 and we have to admit, this is shaping up to be a very substantial release.
Don’t be mistaken, this blog post may be a preview of new KiCad features but the post itself is extensive in its coverage. We haven’t spent time playing with this release yet so we can’t vouch for completeness, but with a printed length of nearly 100 pages it’s hard to imagine [Peter] left anything out! We skimmed through the post to extract a few choice morsels for reproduction here, but obviously take a look at the source if you’re as excited as we are.
There’s No Place Like (0, 0)
The mythical hatched fill
Starting with the foundation, KiCad 6 will finally bring a configurable coordinate system! We’ve found that a significant stumbling block for new users is that the default KiCad coordinates start at the upper left instead of the lower left, as in most CAD and drawing tools.
Version 6 will allow the user to relocate the origin as well as flip either axis, allowing for maximum ordinal freedom. Clearly it doesn’t take much to get us excited, does it?
Rounding Traces and Filling Zones, Mostly
Another historically missing feature in KiCad is curved traces. V6 moves part of the way there, allowing traces to have rounded fillets. This doesn’t quite get to the groovy curvy traces of the 70s but it’s progress in the right direction.
Along similar lines there is new variety in the way a zone can be filled. Now instead of being forced into a solid fill there is a second choice; hatched fill! We say the more the merrier! Next stop; hearts, stars and horseshoes?
Getting Together with Groups
A flock of grouped components in layout
It may seem minor, but should be appreciated by anyone who has worked with carefully arranged groups of components during layout; items can be grouped! It’s always been possible to select multiple elements and drag them together, but that grouping was lost as soon as the selection changed. In KiCad 6 components can be explicitly grouped, allowing you to move those pesky headers around all at once, in perpetuity.
Bussing in the Signals
Even after using version 5 for years, signal busses in KiCad schematics seemed like an ugly duckling with a usage so awkward that they weren’t worth using. [Peter]’s overview has taught us a few new things about that older tool that we didn’t know under the rubric “enhanced bus handling”. For instance, the older version 5 allows the user to textually specify net names to connect across a bus instead of forcing the use of bus entry connections and individual net labels.
Version 6 makes busses significantly more powerful. It’s now possible to specify more elaborate and less uniform net names that share a single bus, and there are graphical hooks in context menus that allow you to “unfold” individual nets from the bus without the guesswork required in version 5. And as an added bonus, in version 6 the visual style of busses can be changed. We’re excited to start getting our signals together!
That’s Not All Folks
Whew, what a list! And that was but a tiny fraction of the improvements in KiCad 6, or the coverage from [Peter]’s excellent post.
It’s worth noting that the post is based on nightly builds euphemistically versioned 5.99. Until the release is officially cut, features and functionality are subject to change, but everything is publicly available to try out in the nightly builds if something catches your eye.
Considering the state of well, everything, we can’t tell you how glad we are to be out of school. That goes double for not being a teacher these days. [Elena] had some awesome light-up tactile buttons set aside for a killer Kerbal Space Program controller, but it’s funny how a pandemic will change your priorities. Instead, those buttons found a good home in this colorful and enticing Zoom control panel.
[Elena]’s ready pile of Arduinos yielded no Leonardos or Pro Micros, but that’s okay because there’s a handy bootloader out there that allows you to reprogram the USB interface chip of an Uno or a Mega and use it as a keyboard. After setting that up, it was mostly a matter of wiring all those latching and momentary buttons and LEDs to the Mega and making them look fantastic with a set of icons. (We all know the big red mushroom button is for aborting the call; so does it really need an icon?)
By now we’re all used to the requirements imposed by the pandemic, of social distancing and wearing masks indoors. But as [polyfloyd] and the rest of the board at Bitlair hackerspace in Amersfoort in the Netherlands were concerned, there are still risk factors to consider when inside a building. Without fresh air the concentration of virus-bearing droplets can increase, and the best way they could think of to monitor this was to install a set of CO2 sensors. To run them they didn’t need to buy any new hardware, instead they turned to a set of event badges, from 2017s SHA hacker camp.
This badge sported an ESP32 module with an e-ink screen, and of most interest for this project it still has a supported software platform and comes with a handy expansion connector on the rear. The commonly-available MH-Z19 infra-red CO2 sensor and BME280 humidity sensor fit on a PCB that follows the shape of the badge with a protrusion at the top on which they appear as an integrated unit. Processing those readings is a MicroPython badge app that issues warnings via MQTT and plots a CO2 graph on the screen. Everything is available, both the hardware in a GitHub repository and the software as a badge.team app.
We applaud anyone who makes use of an event badge for a project, and especially so for using one years after the event. The SHA badge and its descendants are uniquely suited to this through their well-supported platform, so if you have one in a drawer we’d urge you to pull it out and give it a try.
By and large, alarm clocks (including phones that double as alarm clocks) are annoyingly alarming. If it’s not the light or the sound, it’s both. Yes, we know that’s the point of an alarm clock, but sometimes life presents opportunities to check the time and/or the weather and sleep in a little bit longer based on the result. We don’t know about you, but loud noises and eye-blasting light are not conducive to getting back to sleep, especially if you’re a light sleeper.
In [Stavros Korokithakis]’ case, if it’s a tennis practice morning but it’s raining, then it’s no longer a tennis practice morning and he can go back to sleep for a while. A phone seems perfect for this, but the problem is that it provides too much information: the phone can’t check the weather without the internet, and once it has internet access, a bunch of eye-opening notifications come flooding in.
[Stavros] had a long list of must-haves when it came to building the ultimate alarm clock, and we can totally get behind that. He needed something smarter than the average off-the-shelf clock radio, but nothing too smart. Enter the ESP8266. As long as it has an internet connection, it can fetch the time and the weather, which is really all that [Stavros] needs. It gets the current temperature, wind speed, and forecast for the next two hours with the OpenWeather API, and this information is converted to icons that are easy to read at a sleepy, one-eyed glance at the OLED.
Adaptive brightness was high on the list of must-haves, which [Stavros] solved by adding a photoresistor to judge the ambient light and adjust the OLED screen brightness appropriately. And he really did think of everything — the octagonal shape allows for the perfect angle for reading from bed. There’s just one problem — it can’t accept input, so it doesn’t actually function as an alarm clock. But it makes a damn good bedside clock if you ask us.
To get its engineers thinking about design for assembly back in the 1980s, Westinghouse made a video about a product optimized for assembly: the IBM Proprinter. The technology may be dated, but the film presents a great look at how companies designed not only for manufacturing, but also for ease of assembly.
It’s not clear whether Westinghouse and IBM collaborated on the project, but given the inside knowledge of the dot-matrix printer’s assembly, it seems like they did. The first few minutes are occupied by an unidentified Westinghouse executive talking about design for assembly in general terms, and how it impacts the bottom line. Skip ahead to 3:41 if talking suits aren’t your thing.
Once the engineer gets going on the printer, though, things get really interesting. The printer’s guts are laid out before him, ready to be assembled. What’s notably absent from the table are tools — the Proprinter was so well designed that the only tool needed is a pair of human hands. And they don’t have to be particularly dexterous hands, either — the design favors motions that are straight down, letting gravity assist the assembly process and preventing assemblers from the need to contort their bodies. Almost everything is held in place by compliant mechanisms built into the plastic parts. There are a few gems in the film, like the plastic lead screw that drives the printhead, obviating the need to string a fussy timing belt, or the unique roller that twists to lock onto a long shaft, rather than having to be pushed to its center.
We found this film which we’ve placed below the break to be very instructive, and the fact that a device as complex as a printer can be assembled in just a few minutes without picking up a single tool is pretty illustrative of the power of designing for assembly. Slick designs that can’t be manufactured at scale are all too common in this age of powerful design tools and desktop manufacturing, so these lessons from the past might be worth relearning.
We’ve all seen those tiny little RC cars that can climb walls thanks to the suction generated with fans. Their principle is essentially the opposite to that of a hovercraft. [Engineering After Hours] wanted to build his own RC car that could do the same, driving upside down and generating huge amounts of grip.
The build is based on a Traxxas RC car, but heavily modified for the task. An undertray is crafted, with ducts feeding a pair of twin 50mm electric fans. A skirt is fitted around the edge of the undertray, helping create a seal to maximise the downforce generated. This skirt is the area of much engineering effort, as it must form a good seal with the ground, particularly over minor pertubations, without creating undue levels of friction. Suspension components correspondingly need to be beefed up to stop the car bottoming out with the huge downforce generated by the fan system.
After much experimentation, the kinks are worked out, and the car is able to drive upside down successfully. It generates far more downforce than earlier wing experiments from [Engineering After Hours], as expected – with a tradeoff of higher weight and complexity. With the plan to create an RC car capable of huge lateral acceleration, we can’t wait to see what comes next. Video after the break.
A reality of flying RC aircraft is that at some point, one of your birds is going to fall in the line of duty. It could get lost in the clouds never to be seen again, or perhaps it will become suddenly reacquainted with terra firma. Whatever the reason, your overall enjoyment of the hobby depends greatly on how well you can adapt to the occasional loss.
Based on what we’ve seen so far, we’d say [Rural Flyer] has the right temperament for the job. After losing one of his quadcopters in an unfortunate FPV incident, he decided to repurpose the proprietary gimbal it left behind. If he still had the drone he could have slipped a logic analyzer in between its connection with the motorized camera to sniff out the communication protocol, but since that was no longer an option, he had to get a little creative.
Figuring out the power side of things was easy enough thanks to the silkscreen on the camera’s board, and a common 5 V battery eliminator circuit (BEC) connected to the drone’s 7.4 V battery pack got it online. A cobbled together adapter allowed him to mount it to one of his other quads, but unfortunately the angle wasn’t quite right.
[Rural Flyer] wanted the camera tilted down about 15 degrees, but since he didn’t know how to talk to it, he employed a clever brute force solution. After identifying the accelerometer board responsible for determining the camera’s position, he use a glob of hot glue to push the sensor off of the horizontal. Providing this physical offset to the sensor data caused the camera to automatically move itself to exactly where he wanted it.
In the video after the break, you can see the hacked up gimbal seems to perform admirably when attached to its new mothership. Using the original drone’s smartphone application, [Rural Flyer] is able to view the live stream and record the action. Thanks to the new antenna he whipped up for the transmitter, it sounds like he’s even improved things compared to the stock hardware.
Have a rusty collection of protoboards wired together that would benefit from mechanical support? Working on putting together a robot and need to attach PCBAs without drilling holes, zipping a cable tie, or globing hot glue? Add some stud holes with [James Munns]’ Brick Mount! This isn’t the first time we’ve seen an interface between everyone’s favorite Nordic building system and circuitboards, but this implementation has the elegance we’ve come to expect from [James]’ software work.
4×8 Feather Medium protoboard
The project repository contains two things: a KiCad library with components for holes in standard patterns and sizes (1×1, 1×2, etc) and a series of protoboards made with those hole components. The protoboards feature a couple common elements; QUIIC connectors for easy chaining between them and holes in the middle or edges for easy mounting on studs. Some are intended to be carriers for Feather-format PCBAs (very convenient!) and others are primarily undifferentiated prototyping space. Of particular note is the “medium” Feather breakout seen to the left, which incorporates clever cutouts to make it easy to wires down under the board so it can be mounted flush against another board.
The thesis here is that getting custom PCBs fabricated is easier and less expensive than ever before. So easy and inexpensive that fabricating customized protoboard to use in one-off projects is cost-efficient enough to be worthwhile. Waste concerns aside this does seem like a great way to level up those temporary projects which find a more permanent home.
PCI Express (PCIe) has been around since 2003, and in that time it has managed to become the primary data interconnect for not only expansion cards, but also high-speed external devices. What also makes PCIe interesting is that it replaces the widespread use of parallel buses with serial links. Instead of having a bus with a common medium (traces) to which multiple devices connect, PCIe uses a root complex that directly connects to PCIe end points.
This is similar to how Ethernet originally used a bus configuration, with a common backbone (coax cable), but modern Ethernet (starting in the 90s) moved to a point-to-point configuration, assisted by switches to allow for dynamic switching between which points (devices) are connected. PCIe also offers the ability to add switches which allows more than one PCIe end point (a device or part of a device) to share a PCIe link (called a ‘lane’).
This change from a parallel bus to serial links simplifies the topology a lot compared to ISA or PCI where communication time had to be shared with other PCI devices on the bus and only half-duplex operation was possible. The ability to bundle multiple lanes to provide less or more bandwidth to specific ports or devices has meant that there was no need for a specialized graphics card slot, using e.g. an x16 PCIe slot with 16 lanes. It does however mean we’re using serial links that run at many GHz and must be implmented as differential pairs to protect signal integrity.
This all may seem a bit beyond the means of the average hobbyist, but there are still ways to have fun with PCIe hacking even if they do not involve breadboarding 7400-logic chips and debugging with a 100 MHz budget oscilloscope, like with ISA buses.
High Clocks Demand Differential Pairs
PCIe version 1.0 increases the maximum transfer rate when compared to 32-bit PCI from 133 MB/s to 250 MB/s. This is roughly the same as a PCI-X 64-bit connection (at 133 MHz) if four lanes are used (~1,064 MB/s). Here the PCIe lanes are clocked at 2.5 GHz, with differential signaling send/receive pairs within each lane for full-duplex operation.
Today, PCIe 4 is slowly becoming adopted as more and more systems are upgraded. This version of the standard runs at 16 GHz, and the already released PCIe version 5 is clocked at 32 GHz. Although this means a lot of bandwidth (>31 GB/s for an x16 PCIe 4 link), it comes with the cost of generating these rapid transitions, keeping these data links full, and keeping the data intact for more than a few millimeters. That requires a few interesting technologies, primarily differential signaling and SerDes.
Basic visualization of how differential signaling works.
Differential signaling is commonly used in many communication protocols, including RS-422, IEA-485, Ethernet (via twisted-pair wiring), DisplayPort, HDMI and USB, as well as on PCBs, where the connection between the Ethernet PHY and magnetics is implemented as differential pairs. Each side of the pair conducts the same signal, just with one side having the inverted signal. Both sides have the same impedance, and are affected similarly by (electromagnetic) noise in the environment. As a result, when the receiver flips the inverted signal back and merges the two signals, noise in the signal will become inverted on one side (negative amplitude) and thus cancel out the noise on the non-inverted side.
The move towards lower signal voltages (in the form of LVDS) in these protocols and the increasing clock speeds makes the use of differential pairs essential. Fortunately they are not extremely hard to implement on, say, a custom PCB design. The hard work of ensuring that the traces in a differential pair have the same length is made easier by common EDA tools (including KiCad, Autodesk Eagle, and Altium) thatl provide functionality for making the routing of differential pairs a semi-automated affair.
Having It Both Ways: SerDes
Schematic diagram of a SerDes link.
A Serializer/Deserializer (SerDes) is a functional block that is used to convert between serial data and parallel interfaces. Inside an FPGA or communications ASIC the data is usually transferred on a parallel interface, with the parallel data being passed into the SerDes block, where it is serialized for transmission or vice-versa. The PCIe PMA (physical media attachment) layer is the part of the protocol’s physical layer where SerDes in PCIe is located. The exact SerDes implementation differs per ASIC vendor, but their basic functionality is generally the same.
When it comes to producing your own PCIe hardware, an easy way to get started is to use an FPGA with SerDes blocks. One still needs to load the FPGA with a design that includes the actual PCIe data link and transaction layers, but these are often available for free, such as with Xilinx FPGAs.
PCIe HDL Cores
Recent Xilinx FPGAs not only integrate SerDes and PCIe end-point features, but Xilinx also provides free-as-in-beer PCIe IP blocks (limited to x8 at PCIe v2.1) for use with these hardware features that (based on the license) can be used commercially. If one wishes for a slightly less proprietary solution, there are Open Source PCIe cores available as well, such as this PCIe Mini project that was tested on a Spartan 6 FPGA on real hardware and provides a PCIe-to-Wishbone bridge, along with its successor project, which targets Kintex Ultrascale+ FPGAs.
On the other sides of the fence, the Intel (formerly Altera) IP page seems to strongly hint at giving their salesperson a call for a personalized quote. Similarly, Lattice has their sales people standing by to take your call for their amazing PCIe IP blocks. Here one can definitely see the issue with a protocol like PCIe: unlike ISA or PCI devices which could be cobbled together with a handful of 74xx logic chips and the occasional microcontroller or CPLD, PCIe requires fairly specialized hardware.
Even if one buys the physical hardware (e.g. FPGA), use of the SerDes hardware blocks with PCIe functionality may still require a purchase or continuous license (e.g. for the toolchain) depending on the chosen solution. At the moment it seems that Xilinx FPGAs are the ‘go-to’ solution here, but this may change in the future.
Also of note here is that the PCIe protocol itself is officially available to members of PCI-SIG. This complicates an already massive undertaking if one wanted to implement the gargantuan PCIe specification from scratch, and makes it even more admirable that there are Open Source HDL cores at all for PCIe.
Putting it Together
PCI Express x1 edge connector drawing with pin numbers.
The basic board design for a PCIe PCB is highly reminiscent of that of PCI cards. Both use an edge connector with a similar layout. PCIe edge connectors are 1.6 mm thick, use a 1.0 mm pitch (compared to 1.27 mm for PCI), a 1.4 mm spacing between the contact fingers and the same 20° chamfer angle as PCI edge connectors. A connector has at least 36 pins, but can have 164 pins in an x16 slot configuration.
PCIe card edge connector cross section.
An important distinction with PCIe is that there is no fixed length of the edge connector, as with ISA, PCI and similar interfaces. Those have a length that’s defined by the width of the bus. In the case of PCIe, there is no bus, so instead we get the ‘core’ connector pin-out with a single lane (x1 connector). To this single lane additional ‘blocks’ can be added, each adding another lane that gets bonded so that the bandwidth of all connected lanes can be used by a single device.
In addition to regular PCIe cards, one can also pick from a range of different PCIe devices, such as Mini-PCIe. Whatever form factor one chooses, the basic circuitry does not change.
This raises the interesting question of what kind of speeds your PCIe device will require. On one hand more bandwidth is nice, on the other hand it also requires more SerDes channels, and not all PCIe slots allow for every card to be installed. While any card of any configuration (x1, x4, x8 or x16) will fit and work in an x16 slot (mechanical), smaller slots may not physically allow a larger card to fit. Some connectors have an ‘open-ended’ configuration, where you can fit for example an x16 card into an x1 slot if so inclined. Other connectors can be ‘modded’ to allow such larger cards to fit unless warranty is a concern.
The flexibility of PCIe means that the bandwidth scales along with the number of bonded lanes as well as the PCIe protocol version. This allows for graceful degradation, where if, say, a PCIe 3.0 card is inserted into a slot that is capable of only PCIe 1.0, the card will still be recognized and work. The available bandwidth will be severely reduced, which may be an issue for the card in question. The same is true with available PCIe lanes, bringing to mind the story of cryptocoin miners who split up x16 PCIe slots into 16 x1 slots, so that they could run an equal number of GPUs or specialized cryptocoin mining cards.
It’s Full of PCIe
This flexibility of PCIe has also led to PCIe lanes being routed out to strange and wonderful new places. Specifications like Intel’s Thunderbolt (now USB 4) include room for multiple lanes of PCIe 3.0, which enables fast external storage solutions as well as external video cards that work as well as internal ones.
Solid-state storage has moved over from the SATA protocol to NVMe, which essentially defines a storage device that is directly attached to the PCIe controller. This change has allowed NVMe storage devices to be installed or even directly integrated on the main logic board.
Clearly PCIe is the thing to look out for these days. We have even seen that System-on-Chips (SoCs), such as those found on Raspberry Pi 4 boards now come with a single PCIe lane that has already been hacked to expand those boards in ways thought inconceivable. As PCIe becomes more pervasive, this seems like a good time to become more acquainted with it.
The video that you can find below the break is a long and detailed one, but in that detail lies touches that set the conversion apart from the norm. We’re treated to a full-run-down of USB-PD module design and chip programming, and then the mechanics of the 1-wire chip through which the Dell ties itself in with only Dell power supplies. Programming this chip in particular is something of a challenge.
It’s the mechanical design that sets this one apart. He started with an odd-shaped space that had contained the barrel jack socket and a ferrite choke, and designed a PCB to fit it exactly. 3D-printing a model to check for fit is attention to detail at the stratospheric level. The result is a fit that looks almost as though it was part of the original manufacture, and which should keep the laptop useful for years to come.
