Recently, I have been getting back into some shortwave listening and utility monitoring, but not quite in the conventional sense. I still have my own local conventional radio, SDR and loop antenna. But now, I also have the power of the internet (through LTE since I’ve got no NBN service yet) … which means that I could be listening from your place as well.
Can I Borrow Your Radio and Antenna? Please?
If you’re interested in the hobby of radio like I am, it can be quite devastating to live in a large city. Depending on your geographical location, you can be cursed with a number of difficulties including:
- Not having a backyard or access to a rooftop to be able to set up an antenna at a decent elevation, or having council restrictions/neighbours which prevent you from doing so.
- Being on the leeward facing side of a hill which obstructs your line of sight into the city and its main transmission towers.
- Being close to neighbours who love to use power-over-Ethernet, off-brand LED globes, arc welders and solar garden lights that spew noise all over the band and raise the noise floor.
- Being close to high-voltage transmission lines with dirty insulators resulting in partial discharges that also create noise.
- Having too much signal from nearby transmitters that cause intermodulation “images” in your receiver or require expensive filters to effectively handle, making DXing nearly impossible.
- Unseasonal stormy weather which can be a risk to your gear just as you had some free time to devote to listening.
I’ve been affected by all of the above at various stages, which has been rather unfortunate. However, occasionally an opportunity would come up that I would go to another location – say for a holiday, to visit a friend for a few days, etc. This was the ideal situation for me to bring along a backpack of radio gear – a mini DXpedition in a way to explore the radio landscape somewhere else and hear all that I have been missing.
Unfortunately, such DXpeditions were rather limiting – the opportunity only arose occasionally, the need to be mobile restricted the quality of the gear I could bring and consequently the signals I could capture and there would occasionally even be a risk of danger – either to my gear being damaged or lost in transit, or myself in being accused of being a spy or of illegally eavesdropping/receiving signals. The laws in other countries are not always as liberal or as straightforward as the ones at home.
As a result, it actually makes more sense to “borrow” someone’s whole setup instead, as it’s probably already been developed over a period of time and optimised with better equipment. With the existence of the internet with greater bandwidth, greater reliability and lower costs, the concept of a remote base stated to appear. Those fortunate enough could set up a remote controlled receiver with a computer as a server, connected to the internet, so they could use it from their home in the city. Some remote bases were rather elaborate with transmit capabilities as well, but most of them were very much private – e.g. someone setting it up for their own use, or it belonging to a club for club members to use on a scheduled basis. Not being a member of any clubs, this was not something I got into. Of course, this was possible prior to the internet age by using a phone patch repeater, but that was even more niche and expensive.
What I did get into was GlobalTuners. This was a receive-only operation, originally using conventional receivers which were remotely controlled, offering just one channel at a time with some receivers public and “free” to use, others only available to subscribers. The “free” service really piqued my interest, so I gave it a try.
With GlobalTuners, I was able to tune in via different locations across the world to signals I had no chances of hearing at home. Local ATIS, broadcast radio, VOLMETs and even emergency services were available for the taking thanks to the generosity of the operators willing to offer their rigs up for use.
Unfortunately, there were a number of issues – the fact that we could only listen to one channel at a time due to the conventional receiver meant that long term monitoring was not possible, with some time limits set in place and a policy that required users to “share” the receiver and hand over control. Increasingly, the better receivers either became premium or eventually went offline as they were (potentially) worn-out due to the heavy load of constant band/frequency switching and owners were reluctant to replace their rigs only to have them meet with the same fate.
While I could see the potential in GlobalTuners, it didn’t really fit my style of listening (which verges on monitoring). Depending on what you were monitoring, there are some sites dedicated to monitoring certain services (e.g. liveatc.net), but that wasn’t quite as convenient and streamlined as grabbing a multi-band radio and whipping it around the bands. You’d really only get to listen to what other people wanted to listen to.
Something better was required … and eventually, it came in the form of WebSDR.
Software Defined Radio – Many Receivers in One
While conventional radios still ruled the roost when I started my hobby and I still do use a number of them, a revolution was waiting in the wings. Enabled by increasing computing power and memory capacity, combined with reducing costs, the software defined radio seemingly unseated the conventional superheterodyne receiver in the space of no more than a decade.
In fact, I went all-in on SDRs from as early as 2010, purchasing a Winradio G31DDC Excalibur SDR which offered 2Mhz DDC bandwidth in a direct conversion design. I followed that up with the FunCube Dongle in 2012, then offering about 80kHz of real bandwidth but operating in VHF/UHF frequencies. Around the same time, news of the I/Q sampling mode of the RTL2832U DVB-T tuner dongles became widespread leading to the plethora of “$11 SDR” articles that really began to democratise access to radio receivers and increase interest in the whole SDR concept. Since then, I’ve also owned a BladeRF x40 with HF transverter board for even more bandwidth (~28Mhz).
The concept of an SDR is fairly simple – minimise the analog componentry and move as much of the work into the digital signal processing domain as possible. As a result, most SDRs have the bare minimum in terms of signal amplification and bandwidth filtering before digitising the signal using a high-rate ADC, converting it into the digital domain. From there, the reception and demodulation chain can be emulated in software.
With my first SDR, the technology was still in its “infancy” from the perspective of a consumer, requiring absolutely all the processing power of my most powerful dual-core computer of the time to keep-up with its requirements. However, the benefits were already immediately apparent. With a 2Mhz DDC bandwidth, it was now possible to record and replay 2Mhz-wide chunks of spectrum for monitoring of a whole band over a long time. It was possible to have up to three parallel demodulators running to receive multiple signals within this same span for comparison. It was possible to jump around a recording, as there is a waterfall-style spectrum display which makes listening and tuning into radio a visual endeavour as well. It was possible to achieve things that could not have been readily or affordably done with conventional receivers. The downside was the radio itself sometimes was not as sensitive, the demodulation quality and stability varied depending on the computer and the computer’s own RF noise can be a problem especially with monitor leads radiating quite a bit of EMI.
But since then, computing power has increased and more efficient implementation of algorithms with careful understanding of the underlying hardware has led to the existence of online SDR-based radios, addressing the issue of multiple-access.
The first real effort I would consider a quantum leap was the University of Twente’s WebSDR. Initially set-up on Christmas Eve of 2007 at the radio club of the University of Twente and maintained by PA3FWM, it had a 1.5 year interruption between November 2010 through to July 2012. Unfortunately for me, I did not become aware of it until much later.
The WebSDR at UTwente covers the full spectrum from 0-29.160Mhz and often has several hundred listeners using it at any one time. Owing to running on relatively beefy hardware with GPU acceleration, it is possible to have over 500 users listening to different channels at the same time.
Initially based on HTML and Java applets, WebSDR has now evolved into HTML5 allowing for operation on most browsers. The interface has slowly gained a number of extra abilities, but the grey background with purple-and-white waterfall palette remain characteristic of WebSDRs in general, allowing users to zoom in-and-out of the band and look for the next signal of interest all while listening. There are chatbox features and a logbook, along with the ability to see where the other users are tuned to for some inspiration.
While the interface is rather clunky, it worked quite well and the reception in Europe was absolutely mind-blowing. As someone mostly living in a high-noise floor environment in a country few shortwave broadcasters target with relatively few radio amateurs, I could never imagine the band to be as crowded and bursting with life as I’ve seen it on WebSDR.
When listening with the UTwente WebSDR, it is almost like “being there in Europe”. Due to the nature of SDR technology, you can tune into anything without disturbing anyone else. With the waterfall spectrum ability, you can see the signals and tune around in comfort with great efficiency. If you want more, you can open another window and record something as well. Most of the demodulation options you’d need are provided including the regular modes but also variable filter bandwidths and notching of interference. While it’s not quite as flexible as having your own radio with knobs, it’s not far from it. I was absolutely enamored with WebSDR, being able to hear signals I never knew existed. There were some caveats, however, which I will get into later.
Not unexpectedly, this did spark interest in some others to start running their own WebSDR. As a result, there are a number of other WebSDRs running, mostly with limited bandwidth Softrock style receivers being of more limited interest.
However, WebSDR is not the only web-based SDR project out there. I recently became aware of OpenWebRX which is an open-source SDR web server supporting a number of different SDR receivers with the possibility for integrated digital mode decoding and relatively modest DSP resource requirements. By hosting OpenWebRX, it becomes possible to share your SDR with a number of users at the same time – even with absolute strangers on the internet. As of this time, there are over 350 receivers online.
If you look on the list of OpenWebRX receivers, a majority of them are KiwiSDRs. The KiwiSDR is actually a hardware product which is a wide-band SDR and GPS cape for the BeagleBone Black that creates an OpenWebRX SDR server in a very compact, low-powered package. It uses FPGA-based acceleration to create something similar to WebSDR but on a smaller scale of anywhere from about 3 to 8 simultaneous users (depending on bandwidth and with or without waterfall operating mode). Considering the hardware used, the result is quite impressive.
It seems the popularity of the KiwiSDR stems from its reasonable cost and its performance capabilities. It’s not every-day you can afford a radio that is able to GPS-calibrate its internal oscillator for one, or serve radio the world with integrated decoding of some digital modes from something smaller than an average paperback novel.
As a result, I’d have to salute the KiwiSDR guys for creating a product that individuals can afford to buy and use to enable access to their local airwaves over the internet. For a number of years, I lamented that there was only one wideband SDR at websdr.org – now with the advent of KiwiSDR, there are hundreds scattered across the world. Of course, there are some caveats, but the fact that so many generous operators out there has really enhanced my radio monitoring capabilities.
Uses, Tips and Common Frustrations
So, what can a WebSDR be used for? A lot of things:
- Listening to shortwave/AM broadcasts which you can’t receive at home for some reason – this could be weak signals, lack of equipment through to censorship.
- Monitoring broadcasts from different locations to check whether the signal is on the air or not.
- Monitor the spectrum of a band while you operate from home using conventional equipment.
- Verify if your transmissions are reaching a target area or not.
- Listening into radio amateur communications to better understand shortwave propagation behaviour or decode various exotic digital modes.
- Receive utility station broadcasts such as weather faxes or RTTY transmissions.
- Receive the signal from multiple places at once.
- Getting into shortwave radio at nearly no cost!
All you need is a semi-decent internet connection, a computer and a web browser, making the barrier of entry extremely low to the point that even inexperienced members of the public can start to use it.
You can even listen on your phone – my informal quick testing showed that the interface was usable in Chrome Mobile, although the dragging and pinching did not quite behave as I expected. Still, for listening to shortwave “on-the-go”, it’s quite a nifty outcome. The power of a 20m longwire antenna perched up high somewhere in the world from your pocket? It’s possible!
Using WebSDR/OpenWebRX receivers does come with some caveats which are worth understanding. Due to the limitations in hardware and internet bandwidth, most of these receivers can only offer relatively limited listening bandwidths of say approximately 12kHz or maybe even 20kHz. It would not be possible to receive or analyze wider signals, but even 12kHz is enough to decode DRM audio if you configure it appropriately – namely IQ mode reception, positive split mode in Dream.
I successfully was able to receive this Chinese service from a KiwiSDR –
Recordings are performed in the users’ browser, so it pays to ensure that you have a good internet connection and sufficient RAM, as any interruptions in the stream will be in the recording as well.
The internet itself is not optimised for real-time data operations, with congestion between any path between you and the server potentially causing packet loss and/or delay which can result in breaks in audio. When it comes to decoding certain forms of transmissions, such breaks can result in a loss of synchronization, causing a loss of the payload. As a result, OpenWebRX also has “plug-in extension” decoders which can help by doing the decoding on the server-side and passing the results along, avoiding this issue. However, there will be times where you might want to run local decoders – I cover this in the following section.
Despite this, it would make sense to optimise your own network to ensure that you have as good of a connection as possible to support real-time operation. Namely, avoid downloading files while trying to use SDRs, perhaps put in QoS rate limiting measures or use an Ethernet cable rather than a Wi-Fi connection and ensuring your modem has a good signal can make the reception more stable. Failing this, it can help to choose a closer SDR, as the hops the traffic takes along the internet will vary depending on destination.
Sometimes, the bandwidth problem may not be simply at your end, so reducing bandwidth usage may be a good idea. If you are simply monitoring a service, you can disable the waterfall by setting the rate to off to reduce bandwidth consumption. This will also help those who might be on a limited quota (like myself). Also highlighted is the quick jump to band features and page up and down which allows you to more rapidly navigate the spectrum – a useful hint. The extension drop-down houses the server-side decoding extension features, if you wish to use it.
Another caveat is, by default, the audio is compressed to reduce bandwidth requirements. While this is a sensible default which allows for better bandwidth utilisation and reduces the possibility of breaks in the audio, the compression is lossy and does result in a degradation of signal-to-noise ratio which can be important for some modes. This can be disabled using the “Comp” button, but the results do vary (as sometimes you will have more breaks due to bandwidth issues as a result). There is also a Noise Blanker feature (NB) which is useful for reception in the presence of impulse noise, but also when the KiwiSDR has a case of slight input overload (denoted by a red OV indicator in the S-meter bar).
So how can we get the most from WebSDR services? The first step might be to pay attention to the audio routing.
In order to use local decoders, it is necessary to install some form of loop-back audio cable. Virtual cables introduce no additional noise or losses, but can suffer problems due to buffer overflow/underrun due to the sample-accurate mode of operation. In my case, I have a path using one audio cable for decoding from WebSDRs (one at a time), one for my conventional receiver, and one for recordings only which allows for those to operate independently and simultaneously.
By setting my default audio device to the first virtual cable, the browser-based WebSDRs play into the cable linked into my decoders. So that I can continue to use the computer and watch videos, all of the applications which support manually selecting the audio output device instead output directly to my soundcard instead, thus not interfering with the WebSDR decoding.
In some cases, it is necessary to monitor the WebSDR audio output, which can be done using software playthrough by configuring this inside the audio control panel.
Leaving this switched on, it is then possible to decide using the mixer whether the playthrough is muted and to which volume it is mixed into the other audio going to my speakers or headphones.
As many browsers now have a per-tab audio switching feature, it is possible to open multiple WebSDR receivers at once, muting all of them except the one you’re interested in listening to or decoding. This way, you can continue to examine the waterfall spectrum from other receivers or at different frequencies quasi-simultaneously to check whether the signal is better or worse at another location. You can also engage the recording feature on the “silenced” tabs and then decode the .WAV file later. Also, avoid doing this for extensive periods as you could be blocking other people from making use of that particular receiver by consuming its limited resources. Sometimes, especially from the UTwente WebSDR, you will find decoded images have an inconsistent “wobble” due to the resampling algorithm – if you make a recording using the page and decode this recording, this wobble disappears which is good to know.
Sometimes you might get strange results including very frequent breaks in decoding due to sample rate mismatch, so it pays to check the format the audio cable is using. Most modern cards use 48kHz as the default rate, so it’s often good to standardise on a single rate across all devices.
Also ensure your decoder is configured to use this same rate, which avoids resampling which can further degrade signal and be an occasional source of overflows/underruns. Of course, if I was going all-out to have more decoder chains, it could well be worthwhile running multiple virtual machines with their own individual audio routing instead.
To ensure settings and decoded results are kept separate – use a separate Fldigi settings storage by creating a shortcut and appending the profile storage location, as I have done in the screenshot above.
Another thing to be aware of is that KiwiSDRs have various time-out features which can be configured by the operator to ensure fairer use of resources and to avoid monopolization. The first is an inactivity time-out, which kicks in if you’ve left yourself “parked” on a frequency for extended periods, stopping reception. You can avoid this by tuning around every-so-often or refreshing the page once you hit the error.
The second one is the daily time limit, which is the maximum amount of reception time allowed per IP address in a day. The remaining time of your daily limit is shown in orange under the Users tab next to the receiver you are using.
Being IP-address based, this could potentially result in less-than-expected listening time if behind a corporate grade NAT or when sharing a single internet connection with others. Whatever you do, resist the temptation to change your IP address (e.g. by VPN or by grabbing a new dynamic address) – these limits are put in by the operators to improve fairness of access and they won’t be pleased if they find someone is continually monopolizing their receiver! Also, think about the rest of the community who might want to use it, even for a quick “spot” check of a signal.
Unfortunately, for the moment, hitting either one of these time-outs during a recording will cause you to lose your recording, so take special care to keep an eye on the timers and familiarise yourself with any inactivity timeout on the SDR by trial and error.
The final sort of time-out you might encounter is that of a network communication issue, which often results in a frozen OpenWebRX interface that does nothing until you refresh the page. Unfortunately, this is a fact of “internet” life – connections can break at any point between you and the server, so it pays to ensure that your network at home is as “good” as it can be to eliminate any causes of connection breakage (e.g. not using Wi-Fi). Often it can help to try another nearby receiver – the issue could be someone’s modem/link to their ISP or even the transits between the ISP and your ISP.
You might find some of the KiwiSDRs have a URL that ends in proxy.kiwisdr.com. These stations are ones who, for some reason or another, could not offer a direct port forward from their public IP address to their KiwiSDR and are instead relying on a relay service provided by KiwiSDR. As a result, radios operating this way may not be as smooth or reliable as the traffic has to pass through (normally) more links to the KiwiSDR VPS (Linode at the moment if I’m not mistaken) before then travelling to the listener. This is slightly inefficient, consuming additional resources, but is the only sure-fire way of breaking free of multiple NATs, carrier-grade NATs or ISP-related firewalls and is currently offered for free, but may not be the case in the future.
It’s important to remember that the SDRs, especially KiwiSDRs, are a limited resource. Depending on their configuration, they can host either 3 users (20khz mode), 4 users (classic) or 8 users (maximum, 2 waterfall, 6 audio-only). As a result, you might encounter the above message when trying to access a receiver – the only recourse is just to wait it out until someone else relinquishes their slot.
Sometimes, you might find a public SDR has suddenly gone into a password protected mode. If you see this, it’s good to wait and try again in a few hours as it’s probably a sign that the Kiwi’s owner is on the air and probably needs their radio. Otherwise, you can find some radios which go “deaf” occasionally as if the antenna is disconnected – this is likely as the owner is transmitting and switching-out the antenna to protect the KiwiSDR from being damaged.
Finally, very occasionally, the radios can go down for a software update which often means new features. Often this doesn’t take more than ten or so minutes before it is back online again.
If you’re on a KiwiSDR that is configured for eight channels, only the first two will have the wide-band waterfall feature with the remaining six only having the audio FFT.
The End of an Era for the DXpedition?
I realised that with the great power afforded by WebSDRs in being able to listen from practically anywhere around the world, it seems that our prayers have been answered. Unfortunately, in doing so, it makes struggling to pull a signal out from the noise at home in the name of DX a little less exciting when you can just log-on somewhere and find the signal running S9+20 with absolutely no challenge at all.
The whole concept of a DXpedition in the way of packing bags and running some portable equipment at a different place just doesn’t seem so appealing anymore, if catching signals was the end goal. After all, some of these WebSDRs have exceptionally good antennas that catch really strong signals. While there is an attraction to doing it yourself, sometimes the effort isn’t worth the result.
As a result, I’d have to say that the advent of easy access to remote receivers has very much put a dampener on the whole idea of DXpeditions and even potentially DX reception. But it also opens up a potential loophole for those claiming DX reception under contest situations. Less honest people may be tempted to log onto a WebSDR to try and hear those weak signals better and claim a good exchange despite not having any copy from their equipment from home. I suppose it’s important, given the resources, to use it responsibly and accurately declare how the signals were received to prevent potential ambiguity and avoid making outstanding and unjustified claims of DX reception.
I suppose WebSDRs can also be a fascinating source of information for DXers – many of them do have autorun WSPR receivers constantly providing a data source for those to understand propagation around the clock.
Even with anywhere from 3-8 slots per receiver, there’s no shortage of exciting places where you can catch some radio waves.
In modern suburban city living, the wonder of shortwave/HF radio is under threat of extinction. Luckily, thanks to the generosity of various operators around the world, the internet that connects them and the inexpensive computing power that we now have, it is possible to experience remote reception in a way which well surpasses that of simply remotely controlling a conventional receiver. Software defined radio technology has enabled multiple-access, simultaneous multi-channel decoding with a wide-band spectrum display that changes the radio experience into a more efficient, pleasant and visual experience. With clever optimisation, it is possible to do this in a reasonable bandwidth using relatively inexpensive hardware as demonstrated by the KiwiSDR.
As a result, the operators who provide their SDRs for public access are really providing a wonderful resource which can be used by almost anyone – those who are not fortunate enough to be in a good reception location, those who want to spot-check to see if a transmission is on the air or if it’s just their equipment, those who would like to monitor another channel while their own gear is occupied doing something else, or those who want to see if their signal is “getting out” to the world. There are so many different reasons to use it – but I think the biggest advantage is that it can make getting into the hobby of shortwave listening practically free while providing reception that is often well-optimised compared to what you might be able to conjure up at home.
So I am very much indebted to the operators of WebSDRs/OpenWebRXs/KiwiSDRs. They have bought (and will continue to bring) me many hours of joy chasing signals that I had never thought I would be able to hear. There are a few downsides to them, related to limitations in the internet and the abilities of the equipment, but for the most part, they work well enough that it “feels” like I’m operating my own radio, just that it’s someone else’s half-way around the world. If you take the time to configure your equipment well, the result is actually very usable and not far from what you might experience trying to work with your own local SDR (assuming you have one).
The downside is that the motivation to go on DXpeditions has been somewhat lost, if the sole aim is just to set up an antenna in a hotel room and do some listening. There might also be a temptation for some amateurs in contests to “cheat” and receive the audio via another path while claiming to have made a successful contact, so it is important to be honest and use the facilities responsibly. To that end, there are limitations with some servers on inactivity time and total listening time per IP-address per day to avoid abuse, so don’t take it for granted!
Unfortunately, I’m not really in a position to set up one of my own owing to the reception conditions around me and my internet connection, but if that were to change, I would probably consider putting up a public receiver as I can definitely see the benefit it brings to the community of shortwave listeners, HF DXers and radio amateurs alike. For those that do operate stations open to the public (especially the ones I have used), thank you so much for your generosity! I hope that other hams continue to allow public access to their receivers, although I do completely understand if they might be reluctant to do it or might take it down after a while.
Bonus: Chasing Shortwave Radiogram around the World
Being interested in shortwave and chasing QSL cards in the past led me to receiving more “novel” transmissions. One of the most novel was VOA Radiogram, which used a regular AM transmitter to send digital modes (as hams might do) to disseminate information to listeners using regular shortwave receivers. I spent some time monitoring the programs locally at home, but the signals were very variable at times. After going into winter and losing signal entirely, I stopped following the programs.
Since then, the program is now known as Shortwave Radiogram, still produced by Dr. Kim Andrew Elliott, transmitted out of WRMI Florida, USA and SpaceLine Bulgaria. Recently, they publicised the fact they were running the Tecsun Radios Australia #DecodeToWin reception competition, which gave me a good reason to return to monitoring the transmissions. After all, it’s not often that an Australian company is mentioned on shortwave.
As a result, I now try to receive the program from home, but also from a number of WebSDRs/KiwiSDRs to compare results, tweeting reception reports.
.@SWRadiogram was well received from SpaceLine Bulgaria (1400UTC) via Utwente WebSDR over my LTE connection, since I could hear nothing from Sydney, AU. Looking forward to the images from @TecsunRadios in the coming weeks for their competition! pic.twitter.com/AleJTXK6ll
— Gough Lui (@lui_gough) December 8, 2018
.@SWRadiogram Good signal into the @TecsunRadios SDR on 7730khz from WRMI at 0800UTC. Perfect MFSK64 copy, images surprisingly good compared with earlier 1400UTC reception from SpaceLine. pic.twitter.com/I5BvMiuB0h
— Gough Lui (@lui_gough) December 9, 2018
.@TecsunRadios Couldn't get a good signal in Sydney locally nor on your SDR of @SWRadiogram's 2030UTC 7780kHz (WRMI) broadcast, so I had to use @UTwente's WebSDR – not a bad result with 100% MFSK64 and decent images. US-based SDRs seemed to be noisier. #DecodeToWin pic.twitter.com/yXa8k7QRy6
— Gough Lui (@lui_gough) December 14, 2018
.@SWRadiogram's 1400UTC 9400khz from SpaceLine saw 100% MFSK64 in Sydney, AU, received locally (IC-R75 + ALA1530L) & via UTwente's WebSDR. Includes @TecsunRadios #DecodeToWin promotion. Note: running 2 fldigi instances causes image overwriting issues, moving window crops images. pic.twitter.com/qWrZSNpqWV
— Gough Lui (@lui_gough) December 15, 2018
Challenging conditions for 0800UTC 5850/7730khz @SWRadiogram in Sydney with no decodable signal, but the @TecsunRadios SDR received a fading signal with significant QRN from thunderstorms, missing a few images and corrupting text. Tried, but not much luck with UTwente's WebSDR. pic.twitter.com/n8vLBBXBBR
— Gough Lui (@lui_gough) December 16, 2018
Getting 2030UTC @SWRadiogram broadcast proved challenging. Very weak coming into UTwente's WebSDR, a number of US KiwiSDRs and my local rig in Sydney with only RSID and <10% MFSK decode. Luckily, I graced upon #VK6QS's KiwiSDR which had a decodable signal – grey line propagation! pic.twitter.com/EMa4ufsFr5
— Gough Lui (@lui_gough) December 21, 2018
1400UTC 22/12/18 @SWRadiogram #79 broadcast (SpaceLine) received strongly on @UTwente's WebSDR & with decent quality in Sydney, AU locally with @TecsunRadios #DecodeToWin promo. Parallel decoding shown below, skew in WebSDR due to LTE jitter & playback resampling. pic.twitter.com/4SNIUeXKqP
— Gough Lui (@lui_gough) December 22, 2018
0800UTC 23/12/18 @SWRadiogram #79 (WRMI) received locally & @TecsunRadios Australia KiwiSDR in parallel. Signal in Sydney had passable MFSK64 & noisy/missing images, much clearer via Goulburn. Bonus decode of @BroadSpectrumR as well. #DecodeToWin pic.twitter.com/YOt3ejqZid
— Gough Lui (@lui_gough) December 23, 2018
Final @SWRadiogram for this week on 7780kHz at 2330UTC – the one I usually miss. No signs of the program at home (as expected), but decided to give ArcticSDR a try with exceptionally clean results. Definitely can tell it's a radio now, @TecsunRadios #DecodeToWin promotion! pic.twitter.com/j4LVUQoSlj
— Gough Lui (@lui_gough) December 23, 2018
Today's 2030UTC @SWRadiogram with @TecsunRadios #DecodeToWin. I went on SDRs around the world, the best result was at #VK5KEN in Lewiston, South Australia. It seems the SDR had some ADC overload causing speckly images despite good SNR & intelligible voice. No signal at home :(. pic.twitter.com/tR7tB8RRzR
— Gough Lui (@lui_gough) December 28, 2018
Decided to get 2-for-1, had UTwente's WebSDR record 2030UTC @SWRadiogram. I set FLdigi on decoding the recording – looks like I've been deceived by the weak waterfall signal strength, as SNR was similar (AM-S), less doppler, 100% MFSK64, 2 lost images. @TecsunRadios #DecodeToWin pic.twitter.com/SmMXWmtz6O
— Gough Lui (@lui_gough) December 28, 2018
1400UTC @SWRadiogram (SpaceLine) made decent effort into Sydney, AU ~100% MFSK64, missing 2 imgs. Decoded simultaneously over UTwente's WebSDR in real-time, suffering "wobble" & packet loss. Couldn't get onto @TecsunRadios SDR due usr limits, others w/varying signals #DecodeToWin pic.twitter.com/ss7qxOCwqC
— Gough Lui (@lui_gough) December 29, 2018
A pretty strong signal into @TecsunRadios Australia's SDR from @SWRadiogram for the 0800UTC broadcast with 100% MFSK64 #DecodeToWin & passable images. I only got 15% MFSK32 decode at home w/no images – maybe this 41C heatwave & all those inverter air cons raising the noise floor pic.twitter.com/i7ThAR5KQF
— Gough Lui (@lui_gough) December 30, 2018
As promised, another 2-for-1 decode via recording of the 0800UTC @SWRadiogram including @TecsunRadios #DecodeToWin via #NH6XO's KiwiSDR in Kaneohe, Hawaii USA. Very strong signal, but with coloured stripes in images. pic.twitter.com/EakszklYvg
— Gough Lui (@lui_gough) December 30, 2018
Final @SWRadiogram for the year (2330UTC/7780kHz) received via ArcticSDR in Kingsfjord, Norway. V.good signal w/occasional fade, solid decode but RSID was lost + pkt loss. Another successful @TecsunRadios #DecodeToWin image. More SDR recording decodes to come in around 30 mins. pic.twitter.com/nUTiZHk6cJ
— Gough Lui (@lui_gough) December 30, 2018
Same @SWRadiogram 2330UTC bcast from WRMI, different locations/equipment. Decoded from recordings made over LTE for a 4-for-1 decode of the final broadcast of the year, via #VE3HOA (Ottawa, CA), Zsolt's KiwiSDR (Alicante, Spain) & UTwente's WebSDR (NL). @TecsunRadios #DecodeToWin pic.twitter.com/iivUZPnJQf
— Gough Lui (@lui_gough) December 31, 2018
The 1st @SWRadiogram of 2019 – 2030UTC/7780kHz (WRMI) as RX'd via #VK5KEN's KiwiSDR (Lewiston, SA, AU) as there was no decodable signal at home. Noise Blanker is on to reduce speckles due to ADC overload. @TecsunRadios #DecodeToWin continues! Recording decodes to follow in ~40m. pic.twitter.com/iCEIJzHJZj
— Gough Lui (@lui_gough) January 4, 2019
I hope to keep monitoring when I have the time … so check out my Twitter to see further reports.