The
Northern Utah WebSDR
Latest news and current issues
Recent events and resolved issues:
18 May, 2022: Comments.
VFO issues fixed - I hope:
A
user of the WebSDR commented on the fact that, sometimes, the "B=A" or
"A=B" function of the VFO switching didn't always work as expected.
This had been known for a while, but attempts to replicate this
didn't reveal the problem until this person outlined the specific steps
needed to cause the problem. Once this was done, it issue was
properly divined and the problem fixed on all of the Northern Utah WebSDR servers and also on KFS and the Maui WebSDR - Thanks!
Additional modifications on WebSDR #3:
As
noted before, WebSDR #3 is often the "guinea pig" used to test software
changes as it gets relatively little usage - and it is in the same
environment as the other WebSDRs, allowing more thorough testing than
is possible with the "Test WebSDR" in the home lab. A few changes
made since the last update:
Local oscillator leakage suppression in Synchronous AM:
Because the quadrature cancellation isn't perfect, there was a
slight amount of leakage of in the form of an audio tone when
Synchronous AM was used. Now, a high-Q notch filter is
automatically tuned to the frequency of that leakage and the tone is
removed.
Vari-Notch added:
This is a notch filter in which the frequency may be manually
adjusted with a slider. The "Q" of this notch filter is fairly
low (about 2) as too-narrow a notch would make it rather difficult to
tune - and the discrete frequency steps of the slider might make
suitable notch depth impossible to obtain.
Important: This is an audio only notch filter, so it will NOT prevent AGC desense in the presence of a strong signal - only the "Notch 1" filter can address that.
CW Peak filter modified: The CW Peak filter now has an option labeled "Ref. Tone" (e.g. "Reference Tone")
which activates a tone generator at the precise frequency of the
peaking filter. This should aid the user with precisely setting
the peaking filter to the frequency of the station to which they are
listening.
"When will we see these changes/updates on the other Utah WebSDRs?"
We
are still in the process of adding/testing/debugging the new features
on WebSDR #3, but once that is done, we'll roll over some or all of the
"new" features to them. We may roll them over all at once, or
just one at a time - which is something still to be decided.
Power line noise:
As
noted in the 7 May entry, the power line noise level is higher than
normal, likely due to "dusty rain" that coats insulators and hardware
with a very slightly conductive film. We will "walk the power line" as
soon as the opportunity present itself during a future site visit.
7 May, 2022: Site visit:
On this day a site visit was made to do some infrastructure work that has been months in the planning: Little (if anything) was done to the WebSDRs themselves, although the work did affect them.
Improved grounding:
Additional grounding:
Three more ground rods were sunk around the perimeter of the
building and tied to the building itself - which is completely metal.
This activity was complicated by the fact that holes had to be
drilled into the superstructure - one of them having to be tapped as
well - to attach them.
New entry panel installed:
Previously,
the coaxial and data cables entered the building via existing holes
with grounding done immediately inside the building (to the superstructure - which is one solid, welded construction and now tied to at least six ground rods) but it now enters through a "proper" metal box that is both tied to the building and (to be sure!) to the nearest ground rod.
This installation required that every cable going through the entry panel (which is all antennas and the data/power for the Internet connection)
be re-routed. Doing this meant that there were several
interruptions of the RF feeds and Internet connectivity. The RF
feed from the east-pointing beam (WebSDR #4), in particular, was disconnected for several hours during this work.
The
"old" entry hole was closed up and sealed as it had been an ingress
point for insects and air, the holes and wall space filled with
expanding foam.
There
is still plenty of work to be done in that while the cables actually
route through this entry box, we still need to re-terminate each of the
lines and install the grounding/lightning protection blocks in/to the
box itself: This will take several hours to complete and will
undoubtedly cause several more interruptions when this is done - likely
during the next major trip.
QSY of 10 meter (Part 15) beacon:
Previous on (approximately)
28.570 MHz, the on-site telemetry beacon was moved to about 28.925 MHz
to get it farther away from 10 meter SSB activity when the band is
open.
It
was observed that this QSY caused an "inverse-keyed" version of the
beacon to appear on 50.200 MHz on the 6 meter receiver. This
frequency is not harmonically related and we don't know yet if it is a
spurious product of the new oscillator, or a spurious response by the 6
meter receiver - but we'll look at it during the next trip.
Other work completed- not in any particular order:
Several
more "T" stakes were installed/re-sunk to keep the cattle that
occasionally in habit the area away from certain locations (e.g. where coax goes underground, critical areas near the building, etc.) - but we need to do more of this.
A
higher-stability oscillator was installed in a piece of on-site test
equipment to reduce temperature-related drift during remote
testing/troubleshooting.
We still have a very long (and growing) list
of things to be done during future visits, ranging from "must do!" to
"nice-to-do", so there's little possibility that we'll run out of tasks
when we are on site!
Other comments:
UPS upgrade: We
will soon be upgrading the capacity of the UPS (power back-up) by
replacing the existing batteries, hopefully allowing a "run" time of
3-4 hours at minimum.
Power line noise:
As noted in previous entries, because the site is quite near the
Great Salt Lake and salt marshes, the area often experiences "mud rain"
which occurs when slightly conductive, wind-blown dust falls during
rain, coating power line hardware. Understandably, this can raise
the local noise floor considerably at times - and this has happened
several times during the past month. Usually, this condition
persists for a few hours to a few days when "clean rain" falls and
washes away some of the noise leakage paths - but not always. For
this noise source, there is little that we can do except hope that Mother Nature will assist in QRN reduction!
Based
on observation, there does appear to be greater tendency for this
"temporary" noise to persist for longer than it had in the past.
It could be at least partly related to the fact that not too
distant from the site, the retreat of the Great Salt Lake is leaving
large, exposed areas of salt pan that allow the wind-borne dust to
propagate, but it could also be due to degradation of power line
hardware (insulators, clamps, insulator sleeves) that make it more susceptible to the "dirty rain".
There is
a long-term noise source that is consistent, often varying in
intensity, that is centered around 2.25-2.5 MHz and it and its
harmonics (around 60 meters, sometimes the top of 40, part of 30 and 20 meters)
appears that we have yet to locate.
On
our list of things to
do - but it will require the "walking" of several miles of power lines
through very tall grass and near salt marshes on a hot day, braving
mosquitoes, a particularly aggressive species of deer fly and,
possibly, ticks! And why do we do all of this - because it's fun, of course!
3 May, 2022: More "bands" added to the Salt Lake Metro WebSDR:
The "Salt Lake Metro" WebSDR ( found here ) -
which is located along the east benches in the Salt Lake Valley for the
reception of both repeater and simplex operation in the most populous
portion of Utah - has been recently updated to include three new "bands", all using the same discone antenna as the other 2 meter and 70 cm bands:
SLC ATC:
This receiver covers a 2 MHz portion of the "aircraft" band from
approximately 121.1-123.1 MHz - a section that includes a significant
portion of the air traffic control traffic in and around Salt Lake City.
6 Meters:
This receiver, centered on 50.5 MHz, covers the bottom 1 MHz of
the six meter amateur band - mainly for weak signal reception for local
nets, beacons, and the occasional band openings.
Space->Earth:
This receiver, centered at 145.900 MHz, includes the 200 kHz
"Space" segment of the 2 meter amateur band, allowing the reception of
amateur satellites on that band.
Currently, this receiver is
using the same Discone antenna, but it is hoped that it will be soon
switched to a quadrafilar helix that is better-optimized for high angle
reception. This receiver has a single band-pass cavity preceding
it to provide attenuation to other 2 meter signals allowing higher gain
settings on the RTL-SDR than the other receivers and help reduce the
probability of overload - which can
still happen if there is a strong signal on the input frequency of one
or more of the 146 MHz repeaters.
The bandwidth on this receiver
is 256 kHz and is selected to reduce - as much as possible - the
potential for overload/interference from nearby band segments. If
there is interest, it is possible to upgrade this receiver to an SDRPlay RSP1a- but this receiver is significantly more expensive (about $140 versus $35)
and we'd want to make certain that the effort and usefulness if we were
to do that would be appropriately justified in terms of usage.
Consider
all of the receivers on he Salt Lake Metro WebSDR to be experimental:
We are occasionally revising things to try to improve performance
and usability, so there may be occasional outages while we do so.
Finally, although the hardware isn't available at this moment,
there is one more "slot" to add another "band" to this server and we are looking for suggestions.
If you are interested in additional coverage (e.g. more Air Traffic Control frequencies, other band segment, etc.) feel
free to make a suggestion using the contact information via the link
near the bottom of the "About this WebSDR and contact info" page, the
link for which may be found along the right side of the page.If you domake a suggestion, keep the following limitations in mind:
If more coverage than 768 kHz is desired, it must
be done using an RTL-SDR, which has just an 8 bit A/D converter which
has significant limitations in the presence of strong signals within
the receiver's passband .
If <= 768 kHz is needed, this is possible using an SDRPlay RSP1a. As noted above, this receiver is far more expensive (about $140 versus $35 for an RTL-SDR)
and the needs for its much higher performance would have to justify the
cost of the hardware. At present, it is not possible to cover
more than 768 kHz of spectrum while simultaneously having more than 8
bits of A/D resolution that would be needed to simultaneously receive
both weak and strong signals. (Note: This is not possible using "OpenWebRX", either!)
Coverage
of 10 meters is currently not possible due to the presence of a 10
meter WSPR transmitter on site, which would certainly overload any
receiver.
1 May, 2022: Power failure:
At
approximately 2315 MDT on 31 April the commercial power at the WebSDR
receive site failed. The on-site UPS did its job, but with
the 500-600 watt load the battery bank kept the site up until
approximately 0008 MDT this morning - just under one hour. It
is possible that this outage was due to emergency work being done at a nearby utility site.
Reports from residents in the county report a massive disruption
to the grid due to some sort of failure/fault where voltage and phase
measurements went all over the map, causing a fair bit of damage to
mains-powered devices as voltages went very high and low.
The mains voltage at the WebSDR site at one point measured over 137 volts - not good.
Similarly, a large, commercial customer nearby reported 242 volts
on a leg of a 208 volt three-phase circuit with a phase error of 28
degrees. Percentage-wise, this correlates well with our 137 volt
reading.
The commercial power returned at approximately 0105 MDT, at which WebSDRs 2 (Green) and 3 (Blue) appear to have come back up gracefully - but WebSDR 1 (Yellow) and 4 (Magenta)
did not: The reason for their inability to start up reliably from
a cold boot has been investigated in the past, but this has been
thwarted by the fact that when they are tested for this, they will typically start up properly - so go figure!
It's worth noting that because WebSDR #3 (Blue)
was online, its "backup" 80 and 40 meter receivers were usable - in
fact, there were a few dozen users that had "discovered" this fact.
While they are of somewhat lower performance than the comparable
receivers on WebSDR #1 (Yellow), they do very well considering the hardware in use.
The
outage of the WebSDRs was noticed, but it wasn't until about 0850 MDT
this morning that attention could be given to bringing them back online.
It was expected that the UPS battery should have endured for longer (at least two hours) and the batteries tested well the last time this was done (November, 2021) but it appears that this is now an "action item" for the next site visit.
27 April, 2022: Additional modification - CW Peak filter
A
"CW Peak Filter" has been added, configured via a drop-down just above
the DSP Noise Reduction selection. In this window is a selection
of frequency, in Hz, from 350-1000 Hz in 50 Hz steps. Because the
"default" center frequency for the WebSDR's CW filter is 750 Hz, this
value appears twice - at the top, and farther down in the list.
This
filter consists of a single biquad section with a Q of 20 and a gain of
30 which should be a reasonable compromise between narrowness and
minimal ringing and should be suitable for at least 30 WPM.
Comments on its use are appreciated!
26 April, 2022: Modifications now "Live" on WebSDR #3:
Following up on the 23 April, 2022 entry, several new features have been added to WebSDR #3:
Improved tuning resolution.
The
built-in resolution of the WebSDR is typically 31.25 Hz, which is "good
enough" for most instances, but this challenged me to increase it - and
I have done so: The tuning resolution is now exactly 1 Hz.
The display now shows 1 Hz resolution, but this will likely
exceed the frequency stability of the receivers at the server site over
the temperature range!
This was done not
by changing the WebSDR server's code, but rather by doing a linear
frequency shift, the precise amount - which is between 0 and 31.25 Hz,
the exact amount being calculated while tuning is being done.
This shift is done on the users' computer rather that the server
and if one tunes up and down using the added "+" and "-" buttons (e.g. -/, -//, \\+, \+)
you can hear, if listening carefully, a slight delay in the pitch
adjustment of a CW note as you tune up and down due to the Internet
delay.
Revised DSP noise reduction, "Notch2" and "High Boost" functions:
A
significant rework in the DSP code has been done, moving it from a
point in which it operates at the user's computer's sample rate (typically 44.1 or 48 kHz)
but, instead, at the audio rate of the stream from the WebSDR server -
which will be either 8 or 16 kHz. This has several effects:
Much lower CPU load as the filtering is operating on fewer samples per second.
With
the lower sample rate, the filtering bandwidth is a much larger
percentage of the available Nyquist bandwidth and the filter's effects
can be "stronger" with fewer audio artifacts.
The
settings of the DSP noise reduction have been revised so the effects
are now audibly different. A "new" setting called "Extreme" has
been added.
Because
of the changes, the DSP filtering - including the FM de-emphasis and
filtering - now are in effect on the audio recordings.
The addition of (limited) Synchronous AM demodulation:
Two new buttons, "SAM-U" and "SAM-L",
have been added that invoke Upper and Lower sideband synchronous AM,
respectively. This can significantly improve the audio quality of
received AM signals by eliminating distortion caused by the amplitude
and phase of the carrier being upset by selective fading.
Because
the only audio available from the WebSDR that has intact both phase and
frequency information are USB and LSB, it is these modes that are used
internally to synchronously demodulate the AM signal. This puts
certain limitations on the operation of the demodulation:
The
AM signal must be tuned such that the beat note of the carrier of the
AM signal being received is within the audio bandwidth, and it may be
between about 50 and 1050 Hz. The "SAM-L" and "SAM-U" buttons
automatically offset-tune the signal to which you are tuned by 150 Hz
internally, so the offset tuning is automatic if the signal is tuned to zero beat prior to switching to a SAM mode. Internally, the audible CW note is used to lock onto the carrier and synchronously demodulate the signal.
Because
the audio is shifted within the passband, best frequency response will
be obtained if the carrier is nearer zero Hz within the passband - but
it's not recommended that it be tuned to be lower than about 60 Hz to
keep it above the 50 Hz minimum. While the demodulator will track
the carrier up to 1050 Hz, the audio passband will be shifted up (at audio) and you will lose the top 1 kHz of audio frequency response.
For
SWBC listening, the Synchronous AM works well - but there is a possible
problem if listening to an AM net where people are using "Vintage"
rigs: It's often the case that the carrier will be 1 kHz or more
offset from the intended frequency. This frequency shift can
cause two possible problems:
It may result in the carrier being above the 1050 Hz frequency limit. This can happen if you are using "SAM-L" (lower sideband)
and the carrier is greater than 1 kHz lower than the tuned frequency.
Similarly, if "SAM-U" is used, this can happen if the carrier is
more than 1 kHz above the tuned frequency. In this case, you may
have to retune the receiver.
If you are using "SAM-L" and the transmitted carrier is above
the tuned frequency, it will be entirely outside the passband - and a
similar case would be if you are using "SAM-U" and the transmitted
carrier is below the tuned frequency. In either case, it may be possible to change between "SAM-L" and "SAM-U" as appropriate.
When
using Synchronous AM, status information will appear just below the
frequency display on the WebSDR. This shows three pieces of
information:
Lock/Unlock:
This provides an at-a-glance look to determine if the synchronous
AM detector is locked into the carrier of the AM signal being received.
Expect the display to occasionally show "Unlocked" during fading,
if there is QRM, or if you retune the receiver. Some GUI
operations (e.g. zoom in/out, etc.) can also affect the recovered audio and cause brief unlock.
Tuned freq:
This shows the apparent frequency of the AM carrier. This
is done by using the actual, tuned frequency of the WebSDR and the
frequency of the NCO (discussed below)to
calculate the frequency of the carrier of the signal being tuned.
Because the WebSDR's receiver may not have its local oscillator
reference perfectly adjusted, this may be a few Hz off.
NCO: This is the frequency of the "Numerically Controlled Oscillator" - a synthesized local oscillator used to do the synchronous AM demodulation. It is this frequency that must
be between 50 and 1050 Hz - and it is preferred that this frequency,
when locked, be below 200 Hz to preserve maximum audio frequency
response and fidelity. Note that the frequency of the NCO is
subject to the limitations of the 31.25 Hz tuning steps of the WebSDR
server which is why, if you tune a known-accurate signal (a time station) the offset indicated by the NCO frequency will probably not be exactly the ideal 150 Hz.
A few "quirks" and features:
Aside from the limitations above, note that if you click on one of the frequency markers or one of your memories (the tags below the waterfall) it will switch out of SAM mode to whatever mode you selected. At this time, you cannot "save" a Synchronous AM mode setting.
When
one of the SAM buttons is pressed, the bandwidth is automatically set
to maximum which means that if you tune to the carrier's actual
frequency and activate it, the frequency will shift by 150 Hz.
Because the highest audio frequency is about 3.8 kHz, this means
that about 3.65 kHz will actually be available. In the presence
of QRM - after first selecting the sideband that has the least amount of interference -
you may want to move the sideband farthest away from the carrier closer
to it: For SAM-L, you would move the lower filter edge up in
frequency and for SAM-U, you would move the upper filter edge down in frequency.
The
generation of the 90 degree audio phase shift used for synchronous AM
demodulation isn't perfect, the "unwanted" sideband being attenuated by
about 45 dB. Normally, the artifacts of the original carrier are
inaudible, but it may be heard in some instances during quiet periods
of audio with high volume settings.
There
are a small number of Shortwave Broadcast Stations that appear to have
an "improper" phase relation between the carrier and the sidebands, the
result being that the audio recovery of these stations will be quite a
bit lower than in standard AM. This is being investigated.
Please note:These features are currently being tested and debugged: If
they are going to be incorporated into the other WebSDRs, it will be
only after a week or two of additional testing at the earliest.
23 April, 2022: Software being tested on WebSDR #3:
After
several weeks of testing on a "Test" WebSDR at home, code that
constitutes a major re-work in terms of audio handling has been placed
on WebSDR #3. Whereas the previous code using DSP modified the
sound file directly, that file was returned (nearly) to its original
form and only simple "hooks" were installed, moving the rest of the
code to an external file.
In this testing, it's possible (likely!)
that WebSDR #3 will occasionally be unusable as code is tweaked, is
being updated, etc. - all events that could cause the page to not load
properly in some way. Typically, these issues will be only
transient.
As
of this now, the only "new" feature from the updated code that is in
use is the DSP noise reduction and notch filtering: Additional
features will be added in the near future.
2 April, 2022: WebSDR GUI tweaked.
On this day the WebSDR's GUI was adjusted to (hopefully) make the page layout cleaner and more predictable - namely:
The "Bandwidth" and "Logbook" panes have been docked to the "Frequency" pane to form a single, larger control panel on the left.
The "S-Meter" pane will, on a typical size screen (1024 to 1080 pixels across) be to the right of the combined pane.
The "Waterfall View" pane will typically be to the left of that.
As
before, things might rearrange themselves slightly if the screen is
markedly smaller than 1024 pixels across, but this should render OK on
the vast majority of devices. While it would be nice to have a
page that rendered properly on all
devices, not even the most ardent web authors can manage that - instead
to resorting to completely different versions for mobile devices with
small screens that either lack or hide many of the features/content,
making the user open up tabs/dropdowns to see what they are missing.
At
about the time of the above change, it was pointed out that there was a
problem with rendering on Chrome in which the lower portions of the
page were chaotically arranged. This was traced down to a
single-letter typo from a change made about a week ago to fix an error
that was being thrown by a browser due to the deprecation of some
feature: Firefox didn't seem to care - but Chrome certainly did,
but neither of them showed any errors in the debug dialog!
1 April, 2022: User/band scales optimized for amateur band coverage.(No foolin!)
Below
the control boxes, near the bottom of the page are frequency scales
that also include the username and their approximate tuned frequency.
Previously, these had to cover the width of the receiver for that
band, but this tended to crowd everyone into just a small section of
frequency band - particularly on 40 meters, the width of which
constitutes less than half of the receiver bandwidth.
As
of today, "custom" scales have been implemented WebSDRs #1, #2 and #4
for the bands where it makes sense to do so. These new scales are
optimized to cover the just the amateur band (plus just a bit extra) so that users aren't crammed into a small section, horizontally.
As noted, not all of the bands have custom scales - namely 160 and 30 meters, nor the wideband "low-performance" bands (e.g. 60 meters on WebSDR #1, none of the bands on WebSDR #3) and 10 meters, where pretty much all of the receivers' coverages are within the amateur band, anyway.
30 March, 2022: Version 3 of the KFS WebSDR now online - New address! - kfsdr.com
On this day "Version 3" of the KFS WebSDR in Half Moon Bay was made public, offering more bands than before:
Coverage on 60, 17, 15 and 10 meters is now available.
Coverage on 160 meters was dropped (at least for now)
owing to current issues with the antenna system there: The WebSDR
software has a limit of just eight "bands", which is why 12 meters is
not currently available.
Using
the same receivers and drivers as here at the Northern Utah WebSDR,
coverage of up to 768 kHz bandwidth is now possible, permitting the
coverage of 80, 60, 40, 20 and 15 meters in a single band.
20 March, 2022: Modifications now on all Northern Utah WebSDRs:
On
this day, the modifications mentioned in the 18 March, 2022 entry were
moved into place on Northern Utah WebSDRs 1, 2 and 4 - and the
"Salt Lake Metro WebSDR - completing a major update/reworking of the
code base. Modifications/changes include:
"Alt AGC": This
is designed to overcome the deficiencies of the WebSDR's built-in AGC
during AM reception: The original AGC tends to badly
over/undershoot, causing loud clicks and pops when signal strength is
changing rapidly - mostly due to QSB, or when someone keys/unkeys.
The "Alt AGC" attempts to overcome these deficiencies as much as
possible given the limitation of the existing WebSDR server. The
nature of this AGC is that the audio recovery will likely be a bit
lower (e.g. quieter) than
with the normal "RF AGC". The "Alt AGC" works with SSB to a
degree, but it is not optimized for such. This may be invoked in
the command line as one does with frequency and mode by adding
"?altagc=1" to the URL. This is disabled when FM is selected as
its use does not make sense there.
S-meter squelch.
This is a squelch that is based solely on signal strength and as
such it probably isn't a good candidate for typical HF operation where
signal levels and noise varies wildly as it is intended for FM
reception on VHF/UHF bands (including 10 meters). The "Set" button will preset the threshold about 6 dB above the current S-meter reading.
This may be invoked in the command line as one does with
frequency and mode by adding "?smsquelch=X" to the URL, where "X" is
the signal level, in dBM (as displayed on the S-meter) of the squelch
threshold. This control is not
currently visible on WebSDR #1 as none of the bands that it covers
typically have FM operation, but it may still be invoked via the URL.
Mode display on "alt" VFO: The VFO that is NOT being used now includes the mode, displayed next to the the frequency.
"Apparent peak SNR" display: In all modes, below the S-meter is this number which is the apparent signal-noise ratio of the received audio.
This is based on the peak and minimum audio over the past two
seconds and simply displays the ratio between the two in dB.
Because of the way it works, it has some limitations:
On a very noisy signal, it may read higher than actual. This is due to the fact that brief "pops" (static) are detected, and this is why on just plain noise, it may read higher than 0 dB.
It has no audio frequency weighting or filtering. If the audio has a tone (heterodyne) or background hum, the SNR will be low - but this is to be expected.
If
the audio is muted due to squelch operation or from Internet buffering,
the peak SNR may read very high as it's comparing "dead silence" with
what was there.
The
SNR reading is slightly weighted to give more realistic values under
real-world conditions. In FM, this value is reduced by roughly
0.5dB while for other modes is about 1.8 dB.
Deviation metering (in FM only): When FM is selected, audio deviation parameters are also displayed, such as:
Deviation (pk): This shows the peak deviation, updated about 10 times/sec
Avg.: This shows a weighted average of the deviation over a period of about 2 seconds.
Avg-pk:
This shows the "averaged" peak level. The small number
indicates how many samples were used to get this average and a value of
20 indicates 2 seconds.
Min: This is the minimum recorded deviation over the past two seconds.
Max:
This is the maximum recorded deviation over the past two seconds.
It is this "Min" and "Max" data that is used to calculated the
"Apparent peak SNR".
Frequency shown after username in "user view": In the frequency scales below the waterfall display, near the bottom of the page, the approximate frequency is displayed in square brackets after the username - which could also be an IP address or device type.
It
should now possible to provide alternate frequency scales - which can
be useful for bands that are smaller than the frequency coverage.
For example, on WebSDRs 1 and 4, the entire 40 meter band is less
than half of the coverage which means that the information is crammed
into a rather narrow, horizontal space.
There
is a "quirk" to this display in that the calculation of the displayed
frequencies of other users is based on assuming that they
are running the same mode as you. This is necessary as the mode
of each, individual user is not easily accessible for the code being
run on a users' computer where this information is calculated so the (reasonable) assumption is that everyone is running the same mode (e.g. LSB on 40, 80 and USB on 20 and above). Because of this, the display could be off by about 2.5 kHz is you are set to USB and the "other" person is set to LSB.
18 March, 2022: Modified code rolled into place on WebSDR 3:
As
sometimes happens when you have a number of servers that do "similar"
things, the code base diverges and each one has its "own" thing.
This had happened at the Northern Utah WebSDR as each server
needed its own modifications to its code and configuration, but with
five servers, this became unmanageable. What has been done is to
move the items/code that are unique to a particular server into
separate files that are included into the main files. This now
makes it possible to make a modification on one server, test it, and
then simply copy that file to the others with little/no modification .
This
work has enabled a few features to be added to the Utah SDRs that have
been undergoing testing and have been scattered about. Included
in these changes are:
"Alt AGC". Described in an earlier entry (see 12 March, 2022)
this is an alternate to the WebSDR's own AGC which has serious flaws
when used with AM - particularly on signals that are experiencing rapid
QSB (flutter). This
algorithm isn't perfect and may be tweaked over time, but it seems to
be superior to the built-in AGC for AM, at least.
This AGC is based on the S-meter and, to a lesser extent, the audio level.
When
the frequency is tuned, the AGC levels are reset from scratch to allow
it to quickly adapt to very different signal strengths.
If the signal level changes very abruptly (e.g. when an AM station keys/unkeys) the AGC levels may also be reset to more-quickly adapt.
It is not really intended for SSB use and while it works, you may want to stick with the normal "RF AGC".
As the "Alt AGC" operates, you will see the grayed-out slider below the button move around in response to the signal level.
This mode is DISABLED when FM is selected.
You
may activate the alternate AGC via the URL: Add "?altagc=1" to
the URL in the address bar in the manner that you would for specifying
frequency and mode.
S-meter squelch.
While the WebSDR has a "squelch" button, this is noise-operated
and tends to be very slow and is unpleasant to use if you are
monitoring FM repeaters. The S-meter squelch operates MUCH more quickly and it does what it says:
If the signal is above the threshold set by the slider bar, you
hear it - and if isn't, you don't.
There
is a "Set" button that simply sets the threshold about 6 dB above the
CURRENT S-meter reading. This should be used ONLY when there is
NO signal present.
Because
it is based on signal level, it's not really suitable for HF use where
signal levels can vary all over the map - but you are welcome to try it
if you like!
When the S-meter squelch is muting a signal, the words "S-Meter Squelch" appear in red just to the right of the MODE display.
Do NOT expect this to work well at all with SSB or CW signals or very weak signals in general.
Mode display on "alt" VFO: The VFO that is NOT being used now includes the mode, displayed next to the the frequency.
"Apparent peak SNR" display: In all modes, below the S-meter is this number which is the apparent signal-noise ratio of the received audio.
This is based on the peak and minimum audio over the past two
seconds and simply displays the ratio between the two in dB.
Because of the way it works, it has some limitations:
On a very noisy signal, it may read higher than actual. This is due to the fact that brief "pops" (static) are detected, and this is why on just plain noise, it may read higher than 0 dB.
It has no audio frequency weighting or filtering. If the audio has a tone (heterodyne) or background hum, the SNR will be low - but this is to be expected.
If
the audio is muted due to squelch operation or from Internet buffering,
the peak SNR may read very high as it's comparing "dead silence" with
what was there.
The
SNR reading is slightly weighted to give more realistic values under
real-world conditions. In FM, this value is reduced by roughly
0.5dB while for other modes is about 1.8 dB.
Deviation metering (in FM only): When FM is selected, audio deviation parameters are also displayed, such as:
Deviation (pk): This shows the peak deviation, updated about 10 times/sec
Avg.: This shows a weighted average of the deviation over a period of about 2 seconds.
Avg-pk:
This shows the "averaged" peak level. The small number
indicates how many samples were used to get this average and a value of
20 indicates 2 seconds.
Min: This is the minimum recorded deviation over the past two seconds.
Max:
This is the maximum recorded deviation over the past two seconds.
It is this "Min" and "Max" data that is used to calculated the
"Apparent peak SNR".
Frequency shown after username in "user view": In the frequency scales below the waterfall display, near the bottom of the page, the approximate frequency is displayed in square brackets after the username - which could also be an IP address or device type.
It
should now possible to provide alternate frequency scales - which can
be useful for bands that are smaller than the frequency coverage.
For example, on WebSDRs 1 and 4, the entire 40 meter band is less
than half of the coverage which means that the information is crammed
into a rather narrow, horizontal space. This feature is currently
undergoing testing on an offline test server.
These
changes will be tested on WebSDR #3 for several days and if all goes
well, they will be rolled out to the other four Northern Utah WebSDRs.
12 March, 2022: More tweaks on AGC - "Audio AGC" is now called "Alt AGC":
More
tweaking was done to the AGC algorithm and it now keys mostly from the
S-meter reading - but it does act on detected clipping in the audio to
minimize distortion on signals that are rapidly changing in signal
strength (e.g. fast QSB/flutter).
Even
in its current, early state it appears to function better than the "RF
AGC" that is default on the WebSDR in that it seems to be less
susceptible to overshoot and distortion under QSB conditions.
This AGC is not
particularly well-suited for SSB signals owing to the fact that the
S-meter reading on which the gain adjustment is based is delayed via
the Internet and the fact that it is updated just 10 times per second.
What this means is that rapid changes in signal strength - which
is what SSB is all
about - cause overshoot on leading edges of signals - that is, for the
instant a signal first appears and/or after a long pause by the speaker
at the other end. Because AM has a continuous carrier, this is
not so much of an issue, except at the instant the transmitter is first
turned on.
This
will undergo more tweaking and observation and if it seems to work well
under a wide variety of conditions, it may be rolled out to the other
Northern Utah WebSDRs.
The URL-based switch has been renamed, and it is now "?altagc=1" that is specified in the URL to invoke the WebSDR with this AGC mode selected.
9 March, 2022: Experimental audio AGC being tested on WebSDR #3 to improve quality of AM reception:
An
audio-derived AGC is currently being tested on WebSDR #3 and as the
name implies, it adjusts the signal gain based on the audio level being
received. This code is a step along the way in an attempt to address a flaw in the current
WebSDR server's AGC when listening to AM: The tendency of the the audio to
wildly undershoot on AM signals with rapid QSB, causing bursts of
noise (loud clicks) and brief audio drop-outs while it tries to track a signal with rapid QSB (e.g. fluttering signal strength).
If you know anything about audio-derived AGCs, you'll also know that they actually DON'T work on AM signals for one simple reason: If the AM signal is unmodulated, there's nothing for the AGC to key on and the gain will be driven way up. This incarnation works on many amateur AM signals only
because very few of them will be super strong and background noise will
always be present, allowing this test code to work at least somewhat.
Remember: This feature is experimentaland is being done to test other aspects of the code. It's hoped that this "alternate" AGC system - which probably won't be called "Audio AGC" - will primarily key from the S-meter reading, using the audio itself only secondarily in the process.
There are two ways to enable this experimental AGC:
Use the "Audio AGC" button. This button may be found in the window with the S-meter under just under the "Gain Control" label: Simply click "Audio AGC".
Use "?audioagc=1" in the URL-specified tuning parameters. This is done in the same way as specifying the frequency and mode.
Modification of "Manual" gain control:
On a related note, the "Manual" gain control has been present for quite some time, but it has been entirely manual: If you set it too low (to the left), the audio will be quiet but if you set it too high (to the right) audio can be badly distorted. A bit of code has been added to automatically reduce the gain if the signal level is way
too high (e.g. distortion and clipping results) for the current setting and you'll see the "Gain" slider move
down by itself if you try to set it so high that it distorts badly.
6 March, 2022: 10 meter receivers retuned
On this day, changes were made to the 10 Meter Low
receivers on WebSDRs 2 and 4: Their center frequencies were moved
up by 100 kHz to accommodate more of the SSB passband when 10 meters is
open without having to use the 10 Meter Hi receiver.
Changes were also made to the 10 Meter Hi receivers on WebSDRs 2 and 4, moving their centers up by 50 kHz to reduce the image response on the higher end of the band (near 29.7 MHz) to FM operation from images found at the bottom of 10 meters (e.g. FT8, strong CW.)
These
changes were brought about by improving conditions on the higher bands
as sunspot cycle 25 continues to gain strength. Expect additional changes as necessary to deal with the ever-stronger signals as conditions improve over time.
28 February, 2022: The fourth anniversary of the Northern Utah WebSDR's officially going online!
It was on this day in 2018 that the Northern Utah WebSDR went online from the remote northern Utah site.
The WebSDR was first put online publicly on 17 January, 2018 from a (noisy!) location near Salt Lake City during which the hardware was gradually being built and tested.
The only server at that time was #1 (of course!) which included coverage of the AM broadcast band (plus all of 160 meters), about
half of 160 meters using a higher-performance receiver, the upper 2/3 of
the 80/75 meter bands, 60 meters, and the upper half of 40 meters.
20 meters was added at the last minute (because we could) but the receiver hardware performed poorly - but it was (slightly!) better than nothing!
It was a few weeks later (on 18 March) that WebSDR #2 was added, improving coverage on 20 meters and adding 30 and 17 meter coverage as well.
At
this time, enhancements were made on WebSDR #1 including the improvement
of the 160 meter receiver, the addition of the bottom third of 80
meters and the bottom half of 40 meters.
A
day later, 2 meter coverage was added to WebSDR #2, and a few days after
this, coverage of the "beacon" portion of 10 meters was added.
Additional comments:
Label change. The "Atten"
label just below the S-meter was changed to "RF AGC" to better-reflect
what it's intended to convey. This information is present only on
those bands using receiver modules with hardware AGC under software
control (e.g. 75/80 and 40 meters on WebSDR #1, 20, 15 and 10 low on WebSDR #2 and 40, 20, 15 and 10 low on WebSDR #4.)
"10 Meter Low" band limits to shift on WebSDRs #2 and 4:
At the next opportunity, the 10 Meter Low
center frequency will shift up 100 kHz to better-suit SSB activity when
10 meters is open. This will likely be done at a late hour (local time) when the number of users on WebSDRs 2 and 4 are low as this will require a restart of the WebSDR.
At the same time the 10 Meter Hi
receiver will be reconfigured on WebSDRs #2 and #4 as well: We
will either shift its center frequency up by 50-100 kHz or (less likely, but still possible)
change the overall bandwidth from 1.536 up to 2.048 MHz. With the
10 meter band's conditions improving, the limitations of the hardware
for the 10 Meter Hi
receiver are becoming apparent in the appearance of images from strong
signals near the bottom of the 10 meter band, and either one of the
aforementioned changes should mitigate this issue.
"Utah SDR Telemetry" frequency change:
During the next site visit the frequency of the CW telemetry will
be changed to something closer to - but below - 29 MHz, yet to be
determined. This will be done as the SSB activity can spill up
the band around the current frequency (approximately 28.57 MHz) and be QRMed by the telemetry signal.
25 February, 2022: Comments.
WebSDR #3 hiccups:
A
few days ago a new version of the "wsprdeamon" script - which is used
to receive and process WSPR signals across multiple bands - was
installed as a beta test. This new version has the capability of
receiving some of the "new" WSPR-type modes, namely the "FST4W" modes,
and it is is a major step toward making it even more hardware and mode
agnostic over time.
Since
it is "beta", it still has some issues, namely it would randomly spawn
processes - and it did this with great fecundity, eventually consuming
all RAM and CPU cycles in the process, bringing WebSDR #3 to its knees.
A reboot (to clear the wreckage) and reverting back to the previous version has restored sanity - for now.
Frequency entry now allows frequency in MegaHertz to be entered.
A
tweak to the code was mode so that you may now enter the receive
frequency in MHz by typing it in the "Frequency" box. That is, if
you wanted to tune to 3579.55 kHz, you could enter either "3579.55" or "3.57955".
If you enter the frequency in MHz, the system will immediately convert it to kHz
and tune there. If you attempt to enter a frequency not covered
by any receiver on the WebSDR us are currently using, it's likely that
nothing will happen at all.
This
is possible only because there isn't currently a Northern Utah
WebSDR server that covers more than a 1000:1 range:
WebSDR #3 used to fall into this category, covering both 2200 and
2 meters, but it no longer does, so it's possible to determine if
MHz was intended simply by the magnitude of the number entered.
21 February, 2022: Minor changes.
In the past few days, a few minor configuration changes have been made:
Noise blanker threshold adjust for 60 meters.
It
was observed that around 60 meters, the power line noise was
particularly bad: A known issue with a noisy power line exists
around 2.5-2.6 MHz and it is the second harmonic of this that can
affect 60 meters. (We will be
looking for this noise source this spring and hopefully, with the
cooperation of the power utility, tame it down a bit.)
The
WebSDRs have an impulse-type noise blanker very similar to that found
in HF transceivers in that it will detect a strong, narrowband impulse
- such as that from power line arcing - and blank it. Because
this blanker must operate on the widest-bandwidth portion of the receive data, which is common to all users on that band, this is not
a parameter that can be made adjustable by individual users.
Furthermore, any change of this value requires that the WebSDR be
restarted.
Frequency shift for "10 meters lo" on both WebSDR #2 and #4.
As
noted in the 26 January entry, the original "center" frequency of this
receiver landed right on the frequency for the "International Beacon
Project" of 28.2 MHz - but since the receive hardware has the
characteristic of putting a "hole" of a hundred Hz or so right at this
frequency, this dramatically impacted the ability of these receivers to
hear the beacons.
Both WebSDR #2 and #4 were restarted and the new center frequency was set to 28.198 MHz, preventing this problem.
Sensitivity issue with the 12 meter receiver on WebSDR #4.
The
receive hardware being used on 12 meters on this receiver is a FiFiSDR
- a stand-alone USB-based "softrock" type receiver.
Unfortunately, this hardware has a quirk that when it is started
up - and, apparently, over a period of time, it may "glitch" its
start-up and cause the receiver gain to be set to the wrong value, the
result being a rather high noise level (high no-signal "S-meter" , a "bright" waterfall, and possible "deaf" receiver). The only "fix" to this is to restart the WebSDR (sometimes it takes several attempts) which causes the hardware to be reinitialized.
This
issue had been noticed on #4's 12 meter receiver, and when the 10 meter
frequency change was implemented, this was addressed, too. While
this problem occurs during start-up, it rarely happens once the system
is up and running (I don't remember having seen it do it before!), but it's easy to fix.
26 January, 2022: Quick site visit.
During the previous week, two of the KiwiSDRs (#'s 4-5)
went offline on 21 January and on this day, there was time to
investigate. The problem turned out to be a flaky connection
inside the power supply running these two units: A Molex-type of
nylon connector on the mains side had become intermittent, so a bit of
cleaning, strategic tightening of a springy connector and a very light
application of dielectric grease on the pins restored operation to
normal.
It
was also observed at some point since the November, 2021 receiver
upgrade that the "10 Meter Lo" receivers on WebSDRs 2 and 4 is centered
on 28.200 - the same 10 meter frequency on which the IBP (International Beacon Projects)
propagation beacons operate on that band. Because there is a very
narrow "hole" right at the center of the frequency range of many
SDR-type receivers, it's possible that these signals - when they appear
- may fall in this hole and be significantly weakened/inaudible.
Because of this the configuration of #2 and #4 have been changed
to move this "hole" down by two kHz to 28.198 kHz. As of this
writing, WebSDRs 2 and 4 have not yet been restarted to make these changes take effect, but this will automatically happen when they are.
In the coming months (when they become available!) the router and switch on site will be replaced. While the current gear usually
works, there appears to be a firmware or hardware issue in which they
can no longer be monitored or configured, requiring them to be
power-cycled - and there is the possibility that it could even stop
passing traffic. The replacement candidate hardware is not known
to have such an issue. When these units are eventually replaced,
there will be a complete outage of WebSDRs 1-4 and the on-site
KiwiSDRs, but it is our policy to announce scheduled outages several days in advance. (If only we could be aware of unscheduled outages ahead of time!)
6 January, 2022: 70cm added to Salt Lake Metro WebSDR:
On this day coverage was added to the "Salt Lake Metro" WebSDR (see the 23 December 2021 entry, below, for more information about this server)
adding the top 4 MHz of the 70cm amateur band. Because Utah uses
a negative split on 70cm, this coverage encompasses the entirety of the
70cm repeater output sub-band.
In progress is another receiver designed to receive the Earth<>Space portion of 2 meters (145.8-146.0 MHz). Because of its narrower bandwidth and additional filtering, it should have much greater sensitivity (within its intended passband)
than the other receivers on the system on order to have reasonable
performance - and this is only possibly by restricting its frequency
coverage.
The system is still being tweaked, but it appears to be working as it should.
29 December, 2021: WebSDR #2 - Frequency/Temperature compensation enabled on the 30, 17 and 12 meter receivers..
A few weeks ago (See the November 6 and 10th entries and the December 10th entries, below)
we did some major reconfiguration of the receivers at the Northern Utah
WebSDR. In the process of doing this, several of the receivers
that had been committed to the bands that had been upgraded were no
longer being used, so they were redistributed to improve
performance/bandwidth of other bands - specifically, the 30, 17 and 12
meter bands on WebSDR #2.
These
"new" receivers now in use on 30, 17 and 12 meters use Si570 frequency
synthesizers which are rather temperature sensitive. In the past,
a means was devised where the temperature in the building was measured
and a look-up table was used to adjust the frequency to compensate for
thermally-related drift: This system was described in detail in
the 9 December, 2020 entry (on this page).
For whatever reason (I'll blame life getting in the way)
the temperature compensation for the new receiver configuration was
never set up - until today, when I had time, my memory having been
jogged by an email from a user wondering why the 17 meter receiver was
about 90 Hz off: I observed a few 10's of Hz errors on the 12 and
30 meter receivers as well.
The
building of the frequency-versus-temperature information takes time as
it requires manual correlation of the reported temperature with the
needed frequency correction, so building this table will take months as
the internal temperature changes with the seasons - the range being
from as low as 10F (-12C) to as high as 125F (52C), so making a full-range table takes some effort.
This
temperature-based frequency correction has been shown to hold to within
10 Hz or so - little enough that it is not likely to be noticed by most
users. These corrections occur at the top of every minute that is
evenly divisible by four, so they should not interfere with time and
frequency sensitive digital modes like WSPR, FT-8 and others.
28 December, 2021: 19 Meter receiver on WebSDR #3 back online... for now...
It so-happened that one of the hams that has been involved with the WebSDR happened to be passing by (going to the historic site)
and kindly swapped in a different USB extension cable for the 19 meter
receiver. Because we'd already swapped out the receiver itself, we
had more or less ruled out it as a problem (a coincidental failure of both would seem unlikely)
so this time we tried the cable - which also exercised the connectors
at both ends. The receiver appeared to come up properly upon
doing this.
Let's hope that the third time is the charm and it continues to work!
Sharp-eyed
readers may have noticed that I originally mis-wrote in the 25 December entry
about the failure of the 31 meter receiver - which was not correct!
25 December, 2021: 31 19 Meter receiver on WebSDR #3 offline - again!
The
recent "problem child" that is the 31 19 meter receiver on WebSDR #3 is
offline, again. A few weeks ago, the receive hardware itself was
swapped out and everything seemed fine - until sometime in the past day
or so when it abruptly went offline. If you go to the 31 19 meter
receiver now, you'll see no signals at all because that band "slot" has
been reconfigured to point to a sound card with nothing connected as a
"place holder".
Often, one can force a reconnection if it's a software issue (e.g. restart the WebSDR service)
but that didn't work - and neither did a reboot, after which the
receiver itself didn't even show up in the logs as being connected.
It
seems unlikely that the receiver itself has failed, so it is more
likely a flaky connection on the USB cable - or a problem with the
cable itself. In either case, it will be down until a site visit
can occur, which will likely not be for at least a day or two.
23 December, 2021: Some changes:
New server added.
On this day a fifth
WebSDR associated with the Northern Utah WebSDR was made public - a
WebSDR that covers the Salt Lake City, Utah metro area on 2 meters. This server may be found HERE.
This
"local" server has been in the consideration/planning stages for quite
some time, supplementing the 2 meter coverage offered by WebSDR #3 (blue)
from its rural location near Brigham City, Utah. While this rural
receiver can be used to listen to mountaintop repeaters across much of
Northern Utah, its coverage of routine simplex operation is limited by
its location, far from the main population centers.
This "new" server is located in the foothills of the mountains on the east side of the Salt Lake valley, about 10 miles (16 km)
from downtown Salt Lake and as such, it has a better view of
mountaintop repeaters in the Salt Lake and surrounding valleys and it
can also hear simplex signals and transmissions on the inputs of local
repeaters from anywhere in the valley.
Because of geography, it is somewhat shielded from ground-based stations (e.g. simplex, users on repeater inputs) that might occur to the north of Salt Lake (e.g. Davis, Weber, Box Elder), west (Tooele County) and the south (Utah County).
This
WebSDR uses a pair of RTL-SDR dongles to cover the entire 4 MHz of the
2 meter band using a discone antenna at about 30 feet (9 meters) above ground.
The AGC on these receivers is disabled and the gain manually set to just
be able to accommodate the signal power that is likely to impinge on
the receivers when many of the local repeaters are simultaneously
transmitting. Because of this configuration, it is possible to
calibrate the S-meter on this WebSDR - (and all receivers at the Northern Utah WebSDR) to indicate the absolute
signal power at the antenna terminals of the signals being received,
allowing monitoring of apparent repeater ERP and to make determinations
of the efficacy and probable distances to these and other transmitters.
URL-specified parameters added:
As you may know, you can specify the frequency and mode in the URL as follows:
http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb - This will tune to 7272 kHz using LSB. The frequency must be in kHz and can include a decimal (e.g. "?tune=7181.5lsb")
We have added several more URL-specified directives:
Enable squelch. If you wish to load the page with the squelch enabled:
Add "?squelch=1" to load the page with squelch enabled, as in: http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb?zoom=1
Disable DX labels: If you would rather NOT have the labels under the frequency display on the waterfall:
Add "nolabels=1" as in: http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb?nolabels=1
Zoom in on the tuned frequency. If you wish to have the waterfall zoomed in when you load the page, you may specify a number from 0 (full width of the receiver) to 5-8, the maximum number depending on the band. If you specify 9, will be assured to zoom in fully (e.g. the same as the "max in" button.) For example:
Add "zoom=x" where "x" may be 0-9, as in: http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb?zoom=9
One or more of the above can be combined as shown.
10 December, 2021: Site visit.
19 Meter receiver replaced: The RTL-SDR used on WebSDR #3 (blue)
for the 19 meter SWBC band was replaced, having randomly gone offline a
few times in the days prior, finally becoming unresponsive.
31-30 meter moved to WebSDR #3: The "31-30 Meter" receiver, which covers the 31 meter SWBC and 30 meter amateur bands, was moved from WebSDR #2 (green) to WebSDR #3.
30 meter "High Performance" receiver now on WebSDR #2. Due
to recent upgrades, extra hardware was available, allowing a "High
Performance" receiver to be configured for 30 meters on WebSDR #2 (green).
This "new" receiver uses a 16 bit sound card and a "softrock"
receiver, providing much superior performance on the 30 meter band as
compared to the older "31-30 meter" receiver hardware. This
receiver spans about 192 kHz from just below 10 MHz to a bit above the
top of the 30 meter amateur band. As noted above, the "old"
receiver was moved to WebSDR #3, which seems to be the home for several
SWBC receivers.
15 November, 2021: 25 Meter SWBC receiver on WebSDR #3 offline.
On
this day it was observed that both the 25 and 19 meter receivers on
WebSDR #3 were offline. An attempt to restart the WebSDR server
itself failed to restore the operation of either receiver, so the
computer itself was rebooted. Upon reboot, the 25 meter receiver
- an RTL-SDR dongle - was not being enumerated, indicating that it has
either failed, or there is a problem in the USB connection to this
receiver.
As
a "place holder", the server's built-in sound card was configured as a
stand-in for the missing receiver: There is no actual
receiver hardware there, but this allowed the WebSDR to be brought back
up with minimal reconfiguration until the cause of this failure can be
investigated and remedied.
Update: This problem was resolved on 16 November when it responded to queries, so it was reconfigured.
12 November, 2021: Minor modifications to the WebSDR operation
Attenuation feedback:
One
of the features of the new drivers for the SDRPlay receivers is the
ability to monitor the incoming signals - and if the level gets above a
certain threshold, the input gain is reduced - in effect, it's a slow
AGC (Automatic Gain Control).
This allows the receivers to tolerate very strong signals without
overloading while minimally impacting the overall sensitivity.
As
you would expect, changing the attenuation will also affect the S-meter
calibration, so we have come up with a means of conveying the current
attenuation setting of the receiver so-equipped to the web page running
on the user's computer. This data - which is (currently) updated every 2.5 seconds, corrects the S-meter.
For
purposes of debugging and general interest, this attenuation value is
displayed immediately to the right of the numerical S-meter readings.
Note that not all receivers have this capability, and this
information is not displayed for those receivers that lack it.
For the present time, this attenuation value is not
being used to adjust the waterfall, so you may see shifts in its
brightness coincident with the change of attenuation. Note also
that because the attenuation value is updated periodically, the
correction applied to the S-meter (and the Signal Strength plots) may slightly lag the actual attenuation value.
From
a technical standpoint, having this visual feedback will help us "dial
in" the AGC settings to ultimately yield the best-possible performance.
The initial impression is that the AGC is overly-sensitive in its
tendency to increase attenuation and a bit too quick in its decreasing
it again when the strong-signal condition has subsided.
As the time of writing, this "feature" is present only on WebSDR #4. After additional testing and possible debugging, it will be rolled out to WebSDRs 1 and 2.At this time, WebSDR #3 does not have any SDRPlay receivers.
This
feature is now present on WebSDR's 1 and 2 for those bands using
supported receivers - but not on WebSDR #3 as that has no receivers with that capability.
10 November, 2021: A few comments.
Server reboots:
In the late morning (local time) we
had to reboot WebSDRs 1, 2 and 4. It seems that when we upgraded
the operating system the "snapd" software - which is intended to help
automate software package management - started behaving capriciously.
We had hoped
that with the new OS version that we wouldn't have the same
compatibility problems that had occurred after upgrading WebSDR #3 some
months ago, but this wasn't the case: It adversely affected parts
of the operating system, maxing out CPU utilization and the Internet
connection at times and, for some reason, crippling the LAN connection (making it go to 100 Mbps half-duplex!)
while doing whatever it decided that it had to do. Since it isn't
at all relevant to our needs on a WebSDR server, it was removed from
the systems manually, requiring a reboot.
Note to self: When we update the OS in the future on a WebSDR, make sure that we kill "snapd" immediately!
Slight signal deficit on the 12 meter receiver on WebSDR #4:
There would
appear to be not-quite-enough system gain on the 12 meter port on the
WebSDR #4 signal path which means that when 12 meters is closed, its
sensitivity is very slightly less (perhaps 3-6 dB)
than required to hear the "band noise" comfortably above the A/D
quantization level. On the next site visit we'll add a bit of
gain to assure that it's capable of "hearing" any signal that might be
present. If this is the biggest mess-up that we made during the
most recent site visit, we are doing really well!
6 November, 2021:
Upgrade of WebSDR #1: "In for a penny, in for a pound."
Because
we could, we threw some RSP1a's at WebSDR #1, combining the former
three "band" coverage of 80 and 75 meters and also the two 40 meter
segments into two single segments that each cover their respective
bands.
General comment on the upgrades:
As
noted below, these upgrades rely on custom Linux drivers/programs that
are still in their "beta" testing phase, but we've been testing them
for weeks on a non-public WebSDR server. Additionally, we'll be
tweaking the AGC settings of these drivers - something that can only be
done in-situ with wide dynamics of real-world band conditions.
Comments on the RSP1a and drivers:
"Who else uses the RSP1a's on their WebSDRs?"
although many other WebSDRs in the world use RSP1a's, but they use the "RTL-SDR" interface. The advantage of the RTL-SDR 8-bit interface is that it's capable of reasonably high bandwidth - a least 2.048 Msps,
but is limited to just 8 bits which limits the dynamic range of the
receiver and degrades the noise performance. Typically, use is
made of the AGC to scale the input signal to the available dynamics of
the 8 bit pipeline which extends its usefulness and the resulting
performance of RSP1a's run in this manner can be better than the
RTL-SDR (and is more convenient to use), but it doesn't make the best use of its capabilities.
The
"other" interface available with the WebSDR software is ALSA, primarily
intended for use with sound cards. "Out of the box", Linux
doesn't know how to deal with sample rates exceeding 192 kHz but we are
fortunate that, a few years ago, the ALSA core was modified to allow up
to 768 kHz of bandwidth: Unfortunately, most related programs
won't work beyond 192 kHz.
Through
a coordinated effort, we were able to determine another means of
getting raw "I/Q" signal data from the receivers and into the WebSDR
program, modify some of the drivers -
specifically, the loopback and "aplay", and we now have
specially-patched versions of each that have removed this limitation
and can pass data at the 768 kHz rate, which is the limit of the
existing kernel. Fortunately, the WebSDR software itself is capable of
handling 384 and 768 kHz natively - so all we need to do is get data
from the RSP1a into the ALSA system.
A
special driver was written to use the SDRPlay API that does just this,
piping the raw I/Q audio into "aplay" which then can be piped into ALSA
using the (specially-patched)
version of the loopback driver. The result is that we are able to
throw up to 768 kHz from the SDRPlay into the WebSDR server.
While
the SDRPlay API has an AGC function built into it, extensive testing
has revealed that it is not really appropriate for a system where there
are multiple users spread across a wide bandwidth. While it might
be fine to have the built-in AGC adjust signal levels for a single
user, it would be distracting to have the entire waterfall change
apparent brightness. It was also determined that the usability of
the AGC parameters was both limited and cryptic, so we started from the
ground up, implementing an AGC system in our own driver that is
completely configurable, the thresholds of operation based on
monitoring the 16 bit raw data from the A/D converters and taking
appropriate action.
Comment: It should be possible to use any
receiver hardware for which it is possible to get raw I/Q samples to
work with the WebSDR program in this manner so the front end need not
be an RSP1a. In theory, the "universal" Soapy SDR receiver
software could be used with the WebSDR in this way given an appropriate
driver - but the caveat is that one must minimize the pipeline delay as
much as possible to maximize usability of the WebSDR.
"Is it stable?"
Admittedly,
these drivers are still in "beta" stage and undoubtedly have a few
issues, but they have been exercised for several weeks on a non-public
test server. Likely, a few tweaks will be required to best-set
the AGC parameters and to address currently-unknown stability issues.
Operating system upgrades:
Up
to this point, the four WebSDR servers had been running several
different versions of Ubuntu Linux ranging from 16.x to 20.x, so we
took this opportunity to upgrade all of them to Ubuntu 20.x. As
it turns out the RSP drivers' code wasn't readily compatible with
version 16.x anyway (although it did work on 18x).
Stability of WebSDR #2:
Coincidentally,
WebSDR #2 has been acting up for the past day or two, occasionally
hanging up for reasons not recorded in the log files. When we
pulled the server off the rack to install more USB interfaces for the
RSP's, we blew the dust out and re-seated the RAMs. Having
determined that the SSD (Solid State Disk)
reported that the drive was healthy, we don't think that that was the
issue - but we are prepared to replace the hardware if necessary.
Comment:Updates to the "Technical Info" page are pending.
5 November, 2021:
Upgrade of WebSDR #4
WebSDR #4 (Magenta) has been significantly reconfigured:
40 meters:
Formerly, 40 meters was covered with two receivers, "40CW" and "40PH"
because the limitation of sound cards used with the "SoftRock"
receivers was a bandwidth of 192 kHz - the actual, usable coverage
being 180-something kHz, so two segments were needed to cover all 300
kHz of this band. As with the 20 meter receiver a few weeks ago,
an SDRPlay RSP1a was used to provide continuous coverage of the entire
40 meter band. Because we can, the, the receiver is configured
for 768 kHz of bandwidth and the actual coverage is around 700 kHz owing to band-edge filtering.
Note:
Compared to the 40 meter receiver on WebSDR #1 there is
additional "edge darkening" on the waterfall and a slight "hump" in the
noise floor between 7025 and 7100 kHz. This is due to the
super-sharp 40 meter band-pass filter that has been installed to
suppress the (sometimes)
super-strong shortwave broadcast signals that appear on the adjacent 41
meter SWBC band. On a future visit, a bit of tweaking of that
filter may be in order to try to level out the "hump" a bit."
15 meters:
The same type of upgrade was performed for 15 meters as well, covering
the entire band with one "receiver". This is an upgrade of the
older receiver which utilized an 8 bit RTL-SDR dongle preceded with a
frequency converter, whereas the RSP1a has at least 14 bits of usable
resolution, making it more "future proof" in the (hopefully) coming days where improved propagation brings many dB stronger signals. This receiver is also configured for 768 kHz of
bandwidth. The downside is that most of the 13 meter
shortwave broadcast band is no longer covered.
10 meters: Because the 10 meter band is 1.7 MHz wide, it's too wide for even three RSP1a's, so approximately the lower 1/4th of the band is covered with an RSP1a (e.g. "10M-E Lo") and the rest of the band is covered with the original RTL-SDR+converter based receiver ("10M-E Hi").
The rationale behind this configuration is that the best receiver will
be where there are the weakest signals of the greatest interest to the
largest majority of users whereas the "rest of 10 meters" is still
covered with the original RTL-SDR+converter receive system.
We
also put a quad-core processor in this server, upgrading it from a dual
core due to the higher processing loads of the new signal acquisition
hardware, and because "why not"?
Upgrade of WebSDR #2:
In
a manner similar to WebSDR #4, RSP1a's were installed on this server,
combining the two 20 meter segments into a single "band", 15 meters was
switched to higher-performance hardware and 10 meters is covered by
both an RSP1a and the original RTL-SDR+converter.
Minor repair of the TCI-530 antenna:
As
noted in the 9 October, 2021 notes, we'd observed two wires touching on
the TCI-530 Omni antenna - something that was likely present from the
day that it was installed. If we shook the tower via the guy wires, we could hear a "crackle-crackle" on the lower bands (weakly on 40 meters, stronger as one went down in frequency) as these wires vibrated - which makes sense as the wire involved is one of those at the lower frequencies.
On this day, we were able to climb this tower (something that is absolutely miserable owing to its non-standard lattice configuration)
to the 60-ish foot level where we tied one of the wires back, pulling
it closer to the tower using an insulator, Dacron rope and a piece of
garden hose (to prevent chafing of the rope on the tower)
to prevent these two conductors from touching and causing noise
issues. There is one more place where the wires are very close (an inch/cm or two)
from each other, but we believe that these two wires only touch when
there are high winds. Because the near intersection of these
wires is another 15-ish feet up and a few feet away from the tower, it
will have to go un-tethered until we have some sort of man lift or
crane to reach it.
4 November, 2021: WebSDR #2 offline.
According to system logs, WebSDR #2(Green) went offline just after 0300 MT and as the time of writing, the cause is unknown.
A
bit after 8 PM (MT) we able to go onsite to look at the server and
there's evidence of a Linux Kernel Panic and the computer hadn't been
able to reboot on its own. A "hard" power cycle brought it back
online. Self tests were done - including the Solid State Drive -
and no problems were found, but if this happens again in the near
future, we'll simply replace the server.
Update - It happened again:
It would seem that WebSDR #2 only stayed online for an hour or so after
being rebooted, indicating a likely hardware failure: We'll
replace the server.
Site visit scheduled for 5 November:
As
it turns out, we were able to arrange a site visit for Friday, 5
November, so expect outages on all servers tomorrow while we do server
and infrastructure upgrades.
12 October, 2021: Widespread network outage!
In
the early hours on this day it was reported that packet loss on the
carrier used by the WebSDR's ISP started increasing, culminating with a
complete outage a bit after 0640 (MT) local time.
This
outage was apparently fairly wide spread as it appears to be affecting
about every ISP using the same backhaul carrier/fiber operator (e.g. Utopia)
- and it seemed to adversely affect mobile/cell phone service in
certain areas: Phone calls were known to work for at least some of
the carriers, but data coverage in some locales was either out or very
spotty, either due to outright outages or because of heavy loading by
users attempting alternate means of network connectivity.
Upon
arrival at the fiber landing site, the main router connected to the
fiber was showing an error state, so it was rebooted around 0904MT: This action
seemed to bring back the network connectivity, although some aspects of configuration/routing still appeared to be incorrect.
Later
reports indicated that the outage was caused by a configuration error
by the fiber operator. Unfortunately, they couldn't fully "back
out" once the mistake was made and some manual intervention by their
individual customers was required to do the initial restoration,
followed by additional back-and-forth to get things fully operational
on all levels.
9 October, 2021: WebSDR Site visit.
WebSDR #4 reconfigured:
With the successful installation and operation of the new 20 meter hardware (see below)
we were able to free up one of the eight "band" slots on this
WebSDR. This also freed the two FiFiSDRs that had been used for
coverage of 20 meters.
17 meter coverage expanded:
Previously, the coverage on 17 meters has been limited because the only
available sound card was capable of only 96 kHz - not quite enough to
cover a 100 kHz wide band. One of the FiFiSDRs that had been used
on 20 meters is now being used to coverage 17 meters in its entirety.
12 meter coverage added: The other FiFiSDR was used to add coverage of the 12 meter band, also in its entirety.
30 meter sound card changed:
With the switch of the 17 meter receiver to a FiFiSDR, a high-quality
ASUS sound card was freed up, allowing the reassignment of the 30 meter
- which had been using the (available)
sound card on the computer's motherboard. This will probably not
have an obvious change in the signal quality, but we feel better about
doing so! Like the on-board sound card, this "new" card is
capable only of 96 kHz, but this is more than adequate for a band that
is 50 kHz wide.
Coverage of 12 meters on WebSDR #2 expanded.
Since
we had it as a spare, we decided to use an extra FiFiSDR receiver to
expand the coverage of 12 meters from the 96 kHz, as limited by the
available sound card, to 196 kHz, allowing full coverage of that band
on WebSDR #2 as well.
Many interruptions later...
To
properly install/reconfigure these new devices, the WebSDRs had
to be restarted several times, inconveniencing the users on them at the
time. To be fair, we did
put bright red banners on the WebSDRs on which we were working, so
users were warned of this, so we can't feel too bad about it!
TBD:
During
a routine inspection of the towers and guys, we happened to shake the
wires, feeling for looseness and one of us noticed something that we'd
missed before: One of the longer elements - probably for 4 MHz or
so - appears to be touching one of the wires for a matching stub at
about the 55 foot level. On a nicer day - probably in the spring
- a climb of this tower is in the future. Because of the
geometry, about all we can do is tie back one of the errant wires with
some dacron rope and an insulator or two to hold them apart.
6 October, 2021: Additional testing on WebSDR #4 with the SDRPlay hardware:
After
months of testing and tweaking, we are pleased to announce the testing
of a new receiver configuration, made possible with the efforts of
several supporters of the Northern Utah WebSDR: The ability to
provide wider-band receiver coverage than ever before with high bit
depth.
You
may notice that several of the receivers at the Northern Utah WebSDR
have bandwidths of 1 MHz or greater, but these must use an 8 bit
pipeline originally designed for the RTL-SDR receivers. While
this driver was later adapted to use other hardware - like the SDRPlay
USB receiver cards, the pipeline is still limited to 8 bits,
sacrificing the full potential of this hardware. Through the use
of proper filtering and amplitude dynamics it's possible to get
reasonable performance with just 8 bits by pre-processing the data, but
it's still a limitation.
Up to now, the highest-speed sound cards available (for a reasonable price, anyway)
have been those that operate at up to 192 kHz, which is why many of the
bands have to be implemented using several receivers. For
example, it takes three such receivers to cover all of 80 meters, and
two each for 20 and 40 - and more than that if we wanted to cover15 and
10 meters 192 kHz at a time!
As
it turns out, the WebSDR software has no specific limit for its audio
sample rate - but the Linux operating system does, so this has been
patched, and a special driver has been written for the SDRPlay hardware
to be able to pipe this data into the Linux sound system at up to 768
kHz. In theory, a higher rate might be possible, but this would
likely require considerable reworking of the Linux sound kernel, so
it's unlikely to be done anytime soon.
New 20 meter configuration on WebSDR #4:
We are now testing this new configuration on the "20 meter" band on WebSDR #4, covering the entire 20
meter band in "one fell swoop" with a 768 kHz passband. At the
moment, our only other choice for 20 meters, in terms of bandwidth of
coverage, would be 384 kHz, but as you can see the extreme edges of the
waterfall are rather dark where the internal filtering rolls off, and
using this setting would have affected the upper and lower edges in
terms of sensitivity.
If
this testing goes well, we will be able to use the extra "band" freed
up by being able to cover all of 20 meters with just one receiver to
add 12 meter coverage to WebSDR #4, and expand the coverage of 17
meters to include the entire band, rather than the current 90-ish
percent of it: We may also be able to improve the performance of
the 15 and 10 meter receivers - just in time for the improvement in
propagation on these bands!
Slight modification in WebSDR behavior:
Although
present on WebSDR #3 for quite some time, code was added to WebSDR #4
so that it would automatically default to specific frequencies, modes
and zoom levels when one changed bands, or landed on the WebSDR without specifying the frequency and mode in the URL. This was done to "zoom in" a bit on the (now) rather
wide waterfall display, now zoomed in a bit to better show the portion
of the band that is of most interest. This "auto zoom" feature is
implemented on 20, 15 and 10 meters - those bands that cover a rather
wide frequency range.
5 October, 2021: New receiver hardware being tested - the SDRPlay RSP1a.
Using WebSDR #4 (magenta) as a test bed, we have configured the use of an SDRPlay RSP1a receiver on the 20 meter CW portion ("20CW-E") for evaluation, replacing - at least for the time being, the FiFiSDR that had been used since WebSDR #4 came online.
Unlike
most WebSDRs that use the SDRPlay hardware, we have produced a special
driver that allows the full "16 bit" pipeline of signal data to be
used, rather than the 8 bit "RTL-SDR" pipeline that is (believed to be)
used by all other WebSDRs that use this hardware. Special care
has been taken to minimize latency in the signal path, which is
significantly reduced from what is seen using the RTL-SDR driver
pipeline.
This same configuration has been in use for the past 5 months on a "test" WebSDR (available on the Internet, but not listed at "websdr.org")
with no issues whatsoever in terms of reliability and stability.
This test platform has allowed has allowed a thorough testing of
the new driver's operation and configuration and RF performance.
We
have been comparing the RF performance - in terms of signal handling
capability and dynamics - between the usual "sound card" receivers (e.g. "SoftRocks")
- which have thusfar been the gold standard, the 8 bit RTL-SDR driver
pipeline using both RSP1a hardware and various configurations of
RTL-SDR receivers (typically with strong filtering and outboard AGC) and have found the RSP1a on the 16 bit signal path to be very comparable to the SoftRock: We believe that we that the use of the RSP1a (and similar)receivers can be used to entirely replace the SoftRock hardware when properly configured and implemented. Such an implementation includes:
The use of strong, outboard band-pass filtering.
Because the Northern Utah WebSDR is in a location that has both a
low background noise and good antennas, any receivers that we implement
must
be able to handle both extremes - preferably simultaneously. In
accordance with well-established RF design principles, we do this with
outboard, band-specific filtering, prior to the RF input of the
receiver. Although the RSP1a does have its own band-pass
filtering, it is minimal, allowing broad swaths of spectrum into the
receiver hardware. For example, there are only two RF filters that cover the entire HF spectrum (3-30 MHz)
and this is simply not enough to maintain performance in situations
where strong shortwave signals may be present - even at frequencies
distant from where the receiver might be tuned.
The implementation of an "external" AGC algorithm. Although the RSP driver has its own AGC algorithm, testing has shown that it appears to be poorly suited for use as a broadband
receiver where signals across a larger chunk of RF spectrum are to be
receive simultaneously by multiple users. The original AGC seems
to be too aggressive in many ways, throttling back gain and operating
too quickly - something that might be appropriate for the normal,
intended use of this hardware (e.g. a single user tuned to a single frequency)
but we deemed it inappropriate for use on the WebSDR. The "new"
AGC algorithm being tested operates in the new driver and has a lot
more granularity in its configuration.
Higher rates are being tested at the 16 bit depth:
Finally,
was have been able to operate this same hardware at 256 kHz, 384 kHz
and 768 kHz at the full 16 bit depth on the WebSDR. We are still
evaluating these configurations on the test WebSDR and are satisfied
that they are working well, but because these are non-standard "sound
card" rates we are making sure that the necessary Linux driver
modifications are both easy to do and replicable. Fortunately,
the WebSDR server software itself appears to be "happy" at these higher
rates out of the box with no modification.
These "higher" rates will allow consolidation of some of the "bands" (e.g. 80, 40, 20, 15 meters) that presently cannot be covered in their entirety by a single sound card (with 16 bit signal depth).
With the "8 band" limitation of the WebSDR software, this means
that a single server can cover more "bands" at this higher bit depth (rather than having to use an 8 bit pipeline)
which means that it should be possible to add additional bands to
existing WebSDRs that are already "maxed out" with 8 overlapping bands.
We
hope to be able to configure the 20 meter receiver on WebSDR #4 for
higher receive bandwidth in the near future for testing with the
entirety of this amateur band being contained within just one "band".
If this is successful, we should be able to add 12 meter coverage
to WebSDR #4 just in time for the improving conditions on the upper HF
bands!
Additional comment about 15 and 10 meters:
I
didn't notice until the (local) evening of 10/5 that the 15 and 10
meters didn't reinitialize properly - and when I did notice it, I fixed
it.
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