Northern Utah WebSDR
Latest News and current issues
Recent events and resolved issues:
21 September, 2018. Comments:
Sedona, AZ WebSDR shut down: After
about 6 years of operation, Steve, W7RNA has shut down the Sedona
WebSDR. Steve says, "...I have taken down the WebSDR at Sedona.
Except for daytime regional coverage in Arizona and New Mexico, KFS and
Utah WebSDRs cover the West so very well now, that I thought this was a
good time to turn off Sedona as being effectively redundant.
The existing W7RNA links now forward to the two year old Kiwi SDR at the
same location. As you probably know, the Kiwi is limited but it can
still serve Arizona and New Mexico for the few users that still may need
it during the day on 40 and 80m."
Intermittent network slow-downs:
Our rather long-length wireless internet connections are
sometimes showing down connectivity - but these "slowdown" periods seem
to last only an hour or so. We're doing what we can to figure out
a way around this.
10 September, 2018. Comments:
Network Outage: On the evening of September 9 (local time)
the combination of bad weather, a bird's nest and faulty insulators on
the power line that feeds one of the microwave sites that provides
Internet connectivity to the Northern Utah WebSDR disrupted operations
when that site lost power for several hours. While the back-up
battery at that site held for a time, the duration of the outage
exceeded its capability while the local utility crews worked late into
the night to replace the failed hardware. The duration of the network outage was approximately 3 hours and 45 minutes.
Expansion of WSPR decoding capabilities:
On 8 September reconfigurations made it possible for up to 12
simultaneous "bands" to be used for receiving and decoding HF WSPR
transmissions but only 8 or 9 channels will typically be used at one
time. This is done by using an on-site computer (WebSDR3, actually)
to make local network connections to the on-site KiwiSDR receivers and
pull audio from them from virtual receivers tuned to the WSPR
frequencies (these show up as a user called "kiwirecorder.py")
which are saved as files and then processed to recover the WSPR
transmissions. As a reminder, the KiwiSDR receivers can each take
up to 8 users, but only the first two users on each will get a
full-bandwidth waterfall display: These recording channels do not
use any of the waterfall capabilities. The results of this effort
may be seen at the wspernet.org site
with the contributor being "KA7OEI-1". It is hoped that future
effors will enable things like contributions to the RBN (Reverse Beacon Net) and similar.
17 September, 2018. Comments:
the past several months we've been having issues with the wireless
Internet connection to the WebSDR spontaneously "re-training", causing
an outage of between 30 seconds and 5 minutes. The reason for
this seemed to be something amiss with the firmware on the radio link
between the WebSDR site and the next point on the network. We think that this problem has been resolved after firmware/hardware updates.
problem occurred a few weeks ago when one of the main wireless trunks,
which had been been capable of passing up to 1 Gb/sec of traffic
suddenly decided that it would only negotiate to 100Mbps. During
the "off" hours of the day this wasn't so much of a problem but since
the peak traffic on the network could be over 350Mbps, dropped packets
and audio issues could result. This "bottleneck" has been
fixed as of about a week or so ago: We were just watching it to
see if it was really fixed before updating this and the main WebSDR pages.
We have identified the suspect poles and passed the information
to the power company. All we can say is: "They will fix it
when they do."
The "warbly": As noted in the 30 June, 2018 entry and the 9 June and 16 May entries there is a "warbly" that often shows up when the band is very quiet (e.g. 40 meters during the daytime) - one of its harmonics seeming to frequent the area near 7272 kHz, where the Utah Beehive Net meets. This is still
on our list to address, but again, it will take climbing to about 60
feet on a tower and pulling up excess service cable in order to add the
ferrite devices that (we think) should quiet a POE (Power Over Ethernet) device mounted there.
Occasional "crackle-crackle" on received signals - particularly the lower bands:
As noted earlier, one of the guy wires on the antenna will
occasionally touch an active antenna element when it is very windy.
We are trying to figure out how to access and insulate these two
conductors - but their being at about 80 feet (24 meters) up the tower doesn't make it easy!
A few instances of low-level QRM from miscellaneous switching power supplies: While not easily noticed (unless you knew exactly where to look) there are a few "birdies" from other switching power supplies on site - typically on the lowest band (e.g. 160 meters and below.)
Intermodulation on some lower bands (<=80/75 meters) during the daytime:
During daylight hours one may notice a few instances of
intermodulation distortion on some of the lower-frequency bands,
particularly below 2 MHz. Much of this energy appears to be
re-radiated from rusty barbed-wire range fencing surrounding the
receive site but it's possible that at least some of it may be
happening in the receive antenna itself and even some of the RF
distribution. Practically speaking, this hasn't been much of a
priority to fix because:
The majority of the strong signals (several of them 50kW stations)
are reduced in power at night in accordance to conditions of operation
imposed by the FCC to minimize their interfering with other stations.
At night, these bands (80/75, 160, 630, etc.) become
more "alive" and compared to the daytime, the background noise actually
increases, drowning out the intermodulation products that might
otherwise be audible even after the stations reduce their power at
9 September, 2018. More problems with the Chrome browser!
It would appear that a very recent update to the Chrome web browser (such as 69.0.3497.81) has caused yet another audio problem: Sudden, loud crashes of noise - or one may hear only white noise, particularly when first starting the web page.
While muting/un-muting on the WebSDR itself may correct this, the effect will probably be temporary.
There's no known work-around yet so it's recommended that you use a different browser: Firefox works well and is recommended!
If you are doing casual listening on the amateur bands, PLEASE use the main WebSDRs instead! The reason for this is that the main WebSDRs can handle dozens
of users at once, but the KiwiSDRs can handle, at most, only 8-10
users. Most of the receivers on the main WebSDRs are better
performance than the Kiwi, anyway.
These receivers are configured to allow "roll-over" so that if all of the receiver channels on the first (main) one are occupied, it will forward to the second.
Each of these receivers is configured in the "8 channel" mode which means that only the first two
receiver instances will have a full-bandwidth waterfall. At some
point in the near future the "other" receivers may get a more limited
Each of these receivers have several channels dedicated for WSPR use and are not
available for general use showing up on the WSPRNET web site as "ka7oei-1" and "ka7oei-2" for units 1 and 2, respectively: These WSPR-only "receivers" do not
utilize any of the limited waterfall capabilities. Clicking on
the Kiwi's USERS tab will show the current status.
this moment, casual users are only allowed 90 minutes total use during
any 24 hour period: Abuse or lack of it will dictate the need for
any adjustments either way.
KiwiSDRs use the same omnidirectional antenna as the main WebSDR system
so receiver performance should be pretty much identical to other receivers covering comparable frequencies.
The KiwiSDRs do not work with Internet Explorer (and never will) and do not count on them working properly with mobile devices!
are a number of "extensions" that allow reception/analysis of various
types of signals, including RTTY, FAX and WSPR. There is also a
"TDOA" feature that can help one determine the geographical location of
a particular signal - but there is a bit of a "learning curve" in using
it - I would strongly recommend reading EVERYTHING in the "help" tab that appears - and the linked page(s) - when you invoke the TDOA mode. Remember: RTFM! (such as it is..)
The features and configuration of the KiwiSDR receivers WILL CHANGE over time as software evolves and as circumstances warrant.
8 August, 2018. Comments:
outage of approximately 60 minutes duration occurred due to power loss at one of the wireless Internet link(s).
The "idle" time of the WebSDRs (e.g. you, the user not interacting) has been increased from 60 minutes to 90 minutes for WebSDR #1 (yellow) and WebSDR #2 (green) and 120 minutes for WebSDR #3 (blue).
There is an intermittent power
line related noise that occasionally shows up - and we are working to
resolve this issue - but the system's noise blanker seems to be able to
remove most of it. This noise is typically the worst on 80/75
meters, but it seems to disappear at night as the band opens up and the
ionospheric noise submerges it. Several poles have been identified
drop-outs: There have occasionally
been periods where the audio will drop
and/or the waterfall will freeze briefly. This is due to
occasional network drop-outs/queuing and may have several causes - some
of which have already been addressed. This issue is being
analyzed and worked as it appears, but most of them are likely to be
due to your
network and/or computer getting busy for brief periods - see "Miscellaneous Quirks",
below for some causes and work-arounds.
"pop" in the audio and an accompanying change in signal level:
There appears to be an intermittent cross-connection on the
antenna between a feed and guy wire that can cause noise in the
received signals and levels to
fluctuate during very windy periods on site - particularly on the
80/75 and the 630M-AM-160M) bands. A
similar-sounding - but unrelated - issue (described below)
exists with the AM demodulator. Occasionally, this
seems to be accompanied by an increase in
intermodulation distortion from AM broadcast band signals - a problem
that can affect the 75 Meter and lower-frequency bands.
shifts in baseline RF signal levels:
It was noted that signal levels would occasionally shift by
6-10dB across the board. It is suspected that there is an
intermittent connection in an RF jumper cable: A brief site
was made where connections were shaken and after several brief
drop-outs, the signal levels remained solid. The various
connectors/jumpers involved will be closely inspected during the next
site visit. This problem is related to that mentioned above
and can be observed during windy periods.
outages: We are working to
"neaten up" the installation so we occasionally have to take something
off line to dress a cable, replace a connector, "permanentize" an
installation. Tasks like this will cause outages of several
minutes duration. Some work is also being done at one or more
the interim sites that provide the Internet connection that
occasionally result in outages.
Low-level switching supply "birdies":
With lots of computers comes the possibility of lots of QRM from
them! Fortunately, there are no "strong" birdues, but there are
some that, if they happen to sweep across the frequency to which you
are listening, will cause some mild annoyance.
quirks (e.g. "It's
supposed to be that way!"):
If the WebSDR
is not on an active window on YOUR computer: If
the WebSDR is not the currently active
window on your desktop, the computer will give it lower priority and
this will make audio drop-outs/waterfall freezes more common.
same thing can happen if your computer is "busy" doing something else,
such as other programs, updates, incoming emails, etc. The
same is likely true
with other platforms (phone,
first thing that you should do if you experience drop-outs is to switch
to the window running the WebSDR. Don't forget
that your own
Internet connection/ISP can result in drop-out issues as well.
has been observed that on a typical Windows machine, if the processor
utilization is over 65-70%, you may experience occasional drop-outs due
to delays in the operating system providing processor time to the code
that produces the audio and draws the waterfall.
updating when you switch to another window: When
the waterfall is not visible (that
is, you have switched to a window and moved the one with the WebSDR in
it will stop - which makes sense if you can't see it. What
means is that when you switch back to where the waterfall is again
visible there will often be a clear line of demarcation between what
the signals were when you switched away and when you switched back.
burst of noise across the band correlated with strong signals:
This is sometimes the result of the noise blanker that is
on all bands being triggered by the peaks of the strongest signal(s) on
the band. This effect is most easily spotted on 40 meters
the daytime where there is one signal that is extremely strong - often
on the leading edge at the beginning of a transmission - and the band
is otherwise quiet. This effect should not be confused with
things that cause similar-looking artifacts, such as static crashes
from distant lighting storms or brief signals from ionospheric and
ocean wave profilers.
listening to AM, a sudden "pop" in the audio:
It's not actually supposed to do this, but there a "quirk" (bug?)
in the AM demodulator that can cause this to happen, occasionally.
It seems to happen mainly when the signal level changes very
quickly due to QSB (fading)
but is less likely to happen on very steady signals or those with only
very slow QSB. The only "fix" for this - if it becomes
is to listen on USB or LSB and zero-beat the carrier.
The bands on
the "other" server aren't visible to me unless I go to that "other"
server: It is this way because there are several
If you notice some issues that are unrelated to those
listed abovefeel free to use
the contact info on the About
page to let
us know about it. "Less-recent" events and
7 July, 2018. Comments:
who use the WebSDR on 80/40 meters during the day will likely have
noticed an elevated powerline noise floor: At night, this noise
is submerged in the normal background noise of these bands. Being
that the WebSDR site is an 80 mile (130km)
drive for me each way, I understandably try to limit the number of
trips that I have to take - particularly since it involves nearly three
hours driving and (at current prices) $30-$40 of gas for each round trip!
On this day I went to the WebSDR site and carrying a 2 meter AM/FM direction-finding receiver (a VK3YNG unit), a 3 element tape-measure beam, my FT-817, a battery, a 3 foot (1 meter) diameter
shielded H loop, a homebrew ultrasonic down-converter and a small
plastic parabolic dish with an ultrasonic transducer, I tromped through
chest-high (5 feet/1.5 meter) swamp grass in 102° F (39C) heat, following about 2 miles (3.2km)
of powerlines looking for noise sources. With this effort, three
power poles were found with very strong, vertically-polarized
noise (at VHF) and one of
these had just-detectable arcing noise at ultrasonic. I also
found a "corner" power pole on this 38kV line on which one if its
deadmen (guy wire anchor in the ground)
had completely pulled out in the direction of the greatest force.
Taking pictures of the suspect poles, these will be reported to
the power company: Particularly in light of the failed anchor, we
are hoping that they will do what they do to quash this type of noise.
25 and 19 meter bands' filters were analyzed in-situ and it has been
determined that over the 25 meter SWBC band, the image response
(centered at approximately 16.8 MHz) is attenuated by approximately
26dB while the image response in the 19 meter SWBC band (centered at
approximately 13.55 MHz) is attenuated by approximately 22dB.
Because of its proximity to the 14.4 MHz Nyquist frequency of the
RTL-SDR dongle and the finite "sharpness" of the band-pass filters, the image rejection at the 14.67 MHz CHU (Canadian time station)
is only about 8dB at the 14.13 MHz image frequency. While these
values are certainly mediocre, they are adequate for casual listening
on these bands and far better than many inexpensive "all band"
shortwave receivers of the past. I may, in the future,
modify/replace these filters with "sharper" versions with stronger
image frequency attenuation.
might be noticed that some of the 25 meter SWBC band images fall in the
22 meter SWBC band centered at approximately 13.75 MHz, which
correlates to 15.08 MHz. What this means is that some of the
stronger 22 meter SWBC signals are likely to appear in the lower
portion of the 25 meter receiver's passband.
3 July, 2018. Comments:
Michael was able to drop by the WebSDR site (he lives in the general area)
and adjustments were made to the 25 and 19 meter SWBC band receivers -
namely the gain block before the filtering was moved to the output of
the 19 meter filter and the signal path attenuation was adjusted for
both bands. Initial indications are that, at least for
moderate/good band conditions, the recievers should overload less often.
addition, the 19 meter receiver was configured for 1.5 MHz bandwidth
and it now includes 14670 kHz - the frequency of the Canadian time
station, CHU. Please note that especially below 15 MHz, this
receiver is prone to images from below and in the 20 meter amateur band
- the inevitible result of the Nyquist frequency of the RTL-SDR dongle
used occurring at 14400 kHz!
new deadman anchors with the tower in the background and the guys being tensioned. Click on the image for a larger version.
30 June, 2018. Comments:
New UPS installed:As noted in
the 12 June entry, the 500VA UPS failed unexpectedly (what otherkind of random
failure is there?)
and a "new" 700VA UPS was installed - not as nice as the "old" one, but
it should serve its purpose. At this same time a simple
switch (a mains-powered
DPDT relay in an electrical box)
was installed that allows us to change in/out other UPSs in the future
- and it will automatically switch the mains power, should the new UPS
fail, from the "A" source (the
UPS) to the "B" source (the wall socket).
The 25 and 19 meter shortwave
broadcast bands (SWBC) were installed: On WebSDR
3 (the "blue" server)
some RTL-SDR dongles with filtering were installed to provide coverage
of these two shortwave bands. While the levels were adjusted
appropriately at the instant that we installed them, it is clear that
we missed the mark and that the receivers sometimes overload very badly
resulting, at times, in a cacaphony if noise, overlapping audio signals
Please consider the
operation of the 25 and 19 meter receivers to be a work in process!As
noted on the "Technical Info" page, these RTL-SDRs, with there limited
dynamic range, required a certain amount of finesse to adjust properly
to accommodate the majority of weak and strong signal conditions.
These levels cannot be adjusted remotely so they will be
in" on future visits.
The 6 meter band (the bottom 1 MHz, anyway)
has been moved to WebSDR2 (the
"green" server):It would appear that the WebSDR
software (or, possibly,
our server hardware) will only "play nice" with a maximum
of 4 RTL-SDR devices. When we added the 25 and 19 meter bands
to WebSDR3 (blue)
the last receiver ("2M
would not initialize. For this reason we used the last
band slot on WebSDR2. It is configured identically to what it
been when it was on WebSDR3.
One of the power line noise
located: We think
that we found a power pole that is one of the sources of AC mains noise
that becomes apparent when the lower bands (80/75/40) are at
their quietest (e.g.
When we approached the pole in question it was noted to have
damaged insulator on one of the phases: We will report this
the power company. It is very likely that this is not the
only nearby power line noise source, but we have to start somewhere!
Internal gain blocks added to the
15 and 10 meter converters.
When the 10 meter converter was installed on 9 June it was
that it was "gain-starved", so a general-purpose external gain block (high-dynamic range amplifier)
was installed between it at the RTL-SDR dongle. A similar
was noted on the 15 meter converter so an additional gain block was
internally added to both the 15 and 10 meter converters and the levels
readjusted for best performance. This additional gain should
when the band is very "quiet", bringing the signals comfortably above
the receivers' noise floors.
We did not get time to further-address the "warbly" mentioned
in the 9 June and 16 May entries. To further reduce this
noise will require pulling additional Ethernet cable up the tower (the "other" tower, not the one
supporting the antenna that we are using at present) to
get enough "service loop" to be able to add enough inductance to the
cable to choke the common-mode energy. This warbly is audible
only during daylight hours when the band is quiet and line noise is
20 June, 2018. Comments:
Nearly 2 months ago the north
deadman of the "other" tower (not the one
supporting the receive antenna)
pulled completely out of the ground during high winds - the worst of
which usually come from the north at this location. In a
measure, one of the locals kindly parked his large, flat-bed farm truck
and attached the the guy wires to it until he got room in his schedule
to come back and replace the deadman - which occurred on this day.
Rather than excavating a hole
and setting the new deadman in concrete, long, thick-walled steel pipes
were pounded deep into the ground with a pile driver, the first
one (to which
the wires were attached) being belayed by another behind
it, connected by a piece of heavy pipe. This method - used to
tension many thousands of feet of fencing - has been used for decades
with good results. In the near future, the other two deadmen
will be similarly replaced although they appear to be sound... for
The "front" pole has, below
ground, a large "spade" attached to it to increase its stability and
"pull strength" in the soil.
While we won't mention up front
how much this is costing us, it's safe to
say that it wasn't cheap! It should, however,
prevent this tower from suffering the same fate as its twin which
failed in the very same way about a decade ago.
Now that we have
this tower, we are looking into what can be done with the antenna which
at 80 feet (24 meters),
covers from 6 to 40 MHz and is fixed(there is no rotator) on an
86° (true) bearing -
just slightly north of due east: We
have not yet climbed the tower with an antenna analyzer to determine
18 June, 2018.
Power line noise finding
various reasons, the "noise finding" trip that had been tentatively
scheduled for 16 June never happened. The noise persists, so
still have a trip planned to hunt it down - but it will have to wait
until after ARRL Field Day (22-23
June, 2018) as we have previous commitments.
Installation of the new UPS
postponed: This was going to be installed on the
same trip as above.
Slight gain deficit on 15 meters:
It would appear that there is a slight gain deficit on the 15
meter band. While it seems to be adequately sensitive to weak
signals, somewhat better performance could be had with another 6-10dB
of signal gain. This band is served with an RTL-SDR dongle
frequency down-converter (as
described on the RX Equipment
and as noted, the RTL-SDR units are both somewhat deaf and quite
particular when it comes to the amount of gain in the signal path.
On the next trip additional amplification will be put inline.
12 June, 2018.
4 hour power outage.
WebSDR servers and network gear were off for about 4 hours due to the
failure of the on-site UPS. While there was no actual power
CPU within the UPS seems to have lost the ability to measure its own
output voltage and it shuts off its output soon after booting up: After
power-cycling the UPS, it will operate properly
for several seconds before it shuts the inverter down due to "Low AC
Output Voltage" as determined by the alarm code and the remote status
reading. A "new" UPS is being lined up and will probably be
replaced on 16 June. In the meantime, the UPS has been
with the gear running directly from the mains.
Power line noise.
During the quietest parts of the day (late morning through the
there is noticeable AC mains noise on all bands 80 through 15 meters -
most obvious if one listens using AM on 40 meters. The plans
to investicate this noise on 16 June and hopefully locate its source
and pass along that information to the power company. As it
out, some of the folks that service this area are also amateur radio
operators, so it may be more likely to be fixed .
9 June, 2018.
With the addition of 12
meters, this WebSDR system now has coverage on all
U.S. MF and HF amateur bands - 630 through 10 meters.:
coverage of the 10 meter band.
A downconver was constructed and with an RTL-SDR dongle, then
entire 10 meter band is now covered. Because the top is set
29.7 MHz, coverage extends several hundred kHz below 28.0 MHz as well.
The receiver formerly used for the limited 10 meter beacon
coverage was retuned and is now centered on the 12 meter amateur band,
covering about 96kHz of this 100 kHz band.
The only HF bands that aren't completely
Even though the "main" receiver misses the top 8-10
kHz, the entire band is also covered using the "AM-160M-120M"
Approx. 96% of the band - missing the bottom and top 2-3 kHz.
Approx. 96% of the band - missing the bottom and top 2-3 kHz.
For a complete description of the band coverage, see
the "Technical Info"
We have (finally) added a
"Donate" button. If you wish to help support the
WebSDR, go here
to find out how you may donate via PayPal.
strength of the "warbly" has been reduced. The
"warbly" (see the 16
was verified to be coming from a switching supply within a piece of
wireless gear being radiated on the Ethernet cable. Despite
not being a service loop, four snap-on ferrite chokes were placed over
the cable, at the source, noticeably reducing its amplitude.
Unfortunately, without a larger service loop, it was not
to put multiple turns of the cable through the ferrite devices which
would have had far greater effectiveness at the frequencies of
interest: This problem will be revisited later.
The 6 meter
antenna was remounted. Up to this point the 6
meter antenna (a 1/2
was only temporarily mounted. On the new, permanent mount,
antenna is now much higher and completely in the clear so it should
work better than before.
The main HF
antenna feed connection was "excercised" and better-sealed.
Just outside the building, the large coaxial cable from the
main antenna (the
TCI-530) is adapted to a smaller cable (RG-213) for entry
into the building. During the 21 March visit (see below) this
connection was "shaken" to resolve an intermitted RF issue and during this trip (e.g. 9 June)
the entire connection was un-taped and inspected and found to be in
good shape, The connections were further-tightened and the
termination was re-sealed using butyl rubber material and overtopped
with another layer of sealing tape.
power line noise issues: There is a
more-frequent low-level power line noise that can be heard during the
"quiet" times (e.g.
during the middle fo the day) on
the lower bands - notably on 80/75 and 40 meters: We are
up the necessary gear to do HF direction-finding to locate the
source(s) of this noise so that we can report the location(s) to the
being done on the power substation near the WebSDR site on 15 May.
those are bugs in the lights... Lots and lots of bugs. Click on the image for a larger version.
16 May, 2018.
at the WebSDR site due to utility work on 15 May. The
power to the WebSDR site is fed via a spur of a power
that feeds a pumping/compressor station of a nearby pipeline, and on
15 May, a "50 year" upgrade was done requiring that this power
infrastructure be de-energized, which meant that the WebSDR site lost
power. Being a minor customer on this same spur line, we
get notification of this work until the power had already been shut
off. Because of certain complications (e.g. most of us work for a
we were not able break free from our normal tasks and get a portable
generator up and running on-site
immediately, so the system was down for 7 hours or so. The
site was on generator power until after the work on the substation was
completed and the line re-energized.
drop-outs of 5-120 seconds. It
would appear that one of the radio links providing Internet
connectivity to the WebSDR site is occasionally "renegotiating" its
wireless connection, causing brief data drop-outs despite the fact that
the signal level margins are very good. An upgrade of the
affecting link is scheduled.
"warbly" sometimes heard on 40 meters and other places.
early April, a piece of POE (Power
interfaced-equipment with a fairly long cable run was installed.
Unfortunately, as is the case with almost any piece of
that has switching supplies, one of the (many!) harmonics (spaced at about 250-251 kHz)
of this supply can occasionally be heard in the local receiver.
Fortunately, this "warbly" is quite weak, audible
daylight hours when the bands are very quiet: The normal
background noise of the bands at night completely covers this.
This "warbly" is wont to haunt 40 meters and is often heard
the vicinity of 7272kHz, the "default" frequency of the "Yellow" WebSDR
server and the frequency of the Utah Beehive Net, but it tends to drift
around a bit with temperature. This same "warbly" has also
been observed (during
the daytime) on 75/80 meters and on 20 meters.
On the next site visit steps will be taken to mitigate
signal(s) radiated by this equipment and it is expected that this
problem will be eliminated.
3 May, 2018.
with the Chrome browser!
The "Start Chrome audio" button has been added to the
"Mobile" versions of the WebSDR for those using mobile (phone, tablet)
devices and the Chrome browser. It is believed
that this works properly, but consider it to be experimental for now.
Depending on your phone's configuration, the WebSDR audio may
stop when your device goes to sleep/screen blanks: If this
to be an issue, we'll look into adding code that will prevent this -
but doing so will cause your battery to drain very quickly!
Remember also that the Firefox browser
works well with the WebSDRs, so you may consider using it, instead.
If you are using the "normal" web interface with the
browser on your phone, you may have problems with audio
stuttering/echoing, and this seems to be due to too little processor
time being allocated to processing the audio: It may correct itself
after a few moments - but if it happens to you, it probably won't.
Disabling the waterfall (the
"blind" button at the top-left corner, above the waterfall - you may
need to select "one band" an "blind" again) seems to help.
version of the WebSDR interface doesn't seem to have this problem -
neither does the Firefox browser with either the "normal" or "mobile"
version of the WebSDR interface. (This problem has been noted on
Samsung phones running Android and it may or may not occur on other
For more information about this,
go to the "Chrome Fix"
Links on the "Mobile" web interfaces to the other
Northern Utah WebSDRs have been added.
button has been added to the main WebSDR pages. This
the amount of the delay between the reception and your hearing of the
audio, but it can make the use of the WebSDR more tolerant of Internet
connections that are slow and/or subject to larger amounts of jitter (e.g. mobile hot-spot,
satellite, lower-speed "broadband", heavily shared connections).
This button is present on the "mobile" versions (near the bottom)
for the same reason.
drop-outs are due to other applications running on the
computer/phone/tablet taking processor time and NOT
because of network issues.
Having the WebSDR running on a minimized window and running
processor-intensive programs is a great way to make the audio choppy!
1 May, 2018.
The "31M-30M" band on the "Green" server was reconfigured,
increasing the bandwidth to 1536 kHz to cover down to 8676 kHz.
This expanded frequency range includes some of the HF
used for aeronautical communications on ocean routes and frequency tags
for these frequencies (and
those aero frequencies that happen to be covered on the "60M-49M" band
on the "Yellow" server) have been added.
A clock showing UTC was added to all servers in the
blank space between the waterfall and the controls to minimize the
overall web page size and to place it where it is easy to se.
This clock is based on the time setting of the user's
computer and not
that on the WebSDR,
which may not be precise. The code for this clock was
from the KFS WebSDR. On 30 April the display of local time
advisory about the clock's being based on the user's computer was added.
The firmware of the data link connecting the WebSDR site
backhaul has been updated to fix what the manufacturer called
"stability problems". We are hopeful that the link will be
use the Chrome web browser a recent update may
that the user "activate" sound/video on web sites that have this type
of content by clicking a button to activate it - but
this works only if
those same web sites have modified their code to include this button.
While we (beliive
have modified the Northern Utah WebSDRs to have this button, it may
some time before these changes appear on other WebSDRs. For more information about this,
go to the "Chrome Fix"
Earlier this week there were some very high winds
northern Utah. Since then, power line noise at the WebSDR
which is intermittent by nature - is occasionally worse than it had
been before. While we are working with the power company to
the source of this noise, it is largely up to us to locate it and
report the location of the suspected hardware to the utility.
As you can
imagine, we need to find time to do this - and then hope that the noise
is occurring at that same moment so that we can find it.
During 19 and 20 April, some network upgrades were being
undertaken, causing some occasional outages.
Coincident to that,
one of the wireless links connecting the WebSDR to the Internet started
losing its mind, losing/regaining its authorization and dropping a lot
of packets and occasionally going down altogether. Once there
time to address this issue, this link was reprogrammed from the ground
up and it is hoped
that it will behave itself!
The "630M-AM-120M" band has been shifted up slightly, now
covering only down to about 519 kHz. This was done because
is now a dedicated 630 meter band receiver.
The "60M-49M" band has been shifted up, now starting at
4700 kHz and covering to just above 6700 kHz. This was done
because there are (probably)
more signals of interest 6600-6700 kHz range than there were down
around 4500 kHz - although I don't know offhand what those would be...
We have enabled ads on the WebSDRs - trying to keep them
unobtrusive as possible - to help offset the "fixed" expenses related
to operating a WebSDR, such as power and site rental. One
side-effect is that they may slightly delay the loading of
the web page. To read more about why we did this, go the "Why
Bands on individual servers are now in order of lowest
highest frequency rather than by "high performance" receivers first and
then increasing frequency.
The S-meter/waterfall gain settings on 40 meters that
adjusted to compensate for the effects of the high-pass filter have
been restored to their original values.
A/D converter gain values on the 630 meter receive
system were adjusted to provide better overall signal range.
Minor name changes of several bands for better
15 April, 2018.
issue: The high-pass filter was rebuilt.
This is used to block low-frequency (<25 kHz)
energy picked up by the antenna in the form of electrostatic coupling
that was causing problems at low receive frequencies - being
particularly noticeable on the AM broadcast band as mains-induced hum.
The original filter was found to have a broad, shallow
around 40 meters that had reduced signals by about an S-unit.
issue: One of the sources of an intermittent
problem where intermodulation distortion from
AM broadcast would appear and disappear is believed to have been
solved. This was probably due to a flaky solder connection in
"wideband" branch of the signal path where one or more of the notch
filters used to reduce the signal level from strong, local stations
would occasionally fail.
15 Meters: The
15 meter amateur and the 13 meter shortwave broadcast bands
have been added to the "Green" server. This uses a relatively
low-performance RTL-SDR dongle preceded with a custom-built,
tightly-filtered frequency converter, but it was verified that just
will hear the ionospheric noise floor when the band is closed.
Upgrade - 2
meters: A south-pointing, 5-element 2 Meter Yagi
is now being used for 2 meter
reception. This Yagi points toward the Salt Lake City metro
there is the greatest concentration of repeaters.
The "Blue" server has been added, providing a few additional
2 meter coverage has been moved to the new "Blue" server.
Upgrade - 6
Meters: The bottom 1 MHz of 6 meters has been
added, covered on the
"Blue" server in preparation for the upcoming sporadic-E season.
The antenna for this band is not yet properly mounted so it
not (yet) work very well.
630 Meters. The
630 Meter amateur band has been added to the "Blue" server.
This receiver covers from about 389 to 484 kHz, allowing some
(Non-Directional Beacons) to be heard - particularly at night.
Like 160 meters, the 630 meter band is mostly a "winter" band
owing to the crescendo of static that accompanies the summer season.
While this band is also covered on the "630M-AM-160M" band on
"Yellow" server, this receiver has much better performance.
that this band can, at times, be badly affected by the intermittent
powerline noise and intermod/antenna issues that we are experiencing.
There are/will be some occasional outages over
the next week or so as our ISP does some equipment upgrades.
7 April, 2018. There
was an extended power
failure in the general area of the
WebSDR, caused by a pole fire, that resulted in an outage that
lasted significantly longer than a UPS powering one of the microwave
hops providing Internet connectivity could. Whether or not
had anything to do with our intermittent
power line noise remains to be seen. This outage provided the
opportunity to reconfigure the power system to mitigate the
aforementioned power issues at the "next" site along the network.
The original wireless link antenna used to
provide connectivity to the WebSDR site was upgraded from its original
to a 24" (50cm)
antenna, providing better link margin. This resulted in a
outages that totaled 10-15 minutes in the morning between 1130 and
There is a UPS/power supply issue at the "next"
the network from the WebSDR and brief power bumps at this site will
cause a 3-5 minute outage. This will be fixed (which will, itself cause a 3-5
minute outage) in the next several weeks.
While on site today it was observed that the
known-marginal north deadman on the other
antenna tower (a
had pulled completely out of the ground, leaving the guy completely
slack. The already-in-process plan to replace these deadmen
been delayed due to equipment problems of the person we have engaged to
repair this; In the meantime, the north guy wire has been (temporarily!)
attached to a large truck. There is no visible evidence of
antenna/tower damage. All three deadmen will be replaced, but
because the strongest winds are out of the north, this is the one that
is the most critical.
investigation: There is an intermittent issue
where there are spurious 160 and
80/75 meter signals - most notably on 1940, 3480, 3600, 3750, 3870,
3920 and 3960 kHz, many of these seeming to involve a mix between 1160
kHz and other stations. For the most part these spurious
disappear at night when some sources of the signals reduce power as
well as the ionospheric noise on these bands increase. The
source of this problem is believed to be a problem with one of the
filter elements designed to reduce the levels of the AM broadcast band
signals. When this is at its worst the "630M-AM-160M"
receiver may be unusable due to overload.
issue: It was discovered that, somehow, the
sound card used for the
"10M BCN" had reconfigured itself, switching the receiver audio away
from the active input. This was fixed for good - I hope!
issue: It was discovered that the "10M BCN"
receiver intended to cover (most
the 10 meter "beacon" subband from 28.200-28.300 MHz was actually
centered on 28.350. This receiver was retuned to a center
28.245 MHz (this
frequency chosen to include the NCXDF beacons at 28.200 MHz)
and immediately several beacons - including the "K7EMX" beacon located
about 70 miles (112km)
in Salt Lake and another beacon in Texas (K5AB at 28.280 MHz)
- were heard, indicating that the receiver is now working properly.
was noticed that the "= kHz" button doesn't work correctly when the CW
mode is active. The problem had to do with the fact that
other mode where the indicated frequency is that of the carrier (or suppressed carrier on SSB)
the indicated frequency when using a CW mode is that of the center of the passband
- or 750 Hz. Because of this offset, the "= kHz" button
frequency to jump, being rounded using that 750 Hz offset:
offset was taken into account in the code, this problem was fixed.
brief site visit by Mike for the installation of a high-pass
module on the main antenna feed which got rid of the AC mains related
"hum" on signals received on the AM broadcast band receiver.
problem is believed to be related to the pick-up of AM mains
electrostatic fields from the antenna causing modulation of the
magnetic properties of an input RF transformer and/or the modulation of
one of the signal amplifiers. This module provides a
DC path-to-ground for the antenna as well as two (moderate) levels
of lightning protection via gas discharge tubes.
It was noticed that a stray resonance in the added filter
to have caused approximately 1 S-unit of reduction in signals on 40
meters - but there is little or no actual loss of system sensitivity
owing designed-in signal margins. The filter will be modified
during the next site visit.
issue: Extra gain was added in the "10M BCN"
receiver's signal path. Although there are two low-power 10
beacons known to be active in the Salt Lake area, neither one can be
heard on this
receiver - but this is not unexpected as propagation would be only via
groundwave (which is
rather poor on 10 meters, anyway) and the distance is
simply too great to hear them.
investigation: It was noted that the RF levels
on all HF bands were shifting
randomly over the day by as much as 12 dB. A brief site visit
made by Mike who lives near the site and he shook the cables/connectors
between the RF rack and the antenna - we may
have found an intermittent RF connection on a jumper cable:
will be investigated further on the next "full" site visit.
BCN band was added at the time of this visit. We
had an extra "Softrock Ensbemble II" receiver on-hand (it had been the "75PH" receiver
prior to the recent upgrade)
which was reconfigured, putting it approximately in the middle of the
10 meter beacon subband. All that was available was the 96
sound card on the servers' motherboard - and this receiver lacks a
stage of RF amplification so it is going to be somewhat deaf, but it
should hear 10 meter beacons during even moderate band openings.
issue: There was a "hummy" spur that drifts
about on the 40PH
band. The cause of this was unknown - and the symptoms were a
bit perplexing: It was not super strong (only about "S-9")
and weirdly, its image (equidistant
from the 7221kHz center frequency) was only 6-10dB weaker.
If this spur were on-frequency I would have expected that
would have been much
stronger than it was and also that the image would be 40+dB weaker.
The implication of this was that this spur is probably far
off-frequency and what we were seeing was a rather weak spurious
from that (very-strong!)off-frequency
signal. The signal path contains a large number of
filter elements and there are several post-filter RF
and it is likely that one of these had "broken into song":
amplifier design that is used should
have been unconditionally stable, but all bets are off when
involved! The "fix" was to add some 2dB resitive attenuators
to the outputs of these signal amplifiers.
The opportunity was also taken to add an
amplifier stage to the
17 meter receiver, allowing it to hear the background
investigation: The TCI 530 antenna was given the
"shake test" and it was
verified that there is, in fact, some sort of intermittent connection.
There is strong evidance that one of the active antenna
elements is close
enough to touch a guy wire when the antenna is vibrating due
Experimentally, 2-meter coverage was added to the system.
At this time the antenna is not very good, so effective system
sensitivity is quite poor. This site is approx. 70
north of Salt Lake City so the signals from the repeaters in the metro
area are a bit weak with the current configuration. We are
be making some improvements to the antenna system which may make it
more useful, but whether or not 2 meter coverage will be a permanent
part of this system remains to be seen.
2018. Significant system upgrades/modifications:
UPS with a built-in ferroresonant transformer was added to clean up the
power and provide continued operation in the event of brief outages.
160M: Levels were readjusted and this receiver
retuned and moved to a 192 ksps card to cover nearly 96% of the 160
80CW-80PH-75PH: A "triple" receive module was
constructed that cumulatively provides complete coverage of the 80/75
80CW: The the aforementioned module, this band
was added, completing coverage of the entire 80/75 meter amateur band.
issue - 75PH: The sound card was modified (the "Aux" input was made
available on the rear panel of the Asus Xonar DX)
to allow gain adjustment and the audio levels were properly set to fix
problem where the sensitivity at the extreme edges of the band was
reduced by 10-15dB.
This band was moved to a 192ksps card and the center
re-tuned, now providing coverage to the entire 40 meter amateur band.
60-49M: Levels adjusted, improving weak-signal
performance - particularly during the daytime.
WebSDR Server #2 (Green)
was added, providing:
dual high-performance 20-meter receiver module which, with a pair of
192ksps sound cards provides full coverage of 20 meters.
The change to higher-performance, narrow-band receivers
in the loss of the (incidental)
reception of the 22 meter shortwave broadcast band.
The 96 ksps sound card that had previously been used for 40CW was installed
in this server. Redeploying the original 80PH
receiver allows nearly 96% coverage of the 17 meter band. At
time of installation it was noted that this receiver was slightly deaf,
so an amplifier will be added to its signal path during the next site
Coverage of the 31 Meter shortwave broadcast and the
30 Meter amateur bands was added using a (low performance)
There are some ongoing upgrades to the network infrastructure
that provides connectivity to the WebSDR. Because of this
there will be occasional network outages - typically of 4-10 minutes
4 March, 2018. A
modification was made to the code to "brighten" the waterfalls,
particularly during the times of day when the bands were "dead".
At about this time additional "Passband Tuning"
controls were added as well.
This webSDR was moved to its designated site - an old HF
site near the town of Corinne, Utah, about 70 miles (94km)
Salt Lake City. The antenna at this site is a TCI-530, an
omnidirectional Log-Periodic antenna - the same model as that used at
Web Site at Half-Moon Bay, CA. Now that we have the initial
we will work to improve the overall receiver performance, add more
bands and do more performance tweaks. While the person in
of the data networks lives fairly close to the site, the one in charge
of the RF infrastructure lives about 70 miles (and a 75 minute drive)away - a
fact that can sometimes complicate dealing with the latter types of
The system was down for several hours while some of the
critical components were "racked up" - that is, removed from their
temporary location (scattered
across a workbench)
and mounted/wired on shelves in an equipment rack. This
is not yet complete and a few more brief outages will occur in the next
several days while things are "permanentized."
The tentative date for installation of this system at its
"permanent" site is
28 February, 2018. When this happens, this system will be
for several hours as it is relocated and installed with subsequent
debugging of the computer, RF subsystems and the network. The IP address will change at
but there will be another server at the address of the old one that
will inform those users who land there, giving the new address and
prompting them to update their bookmarks. This
"informational" server will be
online for a few weeks before being turned off.
The hard drives on the system started throwing errors were
replaced with Solid State
drives, necessitating a complete rebuild of the operating system.
This process took some time and the system was unavailable
during for about a day.
The 40 meter receive system was reconfigured: A
custom-built dual 40 meter receiver module was used to replace the two
"Softrock Ensemble II" units that, together, had covered 40 meters.
The Softrock Ensemble II units were then reconfigured to
coverage of the bottom 96 kHz of
the 160 meter band and chunk of the
"80 meter" phone band.
2018: This WebSDR server was first made public
from a testing location
near Salt Lake City, Utah,
U.S.A. and was used to test software/hardware
configurations prior to the
installation at a quiet receiver site in Northern Utah. This
location was somewhat "RF
noisy" with the amount of noise varying
wildly at times, so it didn't hear particularly
well - but it still did better than many home installations.
For general information about this WebSDR system -
including contact info - go to the about