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 practice that regularly results in perma-bricked smart devices, though we’ve been seeing some examples 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.

[Header image courtesy of Sleep Number]

There are so many new cool MCUs coming out, and you want to play with all of them, but, initially, they tend to be accessible as bare chips. Devboards might be hard to get, not expose everything, or carry a premium price. [Willmore] has faced this problem with an assortment of new WCH-made MCUs, and brings us all a solution – a universal board for TSSOP20-packaged MCUs, breadboard-friendly and adaptable to any pinout with only a few jumpers on the underside.

The board brings you everything you might want from a typical MCU breakout – an onboard 3.3V regulator, USB series resistors, a 1.5K pullup, decoupling capacitors, and a USB-C port. All GPIOs are broken out, and there’s a separate header you can wire up for all your SWD/UART/USB/whatever needs – just use the “patch panel” on the bottom of the board and pick the test points you want to join. [Willmore] has used these boards for the CH32Vxxx family, and they could, no doubt, be used for more – solder your MCU on, go through the pin table in the datasheet, do a little point-to-point wiring, and you get a pretty functional development board.

Everything is open-source – order a few of these boards from your fab of choice, and you won’t ever worry about a breakout for a TSSOP20 MCU or anything that would fit the same footprint. It could even be used in a pinch for something like an I2C GPIO expander. This is also a technique worth keeping in mind – a step above the generic footprint breakouts. Looking for more universal breakouts to keep? Here’s one for generic LCD/OLED panel breakouts.

If you’re pairing a tiny Linux computer to a few peripherals — perhaps you’re building a reasonably custom Pi-powered device — it’s rightfully tempting to use something like an STM32 for all your low-level tasks, from power management to reading keyboard events.

Now, in case you were wondering how to tie the two together, consider HID over I2C, it’s a standardized protocol with wide software and peripheral support, easily implementable and low-power. What’s more, [benedekkupper] gives you an example STM32 project with a detailed explanation on how you too can benefit from the protocol.

There are several cool things about this project. For a start, its code is generic enough that it will port across the entire STM32 lineup nicely. Just change the pin definitions as needed, compile it, flash it onto your devboard and experiment away. Need to change the descriptors? The hid-rdf library used lets you define a custom descriptor super easily, none of that building a descriptor from scratch stuff, and it even does compile-time verification of the descriptor!

The project has been tested with a Raspberry Pi 400, and [benedekkupper] links a tutorial on quickly adding your I2C-HID device on an Linux platform; all you need is DeviceTree support. Wondering what’s possible with HID? We’ve seen hackers play with HID aplenty here, and hacking on the HID standard isn’t just for building keyboards. It can let you automate your smartphone, reuse a laptop touchpad or even a sizeable Wacom input surface, liberate extra buttons on gamepads, or build your own touchscreen display.

