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.
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.
The capitalisation of CATS makes me think that you should transmit this message:
How are you gentlemen!
All your base are belong to us.
(Yes, I know I’m thirty years out of date, but I couldn’t resist it.)
https://en.wikipedia.org/wiki/Zero_Wing
Missing some information about what this protocol can do / what its scope is. Is it for small battery-powered sensors? Or larger units? Such as what is the practical range achievable? What are the comparable standards and how does it compare? Is it more like LoRA or BLE beacons? There is mention of a 70 cm antenna, is that the smallest practical one can use?
It’s a replacement for ARPS, if you aren’t into this particular niche of amateur radio it’s useless for you. (and probably technologically inferior to LoRa alternatives)
It’s more like LoRa PHY layer but simpler.
Any improvement for APRS is welcome. Hams have aprs.fi, which is a free and very capable web platform. Basic telemetry is possible, which is gold for unattended monitoring of things (like solar powered repeaters) The weak link has been over-the-air radio access called ALOHA, which is brute force, 1200 Baud @ <50% duty, no ACK, no traffic control, and wide area abuse (like sending WX station reports every minute Wide2). Wishing the CATS proponents all the best!
I feel the urge to comment before the anti-rust crazies start coming out of the woodwork.
The baud rate increase is extremely nice. I’m actually surprised its so efficent — or, rather I guess I should say I’m surprised the current method is seemingly that much less efficient.
Rust! You killed my car! Prepare to die!
I’m not against Rust but I do feel that only making a single reference implementation in Rust is hurting the chances of catching on. C is generally what you want for these things because there are far more C compilers that can build for a lot more architectures.
Interesting. Another similar initiative is Ribbit (https://www.ribbitradio.org) which leverages the audio interface and processing capabilities of a smartphone, to couple the audio in a conventional FM radio.
>data whitening
That makes me think, suppose you wanted to send a radio signal but you didn’t want anyone to notice you’re radiating a signal. How would you make it indistinguishable from random background noise and still be able to receive it?
Basic data-in data-out philosophy could be a great place to start research to answer this question, but the long story short is that EMW need to be characterized in order for a transceiver to interpret the signals. You need to define the signal with data, the packet construction (if there are packets) and coordinate any encryption. Each EMW data transmission standard has it’s own protocols and while they may share similar frequencies and timing, they won’t be sharing the same logic of what the high/low signals mean when they are interpreted by the receiver. Here’s a decent place to get started to see signal baud and then work your way backwards to figure out if a transmission rate also has the a packet size that is useful to your projects https://en.wikipedia.org/wiki/List_of_interface_bit_rates. Another example is the IPv4 standard that will demonstrate how the signals are codified and sent then received (no matter the interface you choose to send the signal)
https://en.wikipedia.org/wiki/Internet_Protocol_version_4#Packet_structure
Adding on some clarity: Amplitude and frequency define your specific spectrum of Electromagnetic waves (EMW) and that limits the “noise” though specific filtering for that predefined frequency. Then it goes to interpreting the signal you are receiving, which often can’t be done without some sort of prior handshake whether in the signal itself or interaction with the receivers (humans) to define the method to interpret the signal into the desired structure/application. The ‘noise’ will always be there due to the nature of the universe (and millenia of Earth’s own activity including humans) but it’s about focusing on the correct signal and then listening in the right way.
An example of Morse Code is pretty simple: dot and dit, but only receivers who know what all the dots and dits mean can translate the ‘message’ by taking the low-energy pauses as breaks and the two sets of high-energy signals (short ‘dit’ or point and long ‘dot’ or dash) and then assessing the received data against a key. Morse Code can be transmitting over wire but also wirelessly and so long as you know the frequency you can listen in.
That’s going beyond the point. The question was about disguising radio transmission in general.
Well, if you make it broadband, and apodize it so the “carpet bump” is not sharp-edged, it would be tough to see it. However, if you’re transmitting significant power, the noise floor would increase in proximity to your transmitter antenna, and still make it easy to find.
You could disguise it as natural phenomena like whistlers or lightning but, again, high power would still make you visible, especially if you want to get much information bandwidth (bitrate) out.
If you need to get significant bitrate, maybe consider obfuscating the transmit location by bouncing off some natural feature.
Or you could piggyback on existing transmitters, a la steganography: do some low-rate pseudonoise phase or amplitude modulation of an existing transmission.
The transmitting power is of course a problem, since at some distance away you will see a significant signal above the noise floor regardless.
Maybe if you tapped into something that already makes radio noise, and transmit only when the noise source is on. Something like a big electric motor that has a VFD drive that generates noise.
Try searching Low Probability of Intercept or Low probability os Detection. Spread spectrum is a solution to this
I believe LoRa does something similar since it can demodulate below the noise floor up to a -20dB SNR, though I don’t know if that can be called “indistinguishable” from background noise
spread spectrum.
e. g.
what follows is just an example of a concept, not an example of the best way to implement the idea. Lets say that you use the set bits in a 2048 bit linear-feedback shift register (LFSR) to select the simultaneous frequencies used to transmit each symbol. Say bit-0 is 1kHz, bit-1 is 2kHz,… bit-2047 is 2048kHz. And you skip using all registers that do not have exactly 1024 bits set to one and 1024 bits set to zero, to keep the transmit power required constant. And lets say that the power of each transission at the frequencies selected by the bits in the LFSR are 10 dB below the normal noise floor. 1024 times the signals that are hidden 10 dB under the noise floor would produce, if you knew the frequencies a signal that is 20 dB above the noise floor (-10dB+10*3dB). But only as long as the transmission and reception side are synchronised and start with the same initial LSFR seed value. They in theory can share secret transmissions, but in reality someone may still detect that there ae transmissions if they were to intergrate the noise spectrum over a long enough peirod of time, spikes at the frequencies used would be revealed. But without knowing the LSFR parameters, or frequency selection algorithm, they would be unable to decode the tranmissions hidden underneath the noise floor.
That’s what I was thinking – but like you point out, any time you add power, it shows up as “bumps under the carpet” for anybody bothering to look for them. The question is, what strategy you would use to keep people from noticing that you’re adding power to a particular band.
One way to disguise transmission is to keep transmitting “white” noise equally across the band, except it isn’t all random whenever you actually do transmit data- but that’s the opposite of what I was thinking. You’re simply disguising whether there is data or not, but someone can still see that you’re sending out radio waves.
Maybe disguise it as something else that naturally sends out radio interference?
Dude, I think what you are looking for is “mental telepathy”.
Seriously, anything you do to make your signal readable decreases its covertness, and vice versa. Something-something thermodynamics and something-something information theory.
That’s exactly the problem. The question is, what could you do to make it not so obvious, at least to present means of detecting a radio transmission?
What if you move the transmission across the entire band, that every transmission is tuned by an offset of a few additional Hz until the baseband signal eventually reaches the end of the selected frequency band and then goes back to the start of the selected band and repeats that process. Long term integration of the noise would only show a tiny increase in the noise across the entire band selected and not the individual transmissions at discrete frequencies. Or use a scaled second LSFR for the tuned frequency offset.
Extremely long term integration of the noise would still show that something hinky was going on. But that would not shed much light on the reason why the noise floor was rising.
If someone did a waterfall plot of the noise, they’d see you shifting up or down the band by observing stripes in the noise amplitude.
If each line of the waterfall is averaged over minutes to an hour I guess you will notice something. The thing to keep in mind is that the “signal” is 10dB below the noise floor so in effect our addition will bump half the random pixels that are being displayed 1 shade brighter (1024 frequencies transmit a signal ) and the other half will be 1 shade darker (1024 are no transmission) that the brighter pixels.
For waterfall plot the screen is not millions of pixels wide so even a 1024 point FFT (which would fit on a 1920×1080 HDMI display) each bin is the average of ~2000 Hz, if an SDR (Software Defined Radio) is displaying 2 MHz of bandwidth. Or each pixel that is displayed is the average power in ~2000 Hz of bandwidth. 2 frequencies out of 2000 will be one pixel brighter, but when averaged with 1998 others any increase would go unnoticed. So I doubt you will be see lines, unless you really increase the integration time and then you will see more odd things appear.
Spread spectrum?
> 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.’
Not really. Most VHF/UHF FM radios are quick, except for RDA-based radios (Baofeng, SA818, etc.). RDA-based radios are slow to go from RX to TX and very slow to go from TX to RX. This makes them work poorly for AX.25 because they miss reply packets. And the retries harm the network.