Northern Utah WebSDR
Latest news and current issues
Recent events and resolved issues:
5 August, 2020 - Issues with WebSDR #2:
There were issues with WebSDR #2 (Green) where users were getting incomplete/intermittent audio and waterfalls.
that the issue was an errant software package, known to occasionally
cause issues, that was disabled: We are hoping that the problem
is resolved - but one never knows!
The problem appears
to have been the Linux "SnappyD" service - which is apparently known to
occasionally go rogue, causing excess usage of resources. Since
this is not really needed for the rather stripped-down systems used for
WebSDR service, this was removed.
1 August, 2020 - Site work:
building containing the WebSDR receive hardware was repainted using a
white, IR-reflective "RV" paint to reduce the thermal load - particularly during
these days of high (>100F, >38C) temperatures. The (mostly) bare metal of the exterior of the building went from being too hot to touch to being about the same temperature as ambient.
As the building is normally not air conditioned - except
when someone is there working on something. Until the recent
addition of a thermostatically-controlled vent fan, the interior of the
building would often exceed 125F (52C) - and with the fan this was reduced to about 10-12F (about 6C) above the outside temperature.
repainting of the building should reduce the heat even more and
minimize the during of the vent fan's operation. In case you are
wondering why we don't run an A/C unit all of the time, just consider
what the power bill might be! Computers are are usually just fine at
"reasonably hot" (100F/38C) temperatures, anyway.
Comment on 8/4: After several days of monitoring since painting, the interior temperature is now typically 4-5 degrees F (roughly 3C) above the outside temperature.
Power transfer relay replaced:
WebSDR's equipment has been powered via a simple transfer relay that,
when the UPS power is present, will supply power via that route - but
if the UPS power disappears, it will switch to another power source.
This box has allowed us to work on the UPS without
interrupting the power to the equipment, simply by powering down the
UPS and the relay transferring the load to a non-UPS source - or, if we
so choose - another UPS.
new relay is more rugged, and it includes voltage sensing and a delay
on the "main" power input so that the UPS has time to come up to full
voltage and power before the relay switches.
Brief system outage: Because
all gear is powered via this box, everything at the WebSDR site had to
be powered down when it was changed, resulting in an outage of 5-10
AM broadcast band notch filtering added on RF feed from the beam:
Despite the LP-1002 beam being designed for 6-40 MHz, it does a very good
job of intercepting signals well outside this range - including
the AM and FM broadcast bands. In fact, it does a decent job of
being a (more or less) omnidirectional antenna down through the AM
While some "strong" filtering was
in place to remove the AM/FM band energy, a few of the stronger AM
broadcast band signals were still still able to get through the filter
with a significant amount of energy, so four notch filters were added,
tuned to the four strongest signals to further reduce the possibility of signal overload.
As mentioned in an earlier entry, some of the receivers (notably the 40 meter receivers on WebSDR #1 and the 20 meter receivers on WebSDR #4)
are prone to drift a few 10s of Hz with temperature. This is a
known issue and we are working - as time permits - on a means of
compensating for this.
30 July, 2020 - Brief outage:
appears that there was a brief outage of a major data circuit that
feeds a signicant portion of Northern Utah a bit before 1500 MT on this
day. This interruption temporarily caused the loss of
connectivity to the Northern Utah WebSDR - not to mention many other
customers throughout the region.
25 June, 2020 - Comments:
WebSDR Telemetry transmitter: A
CW telemetry transmitter has been added on site and you may hear this
at 28.569 (USB). This beacon includes indoor temperature,
humidity - and their minimum and maximum voltages. Also conveyed
is the power line voltage (min and max) and it records low (<100 volts) and high (>135 volts) excursions - and it counts power outages and measures their durations.
The temperature/humidity min/max readings are reset at local midnight.
The mains voltage min/max readings are reset at local midnight. every "even" 5 minutes. (Changed 4 August, 2020)
Possible interruption in Internet connectivity: Earlier this week (6/22-6/23) the Internet backhaul provider (not our ISP) had routing issues.
17 June, 2020 - Comments:
Weather Underground widget removed: It
would seem that Weather Underground has finally discontinued support
for their older widgets, meaning that the small display of current
conditions that had appeared in the upper left corner of the WebSDR
pages quit working. We have replaced the widget with a link to a
page that will display weather at the Northern Utah WebSDR receive site.
is unclear whether owners of personal weather stations - one of the
largest contributors of raw data to the Weather Underground monitoring
network - are currently entitled to free "widget" service.
We are looking for alternative widgets that can interface with the Ambient Weather network - preferrably for free.
Slight frequency drift with temperature: Users of some bands (40 meters on WebSDR #1, 20 meters on WebSDR #4 - and a few other bands) may be noticing a drift of a few 10s of Hertz at times.
is due to the use of FiFiSDRs for these bands and the use of similarly
un-compensated oscillators on some of the other affected bands being
affected by changes in ambient temperature.
We are developing a means of automatically compensating the frequency to remove the (majority) of this drift.
Brief outages: There| were (probably) several brief outages today as our ISP upgraded some of its equipment.
Changed mode switching on WebSDR #4.
had been commented by users that the automatic sideband selection on
WebSDR #4 wasn't working as expected. By default, the WebSDR code
is supposed to work like this:
Default to LSB for 160, 80 and 40 meters and USB for everything else.
If, when on a band where USB is normal, one is on LSB, the mode is "swapped" when switching to a band where LSB is normal.
some reason the LSB mode was often being selected when users connected
to WebSDR #4. Code was changed so that the default is now to always select LSB for 40 meters and USB for the other bands... I hope...
31 May, 2020: Power outage at WebSDR receive site.
would appear that the AC power (from the utility) went off at
approximately 0843 MT, the on-site UPS taking over at that time.
about 1230 one of the locals brought over a generator to keep the site
online. The generator remained online until the early evening.
Both the UPS and generator are RF-noisy, causing a bit of QRN on most bands.
later learned that the cause of the outage was vehicle versus power
pole: Apparently, a rather large truck was able to take out two
or three power poles - and then another vehicle, swerving to avoid the
accident, took out another pole on the other side of the road.
Needless to say, it took hours for the utility to repair the
was a brief interruption when power was transferred back to utility
power: Apparently our automatic transfer relay - a device we
installed to allow us to switch power sources without interruption -
didn't work properly, so all servers were dumped, but brought back online
immediately. We'll look at this issue during the next "major"
25 May, 2020: Slight receiver frequency adjustments.
While most of the receiver local oscillators at the Northern Utah WebSDR use TCXOs (Temperature-Controlled Crystal Oscillators)
the FifiSDR and SoftRock Ensemble receivers do not: These
receivers use the Si570 synthesizer, instead. Because of this,
they drift slightly with temperature - roughly on par with that of a
typical, modern HF transceiver with a factory reference.
The bands that may drift slightly with temperature are:
160M, 40CW and 40PH on WebSDR #1 which use FifiSDRs.
17M and 12M on WebSDR #2 which use the Softrock Ensemble II receivers.
20CW and 20PH on WebSDR #4 which use FifiSDRs.
30M and 17M on WebSDR #4 which use Softrock Ensemble III receivers.
I was able to get a utility working that allows "live" tuning of the
FiFiSDRs and wrote some simple scripts that allow "on the fly"
adjustment of the local oscillator frequencies and several of the
receivers (40PH on WebSDR #1 and 20PH on WebSDR #4) were slightly adjusted to bring them closer to being "dead on". Eventually, a script
will be implemented that will allow better frequency-versus-temperature
compensation to minimize the amount of apparent drift.
Because of the nature of the local oscillators used in the aforementioned receivers (e.g. the use of the Si570) they do not readily lend themselves to being externally referenced (e.g. OCXO or GPS.) The
only practical way to do this would be to introduce a known-accurate
and stable frequency into the RF chain and make occasional measurements
of the resulting audio frequency.
22 May, 2020: WebSDR receive site offline due to lighning
around 1800 MT the connectivity to the Northern Utah WebSDR's receive
site was lost when a lighning strike took down one of the wireless hops
of our Internet Service provider.
was restored a few hours later. It was mostly a matter of
power-cycling everything and doing a minor reconfigure to work around
damage to one of the backhaul radios: Equipment will be replaced
later as necessary.
15 May, 2020: WebSDR receive site offline due to rodentia.
At approximately 1830 MT the Northern Utah WebSDR's receive
site went offline: Service was restored about 6 hours later, a
bit after local midnight.
The outage was caused by rodents (rats?)
chewing through an Ethernet cable at a linking site. The cable
was replaced and measures were taken to help prevent this from
1 May, 2020: Site visit.
A site visit was made on this day to address several issues:
40 meter band-pass filter added to 40 Meter receivers on WebSDR #4.
As noted in the 25 April, 2020 entry, the 40 meter receivers on WebSDR #4 ("40CW-E" and "40PH-E") were being overloaded by extremely
strong signals in the adjacent 41 meter shortwave broadcast band,
causing spurious signals to appear at time due to generated
intermodulation distortion. A major challenge is that the top of
the 40 meter amateur band (7.3 MHz) is the bottom of the 41 meter shortwave broadcast band meaning that some of the strong signals were very close to the top of the band, making filtering difficult.
A somewhat complex band-pass filter was constructed in an
attempt to reduce the likelihood of intermodulation distortion by
strongly limiting signals outside the 40 meter band. This filter
provides offering more than 20dB of attenuation below 6.9 and above 7.4
Another KiwiSDR added on the beam's RF signal path.
A second KiwiSDR was added to the signal path from the
LP-1002 beam that feeds WebSDR #4 to allow expanded WSPRNet monitoring
and to free up more channels for general listening. At the
moment, these KiwiSDRs are not publicly available, but we are considering doing so.
A revised "limited attenuation" high-pass filter was
installed in the KiwiSDR signal path - this filter offering more
attenuation at lower frequencies than the previous version.
It was observed that even though this filter has more low
frequency attenuation than the previous, it is not enough to handle
both the extremely strong signals from the 49 and 31 meter shortwave
broadcast bands and
to have enough gain to hear the noise floor at 10 meters. It
would seem that a bit more revision of this filter will be necessary!
New high/low pass filter module added to WebSDR #4 signal path.
As noted in the 11 April, 2020 entry a makeshift high/low
pass filter was installed to prevent overload from both AM and FM
broadcast signals that were happily intercepted by the beam. A
more "permanent" filter was constructed using the "proper" components (NP0 capacitors, carefully adjusted toroidal inductors) that was made to be small enough to be installed in the enclosure containing the amplifier.
The "high pass" portion of the filter was set to (more or less)
pass 160 meter signals, but block AM broadcast band signals by at least
30dB - apparently, this wasn't enough as some of the signals are quite
strong. This will necessitate either modification of the filter
to add frequency-specific notches (for the strongest AM broadcast signals) or a redesign of the filter.
Even though the antenna's "official" frequency range is
6-40 MHz, it can still receive signals well below 6 MHz - albeit at
lower gain and with undefined directivity. Because noise/signal
levels are so high at these frequencies, one can losegain and be able
to hear the bands' noise floors - which means that you can still hear any signal that might be present. This modification was performed to allow signal analysis from this antenna (via WSPR signal monitoring) to determine the viability of this antenna at 6 MHz and below.
Low-pass filter network added to main WebSDR feed:
Even though it had not been observed to be an issue, a 40
MHz low-pass filter was added to the main RF feed from the TCI-530
omnidirectional antenna that feeds WebSDRs 1-3.
Installation of 160 meter band-pass filter "permanentized":
The 16 February, 2020 entry described how a very "sharp"
160 meter band-pass filter was added to the 160 meter signal path.
This filter's offers just 4 dB of attenuation in the 160 meter band, but 20dB at 1700 kHz
and in excess of 40 dB below about 1600 kHz.
The filter - which is
built on a small circuit board - had been temporarily wired in, hanging
in space but it was relocated/placed inside the "low split" filter
25 April, 2020: Overload issues on 40 meter receivers on WebSDR #4:
Users of the 40 meter receivers on WebSDR #4 have likely noticed that during local evenings (in Utah)
- particularly during the hours near sunset - that the performance of
these receivers is degraded. This is due to the extremely strong signals found just above
the 40 meter band in the 7.3-7.8 MHz range, the so-called 41 meter
band. The total RF power of these signals has been observed to
approach 0 dBm - which is a signal level exceeding 70 over S-9 which is enough to cause issues with practically any receiver.
these receivers are already preceded with "strong" band-pass filters,
these were mostly intended to remove the also-strong signals from the
49 meter shortwave broadcast band - and they do that nicely - but they
do little for the powerhouse in the signals in the 41 meter band.
Under construction are some extremely sharp band-pass filters that should offer significant attenuation to signals starting just above 7.3 MHz.
Compounding this issue is the persistent lightning static
that emanates from strong spring thunderstorms across the central
United States - the same direction in which the beam antenna is
pointed. These strong static crashes - combined with the already
overloading receiver - further cause degradation.
noted, the gear needed to make these modifications is currently under
construction, but construction and testing - not to mention arranging a
trip to the WebSDR receive site - will take a bit of time. Thank you for your understanding.
23 April, 2020: Noise issues on WebSDR #4 and LF.
Yesterday (22 April)
significant degradation was noted on the 17, 15, 12 and 10 meter noise
floors on WebSDR #4 along with a severe degradation in performance on
the LF receive system (<=400 kHz) as received on 2200 meters and KiwiSDRs 1-3.
issue was tracked down to an intermittent shield connection on a
coaxial cable that was common to both of these signal paths. It
was initially presumed that the cable on the end of the jumper had
failed where it connected to a grounding block/lightning arrestor, but
subsequent disconnection/testing did not reveal any problem - and when
this cable was reconnected to the same place, the issue could not be
This diagnosis required the complete interruption of the signal path on WebSDR #4.
14 April, 2020: Power bump - and attenuation added to the 40M RXs on WebSDR #4:
Power bump caused by UPS self test:
the UPS on site had gone into a "self calibration" mode to determine
the battery run time and was, in fact running on battery - and the
battery just happened to be dead, at the end of the test cycle.
Of course, as Murphy predicted, there was a power bump at that
very instant and the entire site dropped power for just a moment at
about 1233 local time.
reasons that we don't yet understand, while the WebSDR servers will
boot up and start just fine, the WebSDR program isn't always starting
up cleanly and one must remotely log in to do it manually - this took
several minutes to do for several of the machines. We have
investigated this issue, but it never seems to happen when we are
on-site and try to simulate the conditions where this happens - another
aspect of Murphy, no doubt!
of the locals was nearby and went over to the site to check on things:
The UPS was taken out of the mode where it can do this regular
calibration routine, so this sort of thing shouldn't happen again!
Attenuation added on WebSDR #4:
While there, an extra 9 dB of attenuation was added to the 40CW and 40PH receivers that will hopefully eliminate (or at least reduce)
the overload issue mentioned in the 13 April, 2020 entry. This
issue seems most likely to happen during "Grayline" propagation
conditions between the Eastern U.S. and Utah where the 41 meter SWBC
signals will go up by 20-30dB for a few hours.
will continue to monitor the situation, adding//adjusting attenuation
as appropriate. Because WebSDR #4 is a "new" system, the signal
dynamics are presently more unknown than known so further
tweaks/adjustments will likely be needed as we encounter these varying
13 April, 2020: 40 meter RX overload on WebSDR #4
would seem that we missed something when commissioning something in the
signal path of WebSDR #4: The gain in front of the two 40 meter
receivers! As it turns out the signal of some of the 41 meter
SWBC stations originating from the eastern U.S. can exceed -20dB per signal - and there were multiple signals.
At the base of the antenna there is an amplifier (about 13 dB gain) to set the system noise figure and overcome losses in the 130+ feet (40 meters)
of cable - and the 40 meter receiver, itself, contains a 13 dB gain
amplifier: Between these amplifiers, the gain of the antenna
itself, the cable and splitter losses this receiver is likely seeing a
signal that is equivalent to about "80 over S-9" - enough to overload
almost any receiver you will ever see!
When the opportunity arises some attenuation will be placed in front of the receiver, which should solve the problem.
11 April, 2020: Site visit.
WebSDR #4 (Magenta) brought online.
new WebSDR server, #4, was brought online: This server is
connected to a Hy-Gain LP-1002 Log Period antenna that is at 80 feet
above ground (25 meters) that is fixed, non-rotatable on a heading of 87°(true north reference). This antenna has never had a rotator - and it NEVER WILL.
This system covers the 40, 30, 20, 17, 15 and 10 meter
amateur bands: 12 meter is currently not covered because of
software limitations - but we are considering means of providing such
orientation of this antenna is such that it covers the Eastern United
States in its main lobe, with the far DX coverage putting the center of
coverage on South Africa with the Middle East and the Mediterranean at
the extreme north edge, near the "unity gain" points. Australia
and New Zealand are within the main lobe for "Long Path" coverage.
During this visit, it was discovered that a portion of the feedline had (literally)
disintegrated: A bit of a "kludge" was required to make a
connection to the feedline. We are looking into obtaining
replacement hardware to effect a "permanent and proper" fix.
Please note that this system is still undergoing commissioning and it may go offline or be restarted at times.
you are using this WebSDR in conjunction with your home station, please
remember that you may not be able to hear stations to the west of the heading of this beam - but those other stations might be able to you unless the antenna at your QTH is similarly directional.
was being caused to an RF amplifier module at the tower by the presence
of strong signals from both FM and AM broadcast signals, resulting in
extreme overload and intermodulation distortion. A makeshift
filter was constructed on site using cardboard from a pizza box, some
self-adhesive copper foil, inductors wound using wire found in the tool
box and capacitors from an assortment kit - the operation and
performance verified with a NanoVNA. The filter, while very ugly,
did the job.
A single KiwiSDR, dedicated to monitoring signals from the beam antenna, was added. This KiwiSDR is not (yet) available to the public.
If you have any comments about this antenna and its receiver please send them to email@example.com
4 April, 2020: Site visit.
Reduction of power line and computer noise.
common-mode filtering was strategically added to reduce common-mode
noise from power lines and computer power supplies caused by
circulating currents on some of the internal coaxial connections.
of common-mode noise on "LF" signal path - namely the frequencies below
about 350 kHz covered by the 2200/1750 Meter receiver and the KiwiSDR.
Noise issues below about 30 kHz still need to be addressed.
the first time in decades the on-site LP-1002 log periodic antenna has
been connected to receive gear. Some time in the past the
feedline from the antenna to the ground was cut near the top and the line that went
from the tower to the building is not to be found. Approximately 80 feet (24 meters) of 1/2" Andrews Heliax cable (LDF4-50)
was run inside the tower, to the ground and is connected to an
interface box a bit above ground level. From there, a temporary
feedline runs to the building.
While the antenna (more or less)has
the expected VSWR curve, it is unknown if it is working properly.
Via a radio at the tower base, the bands sounded "ok" and a QSO
was made, but this is a very subjective test. This antenna weighs
about 3/4 of a ton and being at its
height, it's not easy to mechanically inspect the antenna.
are some signal level issues that need to be addressed and it is
unknown to what extent they may be due to the new gear, cabling or the
In the building another WebSDR server is online to allow testing/debugging of this antenna: This WebSDR is currently not available for public use pending this debugging/completion. Stay tuned!
would appear that one of the main backbone Internet connections for
much of Utah and according to the provider, Utopia Networks, they lost some key hardware in their
network core. The effect may have been worst in Northern Utah.
a result the ISP providing the service for WebSDR - which uses Utopia
as one of its main Internet providers - switched to a much lower-speed
backup to maintain some
connectivity for their customers - but this also caused extremely slow
connections to the WebSDR making it impossible to maintain an audio
connection at times with packet transit times often exceeding 3 seconds.
degradation of service lasted from around 1900 to a bit before 2300
MDT. At about 0130 local time on 31 March the faulty hardware -
which had been reset (with much crossing of fingers, no doubt) was replaced.
25 March, 2020: "High Boost" added to the Northern Utah WebSDR servers:
A button marked "High Boost" is now present on the Northern Utah WebSDR servers. When activated, this provides a 6 dB boost to audio with the curve of the response "knee" centered at 1500 Hz.
This button may be useful for high levels of DSP noise reduction which can have the effect of suppress higher audio frequencies.
The high frequency boost may also be beneficial for those with high-frequency hearing loss, to improve intelligibility overall.
19 March, 2020: Internet restrictions relaxed - for now.
Our Internet Service Provider has notified us that bandwidth restrictions imposed by their Internet
backhaul providers have been lifted and with their knowledge, we are
configurations of the WebSDR servers back to their original
configuration in terms of audio compression, waterfall speed, number of
users and time-out limits. These changes require the servers to
be reset so we are waiting for the number of users to drop before doing
that Internet usage has increased dramatically in many areas owing to
the increased need by industry and education for remote access. Because of this you should expect heavy Internet usage that will likely affect connectivity to all web sites at times.
WebSDRs, being nearly real-time, can have only minimal buffering - unlike
many streaming services - which means that they are more affected by
slow-downs in Internet traffic as they cannot simply "pre-fetch" (buffer)
seconds/minutes of content to accommodate.
18 March, 2020: Utah earthquake
At 0709 MDT there was an earthquake (5.7 reported as of writing) that was centered just north of Magna, Utah - approximately 11 miles (17 km)
west of downtown Salt Lake City - just a "little one" for many
indicate that the most severe shaking was
very localized with power outages and damage to unreinforced masonry
structures in the immediate area and several trailer homes having
fallen off their piers. Elsewhere in the Salt Lake
valley the reports vary from "A loud truck going by" to "Holy $#!+".
Businesses and warehouses have reported loss of inventory due to
items having fallen off shelves and tipping/collapse of shelves.
of this writing, there are no reports of serious injuries. Dozens
of aftershocks have been felt all across the Salt Lake area - some of
them quite strong, but so far non have been greater than 4.7 - a
magnitude less than the main 0709 MDT shock.
For the most part, services (power, water, Internet)
have been minimally affected overall with the mobile phone service possibly having been impacted by the
expectedly-high call/text volume. Initial reports are that outages are restricted to very local cases where specific
sites may have had equipment disruption (e.g. loss of power/connectivity).
As far as can be determined, the Northern Utah WebSDR - which is about 70 miles (110 km)
north of Salt Lake City - saw no interruptions in power or service.
If there had been interruptions in service it would most likely
have been due to follow-on effects from widespread power failure and
loss of Internet connectivity in the nearby metro areas.
Wiring damage: It
was observed that some of the receivers' signal levels were low, so a
site visit was made where it was discovered that some of the wiring on
the 12 volt bus that powers the RF infrastructure (preamps, converters, etc.)
had been pulled apart - probably because of shaking of the equipment
and rack. There were a few brief outages as the DC cabling was
re-dressed and repaired.
USB port issues:
While on site it was observed that the system was throwing errors
related to the 40CW USB receiver, occasionally causing the WebSDR
service to restart which would kick everyone off. After a bit of
reconfiguring - which required some changes to the computer, WebSDR
reconfiguration, several reboots and 15-20 minutes of being offline -
that device was moved to a different USB port where it seems to be
Dirty power on site:
few days ago a "new" UPS was put on site after the previous UPS had
been damaged by voltage extremes - and based on the complaints, the new
one was not happy at all with what it was seeing - with the AC mains
voltage varying from 90 to 142 volts - the UPS going on battery when it
was below about 105 volts or above 135 volts. In speaking with
the power company, we should not expect the situation to improve in the
short term which means that we will have to deal with it ourselves (power in rural areas is often like this) and we are considering more robust means of providing back-up power, including:
An AC mains voltage regulator
"online" UPS that can take a wide voltage input and output a consistent
125 volts. Essentially, this is would be just a wide
voltage-range 24 volt DC power supply connected to a battery and that
same battery connected to a 120 volt inverter.
If you have any suggestions - or equipment you might be willing to donate - please contact us as "firstname.lastname@example.org".
KiwiSDR #2 intermittent:
KiwiSDR #2 has been having problems, occasionally rebooting. We think that this is a result of problem with the power lead feeding it and have effected repairs, but we are continuing to monitor.
There is an intermittent power
line related noise that occasionally shows up - and we are working to
resolve this issue - but the system's noise blanker seems to be able to
remove most of it. This noise is typically the worst on 80/75
meters, but it seems to disappear at night as the band opens up and the
ionospheric noise submerges it. Several poles have been
drop-outs: There have occasionally
been periods where the audio will drop
and/or the waterfall will freeze briefly. While this is most
often a result of the user's computer (e.g. your
getting busy, pre-empting the browswer's audio processing or congestion
on your Internet congestion - particularly if you have Internet via
Wireless, Satellite or phone
- see "Miscellaneous Quirks",
below for some causes and work-arounds.
"pop" in the audio and an accompanying change in signal level:
There appears to be an intermittent cross-connection on the
antenna between a feed and guy wire that can cause noise in the
received signals and levels to
fluctuate during very windy periods on site - particularly on the
80/75 and the 630M-AM-160M) bands. A
similar-sounding - but unrelated - issue (described below)
exists with the AM demodulator. Occasionally, this
seems to be accompanied by an increase in
intermodulation distortion from AM broadcast band signals - a problem
that can affect the 75 Meter and lower-frequency bands.
outages: We are working to
"neaten up" the installation so we occasionally have to take something
off line to dress a cable, replace a connector, "permanentize" an
installation. Tasks like this will cause outages of several
minutes duration. Some work is also being done at one or more
the interim sites that provide the Internet connection that
occasionally result in outages.
switching supply "birdies":
With lots of computers comes the possibility of lots of QRM
them! Fortunately, there are no "strong" birdies, but there
some that, if they happen to sweep across the frequency to which you
are listening, will cause some mild annoyance.
quirks (e.g. "It's
supposed to be that way!"):
If the WebSDR
is not on an active window on YOUR computer: If
the WebSDR is not the currently active
window on your desktop, the computer will give it lower priority and
this will make audio drop-outs/waterfall freezes more common.
same thing can happen if your computer is "busy" doing something else,
such as other programs, updates, incoming emails, etc. The
same is likely true
with other platforms (phone,
first thing that you should do if you experience drop-outs is to switch
to the window running the WebSDR. Don't forget
that your own
Internet connection/ISP can result in drop-out issues as well.
has been observed that on a typical Windows machine, if the processor
utilization is over 65-70%, you may experience occasional drop-outs due
to delays in the operating system providing processor time to the code
that produces the audio and draws the waterfall.
updating when you switch to another window: When
the waterfall is not visible (that
is, you have switched to a window and moved the one with the WebSDR in
it will stop - which makes sense if you can't see it. What
means is that when you switch back to where the waterfall is again
visible there will often be a clear line of demarcation between what
the signals were when you switched away and when you switched back.
burst of noise across the band correlated with strong signals:
This is sometimes the result of the noise blanker that is
on all bands being triggered by the peaks of the strongest signal(s) on
the band. This effect is most easily spotted on 40 meters
the daytime where there is one signal that is extremely strong - often
on the leading edge at the beginning of a transmission - and the band
is otherwise quiet. This effect should not be confused with
things that cause similar-looking artifacts, such as static crashes
from distant lighting storms or brief signals from ionospheric and
ocean wave profilers.
listening to AM, a sudden "pop" in the audio:
It's not actually supposed to do this, but there a "quirk" (bug?)
in the AM demodulator that can cause this to happen, occasionally.
It seems to happen mainly when the signal level changes very
quickly due to QSB (fading)
but is less likely to happen on very steady signals or those with only
very slow QSB. The only "fix" for this - if it becomes
is to listen on USB or LSB and zero-beat the carrier.
The bands on
the "other" server aren't visible to me unless I go to that "other"
server: It is this way because there are several
If you notice some issues that are unrelated to those
listed abovefeel free to use
the contact info on the About
page to let
us know about it.
For general information about this WebSDR system -
including contact info - go to the about