Category Archives: Utility_DX

Multi-channel ALE Decoder: Listing and Logging

As if by magic, a file [invoked, marked yellow] completes the decoded messages to a complete and easily readable log. ALE callsign “111111” had no entry in the file, therefore this unidentified USAF aircraft cannot be solved.

Chris Smolinski’s Black Cat Systems ALE Decoder has changed monitoring ALE messages which are widely used onf HF to provide an automatic link establishment. It has set the standard not only by its unsurpassed sensitivity and the option to decode up to 24 channels in parallel, but also with its look-up table for “translating” cryptic ALE callsigns into stations and locations of flesh and blood. Tahnks to this, the usual decoded message of just

  • 7527.0 [Frequency in kHz] USB [mode] 2021-11-10 22:54:24 [date/time] 16 [BER] TO TSC TIS K62

turns into:

  • 7527.0 USB 2021-11-10 22:54:24 16
    TO TSC COTHEN Technical Service Center Orlando FL USA
    TIS K62 USGC MH-65D/E Short Range Recovery Helicopter Dolphin #6562 USA

This blog entry provides a description of the system as well as a list of 3’200+ ALE callsigns as a First Aid Kit.

How Callsigns come into Life

This feature is a major achievement in DXing. And it is, too, that innovative that we have to set our sails into unchartered sea. [Do you remember the completely blank OCEAN-CHART. in Lewis Caroll’s “The Hunting of the Snark” from 1876? You are here!]

The general idea of the software is to look-up each decoded callsign in a list of tab-separated information where you already had collected metadata like organization, station, location, country – anything you consider important.
The software then looks up each callsign – as above TSC and K62 -, introduces all the information in a neat way and prints it all together in the window. Even more, as the software automatically fills a logfile with all this for later inspection, edition and further processing by spreadsheet or database. Smart! And unique!

The callsigns’ document and its quality (extent, reliability, consistency …), of course, plays a pivotal role, see following illustration – shit in, shit out.

Information is circling from your Reference Database into the decoder’s look-up files (folder “ale_callsigns”) and back.

Whatever format your Reference Database may have, it will and must put out a simple tab-separated textfile.

It helps if you think of different type of data (organization, location, country …) as of different fields or cells, each separated by a TAB from each other – see an example with just one entry below.
All data fenced in by TAB can contain arbitrary characters, such as spaces, brackets, commas etc.

ALE CallOrganizationNameLocationTypeITU
HNCUSCGHarriet LanePortsmouth VAWMEC-903USA
Each cell/field is separated by a TAB. “Harriet” and “Lane” are separated by just a blank and as a result handled as one cell/field “Harriet Lane”.

Different output Formats for different Tastes

The decoder may present the same decoded message plus the same information from your callsign file in different ways, controlled by the “Settings” menu of the decoder:

Let us now decline the different Message Formats for a simple message of LNT calling J10 on November 6th, 2021 at 22:19:59 UTC, with data from “ale_callsigns”, see lines 16 to 18 :

Same message and same decode, but different formats and different log entries as well.

The sources for e.g., line 42 are marked in colors:

Divide and conquer

The look-up table(s) must be saved in a directory called “ale_callsigns” (lower case!) in the Documents directory for your user account.

The look-up table must be saved in the Documents directory for your user account.

Above you see not only one callsigns’ file, but many. There is a reason for that: If you have a large callsign file, undoubtedly some one and the same callsign will be valid for two or several stations. If the software detects this case, it prints (original decoded message):

  • 03 5732.0 USB 2021-11-10 22:29:03 31 TWAS J51 Ambiguous – multiple entries

This is because the list contains (in this case) two entries under callsign J51, namely:

  • J51 Royal Moroccan Armed Forces MRC
  • J51 USGC MH-60T Medium Range Helicopter #6051 USA

You can evade this ambiguity by defining different jobs with matching callsigns lists. If you want to check the channels of USCG/COTHEN, you should query your database for USCG only, save this set and invoke just this reduced set of callsigns instead of the complete bunch – divide et impera. This technique in most cases reduces the problem or even avoids it at all.
There maybe also the effect of a “false positive”: if a callsign doubles on two different stations, but you have listed only one under this callsign, being this the wrong one for the given case.

Basic Reference List: Database or Spreadsheet

I keep my data in a very simple FileMaker database with each entry carrying an individual number ALE_ref.

Example for one entry in my FileMaker database

