In my last blog, I wrote about my experiences with BCS-GMDSS multi-channel decoder. Chris, the software author, had added some smart features in the meantime. I would like to briefly introduce some of them in loose order.
Newly introduced is a window showing “Frequency and Time Statistics”. This somewhat sober, albeit highly informative table can be spiced up a bit yourself – see the following three screenshots (double-clicking onto them shows them in full resolution):
The heatmap shows clearly that 8MHz is the most productive channel. It shows also how propagation works – see fade-in and fade-out of those channels on 12MHz and 16MHz. From a DXer’s point of view, however, 2187.5kHz can be considered some of the most interesting channel. Another new window gives an overlook about all those Coastal stations received, and how often, on what channel, and when for the first/last time.
Furthermore, Chris introduced a (basic) map where you can see the locations of those Coastal stations you have received – if you don’t know exactly where to locate e.g., Taman Radio or Marzara del Vallo Radio … Even better, as the map is living: double-click to a location, and a window with your logs of this Coastal is popping up!
The log is organized as a database. This opens the chance for many applications in logging, searching and presenting your logs. Many of those option are already built-in, like searching all stations within a specific time frame or matching one or more specific fields, let it be MMSI, Ship Owner or country. One special format supports that used by highly recommended firstname.lastname@example.org:
The recent version of BCS-GMDSS also supports a search option for MMSI: just double-click the wanted MMSI to open a specific Google search. In nearly all cases I tried, the first result lead straight to much more information on a handful of websites, providing e.g., location, map with position and often a photo of the vessel:
Finally, Chris was kind enough to respond to the request of a single, elderly gentleman and provide for the export of all data in a form that separates all possible data fields by CSVs – analogous to the official ITU publications, among others. This offers many more and very specific possibilities for search and (statistical) evaluation. The nice elderly gentleman has already tried this (“Great!”) with Access:
After so much data then for writing reception reports with some nice results:
Chris Smolinski, W3HFU, did it again: after his multi-channel attack to ALE, he now offers this highly innovative concept also for GMDSS – Black Cat GMDSS. In addition to an extraordinary sensitive decoder, it also includes smart processing of the data – from looking up vessel’s complete data from ITU’s Ship Station List (internet connection needed) to saving all data to a fully-fledged database. Welcome aboard! Now let’s set sail!
3000+ Messages a Day – received on HF
The Global Maritime Distress and Safety System is a system of different maritime communications tools on frequencies ranging from as low as 424kHz [NAVTEX] over HF and VHF up to satellite channels in the GHz region. This blog entry focus on Black Cat GMDSS decoder, hence on HF. There, the six main channels range from 2MHz to 16MHz. Reception of both, Coastal Stations and vessels, is from around the world. In this case from Vestmannaeyjar Radio in Iceland to Cape Town Radio in South Africa, and from Valparaiso Playo Ancha Radio in Chile to Taupo Maritime Radio in New Zealand. You may hear vessels of each and every kind, from small ones for pleasure to the biggest oil tankers, and all over the world. Monitoring on all six main channels in parallel, often raises 3000+ messages a day!
Robust FSK mode
Transmission is done in 2-FSK with 170Hz shift and at speed of 100Bd. Waveform is ‘kind of SITOR-B, repeating each character twice with a 400ms spread to enhance proper decoding under adverse propagation (Rec. ITU-R M.493-11). To establish a call, each station has been assigned to an unique MMSI, or Maritime Mobile Security Identity number consisting of now nine digits, in future 10 digits. MMSIs starting with 00 denote a Coastal Station, e.g., 004123100 for Guangzhou Radio/China. There is a set of 127 symbols, with the first numbers 00 to 99 representing numbers, and each of the remaining number specific situations like “110” denoting “Man over board”. The software has to look up those source-coded messages in a codebook to print a readable message, giving some sense.
One message is about 6.4 seconds long. it starts with a short dot-pattern/phasing sequence for automatic tuning, followed by the content. In this live example, JRCC Australia (MMSI 003669991) is calling Merchant Oil tanker Signal Maya (MMSI 248410000) on 12577kHz at 15:59:43 UTC on November 21, 2021. There are transmitted 23 groups (“Symbols”) in GMDSS :
021 007 061 000 000 -> Address – MMSI of called station
108 -> Category
000 050 030 000 010 -> Self MMSI – MMSI of calling station
118 126 -> first and second [none in this case, “idling”] telecommand message
126 126 126 -> frequency message [none in this case, “idling”]
126 126 122 -> end of message
111 -> error-check character [ECC]
After a look-up in the codebook this turns into:
Format: Individual call
Address [to]: 210761000
Self MMSI [from]: 005030001
First telecommand: Test
… even smarter decoding!
Still not much enlightment. But BCS-GMDSS is at your service. It looks up all the cryptic numbers at different sources, even tapping official ITU webpage to enrich the vessel’s MMSI with its stunning mutltitude of information. Wrapping it up, decoding and looking-up in an internal codebook (Coastal Station) as well as in ITU sources (vessels), the above mentioned 23 symbols come out in full glory reading:
[2021-11-21 14:59:43] 12577 Symbols: 120 120 021 007 061 000 000 108 000 050 030 000 010 118 126 126 126 126 126 126 126 122 111 Self MMSI: 005030001 – Australia – JRCC AUSTRALIA 26 20′ 48″ S 120 33′ 52″ E 13669 km, 92 deg Address: 210761000 – Cyprus Ship: SALT LAKE CITY | Callsign: C4DS2 | MMSI: 210761000 | Cyprus (Republic of) (CYP) | Vessel ID: 9314129 | EPIRB: BE1 | 06/12/2017 Class: Merchant | Bulk carrier | | 89076 tons | 26 persons | INMARSAT C MINI M INMARSAT M VHF DSC | 24 hr service Owner: NOBEL NAVIGATION CO LTD POB 50132 LIMASSOL CYPRUS Misc: Former Name: THALASSINI NIKI | | EPIRB ID: 210761000 | | Telephone Bands: STUV | AAIC: GR14 | | CO | | Format: Individual call Category: Safety First telecommand: Test
As you have seen, I already mixed some theory with some practice – as you know me.
Now for some features of the software, plus some hints to make the most out of it.
Some basics, you must be tuned to
BCS-GMDSS offers up to 8 channels in parallel which by default are set to the main six GMDSS channels plus two with only rarely traffic observed, also on 2MHz. Those channels are fed by a SDR, ideally covering the whole range from 2MHz to 17MHz, alias-free. In this range you have to place the up to eight channels, RX1 … RX8, and have their output set to VAC1 … VAC8. The inputs of the decoder have to match those VAC numbers – see screenshot.
Take some care to think about mode, tuned frequency and audio frequencies, and bandwidth. Mode can be USB, CW-U or FSK, whatever your SDR’s software offers. It is, however, mandatory that the center frequency of the audio output must match the centre frequency of the input of the decoder! Otherwise there will be no decoding.
I am using free SDRC software by Simon Brown, G4ELI, easily providing all eight channels via VAC software. I am using CW-U and a bandwidth of 400Hz, giving some room for stations which might deviate by some 10Hz from the assigned channel – the decoder automatically compensates for this. With this setup (see screenshots below), the frequency readout shows the assigned channels, plus centre frequencies of decoder and receiver are matching (here 1700Hz, as ITU recommends). The bandwidth offers a good balance of SNR and tolerance for stations with a slight offset. Your mileage may vary in some aspects, e.g., you may prefer SSB-USB mode, or your software has a BFO if you use CW … You may also use the wrong sideband (LSB instead of USB) with your receiver – but than you just have to tick “Invert” in the decoder’s Setting menu as it then changes Mark and Space frequencies.
Order! How to cruise through this Ocean of Messages
BCS-GMDSS cleverly combines a most powerful decoder with some extras to calm the rogue waves of decoded information. First, you may reduce (or extend) the degree of information you fetch form the ITU page: Edit -> Settings -> MMSI Lookup. It is very interesting to see the maximum of data (“Most Details”), but with everyday’s monitoring just “Basic” or “Detailed” may run the show. This creenshot is showing the differences:
The second step is to distinguish the vessels from the coastal stations by color. I set the latter ones to show up in blue:
Next, BCS-GMDSS offers a Coastal Station’s database. It is a real database which, e.g., each column can be sorted. In the screenshot below, I had sorted them according to their total messages received. Then “Yusa Radio” has been double-clicked to inspect the timestamps of reception:
The “Loggings Database Search” is like a supertanker, containing all your logs which can be sorted by a double-click, plus being queried for each column, also combining different criteria. This is the most powerful database any GMDSS decoder has on board. See screenshot below for just one example:
Addendum: Where are they cruising?
The location of most Coastal stations is openly available, and their geographical coordinates are internally looked up by the software – even calculation of the distances to your location (Edit -> Settings -> Latitude:/Longitude:) is done automatically. But where are the vessels cruising? They only rarely transmit their location in GMDSS on HF. But if they have an AIS, or Automatic Identification System, you have a fair chance to get the actual location. This system comes in two tastes: AIS and LRTI, or Long Range Identification and Tracking. AIS is using VHF. Propagation restricts the range to some ten kilometers. LRTI is using satellite (INMARSAT). There are some webpages where you get at least AIS for free – just to mention VesselFinder, VesselTracker and MarineTraffic. Their business model is to offer subscriptions for one year at a price of about 1’200 US-$ for LRTI (satellite) data, aimed mainly to the professionals. But most of those companies offer (limited) access to their AIS data for free. The two screenshots below show the difference.
The example above, bulk carrier Salt Lake City, is only availabe on LRIT. So free data are about one week old. Nevertheless, you get at least a clue where the ship had been. And if time plays no role, just look it up exactly this week later …
If you have received the following message, you are lucky:
[2021-11-22 17:02:38] 2187.5 Self MMSI: 229375000 – Malta Ship: CMA CGM FORT DESAIX | 9HA5478 | 229375000 | MLT | MLT | 9400174 | 229375000 | 04/08/2021 Address: 002275300 – France – MRCC CORSEN 48 40′ 60″ N 2 19′ 0″ W 947 km, 252 deg Format: Individual call Category: Safety First telecommand: Test
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
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.
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.
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 :
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.
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):
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.
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.
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”.
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 UDXFmust 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?
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.
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 decoderhas 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!
In the last two blog entries, I took a look at the DAB capabilities of free softwareQIRXby 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.
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.
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.
In this second part about DAB/QIRX, I will deal with anaylzing some results of QIRX’ log.
QIRX software provides several tools and data for DAB reception which it stores in a file called TII logger. TII stands for Transmitter Identification Information. Most important of these data are:
Time of reception
Ensemble ID – identification of the DAB-VHF channel received
Signal-to-Noise ratio, or SNR, of the whole 1.536MHz wide VHF channel. Maximum values here are about 34dB from locals. Audio can be expected from about 9dB, reliable decoding of metadata from around 7dB
Main ID and Sub ID of the physical transmitter’s location
Strength – the average of the amplitudes (magnitudes) of the TII carriers of each transmitter at that moment. The strongest carrier within an ensemble gets value “1”, the other carriers a number from 0 to 1 in respect to their relative magnitude, compared to the strongest carrier. Scale is linear, not logarithmic.
For mobile use, also GPS data in 3D are stored, extracted from an NMEA stream, provided by e.g., an external GPS mouse.
There are two principal methods of collecting data:
Scanning the whole DAB-band with all ensembles or scanning a couple of ensembles, as set in the Options’ tab, see Figure 2. This is done to get an overlook over all or many ensembles.
Scanning of just one ensemble, mostly to scrutinize propagation from the physical transmitter’s locations – Figure 3.
For scanning, the position of the Threshold slider is important. This can be considered as “kind of a squelch”. It sets the threshold where an ensemble/service is logged. You can control this feature via the window “TII Carriers”. A high threshold results in reliably logging of the strongest station(s). A low threshold will save also weak(er) signals but may be prone to false positive logs which have to been checked/erased manually.
Scan the whole Band
A scan of the whole band with a high threshold (here 0.54) resulted in the ensembles of Figure 1. Reception has been done from a fixed location with a largely vertical-polarized discone antenna at a height of about 50m near Hannover, in the lowlands of Northern Germany. The radio horizon is about 30km, following the equation given by Armbrüster/Grünberger: Elektromagnetische Wellen im Hochfrequenzbereich, München/Heidelberg [Siemens], 1978, p.48. Their factor of 4.1 is a bit higher than other values also found, ranging around 3.6. Receiver is an SDRPlay RSP2.
Figure 4 shows the SNRs of three ensembles, transmitted by the local Telemax tower at 15.8km with antennas at a maximum height of about 340m above sea level, or ASL. This results in a radio horizon of 75km.
Both 10kW signals of ensemble 5C and 5D show a more or less similar SNRs, but at different medians of 27.0dB [ensemble 5C], 31.3dB [5D] and 27.1dB [7A], respectively. With (nearly) the same power and the same horizontal polarization – matching my vertical Discone antenna -, with 5D leading the pack by a whopping 4dB, or factor 2.5, presumably using another antenna pattern at the transmitters’ site. What puzzles me more is that the variance of ensemble 7A with 1.56 is more then double as high as with the other signal (0.62 and 0.70).
The next diagram (Figure 5) shows the SNR from ensemble 11C, transmitted from Brocken mountain. With a height of 1141m, it is also virtually line-of-sight. There we see a much lower SNR, due to the fivefold distance, plus the transmitter’s power of being only a fourth that of Hannover Telemax. With 10.2dB, the median SNR is barely above the reliable threshold of around 10dB to provide audio at all. Showing a variance of 0.9, it is prone to sink under this vital level – returning no audio then. The three bigger dips largely coincide with local sunrise, noon and sunset. Further studies are needed to get a clue on that.
The last diagram of this series, Figure 6, shows a splash of DX: From my location, the transmitter “Eggegebirge/Lichtenauer Kreuz” only provides marginal reception – with a median SNR of 8.6dB and a variance of 0.3 only rarely jumping over the threshold of 10dB. Sometimes, even metadata are lost, resulting in a somewhat thinned-out appearance of the diagram. If you compare the diagrams from Brocken above and from Eggegebirge below, you may see some similarity in SNR over time with also pronounced dips around sunrise, noon and sunset.
Scanning one Ensemble
In a second step, I scanned just one ensemble for 24 hours, namely 9B “NDR NDS LG” on 204.640MHz with a choice of six stations – some easy, but e.g. Stade a bit challenging. Figure 7 shows the locations and some results, from a whopping number of 276’092 logs. For this, “Threshold” had been set to the lowest possible value, combining highest sensitivity with a maximum of false hits (here: nearly 30%) to be sorted out later – which of course had been already done in this example.
To get the performance of each transmitter’s locations within one ensemble, you cannot use the SNR values, as they refer to the strongest station within the ensemble: Visselhövede in this case. Hence, I had to use column “Strength” of the TII log, running from “1” for the biggest signal in the ensemble to “0” on a linear scale. Here, the smart guys of UKW/TV Arbeitskreis e.V. have invested much work in identifying the TIIs. If you match the Main/Sub Id of your TII log with their free publications, you can assign the IDs to their locations.
This has been done for Figure 8, sorted by distances of the transmitters. The Bispingen/Egestorf (74.2km) transmitter is running only 2kW, hence its strength is weaker and more patchy than e.g. 10kW transmitter Dannenberg/Zernien, despite its distance of 91.2km. Most prominent in the diagram of this transmitter, you see two peaks between 18:00 and 00:00 UTC. They occur – each time-shifted and weaker – also in the diagrams from Egestorf, Lüneburg and Rosengarten plus, much weaker, Visselhövede. Source of these peaks almost surely is a “moving reflector”, being more an airplane than an atmospheric phenomenon, enhancing reception currently. Websites like Flightradar24 with their playback function will help to find some suspects.
Finally, an alternative look at strengths. In Figure 9, I combined the strengths of just three transmitters, now having set a logarithmic vertical scale, rather than a linear scale to emphasize the weaker signals.
Some Notes on Propagation
Last but no least, I like to add some notes on propagation. In the DAB frequency range, of around 170 to 255 MHz, propagation largely follows “line of sight”, primarily controlled by the height of transmitters’s and receiver’s antenna – plus power of the transmitter and sensitivity of the receiver. Antenna polarization also plays a role – the polarization of the receiver’s antenna must match that of the transmitter’s antenna to avoid losses by a mismatch. Bear in mind that many transmitter’s antennas may have a non-omni-directional diagram.
This general propagation can be enhanced or degraded by atmospheric phenomenons, high or low pressure/temperature; by rain and fog, by aircraft scatter and other factors.
The SNR of an ensemble is mostly as better as the signal is stronger. There is an exception: if the same ensemble is received by two transmitters at a relative distance of more than about 75km, the “Guard Interval” is too short to sort them out. Result then is a reduced SNR at a high signal level. However, I never faced this situation.
Clem dropped my attention also to another most valuable tool, provided by fmscan.org. They maintain detailed databases also on DAB transmitters, their antennas, powers, ensembles etc., and a web service which will draw circles of coverage onto a map. This is a cool and free tool, you must not miss – see Figure 10.
The above mentioned tool does not take into account topographic data which may be important to calculate the coverage in mountainous regions. Here Nautel, a Canadian producer of transmitters, provides a free webtool after registration, see Figure 11.
Digital Audio Broadcast, or: DAB, now is common with most household and car radios – after a more than bumpy start. Pressed into market with voluptuous grants from the tax payer and unabashed blackmailing of ceasing all FM broadcast and, hence, making all analogue FM radios obsolete without any financial compensation.
After fierce protests, there is some coexistence between both ways to the listener – mostly thanks of the pressure of commercial broadcasters which often belong to media giants.
Software defined radios, or: SDRs, make an excellent start to discover both worlds. Here, I will focus on DAB with free software QIRXby Clem Schmidt, DF9GI, from Frankfurt. It directly works with RTL-SDR, Airspyand RSP2 SDRs. I tried this very smart software from my location near Hannover/North Germany, mostly with my RSP2.
This blog has two parts: in this first part (1/2), I want to get some ground under my feet – regarding DAB as well as QIRX. The second part (2/2) deals with some results of QIRX’ logs.
QIRX excels in a number of analytic tools, and an OSM-based map showing your location as well as the locations of the transmitters, all metadata transmitted plus other features like connection to GPS receiver’s NMEA output for mobile use. It can be also used very basically: just to listen.
DAB – an efficient concept
In the first step, you have to find out which transmitters you receive at your location. Each transmitter beams a so-called “ensemble” (also dubbed “bouquet”) into the country, or a bundle of programms. Many of these programms or services can be packed into just one physical DAB-VHF-channel (“block”, e.g. 5D) of 1,536MHz width, via a robust and spectrum-efficient mode, called OFDM. This is a special combination of phase-modulated carriers, commerically pioneered for DAB by Munich-based Institut für Rundfunktechnik from 1981. Each ensemble carries an Ensemble ID (EId), like 11F7 for “Antenne DE”. Thanks to the “Extended Country Code”, this EId is worldwide unique. In turn, each station/programme/service within an ensemble carries an unique Service ID (SId), like 121A for “Absolut OLDIE”. Some identical ensembles may be aired from different locations/ transmitters within a service region. In this case, they work together as a presumably GPS-synchronized Single Frequency Network – to which we’ll come later.
QIRX – the easy start
QIRX offers a scanner, catching all these ensembles from all the transmitters within the reach of your antenna:
At my location, QIRX scanner offers nine to ten such ensembles. For this example, I choosed the ensemble “Mitteldeutscher Rundfunk – Sachsen-Anhalt” (MDR-S-Anhalt), and clicked on the list of eleven services to “MDR Klassik” which shows up with some data on service quality plus multimedia:
It offers perfect reception, despite of delivering a signal-to-noise ration of just 10.9dB from a transmitter at a distance of 80+ kilometers.
Scanning is done in the background, and it may loop through (click: “Scan forever”) for hours or even days. It continually writes the results in the TII Logfile for future inspection – a great tool which will reveal even short openings over a specific time – scatter by tropo, aircraft or meteors among these.
How is the signal?
As an SDR aficionado, you will be pleased to see the spectrum and the spectrogram (“waterfall”) of the signal, the receiver is tuned to. The first screenshot below shows a near-perfect case from my local transmitter in 15.8km distance, delivering an SNR of up to more then 33dB, whereas the second screenshot of the ensemble “11D/Radio fuer NRW” at a distance of 115 kilometers shows a bumpy road ahead with SNRs well under 10dB. The “radio horizon” of this specific transmitter’s site already ends at about 85km, thus the margin is not too high.
One of the most exciting features of QIRX are its analytic tools. To make full use of them, a basic understandig of the concept of DAB is inevitable. ETSI, the European Telecommunications Standards Institute, is the umbrella organisation for maintaining also this concept. They provide a widespread number of different papers with standards and technical reports of which I found EN 300 401 (focusing on receivers) and TR 101 496-3 (focusing on the operation of a DAB network) especially helpful. Clemens, the software author of QIRX, has published some excellent information on these topics on his website, where I especially recommend the two parts dealing with TII, or Transmiter Identification Information. He had put a lot of work into it to present all information to get a clue what happens behind this rather complex and smart DAB system.
The window for the analytic tools comprises up to five sub-windows, with the Audio Spectrum skipped here:
Let’s got through them step by step.
Constellation shows the four phases of the robust DQPSK modulation in a linear manner, representing each of the sub-carrier of the OFDM signal separately. By this, you may see which of the carriers actually is degraded by multipath propagation, caused e.g. by reflection from aircraft. Above, you see the constellation of a near-perfect reception with an SNR of 33dB. Below, you see two examples at a much lower SNR. At the third example, the robust meta information from the Fast Information Channel (FIC) already is decoded, with however, the signal strength (more exactly, the SNR) just under the threshold to provide audio decoding.
Channel Impulse Repsonse (CIR) shows the time of flight from all transmitters to the receiver – referenced to the strongest signal, showing up as “0”. You may switch the scale from samples to time in microseconds to (relative) kilometers. These data also show up in the TII window at left-hand, and are used to populate the map. It is the easy-to-read surface of heavy work under the hood to which also some other radio enthusiasts had contributed. Below you see first the CIR display, where you see signals from three transmitters. The X-scale is in microseconds, time-of-flight, referenced to the strongest signal. On the left you see a list of all three received transmitters, ensemble 5D, with their real distance (km abs.) from the receiver, their distance relative to the strongest signal (km rel.), and their direction as seen from the receiver (AZM) – to turn your antenna into the right direction …
TII Carriers is a unique and exciting tool of QIRX software to look a bit deeper into the structure of the Single Frequency Network to which DAB is organized. Let’s take the map above with three transmitter on the same DAB-Block, or: VHF channel. TII or Transmitter Identification Information tells us just what transmitter(s) we do receive. Clem, the author of QIRX, put a lot of work not only to get this tool running, but also in describing the background and how to use this feature – you must not miss this (there are two parts …)! I can give only a weak echo of his very well placed explanations there.
Basically, it decodes the “Null symbol” of the TII which is transmitted with low power within what seems a “pause” of only 1.3ms of duration between each frame of DAB stream, being itself 96ms long.
The most easy situation is to receive and decode only one transmitter. The following screenshot shows this situation with DAB-VHF-Block 9B, transmitter Visselhövede. In the TII window you see 4 x 4 carriers, separated within four compartments by a dashed vertical yellow line. Each of the four groups of carriers contain the same information, but each taken from a different part of the spectrum to enhance overall sensitivity for weak(er) stations. The position of the TII subcarrier defines the sub-ID, and, hence, the individual transmitter. In this case, the sub-ID is “1”, denoting Visselhövede as transmitter location. The mapping of DAB-VHF-Block, Main/Sub-ID and transmitter site has been mainly done by UKW/TV-Arbeitskreis e.V., a smart group of enthusiasts dealing with reception above 30 MHz.
If you play around with the “Threshold” detecting TII carriers this may reveal also other transmitter locations, transported via the same DAB-VHF-Block. So, I lowered the threshold to 0.010 (x10). As a result, much more TII carriers become visible in the four compartments. They belong to other sites, hence, bearing other sub-IDs. To decode them, they must show up almost similar within all four compartments of the carrier spectrum window (right). Only then they are duly listed under the TII tab on the left side, and show also up in the map at the top.
You see 4 x five carriers, jumping over the gray threshold. On the left, they all are listed with their metadata including their sub-IDs of:
1 Visselhövede – 65,8km/10kW,
2 Dannenberg/Zernien – 91.2km/10kW,
5 Bispingen – 74.2km/2kW,
6 Lüneburg/Neu-Wendhausen – 96.1km/4kW and
4 Rosengarten/Langenrehm – 106,8km/10kW
The additional four sites duly show up in the map, in red with the fifth, Visselhövede, marked green as carrying the best signal.
I/Q Data: The diagram always shows the time sequence of IQ data, in units of samples. Here, one sample corresponds to the system clock time of 1/2048000 sec, i.e. about 1/2 microsecond. The Y-axis can be switched between “Magnitude” (roughly the absolute amplitudes of I/Q), or just the amplitudes of the I-data (“I-Data” ticked). The first is the tool of choice to reveal the above mentioned “Null symbol” of 1.3 milliseconds, see screenshot below. For a detailed explanation, which is out of scope of this blog entry, please refer to QIRX’ website.
One additonal feature of DAB, much worthwhile to be mentioned, is the so-called “Guard Interval“. It guarantees that all transmitters involved in an Singe-Frequency Network, with their individual stations distinguishable only by their TII codes, can all transmit on exactly the same frequency – whereby the relative distances can be up to approx. 75km apart without interfering with each other. This has the consequence that e.g. the Bundesmux (5C – DR Deutschland) needs only one frequency nation-wide, which is e.g. selected once in the car and then works in the whole republic, not requiring any re-tuning by the driver. By the way, all locations of a block stored in the database can be displayed in QIRX with one mouse click.
Caveat: “Threshold” is as sensitive, as it is sensible. Too low a threshold may result in errors, too high a threshold may miss some transmitters. It is a good idea to start at a threshold allowing only one or two transmitters coming through, and then reduce this threshold by carefully checking the results for probability (etc. by their distance).
At some locations, there may occure a collision of the same sub-ID from different transmitters. This can be de-fuddled by QIRX’s function “Show Collisions for Sub ID”, but this is beyond this mere introduction. I have also to skip many more interesting applications of this software, e.g. using it for multipath detection by carefully observing the spectrum and measuring its deviations from a near-perfect brick-like shape – so that you can even calculate the delay caused by this effect.
We all have to be indebted to Clemens not only for his smart achievement in writing QIRX software, but also for his explanations and examples on his website! He also helped in explaining some details for this text.
P.S.: Don’t miss the second part of this blog, showing some examples of analyzing QIRX’ logged data!
P.P.S: The best: the QIRX story isn’t over with just DAB. It features also a ADS-B decoder for those flight messages on 1.090MHz, drawing them on a map, and filing them. I will come back to this also stunning feature soon – stay tuned!
What you see in the picture at the top, is a mostly hidden gem of HF propagation. I took the carrier of Sofia-Kostinbrod transmitter form Bulgaria (250kW) on 9400kHz and observed it for three hours. In the upper window you see the frequency wihtin a window of 2Hz height only. You see two strong carriers: one nearly in parallel to the x-axis, the other snaking some fraction of one Hertz below it.
With one transmitter only on this frequency: How does this happen?
It’s multipath propagation. The signal takes one way via a groundwave-like way, the upper trace. It reveals a very slight drift downwards. As I use a GNSS-controlled receiver, the FDM-S3 from Elad, this miniscule drift should be happen within the transmitter, not the receiver. The snaking trace stems from a second way, most likely via the F2 layer of the ionosphere. As the ionosphere is prone to winds and an ever dynamic change of its ionization, it is moving. And with all moving objects, also this causes a Doppler effect to waves. This is exactly what we see – the angular speed of the ionosphere, relative to the “groundwave-like” signal. You may also see at least two weaker traces, caused by two further ways, hence showing other Doppler shift.
In the diagram at the bottom, you see the combined level of all traces. Because they reach the reeiver at different time and, hence, different phases, their addition leads to an ever changing signal level, called: fading.
I hope to continue this work with some other examples in the future, also taking fade-in and fade-out into account.
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.
We all know that propagation largely follows solar activity – on a diurnal scale, as well as along the seasons and, above all, the solar cycle – see diagram at the top of the page. We just had entered solar cylce #25, and again some unchartered waters, filled with high hopes as well as some shallows. This is a good opportunity to have a look into the rear view mirror, as in general terms we can see part of the future in the past.
To do so, I did some explorative data analysis, available for free from the following sources:
The following diagram shows the correlation of the daily sunspot number with the maximum, the mean, and the minimum MUF as measured that specific day. Therefrom, you see a decent correlation between solar activity and the MUFmean, whereas the impact of solar activity onto the MUFmax splits up at sunspot numbers above ca. 125. Values above in some cases do enhance the MUFmax, and in some cases just to the opposite. The good news, however, is that even at low solar activity, there may be experienced a MUFmax well above 30MHz, the threshold from HF to VHF.
One of the reasons that “more isn’t more in each case” lays geomagnetic activity, also triggered by the sun. From the data trove, I took seven days of November 2012: A stream of days with good propagation is interrupted by one day where the MUFmax in knocked down from more than 30MHz to just under 15MHz. The reason is a coronal mass ejection (CME), resulting in a magnetic storm, disturbing the earth’s magnetic field and, hence, ionospheric propagation. Already on the next day, propagation is recovering. Please have also a look at the “silence before the storm”, namely November 13, 2012. There you see a slight enhancement of the MUFmax of about ten percent. The geomagnetic storm is lagging behind one to three days the solar activity, as calculated from the sunspots. So, you should use this information surfin’ HF just after a massive enhancement of solar activity – before propagation recedes for a day or so. By the way, a geomagnetic storm doesn’t hit the earth in each case. This has to to with the distorted magnetic field which is no plane but resembling the tutu of a ballerina (not my association …).
Tacitely, I had used the term “MUF” in the sense what is exactly dubbed “MUF(3000)F2”, or: “MUF of the F2 layer when communicating between two stations at a distance of 3000 kilometers”. Ionosondes mostly measure the vertical MUF with transmitter and receiver at the same location, which has to be multiplied by a specifc factor. This factor of about 1,5 to 4 largely depends on the distance of the two stations, and the height of the layer. The following illustration shows propagation between my location and Funchal/Madeira, just 3000 kilometers away in the Atlantic Ocean. At a given height of the refracting layer, one hop gets longer with lowering the elevation of the antenna beam. The lower this angle, the larger the hop. It is a difficult and often expensive task to get this angle under 10° or so, especially at lower bands.
The illustration below shows the MUFs of ten consecutive days for bridging different distances from 0 (critical frequency, measured directly at the ionosonde) to 4000km. The last distance reckons with a layer height of 330km, being quite optimistic in the years of low solar activity but will be reached easily in other times. Nowadays, the standard is to use MUF(3000), wheras you often find MUF(4000) in legacy literature.
In the last paragraph, I mentioned the height of the refracting layer, and this changes also with solar activity. How, is illustrated by the figure below. There you can see the heights of the four ionospheric layers F2 (highest), F1, E and Es, or Sporadic-E. At the bottom, you find the smoothed sunspot number. You can see that this mostly influences the F2 layer – raising it at high solar activity, and, hence, allowing for larger 1-hop-distances. The height of all other layers follow a much more regular yearly pattern, and are not that much dependant on solar activity.
This, in turn, leads to the fact that the critical MUFs of each layer, by and large, is matching solar activity. F2 and F layer are mostly influenced by solar activity, as all layers are by the season. See illustration below.
Just a look on how the MUF changes from day to day under more or less stable solar conditions. With the overall pattern remaining nearly the same, the MUFmax may change considerably, ranging from 20 MHz to well above 30MHz. Nevertheless, at each day you will see a sharp rise before local sunrise (fast iononization) and a flat slope (slower re-combination) directly from around sunset.
The following figure shows that there is a high probability to expect today’s propagation also tomorrow – to about 75 percent. There, I used each day of the full twelve years’ period to cover the whole solar cycle.
Did you ever asked yourself, why important contests and DXpeditions are taking place in spring and autumn, preferably in years of high solar activity? The two following figures will give an answer: the MUF peaks just in these seasons. The peaks are prominent in a year of high solar activity, and not that pronounced in a year of less solar activity.
Last, but not least, we now will leave the MUF, heading for power, or, in this case, field strength. The figure below shows hourly measured fieldstrengths on six HF channels from 22.5MHz (top) to 4.3MHz (bottom), normalized to 1kW EIRP from June 1, 1980 to December, 1993, after Deutsche Bundespost had cancelled this project. I added daily smoothed sunspot numbers to the top and the bottom figure. 22.5 MHz has even not been used at all during a time of low solar activity, whereas they stopped using 4.3 MHz from the beginning of a new solar cycle. You can easily spot that some solar activitiy greatly enhances propagation on the channels up from 6.4MHz. In this case, the daily time where you can use the higher channels up from 13.0MHz , also increases. In years of lower solar activity, the time of propagation on the lower channels, down from 8.6MHz, is increased. But this effect is by far not outweighed by the effect on higher frequencies. For these data, we are indebted mainly to Dr. Thomas Damboldt, DJ5DT (1941-2015).
To make use of the future you have to know the past. This is easy with cyclic, physical processes. So this look into history is also a look forward into same aspects of solar cycle #25. It will bring better propagation on higher bands, where we may use smaller antennas, face less atmospheric noise and have larger frequency allocations. I am sure that F2 propagation will even take miniscule signals (QRPP) around the world, allowing for daily contacts from Europe to Australia even on 6m – as I had experienced at the peak of cylce #23. Be prepared!
P.S. All calculations/diagrams had been made with Matlab. You may also try it with free Python, matplotbib and Seabornor other software, you have at hand. With millions of data fields needed, spreadsheet software must be avoided.