Life was simpler when everything your computer did was text-based. It is easy enough to shove data into one end of a pipe and take it out of the other. Sure, if the pipe extends across the network, you might have to call it a socket and take some special care. But how do you pipe all the data we care about these days? In particular, I found I wanted to transport audio from the output of one program to the input of another. Like most things in Linux, there are many ways you can get this done and — like most things in Linux — only some of those ways will work depending on your setup.

Why?

There are many reasons you might want to take an audio output and process it through a program that expects audio input. In my case, it was ham radio software. I’ve been working on making it possible to operate my station remotely. If all you want to do is talk, it is easy to find software that will connect you over the network.

However, if you want to do digital modes like PSK31, RTTY, or FT8, you may have a problem. The software to handle those modes all expect audio from a soundcard. They also want to send audio to a soundcard. But, in this case, the data is coming from a program.

Of course, one answer is to remote desktop into the computer directly connected to the radio. However, most remote desktop solutions aren’t made for high-fidelity and low-latency audio. Plus, it is nice to have apps running directly on your computer.

I’ll talk about how I’ve remoted my station in a future post, but for right now, just assume we want to get a program’s audio output into another program’s audio input.

Sound System Overview

Someone once said, “The nice thing about standards is there are so many of them.” This is true for Linux sound, too. The most common way to access a soundcard is via ALSA, also known as Advanced Linux Sound Architecture. There are other methods, but this is somewhat the lowest common denominator on most modern systems.

However, most modern systems add one or more layers so you can do things like easily redirect sound from a speaker to a headphone, for example. Or ship audio over the network.

The most common layer over ALSA is PulseAudio, and for many years, it was the most common standard. These days, you see many distros moving to PipeWire.

PipeWire is newer and has a lot of features but perhaps the best one is that it is easy to set it up to look like PulseAudio. So software that understands PipeWire can use it. Programs that don’t understand it can pretend it is PulseAudio.

There are other systems, too, and they all interoperate in some way. While OSS is not as common as it once was, JACK is still found in certain applications. Many choices!

One Way

There are many ways you can accomplish what I was after. Since I am running PipeWire, I elected to use qpwgraph, which is a GUI that shows you all the sound devices on the system and lets you drag lines between them.

It is super powerful but also super cranky. As things change, it tends to want to redraw the “graph,” and it often does it in a strange and ugly way. If you name a block to help you remember what it is and then disconnect it, the name usually goes back to the default. But these are small problems, and you can work around them.

In theory, you should be able to just grab the output and “wire” it to the other program’s input. In fact, that works, but there is one small problem. Both PipeWire and PulseAudio will show when a program is making sound, and then, when it stops, the source vanishes.

This makes it very hard to set up what I wanted. I wound up using a loopback device so there was something for the receiver to connect to and the transient sending device.

Here’s the graph I wound up with:

I omitted some of the devices and streams that didn’t matter, so it looks pretty simple. The box near the bottom right represents my main speakers. Note that the radio speaker device (far left) has outputs to the speaker and to the JTDX in box.

This lets me hear the audio from the radio and allows JTDX to decode the FT8 traffic. Sending is a little more complicated.

The radio-in boxes are the loopback device. You can see it hooked to the  JTDX out box because when I took the screenshot, I was transmitting. If I were not transmitting, the out box would vanish, and only the pipe would be there.

Everything that goes to the pipe’s input also shows up as the pipe’s output and that’s connected directly to the radio input. I left that box marked with the default name instead of renaming it so you can see why it is worth renaming these boxes! If you hover over the box, you’ll see the full name which does have the application name in it.

That means JTDX has to be set to listen and send to the streams in question. The radio also has to be set to the correct input and output. Usually, setting them to Pulse will work, although you might have better luck with the actual pipe or sink/source name.

In order to make this work, though, I had to create the loopback device:

pw-loopback -n radio-in -m '[FL FR]' --capture-props='[media.class=Audio/Sink]' --playback-props='[media.class=Audio/Source]' &

This creates the device as a sink with stereo channels that connect to nothing by default. Sometimes, I only connect the left channels since that’s all I need, but you may need something different.

Other Ways

