firmware

148 Articles

Custom Library Rescues Good LoRa Hardware From Bad Firmware

March 13, 2024 by 17 Comments

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

February 3, 2024 by 6 Comments

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

December 7, 2023 by 36 Comments

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

November 29, 2023 by 19 Comments

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

November 17, 2023 by 16 Comments

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.

Close To The Metal

October 14, 2023 by 81 Comments

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

Improving A Kodak Film Digitizer

August 23, 2023 by 10 Comments

Despite the near-complete collapse of its ecosystem in the face of portable videocassette camcorders in the 1980s, somehow the 8 mm format, smallest of the movie films, has survived the decades. There’s a special aura around an 8 mm image which electronic recordings don’t replicate, plus for film makers there’s an attraction to working with real film. Unsurprisingly almost all of the devices used with 8 mm film have ceased to be manufactured, but a few items escaped the cut. It’s still possible to buy an 8 mm digitizer for example, and it’s one of these with a Kodak brand that [Mac84] has. Unsatisfied with its image quality, he’s set about tinkering with its firmware to give it some video adjustment possibilities and remove its artifact-prone artificial sharpening.

Helped by the device having a handy EEPROM from which to extract the code, he was able to recover the firmware intact. From here on he was in luck, because the digitizer’s Novatek CPU is shared with some dash cams and this had spawned a hacker scene. From there he was able to find the relevant area and adjust those settings, and after a few false starts, re-flash it to the device.

The results can be seen in the video below the break, and perhaps reveal much about what we expect from an image in the digital age. The sharpened images look good, until we see untampered versions which are closer to the original.

If you don’t have a Kodak scanner you can always build one yourself, and meanwhile like many people we are still wondering what happened to that new Super 8 camera they announced in 2018 but never released.

Continue reading “Improving A Kodak Film Digitizer” →