[Bwack] had some scanned pictures of an old Commodore card and wanted to recreate PC boards from it. It’s true that he could have just manually redrawn everything in a CAD package, but that’s tedious. Instead, he used SprintLayout 6.0 which allows you to import pictures and use them as a guide for recreating a PCB layout.
You can see the entire process including straightening the original scans. There are tools that make it very easy to place new structures over the original scanned images.
[Ben Cox] found some interesting USB devices on eBay. The Epiphan VGA2USB LR accepts VGA video on one end and presents it as a USB webcam-like video signal on the other. Never have to haul a VGA monitor out again? Sounds good to us! The devices are old and abandoned hardware, but they do claim Linux support, so one BUY button mash later and [Ben] was waiting patiently for them in the mail.
But when they did arrive, the devices didn’t enumerate as a USB UVC video device as expected. The vendor has a custom driver, support for which ended in Linux 4.9 — meaning none of [Ben]’s machines would run it. By now [Ben] was curious about how all this worked and began digging, aiming to create a userspace driver for the device. He was successful, and with his usual detail [Ben] explains not only the process he followed to troubleshoot the problem but also how these devices (and his driver) work. Skip to the end of the project page for the summary, but the whole thing is worth a read.
The resulting driver is not optimized, but will do about 7 fps. [Ben] even rigged up a small web server inside the driver to present a simple interface for the video in a pinch. It can even record its output to a video file, which is awfully handy. The code is available on his GitHub repository, so give it a look and maybe head to eBay for a bit of bargain-hunting of your own.
Software Defined Radio (SDR) is a great technology, but there’s something so satisfying about spinning a physical knob to cruise the airwaves. Wanting to restore that tactile experience, [Tysonpower] purchased a cheap USB volume knob and set out to get it working with his software. Unfortunately, getting it up and running took a lot more work than you’re probably expecting.
After verifying that the knob worked for volume control on his computer, [Tysonpower] decided to try and pull the firmware from the device’s STM32 microcontroller. Unfortunately, this is where things got tricky. It turned out the chip had Code Protection enabled, so when it was wired up to a programmer and put into DFU mode, the firmware got wiped. Oops.
That left [Tysonpower] with no choice but to write a new firmware from scratch, which naturally required reverse engineering the device’s hardware. Step one was reading up on STM32 development and getting the toolchain working, which paved the way to getting the knob’s LED to blink. A couple more hours worth of work and some multimeter poking later, and he was able to read the knob’s movement. He describes getting USB HID working as a nightmare due to lack of documentation, but eventually he got that sorted out as well.
The end result is a firmware allows the volume knob to mimic a mouse scroll wheel, which can be used for tuning in many SDR packages. But we think the real success story is the experience [Tysonpower] gained with reverse engineering and working with the STM32 platform. After all, sometimes the journey is just as important as the end result. Continue reading “Software Defined Radio Gets Physical Control”
When his makerspace was gifted a pair of Luminator LED signs of the sort you might see on the front of a bus, [PWalsh] decided to pull one apart to see what made it tick. Along the way, he managed to reverse engineer its control protocol and replace its original control board with a WiFi-connected Raspberry Pi. Now they can use the LED signs to show whatever they want; no bus required.
As they were designed for automotive use, the signs were wired for 12 volts DC. So the first order of business was fitting it with an AC/DC converter so it could be plugged into the wall. After he measured the display’s current consumption, [PWalsh] estimated it’s maximum energy consumption and determined an old ATX computer power supply was more than up to the task.
With the sign happily running battery-free, he could begin figuring out how to talk to it. Noticing a MAX485 RS-485 converter on the PCB, gave a pretty good idea of what language it was speaking, and with the aid of his trusty oscilloscope, he was able to suss out the baud rate. A cheap USB to RS-485 converter was then wired in between the sign and its control board so he could sniff the data passing over the line.
From there, the final piece of the puzzle was studying the captured data and figuring out the protocol. [PWalsh] was able to identify packet headers and ASCII characters, and pretty soon knew enough about how the sign communicated that he was able to remove the control board entirely and just push text and images to it right from the Pi. He’s even made his framework available for anyone else who might have a similar piece of bus-signage laying around.
Even if you’re not looking to add one of these signs to your lab, this project is a fantastic example of protocol reverse engineering with low-cost tools and simple techniques. We always love to see the process broken down step by step like this, and our hat’s off to [PWalsh] for delivering the goods in a big way.
This isn’t the first time we’ve seen these sort of LED signs get the “Internet of Things” treatment, and if you’re content with a somewhat scaled down version, you could always just build your own display rather than waiting on the local public transit vehicle to get parted out.
[Andrew] had a servo damaged by someone connecting the power supply to the wrong pins (whoops) which fried the microcontroller and a logic level shifter. With a bit of reverse engineering, he successfully restored basic servo functionality by writing some new code. The new code implements only basic features, but that’s enough to save the device from the junk bin.
Why bother reverse engineering a servo? Well, if dollars are reasons then there are many for saving a HerkuleX DRS-0602 from the junk heap; they cost around 320 USD before shipping. Another reason to try is that the microcontroller turned out to be an AVR XMega, which gave [Andrew] confidence in writing some new code.
If you want to understand more about how these servos work, [Andrew] provides good photos of the insides and identifies the major components and their connections and functions. There are some mysteries (such as details of the motor and embedded encoder, which are FAULHABER 2232DBHHO) but [Andrew] figured out enough to write some basic code to allow the servo to work as a standard servo with a UART interface.
Sometimes curiosity drives reverse engineering and repair efforts, sometimes it’s cost, and sometimes it’s both. A $320 servo is certainly worth trying to save, and so are huge observatory telescopes with obsolete servo amps.
You’ve probably seen a few of these miniature arcade games online or in big box retailers: for $20 USD or so you get scaled-down version of a classic arcade cabinet, perfect for a desk toy or to throw up on a shelf as part of your gaming collection. Like any good Hackaday reader, you were probably curious about what makes them tick. Thanks to [wrongbaud], we don’t have to wonder anymore.
Over the course of several blog posts, [wrongbaud] walks readers through the hardware and software used in a few of these miniature games. For example, the Rampage cabinet is using a so-called “NES on a Chip” along with a SPI flash chip to hold the ROM, while Mortal Kombat is using a Genesis emulation solution and parallel flash. It wouldn’t be interesting if they didn’t throw you a few curves now and again, right?
But these are more than simple teardowns. Once [wrongbaud] gives an overview of the hardware, the next step is reading the respective flash storage and trying to make sense of the dumped data. These sort of games generally reuse the hardware among a number of titles, so by isolating where the game ROM is and replacing it, they can be made to play other games without hardware modification. Here, this capability is demonstrated by replacing the ROM data for Rampage with Yoshi’s Cookie. Naturally it’s one of those things that’s easier said than done, but it’s an interesting proof of concept.
The Mortal Kombat cabinet is a newer addition to the collection, so [wrongbaud] hasn’t progressed quite as far with that one. The parallel flash chip has been dumped with the help of an ESP32 and a MCP23017 I/O expander, and some Genesis ROM headers are identifiable in the data, but there’s still some sifting to be done before the firmware structure can be fully understood.
Even if you’re not in the market for a diminutive arcade experience, the information that [wrongbaud] has collected here is really phenomenal. From understanding protocols such as I2C and SPI to navigating firmware dumps with a hex editor, these posts are an invaluable resource for anyone looking to get started with reverse engineering.
Like many creative individuals who suddenly find themselves parents, [Marta] wanted to make something special for his children to play with. Anybody can just purchase an off-the-shelf electronic toy, but if you’ve got the ability to design one on your own terms, why not do it? But even compared to the fairly high standards set by hacker parents, we have to admit that the amount of time, thought, and effort that was put into the “Marta Musik Maschine” is absolutely phenomenal.
[Marta] was inspired by the various commercial offerings which use RFID and other technologies to identify which characters the child is playing with and respond accordingly. But since he didn’t want to get locked into one particular company’s ecosystem and tinkering with the toys seemed frowned upon by their creators, he decided to just come up with his own version.
Over the course of many posts on the Musik Maschine’s dedicated website, [Marta] explains his thought process for every design consideration of the toy in absolutely exquisite detail. Each of the writeups, which have helpfully been broken down for each sub-system of the final toy, are arguably detailed and complete enough to stand as their own individual projects. Even if you’re not looking to get into the world of DIY electronic toys, there’s almost certainly an individual post here which you’ll find fascinating. From the finer points of interfacing your Python code with arcade buttons to tips for designing 3D printed enclosures, there’s really something for everyone here.
The children of hackers are often the envy of the neighborhood thanks to the one-of-a-kind playthings provided by their parents, and considering the level of commitment [Marta] has put into a toddler toy, we can’t wait to see what he comes up with next.
Continue reading “Why Buy Toys When You Can Build Them Instead?”
