Category Archives: DX

Google Translate as a DX Tool

by Don Moore

More of Don’s traveling DX stories can be found in his book Tales of a Vagabond DXer [SWLing Post affiliate link]. If you’ve already read his book and enjoyed it, do Don a favor and leave a review on Amazon.

I still remember an email I received from a DX friend in 1996. I had occasionally helped him translate things from Spanish, and he had just gotten a message from a South American DXer. But this time was different. My friend had already run the message through a new online translation website. He sent me both the original Spanish and the English translation. The translation got the meaning across even if the wording was awkward and unnatural. There was just one thing that puzzled my friend. Why, at the very bottom, did the sender finish with the short phrase “I graze?”

I immediately knew what had happened. The South American DXer was named Francisco but went by the nickname Paco. The Spanish verb for “to graze” is “pacer”. If you know even basic Spanish you know what happened, too. The first-person present form of pacer is paco. Without any sense of context, the translation software had seen the name as a verb and translated accordingly.

Translation software has developed astronomically in the last three decades. Not only has the quality of the translations gotten better, but so has the number of languages that can be translated on websites or in apps. Launched in 2006, Google Translate is the best-known and translates the most languages. But there are many others. Some offer far fewer languages but concentrate on offering better quality translations. Others offer languages that Google doesn’t have. You’ll need to use Bing Translate for Upper Sorbian.

I don’t remember when I first used a translation website or which ones I may have used. Google Translate has been my go-to site and app for years. It’s an easy way to look up Spanish words I don’t know. But my biggest use of Google Translate has nothing to do with translation. When writing messages in Spanish, I often use it even though I know exactly what I want to say. Instead of writing in Spanish, I compose my message in English and then give it to Google. The translation puts in all the accent marks and tildes that are awkward to type on my English-language keyboard. And the fact that 90% of the time the Google translation exactly matches what I would have written makes me feel good about my Spanish.

Before leaving on my trip to Southeast Asia last November, I downloaded Indonesian, Lao, Malay, Tagalog, Thai, and Vietnamese to my phone. In my travels, I’ve found it very useful for understanding text on signs, product labels, and museum displays. I had translated stuff from Albanian, Portuguese, French, Croatian, and a few other languages that way, and I knew I would find plenty of use for the app in Southeast Asia. Google Translate can also understand spoken language. You may have seen videos of people who don’t speak one another’s language having conversations that way with the app translating everything. I had never done that but figured I might give it a try.

Trying It Out On DX

My DX goal for the trip was to make lots of SDR spectrum recordings along the way and then later use the spectrum analyzer tool to DX them. (I’ll be writing about the places I DXed from in an upcoming series of articles.) After five weeks of travel, I arrived in Chiang Mai, Thailand, for a one-month stay, and I started DXing recordings I had made in the Philippines, Vietnam, and Laos. The utility bands were filled with voice broadcasts in lots of languages that I couldn’t even recognize. That’s when I got the idea – why not use Google Translate to see what these stations were saying and maybe identify some of them?

Did it work? Well… sort of.

With any block of written text in an unknown language (even in a different writing system), if you plug it into Google Translate and it’s in their system, the app will quickly identify which language is being used and translate the text. But the documentation at that time pointed out that identifying which language is being used in an audio stream took too much processing power to be practical. Instead, the user had to specify which language was being translated. In most cases, that wouldn’t be a problem. If you’re in Japan and trying to understand a waiter, he’s probably speaking Japanese. But I had no idea what language I was listening to on any of these broadcasts.

My solution was simple. Pick a strong signal and select one of the regional languages to translate from. If it didn’t start translating after about sixty seconds, then I’d switch to a different language. In a few minutes’ time, I could try all the major languages spoken in the region.

The first thing I tried doing this with was an unusual program-like broadcast I had found in the 8 MHz marine band. I set Google Translate to Thai to start, and a few moments later it started translating to English. That turned out to be the Duyên Hi broadcast from Vietnam that I reported in January. It seemed odd to me that they were broadcasting in Thai, but that was the first language I tried, and the app translated everything easily. But after publication of my article, a DXer of Vietnamese ancestry pointed out in the comments that the language being used was Vietnamese, not Thai. That made more sense and, indeed, when I set the app to Vietnamese, the app translated everything equally well. And it continued to do so when set to Thai.

