[hpsdr] frequency-specific frequency domain AGC

[Roger Rehr W3SZ]

Hi Alan,

Thanks for a great note and very helpful set of comments!

I first wrote here that overload occurs in the audio chain before the
VAC; I said this beecause I hear it when listening through my USB
headphones, too, if I turn up the audio gain too much.  As you know, the
sound of a digital audio channel having its upper signal amplitude
exceeded is extremely jarring, and I can say that this is especially if
one is wearing headphones!

But then I realized that my USB headphone drivers are also limited to 16
bits, just as is the input to WSJTX, so perhaps in both cases it is the
16 bit limit in the final stage that is causing the problem.  I DO have
a 24 bit soundcard in the client computer at my remote site, so when I
can eventually get out there after things settle down with my wife's
health I can as a test use that 24 bit soundcard as my final stage and
see how the receive chain without AGC but with 24 bit output does in
terms of handling the higher-amplitude audio signals.

I know that you know this, but I want to mention it here for those who
don't, that the 16 bit limit that you mention is NOT inherent to VAC.
VAC can handle up to 32 bit audio. But the input of WSJTX must have 16
bit audio.  If WSJTX would accept 24 bit audio, then VAC could supply it.

You are doing things the right way there, avoiding the 16 bit problem by
incorporating the decoders into your code.  I am a slow and not
particularly talented programmer, so I chose to stick with using VAC
when I added WSJT capability to my station so that I could use WSJTX
rather than having to write the decoders into my code.  If I ever get
enough time I can always revisit that decision and then do things the
best way, as you have already done, and add the decoders to my software.
 In that case I will still need to address the issue of my 16 bit USB
headphone/driver though. And the WSJTX code has become so user-friendly
with so many bells and whistles that I would miss all of those
incredible features that Joe and Bill and the team have blessed us with.
If my FAGC does as well for me in the long haul as it is doing now, I
can have the best of both worlds: no overload and WSJTX too :)

The devel versions of WSJTX that I have been using do subtract the
strongest signals and then they repeat the decoding process after that
to pull out weaker signals, as you describe.  This two-stage decoding,
as you note, does not help my problem because the overload occurs before
the signal reaches WSJTX.  I want to say parenthetically that the WSJTX
two-stage decoding appears to work quite well with my FAGC in the
receive chain.

Thanks Again Alan for a very interesting and helpful post!  I will let
you know what I find with the 24 bit soundcard when I eventually get
back to my remote station and test it :)

Have a great weekend, Alan, and

Very 73,

Roger W3SZ

On 7/14/2017 5:11 PM, Alan Hopper wrote:
> Hi Roger,
> this is a very interesting idea and has got me thinking.  I think the
> route cause of the problem is using the 16bit vac interface to wsjtx.  I
> believe some of the JT mode decoders play a clever trick of subtracting
> reconstructed strong decoded signals from the original signal to reveal
> weak signals ( mentioned in the latest RadCom )  so the code internally
> copes with high dynamic range but is possibly restricted by the 16 bit
> input.  My own code feeds the wspr and JT decoders directly and avoids
> vac, for wspr this works well as the decoder accepts .c2 files that are
> floating point so clipping is not a problem, the JT65/9 decoder I use
> takes only takes 16 bit samples and I suspect has the issue you
> describe.  I spent some time trying to compare receivers side by side by
> measuring wspr/jt spots on a shared antenna, I found the decoders to be
> a little level sensitive if you want spot counts to be within 1% for
> identical receivers.  I wrote a basic 'after the event' agc that
> equalized the levels at the end of a JT9/65 packet before sending the
> whole recorded 50s block to the decoder, I suspect this is flawed if
> there is impulse noise about and does not solve the problem that you
> have.  It would be very interesting to compare your solution to adding a
> float/double interface to the JT65/9 decoder.
> 
> 73 Alan M0NNB
> 
> On Thu, Jul 13, 2017 at 2:58 PM, Roger Rehr W3SZ <w3sz73 at gmail.com
> <mailto:w3sz73 at gmail.com>> wrote:
>