Freshening Up Google’s USB-C PD Sniffer

USB-C Power Delivery has definitely made the big mess of wires a bit smaller but not all cables are created equal — some of them can handle upwards of 100 W while the cheapest can handle only 10. To accommodate this, USB-C cables need to actively tell both ends what their capabilities are, which turns an otherwise passive device into a hidden chip in a passive looking cable.

[Greg Davill] has decided to unravel the mystery of why your laptop isn’t charging by creating a USB-PD sniffer. Based on Google’s Twinkie sniffer, the FreshTwinkie makes the design more accessible by reducing the number of layers in the PCB and replacing the BGA variant of the STM32 for a more DIY-friendly QFN version. Interestingly, this isn’t the first time we’ve seen somebody try and simplify the Twinkie; back in 2021, the Twonkie from from [dojoe] hit a number of similar notes.

USB-C Power Delivery is just one of many protocols spoken over the CC pins, and the FreshTwinkie might be able to detect when some of those are enabled and why or why not. With future development, it could potentially provide useful information as to why a Thunderbolt 4 or tunneled PCIe device isn’t working correctly.

Australia’s Second Largest Telco Went Dark, And Chaos Reigned

Engineers tend to worry about uptime, whether it’s at a corporate server farm or just our own little hobby servers at home. Every now and then, something will go wrong and take a box offline, which requires a little human intervention to fix. Ideally, you’ll still have a command link that stays up so you can fix the problem. Lose that, though, and you’re in a whole lick of trouble.

That’s precisely what happened to Australia’s second largest telecommunications provider earlier this month. Systems went down, millions lost connectivity, and company techs were left scrambling to put the pieces back together. Let’s dive in and explore what happened on Optus’s most embarrassing day in recent memory.

Continue reading “Australia’s Second Largest Telco Went Dark, And Chaos Reigned”

Simple CMOS Circuit Allows Power And Data Over Twisted-Pair Wiring

If you need to send data from sensors, there are plenty of options, including a bewildering selection of wireless methods. Trouble is, most of those protocols require a substantial stack of technology to make them work, and things aren’t much easier with wired sensors either. It doesn’t have to be that complicated, though, as this simple two-wire power-and-data interface demonstrates.

As with all things electronic, there are tradeoffs, which [0033mer] addresses in some detail in the video below. The basic setup for his use case is a PIC-based sensor — temperature, for this demo — that would be mounted in some remote location. The microcontroller needs to be powered, of course, and also needs to send a signal back to a central point to indicate whether the monitored location is within temperature specs. Both needs are accommodated by a single pair of wires and a tiny bit of additional circuitry. On one end of the twisted pair is a power supply and decoder circuit, which sends 9 volts up the line to power the PIC sensor. The decoder is based on a CD4538 dual monostable multivibrator, set up for an “on” time of one second. A trigger input is connected to the power side of the twisted pair going to the sensor, where a transistor connected to one of the PIC’s GPIO pins is set up to short the twisted pair together every half-second. Power to the PIC is maintained by a big electrolytic and a diode, to prevent back-feeding the controller. The steady 0.5-Hz stream of pulses from the sensor keeps resetting the timer on the control side. Once that stream stops, either through code or by an open or short condition on the twisted pair, the controller triggers an output to go high.

It’s a pretty clever system with very simple and flexible circuitry. [0033mer] says he’s used this over twisted-pair wires a couple of hundred feet long, which is pretty impressive. It’s limited to one bit of bandwidth, of course, but that might just be enough for the job. If it’s not, you might want to check out our primer on current-loop sensors, which are better suited for analog sensors but still share some of the fault-detection features.

Continue reading “Simple CMOS Circuit Allows Power And Data Over Twisted-Pair Wiring”

How To Talk To Your Scope

It used to be only high-end test equipment that had some sort of remote control port. These days, though, they are quite common. Historically, test gear used IEEE-488 (also known as GPIB or, from the originator, HPIB). But today, your device will likely talk over a USB port, a serial port, or a LAN connection. You’d think that every instrument had unique quirks, and controlling it would be nothing like controlling another piece of gear, especially one from another company. That would be half right. Each vendor and even model indeed has its unique command language. There has been a significant effort to standardize some aspects of test instrument control, and you can quickly write code to control things on any platform using many different programming languages. In a few posts, I will show you just how easy it can be.

