Design Review: USB-C PD Input For Yaesu FRG7700

Today is another board from a friend, [treble], who wants to convert a Yaesu FRG7700 radio to USB-C PD power. It’s yet another review that I’ve done privately, and then realized I’ve made more than enough changes to it, to the point that others could learn from this review quite a bit. With our hacker’s consent, I’m now sharing these things with you all, so that we can improve our boards further and further.

This board’s idea is thought-out and executed well – it replaces a bespoke barrel jack assembly, and is mechanically designed to fit the screw holes and the free space inside the chassis. For USB-PD, it uses a CH32V003 coupled with FUSB302 – I definitely did help pick the latter! For mechanical reasons, this board is split into two parts – one has the USB-C port, whereas the other has the MCU and the PD PHY.

In short, this board is a PD trigger. Unlike the usual PD triggers, however, this one is fully configurable, since it has a 32-bit MCU with good software support, plus, the PD PHY is also well known and easily controllable. So, if you want special behavior like charger-power-dependent profile selection for powering a static resistance load, you can implement it easily – or, say, you can do PPS for variable voltage or even lithium ion battery charging! With a bit of extra code, you could even do EPR (28 V = 140 W power) with this board, instantly making it into a pretty advanced PD trigger, beyond the ones available on the market.

Also, the board has some PCB art, and a very handy filter to get some of the USB-C charger noise out. Let’s take a look at all of these!

Current Flow Improvements

Continue reading “Design Review: USB-C PD Input For Yaesu FRG7700”

DisplayPort: Hacking And Examples

So far, I’ve talked about why DisplayPort is the future, introduced the basics of how to work with it on the hacker level, took apart and tamed the DisplayPort altmode, and recently, went through the eDP (embedded DisplayPort) display technology. This time, I want to give you a project library to reference, so that your hacking goes as smoothly as possible – real-world examples of open-source DisplayPort boards, a few boards I’ve worked on, part numbers, and whatever other information you might need.

Even this wonderful build is not immune from wasting power on unnecessary video conversion

Over the past few years, I’ve noticed that a non-zero amount of cyberdeck builders buy eDP screens with HDMI converter boards on Aliexpress, then connect them to SBCs using USB-C to HDMI adapters, or ignore the onboard eDP port; even this super cool Framework-based cyberdeck has done that! I get that it’s the simplest option, but I do believe that you ought to know how to improve it. The issue is that this double-conversion decreases the battery life significantly by burning two extra ASICs doing video conversion back and forth. Every hour of battery life matters in a cyberdeck, doubly so if it’s based on a low-power device already – you could easily cut your battery life in half if you’re not careful!

With these projects and references in your arsenal, my aim is that DisplayPort becomes way more comfortable for you to work with. Thankfully, there are quite a few projects to reference by now – let’s delve in.

Right out of the gate – are you looking for an SBC with DisplayPort support? The BoardDB website, a database of single-board computers, has a DisplayPort filter – click this link with the filter already enabled and browse through.

Continue reading “DisplayPort: Hacking And Examples”

PCB Design Review: HDMI To LVDS Sony Vaio LCD Devboard

Today, we revisit another board from [Exentio] – a HDMI/DVI to LVDS transmitter for the Sony Vaio P display. This board is cool to review – it has a high-speed serial interface, a parallel interface, a healthy amount of power distribution that can be tricky to route, and many connectors to look over.

I’ve decided to show this review to you all because it demonstrates a PCB improvement concept we haven’t yet touched upon, that you should absolutely know about when doing board layout. Plus, I get a chance to talk about connector choice considerations!

The board is lovely. It integrates the DPI-LVDS circuit we’ve previously reviewed, but also a HDMI to parallel RGB chip from Texas Instruments, TFP401, a chip appreciated enough that even Adafruit has adapters with it. The fun thing about this chip is that it doesn’t even handle EDID like the usual HDMI to RGB/LVDS chips you get on cheap Aliexpress boards. So, there’s no firmware to take care of – it just receives a HDMI/DVI signal, converts it into parallel RGB, then converts that to LVDS, and off to the display it goes. The downside is that you have to provide your own EDID with an EEPROM, but that isn’t that tricky.

Again, this is a two-layer board, and, again, I like this – fitting tracks to the smallest possible space is a respectable and enjoyable challenge. This board has absolutely done well by this challenge. I do see how this board could be routed in an even better way, however, and it could be way way cleaner as a result. For a start, rotating the chip would improve the odds a whole lot.

The Chip Gets Rotated

Continue reading “PCB Design Review: HDMI To LVDS Sony Vaio LCD Devboard”

The film scanner [xssfox] found, in the center of a table, with other stuff strewn across the table

Answering All Your ISCSI Scanner Questions

iSCSI is a widely used protocol for exposing SCSI devices over a network connection, and some scanners have in the past been equipped with SCSI ports. So, could you have an iSCSI network scanner? [xssfox] details her journey making a Canoscan FS4000US film scanner work over iSCSI, sparked by someone’s overly-confident StackOverflow comment that it couldn’t be done. Nothing in the spec said it couldn’t actually work, however, and after figuring out a tentative architecture, a hardware setup was put together.