Thai and Vietnamese are as different from one another as are Spanish and Russian. I even reproduced the issue with other broadcasts and other languages. If the app understood the audio, it would translate even if the selected language was different. And it wouldn’t do anything to indicate what the correct language was. So what was happening? I think I now know. In preparing this article, I found out that in December 2025, Google introduced automatic language detection for audio streams. My app hadn’t been updated yet in January, so it didn’t have the feature. However, the translation of the audio streams takes place on Google’s servers. So I think Google was correctly identifying and translating at their end, but the app wasn’t capable of correcting the displayed language name.

The Big News

The big news is that Google Translate can now automatically detect and identify over seventy different languages. And it works very well. I tested it using four different radio web streams, and within five seconds it correctly identified and began translating from Chinese, Hindi, Bulgarian, and Zulu. These were crystal-clear Internet streams, not DX signals. Still, I think we can all see the potential for this in our hobby.

The How-To

Let’s dive into how to use the app. If you don’t already have Google Translate on your phone, you can download it from the App Store. You may see some minor differences in the layout. These images are from my new Samsung S-26+, and it is slightly different from my old Samsung A53, even though the app version numbers are the same.

Upon opening, the app looks like this. The selected languages on either side are changed by just tapping on the button. I tap on Portuguese to get the selection screen.

There is now a Detect Language choice that wasn’t there before. Below that, it lists the languages I’ve downloaded and then all available languages. Downloading languages allows you to translate written text even if you are offline. Translating audio requires an active Internet connection. Here I can select the language being spoken if I know what it is. I don’t, so I select Detect Language.

Now back at the first page, I tap Live Translate at the bottom.

Now I select the mode. I select the text only option so that I can easily scroll back and read what was said. Conversation mode is only enabled when both languages are known. Now I tap on Start.

The audio I’m playing is from a YouTube video. Within a few seconds, the app identifies the language as Telugu, spoken in India, and begins translating.

Back to DXing

If you’ve been seriously DXing for a few decades, your ears are well trained at picking out station IDs from very noisy signals or signals mixed in with several interfering stations. Google Translate is not a DXer. Translation works best with clear, noise-free audio. As noise and interference creep up, success will go down. Sure, the app is designed to work if you’re trying to talk to a waiter in a crowded restaurant. But that’s a different noise environment. The AI hasn’t been trained on DX signals. However, it does very well on clear signals, such as this marine weather report from Nha Trang Radio in Vietnam.

Vietnam operates a large network of marine stations, and I made extensive use of Google Translate to log all the stations and even to find unlisted frequencies and broadcasts. The network will be the subject of my next article. I found that over time the Vietnamese translation actually got better on signals with slight and even moderate noise. The AI is supposed to learn from experience, so maybe I was training it to DX in Vietnamese!

In the video, you may have noted how the app will first create a tentative translation in gray text and then correct that with black text. Language translation is not a simple matter of exchanging one word for another in order. Grammar rules and word order vary, especially so between unrelated languages such as Vietnamese and English. Slang and idiomatic expressions can cloud meaning. And then there’s context. If I say, “John’s at the bank now,” you would assume he’s doing a financial transaction … unless you happen to know he was going fishing this afternoon. Having studied the complexities of linguistics, I find it amazing how well automated translation works.

If your first language is something other than English, you should know that English is always at the center of Google Translate, with just a few very specific exceptions. When translating Vietnamese to Arabic, Google will first translate the Vietnamese to English and then translate the English to Arabic. That extra translation step increases the chance for ambiguity to creep into the result. So if something doesn’t seem right, you may want to switch to translating to English and then translate that to your own language yourself.

Using Google Translate on radio broadcasts couldn’t be simpler. Getting good results, as we will see, is another matter. To get started, I recommend picking strong, clear signals. I get better results with an external speaker. Laptop speakers are rarely the best, and the app will pick up extra noise if the fan is running. I get good results using this pocket Bluetooth speaker with my phone a short distance away and angled up so that the bottom microphone is pointing towards the speaker.

