FAQ - Northern Utah WebSDR

Northern Utah WebSDR
Frequently-asked questions

Here are a few questions that have/may come up, and some answers. They may not be good answers, but they are answers nonetheless. If you have a question about the WebSDR, check out the Q&A below to see if it's already been answered. Below are just some of the topic headings - click on one to jump to it - or just peruse the entire page.

- Supporting the Northern Utah WebSDR	- Weird noises and other things on the bands	- Features of the WebSDR
- Computer and usability issues	- "Why is it this way?"	- "Why don't you support (put a mode or feature here)?"
- System quirks and a few random things	- KiwiSDRs at this site	- "What's with the 10 meter CW beacon?"
- "Why can't I hear audio from the WebSDR?"	- "Why doesn't "CatSync" work properly?"	- "How do I stop the echo when I transmit?"
- "Why don't you guys run OpenWebRX?"	- "Why can't I use 'Pocket TX/RX' with the Utah SDR?"	- "What are the things marked as "HFT Triggers?"

Supporting the Northern Utah WebSDR:

"I've found this WebSDR system to be very useful for my HF operating - how can I support it?"

You can find out how to donate $$$ to help keep this WebSDR system online by going here : Any amount is appreciated - large or small.

"If I donate something, can I get a tax write-off?"

Maybe. The Northern Utah WebSDR is an IRS 501c(3) non-profit organization (as the "Utah SDR Group") and you may be eligible for some sort of write-off with your donation. To find out if you are eligible for such a thing, please consult YOUR tax consultant as we are not tax professionals and could not possibly know your circumstances. More information on donating to support the Northern Utah WebSDR may be found by going here.

"Why are you doing this, and who is paying the bills?"

The reasons for having WebSDR systems are stated on the "About" page. In short, to provide a service to the amateur radio community and anyone else who is interested in the HF spectrum. As a by-product of the operation of the Northern Utah WebSDR, information about propagation and the ionosphere is also gathered is/has been used for academic research, but if you are interested in such data yourself, using the contact information on the "About" page.
Again, You can help us pay the bills: If you can, please donate $$$ to help keep this WebSDR system online by going here : Any amount is appreciated - large or small.

Weird noises and other things on the bands:

"What's with the 10 meter CW beacon?"

On June 25, 2020, a CW telemetry beacon was added to the site, transmitting on approximately 28.925 MHz, +/- 1 kHz. This beacon's antenna is (literally) just a few inches of wire - just enough to get from the equipment rack, into the receive antennas - not nearly enough for anyone more than a few hundred feet away from the receive site to hear it. As such, it falls under FCC part 15 meaning that it does not need a license or "official" callsign of its own which it why it signs "UTAHSDR".

Note: This beacon was on 28.570 MHz until 7 May, 2022 when it was QSYed to reduce the probability of interfering with normal 10 meter activity.

This device also has a web server, not accessible outside the local network, that allows these parameters to be conveyed via a web page. This information is used to allow logging of the measure conditions and the temperature readings will be used to slightly adjust the local oscillator frequency of some of the receivers to compensate for temperature-induced drift. For more information about this device, visit the KA7OEI Blogspot entry about it.
This beacon telemeters the following information:

Indoor temperature. The current temperature - in Fahrenheit - is followed by the recorded minimum and maximum. For outside weather conditions please follow the link in the upper-left corner of the WebSDR pages themselves. The min/max values are reset at local midnight.
Indoor humidity. The current relative humidity is followed by the recorded minimum and maximum. The min/max values are reset at local midnight.
Line voltage. The current mains voltage is followed by the recorded minimum and maximum. The voltage is across only one phase, so it reads around 120 volts rather than the full 240 volts. The min/max values are reset at local midnight.
Low voltage count. The parameter "LCT" is followed by a number indicating the number of times that the mains voltage was recorded as being below 100 volts. The value is reset at local midnight.
High voltage count. The parameter "HCT" is followed by a number indicating the number of times that the mains voltage was recorded as being above 135 volts. The value is reset at local midnight.
Power failure duration and time. The parameter "PF DUR" is followed by a number indicating the duration of the most recent power failure (mains <100 volts) and another parameter indicating how many seconds ago it occurred. Only the most recent mains failure is recorded in this manner. The value is reset at local midnight.
If the WiFi is not connected for some reason there will be an error message that says "WIFI NC" at the end of the telemetry. This message is omitted entirely if the connection is good.

Hum on CW note: It is possible that you may hear a bit of AC/mains hum modulated on the CW signal - but this is not really being transmitted. What is likely happening is a bit of "space modulation" in the local environment causing a slight amount of amplitude modulation at the mains frequency: Listening on a different receiver/antenna combination may reveal that this hum is absent - or at least different in amplitude.

Figure 1:
Left: What the 40 meter waterfall on the WebSDR can look like when there are severe thunderstorms about, taken on 22 August, 2018 at about 1500MDT. The light, horizontal streaks are loud static crashes - and since they are broadband, they occupy the entire band at the same time!
Right: A real-time lightning map (blitzortung.org) taken at the same time of the western U.S. showing the very high lightning activity within normal "skip" range of the daytime 40 meter band.
The left-hand picture shows only one obvious signal and two other weaker ones. Why was the band so devoid of activity? Would you want to be on the air with weather (and the band) behaving like this? (Do you really have to ask?)
**Click on either picture for a larger version.**

"I'm hearing a lot of static crashes on the lower bands (160/80/75/40) that make it hard to hear things. What the deal?"

When it is spring/summer/fall in the northern hemisphere, there is a greater likelihood of thunderstorms - and lightning can cause very loud static crashes. During the daytime, these bands are generally "shorter" - that is, useful to only a few hundred miles - so more distant thunderstorms may not be audible. At night, the scene is different: Not only are these bands propagating over greater distances, but in many locations heavy thunderstorms tend to occur in the evening, not only allowing static crashes to be propagated over a wider geographical area, but there are more of them!
If you are interested in current thunderstorm activity across North America, I would suggest that you visit the Blitzortung web page (snapshot in Figure 1) showing "live" thunderstorm activity. This page represents data from (typically) volunteer weather observers. There are many map options on this page allowing you to check on thunderstorm activity across most of the world.

"What are those light, horizontal bands that appear across whole waterfall?" (related to the question above - also see Figure 1.)

Those are most likely static crashes - and that's what distant lightning, propagated on HF like other signals - looks like and because it is a burst of white noise it covers a wide range of frequencies at once. The "brightness" of the crash on the waterfall is indicative if its relative signal strength where "white" means that it is pretty strong! Because it can be a strong, broadband signal not even fancy DSP can do a lot about it, but this WebSDR has a noise blanker that helps to clip the level of this noise and allow a faster AGC recovery than would otherwise occur. Propagated lightning static tends to be worse on the lower bands (160, 80/75, 40) and is notably weaker on the higher bands.

During the winter there are fewer thunderstorms across North America and this is less common, but in the summer there are times where the bands are constantly barraged with this type of noise.

"What is that "buz-buz-buz-buz" that I keep hearing every few minutes?"

We have no idea - it may be some sort of ocean wave or ionospheric profiler. It seems to be audible on some band nearly everywhere in the world.

"Speaking of "buz-buz", what's the deal with the beehive in the logo?"

Utah is known as the "Beehive State", the idea being that the beehive is a symbol of industry as used in the "highly productive and busy" sense. A suspiciously similar-looking beehive - complete with bees flying about and sego lillies - may be seen on the great seal of the state of Utah..
Somewhat amusingly, it is illegal in the state of Utah to use a skep - that traditional-looking dome-shaped beehive. The reason for this seems to be because these structures originally did not have "movable frames to all the hive’s parts so that access to the hive can be had without difficulty" and that harvesting honey from them often required destruction of the hive and/or the need to kill many bees.
The antenna? Bees have not passed any HOA restrictions on antennas as they are naturally equipped with their own antennae and doing so would not be in their own interest! Maybe they are causing the "buz-buz-buz-buz"!

"What are those "sweeping things" that I see between 4.5 and 6.5 MHz (and maybe other places) - especially at night?"

Those are coastal wave profile radars used to analyze the ocean swells. A Wikipedia article on these types of systems - and links to more information - may be found here: https://en.wikipedia.org/wiki/Wave_radar

"What are the things marked as "HFT Triggers?"

The "High Frequency" in "High Frequency Trading" does not refer to the fact that this occurs on HF (which it does!) but arbitrage that occurs with microsecond timing to take advantage of very slight differences in pricing over time - and a lot of small differences add up over time. As conventional networks are slow (light travels at about 30% of its normal speed through glass fibers, and network delays can add up) the fastest-possible way to convey information across the globe is, in fact, HF.
These signals - which are dead carriers with "clicks" that occur at seemingly random times - are believed to be triggers for a priori transactions. These "clicks" are, in fact, multiple events on the millisecond scale in which the power of the normally idle carrier increases by 15-20 dB, at least. As these signals are not data as such, they represent the fastest, most minimal means of conveying that an action is to occur that is possible.
Because these are very brief pulses, they have a rather wide bandwidth - 10s of kHz. Also, because they can be some of the stronger signals in the sampling passband of many radios, these sudden, high-level pulses can, in certain cases, cause brief disruption over a much wider receive bandwidth due to overloading of the analog-to-digital converter in the say that an impulse from lightning static might.

"I'm sitting here listening and I hear a "twit" sound across the frequency as if someone just tuned their transmitter's dial up the band quickly while keyed down. Who's doing that?"

These are ionosondes - a sort of chirp radar that is used to analyze the composition of the ionosphere. These sweeping transmitters - along with synchronized receivers - function as radars that can determine the height and density of the ionosphere, and with similar devices at other frequencies (you can find them all over the HF spectrum) the quality of the refractive properties and the MUF (Maximum Usable Frequency) can be dynamically tracked. By sweeping the frequency, the delay in the time that it takes the signal to go up and back down from the ionosphere means that the return signal will be at a slightly different frequency than that of the transmitter which will have moved frequency in that time, so the difference in frequency between the transmitted frequency and the return is indicative of the total path length.
Here are a few web sites that have information about/from those systems:

An article about chirpsounders - https://www.hfunderground.com/wiki/index.php/Ionosonde
Some (near) real-time data from those systems - https://www.ngdc.noaa.gov/stp/iono/grams.html
Information about the "Digisonde", a commercially-available ionospheric sounder - http://www.digisonde.com/index.html

