WebSDRs are versatile radios which open up the world of shortwave listening and ham radio to anyone with a computer or smart phone connected to the internet. I last reviewed them about three years ago and will now discuss how they are as the year 2022 nears a close.
The short version is this: People running WebSDR sites are using better RF hardware, improved web interfaces, and fat broadband connectivity. A few lead in performance and features, pushing the genre ahead while certain capabilities are lacking in the standard package.
Some Really Nice WebSDR Interfaces
When a shortwave listener visits a WebSDR site, the page which loads in the web browser is a mix of Javascript and HTML - typical code for interactive web content. The waterfall, audio, and radio controls work through a fast, two-way websocket connection with the server. Out of the box, a WebSDR is presented in a series of grey boxes, "divs," in webspeak. Several sites have replaced the basic divs with a much more user friendly interface.
Note the better frequency display, arrangement of controls, and even the waterfall colors presented by the NA5B WebSDR, near Washington, DC:
In addition to better waterfall colors, the larger frequency display is very nice, and stylish with a retro LED font. I would get a big kick out of other sites using a similar configuration, but maybe with some other interesting fonts. Just for fun, I visited the ON5HB Websdr in Heppen, Belgium. After tuning in some CW activity, I opened up the code in my browser and plugged in some other font styles:
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.
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. Not a small set of tabs on the bottom of the page, but large tabbed panels below the waterfall, which users may click into 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.
Higher RF Performance for WebSDRs
We have surely crested the wave of RTLSDR front ends, and sites seem to have mastered the art of getting the most performance out of them. Operators are using a lot of upgraded units with the more precise 1 PPM clocks, using preamplifiers for better sensitivity, while filtering the inputs to avoid front end overload. WebSDRs based on Airspy and SDRplay receivers are superior in multiple ways. They sample more spectrum and at higher bit depths.
Drilling down on frequency accuracy and stability, I found most operators have their sites accurate to within a few dozen Hertz, with some down to less than ten. The worst I found was an RTLSDR based receiver which was about 130 Hz high at 5 MHz. If you find your favorite WebSDR to be slightly off frequency, manually offset the tuning slightly up or down until you are on frequency.
I still 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.
Two of my favorite WebSDR sites are pushing 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 MHz. It is well designed, using an amplified rooftop antenna, judicicious amplification, plus 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, and I hope more WebSDRs incorporate it soon.
Three WebSDRs operating in the VHF/UHF/microwave spectrum are doing interesting works to receive satellites and distant space probes. IS0GRB and BATC / AMSAT-UK receive signals from the geostationary amateur radio satellite transponder Es'Hail2 (QO-100). A little way's 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. Here, weak means "a strength between the cosmic 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 2019, I griped about a 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. Here in 2022, things seem to have improved. Not only are there plenty of Airspy and SDRplay radios running WebSDRs, but other hardware is streaming on the internet. I have seen Red Pitaya and FUNcube based sites, plus a few FiFi SDRs. There are indeed more kinds of SDRs going online, prioritizing better RF performance and bit depth over bandwidth. To see this in action, visit the KFS WebSDR, which upgraded its RF front ends to RSP-1s. They are capable of 16 bit resolution and a bandwidth of 768 kHz (4x more wide than their FiFi SDRs).
We could still see broader bandwidth SDRs if users are willing to try experimental DSP packages which can stitch together the narrow slices quadrature data from multiple devices like the RTLSDR and create a virtual broadband sample. [grin] Who wants to run one or two KrakenSDRs to cover a broad chunk of spectrum? It doesn't even need to be shortwave and longwave. In theory, VHF or UHF would work just as well, as would sampling the output from a microwave front end.
DSP Noise Reduction All Sites Should Implement
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:
- Notch1 is filter formerly known as "Autonotch," a server side process which removes the strongest carrier in the receiver passband.
- Notch2 is a client side process. It runs on the listener's computer and can remove multiple carrriers from the passband. It is a sine wave killer. Enable that thing during a busy CW contest, and it wipes out the various tones. All that remains are uncorrelated things like key clicks, voices, and other complex wave forms.
- Vari-Notch also removes carrier signals, but it is a manually tunable filter.
- CW Peak is a rather sharp bandpass filter to improve copy of CW signals affected by noise or interference. It is narrow indeed; the ref tone is used to create a note which should be zeroed in on the desired signal.
- SAM-U and SAM-L are mode selectors for synchronous AM using the upper or lower sideband. The DSP synchronizes a local virtual carrier in phase with the incoming signal's carrier, then demodulates the signal. Synchronous detectors have fidelity superior to conventional envelope detection - especially when there is fading or interference. Set the passband limits to include the carrier and the chosen AM sideband. There is an indicator for the lock condition and how much carrier offet exists.
- High Boost is used to increase frequencies broadly above about 1500 Hz, to brighten those highs lost due to the DSP filtering. It is also a nice feature to compensate for a reduced ability to hear highs which comes with age.
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.
More WebSDRs on Better Broadband
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
Method:
- Do a screen capture while monitoring WWV, CHU, or MSF.
- Count frames from start of the minute on the computer clock.
- Count frames frames (30 per second) until the audio signal.
- Measure freq offset with sync detector if available.
- If no sync detector, offset by 1000 Hz and match tone with KiwiSDR.
Results:
- Typical WebSDR: 530 to 630 ms; freq accuracy +/- 130 Hz
- Utwente: 800 ms latency, freq +/- 1 Hz
- K3FEF: 567 ms, freq -30 Hz
- KFS WebSDR: 2030 ms, freq -32 Hz
- Northern Utah #5: 466 ms; freq -5 Hz
Notes:
- Typical KiwiSDR: 1233 to 4000 ms; freq dead-on +/1 < 1 Hz
- Findings consistent across multiple sites.
- Each WebSDR band performs independently of other bands.
- More latency if broadband is limited.
- More latency if using more buffering.
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.
Conclusion
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.
© 2015 - 2024 Skywavelinux.com, All Rights Reserved.
Contact, Privacy Policy and Affiliate Disclosure, XML Sitemap.
This website is reader-supported. As an Amazon affiliate, I earn from qualifying purchases.