WebSDRs are internet connected radios which are made available for anyone with a web browser to tune and listen to broadcast stations, amateur radio, military comms, and other signals. They are in locations around the world and work as well as any alternative you could set up yourself, and often far better. I last reviewed popular WebSDRs in 2022 and will now discuss how they are doing as of summertime, 2024.
Here is a synopsis: existing WebSDR sites continue to upgrade from RTL-SDRs to better RF hardware, improved web interfaces, and more broadband connectivity. New sites have appeared, with some using higher performance equipment from day one. A few continue to lead in performance and features, keeping WebSDRs relevant amid plenty of competing technologies.
WebSDRs consist of a hardware frontend, which filters and amplifies signals, digitizes broad sweeps of spectrum, and passes the data on to the DSP engine. In the DSP engine, a spectrum display is generated and processing is carried out on frequencies tuned by the user.
The visual spectrum data and demodulated signal, tunned by the user, are streamed via websockets to the web browser. The user sees a web page containing radio controls and displays. These are interactive features, generated from a mix of Javascript and HTML. Out of the box, a WebSDR is presented as a series of grey panels, "divs," in webspeak. Each panel contains certain radio controls or display elements. Several sites have replaced the original code in the divs with newer work which presents an appealing, more user friendly interface.
Note the better frequency display, arrangement of controls, and even the waterfall colors presented by the LU6FLZ WebSDR, in Argentina:
The audio stream received in the web browser may be further processed by code within the WebSDR page. In other words, the end user gets not only a web page, but some DSP software for further processing the stream. It runs locally, drawing memory and computing power from the host machine. Therefore, WebSDRs run best on devices with ample CPU capability and plenty of RAM. Examples of locally running DSP are extra noise reduction, CW peak filtering, and the synchronous detector contained in the Northern Utah WebSDR enhancement package.
As stated in earlier versions of this report, site operators are trending toward usage of higher quality RF frontend devices. I see a lot of upgraded RTL-SDR v4 receivers in use, which have stable and accurate clock oscillators, a sensitive upconverter for the lowbands, and better RF filtering. They are inexpensive receivers and can be set up easily.
Airspy and SDRplay comprise the next level of upgrade from RTL-SDR devices. Either brand offers SDRs which are more sensitive, better filtered, and which work in deeper bit depths of twelve to fourteen, rather than the minimalist eight bits of the RTL-SDR. As a listener, you will notice that signals sound cleaner and the tuning is more consistently precise on sites with this better RF hardware.
Looking more closely at frequency accuracy and stability, I note that most operators have their sites tuning accurately, to within a few dozen Hertz, with some down to less than ten. I did a lot of frequency checking while writing the WebSDR Handbook, and was pleased to see operators making the effort to minimize their offsets. The worst I found was a mediumwave receiver which had been misconfiguredamd was off by a whole 4 kHz. Fortunately, the operator eventually fixed that, and my favorite talk radio stations were back on frequency.
Note: If you find your favorite WebSDR to be slightly off frequency, manually offset the tuning slightly up or down until you are on frequency. Some sites have a little daily drift, so you might need to your offset if receiving digital modes. For large and unusual errors, you can sometimes go into the chat section and alert the site operator.
I continue to believe that site operators should do what they can to reach frequency accuracies below 0.5 PPM. KiwiSDRs have built-in clock corrections, tuning with precisions less than one RCH, which is pretty good :-) With other radios, it is smart for operators to set up a master frequency standard in their stations, with at least a GNSS disciplined oscillator if not an eLORAN or Rubidium based time and frequency source. There are even sources intended for NTP servers which could work well as time and frequency references for SDRs. Some WebSDRs are using a precise time and frequency source as a station reference, and their tuning is dead-on.
Two of my favorite WebSDR sites continue to push ahead in WebSDR technology. One is the University of Twente WebSDR (Netherlands), which has been using a wideband A/D converter for years - originally covering zero to 19 MHz, now up to 29.16 MHz. It is well designed, using an amplified whip antenna, mounted on a rooftop. The signals get judicicious amplification, while the digital side uses a clean and steady ADC clock. I checked its frequency accuracy and signal latency and it scored well. See the table below for details. The synchronous AM demodulator is great, although this version has not been picked up by other sites.
More WebSDRs are configuring to receive terrestrial microwaves or tune satellites and distant space probes. IS0GRB and BATC / AMSAT-UK receive signals from the geostationary amateur radio satellite transponder Es'Hail2 (QO-100).
North of Hoogeveen, Netherlands, in Dwingeloo, is the C.A. Muller Radio Astronomy Station. It hosts a WebSDR configured to receive reflected space radar signals, amateur radio moonbounce, and even signals from the Artemis moon rocket - varieties of VHF and UHF weak signals. In this context, weak means "a strength between the cosmic radio background and noise radiated from the Sun. Thanks to this station, we can tune live and recorded radio spectrum of interesting and distant signals.
In 2022, I mentioned the need for standardization in connectivity to the WebSDR software package. It seemed that a more uniform and clear way to pass quadrature signals from SDR hardware (radios) into WebSDR (processing) would open things up for a frictionless growth of internet radio receivers. The situation is improving. Plenty of Airspy and SDRplay radios are running with Linux drivers, feeding signals to WebSDRs. Other hardware is also working. Red Pitaya, FUNcube, and FiFi SDR based sites are online. The KFS WebSDR upgraded its RF front ends to RSP-1 radios, which are capable of 16 bit resolution and a bandwidth of 768 kHz, 4x more wide than the older FiFi SDRs.
A path to broader bandwidth SDRs is to digitally combine the narrow slices of quadrature data from multiple narrowly sampling devices like the RTLSDR, thereby creating virtual broadband spectrums. A practical application could use a KrakenSDR to cover a solid 16 MHz of spectrum. The sampled band doesn't need to be shortwave and longwave. It could just as well be VHF or UHF, or the downconverted output from a satellite dish.
How about a single SDR to cover vast chunks of spectrum for the WebSDR? There is a device currently under test, and it is working very well indeed: the RX-888 Direct Sampling SDR. It can sample at a depth of 16 bits over a bandwidth of 32 MHz. The Northern Utah WebSDR is currently testing the RX-888 in broadband service. It does not run in one single band, like the University of Twente server, but offers eight bands, each about 1536 kHz wide. More bands are available if the operator runs multiple instances of the WebSDR application. I see no reason preventing this from becoming the standard for high bit depth, broad bandwidth sampling.
It is possible to use not only the RX-888, but a growing number of other wideband SDRs to samble the spectrum once, then feed the data to multiple user processes: WSPR skimmers, multichannel voice receivers, and other things. The key element is a mathematical DSP shortcut exploited by the KA9Q-Radio software package. It drastically cuts the computing power required to send I/Q data to multiple users at once.
There has been some work within the WebSDR community to improve noise reduction available to listeners. Thanks to the innovative people operating the Northern Utah WebSDR, we now have an effective set of noise reduction options and another synchronous AM demodulator for enjoying signals on the bands:
Some operators have had problems with spammers and trolls abusing the visitor chatbox feature, so visitors to some sites may find the chatbox missing. There have been WebSDRs popping up from China, and not surprisingly, the chatboxes were disabled. Thus, WebSDRs can be set up to withold features if necessary to control the nature of content visible the sites.
WebSDRs have required and continue to require broadband connectivity at the server and client for stutter-free operation. This is certainly true for the standard client interface; less so for the limited number of sites offering the mobile interface. Good news is that broadband connectivity is becoming more available and cheaper for both operators and users of WebSDRs. In the age of 4G telephony, it is easy to connect from a city street, hiking trail, or home for a pleasant experience listening to signals heard on the other side of the world.
WebSDR Latency & Frequency Measurements (2024)
Method:
Results:
Notes:
Using the standard client interface, typical download bandwidth required is approximately 35 kB/s with a slow waterfall versus 28 kB/s in the blind (no waterfall) mode. Network loading drops considerably using the mobile interface, being about 21 kB/s with the waterfall and 16 kB/s blind.
PhantomSDR is a new type of internet SDR, which is very computationally efficient, massively multiuser, and can work easily with broadband frontend hardware. It is a perfect match for RF hardware such as the RX-888 mk2. Corrently, the fork named PhantomSDR-Plus appears to be in the most active development and offers the most mature interface. This is being discussed as the next flagship WebSDR; I believe there is validity to the speculation.
Currently, the interface is going through minor changes, but at a fast rate. One sure thing, though, is that the RX-888 mk2 passes some clean 16 bit signals, and PhantomSDR uses some nice demodulator code. I really enjoy copying cw on these, and my digimode decoders do well with WSPR, FT8, and the like. Visit these sites to enjoy a first look at what is coming to WebSDRs near you:
From a location northwest of Sao Paolo, Brazil, the Pardinho WebSDR offers a nice interface designed originally by UK radio operator Paul, G8HXT. It brings conveniences such as dual tuners, selectable frequency steps, programmable memories, and the option of watching a waterfall or spectrum histogram display.
The Maasbree WebSDR is located in the eastern Netherlands, close to the border with Germany. It is in a rural location, without much man-made electrical noise. It is set up to be a quiet, sensitive amateur band receiver. It is in the process of converting from a setup with multiple SDR devices as RF frontends to using a single RX-888 (Mk2) receiver. I like the nicely arranged interface, which has the clean, functional look and feel of a classic Ten-Tec or Elecraft rig. Operators are a team led by Loek PE0MJX and Jan PA0SIM.
Northern Utah's RX-888 (Mk2) Test Receiver works as a single source for all bands. It is on an amplified omnidirectional antenna and has a precisely GPS-disciplined clock oscillator. In other words, this receiver is sensitive, stable, and has all of the goodness of the site's DSP enhancement package. Reception on the 22 meter shortwave and 20 meter ham bands is especially good.
I did a listening test, using two of my favorite WebSDRs in the eastern USA, for some shortwave listening on the 31 meter band. I thought to compare the user experience and reception on K3FEF and NA5B servers. The two WebSDRs differ in their presentation and user experience.
At the time I tuned in, WBCQ and WRMI were both on the air with moderately strong and readable signals. What you see in the accompanying images are screenshots of my fun time picking up the Overcomer Ministry. Both servers are using sensitive RF equipment, such that listeners can hear weak signals right down to the atmospheric background noise. Both use adequate filtering, so there are no problems with out of band interference or digital aliasing. Overloading is not a problem on either server. RF-wise, these are professional quality rigs.
From K3FEF comes the minimalist, high performance radio. It uses the stock WebSDR, with its grey and white colors, but just what you need for listening. No chat nor extra tabs with tweakable controls.
A frequency database is in use on the K3FEF WebSDR, which lists stations on many of the frequencies. It included popular listening targets, like WWV, the military's HFGCS network, and popular amateur radio calling frequencies. The database had a lot of broadcasters on other bands, but missed 31 meter frequencies for WBCQ and WRMI.
On the NA5B WebSDR, frequency coverage is similar to the K3FEF server, except it also includes the 25 meter broadcast band. The interface has a custom scheme, with lots of nifty controls and indicators. I enjoy the large frequency display, as it is easy to read on small screens and across the room. There are buttons for instant access to frequencies of the Hurricane Watch Net, which is a pertinent thing for summer and autumn in the northern hemisphere.
The NA5B WebSDR also includes some extra enhancements, such as client side DSP noise reduction, selectable audio channels for the demodulated output, and more options for adjusting the receiver selectivity. The frequency database is more complete, having plenty of stations listed across the 31 meter band.
With some amusement, I note that the chat feature is present on the NA5B WebSDR. At the time of my visit to get my fair share of the Overcomer, the chat section was packed with recent messages about the behavior of hams on 7200 kHz, plus some postings about politics. It is all pretty typical for interactions in 2024.
The bottom line with these two WebSDRs is that they receive very will indeed, getting the maximum performance possible from their RTL-SDR front end devices. Each site has its own style, its own look and feel, as they are run by different people. I listen to them both, and make the selection based on what geographical area I'm listening for. For New York and New England hams, I listen on K3FEF. For Maryland, Virginia, and stations to the south, I go to NA5B. For long haul DX, or Brother Stair, signals sound the same on either server, so I may choose the server with fewer listeners. To have fun baiting radio trolls with a "F*ck Trump" or two, then I'll certainly go to NA5B, as that is the one with a chat panel.
WebSDRs continue to have issues fitting so much display and control space onto the visitors' screens. They are fine on a large, wide desktop screen. I have had to make zoom adjustments to properly fit a WebSDR page when using a smart phone or tablet computer. Switching to the mobile WebSDR pages is not a long term substitute for a smart and responsive web page design.
One solution would be to organize the elements into tabbed panels, as on the G0XBU Jodrell WebSDR. It is not sufficient to set a small set of tabs on the bottom of the page; interface desigers should set up several large tabbed panels below the waterfall, where users may click for changing settings. Put the most commonly used controls and indicators on the main panel, then have another three or four tabs containing other items. In other words, navigate by moving among tabs instead of scrolling a long, cluttered page.
WebSDR sites have evolved moderately over time, with the most obvious improvements being in the user interface operators set up for their visitors. Though not overtly promoted by Pieter-Tjerk de Boer, internal software upgrades have been revealed by features such as dual VFO operation, the synchronous AM detector, easy bandpass filtering, the frequency database, and better spectrum display options.
I have no doubt that the good features appearing among a few WebSDRs will eventually spread to them all. Such is the nature of advancement. Information is like heat. It spreads and doesn't unspread. It is like time, which counts forward and doesn't reverse. Wear shades; the future is bright.
WebSDRs are a lot more responsive in this time of 4g, 5g, Wifi6, and gigabit broadband. Pages can load and run in a couple of seconds, which is pretty good in comparison with starting up an actual hardware radio. Think about it: a person can enter a URL into their web browser to bring up a WebSDR, with the mode and frequency set. Easy and pain - free. Good to go.