There are many ways to accomplish this, including using the pw-link utility or setting up special configurations. The PipeWire documentation has a page that covers at least most of the scenarios.

You can also create this kind of virtual device and wiring with PulseAudio. If you need to do that, investigate the pactl command and use it to load the module-loopback module.

It is even possible to use the snd-aloop module to create loopback devices. However, PipeWire seems to be the future, so unless you are on an older system, it is probably better to stick to that method.

Sound Off!

What’s your favorite way to route audio? Why do you do it? What will you do with it? I’ll have a post detailing how this works to allow remote access to a ham transceiver, although this is just a part of the equation. It would be easy enough to use something like this and socat to stream audio around the network in fun ways.

We’ve talked about PipeWire for audio and video before. Of course, connecting blocks for audio processing makes us want to do more GNU Radio.

There’s an old joke that they want to send an exploratory mission to the sun, but to save money, they are going at night. The European Space Agency’s Solar Orbiter has gotten as close as anything we’ve sent to study our star on purpose, and the pictures it took last year were from less than 46 million miles away. That sounds far away, but in space terms, that’s awfully close to the nuclear furnace. The pictures are amazing, and the video below is also worth watching.

Because the craft was so close, each picture it took was just a small part of the sun’s surface. ESA stitched together multiple images to form the final picture, which shows the entire sun as 8,000 pixels across. We’ll save you the math. We figure each pixel is worth about 174 kilometers or 108 miles, more or less.

The stunning images used the Polarimetric and Helioseismic Imager and the Extreme Ultraviolet Imager. The first instrument snapped the visible light and the magnetic field lines. It also provided a velocity map. The UV instrument took pictures of the corona.

Understanding the sun is important because it greatly impacts our life on Earth. Technology is especially sensitive, and, lest we forget, massive solar disruptions have happened before.

[MindYourDecisions] presents a Babylonian tablet dating back to around 1800 BC that shows that the hypotenuse of a unit square is the square root of two or 1.41421. How did they know that? We don’t know for sure how they computed it, but experts think it is the same as the ancient Greek method written down by Hero. It is a specialized form of the Newton method. You can follow along and learn how it works in the video below.

The method is simple. You guess the answer first, then you compute the difference and use that to adjust your estimate. You keep repeating the process until the error becomes small enough for your purposes.

For example, suppose you wanted to take the square root of 85. You can observe that 9 squared is 81, so the answer is sort of 9, right? But that’s off by 4 (85-81=4). So you take that number and divide it by the current answer (9) multiplied by two. In other words, the adjustment is 4/18 or 0.2222. Putting it together, our first answer is 9.2222.

If you square that, you get about 85.05 which is not too bad, but if you wanted closer you could repeat the process using 9.2222 in place of the 9. Repeat until the error is as low as you like. Our calculator tells us the real answer is 9.2195, so that first result is not bad. A second pass gives 9.2193, You could keep going, but that’s close enough for almost any purpose.

The video shows a geographical representation, and if you are a visual thinker, that might help you. We prefer to think of it algebraically. You are essentially creating each adjustment by adding the guess and the square divided by the guess and averaging them.

The ancients loved to estimate numbers. And Hero was into a lot of different things.

It is hard to imagine that there was a time when having a keyboard and screen readily available was a real problem for people who wanted to experiment with computers. In the 1970s, if you wanted a terminal, you might well have built a [Don Lancaster] “TV Typewriter” and the companion “low cost keyboard.” [Artem Kalinchuk] wanted to recreate this historic keyboard and, you know what? He did! Take a look at the video below.

The first task was to create a PCB from the old artwork from Radio Electronics magazine. [Artem] did the hard work but discovered that the original board expected a very specific kind of key. So, he created a variant that takes modern MX keyboard switches, which is nice. He does sell the PCBs, but you can also find the design files on GitHub.

Not only were the TV typewriters and related projects popular, but they also inspired many similar projects and products from early computer companies.

The board is really just a holder for keys, some jumper wires, and an edge connector. You still need an ASCII encoder board, which [Artem] also recreates. That board is simple, using diodes, a few transistors, and a small number of simple ICs.