Figure 2:
This is an example of IMD showing up on a "clean" 40 meter signal. The signal is peaking about 10dB over S-9 with a little bit of QSB. The noise floor is about S-4 meaning that the peaks of this signal are about 40dB above the noise. Just to the right of the signal (between 7250 and 7251) one can see some energy that is related to voice peaks. Because the waterfall can represent a wide range of signal amplitudes it is quite typical for a transmitter with good IMD specs to appear to have some splatter - but careful comparison of the waterfall's color and brightness will reveal that in this particular case, that IMD is really quite weak.
There are two other signals in the waterfall above: A weak LSB signal at approximately 7253.5 kHz and a carrier with modulation on either side at 7245 that is likely China Radio International.
Several weak horizontal streaks from distant lightning storms can also be seen.
**Click on the picture for a larger version.**

"I notice on the waterfall that a lot of stations seem to be 'wide', so I get on and tell them that - but they say that they aren't overdriving and/or using an amp. What's the deal?"

First of all, are you a member of the "waterfall police"? If so, don't you have something better to do?
Anyway, while it's sometimes the case that someone will overdrive their rig (quite hard to do these days) or overdrive their amplifier (not as difficult to do) it's actually quite rare that one sees a signal that is indicative gross overdriving of something in their RF transmit chain. With the waterfall, what you can see is something that has been going on for decades, but was either misdiagnosed or went unnoticed and that is the intermodulation distortion (IMD) on the transmitted signal.
Conventionally, the measured IMD of a typical amateur transmitter are in the range of -28 to -35dBc (roughly 0.1% of the total transmitted power) - that is, it will "naturally" produce low-level splatter that is 5-6 S-units lower than the peak signal: The use of an amplifier will naturally make the IMD higher because the contribution of the rig is added to that of the amplifier itself. What this means is that if there is a background noise of S-4, if the signal that you are receiving is at least 10-20dB over S-9 that these IMD products will become visible on the waterfall and can be heard as a bit of splatter.
In short: Just because it can appear on the waterfall display, do not automatically assume that there is something wrong with the transmitting station. Some newer radios have some means of reducing IMD, such as digital processing and/or a type of power amplifier that is designed to reduce IMD which can reduce the IMD to somewhere in the -40 to -50 range. Figure 2 shows a typical example of a "pretty clean" signal appearing to have splatter. In truth, all transmitters have a degree of splatter, but in the example shown its spectral purity is well within the accepted limits.

Features of the WebSDR:

"What is that "= kHz" button in the tuning bar used for?"

In the "old days" with analog VFOs hams just plopped down anywhere on HF "close" to the intended frequency - which made sense since few dials were accurate to much better than 1 kHz.
These days, where nearly everyone has a digitally-synthesized transceiver that is actually both stable and accurate in terms of frequency, most hams - at least in the U.S. - seem to have taken to setting their frequency dial to "something.00" kHz (or, occasionally, "something.50"). Why? It could be OCD, or it could just be that it's easier to remember a "whole kHz" frequency that ends with zeros.
Because of this tendency the "= kHz" button to "snap" the tuning to the nearest even kHz ("something.50" will round UP) because moststations will be there, anyway - and it prevents you from needing to click your mouse a bunch of times to dial it in. If you are using SSB and tuning in a station that is at "something.50" kHz you can still use "= kHz" - just hit the "- -" or "+ +" key and you will be stepped down or up 0.5 kHz, which is still fewer steps than clicking the button a bunch of times or directly typing in the frequency. Because it is so useful, you will now find this same feature on many other WebSDR systems, albeit with different names.

"How do I use the 'DSP Noise reduction' feature - all it seems to do is make the background noise sound hollow/watery?

The DSP noise reduction on the Northern Utah WebSDR - just like the noise reduction features that you find on modern radios - depends on the background noise to be random (e.g. "hiss") but the signals that you want to hear (voice, CW) not being random.

DSP Noise Reduction works by "locking on" to signals within the receiver passband that are not random and filtering out everything else. What this means is that in the presence of only noise it will "hunt" around, causing the "swishing" sound you hear - but this noise will (largely) disappear when someone is talking.

When a suitable strong signal is present, the DSP noise reduction will quickly adapt itself to the spectral components of the voice and filter out everything else - and the degree that it does this is dependent on the "strength" setting. For the "Low" setting, the effect is definite - but modest with relatively few artifacts while the effects of the "Strong" setting can be quite intense.
Like all of these noise reduction techniques, if the voice is too far into the noise, it can't help because there is simply too little energy to "lock" onto - and the noise reduction may reduce intelligibility under some situations.
The noise reduction will NOT reduce effects of QRM from nearby signals (splatter, another station too close) as they aren't random noise.
Please note:

The DSP Noise Reduction features was added in March, 2020, having been written by the folks at the Northern Utah WebSDR with the knowledge of the WebSDR software's author. At the time of this writing, only a few other WebSDR systems have contacted us and added these features. If you operate a WebSDR and are interested in added these features you may contact us using the information onthe about page.

"Why doesn't the DSP noise reduction work on my phone/tablet/old computer very well?"

The noise reduction - and the other new features (Notch2, High Boost) run on the client side - that is your computer - rather than the WebSDR server. Unfortunately, old, slower devices with limited processing resources may not be able to cope with the added CPU load of these features and may have problems (choppy audio) when turned on.
This problem seems to be more severe when running the Chrome browser - it's suggested that you try the Firefox browser if you are having problems, but there's no guarantee that this will work.

"Why is there a 'Notch1' and a 'Notch2' setting?"

The "Notch1" setting simply the "Autonotch" setting renamed and it works at the server side. As such it is located where the RF gets converted to an audio stream and it is capable of removing the offending carrier before it is sent out to your computer. By doing so it can prevent very strong signals (carriers of shortwave broadcast signals, "tuner-uppers") from causing the S-meter to deflect and the AGC act which, for very strong signals, can effectively mute the audio. While this notch filter works for very strong signals, it may not work as well for weak/moderate signals as it can "hunt" and inadvertently lock onto other signals within the passband such as modulation - the effect being that the tone to be removed appears and disappears. This filter works only on the single, strongest tone.
The "Notch2" setting operates on the client side (your computer) and it acts only on the audio coming from the WebSDR server and it is capable of removing multiple tones of similar amplitude. Because of this, it won't help with audio de-sense from very strong signals (use "Notch1" for that!) but it can be more effective for weaker/moderate carriers.
Both of these notch filters can degrade speech somewhat as they will "lock on" to tones normal in human speech, causing what sounds like distortion - but this effect is most notable if the notch is not already "busy" removing a tone. In other words, avoid turning on either notch filter unless there is a tone to be removed.
Both Notch1 and Notch2 can be used at the same time - but the warnings above apply.

"What is this "Vari-Notch" for?"

The "Vari-Notch" is a manually-tunable notch filter that the user can adjust, by way of the slider, to remove a fixed-frequency tone. In some cases it might be desirable to manually tune the notch rather than rely on either "Notch1" (which tends to "hunt" sometimes) or "Notch2" - which may be a bit aggressive, particularly if you are listening to music on a Shortwave broadcast. Like "Notch2", this cannot prevent desense of the receiver on strong signals. To disable: Set the slider to the far left so that the displayed frequency changes to "Off".

"Tell me about the 'CW Peak' filter - and what's the 'Ref Tone' button for?"

The "CW Peak" filter is a moderate-Q band-pass filter that may be manually tuned to a specific frequency to aid in the copying of CW stations during heavy band activity or high noise conditions and reduce "ear fatigue.. As with many implementations of a CW Peak filter, this isn't a "brick wall" filter in that it doesn't totally block signals off frequency - which is helpful in maintaining "band awareness" should another station on a nearby frequency call you. To disable: Set the slider to the far left so that the displayed frequency changes to "Off".
The "Ref Tone" button, when checked, will activate a tone with a frequency that corresponds exactly to the peak frequency of the CW Peak filter and can be helpful in adjusting it.

"What are the 'SAM-U' and 'SAM-L' buttons for?"

The "SAM-U" and "SAM-L" buttons enable "Synchronous AM" detection. With a normal AM detector, the signal's carrier frequency is required to demodulate the audio - but if this carrier is disrupted somehow by fading, severe distortion of the audio can occur. With synchronous AM, this carrier is recreated locally, eliminating one potential source of distortion.
Typical AM signals contain two sidebands - the upper and lower - and these buttons allow the selection of either. In many cases, there may be some interference on one sideband that is not present - or as bad - on the other, and one may select the one that that is the best.
Just below the numerical frequency display you will see, when Synchronous AM is enabled, a line that says "Sync AM stat:" that will show LOCKED or UNLOCKED to indicate whether it has locked onto the carrier of the signal being received. Also on this line is the parameter "Tuned freq:" that shows the actual calculated carrier frequency of the signal being received when it is locked - but note that this frequency display's accuracy is limited to that of the receiver at the WebSDR server itself. The final parameter is "NCO" which shows the frequency of the carrier lock mechanism - which will be discussed briefly below.
Limitations and quirks of the "SAM" modes:

The architecture of the WebSDR itself does NOT include the ability to do synchronous AM, so this is accomplished by intentionally mis-tuning the AM signal so that its carrier is heard as a tone. In software, the frequency of this tone is detected and locked onto (the "NCO" frequency noted above) and the audio is shifted to make it sound natural. What this means is that "SAM-U" actually uses the USB mode and "SAM-L" use the LSB mode to pull this off. Because raw I/Q audio is not available from the WebSDR, we can use only one sideband at a time which explains why double-sideband synchronous decoding isn't available - and why the limitations described below exist.
Because the Northern Utah WebSDR is configured for just 8 kHz of audio sample rate, the audio passband is actually from about 0 to 3.8 kHz or so and that means that everything of the AM signal being synchronously demodulated - include the carrier - must be placed within this frequency range. Because the carrier must be present within the passband, the displayed frequency is such that the carrier itself will be present as an audio tone of about 150 Hz before synchronous demodulation. Because the audio must be shifted down by 150 Hz, the upper audio frequency cut-off is also shifted down by this amount. (Comment: Some of these constraints could be relaxed if the Northern Utah WebSDR's audio bandwidth was increased from 8 to 16 ksps - but we simply don't have the bandwidth to do this and maintain the current maximum number of users.)
The "SAM" modes allow the actual carrier of the AM to be anywhere from 55 to 1000 Hz into the passband with, as noted above, the normal offset being assumed to be about 150 Hz. When in SAM mode, you can tune the receiver up and down, but the carrier itself MUST remain within the audio passband of the filters as you do so. As noted above, the audio must be shifted down by the amount displayed in the "NCO" display - but this also means that if you have the band-pass filters set to full width using the brackets on the waterfall or the "PassBand Tuning" buttons, shifting it by 1 kHz means that you will also lose the top 1 kHz of your audio frequency response.

