The Northern Utah WebSDR Latest news and current issues

Recent events and resolved issues:

• 18 May, 2022:  Comments.
• VFO issues fixed - I hope:
• A user of the WebSDR commented on the fact that, sometimes, the "B=A" or "A=B" function of the VFO switching didn't always work as expected.  This had been known for a while, but attempts to replicate this didn't reveal the problem until this person outlined the specific steps needed to cause the problem.  Once this was done, it issue was properly divined and the problem fixed on all of the Northern Utah WebSDR servers and also on KFS and the Maui WebSDR - Thanks!
• Additional modifications on WebSDR #3:
• As noted before, WebSDR #3 is often the "guinea pig" used to test software changes as it gets relatively little usage - and it is in the same environment as the other WebSDRs, allowing more thorough testing than is possible with the "Test WebSDR" in the home lab.  A few changes made since the last update:
• Local oscillator leakage suppression in Synchronous AM:  Because the quadrature cancellation isn't perfect, there was a slight amount of leakage of in the form of an audio tone when Synchronous AM was used.  Now, a high-Q notch filter is automatically tuned to the frequency of that leakage and the tone is removed.
• Vari-Notch added:  This is a notch filter in which the frequency may be manually adjusted with a slider.  The "Q" of this notch filter is fairly low (about 2) as too-narrow a notch would make it rather difficult to tune - and the discrete frequency steps of the slider might make suitable notch depth impossible to obtain.
• Important:  This is an audio only notch filter, so it will NOT prevent AGC desense in the presence of a strong signal - only the "Notch 1" filter can address that.
• CW Peak filter modified:   The CW Peak filter now has an option labeled "Ref. Tone" (e.g. "Reference Tone") which activates a tone generator at the precise frequency of the peaking filter.  This should aid the user with precisely setting the peaking filter to the frequency of the station to which they are listening.
  
• "When will we see these changes/updates on the other Utah WebSDRs?"
• We are still in the process of adding/testing/debugging the new features on WebSDR #3, but once that is done, we'll roll over some or all of the "new" features to them.  We may roll them over all at once, or just one at a time - which is something still to be decided.
• Power line noise:
• As noted in the 7 May entry, the power line noise level is higher than normal, likely due to "dusty rain" that coats insulators and hardware with a very slightly conductive film.  We will "walk the power line" as soon as the opportunity present itself during a future site visit.