If you weren’t there, part of installing old software was writing the code needed to read and write to your terminal. No kidding. We miss [Don Lancaster]. We wonder how many TV typewriters were built, especially if you include modern recreations.

[Kevin] doesn’t stock zener diodes anymore. Why? Because for everything he used to use zeners, he now uses TL431 bandgap voltage references. These look like zener diodes but have an extra terminal. That extra terminal allows you to set the threshold to any value you want (within specifications, of course). Have a look at the video below for an introduction to these devices and a practical circuit on a breadboard.

Inside, there’s a voltage reference, an op-amp, and a transistor, so these are tiny 3-terminal ICs. The chip powers itself from the load, so there are no separate power supply pins.

Note that just before the five-minute mark, he had a typo on the part number, but he corrected that in the comments. He goes on to put a demonstration schematic in KiCad. Once it was all worked out, it was breadboard time.

As always, there were a few real-world things to resolve, but the circuit worked as expected. As [Kevin] points out, the faux-zeners are about four for a dollar and even less in quantity. A zener might be a few pennies cheaper, but unless you are making thousands of copies of your circuit, who cares?

We don’t see zeners as often as we used to. As for the TL431, we’ve seen one torn apart for your amusement.

[My Ham Radio Journey] wanted to see if a “common person” (in his words) could build an effective vertical ham radio antenna. If you look at the video below, the answer is apparently yes.

He started with a 24-foot fishing rod and a roll of 22 gauge wire. The height of the antenna wire is just over 20 feet long and he has several ground radials, as you might expect for a vertical antenna.

You also need a toroid to make an unun for the feed point. The details of how he mounted everything will be useful if you want to experiment with making your own version.

Vertical antennas have plusses and minuses. One advantage is they have a low angle of radiation, which is good for long distance communication. It is possible to make arrays of vertical antennas, and we are surprised we haven’t seen any of those lately.

In the end, it looks like the antenna works well. With the 4:1 transformer, the SWR on all the ham bands is within range of the radio’s tuner.

We recently saw a fishing pole antenna that used no wire at all. If you want portable and fishing isn’t your thing, try a tape measure.

[Japhy Riddle] was tired of creating pixel art. He went to subpixel art. The idea is that since each color pixel is composed of three subpixels, your display is actually three times as dense as you think it is. As long as you don’t care about the colors, of course.

Is it practical? No, although it is related to the Bayer filter algorithm and font antialiasing. You can also use subpixel manipulation to hide messages in plain sight.

[Japhy] shows how it all works using Photoshop, but you could do the same steps with anything that can do advanced image manipulation. Of course, you are assuming the subpixel mask is identical is for any given device, but apparently, they are mostly the same these days. You could modify the process to account for different masks.

Of course, since the subpixels are smaller, scaling has to change. In the end, you get a strange-looking image made up of tiny dots. Strange? Yes. Surreal? You bet. Useful? Well, tell us why you did it in the comments!

Pixel art isn’t just for CRTs. However, subpixel art assumes that the pixels can be divided up, which is not always the case.

How do you collect a lot of data about the ionosphere? Well, you could use sounding rockets or specialized gear. Or maybe you can just conscript a huge number of cell phones. That was the approach taken by Google researchers in a recent paper in Nature.

The idea is that GPS and similar navigation satellites measure transit time of the satellite signal, but the ionosphere alters the propagation of those signals. In fact, this effect is one of the major sources of error in GPS navigation. Most receivers have an 8-parameter model of the ionosphere that reduces that error by about 50%.

However, by measuring the difference in time between signals of different frequencies, the phone can estimate the total electron current (TEC) of the ionosphere between the receiver and the satellite. This requires a dual-frequency receiver, of course.

This isn’t a new idea. There are a large number of fixed-position stations that make this measurement to contribute to a worldwide database. However, the roughly 9,000 stations can’t compete with cell phones everywhere. The paper outlines how Android smartphones can do calculations on the GPS propagation delays to report the TEC numbers.

Hams often study the ionosphere. So do sounding rockets.

Normally, you think of things casting a shadow as being opaque. However, new research shows that under certain conditions, a laser beam can cast a shadow. This may sound like nothing more than a novelty, but it may have applications in using one laser beam to control another. If you want more details, you can read the actual paper online.