Note: The reason that you might want to off-tune the SAM is to accommodate a net or round table with multiple stations that may not be on the same frequency. By setting the displayed frequency to be near the edge of the variation in the stations' frequencies, you can minimize the amount of retuning that might be necessary - but there will likely be distortion as noted below.
If you are listening to a net with stations transmitting AM that may vary in frequency:

If you are listening to a net in which there are stations using older radios that may not be on the same frequency, you may wish to "offset" tune slightly so that instead of relying on all of them being withn a few 10s of Hz, they can vary by several hundred Hz and still be within the lock range.
If using "SAM-U": Tune below the nominal frequency by 500 Hz or so. That is, if the nominal frequency of the net is 3880 kHz, if you tune to 3779.5 kHz, signals that are within about 450 Hz of 3880 kHz will be within lock range.
If using "SAM-L": Tune above the nominal frequency by 500 Hz or so. That is, if the nominal frequency of the net is 3880 kHz, if you tune to 3880.5 kHz, signals that are within 450 Hz of 3880 kHz will be within the lock range.
It is recommended that you zoom in fully ("max zoom") to be able to see the frequency of the carrier of the transmitting station to aid in retuning if its frequency is too far off for frequency lock to occur.
REMEMBER: It may take a second or two for the system to lock to the the carrier when it begins transmitting.

As noted above, because of limitations of the WebSDR architecture, the full frequency and phase relationship of the original RF signal is simply not available. What this means is that if you have tuned the signal such that the NCO is reading 1 kHz - and the SAM decoder is shifting the audio down by 1 kHz to make it sound right - that the audio that is "below" that carrier frequency of 1 kHz is still present, but it will be "folded back" and spectrally inverted, causing audible distortion. This can be "fixed" two ways:

Retune the receiver so that the NCO is showing a frequency of 200 Hz or less. This will minimize the amount of "folded back" spectrum and distortion. Again, this works well for broadcast stations that are on a consistent frequency, but if you are listening to a group or net where there are multiple transmitters taking turns (e.g. an AM net) that are NOT all on the "correct" frequency, you will keep having to retune the receiver.
Adjust the "PassBand" tuning or the on-screen passband slider nearest the AM carrier and move it closer to the carrier to remove the "extra" portion of the signal. Again, this won't really help if you are trying to listen to a net where everyone is on their own frequency.
Some GUI actions may cause momentary loss of carrier lock. For whatever reason, doing things like zooming in/out on the waterfall and some other actions can cause the carrier to lose lock briefly. Of course, retuning the frequency will require lock to be re-established!

As with any Synchronous AM demodulator, it can take some time - perhaps a second or two - to "lock" onto a signal. Also, fading and/or interference can cause it to lose lock occasionally.

"I see that in CW, USB and LSB that the there are 1 and 10 Hz tuning steps - what and how?"

The WebSDR itself natively tunes in 31.25 Hz steps, but because we can know exactly where the WebSDR server itself is tuned, we also know how far it might be off frequency - which will he half of this, or 15.625 Hz. By using the same frequency-shifting techniques used with the Synchronous AM modes, we can "simulate" as much resolution as we wish! Practically speaking 1 Hz is probably overkill as the receivers at the WebSDR server will drift more than this with temperature.

Because there is frequency shifting, the audio passband is affected, as with the Synchronous AM modes, but since this shift is, at most +/- 15.625 Hz, it is completely inaudible. This does mean that in Synchronous AM mode that the smaller frequency tuning steps are not available as the same frequency shifting used for this mode is the same one used for the finer tuning resolution - but this is pretty much irrelevant in SAM mode, anyway.
Because the there are two tuning mechanisms - the remote WebSDR server, which tunes at 31.25 Hz steps and the local frequency shifting, you may note that if you tuning the frequency quickly and are listening to a CW note that there may be a time difference between the tuning of the WebSDR server and the local frequency as manifested by what sounds like a bit of backlash. While an attempt has been made to synchronize the two events, it is not perfect and there's really nothing that can be done about it. Typically, this brief shift will be 15.625 Hz or smaller, but it could be slightly more than that if the frequency is being adjusted quickly and/or if there differing delays in the arrival of the audio via the Internet.

"Why do the tuning steps change when I change modes?"

In SSB and CW modes, fine tuning steps are desirable, but in AM - and especially FM - they are not needed, so coarser (larger) steps are used - so there!

"What is the 'High Boost' for?"

The "High Boost" feature was added for two reasons:

To compensate for the tendency of the DSP Noise Reduction to remove some of the "highs" in receive audio - particularly at the higher setting.
To help those with higher-frequency hearing loss - a problem shared by many people who have work or age-related hearing difficulties. Because these higher audio frequencies carry the consonants, boosting them can make human speech easier to understand.

This filter boosts the higher-frequency audio by 6 dB using a "high pass shelf", the center of the boost curve being located at 1500 Hz.

"Your stupid clock is wrong - why don't you do something about that‽‽‽"

It's really your stupid clock that is wrong: The clock on the WebSDR displays the time to which your computer is set!
If the clock that you see on the display is wrong, you need to find out why your computer's clock isn't set properly - it may be set to the wrong time zone and/or it may not be getting a time update from the Internet. Remember: If your computer's clock is a ways off, it will ignore the Internet time until you manually set the time and get it "close" to the correct time and date.

"What about those labels under the frequency scale/spectrum display? Where do those come from?"

There are two types of labels under the display:

Orange-ish labels: These are added by the sysop to indicate things like band edges, frequencies for various modes, certain stations (e.g. W1AW, international beacon network) and certain nets and the items that are included is entirely at the discretion of the sysop. These orange labels change twice daily: At 5 AM and again at 5 PM local (mountain) time to reduce the the clutter. In many cases, clicking on these labels will set the WebSDR's tuning to that frequency and the mode (LSB, USB, AM, FM) appropriate to operation on that frequency.

Green-ish labels: These exist ONLY if you have defined frequency "Memories", otherwise you will not be able to see them. Like the orange labels, clicking on them will tune the WebSDR to that frequency. Remember: These green labels are stored as cookies on YOUR computer: If you clear your cookies, use a different browser or use a different computer, they will disappear.

Once in a while the orange labels won't appear when the page loads. There are several ways to fix this:

Make sure that the "Hide Labels" box is not checked.
If the "Hide Labels" box is not checked, toggle it on and off again.
Change the width of the waterfall using.
Go to a different band and then come back.

"Why do I sometimes see 'Atten: 0dB' just below the S-meter - and why is it sometimes not there?

In November, 2021 we made a significant change in our receiver hardware. Originally, our widest-bandwidth, high-performance receivers (e.g. those capable of 16 bit data paths) were limited to 192 kHz bandwidth because of the limit of available "sound card" hardware used with "Softrock" type receivers. What this meant was that most of the HF amateur bands required several receivers to completely cover a given amateur band. After nearly a year of testing and work, we were able to make some modifications to the Linux drivers - and write our own program - to allow the use of the SDRPlay RSP1a receiver which increased the bandwidth from 192 to as much as 768 kHz, allowing coverage of any single HF amateur band (except 10 meters) with just one receiver.
These receivers - as do most - have built-in attenuators, and our driver includes the ability to use this as an AGC (Automatic Gain Control) which may be used to reduce the total amount of signal reaching the receiver's A/D converter to prevent clipping (distortion) under high signal conditions. Doing this allows the receiver to be operated at its most sensitive under most conditions, but throttle signals back to prevent overload, which would affect all users on that receiver.
The new driver includes the ability to indicate the amount of attenuation being used by the receiver at any given time and that information is now available on-screen to the right of the numerical S-meter values. The numerical value following "Atten:" shows the number of decibels of attenuation that is being applied at that instant. Because it is and AGC, this number will change - albeit rather slowly (under most circumstances) if the total power of the signals impinging on the receiver's A/D converter exceeds a certain value.
The WebSDR uses this information to correct the S-meter so that it will continued to read correctly despite the change in the signal path. Note that this information is polled from the WebSDR server periodically (every 2.5 seconds as of this writing) so it may lag the actual attenuator setting by a second or to. At this time, this correction value is not being applied to the waterfall, so you may notice that it will darken a bit with higher attenuation and brighten again with lower attenuation.
This "Atten:" value appears ONLY when you are using a receiver that has this AGC capability.
For more information about these receivers, visit the "Technical Information" page.

"What is this 'Alt AGC' thing?"

This is designed to overcome the deficiencies of the WebSDR's built-in AGC during AM reception: The original AGC tends to badly over/undershoot, causing loud clicks and pops when signal strength is changing rapidly - mostly due to QSB, or when someone keys/unkeys. This is disabled when FM is selected as its use does not make sense from a technical standpoint.
The "Alt AGC" attempts to overcome these deficiencies as much as possible given the limitation of the existing WebSDR server. The nature of this AGC is that the audio recovery will likely be a bit lower (e.g. quieter) than with the normal "RF AGC". The "Alt AGC" works with SSB to a degree, but it is not optimized for such.
This "Alt AGC" may be invoked in the command line as one does with frequency and mode by adding "?altagc=1" to the URL.

"What's the S-meter squelch for?

This is a squelch that is based solely on signal strength and as such it probably isn't a good candidate for typical HF operation where signal levels and noise varies wildly as it is intended for FM reception on VHF/UHF bands (including 10 meters). The "Set" button will preset the threshold about 6 dB above the current S-meter reading.
This may be invoked in the command line as one does with frequency and mode by adding "?smsquelch=X" to the URL, where "X" is the signal level, in dBM (as displayed on the S-meter) of the squelch threshold.
Do NOT expect this to work well on SSB or with very weak signals.

"I don't understand the Apparent peak SNR" display! What is that?

In all modes, below the S-meter is this number which is the apparent signal-noise ratio of the received audio. This is based on the peak and minimum audio over the past two seconds and simply displays the ratio between the two in dB. Because of the way it works, it has some limitations:

