Incremental WebSDR Improvements on Different Servers
Internet accessible WebSDR nodes, the brainchild of , Pieter-Tjerk de Boer PA3FWM, have been around for a solid decade, and are especially familiar to two types users: people specifically interested in software defined radio and others who are primarily interested in general coverage monitoring of signals as received in different geographic locations. Judging by site activity, most users seem interested in listening to amateur radio and shortwave broadcast content. Despite the arrival of KiwiSDR, Airspy, and other internet accessible SDRs, the WebSDR remains popular, having retained, improved, or introduced features popular with the user community. Below is a closer look at the current state of WebSDRs and how they have improved over time.
Front-End Hardware for WebSDRs
Major performance factors depend on hardware connected to the receiver site's antenna. A sampling of WebSDR sites reveals several sites with fantastic reception, more sites where reception is "pretty good", and just a few which suffer from high noise or generally low signal levels. Even the RTL-SDR based sites perform well for general coverage listening. As to frequency accuracy and stability, most operators have their sites accurate to within several Hz. That is fine for AM or SSB and users; they can usually correct the tuning by adding or subtracting a small offset to the displayed frequency. Expect tuning errors to decrease more when operators integrate satellite navigation (GNSS), eLORAN, or other tools for precision system timing.
There are three WebSDR sites which lead in front end 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. Other sites have yet to employ a similar wideband front end. Two other sites of note are using GNSS locked oscillators to precisely tune the QO-100 Es'Hail-2 satellite amateur radio downlink at 10.490 GHz. These sites are operated by IS0GRB and BATC / AMSAT-UK.
A WebSDR node accepts a data stream from the RF equipment. This stream consists of quadrature (I/Q) signals from a soundcard or radio A/D converter designed to emulate a soundcard. Thus, a Softrock receiver (quadrature detector and soundcard) works for a fairly narrow range of RF spectrum. RTL-SDR devices are also popular, as they can provide a 2 MHz RF bandwidth. Higher performing receivers such as the FunCubeDongle, Afedri, Airspy, and SDRPlay also work with the WebSDR software.
One thing which has not evolved is compatibility with devices using SoapySDR or Gr-OsmoSDR drivers. That would considerably open up the WebSDR to more devices. It hasn't happened yet, but it needs to happen. Another unseen evolution is general adoption of wideband ADCs. Inexpensive ADCs are available (e.g. AD9265) which can run at sample rates well above 100 MHz, with slightly more pricey ones (e.g. ADS61B29) operating up to 250 MSPS. Standardization is the main barrier preventing adoption of more wideband ADCs on WebSDRs, since it is Pieter-Tjerk de Boer who writes the code to get data from the front end device into the WebSDR software. Ahem, open sourced collaborative development could speed up the development of WebSDR...
WebSDR Internal Processing
Site operators can run WebSDR software on 32 or 64 bit Intel / AMD CPUs and Raspberry Pi single board machines. Debian (Raspbian) Linux is the preferred operating system, though there is no reason to prevent running a WebSDR on Arch Linux or Slackware.
To speculate a bit, let us assume that WebSDR node software has only modestly increased in resource requirements over the last decade. CPU and RAM capability have gone up six to eight times per unit price. Conversely, for a system of similar capability, price has decreased. Without tracking statistics on sites, it appears that operators are running servers on more capable computers. They are accommodating more users, while the sites are more certainly and responsive. For example, the University of Twente server renders, streams, and responds to changes quite quickly - even for two or three hundred simultaneous listeners. With efficient software, sites don\'t have to run large server or desktop machines. To repeat, single board computers (Raspberry Pi3 / Pi4, BeagleBone, Tinker Board) can function as WebSDR nodes and are small, inexpensive, with light power consumption.
Some WebSDR parameters may be tweaked by the site operator, such as default filter bandwidths for each mode, dual VFO operation, frequency memories and database, or the degree of audio data compression use. It is reasonable to expect operators to balance DSP-intensive features against the available computing power and latency brought by the features. For example, setting extremely steep and sharp filter passbands is possible, but increases latency to the point where the time delay could be excessive. High amounts of audio data compression will reduce network bandwidth, but harm sound quality to the point of driving listeners away.
Two features that are currently not available, but could be useful for experimenters or users with certain special interests are: 1) a more configurable waterfall palette, 2) a basic I/Q signal mode, and 3) time encoded with signal data. The former feature would help people looking for especially weak signals or certain features in the spectrum of strong signals. An I/Q mode would be useful for users with other applications who want to do experimental DSP or apply special demodulators on signals picked up by WebSDRs. Lastly, including an accurate time with the data stream would enable time-of-arrival analysis. If a user takes simultaneous data from multiple WebSDRs, it is possible to geolocate the radio signals.
The WebSDR User Interface
Long running WebSDR sites have changed their interfaces slightly, and in different ways over time. They initially looked less like a radio and more like test equipment written by a coder: a collection of different panels (in html div elements), each with specific functions: mode, band, frequency, waterfall controls, etc. Their underlying functionality was based on Javascript at first; now they default to HTML5 and run in any browser. N4HCI (Virginia) currently presents an example of the default WebSDR page layout. Note that each panel is similar in style: white on grey backgrounds, black font, with the title in bold, regular text, and buttons in slightly smaller font. Another example of the default WebSDR layout is K3FEF WebSDR (Pennsylvania). To begin moving away from the default layout, one can retain the same functions but apply different styles and colors, as shown by the Pardinho WebSDR (Brasil). Notice that the Pardinho site offers dual VFOs, selectable filter bandwidths and an indicator of the currently selected reception mode.
The University of Twente WebSDR (Netherlands), with its fabulous wideband ADC, offers an upgraded layout and new functions: two VFOs, an AM synchronous detector, and a simple buttons to widen or narrow the filter bandpass. The chatbox, logbook, memories, and other functions are in a tabbed panel. The synchronous detector is actually more than a button - there's specific demodulator code in the WebSDR supporting it - and it works wonderfully.
Looking at the NA5B WebSDR (Washington, DC) has different buttons controlling bandwidth, some for specific bandwidths, one for widening, and another for narrowing the bandpass. It also overlays the bandpass on the waterfall, nicely showing how the bandpass relates to the actual signal received by the radio. Again, these new buttons reveal how DSP parameters can be changed on the fly within a WebSDR.
Some sites actually use a page layout presenting the WebSDR similarly to a conventional radio, with a large frequency display, with signal modes and filters arranged in a manner familiar to users of conventional radios. See WildcatSDR (Kentucky) and SV1RVL (Greece).
Wouldn\'t it be great to see some of these features presented as standard on all new or updated WebSDRs? Dual VFOs, the AM sync detector, filter passbands overlaid on the waterfall, a common frequency database - these would be great to see as features available right out of the box. Of course, adapting the Wildcat or SV1RL radios would require some template changes, but it would make the sites even better.
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.
WebSDR Connectivity
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 sonnectivity 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.
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 specified by the principal software developer, internal software upgrades have been revealed by features such as dual VFO operation, the synchronous AM detector, click-to-use bandpass filtering, the frequency database, and better spectrum display options.
Improvements in network bandwidth, server hardware, and client hardware have made WebSDRs more responsive. Pages do not render and run instantly, but can indeed be up and running in a couple of seconds, which is pretty good in comparison with the experience of starting up an actual hardware radio. Think about it: one can enter a URL into his web browser to bring up a WebSDR in the desired mode and on the frequency. Easy and pain - free.
It would be helpful for the WebSDR package to go out to site operators with something better than the current default template. For example:
- Set up a larger frequency display.
- Include a panel of buttons for reception modes and associated wide / narrow bandpass filters.
- Put user configurable options in a tabbed panel.
- Add multiple schemes for the waterfall pallette.
- Include the Synchronous AM demodulator.
- Include an I/Q output to feed special modes / experimentation by end users.
Though it seems that KiwiSDRs are taking over the world of internet distributed software defined radio, a closer look shows that classic WebSDRs are still out there and still evolving to meet the needs of people who go online to tune the spectrum for interesting signals from longwave through microwave bands. WebSDRs are very good for certain applications, such as monitoring broadcast, utility, or broadcast signals. With continued refinement, WebSDRs can be useful for more specialized and demanding uses. It has been interesting to observe the different flavors of WebSDR operating around the world. The future will be interesting too, as technology develops and both Pieter-Tjerk de Boer and site operators find more ways to tweak and improve their WebSDRs.
© 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.