Typically, light passes through light without having an effect. But using a ruby crystal and specific laser wavelengths. In particular, a green laser has a non-linear response in the crystal that causes a shadow in  a blue laser passing through the same crystal.

The green laser increases the crystal’s ability to absorb the blue laser beam. which creates a matching region in the blue beam that appears as a shadow.

If you read the article, there’s more to measuring shadows than you might think. We aren’t sure what we would do with this information, but if you figure it out, let us know.

Ruby has a long history with lasers, of course. That green laser pointer you have? It might not be all green, after all.

Nowadays, if you want to delay an audio signal for, say, an echo or a reverb, you’d probably just do it digitally. But it wasn’t long ago that wasn’t a realistic option. Some devices used mechanical means, but there were also ICs like the TCA350 “bucket brigade” device that [10maurycy10] shows us in a recent post.

In this case, bucket brigade is a euphemism calling to mind how firemen would pass buckets down the line to put out a fire. It’s a bit of an analog analogy. The “bucket” is a MOSFET and capacitor. The “water” is electrical charge stored in the cap.  All those charges are tiny snippets of an analog signal.

In practice, the chip has two clock signals that do not overlap. The first one gates the signal to a small capacitor which follows the input signal voltage. Then, when that gate clock closes, the second clock gates that output to another identical capacitor. The second capacitor discharges the first one and the whole process repeats, sometimes for hundreds of times.

In addition to a test circuit and some signals going in and out, the post also shows photomicrographs of the chip’s insides. As you might expect, all those identical gates make for a very regular layout on the die.

You might think these devices are obsolete, and that’s true. However, the basic idea is still in use for CCD camera sensors.

Sometimes, those old delay lines were actually columns of mercury or coiled-up transmission lines. You could even use a garden hose or build your own delay line memory.

When we first looked at [Anders Nielsen’s] EEPROM programmer project, it was nice but needed some software and manual intervention and had some limitations on the parts you could program. But through the magic of Open-Source collaboration, revision 2 of the project overcomes all of these limitations and—as you can see in the video below—looks very polished.

If you recall, the programmer is in a “shield” format that can plug into an Arduino or — if you prefer a retrocomputer — a 6502uno. Along with hardware improvements from the community, [Henrik Olsson] wrote Python software to handle the programming (see the second video below).

The biggest change in the new version is that you don’t have to configure the voltages with jumpers anymore. This was required because different devices draw power on different pins, but a clever two-transistor circuit lets the software handle it. There is still one jumper for switching between 32-pin and 28-pin EEPROMs. The extra transistors added four cents to the total price, although if you buy the kit from [Anders], it is still $9, just like before.

Skimming the database, we don’t see any Microcontrollers (MPUs). However, it looks like the device should be able to program flash MPUs, too.

We covered the first edition of this project, and we were impressed even then. We do hope people will add MPUs and other devices like PALs to the project over time.

Imagine this. A young person comes to you wanting to get started in the electronic hobby. They ask what five things should they buy to get started. Make your list. We’ll wait. We bet we can guess at least two of your items: a multimeter, and a soldering iron. [LearnElectroncsRepair] recently showed us a review of the Zotek Zoyi ZT-N2 which is a soldering iron and a multimeter in one unit. You can watch the video review below.

Honestly, when we heard about this, we didn’t think much of the combination. It doesn’t seem like having your probe get red hot is a feature. However, the probe tip replaces the soldering iron tip, so you are either soldering or measuring, but not both at the same time.

The soldering iron part looks a lot like a T100 iron with a USB connector and a little LCD screen. The device is portable, so it has a little cheap soldering iron stand. As a multimeter, it does all the basic tests, but it is only usable for low-voltage applications under 36V.

The negative lead plugs into the USB connector, so the meter runs off an internal battery. While it looks like it is usable, we couldn’t really think of many cases where this would be handy unless you are really trying to pack a lot in a small space. We’d rather throw a small meter in the bag and call it a day.

In 2017, these little soldering irons were a fresh fad. Now, they are pretty common.