On a very noisy signal, it may read higher than actual. This is due to the fact that brief "pops" (static) are detected, and this is why on just plain noise, it may read higher than 0 dB.
It has no audio frequency weighting or filtering. If the audio has a tone (heterodyne) or background hum, the SNR will be low - but this is to be expected.
If the audio is muted due to squelch operation or from Internet buffering, the peak SNR may read very high as it's comparing "dead silence" with what was there.
The SNR reading is slightly weighted to give more realistic values under real-world conditions. In FM, this value is reduced by roughly 0.5dB while for other modes is about 1.8 dB.

"I see a bunch of numbers displayed below the S-meter when I'm in FM mode - what are those?"

When FM is selected, audio deviation parameters are also displayed, such as:

Deviation (pk): This shows the peak deviation, updated about 10 times/sec

Avg.: This shows a weighted average of the deviation over a period of about 2 seconds.

Avg-pk: This shows the "averaged" peak level. The small number indicates how many samples were used to get this average and a value of 20 indicates 2 seconds.

Min: This is the minimum recorded deviation over the past two seconds.

Max: This is the maximum recorded deviation over the past two seconds. It is this "Min" and "Max" data that is used to calculated the "Apparent peak SNR".

Because, with FM, the loudness of the audio is conveyed ONLY by how much the frequency "wiggles" when modulated, it is displayed ONLY when FM is selected.
This display is most useful for operation on VHF/UHF where it can help users diagnose issues with "low audio" that frequently result from radios that aren't configured properly, are being used by new operators who don't speak loudly and/or close enough to the microphone, or due to some technical issue.

"What's that number in brackets after the username on the frequency scale at the bottom of the page?

In the frequency scales below the waterfall display, near the bottom of the page, the approximate frequency, in kHz, is displayed in square brackets after the username - but if they haven't entered anything in the "Callsign" box this could also be an IP address or device type. This information is useful to help figure out who is on what frequency - something that can be difficult to do, particularly on the wider bands when many users appear to be clumped together.
There is a "quirk" to this display in that the calculation of the displayed frequencies of other users is based on assuming that they are running the same mode as you. This is necessary as the mode of each, individual user is not easily accessible for the code being run on a users' computer where this information is calculated so the (reasonable) assumption is that everyone is running the same mode (e.g. LSB on 40, 80 and USB on 20 and above). Because of this, the display could be off by about 2.5 kHz is you are set to USB and the "other" person is set to LSB.

"When I listen on SSB (USB/LSB) the audio sounds "wider" on the WebSDR than on the rig that I have at home and I hear more 'splatter' from nearby stations? Why does the WebSDR have such sucky filters?"

Based on feedback, many WebSDR users listen casually to nets and roundtables rather than try to dig weak signals out of the noise. Because of this, the "default" LSB and USB filters are wider than those typically found on sideband rigs to give better lows and highs. For more "DX" type use, there are the narrow filters (e.g. "LSB-nrw" and "USB-nrw") that can be selected.
You can also set the bandwidth manually to suit your tastes or the current conditions - The next section (below) tells you how.

"There's another station really close to the frequency on which I'm listening - how do I filter it so that I can hear what's going on where I'm listening?"

If you own a radio made within the past 30 years you probably have a "Passband Tuning" or "IF Shift" control that allows you to move your filter back and forth. If you own a modern receiver you can adjust the high and low sides of your filter independently to narrow your bandwidth at the top or bottom end of the voice channel on which you are listening to reduce that edge of the passband to remove some of the adjacent-channel interference. On this WebSDR, there are several ways to do this:

Select the "Narrow" version of the mode that you are using (e.g. LSB-nrw, USB-nrw).
Click on the "narrower" button to reduce your overall receive bandwidth bandwidth (there are actually two different buttons that do this...)
Under the "Passband Tuning" section use the "<<IF Shift<<" or ">>IF Shift>>" buttons to "slide" your passband up or down, away from the interfering signal.
Use the "<<Low PBT", ">>Low PBT" to slide the low-frequency end of your receive passband down or up, depending on which sideband you are using.
Use the "<<High PBT", ">>High PBT" to slide the high-frequency end of your receive passband down or up, depending on which sideband you are using.
On the screen, grab the low or high end "skirts" the passband with the mouse (e.g. hover the cursor over it then press-and-hold the left-mouse button while dragging it) to change the passband. It is recommended that you zoom in before doing this!

Remember: If you click any of the "USB" or the "LSB" buttons after setting a custom bandwidth that it will reset them to the default values.

"There is a loud tone (carrier) on the frequency where I'm listening - What is that?"

Some of our amateur bands - notably 40 meters above 7200 kHz and large chunks of the 80/75 meter bands are used for international shortwave broadcasting in other parts of the world and shortwave being, well, shortwave, we can often hear those signals - particularly at night or early morning in North America. To a degree, you can remove this tone by clicking the "autonotch" button near the volume control - but this will remove only the carrier, not the modulation (speech, music.) At other times you will hear short-duration carriers while people tune up or, unfortunately, due to the occasional jamming. It is recommended that you NOT use this "Autonotch" or "Notch2" features when receiving CW (or digital!) signals as this will dutifully remove them!
Note that this "autonotch" seems to be able to notch only one tone at a time and during modulation from a received station it will sometimes drop in and out (the tone appearing briefly) as the autonotch "hunts" for the strongest spectral component and briefly mistaking the speech for a tone.
"Notch2" is a separate notch filter that is implemented elsewhere in the audio stream and while it will not prevent desense (S-meter) deflection from a strong signal, it may help with weaker, annoying tones that aren't strong enough for the autonotch to lock onto. It, like the "Autonotch", can affect the quality of the voice.

"How do I engage a noise blanker, noise reduction or other whizz-bang feature like that on the WebSDR?"

The Northern Utah WebSDR now has DSP Noise Reduction, the controls being located below the S-meter and above the volume control - read the description near the top of this section for more information.
Common types of noise reduction work best on periodic noise such as the "buzz" of a powerline but works less-well on the "white" noise of a quiet band where signals are simply weak and really doesn't work at all when signals overlap.
Having said that, there is an "impulse" type noise blanker that is always active on this WebSDR (configurable by the sysops, but not the user) to deal with the occasional power line noise that pops up: We're working with the power company to mitigate this. This noise blanker also helps to take some of the "edge" off strong static crashes/pops so that the AGC recovery can be somewhat quicker so that a user will lose fewer syllables.

"Can you tell me more about the URL parameters for the WebSDR?"

Yes. In addition to specifying the frequency and mode that is "automatically" set when you start the SDR, there are a number of other functions that may also be done and they are listed below - include that which sets the frequency and mode.
To invoke a WebSDR with a URL command using the setting of a frequency and mode as an example:

Append "/?tune=[freq kHz][mode]" to the URL, as in: http://[WebSDR's URL]?tune=7200lsb to tune to 7200 kHz in LSB. As an example:

http://websdr1.sdrutah.org:8901/index1a.html?tune=7200lsb - Note that the port number "8901" and the name of the web page itself "index1a.html" is included in this. Most WebSDRs may not need the "index1a.html" portion at all.

A complete list of URL parameters - and how they are used - may be found on the "URL Parameters" page - link:

"Some WebSDRs have a 'chat' function, but not this WebSDR - why is that?"

Past experience by other WebSDR operators have shown that while the "chat" function can be well used, a small number of people tend to use it as a platform for abuse: Such is the nature of the Internet...
Seriously, have you actually met people!?! Are you surprised about this??? Really?!?

Computer and usability issues:

"I keep hearing audio drop-outs. What can I do to fix that?"

There are several possible causes of audio drop-outs:

You have switched away/minimized the web browser. When the browser window is "front and center" and the active window, it has high priority when it comes to doing "computer things" such as processing, network activity, audio output and screen updates. When you switch away from the browser the priority of the tasks assigned to the browser are reduced. The WebSDR uses scripting running on your computer to decode the audio and update the display and because audio is a "real-time" thing, if the computer isn't processing the audio as fast as it is coming in you will eventually end up with drop-outs. There are several things to do that might minimize this problem:

Use a faster computer. An old, slow computer may simply not be up to being able to service the browser-based audio if the browser itself is relegated to background tasks.
Try a different browser. The ability to service the audio stream may be different from browser-to-browser. In general, it "seems" as though Firefox is more forgiving but Chrome is less-so, but your mileage may vary

Your Internet connection is "jittery". One thing about the Internet is that no matter how fast your connection speed, you are still at the mercy of all of the connections between where you are and the server. Because it is the Internet, the route that the WebSDR's packets take can change on-the-fly, some connection may suddenly get "busier" with increased traffic or there may be a problem somewhere causing "jitter". When jitter happens, the time it takes for a packet of data to get from the server to your computer can vary all over the map - and if too much time has passed since your browser got audio data from the WebSDR, it runs out of data and you will get a brief period of audio silence (e.g. a drop-out). A few common examples of why this might happen include:

Your Internet connection may be busy. If you - or someone else - is watching video, downloading files, etc. via your Internet connection and taking much of the bandwidth, expect more jitter.

You are using a cable Internet modem. During the "busy" hours (evenings, when everyone is watching a streaming service) a "shared" connection (like cable Internet where an entire neighborhood may get all of its bandwidth from just one node) may be overutilized causing occasional backlogs in traffic. While video is pretty tolerant of this (it will often buffer 10s of seconds) the "near real-time" audio from the WebSDR is not quite as forgiving.
You are using a "wireless" Internet carrier. Like a cable modem, it is often the case that an wireless Internet provider will put many customers on a single trunk and data will slow down/jitter increase when more people are using bandwidth.
You are using a "mobile" carrier. This network model is the epitome of "shared" bandwidth and will naturally slow down/increase jitter as more people use it. Also, the "mobile" nature of mobile data can mean that if you are moving around (in a vehicle or in a building) your connection quality may be all over the map.

There may be a problem in the network at the WebSDR end. Unfortunately, this is not unknown: The WebSDR site is in a very rural area and the only way that Internet can be brought to it is via dedicated wireless links. While these links are capable of hundreds of megabits-per-second, the very nature of a wireless network - and the equipment used - makes them a bit more "jittery" than a direct fiber connection to the Internet. We are always looking at ways to minimize this issue, but bad jitter can - and does - happen at times.
The Internet may just be "busy". As you can guess, there are times of the day when there is simply more traffic on the Internet than at other times - the local evenings being just one example. This can lead to congestion, additional packet "jitter" and even the occasionally "lost" packet.