Translation never starts immediately. On a perfectly clear audio stream, it may start in a few seconds. But even a little noise can delay that from several seconds to a minute. Then the first few sentences may not get translated. That’s a problem because many broadcasts, especially from utility stations, begin with the identification announcement, and you may miss it. So, for DXing, Google Translate is best used with recordings rather than live broadcasts. I do all my DXing from SDR spectrum recordings. Once the translation starts working, I quickly reset the playback to the beginning of the audio. Even then, it may take several tries to get the translation to catch right from the start. And if all I have is a short phrase, it likely won’t work at all. The AI seems to need at least a couple of sentences.

After I thought I was finished with this article, I decided to go back and do some more experimenting by placing my old A53 and the new S-26+ side-by-side. Unless I played perfectly clear audio, the two rarely produced identical translations. And it wasn’t just differences in wording. When playing slightly noisy signals, sometimes one phone would work but not the other. Or one would get a few sentences and then hang, but maybe the other would pick up and start translating. Together, they gave me more information than either of them did alone. So, the most productive way to use this on DX signals is to use two (or more?) phones to do the translation and to play a recording back several times to piece together the message.

For example, I had a 90-second broadcast in Tagalog on 7828.5 kHz that I knew was the Philippine Coast Guard, apparently from a place named Cape San Augustin. I pulled that back out, and after playing the recording several times on both phones, I figured out that it was the Philippine Coast Guard vessel BRP Cape San Augustin in the harbor in Masinloc on Luzon Island. Besides identifying the ship and location, the operator gave the call sign MRRV-4408. However, he preceded it with the English phrase “call sign,” and that was throwing off the translator, as it was expecting Tagalog. As a side note, the broadcast was a storm warning and, per the translation, he was telling the fishermen to “go hide.” A better translation would be to take shelter.

A few more observations. Using this for a while – like an hour straight – can really heat up a phone. It’s a good idea to occasionally take a break and turn off the display. It also drains the battery more quickly. And remember, the app is sending the audio stream back to Google’s servers to do the real work. If you’re not on Wi-Fi, it might be a heavy user of data, although I haven’t tested for that.

How Useful Is It?

So just how useful is this to DX hobbyists? On the shortwave broadcast bands, automatic translation makes it possible to monitor stations even if they don’t broadcast in a language that you speak. It also makes it possible to compare what a specific station is telling its different audiences. What is China Radio International’s Swahili service saying? It can be a tool for medium wave DXing if you are in a place where there are stations in multiple languages.

I was primarily interested in translation for utility DXing, and it worked well for communications from official organizations. Google Translate was indispensable for DXing the Vietnamese marine stations, and it also helped me translate and identify scheduled marine broadcasts from China, Japan, and Indonesia, and to log that Philippine Coast Guard vessel.

But what I was really interested in was the two-party and multi-party conversations in numerous languages that fill many of the utility bands. My hope was to translate those and, in the process, identify and log some really unusual stations. It didn’t work anywhere near as well as I had hoped. For one thing, the users of those stations know one another by voice or by nicknames, so there aren’t ID announcements, and rarely do they say anything to indicate exactly where they are located. But the real problem was still language.

My Spanish is very good, and I have no trouble following weather forecasts from the Colombian Coast Guard. But when they start taking messages from local fishermen, I’m lucky if I can pick out a third of what the fishermen are saying. And it’s no better in my native language. I perfectly understand weather reports from the Canadian Coast Guard in Newfoundland, but I struggle with Newfoundland fishermen.

Google Translate can deal with dialect differences – say between Colombian and Argentine Spanish or between English as spoken in Alabama versus Scotland. But in any language, people with less education or less status or far from the centers of commerce and learning are less likely to speak the language according to expected standards. Grammar rules aren’t followed, and pronunciation gets muddled. Localized slang and expressions get used. (It would be wrong, however, to say these people don’t know how to speak their own language. For more on this, read up on prescriptive versus descriptive linguistics.)

