u/Lopsided_Mixture8760

Today I’ve been completely focused on the heatsinks for my USBridge-KVM 2.0 project — IP-KVM tool focused on text-based BIOS-in-Terminal access via SSH. I'm currently putting together the first test batch to send to tech bloggers!

I adapted and modified these standard aluminum heatsink profiles so they would fit perfectly with the custom case design, and so the active cooling fan would sit properly.

I had to work a bit to perfectly align the heatsink mounting posts and brackets with the board. I’m no master machinist, but after applying a thin coat of paint, I think it looks pretty good.

I can’t wait for the first independent reviews to come out! I’d really love to hear your thoughts on the cooling system or the overall hardware layout.

When I explain that I process the video stream using OCR and output the text via SSH, people often ask me, “Why do you need to do that? Just use Serial-over-LAN or IPMI.”

Okay—I’m installing the standard Debian netinst ISO on my computer, booting up, and expecting to see the installer menu via the serial console. Instead, I see nothing. Why? The installer typically defaults to displaying the image on VGA/HDMI. To enable `console=ttyS0`, I need to interact with the boot menu... which is currently only visible on the video output, which I can’t see. To get the serial port working, I first need access to the video output.

“Or maybe the iLO/iDRAC serial port?” The only problem is that the iLO/iDRAC serial console only works if the BIOS is already configured to redirect to the serial port, the COM port is known, and the baud rate is known—and you need a video display to enable this.

Okay, let’s say we’ve all managed to install Debian somehow. Now I want to run a command in the console without a display. What do I need to do? That’s right—the `console=ttyS0` parameter in GRUB, running `getty` on ttyS0, the correct baud rate, and serial port redirection enabled in the BIOS. Where do I configure all of this? During installation or on an already installed system. If I haven’t done this beforehand, then: SSH may be unavailable, the serial port won’t respond, and the command can’t be executed.

In USBridge-KVM 2.0, the BIOS-in-Terminal feature does not have these drawbacks. For the target server, USBridge is simply a standard monitor and keyboard connected to the HDMI and USB ports.

Criterion	Integrated BMC (iDRAC/iLO)	Serial Console (COM/SoL)	USBridge (with offline OCR)
Vendor lock-in	Complete (Dell/HP/etc.)	No	No (works with any hardware)
Requires pre-configuration?	No	Yes (in the BIOS and OS)	No (plug and play)
UI Requirements	Heavy Web GUI / Java	Terminal (CLI)	Standard SSH client (CLI)
Power Management	Yes	No (PDU required)	Yes (module included)
Virtual Media (ISO)	Yes (often licensed)	No	Yes (out-of-the-box)

The KVM captures the “raw” video signal directly from the HDMI port. The server outputs this image regardless of the OS settings. A built-in chip (RK3566) on the KVM itself analyzes the video stream and recognizes text characters on the BIOS screen in real time, completely offline. Type `ssh user@usbridge` in your usual terminal to receive a text stream. Key presses are emulated back to the server as signals from a physical USB keyboard. It doesn’t matter what hardware you’re using—whether it’s a latest-generation server, an old industrial PC, or a custom-built system.

How do you handle issues with headless servers when the default settings stop working? I'd be interested to hear what configurations others use.

Everyone knows the problem with sEMG: it works perfectly in the lab, but in real life it’s finicky. For it to work, you need bare skin, conductive gel, and—most importantly—no static load. Try standing up, and the background noise from your postural muscles (maintaining balance) will simply “drown out” your useful signal.

I decided to approach it from a different angle: active acoustic probing. Instead of waiting for a nerve impulse, I “ring out” the 500 Hz carrier through the muscle waveguide and observe the change in the tissue’s mechanical impedance.

Log Timeline (N=1, Session 175320):

0–30 sec: Rest (Baseline). I am sitting motionless. The differential phase between the sensor axes (X-Y) is aligned with a deviation of only 1.5°. This is our “acoustic lock.”

​30–68 sec: Isometric cycles (Sitting). I alternate tension and relaxation every 5 seconds. The phase forms distinct “steps” with an amplitude of up to 50°. The gyroscope shows a residual 10°/s—this isn’t a perfect vacuum, but for a first prototype without fixation, it’s a clear signal of intent.

68 sec: Change of posture. I straighten my leg while sitting. The waveguide geometry changes, the phase shifts to a new level and instantly stabilizes. I continue clicking—the response persists.