We’ll be honest. Measuring Forth words per second doesn’t seem like a great benchmark since a Forth word could be very simple or quite complex. But we think the real meaning is “up to 400 million words per second.” There was a time when that level of performance would take a huge computer. These days, a simple board that costs a few bucks can do the trick, according to [Peter Forth] in an online presentation.

The key is the use of the Milk V Duo and some similar boards. Some of these look similar to a Raspberry Pi Pico. However, this chip on board has two RISC V cores, an ARM core, and an 8051. There’s also an accelerator coprocessor for vector operations like AI or video applications.

[Peter] has some popular Forth systems ported to the machine on GitHub. This might be the easiest way to get started because, as he mentions in the video, the documentation for these boards leaves something to be desired. However, these chips have a lot of capability for a small price.

We like Forth. If you want something that is less of a port, we’ve seen some native RISC V implementations.

If you think of Apple today, you probably think of an iPhone or a Mac. But the original Apple I was a simple PC board and required a little effort to start up a working system. [Artem] has an Apple I reproduction PCB, and decided to build it on camera so we could watch.

For the Apple I, the user supplied a keyboard and some transformers, so [Artem] had to search for suitable components. He wisely checks the PCB to make sure there are no shorts in the traces. From there, you can watch him build the machine, but be warned: even with speed ups and editing, the video is over an hour long.

If you want to jump to the mostly working device, try around the 57-minute mark. The machine has a basic ROM monitor and, of course, needs a monitor. There was a small problem with memory, but he eventually worked it out by inhibiting some extra RAM on the board. Troubleshooting is half of the battle getting something like this.

Want to look inside the clock generator chip? Or skip the PCB and just use an FPGA.

You don’t have to know how a car engine works to drive a car — but you can bet all the drivers in the Indy 500 have a better than average understanding of what’s going on under the hood. All of our understanding of electronics hinges on Maxwell’s equations, but not many people know them. Even fewer have an intuitive feel for the equations, and [Ali] wants to help you with that. Of course, Maxwell’s gets into some hairy math, but [Ali] covers each law in a very pragmatic way, as you can see in the video below.

While the video explains the math simply, you’ll get more out of it if you understand vectors and derivatives. But even if you don’t, the explanations provide a lot of practical understanding

Understanding the divergence and curl operators is one key to Maxwell’s equations. While this video does give a quick explanation, [3Blue1Brown] has a very detailed video on just that topic. It also touches on Maxwell’s equations if you want some reinforcement and pretty graphics.

Maxwell’s equations can be very artistic. This is one of those topics where math, science, art, and history all blend together.

If you ask someone who grew up in the late 1970s or early 1980s what taught them a lot about programming, they’d probably tell you that typing in programs from magazines was very instructive. However, it was also very boring and error-prone. In fact, we’d say it was less instructional to do the typing than it was to do the debugging required to find all your mistakes. Magazines hated that and, as [Tech Tangents] shows us in a recent video, there were efforts to make devices that could scan barcodes from magazines or books to save readers from typing in the latest Star Trek game or Tiny Basic compiler.

The Cauzin Softstrip was a simple scanner that could read barcodes from a magazine or your printer if you wanted to do backups. As [Tech Tangents] points out, you may not have heard of it, but at the time, it seemed to be the future of software distribution.

We were impressed that [Tech Tangent] had enough old magazines that he had some of the original strips. Byte Magazine had tried to promote a similar format, but there was no hardware made to read those barcodes.

Of course, there were other systems. For example, the HP-41C famously had a barcode scanner, although creating your own was clunky unless you reverse-engineered the “proper” format (which was done). The basic hardware used there also worked with Byte’s format, but you still had to interface the odd scanner to your computer.

Cauzin sidestepped all this with their product, which was simple-to-interface hardware with software support for the major platforms. However, by the time it was on the market, cheap magnetic media and modem-based bulletin boards were destroying interest in loading software from paper.

This is a great look at an almost forgotten technology. You could probably build something modern to scan these if you had the urge. These days, it would be easy enough to design your own system. Modern laser printers would probably make very dense barcodes.

We wouldn’t suggest making a Cauzin guitar, though. These days we have QR codes and even colorful barcodes.

