A standard-compliant MXM card installed into a laptop, without heatsink

MXM: Powerful, Misused, Hackable

April 18, 2024 by Arya Voronova 29 Comments

Today, we’ll look into yet another standard in the embedded space: MXM. It stands for “Mobile PCI Express Module”, and is basically intended as a GPU interface for laptops with PCIe, but there’s way more to it – it can work for any high-power high-throughput PCIe device, with a fair few DisplayPort links if you need them!

You will see MXM sockets in older generations of laptops, barebones desktop PCs, servers, and even automotive computers – certain generations of Tesla cars used to ship with MXM-socketed Nvidia GPUs! Given that GPUs are in vogue today, it pays to know how you can get one in low-profile form-factor and avoid putting a giant desktop GPU inside your device.

I only had a passing knowledge of the MXM standard until a bit ago, but my friend, [WifiCable], has been playing with it for a fair bit now. On a long Discord call, she guided me through all the cool things we should know about the MXM standard, its history, compatibility woes, and hackability potential. I’ve summed all of it up into this article – let’s take a look!

This article has been written based on info that [WifiCable] has given me, and, it’s also certainly not the last one where I interview a hacker and condense their knowledge into a writeup. If you are interested, let’s chat!

Continue reading “MXM: Powerful, Misused, Hackable” →

Human-Interfacing Devices: HID Over I2C

April 17, 2024 by Arya Voronova 22 Comments

In the previous two HID articles, we talked about stealing HID descriptors, learned about a number of cool tools you can use for HID hacking on Linux, and created a touchscreen device. This time, let’s talk about an underappreciated HID standard, but one that you might be using right now as you’re reading this article – I2C-HID, or HID over I2C.

HID as a protocol can be tunneled over many different channels. If you’ve used a Bluetooth keyboard, for instance, you’ve used tunneled HID. For about ten years now, I2C-HID has been heavily present in laptop space, it was initially used in touchpads, later in touchscreens, and now also in sensor hubs. Yes, you can expose sensor data over HID, and if you have a clamshell (foldable) laptop, that’s how the rotation-determining accelerometer exposes its data to your OS.

This capacitive touchscreen controller is not I2C-HID, even though it is I2C. By [Raymond Spekking], CC-BY-SA 4.0

Not every I2C-connected input device is I2C-HID. For instance, if you’ve seen older tablets with I2C-connected touchscreens, don’t get your hopes up, as they likely don’t use HID – it’s just a complex-ish I2C device, with enough proprietary registers and commands to drive you crazy even if your logic analysis skills are on point. I2C-HID is nowhere near that, and it’s also way better than PS/2 we used before – an x86-only interface with limited capabilities, already almost extinct from even x86 boards, and further threatened in this increasingly RISCy world. I2C-HID is low-power, especially compared to USB, as capable as HID goes, compatible with existing HID software, and ubiquitous enough that you surely already have an I2C port available on your SBC.

In modern world of input devices, I2C-HID is spreading, and the coolest thing is that it’s standardized. The standardization means a lot of great things for us hackers. For one, unlike all of those I2C touchscreen controllers, HID-I2C devices are easier to reuse; as much as information on them might be lacking at the moment, that’s what we’re combating right now as we speak! If you are using a recent laptop, the touchpad is most likely I2C-HID. Today, let’s take a look at converting one of those touchpads to USB HID.

A Hackable Platform

Continue reading “Human-Interfacing Devices: HID Over I2C” →

The mod as installed into the handheld, complete with the custom 3D-printed back, with a screwdriver being used to install one of the screws

A ROG Ally Battery Mod You Ought To Try

April 17, 2024 by Arya Voronova 4 Comments

Today’s hack is an unexpected but appreciated contribution from members of the iFixit crew, published by [Shahram Mokhtari]. This is an ROG Ally Asus-produced handheld gaming console mod that has you upgrade the battery to an aftermarket battery from an Asus laptop to double your battery life (40 Wh to 88 Wh).

There are two main things you need to do: replace the back cover with a 3D printed version that accommodates the new battery, and move the battery wires into the shell of an old connector. No soldering or crimping needed — just take the wires out of the old connector, one by one, and put them into a new connector. Once that is done and you reassemble your handheld, everything just works; the battery is recognized by the OS, can be charged, runs the handheld wonderfully all the same, and the only downside is that your ROG Ally becomes a bit thicker.

Continue reading “A ROG Ally Battery Mod You Ought To Try” →

Logic Analyzers: Decoding And Monitoring

April 15, 2024 by Arya Voronova 8 Comments

Last time, we looked into using a logic analyzer to decode SPI signals of LCD displays, which can help us reuse LCD screens from proprietary systems, or port LCD driver code from one platform to another! If you are to do that, however, you might find a bottleneck – typically, you need to capture a whole bunch of data and then go through it, comparing bytes one by one, which is quite slow. If you have tinkered with Pulseview, you probably have already found an option to export decoded data – all you need to do is right-click on the decoder output and you’ll be presented with a bunch of options to export it. Here’s what you will find:

2521888-2521888 I²C: Address/data: Start 2521896-2521947 I²C: Address/data: Address write: 22 2521947-2521954 I²C: Address/data: Write 2521955-2521962 I²C: Address/data: ACK 2521962-2522020 I²C: Address/data: Data write: 01 2522021-2522028 I²C: Address/data: ACK 2522030-2522030 I²C: Address/data: Start repeat 2522038-2522089 I²C: Address/data: Address read: 22 2522089-2522096 I²C: Address/data: Read 2522096-2522103 I²C: Address/data: ACK 2522104-2522162 I²C: Address/data: Data read: 91 2522162-2522169 I²C: Address/data: NACK 2522172-2522172 I²C: Address/data: Stop

