The Northern Utah WebSDR Less recent news and current issues

Looking for more recent new?  Go to the "Latest News" page.

Less-recent events and resolved issues:

• 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 had intended 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."

• 4 October, 2020:  Keyboard audio muting toggle added:

• 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.

• 21 September, 2020:  Tower deadman anchors replaced.

• 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.
• Information about this transfer relay is documented on the 7 July, 2020 entry of the KA7OEI blog page.
  
• 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)
  
• For more information about this device, read the Utah WebSDR FAQ page entry about it.
• This device is described on the KA7OEI Blogspot page - 7 June, 2020 entry.
  
• 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.

• 5 June, 2020:  Brief outages - WebSDR #4 code modified.
• 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!

• 30 March, 2020:  Backhaul issues - extreme slowdown of WebSDR traffic.:
• 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.

• 17 March, 2020:  DSP noise reduction parameters tweaked
• 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:
• WebSDR #1 (yellow)
• WebSDR #2 (green)
• WebSDR #3 (blue)
  
• 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.)
• WebSDR2 Mobile
• WebSDR3 Mobile

• 8 January, 2020:  Internet connectivity lost!
• 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 ABOUT page.
• 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.
• For more information about this change, please read this.
  
• Thank you for your patience.

• 14 May, 2019.  Comments:
• Site visit:
• "High split" preamplifier repaired:
• 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 and RF 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/8^th 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 - 630M-AM-160M :  Levels adjusted, improving weak-signal performance
• 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 

Back to the Northern Utah WebSDR