107 sec: MOMENT OF TRUTH (Standing up). This is where things get really interesting.
EMG: As expected, the baseline noise has increased (static load), making it extremely difficult to distinguish conscious “clicks” due to the extremely low SNR.
Acoustics: The Phase continues to produce the same clear steps as when seated. At 500 Hz, it doesn’t matter how much “electrical noise” is in the muscle—it detects the physical contraction of the fibers. That’s the killer feature.

138 sec: Recalibration. I sit back down. The phase returns to the initial cluster.

Why is this potentially cooler than sEMG?

It works through clothing. sEMG always requires direct skin contact. Acoustics, on the other hand, involve mechanical waves. They don’t need galvanic contact. You can simply press the sensor against your pants or integrate it into an exoskeleton. This is a game-changer for wearable electronics.

Acoustic transparency (Magnitude). I measured the correlation: with each contraction, the 500 Hz magnitude drops. The muscle literally “dampens” the sound by becoming denser. This is a direct measurement of the state of matter (p < 10^{-8}), rather than an indirect one based on electrical potentials.

Differential profile. Thanks to microsecond synchronization (TSF), we can subtract out the overall vibration and leave only the pure biomechanical phase shift.

Yes, this is still N=1. Yes, the shape of the phase “glyph” varies from one run to the next, and we still have a long way to go before we have a universal alphabet of gestures. But the fact remains: in situations where EMG starts to “lie” due to a change in posture, acoustic impedance continues to provide a clear signal.

Following up on my previous post about various cooling options for my USBridge-KVM 2.0 hardware project (the one that transmits the BIOS as text over SSH).

I finally received the new turbine (blower) fans I mentioned earlier. Following the community’s advice, I also ditched the thick 4-millimeter thermal pads.

I soldered a 2-millimeter copper pad to fill the gap between the chip and the heatsink, and I also replaced the axial fan with a blower fan. Now it blows air horizontally across the heatsink fins, rather than struggling to blow downward.

The difference is huge. Old configuration (axial fan + 2 thick spacers): ~70–80 °C under load. New configuration (turbine fan + copper spacer): stable temperature of 50 °C even during intensive video processing/OCR mode.

A temperature drop of more than 20 °C is a huge plus for the device’s long-term stability. I no longer worry about thermal throttling while the device streams 2K video.

I started developing my USBridge 2.0 KVM-over-IP solution because I needed a simple way to manage budget servers at the BIOS level. An example configuration involves motherboards based on the Xeon X99; unfortunately, they do not have built-in IPMI.

The goal was to display the BIOS in the console—without an agent—as readable text that can be copied and read by AI agents for rack diagnostics.

In the end, I found that USBridge-KVM doesn’t just pass through pixels, but converts the BIOS screen into text output in the terminal using deterministic pixel mapping (in simple terms, OCR). In the end, I get the same BIOS, but only as text via SSH. Essentially, it’s the same as IPMI/iLO, but for hardware where it isn’t provided.

I decided not to stop there and finished implementing data snapshots. Since the KVM is physically isolated from the host, I consider this a significant advantage for data protection. The concept is simple: snapshots are saved on the KVM’s SD card, which uses a BTRFS filesystem; after a snapshot is created, it enters copy-on-write mode. Even the root user on the host cannot delete or encrypt it.

I’ve also spent quite a bit of time working with disks. You can mount disks directly so that the host sees them as physical drives; they can boot up and run. All changes are saved separately, which allows for experimentation—I know I can always roll back. In terms of speed, it works almost as fast as an SSD, since I’ve set up caching.

It’s been 8 months since I started working on this, and I’m now in the final stages. I’m finishing up the active cooling system and fixing minor bugs. I’m also polishing the code for the agent (an app similar to TeamViewer or AnyDesk) and the client application so I can release it as open source on GitHub.

Essentially, this will be a completely free alternative to TeamViewer or AnyDesk, with no subscriptions or restrictions.

How are you handling out-of-band access on budget hardware without IPMI? I’m curious to know what solutions people are actually using.

I built a cooling setup using a copper heatsink with square fins—passive cooling plus a small fan. It looked nice, but I wasn’t too happy with the thermal performance.

I switched to a strip-style aluminum heatsink—it has a larger surface area, and it’s 5 mm thick instead of the 3 mm copper one. But the fan blows air downward, and because of its tiny size, it has a hard time pushing air through the fins.

I ordered turbine coolers (see insert)—they blow air sideways through the fins, plus their airflow is almost twice as high. It should be much better for this design. They’ll arrive on May 14, then I’ll compare the temperatures.

The device is a hardware KVM that streams the BIOS as text via SSH. The project is in pre-launch if anyone’s interested.