Reducing the effects of jitter on WebSDR performance. If you can't really do much about any of the above, the Northern Utah WebSDR has an "Audio Buffering" setting just below the volume control in a drop-down menu. By adding more buffering, the audio decoding in the browser is better-able to "ride through" the jitter - but more buffering adds more delay. Because of normal audio processing at the WebSDR and at your computer, there's already about 0.25 seconds "baked in" plus the delay in transit across the Internet. There are currently four settings for audio buffering:

125 msec - This is 1/8th of a second - the lowest amount of buffering available. This setting may work well much of the time, but it may actually be a bit marginal for a wide variety of network conditions, which is why it is not the default.
250 msec - This is the "default" setting with approximately 1/4th second of built-in buffering to allow for slight network jitter.
500 msec - This adds another 1/2 or so to the buffering, making it more resilient to the occasionally-delayed packet, but it does mean that there is another 1/2 of delay between when the signal arrives at the WebSDR's antenna and it comes out of the speaker. For most operation - including nets and round tables - this amount of delay isn't an issue - provided that you aren't being driven crazy by the delayed echo from hearing your own transmission.
1sec - This adds about 1 second more buffering than the "normal" setting making it even more resilient to networking issues - but this is getting to be a large amount of delay and it may be awkward if rapid-fire on-air exchanges are occurring if you are using the WebSDR as your main receiver.
2sec - This adds about 2 seconds more buffering than the "normal" setting and it is very resilient to networking issues and if you are only listening casually, this doesn't pose a problem - but this is probably too much delay if you are participating in any sort of net or on-air discussion and using the WebSDR as your main receiver.
62.5 and 31.25 msec - These should be considered to be "experimental" settings. These settings begin to approach the end-to-end latency and jitter found on even "good" Internet connections at times. While these may "work", expect occasional/frequent drop-outs if you choose either of these settings.

Remember: Increasing the buffering will not only add delay between the RF arriving at the WebSDR's antenna, but the audio will also be delayed when you change frequency, volume on the WebSDR, change a filter, etc. - and the waterfall and S-meter will seem to be "ahead" of the audio as they are not delayed by the same amount.

"I've been using the Chrome browser for a while and there's suddenly no audio (or some gaw-dawful noise) on the WebSDR? What's the deal?"

Is your computer's audio - or the tab in Chrome - muted? Go to another web site that you know has audio (such as YouTube) to make sure that it works there.
Google made changes to Chrome in April, 2018 that may have disabled audio playback, but we have a web page just for this situation - read more by going to the "Fixing Chrome" page.
If you wish to use Chrome with your mobile device (phone, tablet) I strongly suggest that you, too, read the "Fixing Chrome" page!
In early September 2018 a new version of Chrome was released that seems to have compatibility issues with the way the audio is handled by the WebSDR, causing very loud white noise - either when you first go to the WebSDR page or after having been there a while.

The problem with the noise/waterfall issues was fixed with a mid-December 2018 release of Chrome. If you have this problem, please update your Chrome browser to the newest version!
Remember that you don't have to use Chrome: Firefox works very nicely with the WebSDR!

"I'm using my computer/phone/tablet/piece of slate and the web page seems to load, but I never hear any audio and/or see the waterfall. What's the deal?"

The first thing to check is to see if you have an seriously out-of-date browser and/or computer. There are some functions in the code embedded into the web page that require "new-ish" browsers (e.g. newer than about 2014-2015, maybe...)
Your computer/browser may be blocking scripts: The audio and waterfall portions of the code use HTML5 and Javascripting that must be able to run for either to work. This could be a browser setting or something in your device - perhaps a security setting - that blocks such things. This is most common when using a company-owned (e.g. work) device.
Your network may be blocking something. The Northern Utah WebSDR Server #1 (only) can be accessed using either the standard HTTP port 80, or it could use its "normal" port 8901 - so it would be worth trying both (e.g. http://websdr1.sdrutah.org:8901 or just http://websdr1.sdrutah.org:8901). Your network's security infrastructure could be "inspecting" packets and not like the audio and/or waterfall data that is being sent and/or the data sent from your device to control the WebSDR for things like frequency, mode, waterfall settings, etc.
There are some instances where, for no obvious reason that can be fathomed, it just "ain't gonna work" - at least not without getting a networking nerd involved.

"The waterfall/words on the page take up only a small portion of my giant monitor and/or it's all too small for my eyes and I want to make everything bigger - how do I do this?"

Many browsers have a "magnify" feature that allows one to "embiggen" a web page and everything on it. On most browsers this is done by pressing and holding the "ctrl" and then hitting "+" (plus) key. For this you can use the "+" key on your numerical keypad, or you can use the "+" key that shares the "=" (equals) key next to the backspace - but that one will require that you hit "shift" as well to access the "+".
To reduce the size, use the "ctrl" and "-" (minus) keys in the same way.
On many browsers, you can use "ctrl" and "0" (the number zero) to reset back to normal.
The size may also be adjusted by going to the View tab in your browser and adjusting the "Text Zoom" (or similar) setting.
Most modern browsers will associate this setting to a particular web site and its pages and leave the other web pages as they were, so "embiggening" the WebSDR page won't cause all other web pages that you might visit to be embiggened in the same way.

"I often use a WebSDR when on a round table or net - but it's a pain to mute the WebSDR when I transmit to avoid being driven crazier by the echo. Is there another way?"

The most obvious way to mute the receiver is with the "Mute" button near the volume control on the WebSDR. If you click this, it actually stops the audio at the WebSDR, reducing its processor load and network bandwidth. While this is preferred as it saves bandwidth, there are other ways to quickly mute the audio:

Many "multimedia" keyboards have a button on them - usually along the top row - that, when pressed, will toggle the speaker audio on and off. These buttons/keys often have a symbol that looks like a speaker with a diagonal line through it.
Some newer browsers (recent versions of Chrome and Firefox) have, in their tab along the top of the screen, a very small speaker icon when they are at a site that has embedded audio. You can click on that speaker icon on the tab to mute the audio, at which point the icon will switch to a speaker with a diagonal line through it - but remember that you muted it that way when you want to hear the audio again! Muting using this tab may be more convenient since the speaker icon can be visible even if you have hidden the window with the WebSDR.
On your computer/operating system it may be possible set up a shortcut or "hot" key to mute/un-mute the audio.
Turn down/off your computer speaker.

Rig some sort of relay keyed by your rig's PTT output that mutes your computer speaker(s). For a brief article describing one way in which this may be done, click here.

"People report that they hear an echo on my signal, even though I turn down my speaker. What's the deal?"

Of course, if you are transmitting and your computer is on the WebSDR and you can hear your own signal, some of the audio from your computer will make its way into your microphone - and it will be heard, even if the volume is quite low: You should either mute your audio completely, or wear headphones - although audio can "leak" out of many headphones and still be heard because the microphone will probably be near your head!

If you have connected your rig to your computer to run "sound card" modes like FT-8, RTTY, SSTV, JT-9 or many others it may be that your "speaker output" is always getting to your radio. Some radios (possibly including the Elecraft K3) seem to pass some of this audio through, even when one is not in a "digital" mode which means that if you are listening to a WebSDR, your computer audio may be getting into your rig directly and then being transmitted.
The best way to avoid this - and to avoid other issues (such as transmitting email notifications, system sounds - or music) over the air is to use a separate sound card that is dedicated ONLY to digital mods: This "other" sound card could be another device plugged into your computer's internal expansion bus, or it could be a USB device such as an external sound card or a rig interface such as a SignaLink.
By not having computer system audio being sent to that "other" sound card you won't get that echo or be embarrassed when your computer's audio gets blasted across the 20 meter FT-8 sub band. It happens all of the time to others - don't let it happen to you!

"I've noticed that if I listen for a while, it suddenly stops with some sort of screen that talks about a time-out. What's with that?"

If you tune in a frequency on the WebSDR and then leave everything alone, the system will time you out after a while - see the notice near the top of the web page on each server to find out what the time-out might be - but it will be 90 minutes or more.
Why do this? Experience has shown that some users may forget that their WebSDR window is open and an even smaller number would simply run it all of the time if they could, taking up bandwidth and a "user" slot all of the time. Making it time out after a reasonable period prevents anyone from permanently "squatting" on the system.
If you do anything that proves to the system that you are still alive (change frequency, mode, band) this timer will reset, so it only affects users that might "set it and forget it". Any of these time-out timers are at least 90 minutes (if not more) and this should be enough time to sit through a net. If you are in an hours-long round-table you will probably want to get into the habit of occasionally changing something on the WebSDR like the waterfall width or adjusting the volume.

"I'm using an Apple (tablet/I-phone/computer) and I don't hear any sound. What's the deal?"

If you are using Safari, make sure you press the "Audio Start" button that appears just above the waterfall.
Once in a while a new version of a browser comes out that "breaks" things. If that happens, it may have already been fixed and check for a newer version. If you are running a really old version of Safari, update it!
Some Apple products have a quirk when it comes to getting sound from the WebSDR, as explained in this quote from the FAQ at WebSDR.org:

"An issue with iPad (-like) devices is that they have two mute switches: one which affects music, youtube, etc., and one which affects system sounds (like mail notifications bleeps).
Somehow, iOS treats the WebSDR audio as the latter. So please check that you haven't accidentally muted the system sounds. On some devices this is a software switch, on others it's a physical hardware switch."

Try using a different browser: Firefox seems to "play nice" with WebSDR, as do most versions of Chrome - and both of these browsers are available for many Apple platforms.
If you continue to have problems, visit this page for suggested work-arounds.

"I'm trying to use the my computer and can't get audio - why is that?"

On the Northern Utah WebSDR there should be a button just above and to the right of the waterfall display that says "Chrome Audio Start", "Firefox/Mozilla Audio Start" or something similar. This should (hopefully) enable the audio.
In recent years, authors of browser software have required that the user do something - like click a button - to indication permission that YOU have allowed the web site to use audio and video resources on your computer - and the WebSDR is no exeption.
If you continue to have problems, visit this page for suggested work-arounds.

"Why is it this way?":

"Why don't you run 'OpenWebRX'?"

The OpenWebRX software (link) is an open source remote SDR with a web-based interface - but it is not really a replacement for what we run at the Northern Utah WebSDR. Even though it has many more "features" than the PA3FWM WebSDR that we run, we choose to stay with the seemingly less-featured WebSDR software. You would be correct to ask "why"?

