On
this day - particularly in the morning - users of the Northern Utah
WebSDR servers 1-5 would have likely noticed a lot of drop-outs and a
few disconnects. The problem appears to be upstream, beyond our
ISP: Unfortunately, being so close to the New Year's holiday,
phone calls/emails to the higher-level providers are not being answered in a
timely manner to report it/determine the cause so it's hoped that the
reason for this is that they are busy trying to fix it!
28 December, 2022: Reconfigs and reboots.
This
evening all 5 of the remote WebSDRs were reconfigured and rebooted:
No obvious changes to the user, but rather some housekeeping
stuff.
One
task completed was the configuring of RAM disks so that we can move of
some of the "busy" temporary files used in the WebSDR off the solid
state drives and reduce their wear.
An
additional "URL" parameter was added: Including "?chan=X" where
"X" is either "left" or "right" will cause the audio to come from the
left or right channel, respectively - possibly useful for those who
have multiple receivers set up. For an explanation of all URL
parameters, see the "URL Parameter" page - link.
24 December, 2022: 2021/2022 Survey posted
Better late than never: We have finally posted the results of the 2021/2022 survey and you may read it here: 2021/2022 Survey.
It's
not that we didn't want to release the survey, but just that we got
busy with other things and then "out of sight, out of mind" took over.
Look for the next survey in mid 2023 and we "promise" that we'll post the results in a more timely fashion.
4 December, 2022: Minor changes made
The
"stream duplication" noted in the 2 December, 2022 entry was
implemented on all RSP1a hardware for WebSDRs 1, 2 and 4 this evening.
This will allow for analysis, monitoring, and the other features
mentioned below.
Receiver
start-up scrips were also modified. Previous, if an RSP1a
receiver went "out into the weeds" it was necessary to restart all of the RSP1a receivers, but now they may be restarted individually. This is in preparation for (what we hope to be) automatic restart and logging if one of these receivers goes awry.
2 December, 2022: Comments.
Power line noise higher:
You may notice that the power line noise is higher than normal, likely a result of a snowstorm combined with blowing (and conductive!)
dust from the salt pans around the ever-shrinking Great Salt Lake.
Typically, this effect is temporary until more precipitation
washes things clean.
Of
course, when the noise is bad like this, we aren't available to rush up
there and try to figure out which hardware, exactly, is the worst
offender - and when we do, Murphy says that it won't be doing it at
that time!
WebSDR tweaks:
A few tweaks were made to the WebSDRs that shouldn't be too obvious to the end-user, notably:
Stream duplication added to WebSDR #5.
This
duplicates the raw I/Q data from the receiver and makes it available to
other applications that we are considering adding in the future -
notably other receivers and capabilities that may include a CW skimmer
and FT-8 monitoring/logging: We aren't saying that we will add these features, but rather that we can.
This
feature also allows us to analyze what is going on with a receiver by
making the "raw" receiver data available that is being fed to the
WebSDR server itself available for analysis. For example, being
able to diagnose what's going on when the "glitching" happens that is
mentioned in the 19 November, 2022 entry.
If this is reliable, this "stream duplication" will be added to all receiver on all of the Northern Utah WebSDRs - except those that use the RTL-SDR dongle (e.g. AM, 60 meters, the 10 meter "high" receivers, 6 meters, and all of the receivers on WebSDR #3) which operate differently. As with WebSDR #5, the addition of this capability will result in a brief (<5 minute) outage of the WebSDRs as it is updated.
Note:
It was late at night when I did the above the next morning I
noticed that the 10 meter receiver hadn't come back online, so I
restarted it. Oops!
Buffering increased slightly:
The
buffering on all 768 kHz wide receivers was increased slightly from a
value of "33000" to "50000". During testing on WebSDR #5 this
seemed like it might reduce occasional, brief drop-outs under some conditions - and it may
reduce the recurring "glitching" problem noted in the 19 November, 2022
entry. This change of this parameter required a brief (<30 second) outage on the affected receiver bands to restart the process.
25 November, 2022: Audio channel selection added.
In response to an email (yes, we read them!)
you will now find - just below the "Record" button - new ones labeled
"Left", "Both" and "Right". As you might guess, these select
whether the audio will be sent to the left channel, both channels or
right channel.
This
function may be useful if multiple receivers are used and you want
audio to come from a unique source rather than have multiple audio
sources atop each other from the same speaker.
19 November, 2022: Site visit, comments.
Site visit:
RF amplifier repaired.
A visit was made to the remote receive site, mostly to repair the RF amplifier damaged by a nearby lightning strike (see the 22 September, 2022 entry, below).
Since that event, we'd shuffled things around and were using an on-site spare "gain block" (amplifier module), but this time we repaired the damaged amplifier.
This particular amplifier - in the "high pass" (>=30 meters)uses
a Gali-74+ MMIC amplifier which has fairly high gain and low noise
figure, but past history has shown that they are comparatively fragile
as we'd experienced the loss of this same type of amplifier during a
nearby lightning strike several years ago - see the 8 and 14 May, 2019 entries.
While there are several layers of lightning protection, evidence (e.g. the input amplifier of the 630 meter receiver - which uses a medium-power RF transistor)shows
that the energy induced into the antenna from this this particular
strike was very energetic, likely imparting 10s of watts of power.
To (hopefully)
prevent a recurrence of this, yet more protection - in the form of two
series strings of anti-parallel diodes - were placed across the inputs
of these style of amplifiers along with a DC bleed resistor.
Measurements indicate that two diodes in series are not likely to
conduct under any normal circumstances, so there is little worry that
this addition will result in a measurable increase in IMD.
Extraneous signals on 2 meters investigated.
Since the relocation of the 2 meter antenna from the building to the tower, the available sensitivity of these receivers (on WebSDR #3, Blue)
was dramatically increased, but we were still seeing ingress of some
weak carriers - particularly around 144.390 MHz, the APRS frequency.
Using
various techniques, we determined that the likely sources were the
RTL-SDR receivers, each with their own USB port and internal clocks.
We determined that this signal was not actually getting
into the tower-mounted antenna at all, but there was low-level ingress
along cables and equipment inside the building - not surprising as
coaxial cables aren't perfect in terms of shielding outside signals.
What
we finally did was relocate the 2 meter filter/amplifier module, which
had been located right next to a row of RTL-SDRs, onto another shelf,
adding ferrite chokes on the filter/amplifier's power leads and also on
some of the cables to reduce common-mode currents. The result was
a significant reduction in such signals.
Occasional glitching on WebSDR receivers:
Not related to the site visit - but worth mentioning - is that earlier this week, the 20 meter receiver on WebSDR #4 (Magenta)
had "glitched". This problem is manifest by "wider than normal"
signals and what sounds like clicking/stuttering on all signals.
It's usually still possible to understand audio, but it's quite
unpleasant!
This
is a known-occasional problem caused by the USB driver for the SDRPlay
receiver module sometimes getting out of sync with the hardware.
Typically, it seems to "fix itself" in just a minute or two, but
sometimes - like this week - this didn't happen. It would seem
that it started happening sometime shortly after all of the receivers
were checked and wasn't noticed until much later, at which time the
driver was reset manually. This issue can happen on any server
using this receiver hardware - namely servers 1, 2, 4 and 5.
To
help address this, we added some scripting to detect anomalies in the
log, but it would seem that this particular problem doesn't seem to
generate errors anywhere. While this problem is very obvious to
the listener, it's not so obvious how this issue may be reliably
detected, automatically. This issue happens "infrequently" which
makes it a bit more difficult to debug.
You may (or may not) have noticed the "Allow Keyboard" button just above the waterfall that allows many operations of the WebSDR (e.g. tuning, mode selection waterfall zooming, frequency entry, audio muting, etc)
to be done without the mouse. Some people find such keyboard
operation to be more convenient - particularly those who are sight
impaired.
A suggestion was received via email that the (then)
current tuning steps were too small, so a change was made to provide a
better variety of tuning rates - particularly larger tuning steps - and
these are as follows.
Tuning is done using the "j" or left-arrow to decrease frequency and the "k" or right-arrow to increase frequency
In SSB or CW mode, these keys by themselves will tune 10 Hz.
In SSB or CW mode, these keys PLUS the "Shift" key will tune by 50 Hz.
In SSB or CW mode, these keys PLUS the "Control" key will tune by 500 Hz.
In SSB or CW mode, these keys PLUS the "Alt" key will tune by 2500 Hz.
As with the on-screen tune buttons, these tuning rates will change with modes as follows:
In AM modes, the tuning rates will be 100, 1000, 5000, 10000 and 500000 Hz, respectively.
In FM modes, the tuning rates will be 1000, 5000, 10000, 12500 and 50000 Hz, respectively.
URL command for keyboard control added to the Northern Utah WebSDR servers.
If you wish to have keyboard control turned on without having to click on the "allow keyboard" check box, add "?allow_kbd" to the URL, as in:
It appears that around 0938Z on 8 November (UTC) WebSDR #1 (Yellow)experienced
some sort of glitch, causing all of the receivers to become unavailable.
Users would have seen a (nearly) blank waterfall and/or bits of
signals with random bursts of audio.
There doesn't appear to have been any sort of hardware failure, so a simple restart of the WebSDR Server software itself (and all of its related drivers) seems to have "fixed" the problem.
Being
that these are remote systems, it may take a few hours before one of
the "sysops" notices a problem and/or is notified of issues, so we
appreciate your patience.
25 October, 2022: Comments.
USB CW Reception added:
By default, the WebSDR receives CW using LSB (Lower SideBand) using a 750 Hz offset. The ability to use receive CW using upper sideband was added, and this may be done in two ways:
Check the "USB CW RX" box. Checking this box will switch the receiver to USB CW reception, using the default 750 Hz offset.
Regardless of how one selects USB CW reception, clicking on the checkbox will toggle between USB and LSB.
At present, the displayed frequency offset is fixed at 750 Hz.
Occasional power line noise:
As
noted in previous entries, we are continuing to "work the problem" of
power line noise. As is typical with such noise, it varies,
depending on local moisture and contamination of the power line
hardware that is causing the leakage/noise issue - and with winter
approaching, expect this noise to vary a bit - and hopefully diminish.
Eventually,
we hope that this issue will be resolved with the participation of the
local power company - but this is still likely months away from
happening.
22 September, 2022: Update on lightning damage.
One of the local volunteers was able to get some time (between working on repair of lightning damage for other parties) and go to the WebSDR site and bring things back online:
WebSDR #2 "High Split" RF line amp "blowed up":
As expected, the RF line amplifier on the input of the
"High" splitter for WebSDR #2 was damaged. The line amp for the
12 meter receiver was "stolen"
A spare stand-alone "gain block" (amplifier module)
was installed on the 12 meter receiver. The S-meter is likely
reading 2-3 dB higher than it should, but this will be fixed on the
next "full" site visit.
630 meter restored:
It was observed that the 630 meter receiver was completely
blank. Considering that the RF filtering for the 630 meter
receiver passes signals below 500 kHz - and that lightning energy is
dominant below 1 MHz - it's no real surprise that the RF amplifier on
this receiver was destroyed. A spare transistor was on site and
replaced, bringing it back online.
WebSDR #4 throwing DMA errors:
Although it was working fine, WebSDR #4's screen was scrolling DMA errors: A reboot fixed this.
RF amplifier installed on KiwiSDR #6:
During the last trip, I forgot to install an RF amplifier on KiwiSDR #6: This was done.
Grounding system inspected:
A visual inspection was made of all tower grounds and related connections: Everything looks fine.
To be done during the next trip:
RF Amplifier repair: The transistor should be replaced to repair the amplifier.
More spare parts on site: Yes, that.
Equalizing filter for WebSDR #5:
The KiwiSDRs on the other antenna have such devices to reduce the
lower-frequency signals' energy. This allows amplification to
allow the KiwiSDR to "hear" the 10 meter noise floor while reducing the
probability of overload for the lower-frequency (and stronger) signals.
Comment: A nearby industrial customer (a pumping station on a pipeline)
also experienced significant lightning damage, knocking their system
out of commission pending the repair, so whatever happened was rather
significant! Similar damage was reported all over the county in
areas over which the storm was most severe.
22 September, 2022: Lightning damage - no signals on WebSDR #2 (green).
There
was a particularly violent lightning storm in Northern Utah on the
evening of 21 September/morning of 22 September that caused a lot of
damage across the area - and it would seem that the Northern Utah
WebSDR was no exception.
No signals on WebSDR #2:
WebSDR
#2's RF path is via the TCI-530 omnidirectional log-periodic antenna.
In the building, this is split according to band: The lower
bands (160-40 meters) are sent to WebSDR #1 (yellow) and the upper bands (30-10 meters) are sent to WebSDR #2 - with an RF amplifier in the path. It would seem that this RF amplifier was damaged during the storm, likely due to a direct or very nearby lightning strike.
What this means is that ALL bands on WebSDR #2 are affected - with the sole exception of 6 meters, which is fed from a separate antenna (a 6-meter "Ringo Ranger" at 40 feet on a different tower).
"What about lightning protection?"
In the past several months we have spent considerable time (and expense!) on improving grounding and lightning protection(this work will be the subject of a future video for the Northern Utah WebSDR's YouTube channel) in which we have:
Added a grounded/bonded entry panel with lightning protection/grounding on each and every signal line that enters the building.
Added more ground rods and bonding to the metal building itself.
Added more ground rods and bonding to each of the towers.
While grounding, bonding, lightning (surge)
protection on RF signal leads is of paramount importance - particularly
for a site like the WebSDR where we simply cannot run over there,
disconnect the coax cables and throw them out the window (if we had a window!)
every time a black cloud floated by - all we can do is the "best we
can" and minimize the likelihood of damage. Because WebSDR #1 and
WebSDR #2 are on the same antenna
- and WebSDR #1 does not seem to have suffered any damage at all - this
is a testament that the lightning protection that we have is quite
effective..
Alternatives:
For receiving using the east-pointing beam, go to WebSDR #4 (magenta): LINK
For receiving using the northwest-pointing beam, go to WebSDR #5 (teal): LINK
Repairs:
Please
remember that the Northern Utah WebSDR's receive site is in a fairly
remote location. Because of this - and the fact that our
volunteers have other duties and obligations, it will take some time
before a site visit can occur and damage repaired and/or work-arounds
done.
In the meantime, we thank you for your support and understanding.
17 September, 2022: Site visit.
Noise issues on WebSDR #4 resolved.
As
noted in the 14 September entry, it was noted that the noise floor was
elevated on the 10 meter receiver of WebSDR #4. Upon
investigation, it was worse than we thought: All bands were
degraded.
The
problem was tracked down as being a flaky connection on the shield of
the coax cable at the lightning arrestor, in the cable entry box,
allowing line, power supply, and computer noises to enter the cable as
well as reduce the desired signals.
The problem connector was replaced and performance returned to normal.
New KiwiSDR power supply system installed.
The
KiwiSDRs require about 1.5 amps each on start-up and consume somewhere
around 600-800 mA when running. With a total of five KiwiSDRs on
site, there were two power supplies: A dual (redundant) 3-amp 5 volt supply (originally capable of 6 amps total)
running KiwiSDRs 1-3 and a single 3 amp supply for KiwiSDRs 4 and
5. As noted in the 14 September entry, the dual power supply was
buckling under load, requiring one of the KiwiSDRs to be powered down.
A
"new" power supply was constructed based around a 240 watt ATX power
supply. The DC output of the power supply was heavily filtered
with capacitors and inductors and a custom board was constructed based
on a PIC processor that has several functions:
This
processor monitors the power supply - cycling its power switch as
necessary to make sure that it starts up or gets reset if there is a
fault.
When
powered up, the two busses are staggered, the first being turned on
after about 5 seconds, and the second about 10 seconds later - this to
assure a rapid voltage rise on the KiwiSDRs so that they reliably start
up - and also to separate in time the highest current (start-up) load.
It
also monitors the output voltage going to two 5 volt busses - each
equipped with a 5 amp, self-resetting thermal fuse. If the
voltage drops too much (below about 4 volts), the power on the bus is
turned off for 10 seconds before being turned on in the event that
there was a momentary fault. The interval between restarts
increases (to a maximum of about a minute between attempts) if the fault persists.
The
power supply is being conservatively run: The total current
allowed by the thermal fuses is 10 amps, far below the maximum 22 amp
rating of the power supply on the 5 volt bus. This supply is also
power-factor corrected which significantly reduces the volt-amp load on
the UPS - not to mention the fact that this supply is more efficient
that the dual 3 amp, 5 volt linear supply that had been used.
KiwiSDR #6 installed.
Another
KiwiSDR was installed - this one on the Northwest-pointing log periodic
antenna. This KiwiSDR is run in 8 channel mode, and two public
channels are publicly available.
14 September, 2022: Comments:
Additional mode annunciator added to WebSDRs:
While there is an indicator of the current mode (CW, LSB, etc.)
just below the frequency entry bar, it bothered me that there wasn't
one just above where one actually selected the mode. This has
been remedied: The current receive mode is now displayed on the
same line, in the "Bandwidth" section of the control pane, as the
currently-selected bandwidth.
Noise issues on WebSDR #4's "10 meter LO" receiver:
The
background noise on this receiver is badly degraded with the presence
of "computer" noises. It's very likely that a cable has gone bad
or an SMA connector has come loose and the integrity of the shield
connection has been compromised. We know that it's not a problem with the 10 meter passband itself as the "10 meter Hi" receiver shows no such degradation.
KiwiSDR #3 offline:
For
reasons not yet determined, the power supply for KiwiSDRs 1-3 is no
longer capable of powering all three of the KiwiSDRs. This supply
- consisting of a of pair "diode-OR'd" 5 volt, 3 amp supplies seems to
be buckling under the load - perhaps because of degradation of one of
the two supplies. A "new" power supply that should be capable of
powering all of the KiwiSDRs on site is being constructed.
27-28 August, 2022: Site work, again:
WebSDR #5 now fully operational:
As
noted in the previous entry, WebSDR #5's RF chain was "temporary",
using only an 8-way splitter and amplifiers to divide the signals.
Of course, this arrangement is insufficient in the context of a WebSDR
for a couple of reasons:
It requires a significant amount of amplification prior to any filtering just to overcome the splitter losses. This is important if the receiver system's noise figure (which includes RF background noise) needs to be low - as is often the case at the Northern Utah WebSDR.
It unnecessarily exposes each receiver to off-frequency RF-energy. There are really NO SDR-type receiver that have band-specific filtering, so strong signals, such as those from Shortwave Broadcast (SWBC)
stations on frequencies far-removed from the needed amateur band will
impinge on those receivers. As any designer of RF systems knows,
allowing "unneeded" RF energy to reach the front end of the receiver is
deleterious to performance - particularly when the bands are open and very strong SWBC signals are present.
The
per-band filtering network is pretty much a duplicate of the proven
design already in use on WebSDR's 1, 2 and 4 - and also at the KFS
WebSDR in Half-Moon Bay, CA.
The "10M-NW Hi"
receiver is now operational, allowing coverage, albeit with a
lower-performance RTL-SDR, of the upper 2/3 of the 10 meter amateur
band.
With these changes, WebSDR #5 now covers all amateur radio frequencies from 30 through 10 meters.
Please note:
As mentioned before, we are still experiencing intermittent power line
noise issues - most obvious on 20 meters on WebSDR #5. We believe
that we have identified the power poles with the involved hardware and
are working with the power company to resolve this, but these efforts
will take time.
Tower grounding improved:
For whatever reason, the original grounding of the two towers on site (the 94' - 27 meter - for the omnidirectional antenna and the 80' - 25 meter - antenna for the log periodic antennas)
each consisted of a single ground rod attached to one leg of the
tower. During this work party we added two more ground rods per
tower, each rod connected to its own leg of its tower.
The components for improving this grounding were supplied by KF7P Metalwerks (link). Despite the non-standard (in the ham world, anyway) tower leg sizes and configurations, we were able to come up with appropriate means of connecting to the towers:
The 80' tower: This tower has 2" legs, so 2" (51mm)
wide copper strapping was attached using stainless-steel "U"
bolts. Thin stainless-steel "shims" were used as interstitial
material to prevent mechanical contact between the copper and the
galvanized pipe.
The 94' tower:
This tower uses aluminum flat angle pieces, so stainless shims were
again used for interstitial material and a flat plate was used on top to
hold the arrangement against the leg.
Mentioned
previously was a cracked weld on the bracket that interfaces the top of
the tower to beam itself where some of the welds had cracked.
Fortunately, there are "redundant" welds in this position, but it was
concerning that this had occurred.
Because
it's difficult to get a 300 amp welder to 80+ feet, we decided to do a
more expedient "repair": Install several grade 8 bolts to hold
things together, mainly by keeping any small movements to a minimum to
prevent propagation of the crack in the weld.
Armed
with a cobalt drill bit, everything went well while drilling through
the thicker, lower plate, but that halted when we hit the smaller
right-angle portion: The drill bit immediately dulled and
blued. After getting another cobalt bit and going much easier (slower drill speed, frequent oiling) we still could make no progress and another bit was ruined.
Looking
around, we found a carbide-tipped bit of the sort that looks like it is
intended for masonry, but suggested for use on steel by its
manufacturer. Since these were actually cheaper than the cobalt
steel bit, we got several of them and managed to complete a total of
three holes with just two of these bits. The grade 8 bolts were
installed, tightened, and double-nutted to keep them secure.
12-13 August, 2022: Yet more
site work:
New
log periodic beam installed!
A
task actually completed on 7 August - but not mentioned until now - the
Northern Utah WebSDR now sports ANOTHER
log periodic beam antenna. This antenna, a KLM 10-30-7LPA, is
located on the same tower as the larger LP-1002, but at the 53 foot (16 meter) level - about 1/2 wavelength above ground for its lowest operating frequency. This antenna covers the 30 through 10 meter bands.
This
antenna is oriented to a heading of 278° (True), giving it coverage into the "upper" west coast of the U.S. and Canada, Alaska, and into east Asia (Japan, Philippines, Malaysia, eastern China, etc.) as well as Australia and New Zealand - a change from the original 296° heading.
Why didn't we point this antenna at Europe, you may ask? For several reasons:
In recent polling of users, the addition of an antenna pointed towards Australasia ranked highly compared to other possibilities.
The orientation of the tower's legs and the guy wires limit how an antenna can be mounted on it: Pointing the antenna at 278° is nearly parallel to one face of the tower, making it easy to do.
This antenna was donated to the Northern Utah WebSDR ("Utah SDR Group") by the Ted Elliot Hartson Trust. We thank the Hartson family for this kind donation!
This antenna was originally located in Northern Arizona, so an expedition was mounted to get this antenna (and the 6 meter vertical now in use) - a distance of over 600 miles (about 1000km) each way.
While we were there, we did a lot of additional work to take down and
secure other antennas and related structures on the site so that there
would be no concerns by the family related to their safety and
integrity.
<450 kHz signal path repaired:
It
was noted that the signals from the "<450 kHz" signal path - which
is used for 2200 Meter reception - had failed. It was discovered
that a "temporary" transition between CATV hardline and RG-213 had
shorted out due to a tight bend, so a custom-machined transition was
installed in its place: We have three more of those "temporary"
transitions still in place and they will be replaced as we have time to
do so.
Once
this short was cleared, it was noted that an inline common-mode choke
had an intermittent connection on its center pin. A different
choke was installed and the now-repaired choke is on-site as a spare.
This choke - which is a "hum blocker" for analog video used to
prevent common-mode 60 Hz current from flowing - is used to isolate the
feedline for the E-field whip antenna, which is on the tower, from
circulating currents from the building and power system.
WebSDR #5 now public:
Using this new antenna exclusively is WebSDR #5, which has coverage on 30-10 meters.
You
can also find it on each of the WebSDRs' list of bands and servers,
just below the "band select" buttons, with buttons marked "NW" (e.g. "20M-NW") referring to the "Northwest" heading of the antenna.
Temporary RF chain for WebSDR #5:
The
RF infrastructure for this receiver is still being completed so it is
possible that, at times, some of the receivers may experience overload
due to the lack of proper filtering.
The
12 meter receiver, in particular, is currently "gain starved" and lacks
sensitivity: While more amplification could be added, doing so
would probably be deleterious in that it would likely overload on
strong signals - particularly from Shortwave Broadcast transmissions.
In
case you were wondering, the current color scheme for WebSDR #5 is
"Teal" - a dark-ish green color with a bit of blue. We will
probably tweak the colors slightly as it may be a bit on the dark side!
Issues with the 20 meter receiver on WebSDR #4 being investigated:
As
noted in an earlier entry, we are trying to figure out why the 20 meter
receiver on WebSDR #4 sometimes gets into its "glitchy, stutter"
mode. We replaced the USB cable and moved it to a different port (on the same USB hub)
but it still behaved capriciously, so the receiver module itself was
swapped with another known-good unit - and the problems followed, indicating a likely problem with the USB interface card.
The
USB connections for the 20 and 10 meter receivers were swapped:
Because 20 meters is more popular than 10, the loss of 10 meter
coverage would be less problematic than that of 20. Anyway, it's
unlikely that there will be any fantastic 10 meter openings, while the
interface is misbehaving, in the time it will take to get another USB
interface card.
More power line noise investigation:
The
"nearby" power line noise was present again, so we walked the nearby
power line, equipped with a 2 meter DF receiver capable of AM and
pulse-amplitude detection as well as an ultrasonic receiver.
Pole
#130 had a fairly high noise level on 2 meters and arcing could be
heard in the 30-33 kHz area on the ultrasonic, and pounding on the pole
itself (or kicking it) caused a noticeable change in the nature of the noise.
Just
south of this is pole #131 and it, too was also noisy on 2 meters - but
pounding/kicking it caused the noise to come and go.
To be sure, these aren't the only noise power poles, but they are definitely the closest! Now, we'll need to figure out how to report these to the utility.
YouTube videos to follow:
Much of the recent work done on site was documented with photos and video. In the future we'll (eventually) post videos documenting some of this work on the Northern Utah WebSDR YouTube channel.
4-7 August, 2022:
More work on site:
Work
on the LP-1002 log periodic
beam antenna winding up:
Painting completed:
With
the base coat completed and one coat of the polyester top coat applied
last time, we were able to apply two more of the polyester top-coats -
the last coat just barely
beating a rain storm!
With
the application of three of these top coats, one can consider the
insulators of the LP-1002 to be well protected for several more decades.
Insulators/feed sealed:
Noted
in an earlier post, the feedpoint insulators of the beam were damaged:
A section of porcelain was spalled and a plastic insulator
was
cracked. These were given a liberal coating of RTV/silicone (pigmented
rather than clear, to
better-withstand UV exposure) to provide
protection. A "freeze crack" in a piece of aluminum tubing
used as a conductor (and
not as a feed)
was also sealed: If we remember to do so, we'll drill a very
small hole in the bottom of this tubing to prevent the inevitable
moisture accumulation.
Misc.
electrical work:
An
issue was noted with the grounding of the "third prong" in the
building: It's old enough that it relies on the metallic
conduit
for ground return and we'd observed that with loosening and age, this
was bolstered with the running of separate "green wire" grounding in a
few locations. We also noted that a wire clamp on the neutral
wire seems to have worked itself loose, causing voltage issues on the
two 120 volt circuits: This was tightened, and the other
screw
clamps checked.
The
power drop to the site
doesn't go directly to the building (which
the power company
considers to be a "temporary" structure as it could theoretically be
moved on its skids)
but rather to a separate wooden pole with a weatherhead, conduit and
meter base. When this drop was installed, it was done
quickly,
using some pieces of Douglas fir, but these had started to split and
crack. With the aid of the lift, these pieces were replaced
with
redwood and reattached to the pole using proper lag bolts:
This
arrangement should be able to endure many years in the elements.
APRS
"Igate" installed:
Leveraging
the now-relocated 2-meter antenna to the tower, an APRS Igate was put
together using a Raspberry Pi B+ and a Nooelec RTL-SDR as the receiver.
Another splitter was added post filter/amplifier in the
2-meter
signal path and the RTL-SDR connected to it
An
"Igate" is an Internet
Gateway, taking the reported APRS (Automated
Packet Reporting System)
transmissions that it hears and forwarding them to servers on the
Internet, making them public ally available at places like "aprs.fi".
This I-gate has and ID of "NUT" - for "Northern UTah, just in case
there was any doubt! This node is undergoing final
configuration. Note that this is a receive-only
Igate - for obvious reasons!
Initial
reports that it works pretty well, being able to receive signals along
much of the Interstate 15 corridor from Brigham City to North Salt Lake
- and a few places beyond this. The use of the south-pointing
5-element beam certainly helps, but it will limit reception of stations
to the north, east and west to a degree - although coverage is
more-limited by geography in those directions, anyway.
"Other"
work done:
The
majority of our time
on-site was spent working on another project which has been in process
for months - we'll post
more about this in the near future.
28-31 July,
2022: Site visit, again.
Work on the LP-1002 log
periodic beam antenna:
Epoxy base coating
completed:
As
you can infer from the heading, we are continuing work on the
maintenance of this giant antenna. As of today, we
have the
necessary number of epoxy base coats on the antenna's fiberglass
insulators, so we now must let it cure for the requisite amount of time
before applying the polyester top coats to protect it from UV.
Broken
weld noted:
At
the 80-ish foot level - on the antenna base bracket - we observed a
crack in the weld that was propagating along its length: Of
the
four sections of weld bead, one in mid-span is completely broken and
the one on the end is (visually)
about 3/4 of the way along - but it is probably farther along than
that. Based on the amount of corrosion inside the "completely
cracked" weld, it has probably been like this for quite some time.
This
weld attaches a right-angle steel piece to a heavy steel base plate and
while the "outboard" welds are compromised, the inboard welds (on the other side of the
right-angle piece) appear to be fine, so destruction is
not imminent.
To re-weld this piece we'd
either have to move the antenna and mounting to the ground (requiring a fairly hefty crane
and a very calm day)
or get a welder up to the 80-ish foot level - and the latter seems more
likely. We are looking into what it will take to do this.
In
the meantime, we are looking at installing some grade 8 bolts to hold
the
pieces together - which would mainly prevent the crack from
propagating: This should suffice for the future, but we'll
still look around for the opportunity to get some welding done.
Replacement
of "dead end" of guy
line.
It
had been observed some time ago that there was some fraying of the one
of the guy lines near the top of the tower, and with the lift - and
several hours with no wind - it was time to investigate.
Fortunately, we had an extra "dead end" on-hand, so we were
equipped to do a replacement. The first thing that we did was
to
put a (somewhat rusty)
dead
end on the bottom end of the guy wire - a few feet up from the bottom -
and we removed tension with a come-along and unscrewed the turnbuckle,
dropping the guy wire and letting it go slack.
With
two of us in the lift, we went to the top end and unraveled the damaged
end, finding that about half of its strands and that one strand of the
guy wire itself were cut. While we were initially wondering
what
might have damaged it, it was clear once we unwrapped things that it
was due to impact damage - probably from a crane or lift during a
previous servicing.
Since the damage was only about
4 (6cm)
from the end, we simply moved up the end, bypassing the damaged
portion and installing the new end.
Back
at the bottom we reattached the guy wire. Fortunately, there
had
been enough room on the turnbuckle to allow for the shortening that
we'd done at the top - but if there hadn't been, there's still a couple
of feet of cable beyond the dead end at the bottom and it would have
been fairly easy to move it down by the required amount.
Still
to do:
Replace
some 1/4-20 hardware.
As noted before,
some 1/4" hardware is missing in some non-critical places (mostly bracketry)
and the missing pieces will be replaced.
Repair
of feedpoint insulation.
Also noted previously, the insulator at the end of the feedline is
cracked, so we'll be waterproofing it and protecting it from UV.
Power failure - and
something "not quite right" about the UPS:
This
portion of the county has notoriously bad power, and it seems as though
our beleaguered UPS has started to "stutter" when going onto
battery: Instead of simply switching to battery when
something is
amiss with the AC mains input, it seems to switch on and off several
times before finally taking over. The result of this that the
computers (WebSDR
servers)are
seeing this as a power failure and rebooting. When the power
actually went out, this very thing occurred and all of the servers
rebooted. We were wondering if there was something about the
wiring in the building that might make the UPS unhappy, and while this
UPS has an indicator of improper building wiring (floating ground, "neutral" and
"hot" swapped, etc.) the manual states that the UPS
detecting this will NOT
affect its operation.
A
month or so ago we added a "bulk charger" to the system as the UPS
itself was only capable of charging the battery at something well under
an amp. In the past we've had back-to-back power outages
which
caused a cumulative decline in the state-of-charge, meaning that while
the battery capacity was theoretically present, not enough charge could
be put back into the system to carry through a subsequent
outage.
During testing we "discovered" that having this bulk charger connected
seemed to cause the UPS to become unhappy - even after fitting a ground
isolator to the power cord of the bulk charger
In
working the problem, we observed that if we had the bulk charger on the
same phase as the UPS, the latter would be "unhappy" at the instant
the power failed, resulting in the "stuttering" which caused the
servers to reboot. Initial testing indicates that by moving
the
mains input of the bulk charger to a different phase than the UPS that
this "stutter" problem is solved: We even reconnected the
line
conditioner/filter to the UPS output again and it seemed happy, so the
assumption that we'd made last time about this having something to do
with the problem was incorrect.
Ultimately,
we installed two new outlets on circuits dedicated for the UPS and bulk
charger - each on a different phase. Will this prevent the
UPS
from "stuttering"? Time will tell!
27 July, 2022:
Changes to the Firefox browser "breaking" WebSDR audio.
As
of Firefox version 103, released near the end of July, 2022 (around the 26th),
it would
seem that "gestures" are required to enable audio/video on many web
sites when using this browser. What this means is that the
user must do something - like
press a button - to enable audio/video - and this is also required on
the WebSDR. Users of the Chrome
browser and Apple devices have had to do this for some time.
What you can do about this:
Press the
"Firefox/Mozilla audio
start" button. We have added this
button to the Northern Utah WebSDR servers and by pressing this button,
audio is enabled. Note
that you will have to press this button EVERY time you load the web
page unless you configure your browser as described below.
Change
your preferences within
the browser. It is possible to
configure the browser such that it does NOT
require your intervention to start the audio when the WebSDR page is
loaded.
Note that the instructions
describe how to enable audio/video for ALL web
pages - but it is possible to specify this for specific sites if you
wish, but such configuration is beyond the scope of this page.
Power line noise:
As
if the above weren't enough, we are experiencing intermittent bouts of
severe power line noise as noted in the previous entry.
Often,
this noise is absent when we are prepared to seek it out which means
that when we aren't able to do so - or just aren't on site - it will
often buzz away, notably impacting almost all bands - including 6 and 2
meters. We believe that we have narrowed it down to 5 power
poles, but we would really like to be able to give more specific
information to the power company than just saying "We think that it's one of
these!"
21-23 July, 2022:
Site visit.
Work
on the LP-1002 log periodic
beam antenna:
Because
the boom lift is still on-site, we continued with the maintenance on
this antenna's fiberglass insulators. When we finished last
time,
all of the insulators had been sanded, but only 75% of them had been
coated with the two-part epoxy paint - a task that was finished in the
waning hours of the 21st.
The
next day - starting with the elements that had coated first - they were
attacked with sandpaper and a flat file to remove high spots and loose
"hairs" of fiberglass and in doing this, some of the original
fiberglass coating was again exposed, as expected.
Immediately
after sanding, another coat of the two-art paint was applied,
significantly leveling the surface and making it look quite uniform.
Officially, we consider this to be the "first" coat of paint
as
it is the only one (so
far) that has completely re-covered the insulator.
After
applying this coat, a "second" coat was applied to some of the elements
until what was left in the mixing cup was used up. At this
point,
we'd pretty much consumed the last of the paint so additional coats
will have to wait until next time.
Still to do:
We need to finish applying the
"second" coat - and put at least one more coat of two-part paint atop
it.
After
this is applied and cures, we'll need to apply at least two coats of
polyester "top paint" to protect the two-part epoxy paint from UV and
weather.
There are a few bits of missing
hardware (mostly
1/4"-20)
that need to be replaced and a few things that require minor repair -
but at least some of these will wait until after the painting is done.
Relocation
of the six and two
meter antennas:
Between
the 34 and 40 foot levels, two "outriggers" of strut material - tied
together with diagonal bracing and a vertical pipe - were installed.
On
the upper end of the pipe, a
new (to us!)
six meter antenna (a
"Ringo Ranger") was installed, putting its base at about
the 42' (about 13 meter)
level. On the lower end of the pipe the five element
two-meter beam antenna was installed.
RG-6
feedline was installed for each of these two antenna, terminating in
the box at the base of the tower where the shields were grounded for
lightning protection.
Using
two of the CATV 75 ohm
hardlines that were buried several years ago, we attached the output of
the grounding block (using
short RG-6 jumpers) to them using transitions that were
made for us by another local amateur.
The
other end of these runs of
hardline (at the
building)
were terminated and connected to the lightning arrestors in the entry
panel - and from there, it went to the six and two meter receivers.
Estimated line lengths and losses:
Six
meters:
The length of the RG-6 run on the tower is estimated to be
about 55' (16.8 meters)
and the loss is estimated to be about 0.85 dB. The length of
the CATV hardline is about 175' (53.3
meters)
and its loss is estimated to be another 0.8 dB. Miscellaneous
losses are expected to be 1 dB, making the total loss between the
antenna and the receiver about 2.65dB. The gain of the
antenna (a
Ringo Ranger) is on the order of 3 dBi.
Two
meters:
The length of the RG-6 run on the tower is estimated to be
about 46' (14 meters)
and the loss is estimated to be about 1.3dB. The loss of the
175'
of hardline is estimated to be about 1.2 dB with miscellaneous losses
expected to be about 2 dB for a total loss of about 4dB
between
the antenna and the input of the filter/amplifier assembly in the
building. The gain of the antenna (a 5 element Yagi)
is expected to be on the order of 10 dBi, conservative.
The above losses are
commensurate with a single 150' (45.7dB)
run of
good-quality RG-213 in each case.
Results - 6 meters:
The
6 meter receiver is a humble RTL-SDR dongle with the gain set to about
38 dB. With this setting, about 2 dB of "site noise" is
detectable - which is FAR
lower than it was when the six meter antenna was mounted on the
building, placing it much nearer the power line and in a location with
considerable computer noise.
Results
- 2 meters:
The
two meter receivers - which are RTL-SDR dongles, each covering 2 MHz of
the 2 meter band - are fed with a homebrew amplifier based on the
MAV-11 MMIC preceded with a simple L/C band-pass filter.
Currently, the noise floor from the antenna is about the same
as
the receiver system (the
amplifier and RTL-SDR dongle) owing to the need to reduce
the gain setting of the dongle to prevent overload.
While
the RTL-SDR dongle is capable of better sensitivity than noted above,
its 8 bit A/D is really showing its limitations here. When
the
two meter antenna was on the building, its lower location made it more
subject to ground and Fresnel effects - plus there was a significant
amount of noise from the building itself in terms of computer, LAN and
power supply energy. By placing the antenna much higher (at about 32', or 10 meters)
signal levels from distant sources are notably higher, requiring that
we back off the receiver gain by at least 6 dB: More may be
required.
As it turns out, given a single
signal in a 2 MHz bandwidth, you can reasonably expect only about 65 dB
of useful range on an RTL-SDR - this being defined as the range between
overload, and about 12 dB SINAD. If you wish to have a
receiver
of reasonable sensitivity (say,
0.25 uV, or about -119 dBm) you had better make sure that
the TOTAL
SIGNAL POWER
of ALL
signals (e.g. multiple
repeater outputs, signals on repeater inputs, and simplex signals) that
might be present at a given instant NEVER
exceed about -55 dBm (with our
configuration): Considering that -55 dBm is roughly
what you might expect from a 100 watt ERP repeater at a distance of
about 55 miles (88km)
when using a 10dBi gain antenna, this means is that if you are using an
RTL-SDR in an environment with several repeaters or signals of moderate
power levels and distance, you will NOT be
able to run the receiver anywhere near maximum gain.
Because we make sure that the
S-meter is calibrated on the WebSDR, we do NOT
run
the RTL-SDRs in AGC (Automatic
Gain Control)
mode. While doing so would allow the reception of weaker
signals,
the sensitivity would be necessarily reduced when a stronger signal
appeared, causing apparent "desense" and making very weak signals
appear and disappear as other signals came and went.
Originally
we had considered moving the 2 meter filter/amplifier to the base of
the tower, but since the CATV feedline and miscellaneous losses add up
to less than 2 dB - and because we are already bumping up against the
limitations of the signal dynamics of the RTL-SDRs anyway - there is
absolutely no point in doing so! If we were to figure out a
much
better-performance solution for 2 meter coverage than our RTL-SDRs
running at a 2 MHz bandwidth, we would look into this.
WebSDR
#4 outage:
We
seem to have inadvertently caused an outage of WebSDR #4 in which
several of the receivers had gone "deaf". We aren't sure what
happened, but it may have been related to our doing a "live" hard drive
back-up (via the
network) - and it's likely that it was in this state for
several hours. When we did
notice, we had to do a hard reboot (power
off/on) of the computer to restore operation of all of the
bands.
Addition
of the "?10hz" URL
parameter to "fix" an issue with "CatSync" compatibility:
It was brought to our attention
that the "CatSync"
program ceased to be compatible with the Northern Utah WebSDR when we
added the 1 Hz resolution to the frequency readout: It would
seem
that CatSync
may treat the
frequency as a string of text - expecting it to be of fixed length to
the right of the decimal place - rather than treating it as a number,
as I would do if I were doing similar programming.
To
remedy this, we have added the ability to add the "?10hz" parameter to
the URL when loading the WebSDR page to cause it to display in 10 Hz
steps. Here are some examples of how it
might be used:
In
our initial tests it appeared that CatSync behaved properly with this
modification - but we quickly discovered that CatSync itself did not
appear to be particularly stable (it
would crash frequently) and its operation caused it to
consume a tremendous amount of CPU resources.
We tried CatSync on several
different computers running Windows and found similar results (e.g. instability).
CatSync itself seems to use Chrome as the (built-in) browser
and we noticed that whatever CatSync is doing atop the browser, it seem
to take more CPU power to do than than run the browser itself, bringing
an older dual-core Intel computer to its knees, resulting in glitchy
audio, when we tried to use it on that machine.
Because
of the "crashing randomly" issue on a more capable Windows laptop, we
have yet to be able to test it when interfaced to a "real" radio, but
it would seem that adding the "?10hz" to the URL allowed CatSync to
properly parse it when we tried it on a virtual radio, indicating that
this parameter probably
restored compatibility - but further testing is needed.
We
walked the line - again:
As
noted below, a "nearby" power line noise that had intermittently caused
is problems was absent during the previous trip - as it was during the
first day of this one. On the second day, it was back, but it
wasn't until the evening that we were able to get some free time to
walk along the line.
As
during a previous visit, we believed that we'd narrowed down the source
of the noise - which is very strong on 2 meters - to a handful of
poles, but just as we were about to survey the last couple of poles
using both 2 meters and an ultrasonic receiver, the noise abruptly
stopped, putting an end to our quest.
Of
course, a few hours later -
after it had gotten dark - the noise was back!
We'll
come prepared to do more
noise-finding on future visits, but it seems as though it "knows" that
we are looking for it!
14-15 July, 2022:
Site visit, again:
Because
we still have the 110' (35 meter)
boom
lift on site, we continued work on antenna maintenance, concentrating
primarily on the sort of things that could be done ONLY
with the lift.
Work on the TCI-530
omnidirectional antenna:
A few years ago we noticed two
wires within a few inches of each other - but because they were about
85' (25 meters)
up and 4' (1.5 meters)
away from the tower (I
won't mention the issue of simply climbing the tower - see the 5
November, 2021 entry)
so we took the opportunity to tie the wire closer to the tower back,
using polyester rope, an insulator, and a piece of garden hose to
protect the rope. This should greatly reduce the probability
of
these two wire hitting each other in the event of high winds' setting
up vibrations.
For several hours the winds
were too high at the 85' (25
meter) level to permit working on the beam antenna so we
took some time to inspect the TCI-530 and found that lower down (at 20-50 feet, or 6-15 meters) -
where the winds were lower - there were several places were the
insulators had apparently "flipped" upside-down at the time of
installation, causing several instances were insulated sections at the
ends of active elements may have intermittent contact with guys, while
others were not touching metal, but the porcelain insulator was again a
guy line under point-source compression - the latter being deleterious
to that type of insulating material! With a bit of
strong-arming,
I was able to take up the tension of the wire element with one hand and
"flip" the insulator over with the other - something that required a
fair bit of dexterity and strength. I didn't keep count of
how
many insulators were like this, but I'm sure that it was between six
and ten that needed this sort of attention.
One
of these wires which was "flipped around" with metal-touching-metal was
slightly slack, meaning that there wasn't enough tension to hold it in
proper orientation. To prevent such metal-to-metal contact, a
simple insulator was constructed using PVC pipe to entrap the wires and
keep them separated. After installation, this plastic piece
was
given a few coats of dark green paint - because that's what we had!
Work
on the LP-1002 log periodic
beam antenna:
We
aren't sure when, exactly, this beam was installed, but it was
certainly within the 1973-1977 time frame - and it probably had not
seen much maintenance in that time - or certainly, not since the 1980s,
so it needed to be thoroughly inspected. Some of this
inspection
was done during the July 1-3 visit, but we did even more inspecting,
taking close notes on what pieces of hardware to get. The
missing
hardware is mostly 1/4-20 stainless nuts and washers, so it should be
easy to replaced.
An
inspection was also done on the "front" of the antenna and we observed
that the porcelain insulator where the center conductor of the feedline
emerges was somewhat damaged. While this would be of concern
if
we were operating the antenna anywhere near its rated power level, it's
fine for amateur power levels - if, of
course, we were to use this for transmitting - which we are not.
A liberal application of pigmented RTV (silicone)
should suffice in this repair. Similarly, an aluminum tube
used
to convey the power showed some slight mechanical damage - but since
it's being used only as a conductor, sealing and taping it should
suffice - plus, it's likely been like that for quite some time!
The
main goal was to work on this antenna's insulators. Used to
electrically isolate the elements from the boom, these fiberglass
sleeves also mechanically support the elements themselves and decades
of UV exposure and weather had caused them to become a bit "fuzzy" in
places. To address this, the fuzzy fiberglass was removed,
where
possible, using sandpaper - an absolutely miserable job as it causes
the massive shedding of tiny fiberglass particles. While
gloves
and a mask will protect one's hands and lungs, there is nothing that
will completely prevent these tiny particles from getting on the arms
and cause itching - something from which I'm still recovering at the
time of writing. Since, during much of this time, the
temperature
was around 100F (38C)
there's
a practical limit on how much one can cover up and still avoid
overheating! After several retreats due to weather (high wind, approaching storm,
etc.) during which we either worked on the TCI-530 or
other projects, the insulators were finally prepped for recoating.
For
recoating the antennas, we are using a two-part, epoxy-based coating
that is heavy in filler material, yet thin enough to penetrate loose
strands of fiberglass and be self-leveling. Because of the
temperature (well over
90F, 32F)
- and to extend the working life of this paint once it had been mixed
with its activator, we put it in an ice bath, in a drinks cooler.
This extended the working life from a few 10s of minutes to
hours
- which is a good thing since it took about 4-1/2 hours to do about 75%
of the elements, and to mix more paint required lowering the lift down
to the ground - and going back up and repositioning something that
takes about 15 minutes. We went through two "pots" of mixed
paint
do this in that time: The cooling worked very well, with the
paint only very slightly thickening after over 2 hours, by which time
the pot was empty, anyway.
Because
we finished only 75% of the elements, another trip will be required to
finish it - but we'll also have to sand down the first layer of paint
to remove some of the "hairs" of fiberglass and smooth the surface -
and then at least two more coats of the epoxy paint. After
that,
the insulators will need to be painted again
- this time to coat the epoxy with UV-protecting paint. When
all
is said and done, we'll have probably used about $350 of the two types
of paint to do this job!
Testing
done on WebSDR #4:
While
on site, we were curious as to how many SDRPlay receivers could be run
on our 4-port USB 3 plug-in card. While were were hoping that
answer would be "four", it turns out that the real
answer is ONE owing to the fact that the SDRPlay uses a special
transfer mode - and it seems that many USB chipsets only support a
single device at a time that can use that mode.
More
searching for powerline
noise:
During
the July 1-3 trip, we walked the power line, finding 4-5 suspect poles,
but since RF traverses wires, it was rather difficult to diving which
poles seemed to be causing the majority of the noise.
While
we had an ultrasonic receiver with us, the electret microphone just
wasn't terribly sensitive in the region above 25 kHz. In the
meantime, I was able to get a MEMS microphone element that was
specified to be useful to at least 80 kHz and testing showed a dramatic
improvement. This new element was fitted to the parabolic
reflector and I arrived on site hoping to identify the pole - and maybe
even the insulator or hardware - responsible for the racket.
As Murphy so often does, the
noise - which had been very high even on 2 meters and had been bad on
many of the HF bands - was completely
absent. This wasn't actually too surprising as noises come
and go, depending on recent rain (or
lack of it),
wind, etc. - but it is still annoying when your attempts to identify a
problem is thwarted by Murphy. Of course, once we are away
from
the site, it will reappear with a vengeance!
While
the "really bad" source of noise was gone, we turned our attention to a
long-term noise source that seems to hover around 2.2-2.5 MHz - along
with its harmonics - that will sometimes degrade receiver sensitivity
on 60 and 30 meters. While we were unable to locate a point
source of noise, we think
we identified the direction that we might need to follow the power
lines on a future visit - which will apparently take them over a small
mountain and down, somewhere, on the other side. What we have
determined is that this long-term source of noise is very likely
several miles/km away - and NOT
line-of-sight!
Power
line noise:
Even
though we were prepared to walk the power line to try to locate a
nearby source of noise that we were trying to find during an earlier
visit, it was completely quiet this time.
Still
more to do:
As noted above, we
will need to work on painting the beam's insulators - and we will be
sure to bring the DF noise gear (HF,
2 meter, ultrasonic) on the next visit in the hopes that
we can nail down a pole number.
We
also have other projects in the works - including moving the 2 and 6
meter antennas away from the building with the computers and onto the
tower, which should both elevate them above the local terrain and
better-isolate them from the computer-generated noise in the building.
11 July, 2022:
The Northern Utah WebSDR YouTube page!
We
are happy to announce the debut of a YouTube page for the Northern Utah
WebSDR. We are gradually building content, but at the moment
you
can view an aerial tour of the site - and there are several "how to"
videos related to the operation of the WebSDR - and more are on their
way!
We
have been recording videos and still photos of some of the activities
done during recent site visits and we'll eventually be posting these as
well.
To
go the Northern Utah WebSDR
YouTube page, go HERE.
6 July, 2022:
Network outage:
Early
in the morning - around
0100 - the upstream carrier (Utopia)
that feeds that ISP used by the Northern Utah WebSDR
had (yet!)
another outage - pretty much identical in its manifestation as the one
that occurred on July 2/3, noted below in the 1-3 July entry.
Initially,
the carrier blamed the outage on "misconfiguration of routing on part
of the customer" - but then several of this carrier's customers, all of
whom were experiencing an outage, got together and compared notes,
discovering that the carrier's explanation simply didn't wash.
After a bit of collective pressing by the group of customers
demanding a plausible explanation it was revealed that the cause was
actually due to very old network gear, well past its replacement date,
experiencing yet another hardware failure. Apparently, parts
for
this old gear are getting sparse and unless the carrier makes some
upgrades, this problem is likely to recur.
1-3 July, 2022:
Site visit:
Over
another 2.5 day period,
more work was done at the Northern Utah WebSDR remote receive site,
including:
Finalized lightning protection:
There
were a few minor details to finish in the new entry panel:
The
lighting protection module on the feed from the TCI-530 omni antenna
had UHF connectors rather than "N" type
and adapters had been required to interface to the existing
cabling. The arrestor's connectors were changed and the gas
discharge tube was replaced with a lower-voltage (75 volt) unit to
better-reflect
its receive-only role.
Network
upgrade:
Continuing
with work started last time in which the on-site network gear was being
replaced or upgraded, the final piece - a managed switch - was
installed. This required an outage of the receive site, as
you
can imagine, as servers had to be disconnected from the old and
connected to the new.
This
upgrade offers additional capability to detect and act upon potential
attacks to the network to which the WebSDRs are connected: In
most cases, such events will simply result in the sources of such
activity "going away" from the standpoint of the network.
Comment:
Late Saturday night/Sunday morning, there was an outage
caused by the upstream network provider (Utopia) that broke
connectivity to the WebSDR site, lasting about an hour: We
had nothing to do with that outage!
Work
on the power and UPS system:
Work
was done on the power system and UPS - this, to finalize what had been
started last time when batteries were replaced and things were
reconfigured. This, too, resulted in several complete system
outages as it was necessary to interrupt power.
It had been noticed recently
that our transfer switch (a
relay that switches between an "A" and "B" power source, to allow work
to be done on the UPS without dumping the load - or it could permit the
use of two
UPSs) was "chattering" when the UPS tried to switch over,
occasionally causing the loads (servers)
to drop. Investigation showed that a surge
suppressor/harmonic
filter seemed to be causing the output of the UPS to drop briefly when
it switched online, causing the chattering. This behavior is
"new" in that it hadn't been happening before, although we haven't
changed
anything else - so we simply removed this harmonic filter in the
meantime, which seems to have solved the problem.
The voltage of the "bulk
charger" was adjusted downwards from 27.6 volts to 27.1 volts (equal to 13.55 volts for a 12
volt battery) which is a known-good compromise between
full charge of a battery bank and the loss of electrolyte with a higher
voltage.
We
also installed shunt regulators on each of the 6 volt batteries set to
6.82 volts. The job of these is to prevent any individual 6
volt
battery from drifting more than a few 10s of millivolts from 1/4th of
the system voltage which prevents chronic undercharge (which can lead to sulfation -
and overcharge of other batteries) or overvoltage (which will accelerate the loss
of electrolyte) as
the batteries inevitably drift with age. These shunt
regulators
are described here: http://ka7oei.blogspot.com/2019/10/shunt-regulation-of-series-connected.html
Maintenance
on the LP-1002 log
periodic beam antenna:
When
the log periodic beam antenna was brought online in April of 2020, it
was discovered that bird guano had dissolved some of the aluminum 1-5/8
feedline. At the time, a "temporary" connection to the
"bloody
stump" was made, involving hose clamps, flying wire lead, lots of
electrical tape, and a
kludged jumper.
A
few months after bringing the beam online we purchased a 1-5/8 EIA
flange to "N", but with the need to effect the repair at the 85' (26 meter)
level - and accessing this portion requires a bit of tricky maneuvering
at that height to reach the connector - caused us to put off this task..
We
decided to wait until we had a "man lift" of sufficient capability to
reach the antenna to allow this work to be done more easily,
conveniently, and safely. It wasn't until now that we had
access
to such a piece of equipment. This work was
complicated by
the fact that there was a mechanical problem with this lift (it couldn't be steered owing to
a problem with its tie rod) that had to be worked out
before we could use it - something that took much of a day to do.
The
new 1-5/8" EIA flange was successfully installed without incident,
removing the kludge that had been present for a bit over two
years. As you might expect, this resulted in the loss of the
RF
signal path for some time (a
bit over an hour) while this work was done - but this
would have affected only
signals being received by WebSDR #4 (Magenta).
With the signals restored, via
the new flange connector, it's possibly/likely that signals from the
beam will be slightly
improved. While we were at it, the VSWR was swept on the beam
and
it was found to be within specifications - but this was true before,
with the "kludge" connection in place - so any degradation that had
been caused by the old lash-up would likely have been minor.
While
we were at it, this nearly-50 year old antenna was given a reasonably
thorough visual inspection. Of particular interest was the
point
where the boom was attached to the top of the tower in that we wanted
to be sure that the aluminum plates had not started cracking due to
work-hardening caused by flexing in the wind for many
decades.
Aside from some hardware with surface rust, we saw nothing of concern.
We
did notice that a few smaller pieces of hardware seemed to be missing a
few nuts - but these were for fiberglass spacers that had plenty of
other screws (using #10
hardware) still
holding things into place. Finally, an inspection was done of
the
fiberglass insulators for the elements: While these are
getting
to be a bit "fuzzy" due to UV exposure, there was nothing remotely
threatening to their structural integrity: On a future visit
we'll need to apply some "gel coat" (of
the sort used on boats)
to these insulators.
Finally,
it was observed that one bolt was missing from one bracket of the
"torque triangle" at the top of the tower. Fortunately, we
found
a suitable replacement (a
1/2", 1" long galvanized bolt)
and installed it. Other than that, all of the guying hardware
on
the "tower" end of things seemed to be in excellent shape.
Power
line noise:
We
are well aware of the rise in amplitude of power line noise on some
bands which is undoubtedly a combination of the 50+ year old power line
hardware and the fact that with the shrinking Great Salt Lake due to
several decades of reduced precipitation, we get a lot of
partly-conductive wind-blown dust from the now-exposed salt pans that
causes "mud rain" that coats
everything.
While we had hoped to do
additional checking of hardware (using
VHF and ultrasonic gear)
we weren't able to do so as we had spent a lot of time getting the man
lift operational, instead. For future visits we'll be sure to
bring the noise-finding gear along in the hopes that we'll get time to
do more investigation.
17-19 June, 2022:
Site visit:
Over
a 2.5 day period, a lot of
work was done at the Northern Utah WebSDR remote receive site -
including:
UPS battery upgrade/replacement:
The
aging 100 amp-hour batteries that have served for a while were replaced
with higher-capacity and, more importantly, new batteries:
Four
220 aH 6 volt "Golf Cart" batteries in series, comprising a 24 DC
system.
One
issue had been the fact that the UPS, which is a 1kVa unit, would only
charge the battery at about an amp - if even that. Because
the
adage "when it rains, it pours" is true, this meant that we would
occasionally experience back-to-back power outages, each of significant
duration. With the slow battery charging, the total discharge
could accumulate and the battery could be depleted before it had a
chance to charge up. To remedy this, a 15 amp "bulk charger"
was
added to allow a faster recovery for such situations. Initial
testing has led us to think
that this charger is RF-quiet enough that it should be unnoticed - but
more testing is warranted.
The
new batteries are in their own boxes rather than just on the floor -
which is a good thing as the old batteries were sealed, but since these
are flooded cell, we don't want "weeping" of acid to attack the floor!
T-stakes around guy posts reset:
During
certain times of the year, the area with the antennas is full of cattle
- and if you have ever been around cattle, they will rub against
anything solid. For this - and other reasons - the deadmen (guy anchors)
on the TCI-530 Log Periodic Omni have a square area of barbed wire
around
them. Over the years, these have worked their way loose and
the
barbed wire has slid out of place, so a flurry of hammering with a post
pounder and some quality time with fence pliers and tie wire was spent
to restore these to something resembling their former splendor.
KiwiSDR
#4 back online:
"Something"
- we don't know what - happened to KiwiSDR #4. For some
reason,
it would spew out traffic that would cause problems with other
computers on site and occasionally consume inordinate bandwidth, so we
had to disable its LAN port on the switch. We don't know how
long
this problem had been happening, but logs indicate that it may have
been intermittently happening for weeks.
Making
the assumption that this device had been somehow compromised, it was
completely wiped and reconfigured as we just didn't have the
time (or
inclination) to figure out what was wrong - and risk
missing something if we'd tried to "fix" it.
GPS communal antenna distribution
installed:
A
"communal" GPS antenna was installed using a good-quality
commercial antenna (PCTEL
GPS-TMG-HR-26N) with built-in SAW filtering (+/-10 MHz) and 26
dB of amplification.
A custom power inserter and amplifier was constructed and
installed to power the antenna and boost its signal such that it could
immediately be split to each of the KiwiSDRs on site.
Because
it's cheap and "good enough", the new GPS signal plumbing uses
quad-shield
RG-6 TV cable and satellite-frequency splitters along with F female to
SMA male adapters.
This
system provides far better signals than what we had been using up to
now: The KiwiSDRs ship with a cheap, magnetic "puck" antenna (smaller antenna aperture and no
band-pass filtering) and
we'd simply "clonked" those onto the air conditioner. With
the
installation of the new entry panel and lightning protection, this was
no longer a practical (their
cables were too short) or a desired configuration, hence
the change.
"We walked the line":
For the first time since July,
2018, we took a walk along the power line corridor that (ultimately)
feeds power to the WebSDR site. As noted elsewhere in these
pages, the power lines will occasionally "noise up" - usually when "mud
rain" has recently fallen, a combination of rain and wind-blown
salt-laden dust from the now-exposed flats surrounding the (ever shrinking)
Great Salt Lake and adjacent water bodies - and these lines have been
occasionally noisy over the past few weeks.
A few years ago this was done
and a few serious problems were identified (broken guy lines,
obviously-broken or damaged insulators, etc.) and about 9
months later, a work crew spent a day or two addressing these and other
issues.
We
decided to re-walk the line, hoping to find a noise source that seems
to be concentrated around 2.5 MHz, 5 MHz, 7.5 MHz and higher
frequencies of this
interval and, as expected, the results were a bit ambiguous:
Because power line noises are typically produced by arcing,
they generate RF
- and because RF tends to follow conductors, which are also antennas,
this RF can be carried for significant distances along lines.
As
you might expect, this makes it a challenge to localize a noise source
as it can seem to be emanating from a number of places.
For
this task we were armed with an HF shielded loop, a VHF AM receiver
with a 3 element beam and
an ultrasonic receiver with parabolic reflector. For reasons
to
be determined, the ultrasonic didn't work quite as expected, but we are
able to get some "hits" on strong signals being radiated on VHF with
predominant vertical polarization implying an arc along the insulator
string.
This
work was complicated by the fact that this area - near salt marshes -
also has cattle on it which means that as we were walking along in
places, dense clouds of mosquitoes were kicked up - sometimes making it
difficult to see or breathe as they would swarm us. Despite
being
slathered with repellent, we did get quite a few bites despite wearing
long pants and loose-fitting, long-sleeved shirts.
While we have the ID number of
some suspect power poles, we should probably go back later (hopefully when the bugs are
attenuated a bit)
and do more investigating and hopefully, the ultrasonic receiver will
be more amenable to proper functioning to allow more definitive
identification.
Grounding/lightning
entry panel
completed:
During
the last site visit in May, we'd installed the entry panel box, and
covered/sealed what had been a haphazard cable entry, but only had been
able to run the original cables through
the box, but not properly ground them. This time, the
goal was to have EVERY
cable entering the building that carried a signal go through this box -
and through lightning protection.
This
new box has a copper back plane to which the lightning arrestors and
grounding blocks are attached. The box itself is bolted to
the
building - which, itself, is entirely metal and grounded with at least
five ground rods - plus there is a heavy ground wire that runs from the
nearest ground wire to the box - just in case.
The
key to effective lightning protection is a common-point ground as much
as is practical - and for the antennas, this is now the case:
All
RF/signal cables are now entering via this box.
Initial
testing indicates that we didn't create a nasty ground loop and "noise
up" any of the receive signal paths - but more testing needs to be done
to verify this fact.
14 June, 2022:
"Warble" issue on 20 meters on WebSDR #4 fixed.
It
was observed that "something" had gone amiss on WebSDR #4's 20 meter
receiver where there was a sort of strange warble. The issue
seems to have been that the hardware driver for that receiver had
somehow gotten out of sync, dropping audio samples. Signals
were
still intelligible (more
or less) but with annoying artifacts. A restart
of the receiver drivers (which
is most easily done by resetting ALL of them) fixed the
issue.
This
problem has been observed
with the newer receivers (the
SDRPlay) in that it seems to happen about once every three
months or so to one
of the receivers which means that it happens once every few "receiver
years" when you consider that we are using seven of these units.
We are looking into a means of automatically detecting this
occurance, but it is rare enough that we haven't really been able to
figure out how to do that.
2 June, 2022:
WebSDR record feature fixed.
Due
to an inadvertent bug (aren't most
bugs inadvertent?)
the "Record" feature had been broken since 28 May when the new code was
rolled out: This has been fixed!
31 May, 2022:
WebSDR offline for a few hours
On
this day an issue with a router/switch at the remote site caused
connectivity to the outside world to be lost. One of the
locals
visited the site, genuflected appropriately, and restored connectivity.
The cause of the drop-out is being investigated.
28 May, 2022:
Comments.
New
features rolled out to all
Northern Utah WebSDR servers.
On
this day the features that
had been being tested on WebSDR #3 (Blue)
were rolled to the other four Northern Utah WebSDR servers (e.g. #'s 1, 2, 4 and the "SLC
Metro" WebSDR). These features include:
Improved
"Notch2" filter.
This filter should more effectively - and quickly - notch
carriers, but as before it will not -
prevent receiver desense - "Notch1" is for
that.
Vari-Notch.
This is a manually-tunable notch filter that can be set to
notch
a fixed signal: Sliding the button to the far left will turn
it
off.
CW Peak
filter.
This is a moderate-Q band-pass filter that may be manually
tuned
to a specific pitch. This includes the "Ref Tone" button that
will activate a tone that is the same frequency as the filter to aid
adjustment.
Synchronous
AM detection.
The "SAM-U"
and "SAM-L"
buttons will synchronously decode the upper or lower sidebands (respectively) of
an AM signal - the status of this decoding being shown just below the
"Frequency" display when it is enabled. (See the "FAQ" under the section
"Features of the WebSDR")
Tuning
resolution has been
increased to 1 Hz. Natively, the WebSDR's tuning
steps are 31.25 Hz - but this allows steps as fine as 1 Hz to be
tuned. (See the "FAQ"
under the section "Features of the WebSDR")
Context-sensitive
frequency step
buttons. The tuning steps are now shown on the
buttons, and they change with mode as the tuning steps are altered
appropriately.
Audio
recordings now include
noise reduction. Previously, the audio
recordings did not
include the effects of the DSP noise reduction - but now they do!
It
is believed that these new features are fairly-well debugged, but there
is no guarantee of this - again, see the FAQ under the section
"Features of the WebSDR" for known limitations and quirks.
20
meter receiver on WebSDR #4 (Magenta)
reset. It
was found that this receiver was in some sort of mode where audio was
distorted: A reset of this receiver fixed the problem.
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
18 September, 2021: WebSDR site visit:
Work done:
Ground loops on LF receive path broken up: After
beefing up the grounding system last year, additional "noises" appeared
on the LF signal path - notably on the "2200 meter" receiver and on
KiwiSDRs 1-3 below about 350 kHz due to circulating currents on the
coaxial cables between the antenna and receiving gear. We finally
got around to breaking up these circulating currents by inserting
common-mode chokes in strategic locations.
Calibration checked:
Once again, the S-meters were checked, on each band, to verify that the
signal levels from the antenna correlated the S-meter readings:
They do, within a dB or so, indicating that nothing has drifted
significantly over the past (approximately) year.
2 meter receiver gain levels tweaked: The gain settings on the RTL-SDR receivers used for 2 meters were adjusted, improving overall sensitivity by 6-7dB.
UPS battery bank checked:
The UPS back-up batteries were checked for internal resistance and were
also load-tested and appear to be in good shape. The transfer
switch (used to switch to unprotected mains power if the output of the UPS fails, or the UPS needs to be disconnected for maintenance) was also tested and found found to be in good working order. (For reference, both batteries measured around "1.8" on the battery analyzer.)
Linear power supplies (attempted) installation: We had intended to swap out some switching supplies used to power the network gear with linear ones (made by Lambda)
- but this didn't go too well: Unexpectedly, neither supply
worked properly. We'll take them back and load test and repair
them as necessary. During this testing, it was necessary to
temporarily power down the network gear, causing the WebSDR to be
offline for 10 minutes or so.
RF subsystems swept: Using a VNA, the signal paths on HF were swept to characterize the filters and gain stages for later analysis.
Intermittent connection:
An intermittent connection affecting the 15 meter receiver on
WebSDR #1 was found and fixed. This intermittent was causing
occasional loss of sensitivity on this receiver (only).
RSP1a installed:
An SDRPlay RSP1a was installed on WebSDR #4, connected to the 20 meter
signal path to allow testing: For the time being, this receiver
has not been "commissioned" and will be configured remotely for
testing/evaluation of this hardware as a candidate for replacement for
the existing sound card based "High performance" receivers. While
this hardware is capable of up to 768 kHz of coverage at 14 bits of
depth, limitations built into current Linux distributions limit this
pipeline to just 192 kHz - an issue that we are looking into resolving.
Other comments:
Power line noise issues:
We are certainly aware that occasionally, there is noticeable
power line noise on some bands, which is not surprising considering the
fact that there has been only very occasional rain in the area coupled
with wind-blown dust that is likely to have trace amounts of salt and
other minerals coating everything. We do suspect that some of the
hardware has also degraded and we are hoping to "walk the line" with
the appropriate detection gear (HF, VHF, ultrasonic) as we did in July, 2018, where we identified several issues - most of which were (eventually) later fixed by the utility.
A series of unfortunate events for the pilot of a small airplane:
During the outside work (checking antenna signal levels)on
this day I was communicating via radio with the other person on
site: I was injecting a signal into the antenna system and he was
tuning in and recording the signal level reported by the
receiver. It was while doing this that I heard the very loud
sound of an engine seeming to originate from south and west
of the WebSDR site, over the nearby bird refuge, with a
"propeller-like" noise that struck me as being an
extremely noisy airboat - except that air boats aren't allowed in that
area of the bird refuge.
I mentioned this just a few minutes later upon re-entering the building whereupon
the other person on site commented that his amateur radio Handie-Talkie, which
was happened to be set to automatically monitor the old aviation emergency frequency
of 121.5 MHz, had just come to life with the "siren" sound of an ELT (Emergency Locater Transmitter).
The
"siren" sound had stopped just a few minutes later, just before I
returned to the building and together we heard what had turned into a
rapidly-weakening,
unmodulated carrier that started to fade away, and abruptly stop.
Since the deprecation of 121.5 MHz as the primary frequency
several years ago, its
use is primarily for localization (e.g. aiding searches on the ground with direction-finding gear)
and it operates at very low power - but the fact that we could hear it at all indicated that its source was quite
close. A few minutes later, an alert went out about a downed
aircraft, and we reported what we heard.
After a few hours, the
online report was updated and it stated that the pilot's aircraft had lost "rudder
authority" and had to ditch his Cessna in one of the nearby lakes within the bird refuge, about 2.3 miles (3.7km) away and
had since been plucked out of the drink with no/few injuries to himself
- although the same could not be said for the airplane: So yes, we did hear a plane go down and then hear its emergency signal!
17 September, 2021: WebSDR site visit and possible, intermittent outages:
A site visit is planned for Saturday, 18 September to perform routine maintenance on the WebSDR servers and RF infrastructure: Expect occasional outages on all servers during this day.
Among items on the list:
Check signal levels for degradation, do receiver
calibration, inspect antennas and guying, investigate/resolve
common-mode interference on LF receivers, check the UPS (power back-up) system, etc.
10 September, 2021: Updates.
Power failure at fiber interconnect.
At around 1905 MT on this day the Internet connection to the
WebSDR site went offline. A short time earlier, at the point
where the fiber "lands" for our ISP, the line voltage - normally at
about 240 volts, was reported to be 342 volts, causing a safety
disconnect to occur and for whatever reason, power to some of the key
routing gear was cut off - and this outage seems to have affected other
carriers in the area as well. For most customers of the ISP,
there is an alternate route, but for various technical reasons (having to do with fixed IPs, routing, etc.) the WebSDR site cannot be rerouted at this time - a means of providing this is still a work in progress.
This
power failure - which was apparently weather-related - seems also to
have something to do with a fire in the area, probably due to many
downed power lines. It
would also seem that the fiber carrier itself was down in the area as
well, so it took more than just a restoration of electricity to
bring things back up to normal.
Connectivity restored: By
about 2020 MT or so, connectivity to the WebSDR site was
restored when connectivity to the fiber interconnect came back online.
For the first few hours, there appeared to be some issues related
to bandwidth - probably due to the fiber carriers' having other issues
as they brought things back online.
WebSDR site visit for 11 September postponed:
Unrelated to the above, the planned site visit to the WebSDR has
been postponed for now due to a sudden schedule conflict - and not only
that, the weather is predicted to be terrible, putting a damper on
planned outside work. Because there was nothing planned that was
particularly time-sensitive, the delay in the visit is of no real
concern.
3 September, 2021: Internet link stable - we hope!
If
you have been following things, you'll know that for the past week+,
there have been issues with connectivity of the Northern Utah WebSDR's
receiver site. Here's the story in a nutshell:
Almost
2 weeks ago now, an extremely strong storm front moved through Northern
Utah, and coincident with that, one of the "chains" on the our ISP's
backhaul- the one just before
the WebSDR site - went offline, halving its bandwidth. From the
diagnostics, it was not possible to determine if the problem was on the
the "receiving" end or the "transmitting" end in the direction on the
failed chain, so both available "shelf spares" - both of which having
been previously tested in the field - were put into service.
For
the first 15-20 hours or so, everything was fine, but then randomly,
the link would randomly lose signal integrity and would renegotiate -
sometimes at the desired, high bandwidth, but sometimes at a lower
bandwidth. During this renegotiation, connectivity on the entire
link would be momentarily lost and if it came back at a lower
bandwidth, traffic congestion would occur - the severity depending on
the link speed and the network loading. Unfortunately, the
diagnostic tools were, again, not very helpful and it was not possible
to determine which end of the radio link was having the issues.
Ideally, two more radios would be put into service, but anyone who is in this business knows that certain radios (including these)
have been in chronically short supply for the past year or so:
New radios were back-ordered 6-10 weeks and from prior experience,
finding a used radio on the surplus market - if one were available - is
a dicy prospect as there would be no guarantee that it was any good,
requiring several days of testing before installing it. Because both ends of this link are in difficult-to-access locations, replacing even one radio requires a bit of planning and coordination.
Because
the sorts of problems seen sometimes result from power distribution
issues - and the fact that the original failure may have been
lightning-induced - the power supplies, cabling and lightning
protection on both
ends of the link were replaced - but this didn't change the situation,
further pointing to a problem with one of the link radios - but again,
the diagnostics weren't much help in determining exactly which
radio had the issue. During this work, one of the dishes was
replaced with a higher-performance version - just in case the problem
was related to intermittent interference, but this had no discernible
effect, indicating that this was not likely to have been an issue.
In
the meantime, a set of suitable radios from a different manufacturer
were secured and after a rather difficult reconfiguration from their
previous use, were found to work and were undergoing testing.
Unfortunately, this other brand - while of similar data-carrying
capacity - was not compatible with the network management system, and
its configuration options were very limited - nevertheless, it was now
available as an option, but it would require two crews to
simultaneously work each end of the link to replace the gear to
minimize the duration of the outage that would result.
At
about the same time, a radio compatible with those in the ailing link
was finally located locally - but the caveat was that this had seen
some past service and its precise condition was unknown, although
testing seemed to indicate that it was usable. Last night (2 September) the radio on the "far" end of the problem link (one hop away from the WebSDR site)
was swapped out with the "new" one in the hopes that it was the
"problem radio" and since then, the link seems to be running clean,
despite showing a lower signal strength in one direction than the
previous radio. Nevertheless, it seemed to have suitable signal
for the type of modulation on the link (e.g. 1024 QAM) that would provide the needed bandwidth with a suitable safety margin.
The
stability of the link will continue to be monitored for the foreseeable
future, and we'll hope for the best. In the meantime, the "other"
pair of other-brand radios is still available, and efforts continue to
get more spares, despite the long supply delays.
We thank everyone for their patience and support during these problems!
26 August, 2021: Work continues to resolve Internet connectivity issues:
On
this day additional work was done on the "problem" link which has
hopefully improved connectivity: It is believed that the problem
has been identified, but additional work may be necessary in the near
future. Because of this work, there were several outages as
configuration changes were made.
Additional outages may occur as other changes are made - please be patient!
Update - 28 August, 2021: Progress
is being made to resolve the Internet connectivity issues, but
occasional drop-outs and slowdowns are still occurring pending time and
availability of gear.
20 August, 2021: Internet connectivity issues.
If
you had been watching Utah weather recently, you may have noticed that
there was some severe weather in Northern Utah - both wind and
rain. Apparently, one of the wireless links providing Internet
connectivity to the Northern Utah WebSDR suffered some sort of damage,
causing a significant loss of signal margin, reducing overall link
bandwidth.
The result of this has
been that connectivity to the Northern Utah WebSDR's receive site has
suffered degradation, causing occasional audio drop-outs, slow loading,
freezing of the waterfall, etc.
Update:
Repair work is underway as of the morning of Saturday, 21 August.
Expect intermittent outages as equipment is replaced/adjusted/diagnosed.
29 July, 2021: Site work - repairs:
KiwiSDR 1-3 power supply modified:
The redundant DC power supply for KiwiSDRs 1-3 has been prone to
"crowbar" randomly, likely due to the fact that their output voltages
had been increased to overcome the 0.65 volt "diode drop" of the
"diode-OR" array used to provide redundancy. The original silicon
diodes were replaced with Shottky, reducing the drop from 0.65 volts to
around 0.35 volts, also allowing the power supplies voltages to be
reduced by 0.3 volts. Hopefully this will reduce the propensity
toward random crowbar events!
6 Meter antenna repaired:
Several weeks ago the 6 meter antenna was damaged - likely during
a wind storm. The failure was likely related to "work hardening"
of the copper near the antenna base - related to the fact that it had
been outside for the better part of 20 years.
Back on "commercial" power: At some point during the past week the utility feed was switched back to commercial power (see the 14 July, 2021 entry, below) and the very large, multi-megawatt generator-trailer was now absent.
27 July, 2021: WebSDR offline for several hours:
For whatever reason (glitch, lightning, software SNAFU, phase of moon)
one of the routers on site managed to get itself in a state where it
would stop passing traffic for a while. At some point it seemed
to nearly straighten itself out
and resumes passing traffic, albeit very slowly and unreliably.
This persisted for about two hours, starting at around 1652 MDT and
eventually (after getting somewhere with Internet)
our network manager was able to log into the router and remotely reboot
it and from what we can tell, it has been behaving itself since.
14 July, 2021: Power failure
The
power went out with a bang at about 1135 MDT today, apparently due to a
catastrophic failure of a voltage regulator at the substation about a
half mile (1 km) away at a compressor/pumping station.
The on-site UPS carried the load of the WebSDR and its servers (about 650 watts)
for about 90 minutes before depleting the batteries. A generator
was brought to the site and power temporarily restored around 1420 MDT.
A
chat with the line crew indicated that another voltage regulator was on
its way, with an ETA of around 1600 MDT - but no estimate was given on
how long it would take to get it fitted and power restored. The
good news is that this substation powers "critical infrastructure" and
that when it's back online, the power to the WebSDR site should soon
follow - but since the WebSDR itself is not considered to be critical infrastructure, priority will be given to getting the primary customer back online.
UPDATE - 22 July, 2021:
It
would appear that instead of replacing the failed gear, it will be
necessary to do a major ujpgrade at the nearby substation, at the
pipeline. After a day or so of "temporary" power restoration
where the power company was able to get a single phase energized (fortunately, the one that the WebSDR is on) until a very large, multi-megawat generator-trailer was brought in to power the pumping station.
Fortunately,
they were kind enough to connect the WebSDR site to their generator, so
it can be said that the WebSDR site has, in fact, been on generator for
about a week!
The current plan is that the new, updated switchgear at the substation is to be installed this coming weekend.
20 June, 2021: Issues with the 12 and 6 meter receivers.
12 meter receiver:
There is an ongoing problem with the 12 meter receiver (on WebSDR #2 - Green)
in that the frequency stability control is not functioning, and the
gain settings are incorrect. While the receiver is generally
usable, it appears to be very susceptible to overload, and the
frequency will likely be only within 100-ish Hz of nominal.
Again, this will be addressed during the next site visit.
6 meter antenna broken:
It would appear that the 6 meter receiver's antenna (a full-sized J-pole)
has suffered mechanical failure - the top half or so breaking off,
likely due to metal fatigue. As a result, the effective receive
sensitivity will be reduced. This, too, will have to wait for a
site visit to effect a repair.
17 June, 2021: Comments
Tweaks on the 12 meter receiver:
As
noted previously, the processor on the 12 meter receiver would,
apparently due to temperature, stop "talking" on the USB port,
preventing temperature-based frequency compensation. Initially,
the "fix" was to simply switch receivers, but this was later revised.
Instead
of switching the receiver, the processor from another receiver was
swapped with the "old" 12 meter receiver. This was done because
the already-constructed frequency versus temperature compensation
information was specific to the "old" receiver - that is, it's local
oscillator, being unique in its temperature characteristics, wouldn't
necessarily match the "new" one.
By swapping the processor, we (think that we)
can mantain communications with the "old" 12 meter receiver hardware,
but because we kept the original 12 meter receiver hardware, the
temperature compensation info was preserved.
NOTE:
For reasons not understood, the signal level calibrations on the 12
meter receiver are incorrect, resulting in a higher-than-expected
S-meter reading and a "brighter" waterfall. This will be
corrected during the next site visit.
17 meter receiver interrupted:
A
user noted that the 17 meter receiver on WebSDR2 was deaf. Upon
investigating, it was noted that somehow, it had gotten switched from a
17 meter frequency to a 40 meter frequency and because there is a
band-pass filter just for 17 meters, no signals could be seen at
all. Fortunately, we were able to remotely tune the receiver back
onto the proper frequency, restoring operation.
8 June, 2021: Comments.
12 meter receiver changes:
As
noted in the 9 December, 2020 entry, we have applied temperature-based
frequency stabilization to the receivers that have been observed to
drift a bit across the temperature extremes (20F to 120F, -7C to 49C) and this has been working well, but it was noticed that at higher temperatures (above about 90F, 32C)
the USB interface on the 12 Meter receiver on WebSDR #2 would stop
communicating. The suspicion is that the USB port on the receiver
- which is implemented via a "bit-banged" interface on an Atmel AT-Tiny
- is suffering from frequency drift as that processor is using its
built-in clock - which is subject to temperature-related drift - rather
than an external crystal - mainly because this device has only 8 pins
and they are all being used for I/O. Because of this, above this
temperature, temperature-based frequency control failed.
As
a work-around, we moved to a "spare" receiver, but as a consequence the
previous frequency/temperature tables are now invalid and will have to
be rebuilt over time via observation. The change of hardware also
means that image rejection and gain parameters - which had been
calibrated to the "old" receiver, are now invalid and will have to be
re-done.
KiwiSDRs 1-3 offline for a while:
It was (finally)
noticed that KiwiSDRs 1-3 were offline earlier today.
Investigation revealed that the common power supply consisting of a
pair of two diode-paralleled 3 amp, 5 volt linear supplies had gone
offline with both "halves" of the power supply having gone into
over-voltage protection (e.g. "crowbarred").
This has happened before and it was likely a result of a severe spike
on the mains power or, more likely, a nearby lightning strike.
Simply power-cycling the supply restored operation.
16 May, 2021: Brief WebSDR outage and severe static due to locally-intense spring thunderstorms.
It
was reported by our ISP that one of the buildings at a location housing
one of their mains sites took a direct lightning strike, causing their
network gear to reboot, impacting the WebSDR's connectivity for a few
minutes: Other than some non-essential monitoring equipment (a remote voltmeter monitoring the mains power),
everything seems to come up normally again. A site inspection
will occur soon to check for hidden damage and make sure things are as
they should be.
This
same site was rebuilt and upgraded in the past few weeks - including
the addition of better grounding, bonding, AC mains conditioning and
lighting protection - and it seems to have just paid for itself several
times over!
Meanwhile, at the WebSDR site, it was surrounded on all sides by lots of scary lightning (very very frightening!) making most of the LF, MF and HF receivers pretty much unusable in the short-term due to the very high static and noise level.
With the thunderstormstorm accompanied by precipitation, the rain static on WebSDR #4 (magenta) has been intermittently extreme - because physics!
12 May, 2021: WebSDR outages to become less frequent:
The
majority of the work to upgrade network infrastructure being conducted
by our ISP is nearing completion. With the vast majority of new
equipment installed and configured and cut-overs completed, it is
expected that there will be no more lengthy outages.
As the final stages up upgrades are completed and network reconfiguration is done, additional, brief outages are likely.
7 May, 2021: WebSDR outage due to upgrades.
On
this day - beginning around 10 AM - the connectivity to the remote
receiver site of the Northern Utah WebSDR was lost as upgrades by our
ISP continued. Today's work includes the installation of and
cutting over to a new 10 Gbps link at one of the main distribution
points.
While
most of the ISPs customers were routed to an alternate path, the
current network configuration does not allow such re-routing of
customers - such as the WebSDR's remote site - with fixed IP addresses.
In
the near futre, some of these same network upgrades will allow the
implementation of redundancy of the WebSDR's receiver site that
is currently not possible.
Continued to watch this page for updates.
3 May, 2021: WebSDR outages to occur.
Starting 3 May, 2021
expect one or more outages of signficant duration while significant
infrastructure upgrades are undertaken by our Internet Service
Provider. The upgrades include adding overall capacity and
increasing options for redundancy - all of which should improve
performance to the WebSDR and other customers.
30 April, 2021: Comment on audio "warble", clicking or stuttering when using the Chrome browser or its derivatives:
In March/April an update of the CHROME
browser was rolled out - apparently with some sort of bug: This
bug seems to affect Windows-based systems more than IOS/Apple.
The problem appears to be one related to audio samples from the WebSDR
- processed by the Javascript interpreter in the browser - are not
being fed properly to the sound card, being dropped and/or repeated (e.g. stuttering).
The result of this is what has been described as a "warble" when
listening to CW or other modes in which one is hearing a tone from a
transmitted signal - which can include SSTV or digital modes like FT-8,
FT-4 and PSK31.
Problems caused by this can include:
Disruption/distraction in copying Morse code.
Corruption of a digital signal: This can make copying of FT-8, FT-4, PSK31 or SSTV signals problematic.
In severe cases, one can hear odd stuttering on SSB or AM signals - and possibly odd clicking.
Work-arounds:
DO NOT use Chrome browser - or browsers based on it.
The use of Firefox or its related browsers (e.g. SeaMonkey, Pale Moon) is suggested as they do NOT seem to be affected by this problem.
If you are using Chrome, don't open any more tabs/windows in the browser than absolutely necessary.
Avoid, as much as possible, the use of other programs while using Chrome to listen to a WebSDR.
This bug has reportedly been identified and a fix is in consideration for future versions of the Chrome browser.
10 April, 2021: Scheduled service interruptions.
Infrastructure upgrade: There
was a scheduled outage window that started between 8 PM and midnight
and could have persisted for up to six hours after the start. The
reason for this outage was the complete overhaul of one of the main
connectivity points by our ISP in which (much of)
the equipment was replaced. Because of physical and practical
limitations, the old gear had to be removed prior to the new gear being
put into place and connected rather than a simple "cut over".
This
upgrade should further-improve connectivity and reliability of the
Northern Utah WebSDRs - particularly as future upgrades by our ISP
continue to be rolled out.
18 February, 2021: Scheduled service interruptions.
Firmware upgrade:
In the early morning of 18 February, the connectivity to the receivers
at the Northern Utah WebSDR was interrupted to update firmware on
network gear. This outage lasted roughly 5 minutes.
Maximum users on WebSDR #1 increased: WebSDR #1 (Yellow)
was also restarted to effect a configuration change that increased the
maximum number of users from 150 to 200 as this limit had been observed
to have been reached on several occasions.
27 January, 2021: Service interruptions.
One
of the upstream Internet service providers has been having utility
power issues, reportedly causing one or more service outages.
They are continuing to experience issues, but repairs are underway.
24 January, 2021: Comments.
Maximum number of users on WebSDR #1 increased: It was noted that the number of users on WebSDR #1 (Yellow)
- which had been set to 125 - was being reached during peak
hours. During the very early hours on this day this number was
increased to 150 - a task that required restarting the WebSDR service
which, unfortunately, inconvenienced about 50 users at the time: Sorry about that - but there's really no other way to make this type of change.
Alternate servers: It's worth noting that if you encounter a "full" WebSDR server at Northern Utah, you have several options:
For 80 meters: If WebSDR #1 is full, try WebSDR #3(Blue).
It's receiver's performance isn't quite as good as #1 even though it
uses the same antenna, but it would be fine in most situations.
For 40 meters: If WebSDR #1 is full, try WebSDR #3(Blue) for the same, omni antenna - or you might try WebSDR #4(Magenta) for a high-performance receiver on an east-pointing beam.
For 20 meters: If either WebSDR #2(Blue) or WebSDR #4(Magenta) is full, try the "other" receiver: WebSDR #2 uses the omni antenna and WebSDR #4 uses the east-pointing beam.
WebSDR outages due to network infrastructure:
There were several outages on this day due to upgrades to the equipment
on part of our Internet Service provider to improve performance and
reliability. The duration of these outages was minimized as much
as practical.
13 December, 2020: Frequency stabilization code tweaked to
correct for sample rate errors.
After a few days of
operation and tweaking of values, I observed that the frequency drift
had been minimized - but I noticed something else: An odd
frequency offset on the "40PH" receiver on WebSDR #1.
The problem was tracked down
to the sample rate of this receiver being about 50 Hz below the nominal
192 kHz, causing about a 25 Hz error at the band edges, becoming
proportionally less toward the center where it became zero.
The solution was the
addition of some code that applies a correction to the RF frequency to
which a user's virtual receiver is tuned. This correction factor
has been applied to WebSDR #1's "40PH" and I will apply these to other
receivers as necessary.
9 December, 2020: Frequency stabilization measures applied.
On this day, frequency
stabilization measures were applied to the "FifiSDR" and the "Softrock
Ensemble" receivers as they have been observed to drift several 10s of
Hz over the wide temperature range in the unheated/uncooled building
containing the WebSDR's receive equipment.
These devices use the
Si570 synthesizer as their frequency source and thus do not
have a means of temperature compensation, nor can an external frequency
reference (oven-based oscillator,
GPS frequency reference) be directly applied to them.
This system works by reading
the internal temperature of the WebSDR building and looking up the
appropriate local oscillator frequency for that temperature in a table
and applying it to the appropriate receiver with a temperature
resolution of 1
degree Fahrenheit and a frequency resolution of 1 Hz.
Such frequency corrections
are applied at the beginning
of every minute that is divisible
by four(e.g. 0, 4, 8, 12...)
This timing was chosen to avoid degradation of reception of data modes
that might be
adversely affected by a frequency shift during the transmit/receive
period - specifically WSPR, FT-8 and FT-4.
The magnitude of frequency
shift is typically 1 Hz - although with very rapid temperature swings (e.g. operation of the in-building heater
or air-conditioning) the frequency may be be changed in 3 Hz
steps at each four minute interval.
The possibility of an
on-site, precise, remotely-controlled signal generator has been
discussed. Were this done, a precise frequency would be generated
and measured by the receiver to determine the frequency offset.
If the current temperature-based frequency compensation method is
insufficient, we will revisit this possibility.
6 December, 2020: WebSDR outage
There was a loss of
connectivity to the Northern Utah WebSDR starting around 1313 MT,
persisting for about 80 minutes.
The cause was a disturbance
in the commercial power with severe voltage swings in a nearby town
in which one of the sites that provides Internet connectivity is
located.
5 December, 2020: VFO A/B feature added.
As suggested during the 2020
survey, A VFO A/B function has been added to the Northern Utah WebSDR
servers.
The A/B button swaps the frequency and
mode.
The A=B button copies the frequency and
mode of VFO A into VFO B
The B=A button copies the frequency and
mode of VFO B into VFO A
Just to the right of the
frequency entry bar, you will see which VFO is currently selected - and
to the right of this, in smaller font, is the frequency of the
secondary VFO (e.g. the one NOT
being used).
Please let us know if you
find any issues with this new feature - or with the WebSDRs in general
- via email at: sdrinfo@sdrutah.org
4 December, 2020: Comments about background noise.
Users of the Northern Utah
WebSDR may have noticed a somewhat elevated background noise
level. While some of this is due to the recently-increased solar
activity, some of it is power line related noise. Specifically,
noise on some of the higher bands (e.g.
20 meters) has increased somewhat.
A temporary increase in
noise at the Northern Utah WebSDR has occurred in the past - and at
least some of it is due to peculiarities of local weather and
geography. Located near the Great Salt Lake, the areas around the
lake are subjects to blowing dust and "mud rain" caused by wind blowing
across large areas of barren land exposed by the receding Great Salt
Lake. This blowing dust - and the the "mud rain" that often
accompanies brief rain storms - tends to coat everything outside -
including insulators on the power lines, causing leakage paths and
addition noise, not to mention exacerbating issues with marginal
hardware.
The result of this is often
the increase of power line noise, which can propagate for miles in some
cases.
Usually, much of this noise
will subside after a heavy rain storm or snow fall - but as of the time
of writing, there have not been any such storms for many months and the
noise is steadily increasing in the absence of a "washing event" to
clean dirty hardware.
Regardless of the noise
level, we plan to "walk" the power lines near the WebSDR server this
coming spring for a visual inspection and using portable radio and
ultrasonic receivers to divine possible hardware issues. We last
did this in July, 2018 and in the next 9 months, the power company did
fix the majority of the issues that we'd reported.
It's
worth noting that on the lower bands (160, 80, 60 and 40) the normal
band noise during the evenings will override local noise source.
Most of the noise source is
to the west
of the WebSDR site, so unless the station of interest is in that
direction at the WebSDR site, consider using the beam for 40, 20, 17,
15 and 10 meter reception as front-to-back ratio will likely reject
most of the local power line noise.
29 November, 2020: "Notch2" parameters adjusted on all
Northern Utah WebSDR servers:
On this day the internal
parameters for the "Notch2" DSP filter were adjusted to fix several
issues:
The notch filter was
overly aggressive on speech, sometimes causing audible distortion.
To improve its ability to
notch CW notes (e.g. carriers)
in the presence of noise and speech.
Remember:
"Notch1" operates at the
WebSDR server itself and is best used to attenuate a single strong tone or carriers
that may cause an S-meter deflection and receiver desense - but this
notch may "hunt" (e.g. appear to
turn on and off) in the presence of strong audio, particularly
on weaker tones.
"Notch2" operates on the
audio stream only
and cannot prevent S-meter desense, but it is more effective in the
presence of speech and noise and when the annoying tone is weaker, and
it is capable of notching out multiple tones at the same
time.
Please note that it may take several
seconds for the "Notch2" filter to become maximally effective on
weaker, background tones.
Because it's an automatic
notch filter, you should not use a notch filter on CW,
SSTV or any digital mode!
23 November, 2020: Adjustments made to WebSDR #4 and
comments about Power Line noise:
WebSDR #4 adjustments:
On this day adjustments
were made to the 15 meter and 10 meter
receiver signal paths on WebSDR #4: It is expected/hoped that
this should reduce the possibility that either of these receivers will
overload when the bands open.
Adjustments were made to
the AGC loop in the receive converters used for these two bands with
less signal being applied to the RTL-SDR receiver before the AGC action
takes place.
Additionally, the signal
level into
the AGC loop was reduced so that the "no signal" condition results in
less signal to the receivers, overall - but still more than enough to
"tickle" at least a few of the A/D bits. It is suspected that at
least part of this issue is a result of having adjusted the gain in
signal pathseveral months ago without revisiting the settings on these
two receivers.
It is suspected that there
may
be the possibility that the main amplifier in the overall signal path
is overloading - and if this is the case, it will be removed from the
system and the gain redistributed to remedy this, but doing so will
have to wait for more instances of "high signal level" conditions for
additional analysis and a subsequent opportunity to visit the site and
make the needed changes.
On a related note, two
RSP1a SDR receiver units have been ordered. These will be tested
and installed - in a receiver location yet to be determined - when we
are able to do so.
Power line noise:
It has been observed that
the power line noise has increased on some of the higher bands - namely
just below and into the 20 meter band. This increase seems to
have been related to an instanced of "mud rain" where wind-born dust
was deposted by precipitation onto everything in the area, making
leakage paths - and noise - more likely.
This noise is less
apparent on the beam antenna as the suspect power line noise source is
off the back side of it
In the past, this noise
has reduced once we have had some "clean" precipitation (rain, snow) to wash things
off. If this doesn't occur, we'll "walk the powerline" (again) and report our findings to
the power company. This was done about 2 years ago and the power
company did eventually make
repairs.
22 November, 2020: Overload conditions on the 15 and 10
meter receivers on WebSDR #4 during band openings.
With the gradual
reappearance of activity on the sun, the higher bands - namely those
above 20 meters - are starting to wake up, meaning that there are, at
times, many strong signals on the band.
Unfortunately - despite
having attempted an adjustment using test equipment in the absence of
such signals - it would appear that I didn't get the gain/knee
adjustments of the AGC circuits on the 15 and 10 meter receivers on
WebSDR #4 quite right, meaning that each of these receivers may be
prone to overload - and spurious signals - when many strong signals are
present. These receivers use RTL-SDR (V3) units - which have only
8 bits of digitization - and these are preceded by an AGC circuit with
at least three sets of interacting adjustments, and it would seem that
at least one of these need to be (ahem)
adjusted...
We are looking into several
possibilities to remedy this issue, including:
Adjusting the gain/knee
settings on the AGC circuitry.
Replacing the receivers
with other devices more suited to handling the expected signal levels,
such as the RSP1a.
I suspect that we'll do the
first in the immediate future and then work on doing the second item.
Left:
The trench being dug. The soil on site is packed hard with roots,
but when broken up is very light and dusty so "sanding" the trench
wasn't required. Right: The trench dug -
about 147 feet (47 meters) in
length.- with the cables in the process of being laid, and the trench
filled back in as we proceeded.
Fortunately, even though cold - it was sunny and calm when we did the
majority of the outside work. The beam is that just
left of center while the omni antenna can be seen in the background,
near the left edge. Once the trench was closed we walked along
its length, first packing the dirt and pulling more into the slot and
then driving over it with a vehicle. Click
on the image for a larger version.
12 November, 2020: New coaxial
cable runs installed and other site work:
Such work at the Northern Utah WebSDR is
made possible by the kind donations of its many users - thanks!
Coaxial cable runs installed:
On
this day, three of us showed up on site, towing a Ditch Witch that was
used to open a trench between the tower with the beam antenna and the
building. Into this trench we put six runs of 1/2" jacketed
aluminum CATV hardline, representing a bit short of 900' of cable.
These
runs replace what we had been using up to this point which was a
constant maintenance issue: A run of "Siamese" (dual)
RG-6 cable that had been laid on the ground. Over the last couple
of years, we've had to replace this run a couple of times as weather,
the hooves of cattle and the occasional vehicle driving over it has
damaged it.
Even
though this cable is 75 ohm, this "mismatch" is pretty much irrelevant
in a receive-only application (most
receivers' input VSWR is pretty high at 50 ohms, so a mismatch isn't an
issue!), it is low loss (on
par with 1/2" "Heliax")
and it is quite rugged. Even though we don't have specific
applications for all six runs in mind, this will give us several spares
and room to grow in the future.
The
measured reduction
in losses upon switching to the lower-loss cable is
about 1 dB on 40 meters and about 3dB on 10 meters, but because there
is amplification at the base of the tower at the far end of the
feedline, this loss would affect only S-meter
calibration and not actual receiver noise performance.
6
and 2 meter receive performance improved:
Several
months ago, KiwiSDRs #4 and #5 were installed to allow reception on the
beam antenna - but this had a known-likely side-effect:
Degradation of 6 and 2 meter reception. As it happens, by
themselves,
the KiwiSDRs generate a bit of noise on VHF - including 6 and 2
meters. We hadintended
to resolve this issue during the past several visits, but we either
forgot to bring the material to do so or simply forgot to do it!
The
"fix" was to apply ferrites to the GPS, antenna and Ethernet lines
connected to the KiwiSDRs. At these frequencies, reasonable-size
snap-on ferrite devices actually can work as expected
- particularly if several turnsn of the conductors are passed through
the ferrite device to (exponentially!)
increase the inductance.
These
modifications have significantly reduced the amount of noise and the
number of spurious signals seen on the 6 and 2 meter bands: A bit
of low-level QRM is still present, but it's quite close to the noise
floor. Because many of the repeaters to which users might listen
are 80+ miles (128+ km)
distant, they are already quite weak meaning that receive system
improvements will be more likely to be noitced.
In
the future (probably the spring)
we plan to move the 6 and 2 meter receive antennas to the tower with
the beam, utilizing some of the new coax runs that were
installed. This will not only increase the height of these
antennas a bit, but it will move them away from interference sources -
namely, the computers in the building and the powerline.
28 October, 2020: Internet
outages related to upgrades:
You
may recall several months ago when one of the
connecting sites experienced more rodent-related interruptions:
It would seem that if they are hungry enough, they will knaw on about
anything.
The
vulnerable cables are now in conduit - hopefully now safe from any sort
of rodentia - a process that required the rerouting/replacing of a few
bits of cabling and several outages of that remote site.
7 October, 2020: Brief
Internet interruptions:
Over the past day or so, we have experienced several brief (two minutes or less)
interruptions of Internet connectivity. The cause of this outage
is unknown as it is occurring on the fiber backhaul that feeds our ISP,
apparently affecting surrounding communities as well. We are told
by that provider that they are "looking into it."
Just
above the waterfall there is the box marked "Allow keyboard" and if
checked, keyboard shortcuts will be displayed to do many of the WebSDR
functions.
To
this list has been added the ability to mute/unmute the audio using the
"m" key. One may either
hit the "m" key again, or
toggle the "mute" check box to un-mute.
An on-screen indicator that the
audio is muted - whether you use the check box or the "m" key - appears to the right of the
frequency entry and mode display indicator, just below the waterfall.
If
you mute the audio on your computer/browser, the "Audio muted"
indicator will NOT display as the WebSDR
cannot "know" that you have done so.
Remember:
The "m" key will mute audio only
if the "Allow keyboard" box is checked.
Two photos of the new guy wire anchors being
installed to replace the deteriorating underground anchors. Left: Setting up to drive the
pipe into the ground. Right: One anchor done
- one more to go! Click
on either image for a larger version.
On
this day a work crew arrived to replace the original guy anchors for
the 80' tower with the LP-1002 Log Periodic beam antenna. As
noted in the 9 September
entry, there was evidence that the guys had slackened somewhat and
investigation revealed that the Southeast guy had pulled out of the
ground a few inches. Knowing that the "twin" of this same tower
had fallen about a dozen years ago - probably due to a failed guy
anchor - we were intent on not allowing the same fate to
befall this tower!
Rather
than excavate a huge hole to fill with concrete and steel, this anchor
consists of a long, very thick-walled piece of pipe driven deep into
the ground at an angle - and this pipe is belayed by another pipe,
some distance behind it. To install these, a pile
driver is used to pound them into the ground - a process that takes
some time.
Both
the Southeast and Southwest anchors were replaced in this manner.
With this work complete, all three guy anchors have been replaced - the
North anchor having been done in June, 2018.
We
are looking into applying passive cathodic protection to the new
anchors to maximize their lifetime.
As
it happened, the RF feed from the beam went dead at about the same time
a welder was fired up. The cause was determined to be a loose RF
connector that hadn't been properly tightened (e.g. "finger tight and a bit more")
on a previous visit: My bad - sorry! No
doubt that it would have "flaked out" on its own, eventually!
Select photos of this work will follow
shortly.
It
is because of the kind donations by many users of the Northern Utah
WebSDR that we are able to do critical maintenance projects like this!
19 September, 2020: Site visit
The
Northern Utah WebSDR receive site was visited today to take care of
several issues:
Sticking transfer relay.
It appeared earlier that the "delayed-on" feature of the transfer
relay used to feed the output of the UPS to the critical gear wasn't
working - possibly due to a smaller relay driving the
contactor's coil having stuck closed. It was observed during the
visit that the relay was working properly, but just in case, an R/C
snubber network was wired across the contacts of the smaller
relay to suppress the high voltage arc that can occur when it opens on
the peak of an AC cycle and with the back EMF of the collapsing coil of
the contactor. Doing this necessitated taking the entire site
down as
this is
the path for the "critical power". This outage occurred
between approximately 1400-1445 MDT.
This
"transfer relay" is used to allow us to work on the UPS without
interrupting the power to the equipment. In short, if the UPS
power goes away, power is transferred to another source - typically
from an ordinary outlet, which would maintain power if the UPS's output
were to go away - but it could also be a second UPS.
Reconfiguration of the signal path for the
LP-1002 beam.
I
had never been happy with the way the gain balance had been set up when
WebSDR #4 was put online. Because this antenna has significantly
more gain than the omni, the signal dynamics are also different -
particularly with respect to very high-power shortwave broadcast
stations. Soon after installing WebSDR #4 it was immediately
apparent that I could not simply replicate what was done on the TCI-530
for WebSDRs 1-3.
One
of the problems was that there weren't enough RF amplifiers to go
around at the time that WebSDR #4 was put online. At the base of
the tower, there is an amplifier that is
capable of handling any signal that we are likely to get, making up for
the loss of the cable between there and the building. This signal
(eventually) is fed
to the band splitters in the receiver rack where the signal is split -
one path going to the "wideband" receivers (like the KiwiSDRs)
and the other going to the individual band filters. This second
path has an "above 9 MHz" split that goes from the "low split" to
another diplexer splitter (the "high split") that provides feeds for
the 30, 20, 17, 15, 12 and 10 meter bands.
Originally,
I thought that I could get away with putting an amplifier between the
low and high split - but I was wrong: At certain times of the
day, even this very robust amplifier would occasionally overload on the
myriad signals from 1.8-30 MHz - particularly in the evenings with very
strong 49, 41, 31 and 25 meter SWBC signals. When this amplifier
overloaded, all receivers downstream were degraded.
The
"fix" was to build more amplifiers, so I built another module that
contains three amplifiers that are capable of handling very strong
signals. The amplifier between the low
and high split modules was removed and individual amplifiers were
placed on the (filtered) band
outputs that feed each receiver. By strongly limiting the amount
of HF spectrum any individual amplifier might see, the probability of
overload is reduced - and if one amplifier does overload,
it won't
affect other bands.
KiwiSDRs
4 and 5 are also fed from this same signal path via the wideband split
mentioned above. To prevent these receives from overloading, a
"stronger" pre-emphasizing filter (similar
to a "high pass shelf") was implemented, reducing signals at
lower frequencies even more while leaving higher frequencies (e.g. above 20 MHz) pretty much
alone.
Following
the pre-emphasis filter mentioned above, an RF amplifier was placed
that allows, for the first time, KiwiSDRs 4 and 5 to hear the 10 meter
noise floor under "dead band" conditions. This was not possible
before because sufficient gain to allow this resulted in the KiwiSDRs
being overloaded by lower-frequency signals during the same high-signal
times that were
overloading WebSDR #4's signal path.
Because
of the change in configuration, the S meters for WebSDR #4 were
recalibrated to indicate the signal levels at the antenna terminals.
17 September, 2020:
"Disturbances in the force"
At
around 0830 UTC, WebSDR #2 went offline for reasons not entirely clear.
At a bit after 1400 UTC - morning - its WebSDR service was
restarted and everything looked normal.
At
around 1030 MDT several of the WebSDR servers unexpectedly went
offline. A quick check of the network indicated that the inbound
pipe to the WebSDR receive site was saturated by the WebSDR servers
downloading updates. Apparently a number of "extremely critical"
updates have been pushed out to fix one or more "Zero Day" exploits
across a variety of operating systems: We aren't sure of the
details at the moment, but it appears to be affecting all types of
services and platforms so one can expect it to make the news.
After
the updates completed, the WebSDR servers came back online without
intervention having apparently needed to disable their Ethernet
connections for a while in order to complete the updates. Unlike
some other operating systems, they did not need to reboot to do
critical updates.
16 September, 2020: Regional
power outage
At
about 0018 MDT, the power went off at the WebSDR receive site - and in
many of the surrounding northern Utah communities. The UPS
battery bank lasted about 2.5 hours under the 450VA load, finally going
offline at about 0238 MDT.
At
around 0610 MDT, the power returned. For reasons to be
determined, none of the automatic start-up scripts on the WebSDRs did
their job, requiring remote access to kick-start the WebSDR services
themselves. None of the KiwiSDRs on site started up on their own
so a trip to the site will be required to "kick" them manually.
During
this power outage, there was also a network outage which limited
Internet connectivity in the area for a time.
An
interesting side effect was that the labels on the WebSDRs were
"wrong": The labels are changed at 5 AM and 5 PM MT, but since
the power was off at 5 AM the script that runs precisely at that time
did not run when the power was restored. The scripts were
manually run on the four servers to "fix" things. Of course, they
would have eventually fixed themselves!
One of the deadman anchors on the tower with
the beam having pulled out of the ground a few inches as evidenced by
the appearance of metal that had - until recently - been underground. Click
on the image for a larger version.
9 September, 2020 - Wind
storm effects
Very
high winds:
During
the 8th of September a severe "wind event" occurred in Northern Utah
with certain areas recording gusts exceeding 110 MPH (175kph).
As you can imagine, this felled trees, removed roofs, and
caused significant power disruptions. (Addendum: Some areas
were without electricity for more than three days following the event.)
During
this event, connectivity
to the Northern Utah WebSDR was impacted when critical infrastructure
on the Internet Backhaul (which
feeds our ISP) went offline, reducing available bandwidth.
A repair/work-around was implemented within hours.
Failure of tower guy anchor:
At
the Northern Utah WebSDR site an inspection has revealed that one of
the guy anchors on the 80 foot tower holding the LP-1002 beam - the
"South-East" anchor - has failed as evidenced of it pulling out of the
ground a few inches. In referring to the 20 June, 2018 entry
of
this "Latest News" page you will see that a similar thing happened with
the north anchor, which has since been replaced. We have
contacted the same person who did the previous replacement and we will
have him replace the two original anchors - including the
not-yet-failed "South-West" anchor - as soon as possible.
30 August, 2020 -
Internet outages, but not at the WebSDR:
On
the morning of 30 August, 2020 a large-scale outage - largely confined
to customers of Century Link and its related company, Level 3 - where
many customers found that they had no Internet access. There
were
apparently knock-on effects around the world that gradually subsided as
the issues were resolved and/or incorrect routing information (something like that)
aged out - the details are not clear at the time of this writing.
The
WebSDR itself was not directly impacted as it doesn't use any of the
affected
network providers, but many users were unable to connect to it owing to
difficulties caused by this incident.
5 August, 2020 - Issues
with WebSDR #2:
There
were issues with WebSDR
#2 (Green)
where users were getting incomplete/intermittent audio and waterfalls.
We
think
that the issue was an errant software package, known to occasionally
cause issues, that was disabled: We are hoping that the
problem
is resolved - but one never knows!
The
problem appears
to have been the Linux "SnappyD" service - which is apparently known to
occasionally go rogue, causing excess usage of resources.
Since
this is not really needed for the rather stripped-down systems used for
WebSDR service, this was removed.
1 August, 2020 - Site
work:
Building painted:
The
building containing the WebSDR receive hardware was repainted using a
white, IR-reflective "RV" paint to reduce the thermal load -
particularly during
these days of high (>100F,
>38C) temperatures. The (mostly) bare metal
of the exterior of the building went from being too hot to touch to
being about the same temperature as ambient.
As
the building is normally not
air conditioned - except
when someone is there working on something. Until the recent
addition of a thermostatically-controlled vent fan, the
interior of the
building would often exceed 125F (52C)
- and with the fan this was reduced to about 10-12F (about 6C) above
the outside temperature.
The
repainting of the building should reduce the heat even more and
minimize the during of the vent fan's operation. In case you
are
wondering why we don't run an A/C unit all of the time, just consider
what the power bill might be! Computers are are usually just
fine at
"reasonably hot" (100F/38C) temperatures, anyway.
Comment on 8/4:
After several days of monitoring since painting, the interior
temperature is now typically 4-5 degrees F (roughly 3C) above
the outside temperature.
Power transfer relay replaced:
The
WebSDR's equipment has been powered via a simple transfer relay that,
when the UPS power is present, will supply power via that route - but
if the UPS power disappears, it will switch to another power source.
This box has allowed us to work on the UPS without
interrupting the power to the equipment, simply by powering down the
UPS and the relay transferring the load to a non-UPS source - or, if we
so choose - another UPS.
The
new relay is more rugged, and it includes voltage sensing and a delay
on the "main" power input so that the UPS has time to come up to full
voltage and power before the relay switches.
Brief system outage:
Because
all gear is powered via this box, everything
at the WebSDR site had to
be powered down when it was changed, resulting in an outage of 5-10
minutes.
AM broadcast band notch
filtering added on RF feed from the beam:
Despite
the LP-1002 beam being
designed for 6-40 MHz, it does a very good
job of intercepting signals well outside this range - including
the AM and FM broadcast bands. In fact, it does a decent job
of
being a (more or less) omnidirectional antenna down through the AM
broadcast band.
While
some "strong" filtering
was
in place to remove the AM/FM band energy, a few of the stronger AM
broadcast band signals were still still able to get through the filter
with a significant amount of energy, so four notch filters were added,
tuned to the four strongest signals to further reduce the possibility
of signal overload.
Known issue:
As
mentioned in an earlier
entry, some of the receivers (notably
the 40 meter receivers on WebSDR #1 and the 20 meter receivers on
WebSDR #4)
are prone to drift a few 10s of Hz with temperature. This is
a
known issue and we are working - as time permits - on a means of
compensating for this.
30 July, 2020 - Brief
outage:
It
appears that there was a brief outage of a major data circuit that
feeds a significant portion of Northern Utah a bit before 1500 MT on
this
day. This interruption temporarily caused the loss of
connectivity to the Northern Utah WebSDR - not to mention many other
customers throughout the region.
25 June, 2020 - Comments:
WebSDR Telemetry
transmitter: A
CW telemetry transmitter has been added on site and you may hear this
at 28.569 (USB). This beacon includes indoor temperature,
humidity - and their minimum and maximum voltages. Also
conveyed
is the power line voltage (min and max) and it records low (<100 volts)
and high (>135
volts) excursions - and it counts power outages and
measures their durations.
The
temperature/humidity
min/max readings are reset at local midnight.
The
mains voltage min/max
readings are reset at local midnight. every "even" 5 minutes. (Changed 4
August, 2020)
Possible interruption in Internet
connectivity: Earlier this week (6/22-6/23) the
Internet backhaul provider (not
our ISP) had routing issues.
17 June, 2020 - Comments:
Weather Underground
widget removed: It
would seem that Weather Underground has finally discontinued support
for their older widgets, meaning that the small display of current
conditions that had appeared in the upper left corner of the WebSDR
pages quit working. We have replaced the widget with a link
to a
page that will display weather at the Northern Utah WebSDR receive site.
It
is unclear whether owners of personal weather stations - one of the
largest contributors of raw data to the Weather Underground monitoring
network - are currently entitled to free "widget" service.
We
are looking for alternative
widgets that can interface with the Ambient Weather network -
preferably for free.
Slight frequency drift
with temperature: Users
of some bands (40
meters on WebSDR #1, 20 meters on WebSDR #4 - and a few other bands)
may be noticing a drift of a few 10s of Hertz at times.
This
is due to the use of FiFiSDRs for these bands and the use of similarly
un-compensated oscillators on some of the other affected bands being
affected by changes in ambient temperature.
We
are developing a means of
automatically compensating the frequency to remove the (majority) of this
drift.
Brief outages:
There| were (probably) several brief outages today as our ISP
upgraded some of its equipment.
Changed mode switching
on WebSDR #4.
It
had been commented by users that the automatic sideband selection on
WebSDR #4 wasn't working as expected. By default, the WebSDR
code
is supposed to work like this:
Default to LSB for 160, 80 and
40 meters and USB for everything else.
If, when on a band where USB is
normal, one is on LSB, the mode is "swapped" when switching to a band
where LSB is normal.
For
some reason the LSB mode was often being selected when users connected
to WebSDR #4. Code was changed so that the default is now to always
select LSB for 40 meters and USB for the other bands... I hope...
31 May, 2020:
Power outage at WebSDR receive site.
It
would appear that the AC power (from the utility) went off at
approximately 0843 MT, the on-site UPS taking over at that
time.
At
about 1230 one of the locals brought over a generator to keep the site
online. The generator remained online until the early
evening.
Both the UPS and generator are RF-noisy, causing a bit of QRN on most
bands.
We
later learned that the cause of the outage was vehicle versus power
pole: Apparently, a rather large truck was able to take out
two
or three power poles - and then another vehicle, swerving to avoid the
accident, took out another pole on the other side of the road.
Needless to say, it took hours for the utility to repair the
damage.
There
was a brief interruption when power was transferred back to utility
power: Apparently our automatic transfer relay - a device we
installed to allow us to switch power sources without interruption -
didn't work properly, so all servers were dumped, but brought back
online
immediately. We'll look at this issue during the next "major"
site visit.
25 May, 2020:
Slight receiver frequency adjustments.
While
most of the receiver
local oscillators at the Northern Utah WebSDR use TCXOs (Temperature-Controlled Crystal
Oscillators)
the FifiSDR and SoftRock Ensemble receivers do not: These
receivers use the Si570 synthesizer, instead. Because of
this,
they drift slightly with temperature - roughly on par with that of a
typical, modern HF transceiver with a factory reference.
The
bands that may
drift slightly with temperature are:
160M, 40CW and 40PH on WebSDR #1
which use FifiSDRs.
17M and 12M on WebSDR #2
which use the Softrock Ensemble II receivers.
20CW and 20PH on WebSDR #4
which use FifiSDRs.
30M and 17M on WebSDR #4
which use Softrock Ensemble III receivers.
Today
I was able to get a utility working that allows "live" tuning of the
FiFiSDRs and wrote some simple scripts that allow "on the fly"
adjustment of the local oscillator frequencies and several of the
receivers (40PH on
WebSDR #1 and 20PH on WebSDR #4) were slightly
adjusted to bring them closer to being "dead on".
Eventually, a script
will be implemented that will allow better frequency-versus-temperature
compensation to minimize the amount of apparent drift.
Because
of the nature of the
local oscillators used in the aforementioned receivers (e.g. the use of the Si570)
they do not readily lend themselves to being externally
referenced (e.g.
OCXO or GPS.) The
only practical way to do this would be to introduce a known-accurate
and stable frequency into the RF chain and make occasional measurements
of the resulting audio frequency.
22 May, 2020:
WebSDR receive site offline due to lightning
At
around 1800 MT the connectivity to the Northern Utah WebSDR's receive
site was lost when a lightning strike took down one of the wireless
hops
of our Internet Service provider.
Service
was restored a few hours later. It was mostly a matter of
power-cycling everything and doing a minor reconfigure to work around
damage to one of the backhaul radios: Equipment will be
replaced
later as necessary.
15 May, 2020:
WebSDR receive site offline due to rodentia.
At approximately 1830 MT the Northern Utah WebSDR's
receive
site went offline: Service was restored about 6 hours later,
a
bit after local midnight.
The outage was caused by rodents (rats?)
chewing through an Ethernet cable at a linking site. The
cable
was replaced and measures were taken to help prevent this from
happening again.
1 May, 2020:
Site visit.
A site visit was made on this day to address several
issues:
40 meter
band-pass filter added to 40 Meter receivers on WebSDR #4.
As noted in the 25 April, 2020 entry, the 40 meter
receivers on WebSDR #4 ("40CW-E" and "40PH-E")
were being overloaded by extremely
strong signals in the adjacent 41 meter shortwave broadcast band,
causing spurious signals to appear at time due to generated
intermodulation distortion. A major challenge is that the top
of
the 40 meter amateur band (7.3
MHz) is the bottom of the 41 meter shortwave broadcast
band meaning that some of the strong signals were very close to the
top of the band, making filtering difficult.
A somewhat complex band-pass filter was constructed
in an
attempt to reduce the likelihood of intermodulation distortion by
strongly limiting signals outside the 40 meter band. This
filter
provides offering more than 20dB of attenuation below 6.9 and above 7.4
MHz.
Another
KiwiSDR added on the beam's RF signal path.
A second KiwiSDR was added to the signal path from
the
LP-1002 beam that feeds WebSDR #4 to allow expanded WSPRNet monitoring
and to free up more channels for general listening. At the
moment, these KiwiSDRs are not
publicly available, but we are considering doing so.
A revised "limited attenuation" high-pass filter was
installed in the KiwiSDR signal path - this filter offering more
attenuation at lower frequencies than the previous version.
It was observed that even though this filter has
more low
frequency attenuation than the previous, it is not enough to handle
both the extremely strong signals from the 49 and 31 meter shortwave
broadcast bands and
to have enough gain to hear the noise floor at 10 meters. It
would seem that a bit more revision of this filter will be necessary!
New high/low pass
filter module added to WebSDR #4 signal path.
As noted in the 11 April, 2020 entry a makeshift
high/low
pass filter was installed to prevent overload from both AM and FM
broadcast signals that were happily intercepted by the beam.
A
more "permanent" filter was constructed using the "proper" components (NP0 capacitors, carefully
adjusted toroidal inductors) that was made to be small
enough to be installed in the enclosure containing the
amplifier.
The "high pass" portion of the filter was set to (more or less)
pass 160 meter signals, but block AM broadcast band signals by at least
30dB - apparently, this wasn't enough as some of the signals are quite
strong. This will necessitate either modification of the
filter
to add frequency-specific notches (for
the strongest AM broadcast signals) or a redesign of the
filter.
Even though the antenna's "official" frequency
range is
6-40 MHz, it can still receive signals well below 6 MHz - albeit at
lower gain and with undefined directivity. Because
noise/signal
levels are so high at these frequencies, one can lose gain and be able
to hear the bands' noise floors - which means that you can still
hear any signal that might be present. This modification was
performed to allow signal analysis from this antenna (via WSPR signal monitoring)
to determine the viability of this antenna at 6 MHz and below.
Low-pass filter
network added to main WebSDR feed:
Even though it had not been observed to be an issue,
a 40
MHz low-pass filter was added to the main RF feed from the TCI-530
omnidirectional antenna that feeds WebSDRs 1-3.
Installation of 160
meter band-pass filter "permanentized":
The 16 February, 2020 entry described how a very
"sharp"
160 meter band-pass filter was added to the 160 meter signal path.
This filter's offers
just 4 dB of attenuation in the 160 meter band, but 20dB at 1700 kHz
and in excess of 40 dB below about 1600 kHz.
The
filter - which is
built on a small circuit board - had been temporarily wired in, hanging
in space but it was relocated/placed inside the "low split" filter
module.
25 April, 2020:
Overload issues on 40 meter receivers on WebSDR #4:
Users
of the 40 meter receivers
on WebSDR #4 have likely noticed that during local evenings (in Utah)
- particularly during the hours near sunset - that the performance of
these receivers is degraded. This is due to the extremely
strong signals found just above
the 40 meter band in the 7.3-7.8 MHz range, the so-called 41 meter
band. The total RF power of these signals has been observed
to
approach 0 dBm - which is a signal level exceeding 70
over S-9 which is enough to cause issues with practically
any receiver.
While
these receivers are already preceded with "strong" band-pass filters,
these were mostly intended to remove the also-strong signals from the
49 meter shortwave broadcast band - and they do that nicely - but they
do little for the powerhouse in the signals in the 41 meter band.
Under construction are some extremely
sharp band-pass filters that should offer significant attenuation to
signals starting just above 7.3 MHz.
Compounding
this issue is the
persistent lightning static
that emanates from strong spring thunderstorms across the central
United States - the same direction in which the beam antenna is
pointed. These strong static crashes - combined with the
already
overloading receiver - further cause degradation.
As
noted, the gear needed to make these modifications is currently under
construction, but construction and testing - not to mention arranging a
trip to the WebSDR receive site - will take a bit of time. Thank you for your understanding.
23 April, 2020:
Noise issues on WebSDR #4 and LF.
Yesterday
(22 April)
significant degradation was noted on the 17, 15, 12 and 10 meter noise
floors on WebSDR #4 along with a severe degradation in performance on
the LF receive system (<=400
kHz) as received on 2200 meters and KiwiSDRs 1-3.
The
issue was tracked down to an intermittent shield connection on a
coaxial cable that was common to both of these signal paths.
It
was initially presumed that the cable on the end of the jumper had
failed where it connected to a grounding block/lightning arrestor, but
subsequent disconnection/testing did not reveal any problem - and when
this cable was reconnected to the same place, the issue could not be
replicated.
This
diagnosis required the
complete interruption of the signal path on WebSDR #4.
14 April, 2020:
Power bump - and attenuation added to the 40M RXs on WebSDR
#4:
Power bump caused by
UPS self test:
Apparently
the UPS on site had gone into a "self calibration" mode to determine
the battery run time and was, in fact running on battery - and the
battery just happened to be dead, at the end of the test cycle.
Of course, as Murphy predicted, there was a power bump at
that
very instant and the entire site dropped power for just a moment at
about 1233 local time.
For
reasons that we don't yet understand, while the WebSDR servers will
boot up and start just fine, the WebSDR program isn't always starting
up cleanly and one must remotely log in to do it manually - this took
several minutes to do for several of the machines. We have
investigated this issue, but it never seems to happen when we are
on-site and try to simulate the conditions where this happens - another
aspect of Murphy, no doubt!
One
of the locals was nearby and went over to the site to check on things:
The UPS was taken out of the mode where it can do this
regular
calibration routine, so this sort of thing shouldn't happen again!
Attenuation
added on WebSDR #4:
While
there, an extra 9 dB of
attenuation was added to the 40CW
and 40PH
receivers that will hopefully eliminate (or at least reduce)
the overload issue mentioned in the 13 April, 2020 entry.
This
issue seems most likely to happen during "Grayline" propagation
conditions between the Eastern U.S. and Utah where the 41 meter SWBC
signals will go up by 20-30dB for a few hours.
We
will continue to monitor the situation, adding//adjusting attenuation
as appropriate. Because WebSDR #4 is a "new" system, the
signal
dynamics are presently more unknown than known so further
tweaks/adjustments will likely be needed as we encounter these varying
conditions.
13 April, 2020:
40 meter RX overload on WebSDR #4
It
would seem that we missed something when commissioning something in the
signal path of WebSDR #4: The gain in front of the two 40
meter
receivers! As it turns out the signal of some of the 41 meter
SWBC stations originating from the eastern U.S. can exceed -20dB per signal
- and there were multiple
signals.
At
the base of the antenna
there is an amplifier (about
13 dB gain) to set the system noise figure and overcome
losses in the 130+ feet (40
meters)
of cable - and the 40 meter receiver, itself, contains a 13 dB gain
amplifier: Between these amplifiers, the gain of the antenna
itself, the cable and splitter losses this receiver is likely seeing a
signal that is equivalent to about "80 over S-9" - enough to overload
almost any
receiver you will ever see!
When
the opportunity arises
some attenuation will be placed in front of the receiver, which should
solve the problem.
11 April, 2020:
Site visit.
WebSDR #4 (Magenta) brought
online.
A
new WebSDR server, #4, was brought online: This server is
connected to a Hy-Gain LP-1002 Log Period antenna that is at 80 feet
above ground (25 meters)
that is fixed, non-rotatable
on a heading of 87°(true north
reference).
This antenna has never had a rotator - and it NEVER WILL.
This
system covers the 40, 30, 20, 17, 15 and
10 meter
amateur bands: 12 meter is currently not covered because of
software limitations - but we are considering means of providing such
coverage.
The
orientation of this antenna is such that it covers the Eastern United
States in its main lobe, with the far DX coverage putting the center of
the beam
coverage on South Africa with the Middle East and the Mediterranean at
the extreme north edge, near the "unity gain" points.
Australia
and New Zealand are within the main lobe for "Long Path" coverage.
During
this visit, it was
discovered that a portion of the feedline had (literally)
disintegrated: A bit of a "kludge" was required to make a
connection to the feedline. We are looking into obtaining
replacement hardware to effect a "permanent and proper" fix.
Please
note that this system is
still undergoing commissioning and it may go offline or be restarted at
times.
If
you are using this WebSDR in conjunction with your home station, please
remember that you may not be able to hear stations to the west
of
the heading of this beam - but those other stations might be able to you
unless the antenna at your QTH is similarly directional.
Overload
was being caused to an RF amplifier module at the tower by the presence
of strong signals from both FM and AM broadcast signals, resulting in
extreme overload and intermodulation distortion. A makeshift
filter was constructed on site using cardboard from a pizza box, some
self-adhesive copper foil, inductors wound using wire found in the tool
box and capacitors from an assortment kit - the operation and
performance verified with a NanoVNA. The filter, while very
ugly,
did the job.
A
single KiwiSDR, dedicated to
monitoring signals from the beam antenna, was added. This
KiwiSDR is not (yet)
available to the public.
If
you have any comments about
this antenna and its receiver please send them to sdrinfo@sdrutah.org
4 April, 2020:
Site visit.
Reduction of power line
and computer noise.
Some
common-mode filtering was strategically added to reduce common-mode
noise from power lines and computer power supplies caused by
circulating currents on some of the internal coaxial connections.
Reduction
of common-mode noise on "LF" signal path - namely the frequencies below
about 350 kHz covered by the 2200/1750 Meter receiver and the KiwiSDR.
Noise issues below about 30 kHz still need to be addressed.
Antenna work.
For
the first time in decades the on-site LP-1002 log periodic antenna has
been connected to receive gear. Some time in the past the
feedline from the antenna to the ground was cut near the top and the
line that went
from the tower to the building is not to be found.
Approximately 80 feet (24
meters) of 1/2"
Andrews Heliax cable (LDF4-50)
was run inside the tower, to the ground and is connected to an
interface box a bit above ground level. From there, a
temporary
feedline runs to the building.
While
the antenna (more or less)has
the expected VSWR curve, it is unknown if it is working properly.
Via a radio at the tower base, the bands sounded "ok" and a
QSO
was made, but this is a very subjective test. This antenna
weighs
about 3/4 of a ton and being at its
height, it's not easy to mechanically inspect the antenna.
There
are some signal level issues that need to be addressed and it is
unknown to what extent they may be due to the new gear, cabling or the
antenna itself.
In
the building another WebSDR
server is online to allow testing/debugging of this antenna:
This WebSDR is currently not
available for public use pending this debugging/completion. Stay
tuned!
It
would appear that one of the main backbone Internet connections for
much of Utah and according to the provider, Utopia Networks, they lost
some key hardware in their
network core. The effect may have been worst in Northern Utah.
As
a result the ISP providing the service for WebSDR - which uses Utopia
as one of its main Internet providers - switched to a much lower-speed
backup to maintain some
connectivity for their customers - but this also caused extremely slow
connections to the WebSDR making it impossible to maintain an audio
connection at times with packet transit times often exceeding 3 seconds.
The
degradation of service lasted from around 1900 to a bit before 2300
MDT. At about 0130 local time on 31 March the faulty hardware
-
which had been reset (with
much crossing of fingers, no doubt) was replaced.
25 March, 2020:
"High Boost" added to the Northern Utah WebSDR servers:
A
button marked "High Boost" is
now
present on the Northern Utah WebSDR servers. When activated,
this provides a 6 dB boost to audio
with the curve of the response "knee" centered at 1500 Hz.
This
button may be useful for
high levels of DSP noise reduction which can have the effect of
suppress higher audio frequencies.
The
high frequency boost may
also be beneficial for those with high-frequency hearing loss, to
improve intelligibility overall.
19 March, 2020:
Internet restrictions relaxed - for now.
Our
Internet Service Provider
has notified us that bandwidth restrictions imposed by their
Internet
backhaul providers have been lifted and with their knowledge, we are
rolling the
configurations of the WebSDR servers back to their original
configuration in terms of audio compression, waterfall speed, number of
users and time-out limits. These changes require the servers
to
be reset so we are waiting for the number of users to drop before doing
so.
PLEASE REMEMBER
that Internet usage has increased dramatically in many areas owing to
the increased need by industry and education for remote access.
Because
of this
you should expect heavy Internet usage that will likely affect
connectivity to all web
sites at times.
The
WebSDRs, being nearly real-time, can have only minimal buffering -
unlike
many streaming services - which means that they are more affected
by
slow-downs in Internet traffic as they cannot simply "pre-fetch" (buffer)
seconds/minutes of content to accommodate.
18 March, 2020:
Utah earthquake
At
0709 MDT there was an
earthquake (5.7
reported as of writing) that was centered just north of
Magna, Utah - approximately 11 miles (17
km)
west of downtown Salt Lake City - just a "little one" for many
California transplants.
Reports
indicate that the most severe shaking was
very localized with power outages and damage to unreinforced masonry
structures in the immediate area and several trailer homes having
fallen off their piers. Elsewhere in the Salt Lake
valley the reports vary from "A loud truck
going by" to "Holy $#!+".
Businesses and warehouses have reported loss of inventory due
to
items having fallen off shelves and tipping/collapse of shelves.
As
of this writing, there are no reports of serious injuries.
Dozens
of aftershocks have been felt all across the Salt Lake area - some of
them quite strong, but so far non have been greater than 4.7 - a
magnitude less
than the main 0709 MDT shock.
For
the most part, services (power,
water, Internet)
have been minimally affected overall with the mobile phone service
possibly having been impacted by the
expectedly-high call/text volume. Initial reports are that
outages are restricted to very local cases where specific
sites may have had equipment disruption (e.g. loss of
power/connectivity).
As
far as can be determined,
the Northern Utah WebSDR - which is about 70 miles (110 km)
north of Salt Lake City - saw no interruptions in power or service.
If there had been interruptions in service it would most
likely
have been due to follow-on effects from widespread power failure and
loss of Internet connectivity in the nearby metro areas.
WebSDR Issues:
Wiring damage: It
was observed that some of the receivers' signal levels were low, so a
site visit was made where it was discovered that some of the wiring on
the 12 volt bus that powers the RF infrastructure (preamps, converters, etc.)
had been pulled apart - probably because of shaking of the equipment
and rack. There were a few brief outages as the DC cabling
was
re-dressed and repaired.
USB port issues:
While on site it was observed that the system was throwing
errors
related to the 40CW USB receiver, occasionally causing the WebSDR
service to restart which would kick everyone off. After a bit
of
reconfiguring - which required some changes to the computer, WebSDR
reconfiguration, several reboots and 15-20 minutes of being offline -
that device was moved to a different USB port where it seems to be
behaving itself.
Dirty
power on site:
A
few days ago a "new" UPS was put on site after the previous UPS had
been damaged by voltage extremes - and based on the complaints, the new
one was not happy at all with what it was seeing - with the AC mains
voltage varying from 90 to 142 volts - the UPS going on battery when it
was below about 105 volts or above 135 volts. In speaking
with
the power company, we should not expect the situation to improve in the
short term which means that we will have to deal with it ourselves (power in rural areas is often
like this) and we are considering more robust means of
providing back-up power, including:
An AC mains voltage regulator
An
"online" UPS that can take a wide voltage input and output a consistent
125 volts. Essentially, this is would be just a wide
voltage-range 24 volt DC power supply connected to a battery and that
same battery connected to a 120 volt inverter.
If you have any suggestions -
or equipment you might be willing to donate - please contact us as
"sdrinfo@sdrutah.org".
KiwiSDR
#2 intermittent:
KiwiSDR
#2 has been having
problems, occasionally rebooting. We think
that this is a result of problem with the power lead feeding it and
have effected repairs, but we are continuing to monitor.
Adjustments were made to the four "canned" settings of the DSP noise reduction (e.g. "Low", "Medium", "High", "Strong") to make them more usable overall:
Low
- This setting was adjusted to make it less aggressive, but still
noticeable. The idea is to take a bit of the edge off the noise
that might be present.
Medium
- This is roughly comparable to what the "low" setting had been:
It's effect is quite obvious, but likely not enough to be
annoying in most situation.
High
- The adaptation of the filter to voice is noticeably stronger, but it
will have more of an effect on background noise when no signals are
present (e.g. the "hollow" or "barrel" sound).
Strong - This
setting borders on the extreme. It will adapt fairly quickly to
voice energy buried in the noise and this has the effect of leaving a
bit of an "after image" (a ghostly echo) after the voice has stopped.
Remember:
This type of DSP noise reduction - like almost any other - "keys" on the voice energy among the noise, but this means that with very weak signals, there may not be enough voice energy to do this and it may actually reduce intelligibility in certain cases.
This type of filter works best with "white" noise (hiss): It will do nothing to help with off-frequency QRM (splatter) - because that is not noise!
Types of noise that are not random - such as powerline noise (e.g. buzz)- will not be reduced by the DSP noise reduction filter.
14 March, 2020: Extreme power events likely related to high winds in Northern Utah.
Likely
due to high winds, the electrical power at the Northern Utah WebSDR
receive site has been very erratic. It so-happened that one of
our number was at the receive site when a power bump occurred - but for
reasons to be determined, the UPS refused to take over. Of
course, the WebSDR and all of the on-site servers lost power when this
happened, which occurred at about 2008 MT. It took several
minutes for all WebSDR servers to come back online.
After
the power returned and stabilized, the UPS was tested repeatedly (main
power unplugged and plugged in) to replicate the issue, but the UPS
seemed to behave normally.
It
is suspected that some combination of brown-out or high line voltage
may have caused the UPS to freak out - but since the problem could not
be replicated, we may never know.
It was reported that there were scattered power outages in Corinne. In one location where the was power, the line voltage was seen to vary from zero volts to over 160 volts on a (nominal)
120 volt line for seconds at a time! At that particular location,
the UPS had disconnected itself from the power mains and was running
its load on battery-only during the wide voltage excursions.
13 March, 2020: Internet connectivity of the Northern Utah WebSDR affected by the Covid-19 health emergency.
What is happening: Our Internet Service Provider (ISP) has notified us that their connectivity (e.g. connectivity from the entities that provide back haul connectivity to large commercial entities and ISPs) has been restricted for the time-being. This is a follow-on effect caused by, among other things:
Increased use of bandwidth for tele-commuting as workplaces are encouraging employees to work remotely, where possible.
The temporary closure of educational institutions to in-person attendance and moving as many classes online as possible (e.g. remote learning).
Increased
use of home Internet connections for not only remote learning and
telecommuting, but also due to higher demand of online streaming (movie, TV) services because of more people staying home.
The ISP has (understandably) requested that their users minimize their bandwidth as much as practical.
As
you might expect, this sort of problem is affecting rural areas across
the U.S. as they typically have rather limited Internet connectivity,
anyway. The Northern Utah WebSDR is located in a rather
rural/remote area, so we are similarly affected.
What we have done at the Northern Utah WebSDR to reduce bandwidth utilization and maintain service:
Increased audio compression.
To reduce overall bandwidth, the amount of audio compression on
the users' streams has been increased: This will reduce audio
quality somewhat (slightly more noise and distortion) but the effects will likely not be noticed except for very good signals (e.g. "armchair" quality). This can be mitigated somewhat by setting the DSP Noise Reduction to the "Low" setting.
Reduced the inactivity timeout length.
The timeout timers have been reduced to 60 minutes to reduce
probability of "set and forget" monitoring: If nothing has been
done by the user (e.g. an adjustment of the WebSDR's settings) users will be disconnected after 60 minutes - but you will be able to reconnect.
Decreased waterfall speed. The rate of the waterfall scrolling will slow if a large number of users connects to the WebSDR.
Maximum number of users has been reduced. Reducing the maximum number of users will reduce the probability of bandwidth restrictions will affect all users of the Northern Utah WebSDR being affected if we hit the current, lower limit.
How long will this last?
Who's
to say? The increased use of Internet back hauls will be long
term and the Internet providers are ramping up capacity as much as
practical, but the increase in the worldwide demand of the very equipment needed to increase bandwidth (routers, interfaces, customer equipment, etc.)
at the very same time that staffing and supply line issues are
restricted will make this a formidable challenge - but hard work is
being done behind the scenes to reduce the impact
We thank you for your understanding in this matter - and please be safe!
11 March, 2020: Power failure
At
approximately 0915 MT the power at the site went offline and about 2
hours later, the UPS battery was exhausted. At approximately 1145
the power was restored, but apparently it did not do so cleanly:
The power supply in WebSDR #1 was damaged and although the other
servers powered up, they did not recover gracefully.
A
site visit - which occurred about 1600 MT along with more rebooting and
a swap of a power supply was able to bring everything back online by
about 1645.
We are still investigating the nature of the damage to the power supply and why it was that absolutely nothing
came back online by itself: We have had power failures before,
but we have never had so many things refuse to come back up unattended.
It appears that the LF receive system (reception below 400 kHz - including the 2200/1750M receiver)
was damaged at the moment of the original power failure - and did not
recover with the rest of the system: This is on the list of
things to be investigated during the next site visit.
Update:
A brief site visit was made and the power supply feeding this
antenna's coupler was repaired on 12 March, bringing it back online.
9 March, 2020: DSP Noise reduction and "Notch2" added to WebSDR #1 and #2:
The
DSP noise reduction and the second notch filter have been added to
WebSDR #1 and #2 after a few adjustments and bug fixes were made to
them from testing on WebSDR #3.
There
may still be some issues (bugs) with the new filters, so they should be
used with that in mind. If you notice what seems to be a bug -
particularly if you can reliably reproduce it - please let us know via
email at "sdrinfo@sdrutah.org".
If,
while using the DSP noise reduction, the audio suddenly stops, try
turning the filter off and then back on in an attempt to reset it.
Suggested setting of DSP noise reduction for casual listening: The Low setting is recommended as it has a noticeable effect with the fewest artifacts.
7 March, 2020: DSP Noise reduction and additional notch filtering being tested on WebSDR #3 (blue):
Additional notch filter:
In addition to the original notch filter (had been labeled "Autonotch" - now labeled "Notch1"
another notch filter has been implemented. While the original
autonotch filter worked, it had some limitations due to the need to
minimize the processor load on the server: It was able to notch
only one tone at a time and it was easily "fooled" by modulation, the
result being that one could often hear the tone turning and and off as
the original notch filter "hunted". Because this notch filter is
at the server, activating it will cause the S-meter to drop when the
strong tones are removed.
The new filter (labeled "Notch2")
is a bit more aggressive and should have less of a tendency to "hunt".
Because it is on the audio stream from the server, it will not
affect the S-meter, meaning that a strong "tuner-upper" will still
"de-sense" the receiver - unless "Notch1" is also active.
For
minor tones, Notch2, alone is fine, but it's just fine to use both.
Note that these filters will "hunt" a bit and can cause a bit of
odd distortion at times.
Of course, you should NOT use any notch filter if you are running CW or any digital mode!
DSP Noise reduction:
A
simple noise reduction system has been implemented and like "Notch2",
it is also audio-based, operating on the audio stream from the server.
There is a drop-down menu that allows several settings (including "Off") for the amount of noise reduction.
As
is typical of this type of noise reduction, it can have an "hollow"
sound - particularly with very noisy signals but that's just the way it
works.
These filters are designed for voice: They may sound terrible if you use them when listening to music - but try different settings.
The noise reduction works best on strong-to-"medium-weak" signals, but if a signal is extremely weak and noisy, it may not help: Go ahead a try the various settings.
In the presence of very weak (or no signals - just band noise) the audio may sound quiet - particularly if the noise reduction is set high. Be careful when listening as you may be tempted to turn up the volume, only to get blasted when a strong signal appears.
This filter works best on "white" type noise, but it is less-effective on power-line buzz. The "Notch2" filter may work better in some cases.
These filters are currently being tested/debugged:
The settings of these filters is currently being tweaked and they may be improved over time.
Consider
these filters to be in "Alpha" testing: They may be buggy and may
not work as expected in some cases and there may be (yet unknown) compatibility issues. If you find what you think are issues with them drop a line to sdrinfo@sdrutah.org .
These
filters have been tested on Firefox and Chrome as those are the only
browsers currently available for testing. Reports of testing on
other browsers (e.g. Safari) and platforms other than PC are welcome.
It
has long been observed that the Firefox browser works better with
WebSDRs than Chrome: If you are a Chrome user and have issues it
is suggested that you also try Firefox.
If you are having issues with the Chrome browsers, see if your sound card settings (on Windows: Control Panel -> Sound -> Playback -> (select output device) -> Advanced)
and make sure that either "16 Bit 44100 Hz" or "16 Bit 48000 Hz" is
selected as Chrome doesn't seem to do well with higher rates (96000, 192000 Hz).
These filters require more processing horsepower when active than when they are off: This may pose issues (audio drop-outs, etc.) on older/slower computers. Some devices with limited processing power (phones, tablets) may have more problems.
These new features have not yet been rolled out to WebSDR #1 or #2 (or anywhere else) yet: When (and if!) depends on the results of testing.
4 March, 2020: FM demodulation modified.
It was suspected - and verified that the original "FM" demodulation of the WebSDR code did not implement audio de-emphasis. As you may be aware, in FM communications system the audio is not modulated as "straight" FM, but rather the audio is boosted (pre-emphasized) at 6dB/octave on transmit: In other words, given a constant audio level applied to the input of the modulation, the proper
implementation with pre-emphasis applied would be that this level might
give 1 kHz deviation with a 500 Hz tone, 2 kHz deviation with a 1000 Hz
tone and 4 kHz tone. On the receive end, the opposite should be
applied.
Without
de-emphasis, the audio of a typical "FM" signal sounded decidedly
"tinny" - which is to be expected - but it also sounded noisier than it
otherwise would. One of the reasons for transmit audio
pre-emphasis is because of the nature of FM: When a signal gets
weak, noise appears - but at the high frequencies, first. If you
boost the audio on the transmit end and "un-boost" it on the receive
end that noise is reduced by a significant amount.
If
de-emphasis is applied, low frequencies are effective boosted which can
cause subaudible tones to seem to be extremely loud, so high-pass
filtering was added as well: Three cascaded biquad filters - each
with a 12dB/octave roll-off below 225 Hz - pretty much eliminate any
the fundamental frequency of any subaudible tones that might be present
on the signal. Without this high-pass filtering such tones would
surely rattle the daylights out of the speaker!
These
filters were implemented inline in the main handler of the audio HTML5
javascript code so they will not add any additional processing delay.
This modification is most significant on WebSDR #3 which natively covers the 2 meter band.
25 February, 2020: Minor updates.
USB sound device port enumeration implemented:
On 11 January three FiFiSDR receivers were installed, replacing the previously-used (and ultimately unreliable)Asus
Xonar U5 and U7 USB sound cards. As noted, the FiFiSDRs are
complete units with both receiver and sound card hardware connected to
the computer by USB and this hardware has been successfully used by
several other WebSDRs - including the KFS (Half Moon Bay) WebSDR.
One
of the problems with identical USB devices - on both Linux and Windows
- is that it can be difficult to figure out which one is which:
If you have attempted to use multiple USB to Serial interfaces,
you will already be aware of this. With these sound cards (and the older Asus USB sound cards)
not only did the "name" of the sound card depend on into which USB port
it was plugged, but this naming could change if another USB device was
added.
An
addition - using Linux UDEV rules and a Perl script - was made so that
a sound device plugged into a particular USB port would always
have a consistent name. This Perl script was kindly provided by
Craig, W6DRZ, of the KFS WebSDR - and this script is a modified version
of one provided by "gmaruzz", described here.
The installation of this script required several reboots/restarts of WebSDR #1 (Yellow) to install and configure - some of these occurring in the early hours and another occurring mid-morning.
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 totaling 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.
Waterfall labels (the sysop-defined yellow labels for Nets, etc.) updated:
Up
until now, there were only "Day" and "Night" labels on the WebSDRs,
being switched at 0500 and 1700 (Mountain time), respectively.
This feature has been expanded so now there are separate day and
night labels for the weekdays and weekends. Because the
"nighttime" label is displayed until 0500 MT, the "Weeknight" labels
will persist until 0500 MT on Saturday - and similar for the "Weekend
night" labels, which will persist until 0500 MT Monday.
A
modification was made to the code so that it is now possible to move
labels horizontally. This has allowed the labels to be spread out
a bit with fewer of them being covered by another.
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.)
As
of 1637 MT (2337 UTC) on Wednesday, January 8 the receive site of the
Northern Utah WebSDR lost connectivity to the Internet - again
due to issues that our ISP is having.
We are working on a means of
restoration - but expect this outage to last several days.
In the meantime, we have
"re-pointed" the URLs of the WebSDR servers so that most users will see
the landing page and the outage notice when they attempt to go to a
WebSDR server rather than a "dead" link.
Don't worry, we will
get it back online!
7 January, 2020:
Internet connectivity restored!
As of 0845 MT (1545
UTC) on Tuesday, January 7, our ISP was able to restore
connectivity to the receive site of the Northern Utah WebSDR.
We wish to thank them for their work in this restoration.
We
expect that there will be a few lingering issues to work out (e.g.
drop-outs, brief outages) but we are expecting things to improve over
time.
During the outage, we "re-pointed" the WebSDR links to
the
landing page so that users would see the notice rather than just a
broken link: We have pointed them back to there respective
WebSDRs, but it will take several hours (after the above time)
before this change fully propagates through the Internet.
3 January, 2020:
Internet issues.
At
approximately 1338 MT today the Internet connectivity to the Northern
Utah
WebSDR site was lost.
Due to the remoteness of the site, it may take some time
to analyze the
problem and come up with the best solution - which may include
replacement/upgrade of wireless Internet equipment - but we will
get it back online.
We currently have no ETA, but we are hopeful that it will
be restored during the week of 5 January.
26 December, 2019:
Default "Audio
buffering" setting changed.
The default (when
you load the web page)
setting for the "Audio Buffering" on WebSDRs 1, 2 and 3 has been
changed from 0.25 seconds to 0.5 seconds. This change was
made to
help deal with the "flakiness" in the Internet connection (discussed below)
where the "jitter" of that connection will occasionally increase due to
retransmissions on that link segment and cause audio drop-outs.
This setting will be reset to the earlier value of 0.25
seconds
once we "fix" that link. In the meantime, you may select more
or
less buffering when you connect, as desired.
21 December, 2019 - Site
visit:
The trip itself:
It took several days (because of holiday
preparations, schedules, etc.) before an "expedition"
could be carried out to the Northern Utah WebSDR receive site (it's 80 miles/130km each way!)
For a trip to the WebSDR site
we must count on killing the entire
day - and this trip was no exception: The duration of the
trip was about 13 hours, door-to-door,
including about 2-1/2 hours total drive time.
On-site,
it was noted that having four-wheel drive was very useful owing to the
snow/ice on site. The temperature got as high as 34F (1C) and as low as
24F (-4C) during
the time that I was there.
WebSDR #1 (yellow) back
online: Several
issues:
As expected, a failed USB sound
card (Asus Xonar U5)
- used for the "160M"
band - caused the server to hang on "POST" - that is, it didn't ever
get past the start-up (BIOS)
screen to even start loading the operating system. After this
USB device was unplugged, the system booted properly.
It was also discovered that another USB sound
card (Asus Xonar U7)-
this one for "80CW" - had also failed - but instead of hanging the
system, it simply would not negotiate to operate at "High Speed" on the
USB port which meant that the best it would do, if it proved to work at
all, was 48 kHz - able to
cover only 1/4 of the "80CW" range.
Although five
Asus USB sound cards (four
donated by another WebSDR, and one of my own) ere on-hand,
only ONE
of them would work. What that means is that since this WebSDR
was
first brought online in February, 2019, at least six of
these sound cards (Asus
Xonar U5 and U7) have failed, all in similar ways (e.g. failure of the USB port to
properly negotiate a connection).
Since we were one sound card
short of the full compliment (we
are "maxed out" on PCI bus slots, so we had to use
three USB sound cards) we had to sacrifice one band - and
we chose to leave out the "80CW" band for the time-being.
We
have on order several devices (Fifi
SDRs) to completely replace the USB sound
cards - these devices having been used with success at KFS:
It is hoped that this will eliminate this particular
point of unreliability. It is expected that it will take 2-4
weeks for these new devices will arrive (from Germany)
and be tested prior to installation. Unavailable until
recently,
these devices cost about as much as a brand new 192 kHz Asus USB sound
card.
For alternate "80CW" band
coverage (3500-3630 kHz) use
the "90M-80M" receiver on WebSDR #3 (blue) pending the
arrival, testing and installation of the new gear.
Electrical utility work:
It appears
that the upgrade by the electrical power utility is done - but we have
yet to hear "official" word.
Instead of the old,
chunky (and obsolete)
open-delta three-phase 4160 volt line, there is now a "modern"
single-phase 12kV line and a new pole transformer at the WebSDR site
end -
and likely a new transformer at the other end, too! It is
also
likely that our line voltage will stay much closer to the nominal 120
volts rather than the 80-140 volts that we'd occasionally seen before.
(It was 124
VAC when I checked it.)
From the radio site to the
power distribution point (a
compressor station about 2/3-mile, 1km away)
all of the insulators are brand new so we are hoping that it will not
be a source of noise any time soon. (It occasionally rains salty mud
in that part of Utah, so we'll see...)
UPS replaced:
A UPS - which had
failed catastrophically a few months ago - has now been
replaced with a higher-power (1400
VA) unit that uses 24 volts DC provided
by a pair of new-ish 100 amp-hour UPS-rated AGM batteries.
This
should reduce the number of outages -
even though the power has been quite reliable, excepting the recent
utility work where it wouldn't have mattered, anyway.
We calculate that the new
UPS/battery combination should be able to carry the current load for at
least 3 hours.
Image responses reduced:
One
thing that had been an annoyance was that in recent months, whenever an
"I/Q Calibration" procedure was done on the SoftRock ("High Performance")
receivers,
the result was always worse
than
before - so the "old" calibration values were kept, meaning
that
the image rejection was typically around 45dB - not "terribly
terrible",
but not very good, either. Today, the instructions were very
carefully re-read and nothing was
missed - that is, the calibration instructions, written by
the author of the WebSDR software himself, were being followed exactly..
At
this point it was suspect that an important detail had been omitted
from the original instructions - specifically, that one should remove any
existing calibration values before doing the procedure. This
was done experimentally on the
"160M" receiver on WebSDR #1 and the image rejection went from about 45
dB to well over 60 dB. Apparently, the values that obtained
from
the calibration routine are not based on "raw" data from the
signal processing chain, but they are values that have been "cooked",
taken after
existing calibration data been applied, and therefore are utterly
bogus unless one removes any existing calibration data and
restarts the WebSDR service.
The calibration on all
bands that use SoftRock receivers (all
eleven of them - it would have been twelve if the "80CW" receiver
weren't offline)was redone - a lengthy and tedious
process -
and the image rejection on all bands improved significantly.
For
reasons not yet known, the image rejection on the 12 meter receiver
didn't
improve as much as others (it's
around 50dB) but we'll look into that on a future trip.
LF antenna replaced:
Because the LF receive
performance (<350
kHz) was rather poor, the existing 0.75 meter diameter LF
loop antenna was replaced with a 1
meter diameter loop that was recently built and the result was much
stronger signals, but much poorer
signal-noise ratio and even worse performance than the previous loop.
The E-field whip that had been
installed about
a year ago which has more interference on some frequencies than the
whip (the interference
could be nulled out with the loop)
was placed back in service and despite the QRM, the whip works
better overall than the "new" loop.
The "new" loop remains on-site and the older 0.75
meter diameter loop was brought back for re-work.
Internet link tweaked:
There
have been recent issues with the "last hop" of the Internet connection
to the WebSDR side slowing down and, occasionally, dropping out,
probably related to the onset of winter. The working theory
is that
there are Fresnel effects on the "near" (WebSDR site)
side of the link that is causing on-link retransmissions - and path
calculations using terrain database data and path calculating software
bears
this out: Now that the ground is mostly covered with snow,
the
nature of the Fresnel effects have apparently been altered as compared
to those in the summer.
Because
such Fresnel effects - which occur due to multipath caused by ground
reflections from a "high" spot on the terrain somewhere in the path,
below the line-of-sight, the antenna was raised a few degrees in an
attempt to
move the reflected signal farther below the main lobe of the
antenna, reducing its signal will minimally affecting the "main"
signal.
The result seems to be an overall improvement: Even
though
the signal has probably dropped a bit, the reflection has probably
dropped a bit more - this being one of those instances where a stronger
signal does not
mean better performance! The average latency dropped by about
25%
indicating a slightly better link quality overall and instances of
extended ping times - which still occur - appear to be "less bad"
than as link drop-outs are less frequent than before.
An
upgrade to this problematic link is still in the works, but it will
likely be a few weeks before we get all of our "ducks in a row".
18 December, 2019:
Utility work continues:
The electrical utility cut power again around 0900 (MT) to
continue the upgrade and as before, we could not be on-site nor provide
UPS or generator power during this work.
After
about 3 hours, the power was restored. We do not yet have
official word as to whether or not the upgrade is complete.
For some reason, while the
WebSDR #2 (green)
and #3 (blue)
servers (the computers
themselves) came up, the WebSDR program did not.
This rare event wasn't noticed for several hours (sorry!) and
required remote logging-in and manual starting of the WebSDR software.
WebSDR #1 temporarily offline:
As before, WebSDR #1 (yellow)
did not come back online. The suspected problem is a failing
USB
sound card that is causing the computer to "hang" during boot-up, but
we'll have to get eyes on it to be sure. We have extra
hardware
to fix whatever is wrong, but between the utility work (during which we cannot visit
the site), weather, time and the remoteness of the site,
it will likely take a few days before it can be completely restored.
80 and 40 meter back-up
receivers: WebSDR #3 (blue) has back-up
receivers For 80/75 and 40 meter reception - please use these for those
bands in the meantime.
Intermittent connectivity issues:
As noted in the 14 December news, below, we have been
experiencing occasional slow-downs and drop-outs on the 3rd and final
wireless hop to the WebSDR receiver site: Please read that entry for more
details.
17 December, 2019:
Utility work: It
would appear that the long-awaited utility work resumed, the power
coming back after a bit less than 5-1/2 hours. We have yet to
hear official word about whether or not
the work is complete.
WebSDR #1 (yellow) offline:
WebSDR1 did not come back up on its own after the power
returned
- something that had happened following a previous outage. In
that case, the server did
finally come up a few days later, after a power bump but this prevented
a proper analysis of what had happened as the failure "stopped
happening".
The
suspicion is that one of the USB sound cards is starting to fail,
causing the system to "hang" during POST, preventing it from booting
up. This sort of thing had happened before when we were on
site and had to restart the server,
but we had a spare USB sound card and "fixed" the problem.
We're
looking to see what we can do to get WebSDR #1 back online prior to the
next "official" site visit.
14 December, 2019:
Utility work still pending: Between
weather, holidays and other scheduling issues, the work on the upgrade
by the electric power utility still remains to be done: When
we
know something, we'll post it here!
Internet connectivity
issues - slow-downs and drop-outs:
If you are an avid reader of
this page you may already know that it takes three
wireless hops to connect the remote location of the Northern Utah
WebSDR's receiver site to the Internet - and it's the last and shortest
hop (approx 12
miles/19km) that
connects directly to the remote site that has been having issues that
cause the audio to drop out and, occasionally, causing the Northern
Utah
WebSDR's Internet connectivity to become unusable for several minutes.
The issue appears to be related
to Fresnel effects - which
normally cause slight degradation of this last hop - getting briefly
worse when the weather rapidly changes
or is very bad - and severe weather has been happening a
lot in the past couple weeks in that part of the state. We
are
trying to implement some changes to minimize this issue, but it will
likely take a major change to the topology of the network connectivity
to the WebSDR to
eliminate this particular issue.
These
changes are
in the planning stages, but it is not yet known when this might be done
due
to equipment availability, scheduling of those who may do this work and
the kindness of Mother nature. Unfortunately, we are just
entering the time of year where the weather can be the most fierce -
particularly in that part of the state.
10 December, 2019:
Updates.
KiwiSDR receivers back
online: It
appears that all three KiwiSDRs, which run Linux, got into a state
where they were expecting manual intervention by a person before
booting up. We are investigating why this happened so that it
will (hopefully)
not happen again in the future.
Awaiting completion of electrical
utility upgrade:
Because of the weather, slipping of schedules due to other
tasks,
equipment problems the upgrade-in-progress to the electrical feed is
still on hold. When we know more, it will be posted here.
30 November, 2019:
More updates.
Utility work still
pending: Because
of the severe weather, the utility work has been delayed and we don't
have official word as to when it is expected to resume/be finished.
WebSDR1 back online:
Somehow, WebSDR1 seems to have "recovered itself" and is back
online and working normally.
KiwiSDRs still offline:
All three KiwiSDRs are still offline, pending a site visit
which,
itself, is pending better weather and the ability to safely access the
site.
28 November, 2019 update:
More severe weather - just in time for Turkey day!
Heavy weather: A
lot of snow has fallen in the general area of the WebSDR's receiver
site and many roads are awaiting snow plows and there are several
scattered power outages in the area: It has been reported
that
thousands customers (which
is a sizable percentage of people in the country) have
experienced a power failure this morning.
WebSDR #1 (Yellow) back
online: There
appears to have been a power bump at the WebSDR site that lasted long
enough to take everything down - but when power returned, WebSDR1, the
power supply of which had been repaired but the computer didn't boot
properly when initially tried - seems to have recovered itself.
KiwiSDRs offline: Unfortunately,
the power supply running the KiwiSDRs appears to have crowbarred,
possibly because the power did not come back up "cleanly".
Until
the supply can be reset (possibly
another power bump!) the KiwiSDRs - and the "KA7OEI-1"
WSPRNET reporting - will be offline.
27 November, 2019 update:
Severe weather in northwestern Utah delays utility work,
WebSDR1 (Yellow)
still offline.
Utility work postponed: Because
of severe weather in northwestern Utah, the utility work scheduled for
27 November has been postponed. As soon as we know when this
work
will occur, we'll post it here.
Again, expect an extended
outage on that day for the reasons mentioned below.
WebSDR1 repair delayed:
The same weather that delayed the utility work dumped a bunch
of
snow on and around the Northern Utah WebSDR's radio site and
surroundings, making it quite hazardous to travel - particularly for
those people who do not have chains and/or 4WD vehicles.
What this means is that the
primary receivers for 80/75 and 40 meters are down, but there are
back-up receivers on WebSDR3(the Blue one)
that are available for those bands. There are currently no
back-up receivers for 160M, 60M, or the AM broadcast band.
26 November, 2019.
Comments:
Power outage due to utility work:
Because we didn't see another power outage after last Monday,
18
November, we weren't surprised to see it go off today for a while (approx. 1337-1449)
while the power utility did more work.
The utility had to abandon work
on this day because of the failure of a bucket truck (a line/seal ruptured causing
loss of hydraulic oil).
We
have been told that the power will likely
be off again on Wednesday,
27, 2019 while the utility continues work.
NOTE: When
work resumes, we will NOT be
allowed on-site, or be allowed to use a UPS or generator to back the
site up because the utility crew wants there to be ZERO
chance of inadvertent back-feed that might energize the lines on which
they are working!
It is hoped - but not
guaranteed - that the work will be completed during this day (27
November).
WebSDR1 temporarily down:
Unfortunately,
WebSDR #1 (Yellow)
did not recover on its own: Its power supply was damaged -
possibly by a glitch when the power went up/down and will have to be
repaired/replaced.
Backup receivers 80 and 40 meters
on WebSDR3 (blue):
In the meantime - at least while we are working on WebSDR1
and
the power is on - use the back-up 80/75 and 40 meter receivers on
WebSDR3.
Coverage expanded on WebSDR #3 (Blue):
90/80M:
The bandwidth of this receiver has been increased from 1024
kHz
to 1536 kHz and the center frequency shifted upward to 4000 kHz.
The coverage of this band is now 3712 kHz through 4718 kHz
meaning that it now overlaps with the low end of the 60M receiver on
WebSDR #1.
41/40M:
The bandwidth of this receiver has been increased from 1024
kHz
to 1536 kHz and the center frequency shifted upward to 7500 kHz.
The coverage of this band is now 6732 kHz through 8268 kHz
meaning that it now overlaps with the top end of the 60M receiver on
WebSDR #1.
These
changes were made as a result of suggestions made by some participants
on the 2019 Survey to provide additional coverage of commercial,
military, utility, broadcast and "mystery" users in these frequency
ranges: You may read the results of this survey HERE.
Please note that
the performance/sensitivity of these receivers is optimized for the 80
meter (3500-4000 kHz)
and 40 meter (7000-7300
kHz) amateur bands: The
sensitivity will degrade outside these bands.
First two "bands" swapped on
WebSDR #1 (Yellow):
The
positions of the "AM-160M-120M" and "160M" bands on WebSDR #1 were
swapped. This was done so that if one manually entered a 160
meter frequency it would more likely jump to the "160M" receiver,
rather than the "AM-160M-120M" receiver as had happened before.
Network outage: The
Internet connectivity - but not power - to the WebSDR's remote site was
lost for just short an hour in the morning, not related to the power
issues - a likely consequence of weather plus the
"remote-ness" of the site itself.
24 November, 2019:
Typos fixed in web page scripts - Waterfall issues on WebSDR1
resolved.
In the 25 August, 2019 (and possibly other)
entries I mentioned the erratic waterfall on WebSDR1. This
morning I finally got some time to carefully go through the scripting
using some debugging tools and noticed two (apparent)
typos in the WebSDR1 code that were causing the HTML/Javascript parser
to throw errors. While none of these actually "broke"
anything,
the errors caused the parser to "pause" briefly for a couple hundred
milliseconds, a couple of times per second. The result of
this
was that the waterfall was a bit erratic at times - and while the
higher priority of the audio stream took precedence, it's possible that
this also made the audio stream a bit more "fragile" than it otherwise
would be, possibly increasing the probability of audio drop-outs when
the Internet was busy. Another typo was found on WebSDR2, but
this hadn't had any discernible effect on performance.
The errors were fixed and the
waterfall issues on WebSDR1 seem to have disappeared.
23 November, 2019 - Web
server issues - Blank screen and/or "This Page not secure" warnings:
Some updates were made on the
main web server (not
the WebSDRs themselves) and some there were some
unexpected results - namely the web server automatically reverted to
"Make everything
use 'https' (secure)
web connections". This "broke" the links to the WebSDR
servers themselves as they cannot
use "http" - the "insecure" connection mode. It took a little
while to figure out what had changed and fix it.
A "blank" page: Unfortunately,
if you had tried to connect to the WebSDR via the landing page during
this time your browser's cache would have included the instructions to
use "https" - and this is not easily purged by simply refreshing the
web page. In some cases, simply closing the browser and
restarting it will "fix" it, but in most cases it is required that one
purge the browser's cache by doing into the browsers "options" menu.
It should be noted that this
problem did not/has not affected only
the Northern Utah WebSDR, but many other WebSDRs have been "victims" of
this browser behavior where attempting to go to the WebSDR will result
in nothing happening - but this is also fixed by clearing the
browser cache.
"This Web Page is not secure"
warning:
In some cases, you may have gotten this type of warning where
you
could allow an exception to this rule. If you keep getting
this,
try closing/restarting the browser - but if this doesn't work, clear
the browser's cache.
Update - 23 November,
2019:
It's unclear whether or not the
power utility has finished the work - but we are suspecting that they probably have not.
When one of our correspondents spoke with the line crew, it
was indicated that they would try
be done by Friday, 22 November, but there was some question as to
whether all of the materiel required to complete the job would be
available to fit this schedule. Because the "final" work was
expected to cause an extended outage - and we didn't see one - we are
presuming, pending official word, that the final work remains to be
done and that we can still expect one or more extended outages.
Because of the upcoming
Thanksgiving Holiday week in the U.S.,
it is possible that the completion may be further-delayed - but this is
conjecture since we have no easy means of checking with the crew.
18 November, 2019.
Utility Power Interruption:
What happened today: Work
began on the power feed to the Northern Utah WebSDR site and power was
cut for a while to facilitate that work. For various reasons,
we
didn't get prior notice of this work or else we'd at least have posted
a notice.
To make sure things would
recover correctly (they
didn't!) one of the local hams visited the site and found
three problems:
Failed circuit breaker.
When the room was entered, a loud buzz was heard and it was
discovered that the circuit breaker feeding the radio gear had started
to burn up. This breaker was swapped with an on-site spare.
WebSDR 3 would not power up.
WebSDR3 wasn't powering up and it was discovered that the IEC
power cord on the power supply had oxidized and had partially melted.
A new cord restored the service.
One of the KiwiSDRs
had not recovered. Likely
because the utility power did not come up "cleanly", one of the three
on-site KiwiSDRs was stuck in a boot cycle. A "proper" power
cycle restored operation.
What is happening: The
local power utility has begun a replacement/upgrade of the spur power
line feeding the Northern Utah WebSDR site. This power feed
is
very old and obsolete, providing the site with "unregulated" power
between about 90 and 140 volts: The power has been fed
via two legs of a 4160 volt open-delta feed - and if you know
about these things, you'll begin to understand why this upgrade is
being done. Due to future needs in the vicinity, the line is
being upgraded to a modern 12kV circuit.
What is being done: Because
everything
is being replaced - with the possible exception of some of the poles -
power may be on/off for several days, and since there are no
residentical customers on this circuit, the power company may simply
de-energize the circuit until the work is complete.
Will the WebSDR be up? Because
of the duration, the use of a UPS is not really practical, but we may
try to apply generator power. Because this site is quite
remote,
frequent tending of a generator to feed it gas is a bit onerous and
even if we are able to do this, there may still be interruptions.
Please expect lengthy
interruptions!
Computers are computers:
Whenever computers or networking gear are
power-interrupted, there is some
chance that something may not recover due to "improper shutdown",
voltage transients, or possible stressing of a piece of hardware.
We will deal with that as we are able, but recovery from such
events may take a while.
When will this be complete?
We
have been told by the utility that the work is expected to be completed
by Friday, 22 November, 2019 - but due to equipment availablility (such as new transformers)
work may take longer than this.
Remember:This circuit has no
residential or commercial customers per-se, so it is likely that the
utility power will be offline for days at a time during the transition
as the old, obsolete gear is removed and more modern gear is installed.
9 November, 2019.
Maintenance items:
Bandpass filters on 15 and 10
meter receivers retuned and levels adjusted.Using
a vector network analyzer, the bandpass filters on the 15 and 10 meter
receivers were readjusted for maximum flatness across the amateur band
frequencies and this results in a more "even" waterfall - particularly
on 10 meters. In both cases some component values had to be
adjusted
for the desired result. The levels were also tweaked a bit,
adjusting
for the compromise of the lowest input signal that would "tickle" a
sufficient number of A/D converter bits (these bands use RTL-SDR dongles
with frequency converters)
to work well under very weak-signal conditions, yet allow for a
reasonably strong total amount of signal power. These
receivers will
now tolerate a bit over -46dBm (roughly
"40 over")
before they might go into overload. In the future, these
bands will be
equipped with the same AGC blocks that are now in use on the 90-80, 60,
41-40 and 30 meter receivers which will prevent them from overloading
in the presence of many strong signals - which will hopefully happen in
the next few years as the new sunspot cycle starts to come up and these
higher bands have better propagation.
Modification of main splitter
networks.
One of the boxes splits the signal from the antenna between
the
"narrowband", high-performance receivers and the "wideband" receivers (e.g. AM-160-120, 90-80, 60,
41-40, 30, 25, 19 meters and the KiwiSDRs) and
it was "discovered" that the design of splitters had about 2.5dB more
loss than it should have at the highest band (10 meters)
The first splitter - which feeds all MF/HF
recdeivers and the second splitter (which
feeds all of the "wideband" receivers) were
replaced with a different design that had been verified to have lower
loss from 25 kHz through 30 MHz. This should improve
weak-signal
performance on the 17 through 10 meter bands.
12 meter signal path modified.
The absolute noise floor and the "maximum signal before
clipping"
level of the 12 meter receiver was checked and it was observed that two
much gain was present in the signal path. An amplifier was
removed,
dropping the absolute RF level by about 16 dB - but there was no loss
in ultimate sensitivity, further indicating an excess of gain.
This
effectively increased the dynamic range of this receiver by a
significant margin.
Amplifier swapped out.An
RF amplifier in the signal path to the KiwiSDRs was discovered to roll
off in gain below about 7 MHz, causing the absolute sensitivity of the
Kiwi SDR receiver to suffer - particularly on 160 and 630 meters.
An
amplifier that had
been used for 12 meters was redeployed: This amplifier has
far better signal dynamics than the previous amplifier (which had been modified to fix
the low-frequency roll-off issue) and should improve
signal performance on all of the KiwiSDR receivers. The
improvement is quite marked on 630 meters.
KiwiSDR Splitter changed.
It was noted that in testing, the four-way splitter that
feeds the three KiwiSDRs started to increase in attenuation below 1 MHz
- and since the KiwiSDR has coverage down to about 10 kHz, the extreme
low end (particularly
below 500 kHz)
was being impacted. A custom four-way splitter capable of
"flat"
response from 25 kHz to 30 MHz was installed, improving performance
below 1 MHz.
S-meter calibration readjusted on
the Server #2 (green).
With
the above changes, the S-meter calibration was checked and readjusted.
It was also noted that the 30 meter S-meter calibration was
about
12dB
hot: This changed required a server restart, kicking everyone
off. "Fortunately", 20 meters was very dead at the time and
few
people were using it.
Comment:
There have recently been brief outages (1-2 minutes at most)
that may be caused by equipment resetting on one of the links providing
Internet connectivity to the WebSDR site itself: We are
looking
into this issue.
8
November, 2019: Apple iOS 13 audio issues:
With the recent release of Apple iOS 13 there have been
many
complaints by users about the lack of audio, particularly via web sites
that stream audio - and it would appear that users of WebSDRs and
KiwiSDRs are similarly affected. This is not a
problem with the WebSDR/KiwiSDR but an artifact of a change in iOS 13.
A quick look via a search engine will reveal many steps that
others claim to work - but, at the time of this writing, there is no
obvious single "fix". One such page detailing possible steps
to take is HERE.
If you
are able to solve this problem on your device, please let us know via
the email address on the ABOUTpage.
Try a
different browser: In at least one case, the
"Start Audio" button was present on the Chrome browser, but not the
Safari browser, so it is recommended that you try more than one browser.
Try
changing audio settings in Safari: Go into
"Preferences" and changed the setting for "When visiting other
websites" from "Stop Media with Sound" to "Allow All Auto-Play" and
reload the page.
Remember:
If you
are using Chrome or Safari, you may have to click the "Audio Start"
button just above the upper-right corner of the waterfall display - and
you can read more about that here.
UPDATE - 11
November, 2019:
Via a bit of sleuthing and with help from Gary C., we have
determined one possible cause of audio issues with Apple products.
It would seem that Apple may have made some changes in the
way
their browsers indicate their version to the WebSDR. What was
happening was that the WebSDR was not recognizing those "new"
designations and not presenting the user with special code to make
Apple products work. It was also observed that the "iOS Audio
Start" button was no longer appearing on some Apple devices and
browsers, but this change (hopefully)
has fixed that. If you are using an Apple product and still
having issues with the WebSDR, please email us using the link on the "About"
page.
30
October, 2019. "White screen" when trying to go the WebSDR if
their browser was already in HTTPs mode:
We
have been getting occasional reports of users getting just a white
screen when clicking on the links to the Northern Utah WebSDR servers
themselves - in other words, the main page would load, but nothing
happened when one tried to listen. Because we hadn't seen
this
issue and could not replicate it, we didn't know what was happening
until "Tom" figured it out and passed along the information.
Here's what was happening:
The Northern Utah WebSDR's
"landing page"
(sdrutah.org)can,
but does not require, the use of "secure HTTP" (e.g. "https").
If a user arrived at the
landing page with their browser in "https" (secure) mode and
tried to go to a WebSDR server to listen, there was a problem:
The WebSDR servers themselves currently cannot use https -
and directing from a secure page (https)to an the
WebSDR servers themselves (not
"secure" - running only http)
would cause the browser to see this as a potential security issue and
prevent the page from loading - often with no obvious error unless one
dug around inside the browser's debugger.
To be clear: If the
user had already arrived at the site in normal "http" mode (e.g. "http://sdrutah.org"),
there would not have
been an issue in the first place.
Pretty much all other
WebSDR sites use only
"http" mode. When we talk about "http" being "not secure"
this simply means that you would not
want to use this mode to conduct transactions that require encrypting -
like passwords, banking, personal info: The WebSDRs are, by
their very definition, "public"
and no credentials are required, so this is not an issue.
In other words, if you had gone
to "http://sdrutah.org" (rather
than "https://sdrutah.org" - which may be the default of some browsers)it is likely that you - like most
users - would not have ever
seen a problem.
Work-around: The
links on the main "sdrutah.org" page now explicitly use "http" to
direct users to the WebSDR pages. This change should be
transparent to most users - although it is possible that some
browsers/firewalls may flag this: If this happens, simply
allow
the site as part of your "trusted zone".
26 October, 2019.
Network outage:
At
approximately 0137 MT on this day the connectivity to the Northern Utah
WebSDR was lost: It appears to be a problem at one of the
(several) wireless "hops".
Update: 0950 MT:
One of the main wireless Internet trunks (on a licensed frequency)
is offline, apparently affecting the feeds to several broadcast
stations as well. It is being worked on.
Update: 1020 MT:
The Internet connection is back up.
10 October, 2019.
Added "manual" gain control:
A manual gain control - just
below the volume control - has been added to the WebSDR interface.
The default is "AGC
On" in which the gain is automatically controlled by the
amount of signal within the receive passband.
In
manual mode, a slider is made accessible and the overall gain may be
adjusted from minimum to maximum by moving the pointer to the left or
right, respectively.
When in manual mode, please
note the following:
Too little gain:
The audio will be very quiet and accompanied by lower-level
noise and distortion.
Too much gain:
The audio will be distorted badly/noisy, particularly on
signal peaks and static crashes.
PLEASE NOTE:
The signal levels on
HF can vary by 10s of deciBels
which means that a satisfactory manual setting can become
"unsatisfactory" very quickly - particularly between different
stations. For this reason, the manual gain control is most
likely
to be useful on local nets and/or under conditions where the
propagation is very
stable.
You will probably have to
"ride" the manual gain control if you choose to use it.
When in doubt, always use AGC On mode.
28/29 September, 2019.
Power failure!
Caused by severe weather, there
was a widespread power failure in parts of northern Utah (Box Elder county)
that included
the WebSDR site and the sites of some of the
Internet
hops and the duration of this power failure was long-lasting,
exceeding the capability of most UPS (battery back-up)
systems.
As
of the morning of 29 September, it is believed that the power has been
restored to most of the sites involved, but it is not sure that this is
the case - and it may be that not all Internet gear has recovered
gracefully, so one or more site visits may be required to verify the
presence of utility power and diagnose/restore lingering issues.
Because of the remote-ness of the locations involved, it will
take some time to do this.
It
would appear that the extended power failure didn't actually affect the
WebSDR site itself, but rather one of the "hops" for the Internet
connection, which did not come back up gracefully. The
connectivity was restored approximately 12 hours after it was
lost.
25 August, 2019.
Comments:
Slow/erratic waterfall problem on WebSDR1 now fixed - TWO
issues noted:
HTML updated: The
above change didn't actually solve the problem, but a bit of
testing revealed that there was some sort of typo in the underlying
HTML used on WebSDR1 that had been the cause of the waterfall issues -
but not serious enough to actually show up with the debugging tools
built into a browser. The debugging was done by copying the
version of
the suspect HTML from WebSDR2 (where
things worked fine) to a test file on WebSDR1 and
observing that it worked properly, so the (minor)
modifications that are specific to each WebSDR were made to this copy
and dropped into place on WebSDR1. Note that a "reload"
doesn't load
the fixed code, but closing the browser (or just the tab with WebSDR1)
and opening it again does
load the fix. (No,
I didn't bother to go through the two files and do a comparison to see
where the problem really
was...)
Another Issue:
It was observed that running some Ad Blockers on the WebSDR
pages
seems to cause its own problem with the waterfall. At the moment
there are no advertisements on the WebSDRs themselves - but various
other scripts (e.g.
weather station reporting, perhaps one of the "widgets" at the bottom
of the page)
seems to interfere with the timing of the waterfall causing it to move
in fits and starts. If the waterfalls' being a bit jerky
bothers
you, consider disabling the ad blocker on the WebSDR main interface
page.
18 August, 2019.
Comments:
Slow/erratic waterfall
on WebSDR1 (Yellow):
It
was noticed that, for the past "little while" that the waterfall
scrolling on WebSDR1 was a bit erratic/slow when there were 50+ users -
something that was not true several months ago: This was likely
not related to network connectivity or processor loading as this was
not occurring on
WebSDR2 or WebSDR3. On a hunch, the WebSDR service on WebSDR1
was
stopped and the log files - some of which were approaching half a
gigabyte - were renamed so that the WebSDR service - and the operating
system - did not have to deal with such large file structures.
As
of the time of this writing, it is not known if this "fixed" the
issue... yet...
5 August, 2019.
Comments:
On-site power failure:
Likely due to very intense
local thunderstorms (there
were many in the area then!) the utility power at the
WebSDR site was off for an hour between approximately 2305 (on August 4) and
0010 local time - and since there is no UPS currently on-site (see notes on 31 July site visit)
there was no way to provide back-up power.
It's worth noting that the UPS,
had it been working, would have only provided 40-50 minutes of back-up,
anyway, so there would still
have been an outage. As far as can be determined, everything
came up automatically and is working again.
4 August, 2019.
Comment:
Intermittent overload
on the "AM-160M-120M" band:
It has been observed that the "AM-160M-120M" band
is being overloaded at time. It would appear that one of the
single-frequency notch filter (specifically,
the one tuned to 1160 kHz)
is suffering some sort of intermittent connection: When this
notch filter is working properly, the signal level at this frequency
should be in the area of -48dBm - but when this notch is non-functional
that signal may exceed -30dBm, causing overload of the analog/digital
converter in this receiver.
IMPORTANT:
If you have been using this receiver for 160 meters, it is
recommended that you use the dedicated "160M"
receiver, instead: It is completely different hardware and it
is
unaffected by this issue - and this receiver has higher performance,
anyway.
Why are there two receivers
that cover the 160 meter band, anyway? Why not - the hardware
for the "AM-160M-120M"
receiver is capable of working over a 2 MHz range, so allowing some
overlap was trivial - and the dedicated 160M receiver misses the top
and bottom 4-5 kHz of the 160 meter band.
31 July, 2019.
Comments:
Site visit:
Main 12 volt supply
replaced. The
ailing 12 volt supply that runs the all of the softrock receivers and
RF amplification has been replaced with a heavier-duty commercial unit
that has also been equipped with - but does not rely on - a cooling
fan. This has restored the gain of the various amplifiers in
the
signal paths and gotten rid of the strong hum components in the center
of the 160, 17 and 12 meter receivers.
Cooling fans replaced on
KiwiSDRs. The
original fans that had come with the KiwiSDRs' metal cases were of
rather poor quality and out of four receivers owned, all four fans had
failed after about a year. Name-brand ball-bearing fans were
located and installed.
Pre-processing for KiwiSDRs
changed: To account of the differing dynamics of
the HF bands over its frequency range (e.g. lower HF frequencies are
noisier and signals are generally stronger than on the high end)
a "limited attenuation high-pass filter" had been constructed to reduce
signal levels below approximately 10 MHz by about 12dB (e.g. 2 "S" units)
to prevent overload when strong, lower-frequency signals were present -
particularly when additional gain (10-12dB)
was added. The original filter attenuated all
of these lower signals, but a new filter was constructed that provided
the same attenuation below about 10 MHz, but offered minimal
attenuation below the AM broadcast band to restore sensitivity at these
lower frequencies where the main receive antenna is already rolling off.
UPS issues: It
was noted on a previous visit that the UPS had failed, but
further investigation revealed that a transfer switch used to allow
swapping out the UPS - or adding a second unit - had "welded" a
contact and that when the UPS was active, its input was connected it
its output, damaging the UPS. The UPS and transfer switch
have
been retrieved and repair or replacement (as appropriate)
will follow. The entire system had to be powered down to
remove the transfer switch.
LF/MF power supply repaired:
The power supply that fed the signal path for
below approximately 400 kHz (on
the KiwiSDRs - and 2200 meters on WebSDR3)was
repaired. There are still some issues with the LF/MF antenna
that feeds this signal path that will be addressed on a later visit,
but it is working - more or less. Initial indications are
that
the receivers are working about as before on 2200 meters, but
additional work is needed to optimize performance.
80CW/40CW bands swapped:
It
was observed that these two bands were swapped. It seems that
these to bands transposed themselves: It is unknown if this
happened today, or a few days ago when it was discovered that the UPS
had failed and an unplanned power outage had occurred. These
two
bands have the same model USB sound card and this is no doubt related
to the fact that USB enumeration becomes "flaky" when you have more
that one of the same-type device: Usually, using the same
physical port keeps things in order - but apparently that doesn't always work.
27 July, 2019.
Comment:
Main bus undervolt and
degradation of receivers:
A
few days ago it was observed that the gain of the "broadband" signal
path had decreased - an issue manifest by a noted drop in gain of the
"AM-160-120M", 15 and 10 meter receivers and an across-the-board gain
of the KiwiSDRs plus the appearance of strong mains-frequency hum in
the middle of the passbands of the 160M, 17M and 12M receivers.
On a brief site visit the main 12 volt bus voltage was
checked
and it was found to be about 8 volts with a significant amount of AC
mains ripple on it - explaining both the loss of gain due to voltage
reduction of several RF amplifiers and the hum on the 160M, 17M and 12M
receivers.
Inspection
of the main 12 volt power supply indicated a "semi-catastrophic"
failure of several key components - but much to our amazement, it was
still working... sort of. An attempt was made to reconfigure
the
power supply to help it along, but the parts/pieces were not on-hand
for this impromptu visit: This condition - which appeared
almost
a week ago - will have to remain until we can get a new power supply on
site.
In this current state, all
of the receivers are at least slightly affected, but the impact on most
of the receivers is difficult to discern because the signal marginwas just adequate (from the beginning, by design)
to be able to tolerate some amount of degradation.
The power supply for the MF/LF
signal path was repaired, restoring service.
It
is unfortunate that the testing of the power supply had to occur at a
time that concided with the Utah Beehive net - we are sorry
for
the inconvenience.
26 July, 2019.
Comment:
Web Server offline:
For
several hours today the "sdrutah.org" web page was inaccessible during
several outages - some of them quite long: This issue did not
affect the WebSDRs themselves - only the "landing page". This
is
a follow-on
problem from the July 18 operating system by the web hosting service:
Apparently, they've had their hands full, having
mis-configured
something when they did updates of their customers' servers - and they
now
going back and fixing the issues.
22 July, 2019.
Comment:
MF/LF Signal Path
offline:
It would appear that the signal path that provides signals at
frequencies below approximately 400 kHz is offline - the cause is
unknown. What this means is that 2200 Meter receiver is deaf
and
signal below approximately 400 kHz are not present on the KiwiSDR
receivers. This issue will be addressed on a future site
visit.
19 July, 2019.
Comments:
Quick site visit:
KiwiSDR1 and KiwiSDR2 had gone offline due to fan
failures and heat. All three KiwiSDR units were relocated to
a lower location (because
heat rises!)
and their top covers removed. The fans in their cases were
inexpensive sleeve-types: They are to be replaced with
better-quality ball-bearing types on a future visit.
Flaky cable on KiwiSDR3:
It was observed that the antenna cable feeding KiwiSDR3 was
intermittent. A spare was on-hand and the problem was fixed:
The end of the flaky cable was clipped off preventing its
re-use.
UPS Failure.
While there, the UPS was checked - and it was found to have
failed. It has been removed from the circuit by virtue of an
A/B
transfer switch that allows swapping/replacing computer power sources
without interrupting the load. Unfortunately, the load was
interrupted when the UPS, trying to go online, "chattered" instead of
simply dropping out when it failed to carry the load causing all
servers to reboot - but everything came up cleanly - I think...
18 July, 2019.
Comment:
Server upgrade by web
hosting service:
On
the evening of Thursday, 18 July, 2019 at around 1800MT the
"sdrutah.org" web pages were unavailable. This situation was
temporary - lasting less than an hour - as the Web hosting service
upgraded the server from Ubuntu 14.x to 18.x. No changes
should
be visible to the users upon completion of this upgrade.
5 July, 2019.
Comments:
"Bug" fixes on new pages.
Initially,
with the new pages it was not possible to embed the frequency and mode
with the URL, but that has been fixed now - we hope. You can
now
include the frequency and mode if you like, as in: http://sdrutah.org/websdr1.html?tune=7272lsb
- which will go to WebSDR #1 and tune to
7272 kHz, lower sideband.
The redirect did not previously
work with the Microsoft
Edge browser: It appears to do so now.
The "buttons" on the WebSDR GUI
(page)
that
sent you to another WebSDR server to cover a different band had
been "kludged" to work with the new scheme - but they didn't really do
what they were supposed to
do - which was to send the user to the "new" web pages - because of the
inability to embed the frequency and mode in the URL: They do
now!
Low gain on the KiwiSDRs below
500 kHz.
It
has been observed that at frequencies below the AM broadcast band, the
KiwiSDR is a bit "gain starved" - a result of the "Limited attenuation
high-pass filter" that had previously been installed to prevent it from
being overloaded on signals below 8 MHz. At some future
visit,
this filter will be modified to "pass around" such frequencies.
For more
information about this high pass filter, read the article "A Limited Attenuation High-Pass
Filter for the KiwiSDR". This
article does not yet include information about the modification to
allow the <500 kHz energy to pass through.
19 June, 2019.
Comments:
Internet connectivity
issues!
The
Internet connectivity has, at times, been suffering from jitter and
delays - a likely result of ongoing issues with one of the wireless
hops connecting the site. To remedy this situation, we will
be
transitioning to a different Internet Service Provider. Because of
this, there
will be an interruption to this WebSDR system
during the transition. The exact timing of this change is yet
to
be determined: Additionally, there may be the complication of
this system needing to change its URL. We will
attempt to give as much notice as possible prior to this change. In the
meantime, occasional drop-outs may be mitigated by increasing the
buffering using the Audio
Buffering drop-down menu just below the WebSDR's volume
control.
The "loss" of reception on the "20CW", "20PH", "17M", "15M",
"12M", and
"10M"
bands was, as suspected, caused by damage to the amplifier common to
all of these receivers. This amplifier, based on a Gali-74+
MMIC,
proved to be susceptible to what was, at the very least, a "close"
lightning strike. The MMIC was replaced and reception was
restored on these receivers.
In reality, none of these
receivers suffered any damage and remote analysis had shown that these
receivers were just really
deaf - to the tune of 30-40dB or so.
"160M" preamplifier
repaired:
The
"160M" receiver was also preceded by one of these same Gali-74+ MMIC
modules
and this amplifier, too, was damaged by the same strike. A
replacement of
this MMIC restored this device to normal operation.
Additional lightning
protection added:
The
above damage to the amplifiers occurred despite the fact that these
were "downstream" of fairly heavy-duty gas discharge tubes andRF
filtering - both of which would have served to greatly reduce the
amount of transient energy from the strike - but it wasn't apparently
enough for the
MMIC amplifiers. To prevent a similar failure in the future,
a
more "sensitive" protection device was added - one that has both a
gas-discharge tube and
high-current limiting diodes.
It's
worth noting that in the other signal paths, discrete transistor-based
RF
amplifiers - based on the venerable 2N5109 - are being used, and none
of these suffered any damage, likely due to the fact that this rather
rugged device can (briefly)handle several watts without
damage.
The Gali-74+ is used in some of
the signal paths because of its lower noise figure (3 dB versus 6 dB)
and higher gain (21 dB
versus 17dB) than the 2N5109-based amplifiers.
In the "High
split" signal path (for
20-10 meters)
these devices allow the receivers to "hear" the thermal noise floor
more easily, particularly on 10 meters.
Using
one of these devices on 160 meters helps make up for the
relative deafness of the receiver module (a SoftRock II Ensemble) that
is being used and the
fact that the main antenna, which is designed for 3-30 MHz coverage,
has lower signal output at 160 meters than on 80/75 meters.
40 meter receiver modified:
Previously, a single RF
amplifier was used to feed both the "40CW"
and "40PH"receivers
- and internal to this module, the input signal was split
two ways to feed the two softrock boards. After this receiver
had
been built it was determined, during the construction of the modules
for 80/75 and 20 meters, that the best performance was obtained
by using separate amplifiers for each, individual softrock board - each
amplifier following the outputs of the internal RF splitter:
Doing this greatly reduced
the amount of
local-oscillator crosstalk between the two receivers which can, in some
cases, cause low-level spurious signals to appear in the presence of
very strong signals.
To
this end, a pair of RF amplifiers - one for each receiver - was added
to the existing circuitry, inside the receiver module's box.
This
adds 3-4 dB to the noise figure of the receiver because these
amplifiers are now subject to post-splitter loss, but this factor is
unimportant on 40 meters owing to the naturally-high noise and signal
levels.
Reconfiguring
this amplifier freed one of the "general purpose" amplifier blocks
allowing us to replace a "temporary" amplifier that had been built for
the 17 meter receiver, helping to clean up the layout a bit.
Sound cards replaced:
As noted in the 1 May entry,
the USB sound cards that had been used for "40CW" and "40PH"
failed - apparently succombing to the same fate as is common with Asus
Xonar U5 and U7 sound cards. These two cards - a U5 and U7 -
were
replaced with a pair of U7s. The failed cards will be
analyzed to
attempt to determine a "fix".
At the moment, the "40PH"
receiver is still using a Xonar D1 which has someone inferior image
rejection as compared to the U5 or U7 - but it was decided to do this
in case a USB sound card fails (again!)
so that the risk of losing coverage of 40 meter phone - one of the most
popular bands - will be minimized.
Turnbuckles secured:
It had been observed on a
previous visit that one of the guy wires on the recently-replaced
deadman (on the tower
supporting the log-periodic beam)
had unscrewed itself - a clear result of our not having remembered to
add "safety wires" to prevent this. Because of the limited
cable
length, it had not been possible for a single individual to reconnect
this without proper tools, but with several people on-hand for this
visit we could, collectively, pull just
hard
enough to engage the turnbuckle threads.
Safety wires have been
run through all of the turnbuckles to assure that this will not happen
again. With the (temporary)
loss of this cable, the integrity of the tower was in no real danger -
but it needed to be taken care of, just the same!
8 May, 2019.
Comments:
"When
it rains, it pours - and flashes lightning!"
"160M", "20CW",
"20PH", "17M", "15M", "12M" and "10M" receivers offline.
Due to an apparent lightning
strike, the receivers listed above are offline (extremely deaf, actually).
This strike apparently wiped out two RF amplifiers in the
signal path: The one for the "160M" receiver, and
another amplifier that provides gain for all amateur bands above 30
meters.
In the meantime, the "AM-160M-120M"
receiver can provide a degree of coverage for 160 meters.
Unfortunately, there is no
similar back-up for the 20-10 meter bands' receivers.
It
will likely take a site visit to restore operation and it is expected
that this will occur in the next 3-5 days. In theory, these
amplifiers could be bypassed to restore some semblance of operation,
but
this is unlikely to happen before a "proper" site visit might occur.
1 May, 2019.
Comments:
Sound card failures:
Unrelated
to other issues, it would appear that there has been a failure either
in two of the three USB sound cards on WebSDR1, or something amiss with
the USB interface on the motherboard. In the past, we "lost"
one
of these sound cards in a similar manner: Everything was fine
until the system was restarted, at which point the sound card refused
to operate at the higher speed (e.g.
USB 2.0) necessary for full 192 kHz band coverage.
In doing research, this type of
failure has
been documented elsewhere, so it is not unprecedented.
As
a "work-around", the "80CW" sound card is now being used for "40PH",
restoring full coverage of the SSB segment of that band.
Unfortunately, image performance will suffer slightly because
a
"I/Q Balance" equalization could not be done - but this will go
unnoticed in the majority of cases.
The
"80CW" and "40CW" are using the "failed" hardware, but since it can
operate only at 48 kHz, the coverage of those bands is limited.
For coverage of the missing 80CW
and 40CW segments use the back-up "90-80M" and "41-40M"
receivers on WebSDR3 in the meantime.
A site visit to repair/replace
the errant hardware will likely occur within a week of this date.
Firefox issues
revisited - Audio stream stopping when a new tab is opened in the
browser:
As noted below (see 8 April entry)
there is a known problem with the Firefox browser: Clicking
on a link to open a new tab may
cause the audio stream from the WebSDR to stop.
This issue has been reported to
Mozilla and it is believed that a "fix" is in the works.
If the audio stops because you
have opened a new tab, there is currently no known way
to restart the audio short of refreshing the web page.
Unfortunately, this may reset the frequency/mode, requiring
one to re-tune the radio.
If at all possible,
open a link using a "right click" and select "open a new tab":
For whatever reason this seems less likely to interrupt the
audio
stream.
29 April, 2019.
Comments:
WebSDR system offline:
The
WebSDR system was offline for around a day due to some issues with the
server - possibly caused by nefarious activity. Because the
main
"WebSDR guy" (me!) happened
to be on vacation when this happened, it was a day or so before one of
our "alternate" operators noticed and restarted the system.
"40CW" and "40PH" bands semi
off-line - running at reduced bandwidth:
Not directly related
to the above issue, the
sound cards for the "40CW"
and "40PH"
bands are refusing to initialize properly after a system restart.
This is a known hardware/software "bug", but it seems to show
up
only rarely. At the very least, the server will need to be
completely powered-down, requiring a site visit.
The
initial symptom of this was "cutting out" of the audio until these
cards were reinitialized for 48 kHz bandwidth - but this has the
side-effect of allowing only
1/4 of the previous band coverage.
UNTIL THIS PROBLEM IS RESOLVED,
please use the back-up "41-40M" receiver on WebSDR3.
While this receiver isn't quite as good as the normal
receivers, it works nearly as well under most conditions.
8 April, 2019.
Comments:
Audio stopping with Firefox when
you make the browser busy:We have become aware of an
interesting (potential)
issue with Firefox regarding audio: Sometimes the audio
stream
will stop - and not restart - if, on your browser, you open a new tab,
of if you have opened several tabs with the WebSDR running in the
background and have done something in another window/tab that has
momentarily caused your computer/browser to become busy.
The
easiest "fix" for this is to reload the web page which, unfortunately,
is likely to reset the frequency/mode to which you are listening.
We don't have any other suggestions at this time.
Little/no signal on KiwiSDR3 WebSDR3:(Note:
I meant to write "KiwiSDR3" - there was no problem with
WebSDR3). It would appear that I didn't get the
"RF Input" SMA connector
tight when working on KiwiSDR3 which means that only the strongest
signals show up at all. One of our volunteers is likely to be
in
the area in the next couple days and will (hopefully)
get time to drop by and take care of the problem.
Fortunately,
only two of the least-used WSPR "bands" are on this receiver (the now-deprecated 80 meter
frequency and one of the 60 meter frequencies) so not much
is being missed.
2 April, 2019.
Comments:
Local power outage: The
local utility is working on the lines and power to the site was lost at
0915. Because we were informed of this ahead of time (one of the local power guys
occasionally uses this WebSDR system) we were
pre-positioned and put the site on generator power when it went out,
running on UPS for only about 15 minutes, total.
Because
of the extended outage, we were on-site, tending the generator, taking
advantage of the time we are here to do other work on the system, as
noted below.
Off
in the distance we saw the power crews working on the lines that feed
the site. In speaking with one of the utility employees - who
came by to make sure that everything had come back up - he said that
they "... did a lot of
work... replaced a lot of glass" meaning that more than
just insulators were replaced.
The
power was restored at 1755 local time - an outage of 8-2/3
hours
- a bit ahead of schedule despite the rather rainy, miserable weather.
RTL-SDR identification script
installed on WebSDR1: We have finally
installed the script on WebSDR1 that automatically identifies - via
programmed serial number - which RTL-SDR dongle is to be used for which
band.
This
script had been installed on WebSDR2 and 3 a while ago, but WebSDR1
seemed always to be too busy to interrupt everyone and restart the
system - but since there were warnings plastered all over the place
today, we thought that it would be a good opportunity.
This
script solves the problem where it would matter which RTL-SDR dongle
was plugged into which USB port - and how many dongles there were.
Because one must always use the same dongle for the same
frequency band (because
of RF filtering) it was a huge pain to make sure that all
of the dongles got sorted out right: This script eliminates
all of that mess!
17 Meter coverage expanded:The
sound card previously used for this band had a sampling rate of only 96
kHz, which meant that a bit more than 4 kHz of this band (2-3 kHz )
was left off at each end.
The new card has a 192
kHz sample rate, so the
entire band - plus several 10s of kHz beyond the top and bottom - is
now covered.
Fully-covering 12 meters will
require a bit of juggling of
hardware, but since 17 meters is open far more often than 12 during
this part of the solar cycle, 17 meters
had priority.
Log Periodic beam checked:
Despite a drizzle and a modest breeze, the 80 foot tower was
scaled and leads were clipped to the bloody-end of the remaining coax
at the top that connects to the massive 6-45 MHz log periodic beam (a Hy-Gain/U.S. Antenna Products
LP-1002) so that it could be checked: This
antenna is set on a bearing of 87 degrees (true) and is not
rotatable.
Using
an antenna analyzer, the beam was swept and the VSWR was found to be in
line with the antenna's specifications over the 6-45 MHz frequency
range.
While
not absolutely definitive, this result indicates a high probability
that this antenna is working as it should. Had any elements
been
"bad" or had there been a short/open in the open-wire line that feeds
this antenna's elements, the results would have been much different.
Because this antenna does
seem to be OK, we have even fewer excuses for not
using it - stay
tuned!
Radio/Internet link tweaked:
We have observed that the wireless Internet connection to the
site has been having intermittent issues over the past several months.
Having some time to check
things out, we noticed that over two of
the three wireless links that connect the site there were occasional
packet loss/jitter issues that were traced down to the radio's
"switching gears" (e.g.
modulation) frequently. While this is supposed
to be "loss-less" (according
to the manufacturer, at least) anyone
who uses these radios knows that this isn't strictly true: At
the
very least, this constant modulation change will cause queuing of data
and increase jitter (not
idea for streaming audio!)
and in severe cases, packet loss.
To "improve" performance, the
radios' configuration was changed so that they would not attempt
too-high a modulation method, staying at a lower, more stable rate.
This reconfiguration significantly improved one link and made
a
noticeable difference on another - which seems to have other issues
which will have to be addressed.
"40PH" and "80CW" receivers
"un-swapped": On a previous visit (see the 30 December, 2018 entry)
the "80CW" and "40PH" receivers had been swapped because it was
considered that with 40PH using a USB interface, it may have been less
reliable than the sound card. It was later noted that the
sound
card to which we had moved "40PH" had inferior out-of-band image
rejection (e.g.
less-effective low-pass filtering) than the original
USB-based card (see 24
March entry) - so it was moved back to the original USB
card.
It
was observed that despite several attempts at I-Q amplitude/phase
balancing, the in-band image rejection on the "80CW" receiver is not as
good as we'd like it
to be: This probably doesn't directly relate to the problem
mentioned above - but it might. Because this is a lesser-used
band and because the image rejection is "OK" it was decided to leave
this mystery for another day...
Because there are now (lower performance)
redundant receivers for 80/75 and 40 meters, if we experience a failure
on either of these bands on WebSDR1 we are covered!
Gain increased in the
KiwiSDR "HF" signal branch: About 9 dB of additional gain
was added in the HF signal path that feeds the KiwiSDR stack (e.g. from about 400 kHz to 30
MHz) as an experiment to improve weak-signal performance.
A bit more improvement is still needed in the LF signal path (below about 400 kHz)
but that will have to wait for a day with nicer weather.
KiwiSDR fans relubricated:
It would appear that the cooling fans in the KiwiSDR's cases
use
somewhat inferior oil/lubricant - a common complaint with inexpensive
Chinese-made fans whether they use sleeve or ball bearings.
The
fans in all three Kiwis (which
use sleeve bearings) were relubricated with a PTFE-based
oil that is known to greatly improve the lifetime of these fans.
24 March, 2019.
Comments:
Power line noise:
With
recent high winds and heavy rain, insulators on the power lines
near-ish the WebSDR site are again making some noise, most strongly in
the 2.5 and 5 MHz area. While this noise is occasionally
audible
on 160, 80, 60 and 40 meters during daylight hours, it is usually
inaudible at night when these bands typically get noisier -
particularly as the summer season approaches. We continue to
work
with the local power company to minimize this issue.
Update on RTL-SDR "gain block" (see 26 February entry):
Now
that the AGC circuits for the RTL-SDR receivers for the 90-80, 60,
41-40 and 31-30 meter bands have been in use for about a month, I'm
pleased to report that the results have been very good:
These
modules have been very successful in preventing overload from strong
signals on those bands while allowing enough system gain for good
weak-signal performance.
It
would appear that the 31-30 meter module needs a couple dB more signal
gain during "quiet" periods when the bands are closed or in poor
condition.
The bandpass filters used for
90-80, 60 and 41-40 meters may be replaced with "tighter" versions (same bandwidth, stronger
"skirts" to better-reject other signals) - just because I
can, but this is not a high priority project.
I
may adjust the AGC threshold from the current setting of about 40% A/D
full-scale - which seems to be working fine - to 25% full-scale so that
I can observe the results to see if there are any improvements.
As expected, there are some
RMDR-like issues with weak signals on the RTL-SDR based receivers (e.g.
weak signals "seem" slightly noisier than they should be, particularly
if there are strong signals within the receiver's RF passband)
but these are only apparent in an "A/B" comparison between an RTL-SDR
receiver and one of the "High Performance" Softrock-based receivers:
The casual operator would likely not notice this.
This is,
no doubt, largely a result of the limited bit depth of the RTL-SDR
receivers.
6 Meter receiver: So far, the 6 meter
receiver is behaving itself after the 14 March reset.
40 meter images:
It was noted that some images have been appearing at the low
end of the 40 PH
receiver from strong signals above its
coverage range.
For example, an SWBC carrier
can sometimes be heard at 7133 kHz from a signal at 7325 kHz:
7325 kHz is 8 kHz above
the opt of the 40 PH receiver (which
is at 7317 kHz) and this image is therefore 8 kHz above
the bottom end of this receiver (at
7125 kHz).
This defect is due to the lack
of a perfect "brick wall" filter above the 96 kHz Nyquist frequency (with the 192 kHz sample rate)
"wrapping around" and appearing at the bottom.
This issues was not
known to occur prior to the 30 December "hardware shuffle" where the
sound card that had been used for 80CW was swapped with that used for
40PH. It would appear that the "old" sound card was more
resistant to this aliasing.
We
plan to "re-swap" the sound cards on the next site visit because of the
larger overlap on 80 meters and the lack of very strong SWBC signals on
80/75 meters (as
compared to 40 meters)
which means that not only should this problem be less likely occur on
80CW, but the larger overlap allows user to "dodge" such aliasing
should it occur.
The
actual suppression of this image appears to be on the order of just
12dB - increasing to 50dB by the time one gets to 136 kHz (which correlates to 7355 kHz)
- which is much poorer than expected and why we plan to make this
hardware swap.
14 March, 2019.
Comments:
6 meter receiver
offline (WebSDR2 - Green): It
was noticed today that the 6 meter receiver is currently offline.
An attempt was made to restart the driver, but this attempt
failed with errors indicating that something was amiss with the
receiver hardware itself.
A server restart will be
attempted in the late evening when there is typically little use on the
Green WebSDR (#2).
This receiver uses an
inexpensive ($20)
RTL-SDR dongle, so replacing it won't be a big deal - except for the 3
hour round trip drive to do so! It is likely that replacement
will simply wait until the next trip to the site to do other work,
which will likely not occur until early April at the soonest - unless
something else breaks!
Update - 6 meter receiver back
online:
After
a restart of the WebSDR service failed to bring the 6 meter receiver
back online, WebSDR2 (Green) was rebooted remotely: This
seems to
have restored operation of the 6 meter receiver... for now...
27 February, 2019.
Comments:
Added "Mode" indicator:
Something
that had been bugging me from the time we put the WebSDR online was the
fact that may not have been obvious what "mode" (LSB, USB, CW, FM, AM)
had been selected: The only way to "see" this was to take a
close
look at the size and position of the shape of the filter on the
waterfall display - or one could simply click on a mode button to know
for sure. I finally
got around to adding a "Mode" indicator which can be seen just to the
right of the frequency display - where it belongs.
Analysis of the RTL-SDR "gain
block":
Initial indications are that the AGC gain block for the
90-80M,
60M, 41-40M and 30M RTL-SDR based receivers are working exactly as
expected. As we move into summer we'll see how it behaves in
the
presence of lightning static.
26 February, 2019.
Comments:
Kiwis offline:
A
site visit was made, noting that the KiwiSDRs had been offline for
about a day, apparently due to crowbarring of the power supply.
On the next visit modifications will be made to the supply
that
will (hopefully) make it more resistant to this.
Maximum number of users increased:
For WebSDR1 (the "Yellow" one)
the maximum number of allowed users has been increased from 90 to 125.
This should (for
the time being)alleviate
the denials of service that one might have been getting
during very heavy usage periods. In the next "month or two"
the
Internet connection to the WebSDR system will be changed to one that is
(hopefully)
more robust and further increases in the number of users can be
accommodated.
Oops: A
previous modification - replacing an amplifier in the early stages of
the broadband branch- was undone. It had been noticed that
this
amplifier (a MMIC type),
which had been replaced to provide a bit more gain and lower system
noise figure (again,
for the broadband branch)
was causing low-level intermod and the problem was assumed to be
overdriving of the subsequent stage. When a gain adjust was
added
after this "new" amplifier the problem did not diminish and several
weak spurious signals were seen drifting through the 0-30 MHz passband
from this branch indicating that this amplifier was oscillating -
likely at VHF/UHF - and was likely responsible for the problems.
Unfortunately, this could not be tamed with components
on-hand so
the previous known-stable bipolar amplifier was re-installed.
"New" Bands - "90-80M" and
"41-40M",
improvements to 60 and 30 meters: A
newly designed and built module containing four bandpass filters, each
followed by a wideband AGC gain block was installed in front of four
RTL-SDR based receivers on 60 and 30 meter bands. Two "new"
bands
were installed at this time on the "blue" server (WebSDR #3)
- 90-80 Meters and 41-40 Meters.
These cover all of the 80 and
40
meter bands, respectively, but also their adjacent SWBC bands, namely
41 and 90 meters.
These "bands" provide a usable
"back up" for the popular bands (80/75
and 40 meters): In
the event that
WebSDR1 were to go offline and could not be restored remotely we would
point users to WebSDR3 where it is likely that they could operate as
normal.
Being
RTL-SDR based they are considered to be "low performance" receivers -
but they should be "good enough" for casual use when signals are
reasonably good.
The
AGC gain block in front of each of the respective RTL-SDRs is designed
to prevent the RTL-SDRs from "seeing" signals that average more than
about 1/2 full-scale on their A/D converters, which should prevent
overload. The use of this module also allows these dongles to
be
run a bit "hotter" than on normally would, improving their performance
when the bands are "quiet" with the AGC preventing overload when very
strong signals (mostly
shortwave broadcast) are present.
These modules will be described in more detail, soon.
The
60 meter receiver also runs through an AGC gain block allowing its
sensitivity to be increased while preventing it from being overloaded
by strong SWBC stations.
The
30 meter receiver has a newer, "tighter" filter to improve its
performance and it also has an AGC gain block like the 60 meter
receiver which should also improve both weak and strong signal handling
properties.
21 February, 2019.
Comments:
A
modification was made to the code on all of the Northern Utah WebSDR
servers so that the default amount of audio buffering is now 0.25
seconds rather than the original 0.125 seconds buffering.
This
slight increase (by
1/8th of a second)
is likely more appropriate for real-world Internet connections and
should reduce the number of audio drop-outs. If desired, the
original value may be selected from the "Audio Buffering" drop-down
menu.
The
most common cause of audio drop-outs is the changing of the "focus" of
the operating system away from the browser window with the WebSDR.
For example, if you switch the browser to a different tab,
switch
to a different program or even minimize a browser window your computer
will dedicated fewer system resources to processing the WebSDR audio.
Slower computers are more prone to audio dropouts in this
case.
Increasing the buffer may
help this situation, but it is often a matter of the computer not
processing the data from the WebSDR often enough in its round-robin
servicing of the running applications to keep the system's audio buffer
full.
Another cause of drop-outs is
the heavy use of ones Internet connection - perhaps due to watching
videos from online services (e.g.
Netflix, Amazon, Hulu, YouTube, etc.). In this
case, more buffering will likely reduce the likelihood of drop-outs.
11 February, 2019.
KiwiSDRs offline.
It
would seem that all three KiwiSDR units on site went offline at about
1702 MST on 10 February (0002,
11 February UTC).
When
this was investigated on 11 February (at approx. 1125 MST) it was
noticed that
both halves of the redundant 5 volt linear power supply had
"crowbarred" -
that is, its overvoltage protection had tripped. Unplugging
the power
supply for 60 seconds to allow the capacitors to drain and plugging it
back in restored operation. The cause of this
crowbarring is
currently unknown: Because these supplies are in "diode-ORed"
redundant
configuration, one of the power supplies could have tripped out
earlier without being noticed. We are considering means of
remotely
monitoring/resetting this and other power devices.
29 January, 2019.
Comments:
Audio drop-out issues:
There
has, in recent days, been more data jitter on the Internet connection
to the WebSDR site: Our network guru is looking into this
problem
to see if there is a reason/fix for this. An upgrade of this
same
equipment is pending warmer weather and the availability of time to do
so.
The
control of the "additional audio buffering" has been enhanced to allow
the connection to better-deal with "flaky" connections. There is now a
drop-down menu labeled Audio
Buffering
that has several options
+0.125sec:
This uses about 1/8th of a second of audio buffering, which
works out to approximately 1/4 to 1/2 second of total delay between the
signal arriving at an antenna and you hearing it on your
computer, assuming minimal latency of the Internet and your computer's
processing.
+0.25sec:
Another 1/4 second is added to the audio buffering. This is currently the "default"
setting for buffing on this WebSDR system.
+0.5sec:
This adds another 1/2 second to the amount of audio
buffering:
This amount of extra delay is generally tolerable if you are
using the WebSDR as your primary receiver during a QSO.
+1sec: This
adds a bit more buffering - one whole second more. This amount of buffering may be
a bit painful/awkward if you are participating in a round table or net.
+2sec:
This adds two
seconds more of audio buffering. While this is fine for
casual monitoring of signals, you
probably don't want to set it like this if you are involved in a net or
a round table!
Important Note:
The waterfall and S meter are always near real-time and not
affected by the
change in buffering: As more audio buffering as added, the
waterfall and S-meter will increasingly seem to "lead" (e.g. be ahead of)
the audio that you hear.
Remember:
There are several possible causes of audio drop-outs in
addition to issues that may be occurring at the WebSDR site:
Your
Internet connection may be a bit "jittery": This is common
for
cable modem connection and Wireless Internet connection during "busy"
times (e.g.
evenings) when everyone is watching TV/movies online.
You
computer may be "busy": If your computer is doing something
in
the background while you are running the WebSDR in a browser it may
drop-out occasionally.If the
computer is "too" busy to process the data that it is getting, extra
buffering may not help.
You
have minimized and/or put the WebSDR browser page in the background.
If you have switched to another task, the web browser won't
be
given as much processor priority and audio drop-outs can occur.
If the
computer is "too" busy to process the data that it is getting, extra
buffering may not help.
Note: As
mentioned in a previous posting, additional gain installed in the
broadband coupler (which
feeds the KiwiSDRs, the SWBC, AM BCB and 60 meter receivers) has
resulted in occasional intermod/spurious signals being audible on the
above receivers - particularly a few "shortwave" sounds being audible
in some places on the AM broadcast band. This will be
corrected on a
future site visit when there is time to do a proper "gain balancing".
13 January, 2019.
Comments on work that was done on the WebSDR system on this
day:
All WebSDR servers:
Replaced
the original dual-core 2.93 GHz processors with 3.0 GHz quad core
processors. This should allow more stations to use the
WebSDRs
and experience fewer audio drop-outs and faster response. To
be
sure, the most common cause of audio drop-out is on the Internet
connection between the server and the user and not due to the server
itself as well as in user's computer - particularly when the web
browser being used is operating in the "background" - especially when
other programs are running.
LF filters installed on Server
power supplies:
It was observed that the power factor correction circuitry in
the
servers produced a strong signal in the 125-140 kHz range and it was
hoped that this was the source of the noise that was clobbering the
2200M/1750M when using the E-field whip. Unfortunately, that
noise source was not (mainly,
at least) from the power supplies, hence the installation
of the H-field shielded loop mentioned below.
2200M/1750M antenna changed:
A low-noise shielded H-loop was installed for the 2200M/1750M
receiver to help reduce the gaw-dawful noise that was present.
On
installation the loop antenna was rotated to null the noise source that
was found to be either to the north or the south. What this
means
is that all signals originating from locations due north/south of the
Northern Utah WebSDR site will fall into this null on any frequency
below about 350 kHz - both on the "2200M/1750M" band on WebSDR3 and on
the KiwiSDR
receivers on site when tuning below 400 kHz.
7 January, 2019.
Comments:
Maximum number of users
increased to 90 on WebSDR1: It
was observed that the number of users on WebSDR1 would occasionally hit
the (then)
maximum user count (75)
prompting an increase on that server - a change that required a restart
of WebSDR1, which occurred at about 0630, 7 January, 2018, UTC.
The current settings for the
maximum number of users are:
WebSDR1 (yellow): 90
users. WebSDR1 is, by far, the busiest of the servers as it
hosts
both the 40 and 75 meter phone bands which are the mostly heavily used
for nets and ragchewing.
WebSDR2 (green):
75 users (no
change)
WebSDR3 (blue):
60 users (no
change)
30 December, 2018. Comments on work that was done on
the WebSDR system on this day:
Partial failure of
sound card:A (previously-planned)
site visit was made on this day and it was discovered that the USB
interface of the sound card used for the "160M"
band had degraded, unable to connect at USB 2.0. For whatever
reason, this malfunction rippled throughout all USB interfaces and
similarly affected the two other USB sound devices. The
offending
device was swapped out and all devices are now working properly.
(Note:
USB-based sound devices are used in addition to PCI/E devices
because of the limited number of plug-in slots in the servers.)
Hardware shuffle:
Because the "40ph"
band is one of the mostly heavily-used it was decided to swap the "80cw" sound card (a PCI interface card)
and the "40ph"
in an effort to obtain greater reliability. One slight
down-side
is that the card being used on 40ph has a more apparent "hole" at the
center of its
coverage (at 7221 kHz)
as a result of a slight roll-off in amplitude at low audio
frequencies of the sound card/receiver combination. In
practice this "hole" causes only a slight effect
in the audio response of SSB signals that are atop it.
Installation of a 2200-1750 meter
receiver:
The antenna was connected to the 2200/1750 meter receiver on
WebSDR3.
Unfortunately there is some AC mains related noise (possibly a switching power
supply)
that seems to be parked in its coverage range that can degrade its
overall sensitivity. The cause (and remedy) of
this will be investigated on a later visit.
Despite
the noise source, this receiver seems to perform reasonably well in the
upper portion of the "LowFer" band to the top of its range (180+ kHz).
The
KiwiSDRs, which are also coupled to this new antenna below 350-400 kHz,
seem to be doing reasonably well with WSPR reception on the 2200 meter
band - probably because the required bandwidth for WSPR operation is
very small and it manages to evade some of the noise components.
Improved receive performance
below 350 kHz:
Below approx. 350 kHz added filtering/amplification in the
receive chain and a new LF/MF antenna combine to provide 2200M coverage
on WebSDR3 as well as on the KiwiSDRs.
Lower noise amplification
installed:
Lower-noise amplification (based on the Mini-Circuits
Gali74+ MMIC) was installed on the "high" branch of
the main filter network provide some additional gain and a 3-4dB lower
noise figure on bands 20 meters and up: This also improves
performance of the 17 and 12 meter receivers in particular as their
hardware (each, a
SoftRock Ensemble II) is slightly "deaf".
A similar amplifier was
installed
for the 160 meter receiver to make up a slight gain deficit of that
particular hardware (also SoftRock Ensemble II) as well.
Finally, yet another
lower-noise/higher gain module was installed in the broadband coupler (which feeds the KiwiSDRs, the
SWBC, AM BCB and 60 meter receivers).
Comment:
The levels for this change in gain have not yet be properly
"balanced" resulting in occasional intermod/spurious signals being
audible on the above receivers - particularly a few "shortwave" sounds
being audible in some places on the AM broadcast band. This
will
be corrected on a future site visit.
Additional RFI suppression on
cables: Some snap-on ferrite filtering was
installed on cables entering/exiting the building (network, RF) and a
visible reduction of "computer" and power supply noise on 2 and 6
meters was noted.
I/Q rebalance:
A thorough I/Q rebalance was performed on the 80cw, 40cw and 40ph
receivers: A rebalance for 80cw and 40ph was required because
of
a change in the hardware used for those bands.
On future visits,
other bands will be rebalanced to minimize image response.
27-28 December, 2018.
Comments:
Problems on WebSDR1:Seemingly
because no good deed goes unpunished, a known bug related
to USB hardware reared its head: Several of the USB ports
- starting with the 160 meter receiver's sound card - suddenly
"downgraded" their connection from USB2.0 to USB1.1.
The upshot of this is that the 160m, 40cw and 40ph
bands - all of which use USB-connected sound cards (Asus Xonar U5 and U7)
- could no longer
support a sample rate greater than 48ksps - a far cry from the needed
192ksps.
Originally,
it was just the 160 meter band that had this problem so a reboot was
performed remotely - but the problem spread to the other two sound
cards that provide 40 meters, also USB devices..
In
researching this problem it became clear that any means of completely
resetting the USB hardware via command-line was unknown - but the
work-around was simple: Completely remove the power from the
computer for a short time to allow the hardware to reset. (Note: Even when the
computer is "off", the USB hardware may still be powered up.)
This was tried, but the problem didn't resolve:
There may
have been some sort of subtle hardware failure, or it may be
required to keep the unit powered down for a much longer time than was
tried.
As a temporary work-around, the
40ph
and 80cw
receivers' connections have been swapped to restore full 40 meter phone
coverage, albeit at the expense of some 80 meter cw coverage:
Because 40ph is the more-popular band, we believe the
trade-off
to be worth-while.
The errant hardware (160M, 80cw and 40cw after the above
shuffle)
has been reconfigured for 48ksps, but this dramatically reduces the
frequency coverage on those bands/segments, but it's better
than nothing!
Please
note that while only partial 160M coverage is available on the "high
performance" receiver, the "AM-160M-120M" receiver should work fine for
most 160 meter use.
At the next site visit (scheduled for 30 December)
we will investigate this problem and try to determine a "permanent" fix.
26 December, 2018.
Comments on work that was done on the WebSDR system on this
day:
Intermittent outages:Some portions
of the system were brought on/off line to facilitate work on the WebSDR
hardware.
System outage:All WebSDRs
on site were down for about 90 minutes due to a localized power failure
while we were working on-site.
Addition of a 2200/1750 meter
receiver: A new receiver was added to WebSDR3 (blue)
to provide coverage of the 2200 Meter amateur band and the 1750 Meter
experimenter's band. Unfortunately, the coaxial cable for the
antenna was not available at the time so the outside antenna was
mounted and hardware tested with a signal generator. The coax
from the antenna will be run in the next several days, in the meantime there will be no signals audible
on this receiver.
Another KiwiSDR added: A
third KiwiSDR receiver has been installed and added to the "pool" of
KiwiSDRs. One should connect only to
KiwiSDR1: If all of its receiver
"slots" are used up, you will be forwarded to the next available slot
on #2 or #3. Please refrain from using the
KiwiSDRs for frequencies/bands that are already covered by the main
WebSDR system!
Low LF/MF signals levels on the
KiwiSDRs:
The signal levels below 530 kHz on the KiwiSDRs are lower
than
they should be - but this will be corrected during the next site visit.
The reason for this is two-fold:
An LF/MF diplexer was added to
the signal path: Frequencies above approx. 350 kHz will come
from the main HF antenna (the
TCI-530)
and those below 350 kHz will come from a newly-installed E-field whip.
Because the whip is not connected at this time, signals below
about 350 kHz are cut off.
The addition of the
diplexer/combiner network caused a 3-6dB loss at LF/MF frequencies,
putting the (already
marginally-low)
signals at these frequencies below the A/D threshold of the KiwiSDR.
A "gain realignment" will be done on the next visit to bring
the
signals back up to proper levels.
Another visit to the WebSDR site
is tentatively scheduled for Sunday, 30 December, 2018.
16 December, 2018.
Comments:
Powerline noise: The
powerline noise has been quiet recently (knock on wood)
and it is not known if this can be attributed to repairs by the
utility, or because of the season
and recent "washing" of the lines' hardware by rain and snow.
Let us
hope that it never returns!
Comment:
Some powerline noise appeared again two days after originally
posting this - go figure...
Modification of S-meter "peak"
reading:
A "bug" has been fixed that
prevented the "peak" value display below the S-meter from
actually reflecting the peak value.
Additionally, the peak
reading now has a "hang" to it like a real-life S-meter in that it will
(somewhat)
drop from the peak (with
a timed-exponential decay rate)
instead of the previous, "chunky" updating. What this means
is
that the peak signal level will persist for a fraction of a second and
then drop, increasingly quickly, until it senses a new peak either from
an existing signal or when it hits the noise floor. This
has no effect on the receiver AGC.
The
"Signal Strength" plot feature now has two more items in its drop-down
menu: Both a "fast" and "slow" version that uses the peak
value
instead of the instantaneous value. Because the "peak" value
is a
"peak-an-hold with decay", signal plots of signals that vary
considerably in strength (e.g.
SSB)
will be reduced from a scattering of dots to more coherent lines.
Because the "peak" value of the S-meter has an exponential
curve,
you will see this downward curve in the signal level
24 September, 2018.
Comments:
Modification of "Bandwidth" menu:The "wider" and "narrower"
buttons that had been to the right of the mode selection (USB, LSB, AM, etc.)
have been removed as they were redundant: These same
settings and more
were already available under "Passband Tuning" just below the mode
selection. The removal of
these buttons makes the box slightly narrower and may help improve
layout/presentation at some screen resolutions.
Powerline noise:
A long-running issue has been powerline noise. Some
of the
culprit poles have been identified, but it is entirely up to the power
company to decide when something might be done about them. At
present the worst powerline noise is centered in the general area
around 2.5 MHz - outside any amateur bands - but it can affect the low
bands (160, 80, 60 and
40)during
daylight hours when these bands are typically very quiet.
21 September, 2018.
Comments:
Sedona, AZ WebSDR shut down: After
about 6 years of operation, Steve, W7RNA has shut down the Sedona
WebSDR. Steve, W7RNA says, "...I have taken down the WebSDR
at Sedona.
Except for daytime regional coverage in Arizona and New Mexico, KFS and
Utah WebSDRs cover the West so very well now, that I thought this was a
good time to turn off Sedona as being effectively redundant.
The existing W7RNA links now
forward to the two year old Kiwi SDR at the same location. As you
probably know, the Kiwi is limited but it can still serve Arizona and
New Mexico for the few users that still may need it during the day on
40 and 80m."
We would like to thank Steve
for having provided this valuable
service and those of us at the Northern Utah WebSDR have been the
grateful recipient of his technical advice and expertise.
"AM-160M-120M" band coverage
shifted: The center of this band was shifted
slightly so that it's center frequency (which is also the default frequency)
lands squarely atop an even 10 kHz interval rather than several kHz
off, barraging the user with distorted music. At present
there's
no way to select a default frequency other
than shifting the entire receiver's passband and this limits our
selection if we wish to be able to receive over this frequency range.
Intermittent network slow-downs:
Our rather long-length wireless Internet connections are
sometimes showing down connectivity - but these "slowdown" periods seem
to last only an hour or so. We're doing what we can to figure
out
a way around this.
10 September, 2018.
Comments:
Network Outage:
On the evening of September 9 (local time)
the combination of bad weather, a bird's nest and faulty insulators on
the power line that feeds one of the microwave sites that provides
Internet connectivity to the Northern Utah WebSDR disrupted operations
when that site lost power for several hours. While the
back-up
battery at that site held for a time, the duration of the outage
exceeded its capability while the local utility crews worked late into
the night to replace the failed hardware. The duration of the
network outage was approximately 3 hours and 45 minutes.
Expansion of WSPR decoding
capabilities:
On 8 September reconfigurations made it possible for up to 12
simultaneous "bands" to be used for receiving and decoding HF WSPR
transmissions but only 8 or 9 channels will typically be used at one
time. This is done by using an on-site computer (WebSDR3, actually)
to make local network connections to the on-site KiwiSDR receivers and
pull audio from them from virtual receivers tuned to the WSPR
frequencies (these show
up as a user called "kiwirecorder.py")
which are saved as files and then processed to recover the WSPR
transmissions. As a reminder, the KiwiSDR receivers can each
take
up to 8 users, but only the first two users on each will get a
full-bandwidth waterfall display: These recording channels do
not
use any of the waterfall capabilities. The results of this
effort
may be seen at the wsprnet.org
site
with the contributor being "KA7OEI-1". It is hoped that
future
efforts will enable things like contributions to the RBN (Reverse Beacon Net)
and similar.
17 September, 2018.
Comments:
Over
the past several months we've been having issues with the wireless
Internet connection to the WebSDR spontaneously "re-training", causing
an outage of between 30 seconds and 5 minutes. The reason for
this seemed to be something amiss with the firmware on the radio link
between the WebSDR site and the next point on the network. We
think
that this problem has been resolved after firmware/hardware updates.
A different
problem occurred a few weeks ago when one of the main wireless trunks,
which had been been capable of passing up to 1 Gb/sec of traffic
suddenly decided that it would only negotiate to 100Mbps.
During
the "off" hours of the day this wasn't so much of a problem but since
the peak traffic on the network could be over 350Mbps, dropped packets
and audio issues could result. This "bottleneck" has
been
fixed as of about a week or so ago: We were just watching it
to
see if it was really
fixed before updating this and the main WebSDR pages.
Ongoing issues:
Powerline noise:
We have identified the suspect poles and passed the
information
to the power company. All we can say is: "They will
fix it
when they do."
The "warbly":
As noted in the 30 June, 2018 entry and the 9 June and 16 May entries there
is a "warbly" that often shows up when the band is very quiet (e.g. 40 meters during the
daytime) - one of its harmonics seeming to frequent the
area near 7272 kHz, where the Utah Beehive Net meets. This
is still
on our list to address, but again, it will take climbing to about 60
feet on a tower and pulling up excess service cable in order to add the
ferrite devices that (we think)
should quiet a POE (Power
Over Ethernet) device mounted there.
Occasional "crackle-crackle" on
received signals - particularly the lower bands:
As noted earlier, one of the guy wires on the antenna will
occasionally touch an active antenna element when it is very windy.
We are trying to figure out how to access and insulate these
two
conductors - but their being at about 80 feet (24 meters) up the
tower doesn't make it easy!
A few instances of low-level QRM
from miscellaneous switching power supplies:
While not easily noticed (unless
you knew exactly where to look) there are a few "birdies"
from other switching power supplies on site - typically on the lowest
band (e.g. 160 meters
and below.)
Intermodulation on some lower
bands (<=80/75
meters) during the daytime:
During daylight hours one may notice a few instances of
intermodulation distortion on some of the lower-frequency bands,
particularly below 2 MHz. Much of this energy appears to be
re-radiated from rusty barbed-wire range fencing surrounding the
receive site but it's possible that at least some of it may be
happening in the receive antenna itself and even some of the RF
distribution. Practically speaking, this hasn't been much of
a
priority to fix because:
The majority of the strong
signals (several of
them 50kW stations)
are reduced in power at night in accordance to conditions of operation
imposed by the FCC to minimize their interfering with other stations.
At night, these bands (80/75, 160, 630, etc.) become
more "alive" and compared to the daytime, the background noise actually
increases, drowning out the intermodulation products that might
otherwise be audible even after the stations reduce their power at
night.
9 September, 2018.
More
problems with the Chrome browser!
It would appear that a very
recent update to the Chrome web browser (such as 69.0.3497.81) has
caused yet
another audio problem: Sudden, loud crashes of
noise - or one may hear only
white noise, particularly when first starting the web page.
While muting/un-muting on
the WebSDR itself may correct this, the effect will probably be
temporary.
There's
no known work-around yet so it's recommended that you use
a different
browser: Firefox works well and is recommended!
12 August, 2018.
Comments:
A
Second KiwiSDR was installed at the site and some minor networking
issues were resolved allowing both of the Kiwis to show up on the main
list at
the sdr.hu(link)
site. The URL for the first (main) unit is kiwisdr1.sdrutah.org:8073.
For more information, read the KiwiSDR
section of the FAQ.
Please read and understand the
following:
If you are doing casual
listening on the amateur bands, PLEASE use
the main WebSDRs instead! The
reason for this is that the main WebSDRs can handle dozens
of users at once, but the KiwiSDRs can handle, at most, only 8-10
users. Most of the receivers on the main WebSDRs are better
performance than the Kiwi, anyway.
These receivers are configured
to allow "roll-over" so that if all of the receiver channels on the
first (main)
one are occupied, it will forward to the second.
Each of these receivers is
configured in the "8 channel" mode which means that only the first two
receiver instances will have a full-bandwidth waterfall. At
some
point in the near future the "other" receivers may get a more limited
waterfall.
Each of these receivers have
several channels dedicated for WSPR use and are not
available for general use showing up on the WSPRNET web site as
"ka7oei-1" and "ka7oei-2" for units 1 and 2, respectively:
These WSPR-only "receivers" do not
utilize any of the limited waterfall capabilities. Clicking
on
the Kiwi's USERS
tab will show the current status.
At
this moment, casual users are only allowed 90 minutes total use during
any 24 hour period: Abuse or lack of it will dictate the need
for
any adjustments either way.
Both
KiwiSDRs use the same omnidirectional antenna as the main WebSDR system
so receiver performance should be pretty much identical to other
receivers covering comparable frequencies.
The KiwiSDRs do not
work with Internet Explorer (and
never will) and do not count on them working properly with
mobile devices!
There
are a number of "extensions" that allow reception/analysis of various
types of signals, including RTTY, FAX and WSPR. There is also
a
"TDOA" feature that can help one determine the geographical location of
a particular signal - but there is a bit of a "learning curve" in using
it - I would strongly recommend reading EVERYTHING
in the "help" tab that appears - and the linked page(s) - when
you invoke the TDOA mode. Remember: RTFM! (such as it is..)
The features and
configuration of the KiwiSDR receivers WILL CHANGE over
time as software evolves and as circumstances warrant.
Enjoy!
8 August, 2018.
Comments:
An
outage of approximately 60 minutes duration occurred due to
power loss at one of the wireless Internet link(s).
The "idle" time of the WebSDRs (e.g. you, the user not interacting) has
been increased from 60 minutes to 90 minutes for WebSDR #1 (yellow) and WebSDR
#2 (green)
and 120 minutes for WebSDR #3 (blue).
7 July, 2018.
Comments:
Those
who use the WebSDR on 80/40 meters during the day will likely have
noticed an elevated powerline noise floor: At night, this
noise
is submerged in the normal background noise of these bands.
Being
that the WebSDR site is an 80 mile (130km)
drive for me each way, I understandably try to limit the number of
trips that I have to take - particularly since it involves nearly three
hours driving and (at
current prices) $30-$40 of gas for each round
trip!
On this day I went to the
WebSDR site and carrying a 2 meter AM/FM direction-finding receiver (a VK3YNG unit), a
3 element tape-measure beam, my FT-817, a battery, a 3 foot (1 meter) diameter
shielded H loop, a homebrew ultrasonic down-converter and a small
plastic parabolic dish with an ultrasonic transducer, I tromped through
chest-high (5 feet/1.5
meter) swamp grass in 102° F (39C) heat,
following about 2 miles (3.2km)
of powerlines looking for noise sources. With this
effort, three
power poles were found with very strong, vertically-polarized
noise (at VHF)
and one of
these had just-detectable arcing noise at ultrasonic. I also
found a "corner" power pole on this 38kV line on which one if its
deadmen (guy
wire anchor in the ground)
had completely pulled out in the direction of the greatest force.
Taking pictures of the suspect poles, these will be reported
to
the power company: Particularly in light of the failed
anchor, we
are hoping that they will do what they do to quash this type of noise.
The
25 and 19 meter bands' filters were analyzed in-situ and it has been
determined that over the 25 meter SWBC band, the image response
(centered at approximately 16.8 MHz) is attenuated by approximately
26dB while the image response in the 19 meter SWBC band (centered at
approximately 13.55 MHz) is attenuated by approximately 22dB.
Because of its proximity to the 14.4 MHz Nyquist frequency of
the
RTL-SDR dongle and
the finite "sharpness" of the band-pass filters, the image rejection at the
14.67 MHz CHU (Canadian
time station)
is only about 8dB at the 14.13 MHz image frequency. While
these
values are certainly mediocre, they are adequate for casual listening
on these bands and far better than many inexpensive "all band"
shortwave receivers of the past. I may, in the future,
modify/replace these filters with "sharper" versions with stronger
image frequency attenuation.
It
might be noticed that some of the 25 meter SWBC band images fall in the
22 meter SWBC band centered at approximately 13.75 MHz, which
correlates to 15.08 MHz. What this means is that some of the
stronger 22 meter SWBC signals are likely to appear in the lower
portion of the 25 meter receiver's passband.
3 July, 2018.
Comments:
Michael was able to drop by the
WebSDR site (he lives
in the general area)
and adjustments were made to the 25 and 19 meter SWBC band receivers -
namely the gain block before the filtering was moved to the output of
the 19 meter filter and the signal path attenuation was adjusted for
both bands. Initial indications are that, at least for
moderate/good band conditions, the receivers should overload less often.
In
addition, the 19 meter receiver was configured for 1.5 MHz bandwidth
and it now includes 14670 kHz - the frequency of the Canadian time
station, CHU. Please note that especially below 15 MHz, this
receiver is prone to images from below and in the 20 meter amateur band
- the inevitable result of the Nyquist frequency of the RTL-SDR dongle
used occurring at 14400 kHz!
The
new deadman anchors with the tower in the background and the guys being
tensioned. Click on the image for a larger version.
30 June, 2018. Comments:
New UPS installed:As noted in
the 12 June entry, the 500VA UPS failed unexpectedly (what other kind of random
failure is there?)
and a "new" 700VA UPS was installed - not as nice as the "old" one, but
it should serve its purpose. At this same time a simple
transfer
switch (a mains-powered
DPDT relay in an electrical box)
was installed that allows us to change in/out other UPSs in the future
- and it will automatically switch the mains power, should the new UPS
fail, from the "A" source (the
UPS) to the "B" source (the wall socket).
The 25 and 19 meter shortwave
broadcast bands (SWBC) were installed: On WebSDR
3 (the "blue" server)
some RTL-SDR dongles with filtering were installed to provide coverage
of these two shortwave bands. While the levels were adjusted
appropriately at the instant that we installed them, it is clear that
we missed the mark and that the receivers sometimes overload very badly
resulting, at times, in a cacophony if noise, overlapping audio signals
and distortion..
Please consider the
operation of the 25 and 19 meter receivers to be a work in process!As
noted on the "Technical Info" page, these RTL-SDRs, with there limited
dynamic range, required a certain amount of finesse to adjust properly
to accommodate the majority of weak and strong signal conditions.
These levels cannot be adjusted remotely so they will be
"dialed
in" on future visits.
The 6 meter band (the bottom 1 MHz, anyway)
has been moved to WebSDR2 (the
"green" server):It would appear that the WebSDR
software (or, possibly,
our server hardware) will only "play nice" with a maximum
of 4 RTL-SDR devices. When we added the 25 and 19 meter bands
to WebSDR3 (blue)
the last receiver ("2M
High")
would not initialize. For this reason we used the last
remaining
band slot on WebSDR2. It is configured identically to what it
had
been when it was on WebSDR3.
One of the power line noise
sources (possibly)
located: We think
that we found a power pole that is one of the sources of AC mains noise
that becomes apparent when the lower bands (80/75/40) are at
their quietest (e.g.
daytime).
When we approached the pole in question it was noted to have
a
damaged insulator on one of the phases: We will report this
to
the power company. It is very likely that this is not the
only nearby power line noise source, but we have to start somewhere!
Internal gain blocks added to the
15 and 10 meter converters.
When the 10 meter converter was installed on 9 June it was
noted
that it was "gain-starved", so a general-purpose external gain block (high-dynamic range amplifier)
was installed between it at the RTL-SDR dongle. A similar
issue
was noted on the 15 meter converter so an additional gain block was
internally added to both the 15 and 10 meter converters and the levels
readjusted for best performance. This additional gain should
help
when the band is very "quiet", bringing the signals comfortably above
the receivers' noise floors.
The "warbly":
We did not get time to further-address the "warbly" mentioned
in the 9 June and 16 May entries. To further reduce this
noise will require pulling additional Ethernet cable up the tower (the "other" tower, not the one
supporting the antenna that we are using at present) to
get enough "service loop" to be able to add enough inductance to the
cable to choke the common-mode energy. This warbly is audible
only during daylight hours when the band is quiet and line noise is
very low.
20 June, 2018. Comments:
Nearly 2 months ago the north
deadman of the "other" tower (not the one
supporting the receive antenna)
pulled completely out of the ground during high winds - the worst of
which usually come from the north at this location. In a
stop-gap
measure, one of the locals kindly parked his large, flat-bed farm truck
and attached the the guy wires to it until he got room in his schedule
to come back and replace the deadman - which occurred on this day.
Rather than excavating a hole
and setting the new deadman in concrete, long, thick-walled steel pipes
were pounded deep into the ground with a pile driver, the first
one (to which
the wires were attached) being belayed by another behind
it, connected by a piece of heavy pipe. This method - used to
tension many thousands of feet of fencing - has been used for decades
with good results. In the near future, the other two deadmen
will be similarly replaced although they appear to be sound... for
now...
The "front" pole has, below
ground, a large "spade" attached to it to increase its stability and
"pull strength" in the soil.
While we won't mention up front
how much this is costing us, it's safe to
say that it wasn't cheap! It should, however,
prevent this tower from suffering the same fate as its twin which
failed in the very same way about a decade ago.
Now that we have
better-stabilized
this tower, we are looking into what can be done with the antenna which
at 80 feet (24 meters),
covers from 6 to 40 MHz and is fixed(there is no
rotator) on an
86° (true) bearing -
just slightly north of due east: We
have not yet climbed the tower with an antenna analyzer to determine
its usability.
18 June, 2018.
Comments:
Power line noise finding
postponed: For
various reasons, the "noise finding" trip that had been tentatively
scheduled for 16 June never happened. The noise persists, so
we
still have a trip planned to hunt it down - but it will have to wait
until after ARRL Field Day (22-23
June, 2018) as we have previous commitments.
Installation of the new UPS
postponed: This was going to be installed on the
same trip as above.
Slight gain deficit on 15 meters:
It would appear that there is a slight gain deficit on the 15
meter band. While it seems to be adequately sensitive to weak
signals, somewhat better performance could be had with another 6-10dB
of signal gain. This band is served with an RTL-SDR dongle
and a
frequency down-converter (as
described on the RX Equipment
page)
and as noted, the RTL-SDR units are both somewhat deaf and quite
particular when it comes to the amount of gain in the signal path.
On the next trip additional amplification will be put inline.
12 June, 2018.
Comments:
4 hour power outage.
The
WebSDR servers and network gear were off for about 4 hours due to the
failure of the on-site UPS. While there was no actual power
failure, the
CPU within the UPS seems to have lost the ability to measure its own
output voltage and it shuts off its output soon after booting up: After
power-cycling the UPS, it will operate properly
for several seconds before it shuts the inverter down due to "Low AC
Output Voltage" as determined by the alarm code and the remote status
reading. A "new" UPS is being lined up and will probably be
replaced on 16 June. In the meantime, the UPS has been
bypassed
with the gear running directly from the mains.
Power line noise.
During the quietest parts of the day (late morning through the
afternoon)
there is noticeable AC mains noise on all bands 80 through 15 meters -
most obvious if one listens using AM on 40 meters. The plans
are
to investigate this noise on 16 June and hopefully locate its source
and pass along that information to the power company. As it
turns
out, some of the folks that service this area are also amateur radio
operators, so it may be more likely to be fixed .
9 June, 2018.
Comments:
With the addition of 12
meters, this WebSDR system now has coverage on all
U.S. MF and HF amateur bands - 630 through 10 meters.:
Full
coverage of the 10 meter band.
A downconverter was constructed and with an RTL-SDR dongle,
then
entire 10 meter band is now covered. Because the top is set
at
29.7 MHz, coverage extends several hundred kHz below 28.0 MHz as well.
12 meter
band coverage.
The receiver formerly used for the limited 10 meter beacon
band
coverage was retuned and is now centered on the 12 meter amateur band,
covering about 96kHz of this 100 kHz band.
The only HF bands that aren't completely
covered are:
160M:
Even though the "main" receiver misses the top 8-10
kHz, the entire band is also covered using the "AM-160M-120M"
receiver.
17M:
Approx. 96% of the band - missing the bottom and top 2-3 kHz.
12M:
Approx. 96% of the band - missing the bottom and top 2-3 kHz.
For a complete description of the band coverage, see
the "Technical Info"
page.
We have (finally) added a
"Donate" button. If you wish to help support the
WebSDR, go here
to find out how you may donate via PayPal.
The signal
strength of the "warbly" has been reduced. The
"warbly" (see the 16
MHz comments)
was verified to be coming from a switching supply within a piece of
wireless gear being radiated on the Ethernet cable. Despite
there
not being a service loop, four snap-on ferrite chokes were placed over
the cable, at the source, noticeably reducing its amplitude.
Unfortunately, without a larger service loop, it was not
possible
to put multiple turns of the cable through the ferrite devices which
would have had far greater effectiveness at the frequencies of
interest: This problem will be revisited later.
The 6 meter
antenna was remounted. Up to this point the 6
meter antenna (a 1/2
wave J-pole)
was only temporarily mounted. On the new, permanent mount,
the
antenna is now much higher and completely in the clear so it should
work better than before.
The main HF
antenna feed connection was "exercised" and better-sealed.
Just outside the building, the large coaxial cable from the
main antenna (the
TCI-530) is adapted to a smaller cable (RG-213) for entry
into the building. During the 21 March visit (see below) this
connection was "shaken" to resolve an intermittent RF issue and during this trip (e.g. 9 June)
the entire connection was un-taped and inspected and found to be in
good shape, The connections were further-tightened and the
entire
termination was re-sealed using butyl rubber material and overtopped
with another layer of sealing tape.
Ongoing
power line noise issues: There is a
more-frequent low-level power line noise that can be heard during the
"quiet" times (e.g.
during the middle of the day) on
the lower bands - notably on 80/75 and 40 meters: We are
rounding
up the necessary gear to do HF direction-finding to locate the
source(s) of this noise so that we can report the location(s) to the
power company.
Work
being done on the power substation near the WebSDR site on 15 May.
Yes,
those are bugs in the lights... Lots and lots of bugs. Click on the image for a larger version.
16 May, 2018.
Comments:
Power loss
at the WebSDR site due to utility work on 15 May. The
power to the WebSDR site is fed via a spur of a power
line
that feeds a pumping/compressor station of a nearby pipeline, and on
15 May, a "50 year" upgrade was done requiring that this power
infrastructure be de-energized, which meant that the WebSDR site lost
power. Being a minor customer on this same spur line, we
didn't
get notification of this work until the power had already been shut
off. Because of certain complications (e.g. most of us work for a
living!)
we were not able break free from our normal tasks and get a portable
generator up and running on-site
immediately, so the system was down for 7 hours or so. The
WebSDR
site was on generator power until after the work on the substation was
completed and the line re-energized.
Data
drop-outs of 5-120 seconds. It
would appear that one of the radio links providing Internet
connectivity to the WebSDR site is occasionally "renegotiating" its
wireless connection, causing brief data drop-outs despite the fact that
the signal level margins are very good. An upgrade of the
affecting link is scheduled.
A weak
"warbly" sometimes heard on 40 meters and other places.
In
early April, a piece of POE (Power
Over Ethernet)
interfaced-equipment with a fairly long cable run was installed.
Unfortunately, as is the case with almost any piece of
equipment
that has switching supplies, one of the (many!) harmonics (spaced at about 250-251 kHz)
of this supply can occasionally be heard in the local receiver.
Fortunately, this "warbly" is quite weak, audible
during
daylight hours when the bands are very quiet: The normal
background noise of the bands at night completely covers this.
This "warbly" is wont to haunt 40 meters and is often heard
in
the vicinity of 7272kHz, the "default" frequency of the "Yellow" WebSDR
server and the frequency of the Utah Beehive Net, but it tends to drift
around a bit with temperature. This same "warbly" has also
been observed (during
the daytime) on 75/80 meters and on 20 meters.
On the next site visit steps will be taken to mitigate
the
signal(s) radiated by this equipment and it is expected that this
problem will be eliminated.
3 May, 2018.
Comments:
More fun
with the Chrome browser!
The "Start Chrome audio" button has been added to the
"Mobile" versions of the WebSDR for those using mobile (phone, tablet)
devices and the Chrome browser. It is believed
that this works properly, but consider it to be experimental for now.
Depending on your phone's configuration, the WebSDR audio may
stop when your device goes to sleep/screen blanks: If this
proves
to be an issue, we'll look into adding code that will prevent this -
but doing so will cause your battery to drain very quickly!
Remember also that the Firefox browser
works well with the WebSDRs, so you may consider using it, instead.
If you are using the "normal" web interface with the
Chrome
browser on your phone, you may have problems with audio
stuttering/echoing, and this seems to be due to too little processor
time being allocated to processing the audio: It may correct itself
after a few moments - but if it happens to you, it probably won't.
Disabling the waterfall (the
"blind" button at the top-left corner, above the waterfall - you may
need to select "one band" an "blind" again) seems to help.
The
"mobile"
version of the WebSDR interface doesn't seem to have this problem -
neither does the Firefox browser with either the "normal" or "mobile"
version of the WebSDR interface. (This problem has been noted on
Samsung phones running Android and it may or may not occur on other
phones.)
For more information about this,
go to the "Chrome Fix"
web page.
Links on the "Mobile" web interfaces to the other
Northern Utah WebSDRs have been added.
The "additional
audio buffering"
button has been added to the main WebSDR pages. This
increases
the amount of the delay between the reception and your hearing of the
audio, but it can make the use of the WebSDR more tolerant of Internet
connections that are slow and/or subject to larger amounts of jitter (e.g. mobile hot-spot,
satellite, lower-speed "broadband", heavily shared connections).
This button is present on the "mobile" versions (near the bottom)
for the same reason.
Remember:
Most audio
drop-outs are due to other applications running on the
computer/phone/tablet taking processor time and NOT
because of network issues.
Having the WebSDR running on a minimized window and running
other
processor-intensive programs is a great way to make the audio choppy!
1 May, 2018.
The "31M-30M" band on the "Green" server was reconfigured,
increasing the bandwidth to 1536 kHz to cover down to 8676 kHz.
This expanded frequency range includes some of the HF
frequencies
used for aeronautical communications on ocean routes and frequency tags
for these frequencies (and
those aero frequencies that happen to be covered on the "60M-49M" band
on the "Yellow" server) have been added.
26 April,
2018. Comments:
A clock showing UTC was added to all servers in the
(otherwise)
blank space between the waterfall and the controls to minimize the
overall web page size and to place it where it is easy to see.
This clock is based on the time setting of the user's
computer and not
that on the WebSDR,
which may not be precise. The code for this clock was
"borrowed"
from the KFS WebSDR. On 30 April the display of local time
and an
advisory about the clock's being based on the user's computer was added.
The firmware of the data link connecting the WebSDR site
to the
back haul has been updated to fix what the manufacturer called
"stability problems". We are hopeful that the link will be
more
reliable.
20 April,
2018.
Comments:
Chrome
users:
If you
use the Chrome web browser a recent update may
require
that the user "activate" sound/video on web sites that have this type
of content by clicking a button to activate it - but
this works only if
those same web sites have modified their code to include this button.
While we (believe
that we)
have modified the Northern Utah WebSDRs to have this button, it may
take
some time before these changes appear on other WebSDRs. For more information about this,
go to the "Chrome Fix"
web page.
Earlier this week there were some very high winds
throughout
northern Utah. Since then, power line noise at the WebSDR
site -
which is intermittent by nature - is occasionally worse than it had
been before. While we are working with the power company to
find
the source of this noise, it is largely up to us to locate it and
report the location of the suspected hardware to the utility.
As you can
imagine, we need to find time to do this - and then hope that the noise
is occurring at that same moment so that we can find it.
During 19 and 20 April, some network upgrades were being
undertaken, causing some occasional outages.
Coincident to that,
one of the wireless links connecting the WebSDR to the Internet started
losing its mind, losing/regaining its authorization and dropping a lot
of packets and occasionally going down altogether. Once there
was
time to address this issue, this link was reprogrammed from the ground
up and it is hoped
that it will behave itself!
19 April,
2018. Comments:
The "630M-AM-120M" band has been shifted up slightly, now
covering only down to about 519 kHz. This was done because
there
is now a dedicated 630 meter band receiver.
The "60M-49M" band has been shifted up, now starting at
about
4700 kHz and covering to just above 6700 kHz. This was done
because there are (probably)
more signals of interest 6600-6700 kHz range than there were down
around 4500 kHz - although I don't know offhand what those would be...
We have enabled ads on the WebSDRs - trying to keep them
as
unobtrusive as possible - to help offset the "fixed" expenses related
to operating a WebSDR, such as power and site rental. One
side-effect is that they may slightly delay the loading of
the web page. To read more about why we did this, go the "Why
ads?" article.
17 April,
2018. Comments:
Bands on individual servers are now in order of lowest
to
highest frequency rather than by "high performance" receivers first and
then increasing frequency.
The S-meter/waterfall gain settings on 40 meters that
had been
adjusted to compensate for the effects of the high-pass filter have
been restored to their original values.
A/D converter gain values on the 630 meter receive
system were adjusted to provide better overall signal range.
Minor name changes of several bands for better
consistency.
15 April, 2018.
Comments:
Resolved
issue: The high-pass filter was rebuilt.
This is used to block low-frequency (<25 kHz)
energy picked up by the antenna in the form of electrostatic coupling
that was causing problems at low receive frequencies - being
particularly noticeable on the AM broadcast band as mains-induced hum.
The original filter was found to have a broad, shallow
"notch" at
around 40 meters that had reduced signals by about an S-unit.
Resolved
issue: One of the sources of an intermittent
problem where intermodulation distortion from
AM broadcast would appear and disappear is believed to have been
solved. This was probably due to a flaky solder connection in
the
"wideband" branch of the signal path where one or more of the notch
filters used to reduce the signal level from strong, local stations
would occasionally fail.
Upgrade -
15 Meters: The
15 meter amateur and the 13 meter shortwave broadcast bands
have been added to the "Green" server. This uses a relatively
low-performance RTL-SDR dongle preceded with a custom-built,
tightly-filtered frequency converter, but it was verified that just
will hear the ionospheric noise floor when the band is closed.
Upgrade - 2
meters: A south-pointing, 5-element 2 Meter Yagi
is now being used for 2 meter
reception. This Yagi points toward the Salt Lake City metro
area where
there is the greatest concentration of repeaters.
Upgrade:
The "Blue" server has been added, providing a few additional
bands.
Change:
2 meter coverage has been moved to the new "Blue" server.
Upgrade - 6
Meters: The bottom 1 MHz of 6 meters has been
added, covered on the
"Blue" server in preparation for the upcoming sporadic-E season.
The antenna for this band is not yet properly mounted so it
does
not (yet) work very well.
Upgrade -
630 Meters. The
630 Meter amateur band has been added to the "Blue" server.
This receiver covers from about 389 to 484 kHz, allowing some
NDB
(Non-Directional Beacons) to be heard - particularly at night.
Like 160 meters, the 630 meter band is mostly a "winter" band
owing to the crescendo of static that accompanies the summer season.
While this band is also covered on the "630M-AM-160M" band on
the
"Yellow" server, this receiver has much better performance.
Note
that this band can, at times, be badly affected by the intermittent
powerline noise and intermod/antenna issues that we are experiencing.
11 April,
2018.Notice:
There are/will be some occasional outages over
the next week or so as our ISP does some equipment upgrades.
7 April, 2018. There
was an extended power
failure in the general area of the
WebSDR, caused by a pole fire, that resulted in an outage that
lasted significantly longer than a UPS powering one of the microwave
hops providing Internet connectivity could. Whether or not
this
had anything to do with our intermittent
power line noise remains to be seen. This outage provided the
opportunity to reconfigure the power system to mitigate the
aforementioned power issues at the "next" site along the network.
5 April,
2018. Comments:
Upgrade:
The original wireless link antenna used to
provide connectivity to the WebSDR site was upgraded from its original
12" (25cm)
to a 24" (50cm)
antenna, providing better link margin. This resulted in a
pair of
outages that totaled 10-15 minutes in the morning between 1130 and
1145 MT.
Upgrade:
There is a UPS/power supply issue at the "next"
site along
the network from the WebSDR and brief power bumps at this site will
cause a 3-5 minute outage. This will be fixed (which will, itself cause a 3-5
minute outage) in the next several weeks.
While on site today it was observed that the
known-marginal north deadman on the other
antenna tower (a
log-periodic beam)
had pulled completely out of the ground, leaving the guy completely
slack. The already-in-process plan to replace these deadmen
has
been delayed due to equipment problems of the person we have engaged to
repair this; In the meantime, the north guy wire has been (temporarily!)
attached to a large truck. There is no visible evidence of
antenna/tower damage. All three deadmen will be replaced, but
because the strongest winds are out of the north, this is the one that
is the most critical.
Under
investigation: There is an intermittent issue
where there are spurious 160 and
80/75 meter signals - most notably on 1940, 3480, 3600, 3750, 3870,
3920 and 3960 kHz, many of these seeming to involve a mix between 1160
kHz and other stations. For the most part these spurious
signals
disappear at night when some sources of the signals reduce power as
well as the ionospheric noise on these bands increase. The
source of this problem is believed to be a problem with one of the
filter elements designed to reduce the levels of the AM broadcast band
signals. When this is at its worst the "630M-AM-160M"
receiver may be unusable due to overload.
Resolved
issue: It was discovered that, somehow, the
sound card used for the
"10M BCN" had reconfigured itself, switching the receiver audio away
from the active input. This was fixed for good - I hope!
27 March,
2018. Comments:
Resolved
issue: It was discovered that the "10M BCN"
receiver intended to cover (most
of)
the 10 meter "beacon" subband from 28.200-28.300 MHz was actually
centered on 28.350. This receiver was retuned to a center
frequency of
28.245 MHz (this
frequency chosen to include the NCXDF beacons at 28.200 MHz)
and immediately several beacons - including the "K7EMX" beacon located
about 70 miles (112km)
in Salt Lake and another beacon in Texas (K5AB at 28.280 MHz)
- were heard, indicating that the receiver is now working properly.
Resolved
issue: It
was noticed that the "= kHz" button doesn't work correctly when the CW
mode is active. The problem had to do with the fact that
unlike
any
other mode where the indicated frequency is that of the carrier (or suppressed carrier on SSB)
the indicated frequency when using a CW mode is that of the center of the passband
- or 750 Hz. Because of this offset, the "= kHz" button
caused the
frequency to jump, being rounded using that 750 Hz offset:
After this
offset was taken into account in the code, this problem was fixed.
24 March,
2018. Comments:
Resolved
issue: A
brief site visit by Mike for the installation of a high-pass
module on the main antenna feed which got rid of the AC mains related
"hum" on signals received on the AM broadcast band receiver.
This
problem is believed to be related to the pick-up of AM mains
electrostatic fields from the antenna causing modulation of the
magnetic properties of an input RF transformer and/or the modulation of
one of the signal amplifiers. This module provides a
DC path-to-ground for the antenna as well as two (moderate) levels
of lightning protection via gas discharge tubes.
Related
issue:
It was noticed that a stray resonance in the added filter
seems
to have caused approximately 1 S-unit of reduction in signals on 40
meters - but there is little or no actual loss of system sensitivity
owing designed-in signal margins. The filter will be modified
during the next site visit.
Resolved
issue: Extra gain was added in the "10M BCN"
receiver's signal path. Although there are two low-power 10
meter
beacons known to be active in the Salt Lake area, neither one can be
heard on this
receiver - but this is not unexpected as propagation would be only via
ground wave (which is
rather poor on 10 meters, anyway) and the distance is
simply too great to hear them.
21 March,
2018. Comments:
Under
investigation: It was noted that the RF levels
on all HF bands were shifting
randomly over the day by as much as 12 dB. A brief site visit
was
made by Mike who lives near the site and he shook the cables/connectors
between the RF rack and the antenna - we may
have found an intermittent RF connection on a jumper cable:
This
will be investigated further on the next "full" site visit.
The 10M
BCN band was added at the time of this visit. We
had an extra "Softrock Ensbemble II" receiver on-hand (it had been the "75PH" receiver
prior to the recent upgrade)
which was reconfigured, putting it approximately in the middle of the
10 meter beacon subband. All that was available was the 96
ksps
sound card on the servers' motherboard - and this receiver lacks a
stage of RF amplification so it is going to be somewhat deaf, but it
should hear 10 meter beacons during even moderate band openings.
19 March,
2018. Comments:
Resolved
issue: There was a "hummy" spur that drifts
about on the 40PH
band. The cause of this was unknown - and the symptoms were a
bit perplexing: It was not super strong (only about "S-9")
and weirdly, its image (equidistant
from the 7221kHz center frequency) was only 6-10dB weaker.
If this spur were on-frequency I would have expected that
would have been much
stronger than it was and also that the image would be 40+dB weaker.
The implication of this was that this spur is probably far
off-frequency and what we were seeing was a rather weak spurious
response
from that (very-strong!)off-frequency
signal. The signal path contains a large number of
filter elements and there are several post-filter RF
amplifiers
and it is likely that one of these had "broken into song":
The
amplifier design that is used should
have been unconditionally stable, but all bets are off when
Murphy is
involved! The "fix" was to add some 2dB resistive attenuators
to the outputs of these signal amplifiers.
Upgrade:
The opportunity was also taken to add an
amplifier stage to the
recently-added
17 meter receiver, allowing it to hear the background
ionospheric noise.
Under
investigation: The TCI 530 antenna was given the
"shake test" and it was
verified that there is, in fact, some sort of intermittent connection.
There is strong evidence that one of the active antenna
elements is close
enough to touch a guy wire when the antenna is vibrating due
to wind.
Experimentally, 2-meter coverage was added to the system.
At this time the antenna is not very good, so effective system
sensitivity is quite poor. This site is approx. 70
miles (112km)
north of Salt Lake City so the signals from the repeaters in the metro
area are a bit weak with the current configuration. We are
will
be making some improvements to the antenna system which may make it
more useful, but whether or not 2 meter coverage will be a permanent
part of this system remains to be seen.
18 March,
2018. Significant system upgrades/modifications:
Upgraded
power: A
UPS with a built-in ferroresonant transformer was added to clean up the
power and provide continued operation in the event of brief outages.
Upgrade -
160M: Levels were readjusted and this receiver
retuned and moved to a 192 ksps card to cover nearly 96% of the 160
meter band.
Upgrade -
80CW-80PH-75PH: A "triple" receive module was
constructed that cumulatively provides complete coverage of the 80/75
meter bands.
Addition -
80CW: The the aforementioned module, this band
was added, completing coverage of the entire 80/75 meter amateur band.
Resolved
issue - 75PH: The sound card was modified (the "Aux" input was made
available on the rear panel of the Asus Xonar DX)
to allow gain adjustment and the audio levels were properly set to fix
the
problem where the sensitivity at the extreme edges of the band was
reduced by 10-15dB.
Upgrade -
40CW:
This band was moved to a 192ksps card and the center
frequency
re-tuned, now providing coverage to the entire 40 meter amateur band.
Tweak -
60-49M: Levels adjusted, improving weak-signal
performance - particularly during the daytime.
Upgrade -
WebSDR Server #2 (Green)
was added, providing:
20M:
A
dual high-performance 20-meter receiver module which, with a pair of
192ksps sound cards provides full coverage of 20 meters.
The change to higher-performance, narrow-band receivers
resulted
in the loss of the (incidental)
reception of the 22 meter shortwave broadcast band.
17M:
The 96 ksps sound card that had previously been used for 40CW was installed
in this server. Redeploying the original 80PH
receiver allows nearly 96% coverage of the 17 meter band. At
the
time of installation it was noted that this receiver was slightly deaf,
so an amplifier will be added to its signal path during the next site
visit.
30-31M:
Coverage of the 31 Meter shortwave broadcast and the
30 Meter amateur bands was added using a (low performance)
RTL-SDR Dongle.
12 March,
2018.
There are some ongoing upgrades to the network infrastructure
that provides connectivity to the WebSDR. Because of this
work,
there will be occasional network outages - typically of 4-10 minutes
duration.
4 March, 2018. A
modification was made to the code to "brighten" the waterfalls,
particularly during the times of day when the bands were "dead".
At about this time additional "Passband Tuning"
controls were added as well.
28 February,
2018.
This WebSDR was moved to its designated site - an old HF
research
site near the town of Corinne, Utah, about 70 miles (94km)
north of
Salt Lake City. The antenna at this site is a TCI-530, an
omnidirectional Log-Periodic antenna - the same model as that used at
the KFS
Web Site at Half-Moon Bay, CA. Now that we have the initial
system running,
we will work to improve the overall receiver performance, add more
bands and do more performance tweaks. While the person in
charge
of the data networks lives fairly close to the site, the one in charge
of the RF infrastructure lives about 70 miles (and a 75 minute drive)away - a
fact that can sometimes complicate dealing with the latter types of
problems.
23 February,
2018:Several
items:
The system was down for several hours while some of the
critical components were "racked up" - that is, removed from their
temporary location (scattered
across a workbench)
and mounted/wired on shelves in an equipment rack. This
process
is not yet complete and a few more brief outages will occur in the next
several days while things are "permanentized."
The tentative date for installation of this system at its
"permanent" site is
28 February, 2018. When this happens, this system will be
down
for several hours as it is relocated and installed with subsequent
debugging of the computer, RF subsystems and the network. The IP address will change at
this time
but there will be another server at the address of the old one that
will inform those users who land there, giving the new address and
prompting them to update their bookmarks. This
"informational" server will be
online for a few weeks before being turned off.
21 February,
2018:
The hard drives on the system started throwing errors were
replaced with Solid State
drives, necessitating a complete rebuild of the operating system.
This process took some time and the system was unavailable
during for about a day.
7 February,
2018:
The 40 meter receive system was reconfigured: A
custom-built dual 40 meter receiver module was used to replace the two
"Softrock Ensemble II" units that, together, had covered 40 meters.
The Softrock Ensemble II units were then reconfigured to
provide
coverage of the bottom 96 kHz of
the 160 meter band and chunk of the
"80 meter" phone band.
17 January,
2018: This WebSDR server was first made public
from a testing location
near Salt Lake City, Utah,
U.S.A. and was used to test software/hardware
configurations prior to the
installation at a quiet receiver site in Northern Utah. This
location was somewhat "RF
noisy" with the amount of noise varying
wildly at times, so it didn't hear particularly
well - but it still did better than many home installations.
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
