Hacked Oscilloscope Plays Breakout, Hints At More

You know things are getting real when the Dremel is one of the first tools you turn to after unboxing your new oscilloscope. But when your goal is to hack the scope to play Breakout, sometimes plastic needs to be sacrificed.

Granted, the scope in question, a Fnirsi DSO152, only cost [David Given] from Poking Technology a couple of bucks. And while the little instrument really isn’t that bad inside, it’s limited to a single channel and 200 kHz of bandwidth, so it’s not exactly lab quality. The big attractions for [David] were the CH32F103 microcontroller and the prominent debug port inside, not to mention the large color LCD panel.

[David]’s attack began with the debug port and case mods to allow access, but quickly ground to a halt when he accidentally erased the original firmware. But no matter — tracing out the pins is always an option. [David] made that easier by overlaying large photos of both sides of the board, which let him figure out which buttons went to which pins, and mapping for the display’s parallel interface. He didn’t mess with any of the analog stuff except to create a quick “Hello, oscilloscope!” program to output a square wave to the calibration pin. He did, however, create a display driver and port a game of breakout to the scope — video after the hop.

We’ve been seeing a lot of buzz around the CH32xx MCUs lately; seeing it start to show up in retail products is perhaps a leading indicator of where the cheap RISC chips are headed. We’ve seen a few interesting hacks with them, but we’ve also heard tell they can be hard to come by. Maybe getting one of these scopes to tear apart can fix that, though.

Continue reading “Hacked Oscilloscope Plays Breakout, Hints At More”

Open HT Surgery Gives Cheap Transceiver All-Band Capabilities

Watch out, Baofeng; there’s a new kid on the cheap handy talkie market, and judging by this hardware and firmware upgrade to the Quansheng UV-K5, the radio’s hackability is going to keep amateur radio operators busy for quite a while.

Like the ubiquitous Baofeng line of cheap transceivers, the Quansheng UV-K5 is designed to be a dual-band portable for hams to use on the 2-meter VHF and 70-centimeter UHF bands. While certainly a useful capability, these bands are usually quite range-limited, and generally require fixed repeaters to cover a decent geographic area. For long-range comms you want to be on the high-frequency (HF) bands, and you want modulations other than the FM-only offered by most of the cheap HT radios.

Luckily, there’s a fix for both problems, as [Paul (OM0ET)] outlines in the video below. It’s a two-step process that starts with installing a hardware kit to replace the radio’s stock receiver chip with the much more capable Si4732. The kit includes the chip mounted on a small PCB, a new RF choke, and a bunch of nearly invisible capacitors. The mods are straightforward but would certainly benefit from the help of a microscope, and perhaps a little hot air rework. Once the hardware is installed and the new firmware flashed, you have an HT that can receive signals down to the 20-meter band, with AM and SSB modulations, and a completely redesigned display with all kinds of goodies.

It’s important to note that this is a receive-only modification — you won’t be transmitting on the HF bands with this thing. However, it appears that the firmware allows you to switch back and forth between HF receive and VHF/UHF transceive, so the radio’s stock functionality is still there if you need it. But at $30 for the radio and $12 for the kit, who cares? Having a portable HF receiver could be pretty handy in some situations. This looks like yet another fun hack for this radio; we’ve seen a few recently, including a firmware-only band expansion and even a Trojan that adds a waterfall display and a game of Pong. Continue reading “Open HT Surgery Gives Cheap Transceiver All-Band Capabilities”

Custom Library Rescues Good LoRa Hardware From Bad Firmware

The range of hardware that comes on some dev boards these days is truly staggering. Those little LoRa boards are a prime example — ESP32 with WiFi and Bluetooth, a transceiver that covers a big chunk of the UHF band, and niceties like OLED displays and plenty of GPIO. But the firmware and docs? Well, if you can’t say something nice, don’t say anything at all. Or better yet, just roll your own.

Of course that doesn’t hold true for all the LoRa dev boards on the market, but [Rop] certainly found it to be the case for the Heltec HTIT-WB32LA. This board has all the bells and whistles and would be perfect for LoraWAN and Meshtastic applications, but it needed a little help getting it over the line. [Rop]’s contribution to this end is pretty comprehensive and is based on his fork of the RadioLib library, which incorporates a library that greatly reduces wear on the ESP32’s flash memory. In addition to full radio support, the library supports all the hardware on the board from the pushbutton to the display, power management and battery charging, and of course the blinkenlights.

[Jop] includes quite a few example applications, from the bare minimum needed to get the board spun up to a full-blown spectrum analyzer. It’s a nice piece of work, and a great give-back to the LoRa community. And if you want to put one of these modules to work, you’re certainly in the right place. We’ve got everything from LoRaWAN networks to the magic of Meshtastic, so take your pick and get hacking.

Recovering A Busted Video Capture Device With Firmware Flashing Tricks

Sometimes, you have a piece of hardware that just up and stops working on you. In today’s fast-paced world, it’s easy to toss something broken and move on. [BuyItFixIt], as you imagine, makes it their purpose to, well, fix things instead. Their latest efforts involved resurrecting a dead AVerMedia Live Gamer 2 Plus capture device sourced off eBay.

The device was advertised as being dead, with no power. Probing around the board when powered up showed that there was some basic activity going on with one of the flash chips, but the device simply wouldn’t spring to life. This suggested that perhaps the flash had become corrupted, which was confirmed when reading the chip mostly returned 0xFF. Sadly, the device was so badly bricked that the usual update methods via SD card simply wouldn’t work.

