Future WebSDR servers - Northern Utah WebSDR

Northern Utah WebSDR

KD7EFG

Newer WebSDR Servers:

If, what and when?

Testing of newer WebSDR software

We are looking into the possibility of migrating to a platform other than the PA3FWM WebSDR currently in use. While there are several options out there such as "Phantom WebSDR" and its follow-on project, "NovaSDR" - and UberSDR. This has the advantage of using simpler hardware (and RX-888 or similar) to receive HF bands, presenting the user with a single interface for the entire HF spectrum - much like the KiwiSDR or even the University of Twente WebSDR, also operated by PA3FWM.

NovaSDR

More recently, the development of NovaSDR has been stymied by fragmentation of effort: A number of groups seem to be working independently and rather than collaborating efficiently it appears, from the outside, to be duplication of effort along with a bit of misplaced idealism on what the end goal should be. To be absolutely clear, we wish the various developers well and we are hopeful that those who are both competent programmers and are able to sight a clear path to a better-defined goal will prevail.
If you peruse the Northern Utah WebSDR's web sites you'll note that we do cover all of HF on some receivers (KiwiSDRs) as well as a number of the shortwave broadcast bands. Further investigation will reveal that these resources get relatively little use compared to the amateur band receivers. Between these observations as well as results of surveys and correspondence with users indicate that most users do NOT really care about frequencies other than amateur bands for the most part - and that there's something to be said about simplicity of operation when one can simply select an individual amateur band rather than have to pick it out from a 30 MHz wide display..

We expect that NovaSDR, UberSDR - and possibly others - will eventually mature to the point where they are both stable and suitable for large numbers of users and be optimized for both processor and network bandwidth utilization - but that day is not yet today.

Comments related to testing with NovaSDR (as of 18 February, 2026):

In our testing of NovaSDR, there are a few comments/concerns that will need to be addressed before we would consider using it as a wholesale replacement of the existing PA3FWM WebSDRs, in no particular order:

No obvious time-out mechanism. There needs to be a time-out mechanism to prevent "leeches" - that is, users that camp for 24/7 on the server: If they don't make some sort of change (tune, change modes, etc.) in the space of a few hours, we can presume that they aren't actually listening. As we have limited bandwidth available to us, we would like to minimize such usage.
Some sort of audio distortion. It's hard to put a finger on it, but the audio is somewhat "crunchy." This sounds like some sort of clipping - either in the codec or, perhaps, in the AGC action. This seems to be present both in the ADPCM and the FLAC codecs, and at 8 and 16 ksps: Side-by-side comparison with the same signals on the PA3FWM WebSDR - which also uses ADPCM - show the latter to lack this distortion.
Higher/"Creeping" latency. The latency of the NovaSDR seems to be significantly greater than that of the PA3FWM WebSDR - but it also appears to have the tendency to "stretch" to several seconds - a phenomenon not reflected in the debug stats on the user's UI: A delay of just a second makes it unpleasent to use in the context of a net, either as net control or as one of the participants.

A few configuration changes were made (different codes/rates) but this seemed to not have any obvious effect.

There is currently no means of configurating/changing the waterfall update rate. Slowing the the watefall update - either by configuration or when the number of users exceeds a threshold - would be very useful for bandwidth management.
There is no means of tine-tuning the receiver's operating frequency. This is not the user-facing tuning, but rather the inability to compensate for the receiver hardware itself being off-frequency: If the receiver is, say, 100 Hz off at 14 MHz, there appears to be no means of fixing this offset in the configuration.
There is no means of S-meter compensation across wide frequency ranges. If one plans to use a wideband, direct-sampling receiver such as the RX-888, they better be prepared to apply "pre-emphasis" (a.k.a. "shelving filter") to maximize dynamic range across the HF spectrum - and if you are running this or similar receive hardware, the overall performance of your system is surely suffering: You can read about this issue HERE.

This sort of compensation means that an S-meter calibration (e.g. applying a known signal level to the system antenna port - on the "antenna" side of any such filtering) will be valid only at that particular frequency.
What is needed is the ability to input a number of different frequency/S-meter calibration entries in a table to allow - via linear interpolation between these entries - correct S-meter readings despite differences in gain and filtering across the received spectrum.