Then you can query the list: “Tell me all USCG entries located in Alaska!”, getting this window out of your database. This must be exported as TAB-separated file (“USCG_ALS”) and put into the “ale_callsigns” folder of your “Documents” directory.

Result after asking for all USCG entries, located in Alaska.

Of course, you may use any type of spreadsheet and/or database.

You can see the content of folder “ale_callsigns” in the dropdown menu “Callsigns” of the decoder. There you have the choice to select one, two or many files or even “all”.

Under “Callsigns” there are listed all available callsigns files. Here I choose file “Full.tab” with 3175 entries of which 2956 are unique – as the decoder tells you under tab ” Channel 1″.

Callsigns: A First Aid Kit, 3’000+ entries

To become a bit acquainted with this new function, I prepared a list of callsigns containing only very few basic data. It must, of course, contain the callsign for looking up. I then provided fields for the organziation (USCG), the station itself, its location and the ITU 3-letter code. All fields/cells mut be separated by a TAB. For each field which is left empty (i.e., if you don’t know the location), you must insert a TAB instead. Otherwise, the other data may be wrongly allocated in your log. I also tried to keep a balance of streamlined data and the obvious desire not to have be a Rear Admiral of the Navy to understand all the acronyms. The list works perfect for the decoder, plus as sink and as source for your by far more flexible reference database/spreadsheet.

I plan to extend the list as well as to correct the mistakes. Your support is welcome!

The list is a first approach in format and content. It surely works fine. As all work in this field, it combines information from many different sources, contributors to UDXF must be named first. The list is also flavored with my own monitoring log of more than 11000 entries, being all different in call/frequency. In addition, there is a lot of information around in the web – surprisingly often from the organizations themselves, but also from flight spotters, vessel spotters etc. I am sure that all information used is “open”, as otherwise I couldn’t had no access to it … got it?

You can download the zipped list here:

If this doesn’t work, drop me a line under dk8ok_at_gmx.net.

Black Cat ALE: Decoding 24 ALE Channels in parallel!

Here shown with 13 decoders only, Black Cat ALE decoder will read up to 24 different 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.

Decoding by point and click, see text.

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.

Live monitoring of 16 channels of the U.S. Department of State, see text.

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.

Favourites: Follow the red arrow to save your set of channels …
… all the channels appear in the RX window of SDRC. Don’t forget to activate them “All”!

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.

Part of the Decoder Configuration file, containing the number of entries (16), followed by frequency and input of each channel, opened in Notepad++.

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.

Load the callsigns’ list.

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.

Part of decoded messages – monitoring 18 COTHEN channels. For P21, T1B and 715 there had been found no matching entry in the callsigns’ list.

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.

With the bandwidth spanning 33MHz, the alias-free reception range will cover all 16 DoS channels from 4MHz to 25MHz. See yellow box at the bottom (“slider”) and broken line within the spectrum.
If only a smaller bandwidth is possible (here:16,6MHz), change the bar at the bottom according to propagation. Here it is set to cover only channels 6 … 16 (broken line) and the slider (yellow box) has been shifted downwards to cover the lowest channels for night-time reception.

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 …

That’s live/life: USCG Medium Surveillance Aircraft #2313, decoded soundings on eight channels within 90 seconds.

Thanks, Chris, for this unprecedented achievement in ALE monitoring!

Decoding ADS-B with free QIRX software

QIRX’ dashboard, decoding ADS-B: in the middle you see spectrum and spectrogram (“waterfall”) of the ADS-B signals. The window at the bottom lists alls received aircraft with additional data, whereas the top window places them onto a map.

In the last two blog entries, I took a look at the DAB capabilities of free software QIRX by Clem Schmidt, DF9GI, from Frankfurt. It directly works with RTL-SDR, Airspy and RSP2 SDRs. I tried this very smart software from my location near Hannover/North Germany now also with ADS-B, mostly with my RSP2.

ADS-B stands for “Automatic Dependant Surveillance – Broadcast” and is an automatic service where aircraft continuously transmits several vital data on around 1.090MHz. Most important part of these data is the 2D location of the aircraft which it gets by GPS plus height by a baromatric altimeter. From this position data, many other data are derived, e.g. climbing/sinking or speed. If matched to databases, you will also see type of aircraft, flight number and many other data.