Language translation AI is trained on official sources and what is available on the Internet. Not much of that comes from the least educated and most remote speakers of any language. That is precisely the problem I had in trying to DX the two-way chatter on the utility bands. Even with a strong, clear signal, the app would struggle with the translation and only get phrases here and there. Sometimes the translation didn’t make sense because the AI seemed to be literally translating local slang expressions. But occasionally I got something useful, such as two Indonesian stations that gave their locations as Bandung and Kendari, even if I had no idea who they were.

How useful automatic translation is for DXing depends on what you want to use it for. And, of course, how clear the signal is that you want to translate. If nothing else, it’s fun to play with, and I recommend giving it a try.

How Do They Say That? Using Text-to-Speech for Foreign Language DX Identification

1 Reply

By Don Moore

When I first discovered shortwave radio way back in 1971, right from the start I was both a listener (looking for interesting content) and a DXer (trying to hear as many different places as possible). But my DXing had a problem in that I only spoke English. Sure, lots of countries had international broadcasters with programs in English. But how was I going to log the many that didn’t?

In July 1972, I ordered a sample copy of FRENDX, the bulletin of the North American Shortwave Association. It was the first time I had seen a DX bulletin, and I learned a lot. The most eye-opening thing I found out was that other North American DXers were routinely identifying and logging radio stations using languages that they didn’t themselves speak. I was genuinely surprised by this. But if they could do it, then I could, too.

I began by going after Spanish-language broadcasters. I had started studying Spanish in school, so I knew the pronunciation rules even if I didn’t yet understand much. Some station names, like Barquisimeto and Bucaramanga, were even fun to say. I soon branched out to DXing stations in Portuguese, Arabic, and French and eventually to other languages like Russian and Indonesian. One thing that helped was that in those days the World Radio TV Handbook included transcriptions of standard ID announcements from many stations, such as in the image below of Radiodiffusion Television Algerienne in the 1972 WRTH. But whatever the language, the difficulty was always the same. What my English-centered brain thought the words in a book should sound like didn’t always match how the native speakers of the language actually said it.

The anecdote, of course, was experience. Over time I developed an ear for the various languages used by lots of DX stations. Even so, long words could still trip me up. Sure, my knowledge of Spanish made Barquisimeto and Bucaramanga easy. But words like Tanjungkarang and Manokwari in Indonesian and Itatiaia and Goiânia in Portuguese still gave me headaches.

The Reasons Why

In the late 1980s I went back to school to get a master’s degree in Applied Linguistics with the goal of teaching English as a Second Language. One of the first classes I had to take was phonetics – the study of how our mouths make the sounds that turn into words. It’s more complex than you might think. The International Phonetic Alphabet has 107 symbols for distinct vowel and consonant sounds. I had to learn to audibly recognize each of them. (Just don’t ask me to do it now.) Each of those sounds can be further modified in various ways, and it’s those sounds with modifications that produce the unique phonemes that make up each language. Standards of measurement vary, but the best estimates put the total number of phonemes in all the world’s languages at around eight hundred. Most languages only use around forty. English has 44 phonemes.

So that station name spelled out on a printed list may not only sound different than you expect, but it likely also contains sounds that you don’t even know. And when the sounds get chained into words, there’s the issue of which syllable gets the stress (consider photograph versus photography). Many languages help by using accent marks when stress differs from the standard. As words get chained into sentences, the connections also affect pronunciation, such as how “got to” becomes “gotta” in colloquial English. Other languages do the same thing. And I’m not even going to go into the use of tones in languages like Mandarin, Vietnamese, and Thai.

If you think English is an easy language, you are wrong. In terms of how the pronunciation of a word matches the spelling, English is one of the worst. There are historical reasons for the inconsistencies, but about 20% of English words are pronounced significantly differently from how they are spelled. And we don’t use accents or other diacritic marks to indicate when the sound differs from what’s standard. That makes English a difficult language to learn to speak and to understand. My linguistic DX heroes are any non-native English speakers DXing American medium wave stations. Local people do not pronounce places like Louisville (Kentucky) or DuBois (Pennsylvania) the way you would expect.