The key is to use VISA. This protocol is defined by the IVI Foundation that lets you talk to instruments regardless of how they communicate. You do have to build an address that tells the VISA library how to find your device. For example: “TCPIP::192.168.1.92::INSTR.” But once you have that, it is easy to talk to any instrument anywhere.

I say that thinking it is a problem is half right because talking to the box is one task of the two you need to complete. The other is what to say to the box and what it will say back to you. There are a few standards in this area, but this is where you get into problems. Continue reading “How To Talk To Your Scope”

PicoGUS: For All Your ISA Sound Card Needs

Sound cards used to be a big part of gaming machines in the 90s and 2000s but have largely gone extinct in the wake of powerful CPUs doing the sound themselves. Sound cards were expensive back then and, because the good ones weren’t very common, are expensive still for the retro gamer. But if you don’t need the real thing, [polpo] has you covered with his RP2040-based ISA sound card.

The PicoGUS, as he calls it, primarily serves to replace the Gravis UltraSound with modern components at a low cost. It uses the RP2040’s PIO to attach to an ISA bus and the RP2040’s dual-core power to synthesize the audio for its primary target, but also the AdLib (OPL2), CMS/Game Blaster and Tandy 3-Voice. [polpo] sells the PicoGUS on his Tindie store, but since it’s open source, you can of course just make your own.

Although “work-in-progress”, the PicoGUS is very useful to the right person and a perfect demonstration of how the RP2040’s PIO can be used to interface with almost any type of protocol.

Of couse, that’s not the only way to use the PIO, you can also create a CAN bus or even add another USB port.

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With The Duplex Typewriter

The Coleco Adam? A not-so-great home computer that likely contributed to the downfall of the company. The keyboard, however, is a different story, and worth repurposing.

[Nick Bild] has created a USB adapter that uses a Teensy 4.1 and an RJ-12 breakout board. Now this wasn’t just a simple matrix to decode. No, the fine folks at Coleco rolled their own communications protocol called AdamNet.

The keyboard uses an RJ-12 connector and a single data line to communicate over a 62.5 kbit/s, half-duplex serial bus. Inside the keyboard is a Motorola 6801 that caches the key presses and sends them to the computer. So the BOM is limited to what you see above — an RJ-12 breakout and a Teensy 4.1. It’s great to see old keyboards come alive again, especially one with such cool sci-fi keycaps. Want to hear it clack? Of course you do.

Continue reading “Keebin’ With Kristina: The One With The Duplex Typewriter”

Using Nuclear Decay As Random Number Generator Source For An MCU

Although there are many ways to get a random number generator (RNG) set up on a microcontroller, it’s hard to argue with the sheer randomness of the various kinds of radiation zipping all around us from nuclear decay events. For [gbonacini] the purchase of a Geiger counter first in 2022 was the reason to tinker with using these as the source for an RNG, which simply runs a counter until a Geiger counter event occurs that ‘selects’ a number and the counter is reset to zero.

With the next version of this system the hardware and layout has changed somewhat, using a commercial handheld Geiger counter (GMC-320+) and its audio output as a generic input for any MCU. The (pulsed) audio signal is amplified with an opamp (left unspecified) that connects to a GPIO pin of the MCU (RP2040-based Pico W). Here the same algorithm is used to create a continuous queue of randomly picked numbers, which can also be queried via the WiFi interface with a custom protocol, essentially making it a network-connected RNG that could be used by other network-connected appliances.

C++ source is provided for the Pico W example, but it should be easy enough to adapt to other platforms. The GMC-320+ is also among the more affordable Geiger counters out there, even if it’s somewhat bulky to pair with just a single MCU, making a more basic Geiger counter module better for a permanent installation. Either way you should get pretty good RNG this way without splurging on exotic hardware.

Thanks to [navigator] for the tip.