• 7 May, 2022:  Site visit:
• On this day a site visit was made to do some infrastructure work that has been months in the planning:  Little (if anything) was done to the WebSDRs themselves, although the work did affect them.
• Improved grounding:
• Additional grounding:  Three more ground rods were sunk around the perimeter of the building and tied to the building itself - which is completely metal.  This activity was complicated by the fact that holes had to be drilled into the superstructure - one of them having to be tapped as well - to attach them.
• New entry panel installed:
• Previously, the coaxial and data cables entered the building via existing holes with grounding done immediately inside the building (to the superstructure - which is one solid, welded construction and now tied to at least six ground rods) but it now enters through a "proper" metal box that is both tied to the building and (to be sure!) to the nearest ground rod.
• This installation required that every cable going through the entry panel (which is all antennas and the data/power for the Internet connection) be re-routed.  Doing this meant that there were several interruptions of the RF feeds and Internet connectivity.  The RF feed from the east-pointing beam (WebSDR #4), in particular, was disconnected for several hours during this work.
• The "old" entry hole was closed up and sealed as it had been an ingress point for insects and air, the holes and wall space filled with expanding foam.
• There is still plenty of work to be done in that while the cables actually route through this entry box, we still need to re-terminate each of the lines and install the grounding/lightning protection blocks in/to the box itself:  This will take several hours to complete and will undoubtedly cause several more interruptions when this is done - likely during the next major trip.
• QSY of 10 meter (Part 15) beacon:
• Previous on (approximately) 28.570 MHz, the on-site telemetry beacon was moved to about 28.925 MHz to get it farther away from 10 meter SSB activity when the band is open.
• It was observed that this QSY caused an "inverse-keyed" version of the beacon to appear on 50.200 MHz on the 6 meter receiver.  This frequency is not harmonically related and we don't know yet if it is a spurious product of the new oscillator, or a spurious response by the 6 meter receiver - but we'll look at it during the next trip.
  
• Other work completed- not in any particular order:
• Several more "T" stakes were installed/re-sunk to keep the cattle that occasionally in habit the area away from certain locations (e.g. where coax goes underground, critical areas near the building, etc.) - but we need to do more of this.
• A higher-stability oscillator was installed in a piece of on-site test equipment to reduce temperature-related drift during remote testing/troubleshooting.
• We still have a very long (and growing) list of things to be done during future visits, ranging from "must do!" to "nice-to-do", so there's little possibility that we'll run out of tasks when we are on site!
• Other comments:
• UPS upgrade:  We will soon be upgrading the capacity of the UPS (power back-up) by replacing the existing batteries, hopefully allowing a "run" time of 3-4 hours at minimum.
• Power line noise:
• As noted in previous entries, because the site is quite near the Great Salt Lake and salt marshes, the area often experiences "mud rain" which occurs when slightly conductive, wind-blown dust falls during rain, coating power line hardware.  Understandably, this can raise the local noise floor considerably at times - and this has happened several times during the past month.  Usually, this condition persists for a few hours to a few days when "clean rain" falls and washes away some of the noise leakage paths - but not always.  For this noise source, there is little that we can do except hope that Mother Nature will assist in QRN reduction!
• Based on observation, there does appear to be greater tendency for this "temporary" noise to persist for longer than it had in the past.  It could be at least partly related to the fact that not too distant from the site, the retreat of the Great Salt Lake is leaving large, exposed areas of salt pan that allow the wind-borne dust to propagate, but it could also be due to degradation of power line hardware (insulators, clamps, insulator sleeves) that make it more susceptible to the "dirty rain".
  
• There is a long-term noise source that is consistent, often varying in intensity, that is centered around 2.25-2.5 MHz and it and its harmonics (around 60 meters, sometimes the top of 40, part of 30 and 20 meters) appears that we have yet to locate.
• On our list of things to do - but it will require the "walking" of several miles of power lines through very tall grass and near salt marshes on a hot day, braving mosquitoes, a particularly aggressive species of deer fly and, possibly, ticks!  And why do we do all of this - because it's fun, of course!

• 3 May, 2022:  More "bands" added to the Salt Lake Metro  WebSDR:
• The "Salt Lake Metro" WebSDR ( found here ) - which is located along the east benches in the Salt Lake Valley for the reception of both repeater and simplex operation in the most populous portion of Utah - has been recently updated to include three new "bands", all using the same discone antenna as the other 2 meter and 70 cm bands:
• SLC ATC:  This receiver covers a 2 MHz portion of the "aircraft" band from approximately 121.1-123.1 MHz - a section that includes a significant portion of the air traffic control traffic in and around Salt Lake City.
• 6 Meters:  This receiver, centered on 50.5 MHz, covers the bottom 1 MHz of the six meter amateur band - mainly for weak signal reception for local nets, beacons, and the occasional band openings.
• Space->Earth:  This receiver, centered at 145.900 MHz, includes the 200 kHz "Space" segment of the 2 meter amateur band, allowing the reception of amateur satellites on that band.
• Currently, this receiver is using the same Discone antenna, but it is hoped that it will be soon switched to a quadrafilar helix that is better-optimized for high angle reception.  This receiver has a single band-pass cavity preceding it to provide attenuation to other 2 meter signals allowing higher gain settings on the RTL-SDR than the other receivers and help reduce the probability of overload - which can still happen if there is a strong signal on the input frequency of one or more of the 146 MHz repeaters.
• The bandwidth on this receiver is 256 kHz and is selected to reduce - as much as possible - the potential for overload/interference from nearby band segments.  If there is interest, it is possible to upgrade this receiver to an SDRPlay RSP1a- but this receiver is significantly more expensive (about $140 versus $35) and we'd want to make certain that the effort and usefulness if we were to do that would be appropriately justified in terms of usage.
• Consider all of the receivers on he Salt Lake Metro WebSDR to be experimental:  We are occasionally revising things to try to improve performance and usability, so there may be occasional outages while we do so.  Finally, although the hardware isn't available at this moment, there is one more "slot" to add another "band" to this server and we are looking for suggestions.  
• If you are interested in additional coverage (e.g. more Air Traffic Control frequencies, other band segment, etc.) feel free to make a suggestion using the contact information via the link near the bottom of the "About this WebSDR and contact info" page, the link for which may be found along the right side of the page.  If you do make a suggestion, keep the following limitations in mind:
• If more coverage than 768 kHz is desired, it must be done using an RTL-SDR, which has just an 8 bit A/D converter which has significant limitations in the presence of strong signals within the receiver's passband .
• If <= 768 kHz is needed, this is possible using an SDRPlay RSP1a.  As noted above, this receiver is far more expensive (about $140 versus $35 for an RTL-SDR) and the needs for its much higher performance would have to justify the cost of the hardware.  At present, it is not possible to cover more than 768 kHz of spectrum while simultaneously having more than 8 bits of A/D resolution that would be needed to simultaneously receive both weak and strong signals.  (Note:  This is not possible using "OpenWebRX", either!)
• Coverage of 10 meters is currently not possible due to the presence of a 10 meter WSPR transmitter on site, which would certainly overload any receiver.
• 
  
• 1 May, 2022:  Power failure:
• At approximately 2315 MDT on 31 April the commercial power at the WebSDR receive site failed.  The on-site UPS did its job, but with the 500-600 watt load the battery bank kept the site up until approximately 0008 MDT this morning - just under one hour.  It is possible that this outage was due to emergency work being done at a nearby utility site.  Reports from residents in the county report a massive disruption to the grid due to some sort of failure/fault where voltage and phase measurements went all over the map, causing a fair bit of damage to mains-powered devices as voltages went very high and low.
• The mains voltage at the WebSDR site at one point measured over 137 volts - not good.  Similarly, a large, commercial customer nearby reported 242 volts on a leg of a 208 volt three-phase circuit with a phase error of 28 degrees.  Percentage-wise, this correlates well with our 137 volt reading.
  
• The commercial power returned at  approximately 0105 MDT, at which WebSDRs 2 (Green) and 3 (Blue) appear to have come back up gracefully - but WebSDR 1 (Yellow) and 4 (Magenta) did not:  The reason for their inability to start up reliably from a cold boot has been investigated in the past, but this has been thwarted by the fact that when they are tested for this, they will typically start up properly - so go figure!
• It's worth noting that because WebSDR #3 (Blue) was online, its "backup" 80 and 40 meter receivers were usable - in fact, there were a few dozen users that had "discovered" this fact.  While they are of somewhat lower performance than the comparable receivers on WebSDR #1 (Yellow), they do very well considering the hardware in use.
  
• The outage of the WebSDRs was noticed, but it wasn't until about 0850 MDT this morning that attention could be given to bringing them back online.
  
• It was expected that the UPS battery should have endured for longer (at least two hours)  and the batteries tested well the last time this was done (November, 2021) but it appears that this is now an "action item" for the next site visit.

• 27 April, 2022:  Additional modification - CW Peak filter
• A "CW Peak Filter" has been added, configured via a drop-down just above the DSP Noise Reduction selection.  In this window is a selection of frequency, in Hz, from 350-1000 Hz in 50 Hz steps.  Because the "default" center frequency for the WebSDR's CW filter is 750 Hz, this value appears twice - at the top, and farther down in the list.
• This filter consists of a single biquad section with a Q of 20 and a gain of 30 which should be a reasonable compromise between narrowness and minimal ringing and should be suitable for at least 30 WPM.
• Comments on its use are appreciated!
  

• 26 April, 2022:  Modifications now "Live" on WebSDR #3:
• Following up on the 23 April, 2022 entry, several new features have been added to WebSDR #3:
• Improved tuning resolution.
• The built-in resolution of the WebSDR is typically 31.25 Hz, which is "good enough" for most instances, but this challenged me to increase it - and I have done so:  The tuning resolution is now exactly 1 Hz.  The display now shows 1 Hz resolution, but this will likely exceed the frequency stability of the receivers at the server site over the temperature range!
• This was done not by changing the WebSDR server's code, but rather by doing a linear frequency shift, the precise amount - which is between 0 and 31.25 Hz, the exact amount being calculated while tuning is being done.  This shift is done on the users' computer rather that the server and if one tunes up and down using the added "+" and "-" buttons (e.g. -/, -//, \\+, \+) you can hear, if listening carefully, a slight delay in the pitch adjustment of a CW note as you tune up and down due to the Internet delay.
• Revised DSP noise reduction, "Notch2" and "High Boost" functions:
• A significant rework in the DSP code has been done, moving it from a point in which it operates at the user's computer's sample rate (typically 44.1 or 48 kHz) but, instead, at the audio rate of the stream from the WebSDR server - which will be either 8 or 16 kHz.  This has several effects:
• Much lower CPU load as the filtering is operating on fewer samples per second.
• With the lower sample rate, the filtering bandwidth is a much larger percentage of the available Nyquist bandwidth and the filter's effects can be "stronger" with fewer audio artifacts.
• The settings of the DSP noise reduction have been revised so the effects are now audibly different.  A "new" setting called "Extreme" has been added.
• Because of the changes, the DSP filtering - including the FM de-emphasis and filtering - now are in effect on the audio recordings.
• The addition of (limited) Synchronous AM demodulation:
• Two new buttons, "SAM-U" and "SAM-L", have been added that invoke Upper and Lower sideband synchronous AM, respectively.  This can significantly improve the audio quality of received AM signals by eliminating distortion caused by the amplitude and phase of the carrier being upset by selective fading.
• Because the only audio available from the WebSDR that has intact both phase and frequency information are USB and LSB, it is these modes that are used internally to synchronously demodulate the AM signal.  This puts certain limitations on the operation of the demodulation:
• The AM signal must be tuned such that the beat note of the carrier of the AM signal being received is within the audio bandwidth, and it may be between about 50 and 1050 Hz.  The "SAM-L" and "SAM-U" buttons automatically offset-tune the signal to which you are tuned by 150 Hz internally, so the offset tuning is automatic if the signal is tuned to zero beat prior to switching to a SAM mode.  Internally, the audible CW note is used to lock onto the carrier and synchronously demodulate the signal.
• Because the audio is shifted within the passband, best frequency response will be obtained if the carrier is nearer zero Hz within the passband - but it's not recommended that it be tuned to be lower than about 60 Hz to keep it above the 50 Hz minimum.  While the demodulator will track the carrier up to 1050 Hz, the audio passband will be shifted up (at audio) and you will lose the top 1 kHz of audio frequency response.
• For SWBC listening, the Synchronous AM works well - but there is a possible problem if listening to an AM net where people are using "Vintage" rigs:  It's often the case that the carrier will be 1 kHz or more offset from the intended frequency.  This frequency shift can cause two possible problems:
• It may result in the carrier being above the 1050 Hz frequency limit.  This can happen if you are using "SAM-L" (lower sideband) and the carrier is greater than 1 kHz lower than the tuned frequency.  Similarly, if "SAM-U" is used, this can happen if the carrier is more than 1 kHz above the tuned frequency.  In this case, you may have to retune the receiver.
• If you are using "SAM-L" and the transmitted carrier is above the tuned frequency, it will be entirely outside the passband - and a similar case would be if you are using "SAM-U" and the transmitted carrier is below the tuned frequency.  In either case, it may be possible to change between "SAM-L" and "SAM-U" as appropriate.
• When using Synchronous AM, status information will appear just below the frequency display on the WebSDR.  This shows three pieces of information:
• Lock/Unlock:  This provides an at-a-glance look to determine if the synchronous AM detector is locked into the carrier of the AM signal being received.  Expect the display to occasionally show "Unlocked" during fading, if there is QRM, or if you retune the receiver.  Some GUI operations (e.g. zoom in/out, etc.) can also affect the recovered audio and cause brief unlock.
•  Tuned freq:  This shows the apparent frequency of the AM carrier.  This is done by using the actual, tuned frequency of the WebSDR and the frequency of the NCO (discussed below) to calculate the frequency of the carrier of the signal being tuned.  Because the WebSDR's receiver may not have its local oscillator reference perfectly adjusted, this may be a few Hz off.
• NCO:  This is the frequency of the "Numerically Controlled Oscillator" - a synthesized local oscillator used to do the synchronous AM demodulation.  It is this frequency that must be between 50 and 1050 Hz - and it is preferred that this frequency, when locked, be below 200 Hz to preserve maximum audio frequency response and fidelity.  Note that the frequency of the NCO is subject to the limitations of the 31.25 Hz tuning steps of the WebSDR server which is why, if you tune a known-accurate signal (a time station) the offset indicated by the NCO frequency will probably not be exactly the ideal 150 Hz.
• A few "quirks" and features:
• Aside from the limitations above, note that if you click on one of the frequency markers or one of your memories (the tags below the waterfall) it will switch out of SAM mode to whatever mode you selected.  At this time, you cannot "save" a Synchronous AM mode setting.
• When one of the SAM buttons is pressed, the bandwidth is automatically set to maximum which means that if you tune to the carrier's actual frequency and activate it, the frequency will shift by 150 Hz.  Because the highest audio frequency is about 3.8 kHz, this means that about 3.65 kHz will actually be available.  In the presence of QRM - after first selecting the sideband that has the least amount of interference -  you may want to move the sideband farthest away from the carrier closer to it:  For SAM-L, you would move the lower filter edge up in frequency and for SAM-U, you would move the upper filter edge down in frequency.
• The generation of the 90 degree audio phase shift used for synchronous AM demodulation isn't perfect, the "unwanted" sideband being attenuated by about 45 dB.  Normally, the artifacts of the original carrier are inaudible, but it may be heard in some instances during quiet periods of audio with high volume settings.
  
• There are a small number of Shortwave Broadcast Stations that appear to have an "improper" phase relation between the carrier and the sidebands, the result being that the audio recovery of these stations will be quite a bit lower than in standard AM.  This is being investigated.
  
• Please note:  These features are currently being tested and debugged:  If they are going to be incorporated into the other WebSDRs, it will be only after a week or two of additional testing at the earliest.
  

• 23 April, 2022:  Software being tested on WebSDR #3:
• After several weeks of testing on a "Test" WebSDR at home, code that constitutes a major re-work in terms of audio handling has been placed on WebSDR #3.  Whereas the previous code using DSP modified the sound file directly, that file was returned (nearly) to its original form and only simple "hooks" were installed, moving the rest of the code to an external file.
• In this testing, it's possible (likely!) that WebSDR #3 will occasionally be unusable as code is tweaked, is being updated, etc. - all events that could cause the page to not load properly in some way.  Typically, these issues will be only transient.
• As of this now, the only "new" feature from the updated code that is in use is the DSP noise reduction and notch filtering:  Additional features will be added in the near future.

• 2 April, 2022:  WebSDR GUI tweaked.
• On this day the WebSDR's GUI was adjusted to (hopefully) make the page layout cleaner and more predictable - namely:
• The "Bandwidth" and "Logbook" panes have been docked to the "Frequency" pane to form a single, larger control panel on the left.
• The "S-Meter" pane will, on a typical size screen (1024 to 1080 pixels across) be to the right of the combined pane.
• The "Waterfall View" pane will typically be to the left of that.
• As before, things might rearrange themselves slightly if the screen is markedly smaller than 1024 pixels across, but this should render OK on the vast majority of devices.  While it would be nice to have a page that rendered properly on all devices, not even the most ardent web authors can manage that - instead to resorting to completely different versions for mobile devices with small screens that either lack or hide many of the features/content, making the user open up tabs/dropdowns to see what they are missing.
• At about the time of the above change, it was pointed out that there was a problem with rendering on Chrome in which the lower portions of the page were chaotically arranged.  This was traced down to a single-letter typo from a change made about a week ago to fix an error that was being thrown by a browser due to the deprecation of some feature:  Firefox didn't seem to care - but Chrome certainly did, but neither of them showed any errors in the debug dialog!

• 1 April, 2022:  User/band scales optimized for amateur band coverage.  (No foolin!)
• Below the control boxes, near the bottom of the page are frequency scales that also include the username and their approximate tuned frequency.  Previously, these had to cover the width of the receiver for that band, but this tended to crowd everyone into just a small section of frequency band - particularly on 40 meters, the width of which constitutes less than half of the receiver bandwidth.
• As of today, "custom" scales have been implemented WebSDRs #1, #2 and #4 for the bands where it makes sense to do so.  These new scales are optimized to cover the just the amateur band (plus just a bit extra) so that users aren't crammed into a small section, horizontally.
• As noted, not all of the bands have custom scales - namely 160 and 30 meters, nor the wideband "low-performance" bands (e.g. 60 meters on WebSDR #1, none of the bands on WebSDR #3) and 10 meters, where pretty much all of the receivers' coverages are within the amateur band, anyway.

• 30 March, 2022:  Version 3 of the KFS WebSDR now online - New address! - kfsdr.com
• On this day "Version 3" of the KFS WebSDR in Half Moon Bay was made public, offering more bands than before:
• Coverage on 60, 17, 15 and 10 meters is now available.
• Coverage on 160 meters was dropped (at least for now) owing to current issues with the antenna system there:  The WebSDR software has a limit of just eight "bands", which is why 12 meters is not currently available.
• Using the same receivers and drivers as here at the Northern Utah WebSDR, coverage of up to 768 kHz bandwidth is now possible, permitting the coverage of 80, 60, 40, 20 and 15 meters in a single band.

• 20 March, 2022:  Modifications now on all Northern Utah WebSDRs:
• On this day, the modifications mentioned in the 18 March, 2022 entry were moved into place on  Northern Utah WebSDRs 1, 2 and 4 - and the "Salt Lake Metro WebSDR - completing a major update/reworking of the code base.  Modifications/changes include:
• "Alt AGC":  This is designed to overcome the deficiencies of the WebSDR's built-in AGC during AM reception:  The original AGC tends to badly over/undershoot, causing loud clicks and pops when signal strength is changing rapidly - mostly due to QSB, or when someone keys/unkeys.  The "Alt AGC" attempts to overcome these deficiencies as much as possible given the limitation of the existing WebSDR server.  The nature of this AGC is that the audio recovery will likely be a bit lower (e.g. quieter) than with the normal "RF AGC".  The "Alt AGC" works with SSB to a degree, but it is not optimized for such.  This may be invoked in the command line as one does with frequency and mode by adding "?altagc=1" to the URL.  This is disabled when FM is selected as its use does not make sense there.
• S-meter squelch.  This is a squelch that is based solely on signal strength and as such it probably isn't a good candidate for typical HF operation where signal levels and noise varies wildly as it is intended for FM reception on VHF/UHF bands (including 10 meters).  The "Set" button will preset the threshold about 6 dB above the current S-meter reading.     This may be invoked in the command line as one does with frequency and mode by adding "?smsquelch=X" to the URL, where "X" is the signal level, in dBM (as displayed on the S-meter) of the squelch threshold.  This control is not currently visible on WebSDR #1 as none of the bands that it covers typically have FM operation, but it may still be invoked via the URL.
• Mode display on "alt" VFO:  The VFO that is NOT being used now includes the mode, displayed next to the the frequency.
• "Apparent peak SNR" display:  In all modes, below the S-meter is this number which is the apparent signal-noise ratio of the received audio.  This is based on the peak and minimum audio over the past two seconds and simply displays the ratio between the two in dB.  Because of the way it works, it has some limitations:
• On a very noisy signal, it may read higher than actual.  This is due to the fact that brief "pops" (static) are detected, and this is why on just plain noise, it may read higher than 0 dB.
• It has no audio frequency weighting or filtering.  If the audio has a tone (heterodyne) or background hum, the SNR will be low - but this is to be expected.
• If the audio is muted due to squelch operation or from Internet buffering, the peak SNR may read very high as it's comparing "dead silence" with what was there.
• The SNR reading is slightly weighted to give more realistic values under real-world conditions.  In FM, this value is reduced by roughly 0.5dB while for other modes is about 1.8 dB.
  
• Deviation metering (in FM only):   When FM is selected, audio deviation parameters are also displayed, such as:
• Deviation (pk):  This shows the peak deviation, updated about 10 times/sec
• Avg.:  This shows a weighted average of the deviation over a period of about 2 seconds.
• Avg-pk:  This shows the "averaged" peak level.  The small number indicates how many samples were used to get this average and a value of 20 indicates 2 seconds.
• Min:  This is the minimum recorded deviation over the past two seconds.
• Max:  This is the maximum recorded deviation over the past two seconds.  It is this "Min" and "Max" data that is used to calculated the "Apparent peak SNR".
• Frequency shown after username in "user view":   In the frequency scales below the waterfall display, near the bottom of the page, the approximate frequency is displayed in square brackets after the username - which could also be an IP address or device type.
• It should now possible to provide alternate frequency scales - which can be useful for bands that are smaller than the frequency coverage.  For example, on WebSDRs 1 and 4, the entire 40 meter band is less than half of the coverage which means that the information is crammed into a rather narrow, horizontal space.
• There is a "quirk" to this display in that the calculation of the displayed frequencies of other users is based on assuming that they are running the same mode as you.  This is necessary as the mode of each, individual user is not easily accessible for the code being run on a users' computer where this information is calculated so the (reasonable) assumption is that everyone is running the same mode (e.g. LSB on 40, 80 and USB on 20 and above).  Because of this, the display could be off by about 2.5 kHz is you are set to USB and the "other" person is set to LSB.

• 18 March, 2022:  Modified code rolled into place on WebSDR 3:
• As sometimes happens when you have a number of servers that do "similar" things, the code base diverges and each one has its "own" thing.  This had happened at the Northern Utah WebSDR as each server needed its own modifications to its code and configuration, but with five servers, this became unmanageable.  What has been done is to move the items/code that are unique to a particular server into separate files that are included into the main files.  This now makes it possible to make a modification on one server, test it, and then simply copy that file to the others with little/no modification .
• This work has enabled a few features to be added to the Utah SDRs that have been undergoing testing and have been scattered about.  Included in these changes are:
• "Alt AGC".  Described in an earlier entry (see 12 March, 2022) this is an alternate to the WebSDR's own AGC which has serious flaws when used with AM - particularly on signals that are experiencing rapid QSB (flutter).  This algorithm isn't perfect and may be tweaked over time, but it seems to be superior to the built-in AGC for AM, at least.
• This AGC is based on the S-meter and, to a lesser extent, the audio level.
• When the frequency is tuned, the AGC levels are reset from scratch to allow it to quickly adapt to very different signal strengths.
• If the signal level changes very abruptly (e.g. when an AM station keys/unkeys) the AGC levels may also be reset to more-quickly adapt.
• It is not really intended for SSB use and while it works, you may want to stick with the normal "RF AGC".
• As the "Alt AGC" operates, you will see the grayed-out slider below the button move around in response to the signal level.
• This mode is DISABLED when FM is selected.
• You may activate the alternate AGC via the URL:  Add "?altagc=1" to the URL in the address bar in the manner that you would for specifying frequency and mode.
  
• S-meter squelch.  While the WebSDR has a "squelch" button, this is noise-operated and tends to be very slow and is unpleasant to use if you are monitoring FM repeaters.  The S-meter squelch operates MUCH more quickly and it does what it says:  If the signal is above the threshold set by the slider bar, you hear it - and if isn't, you don't.
• There is a "Set" button that simply sets the threshold about 6 dB above the CURRENT S-meter reading.  This should be used ONLY when there is NO signal present.
• Because it is based on signal level, it's not really suitable for HF use where signal levels can vary all over the map - but you are welcome to try it if you like!
• When the S-meter squelch is muting a signal, the words "S-Meter Squelch" appear in red just to the right of the MODE display.
• Do NOT expect this to work well at all with SSB or CW signals or very weak signals in general.
  
• Mode display on "alt" VFO:  The VFO that is NOT being used now includes the mode, displayed next to the the frequency.
• "Apparent peak SNR" display:  In all modes, below the S-meter is this number which is the apparent signal-noise ratio of the received audio.  This is based on the peak and minimum audio over the past two seconds and simply displays the ratio between the two in dB.  Because of the way it works, it has some limitations:
• On a very noisy signal, it may read higher than actual.  This is due to the fact that brief "pops" (static) are detected, and this is why on just plain noise, it may read higher than 0 dB.
• It has no audio frequency weighting or filtering.  If the audio has a tone (heterodyne) or background hum, the SNR will be low - but this is to be expected.
• If the audio is muted due to squelch operation or from Internet buffering, the peak SNR may read very high as it's comparing "dead silence" with what was there.
• The SNR reading is slightly weighted to give more realistic values under real-world conditions.  In FM, this value is reduced by roughly 0.5dB while for other modes is about 1.8 dB.
  
• Deviation metering (in FM only):   When FM is selected, audio deviation parameters are also displayed, such as:
• Deviation (pk):  This shows the peak deviation, updated about 10 times/sec
• Avg.:  This shows a weighted average of the deviation over a period of about 2 seconds.
• Avg-pk:  This shows the "averaged" peak level.  The small number indicates how many samples were used to get this average and a value of 20 indicates 2 seconds.
• Min:  This is the minimum recorded deviation over the past two seconds.
• Max:  This is the maximum recorded deviation over the past two seconds.  It is this "Min" and "Max" data that is used to calculated the "Apparent peak SNR".
• Frequency shown after username in "user view":   In the frequency scales below the waterfall display, near the bottom of the page, the approximate frequency is displayed in square brackets after the username - which could also be an IP address or device type.
• It should now possible to provide alternate frequency scales - which can be useful for bands that are smaller than the frequency coverage.  For example, on WebSDRs 1 and 4, the entire 40 meter band is less than half of the coverage which means that the information is crammed into a rather narrow, horizontal space.  This feature is currently undergoing testing on an offline test server.
  
• These changes will be tested on WebSDR #3 for several days and if all goes well, they will be rolled out to the other four Northern Utah WebSDRs.

• 12 March, 2022:  More tweaks on AGC - "Audio AGC" is now called "Alt AGC":
• More tweaking was done to the AGC algorithm and it now keys mostly from the S-meter reading - but it does act on detected clipping in the audio to minimize distortion on signals that are rapidly changing in signal strength (e.g. fast QSB/flutter).
• Even in its current, early state it appears to function better than the "RF AGC" that is default on the WebSDR in that it seems to be less susceptible to overshoot and distortion under QSB conditions.
• This AGC is not particularly well-suited for SSB signals owing to the fact that the S-meter reading on which the gain adjustment is based is delayed via the Internet and the fact that it is updated just 10 times per second.  What this means is that rapid changes in signal strength - which is what SSB is all about - cause overshoot on leading edges of signals - that is, for the instant a signal first appears and/or after a long pause by the speaker at the other end.  Because AM has a continuous carrier, this is not so much of an issue, except at the instant the transmitter is first turned on.
• This will undergo more tweaking and observation and if it seems to work well under a wide variety of conditions, it may be rolled out to the other Northern Utah WebSDRs.
• The URL-based switch has been renamed, and it is now "?altagc=1" that is specified in the URL to invoke the WebSDR with this AGC mode selected.
  

• 9 March, 2022:  Experimental audio AGC being tested on WebSDR #3 to improve quality of AM reception:
• An audio-derived AGC is currently being tested on WebSDR #3 and as the name implies, it adjusts the signal gain based on the audio level being received.  This code is a step along the way in an attempt to address a flaw in the current WebSDR server's AGC when listening to AM:  The tendency of the the audio to wildly undershoot on AM signals with rapid QSB, causing bursts of noise (loud clicks) and brief audio drop-outs while it tries to track a signal with rapid QSB (e.g. fluttering signal strength).
• If you know anything about audio-derived AGCs, you'll also know that they actually DON'T work on AM signals for one simple reason:  If the AM signal is unmodulated, there's nothing for the AGC to key on and the gain will be driven way up.  This incarnation works on many amateur AM signals only because very few of them will be super strong and background noise will always be present, allowing this test code to work at least somewhat.
  
• Remember:  This feature is experimental and is being done to test other aspects of the code.  It's hoped that this "alternate" AGC system - which probably won't be called "Audio AGC" - will primarily key from the S-meter reading, using the audio itself only secondarily in the process.
  
• There are two ways to enable this experimental AGC:
• Use the "Audio AGC" button.  This button may be found in the window with the S-meter under just under the "Gain Control" label:  Simply click "Audio AGC".
• Use "?audioagc=1" in the URL-specified tuning parameters.  This is done in the same way as specifying the frequency and mode.
• Modification of "Manual" gain control:
• On a related note, the "Manual" gain control has been present for quite some time, but it has been entirely manual:  If you set it too low (to the left), the audio will be quiet but if you set it too high (to the right) audio can be badly distorted.  A bit of code has been added to automatically reduce the gain if the signal level is way too high (e.g. distortion and clipping results) for the current setting and you'll see the "Gain" slider move down by itself if you try to set it so high that it distorts badly.

• 6 March, 2022:  10 meter receivers retuned
• On this day, changes were made to the 10 Meter Low receivers on WebSDRs 2 and 4:  Their center frequencies were moved up by 100 kHz to accommodate more of the SSB passband when 10 meters is open without having to use the 10 Meter Hi receiver.
• Changes were also made to the 10 Meter Hi receivers on WebSDRs 2 and 4, moving their centers up by 50 kHz to reduce the image response on the higher end of the band (near 29.7 MHz) to FM operation from images found at the bottom of 10 meters (e.g. FT8, strong CW.)
• These changes were brought about by improving conditions on the higher bands as sunspot cycle 25 continues to gain strength.  Expect additional changes as necessary to deal with the ever-stronger signals as conditions improve over time.

• 28 February, 2022:  The fourth anniversary of the Northern Utah WebSDR's officially going online!
• It was on this day in 2018 that the Northern Utah WebSDR went online from the remote northern Utah site. 
• The WebSDR was first put online publicly on 17 January, 2018 from a (noisy!) location near Salt Lake City during which the hardware was gradually being built and tested.
• The only server at that time was #1 (of course!) which included coverage of the AM broadcast band (plus all of 160 meters), about half of 160 meters using a higher-performance receiver, the upper 2/3 of the 80/75 meter bands, 60 meters, and the upper half of 40 meters.  20 meters was added at the last minute (because we could) but the receiver hardware performed poorly - but it was (slightly!) better than nothing!
• It was a few weeks later (on 18 March) that WebSDR #2 was added, improving coverage on 20 meters and adding 30 and 17 meter coverage as well.
• At this time, enhancements were made on WebSDR #1 including the improvement of the 160 meter receiver, the addition of the bottom third of 80 meters and the bottom half of 40 meters.
• A day later, 2 meter coverage was added to WebSDR #2, and a few days after this, coverage of the "beacon" portion of 10 meters was added.
• Additional comments:
• Label change.  The "Atten" label just below the S-meter was changed to "RF AGC" to better-reflect what it's intended to convey.  This information is present only on those bands using receiver modules with hardware AGC under software control (e.g. 75/80 and 40 meters on WebSDR #1, 20, 15 and 10 low on WebSDR #2 and 40, 20, 15 and 10 low on WebSDR #4.)
• "10 Meter Low" band limits to shift on WebSDRs #2 and 4:
• At the next opportunity, the 10 Meter Low center frequency will shift up 100 kHz to better-suit SSB activity when 10 meters is open.  This will likely be done at a late hour (local time) when the number of users on WebSDRs 2 and 4 are low as this will require a restart of the WebSDR.
• At the same time the 10 Meter Hi receiver will be reconfigured on WebSDRs #2 and #4 as well:  We will either shift its center frequency up by 50-100 kHz or (less likely, but still possible) change the overall bandwidth from 1.536 up to 2.048 MHz.  With the 10 meter band's conditions improving, the limitations of the hardware for the 10 Meter Hi receiver are becoming apparent in the appearance of images from strong signals near the bottom of the 10 meter band, and either one of the aforementioned changes should mitigate this issue.
• "Utah SDR Telemetry" frequency change:  During the next site visit the frequency of the CW telemetry will be changed to something closer to - but below - 29 MHz, yet to be determined.  This will be done as the SSB activity can spill up the band around the current frequency (approximately 28.57 MHz) and be QRMed by the telemetry signal.
  

• 25 February, 2022:  Comments.
• WebSDR #3 hiccups:
• A few days ago a new version of the "wsprdeamon" script - which is used to receive and process WSPR signals across multiple bands - was installed as a beta test.  This new version has the capability of receiving some of the "new" WSPR-type modes, namely the "FST4W" modes, and it is is a major step toward making it even more hardware and mode agnostic over time.
• Since it is "beta", it still has some issues, namely it would randomly spawn processes - and it did this with great fecundity, eventually consuming all RAM and CPU cycles in the process, bringing WebSDR #3 to its knees.
• A reboot (to clear the wreckage) and reverting back to the previous version has restored sanity - for now.
• Frequency entry now allows frequency in MegaHertz to be entered.
• A tweak to the code was mode so that you may now enter the receive frequency in MHz by typing it in the "Frequency" box.  That is, if you wanted to tune to 3579.55 kHz, you could enter either "3579.55" or "3.57955".
• If you enter the frequency in MHz, the system will immediately convert it to kHz and tune there.  If you attempt to enter a frequency not covered by any receiver on the WebSDR us are currently using, it's likely that nothing will happen at all.
• This is possible only because there isn't currently a Northern Utah WebSDR server that covers more than a 1000:1 range:   WebSDR #3 used to fall into this category, covering both 2200 and 2 meters, but it no longer does,  so it's possible to determine if MHz was intended simply by the magnitude of the number entered.

• 21 February, 2022:  Minor changes.
• In the past few days, a few minor configuration changes have been made:
• Noise blanker threshold adjust for 60 meters.
• It was observed that around 60 meters, the power line noise was particularly bad:  A known issue with a noisy power line exists around 2.5-2.6 MHz and it is the second harmonic of this that can affect 60 meters.  (We will be looking for this noise source this spring and hopefully, with the cooperation of the power utility, tame it down a bit.)
  
• The WebSDRs have an impulse-type noise blanker very similar to that found in HF transceivers in that it will detect a strong, narrowband impulse - such as that from power line arcing - and blank it.  Because this blanker must operate on the widest-bandwidth portion of the receive data, which is common to all users on that band, this is not a parameter that can be made adjustable by individual users.  Furthermore, any change of this value requires that the WebSDR be restarted.
• Frequency shift for "10 meters lo" on both WebSDR #2 and #4.  
• As noted in the 26 January entry, the original "center" frequency of this receiver landed right on the frequency for the "International Beacon Project" of 28.2 MHz - but since the receive hardware has the characteristic of putting a "hole" of a hundred Hz or so right at this frequency, this dramatically impacted the ability of these receivers to hear the beacons.
• Both WebSDR #2 and #4 were restarted and the new center frequency was set to 28.198 MHz, preventing this problem.
• Sensitivity issue with the 12 meter receiver on WebSDR #4.
• The receive hardware being used on 12 meters on this receiver is a FiFiSDR - a stand-alone USB-based "softrock" type receiver.  Unfortunately, this hardware has a quirk that when it is started up - and, apparently, over a period of time, it may "glitch" its start-up and cause the receiver gain to be set to the wrong value, the result being a rather high noise level (high no-signal "S-meter" , a "bright" waterfall, and possible "deaf" receiver).  The only "fix" to this is to restart the WebSDR (sometimes it takes several attempts) which causes the hardware to be reinitialized.
• This issue had been noticed on #4's 12 meter receiver, and when the 10 meter frequency change was implemented, this was addressed, too.  While this problem occurs during start-up, it rarely happens once the system is up and running (I don't remember having seen it do it before!), but it's easy to fix.

• 26 January, 2022:  Quick site visit.
• During the previous week, two of the KiwiSDRs (#'s 4-5) went offline on 21 January and on this day, there was time to investigate.  The problem turned out to be a flaky connection inside the power supply running these two units:  A Molex-type of nylon connector on the mains side had become intermittent, so a bit of cleaning, strategic tightening of a springy connector and a very light application of dielectric grease on the pins restored operation to normal.
• It was also observed at some point since the November, 2021 receiver upgrade that the "10 Meter Lo" receivers on WebSDRs 2 and 4 is centered on 28.200 - the same 10 meter frequency on which the IBP (International Beacon Projects) propagation beacons operate on that band.  Because there is a very narrow "hole" right at the center of the frequency range of many SDR-type receivers, it's possible that these signals - when they appear - may fall in this hole and be significantly weakened/inaudible.  Because of this the configuration of #2 and #4 have been changed to move this "hole" down by two kHz to 28.198 kHz.  As of this writing, WebSDRs 2 and 4 have not yet been restarted to make these changes take effect, but this will automatically happen when they are.
• In the coming months (when they become available!) the router and switch on site will be replaced.  While the current gear usually works, there appears to be a firmware or hardware issue in which they can no longer be monitored or configured, requiring them to be power-cycled - and there is the possibility that it could even stop passing traffic.  The replacement candidate hardware is not known to have such an issue.  When these units are eventually replaced, there will be a complete outage of WebSDRs 1-4 and the on-site KiwiSDRs, but it is our policy to announce scheduled outages several days in advance.  (If only we could be aware of unscheduled outages ahead of time!)
  

• 6 January, 2022:  70cm added to  Salt Lake Metro WebSDR:
• On this day coverage was added to the "Salt Lake Metro" WebSDR (see the 23 December 2021 entry, below, for more information about this server) adding the top 4 MHz of the 70cm amateur band.  Because Utah uses a negative split on 70cm, this coverage encompasses the entirety of the 70cm repeater output sub-band.
• In progress is another receiver designed to receive the Earth<>Space portion of 2 meters (145.8-146.0 MHz).  Because of its narrower bandwidth and additional filtering, it should have much greater sensitivity (within its intended passband) than the other receivers on the system on order to have reasonable performance - and this is only possibly by restricting its frequency coverage.
  
• The system is still being tweaked, but it appears to be working as it should. 
• This WebSDR may be found HERE.

• 29 December, 2021:  WebSDR #2 - Frequency/Temperature compensation enabled on the 30, 17 and 12 meter receivers..
• A few weeks ago (See the November 6 and 10th entries and the December 10th entries, below) we did some major reconfiguration of the receivers at the Northern Utah WebSDR.  In the process of doing this, several of the receivers that had been committed to the bands that had been upgraded were no longer being used, so they were redistributed to improve performance/bandwidth of other bands - specifically, the 30, 17 and 12 meter bands on WebSDR #2.
• These "new" receivers now in use on 30, 17 and 12 meters use Si570 frequency synthesizers which are rather temperature sensitive.  In the past, a means was devised where the temperature in the building was measured and a look-up table was used to adjust the frequency to compensate for thermally-related drift:  This system was described in detail in the 9 December, 2020 entry (on this page).
• For whatever reason (I'll blame life getting in the way) the temperature compensation for the new receiver configuration was never set up - until today, when I had time, my memory having been jogged by an email from a user wondering why the 17 meter receiver was about 90 Hz off:  I observed a few 10's of Hz errors on the 12 and 30 meter receivers as well.
• The building of the frequency-versus-temperature information takes time as it requires manual correlation of the reported temperature with the needed frequency correction, so building this table will take months as the internal temperature changes with the seasons - the range being from as low as 10F (-12C) to as high as 125F (52C), so making a full-range table takes some effort.
• This temperature-based frequency correction has been shown to hold to within 10 Hz or so - little enough that it is not likely to be noticed by most users.  These corrections occur at the top of every minute that is evenly divisible by four, so they should not interfere with time and frequency sensitive digital modes like WSPR, FT-8 and others.

• 28 December, 2021:  19 Meter receiver on WebSDR #3 back online... for now...
• It so-happened that one of the hams that has been involved with the WebSDR happened to be passing by (going to the historic site) and kindly swapped in a different USB extension cable for the 19 meter receiver.  Because we'd already swapped out the receiver itself, we had more or less ruled out it as a problem (a coincidental failure of both would seem unlikely) so this time we tried the cable - which also exercised the connectors at both ends.  The receiver appeared to come up properly upon doing this.
• Let's hope that the third time is the charm and it continues to work!
  
• Sharp-eyed readers may have noticed that I originally mis-wrote in the 25 December entry about the failure of the 31 meter receiver - which was not correct!

• 25 December, 2021:  31 19 Meter receiver on WebSDR #3 offline - again!
• The recent "problem child" that is the 31 19 meter receiver on WebSDR #3 is offline, again.  A few weeks ago, the receive hardware itself was swapped out and everything seemed fine - until sometime in the past day or so when it abruptly went offline.  If you go to the 31 19 meter receiver now, you'll see no signals at all because that band "slot" has been reconfigured to point to a sound card with nothing connected as a "place holder".
• Often, one can force a reconnection if it's a software issue (e.g. restart the WebSDR service) but that didn't work - and neither did a reboot, after which the receiver itself didn't even show up in the logs as being connected.
• It seems unlikely that the receiver itself has failed, so it is more likely a flaky connection on the USB cable - or a problem with the cable itself.  In either case, it will be down until a site visit can occur, which will likely not be for at least a day or two.

• 23 December, 2021:  Some changes:
• New server added.
• On this day a fifth WebSDR associated with the Northern Utah WebSDR was made public - a WebSDR that covers the Salt Lake City, Utah metro area on 2 meters.  This server may be found HERE.
• This "local" server has been in the consideration/planning stages for quite some time, supplementing the 2 meter coverage offered by WebSDR #3 (blue) from its rural location near Brigham City, Utah.  While this rural receiver can be used to listen to mountaintop repeaters across much of Northern Utah, its coverage of routine simplex operation is limited by its location, far from the main population centers.
• This "new" server is located in the foothills of the mountains on the east side of the Salt Lake valley, about 10 miles (16 km) from downtown Salt Lake and as such, it has a better view of mountaintop repeaters in the Salt Lake and surrounding valleys and it can also hear simplex signals and transmissions on the inputs of local repeaters from anywhere in the valley.
• Because of geography, it is somewhat shielded from ground-based stations (e.g. simplex, users on repeater inputs) that might occur to the north of Salt Lake (e.g. Davis, Weber, Box Elder), west (Tooele County) and the south (Utah County).
• This WebSDR uses a pair of RTL-SDR dongles to cover the entire 4 MHz of the 2 meter band using a discone antenna at about 30 feet (9 meters) above ground.
• The AGC on these receivers is disabled and the gain manually set to just be able to accommodate the signal power that is likely to impinge on the receivers when many of the local repeaters are simultaneously transmitting.  Because of this configuration, it is possible to calibrate the S-meter on this WebSDR - (and all receivers at the Northern Utah WebSDR) to indicate the absolute signal power at the antenna terminals of the signals being received, allowing monitoring of apparent repeater ERP and to make determinations of the efficacy and probable distances to these and other transmitters.
• URL-specified parameters added:
• As you may know, you can specify the frequency and mode in the URL as follows: 
• http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb - This will tune to 7272 kHz using LSB.  The frequency must be in kHz and can include a decimal (e.g. "?tune=7181.5lsb") 
• We have added several more URL-specified directives:
• Enable squelch.  If you wish to load the page with the squelch enabled:
• Add "?squelch=1" to load the page with squelch enabled, as in:  http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb?zoom=1
• Disable DX labels:  If you would rather NOT have the labels under the frequency display on the waterfall:
• Add "nolabels=1" as in:  http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb?nolabels=1 
• Zoom in on the tuned frequency.  If you wish to have the waterfall zoomed in when you load the page, you may specify a number from 0 (full width of the receiver) to 5-8, the maximum number depending on the band.  If you specify 9, will be assured to zoom in fully (e.g. the same as the "max in" button.)  For example:
• Add "zoom=x" where "x" may be 0-9, as in:  http://websdr1.sdrutah.org:8901/index1a.html?tune=7272lsb?zoom=9
• One or more of the above can be combined as shown.
  

• 10 December, 2021:  Site visit.
• 19 Meter receiver replaced:  The RTL-SDR used on WebSDR #3 (blue) for the 19 meter SWBC band was replaced, having randomly gone offline a few times in the days prior, finally becoming unresponsive.
• 31-30 meter moved to WebSDR #3:  The  "31-30 Meter" receiver, which covers the 31 meter SWBC and 30 meter amateur bands, was moved from WebSDR #2 (green) to WebSDR #3.
• 30 meter "High Performance" receiver now on WebSDR #2.  Due to recent upgrades, extra hardware was available, allowing a "High Performance" receiver to be configured for 30 meters on WebSDR #2 (green).  This "new" receiver uses a 16 bit sound card and a "softrock" receiver, providing much superior performance on the 30 meter band as compared to the older "31-30 meter" receiver hardware.  This receiver spans about 192 kHz from just below 10 MHz to a bit above the top of the 30 meter amateur band.  As noted above, the "old" receiver was moved to WebSDR #3, which seems to be the home for several SWBC receivers. 
• 15 November, 2021:  25 Meter SWBC receiver on WebSDR #3 offline.
• On this day it was observed that both the 25 and 19 meter receivers on WebSDR #3 were offline.  An attempt to restart the WebSDR server itself failed to restore the operation of either receiver, so the computer itself was rebooted.  Upon reboot, the 25 meter receiver - an RTL-SDR dongle - was not being enumerated, indicating that it has either failed, or there is a problem in the USB connection to this receiver.
• As a "place holder", the server's built-in sound card was configured as a stand-in for the missing receiver:  There is no actual receiver hardware there, but this allowed the WebSDR to be brought back up with minimal reconfiguration until the cause of this failure can be investigated and remedied.
• Update:  This problem was resolved on 16 November when it responded to queries, so it was reconfigured.
  

• 12 November, 2021:  Minor modifications to the WebSDR operation
• Attenuation feedback:
• One of the features of the new drivers for the SDRPlay receivers is the ability to monitor the incoming signals - and if the level gets above a certain threshold, the input gain is reduced - in effect, it's a slow AGC (Automatic Gain Control).  This allows the receivers to tolerate very strong signals without overloading while minimally impacting the overall sensitivity.
• As you would expect, changing the attenuation will also affect the S-meter calibration, so we have come up with a means of conveying the current attenuation setting of the receiver so-equipped to the web page running on the user's computer.  This data - which is (currently) updated every 2.5 seconds, corrects the S-meter.
• For purposes of debugging and general interest, this attenuation value is displayed immediately to the right of the numerical S-meter readings.  Note that not all receivers have this capability, and this information is not displayed for those receivers that lack it.
• For the present time, this attenuation value is not being used to adjust the waterfall, so you may see shifts in its brightness coincident with the change of attenuation.  Note also that because the attenuation value is updated periodically, the correction applied to the S-meter (and the Signal Strength plots) may slightly lag the actual attenuation value.
• From a technical standpoint, having this visual feedback will help us "dial in" the AGC settings to ultimately yield the best-possible performance.  The initial impression is that the AGC is overly-sensitive in its tendency to increase attenuation and a bit too quick in its decreasing it again when the strong-signal condition has subsided.
• As the time of writing, this "feature" is present only on WebSDR #4.  After additional testing and possible debugging, it will be rolled out to WebSDRs 1 and 2.  At this time, WebSDR #3 does not have any SDRPlay receivers.
• This feature is now present on WebSDR's 1 and 2 for those bands using supported receivers - but not on WebSDR #3 as that has no receivers with that capability.
  

• 10 November, 2021:  A few comments.
• Server reboots:
• In the late morning (local time) we had to reboot WebSDRs 1, 2 and 4.  It seems that when we upgraded the operating system the "snapd" software - which is intended to help automate software package management - started behaving capriciously.  We had hoped that with the new OS version that we wouldn't have the same compatibility problems that had occurred after upgrading WebSDR #3 some months ago, but this wasn't the case:  It adversely affected parts of the operating system, maxing out CPU utilization and the Internet connection at times and, for some reason, crippling the LAN connection (making it go to 100 Mbps half-duplex!) while doing whatever it decided that it had to do.  Since it isn't at all relevant to our needs on a WebSDR server, it was removed from the systems manually, requiring a reboot.
• Note to self:  When we update the OS in the future on a WebSDR, make sure that we kill "snapd" immediately!
• Slight signal deficit on the 12 meter receiver on WebSDR #4:
• There would appear to be not-quite-enough system gain on the 12 meter port on the WebSDR #4 signal path which means that when 12 meters is closed, its sensitivity is very slightly less (perhaps 3-6 dB) than required to hear the "band noise" comfortably above the A/D quantization level.  On the next site visit we'll add a bit of gain to assure that it's capable of "hearing" any signal that might be present.  If this is the biggest mess-up that we made during the most recent site visit, we are doing really well!
  

• 6 November, 2021:
• Upgrade of WebSDR #1:  "In for a penny, in for a pound."
  
• Because we could, we threw some RSP1a's at WebSDR #1, combining the former three "band" coverage of 80 and 75 meters and also the two 40 meter segments into two single segments that each cover their respective bands.
• General comment on the upgrades:
• As noted below, these upgrades rely on custom Linux drivers/programs that are still in their "beta" testing phase, but we've been testing them for weeks on a non-public WebSDR server.  Additionally, we'll be tweaking the AGC settings of these drivers - something that can only be done in-situ with wide dynamics of real-world band conditions.
  
• Comments on the RSP1a and drivers:
• "Who else uses the RSP1a's on their WebSDRs?"
  
• although many other WebSDRs in the world use RSP1a's, but they use the "RTL-SDR" interface.  The advantage of the RTL-SDR 8-bit interface is that it's capable of reasonably high bandwidth - a least 2.048 Msps, but is limited to just 8 bits which limits the dynamic range of the receiver and degrades the noise performance.  Typically, use is made of the AGC to scale the input signal to the available dynamics of the 8 bit pipeline which extends its usefulness and the resulting performance of RSP1a's run in this manner can be better than the RTL-SDR (and is more convenient to use), but it doesn't make the best use of its capabilities.
  
• The "other" interface available with the WebSDR software is ALSA, primarily intended for use with sound cards.  "Out of the box", Linux doesn't know how to deal with sample rates exceeding 192 kHz but we are fortunate that, a few years ago, the ALSA core was modified to allow up to 768 kHz of bandwidth:  Unfortunately, most related programs won't work beyond 192 kHz.
• Through a coordinated effort, we were able to determine another means of getting raw "I/Q" signal data from the receivers and into the WebSDR program, modify some of the drivers - specifically, the loopback and "aplay", and we now have specially-patched versions of each that have removed this limitation and can pass data at the 768 kHz rate, which is the limit of the existing kernel. Fortunately, the WebSDR software itself is capable of handling 384 and 768 kHz natively - so all we need to do is get data from the RSP1a into the ALSA system.
  
• A special driver was written to use the SDRPlay API that does just this, piping the raw I/Q audio into "aplay" which then can be piped into ALSA using the (specially-patched) version of the loopback driver.  The result is that we are able to throw up to 768 kHz from the SDRPlay into the WebSDR server.
• While the SDRPlay API has an AGC function built into it, extensive testing has revealed that it is not really appropriate for a system where there are multiple users spread across a wide bandwidth.  While it might be fine to have the built-in AGC adjust signal levels for a single user, it would be distracting to have the entire waterfall change apparent brightness.  It was also determined that the usability of the AGC parameters was both limited and cryptic, so we started from the ground up, implementing an AGC system in our own driver that is completely configurable, the thresholds of operation based on monitoring the 16 bit raw data from the A/D converters and taking appropriate action.
• Comment:  It should be possible to use any receiver hardware for which it is possible to get raw I/Q samples to work with the WebSDR program in this manner so the front end need not be an RSP1a.  In theory, the "universal" Soapy SDR receiver software could be used with the WebSDR in this way given an appropriate driver - but the caveat is that one must minimize the pipeline delay as much as possible to maximize usability of the WebSDR.
  
• "Is it stable?"
• Admittedly,  these drivers are still in "beta" stage and undoubtedly have a few issues, but they have been exercised for several weeks on a non-public test server.  Likely, a few tweaks will be required to best-set the AGC parameters and to address currently-unknown stability issues.
• Operating system upgrades:
• Up to this point, the four WebSDR servers had been running several different versions of Ubuntu Linux ranging from 16.x to 20.x, so we took this opportunity to upgrade all of them to Ubuntu 20.x.  As it turns out the RSP drivers' code wasn't readily compatible with version 16.x anyway (although it did work on 18x).
  
• Stability of WebSDR #2:
• Coincidentally, WebSDR #2 has been acting up for the past day or two, occasionally hanging up for reasons not recorded in the log files.  When we pulled the server off the rack to install more USB interfaces for the RSP's, we blew the dust out and re-seated the RAMs.  Having determined that the SSD (Solid State Disk) reported that the drive was healthy, we don't think that that was the issue - but we are prepared to replace the hardware if necessary.
  
• Comment:  Updates to the "Technical Info" page are pending.
  

• 5 November, 2021:
  
• Upgrade of WebSDR #4
• WebSDR #4 (Magenta) has been significantly reconfigured:
• 40 meters:  Formerly, 40 meters was covered with two receivers, "40CW" and "40PH" because the limitation of sound cards used with the "SoftRock" receivers was a bandwidth of 192 kHz - the actual, usable coverage being 180-something kHz, so two segments were needed to cover all 300 kHz of this band.  As with the 20 meter receiver a few weeks ago, an SDRPlay RSP1a was used to provide continuous coverage of the entire 40 meter band.  Because we can, the, the receiver is configured for 768 kHz of bandwidth and the actual coverage is around 700 kHz owing to band-edge filtering.
• Note:  Compared to the 40 meter receiver on WebSDR #1 there is additional "edge darkening" on the waterfall and a slight "hump" in the noise floor between 7025 and 7100 kHz.  This is due to the super-sharp 40 meter band-pass filter that has been installed to suppress the (sometimes) super-strong shortwave broadcast signals that appear on the adjacent 41 meter SWBC band.  On a future visit, a bit of tweaking of that filter may be in order to try to level out the "hump" a bit."
  
• 15 meters:  The same type of upgrade was performed for 15 meters as well, covering the entire band with one "receiver".  This is an upgrade of the older receiver which utilized an 8 bit RTL-SDR dongle preceded with a frequency converter, whereas the RSP1a has at least 14 bits of usable resolution, making it more "future proof" in the (hopefully) coming days where improved propagation brings many dB stronger signals.  This receiver is also configured for 768 kHz of bandwidth.  The downside is that most of the 13 meter shortwave broadcast band is no longer covered.
  
• 10 meters:  Because the 10 meter band is 1.7 MHz wide, it's too wide for even three RSP1a's, so approximately the lower 1/4th of the band is covered with an RSP1a (e.g. "10M-E Lo") and the rest of the band is covered with the original RTL-SDR+converter based receiver ("10M-E Hi").  The rationale behind this configuration is that the best receiver will be where there are the weakest signals of the greatest interest to the largest majority of users whereas the "rest of 10 meters" is still covered with the original RTL-SDR+converter receive system.
• We also put a quad-core processor in this server, upgrading it from a dual core due to the higher processing loads of the new signal acquisition hardware, and because "why not"?
  
• Upgrade of WebSDR #2:
• In a manner similar to WebSDR #4, RSP1a's were installed on this server, combining the two 20 meter segments into a single "band", 15 meters was switched to higher-performance hardware and 10 meters is covered by both an RSP1a and the original RTL-SDR+converter.
• Minor repair of the TCI-530 antenna:
• As noted in the 9 October, 2021 notes, we'd observed two wires touching on the TCI-530 Omni antenna - something that was likely present from the day that it was installed.  If we shook the tower via the guy wires, we could hear a "crackle-crackle" on the lower bands (weakly on 40 meters, stronger as one went down in frequency) as these wires vibrated - which makes sense as the wire involved is one of those at the lower frequencies.
  
• On this day, we were able to climb this tower (something that is absolutely miserable owing to its non-standard lattice configuration) to the 60-ish foot level where we tied one of the wires back, pulling it closer to the tower using an insulator, Dacron rope and a piece of garden hose (to prevent chafing of the rope on the tower) to prevent these two conductors from touching and causing noise issues.  There is one more place where the wires are very close (an inch/cm or two) from each other, but we believe that these two wires only touch when there are high winds.  Because the near intersection of these wires is another 15-ish feet up and a few feet away from the tower, it will have to go un-tethered until we have some sort of man lift or crane to reach it.
  

• 4 November, 2021:  WebSDR #2 offline.
• According to system logs, WebSDR #2 (Green) went offline just after 0300 MT and as the time of writing, the cause is unknown.
• A bit after 8 PM (MT) we able to go onsite to look at the server and there's evidence of a Linux Kernel Panic and the computer hadn't been able to reboot on its own.  A "hard" power cycle brought it back online.  Self tests were done - including the Solid State Drive - and no problems were found, but if this happens again in the near future, we'll simply replace the server.
• Update - It happened again:  It would seem that WebSDR #2 only stayed online for an hour or so after being rebooted, indicating a likely hardware failure:  We'll replace the server.
  
• Site visit scheduled for 5 November:
• As it turns out, we were able to arrange a site visit for Friday, 5 November, so expect outages on all servers tomorrow while we do server and infrastructure upgrades.
  

• 12 October, 2021:  Widespread network outage!
• In the early hours on this day it was reported that packet loss on the carrier used by the WebSDR's ISP started increasing, culminating with a complete outage a bit after 0640 (MT) local time.
• This outage was apparently fairly wide spread as it appears to be affecting about every ISP using the same backhaul carrier/fiber operator (e.g. Utopia) - and it seemed to adversely affect mobile/cell phone service in certain areas:  Phone calls were known to work for at least some of the carriers, but data coverage in some locales was either out or very spotty, either due to outright outages or because of heavy loading by users attempting alternate means of network connectivity.
  
• Upon arrival at the fiber landing site, the main router connected to the fiber was showing an error state, so it was rebooted around 0904MT:  This action seemed to bring back the network connectivity, although some aspects of configuration/routing still appeared to be incorrect.
• Later reports indicated that the outage was caused by a configuration error by the fiber operator.  Unfortunately, they couldn't fully "back out" once the mistake was made and some manual intervention by their individual customers was required to do the initial restoration, followed by additional back-and-forth to get things fully operational on all levels.
  

• 9 October, 2021:  WebSDR Site visit.
• WebSDR #4 reconfigured:
• With the successful installation and operation of the new 20 meter hardware (see below) we were able to free up one of the eight "band" slots on this WebSDR.  This also freed the two FiFiSDRs that had been used for coverage of 20 meters.
• 17 meter coverage expanded:  Previously, the coverage on 17 meters has been limited because the only available sound card was capable of only 96 kHz - not quite enough to cover a 100 kHz wide band.  One of the FiFiSDRs that had been used on 20 meters is now being used to coverage 17 meters in its entirety.
• 12 meter coverage added:  The other FiFiSDR was used to add coverage of the 12 meter band, also in its entirety.
• 30 meter sound card changed:  With the switch of the 17 meter receiver to a FiFiSDR, a high-quality ASUS sound card was freed up, allowing the reassignment of the 30 meter - which had been using the (available) sound card on the computer's motherboard.  This will probably not have an obvious change in the signal quality, but we feel better about doing so!  Like the on-board sound card, this "new" card is capable only of 96 kHz, but this is more than adequate for a band that is 50 kHz wide.
• Coverage of 12 meters on WebSDR #2 expanded.
• Since we had it as a spare, we decided to use an extra FiFiSDR receiver to expand the coverage of 12 meters from the 96 kHz, as limited by the available sound card, to 196 kHz, allowing full coverage of that band on WebSDR #2 as well.
• Many interruptions later...
• To properly  install/reconfigure these new devices, the WebSDRs had to be restarted several times, inconveniencing the users on them at the time.  To be fair, we did put bright red banners on the WebSDRs on which we were working, so users were warned of this, so we can't feel too bad about it!
• TBD:
• During a routine inspection of the towers and guys, we happened to shake the wires, feeling for looseness and one of us noticed something that we'd missed before:  One of the longer elements - probably for 4 MHz or so - appears to be touching one of the wires for a matching stub at about the 55 foot level.  On a nicer day - probably in the spring - a climb of this tower is in the future.  Because of the geometry, about all we can do is tie back one of the errant wires with some dacron rope and an insulator or two to hold them apart.
  

• 6 October, 2021:  Additional testing on WebSDR #4 with the SDRPlay hardware:
• After months of testing and tweaking, we are pleased to announce the testing of a new receiver configuration, made possible with the efforts of several supporters of the Northern Utah WebSDR:  The ability to provide wider-band receiver coverage than ever before with high bit depth.
• You may notice that several of the receivers at the Northern Utah WebSDR have bandwidths of 1 MHz or greater, but these must use an 8 bit pipeline originally designed for the RTL-SDR receivers.  While this driver was later adapted to use other hardware - like the SDRPlay USB receiver cards, the pipeline is still limited to 8 bits, sacrificing the full potential of this hardware.  Through the use of proper filtering and amplitude dynamics it's possible to get reasonable performance with just 8 bits by pre-processing the data, but it's still a limitation.
• Up to now, the highest-speed sound cards available (for a reasonable price, anyway) have been those that operate at up to 192 kHz, which is why many of the bands have to be implemented using several receivers.  For example, it takes three such receivers to cover all of 80 meters, and two each for 20 and 40 - and more than that if we wanted to cover15 and 10 meters 192 kHz at a time!
• As it turns out, the WebSDR software has no specific limit for its audio sample rate - but the Linux operating system does, so this has been patched, and a special driver has been written for the SDRPlay hardware to be able to pipe this data into the Linux sound system at up to 768 kHz.  In theory, a higher rate might be possible, but this would likely require considerable reworking of the Linux sound kernel, so it's unlikely to be done anytime soon.
• New 20 meter configuration on WebSDR #4:
• We are now testing this new configuration on the "20 meter" band on WebSDR #4, covering the entire  20 meter band in "one fell swoop" with a 768 kHz passband.  At the moment, our only other choice for 20 meters, in terms of bandwidth of coverage, would be 384 kHz, but as you can see the extreme edges of the waterfall are rather dark where the internal filtering rolls off, and using this setting would have affected the upper and lower edges in terms of sensitivity.
• If this testing goes well, we will be able to use the extra "band" freed up by being able to cover all of 20 meters with just one receiver to add 12 meter coverage to WebSDR #4, and expand the coverage of 17 meters to include the entire band, rather than the current 90-ish percent of it:  We may also be able to improve the performance of the 15 and 10 meter receivers - just in time for the improvement in propagation on these bands!
• Slight modification in WebSDR behavior:
• Although present on WebSDR #3 for quite some time, code was added to WebSDR #4 so that it would automatically default to specific frequencies, modes and zoom levels when one changed bands, or landed on the WebSDR without specifying the frequency and mode in the URL.  This was done to "zoom in" a bit on the (now) rather wide waterfall display, now zoomed in a bit to better show the portion of the band that is of most interest.  This "auto zoom" feature is implemented on 20, 15 and 10 meters - those bands that cover a rather wide frequency range.
  

• 5 October, 2021:  New receiver hardware being tested - the SDRPlay RSP1a.
• Using WebSDR #4 (magenta) as a test bed, we have configured the use of an SDRPlay RSP1a receiver on the 20 meter CW portion ("20CW-E") for evaluation, replacing - at least for the time being, the FiFiSDR that had been used since WebSDR #4 came online.
• Unlike most WebSDRs that use the SDRPlay hardware, we have produced a special driver that allows the full "16 bit" pipeline of signal data to be used, rather than the 8 bit "RTL-SDR" pipeline that is (believed to be) used by all other WebSDRs that use this hardware.  Special care has been taken to minimize latency in the signal path, which is significantly reduced from what is seen using the RTL-SDR driver pipeline.
• This same configuration has been in use for the past 5 months on a "test" WebSDR (available on the Internet, but not listed at "websdr.org") with no issues whatsoever in terms of reliability and stability.  This test platform has allowed has allowed a thorough testing of the new driver's operation and configuration and RF performance.
• We have been comparing the RF performance - in terms of signal handling capability and dynamics - between the usual "sound card" receivers (e.g. "SoftRocks") - which have thusfar been the gold standard, the 8 bit RTL-SDR driver pipeline using both RSP1a hardware and various configurations of RTL-SDR receivers (typically with strong filtering and outboard AGC) and have found the RSP1a on the 16 bit signal path to be very comparable to the SoftRock:  We believe that we that the use of the RSP1a (and similar) receivers can be used to entirely replace the SoftRock hardware when properly configured and implemented.  Such an implementation includes:
• The use of strong, outboard band-pass filtering.  Because the Northern Utah WebSDR is in a location that has both a low background noise and good antennas, any receivers that we implement must be able to handle both extremes - preferably simultaneously.  In accordance with well-established RF design principles, we do this with outboard, band-specific filtering, prior to the RF input of the receiver.  Although the RSP1a does have its own band-pass filtering, it is minimal, allowing broad swaths of spectrum into the receiver hardware.  For example, there are only two RF filters that cover the entire HF spectrum (3-30 MHz) and this is simply not enough to maintain performance in situations where strong shortwave signals may be present - even at frequencies distant from where the receiver might be tuned.
• The implementation of an "external" AGC algorithm.  Although the RSP driver has its own AGC algorithm, testing has shown that it appears to be poorly suited for use as a broadband receiver where signals across a larger chunk of RF spectrum are to be receive simultaneously by multiple users.  The original AGC seems to be too aggressive in many ways, throttling back gain and operating too quickly - something that might be appropriate for the normal, intended use of this hardware (e.g. a single user tuned to a single frequency) but we deemed it inappropriate for use on the WebSDR.  The "new" AGC algorithm being tested operates in the new driver and has a lot more granularity in its configuration.
• Higher rates are being tested at the 16 bit depth:
• Finally, was have been able to operate this same hardware at 256 kHz, 384 kHz and 768 kHz at the full 16 bit depth on the WebSDR.  We are still evaluating these configurations on the test WebSDR and are satisfied that they are working well, but because these are non-standard "sound card" rates we are making sure that the necessary Linux driver modifications are both easy to do and replicable.  Fortunately, the WebSDR server software itself appears to be "happy" at these higher rates out of the box with no modification.
• These "higher" rates will allow consolidation of some of the "bands" (e.g. 80, 40, 20, 15 meters) that presently cannot be covered in their entirety by a single sound card (with 16 bit signal depth).  With the "8 band" limitation of the WebSDR software, this means that a single server can cover more "bands" at this higher bit depth (rather than having to use an 8 bit pipeline) which means that it should be possible to add additional bands to existing WebSDRs that are already "maxed out" with 8 overlapping bands.
• We hope to be able to configure the 20 meter receiver on WebSDR #4 for higher receive bandwidth in the near future for testing with the entirety of this amateur band being contained within just one "band".  If this is successful, we should be able to add 12 meter coverage to WebSDR #4 just in time for the improving conditions on the upper HF bands!
• Additional comment about 15 and 10 meters:
• I didn't notice until the (local) evening of 10/5 that the 15 and 10 meters didn't reinitialize properly - and when I did notice it, I fixed it.

For "less-recent" (earlier) events, go to the "Latest News Archive" page - link.

---

Issues currently being investigated:

• Power Line noise:  There is an intermittent power line related noise that occasionally shows up - and we are working to resolve this issue - but the system's noise blanker seems to be able to remove most of it.  This noise is typically the worst on 80/75 meters, but it seems to disappear at night as the band opens up and the ionospheric noise submerges it.  Several poles have been identified

• Audio/system drop-outs:  There have occasionally been periods where the audio will drop and/or the waterfall will freeze briefly.  While this is most often a result of the user's computer (e.g. your computer!) getting busy, pre-empting the browser's audio processing or congestion on your Internet congestion - particularly if you have Internet via Wireless, Satellite or phone - see "Miscellaneous Quirks", below for some causes and work-arounds.

• A "pop" in the audio and an accompanying change in signal level:  There appears to be an intermittent cross-connection on the antenna between a feed and guy wire that can cause noise in the received signals and levels to fluctuate during very windy periods on site - particularly on the lower (160, 80/75 and the 630M-AM-160M) bands.  A similar-sounding - but unrelated - issue (described below) exists with the AM demodulator.   Occasionally, this seems to be accompanied by an increase in intermodulation distortion from AM broadcast band signals - a problem that can affect the 75 Meter and lower-frequency bands.

• Occasional outages:  We are working to "neaten up" the installation so we occasionally have to take something off line to dress a cable, replace a connector, "permanentize" an installation.  Tasks like this will cause outages of several minutes duration.  Some work is also being done at one or more of the interim sites that provide the Internet connection that occasionally result in outages.

• Low-level switching supply "birdies":  With lots of computers comes the possibility of lots of QRM from them!  Fortunately, there are no "strong" birdies, but there are some that, if they happen to sweep across the frequency to which you are listening, will cause some mild annoyance.

---

Miscellaneous quirks (e.g. "It's supposed to be that way!"):

• If the WebSDR is not on an active window on YOUR computer:  If the WebSDR is not the currently active window on your desktop, the computer will give it lower priority and this will make audio drop-outs/waterfall freezes more common.  The same thing can happen if your computer is "busy" doing something else, such as other programs, updates, incoming emails, etc.  The same is likely true with other platforms (phone, Mac, etc.)  The first thing that you should do if you experience drop-outs is to switch to the window running the WebSDR.  Don't forget that your own Internet connection/ISP can result in drop-out issues as well.  It has been observed that on a typical Windows machine, if the processor utilization is over 65-70%, you may experience occasional drop-outs due to delays in the operating system providing processor time to the code that produces the audio and draws the waterfall.

• Waterfall not updating when you switch to another window:  When the waterfall is not visible (that is, you have switched to a window and moved the one with the WebSDR in the background) it will stop - which makes sense if you can't see it.  What this means is that when you switch back to where the waterfall is again visible there will often be a clear line of demarcation between what the signals were when you switched away and when you switched back.

• Occasional burst of noise across the band correlated with strong signals:  This is sometimes the result of the noise blanker that is active on all bands being triggered by the peaks of the strongest signal(s) on the band.  This effect is most easily spotted on 40 meters during the daytime where there is one signal that is extremely strong - often on the leading edge at the beginning of a transmission - and the band is otherwise quiet.  This effect should not be confused with other things that cause similar-looking artifacts, such as static crashes from distant lighting storms or brief signals from ionospheric and ocean wave profilers.

• When listening to AM, a sudden "pop" in the audio:  It's not actually supposed to do this, but there a "quirk" (bug?) in the AM demodulator that can cause this to happen, occasionally.  It seems to happen mainly when the signal level changes very quickly due to QSB (fading) but is less likely to happen on very steady signals or those with only very slow QSB.  The only "fix" for this - if it becomes annoying - is to listen on USB or LSB and zero-beat the carrier.

• The bands on the "other" server aren't visible to me unless I go to that "other" server:  It is this way because there are several independent WebSDR servers.

---

If you notice some issues that are unrelated to those listed above feel free to use the contact info on the About page to let us know about it.

Additional information:

• For general information about this WebSDR system - including contact info - go to the about page (link).

• For technical information about this WebSDR system, go to the technical info page (link).

• For a list of questions and answers, visit the FAQ page (link).

• For more information about the WebSDR project in general - including information about other WebSDR servers worldwide and additional technical information - go to http://www.websdr.org 

Back to the Northern Utah WebSDR