OpenWebRX doesn't scale well with large numbers of users. The Northern Utah WebSDR frequently hosts more than 200 users on a single WebSDR server: The internal architecture of OpenWebRX simply doesn't allow this with modest hardware.
The vast majority of users are interested only in hearing signals on the band. While OpenWebRX has a lot of bells and whistles - which is part of the reason why it's difficult to scale to a large number of users - very few users actually care about doing anything other than "just listening". How do we know? We ask them, and they tell us!

BTW, the Northern Utah WebSDR does have some wideband receivers that use the OpenWebRX interface (e.g. the KiwiSDRs) and have a lot of bells and whistles like RTTY, PSK, FT-8, SSTV and Morse decoding - to name but a few - but relatively few people use them as compared to the WebSDRs.

The vast majority of users only care about the amateur bands. There might be the temptation to offer large swaths of HF for reception of SWBC stations, but again, most users don't care at all about that.

Rather than have a "broad as a barn door" receivers that covers a lot of spectrum that performs only marginally well in doing so, we have amateur band specific receivers with good input filtering to prevent degradation from other strong signals across the spectrum so that they are able to "hear everything that there is to hear."
For those interested in SWBC listening, many of these bands are already covered by our WebSDR #3 (Blue) - not to mention the KiwiSDRs as well. Again, we keep track of how many people use those receivers and it's a very small percentage of the total.

"Why don't you run the Phantom WebSDR - it's a replacement for the PA3FWM WebSDR isn't it?"

Unlike the PA3FWM WebSDR that is used for the main servers of the Northern Utah WebSDR, the "Phantom WebSDR" is open source - but as of the time of the writing of this entry (September, 2024) it isn't ready for "prime time". Whereas the PA3FWM WebSDR needs only 45-60 kbps of total bandwidth (for audio, waterfall, control) per user, the Phantom WebSDR needs somewhere areound 4-8 times this. It also is a bit "bare bones" at the moment and it doesn't have the features/UI refinement of the modified PA3FWM WebSDR being used at the Northern Utah WebSDR and other places..
As it is open source, it may well be that these issues will be resolved over time and become more generally useful.

"Why is it that if I click on one of the Northern Utah WebSDR's servers at "websdr.org" that I end going to another page rather than the server itself?"

In July 2019 a "landing page" was set up that is intended to provide a common point to access all of the servers at the Northern Utah WebSDR.
Having the landing page also helps to alert new users about all of the WebSDRs and related servers at the Northern Utah WebSDR.

"Why is the web site/WebSDR Servers so old-fashioned looking?"

The main reason: Simplicity.
Other reasons:

The WebSDRs do NOT run full-featured web servers per se, but rather a very stripped-down web server that has been highly optimized for the purpose - which is to serve only the bare minimum of data required while using minimal resources and bandwidth: Nothing else really matters.
The "sdrutah.org" web site is fairly bare bones: The majority of users go to the site just to go to the WebSDRs themselves while a few look at the information presented at the web site - which isn't that much, nor does it need to be fancy.

"If I zoom in tightly on the location of the Northern Utah WebSDR on the map on the bottom of the page at the WebSDR.org web site I see that there are several different WebSDRs, each in a different location on the map, very close to each other. What's the deal?"

This map uses the "grid square" information to show the locations of the WebSDRs, but since the servers at the Northern Utah WebSDR are all in the same place, only one of those markers would appear - and which server, exactly, showed up on the map seemed to be entirely random. To spread them out, only the "Yellow" WebSDR's location is correct, with the other WebSDR(s) being one "sub-grid" off from that of the main server.
While zoomed out, you will still see only one WebSDR on the map, but you will see all of them if you zoom in far enough..

"What's the deal with 'high performance receivers'? Are there 'low performance' receivers?"

There are two classes of receivers on the Northern Utah WebSDR: The "High Performance" receivers that are relatively narrow-banded (96-1536 kHz) that use high-performance sound cards and QSD (Quadrature Sampling Detector) mixers or do direct sampling that can handle both weak and strong signals at the same time as they use the same sort of hardware found in high-performance HF rigs (e.g. 14-16 bits of A/D conversion).
Those that are not "high performance" receivers use inexpensive "RTL-SDR" dongles.

The dongles are attractive in that they are very cheap ($4-$80, depending on features - the ones we use are $20 each) and can cover up to about 2 MHz of spectrum at once - but this comes at a cost in performance: They have only 8 bit A/D converters which means that if you adjust them to receive weak signals, strong signals will badly overload them while adjusting for strong signals means that it's likely that they won't hear weak ones.
With proper filtering and precise level adjustment one can get closer to a happy medium, but their use is inevitably a trade-off. It's because they are so cheap and relatively broad banded that they are an attractive way to get "some" coverage over large frequency ranges with generally-acceptable performance. In several cases, even though we could cover 2 MHz of bandwidth, we only cover 1 or 1.5 MHz but this was done because there wasn't anything of particular interest immediately outside this frequency range and the receivers work slightly better with reduced coverage.

"When I connect to the WebSDR, the audio blasts me out of the room and I have to quickly turn things down. Can't you make it start 'quieter'?"

When this WebSDR first went online I did make the audio quieter by default exactly for this reason, but I soon got complaints from people about how this WebSDR's audio was so much quieter than, say, the audio at KFS - so I changed it back so that once again, it blasts as loud as everyone else's!
All I can suggest is that you turn down your volume before connecting to the WebSDR.

"Why do I hear signals belonging to hams outside some of the ham bands? Are they actually transmitting there?"

This is a spurious (image) response due to the way sound cards work. For example, at a sampling rate of 192 kHz the highest frequency that can be accurately represented is half this - 96 kHz at the Nyquist limit. Frequencies above this will "wrap around" and move down, away from 96 kHz. The sound cards contain low-pass filters that help prevent this, but they aren't perfect "brick wall" which means that they will respond increasingly weakly at the input frequency goes above the Nyquist limit - but they aren't completely gone. To work around this adjacent bands have a bit of overlap so that one can get away from this response.
A good example of this spurious response is the 19 meter SWBC receiver on WebSDR #3 where one can see "inverted" signals from 20 meters at the bottom. This is due to the nature of the way the RTL-SDR works and the difficulty of making a filter that would prevent such.
In radios that use sound cards as their input devices (e.g. Elecraft transceivers like the KX2, KX3 and K3) this is avoided by only "looking" at signals that are well away from the "edges" of the input bandwidth response where the Nyquist filter's attenuation is stronger.

"Why are there several servers rather than all bands being on the same server?"

The WebSDR software is designed to allow only up to 8 bands at once, so additional bands must be hosted on other servers. Using affordable acquisition hardware (e.g. plug-in sound cards, various USB devices) there are also definite, practical limiters on the number of these devices that may be connected to one computer at the same time. Having multiple servers also allows lower-performance (and less-expensive) computer hardware to be used.

"The Utah SDR's interface seems to look slightly different than some of the others that I've seen with a few extra features - what's the deal?"

During the time that the Northern Utah WebSDR has been online, several changes have been made to the scripts that make everything work. Several of which have already been mentioned, but here they are again - at least the ones that I remember doing!

