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
about the WebSDR, check out the Q&A below to see if it's
been answered. Below are main topic headings -
click on one to jump to it - or just peruse the entire page.
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. While
some ads on the page, these provide enough to pay the power bill - but
not much more, so we need to come up with extra $$$ to fully cover
things like rent and maintaining the equipment or getting additional
gear for upgrades.
- "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"
In short, to provide a service to the amateur radio
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
- Again, You can help us pay the bills: If you can, please donate $$$ to help keep this WebSDR
system online by going here
amount is appreciated - large or small.
- At the present
time, the cost of the equipment and ongoing expense is being borne by a
small number of individuals who have donated time, money and materials
to get the system off the ground. Going forward, recurring
expenses such as electrical power (we
are the only users at this site!)
and additional needed for maintenance and upgrades will continue.
Weird noises and
other things on the bands:
- "What's with the 10 meter CW beacon?"
June 25, 2020, a CW telemetry beacon was added to the site,
transmitting on approximately 28.570 MHz, +/- 1 kHz. This beacon's
antenna is (literally)
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".
- 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.
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.
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
A real-time lightning map (blitzortung.org)
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?
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,
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
to the question above - also see Figure
- Those are most likely static crashes - and that's what
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
(160, 80/75, 40) and is notably weaker on the higher bands.
- During the winter there are fewer thunderstorms across
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
beehive is a symbol of industry as used in the "highly productive and
busy" sense. A suspiciously similar-looking beehive -
with bees flying about and sego lillies - may be seen on the great seal
of the state of
- Somewhat amusingly, it is illegal in the state of Utah to
use a skep - that traditional-looking dome-shaped beehive.
reason for this seems to be because these structures originally did not
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
- 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?"
- We think that those are coastal wave profile radars used
analyze the ocean swells. A Wikipedia article on these types
systems - and links to more information - may be found here: https://en.wikipedia.org/wiki/Wave_radar
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
the quality of the refractive properties and the MUF
can be dynamically tracked. By sweeping the frequency, the
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
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:
This is an example of IMD showing up on a "clean" 40
signal. The signal is peaking about 10dB over S-9 with a
bit of QSB. The noise floor is about S-4 meaning that the
of this signal are about 40dB above the noise. Just to the
of the signal (between
7250 and 7251)
one can see some energy that is related to voice peaks.
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
There are two other signals in the waterfall above: A weak
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
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.
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
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
- 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
naturally make the IMD higher because the contribution of the rig is
added to that of the amplifier itself. What this means is
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
- "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
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,
Why? It could be OCD, or it could just be that it's
to remember a "whole kHz" frequency that ends with zeros.
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
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
- "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, 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 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
- 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
- "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
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
off, it will ignore the Internet time until you manually
set the time and get it "close" to the correct time and
- "What about
those labels under the frequency scale/spectrum display?
Where do those come from?"
- There are two
types of labels under the display:
labels: These are added by the sysop to indicate
things like band edges, frequencies for various modes, certain stations
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
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.
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
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.
- "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
such sucky filters?"
- Based on feedback, many WebSDR users listen casually to
and roundtables rather than try to dig weak signals out of the noise.
Because of this, the "default" LSB and USB filters are wider
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
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
- If you own a radio made within the past 30 years you
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
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,
- 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
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!
If you click any of the "USB" or the "LSB" buttons
setting a custom bandwidth that it will reset them to the default
- "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
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
that you NOT
use this "Autonotch" feature when receiving CW signals as this will
dutifully remove them!
- Note that this "autonotch" seems to be able to notch only
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
- "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.
- "Some WebSDRs
have a 'chat' function, but not this WebSDR - why is that?"
- Past experience by other WebSDR operators have shown that
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
- Seriously, have you actually met
people!?! Are you surprised about this??? Really?!?
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
assigned to the browser are reduced. The WebSDR uses
scripting running on your
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
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
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
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
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:
Internet connection may be busy.
If you - or someone else - is watching video, downloading
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
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
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
ways to minimize this issue, but bad jitter can - and does - happen at
Internet may just be "busy".
As you can guess, there are times of the day when there is
more traffic on the Internet than at other times - the local evenings
being just one example. This can lead to congestion,
packet "jitter" and even the occasionally "lost" packet.
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
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:
- This is 1/8th of a second - the lowest amount of buffering available.
This setting may work well much of the time, but it
actually be a bit marginal for a wide variety of network conditions,
which is why it is not the default.
- 0.25sec - This is the
"default" setting with approximately 1/4th second of built-in buffering
to allow for slight network jitter.
- 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
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
- 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.
- 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.
Increasing the buffering will not only add delay between the
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
disabled audio playback, but we have a web page just for this situation
- read more by going to the "Fixing Chrome"
- If you wish to use Chrome with your mobile device (phone, tablet) I
strongly suggest that you, too, read the "Fixing Chrome"
- In early September 2018 a new version of Chrome was
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.
problem with the noise/waterfall issues was fixed with a mid-December
2018 release of Chrome. If you have this problem, please
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 first thing to check is to see if you have an
out-of-date browser and/or computer. There are some functions
the code embedded into the web page that require "new-ish" browsers (e.g. newer than about
- Your computer/browser may be blocking scripts:
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
- Your network may be blocking something. The
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.
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
is done by pressing and holding the "ctrl" and then hitting "+" (plus)
key. For this you can use the "+" key on your numerical
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
"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)
- 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.
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
button near the volume control on the WebSDR. If you click
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 -
along the top row - that, when pressed, will toggle the speaker audio
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
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
icon can be visible even if you have hidden the window with the WebSDR.
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.
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
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
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?"
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
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
- 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
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
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
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
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
- Try using a different
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 Chrome browser 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". This should (hopefully) enable the audio.
- If you continue to have problems, visit this page for suggested work-arounds.
"Why is it this
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
- In July 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. Ideally, we would
like to make the link at "websdr.org" go right to the landing page, but
because of the way that page gets and presents its information, it can
only direct users to the actual WebSDR server and not the landing page.
- "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
I see that there are several different WebSDRs, each in a different
location on the map, very close to each other. What's the
- 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"
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
- "What's the
deal with 'high performance receivers'? Are there 'low
- There are two classes of receivers on the Northern Utah
Performance" receivers that are relatively
narrow-banded (96 or
192 kHz wide) that use high-performance sound cards and
mixers 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.
- Those that are not "high performance" receiver use
"RTL-SDR" dongles. The dongles are attractive in that they
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
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
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
"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 - as in the case
31M-30M and the 15M-13M bands. This was done because there
anything of particular interest immediately outside this
frequency range, the receivers work slightly better
with reduced coverage - and running them at less than 2 MHz bandwidth
reduces processor loading.
- "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'?"
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!
- "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
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.
- Examples of this spurious response are
on 20 meters where a strong signal on, say, 14190 may also appear
around 14000 - 192 kHz below. In radios that use sound cards
their input devices (e.g.
most modern Elecraft transceivers)
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 is 160
meters covered on two separate receivers?"
- You may have noticed that there is not only
receiver marked as "160M", but another, "lower performance" receiver
marked "AM-160M-120M" that also
includes the 160 meter band. When the Northern Utah WebSDR
originally put online there wasn't enough equipment on-hand to cover
more than the bottom 96 kHz or so of the 160 meter band and the
remainder of the band had to be covered by the lower-performance
- Since then, we've updated the system to include the
192 kHz of the 160 meter band, so it's almost
completely covered, but
we still cover it with the other receiver - which also includes the
120 meter "tropical" shortwave broadcasting band and 2.5 MHz WWV/H.
Anyway, Murphy's law says that if you really
need to listen to something on 160 meters, it will be in that top 8 kHz
or so that the "main" 160 meter band isn't covering.
the 630 meter band was covered with a band marked "630M-AM-160M" but a
dedicated 630 meter receiver has been installed that offers superior
performance over the
incidental coverage that had been available on on the "630M-AM-160M"
- "What's the
difference between '75' and '80' meters - isn't that the same band?"
- Both "75" and "80" meters refer to the 3.5-4.0 MHz
amateur band - and
the reference is somewhat historical: Decades ago, only the
half (or so)
of the band was available for phone operation (in the U.S.)
and if one does the math, the top end of the band - 4.0 MHz - comes out
at exactly 75 meters. The distinction was that "75 meters"
referred to the phone portion and "80 meters" referred to the CW
- More recently, phone operation for U.S. (Extra class) amateurs
has been extended to 3.6 MHz, well into territory that was once the
sole domain of CW and digital.
Although historical, the convention remains: "75"
usually refers to the phone portion and 80 meters to the CW
- On this WebSDR the designation of "75 PH" ( for 75 meter phone)conveniently
takes advantage of this nomenclature referring to the top
portion and "80 CW"
being the bottom of the band - although this last segment also includes
the very bottom portion of the phone allocation while "80 PH" refers to
the middle of the band that once was mostly the domain of CW.
- "I noticed
that both 80/75 and 40 meters are covered on two separate
servers - on the 'main' server (WebSDR
#1 - Yellow) and the 'blue' one - WebSDR3. Why
did you bother doing that?"
- You may have noticed that the vast majority of our users
80/75 and 40 meters: If we had "only" those two bands on the
entire system, we'd still
get a lot of use. Because the WebSDRs are running on
computers that are not easily accessible (e.g. quite a way to drive)
it would make sense to have a back-up of the most popular bands:
If WebSDR #1 (the
Yellow one) were to go offline, we could point users to
WebSDR #3 (the blue one)
and it is likely that most could carry on as normal.
- These "back-up" 80/75 and 40 meter receivers use somewhat
inferior hardware (RTL-SDR
and as such, their performance isn't as good as the "normal" receivers
- but this is likely to be noticed by the casual user only in the more
severe case (e.g. very
weak signals all over due to poor conditions or lots of
strong signals when the band is doing well and many signals are present
- such as what one wishes for in a contest.)
- Because the RTL-SDR devices can cover 1-2 MHz of
was decided to include those shortwave bands adjacent to 80/75 and 40
meters - namely the 90 and 41 meter shortwave broadcast bands,
respectively because... why not?
- "Why are
there several servers rather than all bands being on the same server?"
WebSDR software is designed to allow only up to 8 bands at once, so
additional bands must be hosted on other servers.
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.
multiple servers also allows lower-performance (and less-expensive)
computer hardware to be used. As it turns out, we have access
a large number of PCs of modest computing power for free, so we are
- "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
several changes have been made to the scripts that make everything
work. Several of which have already been mentioned, but here
are again - at least the ones that I remember doing!
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).
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.
"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.
"dBm" to the S-meter scale: Because the meter's
numerical value reads in dBm, I thought that this should be on the
There are more settings than standard WebSDRs to choose from.
As noted on the main screen, the "default" settings are in
font. Note that some of the "defaults"
on this WebSDR are different from the original values.
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.
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.)
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.
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.
The code for zooming in has been tweaked so that the
which the receiver is tuned stays within the spectrum display.
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
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
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.
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
"brighter" for weak signals. In the original code, if the
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.
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.
- 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.
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
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
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.
- One thing that we'd like to be able to leverage is the
that we already have, for many of the amateur bands, "raw audio" of 96
or 192 kHz bandwidth that could be sent over the local network to
another server for such processing, independent of the existing
receivers - but this will take a bit of research and work to set up.
Whatever we do, we don't want it to have an adverse impact on
existing system. Having said this, there are many "hooks" in
system that could allow separate receivers to be implemented.
- 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".
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
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.
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
on modes like CW or PSK31 where characters can be occasionally missed,
in timing can completely mess up the reception of WSPR, JT-9 and FT-8
transmissions, either degrading them or completely wrecking their
- 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) and
without a "front end" using a GPU or FPGA this task is arguably beyond
the capability of almost any multi-core, multi-GHz computer that is
hardware, while commercially available, is still quite expensive - as
in the thousands
of dollars. Because of this, the support by the
WebSDR program is largely for acquisition methods that use relatively
inexpensive, consumer-grade, off-the-shelf hardware like sound cards or
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.
- 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
issues related to signal dynamics: If it is adjusted to
the weakest (sub-microvolt)
it will likely overload on stronger signals elsewhere in the
RF spectrum. In the case of a "direct sampling" radio like
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
random frequencies scattered across the entire HF
- "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:
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 connectivity to many web-connected
receivers and transceivers around the world - with the consent of those
that have these resources.
- We have been asked to consider allowing this app to use
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
from the actual resource. In other words, to the typical
they consider the use of something like a WebSDR to be using a feature
of the app, but they may not realize that the resource that they are
using may also be user-supported. In some cases, the operator
a WebSDR or other type of radio runs it as a hobby and/or simply "foots
the bill" and has kindly allowed its use with this app - and we applaud
them for their ability to do so.
- We believe that such abstract use would
reduce the probability that the user would support the actual system
being used by the application, be it a WebSDR or other type of remote
radio. As you might expect, any ads that might appear in the
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.
quirks and a few random things:
- "Why do I
keep hearing WWV/H in several places on the '60-49M'/'31-30M'/'19M'
- 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
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
so the proper balance that will suit widely varying signal conditions
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
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
- "Why do the
31-30M, 25M or 19M receivers work fine at times and not others?"
the "60-49M" receiver, these use RTL-SDR dongles - with limited dynamic
range. At the time of installation the RF input level was
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
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.
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
extremely quiet which means that very low-level signals can start to
appear. On these bands some lines - usually faint - often
and these are due to intermodulation products of AM broadcast stations.
This effect is likely due to nonlinear junctions that
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
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
- "Where is
'dunno - it's somewhere west of Denver and northeast of Los Angeles.
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
- "I read about
this site in Utah - you are using the large, steerable antenna there,
- There are two antennas on this site: A large
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
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
70-80 miles (approx.
120km) away. That, alone, will cause the signals
weaker than you'd expect for "local" signals.
- The WebSDR site is only a few 10s of feet above the
the Great Salt Lake, a vast area of brine and mud. As such,
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
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)
- To combat this a 5 element Yagi, pointed in the general
direction of Salt Lake City, is used for reception. To
help, the receivers (RTL-SDR
are preceded with a bandpass filter and preamplifier before splitting
which helps, but there's only so much that one can really do!
- The FM audio decoding in the WebSDR software is a bit low
- and it seems to lack the "de-emphasis" (rolling off of "highs")
found in amateur FM receivers to make weaker signals "sound" a bit
cleaner. These two factors combine to produce "tinny" audio
rather low levels, requiring one to increase the volume a bit.
Additionally, subaudible tones that might be being
may be heard as a low-frequency hum as they are not being filtered out.
- "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
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
- Remember that 6 meters isn't usually open. In
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
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
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
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).
- Those lines? We think that these are from all
computers located in the building. At some point we may try
relocate the 6 meter antenna which should reduce the power line noise
and the weak spurious signals from the computers.
KiwiSDRs at this site:
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?"
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
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,
user getting a waterfall display, but latter versions of the software
have introduced an "8 user" version, with the trade-off that only the
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?"
- "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
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
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.
waterfalls seem a bit slow - what causes that?"
- The waterfall is a bit slower on these Kiwis than some
- 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
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
- "The Kiwi
kicked me off/won't allow me to log in - why?"
- At present, the Kiwis will limit the duration of any
listening period to 30 minutes and 90 minutes during any 24 hour
period. Because these receivers are a scarcer resource than
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
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
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
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
- 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
The KiwiSDRs have many
more features than can possibly be covered here - please read the KiwiSDR
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
- For general information about this WebSDR system -
including contact info - go to the about
- For the latest news about this system and current issues,
visit the latest news
- For technical information about this system, go to the technical
info page .
Back to the Northern Utah WebSDR
- 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