So there are all types of reasons why that station identification may not sound like we think it should sound.

But There’s a Solution …

I didn’t lead you all the way here just to complain about how complicated it all is. We now have a solution.

Text-to-speech is the process of presenting a computer program with a word or phrase and having it generate the sounds. For most of us, our first experience with this probably happened two or three decades ago when calling an automated phone system that used a mechanical voice to read back unique information that couldn’t be prerecorded by a human. It was pretty bad, and text-to-speech of the era deservedly got a bad reputation.

But the good news is that, like so much technology, text-to-speech has gotten a lot better. Some of it is so good that it’s become difficult to distinguish computer-generated speech from real human speech. Of course, the ways that can be misused also make it scary, but that’s a topic for other forums. Dozens of companies provide text-to-speech software in dozens of languages. And most of them have websites where you can try out their software for free.

I do a lot of DXing of stations in languages that I don’t understand or know well. And sometimes I hear what seems to be an ID but doesn’t match what I would expect from the spelling of any listed station. Then I go to one of those text-to-speech websites and plug in the station name to create a sample audio file. I compare that file with what is being said in my DX recording to see if they match.

I’ve been using this method for several years with Brazilian medium wave stations, Russian airports, and Indonesian marine stations, among others. I’ve confirmed numerous IDs this way that otherwise I wouldn’t have figured out, or at least not have been as comfortable that I had gotten the logging right. A couple of times it’s even saved me from making mis-logs on similarly spelled station names on the same frequency.

Most text-to-speech generators offer multiple voices, including both male and female. I always pick the gender that matches that of the ID I’m comparing to. For the most widely spoken languages, some companies offer multiple dialects, like Nigerian English or Argentine Spanish. So if you’re trying to ID a Colombian station, pick Colombian Spanish, not Argentine.

And, very important, be sure to use the correct spelling when pasting in the station name to check. That means including all the accent marks, tildes, umlauts, cedillas, etc. They are there to indicate how the word is pronounced, and if you omit them you will not get the right result. To make sure I have the correct spelling with all the proper diacritic marks, I usually copy/paste from Google Maps, a Wikipedia article, or some other webpage.

Finally, be aware that some local pronunciations are so unusual that the speech engines still may not get it right. I grew up near DuBois, Pennsylvania, and not one of the text-to-speech sites I tested said “DuBois, Pennsylvania” the way the people who live there do. They call their town “DO-boys.” To any native French speakers reading this, I sincerely apologize for what we Pennsylvanians have done to your language.

Links

A quick way to find a TTS engine is to do a web search for “<language name> text to speech”. Here are a few of the better ones.

https://speechgen.io/en/voices/ SpeechGen has a wide variety of regional Arabic, English, and Spanish accents.
https://www.narakeet.com/ Narakeet has the largest variety of languages I’ve found anywhere. However, the system has few regional Spanish accents and only one for Arabic. Click on voices in the top menu.
https://www.naturalreaders.com/online/ Natural Readers is another large provider, although their selection of languages is smaller.

Help record the 2026 BBC Antarctic Midwinter Broadcast later today (June 21, 2026)

Every year, the BBC broadcasts a special program to the scientists and support staff in the British Antarctic Survey Team. The BBC plays music requests and sends special messages to the small team located at various Antarctic research stations. Each year, the thirty minute show is guaranteed to be quirky, nostalgic, and certainly a DX-worthy catch!

After successful listener events from years past, I’m once again calling on all SWLing Post readers and shortwave radio listeners to make a short recording (say, 30–60 seconds) of the BBC Antarctic Midwinter Broadcast today and share it here on the SWLing Post. Details on this below.

Time and frequencies

Thanks to Dave Porter who has confirmed these three shortwave frequencies for the annual BBC Antarctic Midwinter Broadcast (2130–2200 UTC Sunday, June 21, 2026):

9460 kHz from Woofferton
9510 kHz from Ascension
12070 kHz from Woofferton
Also on DAB in the UK at 2130 UTC (2230 BST).

Recording the Midwinter Broadcast has become an SWLing Post community tradition! Read our previous post for more details.

