new ADC overflow logic (S-meter "OV" indicator) [added in v1.315, improved in v1.357,358]

edited December 2019 in KiwiSDR Discussion
The latest release adds some averaging to the overflow signal provided by the ADC. This means the "OV" indicator on the S-meter should now reflect a more meaningful indication of an ADC overload condition.

Previously whenever even a single ADC sample (at 66 MHz) was asserting the overflow signal a latch was set and OV was displayed until the next S-meter update cleared the latch. This logic was simple to implement but for a real signal environment it represented an overly pessimistic reaction. The random instantaneous peaks of strong signals could be adding at the ADC input to cause a single sample to overflow occasionally even though most of the time the vast majority of input samples were within the dynamic range of the ADC input.

Now in the FPGA logic there are two counters. One that counts a for a fixed number of sequential samples (64k at the moment) and one that counts only when ADC overflow is being asserted for a sample. At the end of the 64k period the second counter is checked to see if it is greater than 16k. If so then the OV indication is set. So if more than 25% of the samples are overflowed during the period then the ADC is assumed to be overloaded. Note that it doesn't have to be 16k sequential overflowed samples. Just 16k somewhere out of the entire 64k period. All these values are easily changed.

I ran some tests using an hp8657 signal generator @ 10 MHz. At -13 dBm (S9+60) the OV indicator is never lit. At -12 dBm, just 1 dB more, OV begins to appear. More interestingly IMD products begin appearing in the waterfall which validates that the ADC is indeed in an overloaded condition. When using the old logic OV appears beginning at -14 dBm when there is no IMD in the waterfall. So this seems to confirm that the averaging is doing a better job at representing the true ADC condition. This of course is a single-tone measurement and not the real world.