“The internet” provides many services showing the results of ADS-B and other data, collected from receivers all over the world, among them Flightradar24, OpenSky, FlightAware and AirNavRadarbox. They each provide many additional data, somtimes available at different schemes. Most provide free access to much of their data, with some more specific data behind their paywall. OpenSky as a scientific and non-profit organization offers billions of datasets for free, see Scientific Datasets. QIRX uses an OpenSky data base with about 650’000 entries.

Backbone of all these services is a net of ADS-B receivers, connected via the internet and curated by each company.

QIRX shows some capabilities of such a receiving station, using a proper antenna and a simple SDR. It decodes the I/Q stream of it. ADS-B is transmitted via pulse-position modulation, or ppm. The system is explained in ICAO Annex 10 Volume IV [free download].

With QIRX, you must set the sampling rate of you SDR to 200000[Hz], as other sampling rates won’t work, see screenshot below.

To decode ADS-B, you must set the sample rate for your SDR to 2000000Hz.

After that, and having started QIRX in ADS-B mode, decoding is done automatically. Release your seatbelts, and simply relax by viewing the activities above your head. Coverage largely depends on the “view” of you antenna and a few other factors like te sensitivity of your SDR and the attenuation of your cable connecting your antenna with your SDR. Some web services, thanks to anticipatory obedience/security reasons/data protection etc., do mute some “special” flights . This is not the case, of course, with this setup. QIRX always provides stable decoding at even low SNRs – great!

Last, but not least, please find below a comparison of FlightRadar24 and QIRX setup with Flight Number TK1554/THY6KG, Hannover->Istanbul, starting from Hannover Airport. One difference between both screenshots is that at my location (Burgdorf), I got the Airbus only after it had climbed to an atlitude of 200m or so, whereas the FR24 receivers are placed at positions allowing for tracking the aircraft from even the runway.

Starting from Hannover to Istanbul: the airbus on track around Hannover. Top window shows the flight via FlightRadar24 web service, and even from the runway. Bottom window shows it received with QIRX from Burgdorf (red point in the northeast).

Also small aircraft is equipped with transponders, but not necessarily with ADS-B transponders, broadcasting the position, derived from their GPS. These small aircraft may haveonly Mode-S transponders on board, transmitting identification, height and squawk (transponder code) as assigned by their responsible ATC, or Air Traffic Control.

Doppler: Following Airplanes’ tracks

Carrier and Doppler trace (left), locations of transmitter, receiver and track of flight NH8406 – March 27, 2021, around 16:45 UTC [click onto the screenshot for richer detail]

Working on a project which will focus on Doppler spread of HF channels (see at the bottom) and other impairements, I also bumped into some more prominent Doppler catches, namely on the VHF aero band. I took the AM carrier of nearby Hannover VOLMET on 127.4 MHz and observed doppler traces about plus/minus 200Hz the carrier frequency. Following the acitvity in the airspace via Flightradar24 in parallel, it is easy to match traces and aircrafts. In this case, I nailed cargo flight NH8406 from Frankfurt to Narita/Tokyo. It is important to remember what is shown in left part of the screenshot: it is the signal of Hannover VOLMET, reflected by this moving Boeing 777-F. Thus, the reflected frequency shows a Doppler frequency shift – depending on the relative speed in respect to transmitter and receiver. A positive Doppler frequency signals that the aircraft is approaching my location. When it turns to the lower frequencies, I see the aircraft passing.

Things get more complex wen it comes to the Doppler shift at HF propagation. You will also see planes, but effects from high winds in the upper atmosphere, coming and fading of ionospheric layers and the influences of the geomagnetic field are prevailing. Due to the much lower frequencies, the effects are just about a tenth compared to thie above example on VHF.

See below a result from my observations on HF as a preview.

Carrier of TRT Emirler, Turkey, in the 19 meter band. Just after sunrise, the carrier splits into two, and you also see double lines due to magnetoionic effects. The window shos about 3Hz in the vertical, and about 40 minutes in the horizontal scale.

CIS Time Signals on VLF

Locations, callsigns and starting times of the received VLF time signal stations, 25 kHz

On January 10, 2020, I did a round-up of VLF time stations from the Commonwealth of Independant States (CIS). They are controlled by the Russian Navy and start their main transmission on 25.0kHz. Then they change to a couple of four other VLF channels. See here for some detailed information in Russian. The diagram below shows a panorama of all received station (Khabarovsk in the Far East missing, as they skip transmission on the 10., 20. and 30. each month) on all frequencies versus time and signal level.

Five locations, six transmissions, five frequencies – this diagram puts it all together.

