CATS mobile transceiver in a 3d-printed case

CATS: A New Communication And Telemetry System

CATS is a new communication and telemetry standard intended to surpass the current Automatic Packet Reporting System (APRS) standard by leveraging modern, super-cheap Frequency Shift Keying (FSK) transceivers rather than standard FM units. The project is in the early stages, but as of this writing, there is a full open source software stack and reference hardware for both Raspberry Pi-based gateway devices and an STM32-based mobile device.

CATS packets are called ‘whiskers!’

From a radio perspective, CATS uses raw FSK rather than the inefficient AFSK used by APRS. A real killer for channel utilization is the PTT time; this is the dead time around a packet APRS requires for ‘keying up’ and ‘keying down.’ The CATS standard is aggressive with PTT timing, enabling the channel to get going on sending the data sooner.

Additionally, compared to APRS, the packet baud rate increases from 1200 baud to 9600 baud. Other key points are using LDPC encoding for forward error correction and data whitening (a useful PDF guide from Ti) to smooth over any burst errors.

One of the neat concepts of APRS is the APRS-IS (APRS Internet service). This enables amateur radio services to be connected over the Internet, vastly improving range. The CATS equivalent is called FELINET (if you’re not spotting all the ‘cat’ references by now, go and get another coffee). Together with the I-gate hardware, FELINET bridges the CATS radio side with the current APRS network. As FELINET expands to more than the current few dozen nodes, APRS services will no longer be required, and FELINET may well replace it. Interestingly, all software for FELINET, the APRS relay, and the I-Gate firmware are written in Rust. We told you learning Rust was going to be worth the effort!

On the reference hardware side of things, the CATS project has delivered a Raspberry Pi hat, which uses a 1 watt RF4463 transceiver and supporting passives. The design is about as simple as it can be. A mobile transceiver version uses an STM32 micro to drive the same RF4463 but with supporting power supplies intended to run from a typical automotive outlet. Both designs are complete KiCAD projects. Finally, once you’ve got some hardware in place and the software installed, you will want to be able to debug it. CATS has you covered with an RTL-SDR I-Gate module, giving you an independent packet log.

APRS is quite mature, and we’ve seen many hacks on these pages. Here’s an earlier APRS IGate build using a Raspberry Pi. Need to hook up your PC to a cheap Chinese transceiver? You need the all-in-one cable. As with many things amateur-radio-oriented, you can get playing cheaply.

Persistence Pays In TI-99/4A Cassette Tape Data Recovery

In the three or four decades since storing programs on audio cassettes has been relevant, a lot of irreplaceable personal computing history has been lost to the ravages of time and the sub-optimal conditions in the attics and basements where tapes have been stored. Luckily, over that time we’ve developed a lot of tools and techniques that might make it possible to recover some of these ancient treasures. But as [Noel] shows us, recovering data from cassette tapes is a tricky business.

His case study for the video below is a tape from a TI-99/4A that won’t load. A quick look in Audacity at the audio waveform seems to show the problem — an area of severely attenuated signal. Unfortunately, no amount of boosting and filtering did the trick, so [Noel] had to dig a bit deeper. It turns out that the TI tape interface standard, with its redundant data structure, was somewhat to blame for the inability to read this particular tape. As [Noel] explains, each 64-bit data record is recorded to tape twice, along with a header and a checksum. If neither record decodes correctly, then tape playback just stops.

Luckily, someone who had already run into this problem spun up a Windows program to help. CS1er — our guess would be “Ceaser” — takes WAV file input and loads each record, simply flagging the bad ones instead of just bailing out. [Noel] used the program to analyze multiple recordings of the same data and eventually got enough good records to reassemble the original program, a game called Dogfight — or was it Gogfight? Either way, he managed to get most of the data off the tape, and since it was a BASIC program, it was pretty easy to figure out the missing bytes by inspection.

[Noel]’s experience will no doubt be music to the ears of the TI aficionados out there. Of which we’ve seen plenty, from the TI-99 demoscene to running Java on one, and whatever this magnificent thing is.

Continue reading “Persistence Pays In TI-99/4A Cassette Tape Data Recovery”

Add A Little Quindar To Your Comms For That Apollo-Era Sound

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”

A Cassette Interface For A 6502 Breadboard Computer, Kansas City-Style

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”

Impatience Is A Virtue When Testing This Old Maritime Teleprinter

[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 (in German). 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”

RF Modulation: Crash Course For Hackers

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”

Reading Old Data Tapes, The Hard Way

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”