2200-1750M RX fixed.
A brief visit to the site and re-seating of the cable resolved
the "mirroring" issue of this receiver. As expected, an audio
cable had been partially dislodged, resulting in a loss of one of the
It would seem that the FiFiSDR is more susceptible to overload by
AM broadcast stations than the Softrock Ensemble II that had previously
been in use. The result is that one can hear several distorted
signals on the "160M" receiver (only)
- from "nearby" AM broadcast stations at the top of the band - can be
heard. In the evening, these stations reduce in power and the
nose rises, making most of these artifacts (mostly) undetectable.
While there is
a filter on the 160 meter port, it is apparently not sharp enough to
sufficiently attenuate the AM broadcast stations at the top end of the
band (above about 1400 kHz).
additional filter has been constructed - one that offers much greater
attenuation at the top of the AM broadcast band - that will be
installed and should (hopefully) resolve this issue.
KiwiSDR performance. As
noted in the 8 February entry, a different RF line amplifier was
required to avoid instability issues - but this "temporary" amplifier
has noise ingress issues that degrade its performance below 500 kHz.
A new amplifier has been constructed that will replace it, to be
installed during the same trip as addition of the new 160 meter band
8 February, 2020: Site visit.
VLF/LF line amplifier replaced:
the last trip it was discovered that a line amplifier in the "3-375
kHz" signal path had failed - likely due to a voltage impulse that had
come down the coax (the antenna used for this is active, voltage being sent via the feedline) when antenna work had been done, reminding me that I really should have
completed modification to prevent this very occurrence.
Since the previous trip, a new amplifier module was constructed -
with much stronger protection - and installed, restoring the signal
The "new" amplifier has much higher P1dB and IP3 specs (much "stronger") making it far more resistant to overload than the amplifier that had been used in the meantime.
the intermodulation observed while the "temporary" amplifier was
reduced, it wasn't gone, indicating another problem, described below.
the time of writing, the 2200M receiver on WebSDR 3 is degraded:
Apparently, when moving things around an audio cable from the
receiver module got partially unplugged resulting in the loss of the
I/Q channel pair causing the appearance of "images" (duplicate signals)
mirrored above/below the center frequency. It is expected that
this will be corrected in a few days. This does not affect the
performance of the KiWiSDRs or the related WSPRNET operations.
Intermodulation issues resolved.
noted in the 31 January entry, there was an intermittent issue in which
severe intermodulation distortion was occurring on the "wideband"
branch of the RF distribution, most strongly affecting the KiwiSDRs.
The most obvious effect of this was seeing/hearing 10 kHz-spaced
carriers containing audio from multiple AM broadcast stations - and
occasionally a "shortwave" sound (RTTY, CW, digital).
suspected culprit was a failed 570 kHz AM broadcast band notch - but
I'd not recalled at the time of the previous post that there was no 570 kHz notch - a fact verified on site when the filter assembly was connected to a network analyzer.
I had the HF Splitter/BCB splitter/filter/amp unit apart, I revisited
the notch tuning, moving one notch from a weaker, more distant station
to a fairly strong more local station, reducing the total amount of
energy from the AM broadcast band.
the "3-375 kHz" amplifier had been replaced, there was still some
intermodulation distortion - but it seemed to occur only when the main
HF input was connected. After a bit of sleuthing, it was
discovered that RF amplifier being used to boost the signals to the
KiwiSDRs after the "limited attenuation high-pass filter" (the filter that reduces signal between 500 kHz and 12 MHz to prevent overload of very strong SWBC signals)
was going in to what appeared to be "regenerative oscillation" - that
is, it was on the verge of oscillating, but in the process it was
amplifying certain frequency ranges by an enormous amount. What's
interesting is that this same amplifier has been in use for several
months, but it didn't have any issues until after the 11 January trip.
amplifier - using a MMIC - was replaced with a much "stronger", but
similar gain, discrete, high-dynamic range bipolar RF amplifier.
FiFiSDR receivers shuffled around:
As noted in the 11 January entry, we received three FiFiSDRs (and modified them appropriately for better performance)
and these were "temporarily" placed in the three 80 meter band
positions - 80CW, 80PH and 75PH, all replacing a single unit: If
one of these FiFiSDRs had failed, alternate coverage would have been
available on WebSDR #3 (blue).
receivers were reprogrammed and moved to 160, 40CW and 40PH and the
previous 3-band module used for 80/75 meters was placed in service.
This frees up the receiver module that had been used on 160
meters (but is tunable from 160-10 meters) and the dedicated 40 meter receive module for an upcoming project at the Northern Utah WebSDR.
One of the remaining issues is that identical USB devices on Linux (and other operating systems) can't be reliably differentiated from each other. What this means is that if the configuration of any USB device is changed (added/removed) their identity can change. In the case of the FiFiSDRs, they can (seemingly)
randomly rearrange themselves causing such mischief of the 160 meter
ending up on 40 meters and vice-versa - and when this happens, they do
not work well at all! An attempt was made to add a script using
Linux "UDEV" rules that would tie a device name to a specific USB port,
but this effort was abandoned in deference to the late hour - a project
to be tackled later.
"IQ" calibration was done on the 160, 80CW, 80PH, 75PH, 40CW and 40PH
receivers to minimize image response - a laborious, but worthwhile
process that should be done any time receiver hardware is moved around.
issue with slightly low gain on 80 meters after the installation of the
FiFiSDRs was averted: Appropriate gain now precedes the 160 and
40 meter receivers to prevent this issue. This issue was averted
on 80 and 75 meters with resumption of the use of the original receiver
Weather station back online:
weather station at the Northern Utah WebSDR site is back online.
At the moment, the "widget" used to display the conditions on the
web page(s) is via "Weather Underground", but it would seem that they
are in the process of switching away from a "crowd sourced" model for
their data. What this likely means is that we'll be switching to
another method of displaying the weather data on the Northern Utah
WebSDR web pages.
Grounding system improved:
RF and lightning grounding system was significantly bolstered,
something that had been on the list from the very beginning of the
WebSDR. This includes re-doing connections and providing
additional bonding of ground cables.
Additional lightning/impulse protection was added to all incoming coaxial cables
bit more work remains to be done on overall grounding/lightning
protection, but that is probably true for almost any antenna
"Low HF Split" module modified:
In the signal path for the higher performance "narrowband" receivers (those shown in "bold" on the WebSDRs)
there is a take-off point for all band above and including 30 meters.
It was noted on a previous visit - and verified via simulation -
that a minor modification would theoretically reduce ripple and loss on
some of the higher bands. It is likely that the difference will
not be apparent except to someone wielding the appropriate test
Waterfall labels (the sysop-defined yellow labels for Nets, etc.) updated:
until now, there were only "Day" and "Night" labels on the WebSDRs,
being switched at 0500 and 1700 (Mountain time), respectively.
This feature has been expanded so now there are separate day and
night labels for the weekdays and weekends. Because the
"nighttime" label is displayed until 0500 MT, the "Weeknight" labels
will persist until 0500 MT on Saturday - and similar for the "Weekend
night" labels, which will persist until 0500 MT Monday.
modification was made to the code so that it is now possible to move
labels horizontally. This has allowed the labels to be spread out
a bit with fewer of them being covered by another.
remains an issue that causes occasional network slowdowns and audio
drop-outs. The cause is known and will be addressed with an
upgrade that is expected to occur in the near future.
2 February, 2020: Slowdowns, network issues.
We have been experiencing network issues today (2 Feb) and yesterday (1 Feb): We are working to solve the problem. Thank you for your patience.
Update: The device with the problem was rebooted and the issue seems to be resolved.
31 January, 2020: Intermittent intermod on lower frequencies.
appears to be an intermittent issue in which significant
intermodulation distortion will appear on the lower frequencies causing
the appearance of carriers every 10 kHz or so along with a mish-mash of
audio from multiple AM broadcast stations.
analysis indicates that the notch used to attenuate a strong local AM
broadcast station on 570 kHz on the "wideband" RF branch has become intermittent: When this
happens the amplitude of that station increases by about 50dB,
completely saturating the RF line amplifier that follows this filtering.
of the finite reverse isolation of this amplifier, the distortion is
reflected back into the antenna system and due to its lower
frequency and the relatively transparency of the AM broadcast band
filter at 630 meters, that receiver is particularly badly affected.
The 160 meter receiver, which is also on the "narrowband" branch, is
also affected, but less than 630 meters.
All other receivers that are on "wideband" signal path (all
of the KiwiSDRs, 60M, 25M SW, 19 M SW, the "back-up" 90-80M" and
"41-40M" receivers on WebSDR #3 and, of course, the AM-160-120M
receiver) are strongly affected when this is ocurring.
This issue will be addressed during the next site visit.
13 January, 2020: Miscellaneous items.
WebSDR configuration tweaks, including:
With the Internet traffic moving more reliably, the default audio buffering was set from 0.5 seconds back to 0.25 seconds.
make to links to update and reflect the new WebSDR and KiwiSDR
configurations - including updating of links on the "mobile" versions
of the WebSDR page.
A few tweaks to the network configuration resulted in two brief outages.
Possible issues with the 25M receiver: It seems that the 25M receiver (on WebSDR #3)
has noise issues causing it to be somewhat deaf. The reasons for
this are unknown as this frequency range is clear on the KiwiSDRs,
indicating that it is not due to local site interference.
Slightly low RF gain on the 80 meter receivers: The three 80 meter receivers (80CW, 80PH and 75PH)
are slightly "gain starved" at RF. These are the newly-installed
FiFiSDR receivers: There's an approximately 10dB "hit" on signal
level between these receivers and the antenna due to a 2-way splitter
"early" in the chain and a four-way splitter to feed the three
receivers. Without this loss an individual FiFiSDR would be
sensitive enough hear the low HF noise floor "barefoot".
This is evident during very RF quiet times (middle of the day) where one can see the noise floor on the receivers (particularly 75PH)
is higher at the extreme edges rather than the middle. This is
not a problem in the night/evenings when propagation improves and the
80 meter noise floor increases by 10-17 dB.
the receiver was RF noise-limited it would be the other way around:
Slightly lower noise floor at the upper/lower edges due to slight
roll-off of the audio chain at higher audio frequencies.
we are able to do so, an extra gain block will be inserted into the 80
meter receive chain. Note that these three FiFiSDRs will
eventually be moved to cover the 160 and 40 meter bands, anyway.
12 January, 2020:
Site visit, and the Northern Utah WebSDR back online.
work party convened on 11 January at around 0800 MST with a lot of things
to do, finishing at around 0220 on 12 January - not including 90 minute
driving times for some of those involved. Almost everything
on the list was completed.
New receiver hardware installed
on WebSDR #1:
mentioned in the 21 December, 2019 entry, several of the USB sound
cards had failed leaving a deficit of one receiver on WebSDR #1 - so we
chose to sacrifice the 80CW
- the absence of which was covered by the "90/80M" receiver on WebSDR
#3. Since the last visit we had ordered and received three
SDR receivers - all-in-one SDR receiver and USB sound cards that can
cover from a few
hundred kHz to at least 30 MHz - and they cost about the same as a new
USB sound card. The KFS WebSDR has used these units
for about 2 years with good results.
These new receivers were
installed in the 80CW,
80PH and 75PH
for the time-being. Because these devices are new we
"breaking them in" and don't yet know how they will hold up - both
hardware and software-wise - so we did not put them on 40 meters, the
most popular band, but installed them on a band that requires three
receivers - 80/75 meters, temporarily replacing the older
configuration. If one or more of these receivers quits
there is a usable alternate on WebSDR #3.
If proven to be reliable, these
will eventually be moved to 40CW,
and 160 and
the existing 40 meter receive gear will be re-deployed for an
WebSDR rack rewired:
Originally, the Northern Utah
WebSDR had been just one server and
several receivers neatly organized in a single rack - but it has since
expanded to three severs with several rat's nests of wires, making
rather difficult. While the Internet connection was being
out, the WebSDR rack was pretty much emptied, many receiver modules
re-mounted, cables organized (RF-carrying
cables separated from data and power) and carefully
This task - which had been put
for months - took many hours to complete, but since the WebSDR system
was offline, anyway, we decided to do it. The result is a
not quite "neat") installation with gear and cables that
are much easier to manage.
Weather station offline:
The weather station is temporarily offline - this will be
Grounding improved: While
not complete, the ground and bonding of various pieces (coax cables, racks, etc.) is much improved over what it had been and tidied somewhat. More
work on this is still to be done.
Default buffering changed back to
With the more stable Internet connection, the default
for WebSDR audio has been reduced from 0.5 seconds back to the previous default of 0.25 seconds.
2200/1750 meter and reception on
frequencies below 400 kHz improved:
After locating and dealing with
a persistent noise source, the noise level on the very low frequencies (below approximately 400 kHz)
has been much reduced - whether you use the "2200/1750M" receiver or
listen "down there" on the KiwiSDRs.
Due to minor equipment
damage and the lack of appropriate repair parts (and time!) there
are some signal
integrity issues on this RF path (a bit of intermod, lower
absolute signal levels) but it still works better than
many home installations: This is on the list of things to fix
during the next site visit.
2 meter and 6 meter reception
improved: Via reconfiguration of some of the
gear (which included rerouting cables and lowering the Ethernet speed of
the KiwiSDRs to 10 Mbps - still more than adequate)
a lot of the noise and spurious signals that had been present on 6 and
2 meters have gone or been significantly reduced. A bit more
improvement can be afforded with more time/work.
Internet restoration: We
were able to install new gear and restore our connection to
the Internet: We thank our previous ISP for their past hard
and service. There are a few minor issues to work out, but
will be addressed in the coming days/weeks, so there will be a few (hopefully brief!) outages.
If you end up WebSDR #1 (yellow) when trying to go to WebSDR #2 (green) or WebSDR #3 (blue):
If you are trying to go to WebSDR #2 (green) or WebSDR #3
(blue) but keep ending up on WebSDR #1, please use the URL on the landing
page and update your bookmarks and shortcuts! For convenience, the new URLs are listed below:
reason for this change is that all WebSDRs and KiwiSDRs now share a
common IP address, but use different ports. What this means
that if you used your old bookmark you will always
end up at WebSDR #1.
If you can get to
WebSDR #1 but
get a dead link when you try to go to WebSDR #2 or WebSDR #3 -
particularly on a mobile device or on a secure network:
First, make sure
that you have tried the new links on the landing page.
may have been using the WebSDR interfaces via port 80 - which can be
advantageous to those that use an Internet service that does NOT
allow non-standard ports for web traffic: Some ISPs do this,
but it is also common on mobile (phone)
connections and on "secure" networks such as those found at workplaces,
WiFi hot-spots, and other places where they have "locked down" their
Previously, each WebSDR had its
own address and allowed forwarding of the most common port (80) to the native
WebSDR ports (8901)
- but it is currently possible to do this only
with WebSDR #1 as there is only one
address available. WebSDR #1 was chosen as it is by far the
the moment, the best way around this is to use a VPN proxy service on your computer to get
"outside" the restricted Internet connection. In the future
may be able to give each server its own address, again.
The KiwiSDRs, previously
accessible via port 80, can no longer be accessed via that port.
Mobile page access
users of the lightweight "mobile" version of the Northern Utah WebSDR,
make sure your links have been updated as follows:
of 1637 MT (2337 UTC) on Wednesday, January 8 the receive site of the
Northern Utah WebSDR lost connectivity to the Internet - again
due to issues that our ISP is having.
We are working on a means of
restoration - but expect this outage to last several days.
In the meantime, we have
"re-pointed" the URLs of the WebSDR servers so that most users will see
the landing page and the outage notice when they attempt to go to a
WebSDR server rather than a "dead" link.
Don't worry, we will
get it back online!
7 January, 2020:
Internet connectivity restored!
As of 0845 MT (1545
UTC) on Tuesday, January 7, our ISP was able to restore
connectivity to the receive site of the Northern Utah WebSDR.
We wish to thank them for their work in this restoration.
expect that there will be a few lingering issues to work out (e.g.
drop-outs, brief outages) but we are expecting things to improve over
During the outage, we "re-pointed" the WebSDR links to
landing page so that users would see the notice rather than just a
broken link: We have pointed them back to there respective
WebSDRs, but it will take several hours (after the above time)
before this change fully propagates through the Internet.
3 January, 2020:
approximately 1338 MT today the Internet connectivity to the Northern
WebSDR site was lost.
Due to the remoteness of the site, it may take some time
to analyze the
problem and come up with the best solution - which may include
replacement/upgrade of wireless Internet equipment - but we will
get it back online.
We currently have no ETA, but we are hopeful that it will
be restored during the week of 5 January.
26 December, 2019:
buffering" setting changed.
The default (when
you load the web page)
setting for the "Audio Buffering" on WebSDRs 1, 2 and 3 has been
changed from 0.25 seconds to 0.5 seconds. This change was
help deal with the "flakiness" in the Internet connection (discussed below)
where the "jitter" of that connection will occasionally increase due to
retransmissions on that link segment and cause audio drop-outs.
This setting will be reset to the earlier value of 0.25
once we "fix" that link. In the meantime, you may select more
less buffering when you connect, as desired.
21 December, 2019 - Site
The trip itself:
It took several days (because of holiday
preparations, schedules, etc.) before an "expedition"
could be carried out to the Northern Utah WebSDR receive site (it's 80 miles/130km each way!)
For a trip to the WebSDR site
we must count on killing the entire
day - and this trip was no exception: The duration of the
trip was about 13 hours, door-to-door,
including about 2-1/2 hours total drive time.
it was noted that having four-wheel drive was very useful owing to the
snow/ice on site. The temperature got as high as 34F (1C) and as low as
24F (-4C) during
the time that I was there.
WebSDR #1 (yellow) back
As expected, a failed USB sound
card (Asus Xonar U5)
- used for the "160M"
band - caused the server to hang on "POST" - that is, it didn't ever
get past the start-up (BIOS)
screen to even start loading the operating system. After this
USB device was unplugged, the system booted properly.
It was also discovered that another USB sound
card (Asus Xonar U7)-
this one for "80CW" - had also failed - but instead of hanging the
system, it simply would not negotiate to operate at "High Speed" on the
USB port which meant that the best it would do, if it proved to work at
all, was 48 kHz - able to
cover only 1/4 of the "80CW" range.
Asus USB sound cards (four
donated by another WebSDR, and one of my own) ere on-hand,
of them would work. What that means is that since this WebSDR
first brought online in February, 2019, at least six of
these sound cards (Asus
Xonar U5 and U7) have failed, all in similar ways (e.g. failure of the USB port to
properly negotiate a connection).
Since we were one sound card
short of the full compliment (we
are "maxed out" on PCI bus slots, so we had to use
three USB sound cards) we had to sacrifice one band - and
we chose to leave out the "80CW" band for the time-being.
have on order several devices (Fifi
SDRs) to completely replace the USB sound
cards - these devices having been used with success at KFS:
It is hoped that this will eliminate this particular
point of unreliability. It is expected that it will take 2-4
weeks for these new devices will arrive (from Germany)
and be tested prior to installation. Unavailable until
these devices cost about as much as a brand new 192 kHz Asus USB sound
For alternate "80CW" band
coverage (3500-3630 kHz) use
the "90M-80M" receiver on WebSDR #3 (blue) pending the
arrival, testing and installation of the new gear.
Electrical utility work:
that the upgrade by the electrical power utility is done - but we have
yet to hear "official" word.
Instead of the old,
chunky (and obsolete)
open-delta three-phase 4160 volt line, there is now a "modern"
single-phase 12kV line and a new pole transformer at the WebSDR site
and likely a new transformer at the other end, too! It is
likely that our line voltage will stay much closer to the nominal 120
volts rather than the 80-140 volts that we'd occasionally seen before.
(It was 124
VAC when I checked it.)
From the radio site to the
power distribution point (a
compressor station about 2/3-mile, 1km away)
all of the insulators are brand new so we are hoping that it will not
be a source of noise any time soon. (It occasionally rains salty mud
in that part of Utah, so we'll see...)
A UPS - which had
failed catastrophically a few months ago - has now been
replaced with a higher-power (1400
VA) unit that uses 24 volts DC provided
by a pair of new-ish 100 amp-hour UPS-rated AGM batteries.
should reduce the number of outages -
even though the power has been quite reliable, excepting the recent
utility work where it wouldn't have mattered, anyway.
We calculate that the new
UPS/battery combination should be able to carry the current load for at
least 3 hours.
Image responses reduced:
thing that had been an annoyance was that in recent months, whenever an
"I/Q Calibration" procedure was done on the SoftRock ("High Performance")
the result was always worse
before - so the "old" calibration values were kept, meaning
the image rejection was typically around 45dB - not "terribly
but not very good, either. Today, the instructions were very
carefully re-read and nothing was
missed - that is, the calibration instructions, written by
the author of the WebSDR software himself, were being followed exactly..
this point it was suspect that an important detail had been omitted
from the original instructions - specifically, that one should remove any
existing calibration values before doing the procedure. This
was done experimentally on the
"160M" receiver on WebSDR #1 and the image rejection went from about 45
dB to well over 60 dB. Apparently, the values that obtained
the calibration routine are not based on "raw" data from the
signal processing chain, but they are values that have been "cooked",
existing calibration data been applied, and therefore are utterly
bogus unless one removes any existing calibration data and
restarts the WebSDR service.
The calibration on all
bands that use SoftRock receivers (all
eleven of them - it would have been twelve if the "80CW" receiver
weren't offline)was redone - a lengthy and tedious
and the image rejection on all bands improved significantly.
reasons not yet known, the image rejection on the 12 meter receiver
improve as much as others (it's
around 50dB) but we'll look into that on a future trip.
LF antenna replaced:
Because the LF receive
kHz) was rather poor, the existing 0.75 meter diameter LF
loop antenna was replaced with a 1
meter diameter loop that was recently built and the result was much
stronger signals, but much poorer
signal-noise ratio and even worse performance than the previous loop.
The E-field whip that had been
a year ago which has more interference on some frequencies than the
whip (the interference
could be nulled out with the loop)
was placed back in service and despite the QRM, the whip works
better overall than the "new" loop.
The "new" loop remains on-site and the older 0.75
meter diameter loop was brought back for re-work.
Internet link tweaked:
have been recent issues with the "last hop" of the Internet connection
to the WebSDR side slowing down and, occasionally, dropping out,
probably related to the onset of winter. The working theory
there are Fresnel effects on the "near" (WebSDR site)
side of the link that is causing on-link retransmissions - and path
calculations using terrain database data and path calculating software
this out: Now that the ground is mostly covered with snow,
nature of the Fresnel effects have apparently been altered as compared
to those in the summer.
such Fresnel effects - which occur due to multipath caused by ground
reflections from a "high" spot on the terrain somewhere in the path,
below the line-of-sight, the antenna was raised a few degrees in an
move the reflected signal farther below the main lobe of the
antenna, reducing its signal will minimally affecting the "main"
The result seems to be an overall improvement: Even
the signal has probably dropped a bit, the reflection has probably
dropped a bit more - this being one of those instances where a stronger
signal does not
mean better performance! The average latency dropped by about
indicating a slightly better link quality overall and instances of
extended ping times - which still occur - appear to be "less bad"
than as link drop-outs are less frequent than before.
upgrade to this problematic link is still in the works, but it will
likely be a few weeks before we get all of our "ducks in a row".
18 December, 2019:
Utility work continues:
The electrical utility cut power again around 0900 (MT) to
continue the upgrade and as before, we could not be on-site nor provide
UPS or generator power during this work.
about 3 hours, the power was restored. We do not yet have
official word as to whether or not the upgrade is complete.
For some reason, while the
WebSDR #2 (green)
and #3 (blue)
servers (the computers
themselves) came up, the WebSDR program did not.
This rare event wasn't noticed for several hours (sorry!) and
required remote logging-in and manual starting of the WebSDR software.
WebSDR #1 temporarily offline:
As before, WebSDR #1 (yellow)
did not come back online. The suspected problem is a failing
sound card that is causing the computer to "hang" during boot-up, but
we'll have to get eyes on it to be sure. We have extra
to fix whatever is wrong, but between the utility work (during which we cannot visit
the site), weather, time and the remoteness of the site,
it will likely take a few days before it can be completely restored.
80 and 40 meter back-up
receivers: WebSDR #3 (blue) has back-up
receivers For 80/75 and 40 meter reception - please use these for those
bands in the meantime.
Intermittent connectivity issues:
As noted in the 14 December news, below, we have been
experiencing occasional slow-downs and drop-outs on the 3rd and final
wireless hop to the WebSDR receiver site: Please read that entry for more
17 December, 2019:
Utility work: It
would appear that the long-awaited utility work resumed, the power
coming back after a bit less than 5-1/2 hours. We have yet to
hear official word about whether or not
the work is complete.
WebSDR #1 (yellow) offline:
WebSDR1 did not come back up on its own after the power
- something that had happened following a previous outage. In
that case, the server did
finally come up a few days later, after a power bump but this prevented
a proper analysis of what had happened as the failure "stopped
suspicion is that one of the USB sound cards is starting to fail,
causing the system to "hang" during POST, preventing it from booting
up. This sort of thing had happened before when we were on
site and had to restart the server,
but we had a spare USB sound card and "fixed" the problem.
looking to see what we can do to get WebSDR #1 back online prior to the
next "official" site visit.
14 December, 2019:
Utility work still pending: Between
weather, holidays and other scheduling issues, the work on the upgrade
by the electric power utility still remains to be done: When
know something, we'll post it here!
issues - slow-downs and drop-outs:
If you are an avid reader of
this page you may already know that it takes three
wireless hops to connect the remote location of the Northern Utah
WebSDR's receiver site to the Internet - and it's the last and shortest
hop (approx 12
connects directly to the remote site that has been having issues that
cause the audio to drop out and, occasionally, causing the Northern
WebSDR's Internet connectivity to become unusable for several minutes.
The issue appears to be related
to Fresnel effects - which
normally cause slight degradation of this last hop - getting briefly
worse when the weather rapidly changes
or is very bad - and severe weather has been happening a
lot in the past couple weeks in that part of the state. We
trying to implement some changes to minimize this issue, but it will
likely take a major change to the topology of the network connectivity
to the WebSDR to
eliminate this particular issue.
in the planning stages, but it is not yet known when this might be done
to equipment availability, scheduling of those who may do this work and
the kindness of Mother nature. Unfortunately, we are just
entering the time of year where the weather can be the most fierce -
particularly in that part of the state.
10 December, 2019:
KiwiSDR receivers back
appears that all three KiwiSDRs, which run Linux, got into a state
where they were expecting manual intervention by a person before
booting up. We are investigating why this happened so that it
not happen again in the future.
Awaiting completion of electrical
Because of the weather, slipping of schedules due to other
equipment problems the upgrade-in-progress to the electrical feed is
still on hold. When we know more, it will be posted here.
30 November, 2019:
Utility work still
of the severe weather, the utility work has been delayed and we don't
have official word as to when it is expected to resume/be finished.
WebSDR1 back online:
Somehow, WebSDR1 seems to have "recovered itself" and is back
online and working normally.
KiwiSDRs still offline:
All three KiwiSDRs are still offline, pending a site visit
itself, is pending better weather and the ability to safely access the
28 November, 2019 update:
More severe weather - just in time for Turkey day!
Heavy weather: A
lot of snow has fallen in the general area of the WebSDR's receiver
site and many roads are awaiting snow plows and there are several
scattered power outages in the area: It has been reported
thousands customers (which
is a sizable percentage of people in the country) have
experienced a power failure this morning.
WebSDR #1 (Yellow) back
appears to have been a power bump at the WebSDR site that lasted long
enough to take everything down - but when power returned, WebSDR1, the
power supply of which had been repaired but the computer didn't boot
properly when initially tried - seems to have recovered itself.
KiwiSDRs offline: Unfortunately,
the power supply running the KiwiSDRs appears to have crowbarred,
possibly because the power did not come back up "cleanly".
the supply can be reset (possibly
another power bump!) the KiwiSDRs - and the "KA7OEI-1"
WSPRNET reporting - will be offline.
27 November, 2019 update:
Severe weather in northwestern Utah delays utility work,
Utility work postponed: Because
of severe weather in northwestern Utah, the utility work scheduled for
27 November has been postponed. As soon as we know when this
will occur, we'll post it here.
Again, expect an extended
outage on that day for the reasons mentioned below.
WebSDR1 repair delayed:
The same weather that delayed the utility work dumped a bunch
snow on and around the Northern Utah WebSDR's radio site and
surroundings, making it quite hazardous to travel - particularly for
those people who do not have chains and/or 4WD vehicles.
What this means is that the
primary receivers for 80/75 and 40 meters are down, but there are
back-up receivers on WebSDR3(the Blue one)
that are available for those bands. There are currently no
back-up receivers for 160M, 60M, or the AM broadcast band.
26 November, 2019.
Power outage due to utility work:
Because we didn't see another power outage after last Monday,
November, we weren't surprised to see it go off today for a while (approx. 1337-1449)
while the power utility did more work.
The utility had to abandon work
on this day because of the failure of a bucket truck (a line/seal ruptured causing
loss of hydraulic oil).
have been told that the power will likely
be off again on Wednesday,
27, 2019 while the utility continues work.
work resumes, we will NOT be
allowed on-site, or be allowed to use a UPS or generator to back the
site up because the utility crew wants there to be ZERO
chance of inadvertent back-feed that might energize the lines on which
they are working!
It is hoped - but not
guaranteed - that the work will be completed during this day (27
WebSDR1 temporarily down:
WebSDR #1 (Yellow)
did not recover on its own: Its power supply was damaged -
possibly by a glitch when the power went up/down and will have to be
Backup receivers 80 and 40 meters
on WebSDR3 (blue):
In the meantime - at least while we are working on WebSDR1
the power is on - use the back-up 80/75 and 40 meter receivers on
Coverage expanded on WebSDR #3 (Blue):
The bandwidth of this receiver has been increased from 1024
to 1536 kHz and the center frequency shifted upward to 4000 kHz.
The coverage of this band is now 3712 kHz through 4718 kHz
meaning that it now overlaps with the low end of the 60M receiver on
The bandwidth of this receiver has been increased from 1024
to 1536 kHz and the center frequency shifted upward to 7500 kHz.
The coverage of this band is now 6732 kHz through 8268 kHz
meaning that it now overlaps with the top end of the 60M receiver on
changes were made as a result of suggestions made by some participants
on the 2019 Survey to provide additional coverage of commercial,
military, utility, broadcast and "mystery" users in these frequency
ranges: You may read the results of this survey HERE.
Please note that
the performance/sensitivity of these receivers is optimized for the 80
meter (3500-4000 kHz)
and 40 meter (7000-7300
kHz) amateur bands: The
sensitivity will degrade outside these bands.
First two "bands" swapped on
WebSDR #1 (Yellow):
positions of the "AM-160M-120M" and "160M" bands on WebSDR #1 were
swapped. This was done so that if one manually entered a 160
meter frequency it would more likely jump to the "160M" receiver,
rather than the "AM-160M-120M" receiver as had happened before.
Network outage: The
Internet connectivity - but not power - to the WebSDR's remote site was
lost for just short an hour in the morning, not related to the power
issues - a likely consequence of weather plus the
"remote-ness" of the site itself.
24 November, 2019:
Typos fixed in web page scripts - Waterfall issues on WebSDR1
In the 25 August, 2019 (and possibly other)
entries I mentioned the erratic waterfall on WebSDR1. This
morning I finally got some time to carefully go through the scripting
using some debugging tools and noticed two (apparent)
to throw errors. While none of these actually "broke"
the errors caused the parser to "pause" briefly for a couple hundred
milliseconds, a couple of times per second. The result of
was that the waterfall was a bit erratic at times - and while the
higher priority of the audio stream took precedence, it's possible that
this also made the audio stream a bit more "fragile" than it otherwise
would be, possibly increasing the probability of audio drop-outs when
the Internet was busy. Another typo was found on WebSDR2, but
this hadn't had any discernible effect on performance.
The errors were fixed and the
waterfall issues on WebSDR1 seem to have disappeared.
23 November, 2019 - Web
server issues - Blank screen and/or "This Page not secure" warnings:
Some updates were made on the
main web server (not
the WebSDRs themselves) and some there were some
unexpected results - namely the web server automatically reverted to
use 'https' (secure)
web connections". This "broke" the links to the WebSDR
servers themselves as they cannot
use "http" - the "insecure" connection mode. It took a little
while to figure out what had changed and fix it.
A "blank" page: Unfortunately,
if you had tried to connect to the WebSDR via the landing page during
this time your browser's cache would have included the instructions to
use "https" - and this is not easily purged by simply refreshing the
web page. In some cases, simply closing the browser and
restarting it will "fix" it, but in most cases it is required that one
purge the browser's cache by doing into the browsers "options" menu.
It should be noted that this
problem did not/has not affected only
the Northern Utah WebSDR, but many other WebSDRs have been "victims" of
this browser behavior where attempting to go to the WebSDR will result
in nothing happening - but this is also fixed by clearing the
"This Web Page is not secure"
In some cases, you may have gotten this type of warning where
could allow an exception to this rule. If you keep getting
try closing/restarting the browser - but if this doesn't work, clear
the browser's cache.
Update - 23 November,
It's unclear whether or not the
power utility has finished the work - but we are suspecting that they probably have not.
When one of our correspondents spoke with the line crew, it
was indicated that they would try
be done by Friday, 22 November, but there was some question as to
whether all of the materiel required to complete the job would be
available to fit this schedule. Because the "final" work was
expected to cause an extended outage - and we didn't see one - we are
presuming, pending official word, that the final work remains to be
done and that we can still expect one or more extended outages.
Because of the upcoming
Thanksgiving Holiday week in the U.S.,
it is possible that the completion may be further-delayed - but this is
conjecture since we have no easy means of checking with the crew.
18 November, 2019.
Utility Power Interruption:
What happened today: Work
began on the power feed to the Northern Utah WebSDR site and power was
cut for a while to facilitate that work. For various reasons,
didn't get prior notice of this work or else we'd at least have posted
To make sure things would
recover correctly (they
didn't!) one of the local hams visited the site and found
Failed circuit breaker.
When the room was entered, a loud buzz was heard and it was
discovered that the circuit breaker feeding the radio gear had started
to burn up. This breaker was swapped with an on-site spare.
WebSDR 3 would not power up.
WebSDR3 wasn't powering up and it was discovered that the IEC
power cord on the power supply had oxidized and had partially melted.
A new cord restored the service.
One of the KiwiSDRs
had not recovered. Likely
because the utility power did not come up "cleanly", one of the three
on-site KiwiSDRs was stuck in a boot cycle. A "proper" power
cycle restored operation.
What is happening: The
local power utility has begun a replacement/upgrade of the spur power
line feeding the Northern Utah WebSDR site. This power feed
very old and obsolete, providing the site with "unregulated" power
between about 90 and 140 volts: The power has been fed
via two legs of a 4160 volt open-delta feed - and if you know
about these things, you'll begin to understand why this upgrade is
being done. Due to future needs in the vicinity, the line is
being upgraded to a modern 12kV circuit.
What is being done: Because
is being replaced - with the possible exception of some of the poles -
power may be on/off for several days, and since there are no
residentical customers on this circuit, the power company may simply
de-energize the circuit until the work is complete.
Will the WebSDR be up? Because
of the duration, the use of a UPS is not really practical, but we may
try to apply generator power. Because this site is quite
frequent tending of a generator to feed it gas is a bit onerous and
even if we are able to do this, there may still be interruptions.
Please expect lengthy
Computers are computers:
Whenever computers or networking gear are
power-interrupted, there is some
chance that something may not recover due to "improper shutdown",
voltage transients, or possible stressing of a piece of hardware.
We will deal with that as we are able, but recovery from such
events may take a while.
When will this be complete?
have been told by the utility that the work is expected to be completed
by Friday, 22 November, 2019 - but due to equipment availablility (such as new transformers)
work may take longer than this.
Remember:This circuit has no
residential or commercial customers per-se, so it is likely that the
utility power will be offline for days at a time during the transition
as the old, obsolete gear is removed and more modern gear is installed.
9 November, 2019.
Bandpass filters on 15 and 10
meter receivers retuned and levels adjusted.Using
a vector network analyzer, the bandpass filters on the 15 and 10 meter
receivers were readjusted for maximum flatness across the amateur band
frequencies and this results in a more "even" waterfall - particularly
on 10 meters. In both cases some component values had to be
for the desired result. The levels were also tweaked a bit,
for the compromise of the lowest input signal that would "tickle" a
sufficient number of A/D converter bits (these bands use RTL-SDR dongles
with frequency converters)
to work well under very weak-signal conditions, yet allow for a
reasonably strong total amount of signal power. These
now tolerate a bit over -46dBm (roughly
before they might go into overload. In the future, these
bands will be
equipped with the same AGC blocks that are now in use on the 90-80, 60,
41-40 and 30 meter receivers which will prevent them from overloading
in the presence of many strong signals - which will hopefully happen in
the next few years as the new sunspot cycle starts to come up and these
higher bands have better propagation.
Modification of main splitter
One of the boxes splits the signal from the antenna between
"narrowband", high-performance receivers and the "wideband" receivers (e.g. AM-160-120, 90-80, 60,
41-40, 30, 25, 19 meters and the KiwiSDRs) and
it was "discovered" that the design of splitters had about 2.5dB more
loss than it should have at the highest band (10 meters)
The first splitter - which feeds all MF/HF
recdeivers and the second splitter (which
feeds all of the "wideband" receivers) were
replaced with a different design that had been verified to have lower
loss from 25 kHz through 30 MHz. This should improve
performance on the 17 through 10 meter bands.
12 meter signal path modified.
The absolute noise floor and the "maximum signal before
level of the 12 meter receiver was checked and it was observed that two
much gain was present in the signal path. An amplifier was
dropping the absolute RF level by about 16 dB - but there was no loss
in ultimate sensitivity, further indicating an excess of gain.
effectively increased the dynamic range of this receiver by a
Amplifier swapped out.An
RF amplifier in the signal path to the KiwiSDRs was discovered to roll
off in gain below about 7 MHz, causing the absolute sensitivity of the
Kiwi SDR receiver to suffer - particularly on 160 and 630 meters.
amplifier that had
been used for 12 meters was redeployed: This amplifier has
far better signal dynamics than the previous amplifier (which had been modified to fix
the low-frequency roll-off issue) and should improve
signal performance on all of the KiwiSDR receivers. The
improvement is quite marked on 630 meters.
KiwiSDR Splitter changed.
It was noted that in testing, the four-way splitter that
feeds the three KiwiSDRs started to increase in attenuation below 1 MHz
- and since the KiwiSDR has coverage down to about 10 kHz, the extreme
low end (particularly
below 500 kHz)
was being impacted. A custom four-way splitter capable of
response from 25 kHz to 30 MHz was installed, improving performance
below 1 MHz.
S-meter calibration readjusted on
the Server #2 (green).
the above changes, the S-meter calibration was checked and readjusted.
It was also noted that the 30 meter S-meter calibration was
hot: This changed required a server restart, kicking everyone
off. "Fortunately", 20 meters was very dead at the time and
people were using it.
There have recently been brief outages (1-2 minutes at most)
that may be caused by equipment resetting on one of the links providing
Internet connectivity to the WebSDR site itself: We are
into this issue.
November, 2019: Apple iOS 13 audio issues:
With the recent release of Apple iOS 13 there have been
complaints by users about the lack of audio, particularly via web sites
that stream audio - and it would appear that users of WebSDRs and
KiwiSDRs are similarly affected. This is not a
problem with the WebSDR/KiwiSDR but an artifact of a change in iOS 13.
A quick look via a search engine will reveal many steps that
others claim to work - but, at the time of this writing, there is no
obvious single "fix". One such page detailing possible steps
to take is HERE.
are able to solve this problem on your device, please let us know via
the email address on the ABOUTpage.
different browser: In at least one case, the
"Start Audio" button was present on the Chrome browser, but not the
Safari browser, so it is recommended that you try more than one browser.
changing audio settings in Safari: Go into
"Preferences" and changed the setting for "When visiting other
websites" from "Stop Media with Sound" to "Allow All Auto-Play" and
reload the page.
are using Chrome or Safari, you may have to click the "Audio Start"
button just above the upper-right corner of the waterfall display - and
you can read more about that here.
UPDATE - 11
Via a bit of sleuthing and with help from Gary C., we have
determined one possible cause of audio issues with Apple products.
It would seem that Apple may have made some changes in the
their browsers indicate their version to the WebSDR. What was
happening was that the WebSDR was not recognizing those "new"
designations and not presenting the user with special code to make
Apple products work. It was also observed that the "iOS Audio
Start" button was no longer appearing on some Apple devices and
browsers, but this change (hopefully)
has fixed that. If you are using an Apple product and still
having issues with the WebSDR, please email us using the link on the "About"
October, 2019. "White screen" when trying to go the WebSDR if
their browser was already in HTTPs mode:
have been getting occasional reports of users getting just a white
screen when clicking on the links to the Northern Utah WebSDR servers
themselves - in other words, the main page would load, but nothing
happened when one tried to listen. Because we hadn't seen
issue and could not replicate it, we didn't know what was happening
until "Tom" figured it out and passed along the information.
Here's what was happening:
The Northern Utah WebSDR's
but does not require, the use of "secure HTTP" (e.g. "https").
If a user arrived at the
landing page with their browser in "https" (secure) mode and
tried to go to a WebSDR server to listen, there was a problem:
The WebSDR servers themselves currently cannot use https -
and directing from a secure page (https)to an the
WebSDR servers themselves (not
"secure" - running only http)
would cause the browser to see this as a potential security issue and
prevent the page from loading - often with no obvious error unless one
dug around inside the browser's debugger.
To be clear: If the
user had already arrived at the site in normal "http" mode (e.g. "http://sdrutah.org"),
there would not have
been an issue in the first place.
Pretty much all other
WebSDR sites use only
"http" mode. When we talk about "http" being "not secure"
this simply means that you would not
want to use this mode to conduct transactions that require encrypting -
like passwords, banking, personal info: The WebSDRs are, by
their very definition, "public"
and no credentials are required, so this is not an issue.
In other words, if you had gone
to "http://sdrutah.org" (rather
than "https://sdrutah.org" - which may be the default of some browsers)it is likely that you - like most
users - would not have ever
seen a problem.
links on the main "sdrutah.org" page now explicitly use "http" to
direct users to the WebSDR pages. This change should be
transparent to most users - although it is possible that some
browsers/firewalls may flag this: If this happens, simply
the site as part of your "trusted zone".
26 October, 2019.
approximately 0137 MT on this day the connectivity to the Northern Utah
WebSDR was lost: It appears to be a problem at one of the
(several) wireless "hops".
Update: 0950 MT:
One of the main wireless Internet trunks (on a licensed frequency)
is offline, apparently affecting the feeds to several broadcast
stations as well. It is being worked on.
Update: 1020 MT:
The Internet connection is back up.
10 October, 2019.
Added "manual" gain control:
A manual gain control - just
below the volume control - has been added to the WebSDR interface.
The default is "AGC
On" in which the gain is automatically controlled by the
amount of signal within the receive passband.
manual mode, a slider is made accessible and the overall gain may be
adjusted from minimum to maximum by moving the pointer to the left or
When in manual mode, please
note the following:
Too little gain:
The audio will be very quiet and accompanied by lower-level
noise and distortion.
Too much gain:
The audio will be distorted badly/noisy, particularly on
signal peaks and static crashes.
The signal levels on
HF can vary by 10s of deciBels
which means that a satisfactory manual setting can become
"unsatisfactory" very quickly - particularly between different
stations. For this reason, the manual gain control is most
to be useful on local nets and/or under conditions where the
propagation is very
You will probably have to
"ride" the manual gain control if you choose to use it.
When in doubt, always use AGC On mode.
28/29 September, 2019.
Caused by severe weather, there
was a widespread power failure in parts of northern Utah (Box Elder county)
the WebSDR site and the sites of some of the
hops and the duration of this power failure was long-lasting,
exceeding the capability of most UPS (battery back-up)
of the morning of 29 September, it is believed that the power has been
restored to most of the sites involved, but it is not sure that this is
the case - and it may be that not all Internet gear has recovered
gracefully, so one or more site visits may be required to verify the
presence of utility power and diagnose/restore lingering issues.
Because of the remote-ness of the locations involved, it will
take some time to do this.
would appear that the extended power failure didn't actually affect the
WebSDR site itself, but rather one of the "hops" for the Internet
connection, which did not come back up gracefully. The
connectivity was restored approximately 12 hours after it was
25 August, 2019.
Slow/erratic waterfall problem on WebSDR1 now fixed - TWO
HTML updated: The
above change didn't actually solve the problem, but a bit of
testing revealed that there was some sort of typo in the underlying
HTML used on WebSDR1 that had been the cause of the waterfall issues -
but not serious enough to actually show up with the debugging tools
built into a browser. The debugging was done by copying the
the suspect HTML from WebSDR2 (where
things worked fine) to a test file on WebSDR1 and
observing that it worked properly, so the (minor)
modifications that are specific to each WebSDR were made to this copy
and dropped into place on WebSDR1. Note that a "reload"
the fixed code, but closing the browser (or just the tab with WebSDR1)
and opening it again does
load the fix. (No,
I didn't bother to go through the two files and do a comparison to see
where the problem really
It was observed that running some Ad Blockers on the WebSDR
seems to cause its own problem with the waterfall. At the moment
there are no advertisements on the WebSDRs themselves - but various
other scripts (e.g.
weather station reporting, perhaps one of the "widgets" at the bottom
of the page)
seems to interfere with the timing of the waterfall causing it to move
in fits and starts. If the waterfalls' being a bit jerky
you, consider disabling the ad blocker on the WebSDR main interface
18 August, 2019.
on WebSDR1 (Yellow):
was noticed that, for the past "little while" that the waterfall
scrolling on WebSDR1 was a bit erratic/slow when there were 50+ users -
something that was not true several months ago: This was likely
not related to network connectivity or processor loading as this was
not occurring on
WebSDR2 or WebSDR3. On a hunch, the WebSDR service on WebSDR1
stopped and the log files - some of which were approaching half a
gigabyte - were renamed so that the WebSDR service - and the operating
system - did not have to deal with such large file structures.
of the time of this writing, it is not known if this "fixed" the
5 August, 2019.
On-site power failure:
Likely due to very intense
local thunderstorms (there
were many in the area then!) the utility power at the
WebSDR site was off for an hour between approximately 2305 (on August 4) and
0010 local time - and since there is no UPS currently on-site (see notes on 31 July site visit)
there was no way to provide back-up power.
It's worth noting that the UPS,
had it been working, would have only provided 40-50 minutes of back-up,
anyway, so there would still
have been an outage. As far as can be determined, everything
came up automatically and is working again.
4 August, 2019.
on the "AM-160M-120M" band:
It has been observed that the "AM-160M-120M" band
is being overloaded at time. It would appear that one of the
single-frequency notch filter (specifically,
the one tuned to 1160 kHz)
is suffering some sort of intermittent connection: When this
notch filter is working properly, the signal level at this frequency
should be in the area of -48dBm - but when this notch is non-functional
that signal may exceed -30dBm, causing overload of the analog/digital
converter in this receiver.
If you have been using this receiver for 160 meters, it is
recommended that you use the dedicated "160M"
receiver, instead: It is completely different hardware and it
unaffected by this issue - and this receiver has higher performance,
Why are there two receivers
that cover the 160 meter band, anyway? Why not - the hardware
for the "AM-160M-120M"
receiver is capable of working over a 2 MHz range, so allowing some
overlap was trivial - and the dedicated 160M receiver misses the top
and bottom 4-5 kHz of the 160 meter band.
31 July, 2019.
Main 12 volt supply
ailing 12 volt supply that runs the all of the softrock receivers and
RF amplification has been replaced with a heavier-duty commercial unit
that has also been equipped with - but does not rely on - a cooling
fan. This has restored the gain of the various amplifiers in
signal paths and gotten rid of the strong hum components in the center
of the 160, 17 and 12 meter receivers.
Cooling fans replaced on
original fans that had come with the KiwiSDRs' metal cases were of
rather poor quality and out of four receivers owned, all four fans had
failed after about a year. Name-brand ball-bearing fans were
located and installed.
Pre-processing for KiwiSDRs
changed: To account of the differing dynamics of
the HF bands over its frequency range (e.g. lower HF frequencies are
noisier and signals are generally stronger than on the high end)
a "limited attenuation high-pass filter" had been constructed to reduce
signal levels below approximately 10 MHz by about 12dB (e.g. 2 "S" units)
to prevent overload when strong, lower-frequency signals were present -
particularly when additional gain (10-12dB)
was added. The original filter attenuated all
of these lower signals, but a new filter was constructed that provided
the same attenuation below about 10 MHz, but offered minimal
attenuation below the AM broadcast band to restore sensitivity at these
lower frequencies where the main receive antenna is already rolling off.
UPS issues: It
was noted on a previous visit that the UPS had failed, but
further investigation revealed that a transfer switch used to allow
swapping out the UPS - or adding a second unit - had "welded" a
contact and that when the UPS was active, its input was connected it
its output, damaging the UPS. The UPS and transfer switch
been retrieved and repair or replacement (as appropriate)
will follow. The entire system had to be powered down to
remove the transfer switch.
LF/MF power supply repaired:
The power supply that fed the signal path for
below approximately 400 kHz (on
the KiwiSDRs - and 2200 meters on WebSDR3)was
repaired. There are still some issues with the LF/MF antenna
that feeds this signal path that will be addressed on a later visit,
but it is working - more or less. Initial indications are
the receivers are working about as before on 2200 meters, but
additional work is needed to optimize performance.
80CW/40CW bands swapped:
was observed that these two bands were swapped. It seems that
these to bands transposed themselves: It is unknown if this
happened today, or a few days ago when it was discovered that the UPS
had failed and an unplanned power outage had occurred. These
bands have the same model USB sound card and this is no doubt related
to the fact that USB enumeration becomes "flaky" when you have more
that one of the same-type device: Usually, using the same
physical port keeps things in order - but apparently that doesn't always work.
27 July, 2019.
Main bus undervolt and
degradation of receivers:
few days ago it was observed that the gain of the "broadband" signal
path had decreased - an issue manifest by a noted drop in gain of the
"AM-160-120M", 15 and 10 meter receivers and an across-the-board gain
of the KiwiSDRs plus the appearance of strong mains-frequency hum in
the middle of the passbands of the 160M, 17M and 12M receivers.
On a brief site visit the main 12 volt bus voltage was
and it was found to be about 8 volts with a significant amount of AC
mains ripple on it - explaining both the loss of gain due to voltage
reduction of several RF amplifiers and the hum on the 160M, 17M and 12M
of the main 12 volt power supply indicated a "semi-catastrophic"
failure of several key components - but much to our amazement, it was
still working... sort of. An attempt was made to reconfigure
power supply to help it along, but the parts/pieces were not on-hand
for this impromptu visit: This condition - which appeared
a week ago - will have to remain until we can get a new power supply on
In this current state, all
of the receivers are at least slightly affected, but the impact on most
of the receivers is difficult to discern because the signal marginwas just adequate (from the beginning, by design)
to be able to tolerate some amount of degradation.
The power supply for the MF/LF
signal path was repaired, restoring service.
is unfortunate that the testing of the power supply had to occur at a
time that concided with the Utah Beehive net - we are sorry
26 July, 2019.
Web Server offline:
several hours today the "sdrutah.org" web page was inaccessible during
several outages - some of them quite long: This issue did not
affect the WebSDRs themselves - only the "landing page". This
problem from the July 18 operating system by the web hosting service:
Apparently, they've had their hands full, having
something when they did updates of their customers' servers - and they
going back and fixing the issues.
22 July, 2019.
MF/LF Signal Path
It would appear that the signal path that provides signals at
frequencies below approximately 400 kHz is offline - the cause is
unknown. What this means is that 2200 Meter receiver is deaf
signal below approximately 400 kHz are not present on the KiwiSDR
receivers. This issue will be addressed on a future site
19 July, 2019.
Quick site visit:
KiwiSDR1 and KiwiSDR2 had gone offline due to fan
failures and heat. All three KiwiSDR units were relocated to
a lower location (because
and their top covers removed. The fans in their cases were
inexpensive sleeve-types: They are to be replaced with
better-quality ball-bearing types on a future visit.
Flaky cable on KiwiSDR3:
It was observed that the antenna cable feeding KiwiSDR3 was
intermittent. A spare was on-hand and the problem was fixed:
The end of the flaky cable was clipped off preventing its
While there, the UPS was checked - and it was found to have
failed. It has been removed from the circuit by virtue of an
transfer switch that allows swapping/replacing computer power sources
without interrupting the load. Unfortunately, the load was
interrupted when the UPS, trying to go online, "chattered" instead of
simply dropping out when it failed to carry the load causing all
servers to reboot - but everything came up cleanly - I think...
18 July, 2019.
Server upgrade by web
the evening of Thursday, 18 July, 2019 at around 1800MT the
"sdrutah.org" web pages were unavailable. This situation was
temporary - lasting less than an hour - as the Web hosting service
upgraded the server from Ubuntu 14.x to 18.x. No changes
be visible to the users upon completion of this upgrade.
5 July, 2019.
"Bug" fixes on new pages.
with the new pages it was not possible to embed the frequency and mode
with the URL, but that has been fixed now - we hope. You can
include the frequency and mode if you like, as in: http://sdrutah.org/websdr1.html?tune=7272lsb
- which will go to WebSDR #1 and tune to
7272 kHz, lower sideband.
The redirect did not previously
work with the Microsoft
Edge browser: It appears to do so now.
The "buttons" on the WebSDR GUI
sent you to another WebSDR server to cover a different band had
been "kludged" to work with the new scheme - but they didn't really do
what they were supposed to
do - which was to send the user to the "new" web pages - because of the
inability to embed the frequency and mode in the URL: They do
Low gain on the KiwiSDRs below
has been observed that at frequencies below the AM broadcast band, the
KiwiSDR is a bit "gain starved" - a result of the "Limited attenuation
high-pass filter" that had previously been installed to prevent it from
being overloaded on signals below 8 MHz. At some future
this filter will be modified to "pass around" such frequencies.
information about this high pass filter, read the article "A Limited Attenuation High-Pass
Filter for the KiwiSDR". This
article does not yet include information about the modification to
allow the <500 kHz energy to pass through.
19 June, 2019.
Internet connectivity has, at times, been suffering from jitter and
delays - a likely result of ongoing issues with one of the wireless
hops connecting the site. To remedy this situation, we will
transitioning to a different Internet Service Provider. Because of
will be an interruption to this WebSDR system
during the transition. The exact timing of this change is yet
be determined: Additionally, there may be the complication of
this system needing to change its URL. We will
attempt to give as much notice as possible prior to this change. In the
meantime, occasional drop-outs may be mitigated by increasing the
buffering using the Audio
Buffering drop-down menu just below the WebSDR's volume
The "loss" of reception on the "20CW", "20PH", "17M", "15M",
bands was, as suspected, caused by damage to the amplifier common to
all of these receivers. This amplifier, based on a Gali-74+
proved to be susceptible to what was, at the very least, a "close"
lightning strike. The MMIC was replaced and reception was
restored on these receivers.
In reality, none of these
receivers suffered any damage and remote analysis had shown that these
receivers were just really
deaf - to the tune of 30-40dB or so.
"160M" receiver was also preceded by one of these same Gali-74+ MMIC
and this amplifier, too, was damaged by the same strike. A
this MMIC restored this device to normal operation.
above damage to the amplifiers occurred despite the fact that these
were "downstream" of fairly heavy-duty gas discharge tubes andRF
filtering - both of which would have served to greatly reduce the
amount of transient energy from the strike - but it wasn't apparently
enough for the
MMIC amplifiers. To prevent a similar failure in the future,
more "sensitive" protection device was added - one that has both a
gas-discharge tube and
high-current limiting diodes.
worth noting that in the other signal paths, discrete transistor-based
amplifiers - based on the venerable 2N5109 - are being used, and none
of these suffered any damage, likely due to the fact that this rather
rugged device can (briefly)handle several watts without
The Gali-74+ is used in some of
the signal paths because of its lower noise figure (3 dB versus 6 dB)
and higher gain (21 dB
versus 17dB) than the 2N5109-based amplifiers.
In the "High
split" signal path (for
these devices allow the receivers to "hear" the thermal noise floor
more easily, particularly on 10 meters.
one of these devices on 160 meters helps make up for the
relative deafness of the receiver module (a SoftRock II Ensemble) that
is being used and the
fact that the main antenna, which is designed for 3-30 MHz coverage,
has lower signal output at 160 meters than on 80/75 meters.
40 meter receiver modified:
Previously, a single RF
amplifier was used to feed both the "40CW"
- and internal to this module, the input signal was split
two ways to feed the two softrock boards. After this receiver
been built it was determined, during the construction of the modules
for 80/75 and 20 meters, that the best performance was obtained
by using separate amplifiers for each, individual softrock board - each
amplifier following the outputs of the internal RF splitter:
Doing this greatly reduced
the amount of
local-oscillator crosstalk between the two receivers which can, in some
cases, cause low-level spurious signals to appear in the presence of
very strong signals.
this end, a pair of RF amplifiers - one for each receiver - was added
to the existing circuitry, inside the receiver module's box.
adds 3-4 dB to the noise figure of the receiver because these
amplifiers are now subject to post-splitter loss, but this factor is
unimportant on 40 meters owing to the naturally-high noise and signal
this amplifier freed one of the "general purpose" amplifier blocks
allowing us to replace a "temporary" amplifier that had been built for
the 17 meter receiver, helping to clean up the layout a bit.
Sound cards replaced:
As noted in the 1 May entry,
the USB sound cards that had been used for "40CW" and "40PH"
failed - apparently succombing to the same fate as is common with Asus
Xonar U5 and U7 sound cards. These two cards - a U5 and U7 -
replaced with a pair of U7s. The failed cards will be
attempt to determine a "fix".
At the moment, the "40PH"
receiver is still using a Xonar D1 which has someone inferior image
rejection as compared to the U5 or U7 - but it was decided to do this
in case a USB sound card fails (again!)
so that the risk of losing coverage of 40 meter phone - one of the most
popular bands - will be minimized.
It had been observed on a
previous visit that one of the guy wires on the recently-replaced
deadman (on the tower
supporting the log-periodic beam)
had unscrewed itself - a clear result of our not having remembered to
add "safety wires" to prevent this. Because of the limited
length, it had not been possible for a single individual to reconnect
this without proper tools, but with several people on-hand for this
visit we could, collectively, pull just
enough to engage the turnbuckle threads.
Safety wires have been
run through all of the turnbuckles to assure that this will not happen
again. With the (temporary)
loss of this cable, the integrity of the tower was in no real danger -
but it needed to be taken care of, just the same!
8 May, 2019.
it rains, it pours - and flashes lightning!"
"20PH", "17M", "15M", "12M" and "10M" receivers offline.
Due to an apparent lightning
strike, the receivers listed above are offline (extremely deaf, actually).
This strike apparently wiped out two RF amplifiers in the
signal path: The one for the "160M" receiver, and
another amplifier that provides gain for all amateur bands above 30
In the meantime, the "AM-160M-120M"
receiver can provide a degree of coverage for 160 meters.
Unfortunately, there is no
similar back-up for the 20-10 meter bands' receivers.
will likely take a site visit to restore operation and it is expected
that this will occur in the next 3-5 days. In theory, these
amplifiers could be bypassed to restore some semblance of operation,
this is unlikely to happen before a "proper" site visit might occur.
1 May, 2019.
Sound card failures:
to other issues, it would appear that there has been a failure either
in two of the three USB sound cards on WebSDR1, or something amiss with
the USB interface on the motherboard. In the past, we "lost"
of these sound cards in a similar manner: Everything was fine
until the system was restarted, at which point the sound card refused
to operate at the higher speed (e.g.
USB 2.0) necessary for full 192 kHz band coverage.
In doing research, this type of
been documented elsewhere, so it is not unprecedented.
a "work-around", the "80CW" sound card is now being used for "40PH",
restoring full coverage of the SSB segment of that band.
Unfortunately, image performance will suffer slightly because
"I/Q Balance" equalization could not be done - but this will go
unnoticed in the majority of cases.
"80CW" and "40CW" are using the "failed" hardware, but since it can
operate only at 48 kHz, the coverage of those bands is limited.
For coverage of the missing 80CW
and 40CW segments use the back-up "90-80M" and "41-40M"
receivers on WebSDR3 in the meantime.
A site visit to repair/replace
the errant hardware will likely occur within a week of this date.
revisited - Audio stream stopping when a new tab is opened in the
As noted below (see 8 April entry)
there is a known problem with the Firefox browser: Clicking
on a link to open a new tab may
cause the audio stream from the WebSDR to stop.
This issue has been reported to
Mozilla and it is believed that a "fix" is in the works.
If the audio stops because you
have opened a new tab, there is currently no known way
to restart the audio short of refreshing the web page.
Unfortunately, this may reset the frequency/mode, requiring
one to re-tune the radio.
If at all possible,
open a link using a "right click" and select "open a new tab":
For whatever reason this seems less likely to interrupt the
29 April, 2019.
WebSDR system offline:
WebSDR system was offline for around a day due to some issues with the
server - possibly caused by nefarious activity. Because the
"WebSDR guy" (me!) happened
to be on vacation when this happened, it was a day or so before one of
our "alternate" operators noticed and restarted the system.
"40CW" and "40PH" bands semi
off-line - running at reduced bandwidth:
Not directly related
to the above issue, the
sound cards for the "40CW"
bands are refusing to initialize properly after a system restart.
This is a known hardware/software "bug", but it seems to show
only rarely. At the very least, the server will need to be
completely powered-down, requiring a site visit.
initial symptom of this was "cutting out" of the audio until these
cards were reinitialized for 48 kHz bandwidth - but this has the
side-effect of allowing only
1/4 of the previous band coverage.
UNTIL THIS PROBLEM IS RESOLVED,
please use the back-up "41-40M" receiver on WebSDR3.
While this receiver isn't quite as good as the normal
receivers, it works nearly as well under most conditions.
8 April, 2019.
Audio stopping with Firefox when
you make the browser busy:We have become aware of an
issue with Firefox regarding audio: Sometimes the audio
will stop - and not restart - if, on your browser, you open a new tab,
of if you have opened several tabs with the WebSDR running in the
background and have done something in another window/tab that has
momentarily caused your computer/browser to become busy.
easiest "fix" for this is to reload the web page which, unfortunately,
is likely to reset the frequency/mode to which you are listening.
We don't have any other suggestions at this time.
Little/no signal on KiwiSDR3 WebSDR3:(Note:
I meant to write "KiwiSDR3" - there was no problem with
WebSDR3). It would appear that I didn't get the
"RF Input" SMA connector
tight when working on KiwiSDR3 which means that only the strongest
signals show up at all. One of our volunteers is likely to be
the area in the next couple days and will (hopefully)
get time to drop by and take care of the problem.
only two of the least-used WSPR "bands" are on this receiver (the now-deprecated 80 meter
frequency and one of the 60 meter frequencies) so not much
is being missed.
2 April, 2019.
Local power outage: The
local utility is working on the lines and power to the site was lost at
0915. Because we were informed of this ahead of time (one of the local power guys
occasionally uses this WebSDR system) we were
pre-positioned and put the site on generator power when it went out,
running on UPS for only about 15 minutes, total.
of the extended outage, we were on-site, tending the generator, taking
advantage of the time we are here to do other work on the system, as
in the distance we saw the power crews working on the lines that feed
the site. In speaking with one of the utility employees - who
came by to make sure that everything had come back up - he said that
they "... did a lot of
work... replaced a lot of glass" meaning that more than
just insulators were replaced.
power was restored at 1755 local time - an outage of 8-2/3
- a bit ahead of schedule despite the rather rainy, miserable weather.
RTL-SDR identification script
installed on WebSDR1: We have finally
installed the script on WebSDR1 that automatically identifies - via
programmed serial number - which RTL-SDR dongle is to be used for which
script had been installed on WebSDR2 and 3 a while ago, but WebSDR1
seemed always to be too busy to interrupt everyone and restart the
system - but since there were warnings plastered all over the place
today, we thought that it would be a good opportunity.
script solves the problem where it would matter which RTL-SDR dongle
was plugged into which USB port - and how many dongles there were.
Because one must always use the same dongle for the same
frequency band (because
of RF filtering) it was a huge pain to make sure that all
of the dongles got sorted out right: This script eliminates
all of that mess!
17 Meter coverage expanded:The
sound card previously used for this band had a sampling rate of only 96
kHz, which meant that a bit more than 4 kHz of this band (2-3 kHz )
was left off at each end.
The new card has a 192
kHz sample rate, so the
entire band - plus several 10s of kHz beyond the top and bottom - is
Fully-covering 12 meters will
require a bit of juggling of
hardware, but since 17 meters is open far more often than 12 during
this part of the solar cycle, 17 meters
Log Periodic beam checked:
Despite a drizzle and a modest breeze, the 80 foot tower was
scaled and leads were clipped to the bloody-end of the remaining coax
at the top that connects to the massive 6-45 MHz log periodic beam (a Hy-Gain/U.S. Antenna Products
LP-1002) so that it could be checked: This
antenna is set on a bearing of 87 degrees (true) and is not
an antenna analyzer, the beam was swept and the VSWR was found to be in
line with the antenna's specifications over the 6-45 MHz frequency
not absolutely definitive, this result indicates a high probability
that this antenna is working as it should. Had any elements
"bad" or had there been a short/open in the open-wire line that feeds
this antenna's elements, the results would have been much different.
Because this antenna does
seem to be OK, we have even fewer excuses for not
using it - stay
Radio/Internet link tweaked:
We have observed that the wireless Internet connection to the
site has been having intermittent issues over the past several months.
Having some time to check
things out, we noticed that over two of
the three wireless links that connect the site there were occasional
packet loss/jitter issues that were traced down to the radio's
"switching gears" (e.g.
modulation) frequently. While this is supposed
to be "loss-less" (according
to the manufacturer, at least) anyone
who uses these radios knows that this isn't strictly true: At
very least, this constant modulation change will cause queuing of data
and increase jitter (not
idea for streaming audio!)
and in severe cases, packet loss.
To "improve" performance, the
radios' configuration was changed so that they would not attempt
too-high a modulation method, staying at a lower, more stable rate.
This reconfiguration significantly improved one link and made
noticeable difference on another - which seems to have other issues
which will have to be addressed.
"40PH" and "80CW" receivers
"un-swapped": On a previous visit (see the 30 December, 2018 entry)
the "80CW" and "40PH" receivers had been swapped because it was
considered that with 40PH using a USB interface, it may have been less
reliable than the sound card. It was later noted that the
card to which we had moved "40PH" had inferior out-of-band image
less-effective low-pass filtering) than the original
USB-based card (see 24
March entry) - so it was moved back to the original USB
was observed that despite several attempts at I-Q amplitude/phase
balancing, the in-band image rejection on the "80CW" receiver is not as
good as we'd like it
to be: This probably doesn't directly relate to the problem
mentioned above - but it might. Because this is a lesser-used
band and because the image rejection is "OK" it was decided to leave
this mystery for another day...
Because there are now (lower performance)
redundant receivers for 80/75 and 40 meters, if we experience a failure
on either of these bands on WebSDR1 we are covered!
Gain increased in the
KiwiSDR "HF" signal branch: About 9 dB of additional gain
was added in the HF signal path that feeds the KiwiSDR stack (e.g. from about 400 kHz to 30
MHz) as an experiment to improve weak-signal performance.
A bit more improvement is still needed in the LF signal path (below about 400 kHz)
but that will have to wait for a day with nicer weather.
KiwiSDR fans relubricated:
It would appear that the cooling fans in the KiwiSDR's cases
somewhat inferior oil/lubricant - a common complaint with inexpensive
Chinese-made fans whether they use sleeve or ball bearings.
fans in all three Kiwis (which
use sleeve bearings) were relubricated with a PTFE-based
oil that is known to greatly improve the lifetime of these fans.
24 March, 2019.
Power line noise:
recent high winds and heavy rain, insulators on the power lines
near-ish the WebSDR site are again making some noise, most strongly in
the 2.5 and 5 MHz area. While this noise is occasionally
on 160, 80, 60 and 40 meters during daylight hours, it is usually
inaudible at night when these bands typically get noisier -
particularly as the summer season approaches. We continue to
with the local power company to minimize this issue.
Update on RTL-SDR "gain block" (see 26 February entry):
that the AGC circuits for the RTL-SDR receivers for the 90-80, 60,
41-40 and 31-30 meter bands have been in use for about a month, I'm
pleased to report that the results have been very good:
modules have been very successful in preventing overload from strong
signals on those bands while allowing enough system gain for good
would appear that the 31-30 meter module needs a couple dB more signal
gain during "quiet" periods when the bands are closed or in poor
The bandpass filters used for
90-80, 60 and 41-40 meters may be replaced with "tighter" versions (same bandwidth, stronger
"skirts" to better-reject other signals) - just because I
can, but this is not a high priority project.
may adjust the AGC threshold from the current setting of about 40% A/D
full-scale - which seems to be working fine - to 25% full-scale so that
I can observe the results to see if there are any improvements.
As expected, there are some
RMDR-like issues with weak signals on the RTL-SDR based receivers (e.g.
weak signals "seem" slightly noisier than they should be, particularly
if there are strong signals within the receiver's RF passband)
but these are only apparent in an "A/B" comparison between an RTL-SDR
receiver and one of the "High Performance" Softrock-based receivers:
The casual operator would likely not notice this.
no doubt, largely a result of the limited bit depth of the RTL-SDR
6 Meter receiver: So far, the 6 meter
receiver is behaving itself after the 14 March reset.
40 meter images:
It was noted that some images have been appearing at the low
end of the 40 PH
receiver from strong signals above its
For example, an SWBC carrier
can sometimes be heard at 7133 kHz from a signal at 7325 kHz:
7325 kHz is 8 kHz above
the opt of the 40 PH receiver (which
is at 7317 kHz) and this image is therefore 8 kHz above
the bottom end of this receiver (at
This defect is due to the lack
of a perfect "brick wall" filter above the 96 kHz Nyquist frequency (with the 192 kHz sample rate)
"wrapping around" and appearing at the bottom.
This issues was not
known to occur prior to the 30 December "hardware shuffle" where the
sound card that had been used for 80CW was swapped with that used for
40PH. It would appear that the "old" sound card was more
resistant to this aliasing.
plan to "re-swap" the sound cards on the next site visit because of the
larger overlap on 80 meters and the lack of very strong SWBC signals on
80/75 meters (as
compared to 40 meters)
which means that not only should this problem be less likely occur on
80CW, but the larger overlap allows user to "dodge" such aliasing
should it occur.
actual suppression of this image appears to be on the order of just
12dB - increasing to 50dB by the time one gets to 136 kHz (which correlates to 7355 kHz)
- which is much poorer than expected and why we plan to make this
14 March, 2019.
6 meter receiver
offline (WebSDR2 - Green): It
was noticed today that the 6 meter receiver is currently offline.
An attempt was made to restart the driver, but this attempt
failed with errors indicating that something was amiss with the
receiver hardware itself.
A server restart will be
attempted in the late evening when there is typically little use on the
Green WebSDR (#2).
This receiver uses an
RTL-SDR dongle, so replacing it won't be a big deal - except for the 3
hour round trip drive to do so! It is likely that replacement
will simply wait until the next trip to the site to do other work,
which will likely not occur until early April at the soonest - unless
something else breaks!
Update - 6 meter receiver back
a restart of the WebSDR service failed to bring the 6 meter receiver
back online, WebSDR2 (Green) was rebooted remotely: This
have restored operation of the 6 meter receiver... for now...
27 February, 2019.
Added "Mode" indicator:
that had been bugging me from the time we put the WebSDR online was the
fact that may not have been obvious what "mode" (LSB, USB, CW, FM, AM)
had been selected: The only way to "see" this was to take a
look at the size and position of the shape of the filter on the
waterfall display - or one could simply click on a mode button to know
for sure. I finally
got around to adding a "Mode" indicator which can be seen just to the
right of the frequency display - where it belongs.
Analysis of the RTL-SDR "gain
Initial indications are that the AGC gain block for the
60M, 41-40M and 30M RTL-SDR based receivers are working exactly as
expected. As we move into summer we'll see how it behaves in
presence of lightning static.
26 February, 2019.
site visit was made, noting that the KiwiSDRs had been offline for
about a day, apparently due to crowbarring of the power supply.
On the next visit modifications will be made to the supply
will (hopefully) make it more resistant to this.
Maximum number of users increased:
For WebSDR1 (the "Yellow" one)
the maximum number of allowed users has been increased from 90 to 125.
This should (for
the time being)alleviate
the denials of service that one might have been getting
during very heavy usage periods. In the next "month or two"
Internet connection to the WebSDR system will be changed to one that is
more robust and further increases in the number of users can be
previous modification - replacing an amplifier in the early stages of
the broadband branch- was undone. It had been noticed that
amplifier (a MMIC type),
which had been replaced to provide a bit more gain and lower system
noise figure (again,
for the broadband branch)
was causing low-level intermod and the problem was assumed to be
overdriving of the subsequent stage. When a gain adjust was
after this "new" amplifier the problem did not diminish and several
weak spurious signals were seen drifting through the 0-30 MHz passband
from this branch indicating that this amplifier was oscillating -
likely at VHF/UHF - and was likely responsible for the problems.
Unfortunately, this could not be tamed with components
the previous known-stable bipolar amplifier was re-installed.
"New" Bands - "90-80M" and
improvements to 60 and 30 meters: A
newly designed and built module containing four bandpass filters, each
followed by a wideband AGC gain block was installed in front of four
RTL-SDR based receivers on 60 and 30 meter bands. Two "new"
were installed at this time on the "blue" server (WebSDR #3)
- 90-80 Meters and 41-40 Meters.
These cover all of the 80 and
meter bands, respectively, but also their adjacent SWBC bands, namely
41 and 90 meters.
These "bands" provide a usable
"back up" for the popular bands (80/75
and 40 meters): In
the event that
WebSDR1 were to go offline and could not be restored remotely we would
point users to WebSDR3 where it is likely that they could operate as
RTL-SDR based they are considered to be "low performance" receivers -
but they should be "good enough" for casual use when signals are
AGC gain block in front of each of the respective RTL-SDRs is designed
to prevent the RTL-SDRs from "seeing" signals that average more than
about 1/2 full-scale on their A/D converters, which should prevent
overload. The use of this module also allows these dongles to
run a bit "hotter" than on normally would, improving their performance
when the bands are "quiet" with the AGC preventing overload when very
strong signals (mostly
shortwave broadcast) are present.
These modules will be described in more detail, soon.
60 meter receiver also runs through an AGC gain block allowing its
sensitivity to be increased while preventing it from being overloaded
by strong SWBC stations.
30 meter receiver has a newer, "tighter" filter to improve its
performance and it also has an AGC gain block like the 60 meter
receiver which should also improve both weak and strong signal handling
21 February, 2019.
modification was made to the code on all of the Northern Utah WebSDR
servers so that the default amount of audio buffering is now 0.25
seconds rather than the original 0.125 seconds buffering.
slight increase (by
1/8th of a second)
is likely more appropriate for real-world Internet connections and
should reduce the number of audio drop-outs. If desired, the
original value may be selected from the "Audio Buffering" drop-down
most common cause of audio drop-outs is the changing of the "focus" of
the operating system away from the browser window with the WebSDR.
For example, if you switch the browser to a different tab,
to a different program or even minimize a browser window your computer
will dedicated fewer system resources to processing the WebSDR audio.
Slower computers are more prone to audio dropouts in this
Increasing the buffer may
help this situation, but it is often a matter of the computer not
processing the data from the WebSDR often enough in its round-robin
servicing of the running applications to keep the system's audio buffer
Another cause of drop-outs is
the heavy use of ones Internet connection - perhaps due to watching
videos from online services (e.g.
Netflix, Amazon, Hulu, YouTube, etc.). In this
case, more buffering will likely reduce the likelihood of drop-outs.
11 February, 2019.
would seem that all three KiwiSDR units on site went offline at about
1702 MST on 10 February (0002,
11 February UTC).
this was investigated on 11 February (at approx. 1125 MST) it was
both halves of the redundant 5 volt linear power supply had
that is, its overvoltage protection had tripped. Unplugging
supply for 60 seconds to allow the capacitors to drain and plugging it
back in restored operation. The cause of this
currently unknown: Because these supplies are in "diode-ORed"
configuration, one of the power supplies could have tripped out
earlier without being noticed. We are considering means of
monitoring/resetting this and other power devices.
29 January, 2019.
Audio drop-out issues:
has, in recent days, been more data jitter on the Internet connection
to the WebSDR site: Our network guru is looking into this
to see if there is a reason/fix for this. An upgrade of this
equipment is pending warmer weather and the availability of time to do
control of the "additional audio buffering" has been enhanced to allow
the connection to better-deal with "flaky" connections. There is now a
drop-down menu labeled Audio
that has several options
This uses about 1/8th of a second of audio buffering, which
works out to approximately 1/4 to 1/2 second of total delay between the
signal arriving at an antenna and you hearing it on your
computer, assuming minimal latency of the Internet and your computer's
Another 1/4 second is added to the audio buffering. This is currently the "default"
setting for buffing on this WebSDR system.
This adds another 1/2 second to the amount of audio
This amount of extra delay is generally tolerable if you are
using the WebSDR as your primary receiver during a QSO.
adds a bit more buffering - one whole second more. This amount of buffering may be
a bit painful/awkward if you are participating in a round table or net.
This adds two
seconds more of audio buffering. While this is fine for
casual monitoring of signals, you
probably don't want to set it like this if you are involved in a net or
a round table!
The waterfall and S meter are always near real-time and not
affected by the
change in buffering: As more audio buffering as added, the
waterfall and S-meter will increasingly seem to "lead" (e.g. be ahead of)
the audio that you hear.
There are several possible causes of audio drop-outs in
addition to issues that may be occurring at the WebSDR site:
Internet connection may be a bit "jittery": This is common
cable modem connection and Wireless Internet connection during "busy"
evenings) when everyone is watching TV/movies online.
computer may be "busy": If your computer is doing something
the background while you are running the WebSDR in a browser it may
drop-out occasionally.If the
computer is "too" busy to process the data that it is getting, extra
buffering may not help.
have minimized and/or put the WebSDR browser page in the background.
If you have switched to another task, the web browser won't
given as much processor priority and audio drop-outs can occur.
computer is "too" busy to process the data that it is getting, extra
buffering may not help.
mentioned in a previous posting, additional gain installed in the
broadband coupler (which
feeds the KiwiSDRs, the SWBC, AM BCB and 60 meter receivers) has
resulted in occasional intermod/spurious signals being audible on the
above receivers - particularly a few "shortwave" sounds being audible
in some places on the AM broadcast band. This will be
corrected on a
future site visit when there is time to do a proper "gain balancing".
13 January, 2019.
Comments on work that was done on the WebSDR system on this
All WebSDR servers:
the original dual-core 2.93 GHz processors with 3.0 GHz quad core
processors. This should allow more stations to use the
and experience fewer audio drop-outs and faster response. To
sure, the most common cause of audio drop-out is on the Internet
connection between the server and the user and not due to the server
itself as well as in user's computer - particularly when the web
browser being used is operating in the "background" - especially when
other programs are running.
LF filters installed on Server
It was observed that the power factor correction circuitry in
servers produced a strong signal in the 125-140 kHz range and it was
hoped that this was the source of the noise that was clobbering the
2200M/1750M when using the E-field whip. Unfortunately, that
noise source was not (mainly,
at least) from the power supplies, hence the installation
of the H-field shielded loop mentioned below.
2200M/1750M antenna changed:
A low-noise shielded H-loop was installed for the 2200M/1750M
receiver to help reduce the gaw-dawful noise that was present.
installation the loop antenna was rotated to null the noise source that
was found to be either to the north or the south. What this
is that all signals originating from locations due north/south of the
Northern Utah WebSDR site will fall into this null on any frequency
below about 350 kHz - both on the "2200M/1750M" band on WebSDR3 and on
receivers on site when tuning below 400 kHz.
7 January, 2019.
Maximum number of users
increased to 90 on WebSDR1: It
was observed that the number of users on WebSDR1 would occasionally hit
maximum user count (75)
prompting an increase on that server - a change that required a restart
of WebSDR1, which occurred at about 0630, 7 January, 2018, UTC.
The current settings for the
maximum number of users are:
WebSDR1 (yellow): 90
users. WebSDR1 is, by far, the busiest of the servers as it
both the 40 and 75 meter phone bands which are the mostly heavily used
for nets and ragchewing.
75 users (no
60 users (no
30 December, 2018. Comments on work that was done on
the WebSDR system on this day:
Partial failure of
sound card:A (previously-planned)
site visit was made on this day and it was discovered that the USB
interface of the sound card used for the "160M"
band had degraded, unable to connect at USB 2.0. For whatever
reason, this malfunction rippled throughout all USB interfaces and
similarly affected the two other USB sound devices. The
device was swapped out and all devices are now working properly.
USB-based sound devices are used in addition to PCI/E devices
because of the limited number of plug-in slots in the servers.)
Because the "40ph"
band is one of the mostly heavily-used it was decided to swap the "80cw" sound card (a PCI interface card)
and the "40ph"
in an effort to obtain greater reliability. One slight
is that the card being used on 40ph has a more apparent "hole" at the
center of its
coverage (at 7221 kHz)
as a result of a slight roll-off in amplitude at low audio
frequencies of the sound card/receiver combination. In
practice this "hole" causes only a slight effect
in the audio response of SSB signals that are atop it.
Installation of a 2200-1750 meter
The antenna was connected to the 2200/1750 meter receiver on
Unfortunately there is some AC mains related noise (possibly a switching power
that seems to be parked in its coverage range that can degrade its
overall sensitivity. The cause (and remedy) of
this will be investigated on a later visit.
the noise source, this receiver seems to perform reasonably well in the
upper portion of the "LowFer" band to the top of its range (180+ kHz).
KiwiSDRs, which are also coupled to this new antenna below 350-400 kHz,
seem to be doing reasonably well with WSPR reception on the 2200 meter
band - probably because the required bandwidth for WSPR operation is
very small and it manages to evade some of the noise components.
Improved receive performance
below 350 kHz:
Below approx. 350 kHz added filtering/amplification in the
receive chain and a new LF/MF antenna combine to provide 2200M coverage
on WebSDR3 as well as on the KiwiSDRs.
Lower noise amplification
Lower-noise amplification (based on the Mini-Circuits
Gali74+ MMIC) was installed on the "high" branch of
the main filter network provide some additional gain and a 3-4dB lower
noise figure on bands 20 meters and up: This also improves
performance of the 17 and 12 meter receivers in particular as their
hardware (each, a
SoftRock Ensemble II) is slightly "deaf".
A similar amplifier was
for the 160 meter receiver to make up a slight gain deficit of that
particular hardware (also SoftRock Ensemble II) as well.
Finally, yet another
lower-noise/higher gain module was installed in the broadband coupler (which feeds the KiwiSDRs, the
SWBC, AM BCB and 60 meter receivers).
The levels for this change in gain have not yet be properly
"balanced" resulting in occasional intermod/spurious signals being
audible on the above receivers - particularly a few "shortwave" sounds
being audible in some places on the AM broadcast band. This
be corrected on a future site visit.
Additional RFI suppression on
cables: Some snap-on ferrite filtering was
installed on cables entering/exiting the building (network, RF) and a
visible reduction of "computer" and power supply noise on 2 and 6
meters was noted.
A thorough I/Q rebalance was performed on the 80cw, 40cw and 40ph
receivers: A rebalance for 80cw and 40ph was required because
a change in the hardware used for those bands.
On future visits,
other bands will be rebalanced to minimize image response.
27-28 December, 2018.
Problems on WebSDR1:Seemingly
because no good deed goes unpunished, a known bug related
to USB hardware reared its head: Several of the USB ports
- starting with the 160 meter receiver's sound card - suddenly
"downgraded" their connection from USB2.0 to USB1.1.
The upshot of this is that the 160m, 40cw and 40ph
bands - all of which use USB-connected sound cards (Asus Xonar U5 and U7)
- could no longer
support a sample rate greater than 48ksps - a far cry from the needed
it was just the 160 meter band that had this problem so a reboot was
performed remotely - but the problem spread to the other two sound
cards that provide 40 meters, also USB devices..
researching this problem it became clear that any means of completely
resetting the USB hardware via command-line was unknown - but the
work-around was simple: Completely remove the power from the
computer for a short time to allow the hardware to reset. (Note: Even when the
computer is "off", the USB hardware may still be powered up.)
This was tried, but the problem didn't resolve:
have been some sort of subtle hardware failure, or it may be
required to keep the unit powered down for a much longer time than was
As a temporary work-around, the
receivers' connections have been swapped to restore full 40 meter phone
coverage, albeit at the expense of some 80 meter cw coverage:
Because 40ph is the more-popular band, we believe the
to be worth-while.
The errant hardware (160M, 80cw and 40cw after the above
has been reconfigured for 48ksps, but this dramatically reduces the
frequency coverage on those bands/segments, but it's better
note that while only partial 160M coverage is available on the "high
performance" receiver, the "AM-160M-120M" receiver should work fine for
most 160 meter use.
At the next site visit (scheduled for 30 December)
we will investigate this problem and try to determine a "permanent" fix.
26 December, 2018.
Comments on work that was done on the WebSDR system on this
Intermittent outages:Some portions
of the system were brought on/off line to facilitate work on the WebSDR
System outage:All WebSDRs
on site were down for about 90 minutes due to a localized power failure
while we were working on-site.
Addition of a 2200/1750 meter
receiver: A new receiver was added to WebSDR3 (blue)
to provide coverage of the 2200 Meter amateur band and the 1750 Meter
experimenter's band. Unfortunately, the coaxial cable for the
antenna was not available at the time so the outside antenna was
mounted and hardware tested with a signal generator. The coax
from the antenna will be run in the next several days, in the meantime there will be no signals audible
on this receiver.
Another KiwiSDR added: A
third KiwiSDR receiver has been installed and added to the "pool" of
KiwiSDRs. One should connect only to
KiwiSDR1: If all of its receiver
"slots" are used up, you will be forwarded to the next available slot
on #2 or #3. Please refrain from using the
KiwiSDRs for frequencies/bands that are already covered by the main
Low LF/MF signals levels on the
The signal levels below 530 kHz on the KiwiSDRs are lower
they should be - but this will be corrected during the next site visit.
The reason for this is two-fold:
An LF/MF diplexer was added to
the signal path: Frequencies above approx. 350 kHz will come
from the main HF antenna (the
and those below 350 kHz will come from a newly-installed E-field whip.
Because the whip is not connected at this time, signals below
about 350 kHz are cut off.
The addition of the
diplexer/combiner network caused a 3-6dB loss at LF/MF frequencies,
putting the (already
signals at these frequencies below the A/D threshold of the KiwiSDR.
A "gain realignment" will be done on the next visit to bring
signals back up to proper levels.
Another visit to the WebSDR site
is tentatively scheduled for Sunday, 30 December, 2018.
16 December, 2018.
Powerline noise: The
powerline noise has been quiet recently (knock on wood)
and it is not known if this can be attributed to repairs by the
utility, or because of the season
and recent "washing" of the lines' hardware by rain and snow.
hope that it never returns!
Some powerline noise appeared again two days after originally
posting this - go figure...
Modification of S-meter "peak"
A "bug" has been fixed that
prevented the "peak" value display below the S-meter from
actually reflecting the peak value.
Additionally, the peak
reading now has a "hang" to it like a real-life S-meter in that it will
drop from the peak (with
a timed-exponential decay rate)
instead of the previous, "chunky" updating. What this means
that the peak signal level will persist for a fraction of a second and
then drop, increasingly quickly, until it senses a new peak either from
an existing signal or when it hits the noise floor. This
has no effect on the receiver AGC.
"Signal Strength" plot feature now has two more items in its drop-down
menu: Both a "fast" and "slow" version that uses the peak
instead of the instantaneous value. Because the "peak" value
"peak-an-hold with decay", signal plots of signals that vary
considerably in strength (e.g.
will be reduced from a scattering of dots to more coherent lines.
Because the "peak" value of the S-meter has an exponential
you will see this downward curve in the signal level
24 September, 2018.
Modification of "Bandwidth" menu:The "wider" and "narrower"
buttons that had been to the right of the mode selection (USB, LSB, AM, etc.)
have been removed as they were redundant: These same
settings and more
were already available under "Passband Tuning" just below the mode
selection. The removal of
these buttons makes the box slightly narrower and may help improve
layout/presentation at some screen resolutions.
A long-running issue has been powerline noise. Some
culprit poles have been identified, but it is entirely up to the power
company to decide when something might be done about them. At
present the worst powerline noise is centered in the general area
around 2.5 MHz - outside any amateur bands - but it can affect the low
bands (160, 80, 60 and
daylight hours when these bands are typically very quiet.
21 September, 2018.
Sedona, AZ WebSDR shut down: After
about 6 years of operation, Steve, W7RNA has shut down the Sedona
WebSDR. Steve, W7RNA says, "...I have taken down the WebSDR
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."
We would like to thank Steve
for having provided this valuable
service and those of us at the Northern Utah WebSDR have been the
grateful recipient of his technical advice and expertise.
"AM-160M-120M" band coverage
shifted: The center of this band was shifted
slightly so that it's center frequency (which is also the default frequency)
lands squarely atop an even 10 kHz interval rather than several kHz
off, barraging the user with distorted music. At present
no way to select a default frequency other
than shifting the entire receiver's passband and this limits our
selection if we wish to be able to receive over this frequency range.
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
a way around this.
10 September, 2018.
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
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
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
up to 8 users, but only the first two users on each will get a
full-bandwidth waterfall display: These recording channels do
use any of the waterfall capabilities. The results of this
may be seen at the wsprnet.org
with the contributor being "KA7OEI-1". It is hoped that
efforts will enable things like contributions to the RBN (Reverse Beacon Net)
17 September, 2018.
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
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.
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
fixed as of about a week or so ago: We were just watching it
see if it was really
fixed before updating this and the main WebSDR pages.
We have identified the suspect poles and passed the
to the power company. All we can say is: "They will
when they do."
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
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
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
Intermodulation on some lower
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
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.
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
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
no known work-around yet so it's recommended that you use
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
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
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
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
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
are a number of "extensions" that allow reception/analysis of various
types of signals, including RTTY, FAX and WSPR. There is also
"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.
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
and 120 minutes for WebSDR #3 (blue).
7 July, 2018.
who use the WebSDR on 80/40 meters during the day will likely have
noticed an elevated powerline noise floor: At night, this
is submerged in the normal background noise of these bands.
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
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
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
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
the power company: Particularly in light of the failed
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
RTL-SDR dongle and
the finite "sharpness" of the band-pass filters, the image rejection at the
14.67 MHz CHU (Canadian
is only about 8dB at the 14.13 MHz image frequency. While
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.
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 receivers 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 inevitable 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 other kind 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 cacophony 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 investigate 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 downconverter was constructed and with an RTL-SDR dongle,
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 "exercised" 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 intermittent 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 of 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 see.
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
back haul 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 (believe
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
ground wave (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 resistive 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 evidence 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