The diagram features a time resolution of 1s and has a resolution bandwidth of about 0.12 Hz. It is part of a 24h session, made with Winradio’s Excalibur Sigma SDR, active dipole MD300DX (2x5m) and Simon Brown’s software SDRC V3. This software delivers also the values for level over time, which were visualized and combined with QtiPlot software.

Only seemingly, Vileyka and Krasnodar are transmitting on two channels at the same time (from 07:06 UTC/11:06 UTC). This is not the case, but their transmitters show a bit wider signal in their first part of the transmission. Thus, the much weaker (ca. -30dB) “signal” at the same time, but 100Hz up, is some kind of sideband, but not the carrier!

You will see some variation of the carrier power, especially following sign on, but also during the transmission. This can bee seen with tenfold time resolution (i.e. 100ms) and magnifying the dB-scale, see diagram at the bottom as just one example. Fading can be largely excluded for several reasons, artificial characteristic of changes and VLF propagation during short periods among them.

Under the microscope: This rise of 1.5dB of the carrier is part of the workflow of switching on/tuning the transmitter. There are many such details, and they may differ from transmitter, location and performance. Such details might be used for “fingerprinting”.

P.S. The map at the top was made with free software Tableau Public. The locations are geo-referenced, and a satellite map as background will you lead directly to the antennas. Please try this here.

FAX from Shanghai: Pacific Pressures

This FAX broadcast was new to me and received on December 16, 2019 at 08:20 UTC on 16557,1 kHz. It was transmitted via Shanghai Coastal Radio, presumably directed into the Pacific, of which it shows the 48h surface pressure.

It was demodulated from a 25 MHz wide HF recording over 24 hours. This recording was made with Winradio’s G65DDCe Sigma SDR, connected to an active vertical MegaDipol MD300DX (2 x 5 m), and decoded with Wavecom’s W-Code. The recording was scheduled with software SDRC V3 by Simon Brown, and directed via USB3.1 to a 20TB hard disk, WD Duo Book. The resulting one file was 8TB, format WAV RF64.

It was also played back from this hard disk, also via USB3.1. Doing so, it is most remarkable that this setup worked smoothly without any glitches which would promptly have been seen at such a time-critical mode like this FAX., 120/576. So, this reception is also a proof that one can work smoothly with such ‘big data’ even on a hard disk – and not only on expensive SSDs. A FAX transmission is that sensitive that you even see a very weak echo (best seen of the big vertical black stripe at the right which echoes from around 115° East). This originates from a mixed short/long path reception. The strong short path’ flight time is 28.7ms, whereas the weak long path needed 104.7ms. As one FAX line covers 500ms, you can easily measure the delay of roughly 80ms, almost exactly matching the difference of long and short path.

The screenshot has been left un-retouched.

3 x CW: Kagoshima Fishery Radio, JFX

Parallel DXing: JFX on 6421,5 kHz, 8690 kHz and 12704,5 kHz

Morse Code or CW has become rare among professionals (in the West). But there is a busy net of small Japanese Fishery Stations literally pounding the brass. One of them is Kagoshima Radio, JFX. They are not daily heard in Europe, but a combination of receiver Winradio Sigma, active antenna MD300DX (2×2.5 m, vertical) and SDRC V3 software did the trick even under this grim summer propagation. See screenshot above, from 24 hours’ recording of 25 MHz HF. All channels clearly readable – as far as the expressive handwriting (see detailed screenshot at the bottom) of their CW allows for … Yeah: CQ CQ DE JFX JFX QRU QSX 6 / 8 /12 MHz K

First part of the CQ call of JFX in good ol’ hand-made CW … from 12704.5 kHz

Monitoring: Visualizing with free Tableau Public Software

Part of a multi-channel monitoring of the HFGCS net in ALE on July 14, 2019: the vertikal axis shows the channel, the horizontal axis the time of monitoring.

2019 is the year of groundbreaking Software-defined radios, covering the whole HF range of 30 MHz width and recording it for many hours, e.g. from midnight to midnight. In combination with proper software, this allows for a fresh view onto monitoring.

For the screenshot on the top, I had monitored nine HFGCS channels from 3137 kHz to 23327 kHz in parallel (the 18003 kHz didn’t work, sorry) with Winradio’s SIGMA SDR, running with Simon Brown’s free software SDRC V3 and nine instances of MultiPSK decoder.