It would be nice for the Synchronous AM detector to show the frequency of the recovered carrier. In many receivers with synchronous AM detection (e.g. KiwiSDR) it will display the apparent frequency of the carrier.

For example: If the front-end receiver is GPS-locked, this could indicate to the user the absolute frequency of the signal in question.
A "lock" status of the SAM detector would also be very nice.

A more graphical S-meter. An "S-unit" scale would mean more to different users.
The ability to graph the S-meter readings. The KiwiSDR and PA3FWM WebSDRs have the provisions to graph the signal strength over time - useful for antenna and other signal measurements.
Amateur band pre-sets. In speaking with those first using the KiwiSDR or similar (like the NovaSDR) being immediately presented with all of the HF spectrum (as one might be using an RX-888) is a bit daunting: A pre-set band selection where the zoom and mode is preset when the user clicks on a button would be handy.
It's not as stable. Reports from others who have been testing it have reported that it's a bit of a fight to get it going - and it requires a bit of babysitting to to keep it working properly. In contrast, the PA3FWM WebSDR is extremely stable and robust.

It's a bandwidth hog. Whereas each, individual user of the PA3FWM WebSDR need consume only 40-50kbps of bandwidth for audio, waterfall and control, the typical configuration of the UberSDR results in each user requiring somewhere in the range of 200-500 kbps. NovaSDR can be configured such that only 60-90kbps is required per-user, which is getting to the point of being manageable from our standpoint.

To support just 200 users - which is a common load for the Northern Utah WebSDR - would require approximately 100 megabits of Internet bandwidth, and that is simply not available at the remote Northern Utah WebSDR receive site at this time. The reason for this seems to be (unnecessarily?) high audio encoding rates and an inefficient means of conveying the waterfall display as currently implemented in Phantom WebSDR and UberSDR.
Requiring nearly a half megabit of also strains the connectivity of many individual users - particularly those who may have tenuous (e.g. mobile devices and satellite connections, poor connectivity overall, etc.) Internet connections and/or "metered" ("pay per gigabyte") data plans.

Potentially marginal performance of a single, wide-band receiver coving all of HF.

Simply connecting a single, wideband receiver - like a KiwiSDR, RX-888, Web-888, Red Pitaya or similar to an antenna will likely result in mediocre performance - particularly if this system is located in an area with a very low noise floor - the result being that performance of the receive system, particularly on the upper HF amateur bands, will be rather poor compared to a typical amateur receiver in terms of sensitivity and the ability to handle large signal levels.
This issue is solvable - and articles on doing this (which may well involve constructing specialized hardware that isn't available commercially) may be found in the "Technical" pages of the Northern Utah WebSDR and other places - but the need and means of doing this may not be known to many who attempt to use this hardware.

Creeping buffering. For QSO use, a delay of somewhere between 500-1000 milliseconds is the maximum tolerable and (at least some versions) of NovaSDR had wildly variable delays - sometimes well to the seconds. This may have been fixed since, but it, by itself, was definitely a show-stopper.

We are aware that the NovaSDR - and others - are currently being developed and fully anticipate refinements as time goes on.

* * *

UberSDR

A more stable alternative would appear to be UberSDR. The main concern that we have about it is that some of its core aspects are obfuscated - notably the fact that it runs behind a proxy. For the purposes of "simple to install and configure", this makes sense, but in our environment at the Northern Utah WebSDR where we must carefully watch not only the amount of traffic that is flowing, but also know exactly what sort of traffic that is, we are understandably wary. We are watching the development of this software and hope to have a better understanding of it in the future.

* * *

We continue to be on the lookout for a worthy replacement of the original PA3FWM WebSDR software and if you can suggest something that was not mentioned above, please let us know via the contact information on the About page.

Questions? Use the contact info on the About page to let us know.

Additional information:

For general information about this WebSDR system - including contact info - go to the about page (link).

For technical information about this WebSDR system, go to the technical info page (link).

For a list of questions and answers, visit the FAQ page (link).

For more information about the WebSDR project in general - including information about other WebSDR servers worldwide and additional technical information - go to http://www.websdr.org

Back to the Northern Utah WebSDR landing page