new ADC overflow logic (S-meter "OV" indicator) [added in v1.315, improved in v1.357,358]
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.
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/b4/fbc5fa5a085111dc054154385a9eb6.png
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.
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/b4/fbc5fa5a085111dc054154385a9eb6.png
Comments
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.
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.
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/39/6fbe6aad40d5f4eb4610e904944465.png
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.
Phase noise maybe.
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.
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 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.
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
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.
Regards,
Martin - G8JNJ
In wsprdaemon V2.6a (https://github.com/rrobinett/wsprdaemon.git) 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.
Rob
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.
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.
Regards,
Martin - G8JNJ
>
>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.
Regards,
Martin - G8JNJ
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..
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.
Thanks for adding that, most useful.
Regards,
Martin - G8JNJ
Regards,
Martin - G8JNJ
That forces a "restart required" and saves the change (it seems).
Fudge but allows testing.
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:-)
Regards,
Martin - G8JNJ