<div dir="ltr"><div dir="ltr" style="font-size:12.8px">Hi Roger,<div>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.</div><div><br></div><div>73 Alan M0NNB</div><div><br></div></div></div>