By now most readers will be familiar with the Miniware TS100 and TS80 soldering irons, compact and lightweight temperature controlled soldering tools that have set a new standard at the lower-priced end of the decent soldering iron market. We know they have an STM32 processor, a USB interface, and an OLED display, and that there have been a variety of alternative firmwares produced for them.
Take a close look at the TS80, and you’ll find the element connector is rather familiar. It’s a 3.5 mm jack plug, something we’re more used to as an audio connector. Surely audio from a soldering iron would be crazy? Not if you are [Joric], who has created a music player firmware for the little USB-C iron. It’s hardly a tour de force of musical entertainment and it won’t pull away the audiophiles from their reference DACs, but it does at least produce a recognisable We Wish You A Merry Christmas as you’ll see from the video below the break.
Since the TS100 arrived a couple of years ago we’ve seen a variety of inventive firmware for it. You may remember [Joric]’s previous triumph of a Tetris game for the iron, but our favourite is probably the TS100 oscilloscope.
Continue reading “Your TS80 – Music Player”
Two months after its surprise reveal at the 2019 East Coast RepRap Festival, the Prusa Mini has started shipping out to the first wave of early adopters. True to form, with the hardware now officially released to the public, the company has begun the process of releasing the design as open source. In their GitHub repository, owners can already find the KiCad files for the new “Buddy” control board and STLs for the machine’s printable parts.
But even so, not everyone feels that Prusa Research has made the Mini as “open” as its predecessors. Some concerned owners have pointed out that according to the documentation for the Buddy board, they’ll need to physically snap off a section of the PCB so they can flash custom firmware images via Device Firmware Upgrade (DFU) mode. Once this piece of the board has been broken off, which the documentation refers to as the Appendix, Prusa Research will no longer honor any warranty claims for the electronic components of the printer.
For the hardcore tinkerers out there, this news may come as something of a shock. Previous Prusa printers have enjoyed a fairly active firmware development community, and indeed, features that started out as user-developed modifications eventually made their way into the official upstream firmware. What’s more, certain hardware modifications require firmware tweaks to complete.
Prusa Research explains their stance by saying that there’s no way the company can verify the safety of community developed firmware builds. If thermal runaway protections have been disabled or otherwise compromised, the results could be disastrous. We’ve already seen it happen with other printers, so it’s hard to fault them for being cautious here. The company is also quick to point out that the installation of an unofficial firmware has always invalidated the printer’s warranty; physically breaking the board on the Mini is simply meant as a way to ensure the user understands they’re about to leave the beaten path.
How much support is a manufacturer obligated to provide to a user who’s modified their hardware? It’s of course an issue we’ve covered many times before. But here the situation is rather unique, as the user is being told they have to literally break a piece off of their device to unlock certain advanced functionality. If Prusa wanted to prevent users from running alternate firmware entirely they could have done so (or at least tried to), but instead they’ve created a scenario that forces the prospective tinkerer to either back down or fully commit.
So how did Prusa integrate this unusual feature into their brand new 32-bit control board? Perhaps more importantly, how is this going to impact those who want to hack their printers? Let’s find out.
Continue reading “Prusa Dares You To Break Their Latest Printer”
It has now been a few months since the launch of the Raspberry Pi 4, and it would only be fair to describe the launch as “rocky”. While significantly faster than the Pi 3 on paper, its propensity for overheating would end up throttling down the CPU clock even with the plethora of aftermarket heatsinks and fans. The Raspberry Pi folks have been working on solutions to these teething troubles, and they have now released a bunch of updates in the form of a new bootloader, that lets the Pi 4 live up to its promise. (UPDATE: Here’s the download page and release notes)
The real meat of the update comes in an implementation of a low power mode for the USB hub. It turns out that the main source of heat on the SoC wasn’t the CPU, but the USB. Fixing the USB power consumption means that you can run the processor cool at stock speeds, and it can even be overclocked now.
There is also a new tool for updating the Pi bootloader, rpi-eeprom, that allows automatic updates for Pi 4 owners. The big change is that booting the Pi 4 over the network or an attached USB device is now a possibility, which is a must if you’re installing the Pi permanently. There are some fixes that caused problems with certain HATs, in which the Pi 4’s 3.3 V line was cycled during a reboot.
With a device as complex as a Raspberry Pi it comes as no surprise that it might ship with a few teething troubles. We’ve already covered some surrounding the USB-C power, for example. And the overheating. Where the Pi people consistently deliver though is in terms of support, both official and from the community, and we’re very pleased to see them come through in this case too.
The regular Hackaday reader might remember the iClicker from our previous coverage of the classroom quiz device, or perhaps you even had some first hand experience with it during your university days. A number of hackers have worked to reverse engineer the devices over the years, and on the whole, it’s a fairly well understood system. But there are still a few gaps in the hacker’s map of the iClicker, and for some folks, that just won’t do.
[Ammar Askar] took it upon himself to further the state of the art for iClicker hacking, and has put together a very detailed account on his blog. While most efforts have focused on documenting and eventually recreating how the student remotes send their responses to the teacher’s base station, he was curious about looking at the system from the other side. Specifically, he wanted to know how the base station was able to push teacher-supplied welcome messages to the student units, and how it informed the clients that their answers had been acknowledged.
He started by looking through the base station’s software update tool to find out where it was downloading the firmware files from, a trick we’ve seen used to great effect in the past. With the firmware in hand, [Ammar] disassembled the AVR code in IDA and got to work piecing together how the hardware works. He knew from previous group’s exploration of the hardware that the base station’s Semtech XE1203F radio is connected to the processor via SPI, so he started searching for code which was interacting with the SPI control registers.
This line of logic uncovered how the radio is configured over SPI, and ultimately where the data intended for transmission is stored in memory. He then moved over to running the firmware image in simavr. Just like Firmadyne allows you to run ARM or MIPS firmware with an attached debugger, this tool allowed [Ammar] to poke around in memory and do things such as simulate when student responses were coming in over the radio link.
At that point, all he had to do was capture the bytes being sent out and decode what they actually meant. This process was complicated slightly by the fact the system uses to use its own custom encoding rather than ASCII for the messages, but by that point, [Ammar] was too close to let something like that deter him. Nearly a decade after first hearing that hackers had started poking around inside of them, it looks like we can finally close the case on the iClicker.
Making a programming jig becomes exponentially more difficult after two pins and who would even consider building one if they were not setting up more than twenty boards? If it were easy for novices to construct jigs, we might all have a quiver of them on the shelf next to our microprocessors. Honestly, a tackle box full of homemade programming fixtures sounds pretty chic. The next advantage to ditching the demo boards is that bare processors take up less room and don’t draw power for unnecessary components like unused voltage regulators and LEDs. [Albert David] improves the return-on-time-investment factor by showing us how to repurpose a WeMos board to program a bare ESP8266 module.
[Albert]’s concept can apply to many other surface-mount chips and modules. The first step is to buy a demo board which hosts a programmable part and remove that part. Since you’ve exposed some solder pads in the process, put pogo pins in their place. Pogo pins are small spring-loaded probes that can be surface mounted or through-hole. We’ve used them for programming gorgeous badges and places where the ESP8266 has already been installed. When you are ready to install your software, clamp your Franken-porcupine to the controller and upload like normal. Rinse, wash, repeat. We even get a view of the clamp [Albert] uses.
eBay is a wondrous land, full of Star Wars memorabilia in poor condition, old game consoles at insane markups, and a surprising amount of DIY electronics. [TheHWCave] found himself tinkering with a common frequency counter kit, and decided to make a few choice improvements along the way (Youtube link, embedded below).
The frequency counter in question is a common clone version of [Wolfgang “Wolf” Büscher]’s minimalist PIC design. Using little more than a PIC16F628 and some seven-segment displays, it’s a competent frequency counter for general use. Clone versions often add a crystal oscillator tester and are available on eBay for a fairly low price.
[TheHWCave] found that the modifications were less than useful, and developed a way to turn the tester components into a more useful signal preamp instead. Not content to stop there, custom firmware was developed to both improve the resolution and also add a tachometer feature. This allows the device to display its output in revolutions per minute as opposed to simply displaying in hertz. By combining this with an optical pickup or other RPM signal, it makes a handy display for rotational speed. If you’re unfamiliar with the theory, read up on our phototachometer primer. If you’re looking to modify your own kit, modified firmware is available on Github.
We’ve seen other eBay kit specials modified before. Being cheap and using commodity microcontrollers makes them a ripe platform for hacking, whether you just want to make a few tweaks or completely repurpose the device.
[Thanks to Acesoft for the tip!]
Continue reading “Hacking A Cheap EBay Frequency Counter”
It might be difficult for modern audiences to believe, but at one point Microsoft Windows fit on floppy disks. This was a simpler time, with smaller hard drives, lower resolution displays, and no hacker blogs for you to leave pessimistic comments on. A nearly unrecognizable era, to be sure. But if you’re one of the people who looks back on these days fondly, you might wonder why we don’t see this tiny graphical operating system smashed into modern hardware. After all, SkiFree sure ain’t gonna play itself.
Well, wonder no more. A hacker by the name of [redsPL] thought that Microsoft’s latest and greatest circa 1992 might do well crammed into the free space remaining on a ThinkPad X200’s firmware EEPROM. It would take a little fiddling, plus the small matter of convincing the BIOS to see the EEPROM as a virtual floppy drive, but clearly those are all minor inconveniences for anyone mad enough to boot their hardware into a nearly 30 year old copy of Visual Basic for a laugh.
The adventure starts when [redsPL] helped a friend install libreboot and coreboot on a stack of old ThinkPads by using the Raspberry Pi as an SPI flasher, a pastime we’re no strangers to ourselves. Once the somewhat finicky software and hardware environment was up and running, it seemed a waste not to utilize it further. Especially given the fact most firmware replacements only fill a fraction of the X200’s 8 MB chip.
Of course, Windows 3.1 was not designed for modern hardware and no proper drivers exist for much of it. Just getting the display resolution up to 1024×768 (and still with only 256 colors) required patching the original video drivers with ones designed for VMWare. [redsPL] wasn’t able to get the sound hardware working, but at least the PC speaker makes the occasional buzz. The last piece of the puzzle was messing around the
xz commands until the disk image was small enough to sneak onto the chip.
Believe it or not, this isn’t the first time we’ve seen Windows from this era running on a (relatively) modern ThinkPad. For whatever reason, these two legends of the computing world seem destined to keep running into each other.
[Thanks to Renard for the tip.]