Whether on the screen or in an exported file, the decoder output is not terribly readable – depending on the kind of interface you’re sniffing, be it I2C, UART or SPI, you will get five to ten lines of decoder output for every byte transferred. If you’re getting large amounts of data from your logic analyzer and you want to actually understand what’s happening, this quickly will become a problem – not to mention that scrolling through the Pulseview window is not a comfortable experience.

The above output could look like this: 0x22: read 0x01 ( DEV_ID) = 0x91 (0b10010001). Yet, it doesn’t, and I want to show you how to correct this injustice. Today, we supercharge Pulseview with a few external scripts, and I’ll show you how to transfer large amounts of Sigrok decoder output data into beautiful human-readable transaction printouts. While we’re at it, let’s also check out commandline sigrok, avoiding the Pulseview UI altogether – with sigrok-cli, you can easily create a lightweight program that runs in the background and saves all captured data into a text file, or shows it on a screen in realtime! Continue reading “Logic Analyzers: Decoding And Monitoring” →

Logic analyzer capture, showing the rails constantly oscillating at a high rate

When Your Level Shifter Is Too Smart To Function

April 13, 2024 by Arya Voronova 9 Comments

By now, 3.3V has become a comfortable and common logic level for basically anything you might be hacking. However, sometimes, you still need to interface your GPIOs with devices that are 5 V, 1.8 V, or something even less common like 2.5 V. At this point, you might stumble upon autosensing level shifters, like the TXB010x series Texas Instruments produces, and decide that they’re perfect — no need to worry about pin direction or bother with pullups. Just wire up your GPIOs and the two voltage rails you’re good to go. [Joshua0] warns us, however, that not everything is hunky dory in the automagic shifting world.

During board bring-up and multimeter probing, he found that the 1.8 V-shifted RESET signal went down to 1.0V — and its 3.3 V counterpart stayed at 2.6V. Was it a current fight between GPIOs? A faulty connection? Voltage rail instability? It got more confusing as the debugging session uncovered the shifting operating normally as soon as the test points involved were probed with the multimeter in a certain order. After re-reading the datasheet and spotting a note about reflection sensitivity, [Joshua0] realized he should try and probe the signals with a high-speed logic analyzer instead.

Continue reading “When Your Level Shifter Is Too Smart To Function” →

Ultimate Power: Lithium-Ion Packs Need Some Extra Circuitry

April 8, 2024 by Arya Voronova 19 Comments

A LiIon pack might just be exactly what you need for powering a device of yours. Whether it’s a laptop, or a robot, or a custom e-scooter, a CPAP machine, there’s likely a LiIon cell configuration that would work perfectly for your needs. Last time, we talked quite a bit about the parameters you should know about when working with existing LiIon packs or building a new one – configurations, voltage notations, capacity and internal resistance, and things to watch out for if you’re just itching to put some cells together.

Now, you might be at the edge your seat, wondering what kind of configuration do you need? What target voltage would be best for your task? What’s the physical arrangement of the pack that you can afford? What are the safety considerations? And, given those, what kind of electronics do you need?

Picking The Pack Configuration

Pack configurations are well described by XsYp:X serial stages, each stage having Y cells in parallel. It’s important that every stage is the same as all the others in as many parameters as possible – unbalanced stages will bring you trouble.

To get the pack’s nominal voltage, you multiply X (number of stages) by 3.7 V, because this is where your pack will spend most of its time. For example, a 3s pack will have 11.1 V nominal voltage. Check your cell’s datasheet – it tends to have all sorts of nice graphs, so you can calculate the nominal voltage more exactly for the kind of current you’d expect to draw. For instance, the specific cells I use in a device of mine, will spend most of their time at 3.5 V, so I need to adjust my voltage expectations to 10.5 V accordingly if I’m to stack a few of them together.

Now, where do you want to fit your pack? This will determine the voltage. If you want to quickly power a device that expects 12 V, the 10.5 V to 11.1 V of a 3s config should work wonders. If your device detects undervoltage at 10.5V, however, you might want to consider adding one more stage.

How much current do you want to draw? For the cells you are using, open their spec sheet yet again, take the max current draw per cell, derate it by like 50%, and see how many cells you need to add to match your current draw. Then, add parallel cells as needed to get the capacity you desire and fit the physical footprint you’re aiming for. Continue reading “Ultimate Power: Lithium-Ion Packs Need Some Extra Circuitry” →

The line injector shown characterising the PSRR of an AMS1117 regulator, with a bunch of stuff connected to it through SMA jacks

A Simple Line Injector Shows You The Wonderful World Of PSRR

April 5, 2024 by Arya Voronova 8 Comments

[limpkin] writes us to show a line injector they’ve designed. The principle is simple — if you want to measure how much PSU noise any of your electronic devices let through, known as PSRR (Power Supply Rejection Ratio), you can induce PSU noise with this board, and then measure noise on your device’s output. The board is likewise simple. A few connectors, resistors, and caps, and a single N-FET!

You do need a VNA, but once you have that, you get a chance to peek into an entire world of insights. Does that 1117 LDO actually filter out noise better than a buck regulator? Is it enough to use a Pi filter for that STM32’s ADC rail, and do the actual parts you’re using actually help with that task? How much noise does your device actually let through in the real world, after being assembled with the specific components you’ve picked? [limpkin] shows us a whole bunch of examples – putting regulators, filters and amplifiers to the test, and showing us how there’s more than meets the eye.

Everything is open source, with full files available on the blog. And, if you want it pre-assembled, tested and equipped with the CNC-milled case, you can get it on Tindie or Lektronz! Of course, even without a tool like this, you can still get good filter designs done with help of computer-aided modelling.

We thank [alfonso] for sharing this with us!