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!

The I2C extender board on a white background, fully assembled, with two connectors and two indicator LEDs

Extenders And Translators For Your I2C Toolkit

April 5, 2024 by Arya Voronova 5 Comments

If you’ve ever been laying out a network I2C devices inside a project box or throughout your robot’s body, you’ll probably know that I2C is not without its pitfalls. But for many of those pitfalls, there’s a handy chip you can use. [Roman Dvořák] from ThunderFly has experienced it on their drone building journeys, and that’s why they bring us two wonderful open source hardware boards: an I2C bus extender, and an I2C address translator.

The first board, an I2C bus extender, is based around the TCA4307 chip, and not only it lets you extend the bus further than it would normally go, it would also protect you. When the bus capacity is no longer handleable by your devices, or a particular misbehaving device gets the bus stuck, this chip will take care of it and dissipate your troubles. It will even let you know when your bus is wired up correctly, with a handy shine-through LED!

The second board is an I2C address translator. We’ve covered them before, but in short, address translators let you avoid I2C address conflicts while using multiple devices that share the same address. This particular module uses the LTC4317 chip, a common choice for such translation, and the board leaves no feature unimplemented. In the README, there’s quite a few pictures with examples of where this sensor proves mighty useful, too!

It appears that ThunderFly open sources a lot of their designs on GitHub, an effort that we salute. The designs are great to learn from, but if you’re just looking for turn-key hardware, you can get both of these boards from their Tindie store. The cables they use have locking connectors, but as long as the pinout matches, you should be able to solder a JST-SH socket and add these modules to your QWIIC toolkit.

The assembled PCB on red foam, with both a USB-C connector and the ASM2464PD chip visible

Finally Taming Thunderbolt With Third-Party Chips

April 4, 2024 by Arya Voronova 16 Comments

Thunderbolt has always been a functionally proprietary technology, held secret by Intel until “opening” the standard in a way that evidently wasn’t enough for anyone to meaningfully join in. At least, until last year, when we saw announcements about ASMedia developing two chips for Thunderbolt use. Now, we are starting to see glimmers of open source, letting us tinker with PCIe at prices lower than $100 per endpoint.

In particular, this board from [Picomicro] uses the ASM2464PD — a chipset that supports TB3/4/USB4, and gives you a 4x PCIe link. Harnessing the 40 Gbps power to wire up an NVMe SSD, this board shows us it’s very much possible to design a fully functional ASM2464PD board without the blessing of Intel. With minimal footprint that barely extends beyond the 2230 SSD it’s designed for, curved trace layout, and a CNC-milled case, this board sets a high standard for a DIY Thunderbolt implementation.

The main problem is that this project is not open-source – all we get is pretty pictures and a bit of technical info. Thankfully, we’ve also seen [WifiCable] take up the mantle of making this chip actually hobbyist-available – she’s created a symbol, fit a footprint, and made an example board in KiCad retracing [Picomicro]’s steps in a friendly fashion. The board is currently incomplete because it needs someone to buy an ASM2464PD enclosure on Aliexpress and reverse-engineer the missing circuitry, but if open-source Thunderbolt devices are on your wish list, this is as close as you get today – maybe you’ll be able to make an eGPU adapter, even. In the meantime, if you don’t want to develop hardware but want to take advantage of Thunderbolt, you can build 10 Gbps point-to-point networks.

USB HID And Run Exposes Yet Another BadUSB Surface

April 4, 2024 by Arya Voronova 20 Comments

You might think you understand the concept of BadUSB attacks and know how to defend it, because all you’ve seen is opening a terminal window. Turns out there’s still more attack surface to cover, as [piraija] tells us in their USB-HID-and-run publication. If your system doesn’t do scrupulous HID device filtering, you might just be vulnerable to a kind of BadUSB attack you haven’t seen yet, rumoured to have been the pathway a few ATMs got hacked – simply closing the usual BadUSB routes won’t do.

The culprit is the Consumer Control specification – an obscure part of HID standard that defines media buttons, specifically, the “launch browser” and “open calculator” kinds of buttons you see on some keyboards, that operating systems, surprisingly, tend to support. If the underlying OS you’re using for kiosk purposes isn’t configured to ignore these buttons, they provide any attacker with unexpected pathways to bypass your kiosk environment, and it works astonishingly well.

[piraija] tells us that this attack provides us with plenty of opportunities, having tested it on a number of devices in the wild. For your own tests, the writeup has Arduino example code you can upload onto any USB-enabled microcontroller, and for better equipped hackers out there, we’re even getting a Flipper Zero application you can employ instead. While we’ve seen some doubts that USB devices can be a proper attack vector, modern operating systems are more complex and bloated than even meets the eye, often for hardly any reason – for example, if you’re on Windows 10 or 11, press Ctrl+Shift+Alt+Win+L and behold. And, of course, you can make a hostile USB implant small enough that you can build them into a charger or a USB-C dock.

USB image: Inductiveload, Public domain.