Could /status page display the Admin->Config->S-meter OV setting? [/adc added in v1.594]

Comments

• jks

  April 2023

  The adc_ov= entry from a /status query is really only meant to drive the "OV" indicator on the S-meter. The averaging logic in the FPGA and low-overhead way in which the result is transmitted to the Beagle doesn't have any sort of resolution and is quantized rather badly. Lowering the averaging value to one isn't going to do what you want.

  Instead, I did something else in v1.598. I just got done adding the /adc interface which does have full resolution (each ADC clock cycle). So now it has a mode that will count ADC overflow events in addition to the current mode (which counts the number of times the ADC value exceeds a threshold). This way you can see all ADC overflow events with no averaging and then interpret the result however you like.

  Just use zero as the level value, e.g. my_kiwi:8073/adc?level=0 Remember that the very first time you do this, and also the first time after level has been non-zero, you have to ignore the first result returned. Starting with v1.598 the server version number is returned in the query. This is a way of detecting that the level=0 mode is supported by a particular Kiwi:

  # curl -s my_kiwi:8073/adc?level=0

  { "adc_level_dec":0, "adc_level_hex":"0x0", "adc_count":1234, "ver_maj":1, "ver_min":598 }

  So if you were to poll every half second, and the ADC were overflowing on every single sample, then adc_count would be roughly 33M (i.e. 66 MHz / 2). Remember that the counter is 32-bit. So if it is counting for every single ADC clock cycle (unlikely in most cases) it won't overflow for about 64 seconds.
• rrobinet

  April 2023

  Thanks you. I will work with it in the morning.
• ka7oei

  April 2023

  I take it that the architecture of the FPGA precludes the (easy) recording/displaying of the ADC "High Water Mark" since it was last read/reset - or is this in some way possible?

  * * *

  Here's an explanation of the issue for the readers who wonder what the fuss is about:

  Managing a number of (PA3FWM) WebSDRs, I find that facility of knowing information about the ADC high water mark to be the most useful of all in properly setting up the signal path.

  When I wrote the A/D acquisition code for M0NKA's mcHF transceiver I added two layers of AGC it was absolutely necessary to maintain optimal gain for the said signal path. (I say "two layers" as the "outer" AGC operates on the signal path into the ADC and the "inner" AGC operates at the user bandwidth (SSB, CW, AM) - and adjustments by the "outer" AGC are used to correct the S-meter, prevent jumps in audio level, etc.)

  For example, with the "outer" AGC:

  • If the ADC peak in the last second or so exceeds 1/4 full scale ADC, reduce gain a bit as noise bursts/QSB of multiple signals with the acquisition passband have high statistical likelihood of causing ADC clipping and can provide some margin for unpredictable clipping. Such changes should be slow to prevent wild gain changes in response to single-pulse events as a small percentage of ADC clips are inevitable and are likely to have minimal impact on the quality of received signals. (The "acceptable" number of ADC clips depends both on how much degradation the user is willing to accept and the ratio between the sample rate bandwidth and the user's operational bandwidth and is quite subjective.)
  • If the ADC peak in the last second or so never exceeds 1/16th full scale ADC, you are probably safe to increase the gain a bit.

  * * *

  Among the issues faced by users of KiwiSDRs - or any full-bandwidth HF receiver (RX-888, Red Pitaya) are as follows:

  • HF noise/signals are typically 10-20 dB stronger on lower (160-40) than higher bands (15-10).
  • If you have "only" 14-16 bits of ADC and are fortunate to have a "very" quiet site, in order to have enough signal path gain on the highest bands (10 meters) to see the noise floor, you'll probably have excess gain on the lower bands.
  • Some omni HF antennas- particularly active whips- have lower gain on the higher end of their coverage, exacerbating the issue of the first point.

  Prior to the recent re-emergence of solar activity, many KiwiSDR operators found that their receivers were deaf on the higher bands - but upon adding the (approximate) 10 dB of gain to "see" the noise floor on the higher bands, suffered severe overload at the lower frequencies.

  Many users of KiwiSDRs and similar hardware have mitigated this with the addition of a "pre-emphasis" filter (see this page: http://ka7oei.blogspot.com/2020/08/revisiting-limited-attenuation-high.html ) which "tilts" the response - attenuating the low bands by 10-15 dB while minimally affecting upper band: The nature of the low bands means that this attenuation doesn't cause loss of apparent sensitivity of lower frequencies withmore evenly distributed RF energy across the spectrum, reducing the total input power present at the input of the ADC.

  * * *

  As noted in that article, I predicted that this strategy - by itself - would eventually fail to be sufficient when conditions on the upper bands improve - and this has proven to be the case.

  The usual ways by which direct-sampling receivers deal with such situations is by the inclusion of adjustable attenuation/gain prior to the ADC and band-pass filtering. For receivers that need not inhale the HF entire spectrum at once (e.g. HF rigs - like the IC-7300, IC-7610, etc.) both are employed - but in the case where it is desirable that the acquisition path be frequency-agnostic (that is, able to tune anywhere) our first line of defense would be to maintain the input signal path gain to a level "just below" significant clipping: Provided that signal path noise (ADC, RMDR, NPR) is not excessive, this can often be done without excessive degradation of signals that may otherwise be near the noise floor: Under-driving an ADC is likely to be less harmful in terms of signal degradation than severe clipping - and this is particularly true on HF when the total power of the composite signals ebbs and flows with propagation.

  The only other options for such a receive system would be to have a multi-band "window" filter that is designed to pass only portions of spectrum near frequencies - with gain/attenuation set on a per "band" basis as appropriate - or to have multiple receivers - each with their own AGC/filtering - strategically spread across the HF spectrum.

  * * *

  While challenging (or in my opinion, fun problems to deal with) these are certainly surmountable - given the proper tools to analyze and manage what is going on.

  Finally - as an experiment - I decided, as a challenge, to see what I could get the 8 bits of the lowly RTL-SDR to do on some amateur bands. These receivers are available for anyone to see on the Northern Utah WebSDR: The 60 meter band on WebSDR #1 and the 80, 40 and 30 meter bands on WebSDR #3 are such receivers.

  Considering the rather limited dynamic range of an 8 bit signal path in an SSB bandwidth (which - in the absence of other signals - is typically around 75 dB owing to effective oversampling between clipping and an SNR of 3dB in a 500 Hz bandwidth - see http://ka7oei.blogspot.com/2021/05/characterizing-rtl-sdr-block-version-3.html ) these receivers work surprisingly well - but the main reason for this is the fact that they are preceded both by band-pass filtering and AGC to keep the total signal power within the useful range as described on this page: http://www.sdrutah.org/info/rtl_sdr_agc.html A caveat: If you decide to build such a thing to precede your KiwiSDR - with or without filtering - be sure to use only the PIN diode attenuators such as those mentioned rather than doubly-balanced mixers to avoid generating IMD products!

  73,

  Clint, KA7OEI
• jks

  April 2023

  I take it that the architecture of the FPGA precludes the (easy) recording/displaying of the ADC "High Water Mark" since it was last read/reset - or is this in some way possible?

  This is what the new /adc interface does.