Black Cat ALE: Decoding 24 ALE Channels in parallel!
Since its development in the late 1980s’, Automatic Link Establishment, or ALE, has made HF communications as easy as just pressing the PTT key of a transceiver. In the days before the MIL-STD-188-141-standard HF communications needed some knowledge about propagation and interference. Only 30% of first attempts to establish communications were successful. With the advent of ALE, this number jumped to about 90%, re-vitalizing HF as a reliable tool of communications.
Motto: Leader of the Pack. The Shangri-Las, 1965
HF Communications via ALE: Just press the (PTT) button
With ALE, the knowledge of an expert simply slipped into software. It starts with planning a network, defining the locations (regional, continental, worldwide) and the main times of traffic (daylight, dusk, night). This information is used to develop a set of, say, ten channels of which at least one or, better, two will provide communications under all given circumstances.
This set of channels is programmed into the transceivers of all participants of a network. The headquarters then cycles through all the channels all 30 minutes, or so. It transmits a short message in a very robust, redundant mode (8-FSK) with forward-error correction. Each receiver of the net is scanning through all channels, listening on each channel for about one second. The length of the transmission must be a bit longer than the number of channels, multiplied with the hold time of the scanner, at least ten seconds in the case of ten channels.
If the scanner identifies an ALE signal, it decodes it and saves some results like the quality of reception. After a while, it builds up a table of channels with each of its reception quality. To establish communications, one just has to press the PTT key: the software looks for the best channel, switching to it, and you can speak or do some other type of communications.
Great and world-wide activity
Since its introduction a generation ago, this concept is the tool of choice used worldwide by forces, diplomatic services, emergency agencies, police, militia, UN missions, drug enforcement, border control and even amateur radio. It is used from aircraft like AWACS, as from aircraft carriers, from mobile units to fixed stations. Within the last three years, I have logged 10’000 different combinations of call signs and frequencies from Chile to Australia, from Alaska to South Africa.
Usually, you will receive the so-called sounding of the stations, like TWAS CHONKAPKA, reading “this was Cho’n-Chapka, Kyrgyz border control on the border to Kazakhstan”. However, DXer’s business is not always that easy, needing some detective work and even direction finding to nail cryptic callsigns like HQ3, AAA or 344013. UDXF is a smart group which will help to unveil many of these secrets.
Now for the 3rd generation of ALE Decoders
The first generation of monitoring saw the DXer sticking to one channel for hours waiting for a signal. The second generation mimicked a network’s receiver, scanning through all the network’s channels. Now, state-of-the art covers up to 24 channels in parallel. This nothing other like a paradigm shift (Thomas S. Kuhn) is done with a wide-band SDR, free SDRC software featuring up to 24 demodulators, and a multi-channel decoder, accepting up to 24 different input signals to digest them. Demodulators and decoders are connected via Virtual Audio Cable, a software.
After having worked with one decoder, multi-instances, what proofed cumbersome when it came to e.g. 10+ parallel channels, we now embrace with the Black Cat ALE decoder the very first multi-channel ALE decoder doing all this as one-stop shop.
The Black Cat ALE decoder has been developed by Chris Smolinski, W3HFU, the smart brain behind Black Cat Systems. Chris already has developed a couple of unique (decoding) software, first for MacOS, then opened many of them also for Windows.
Paradigm Shift changes Monitoring Strategies
Chris has written his manual with also the practitioner in mind, plus giving some backgrounds of how his software works. so this doesn’t need too much echoing it – RTFM. I will concentrate on how to use it for efficient monitoring.
One decoder only: “Point and click” on a new level
Let’s start with one decoder only. This is the case where you want to analyse a recording by point-and-click to the ALE footprints on a spectrogram, made by SDRC’s File Analyzer. By this highly efficient technique you dig out new stations/frequencies.
Doing this for the first time with Black Cat ALE decoder, you soon will see that this software excels in raising incredibly weak signals you may even not hear or see in the spectrogram. From my findings, Black Cat ALE decoder surpasses each and every other software on the market, being this professional or for hobbyists. The user may set the sensitivity and the reliability of the results under its Settings tab: if the software listens deeper, the probability that noise or interference is interpreted as “signal”, is raising a bit. But this “deep decoding” is absolutely worthwhile using it.
The screenshot below shows this basic technique of clicking to a footprint in a spectrogram, done with SDRC’s File Analyser tool, and decoding it. You may double-click the screenshot to better read the details.
Multi-channel decoding: The right stuff
Using one decoder is a good start to get acquainted with all or at least many settings of the software and raising stations. The ultimate step is then to continuously monitor up to 24 channels, live. See the screenshot below for a first impression.
The screenshot above is the result of the following workflow which I consider “best practice”.
Step by step: How to prepare for multi-channel monitoring
The usual task is to monitor a network, in this example that of the U.S. Department of State (DoS) with their Embassies, Consulates General and other Diplomatic Missions.
This starts with a given set of frequencies, or channels. It also helps if you have a list of callsigns and the stations, associated with them. In this case – as in some others -, UDXF provides such a list.
I start with programming SDRC software with all 16 channels – RX1 … RX16, with their output feeding VAC1 … VAC16. Don’t forget to set AGC to fast in order to use always the highest sensitivity in case a strong signal is followed by a weak one. The latter may be missed with AGC slow. Check also if each channel is set to the correct sideband, usually USB, and a matching bandwidth, e.g. 600 to 2650Hz. Save this set of channels under the Favourites tab, see screenshot below, where the set of 16 DoS channels had been saved under – DoS_16.
With the receiver being prepared, start to prepare the decoder: first the input channels with their VAC number VAC1 … VAC16 and frequency, here 4553.6kHz … 24883.6kHz. Save these settings in a folder “Decoder Configuration”. From there, this and all other decoder’s configuration can be loaded into the decoder. This file is plain text, it may be edited, e.g. with free text editor Notepad++. The frequency notation must follow the international pattern 12345.6 and not 12345,6 which is used in some European countries. In the latter case, the 100Hz position is automatically set to zero.
Last step maybe to set up a text file with the call signs of a net plus additional information. For this, you have to follow the instructions in the manual. In this case, I set up a file of 306 known DoS callsigns and their locations, duly saved it in the folder “ale_callsigns” and invoked it into the decoder – see screenshot below.
Now all has been prepared to continuously monitoring the given set of channels (net) and see the results with their proper frequency, date, time, decoded callsign and matching text – as in the screenshot below, where I monitored some COTHEN channels in the way described above.
This output can be performed in a couple of formats (-> Setup), matching different formats. One of them is the format required by UDXF, also including your location/the source in brackets. Other formats are matching different needs for further processing with §rd-party software – spreadsheets and/or databases.
Limitations, hints, and twists
PC power: Please be aware of a few limitations of this setup. The number of channels is limited by the power of your PC. This technique eats up some resources, especially using 24 channels over say, 24MHz with 16bit SDR. If your PC doesn’t stand such approach, first try to reduce the HF span, say from 30MHz to 25, 20 or 15MHz – your mileage may vary. Many networks are regional, their channels are often located in a range of just a few MHz width. With a worldwide net, spanning (nearly) the whole HF range from 3 to 30MHz, you may reduce the span to about 15MHz, and shifting the range according to propagation at day or night.
One example: The DoS net spans from 4MHz to 25MHz and needs at least a HF bandwidth of 21MHz, alias-free. In practice, this calls for a 30MHz bandwidth for unattended 24/7 monitoring. If your PC doesn’t allow for this, you may use 15MHz or 20MHz bandwidth, using e.g., 10MHz to 25MHz at daylight and 4 to 19MHz at night.
To do so, just shift the lower bar in the SDRC GUI to the channels possible and/or needed. Channels outside this range will simply give no output. If you want to reduce the power requirement further, you should set these “dead” VACs to “Not used” at the decoder – but don’t forget to change this after againg having shifted the range. See screenshots below, showing the shifting of the range.
Sensitivity: Another “limitation” is to find the right balance between sensitivity of the decoder and preventing it to interpret noise as valid signals. In my experience, you have to use some care from BERs around 30 and higher. You may limit decoding to this value, but then you miss correct calls which can be received at BERs above 30.
Whenever you are in doubt: if the same callsign is seen on at least two or better three different channels, this is a reliable indicator for a valid callsign. Chris, the software author, has provided default settings, balancing near-perfect between high sensitivity and reliability. Change these defaults only if you know what you are doing. It is always a good idea to check and re-check a so far unknown callsign before logging and publication. You are responsible for trusting this or that result – not the software!
Audio files: Blackcat ALE Decoder also features a decoding from audio files. These are decoded in just a fraction of the original time. This welcome feature depends on your PC’s power; I reached a reduction of 1:13. You may mark several audio files which are decoded one after another.
This tool is ideal to experiment with different settings, i.e., trading reliability for sensitivity. Thanks to the butterfly effect [Edward D. Lorenz, 1972], the results when decoding ultra-weak signals or noise may or may not be the same when repeating this.
Callsigns/Configuration files: Keep them tidy and up-to-date. If needed, correct and/or complement them as soon as possible. They are the tools and the face of the software, of your results! They represent your skills.
It is a good practice to keep a separate “Callsigns” file for each (bigger) network. By this, you evade ambiguity, i.e. “HQ3” as used by a couple of different networks.
Always keep in mind the aim of your task which mainly will be monitoring one network. If needed, you can invoke more than one callsign files which the software will look up.
These files are both a great tool and a great temptation. Carefully used, they offer new perspectives, see below the live decoding (not redacted) of U.S. Coast Guard Medium Surveillance Aircraft #2313, ALE callsign N13, from which soundings on eight consecutive used transmitting channels had been received on October 29, 2021, in the late afternoon in Germany. Not bad for this HC-144 “Ocean Sentry” from EADS with its effectively radiating kind-of V-antenna, stretching from top of its tail fin down to its rear fuselage …
Thanks, Chris, for this unprecedented achievement in ALE monitoring!