The
Northern Utah WebSDR
Latest news and current issues
Recent events and resolved issues:
18 February, 2021: Scheduled service interruptions.
Firmware upgrade:
In the early morning of 18 February, the connectivity to the receivers
at the Northern Utah WebSDR was interrupted to update firmware on
network gear. This outage lasted roughly 5 minutes.
Maximum users on WebSDR #1 increased: WebSDR #1 (Yellow)
was also restarted to effect a configuration change that increased the
maximum number of users from 150 to 200 as this limit had been observed
to have been reached on several occasions.
27 January, 2021: Service interruptions.
One
of the upstream Internet service providers has been having utility
power issues, reportedly causing one or more service outages.
They are continuing to experience issues, but repairs are underway.
24 January, 2021: Comments.
Maximum number of users on WebSDR #1 increased: It was noted that the number of users on WebSDR #1 (Yellow)
- which had been set to 125 - was being reached during peak
hours. During the very early hours on this day this number was
increased to 150 - a task that required restarting the WebSDR service
which, unfortunately, inconvenienced about 50 users at the time: Sorry about that - but there's really no other way to make this type of change.
Alternate servers: It's worth noting that if you encounter a "full" WebSDR server at Northern Utah, you have several options:
For 80 meters: If WebSDR #1 is full, try WebSDR #3(Blue).
It's receiver's performance isn't quite as good as #1 even though it
uses the same antenna, but it would be fine in most situations.
For 40 meters: If WebSDR #1 is full, try WebSDR #3(Blue) for the same, omni antenna - or you might try WebSDR #4(Magenta) for a high-performance receiver on an east-pointing beam.
For 20 meters: If either WebSDR #2(Blue) or WebSDR #4(Magenta) is full, try the "other" receiver: WebSDR #2 uses the omni antenna and WebSDR #4 uses the east-pointing beam.
WebSDR outages due to network infrastructure:
There were several outages on this day due to upgrades to the equipment
on part of our Internet Service provider to improve performance and
reliability. The duration of these outages was minimized as much
as practical.
13 December, 2020: Frequency stabilization code tweaked to
correct for sample rate errors.
After a few days of
operation and tweaking of values, I observed that the frequency drift
had been minimized - but I noticed something else: An odd
frequency offset on the "40PH" receiver on WebSDR #1.
The problem was tracked down
to the sample rate of this receiver being about 50 Hz below the nominal
192 kHz, causing about a 25 Hz error at the band edges, becoming
proportionally less toward the center where it became zero.
The solution was the
addition of some code that applies a correction to the RF frequency to
which a user's virtual receiver is tuned. This correction factor
has been applied to WebSDR #1's "40PH" and I will apply these to other
receivers as necessary.
9 December, 2020: Frequency stabilization measures applied.
On this day, frequency
stabilization measures were applied to the "FifiSDR" and the "Softrock
Ensemble" receivers as they have been observed to drift several 10s of
Hz over the wide temperature range in the unheated/uncooled building
containing the WebSDR's receive equipment.
These devices use the
Si570 synthesizer as their frequency source and thus do not
have a means of temperature compensation, nor can an external frequency
reference (oven-based oscillator,
GPS frequency reference) be directly applied to them.
This system works by reading
the internal temperature of the WebSDR building and looking up the
appropriate local oscillator frequency for that temperature in a table
and applying it to the appropriate receiver with a temperature
resolution of 1
degree Fahrenheit and a frequency resolution of 1 Hz.
Such frequency corrections
are applied at the beginning
of every minute that is divisible
by four(e.g. 0, 4, 8, 12...)
This timing was chosen to avoid degradation of reception of data modes
that might be
adversely affected by a frequency shift during the transmit/receive
period - specifically WSPR, FT-8 and FT-4.
The magnitude of frequency
shift is typically 1 Hz - although with very rapid temperature swings (e.g. operation of the in-building heater
or air-conditioning) the frequency may be be changed in 3 Hz
steps at each four minute interval.
The possibility of an
on-site, precise, remotely-controlled signal generator has been
discussed. Were this done, a precise frequency would be generated
and measured by the receiver to determine the frequency offset.
If the current temperature-based frequency compensation method is
insufficient, we will revisit this possibility.
6 December, 2020: WebSDR outage
There was a loss of
connectivity to the Northern Utah WebSDR starting around 1313 MT,
persisting for about 80 minutes.
The cause was a disturbance
in the commercial power with severe voltage swings in a nearby town
in which one of the sites that provides Internet connectivity is
located.
5 December, 2020: VFO A/B feature added.
As suggested during the 2020
survey, A VFO A/B function has been added to the Northern Utah WebSDR
servers.
The A/B button swaps the frequency and
mode.
The A=B button copies the frequency and
mode of VFO A into VFO B
The B=A button copies the frequency and
mode of VFO B into VFO A
Just to the right of the
frequency entry bar, you will see which VFO is currently selected - and
to the right of this, in smaller font, is the frequency of the
secondary VFO (e.g. the one NOT
being used).
Please let us know if you
find any issues with this new feature - or with the WebSDRs in general
- via email at: sdrinfo@sdrutah.org
4 December, 2020: Comments about background noise.
Users of the Northern Utah
WebSDR may have noticed a somewhat elevated background noise
level. While some of this is due to the recently-increased solar
activity, some of it is power line related noise. Specifically,
noise on some of the higher bands (e.g.
20 meters) has increased somewhat.
A temporary increase in
noise at the Northern Utah WebSDR has occurred in the past - and at
least some of it is due to peculiarities of local weather and
geography. Located near the Great Salt Lake, the areas around the
lake are subjects to blowing dust and "mud rain" caused by wind blowing
across large areas of barren land exposed by the receding Great Salt
Lake. This blowing dust - and the the "mud rain" that often
accompanies brief rain storms - tends to coat everything outside -
including insulators on the power lines, causing leakage paths and
addition noise, not to mention exacerbating issues with marginal
hardware.
The result of this is often
the increase of power line noise, which can propagate for miles in some
cases.
Usually, much of this noise
will subside after a heavy rain storm or snow fall - but as of the time
of writing, there have not been any such storms for many months and the
noise is steadily increasing in the absence of a "washing event" to
clean dirty hardware.
Regardless of the noise
level, we plan to "walk" the power lines near the WebSDR server this
coming spring for a visual inspection and using portable radio and
ultrasonic receivers to divine possible hardware issues. We last
did this in July, 2018 and in the next 9 months, the power company did
fix the majority of the issues that we'd reported.
It's
worth noting that on the lower bands (160, 80, 60 and 40) the normal
band noise during the evenings will override local noise source.
Most of the noise source is
to the west
of the WebSDR site, so unless the station of interest is in that
direction at the WebSDR site, consider using the beam for 40, 20, 17,
15 and 10 meter reception as front-to-back ratio will likely reject
most of the local power line noise.
29 November, 2020: "Notch2" parameters adjusted on all
Northern Utah WebSDR servers:
On this day the internal
parameters for the "Notch2" DSP filter were adjusted to fix several
issues:
The notch filter was
overly aggressive on speech, sometimes causing audible distortion.
To improve its ability to
notch CW notes (e.g. carriers)
in the presence of noise and speech.
Remember:
"Notch1" operates at the
WebSDR server itself and is best used to attenuate a single strong tone or carriers
that may cause an S-meter deflection and receiver desense - but this
notch may "hunt" (e.g. appear to
turn on and off) in the presence of strong audio, particularly
on weaker tones.
"Notch2" operates on the
audio stream only
and cannot prevent S-meter desense, but it is more effective in the
presence of speech and noise and when the annoying tone is weaker, and
it is capable of notching out multiple tones at the same
time.
Please note that it may take several
seconds for the "Notch2" filter to become maximally effective on
weaker, background tones.
Because it's an automatic
notch filter, you should not use a notch filter on CW,
SSTV or any digital mode!
23 November, 2020: Adjustments made to WebSDR #4 and
comments about Power Line noise:
WebSDR #4 adjustments:
On this day adjustments
were made to the 15 meter and 10 meter
receiver signal paths on WebSDR #4: It is expected/hoped that
this should reduce the possibility that either of these receivers will
overload when the bands open.
Adjustments were made to
the AGC loop in the receive converters used for these two bands with
less signal being applied to the RTL-SDR receiver before the AGC action
takes place.
Additionally, the signal
level into
the AGC loop was reduced so that the "no signal" condition results in
less signal to the receivers, overall - but still more than enough to
"tickle" at least a few of the A/D bits. It is suspected that at
least part of this issue is a result of having adjusted the gain in
signal pathseveral months ago without revisiting the settings on these
two receivers.
It is suspected that there
may
be the possibility that the main amplifier in the overall signal path
is overloading - and if this is the case, it will be removed from the
system and the gain redistributed to remedy this, but doing so will
have to wait for more instances of "high signal level" conditions for
additional analysis and a subsequent opportunity to visit the site and
make the needed changes.
On a related note, two
RSP1a SDR receiver units have been ordered. These will be tested
and installed - in a receiver location yet to be determined - when we
are able to do so.
Power line noise:
It has been observed that
the power line noise has increased on some of the higher bands - namely
just below and into the 20 meter band. This increase seems to
have been related to an instanced of "mud rain" where wind-born dust
was deposted by precipitation onto everything in the area, making
leakage paths - and noise - more likely.
This noise is less
apparent on the beam antenna as the suspect power line noise source is
off the back side of it
In the past, this noise
has reduced once we have had some "clean" precipitation (rain, snow) to wash things
off. If this doesn't occur, we'll "walk the powerline" (again) and report our findings to
the power company. This was done about 2 years ago and the power
company did eventually make
repairs.
22 November, 2020: Overload conditions on the 15 and 10
meter receivers on WebSDR #4 during band openings.
With the gradual
reappearance of activity on the sun, the higher bands - namely those
above 20 meters - are starting to wake up, meaning that there are, at
times, many strong signals on the band.
Unfortunately - despite
having attempted an adjustment using test equipment in the absence of
such signals - it would appear that I didn't get the gain/knee
adjustments of the AGC circuits on the 15 and 10 meter receivers on
WebSDR #4 quite right, meaning that each of these receivers may be
prone to overload - and spurious signals - when many strong signals are
present. These receivers use RTL-SDR (V3) units - which have only
8 bits of digitization - and these are preceded by an AGC circuit with
at least three sets of interacting adjustments, and it would seem that
at least one of these need to be (ahem)
adjusted...
We are looking into several
possibilities to remedy this issue, including:
Adjusting the gain/knee
settings on the AGC circuitry.
Replacing the receivers
with other devices more suited to handling the expected signal levels,
such as the RSP1a.
I suspect that we'll do the
first in the immediate future and then work on doing the second item.
Left:
The trench being dug. The soil on site is packed hard with roots,
but when broken up is very light and dusty so "sanding" the trench
wasn't required. Right: The trench dug -
about 147 feet (47 meters) in
length.- with the cables in the process of being laid, and the trench
filled back in as we proceeded.
Fortunately, even though cold - it was sunny and calm when we did the
majority of the outside work. The beam is that just
left of center while the omni antenna can be seen in the background,
near the left edge. Once the trench was closed we walked along
its length, first packing the dirt and pulling more into the slot and
then driving over it with a vehicle. Click
on the image for a larger version.
12 November, 2020: New coaxial
cable runs installed and other site work:
Such work at the Northern Utah WebSDR is
made possible by the kind donations of its many users - thanks!
Coaxial cable runs installed:
On
this day, three of us showed up on site, towing a Ditch Witch that was
used to open a trench between the tower with the beam antenna and the
building. Into this trench we put six runs of 1/2" jacketed
aluminum CATV hardline, representing a bit short of 900' of cable.
These
runs replace what we had been using up to this point which was a
constant maintenance issue: A run of "Siamese" (dual)
RG-6 cable that had been laid on the ground. Over the last couple
of years, we've had to replace this run a couple of times as weather,
the hooves of cattle and the occasional vehicle driving over it has
damaged it.
Even
though this cable is 75 ohm, this "mismatch" is pretty much irrelevant
in a receive-only application (most
receivers' input VSWR is pretty high at 50 ohms, so a mismatch isn't an
issue!), it is low loss (on
par with 1/2" "Heliax")
and it is quite rugged. Even though we don't have specific
applications for all six runs in mind, this will give us several spares
and room to grow in the future.
The
measured reduction
in losses upon switching to the lower-loss cable is
about 1 dB on 40 meters and about 3dB on 10 meters, but because there
is amplification at the base of the tower at the far end of the
feedline, this loss would affect only S-meter
calibration and not actual receiver noise performance.
6
and 2 meter receive performance improved:
Several
months ago, KiwiSDRs #4 and #5 were installed to allow reception on the
beam antenna - but this had a known-likely side-effect:
Degradation of 6 and 2 meter reception. As it happens, by
themselves,
the KiwiSDRs generate a bit of noise on VHF - including 6 and 2
meters. We hadintended
to resolve this issue during the past several visits, but we either
forgot to bring the material to do so or simply forgot to do it!
The
"fix" was to apply ferrites to the GPS, antenna and Ethernet lines
connected to the KiwiSDRs. At these frequencies, reasonable-size
snap-on ferrite devices actually can work as expected
- particularly if several turnsn of the conductors are passed through
the ferrite device to (exponentially!)
increase the inductance.
These
modifications have significantly reduced the amount of noise and the
number of spurious signals seen on the 6 and 2 meter bands: A bit
of low-level QRM is still present, but it's quite close to the noise
floor. Because many of the repeaters to which users might listen
are 80+ miles (128+ km)
distant, they are already quite weak meaning that receive system
improvements will be more likely to be noitced.
In
the future (probably the spring)
we plan to move the 6 and 2 meter receive antennas to the tower with
the beam, utilizing some of the new coax runs that were
installed. This will not only increase the height of these
antennas a bit, but it will move them away from interference sources -
namely, the computers in the building and the powerline.
28 October, 2020: Internet
outages related to upgrades:
You
may recall several months ago when one of the
connecting sites experienced more rodent-related interruptions:
It would seem that if they are hungry enough, they will knaw on about
anything.
The
vulnerable cables are now in conduit - hopefully now safe from any sort
of rodentia - a process that required the rerouting/replacing of a few
bits of cabling and several outages of that remote site.
7 October, 2020: Brief
Internet interruptions:
Over the past day or so, we have experienced several brief (two minutes or less)
interruptions of Internet connectivity. The cause of this outage
is unknown as it is occurring on the fiber backhaul that feeds our ISP,
apparently affecting surrounding communities as well. We are told
by that provider that they are "looking into it."
Just
above the waterfall there is the box marked "Allow keyboard" and if
checked, keyboard shortcuts will be displayed to do many of the WebSDR
functions.
To
this list has been added the ability to mute/unmute the audio using the
"m" key. One may either
hit the "m" key again, or
toggle the "mute" check box to un-mute.
An on-screen indicator that the
audio is muted - whether you use the check box or the "m" key - appears to the right of the
frequency entry and mode display indicator, just below the waterfall.
If
you mute the audio on your computer/browser, the "Audio muted"
indicator will NOT display as the WebSDR
cannot "know" that you have done so.
Remember:
The "m" key will mute audio only
if the "Allow keyboard" box is checked.
Two photos of the new guy wire anchors being
installed to replace the deteriorating underground anchors. Left: Setting up to drive the
pipe into the ground. Right: One anchor done
- one more to go! Click
on either image for a larger version.
On
this day a work crew arrived to replace the original guy anchors for
the 80' tower with the LP-1002 Log Periodic beam antenna. As
noted in the 9 September
entry, there was evidence that the guys had slackened somewhat and
investigation revealed that the Southeast guy had pulled out of the
ground a few inches. Knowing that the "twin" of this same tower
had fallen about a dozen years ago - probably due to a failed guy
anchor - we were intent on not allowing the same fate to
befall this tower!
Rather
than excavate a huge hole to fill with concrete and steel, this anchor
consists of a long, very thick-walled piece of pipe driven deep into
the ground at an angle - and this pipe is belayed by another pipe,
some distance behind it. To install these, a pile
driver is used to pound them into the ground - a process that takes
some time.
Both
the Southeast and Southwest anchors were replaced in this manner.
With this work complete, all three guy anchors have been replaced - the
North anchor having been done in June, 2018.
We
are looking into applying passive cathodic protection to the new
anchors to maximize their lifetime.
As
it happened, the RF feed from the beam went dead at about the same time
a welder was fired up. The cause was determined to be a loose RF
connector that hadn't been properly tightened (e.g. "finger tight and a bit more")
on a previous visit: My bad - sorry! No
doubt that it would have "flaked out" on its own, eventually!
Select photos of this work will follow
shortly.
It
is because of the kind donations by many users of the Northern Utah
WebSDR that we are able to do critical maintenance projects like this!
19 September, 2020: Site visit
The
Northern Utah WebSDR receive site was visited today to take care of
several issues:
Sticking transfer relay.
It appeared earlier that the "delayed-on" feature of the transfer
relay used to feed the output of the UPS to the critical gear wasn't
working - possibly due to a smaller relay driving the
contactor's coil having stuck closed. It was observed during the
visit that the relay was working properly, but just in case, an R/C
snubber network was wired across the contacts of the smaller
relay to suppress the high voltage arc that can occur when it opens on
the peak of an AC cycle and with the back EMF of the collapsing coil of
the contactor. Doing this necessitated taking the entire site
down as
this is
the path for the "critical power". This outage occurred
between approximately 1400-1445 MDT.
This
"transfer relay" is used to allow us to work on the UPS without
interrupting the power to the equipment. In short, if the UPS
power goes away, power is transferred to another source - typically
from an ordinary outlet, which would maintain power if the UPS's output
were to go away - but it could also be a second UPS.
Reconfiguration of the signal path for the
LP-1002 beam.
I
had never been happy with the way the gain balance had been set up when
WebSDR #4 was put online. Because this antenna has significantly
more gain than the omni, the signal dynamics are also different -
particularly with respect to very high-power shortwave broadcast
stations. Soon after installing WebSDR #4 it was immediately
apparent that I could not simply replicate what was done on the TCI-530
for WebSDRs 1-3.
One
of the problems was that there weren't enough RF amplifiers to go
around at the time that WebSDR #4 was put online. At the base of
the tower, there is an amplifier that is
capable of handling any signal that we are likely to get, making up for
the loss of the cable between there and the building. This signal
(eventually) is fed
to the band splitters in the receiver rack where the signal is split -
one path going to the "wideband" receivers (like the KiwiSDRs)
and the other going to the individual band filters. This second
path has an "above 9 MHz" split that goes from the "low split" to
another diplexer splitter (the "high split") that provides feeds for
the 30, 20, 17, 15, 12 and 10 meter bands.
Originally,
I thought that I could get away with putting an amplifier between the
low and high split - but I was wrong: At certain times of the
day, even this very robust amplifier would occasionally overload on the
myriad signals from 1.8-30 MHz - particularly in the evenings with very
strong 49, 41, 31 and 25 meter SWBC signals. When this amplifier
overloaded, all receivers downstream were degraded.
The
"fix" was to build more amplifiers, so I built another module that
contains three amplifiers that are capable of handling very strong
signals. The amplifier between the low
and high split modules was removed and individual amplifiers were
placed on the (filtered) band
outputs that feed each receiver. By strongly limiting the amount
of HF spectrum any individual amplifier might see, the probability of
overload is reduced - and if one amplifier does overload,
it won't
affect other bands.
KiwiSDRs
4 and 5 are also fed from this same signal path via the wideband split
mentioned above. To prevent these receives from overloading, a
"stronger" pre-emphasizing filter (similar
to a "high pass shelf") was implemented, reducing signals at
lower frequencies even more while leaving higher frequencies (e.g. above 20 MHz) pretty much
alone.
Following
the pre-emphasis filter mentioned above, an RF amplifier was placed
that allows, for the first time, KiwiSDRs 4 and 5 to hear the 10 meter
noise floor under "dead band" conditions. This was not possible
before because sufficient gain to allow this resulted in the KiwiSDRs
being overloaded by lower-frequency signals during the same high-signal
times that were
overloading WebSDR #4's signal path.
Because
of the change in configuration, the S meters for WebSDR #4 were
recalibrated to indicate the signal levels at the antenna terminals.
17 September, 2020:
"Disturbances in the force"
At
around 0830 UTC, WebSDR #2 went offline for reasons not entirely clear.
At a bit after 1400 UTC - morning - its WebSDR service was
restarted and everything looked normal.
At
around 1030 MDT several of the WebSDR servers unexpectedly went
offline. A quick check of the network indicated that the inbound
pipe to the WebSDR receive site was saturated by the WebSDR servers
downloading updates. Apparently a number of "extremely critical"
updates have been pushed out to fix one or more "Zero Day" exploits
across a variety of operating systems: We aren't sure of the
details at the moment, but it appears to be affecting all types of
services and platforms so one can expect it to make the news.
After
the updates completed, the WebSDR servers came back online without
intervention having apparently needed to disable their Ethernet
connections for a while in order to complete the updates. Unlike
some other operating systems, they did not need to reboot to do
critical updates.
16 September, 2020: Regional
power outage
At
about 0018 MDT, the power went off at the WebSDR receive site - and in
many of the surrounding northern Utah communities. The UPS
battery bank lasted about 2.5 hours under the 450VA load, finally going
offline at about 0238 MDT.
At
around 0610 MDT, the power returned. For reasons to be
determined, none of the automatic start-up scripts on the WebSDRs did
their job, requiring remote access to kick-start the WebSDR services
themselves. None of the KiwiSDRs on site started up on their own
so a trip to the site will be required to "kick" them manually.
During
this power outage, there was also a network outage which limited
Internet connectivity in the area for a time.
An
interesting side effect was that the labels on the WebSDRs were
"wrong": The labels are changed at 5 AM and 5 PM MT, but since
the power was off at 5 AM the script that runs precisely at that time
did not run when the power was restored. The scripts were
manually run on the four servers to "fix" things. Of course, they
would have eventually fixed themselves!
One of the deadman anchors on the tower with
the beam having pulled out of the ground a few inches as evidenced by
the appearance of metal that had - until recently - been underground. Click
on the image for a larger version.
9 September, 2020 - Wind
storm effects
Very
high winds:
During
the 8th of September a severe "wind event" occurred in Northern Utah
with certain areas recording gusts exceeding 110 MPH (175kph).
As you can imagine, this felled trees, removed roofs, and
caused significant power disruptions. (Addendum: Some areas
were without electricity for more than three days following the event.)
During
this event, connectivity
to the Northern Utah WebSDR was impacted when critical infrastructure
on the Internet Backhaul (which
feeds our ISP) went offline, reducing available bandwidth.
A repair/work-around was implemented within hours.
Failure of tower guy anchor:
At
the Northern Utah WebSDR site an inspection has revealed that one of
the guy anchors on the 80 foot tower holding the LP-1002 beam - the
"South-East" anchor - has failed as evidenced of it pulling out of the
ground a few inches. In referring to the 20 June, 2018 entry
of
this "Latest News" page you will see that a similar thing happened with
the north anchor, which has since been replaced. We have
contacted the same person who did the previous replacement and we will
have him replace the two original anchors - including the
not-yet-failed "South-West" anchor - as soon as possible.
30 August, 2020 -
Internet outages, but not at the WebSDR:
On
the morning of 30 August, 2020 a large-scale outage - largely confined
to customers of Century Link and its related company, Level 3 - where
many customers found that they had no Internet access. There
were
apparently knock-on effects around the world that gradually subsided as
the issues were resolved and/or incorrect routing information (something like that)
aged out - the details are not clear at the time of this writing.
The
WebSDR itself was not directly impacted as it doesn't use any of the
affected
network providers, but many users were unable to connect to it owing to
difficulties caused by this incident.
5 August, 2020 - Issues
with WebSDR #2:
There
were issues with WebSDR
#2 (Green)
where users were getting incomplete/intermittent audio and waterfalls.
We
think
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 painted:
The
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.
The
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:
The
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.
The
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
minutes.
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
broadcast band.
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.
Known issue:
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:
It
appears that there was a brief outage of a major data circuit that
feeds a significant 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.
It
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 -
preferably 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.
This
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.
It
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.
For
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.
It
would appear that the AC power (from the utility) went off at
approximately 0843 MT, the on-site UPS taking over at that
time.
At
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.
We
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
damage.
There
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"
site visit.
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.
Today
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 lightning
At
around 1800 MT the connectivity to the Northern Utah WebSDR's receive
site was lost when a lightning strike took down one of the wireless
hops
of our Internet Service provider.
Service
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
happening again.
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
MHz.
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 lose gain 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
module.
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.
While
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.
As
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.
The
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
replicated.
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:
Apparently
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.
For
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!
One
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.
We
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
conditions.
13 April, 2020:
40 meter RX overload on WebSDR #4
It
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.
A
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
coverage.
The
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
the beam
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.
If
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.
Overload
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 sdrinfo@sdrutah.org
4 April, 2020:
Site visit.
Reduction of power line
and computer noise.
Some
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.
Reduction
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.
Antenna work.
For
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.
There
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
antenna itself.
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!
It
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.
As
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.
The
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
rolling the
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
so.
PLEASE REMEMBER
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.
The
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
California transplants.
Reports
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.
As
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.
WebSDR Issues:
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
behaving itself.
Dirty
power on site:
A
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
An
"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
"sdrinfo@sdrutah.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.
Power
Line noise:
There is an intermittent power
line related noise that occasionally shows up - and we are working to
resolve this issue - but the system's noise blanker seems to be able to
remove most of it. This noise is typically the worst on 80/75
meters, but it seems to disappear at night as the band opens up and the
ionospheric noise submerges it. Several poles have been
identified
Audio/system
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
computer!)
getting busy, pre-empting the browser'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.
A
"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
lower (160,
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.
Occasional
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
of
the interim sites that provide the Internet connection that
occasionally result in outages.
Low-level
switching supply "birdies":
With lots of computers comes the possibility of lots of QRM
from
them! Fortunately, there are no "strong" birdies, but there
are
some that, if they happen to sweep across the frequency to which you
are listening, will cause some mild annoyance.
Miscellaneous
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.
The
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,
Mac, etc.)The
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.
It
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.
Waterfall not
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
the background)
it will stop - which makes sense if you can't see it. What
this
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.
Occasional
burst of noise across the band correlated with strong signals:
This is sometimes the result of the noise blanker that is
active
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
during
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
other
things that cause similar-looking artifacts, such as static crashes
from distant lighting storms or brief signals from ionospheric and
ocean wave profilers.
When
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
annoying -
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 independent
WebSDR servers.
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.
Additional information:
For general information about this WebSDR system -
including contact info - go to the about
page(link).
For technical information about this WebSDR system, go to
the technical
info
page(link).
For a list of questions and answers, visit the FAQ
page (link).
For more information about the WebSDR project in general -
including information about other WebSDR servers worldwide and
additional technical information - go to http://www.websdr.org
