The demonstration is simple, using an ESP32 microcontroller fitted with two push buttons. When one button is pushed, it increments a counter and sends a Signal message noting the current count. The other button sends an image as a Signal message.
The project relies on a Signal bot to deliver an API key that enables the project to work. Messages are sent by making HTTP requests with this key to the CallMeBot.com server. With the API key as authentication, users can only send messages to their own number, keeping the system safe from spammers.
While the demonstration is basic, it merely serves to illustrate how the project works. The aim was to allow home automation and other Internet of Things systems to send Signal messages, and through this method, it’s now possible. The highly security conscious likely won’t want to rely on a random third party server, but for those tinkering around, it may not be such a big deal.
If you’ve been on the RTL-SDR forums lately you may have seen that a lot of work has been going into the DragonOS software. This is a software-defined radio group that has seen a lot of effort put into a purpose-built Debian-based Linux distribution that can do a lot of SDR out of the box. The latest and most exciting project coming from them involves a method for using the software to receive and demodulate analog video.
[Aaron]’s video (linked below) demonstrates using a particular piece of software called SigDigger to analyze an incoming analog video stream from a drone using a HackRF. (Of course any incoming analog signal could be used, it doesn’t need to be a drone.) The software shows the various active frequency ranges, allows a user to narrow in on one and then start demodulating it. While it has to be dialed in just right to get anything that doesn’t look like snow, [Aaron] is able to get recognizable results in just a few minutes.
Getting something like this to work completely in software is an impressive feat, especially considering that all of the software used here is free. Granted, this wouldn’t be as easy for a digital signal like most TV stations broadcast, but there’s still a lot of fun to be had. In case you missed the release of DragonOS, we covered it a few weeks ago and it’s only gotten better since then, with this project just as one example.
An ideal application for mesh networking is off-grid communication; when there’s no cellular reception and WiFi won’t reach, wide-area technologies like LoRa can be used to create ad hoc wireless networks. Whether you’re enjoying the outdoors with friends or conducting a rescue operation, a cheap and small gadget that will allow you to create such a network and communicate over it would be a very welcome addition to your pack.
Developer [Kevin Hester] tells us that these are still the very early days, and there’s plenty of work yet to be done. In fact, he’s actively looking to bring a few like-minded individuals onto the project. So if you have experience with the ESP32 or mobile application development, and conducting private communications over long-range wireless networks sounds like your kind of party, this might be your lucky day.
From a user’s perspective, this project is extremely approachable. You don’t need to put any custom hardware together, outside of perhaps 3D printing a case for your particular board. The first time around you’ll need to flash the firmware with esptool.py, but after that, [Kevin] says future updates can be handled by the smartphone application.
Incidentally, the primary difference between the two boards is that the larger and more expensive one includes GPS. The mesh networking side of things will work with either board, but if everyone in your group has the GPS-equipped version, each user will be able to see the position of everyone else in the network.
It is easy to think that a Linux shell like Bash is just a way to enter commands at a terminal. But, in fact, it is also a powerful programming language as we’ve seen from projects ranging from web servers to simple utilities to make dangerous commands safer. Like most programming languages, though, there are multiple layers of complexity. You can spend a little time and get by or you can invest more time and learn about the language and, hopefully, write more robust programs.
The year is 1894. You are designing a train system for a large city. Your boss informs you that the mayor’s office wants assurances that trains can’t have wrecks. The system will start small, but it is going to get big and complex over time with tracks crossing and switching. Remember, it is 1894, so computing and wireless tech are barely science fiction at this point. The answer — at least for the New York City subway system — is a clever system of signals and interlocks that make great use of the technology of the day. Bernard S. Greenberg does a great job of describing the system in great detail.
The subway began operation in 1904, well over 30 years since the above-ground trains began running. A clever system of signals and the tracks themselves worked together with some mechanical devices to make the subway very safe. Even if you tried to run two trains together, the safety systems would prevent it.
On the face of it, the system is very simple. There are lights that show red, yellow, and green. If you drive, you know what these mean. But what’s really interesting is the scheme used at the time to make them light.
An oscilloscope is a handy tool for measuring signals of all kinds, but it’s especially useful if you want to measure something with a periodic component. Modern oscilloscopes have all kinds of features built-in that allow you sample a wide range of signals in the hundreds of megahertz, and make finding and measuring your signal pretty easy, provided you know which buttons to push. There are some advanced oscilloscope methods that go beyond the built-in features of even the best oscilloscopes, and [AM] has a tutorial on one of them.
The method used here is called phase-senstitive detection, and allows tiny signals to be found within noise, even if the magnitude of the noise is hundreds of times greater than the signal itself. Normally this wouldn’t be possible, but by shifting the signal out of the DC range and giving it some frequency content, and then using a second channel on the oscilloscope to measure the frequency content of the source and triggering the oscilloscope on the second channel, the phase of the measured signal can be sifted out of the noise and shown clearly on the screen.
In [AM]’s example, he is measuring the intensity of a laser using a photodiode with a crude amplifier, but even with the amplifier it’s hard to see the signal in the noise. By adding a PWM-like signal to the power source of the laser and then syncing it up with the incoming signal from the photodiode, he can tease out the information he needs. It’s eally a fascinating concept, and if you fancy yourself a whiz with an oscilloscope this is really a tool you should have in your back pocket. If you’re new to this equipment, we do have a primer on some oscilloscope basics, too.
Anyone with even a passing familiarity with the classic animated shorts of the 1940s will recognize the traffic signal in the image above. Yes, such things actually existed in the real world, not just in the Looney world of [Bugs Bunny] et al. As sturdy as such devices were, they don’t last forever, though, which is why a restoration of this classic Acme traffic signal was necessary for a California museum. Yes, that Acme.
When you see a traffic signal from the early days of the automotive age like this one, it becomes quickly apparent how good the modern equivalent has become. Back in the day, with a mix of lights distributed all over the body of the signal, arms that extend out, and bells that ring when the state changes, it’s easy to see how things could get out of hand at an intersection. That complexity made the restoration project by [am1034481] and colleagues at the Southern California Traffic Museum all the more difficult. Each signal has three lights, a motor for the flag, and an annunciator bell, each requiring a relay. What’s more, the motor needs to run in both directions, so a reversing relay is needed, and the arm has a mechanism to keep it in position when motor power is removed, which needs yet another relay. With two signals, everything was doubled, so the new controller used a 16-channel relay board and a Raspberry Pi to run through various demos. To keep induced currents from wreaking havoc, zero-crossing solid state relays were used on the big AC motors and coils in the signal. It looks like a lot of work, but the end results are worth it.