WSJTX, Q65, SNR and DSP (noise reduction, noise blanker etc.)

DSP (Digital Signal Processing) is a common feature on most transcievers these days. It's used for things like notch filters, noise blanking and something often called "digital noise reduction" (DNR) or something similar (such as noise reduction or NR). What DNR is designed for is to increase the intelligibility of signals (SSB, CW) by modifying the audio characteristics of the radio. The audio may be filters at some frequencies and enhanced at others. DNR will try to adapt to changes in the signal. It can "clean up" SSB, making it more intelligible by removing noise outside the digital bandwidth, enhancing voice frequencies, possible using some form of AGC and maybe even removing the effects of spurious signals in the audio passband. Similarly on CW it can enhance the CW frequency signal by reducing noise around it.

But what about digital modes like JT65 and Q65. Does it help? The short answer is NO, it doesn't. Here's why. What you hear as a digital signal is not what the digital decoder in the program hears. You hear the whole 2.5KHz audio passband (or as much as 5kHz of audio passband in some cases). The digital decoder doesn't. The software does an FFT of the audio signal, breaking it up into multiple "bins", each of which may be from a fraction of 1Hz wide to a few 10's of Hz wide. In Q65-60C, the bins are 6.6Hz wide. This is it's own "DSP", specifically designed for the characteristics of the Q65 signal. When the program is in the decoding phase, it's looking at these narrow "bins". It's not looking outside them. It may be just looking at 1500 to 1506.6 Hz. What's happening at other frequencies has no effect on what it's seeing from 1500 to 1506.6 Hz. When it comes to decoding, what the decoder really likes is a flat, uniform, noise background with the signal on top of it. It doesn't really like sloping noise backgrounds or lumpy noise backgrounds or any form of non-uniform audio passband. It can usually deal with them when it comes to decoding though.

The SNR is calculated by looking at the integrated power of the signal and comparing it to the noise outside the signal bandwidth. So if the signal extends from 1000Hz to 1432Hz (Q65-60C without spreading) it looks at some range of frequencies below 1000Hz and above 1432Hz to determine the noise level. If you have DSP running it may well "lower the noise" outside the signal. However it can't lower the noise within the signal bandwidth. You can't magically make noise under a signal go away by digital (or other) means. So it will probably report a better SNR with DSP operating then without it. However, the decoder is still looking at the same 1000-1432 range (split up into 65 small frequency bands). It won't decode that signal any better. In fact if DSP has messed with the audio passband that contains the signal, it could make the decoder's job more difficult under some circumstances.

But I get a better decode SNR with DNR on

The way to tell what the effect on the DNR (or any other DSP function) is on decode sensitivity is to make an audio recording of the Q65 signal with DNR on and DNR off. They may well give different decode SNR numbers, but those numbers don't mean much. One you have the two recordings you can degrade both of them equally by deliberately adding noise at various levels until you start to get decode failures. This is actually part of WSJTX (see File -> Settings -> Advanced). For example, if you can add 10dB of noise before decoding fails, the signal was 10dB above the decode threshold. Whatever the reported decode SNR, the signal with the larger decode threshold was obtained with the more sensitive condition. If without DNR you see a -12dB decode and that signal has a 10dB added noise decode threshold, and with DNR enables you see a -8dB SNR and a 10dB added noise decode threshold, there is no change in decoding sensitivity. Both cases will decode equally weak signals. When I've tested this on decoding of the 10Ghz DL0SHF beacon, I've found it to be the case. Though indicated SNR appears to improve with DNR enables, there is no gain in decode sensitivity. Both with and without DNR, decoded failed with added noise at the same point in both cases.

You can also change the decode SNR by other means. If you put the sync tone very low (e.g. 400Hz) you may bee the decode SNR number increase. If you narrow the audio bandwidth so that the signal just fits inside it, you may be the displayed SNR increase. In neither case does the actual decode sensitivity improve. It's just that the WSJTX Q65 decoder expects (and assumes) certain things are true, like a uniform noise floor, a sync tone well above the audio cutoff frequency and a bandwidth larger than the signal width. It doesn't expect audio modified by DSP.

So how do you get the most accurate and consistent SNR and the best chance of a decode? Well, for one thing you don't turn on DNR. Turning AGC off never hurts, though for the purposes of decode sensitivity it doesn't really matter if you have a radio where AGC can't be turned off. AGC must be turned off for accurate noise measurement tests like measuring sun noise. It's fine to use a Noise Blanker. Noise blankers only cut out very sharp impulse noise, they don't affect the shape of the audio response curve. You don't need to minimize audio bandwidth, as you often do when copying CW. WSJTX uses its own internal narrow band filters when they are needed. It does held slightly to use a reference audio spectrum to flatten the audio response curve. This is covered in WSJTX Wide Graph Settings.

