The
Northern Utah WebSDR
Latest news and current issues
Recent events and resolved issues:
13 January, 2020: Miscellaneous items.
WebSDR configuration tweaks, including:
With the Internet traffic moving more reliably, the default audio buffering was set from 0.5 seconds back to 0.25 seconds.
Changes
make to links to update and reflect the new WebSDR and KiwiSDR
configurations - including updating of links on the "mobile" versions
of the WebSDR page.
A few tweaks to the network configuration resulted in two brief outages.
Possible issues with the 25M receiver: It seems that the 25M receiver (on WebSDR #3)
has noise issues causing it to be somewhat deaf. The reasons for
this are unknown as this frequency range is clear on the KiwiSDRs,
indicating that it is not due to local site interference.
Slightly low RF gain on the 80 meter receivers: The three 80 meter receivers (80CW, 80PH and 75PH)
are slightly "gain starved" at RF. These are the newly-installed
FiFiSDR receivers: There's an approximately 10dB "hit" on signal
level between these receivers and the antenna due to a 2-way splitter
"early" in the chain and a four-way splitter to feed the three
receivers. Without this loss an individual FiFiSDR would be
sensitive enough hear the low HF noise floor "barefoot".
This is evident during very RF quiet times (middle of the day) where one can see the noise floor on the receivers (particularly 75PH)
is higher at the extreme edges rather than the middle. This is
not a problem in the night/evenings when propagation improves and the
80 meter noise floor increases by 10-17 dB.
If
the receiver was RF noise-limited it would be the other way around:
Slightly lower noise floor at the upper/lower edges due to slight
roll-off of the audio chain at higher audio frequencies.
When
we are able to do so, an extra gain block will be inserted into the 80
meter receive chain. Note that these three FiFiSDRs will
eventually be moved to cover the 160 and 40 meter bands, anyway.
12 January, 2020:
Site visit, and the Northern Utah WebSDR back online.
A
work party convened on 11 January at around 0800 MST with a lot of things
to do, finishing at around 0220 on 12 January - not including 90 minute
(each way)
driving times for some of those involved. Almost everything
on the list was completed.
New receiver hardware installed
on WebSDR #1:
As
mentioned in the 21 December, 2019 entry, several of the USB sound
cards had failed leaving a deficit of one receiver on WebSDR #1 - so we
chose to sacrifice the 80CW
segment
- the absence of which was covered by the "90/80M" receiver on WebSDR
#3. Since the last visit we had ordered and received three
FiFi
SDR receivers - all-in-one SDR receiver and USB sound cards that can
cover from a few
hundred kHz to at least 30 MHz - and they cost about the same as a new
USB sound card. The KFS WebSDR has used these units
exclusively
for about 2 years with good results.
These new receivers were
installed in the 80CW,
80PH and 75PH
positions
for the time-being. Because these devices are new we
are
"breaking them in" and don't yet know how they will hold up - both
hardware and software-wise - so we did not put them on 40 meters, the
most popular band, but installed them on a band that requires three
receivers - 80/75 meters, temporarily replacing the older
configuration. If one or more of these receivers quits
working
there is a usable alternate on WebSDR #3.
If proven to be reliable, these
three units
will eventually be moved to 40CW,
40PH
and 160 and
the existing 40 meter receive gear will be re-deployed for an
upcoming project.
WebSDR rack rewired:
Originally, the Northern Utah
WebSDR had been just one server and
several receivers neatly organized in a single rack - but it has since
expanded to three severs with several rat's nests of wires, making
routine maintenance
rather difficult. While the Internet connection was being
sorted
out, the WebSDR rack was pretty much emptied, many receiver modules
re-mounted, cables organized (RF-carrying
cables separated from data and power) and carefully
labeled.
This task - which had been put
off
for months - took many hours to complete, but since the WebSDR system
was offline, anyway, we decided to do it. The result is a
much
less-disorganized (but
not quite "neat") installation with gear and cables that
are much easier to manage.
Weather station offline:
The weather station is temporarily offline - this will be
restored soon.
Grounding improved: While
not complete, the ground and bonding of various pieces (coax cables, racks, etc.) is much improved over what it had been and tidied somewhat. More
work on this is still to be done.
Default buffering changed back to
0.25 sec:
With the more stable Internet connection, the default
buffering
for WebSDR audio has been reduced from 0.5 seconds back to the previous default of 0.25 seconds.
2200/1750 meter and reception on
frequencies below 400 kHz improved:
After locating and dealing with
a persistent noise source, the noise level on the very low frequencies (below approximately 400 kHz)
has been much reduced - whether you use the "2200/1750M" receiver or
listen "down there" on the KiwiSDRs.
Due to minor equipment
damage and the lack of appropriate repair parts (and time!) there
are some signal
integrity issues on this RF path (a bit of intermod, lower
absolute signal levels) but it still works better than
many home installations: This is on the list of things to fix
during the next site visit.
2 meter and 6 meter reception
improved: Via reconfiguration of some of the
gear (which included rerouting cables and lowering the Ethernet speed of
the KiwiSDRs to 10 Mbps - still more than adequate)
a lot of the noise and spurious signals that had been present on 6 and
2 meters have gone or been significantly reduced. A bit more
improvement can be afforded with more time/work.
Internet restoration: We
were able to install new gear and restore our connection to
the Internet: We thank our previous ISP for their past hard
work
and service. There are a few minor issues to work out, but
these
will be addressed in the coming days/weeks, so there will be a few (hopefully brief!) outages.
If you end up WebSDR #1 (yellow) when trying to go to WebSDR #2 (green) or WebSDR #3 (blue):
If you are trying to go to WebSDR #2 (green) or WebSDR #3
(blue) but keep ending up on WebSDR #1, please use the URL on the landing
page and update your bookmarks and shortcuts! For convenience, the new URLs are listed below:
The
reason for this change is that all WebSDRs and KiwiSDRs now share a
common IP address, but use different ports. What this means
is
that if you used your old bookmark you will always
end up at WebSDR #1.
If you can get to
WebSDR #1 but
get a dead link when you try to go to WebSDR #2 or WebSDR #3 -
particularly on a mobile device or on a secure network:
First, make sure
that you have tried the new links on the landing page.
You
may have been using the WebSDR interfaces via port 80 - which can be
advantageous to those that use an Internet service that does NOT
allow non-standard ports for web traffic: Some ISPs do this,
but it is also common on mobile (phone)
Internet
connections and on "secure" networks such as those found at workplaces,
WiFi hot-spots, and other places where they have "locked down" their
Internet connection.
Previously, each WebSDR had its
own address and allowed forwarding of the most common port (80) to the native
WebSDR ports (8901)
- but it is currently possible to do this only
with WebSDR #1 as there is only one
address available. WebSDR #1 was chosen as it is by far the
most popular.
The URL for WebSDR #1 (yellow) using only port 80 is http://websdr1.sdrutah.org/index1a.html. Again, port 80 URLs for WebSDR #2 (green) and WebSDR #3 (blue) are not currently available.
At
the moment, the best way around this is to use a VPN proxy service on your computer to get
"outside" the restricted Internet connection. In the future
we
may be able to give each server its own address, again.
The KiwiSDRs, previously
accessible via port 80, can no longer be accessed via that port.
Mobile page access
changed: For
users of the lightweight "mobile" version of the Northern Utah WebSDR,
make sure your links have been updated as follows:
WebSDR1 Mobile
- (Use this alternate port 80 link
to WebSDR 1 if your mobile provider blocks the normal
WebSDR ports and the normal link does not work. No alternates
for #2 or #3 yet - sorry.)
As
of 1637 MT (2337 UTC) on Wednesday, January 8 the receive site of the
Northern Utah WebSDR lost connectivity to the Internet - again
due to issues that our ISP is having.
We are working on a means of
restoration - but expect this outage to last several days.
In the meantime, we have
"re-pointed" the URLs of the WebSDR servers so that most users will see
the landing page and the outage notice when they attempt to go to a
WebSDR server rather than a "dead" link.
Don't worry, we will
get it back online!
7 January, 2020:
Internet connectivity restored!
As of 0845 MT (1545
UTC) on Tuesday, January 7, our ISP was able to restore
connectivity to the receive site of the Northern Utah WebSDR.
We wish to thank them for their work in this restoration.
We
expect that there will be a few lingering issues to work out (e.g.
drop-outs, brief outages) but we are expecting things to improve over
time.
During the outage, we "re-pointed" the WebSDR links to
the
landing page so that users would see the notice rather than just a
broken link: We have pointed them back to there respective
WebSDRs, but it will take several hours (after the above time)
before this change fully propagates through the Internet.
3 January, 2020:
Internet issues.
At
approximately 1338 MT today the Internet connectivity to the Northern
Utah
WebSDR site was lost.
Due to the remoteness of the site, it may take some time
to analyze the
problem and come up with the best solution - which may include
replacement/upgrade of wireless Internet equipment - but we will
get it back online.
We currently have no ETA, but we are hopeful that it will
be restored during the week of 5 January.
26 December, 2019:
Default "Audio
buffering" setting changed.
The default (when
you load the web page)
setting for the "Audio Buffering" on WebSDRs 1, 2 and 3 has been
changed from 0.25 seconds to 0.5 seconds. This change was
made to
help deal with the "flakiness" in the Internet connection (discussed below)
where the "jitter" of that connection will occasionally increase due to
retransmissions on that link segment and cause audio drop-outs.
This setting will be reset to the earlier value of 0.25
seconds
once we "fix" that link. In the meantime, you may select more
or
less buffering when you connect, as desired.
21 December, 2019 - Site
visit:
The trip itself:
It took several days (because of holiday
preparations, schedules, etc.) before an "expedition"
could be carried out to the Northern Utah WebSDR receive site (it's 80 miles/130km each way!)
For a trip to the WebSDR site
we must count on killing the entire
day - and this trip was no exception: The duration of the
trip was about 13 hours, door-to-door,
including about 2-1/2 hours total drive time.
On-site,
it was noted that having four-wheel drive was very useful owing to the
snow/ice on site. The temperature got as high as 34F (1C) and as low as
24F (-4C) during
the time that I was there.
WebSDR #1 (yellow) back
online: Several
issues:
As expected, a failed USB sound
card (Asus Xonar U5)
- used for the "160M"
band - caused the server to hang on "POST" - that is, it didn't ever
get past the start-up (BIOS)
screen to even start loading the operating system. After this
USB device was unplugged, the system booted properly.
It was also discovered that another USB sound
card (Asus Xonar U7)-
this one for "80CW" - had also failed - but instead of hanging the
system, it simply would not negotiate to operate at "High Speed" on the
USB port which meant that the best it would do, if it proved to work at
all, was 48 kHz - able to
cover only 1/4 of the "80CW" range.
Although five
Asus USB sound cards (four
donated by another WebSDR, and one of my own) ere on-hand,
only ONE
of them would work. What that means is that since this WebSDR
was
first brought online in February, 2019, at least six of
these sound cards (Asus
Xonar U5 and U7) have failed, all in similar ways (e.g. failure of the USB port to
properly negotiate a connection).
Since we were one sound card
short of the full compliment (we
are "maxed out" on PCI bus slots, so we had to use
three USB sound cards) we had to sacrifice one band - and
we chose to leave out the "80CW" band for the time-being.
We
have on order several devices (Fifi
SDRs) to completely replace the USB sound
cards - these devices having been used with success at KFS:
It is hoped that this will eliminate this particular
point of unreliability. It is expected that it will take 2-4
weeks for these new devices will arrive (from Germany)
and be tested prior to installation. Unavailable until
recently,
these devices cost about as much as a brand new 192 kHz Asus USB sound
card.
For alternate "80CW" band
coverage (3500-3630 kHz) use
the "90M-80M" receiver on WebSDR #3 (blue) pending the
arrival, testing and installation of the new gear.
Electrical utility work:
It appears
that the upgrade by the electrical power utility is done - but we have
yet to hear "official" word.
Instead of the old,
chunky (and obsolete)
open-delta three-phase 4160 volt line, there is now a "modern"
single-phase 12kV line and a new pole transformer at the WebSDR site
end -
and likely a new transformer at the other end, too! It is
also
likely that our line voltage will stay much closer to the nominal 120
volts rather than the 80-140 volts that we'd occasionally seen before.
(It was 124
VAC when I checked it.)
From the radio site to the
power distribution point (a
compressor station about 2/3-mile, 1km away)
all of the insulators are brand new so we are hoping that it will not
be a source of noise any time soon. (It occasionally rains salty mud
in that part of Utah, so we'll see...)
UPS replaced:
A UPS - which had
failed catastrophically a few months ago - has now been
replaced with a higher-power (1400
VA) unit that uses 24 volts DC provided
by a pair of new-ish 100 amp-hour UPS-rated AGM batteries.
This
should reduce the number of outages -
even though the power has been quite reliable, excepting the recent
utility work where it wouldn't have mattered, anyway.
We calculate that the new
UPS/battery combination should be able to carry the current load for at
least 3 hours.
Image responses reduced:
One
thing that had been an annoyance was that in recent months, whenever an
"I/Q Calibration" procedure was done on the SoftRock ("High Performance")
receivers,
the result was always worse
than
before - so the "old" calibration values were kept, meaning
that
the image rejection was typically around 45dB - not "terribly
terrible",
but not very good, either. Today, the instructions were very
carefully re-read and nothing was
missed - that is, the calibration instructions, written by
the author of the WebSDR software himself, were being followed exactly..
At
this point it was suspect that an important detail had been omitted
from the original instructions - specifically, that one should remove any
existing calibration values before doing the procedure. This
was done experimentally on the
"160M" receiver on WebSDR #1 and the image rejection went from about 45
dB to well over 60 dB. Apparently, the values that obtained
from
the calibration routine are not based on "raw" data from the
signal processing chain, but they are values that have been "cooked",
taken after
existing calibration data been applied, and therefore are utterly
bogus unless one removes any existing calibration data and
restarts the WebSDR service.
The calibration on all
bands that use SoftRock receivers (all
eleven of them - it would have been twelve if the "80CW" receiver
weren't offline)was redone - a lengthy and tedious
process -
and the image rejection on all bands improved significantly.
For
reasons not yet known, the image rejection on the 12 meter receiver
didn't
improve as much as others (it's
around 50dB) but we'll look into that on a future trip.
LF antenna replaced:
Because the LF receive
performance (<350
kHz) was rather poor, the existing 0.75 meter diameter LF
loop antenna was replaced with a 1
meter diameter loop that was recently built and the result was much
stronger signals, but much poorer
signal-noise ratio and even worse performance than the previous loop.
The E-field whip that had been
installed about
a year ago which has more interference on some frequencies than the
whip (the interference
could be nulled out with the loop)
was placed back in service and despite the QRM, the whip works
better overall than the "new" loop.
The "new" loop remains on-site and the older 0.75
meter diameter loop was brought back for re-work.
Internet link tweaked:
There
have been recent issues with the "last hop" of the Internet connection
to the WebSDR side slowing down and, occasionally, dropping out,
probably related to the onset of winter. The working theory
is that
there are Fresnel effects on the "near" (WebSDR site)
side of the link that is causing on-link retransmissions - and path
calculations using terrain database data and path calculating software
bears
this out: Now that the ground is mostly covered with snow,
the
nature of the Fresnel effects have apparently been altered as compared
to those in the summer.
Because
such Fresnel effects - which occur due to multipath caused by ground
reflections from a "high" spot on the terrain somewhere in the path,
below the line-of-sight, the antenna was raised a few degrees in an
attempt to
move the reflected signal farther below the main lobe of the
antenna, reducing its signal will minimally affecting the "main"
signal.
The result seems to be an overall improvement: Even
though
the signal has probably dropped a bit, the reflection has probably
dropped a bit more - this being one of those instances where a stronger
signal does not
mean better performance! The average latency dropped by about
25%
indicating a slightly better link quality overall and instances of
extended ping times - which still occur - appear to be "less bad"
than as link drop-outs are less frequent than before.
An
upgrade to this problematic link is still in the works, but it will
likely be a few weeks before we get all of our "ducks in a row".
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 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.
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