While we are used to USB WiFi adapters, embedded devices typically use SDIO WiFi cards, and for good reasons – they’re way more low-power, don’t take up a USB port, don’t require a power-sipping USB hub, and the SDIO interface is widely available. However, SDIO cards and modules tend to be obscure and proprietary beyond reason. Enter ESP-Hosted – Espressif’s firmware and driver combination for ESP32 (press release)(GitHub), making your ESP32 into a WiFi module for either your Linux computer (ESP-Hosted-NG) or MCU (ESP-Hosted-FG). In particular, ESP-Hosted-NG his turns your SPI- or SDIO-connected ESP32 (including -S2/S3/C2/C3/C6 into a WiFi card, quite speedy and natively supported by the Linux network stack, as opposed to something like an AT command mode.

We’ve seen this done with ESP8266 before – repurposing an ESP8089 driver from sources found online, making an ESP8266 into a $2 WiFi adapter for something like a Pi. The ESP-Hosted project is Espressif-supported, and it works on the entire ESP32 lineup, through an SDIO or even SPI interface! It supports 802.11b/g/n and even Bluetooth, up to BLE5, either over an extra UART channel or the same SDIO/SPI channel; you can even get BT audio over I2S. If you have an SPI/SDIO port free and an ESP32 module handy, this might just be the perfect WiFi card for your Linux project!

There are some limitations – for instance, you can’t do AP mode in the NG (Linux-compatible) version. Also, part of the firmware has blobs in it, but a lot of the firmware and all of the driver are modifiable in case you need your ESP32 to do even more than Espressif has coded in – this is not fully open-source firmware, but it’s definitely way more than the Broadcom’s proprietary onboard Raspberry Pi WiFi chip. There’s plenty of documentation, and even some fun features like raw transport layer access. Also, of note is that this project supports ESP32-C6, which means you can equip your project with a RISC-V-based WiFi adapter.

Title image from [zhichunlee].

This article was prompted by a friend of mine asking for help on a board with an ESP32 heart. The board outputs 2.1 V instead of 3.3 V, and it doesn’t seem like incorrectly calculated feedback resistors are to blame – let’s take a look at the layout. Then, let’s also take a look at a recently sent in design review entry, based on an IC that looks perfect for all your portable Raspberry Pi needs!

What Could Have Gone Wrong?

Here’s the board in all its two-layer glory. This is the kind of board you can use to drive 5 V or 12 V Neopixel strips with a firmware like WLED – exactly the kind of gadget you’ll want to use for LED strip experiments! 3.3 V power is provided by a Texas Instruments TPS54308 IC, and it’s the one misfiring, so let’s take a look.

The design has an ESP32 on the opposite side of the switching regulator. For review purposes, let’s pull the regulator circuit out – disable all front layers (copper, silk, mask, courtyard and paste), hide vias, then box select the regulator circuit and move it out. I’ve also added net labels to the circuit – here’s a screenshot.

There are things done right here, for sure, and a few things that could be the culprit in improper regulation. If you want hints, you can see TPS54308 datasheet, page 22, for layout recommendations. Both SW and FB nodes are pretty long, and the FB trace goes right next to VOUT – before regulation.

Furthermore, from the pinout and also the layout recommendations, it appears this regulator is designed in a way that all switching circuitry can be. Yet, this design has the inductor go all the way to supposedly sensitive side. Thankfully, this is easy to fix.

Refresher – FB and SW traces have to be as short as possible, inductor as close to SW as possible, and the VOUT to FB connection can be a separate tracks on the other layer. With that in mind, let’s move the inductor to the other side of the regulator, move the FB resistors to the FB pin, and see how far we get.

My Take Versus TI’s Recommendation

This is my take. FB resistors moved to one side, switching components to the other, VOUT track on another layer. Add capacitors and vias as necessary, and pull tracks under components to get extra ground connections if needed. Of course, ideally, SW would be a copper polygon, and so would be VOUT. I’m also showing how EN could be pulled out, in case you needed that – in this particular schematic, EN can be safely left floating, but most regulators will want you to pull it either to VIN or to GND.

Since this is a TI chip, it also has a diagram for the layout recommendation! Let’s take a look how far off the mark we are, and it appears we aren’t that far. Curiously, it wants us to put SW onto another layer. Having switching current pass through extra inductance doesn’t sit right with me, personally, but my guess is that they want to minimize switching current flowing under the regulator, as the recommendation suggests.

Another part that’s curious to me, is a suggestion for a Kelvin connection for the FB net’s GND pin. TI also publishes data for evaluation boards, and the TPS54308 has such a board indeed. Seeing on the page 13 of the evaluation board datasheet, I’m not quite seeing a Kelvin connection, unless Kelvin is the name of the engineer involved in designing the board. I do see that GND is tapped with a via far away from the area where switching happens, so it might just be that.

At this point, I’m curious whether my take is a dealbreaker, but since TI’s recommendations are available, I might just end up implementing exactly that and sending the files back. So, we take this circuit, implant it back into the board, order a new revision, and keep our fingers crossed.

A Pi-suited UPS, On A Stamp

A week ago, [Lukilukeskywalker] has shared a board with us, asking for a design review. The board is a stamp that houses a LTC4040 chip, and the chip itself is a treat. It takes 5 V, outputs 5 V, and when connected, it generates 5 V from a battery. It supports both regular LiIon, can do up to 2.5 A, and appears to be a perfect option if you want to power a Raspberry Pi or any other 5 V-powered SBC on the go.

There are a few small nits to pick on this board. For instance, the connector for the battery is JST-SH, 3-pin, with one pin for BATT+. 2.5 A at 5 V means 12.5 W means up to 4 A at 3.5 V battery level, which might just melt a JST-SH connector or the gauge of wire you can attach to a JST-SH-sized metal contact. However, it’s switching regulator time, so let’s take a look at that specifically.

Here’s another thing you might notice immediately – lack of ground path from the IC’s ground connections, all the way under the switching path. In particular, the switching path is broken by a few traces, and it doesn’t appear that these traces must be there! Page 22 in the LTC4040 datasheet, which lists the layout recommendations, also stresses upon this, elaborating that “High frequency currents in the hot loop tend to flow along a mirror path on the ground plane which is directly beneath the incident path on the top plane of the board”.

Well, there are only two tracks that really interrupt the switching path above them, and both could be moved to the left. One of them is for a resistor that sets the charging current limit, and another goes to a castellated pad. Moving the latter is going to break the symmetry, but remember – it’s okay for a stamp to be asymmetric, that helps you ensure it’s mounted on your board correctly!

Sadly, while Linear Tech makes fancy tech, their evaluation board data isn’t as available as TI’s – there’s a PDF with schematics, but no layout data I could find. However, comparing to the pictures, you can see that the general layout of the switching area is correct, our hacker correctly uses polygons, the feedback circuit is pretty nice – it’s just these two tracks that are a bit uncouth when it comes to the switching regulator part of it. As for reviewing the rest of the board, you can read this article!

Towards A Powerful Future

Got switching regulator designs that didn’t quite work right when you put them to test, or that you’re yet to order and feel cautious about? Show them to us down below in the comments, and let’s take a look; your circuits deserve to operate at their best capacity possible.

And, as usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.

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!

We thank [linalinn] for sharing this with us!

Some hacks are implemented well enough that they can imitate involved and bespoke parts with barely any tools. [CodeName X]’s Thinkpad X1 Tablet Keyboard to USB adapter is one such hack – it let’s one reuse, with nothing more than a 3D printed part and a spare USB cable, a keyboard intended for the Thinkpad X1 Tablet (2016 or 2017).

The issue is, this keyboard connects through pogo pins and holds onto the tablet by magnets, so naturally, you’d expect reusing it to involve a custom PCB. Do not fret – our hacker’s take on this only needs aluminum foil and two small circular magnets, pressing the foil into the pins with the help of the printed part, having the USB cable pins make contact with the foil pads thanks to nicely laid out wire channels in the adapter. If you want to learn more, just watch the video embedded below.

Of course, this kind of adapter will apply to other similar keyboards too — there’s no shortage of tablets from last decade that had snap-on magnetic keyboards. But watch out; some will need 3.3V, and quite a few of them will use I2C-HID, which would require a MCU-equipped adapter like this wonderful Wacom rebuild did. Not to worry, as we’ve shown you the ropes of I2C-HID hacking.

[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.

Yet another hands-on course on Ghidra, and a wonderful primer on mouse dongle hacking – after all, if you treat your mouse’s dongle as a development platform, you can easily do things like controlling a small quadcopter, or pair the dongle with a SNES gamepad, or build a nifty wearable.

Do you have a 5 V device you want to run 24/7, no matter whether you have electricity? Not to worry – Linear Technology has made a perfect IC for you, the LTC4040; with the perfect assortment of features, except perhaps for the hefty price tag.

[Lukilukeskywalker] has shared a PCB for us to review – a LTC4040-based stamp you can drop onto your PCB whenever you want a LTC4040 design. It’s a really nice module to see designed – things like LiFePO4 support make this IC a perfect solution for many hacker usecases. For instance, are you designing a custom Pi HAT? Drop this module to give your HAT the UPS capability for barely any PCB effort. if your Pi or any other single-board computer needs just a little bit of custom sauce, this module spices it up alright!

This one is a well-designed module! I almost feel like producing a couple of these, just to make sure I have them handy. If you like the LTC4040, given its numerous features and all, this is also not the only board in town – here’s yet another LTC4040 board that has two 18650 holders, and referencing its PCB design will help me today in this review, you can take a look at it too!

Now, having looked at this PCB for a fair bit, it has a few things that we really do want to take care of. Part of today’s review will be connector selection, another would be the module form-factor, some layout, and some suggestions on sizing the passives – the rows of 1206 components are pretty, but they’re also potentially a problem. Let’s waste no time and delve in.

Battery Wireup And Formfactor

The battery connector uses JST-SH, one pin for VBAT and one for GND. The problem with this is that the module is capable of 2.5 A at 5 V = 12 W. At 3.6 V, that’s 4 A if not more and JST-SH is only rated for 1 A per pin. Using this module with a battery as-intended will melt things. You could add a bigger connector like the standard JST-PH, but that’d increase the module size, and my assessment is that this board doesn’t have to be larger than it already is.

Thankfully, this is an open-source module, so we can change its pinout easily enough, adding pins for the battery into the mix. Currently, this board feels breadboardable, but it isn’t quite – it’s pretty wide, so it will take two breadboards to handle, and a breadboard would also probably be disappointed with the pin amount required. With that in mind, adding pins at the top looks convenient enough.

In general, shuffling the pins around will help a fair bit. My hunch is to make the module’s castellations asymmetric, say, do 7-5-5-5 – one side with seven pins, three sides with five pins. It might not look as perfect, but what’s important is that it will be way way harder to mount incorrectly, something I’ve done with a module of my own design – that was not fun to fix. If you are worried about having enough pins to fill the resulting 22-pin combination, it’s always great to just add GND, doubly so for a power-related module!

Adding more castellations also helps us shuffle the pinout around, freeing up the routing – let’s go through the pins and see what that could help with.

Pinout Changes

The schematic is seriously nice looking – every single block is nicely framed and has its description listed neatly. Comparing it with reference schematic, it looks pretty good!

There’s a few nits to pick. For instance, BST_OFF and CHG_OFF need to be grounded for the IC to work – datasheet page 10. You could ground them through a resistor and pull them onto a castellation, but you can’t leave them floating. This is not easy to notice, however, unless you go through the pins one by one and recheck their wiring; I noticed it because I was looking at the board, saw two unconnected pins and decided to check.

My hunch is that, first, all the pins were given power names, and then two of them were missed as not connected anywhere, which is an understandable mistake to make.

Let’s keep with the schematic style – add two more connectors, one 5-pin and one 7-pin, rearrange the pinout, and keep them in their own nicely delineated area. The 7-pin connector gets the battery pins and a healthy dose of ground, and as for the 5 extra pins at the bottom, they’ll serve as extra ground pins, and give us shuffling slots for pins that are best routed southward.

Components And Placement

Having 1206 resistors on such a module is a double-edged sword. On one hand, given the adjustability, you definitely want resistors that you’d be able to replace easily, so 0402 is not a great option. However, 1206 can actually be harder to replace with a soldering iron, since you need to heat up both sides. The writing is more readable on 1206, no doubt, and it’s also nice that this module is optimized by size. Still, for the sake of routability, I will start by replacing the LEDs and LED resistors with 0603 components – those are resistors you will not be expected to replace, anyway.

Also, I have a hunch that a few components need to be moved around. First one is the RProg, no doubt – it’s in the way of the switching path, going right under the SW polygon. Then, I will rotate the Rsense resistor so that it’s oriented vertically – it feels like that should make the VIN track less awkward, and show whether there’s any space to be freed on the left.

Resistors replaced, a few components moved, and here’s where the fun begins. The IGATE track is specifically designated in the datasheet as pretty sensitive, to the point the PDF talks about leakage from this track to the other tracks – it is a FET gate driver output, after all. Having it snake all around power tracks feels uncomfortable I’d like to refactor these FETs a bit, and see if I can make the IGATE track a bit more straightforward, perhaps also make the space usage on the left more optimized. While doing that, I will be shuffling pins between the castellated edges every now and then.

After a bit of shuffling and component rerouting, it felt like I wasn’t getting anywhere. It was time to try and reconstruct the circuit in the way it could make sense, prioritizing the power path and starting with it. For that, I pulled out both FETs, current sense resistor and the feedback divider out of the circuit, and tried rearranging them until it looked like they would work.

Following quite a few attempts at placing the components, I had to settle on the last one. I_GATE took quite a detour, though I did route it via-less in the end; VIN and CLN went on the bottom layer to give room to I_GATE (and be able to cross each other), and all the non-sensitive signals went into vias so that they could be routed outside of the switching area. It turned out the pinout is seriously not conducive to a neat layout; I suppose, some chips are just like that. Perhaps, it was that the gate driver only could’ve had been located on this particular, so that’s why the IGATE pin is on the opposite side of where the FET could be, instead of it, say, being next to V_SYS outputs.

Post-Redesign Clarity

Is the board better now? In many ways, yes; in some ways, no. I don’t know that it’s necessarily prettier, if that makes sense, there were certainly things about the board’s original state that were seriously nice. The package chosen for the FETs definitely didn’t help routing with my I_GATE target in mind, giving no leeway to route things between pins; if I were to change them to DFN8, I could indeed more easily provide a VSYS guard track that the datasheet suggests you use for I_GATE.

I’ve also rearranged the pinout quite a bit. That does mean the STATUS/POWER side distinction of the original board no longer works, but now pins don’t have to go across the board, cutting GND in half. After looking into the datasheet, I didn’t find any use for the CSN pin being broken out, since it’s just a sense resistor net; that space is now occupied by a GND pin, and there’s one less track to route out.

There’s now a good few GND pins on the board – way more than you might feel like you need; the right header feels particularly empty. If you wanted, you could add a Maxim I2C LiIon fuel gauge onto the board, since there’s now enough space in the top right, and quite a few free pins on the right. This would let your UPS-powered device also query the UPS’s status, for one. Of course, such things can always be added onto the actual board that the module would mount onto.

I also removed designators about things that felt too generic – specifically, resistors that only have one possible value and won’t need to be replaced, like LED resistors and pullups for mode selection jumpers. All in all, this board is now a little easier to work with, and perhaps, its ground distribution is a little better.

This module’s idea, and both its authors and my implementation are seriously cool! I hope I’ve helped make it cooler, if at least in the battery connector department. Both the pre-review and post-review versions are open-source, so you can also base your own castellated module off this board if you desire – it’s a good reference design for both LTC4040 and also self-made castellated modules. It’s only 30 mm x 30 mm, too, so it will be very cheap to get made. I hope my input can make this module all that cooler, and, at this point, I want to make a board around this module – stay tuned!

As usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.

We would not be surprised if DSI screens made up the majority of screens on our planet at this moment in time. If you own a smartphone, there’s a 99.9% chance its screen is DSI. Tablets are likely to use DSI too, unless it’s eDP instead, and a smartwatch of yours definitely will. In a way, DSI displays are inescapable.

This is for a good reason. The DSI interface is a mainstay in SoCs and mobile CPUs worth their salt, it allows for higher speeds and thus higher resolutions than SPI ever could achieve, comparably few pins, an ability to send commands to the display’s controller unlike LVDS or eDP, and staying low power while doing all of it.

There’s money and power in hacking on DSI – an ability to equip your devices with screens that can’t be reused otherwise, building cooler and cooler stuff, tapping into sources of cheap phone displays. What’s more, it’s a comparably underexplored field, too. Let’s waste no time, then!

Decently Similar Internals

DSI is an interface defined by the MIPI Alliance, a group whose standards are not entirely open. Still, nothing is truly new under the sun, and DSI shares a lot of concepts with interfaces we’re used to. For a start, if you remember DisplayPort internals, there are similarities. When it comes to data lanes, DSI can have one, two or four lanes of a high-speed data stream; smaller displays can subsist with a single-lane, while very high resolution displays will want all four. This is where the similarities end. There’s no AUX to talk to the display controller, though – instead, the data lanes switch between two modes.

The first mode is low-speed, used for sending commands to the display, like initialization sequences, tweaking the controller parameters, or entering sleep mode. You can capture this with a logic analyzer. If you’ve ever sniffed communications of an SPI display, you will find that there are many similarities with how DSI commands are sent – in fact, many SPI displays use a command set defined by the MIPI Alliance that DSI displays also use. (If your Sigrok install lists a DSI decoder, don’t celebrate too soon – it’s an entirely different kind of DSI.)

The second mode is high-speed, and it’s the one typically used for pixel transfer. A logic analyzer won’t do here, at least not unless it’s seriously powerful when it comes to capture rate. You will want to use a decent scope for working with high-speed DSI signals, know your way around triggers, and perhaps make a custom PCB tap with a buffer for the the DSI signal so that your probe doesn’t become a giant stub, and figure out a way to work with the impedance discontinuities. Still, it is very much possible to tap into high-speed DSI, like [Wenting Zhang] has recently demonstrated, sometimes an approximation of the high-speed signal is more than enough for reverse-engineering.

Got a datasheet for your panel? Be careful – the initialization sequence in it might be wrong; if your bringup is not successful or your resulting image is weird, this just might be the culprit, so even if you have procured the correct PDF, you might still end up having to capture the init sequence with a logic analyzer. Whether your display’s initialization are well-known, or you end up capturing them from a known-working device, you will need something to drive your display with – a typical Arduino board will no longer do; though, who knows, an RP2040 just might, having seen what you all are capable of.

Ideally, you will want a microcontroller or a CPU that has a DSI peripheral, with decent documentation and/or examples on how to use it – that part is important. Linux-capable Raspberry Pi boards can help you here a surprising amount – you may remember the Raspberry Pi DSI header as being proprietary, but that was only true initially. With developments like the official Raspberry Pi screen and open-source graphics drivers aided by that $10k driver bounty they put out, it became viable to connect custom screens. WaveShare DSI screens are a known alternative if you want to get a DSI display for your Pi. On the regular Pi, you only get two lanes of DSI, but that is good enough for many a display. Funnily enough, you can get a third-party display for your Pi that uses the same panel, with two extra chips that seem to run the display without a driver like the official Pi display (this thread on these displays is fascinating!); the display is still limited to the same resolution, the only advantage is a slightly lower price, and the ability to overload your 3.3V rail is a questionable benefit. It’s not quite clear why this display exists, but you might want to resist the temptation.

If you’re using a Pi Compute Module, you get entire two DSI peripherals to play with, one four-lane and one two-lane, and it doesn’t take long to find a good few examples of Raspberry Pi Compute Module boards with DSI screens. If you have a Compute Module and its devboard somewhere on a shelf, you can do four-lane DSI, with a Linux-exposed interface that works in the same way alternative OSes do on your phone. Given that CMs are typically used for custom stuff and a hacker using one is more likely to have patience for figuring out DSI panel parameters, a Compute Module baseboard is a pretty popular option to hack on that one cheap DSI display from a tablet that caught your eye! Don’t have a baseboard? You can even etch one, here’s a single-layer breakout with a DSI socket. Not that you don’t need a Compute Module if you’re doing two-lane DSI: a regular Pi will do.

So, get out there and hack – there is a ton of unexplored potential in the never-ending supply of aftermarket screens for older iPhone and Samsung models!  Speaking of phones, they are the forefront of DSI hacking, as you might suspect, thanks to all the alternative OS projects and Linux kernel mainlining efforts. You can enjoy fruits of their labour fairly easily, sparing you a logic analyzer foray – reusing a seriously nice DSI display might be as easy as loading a kernel module.

Want A Panel? Linux Is Here To Help

There’s a fun hacker tactic – if you’re looking for an I2C GPIO expander chip, you can scroll through the Linux kernel config file that lists supported GPIO expanders, and find a good few ICs you’ve never known about! What’s great is, you know you’re getting a driver, too.

The same goes for DSI screens, except the payoff is way higher. If you’re on the market for a DSI screen, you can open the list of Linux kernel drivers for various DSI panels. Chances are, all you need is just the physical wireup part, maybe some backlight driving, and a Device Tree snippet.

Want a $20 1920 x 1200 IPS display for your Compute Module? Who doesn’t! Well, wouldn’t you know, the Google Nexus 7 tablet uses one, and the driver for it is in mainline Linux! Just solder together a small FPC-to-bespoke-connector adapter board (or order PCBA), add a Device Tree snippet into your configuration, and off you go; there are even custom boards for using this display with a CM4, it’s that nice.

New displays get added into the kernel all the time; all it takes is someone willing to poke at the original firmware, perhaps load a proprietary kernel module into Ghidra and pull out the initialization sequence, or simply enable the right kind of debug logging in the stock firmware. All of this is thanks to tireless efforts of people trying to make their phones work beyond the bloatware-ridden shackles of the stock Android OS; sometimes, it’s some company doing the right thing and upstreaming a driver for a panel used by hundreds of thousands of devices in the wild.

There are some fun nuances in the display scene, as much as of a “scene” it is – people are just trying to make their devices work for them, then share that work with other people in the same situation, figuring out a display is part of the process. It’s not uncommon that a smartphone will use slightly different screens in the same batch – it’s an uncommon but real issue with alternative OSes like LineageOS, where, say, 10% of your firmware’s users might have their panel malfunction because, despite the phone listing the same model on the lid, their specific phones use a display with a different controller, that only the manufacturer’s firmware properly accounts for.

Our DSI Role Models

These are the basics of what you need to reuse DSI displays as if effortlessly. Now, I’d like to highlight a good few examples of people hacking on DSI, from our coverage and otherwise.

Without a doubt, the first one that springs to mind is [Mike Harrison] aka [mikeselectricstuff], from way back in 2013. I’ve spent a lot of time with the exact iPod Nano being reverse-engineered, and [Mike]’s videos gave me insight into a piece of tech I relied on for a fair bit. For instance, in this video, [Mike] masterfully builds a scoping jig, solders microscoping wires to the tiny PCB, walks us through the entire reverse-engineering process, and successfully reuses the LCD for a project.

Following in [Mike]’s footsteps, we’ve even seen this display reused in an ESP32 project, thanks to a parallel RGB to DSI converter chip!

[Wenting Zhang] reverse-engineering a Macbook Touchbar display is definitely on my favourites list. In this short video, he teaches us DSI fundamentals, and manages to show the entire reverse-engineering process from start to end., no detail spared. Having just checked the video description, the code is open-source, and it’s indeed a RP2040 project – just like I forecasted a good few paragraphs above.

Are mysterious ASICs your vibe, and would you like to poke at some firmware? You should see this HDMI-to-DSI adapter project, then. The creator even turns it into a powerbank with a built-in screen as a demo – that’s a hacker accessory if I’ve ever seen one. More of a gateware fan? Here’s an FPGA board doing the same, and another one, that you can see here driving a Galaxy S4 screen effortlessly. Oh, and if you are friends with a Xilinx+Vivado combination, there are DSI IP cores for you to use with barely any restrictions.

The Year Of DSI Hacking

DSI is an interface that is becoming increasingly hacker-friendly – the economies of scale are simply forcing our hand, and even the microcontroller makers are following suit. The official devboard for Espressif’s ESP32-P4, a pretty beefy RISC-V chip, sports a DPI interface alongside the now-usual CSI for cameras. We will see DSI more and more, and I raise a glass of water for numerous hackers soon to reap the fields of DSI. May your harvest be plentiful.

I thank [timonsku] for help with this article!

Recently, the Ukrainian government has published a database of Western components being used in recently produced Russian armaments, and it’s a fascinating scroll. Just how much does Russia rely on Western manufacturers’ parts? It turns out, a surprising amount. For instance, if you are wondering which ICs are used to build Iran-produced Shahed drones, it seems that it’s a whole bunch of Texas Instruments parts, as well as some Maxim, Intel, and Xilinx ones. Many of the parts in the lists are MCUs and FPGAs, but it’s also surprising how many of the components are jelly bean parts with multiple suppliers.

There appear to be thousands of parts listings, compiled from a good few dozen pieces of equipment that volunteers appear to have taken apart and scrupulously documented – just take a look at the dropdowns at the top of the page. The Ukrainian government is advocating for parts restrictions to be implemented based upon this data – as we all remember, it’s way harder to produce hardware when you can’t buy crucial ICs.

Even for a regular hacker, this database is worth a scroll, if only to marvel at all the regular parts we wouldn’t quite associate with military use. Now, all that’s left is to see whether any of the specific chips pictured have been sold to washing machine manufacturers.

[sdz] of Vogons forum brings us an unexpected device for the 21st century – a 3dfx Voodoo 4 card in MXM format, equipped with 64MB of RAM. This isn’t just a showpiece – this card actually, properly works when installed into our hacker’s Dell Precision M4800, and [sdz] tells us more on how the card came to be.

Equipped with a VSA-100 GPU, this card has a whole lot of support components for adapting old interfaces to modern ones. There’s a PCIe-PCI bridge IC, an FPGA, HDMI muxes, and a Realtek scaler for video conversion. Handling all the MXM interfaces would’ve been downright impossible, so the card also holds an LVDS header for the M4800’s panel. Plus, for testing all of it, [sdz] has developed a PCIe to MXM adapter board with minimal circuitry needed to have the card work – this is a seriously involved hack and it’s executed remarkably well.

The forum post shows a whole lot of the journey, from receiving the PCBs to code and FPGA gateware bringup, as well as videos of VGA and HDMI operation. In the end, our hacker shows us a fully working setup, the 3dfx card inserted into M4800 and driving its display, as well as overclocking experiments; the author has promised to open-source the card files in due time, too. It’s seriously nice to see DIY MXM cards in the wild, and if you ever wanted to build one, we’ve got an article tells you everything you could want to know about the MXM standard.

We thank [Misel] for sharing this with us!

You know the feeling of having just created a perfect setup for your hacker lab? Sometimes, there’s just this missing piece in the puzzle that requires you to do a small hack, and those are the most tempting. [maxime borges] has such a perfect setup that involves a HDMI 4:2 switch, and he brings us a write-up on integrating that HDMI switch into Home Assistant through emulating an infrared receiver’s signals.

The HDMI switch is equipped with an infrared sensor as the only means of controlling it, so naturally, that was the path chosen for interfacing the ESP32 put inside the switch. Fortunately, Home Assistant provides the means to both receive and output IR signals, so after capturing all the codes produced by the IR remote, parsing their meaning, then turning them into a Home Assistant configuration, [maxime] got HDMI input switching to happen from the comfort of his phone.

We get the Home Assistant config snippets right there in the blog post — if you’ve been looking for a HDMI switch for your hacker lair, now you have one model to look out for in particular. Of course, you could roll your own HDMI switch, and if you’re looking for references, we’ve covered a good few hacks doing that as part of building a KVM.

Our PCBs greatly benefit from cases – what’s with all the pins that can be accidentally shorted, connectors that stick out of the outline, and cables pulling the board into different directions. Designing a case for your PCB might feel like a fair bit of effort – but it likely isn’t, thanks to projects like turbocase from [Martijn Braam].

This script generates simple and elegant OpenSCAD cases for your KiCad PCBs – you only need to draw a few extra lines in the PCB Editor, that’s it. It makes connector openings, too – add a “Height” property to your connector footprints to have them be handled automatically. Oh, and there’s a few quality-of-life features – if your project has mounting holes, the script will add threaded-insert-friendly standoffs to the case; yet another argument for adding mounting holes to your boards, in case you needed more.

Installing the script is a single line, running it is merely another, and that will cover an overwhelming majority of boards out there; the code is all open too, of course. Want some more customization? Here’s some general project enclosure tutorials for OpenSCAD, and a KiCad-friendly StepUp tutorial. Oh, and of course, there’s many more ways to enclose PCBs – our own [Bob Baddeley] has written a guide to project enclosures that you are bound to learn new things from.

We thank [adistuder] for sharing this with us!

MicroPython is a wonderful Python interpreter that runs on many higher-end microcontrollers, from ESP8266 to STM32 to the RP2040. MicroPython lets you build devices quickly, and its latest release, 1.23, brings a number of improvements you should be aware of.

The first one is custom USB device support, and it’s a big one. Do you want to build HID devices, or play with MIDI, or do multiple serial streams with help of PIO? Now MicroPython lets you easily create USB devices on a variety of levels, from friendly wrappers for creating HID or MIDI devices, to low-level hooks to let you define your own USB descriptors, with user-friendly libraries to help all the way through. Currently, SAMD and RP2040 ports are supported in this part of code, but you can expect more in the future.

There’s more – support for OpenAMP, an inter-core communication protocol, has received a ton of improvements for systems where MicroPython reigns supreme on some of the CPU cores but also communicates with different systems on other cores. A number of improvements have made their way through the codebase, highlighting things we didn’t know MicroPython could do – for instance, did you know that there’s a WebAssembly port in the interpreter, letting you run MicroPython in your browser?

Well, it’s got a significant overhaul in this release, so there’s no better time to check it out than now! Library structure has been refactored to improve CPython compatibility, the RP2040 port receives a 10% performance boost thanks to core improvements, and touches upon areas like PIO and SPI interfaces.

We applaud all contributors involved on this release. MicroPython is now a decade old as of May 3rd, and it keeps trucking on, having firmly earned its place in the hacker ecosystem. If you’ve been playing with MicroPython, remember that there are multiple IDEs, graphics libraries, and you can bring your C code with you!

How hard could it be to add an extra USB port inside your laptop? As [Joshua Stein] shows, it can be decently hard, but you will have fun along the way. His journey involves a Thinkpad X1 Nano, and his tech setup means it’d be most comfortable for him to have a USB port inside its case, for a Logitech mouse’s USB receiver. It wasn’t smooth sailing all throughout, but the end result is no doubt beautifully executed.

M.2 B-key, A-key and E-key slots have USB 2.0 available on them – you’d think that’s perfect for such a receiver, and there’s even plug and play adapters for this on places like eBay. Unfortunately, none of these, as Lenovo implements wireless card whitelists to this day. Tinkering with the whitelist on [Joshua]’s laptop resulted in BIOS digital signature check failures, and the USB-connected fingerprint reader was ultimately chosen as the most viable path.

Initially, he’s tested the fingerprint reader with an FPC breakout, having the USB connection work – many a hacker would stop here, pulling a few bodge wires from the breakout. [Joshua], however, raised the bar, creating a flexible PCB that would pull the fingerprint connector signals to a spot in the case where the USB receiver could fit neatly, with a 5 V step-up on the board, too.

[Joshua] tops it off by showing a 3D-printed spacer that goes into now-vacant spot where the fingerprint reader used to be. This mod is not open-source as far as we can see, but it’s definitely an inspiration. Want to put even more USB devices inside your laptop? Perhaps a tiny USB hub would help, in line with the EEE PC mods that aimed to stuff the tiny laptop with the largest amount of USB devices possible.

There’s a good few options for exporting data out of FPGAs, like Ethernet, USB2, or USB3. Many FPGAs have a HDMI (or rather, sparkling DVI) port as well, and [Steve Markgraf] brings us the hsdaoh project — High-Speed Data Acquisition Over HDMI, using USB3 capture cards based on the Macrosilicon MS2130 chipset to get the data from the FPGA right to your PC.

Current FPGA-side implementation is designed for Sipeed Tang chips and the GOWIN toolchain, but it should be portable to an open-source toolchain in the future. Make sure you’re using a USB3 capture card with a MS2130 chipset, load the test code into your FPGA, run the userspace capture side, and you’re ready to add this interface to your FPGA project! It’s well worth it, too – during testing, [Steve] has got data transfer speeds up to 180 MB/s, without the USB3 complexity.

As a test, [Steve] shows us an RX-only SDR project using this interface, with respectable amounts of bandwidth. The presentation goes a fair bit into the low-level details of the protocol, from HDMI fundamentals, to manipulating the MS2130 registers in a way that disables all video conversion; do watch the recording, or at least skim the slides! Oh, and if you don’t own a capture card yet, you really should, as it makes for a wonderful Raspberry Pi hacking companion in times of need.

[befi] brings us a project as impressive as it is reminiscent of older times, a Blu-Ray mini disk player. Easily fitting inside a pocket like a 8 cm CD player would, this is a labour of love and, thanks to [befi]’s skills both in electronics and in using a dremel tool.

A BluRay drive was taken apart, for a start, and a lot of case parts were cut off; somehow, [befi] made it fit within an exceptionally tiny footprint, getting new structural parts printed instead, to a new size. The space savings let him put a fully custom F1C100S-powered board with a number of unique features, from a USB-SATA chip to talk to the BluRay drive, to USB pathway control for making sure the player can do USB gadget mode when desired.

There’s an OLED screen on the side, buttons for controlling the playback, power and battery management – this player is built to a high standard, ready for day-to-day use as your companion, in the world where leaving your smartphone as uninvolved in your life as possible is a surprisingly wise decision. As a fun aside, did you know that while 8 cm CDs and DVDs existed, 8 cm BluRay drives never made it to market? If you’re wondering how is it that [befi] has disks to play in this device, yes, he’s used a dremel here too.

Everything is open-sourced – 3D print files, the F1C100S board, and the Buildroot distribution complete with all the custom software used. If you want to build such a player, and we wouldn’t be surprised if you were, there’s more than enough resources for you to go off. And, if you’re thinking of building something else in a similar way, the Buildroot image will be hugely helpful.

Want some entertainment instead? Watch the video embedded below, the build journey is full of things you never knew you wanted to learn. This player is definitely a shining star on the dark path that is Blu-Ray, given that our most popular articles on Blu-Ray are about its problems.

Sometimes, it’s time to shut down the oscilloscope, and break out the cardboard and paints. If you’re wondering what for, well, here’s a reminder of an Instructable from [CrazyScience], that brings us back to cardboard crafts days. They rebuild one of the most iconic components for an electronics tinkering beginner — an ultrasonic distance sensor, and what’s fun is, it stays fully functional after the rebuild!

This project is as straightforward as it gets, describing all the steps in great detail, and you can complete it with just a hot glue gun and soldering iron. With materials being simple cardboard, aluminum foil, popsicle sticks, some mesh, and a single ultrasonic sensor for harvesting the transmitter and receiver out of, this is the kind of project you could easily complete with your kids on a rainy day.

Now, the venerable ultrasonic sensor joins the gallery of classics given a size change treatment, like the 555 timer we’ve seen two different takes on, or perhaps that one Arduino Uno. Unlike these three, this project’s cardboard skeleton means it’s all that simpler to build your own, what’s with all the shipping boxes we accumulate.