Note: in the image below the S-meter says -11 dBm when the generator is at -12 because the S-meter calibration (admin page, config tab) needs to be adjusted by 1 dB for this particular measurement setup.




  • In my case the OV warning doesn't show up, even though the ADC is in overload for tens of seconds.
  • jksjks
    edited August 2019
    What are the peak values of those 4 strong signals? Increase the WF max slider a little until the peaks are in range. Or maybe the top of the image is cropped a little too much?
  • edited August 2019
    Here it is with 10 dB attenuation. I can't say if these are the same frequencies and amplitudes though. They have strong fading, the amplitude does change rapidly in the range of 10-30 dB.
  • jksjks
    edited August 2019
    It's difficult to tell just by looking at that static image, but I think you might have something besides ADC overload going on. It sort of looks like the 4 strong signals are still strong across the largest black band where the IMD disappears. It also seems odd that there are many black bands of very short duration given the waterfall speed. Almost like a loose connection. I wonder if there is an external rectification problem or some other non-linear process.

    One test would be to put a variable attenuator on the input and look for the classic exponential drop in IMD versus linear drop in signal strength as you increase attenuation. If you don't have a fancy attenuator you can even do this with a low value pot across the input. If you see this (exponential IMD drop) then it is almost certain the issue is on the Kiwi side.
  • jksjks
    edited August 2019
    Here's an EU Kiwi I found that seems to support your position. It's clearly fading in and out of IMD. It's running v1.315 and OV flashes briefly during the highest signal levels but not during the entire period of the visible IMD.

    This image even has those short duration dark bands of no IMD (top of waterfall). Maybe that's being cause by momentary phase cancellation of the transmit carriers and the resulting drop in instantaneous signal level to the ADC. That's the only thing I can think of that would account for that.

    Let me see if I can make the averaging factor adjustable from the user interface (including going back to the old scheme) so that perhaps a more optimal scheme can be found.


  • You mean the spikes in the HPF range (<5 MHz)? They only show up in the waterfall, they are not audible.
    The strong signals have also quick QSB (20 dB in 2 seconds is not uncommon) With good propagation conditions it requires 10 dB attenuation in the evening hours to prevent ADC saturation. Today is such a day.
    Because of me you don't have to bother. I don't need the OV indicator.
  • So I just found a bug in the v1.315 averaging logic that might account for the observed behavior. It will be fixed when I add the averaging UI control.
  • Also they disappear, when zooming in.
    Phase noise maybe.
  • jksjks
    edited August 2019
    v1.316 is out which fixes a bug in the ADC averaging. If the ADC was reporting overflow for *all* samples during the averaging period (severe ADC overload) then the OV indicator would not light up.

    You can now set the averaging mask using the development controls extension ("devl" in the extension menu). Set the first field to a hex bit mask as follows: To set OV on every overflow reported by the ADC enter the value 0xffff (a hex number) which represents the old behavior. To set OV if 16 overflows occur out of each 64k samples use 0xfff0. For 256/64k use 0xff00. For 4096/64k use 0xf000 etc. The default is 0xfc00 which is 1k/64k. After some real world testing the default can be adjusted in the next release.
  • Is there a way to determine the results of the new/masked OV determination remotely from
  • I added a "--OV" option to my kiwiclient repo. It just prints a message when OV is occurring.
  • edited September 2019
    On v 1.320 with a pulse modulated 14MHz input at -10 dBm the OV indicator flickers the same whether I enter "0xffff" or "0x0001" in the first field of the devl extension. The flicker on/off ratio is much less than the 50% duty cycle of the pulsed AM. I've tried pulse rates from 100 Hz to 20 kHz with no difference. I must be doing something wrong...
  • 0x0001 is not a valid value. This is a bit mask we're talking about, so all the high bits must be set. The number of low-order zeros determines how many samples out of 64k are required to trigger OV (see comment above for examples).

    The "flicker" behavior in the user interface doesn't mean anything because its timing is determined by factors not related to the hardware. In particular its dwell time depends on how often sound packets are going between the server and browser, not the duty cycle of how often the OV condition is actually occurring.
  • I am now wondering if there is strong-signal IMD introduced by saturation of the small SMD inductors used in the 30 MHz LPF and/or ADC preamp before any ADC overflow starts to take place. So that what you see is a combination of factors instead of a simple explanation.
  • Thanks for the clarification. I'm still having difficulty seeing any effect from changes to the number of 0's. Also what I observe doesn't look to me like inductor saturation. Things are well behaved in the waterfall until the instant of onset - the moment I break about -15 dBm level. When this happens, the OV starts flashing with a relatively low duty cycle, maybe 10%, and without any obvious periodicity. The lack of periodicity makes sense as you describe but with 0 dBm going in, I'd expect that every set of 64K samples to have a lot of hits such that 0xfffe would give a steady indication, one for every sound packet. As I remember, previous code versions could indeed exhibit "steady red". I don't see this happening any longer under any conditions I've yet found.
    I don't need to be restarting the server in between setting changes do I?

    If you can think of a test for me to perform, I'm glad to try.
  • jksjks
    edited September 2019
    I've been meaning to look at the overflow signal coming out of the ADC directly with my scope to see how it behaves with an increasing signal level from the sig gen.

    Unfortunately, just like my spectrum analyzer, some caps in the sig gen went "bang" recently after running for a time on 240V here in NZ (after running for years on 120V in the US). I fully expect to find this problem once I have the time to dig into it: RIFA-madness
  • Pin 28 of the LTC2248 is behaving just as I'd expect. At -15 dBm it is low while at -14.9 dBm there are infrequent 15 ns wide pulses. By -13 dBm or higher power they are very common. I can believe that integrated they follow the percentage of the time that the ADC is hitting OV.
  • Hi John,

    I'm having problems trying to track down some occasional IMD on one of my KiWi's.

    I think it's ADC overload but with the averaged OV indication it's very difficult to tell.

    At one time you could set the averaging mask using the development controls extension, but this option now seems to be missing.

    The averaged OV indicator may be OK for general guidance purposes, but is there any way I can revert back to the original indicator, as I found it to be much more useful when trying to troubleshoot issues.


    Martin - G8JNJ
  • Hi Martin,
    In wsprdaemon V2.6a ( I have added OV logging. When running it at debug level 1 or above (-v or -vv ...), the number of OV events are logged every 10 minutes to the watchdog.log file. You may find those report lines useful.
  • @Martin What do you mean "option now seems to be missing" ? You should be able to open the "devl" extension and change the first field from "1" to "0xffff" (that first char is a zero) to remove the averaging.

    It's on my list to add an S-meter OV averaging field to the admin config tab. That and the AGC change we previously discussed are on the "sooner rather than later" TODO list.
  • Hi John,

    My fault, I expected the dev parameters to only be available via the extension admin page (where it is not visible) and not from the GUI extension dropdown list, where users can fiddle with it.

    Is there any way I can remove the dev extension from the extension list like the others (apart from the antenna switch) ?

    Another thought is to maybe make the OV indicator flash orange on occasional overloads and red on long term instances, a bit like a 'traffic light' warning system.


    Martin - G8JNJ
  • Wasn't extension locking added recently
  • Hi Jim,

    >Wasn't extension locking added recently

    Yes it was, but the dev extension is not listed among the rest on the extension admin page, so you can't lock it out from general users.


    Martin - G8JNJ
  • "development" controls like that accessible from a user connection isn't really intended for anyone but me (facilitates rapid experimentation without having to reload the page e.g. by changing a URL parameter). If anything experimental parameters like that for you belong on the admin page someplace.

    That said, the S-meter averaging value needs to be an official setting on the admin config tab. I probably could have added it in the time it took me to read these posts..
  • Alright, v1.357 is out with an S-meter OV averaging adjustment slider on the admin config tab.

    Remember that the averaging is defined as as threshold count of per-sample ADC overflow events for every 64k ADC samples. So when the slider is set to 1k (the default) it means that the OV indicator will only light if there have been >= 1k ADV OVs during the 64k period. Note that the 1k OV events don't have to be consecutive. It's a threshold over a fixed interval.
  • Hi John,

    Thanks for adding that, most useful.


    Martin - G8JNJ
  • Am I using v1.357 wrongly? I can set the value from the admin config tab but it doesn't seem to stick even after restarting the server. For most of what I do I like to have pretty sensitive OV indication and want to turn the default restart condition down nearer 1. I can't seem to make it stay put.
  • Same for me, if I refresh the admin page it's back to the original default value :-(


    Martin - G8JNJ
  • Change something else like Initial Mode (just call up the drop down menu and back to the exisiting value).
    That forces a "restart required" and saves the change (it seems).

    Fudge but allows testing.
  • Hi Stu,

    Yes that worked for me.

    Good as a workaround but not so good for quick comparisons.

    However I can now see the OV indicator flashing again, which is what I suspected was happening, so it's not antenna generated IMD after all:-)


    Martin - G8JNJ
Sign In or Register to comment.