Addition of the "=kHz" button: Pressing this rounds the frequency to the nearest even kHz - useful these days because most people tend to set their radios to frequencies that end in "x.00". (This change was also adopted at KFS where it is the "=0.00" button).
Addition of an on-screen clock: "Borrowed" from KFS, there is a real-time clock, based on your computer's time, displayed in the lower-left corner of the spectral display.
Additional "bands" on the screen: The limit of the WebSDR software is 8 bands per server (it would be difficult to add more input devices to a single server,, anyway!) so there are different bands' buttons that take you to those other servers.
Added "dBm" to the S-meter scale: Because the meter's numerical value reads in dBm, I thought that this should be on the scale, too!
Additional bandwidth settings: There are more settings than standard WebSDRs to choose from. As noted on the main screen, the "default" settings are in bold font. Note that some of the "defaults" on this WebSDR are different from the original values.
Wider variety of waterfall sizes and speeds: Most of the Utah WebSDRs have a greater variety of speeds and waterfall sizes than normal. The "default" waterfall speed is actually slower than standard - this being done to reduce the needed bandwidth slightly, but still update at an acceptable rate.
Additional bandwidth setting buttons: If you wish to weak the bandwidth settings for your liking, addition buttons are provided below the mode and "canned" bandwidth setting buttons. (These were "borrowed" from the "Weert" WebSDR.)
"Audio buffering": This drop-down allows the selection of different amounts of buffering used for the incoming audio stream. This is useful if your Internet connection is a bit "jittery" and/or slow and it also helps if you are running the window with the WebSDR in the background, causing your computer to give it lower priority - but more buffering means a longer delay. Please read the section about using buffering to reduce audio drop-outs, above.
"Chrome Audio Start" button: If you are using the Chrome browser, you may see this button: You may not get audio unless/until you press it, depending on your browser's configuration.
Frequency-centering zoom: The code for zooming in has been tweaked so that the frequency to which the receiver is tuned stays within the spectrum display. (This isn't mine - I just un-commented some existing code to allow it...)
Change of the behavior of the "Peak" S-Meter reading: The "peak" value on the S-meter is calculated differently than is standard: The peak value will "hang" for a short time before dropping in a "ballistic" way. This method gives a slightly better indication of the peak signal level than the original method.
Additional settings on the "Sig. strength plot": There are now options on the signal strength plotting to use the (modified) peak S-meter value. This makes plots of rapidly-varying signals easier to read.
Spectral display is adjusted "higher" on most bands to make weak signals more visible in the waterfall: This is, perhaps, a subtle change that makes the waterfalls look "brighter" for weak signals. In the original code, if the S-meter is calibrated to accurately read signal levels the waterfalls will often look black on the higher bands - or even on lower bands during the day due to the naturally-low signal levels - and this is especially true on bands that are "closed." The code was tweaked on a per-band basis so that even if the band is at its quietest, the waterfall won't be completely dark.
Mode indication: For whatever reason, the WebSDR pages didn't originally tell you which receiver mode you were using (e.g. LSB, USB, AM, FM, CW) and if you were to have accidentally changed it, it may not be obvious why you are having trouble tuning in signals. The currently-selected mode is now just to the right of the frequency display - right were God intended it to be.
Noise reduction: As mentioned above, we have written DSP noise reduction code for the WebSDR and added it: If you run a similar WebSDR system and are interested in implmenting the noise reduction on their system, contact us using the information at the bottom of this page.
Notch2: This is a second notch filter - operating on the audio stream rather than at the WebSDR server. This is intended to operate on weaker CW carriers/tones that the "Autonotch" can't reliaibly remove.
"Audio Muted" indicator: This is an on-screen indicator - to the right of the frequency entry bar and the mode display - that indicates when you have muted the receiver using the WebSDR interface. This doen't show if you muted the audio on your browser or your computer.
Added audio muting to the keyboard input: When keyboard input is enabled, the "m" key will mute/unmute the audio.
Audio de-emphsis and high-pass filtering added for FM demodulation: We have written code that applies proper de-emphasis to received FM audio, and it has a 200 Hz high-pass filter to attenuate subaudible tones that might be received. Contact us if you have a WebSDR and wish to implement this code on your system.
URL parameters. Various configurations and modes may be specified in the URL so that you can customize a link or shortcut such that the WebSDR is "pre-configured" when the page loads. A complete list of URL parameters - and how they are used - may be found on the "URL Parameters" page - link:

There are likely a few other tweaks that have been made, but didn't come to me when making the above list. If you run a WebSDR and are interested in any of the above, let me know via the "contact" information on the "about" page.

"Why don't you support (put a mode or feature here)?":

"The WebSDR's receivers/antenna would be awesome for a (Skimmer, WSPR receiver, other cool thing) - why don't you do that?"

It took a lot of effort to get the current suite of receivers up and running - and there's still a bit of work to do before we really consider adding lots more bells and whistles. Having said that, we are keeping an eye on ways to interface with other programs/devices to allow future integration of things like CW skimmers, propagation analysis tools and the like - and the system was designed from the outset to allow this.
As it turns out, there is a CW skimmer system in operation at the Northern Utah WebSDR currently reporting using the callsign "KA7OEI". This primarly uses the Omni antenna, but can take signals from the other antennas as well. This system is considered to be "experimental".
There is a totally independent WSPR decoder/monitoring receive system on site - See below for more information. Presently, it has been configured to monitor the 630 and 160 meter bands (plus a few others), reporting with the callsign "KA7OEI-1". It is possible that this may include other bands sometime in the future, but this will depend on the available resources.

"Can I use the WebSDR to receive digital modes like FT-8 or WSPR?"

Because of resource and complexity limitations, the WebSDR currently has no built-in decoder for these modes, but it is possible for you to route the audio that you are getting from the WebSDR into a program that does the decoding. As with the noise reduction mentioned above, it would be necessary for you to somehow "pipe" your receive audio into the decoding program - with with a program like "Virtual Audio Cable" or with a hard cable.
One issue is that because of the nature of the Internet and the way your computer processes sound, there may be occasional drop-outs and/or changes in the delay between when the signal hits the WebSDR's antenna and it comes out of your computer: While this may be an annoyance on modes like CW or PSK31 where characters can be occasionally missed, this change in timing can completely mess up the reception of WSPR, JT-9 and FT-8 transmissions, either degrading them or completely wrecking their synchronization.
Finally, remember that any mode that requires tight clock synchronization (like WSPR, FT-8, JT-9, etc.) can also be affected if the overall delay across the network and in your computer is too great.

"Why don't you cover from 0-30 MHz all in one swath?"

This is a bit of a technical challenge to accomplish, requiring what is still exotic hardware (very fast A/D converter, a very fast processor platform such as a multi-core graphics card or dedicated hardware like an FPGA) - but recent work has been done that may make such possible.
There are less-expensive devices - such as the KiwiSDR that can cover 0-30 MHz that FPGAs for their "heavy lifting" but these can only support a handful of users at once. There are two of these receivers on site - see the KiwiSDR portion of this FAQ for more information.
There are devices that are simply an A/D converter connected to a USB3 interface (e.g. the RX-888) that are currently being used for testing, and these are capable of inhaling all of the HF spectrum at the same time - but there is not yet "WebSDR" software that will satisfactorily make this full spectrum available to hundreds of users, simultaneously. Having said that, there are WebSDRs now in operation that use a single RX-888 for all of the received bands.
16 bits isn't enough! Finally, any RF acquisition system that "inhales" the entire band from 0-30 MHz all at once - even if it uses a 16 bit A/D converter (most don't!) - can have significant issues related to signal dynamics: If it is adjusted to "hear" the weakest (sub-microvolt) signals, it will likely overload on stronger signals elsewhere in the RF spectrum. In the case of a "direct sampling" radio like the Icom IC-7300 or IC-7610 they get around this by having filters that lets only a small "window" of spectrum through at once along with dynamic gain control: Neither of these may be done if you have many users at random frequencies scattered across the entire HF spectrum! There are ways to mitigate this issue with appropriate filtering and signal level management - use the contact information on the bottom of the "about" page for more information.

"How about more bands. I want more bands!"

We already have coverage on the 2200, 630, 160, 80/75, 60, 40, 30, 20, 17, 15, 12, 10, 6 and 2 meter amateur bands - plus the 120, 90, 60, 75, 49, 41, 31, 25, 19 and 13 meter SWBC (Shortwave Broadcasting) bands along with the AM broadcast band: What more do you want? (No, really - let us know!)

"Why can't I use the 'Pocket TX/RX' app with the Utah WebSDR?"

"Pocket TX/RX" (by Dan, YO3GGX) is an all-in-one app that allows the convenient use of many web-connected receivers and transceivers around the world - with the consent of those that actually operate these sytems.
We have been asked to consider allowing this app to use the Northern Utah WebSDR, but for the time being we have declined to do so. By its nature, the Pocket TX/RX app somewhat "abstracts" the user from the remote radio system itself. In other words, to the typical user, they consider the use of something like a WebSDR to be akin to using a feature of the app, but they may not realize that the remote radio system that they are using may also be user-supported that is unconnected to the app itself. In some cases, the operator of a WebSDR or other type of radio runs it as a hobby and simply "foots the bill" and has kindly allowed its use with this app - and we applaud them for their ability to do so - but doing this is simply not possible at the Northern Utah WebSDR considering the nature of the site, its location and necessary infrastructure and all of the ongoing maintenance ane expenses that such a system incurs.
We believe that such abstract use (e.g. using an app rather than the WebSDR itself) would reduce the probability that the user would know to help support the remote radio system being used by the application - be it a WebSDR or other type of remote radio. As you might expect, the support from any ads that might appear in the app would go to the author for the support of this fine product, but not toward the radio system that is being used. It is by direct user support that we can keep the lights on here at the Northern Utah WebSDR.

"Why doesn't CatSync work properly with the Northern Utah WebSDR servers?"

"CatSync" is a program that allows semi-automated integration of online receivers with operation of your radio. Its compatibility includes several online Web-type SDRs.
We occasionally get reports that CatSync doesn't work properly with the Northern Utah WebSDR WebSDR servers. In 2022 - once we became aware of this - we reached out to the CatSync author and with a bit of difficulty, we were able to work out the issue at that time. Since then, we've gotten occasional reports of the same issues, but are having problems communicating with the CatSync author.
It appears that the CatSync software may process the frequency as a string of an expected length rather than as a numerical value and the extra digit to the right of the decimal (e.g. 1Hz frequency resolution) throws it off.
As a work-around, you can add "?10hz" (excluding the quotes, of course) to the end of the URL to force a display with just 10 Hz resolution.
To be clear: We, at the Northern Utah WebSDR are not doing anything to intentionally break compatibility with CatSync or other, similar programs and we are willing to determine work-arounds if we are contacted by and get cooperation with users and authors of such software: We have no interest in purpsely "breaking" things for such software and rumors to the contrary are false.

System quirks and a few random things:

"Why do I keep hearing WWV/H in several places on the '60-49M'/'31-30M'/'19M' receiver(s)?"

These receivers uses an inexpensive "RTL-SDR" dongle which, with only 8 bits of A/D has rather limited dynamic range (in the 40-50dB range) making it prone to overload on very strong signals. The "WWV" problem, interestingly is not due to overload, but because there is too little RF getting to the receiver input. For example, with just 8 bits of A/D, one can have signals of +/- 127 or so - but during the daytime when the band is quiet the A/D converter is only "tickling" A/D readings of +/-2 to +/-4, which is equivalent of having an A/D converter with only 2-3 bits! The result of this is distortion, which is why WWV is appearing in several places. The only reason that it isn't worse than it is is due to the fact that the post-A/D sample rate is 2048ksps so the effective A/D resolution is improved due to oversampling and the presence of noise - but this can only go so far to help the situation.
The work-around (aside from getting a "better" receiver) would be to increase the antenna RF into the receiver a bit - but this is a delicate balance: Too much signal and the receiver overloads - so the proper balance that will suit widely varying signal conditions is difficult to find on a receiver with dynamic range issues.
Interestingly, it takes quite a bit A/D clipping (e.g. hitting full scale) to have a significant effect on overall performance so it's a bit better to put a little bit of excess signal into a receiver like this than it is to put too little. Finding the best balance between "underload" and "overload" takes a bit of ongoing work, experimentation and continuing vigilance.
As of February 26, 2019 the RF paths to the 60-49M and 31-30M receivers (as well as the 90-80M and 41-40M) have some experimental circuitry that it is hoped that will eke more performance out of the limited RTL-SDR dongles by allowing higher signal levels into these receivers (to help when conditions are poor) as well as to automatically limit the levels when very strong signals are present to prevent overload.
As of September, 2023 the "60-49M" receiver that had been on WebSDR #1 (Yellow) was moved to WebSDR #3 (Blue) and a high-performance receiver was installed on WebSDR #1 that is immune to these issues.

"Why do the 31-30M, 25M or 19M receivers work fine at times and not others?"

Like the "60-49M" receiver, these use RTL-SDR dongles - with limited dynamic range. At the time of installation the RF input level was adjusted on a "best guess" basis - but we figured that experience would soon show us if this setting was too high or too low. Clearly, there are times, for example, when the 31M shortwave broadcast band is filled with high-power broadcast signals that the setting was "too high." In time we'll do further analysis and tweaking - and if there is enough interest, possibly implement a separate, high-performance receiver just for the 30 meter amateur band.
As mentioned above, some experimental circuitry has been installed to improve the dynamics of some of the receivers. If this works out well, more bands will be equipped with these devices, improving their performance as well.

