If you’ve ever bought a modchip that adds features to your game console, you might have noticed sanded-off IC markings, epoxy blobs, or just obscure chips with unknown source code. It’s ironic – these modchips are a shining example of hacking, and yet they don’t represent hacking culture one bit. Usually, they are more of a black box than the console they’re tapping into. This problem has plagued the original XBOX hacking community, having them rely on inconsistent suppliers of obscure boards that would regularly fall off the radar as each crucial part went to end of life. Now, a group of hackers have come up with a solution, and [Macho Nacho Productions] on YouTube tells us its story – it’s an open-source modchip with an open firmware, ModXO.
Like many modern modchips and adapters, ModXO is based on an RP2040, and it’s got a lot of potential – it already works for feeding a BIOS to your console, it’s quite easy to install, and it’s only going to get better. [Macho Nacho Productions] shows us the modchip install process in the video, tells us about the hackers involved, and gives us a sneak peek at the upcoming features, including, possibly, support for the Prometheos project that equips your Xbox with an entire service menu. Plus, with open-source firmware and hardware, you can add tons more flashy and useful stuff, like small LCD/OLED screens for status display and LED strips of all sorts!
If you’re looking to add a modchip to your OG XBOX, it looks like the proprietary options aren’t much worth considering anymore. XBOX hacking has a strong community behind it for historical reasons and has spawned entire projects like XBMC that outgrew the community. There’s even an amazing book about how its security got hacked. If you would like to read it, it’s free and worth your time. As for open-source modchips, they rule, and it’s not the first one we see [Macho Nacho Productions] tell us about – here’s an open GameCube modchip that shook the scene, also with a RP2040!
Did you know you can get a “smart bed” that tracks your sleep, breathing, heart rate, and even regulates the temperature of the mattress? No? Well, you can get root access to one, too, as [Dillan] shows, and if you’re lucky, find a phone-home backdoor-like connection. The backstory to this hack is pretty interesting, too!
You see, a Sleep Number bed requires a network connection for its smart features, with no local option offered. Not to worry — [Dillan] wrote a Homebridge plugin that’d talk the cloud API, so you could at least meaningfully work with the bed data. However, the plugin got popular, Sleep Number didn’t expect the API to be that popular. When they discovered the plugin, they asked that it be shut down. Tech-inclined customers are not to be discouraged, of course.
Taking a closer look at the hardware, [Dillan] found a UART connection and dumped the flash, then wrote an extensive tutorial on how to tap into your bed’s controller, which runs Linux, and add a service you can use locally to query bed data and control the bed – just like it should have been from the beginning. Aside from that, he’s found a way to connect this hub to a network without using Sleep Number’s tools, enabling fully featured third-party use – something that the company doesn’t seem to like. Another thing he’s found is a reverse SSH tunnel back into the Sleep Number network.
Now, it can be reasonable to have a phone-home tunnel, but that doesn’t mean you want it in your personal network, and it does expose a threat surface that might be exploited in the future, which is why you might want to know about it. Perhaps you’d like to use Bluetooth instead of WiFi. Having this local option is good for several reasons. For example, having your smart devices rely on the manufacturer’s server is a practicethatregularlyresultsinperma-brickedsmartdevices, though we’ve been seeing someexamples of dedicated hackers bringing devices back to life. Thanks to this hack, once Sleep Number shutters, is bought out, or just wants to move on, their customers won’t be left with a suddenly dumbed-down bed they can no longer control.
Over the last few years, it’s been increasingly common for concertgoers to be handed a light-up bracelet from PixMob that synchronizes with the others in the crowd to turn the entire audience into a music visualizer. They’re a clever way of enhancing the concert experience, but unfortunately, they don’t do anything once you leave the show. Or at least, that used to be the case.
We’ve seen efforts to reverse engineer the IR (and occasionally radio) signals that drive these PixMob devices, but since we checked in last it seems like things have gotten a lot easier for the home gamer. [David Pride] has recently posted a brief write-up that shows how quickly and easily it is to get these devices fired up using nothing more exotic than an Arduino, an IR LED, and an audio sensor module.
With the audio sensor module connected to the Arduino’s digital input and the IR LED wired to digital out, all you need to do is flash firmware to the board and start playing some beats. The source code [David] has provided is a a remixed version of what’s previously been published by [Carlos Ganoza], which, in this case, has been tweaked to make the lighting patterns less random.
Presumably, this is to make the devices behave more like they do during an actual concert, but since nobody at Hackaday is cool enough to have seen a live musical performance in the last decade, we’re not really sure. All we can say is that the effect looks pretty sweet in the demo video.
Back in 2019, we saw a teardown of an early PixMob device, and by 2022, the efforts to reverse engineer their IR control protocol were well underway. We’re glad to see things have progressed to the point that you can piece together a transmitter from what’s in the parts bin, as it means at least some of these devices will have a lifespan longer than a single concert.
[Poking Technology] doesn’t think much of his new smartwatch. It is, by his admission, the cheapest possible smartwatch, coming in at about $3. It has very few useful features but he has figured out how to port MicroPython to it, so for a wrist-mounted development board with BLE, it might be useful. You can check it out in the video below.
The first step is a teardown, which reveals surprisingly little on the inside. There’s a tiny battery, a few connections, a display, and a tiny CPU board. There are, luckily, a few test pads that let you get into the CPU. What do you get? A 24 MHz Telink CPU with 512k of flash and 16k of RAM, along with all the other hardware.
Of course, even if you just want a display with some smarts, $3 might be in your price range. The whole thing wound up taped down to a PCB. But the usual debugger didn’t want to connect. Grabbing an oscilloscope revealed that the output from the board had some level problems. He eventually wrote his own debugger interface using a Pi Pico.
He was able to find the onboard CPU’s development tools. The CPU claims to be proprietary but looks suspiciously like a slightly modified ARM. A short investigation shows that the object code is extremely similar to the ARM Thumb instruction set but with a few extra bits set and different mnemonics. But once you put Python on board, who really cares?
The only downside is that it doesn’t appear that the BLE is practically usable because of memory limitations. But there are still places you might use the little watch in a project.
If you want a smartwatch, maybe build your own. While many DIY watches are simple, you can get pretty complicated if you like.
We’ve seen prolific firmware hacker [Aaron Christophel] tackle smart devices of all sorts, and he never fails to deliver. This time, he’s exploring a device that seems like it could have come from the pages of a Cyberpunk RPG manual — a shiny chrome Bluetooth Low Energy (BLE) smart ring that’s packed with sensors, is reasonably hacker friendly, and is currently selling for as little as $20.
The ring’s structure is simple — the outside is polished anodized metal, with the electronics and battery carefully laid out along the inside surface, complete with a magnetic charging port. It has a BLE-enabled MCU, a heartrate sensor, and an accelerometer. It’s not much, but you can do a lot with it, from the usual exercise and sleep tracking, to a tap-sensitive interface for anything you want to control from the palm of your hand. In the video’s comments, someone noted how a custom firmware for the ring could be used to detect seizures; a perfect example of how hacking such gadgets can bring someone a brighter future.
The ring manufacturer’s website provides firmware update images, and it turns out, you can upload your own firmware onto it over-the-air through BLE. There’s no signing, no encryption — this is a dream device for your purposes. Even better, the MCU is somewhat well-known. There’s an SDK, for a start, and a datasheet which describes all you would want to know, save for perhaps the tastiest features. It’s got 200 K of RAM, 512 K of flash, BLE library already in ROM, this ring gives you a lot to wield for how little space it all takes up. You can even get access to the chip’s Serial Wire Debug (SWD) pads, though you’ve got to scrape away some epoxy first.
As we’ve seen in the past, once [Aaron] starts hacking on these sort of devices, their popularity tends to skyrocket. We’d recommend ordering a couple now before sellers get wise and start raising prices. While we’ve seen hackers build their own smart rings before, it’s tricky business, and the end results usually have very limited capability. The potential for creating our own firmware for such an affordable and capable device is very exciting — watch this space!
[endes0] has been hacking with USB HID recently, and a Logitech M185 mouse’s USB receiver has fallen into their hands. Unlike many Logitech mice, this one doesn’t include a Unifying receiver, though it’s capable of pairing to one. Instead, it comes with a pre-paired CU0019 receiver that, it turns out, is based on a fairly obscure TC32 chipset by Telink, the kind we’ve seen in cheap smart wristbands. If you’re dealing with a similarly obscure MCU, how do you even proceed?
In this case, GitHub had a good few tools developed by other hackers earlier — a Ghidra integration, and a tool for working with the MCU using a USB-UART and a single resistor. Unfortunately, dumping memory through the MCU’s interface was unreliable and frustrating. So it was time to celebrate when fuzzing the HID endpoints uncovered a memory dump exploit, with the memory dumper code helpfully shared in the blog post.
From a memory dump, the exploration truly began — [endes0] uncovers a fair bit of dongle’s inner workings, including a guess on which project it was based on, and even a command putting the dongle into a debug mode where a TC32-compatible debugger puts this dongle fully under your control.
Climbers care a lot about their ropes because their lives literally depend on them. And while there’s been tremendous progress in climbing rope tech since people first started falling onto hemp fibers, there are still accidents where rope failure is to blame.
This long, detailed, and interesting video from [Hard is Easy] follows him on a trip to the Mammut test labs to see what’s up with their relatively new abrasion-resistant rope. His visit was full of cool engineering test rigs that pushed the ropes to breaking in numerous ways. If you climb, though, be warned that some of the scenes are gut-wrenchingly fascinating, watching the ropes fail horribly in well-shot slow-mo.
Long story short, some climbing ropes are strong but stiff. These are called static ropes, and they’re rated to hold a given weight, and tested to breaking under a static load. The thinnest and strongest static ropes are made of Kevlar, and they are correspondingly very abrasion resistant, but they hurt to fall into.
Dynamic climbing ropes have some stretch, and are rated both for how gently they let you down and their maximum breaking force. These are mostly made of nylon, and they are tested by dropping a mass with an accelerometer onto a slack rope — a pretty good simulation of falling back off of a flat face like at the climbing gym.
Now what if you wanted an abrasion resistant dynamic rope? A couple of manufacturers have created custom Kevlar-nylon filaments where the Kevlar is wrapped loosely around the nylon. This filament is abrasion resistant because of the Kevlar, but gives like a nylon rope because the Kevlar fibers have slack built in.
Testing these ropes involved creating a custom test that drops a mass onto the rope, but pulls it across a 45-degree granite edge as it falls. These tests absolutely shred the normal nylon dynamic ropes, but the Kevlar-reinforced ropes held fast. They’re both fun and terrifying to watch.
We’ve said it before, and it’s said a number of times in this video: “you can’t improve what you can’t measure“. In this context, it’s a little sobering is that there isn’t an industry standard test for abrasion resistance, but it’s cool to see the Mammut folks working on it.
In the course of a career, you may run up against projects that get cancelled, especially those that are interesting, but deemed unprofitable in the eyes of the corporate overlords. Most people would move, but [Ron Avitzur] just couldn’t let it go.
In 1993, in the midst of the transition to PowerPC, [Avitzur]’s employer let him go as the project they were contracted to perform for Apple was canceled. He had been working on a graphing calculator to show off the capabilities of the new system. Finding his badge still allowed him access to the building, he “just kept showing up.”
[Avitzur] continued working until Apple Facilities caught onto his use of an abandoned office with another former contractor, [Greg Robbins], and their badges were removed from the system. Not the type to give up, they tailgated other engineers into the building to a different empty office to continue their work. (If you’ve read Kevin Mitnick‘s Ghost in the Wires, you’ll remember this is one of the most effective ways to gain unauthorized access to a building.)
We’ll let [Avitzur] tell you the rest, but suffice it to say, this story has a number of twists and turns to it. We suspect it certainly isn’t the typical way a piece of software gets included on the device from the factory.
Using an external MCU as a crude clock source for the Altera CPLD. (Credit: [Doug Brown])One exciting feature of hardware development involving MCUs and FPGAs is that you all too often need specific tools to program them, with [Doug Brown] suffering a price tag aneurysm after checking the cost of an official Altera/Intel USB Blaster (yours for $300) to program a MAX 10 FPGA device with. This led him naturally down the path of exploring alternatives, with the $69 Terasic version rejected for ‘being too expensive’ and opting instead for the Waveshare USB Blaster V2, at a regretful $34. The amazing feature of this USB Blaster clone is that while it works perfectly fine under Windows, it works at most intermittently under Linux.
This led [Doug] down the path of reverse-engineering and diagnosing the problem, ultimately throwing in the towel and downclocking the Altera CPLD inside the adapter after finding that it was running a smidge faster than the usual 6 MHz. This was accomplished initially by wiring in an external MCU as a crude (and inaccurate) clock source, but will be replaced with a 12 MHz oscillator later on. Exactly why the problem only exists on Linux and not on Windows will remain a mystery, with Waveshare support also being clueless.
Undeterred, [Doug] then gambled on a $9 USB Blaster clone (pictured above), which turned out to be not only completely non-functional, but also caused an instant BSOD on Windows, presumably due to the faked FTDI USB functionality tripping up the Windows FTDI driver. This got fixed by flashing custom firmware by [Vladimir Duan] to the WCH CH552G-based board after some modifications shared in a project fork. This variety of clone adapters can have a range of MCUs inside, ranging from this WCH one to STM32 and PIC MCUs, with very similar labels on the case. While cracking one open we had lying around, we found a PIC18 inside, but if you end up with a CH552G-based one, this would appear to fully fix it. Which isn’t bad for the merest fraction of the official adapter.
With all the EV hype in the air, you’d be forgiven for thinking electric vehicles are something new. But of course, EVs go way, way back, to the early 19th century by some reckonings. More recently but still pretty old-school were Ford’s Think line of NEVs, or neighborhood electric vehicles. These were commercially available in the early 2000s, and something like 7,200 of the slightly souped-up golf carts made it into retirement communities and gated neighborhoods.
But as Think aficionado [Hagan Walker] relates, the Achille’s heel of these quirky EVs was its instrument cluster, which had a nasty habit of going bad and taking the whole vehicle down with it, sometimes in flames. So he undertook the effort of completely reverse engineering the original cluster, with the goal of building a plug-in replacement.
The reverse engineering effort itself is pretty interesting, and worth a watch. The microcontroller seems to be the primary point of failure on the cluster, probably getting fried by some stray transients. Luckily, the microcontroller is still available, and swapping it out is pretty easy thanks to chunky early-2000s SMD components. Programming the MCU, however, is a little tricky. [Hagan] extracted the code from a working cluster and created a hex file, making it easy to flash the new MCU. He has a bunch of other videos, too, covering everything from basic diagnostics to lithium battery swaps for the original golf cart batteries that powered the vehicle.
True, there weren’t many of these EVs made, and fewer still are on the road today. But they’re not without their charm, and keeping the ones that are still around from becoming lawn ornaments — or worse — seems like a noble effort.
If there’s one thing we like better around here than old, obscure displays, it’s old, obscure displays with no documentation that need a healthy dose of reverse engineering before they can be put to use. These Plessey dot-matrix displays are a perfect example of that.
We’re not sure where [Michael] scored these displays, but they look fantastic. Each 8-pin DIP has two 5×7-matrix, high-visibility LED displays. They bear date codes from the late 80s under the part number, GPD340, but sadly, precious little data about them could be dredged up from the Interwebz. With 70 pixels and only six pins after accounting for power and ground, [Michael] figured there would be a serial protocol involved, but which pins?
He decided to brute-force the process of locating them, using a Pico to sequentially drive every combination while monitoring the current used with a current sensor. This paid off after only a few minutes, revealing that each character of the display has its own clock and data pins. The protocol is simple: pull the clock and data pins high then send 35 bits, which the display sorts out and lights the corresponding pixels. The video below shows a 12-character scrolling display in action.
Plessey made a lot of displays for military hardware, and these chunky little modules certainly have a martial air about them. Given that and the date code, these might have come from a Cold War-era bit of military hardware, like this Howitzer data display which sports another Plessey-made display.
If your old camera’s WiFi picture upload feature breaks, what do you do? Begrudgingly get a new one? Well, if you’re like [Ge0rg], you break out Ghidra and find the culprit. He’s been hacking on Samsung’s connected cameras for a fair bit now, and we’ve covered his adventures hacking on Samsung’s Linux-powered camera series throughout the last decade, from getting root on them for fun, to deep dives into the series. Now, it was time to try and fix a problem with one particular camera, Samsung WB850F, which had its picture upload feature break at some point.
[Ge0rg] grabbed a firmware update .zip, and got greeted by a bunch of compile-time debug data as a bonus, making the reverse-engineering journey all that more tempting. After figuring out the update file partition mapping, loading the code into Ghidra, and feeding the debug data into it to get functions to properly parse, he got to the offending segment, and eventually figured out the bug. Turned out, a particularly blunt line of code checking the HTTP server response was confused by s in https, and a simple spoof server running on a device of your choice with a replacement hosts file is enough to have the feature work again, well, paired with a service that spoofs the long-shutdown Samsung’s picture upload server.
Turned out, a bunch more cameras from Samsung had the same check misfire for them, which made this reverse-engineering journey all that more fruitful. Once again, Ghidra skills save the day.
In the annals of ambitious engineering projects, few have captured the imagination and courted controversy quite like Gerald Bull’s Supergun. Bull, a Canadian artillery expert, envisioned a gun that could shoot payloads directly into orbit. In time, his ambition led him down a path that ended in both tragedy and unfinished business.
Depending on who you talk to, the Supergun was either a new and innovative space technology, or a weapon of war so dangerous, it couldn’t be allowed to exist. Ultimately, the powers that be intervened to ensure we would never find out either way.
First Shots Fired
Gerard Bull, pictured at the Space Research Institute at McGill University in 1964. Credit: CC BY-SA 3.0
Gerald Bull was born in 1928 in Ontario, Canada. After a tumultuous youth, his uncle was able to find him a place at the University of Toronto at the age of sixteen. Where his uncle suggested the medical school, Bull requested a position in the newly established aeronautical engineering course. After passing an interview, he was able to begin his tertiary studies in the field at the age of sixteen.
He would go on to graduate in 1948, a strictly average student that had done little to distinguish himself during his period at the university. However, his energy and passion would eventually see him admitted to further study at the Institute of Aerodynamics, where he studied the design of advanced wind tunnels.
This academic pursuit laid the groundwork for his future endeavors. While finishing his PhD in 1950, Bull would eventually be nominated for military work with the Defence Research Board. That led to his position with the Canadian Armament Research and Development Establishment, where he dived into the world of advanced artillery technology.
He began exploring the use of artillery guns for supersonic aerodynamic research, as a cheaper alternative to building high-speed wind tunnels. Later on, he would go on to develop the High Altitude Research Project (HARP), a joint Canadian-American initiative aimed at exploring ballistics at extremely high altitudes.
Kicking off in the 1960s, HARP’s most notable achievement was the creation of a massive gun capable of firing projectiles into the stratosphere, setting the stage for Bull’s lifelong obsession with superguns.
His early experiments with HARP demonstrated the potential of using artillery to reach the upper atmosphere, though the project was eventually shuttered due to financial and political pressures. The project developed a 16.4 inch (41.6 cm) smooth-bore gun which was installed for testing in Barbados.
By 1962, HARP was firing 330 pound (150 kilogram) finned projectiles at over 10,000 feet per second (3000 m/s), reaching altitudes of 215,000 feet (65 kilometers). The project was funded by using the projectiles to capture meteorological data in the upper atmosphere.
Aiming Higher
The seeds for Bull’s later work on the infamous Supergun were sown during these formative years. His desire was not just to shoot projectiles into the upper atmosphere, but to fire them so fast that they could actually reach orbit. His idea to achieve this was simple — he’d use a large gun to fire a projectile high into the atmosphere, where it would then ignite a rocket to boost its velocity further.
Bull’s SRC was in the arms trade, with the company desinging and manufacturing the GC-45 howitzer for multiple customers. Credit: Sturmvogel 66, CC BY-SA 3.0
Well, simple enough on paper, anyway. But achieving this feat was altogether more complex in reality. Bull began investigating the concept during his time at the HARP project. There, he developed rocket-assisted projectiles that could be fired from an artillery gun without damage to the solid fuel propellant.
Plans centered around a small multi-staged rocket called the Martlet. It was to be fired from a 16.4 inch (41.6 cm) gun that was assembled by joining two existing naval cannons together into one massive barrel a full 110 feet (33.5 meters) long. Sadly, HARP’s funding began to dry up towards the end of the 1960s, and a change of government sealed the project’s fate.
Bull ended up going out on his own, establishing the Space Research Corporation (SRC) to pursue his goals. The company operated as an artillery consultancy for international clients, including the Canadian and US military. He developed improved rifling techniques which helped give military artillery longer range and better accuracy. SRC and Bull would go on to sell shells and guns to states all around the world. On the side, he continued to develop his orbital gun technology.
A small barrel section from Project Babylon exists in the collection of the Imperial War Museum, Duxford. Credit: CC BY-SA 3.0
The culmination of Bull’s work came in the late 1980s with the Supergun project. After serving jail time in the US for dealing arms to South Africa, Bull had moved away from clients in the West, and had taken up work with China and Iraq. Ultimately, though, this gave him the opportunity to pursue his dream of an orbital launch gun once more.
Officially known as Project Babylon, it was commissioned by Saddam Hussein in 1988, while he was then the Iraqi defense secretary. The project’s goal was ostensibly to develop a supergun capable of launching satellites into orbit, potentially reducing the cost and complexity of space launches. The guns were intended to fire multi-stage rocket propelled shells that would be capable of reaching orbit.
Bull agreed to continue work on conventional military artillery pieces for the Iraqi government, in exchange for a $25 million payment towards Project Babylon. The project would see the construction of multiple “Baby Babylon” guns, each measuring 147 feet (44.8 meters) long with a caliber of 13.8 inches (35 cm).
Big Babylon
The ultimate goal, however, was the production of two mighty PC-2 Big Babylon guns. They would measure 512 feet (156 meters) long with a massive 39 inch (99 cm) bore. The PC-2 was intended to be capable of launching a 440 lb (200 kg) satellite into an orbital trajectory, carried by a 4,400 lb (2,000 kg) rocket-assisted projectile. Alternatively, it could have launched a 1,300 lb (600 kg) projectile over 620 miles (1,000 km). The final gun would have sat almost 328 feet (100 m) high at the tip, with the barrel suspended by cables from a large supporting frame. The barrel itself was to weigh 1,510 tons, with the whole structure coming in at a hefty 2,100 tons in total.
Two segments of the Iraqi supergun, Big Babylon, are displayed at the Royal Armouries in Fort Nelson, Portsmouth. Credit: Geni, GFDL CC-BY-SA
The technical challenges were immense. Achieving the necessary muzzle velocity to reach orbit required unprecedented gun lengths and extremely durable materials to withstand the immense pressures involved. The initial construction of the Baby Babylon revealed problems with seals between multiple barrel segments. This was a complication from a a necessary engineering decision, as producing a single barrel at such large sizes was impractical.
Meanwhile, the political implications of the project drew international concern. Given the fraught political situation at the time, a large Iraqi gun project was not popular on the international stage. On paper, the gun’s applications for military use were limited. It was not possible to readily aim the gun, nor could it fire rapid salvos on a given target. It was impossible to move or hide, and it was extremely vulnerable to air attack.
Regardless of these practical limitations, few countries wanted Iraq to have such a potent gun in any way, shape or form. Furthermore, Bull was continuing to work on other Iraqi artillery projects, including Scud missile development. This only made him more unpopular with Iraq’s enemies.
The project’s demise was as dramatic as its ambition. In 1990, Bull was assassinated in Brussels as he approached his apartment’s front door. It followed a series of break-ins to his home, which were suggested to be a threat to the engineer to cease his work on the project. His death effectively ended Project Babylon. Supergun components, which had been in production across Europe, were seized by customs officers, and Bull’s staff in turn abandoned the project. Parts of the gun still exist today, after being donated to museums in the UK.
In the aftermath, the Supergun project remains a fascinating study of the interactions between ambition, technology and politics. Gerard Bull’s legacy is a testament to the limits of engineering, and the limits of our own ruling structures. While technically feasible, the Supergun could not be born, given the perceived geopolitical ramifications of such a weapon.
Gerard Bull’s story is a poignant chapter in the history of space exploration technology, marked by brilliant engineering marred by political intrigue and a tragic end. It serves as a reminder of the complexities involved when mixed-use technologies clash with political interests and national security concerns.
Although much of the software that runs on the ESP32 microcontroller is open source, the Wi-Fi driver is not. Instead, it uses a proprietary binary blob. This was no problem for [Jasper Devreker]’s reverse-engineering of the ESP32’s Wi-Fi stack so far until he came face to face with reverse-engineering the initialization of the Wi-Fi peripheral. As it turns out, there is a lot of work involved after you call esp_phy_enable in the Espressif binary blob, with the team logging 53,286 peripheral accesses during the initialization phase. In comparison, sending a Wi-Fi packet takes about ten calls.
Currently, the way that the initialization step is handled is by having the initialization routine in the binary blob do its thing by configuring the radio and other elements before killing the FreeRTOS task and replacing it with their own version. The team is actively looking for a clean approach for moving forward that will avoid simply writing everything from scratch. For the Wi-Fi MAC, existing code (e.g., FreeBSD’s stack) could be used, but the radio code is much more of a headache. Clearly, there’s still a lot more work to be done in order to get a fully open-source Wi-Fi MAC and stack for the ESP32, but having the community (that’s you) pitch in might speed things up if there’s demand for an open-source driver.
Some of us may have recently stumbled over these mysterious ‘Mini 560’ synchronous buck converter modules at various e-shopping websites. These little modules claim to take in 7-20 VDC and output whatever voltage they’re configured for (e.g., 5 VDC). What IC is used on these modules? Since the IC on these modules has had its markings laser-etched away, answering that particular question is a tedious sleuthing job. Fortunately, [MisterHW] has done the legwork for us already, with a detailed write-up.
Details like the nominal input rating, measured currents, and resulting efficiency values provide clues. Looking at the 0603 SMD resistor values for given output voltages provides the programming resistances, combined with the footprint of the QFN-20 package. After desoldering the IC on a sample board, the footprint was reminiscent of certain Texas Instruments (Ti) packages, leading to a perusal of the Ti parametric database and a couple of candidate matches.
JoulWatt JW5069A buck converted on a Mini 560 module.
The other provided parameters for the Mini 560, such as the 500 kHz frequency, narrows things down to two Ti parts: the TPS51397A and TPS56C230. The latter only accepts up to 18 VDC unless you look at the absolute maximum ratings, which matches the 20 VDC. The pin-out of the TPS56C230 also matches the Mini560 IC, but looking deeper, there’s no good match.
Catching a lucky break, [MisterHW] got pointed to the JoulWatt JW5069A, which, as it turns out, is a good match, including the odd footprint with bridged pads. Googling for this part number even led to images of the Mini 560 module without the laser-etching. It looks like JoulWatt may have been founded in China in 2013 to provide drop-in alternatives for Western parts like those from Ti (with the JW5068A also very interesting), but it still doesn’t really explain the laser-etched markings unless these parts aren’t designed for the export market? Some mysteries may never truly be solved, it seems.
Over the past few years a number of teams have been putting a lot of effort into taking beloved Nintendo 64 games, decompiling them, and lovingly crafting them into highly portable C code. This allows for these games to not only run natively on PCs, but also for improvements to be made to the rendering engine and other components.
Yet this artisan approach to porting these games means a massive time investment, something which static binary translation (static recompilation) may conceivably speed up. Enter the N64: Recompiled project, which provides a binary translation tool to ease the translation of the N64’s binaries into C code.
This is effectively quite similar to what an emulator does in real-time, just with the goal of creating a permanent copy of the translated instructions. After this static binary translation, the C code can be compiled again, but as noted by the project’s documentation, a suitable runtime is needed to get a functional game. An example of this is the Zelda 64: Recompiled project, which uses the N64: Recompiled project at its core, while providing the necessary scaffolding and wrappers to create a working copy of The Legend of Zelda: Majora’s Mask as output.
In the video below, [Modern Vintage Gamer] takes the software for a test drive and comes away very excited about the potential it has to completely change the state of N64 emulation. To be clear, this isn’t a one-button-press solution — it still requires capable developers to roll up their sleeves and get the plumbing in. It’s going to take some time before you favorite game is supported, but the idea of breathing new life into some of the best games from the 1990s and early 2000s certainly has us eager to see where this technology goes
Most of the Hackaday community would never wire a power supply to a circuit without knowing the expected voltage and the required current. But our mechanical design is often more bodged. We meet folks who carefully budget power to their microcontroller, sensors, and so on, but never measure the forces involved in their mechanical designs. Then they’re surprised when the motor they chose isn’t big enough for the weight of their robot.
An obstacle to being more numbers oriented is lack of basic data about the system. So, here are some simple tools for measuring dynamic properties of small mechanisms; distances, forces, velocities, accelerations, torques, and other things you haven’t thought about since college physics. If you don’t have these in your toolkit, how do you measure?
Distance
For longer distances the usual homeowner’s tools work fine. The mechatronics tinkerer benefits from two tools on the small end. A dial or electronic caliper for measuring small things, and a thickness gauge (or leaf gauge) for measuring small slots.
A thickness gauge is just metal leaves in different thicknesses, bolted together at one end. Find a combination of leaves that just fits in the space.
Force
Here’s four force measuring tools we use to cover different magnitudes of force: a postage scale, a push stick, a spring scale, and a letter scale. The postage scale is best purchased. For big things, the bathroom scale works.
A push stick is a force measurement device that you can make yourself. We first saw one of these used to tune slot cars, but they’re universally useful. It’s a simple pen shaped device made with a barrel from any small transparent parts tube, a spring, and a plunger with a protruding pin. Grasp the barrel and push the gizmo with the pin, and you can read the force off the tube.
If you need it to be calibrated, remember that you just bought a postage scale. Push it into the scale and mark off reasonable increments. Make several, in different sizes. A Z or L shaped plunger is useful for hard to reach places.
The conventional spring tension scale is useful, but most commercial ones are terribly made and inaccurate. You can make yourself a better one. They are useful for measuring the spring constant of springs, for learning the tractive effort needed to move a robot, finding the center of gravity of a robot arm, and a hundred other ‘how much oomph’ things. Again, it’s just a matter of connecting a hook to a spring, and measuring its deflection.
For yet lighter weights, you could buy a letter scale, at least in the old days. Today you might have to make your own. It can be as simple as a piece of spring steel fixed to a sheet of calibrated cardboard.
Torque
Torque measurements are good not only for sizing actuators, but for measuring efficiency.
How you do torque measurements depend on the speed you want to make them at. For static loads, just put a lever of known length on the shaft and measure the force. Torque = distance * force. For fast rotating systems, you can run the system at a known speed and measure the electrical energy used.
Schematic of a Prony brake by [MatthiasDD]If you just want to apply a varying known torque to measure efficiency, your life is much easier. Mount a broad wheel of some sort on the shaft — RC airplane tires work well. Drape a piece of ribbon over the tire. Anchor it at the “out” end and hang a small weight at the “in” end. This is a Prony Brake, and it’s a useful device to know about. The force on the outside of the wheel is just enough to lift the weight – after that the ribbon slips. The measured torque is then the weight times the wheel radius.
You may also want to measure speeds and accelerations. Here, the ubiquity of cell phone cameras is your friend. Suppose you’re animating a crane on your model railroad. Record yourself on video moving the crane with your hands against a protractor to get a feel for speed and acceleration. In video editing software check the positions for various frames, and you now have position changes. The number of frames and distance can help you calculate the speed, and the change in speed vs time is acceleration.
If your mechanism is moving too fast for video, use a fast phototransistor or hall effect device and an oscilloscope, or gear down by holding a toy wheel against the shaft and measure the more slowly rotating wheel.
In the crane example, the torque you need to supply is the frictional torque plus the acceleration torque, and to calculate the acceleration torque you need the moment of inertia. For refresher: angular acceleration = torque / moment of inertia (ω = τ / I) and moment of inertia = mass * radius2 (I = m * r2 ) for point mass.
You can drive the crane with a repeatable torque, say using a pulley and weight or a motor, and get the acceleration ω1 from the still frames on your video. If you repeat this with a known mass m a known distance r from the shaft axis, like a lump of putty on the end of the crane arm, you can get a second value: ω2.
Write the ω = τ / I equations, ω1 = τ / Icrane and ω2 = τ / (Icrane + r 2 * m). Combining and isolating Icrane and holding our tongues just right, Icrane = r2 * m / (ω1 / ω2 – 1).
Be careful to subtract the moment of inertia of your measuring apparatus, and add in the moment of inertia of the final drive if needed. Now you can size your servo with some confidence. Believe me, once you’ve done this a couple times, you’ll never go back to winging it.
Power
The easiest way to get a ballpark feel for power is to simply measure the system’s consumed power by measuring the electrical power at the motor, but this ignores losses in the drive train. And losses are one of the really interesting things to measure. Bad performance is usually friction, and efficiency is a goal for other reasons than just motor sizing or battery life. It’s a measure of how janky your setup is.
Does your model train or robot run poorly? Set it to climb a steep grade on a test track. Calculate the work it does: mass * height change. Measure the input electrical power and the time, Energy = V*I*T. You now have an idea of how much the actual power consumption differs from the maximally efficient system. Any power that went in but didn’t appear as potential energy in the choo-choo’s new position is frictional loss. Now you can experiment with loosening and tightening screws, changing gear mesh, and such, and have some idea if you’re making things better or worse.
Conclusion
None of the above was rocket science, and you don’t need to do some complex FEM analysis to make the average hacker project. But a bit of real engineering can go a long way towards more reliable mechanisms, and that starts with knowing the numbers you’re dealing with. Taking the required measurements can be simple if you know how to build the tools you need, and your life will be easier with some numbers to guide you.
Have you ever tried to eat one jelly bean or one potato chip? It is nearly impossible. Some of us have the same problem with hardware projects. It all started when I wrote about the old bitslice chips people used to build computers before you could easily get a whole CPU on a chip. Bitslice is basically Lego blocks that build CPUs. I have always wanted to play with technology, so when I wrote that piece, I looked on eBay to see if I could find any leftovers from this 1970-era tech. It turns out that the chips are easy to find, but I found something even better. A mint condition AM2900 evaluation board. These aren’t easy to find, so the chances that you can try one out yourself are pretty low. But I’m going to fix that, virtually speaking.
This was just the second potato chip. Programming the board, as you can see in the video below, is tedious, with lots of binary switch-flipping. To simplify things, I took another potato chip — a Google Sheet that generates the binary from a quasi-assembly language. That should have been enough, but I had to take another chip from the bag. I extended the spreadsheet to actually emulate the system. It is a terrible hack, and Google Sheets’ performance for this sort of thing could be better. But it works.
The idea for the simulator struck me when I was building the assembler. I considered writing a stand-alone program, but I wanted to limit my potato chip consumption, so keeping it in the spreadsheet seemed like a good idea.
Was it? Hard to say. Google Sheets has macros that are just Javascript. However, the macros are somewhat slow and attaching them to user interface elements is difficult. There were plenty of ways to do it, but I went for the path of least resistance.
Strategy
For better or worse, I tried to minimize the amount of scripting. All of the real work occurs on the Sim tab of the spreadsheet, and only a few key parts are included in the attached macros. Instead, the cells take advantage of the way the AM2900 works. For example, some bits in the microcode instructions represent how to find the next address. Instead of calculating this with code, there is a table that computes the address for each possible branch.
For example, branch type zero goes to the next address when the current result is zero or the address coded in the instruction if the result is not zero. If the branch type is one, there is always a jump to the hardcoded address, while a branch type of two always takes the next instruction. So, the associated table always computes all the possible results (see cells O1 through P18). Then, cell P18 uses VLOOKUP to pick the right row from the table (which has 16 rows).
Every part of the instruction decode works this way. The only complication is that the instructions operate on the current result, something mentioned in the last post. In other words, consider an instruction that says (in English): If the result is zero, go to location 9; add 1 to the B register. You might assume the jump will occur if B+1 results in zero. But that’s not how it works. Instead, the processor adds B and 1. Then, it jumps to location 9 if the state was zero before the addition operation.
What this means is that the spreadsheet computes all things at all times. The macros are almost like clock pulses. Instead of gating flip flops, they copy things from where they are calculated to where they are supposed to go.
Macros
The main simulation logic is in the stepengine macro. It computes the next address and sets the status latch, if necessary. Then it grabs the result of the current operation and places it in the correct destination. The final part of the macro updates the next location, which may require manipulating the processor stack. All of those things would have been difficult to do in spreadsheet logic.
The other macros are essentially wrappers around stepengine. The Exec macro executes an instruction without advancing (like stepping the real board in load mode). The Step macro can optionally single step, or it can execute in place like Exec. The Run macro does the real execution and also checks for breakpoints. There’s also a Reset macro to put everything in a known state.
Usage
The user interface for the simulator.
You can call the macros directly, but that’s not very user-friendly. Instead, the Sim tab has three graphical buttons for run, step, and reset. Each command has options. For example, under Run, you can set a hex address to break execution. Under Step, you can decide if the step should advance the program counter or not. The reset button allows you to clear registers.
Don’t enter your program on the Sim tab. Use the Main tab as before. You can also go to the Extensions | Macros menu to load one of the canned demos. Demo 1 is the BCD program from the last post. The other examples are the ones that shipped with the real board’s manual. If you really want to learn how the thing works, you could do worse than walk through the manual and try each example. Just don’t forget that the scanned manual has at least two typos: Figure 7 is wrong, and example 7 has an error (that error was fixed in later manuals and in the simulator’s copy, too). Instead of figure 7, use figure 3 or pick up a corrected figure on Hackaday.io.
Why learn how to operate the AM2900 evaluation board? Beats me, but I did it anyway, and now you can do it without spending the money I did on a piece of exotic hardware. I’d like to say that this might help you understand modern CPU design, but that wouldn’t be very fair. I suppose it does help a little, but modern CPUs have as much in common with this design as a steam locomotive has in common with a jet airplane.
If the idea of building a CPU from modules appeals to you, check out DDL-4. If that’s too easy for you, grab your bag of 2,000 transistors and check out this build. I’m sealing up my bag of potato chips now. Really.
[Matthew “wrongbaud” Alt] is well known around these parts for his hardware hacking and reverse-engineering lessons, and today he’s bringing us a JTAG hacking primer that demoes some cool new hardware — the PiFEX (Pi Interface Explorer). Ever wondered about those testpoint arrays on mSATA and M.2 SSDs? This write-up lays bare the secrets of such an SSD, using a Pi 4, PiFEX, OpenOCD and a good few open-source tools for JTAG probing that you can easily use yourself.
The PiFEX hat gives you level-shifted bidirectional GPIO connectors for UART, SPI, I2C, JTAG, SWD and potentially way more, an OLED screen to show any debugging information you might need, and even a logic analyzer header so that you can check up on your reverse-engineering progress.
The suggested software workflow pulls no punches either, proposing ease-of-use features like USB-Ethernet gadget mode and Jupyter notebooks. [wrongbaud] shows us how to find JTAG among the dozen testpads left on the SSD, get the SSD single-stepping through code, and dump some of its memory space as a test. Full of tricks of the trade like reverse-engineering devices on a sheet of paper you can leave markings on, this write-up gives you a solid background in JTAG hacking, even if you only have a Pi and an old SSD.
So how can you get your hands on one? [wrongbaud] says the plan is to open source both the PiFEX hardware and software in the near future. Until until then, it looks like at least the hardware it wouldn’t be too hard to re-implement it yourself if you wanted to get the hang of reverse engineering with the Raspberry Pi.
Conectar