A word about decode SNR numbers

It's my understanding that the SNR decode numbers (even when obtained using optimum WSJTX settings) are not, and were never intended to be, a high accurate, precision tool for measuring signal SNR. Different versions of WSJT(X) and MAP65 can give different numbers on the same decode. At low signal levels, decode SNR numbers have a higher uncertainty than at higher levels, because it gets ever more difficult to get a good estimate of the difference between the signal level and the noise level. Remember at an SNR of -30dB, the noise is 1000x stronger then the signal. And the accuracy of both measurements depend on the integration time. If you see a Q65-30B decode at -31dB, it doesn't mean Q65-30B has been decoded at an SNR of -31dB. It means that there has been a decode and the best estimate of the SNR is near-31dB. I assume any decode will have an associated SNR in order to preserve the Q65 message format. A very low number may perhaps be best interpreted as simply be the equivalent of an "O" report (i.e. the signal has been copied).

The above image shows the decode strength of 25 Q65-60C simulations, one at -27dB SNR, one at -5dB SNR. These simulations were created using Q65sin, which is part of the WSJTX package. The upper plot shows all 25 sample decodes of the -5dB set, with very little change in the decode strength (measured with a 0.1dB resolution). The variation between decodes is less than 0.5dB, and the normal decode SNR display (to the nearest dB was -6dB every time.

The lower plot (in red) shows the decodes of signals synthesized at -27dB. You can see not all the files decodes in a single decode. The range of SNR values is much larger, with a variation of almost 6dB between extreme readings. All the readings should have been the same, but statistical variations in noise cause the wide spread at low SNRs. Integrating over a longer time period than is used for the Q65-60 mode should result in less variation in SNR as statistical noise variations are better averaged out.

The best way to estimate the strength of a very weak signal would be to measure a long carrier transmission, the longer the better (e.g. 300s). This can be done best by custom software written for the purpose of this analysis, but you can also do this (though not as efficiently) by using the Echo mode of WSJTX. Details of how to do this can be found in the "Measuring SNR of Another Station’s Signal" section of Echo Mode in WSJT-X 2.6.0, Bob Atkins, KA1GT, Charlie Suckling, DL3WDG, and Joe Taylor, K1JT (Published in Dupus magazine).

The bottom line here is not to read things into the decode SNR numbers that are not really there. They are a reasonable estimate of what the SNR of a single decoded signal was but are not meant to be a precise measurements of signal SNR, especially at low signal strength. The numbers are useful (especially for QSO signal report exchanges) and provide a useful indicator of relative general signal strength.

More readings

See also DL0SHF decoding for comments on the effect of sync tone frequency on SNR.

Some further information, courtesy of Charlie, DL3WDG, who has also looked at these effects and wrote this note for the 432 and up EME newsletter:

"DIGI NOTEs BY DL3WDG: 1) Noise reduction and optimistic signal reports from WSJT-X: Some stations have been experimenting with so-called "noise reduction" (NR) techniques, in the hope that they could improve receive sensitivity for digital modes. Several modern radios have this feature, and also SDRConsole (the "NR1" button). I have looked at wave files recorded with and without NR using WSJT-X's degradation function (Settings->Advanced) (TNX to CT2GUR, KA1GT and G0OLX who provided the wave files), there seems to be no discernible difference in decode threshold when using NR. Using these techniques does not make any improvement in the ability to decode weak signals.

However, there is an effect in using NR. The signal reports are wrong, and in all cases are optimistic, sometimes by many dB! Its worth noting that other receiver characteristics can also lead to significant errors in signal reports, such as a non-flat receiver passband. For example, using a narrow IF filter which rolls of the passband on either side of where the signal appears is also known to lead to optimistic reports. If the receiver passband is not flat, this can usually be corrected using the 'reference spectrum' facility in WSJT-X. https://drive.google.com/file/d/1hGXCZk0TqwhtO-wojgkwCBlqM_gCgP51/view?usp=sharing. Results of some careful tests by KA1GT and CT2GUR, including example wave files that can be played back on WSJT-X are at: https://drive.google.com/drive/folders/1MvVyxPXfKMkHwCeck6r78k0hm-f3TN8C?usp=sharing