If there’s one thing that ties together all the media coming out of the Apollo era, it’s probably the iconic Quindar tones. These quarter-second beeps served as control tones for the globe-spanning communications network needed to talk to the Apollo astronauts, and any attempt to recreate the Apollo-era sound would be glaringly wrong without them. And that’s why [CuriousMarc] whipped up this Quindar tone system.
The video below starts with a detailed treatment of what Quindar tones are and why they were used, a topic we’ve covered ourselves in the past. To recap, Quindar tones are a form of in-band signaling, with a 2,525-Hz pure sine wave intro tone that signaled the transmitters connected to Mission Control in Houston over leased telephone lines to key up. The 2,475-Hz outro tone turned off the transmitters and connected the line to the receivers.
To recreate the sound quality of the original circuitry, and to keep in the retro vibe, [Marc]’s Quindar homage avoided digital circuitry as much as possible, opting instead to generate the two tones with an XR-2206 function generator chip. The chip can rapidly switch back and forth between two frequencies, making it perfect for FSK applications or, in this case, reproducing the two slightly different tones. [Marc] added a dual mono-stable multi-vibrator to pulse the tone, giving the 250-ms pulse, and an audio gate, which uses a MOSFET to switch the tone into an audio stream. All this got soldered up to a piece of perf board and stuffed in the base of a cheap intercom microphone, which while not period accurate still has a cool retro look — and now, a retro sound, too.
Hats off to [CuriousMarc] and his merry band for probing the mysteries of Apollo-era comms and keeping the accomplishments of all those engineers alive. The methods they used are still relevant after all these years, and there seems to be no end to what we can learn from them.
Continue reading “Add A Little Quindar To Your Comms For That Apollo-Era Sound” →
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.
Listeners of the Hackaday Podcast may recall we experimented with using KCS to hide some data within an episode a few months back.
Continue reading “A Cassette Interface For A 6502 Breadboard Computer, Kansas City-Style” →
[Larry Wall], inventor of Perl, once famously said that programmers have three key virtues: sloth, hubris, and impatience. It’s safe to say that these personality quirks are also present in some measure in most hardware hackers, too, with impatience being perhaps the prime driver of great hacks. Life’s too short to wait for someone else to build it, whatever it may be.
Impatience certainly came into play for [Sebastian (AI5GW)] while hacking a NAVTEX receiver. The NAVTEX system allows ships at sea to receive text broadcast alerts for things like changes in the weather or hazards to navigation. The trouble is, each NAVTEX station only transmits once every four hours, making tests of the teleprinter impractical. So [Sebastian]’s solution was to essentially create his own NAVTEX transmitter.
Job one was to understand the NAVTEX protocol, which is a 100-baud, FSK-modulated signal with characters encoded in CCIR 476. Since this encoding is also used in amateur radio teletype operations, [Sebastian] figured there would surely be an Arduino library for encoding and decoding it. Surprisingly, there wasn’t, but there is now, allowing an Arduino to produce the correct sequence of pulses for a CCIR 476-encoded message. Fed into a function generator, the mini-NAVTEX station’s signal was easily received and recorded by the painfully slow teleprinter. There’s that impatience again.
We thought this was a neat hack, and we especially appreciate that [Sebastian]’s efforts resulted in a library that could be useful to hams and other radio enthusiasts in the future. We’ve talked about some more modern amateur radio digital modes, like WSPR and FT8, but maybe it’s time to look at some other modes, too.
Continue reading “Impatience Is A Virtue When Testing This Old Maritime Teleprinter” →
When you’re looking to add some wireless functionality to a project, there are no shortage of options. You really don’t need to know much of the technical details to make use of the more well-documented modules, especially if you just need to get something working quickly. On the other hand, maybe you’ve gotten to the point where you want to know how these things actually work, or maybe you’re curious about that cheap RF module on AliExpress. Especially in the frequency bands below 1 GHz, you might find yourself interfacing with a module at really low level, where you might be tuning modulation parameters. The following overview should give you enough of an understanding about the basics of RF modulation to select the appropriate hardware for your next project.
Three of the most common digital modulation schemes you’ll see in specifications are Frequency Shift Keying (FSK), Amplitude Shift Keying (ASK), and LoRa (Long Range). To wrap my mechanically inclined brain around some concepts, I found that thinking of RF modulation in terms of pitches produced by a musical instrument made it more intuitive.
And lots of pretty graphs don’t hurt either. Signals from two different RF dev boards were captured and turned into waterfall and FFT plots using a $20 RTL-SDR dongle. Although not needed for wireless experimentation, the RTL-SDR is an extremely handy debugging tool, even to just check if a module is actually transmitting. Continue reading “RF Modulation: Crash Course For Hackers” →
Those who were around for the pre-floppy days of computer mass storage were likely to have made the mistake of slipping a cassette tape containing data into a stereo tape deck. Instead of hearing the expected Awesome Mix, the speakers gave off an annoying bleat, warbling between two discordant tones and no doubt spoiling the mood.
What you likely heard was the Kansas City standard, an early attempt to provide the budding microcomputer industry with a mass-storage standard. It was successful enough that you can still find KCS tapes in need of decoding to this day. That job would be a snap with a microcontroller, which is exactly why [matseng] chose to do it the hard way and built a KCS decoder with nothing but discrete components.
The goal was to decode the frequency-shift-keyed (FSK) signal into an 8-bit parallel output, and maybe drive a seven-segment display as the characters came off the tape at a screaming 300 baud. Not an IC is in sight in the schematics; as [matseng] says, it’s nothing but “Qs, Rs, and Cs.” All the amps, flip-flops, and counters needed are built from a forest of transistors, and even the seven-segment display is a DIY affair of LEDs in a 3D-printed and hot-glue frame. The video below shows the display doing its best to show the alphanumeric characters encoded on the audio tape. And for who absolutely need a dose of Arduino, [matseng] used one along with a dead-bug low-pass filter to emulate KCS signals, for easier development.
We always appreciate hackers who take the road less traveled to arrive at a solution, but if you’re pressed for time to decode some KCS tapes, fear not – all you need is a PC and Audacity.
Continue reading “Reading Old Data Tapes, The Hard Way” →
Many of the hacks featured here are complex feats of ingenuity that you might expect to have emerged from a space-age laboratory rather than a hacker’s bench. Impressive stuff, but on the other side of the coin the essence of a good hack is often just a simple and elegant way of solving a technical problem using clever lateral thinking.
Take this project from [drtune], he needed to synchronize some lighting to an audio stream from an MP3 player and wanted to store his lighting control on the same SD card as his MP3 file. Sadly his serial-controlled MP3 player module would only play audio data from the card and he couldn’t read a data file from it, so there seemed to be no easy way forward.
His solution was simple: realizing that the module has a stereo DAC but a mono amplifier he encoded the data as an audio FSK stream similar to that used by modems back in the day, and applied it to one channel of his stereo MP3 file. He could then play the music from his first channel and digitize the FSK data on the other before applying it to a software modem to retrieve its information.
There was a small snag though, the MP3 player summed both channels before supplying audio to its amplifier. Not a huge problem to overcome, a bit of detective work in the device datasheet allowed him to identify the resistor network doing the mixing and he removed the component for the data channel.
He’s posted full details of the system in the video below the break, complete with waveforms and gratuitous playback of audio FSK data.
Continue reading “Synchronize Data With Audio From A $2 MP3 Player” →
Do you see the patterns everywhere around you? No? Look closer. Still no? Look again. OK, maybe there’s nothing there.
[Oona Räisänen] hears signals and then takes them apart. And even when there’s nothing there, she’s thinking “what if they were?” Case in point: could one hypothetically transmit coded information in the trilling of a referee’s whistle at the start of a soccer match?
To you, the rapid pitch changes made by the little ball that’s inside a ref’s whistle sounds like “trilling” or “warbling” or something. To [Oona], it sounds like frequency-shift key (FSK) modulation. Could you make a non-random trilling, then, that would sound like a normal whistle?
Her perl script says yes. It takes the data you want to send, encodes it up as 100 baud FSK, smoothes it out, adds some noise and additional harmonics, and wraps it up in an audio file. There’s even a couple of sync bytes at the front, and then a byte for packet size. Standard pea-whistle protocol (PWP), naturally. If you listen really closely to the samples, you can tell which contains data, but it’s a really good match. Cool!
[Oona] has graced our pages before, naturally. From this beautiful infographic tracing out a dial-up modem handshake to her work reversing her local bus stop information signs or decoding this strange sound emitted by a news helicopter, She’s full of curiosity and good ideas — a hacker’s hacker. Her talk on the bus stop work is inspirational.. She’s one of our secret heroes!