firmware

152 Articles

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 11 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” →

Open-Source Firmware For Soldering Irons

August 2, 2023 by 23 Comments

For most of us, the first soldering iron we pick up to start working on electronics has essentially no features at all. Being little more than resistive heaters plugged straight into the wall with perhaps a changeable tip, there’s not really even a need for a power switch. But doing anything more specialized than through-hole PCB construction often requires a soldering iron with a little more finesse, though. Plenty of “smart” soldering irons are available for specialized soldering needs now, and some are supported by the open-source IronOS as well.

The project, formerly known as TS100, is a versatile soldering iron control firmware that started as an alternative firmware for only the TS100 soldering iron. It has since expanded to have compatibility with several other soldering irons and hosts a rich set of features, including temperature control, motion activation, and the ability to temporarily increase the temperature when using the iron. The firmware is also capable of working with irons that use batteries as well as irons that use USB power delivery.

For anyone with a modern smart soldering iron, like the Pinecil or various Miniware iron offerings, this firmware is a great way of being able to gain fine control over the behavior of one’s own soldering iron, potentially above and beyond what the OEM firmware can do. If you’re still using nothing more than a 30W soldering iron that just has a wall plug, take a look at a review we did for the TS100 iron a few years ago to see what you’re missing out on.

Photo via Wikimedia Commons

A Deep Dive On Battery Life

July 28, 2023 by 12 Comments

There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.

[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.

While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.

Remote Code Execution On An Oscilloscope

July 17, 2023 by 10 Comments

There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.

The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a curl command directed at the oscilloscope.

In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.