No flatbed scanners with SCSI ports could be found on the cheap, so a film scanner had to be procured. After figuring out a few hitches with the loading mechanism and getting a test image locally, it was time to try and build up the software setup, tearing through SCSI compatibility and cabling, driver and PCI pass-through woes, bluescreens, and intermediate software having dropped some of the necessary features by now. Still, [xssfox] eventually exported the scanner as an iSCSI target – and, on the other end of the network, successfully connected to it and completed a scan. The StackOverflow answer was wrong, after all.

It’s fun to see how far old technology can go, and get answers to questions you never knew you had. Whether you’re reminiscing about SCSI days or wondering what the technology about, we’ve talked about it aplenty, from a retrospective to modern-day experiments, repurposing old SCSI hardware for modern SATA ports, a Raspberry Pi implementation, an emulator, and a fair bit more.

We thank [Valentijn Sessink] and [adistuder] for sharing this with us!

Pi with the PiFEX shield on the right, the SSD under test on the left with testpoints held by a jumper clip, jumper wires connecting the two together

JTAG Hacking An SSD With A Pi: A Primer

[Matthew “wrongbaud” Alt] is well known around these parts for his hardware hacking and reverse-engineering lessons, and today he’s bringing us a JTAG hacking primer that demoes some cool new hardware — the PiFEX (Pi Interface Explorer). Ever wondered about those testpoint arrays on mSATA and M.2 SSDs? This write-up lays bare the secrets of such an SSD, using a Pi 4, PiFEX, OpenOCD and a good few open-source tools for JTAG probing that you can easily use yourself.

The PiFEX hat gives you level-shifted bidirectional GPIO connectors for UART, SPI, I2C, JTAG, SWD and potentially way more, an OLED screen to show any debugging information you might need, and even a logic analyzer header so that you can check up on your reverse-engineering progress.

Continue reading “JTAG Hacking An SSD With A Pi: A Primer”

Two pictures of the same black dog, wearing two separate pairs of the AR glasses reviewed in these two articles

A Master-Class On Reverse-Engineering Six AR Glasses

Augmented reality (AR) tech is getting more and more powerful, the glasses themselves are getting sleeker and prettier, and at some point, hackers have to conquer this frontier and extract as much as possible. [Void Computing] is writing an open source SDK for making use of AR glasses, and, along the way, they’ve brought us two wonderful blog posts filled with technical information laid out in a fun to read way. The first article is titled “AR glasses USB protocols: the Good, the Bad and the Ugly”, and the second one follows as “the Worse, the Better and the Prettier”.

Have you ever wanted to learn how AR glasses and similar devices work, what’s their internal structure, which ones are designed well and which ones maybe not so much? These two posts have concise explanations, more than plenty of diagrams, six case studies of different pairs of AR glasses on the market, each pair demonstrated by our hacker’s canine assistant.

[Void Computing] goes in-depth on this tech — you will witness MCU firmware reverse-engineering, HID packet captures, a quick refresher on the USB-C DisplayPort altmode, hexdumps aplenty, and a reminder on often forgotten tools of the trade like Cunningham’s law.

If reverse-engineering lights your fire, these high-level retrospectives will teach you viable ways to reverse-engineer devices in your own life, and they certainly set a high bar for posts as far as write-ups go. Having read through these posts, one can’t help but think that some sort of AR glasses protocol standard is called for here, but fortunately, it appears like [Void Computing]’s SDK is the next best thing, and their mission to seize the good aspects of a tentative cyberpunk future is looking to be a success. We’ve started talking about AR glasses over a decade ago, and it’s reassuring to see hackers catching up on this technology’s advancements.

We thank [adistuder] for sharing this with us on the Hackaday Discord server!

Displays We Love Hacking: LVDS And EDP

There are times when tiny displays no longer cut it. Whether you want to build a tablet or reuse some laptop displays, you will eventually deal with LVDS and eDP displays. To be more exact, these are displays that want you to use either LVDS or eDP signaling to send a picture.

Of the two, LVDS is the older standard for connecting displays, and eDP is the newer one. In fact, eDP has mostly replaced LVDS for things like laptop and tablet displays. Nevertheless, you will still encounter both of these in the wild, so let’s start with LVDS.

The name “LVDS” actually comes from the LVDS signaling standard (Low-Voltage Differential Signaling), which is a fairly generic data transfer standard over differential pairs, just like RS485. Using LVDS signaling for embedded display purposes is covered by a separate standard called FPD-Link, and when people say “LVDS”, what they’re actually talking about is FPD-Link. In this article, I will also use LVDS while actually talking about FPD-Link. Barely anyone uses FPD-Link except some datasheets, and I’ll use “LVDS” because that’s what people actually use. It’s just that you deserve to know the distinction so that you’re not confused when someone mentions LVDS when talking about, say, industrial machinery.

Both LVDS and eDP run at pretty high frequencies – they’re commonly used for color displays with pretty large resolutions, so speed can no longer be a constraint. eDP, as a successor technology, is a fair bit more capable, but LVDS doesn’t pull punches either – if you want to make a 1024 x 768 color LCD panel work, you will use LVDS, sometimes parallel RGB – at this point, SPI just won’t cut it. There’s a lot of overlap – and that’s because LVDS is basically parallel RGB, but serialized and put onto diffpairs. Let me show you how that happened, and why it’s cool.

Continue reading “Displays We Love Hacking: LVDS And EDP”