The
Northern Utah WebSDR
Latest news and current issues
Recent events and resolved issues:
19 February, 2020: Service interruptions, upgrades.
There were several interruptions on this day while several pieces of gear (mostly networking)
were reconfigured and/or upgraded between 1000 and 2000 MT. This change should reduce the
likelihood of audio drop-outs caused by packet loss/jitter/delay on the
Internet connection that feeds the Northern Utah WebSDR's receive site.
This work caused a number of outages totalling several hours - something that was unavoidable.
16 February, 2020: Comments.
Power issues: At
approximately 0715 UTC the connectivity to the Northern Utah WebSDR
remote site was lost due to a power failure. Service was restored around 1935 UTC.
Note:
There will be an outage during the week of 16-22 February, 2020
for an equipment upgrade - the precise time/date yet to be determined.
160M Intermod reduced:
A
custom-made 160 meter band-pass filter was constructed and
placed in the 160 meter signal path, prior to any active devices. As noted in the 10 February
entry, the FiFiSDR was being overloaded by signals near the top end of
the AM broadcast band, these spurious signals (mostly) disappearing at night
when they went to low power.
This
filter was placed in series with the "160 meter" tap of the
multicoupler, which is, itself a filter - but apparently not good
enough to take care of the strong signals. The "new" filter
offers 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 new filter resolved the "new"
intermod issue related to the KiwiSDRs: There are some low-level intermodulation signals
- notably one at 1940 kHz, which is a mix of 1160 kHz (KSL AM, 50 kW)
and twice the frequency of another station on 1550 kHz (e.g. (2 x 1550)
- 1160 = 1940).
We have ruled out the RF chain as being the
source of this intermodulation by bypassing several pieces of equipment that preceded the new filter (main splitter/BCB filter, any amplification, all of the lightning protection, etc.). The source of the signals could
be the TCI-530 antenna, its tower or, most likely, the miles of rusty
barbed-wire fencing surrounding the site rectifying and re-radiating
IMD.
In
the process of diagnosing the intermod problem, we had to interrupt the
RF signal paths several times which affected all bands to some degree.
New amplifier in the KiwiSDR chain:
As
noted in the 10 February entry, an RF line amplifier in the KiwiSDR
signal path had become unstable and a different amplifier was temporarily placed inline - but that amplifier wasn't well-suited for very low frequency (VLF, LF) use as it suffered from low-level ingress of switching supply noise (from the computer gear) via its power lead.
A
new amplifier was constructed specifically for this task was placed into
service.
This amplifier is based on the
venerable 2N5109 transistor - a medium-power RF device designed for low
intermoduation distortion that is usable from audio through UHF.
This
amplifier has been specially designed to be useful from high audio
frequencies to at least 50 MHz allowing to cover the VLF-HF range
received by the KiwiSDR receivers.
Special
attention was made to the design to decouple/filter the DC input of the
amplifier so that low-level signals - particularly those below 100 kHz
- could not find their way in via that route.
The
new amplifier has greatly reduced the QRM from the DC line input that
had appeared at VLF and LF frequencies during the temporary use of the
amplifier installed on 8 February, and it has much greater signal
handling capability than the previously-used MMIC-based RF line
amplifier.
10 February, 2020: Comments.
2200-1750M RX fixed.
A brief visit to the site and re-seating of the cable resolved
the "mirroring" issue of this receiver. As expected, an audio
cable had been partially dislodged, resulting in a loss of one of the
I/Q channels.
160M Intermod.
It would seem that the FiFiSDR is more susceptible to overload by
AM broadcast stations than the Softrock Ensemble II that had previously
been in use. The result is that one can hear several distorted
signals on the "160M" receiver (only)
- from "nearby" AM broadcast stations at the top of the band - can be
heard. In the evening, these stations reduce in power and the
nose rises, making most of these artifacts (mostly) undetectable.
While there is
a filter on the 160 meter port, it is apparently not sharp enough to
sufficiently attenuate the AM broadcast stations at the top end of the
band (above about 1400 kHz).
An
additional filter has been constructed - one that offers much greater
attenuation at the top of the AM broadcast band - that will be
installed and should (hopefully) resolve this issue.
KiwiSDR performance. As
noted in the 8 February entry, a different RF line amplifier was
required to avoid instability issues - but this "temporary" amplifier
has noise ingress issues that degrade its performance below 500 kHz.
A new amplifier has been constructed that will replace it, to be
installed during the same trip as addition of the new 160 meter band
pass filter.
8 February, 2020: Site visit.
VLF/LF line amplifier replaced:
On
the last trip it was discovered that a line amplifier in the "3-375
kHz" signal path had failed - likely due to a voltage impulse that had
come down the coax (the antenna used for this is active, voltage being sent via the feedline) when antenna work had been done, reminding me that I really should have
completed modification to prevent this very occurrence.
Since the previous trip, a new amplifier module was constructed -
with much stronger protection - and installed, restoring the signal
path.
The "new" amplifier has much higher P1dB and IP3 specs (much "stronger") making it far more resistant to overload than the amplifier that had been used in the meantime.
While
the intermodulation observed while the "temporary" amplifier was
reduced, it wasn't gone, indicating another problem, described below.
Comment: At
the time of writing, the 2200M receiver on WebSDR 3 is degraded:
Apparently, when moving things around an audio cable from the
receiver module got partially unplugged resulting in the loss of the
I/Q channel pair causing the appearance of "images" (duplicate signals)
mirrored above/below the center frequency. It is expected that
this will be corrected in a few days. This does not affect the
performance of the KiWiSDRs or the related WSPRNET operations.
Intermodulation issues resolved.
As
noted in the 31 January entry, there was an intermittent issue in which
severe intermodulation distortion was occurring on the "wideband"
branch of the RF distribution, most strongly affecting the KiwiSDRs.
The most obvious effect of this was seeing/hearing 10 kHz-spaced
carriers containing audio from multiple AM broadcast stations - and
occasionally a "shortwave" sound (RTTY, CW, digital).
The
suspected culprit was a failed 570 kHz AM broadcast band notch - but
I'd not recalled at the time of the previous post that there was no 570 kHz notch - a fact verified on site when the filter assembly was connected to a network analyzer.
While
I had the HF Splitter/BCB splitter/filter/amp unit apart, I revisited
the notch tuning, moving one notch from a weaker, more distant station
to a fairly strong more local station, reducing the total amount of
energy from the AM broadcast band.
After
the "3-375 kHz" amplifier had been replaced, there was still some
intermodulation distortion - but it seemed to occur only when the main
HF input was connected. After a bit of sleuthing, it was
discovered that RF amplifier being used to boost the signals to the
KiwiSDRs after the "limited attenuation high-pass filter" (the filter that reduces signal between 500 kHz and 12 MHz to prevent overload of very strong SWBC signals)
was going in to what appeared to be "regenerative oscillation" - that
is, it was on the verge of oscillating, but in the process it was
amplifying certain frequency ranges by an enormous amount. What's
interesting is that this same amplifier has been in use for several
months, but it didn't have any issues until after the 11 January trip.
This
amplifier - using a MMIC - was replaced with a much "stronger", but
similar gain, discrete, high-dynamic range bipolar RF amplifier.
FiFiSDR receivers shuffled around:
As noted in the 11 January entry, we received three FiFiSDRs (and modified them appropriately for better performance)
and these were "temporarily" placed in the three 80 meter band
positions - 80CW, 80PH and 75PH, all replacing a single unit: If
one of these FiFiSDRs had failed, alternate coverage would have been
available on WebSDR #3 (blue).
These
receivers were reprogrammed and moved to 160, 40CW and 40PH and the
previous 3-band module used for 80/75 meters was placed in service.
This frees up the receiver module that had been used on 160
meters (but is tunable from 160-10 meters) and the dedicated 40 meter receive module for an upcoming project at the Northern Utah WebSDR.
One of the remaining issues is that identical USB devices on Linux (and other operating systems) can't be reliably differentiated from each other. What this means is that if the configuration of any USB device is changed (added/removed) their identity can change. In the case of the FiFiSDRs, they can (seemingly)
randomly rearrange themselves causing such mischief of the 160 meter
ending up on 40 meters and vice-versa - and when this happens, they do
not work well at all! An attempt was made to add a script using
Linux "UDEV" rules that would tie a device name to a specific USB port,
but this effort was abandoned in deference to the late hour - a project
to be tackled later.
An
"IQ" calibration was done on the 160, 80CW, 80PH, 75PH, 40CW and 40PH
receivers to minimize image response - a laborious, but worthwhile
process that should be done any time receiver hardware is moved around.
The
issue with slightly low gain on 80 meters after the installation of the
FiFiSDRs was averted: Appropriate gain now precedes the 160 and
40 meter receivers to prevent this issue. This issue was averted
on 80 and 75 meters with resumption of the use of the original receiver
module.
Weather station back online:
The
weather station at the Northern Utah WebSDR site is back online.
At the moment, the "widget" used to display the conditions on the
web page(s) is via "Weather Underground", but it would seem that they
are in the process of switching away from a "crowd sourced" model for
their data. What this likely means is that we'll be switching to
another method of displaying the weather data on the Northern Utah
WebSDR web pages.
Grounding system improved:
The
RF and lightning grounding system was significantly bolstered,
something that had been on the list from the very beginning of the
WebSDR. This includes re-doing connections and providing
additional bonding of ground cables.
Additional lightning/impulse protection was added to all incoming coaxial cables
A
bit more work remains to be done on overall grounding/lightning
protection, but that is probably true for almost any antenna
installation.
"Low HF Split" module modified:
In the signal path for the higher performance "narrowband" receivers (those shown in "bold" on the WebSDRs)
there is a take-off point for all band above and including 30 meters.
It was noted on a previous visit - and verified via simulation -
that a minor modification would theoretically reduce ripple and loss on
some of the higher bands. It is likely that the difference will
not be apparent except to someone wielding the appropriate test
equipment.
Comment: There
remains an issue that causes occasional network slowdowns and audio
drop-outs. The cause is known and will be addressed with an
upgrade that is expected to occur in the near future.
2 February, 2020: Slowdowns, network issues.
We have been experiencing network issues today (2 Feb) and yesterday (1 Feb): We are working to solve the problem. Thank you for your patience.
Update: The device with the problem was rebooted and the issue seems to be resolved.
31 January, 2020: Intermittent intermod on lower frequencies.
There
appears to be an intermittent issue in which significant
intermodulation distortion will appear on the lower frequencies causing
the appearance of carriers every 10 kHz or so along with a mish-mash of
audio from multiple AM broadcast stations.
Remote
analysis indicates that the notch used to attenuate a strong local AM
broadcast station on 570 kHz on the "wideband" RF branch has become intermittent: When this
happens the amplitude of that station increases by about 50dB,
completely saturating the RF line amplifier that follows this filtering.
Because
of the finite reverse isolation of this amplifier, the distortion is
reflected back into the antenna system and due to its lower
frequency and the relatively transparency of the AM broadcast band
filter at 630 meters, that receiver is particularly badly affected.
The 160 meter receiver, which is also on the "narrowband" branch, is
also affected, but less than 630 meters.
All other receivers that are on "wideband" signal path (all
of the KiwiSDRs, 60M, 25M SW, 19 M SW, the "back-up" 90-80M" and
"41-40M" receivers on WebSDR #3 and, of course, the AM-160-120M
receiver) are strongly affected when this is ocurring.
This issue will be addressed during the next site visit.
13 January, 2020: Miscellaneous items.
WebSDR configuration tweaks, including:
With the Internet traffic moving more reliably, the default audio buffering was set from 0.5 seconds back to 0.25 seconds.
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.)
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