Eventually, hunting down a debug header provided a way in. [BuyItFixIt] was able to find a way to flash firmware over this connection instead, but there was a problem. The firmware they had was formatted for loading via SD card, and wouldn’t work for the debug mode entry route. Instead, getting the device going would require recovering firmware from a similar working device, and then using that as a guide to assemble a proper workable firmware update to get the device back to an operational state.

It’s a great tale of perseverance and triumph, particularly given many would give up after the first update attempt failed. We’ve seen [BuyItFixIt] pull off some heroic repairs before, too. Video after the break.

Continue reading “Recovering A Busted Video Capture Device With Firmware Flashing Tricks”

One Less Binary Blob

Open-source software has gone a long way into making modern technology the way it is today. The Linux kernel alone is almost single-handedly holding up the entire Internet, and various other open-source projects allow for more access to computing resources not just because the software is often free, but because it’s possible to look under the hood and modify it for specific needs. Without open-source software available we often run into problems both expected, such as software licensing costs, and unexpected, which often come up because a developer can’t or won’t fix issues or add features. To that end, a group at Ghent University in Belgium are attempting to rectify a problem with the ESP32 by eliminating one of its binary blobs and replacing it with an open source driver.

The ESP32 is famously a low-cost microcontroller with on-board wireless capabilities, but its Wi-Fi functionality currently relies on closed-source software from Espressif. The team is currently working on building a fully working open-source networking stack with the hopes of enabling greater flexibility of these devices but also making things like security auditing possible. The other major goal is to improve low-cost mesh networking which is currently not available with the proprietary driver. Reverse engineering is the name of the game here, both from a hardware and a software level, but current versions of the software already able to send and receive packets.

The source code for the project is available on the team’s GitHub page for any open-source aficionados to take a look at. We certainly hope the project gains some steam, as any new open source project helps all of us using the platform. Open source projects frequently get stymied by a single or small handful of binary blobs too, often with little hope for recourse. Examples include Android being an open-source operating system but generally using the closed-source Google Play suite in practice, or Firefox including support for Adobe Flash. Another great example is that even computers running 100% open-source code once they boot their operating systems, there’s still some black boxes running in the background few of us think about.

Thanks to [Crote] for the tip!

Converting Bluetooth Sensors To Zigbee

With the increase in popularity of Internet of Things (IoT) devices and their need to communicate wirelessly,  there’s been a corresponding explosion of wireless protocols to chose from. Of course there’s Wi-Fi and Bluetooth, but for more specialized applications there are some other options like Z-Wave, LoRa, Sigfox, and Thread. There’s a decent amount of overlap in their capabilities too, so when [SHS] was investigating some low-cost Xiaomi sensors it was discovered that it is possible to convert them from their general purpose Bluetooth protocol over to the more IoT-specialized Zigbee protocol instead.

These combination temperature and humidity sensors have already been explored by [Aaron Christophel] who found that it’s possible to flash these devices with custom firmware. With that background, converting them from Bluetooth to Zigbee is not a huge leap. All that’s needed is the Zigbee firmware from [Ivan Belokobylskiy] aka [devbis] and to follow the steps put together by [SHS] which include a process for flashing the firmware using an over-the-air update and another using UART if the wireless updates go awry. Then it’s just a short process to pair the new Zigbee device to the network and the sensor is back up and running.

Converting from one wireless protocol to another might not seem that necessary, but using Bluetooth as an IoT network often requires proxy nodes as support devices, whereas Zigbee can communicate directly from the sensor to a hub like Home Assistant. Other Zigbee devices themselves can also act as a mesh network of sorts without needing proxy nodes. The only downside of this upgrade is that once the Bluetooth firmware has been replaced, the devices no longer has any Bluetooth functionality.

Thanks to [RoganDawes] for the tip!

Taking A Public Transit Display From Project To Product

We’ve noticed an uptick in “project to product” stories lately, which seems like a fantastic trend to us. It means that hackers are turning out projects that really resonate with people, to the degree that taking the leap and scaling up from a one-off to a marketable product is worth the inherent risk. And luckily enough for the rest of us, we get to learn from their experiences.

The latest example of this comes to us from [Stefan Schüller], who from the sound of things only reluctantly undertook the conversion of his LED matrix public transit sign into an actual product. The original project had a lot going for it; it looked fantastic, it was technologically simple, and it provided a valuable service. But as a project, it made certain assumptions and concessions that would cause problems when in the hands of a customer. Chief among these was the physical protection of the fragile LEDs, which could easily shear off the display modules if bumped or dropped. There were also firmware issues, such as access to the backend API that serves the transit data; requiring each customer to sign up for and configure their own API key is a non-starter for a product.

In the article, [Stefan] enumerates a long list of problems that going from project to product raises, as well as how he addressed them. The API issue was solved by implementing his own service, which acts as a middleman between the official API and his customers. A nice plexiglass and sheet-metal frame serves to protect the display, too. Design changes were made as well, not only to provide better functionality but to make manufacturing easier. [Stefan] also relates a tale of woe with regard to getting the display’s app into the app stores, something that few of us have to deal with when we’re just fiddling around with something on the bench.

All in all, [Stefan] does a great job walking us through the trials and tribulations of bringing a product to market. There are similar lessons in this production run scale-up, too, but with an entirely different level of project complexity.