I’m especially fond of this broadcast as it always falls on my birthday and it’s always fun capturing this unique DX!

Share your recording and notes with us!

Comment with your recording!

During the Midwinter Broadcast, I will publish a dedicated post where you can comment and include links to audio and video of your 2026 Midwinter Broadcast recordings. When this post is available, I will link to it here. This will allow you to post your logs and recordings at your convenience without my availability becoming the bottleneck.

So that there’s no confusion, I’ve turned off comments on this post so that comments are left on the appropriate article.

Here’s the format I’d like you to leave in your comment on the dedicated post:

Name:

Listening location:

Notes: (Include frequencies and any details about your receiver and antenna.)

Link to audio or video: (YouTube, Vimeo, Internet Archive, SoundCloud, etc.)

Video and Audio Recordings

There is no way to directly upload audio in your comments, however, you can link to the recordings if you upload them to the Internet Archive (which I’d highly recommend) or any of the video streaming services—like YouTube and Vimeo—or audio services like SoundCloud.

If you have a photo you’d like to include in your comment, send me an email from the same address you used in your comment. I’ll manually post the image at the top of your comment when time allows.

As with each year, I’ll make sure the BAS team and the BBC receive a link with all of your recordings!

Antarctic Midwinter Broadcast 2026: Tune in Sunday, June 21, 2026

2 Replies

Each year, we look forward to one of the most unique traditions in the world of shortwave radio: the BBC’s Antarctic Midwinter Broadcast—a special program beamed to a handful of overwintering scientists and support staff at British Antarctic research stations.

Halley VI: The British Antarctic Survey’s new base (Source: British Antarctic Survey)

SWLing Post readers around the globe regularly tune in and make off-air recordings of this remarkable broadcast, sharing reception reports and recordings from every corner of the planet. It’s one of our favorite annual traditions!

Time and Frequencies

Many thanks to SWLing Post contributor Richard Langley, who shares the following information via the bdxc-news and Alan Pennington:

Thanks to Dave Porter, who has confirmed these three shortwave frequencies for the annual BBC Antarctic midwinter broadcast (2130-2200 UTC Sunday 21st June):

- 9460 kHz from Woofferton.
- 9510 kHz from Ascension
- 12070 kHz from Woofferton

Also on DAB in UK at 2130 UTC (2230 BST).

https://www.bbc.co.uk/programmes/w3ct9bnv

As always, we’ll post an article here on Sunday as the broadcast begins, where you can share your own reception reports, audio clips, and impressions in the comments section—just as we’ve done in years past.

Happy DXing, and let’s celebrate midwinter together—wherever you are in the world!

DXing Comes to the Madison Clinic

The MLite-880: A more thorough performance assessment

15 Replies

By 13dka

Following up on the article I recently wrote about the MLite-880, I still had a comparison with a reference radio on a proper antenna on my to-do list. I wasn’t in a hurry because I got pretty fascinated with exploring what I can get out of various magmounts on my car with this radio, which is quite a lot and it never gave me the feeling of missing out on something. I was also a bit hung up on the idea of comparing the MLite with the Belka because, you know, same price level and all, but that’s a bit iffy with my little passive splitter and 2 different input impedances.

Then a claim was made on the interwebz that the MLite-880 would be just a mediocre radio that would not stand scrutiny without its outstanding noise reduction, to summarize that in my own words. My experience is obviously very different and it made me curious how much truth could be in this claim. So I just took the ingenious Icom and the mediocre MLite to the dike to slip in a little shootout and then maybe give the loser a Viking funeral on a little raft I improvised out of flotsam and jetsam while making a lot of recordings to give my findings a whiff of evidence.

Both radios were connected to my lazy 10m/33′ monopole antenna via a Diamond SS-500 splitter and 15m double-shielded and common-mode choked coax. Both were recording to their own SD cards, but unfortunately, the recorded audio from the Icom does not represent the live audio off the radio on AM recordings because it records to an SD card with an 8 kHz sample rate, and that limits the audio bandwidth to at best 4 kHz. The deciding thing to listen to in these recordings is the noise and sometimes the pure existence of a signal, though, and lower bandwidth is almost an advantage in this context.

