A/D Overhead Level


I'm experimenting with different configurations of distribution and filtering on the receivers out the VK5ARG remote site (http://kiwisdr.areg.org.au:8073 and 8074). Right now one of the receivers is just ending up just slightly in the overload region at night-time.

Is there a way to get some idea of the A/D overhead? e.g. the maximum observed A/D reading in the last 1 second (or some other convenient period), in dBFS? This would give me a good indication of how close the receiver is getting to overload and adjust the front-end accordingly (it'd also open the door to implementing a basic external AGC...).

Being able to query it via the /status interface would mean I could plot it over time, see how often I'm getting near (or hitting) overload, and decide on the best course of action to make the station perform the best it can!

I work with direct-sampling HF receivers at my day-job, and the A/D overhead level is one of the key metrics we look at in seeing how a receiver is doing when exposed to the HF large-signal environment. Overload count is the other (which I can probably get if I tie up a channel).

Maybe this exists somewhere already?


Mark VK5QI


  • In wsprdaemon I invoke kiwirecorder with the ‘-OV’ command line flag and redirect stdout to a log file. WD checks that log file every 10 seconds to determine if/how many OVs have been output. From that count WD derives the number of OVs in each 10 minutes. Ugly, but it helps WD users determine if they need more filtering.

  • Yes, overload count is definitely useful - but it ties up a channel which could be used for more useful things.

    An overall A/D peak level (which would necessarily be done much further up the signal processing chain) would provide similar, but much more useful information - it would tell users how close they are getting to overload, not just if they are overloading.

    Being able to grab this data and plot it over time would be extremely valuable in determining how close a station is getting to overload, or even being able to switch in attenuation to stop that from happening.



Sign In or Register to comment.