"What are those (faint) lines that I see on 160 and 80/75 meters during the day?"

During daylight hours the 160 and 80/75 meter bands can be extremely quiet which means that very low-level signals can start to appear. On these bands some lines - usually faint - often show up and these are due to intermodulation products of AM broadcast stations. This effect is likely due to nonlinear junctions that intercept the energy, mix together and then re-radiate and this could be from long runs of rusty and/or corroded metal such as runs of barbed-wire fence (of which there is a lot near the antenna!) or imperfect connections on the antenna itself and/or its supporting structure.
At night these signals tend to disappear, probably due to a combination of many of the AM broadcast stations that run 50kW during the day lowering their power at night, but more likely due to the fact that these bands get much noisier at night owing the reduction of ionospheric absorption, the greater number of signals and the fact that noise from all over can be more easily propagated to the receive antenna.

"Where is 'Yooo-Tah' anyway?"

I 'dunno - it's somewhere west of Denver and northeast of Los Angeles. I think that there's a big lake, a lot of seagulls, and some strange people that live there that make it hard to find good beer. Oh, there are mountains, too...

"I read about this site in Utah - you are using the large, steerable antenna there, right?"

There are two antennas on this site: A large log-periodic beam antenna and a larger, omnidirectional wire antenna on a taller tower that is not as easily seen, either from the highway or via Google Earth - and we are using the wire antenna.
The log-periodic beam on site is, as of 11 April, 2020, being used to feed the receivers on WebSDR #4, offering coverage of the 40-10 meter bands. This antenna is on a heading of 87° (true) and is NOT rotatable - and it NEVER will be. (Where would one point a rotatable antenna on a shared receive system, anyway?)

"Why are signals on the 2 meter receivers on the weak side?"

If you have listened much on the 2 meter receivers you might notice that signals "seem" a bit weak - and they are, and there are several reasons for this:

Most of the "busy" repeaters are in the Salt Lake City area, 70-80 miles (approx. 120km) away. That, alone, will cause the signals to be weaker than you'd expect for "local" signals.
The WebSDR site is only a few 10s of feet above the level of the Great Salt Lake, a vast area of brine and mud. As such, the signals from afar - even though many of them originate from mountains that are about a mile (1.6km) in elevation above the lake, propagate on a very shallow p angle above the ground which puts them squarely in a fairly strong "Fresnel Zone" where ground reflections can strongly affect signals. The same signals, if received from the top of nearby hills, will be 10-15dB (about 2 S-units) stronger.

To combat this a 5 element Yagi, pointed in the general direction of Salt Lake City, is used for reception. To further help, the receivers (RTL-SDR dongles) are preceded with a bandpass filter and preamplifier before splitting which helps, but there's only so much that one can really do!
In July, 2022 the 2 meter Yagi was relocated and placed some distance from the building (with computer noises, etc.) and at greater height (about 33 feet, 10 meters). This has significantly improved 2 meter reception, but that doesn't change the fact that this site is rural!
While the FM audio on the WebSDR was originally a bit on the low side and sounded tinny, we have implemented code (mentioned above) that provides proper de-emphasis and filtering of subaudible tones.

"Is the 6 meter receiver deaf or something - and what are all of those lines?"

Yes and no. The 6 meter antenna, a full-sized J-pole at the building, receives a bit of noise from the computers within and the nearby power lines without, but the receiver itself can pretty easily "see" that noise floor, so additional receiver sensitivity wouldn't actually help.
Remember that 6 meters isn't usually open. In order to hear signals on that band one will have to hope for Sporadic-E propagation or some other type of event that will "open" the band. Sporadic-E is somewhat seasonal and generally unaffected by solar activity or the lake of it. It is most likely to occur in May-June and to a lesser extent, late December and early January. During periods of low sunspot activity it often "seems" as though there are fewer Sporadic-E openings, but with fewer people using the higher bands (10-15 meters) and the curtailment of analog TV in North America (which removed useful signals that could indicate propagation) the activity may be lower. To be sure, some 6 meter propagation is strongly correlated to sunspot activity and being at a low point in the 11 year cycle doesn't really help.
If you want to use the WebSDR to check for signals on 6 meters it's recommended that you listen/look at the CW beacon portion of the band (50.06-50.08 MHz) and in the area where FT-8 and other digital modes are active (50.293 MHz USB for WSPR, 50.313 MHz USB for FT-8).
In July, 2022 the 6 meter antenna was replaced and located and placed some distance from the building (with computer noises, etc.) and at greater height (about 42 feet, 13 meters) significantly improving reception.

KiwiSDRs at this site:

Important: Please use the WebSDR and not the Kiwis on frequencies/bands that are already covered by the WebSDR for casual use. Read on to find out why.

See also the KiwiSDR FAQ - link

"I should be using those Kiwis instead of the 'old' WebSDR, right?"

NO! Before you use a KiwiSDR, please consider the following:

If you are listening on the amateur bands using modes that are covered by the WebSDR, please use the WebSDR instead!
The WebSDR takes less bandwidth on your Internet connection and lower processing power on your computer - plus it is known to work on many different operating systems such as Windows, MAC and Linux - plus it will also work on most portable devices, Android or iPhone.

The KiwiSDR will probably never work properly on many mobile devices, owing both to the vagaries of what is supported by those platforms and the typically-small screen that makes the design of a useful user interface difficult.
The KiwiSDR will likely never support the Internet Explorer browser - sorry.

"If KiwiSDRs are so wonderful, why not use those instead?"

As it happens, the "high performance" receivers at the WebSDR are more capable (in terms of signal-handling capability, overall sensitivity, etc.) than the Kiwis because they have 16 bit analog-digital conversion with strong filtering over a rather narrow frequency range. In contrast, the KiwiSDR units have only only 14 bits of A/D conversion and it's being hit with the entire spectrum from 0-30 MHz, more or less. The lower bit depth and wider frequency input of the Kiwis tends to reduce its performance - often in subtle ways, particularly in the presence of other strong signals (including noise) that can (often) subtly mask the desired signals.
The KiwiSDRs can handle far fewer users. Originally, they were able to handle just 4 users, each user getting a waterfall display, but latter versions of the software have introduced an "8 user" version, with the trade-off that only the first two users get a full-spectrum waterfall. In comparison, the WebSDR systems can handle at least 90 users each - probably more!

"Are there other KiwiSDRs out there?"

Yes, there are - go to kiwisdr.com/public to find a list of publicly-accessible KiwiSDRs and to rx.linkfanel.net for a worldwide map.

"I hear tell about these other receiver things at this site - what are those?"

You are probably talking about the "KiwiSDRs" that are co-located at this site. These are WebSDR-type receivers that are capable of tuning from 0 through 30 MHz and able to receive a wide variety of modes, but one should continue to use the "old" WebSDRs for the bands/modes supported by them.

"I noticed that something is always hogging a bunch user slots on the KiwiSDR - why is that?"

The KiwiSDRs are used by another server on-site (WebSDR3, actually) to acquire audio on the frequencies of WSPR transmissions. This audio is then processed by the server and the WSPR reports are automatically forwarded to the wsprnet.org web site, identified by the call sign "KA7OEI-1".
The automated WSPR slots do not utilize any of the waterfalls that are available, so you don't have to worry about that.

"The waterfalls seem a bit slow - what causes that?"

The waterfall is a bit slower on these Kiwis than some others because:

The internal communications rate between the FPGA (the main number crunching chip) and the computer had to be dropped from 48 Mbps to 24 Mbps to avoid causing (terrible!) interference to the 2 meter receivers at the WebSDR.
The more people that are using the Kiwi, the slower the waterfall will get owing to less available processor time.

"The Kiwi kicked me off/won't allow me to log in - why?"

At present, the Kiwis will limit the duration of any single listening period to 30 minutes and 90 minutes during any 24 hour period. Because these receivers are a scarcer resource than the WebSDR, there are stricter time limits on their use.
If there are too many receivers already in use, it will give you a message saying so.
Having said that, there are several Kiwis on site and if one is "full", it should forward you to the next one automatically - assuming that there are receive slots available. It is possible that if many people are using the Kiwis at once that you will not get the full-spectrum waterfall, but rather a limited-range waterfall that shows only the audio spectra being received by you, after any filtering.

"I tuned below the AM broadcast band and don't hear squat. I thought you said that it would go down to 0 Hz?"

While the receiver can go down to nearly zero Hz (more like 5-10 kHz, actually) there's no guarantee that the antenna will! On the Northern Utah WebSDR the antenna being used is designed for the 3-30 MHz range and while it works for receive below this, it pretty much runs "out of steam" by the time one gets to 300 kHz or so.
A dedicated LF/VLF antenna has been incorporated into the system to allow the KiwiSDR to hear LF and VLF in addition to HF: This "other" antenna cuts in below about 350-400 kHz allowing the entire "NDB" (Non-Directional Beacon) band to be heard, plus other signals that reside below 100 kHz.

"Why won't the stupid thing work with my browser?"

As noted elsewhere, do not expect these to work properly with any portable device like an Android or an iPhone owing to the peculiar and changing needs of these devices: It would take a lot of work for someone to constantly update things to keep them working!
It will not work with Internet Explorer - and probably never will for the same reasons as above.
Modern, mainstream browsers should work such as Firefox, Chrome and (probably) Safari. If you have trouble, try one of those before you try something "different".
If you have your security settings adjusted too high, certain parts of the browser may not work.

"What other things will the KiwiSDR do?"

Besides being able to tune all over the place, the Kiwi can do things like decode RTTY, CW, FAX and WSPR - to name but a few. The KiwiSDR FAQ has a bit more information on what the receiver can do.

How do I connect to a KiwiSDR at this site?

Go to kiwisdr.com/public to find a list of publicly-accessible KiwiSDRs and to rx.linkfanel.net for a worldwide map - including the KiwiSDRs at the Northern Utah WebSDR site.
You can connect to the KiwiSDR system at the Northern Utah WebSDR using this link. Again, please refrain from using a KiwiSDR for a frequency that is already covered by the main WebSDR servers!

The KiwiSDRs have many more features than can possibly be covered here - please read the KiwiSDR FAQ at this web site as well as the KiwiSDR Quick start guide (link) and follow some of the links within for more information than you probably want.

Additional information:

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

For the latest news about this system and current issues, visit the latest news page.

For technical information about this system, go to the technical info page .

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