After automatic monitoring, I harvested all time-stamped logs stripped them from information not needed, and imported them to free Tableau Public software to visualize activity according to station, time and channel. This gives an overview on the monitoring session, propagation, time sequences of hopping from channel to channel etc. – you might zoom into the screenshot for a clearer look.

Thanks to Tableaus also stunning geospatial features, completely other views of the same log are available. The screenshot below shows the number of logs on all channels of a monitoring session of 12 hours.

Geospatial information of the stations, combined with the number of log entries on all channels.

You may zoom into this OSM[ap], and you may also have a zoomed satellite view (or this or that) which directly hits the feeder point of your antenna … if you know the exact location and this is a part of your log entry – see screenshot below.

Zooming the map above onto JDG at satellite view, directly leads you to the location of the station – here Diega Garcia US Military base.

The most versatile Tableau software also allows to relaize many other ideas to visualize monitoring; some of them already above horizon, others still below. To conclude this entry, I did a visualization of all HF stations/channels of AFAD, the Turkish Disaster and Emergency Management Authority, heard by me over the last 18 months. Each (?) of the 81 Turkish provinces maintains an AFAD base, and all (most?) of them are communicating on HF. As Tableau has many detailed geographical already aboard, a visualization of channels/province being heard is easy.

Analyzing part of a logbook: All Turkish provinces heard with ALE signals of AFAD are colored – the deeper the color, the more channels were received in the last 18 months.

Dream Team: Winradio’s SIGMA and Simon’s Software (1)

All main six GMDSS channels on HF at once: Winradio’s SIGMA with Simon Brown’s software SDRC V3

Some days ago, I wrote about my very first experiences with Winradio’s groundbreaking SIGMA SDR receiver, covering e.g. the whole HF band with 32 MHz width and 16 bit resolution – plus much, much more. SIGMA comes with a fine software, and provides an API.dll for connection to 3rd-party software. Thankfully, Simon Brown, G4ELI, adapted his unique SDRC V3 software to this (and other) Winradio in nearly no time.

This combination has become a real dream team: the best hardware and the best software avalaible. The screenshot at the top shows just one example of others which will follow: I made a 24 hour recording of 0 to 25 MHz (7.85TB) and placed six demodulators on the main GMDSS channels on HF between 2 and 16 MHz. You see each channel in a separate window at the top of the screenshot, showing spectrum and spectrogram with time stamps of the recording. Below those six channels you see spectrum and spectrogram of the whole recorded bandwidth, namely 25 MHz. Eventually, below this spectrogram you see 60 x 24 boxes, one for every minute of the 24 hours recording. Just click into the time you want, and the recording instantaneoulsy to it.

Demodulated audio is guided via VAC1 … VAC6 to six different instances of the free YAND GMDSS decoder – see screenshot at the bottom.

There are great many other applications of this revolutionary combination to which I will come back later.

Parallel reception & decoding of six GMDSS channels at once.

ALE [MIL-STD-188-141A]: Which one is the best Decoder?

This is an update from my post two days ago. I have expanded the number of test signals and added some hints.

Does your decoder read this track? Buried in noise and plagued by multipath fading, the recordings below will separate the wheat from the whaff.

Often I am asked – and sometimes even asking myself! – “Which one is the best decoder for ALE?” This means: Which one delivers the best decoding under demanding conditions?

To test this, I made a recording of twelve stations “on the air” plus one weak signal, buried in Additive White Gaussian Noise, AWGN. All signals are correctly tuned, no one invers. All were read by at leastby one of my decoders “in a row”.

To test your decoders, you should download this WAV file of 131 seconds length and play it. It can be either directly opened by some decoder, or feed it via virtual audio cable (VAC) into a decoder. I used Audacity for this.

I am as interested in the results as you are – so please drop me a line to dk8ok [at] gmx.net. I like to encourage you to try all ALE decoders you have at hand – the more, the better.

Already the first results were surprising. This concerned both, the decoding ability of the decoders and the repeatability of the test. So far, the following decoders had participated: go2monitor, Krypto500, MARS-ALE, MultiPSK, Sorcerer, and W-Code. Steve, N2CKH, had written some valuable hints to optimize his MARS-ALE software for SIGINT purposes – please see his comment.


This WAV file contains the calls of thirteen ALE stations. Download and save this file (point to the icon, press right mouse button …). Then feed it to your decoders. Copy the results and send them to me. Have fun!
« Older Entries Recent Entries »