According to [MTSI], if you used a Z80 chip back in the 1980s, it almost certainly passed through the sole Fairchild Sentry 610 system that gave it the seal of approval.

The Sentry was big iron for its day. The CPU was a 24-bit device and ran at a blistering 250 kHz. Along with a tape drive and a specialized test bed, it could test Z80s, F8s, and other Mostek products of the day. There was a disk drive, too. The 26-inch platters stored under 10 kilobytes. Despite the relatively low speed of the CPU, the Sentry could test devices running up to 10 MHz, which was plenty for the CPUs it was testing. The actual test interface ran at 11 MHz and used an exotic divider to generate slower frequencies.

According to the post, an informal count of the number of chips in the device came up with around 60,000. That, as you might expect, took a huge power supply, too.

From some 1975 corporate literature:

“Optimized for engineering, sophisticated production needs, QA and test center operations, the Sentry 610 is the most versatile analytical tester available for engineering and production. It can perform the widest range of tests for the broadest range of components. At user option, the Sentry 610 can perform high-speed MaS/LSI, PCB, and bipolar tests simultaneously. It offers complete testing at the wafer level and through automatic handlers at full-rated device speeds up to 10 MHz. The wide choice of peripherals gives the Sentry 610 system massive data handling capacity to manipulate, analyze, compute and generate reports on test procedures in analyzing MaS/LSI.”

These days, you are as likely to stick test hardware on the IC as have a big machine on the outside. And even then, you probably wouldn’t have something this elaborate. But in its day, this was high-tech for sure.

The Z80 sure has had a long lifespan. It shouldn’t surprise you that Z80s need to be tested, just like everything else.

If you want to add humidity and temperature sensors to your home automation sensor, you can — like [Maker’s Fun Duck] did — buy some generic ones for about a buck. For a dollar, you get a little square LCD with sensors and a button. You even get the battery. Can you reprogram the firmware to bend it to your will? As [Duck] shows in the video, you can.

The device advertises some custom BLE services, but [Duck] didn’t want to use the vendor’s phone app, so he cracked the case open. Inside was a microcontroller with Bluetooth, an LCD driver, a sensor IC, and very little else.

The processor is an ARM Cortex M0, a PHY6222 with very low power consumption. The LCD is a very cheap panel with no drivers onboard. All the drive electronics are on the PCB. The sensor is a CHT8305C which uses I2C.

Luckily, the PHY6222 has a publically available SDK with English documentation. The PCB has two sets of UART pads and it is possible to flash the chip via one of the UARTs.

Eventually, [Duck] put a custom firmware on the box, but we were intrigued by the idea that for a buck you could get a little low-power ARM module with an LCD and a sensor. It seems like you could do more with this, although we are sure the LCD is not very general purpose, surely this little box could act as a panel meter, a countdown timer, or lots of other things with some custom firmware.

These are, of course, knock offs of the slightly more expensive Xiaomi sensors, and those are flashable, too. We aren’t sure how accurate either sensor is, but humidity measurement is a complex topic.

In the modern age, when you hear “component tester” you probably think of one of those cheap microcontroller-based devices that can identify components and provide basic measurements on an LCD screen. However, in the past, these were usually simple circuits that generated an XY scope plot. The trace would allow an experienced operator to identify components and read a few key parameters. [Thomas] tears down an old Hameg device that uses this principle in the video below.

The unit is in a nice enclosure and has a feature that controls the amount of current the unit uses in the excitation signal. It plugs into the wall, and you can connect the component under test with either test leads or a socket. The output, of course, is a pair of BNCs for the scope’s X and Y inputs.

Compared to some homebrew projects that are similar, the PCB inside the device seems more complex. The output of most devices like this uses the line frequency (50 or 60 Hz). This one, however, has its own drive oscillator that operates at a different frequency.

Each type of component has a tell-tale trace on the scope. We found the tunnel diode trace especially interesting. Capacitors are circles, diodes make a definite step shape. There’s a table from the manual near the end of the video.

Most of these devices are much simpler, using a transformer to generate the AC sweep and a simple mechanism to measure the current. That makes them quite easy to build and they are still surprisingly useful.