oznorWO

Sensitivity Test

Since the question is really the practical sensitivity and, therefore, how dependent this radio is on its noise reduction to get good results, I’ll start with the IBP beacons, which were recorded without NR, of course. To spot and quantify SNR/sensitivity differences you can use the four -10dB stepped (100W, 10W, 1W, 0.1W) dashes the IBP beacons transmit after their callsign.

The most grassrootsy first: OA4B in Peru (10,800km/6,700mi) on the 17m-band. MLite first, then the Icom. Both radios receive the second (10W) dash as faintly as the 100W dash, but with too little SNR left.

5Z4B beacon in Nairobi, Kenya (6,600km/4,100mi with a 3rd dash = 1W!) informing a silent 15m band about the opportunity around sunset. MLite starts again, then the Icom. The latter has the 3rd dash faintly but clearly and the former leaves some more ambiguity about that. Demonstrates again the minuscule difference.

5Z4B again, but on 20m with a 4th dash to count, whether or not the last one is really from 5Z4B or just interference doesn’t matter; what counts is that both radios heard it. The 1W dash was clearly received by both, starting with the MLite.

Here’s one where only the MLite heard an interference, and I’m not sure it imagined it (absolutely unavoidable pun) – VK6RBP in Australia for the 10,000 miles bragging rights.

I think the conclusion here is that we could probably agree on “same ballpark”, right? I don’t know about you, but imagine my surprised Pikachu face!

The AF SNR difference, which is probably all that counts in sensitivity tests, is within 3dB between the two, not to be confused with RF power decibels (but reflected on the RF side in comparably small amounts). For the interested:I did take day/night variations of the noise floor above 10MHz into consideration, with a decreased noise level around midnight on 21MHz, the MLite still matches the Icom, which is all that counts in this comparison (not absolute measurements) context.

The magic button

Another claim was made about the noise reduction, that it would only work with signals of a certain strength. While it is technically correct that it needs a minimum SNR to improve upon, my experience is that it is effective with almost any remaining SNR, provided the signal is fed into the NR with sufficient levels, and it exceeds all my expectations at that. Here are a few recordings of CHU demonstrating both points:

CHU 14670 kHz in Ottawa (5,800km/3,600mi) in bad enough conditions. The same announcement from the IC-705, then the MLite with NR at ? of its range. Note how difficult the French announcement at the end of the transmission is for both radios. I will miss that station. The noise, not so much.

This is just the announcement a minute earlier, when the signal dipped below the noise floor. Nothing gets really recovered, but nothing gets lost either, and what’s left stands out more:

However, if you only look at its inability to cheat physics, you could be missing the point of a good noise reduction in this particular “shortwave radio” context. Restoring fidelity, removing masking noises and generally increasing the SNR and thus ease of listening is having a massive impact on how at least I can enjoy programs or conversations and there’s more: After a few decades many of us (particularly 2-way) radioheads have gotten their auditory cortices hardwired to make a connection between noise and signal strength and then pushing this NR button might feel like witchcraft when it makes a bloke driving around on the other side of the globe sound like he’s just passing your local highway intersection.

In the following sound clips you will hear both radios taking turns in 5-second chunks as if I switch forth and back between them, in some of them I will play the same bit of transmission twice, first from the one, then the other radio so you can e.g. make out differences quite precisely. Continue reading →

Did the Miyako earthquake affect Medium Wave reception at a Japanese DXpedition?

3 Replies

by Satoshi Miyauchi, JP1SCQ, with Nick Hall-Patch, VE7DXR

Introduction

