If you’ve scavenged some random keypads and want to reuse them in a project without the hassle of figuring out the pinouts, then [Cliff Biffle] has an interface module for you. The Keypad Go connects to the mystery keypad via an 8-pin 0.1 inch header, and talks to your own project using I2C and/or serial.
You could categorize the mechanism at work as machine learning of a sort, though it’s stretching definitions a bit, as there is no ChatGPT or GitHub Copilot wizardry going on here. But you must teach the module during an initial calibration sequence, assigning a 7-bit ASCII character to each key as you press it. Once trained, it responds to key presses by sending the pre-assigned character over the interface. Likewise, key releases send the same character but with the 8th bit set.
The heart of the board is either an STM32G030 or STM32C011/31, depending on parts availability we presume. I2C connectivity is over a four-pin STEMMA connector, and logic-level serial UART data is over a four-pin 0.1 inch pin header. [Cliff] plans to release the firmware and schematics as open source soon, after cleaning up the code a bit. The device is also for sale on Tindie, though it looks like they won’t be back in stock until later on in the month.
Longtime readers might recognize [Cliff] from his impressive m4vga project which we covered back in 2015, where he manages to generate 800×600 VGA signals at 60 Hz from an STM32F4-family microcontroller.
It’s been a long time since computer hobbyists stored their programs and data on cassette tapes. But because floppy drives were expensive peripherals and hard drives were still a long way from being the commodity they are today, cassettes enjoyed a long run at the top of the bulk data storage heap.
Celebrating that success by exploring the technology of cassette data storage is the idea behind [Greg Strike]’s Kansas City decoder project, which he hopes to use with his [Ben Eater]-style 6502 computer. The video below explains the Kansas City standard in some detail, and includes some interesting historical context we really hadn’t delved into before. There are also some good technical details on the modulation scheme KCS used, which [Greg] used to base his build. After a failed attempt to use an LM567 tone decoder chip, he stumbled upon [matseng]’s KCSViewer project, which decodes KCS-encoded audio signals using nothing but discrete components.
[Greg]’s prototype has a comparator to convert sine waves to square waves, followed by pair of monostable timers, each tuned to either the high or low frequency defined in the KCS specs. A test signal created using Audacity — is there anything it can’t do? — was successfully decoded, providing proof of concept for the project’s first phase. We’re looking forward to the rest of the series, which will turn this into an actual decoder, and presumably add an encoder as well.
As side-channel attacks go, it’s one of the weirder ones we’ve heard of. But the tech news was filled with stories this week about how Janet Jackson’s “Rhythm Nation” is actually a form of cyberattack. It sounds a little hinky, but apparently this is an old vulnerability, as it was first noticed back in the days when laptops commonly had 5400-RPM hard drives. The vulnerability surfaced when the video for that particular ditty was played on a laptop, which would promptly crash. Nearby laptops of the same kind would also be affected, suggesting that whatever was crashing the machine wasn’t software related. As it turns out, some frequencies in the song were causing resonant vibrations in the drive. It’s not clear if anyone at the time asked the important questions, like exactly which part of the song was responsible or what the failure mode was on the drive. We’ll just take a guess and say that it was the drive heads popping and locking.
It’s no secret that the era of the landline telephone is slowly coming to a close. As of 2020, it was estimated that less than half the homes in America still subscribed to plain old telephone service (POTS). But of course, that still amounts to millions upon millions of subscribers that might get a kick out of this Arduino caller ID developed by [Dilshan Jayakody].
Truth be told, until this point, we hadn’t really given a lot of thought to how the caller ID system works. But as [Dilshan] explains, you can actually pick up a dedicated IC that can decode incoming caller data that’s sent over the telephone line. In this case he’s using a Holtek HT9032D, which comes in a through-hole DIP-8 package and can be picked up for around $2 USD. The chip needs a handful of passives and a 3.58 MHz crystal to help it along on its quest, but beyond that, it’s really just a matter of reading the decoded data from its output pin.
To display the caller’s information, [Dilshan] is using an Arduino Uno and common 16×2 HD44780 LCD. As a nice touch, the code will even blink the Arduino’s onboard LED when you’ve missed a call. As a proof of concept there’s been no attempt to condense the hardware or ditch the breadboard, but it’s not hard to imagine that all the components could be packed into a nice 3D printed enclosure should you want something a bit more permanent.
We’ve seen caller ID data being collected in previous projects, but they used a USB modem combined with a software approach. We really like the idea of doing it with a cheap dedicated IC, though we’ll admit this demonstration would probably have been a bit more exciting a decade ago.
Hardware development often involves working with things that can’t be directly perceived, which is one reason good development tools are so important. In appreciation of this, [David Johnson-Davies] created the IR Remote Control Detective to simplify working with IR signals. While IR remote controls are commonplace, there are a number of different protocols and encoding methods in use across different brands. The IR Detective takes care of all of that with three main components, none of which are particularly expensive. To use the decoder, one simply points an IR remote at the unit and presses one of the buttons. The IR Detective will identify the protocol, decode the signal, and display the address and command related to the key that was pressed. The unit doesn’t consist of much more than an ATtiny85 microcontroller, a small OLED display, and an IR receiver unit. The IR receiver used is intended for a 38 kHz carrier, but such receivers can and do respond to signals outside this frequency, although they do so at a reduced range.
As a result, not only is the unit useful for decoding IR or verifying that correct signals are being generated, but the small size and low cost means it could easily be used as a general purpose receiver to add IR remote control to other devices. It’s also halfway to bridging IR to something else, like this WiFi-IR bridge which not only interfaces to legacy hardware, but does it across WiFi to boot.
For a hobby that’s ostensibly all about reaching out to touch someone, ham radio can often be a lonely activity. Lots of hams build and experiment with radio gear much more than they’re actually on the air, improving their equipment iteratively. The build-test-tweak-repeat cycle can get a little tedious, though, especially when you’re trying to assess signal strength and range and can’t find anyone to give you a report.
To close the loop on field testing, [WhiskeyTangoHotel] threw together a simple ham radio field confirmation unit that’s pretty slick. It relies on the fact that almost every ham radio designed for field use incorporates a DTMF encoder in the microphone or in the transceiver itself. Hams have used Touch Tones for in-band signaling control of their repeaters for decades, and even as newer digital control methods have been introduced, good old analog DTMF hangs in there. The device consists of a DTMF decoder attached to the headphone jack of a cheap handy talkie. When a DTMF tone is received, a NodeMCU connected to the decoder calls an IFTTT job to echo the key to [WTH]’s phone as an SMS message. That makes it easy to drive around and test whether his mobile rig is getting out. And since the receiver side is so portable, there’s a lot of flexibility in how tests can be arranged.
On the fence about ham as a hobby? We don’t blame you. But fun projects like this are the perfect excuse to go get licensed and start experimenting.
In the first part of our series on in-band signaling, we discussed one of the most common and easily recognizable forms of audio control, familiar to anyone who has dialed a phone in the last fifty years – dual-tone multifrequency (DTMF) dialing. Our second installment will look at an in-band signaling method that far fewer people have heard, precisely because it was designed to be sub-audible — coded squelch systems for public service and other radio services. Continue reading “In-Band Signaling: Coded Squelch Systems”→