Everything In A Linux Terminal

Here at Hackaday Central, we fancy that we know a little something about Linux. But if you’d tasked us to run any GUI program inside a Linux terminal, we’d have said that wasn’t possible. But, it turns out, you should have asked [mmulet] who put together term.everything.

You might be thinking that of course, you can launch a GUI program from a terminal. Sure. That’s not what this is. Instead, it hijacks the Wayland protocol and renders the graphics as text. Or, if your terminal supports it, as an image. Performance is probably not your goal if you want to do this. As the old saying goes, “It’s not that the dog can sing well; it’s that the dog can sing at all.”

If, like us, you are more interested in how it works, there’s a write up explaining the nuances of the Wayland protocol. The article points out that Wayland doesn’t actually care what you do with the graphical output. In particular, “… you could print out the graphics and give them to a league of crochet grandmas to individually tie together every single pixel into the afghan of legend!” We expect to see this tested at an upcoming hacker conference. Maybe even Supercon.

We generally don’t like Wayland very much. We use a lot of hacks like xdotool and autokey that Wayland doesn’t like. We also think people didn’t understand X11’s network abilities until it was too late. If you think of it as only a video card driver, then you get what you deserve. But we have to admit, we are humbled by term.everything.

The Android Linux Commander

Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.

I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:

  • All messages to the ordinary Linux start with >
  • All messages to the Android device start with <
  • All messages end with a carriage return

Security

You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.

There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.

If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.

Continue reading “The Android Linux Commander”

Retrotechtacular: The Noisy Home Computer From 1967

[Rex Malik] didn’t need an alarm clock. That’s because he had one of two “home computer terminals” next to his bed and, as you can see in the video below, it made quite a racket. The terminal looks like an ASR33 with some modifications. In 1967, it was quite a novelty and, of course, it didn’t have any real processing power. It connected to an “invisible brain” ten miles away.

What do you do with a computer in 1967? Well, it looks like you could trade stocks. It also apparently managed his shopping list and calendar. His young son also learned some letters and numbers. We’d love to hear from the young [Mr. Malik] today to find out what kind of computer he’s using now.

Continue reading “Retrotechtacular: The Noisy Home Computer From 1967”

Reverse Engineering A (Toy) Fire Engine

Your kid has a toy remote control fire truck. You have an RTL SDR. See where this is going? [Jacob] couldn’t resist tearing into the why and how of the truck’s remote control protocol.

The entire process began with a basic GNU Radio setup to determine the exact frequency of the signal. Then a little analysis suggested that it might be using amplitude shift keying. That is, the information is in the amplitude of the signal, where one possible amplitude is completely off in some cases.

Continue reading “Reverse Engineering A (Toy) Fire Engine”

Faux Potentiometers Use Magnets, No Contacts

Ever tear open a potentiometer? If you haven’t, you can still probably guess what’s inside. A streak of resistive material with some kind of contact that moves across it as you rotate the shaft, right? Usually, you’d be right, but [T. K. Hareedran] writes about a different kind of pot: ones that use magnetic sensing.

Why mess with something simple? Simplicity has its price. Traditional units may not be very accurate, can be prone to temperature and contamination effects, and the contact will eventually wear out the resistive strip inside. However, we were a little curious about how a magnetic potentiometer could offer a resistive output. The answer? It doesn’t.

Really, these would be better described as rotary encoders with a voltage output. They aren’t really potentiometers. The SK22B mentioned in the article, for example, requires a 5 V input and outputs somewhere between 10% and 90% of that voltage on the ersatz wiper pin.

That makes the devices much easier to puzzle out. The linearity of a device like that is better than a real pot, and, of course, the life expectancy is greatly increased. On the other hand, we’d rather get one with quadrature or I2C output and read it digitally, but if you need a voltage, these devices are certainly an option.

[T. K.] goes on to show how he fabricated his own non-contact sensor using photosensors and a gray-coded wheel with a single track. You do need to be careful about where you position the sensors, though.

Could you make a real non-contact resistive pot? Seems like you could get close with an FET output stage, but it wouldn’t be as generally applicable as a good old-fashioned smear of carbon. If you have a better idea, drop it in the comments or build it and give us a tip.

Want a 20A-capable device? Build it. Want to see how we like to read encoders?

Heart Rate Monitoring Via WiFi

Before you decide to click away, thinking we’re talking about some heart rate monitor that connects to a display using WiFi, wait! Pulse-Fi is a system that monitors heart rate using the WiFi signal itself as a measuring device. No sensor, no wires, and it works on people up to ten feet away.

Researchers at UC Santa Cruz, including a visiting high school student researcher, put together a proof of concept. Apparently, your heart rate can modify WiFi channel state information. By measuring actual heart rate and the variations in the WiFi signal, the team was able to fit data to allow for accurate heart rate prediction.

The primary device used was an ESP32, although the more expensive Raspberry Pi performed the same trick using data generated in Brazil. The Pi appeared to work better, but it is also more expensive. However, that implies that different WiFi chipsets probably need unique training, which, we suppose, makes sense.

Like you, we’ve got a lot of questions about this one — including how repeatable this is in a real-world environment. But it does make you wonder what we could use WiFi permutations to detect. Or other ubiquitous RF signals like Bluetooth.

No need for a clunky wristband. If you could sense enough things like this, maybe you could come up with a wireless polygraph.

Tips For Homebrewing Inductors

How hard can it be to create your own inductors? Get a wire. Coil it up. Right? Well, the devil is definitely in the details, and [Nick] wants to share his ten tips for building “the perfect” inductor. We don’t know about perfect, but we do think he brings up some very good points. Check out his video below.

If you are winding wire around your finger (or, as it appears in the video, a fork) or you are using a beefy ferrite core, you’ll find something interesting in the video.

Continue reading “Tips For Homebrewing Inductors”