In early November 2025, several members of our Totsuka DXers Circle in Japan (TDXC https://www.tdxc.net/abouttdxc/ ) traveled from the Tokyo area to Tanohata village in Iwate prefecture on northern Honshu island in order to take part in a medium wave (MW) DXpedition that took place on the 8th and 9th of the month. The site was about 500m (1/3 mile) from the Pacific Ocean, overlooking Kitayamazaki cliffs, a very scenic area (Figure 1), but also one from which a great deal of long-haul DX had been heard in the past, including trans-polar WBZ-1030kHz, as well as the farthest possible Antipodes DX such as R. Nacional in Argentina on 870kHz and Radio Monte Carlo in Uruguay on 930kHz.

Figure 1

Our listening post was a meeting room in the Tanohata Nature Training Center, where we set up our receivers, such as Perseus and Airspy HF+discovery, plus our recording gear and accessories (Figure 2).

Figure 2

My recording software was SDR Console, but playback and analysis also used WavViewDX. We set up a TDDF (Twisted Double Delta Flag) antenna with a northeast directional pattern in order to receive medium-wave broadcasts from North America. (Figure 3)

Figure 3 – TDDF antenna; note that low-noise pre-amplifier with bias-T is a must.

Directional patterns from Kazu GOSUI

On the second evening, November 9th, while enjoying the reception, an emergency earthquake alert was issued, and shaking struck. Inside our building, nearly 200 meters above sea level on the solid bedrock of Kitayamazaki, the shaking felt less intense than the reported magnitude of 6.9, even with an epicenter only 140km away. (Figure 4)

Figure 4

However, since earthquakes had been occurring even before that day and numerous aftershocks were felt afterward, it left us with a vague sense of unease. Later, a tsunami advisory was announced on the radio, plus the Tohoku Shinkansen train back to Tokyo had also stopped, and I myself couldn’t help worrying about whether it might affect my return home the following day. At that moment, I had a conversation with the members there, thinking, “If there’s something related to the earthquake recorded, that would be amazing.” However, during the real-time reception, we were targeting signals from North America in 10kHz steps, and there was no effect noticed upon those receptions.

Unusual Signal Dropouts Observed

I played back the SDR files using WavViewDX (https://rweiss.de/dxer/tools.html), a software with many capabilities, including a choice of displaying all signals across the MW band at 9 or 10kHz channel spacing, but, because I was looking for North American DX, I only realized a week after returning home that the reception conditions for the 9kHz spaced domestic Japanese stations had significantly changed around 0715 to 0745UT (16:15 to 16:45 Japan time) on 9 November, based on our recordings. The dropouts on various channels over 0715 to 0745UT are quite obvious in Figure 5; I had never seen such sudden attenuation before. For those not familiar with WavViewDX, the green vertical lines on the display represent stronger signals being received on broadcast channels, while gray or black areas represent weak or no signal. (For a more detailed description of WavViewDX and its capabilities, see https://swling.com/blog/2025/10/an-introduction-to-wavviewdx-sdr-playback-software-a-totsuka-dxers-circle-article-by-kazu-gosui

Figure 5 – WavViewDX display of signal dropouts. X-axis is frequency of received signal, Y-axis is time UTC

A first look at the data led to a couple of other observations:

Signals originating north of the receiving site, primarily from the island of Hokkaido, were largely unaffected by the attenuation. (It is true that our antenna’s directionality was northeast, but it also received the stronger domestic stations from southwest of the antenna.)
Regarding signals from North America, even during the same time period, the intense attenuation observed in domestic stations was generally not seen. It is unclear, however, whether some dips in North American signals around that time were due to normal fading or to the same cause that brought about the attenuation in domestic stations.

What Could Have Caused These Dropouts?

Local sunset?

These sudden drops in signal strength corresponded quite closely with local sunset at 0722UT, normally a time of disturbed propagation (see Figure 6), so the most straightforward possibility is simply the well-known change in ionospheric propagation conditions that occurs at sunset. Was that all that there was to it? However, we had been listening and recording the previous day as well, and analyzing those recordings with WavViewDX yielded no sign of dropouts in domestic signal strength at sunset on that day. Examining recordings that had been made at the same site, using similar equipment, on 24 October 2024, also showed no dropouts taking place at local sunset.

Figure 6

In fact, over many years in Japan, not only at this location but across various areas, records have been accumulated during the same time window, because good trans-Pacific DX occurs around local sunset. Nowhere in these records has a situation such as observed this time—a significant attenuation of domestic stations at local sunset—been found. Therefore, it seemed unlikely that sunset was the cause of the dropouts, but what else could it have been? Continue reading →