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.
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?
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.
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.
Using digital techniques has caused a resurgence of interest in VLF — very low frequency — radio. Thanks to software-defined radio, you no longer need huge coils. However, you still need a suitable antenna. [Electronics Unmessed] has been experimenting and asks the question: What really matters when it comes to VLF loops? The answer he found is in the video below.
This isn’t the first video about the topic he’s made, but it covers new ground about what changes make the most impact on received signals. You can see via graphs how everything changes performance. There are several parameters varied, including different types of ferrite, various numbers of loops in the antenna, and wire diameter. Don’t miss the comment section, either, where some viewers have suggested other parameters that might warrant experimentation.
Don’t miss the 9-foot square antenna loop in the video. We’d like to see it suspended in the air. Probably not a good way to ingratiate yourself with your neighbors, though.
Between software-defined radio and robust computer simulation, there’s never been a better time to experiment with antennas and radios. We first saw these antennas in an earlier post. VLF sure is easier than it used to be.
If you ever develop an embedded system in a corporate environment, someone will probably tell you that you can only use 80% of the CPU or some other made-up number. The theory is that you will need some overhead for expansion. While that might have been a reasonable thing to do when CPUs and operating systems were very simple, those days are long gone. [Brendan Long] explains at least one problem with the idea in some recent tests he did related to server utilization.
[Brendan] recognizes that a modern CPU doesn’t actually scale like you would think. When lightly loaded, a modern CPU might run faster because it can keep other CPUs in the package slower and cooler. Increase the load, and more CPUs may get involved, but they will probably run slower. Beyond that, a newfangled processor often has fewer full CPUs than you expect. The test machine was a 24-core AMD processor. However, there are really 12 complete CPUs that can fast switch between two contexts. You have 24 threads that you can use, but only 12 at a time. So that skews the results, too.
Of course, our favorite problem is even more subtle. A modern OS will use whatever resources would otherwise go to waste. Even at 100% load, your program may work, but very slowly. So assume the boss wants you to do something every five seconds. You run the program. Suppose it is using 80% of the CPU and 90% of the memory. The program can execute its task every 4.6 seconds. So what? It may be that the OS is giving you that much because it would otherwise be idle. If you had 50% of the CPU and 70% of the memory, you might still be able to work in 4.7 seconds.
A better method is to have a low-priority task consume the resources you are not allowed to use, run the program, and verify that it still meets the required time. That solves a lot of [Brendan’s] observations, too. What you can’t do is scale the measurement linearly for all these reasons and probably others.
Not every project needs to worry about performance. But if you do, measuring and predicting it isn’t as straightforward as you might think. If you are interested in displaying your current stats, may we suggest analog? You have choices.
If you are interested in retrocomputers, you might be like us and old enough to remember the old systems and still have some of the books. But what if you aren’t? No one is born knowing how to copy a file with PIP, for example, so [Kraileth] has the answer: A Gentle Introduction to CP/M.
Of course, by modern standards, CP/M isn’t very hard. You had disks and they had a single level of files in them. No subdirectories. We did eventually get user areas, and the post covers that near the end. It was a common mod to treat user 0 as a global user, but by default, no.
