Re: [wsjt-devel] QRA64 2m transatlantic contact

[Joe T. <jo...@pr...>]

Hi Dani,

Dani EA4GPZ wrote:
> Probably we've all heard about the recent 2m QRA64 transatlantic contact:
>
> http://www.arrl.org/news/transatlantic-contact-completed-on-2-meters
>
> What I find a bit strange is the signal reports of -36dB and -37dB SNR
> that they give. Even though QRA64 is quite good, I would expect that
> it's almost impossible to copy QRA64 signals at -36dB.

Evidently you have not seen the messages I posted yesterday to 
"wsjtgroup".  For completeness they are copied below.

I believe V51PJ and PY1MHZ have been unaware of the way decodes using a 
priori information should be used, and consequently they have been 
fooled by false decodes displayed by whatever unreleased version of 
WSJT-X they were using.

	-- 73, Joe, K1JT


-------- Forwarded Message --------
Subject: Re: [wsjtgroup] thanks to the software team
Date: Wed, 5 Oct 2016 09:57:29 -0400
From: Joe Taylor joe@Princeton.EDU [wsjtgroup] 
<wsj...@ya...>
Reply-To: Joe Taylor <joe@Princeton.EDU>
To: ne...@mt..., WSJT Group <wsj...@ya...>

Dear Pieter V51PJ,

I do not in any way wish to throw cold water on your attempts at 
trans-Atlantic communication on 2 meters, but I would like to be sure 
you understand what has been accomplished.

Evidently you are using an unreleased version of WSJT-X built from the 
development branch of our open source code.  The QRA64 mode there is 
functional but not yet yet fully complete, and some details of its use 
are not yet documented.

Apparently both lines of decoded text shown in the screen shots I've 
seen are flagged with the number "8" at the end of line.  This indicator 
shows how much "a priori" information (if any) has been used as part of 
the decoding procedure.

In case it would be useful, here is some (internal) documentation from 
our source code describing the end-of-line return codes from the QRA64 
decoder:

/*
    Return codes:
      -16    Failed sanity check
       -2    Decoded, but CRC check failed
       -1    No decode
        0    [?    ?    ?] AP0    (decoding with no a-priori information)
        1    [CQ   ?    ?] AP27
        2    [CQ   ?     ] AP42
        3    [CALL ?    ?] AP29
        4    [CALL ?     ] AP44
        5    [CALL CALL ?] AP57
        6    [?    CALL ?] AP29
        7    [?    CALL  ] AP44
        8    [CALL CALL G] AP72
*/

The information here is rather cryptic, intended for our own programming 
use.  But in short, the "8" flag means that the content of your 
transmissions could be determined (and verified with the transmitted 
message's cyclic redundancy check) only because its plausible content -- 
in this case, two callsigns and a grid locator -- were known in advance 
to the receiving software.  (Of course, this known information is always 
available for a scheduled QSO attempt.)

For our weak-signal software development we have been using the 
following somewhat "official" definition of a minimum valid QSO, which 
appears in the IARU Region 1 VHF Managers Handbook:
#########################################################################
7.1 Minimum Requirement for a valid QSO (Vienna 2007)

A definition for a valid QSO on VHF and on higher bands is:

A valid contact is one where both operators during the contact have

(1) mutually identified each other

(2) received a report, and

(3) received a confirmation of the successful identification and the
reception of the report.

It is emphasized that the responsibility always lies with the operator
for the integrity of the contact.
#########################################################################

It seems to me that your exchanges with PY1MHZ may have satisfied item 
#1 in the above list.  Now, you need to persist and exchange some 
previously *unknown* information, such as a signal report, followed by 
an acknowledgment -- and then you will have made a truly record-breaking 
QSO!

In passing, I should also caution you and others not to take the dB 
signal reports produced by our existing code too seriously.  At the low 
end of the S/N range for marginal signals, say below -28 dB for QRA64, 
the uncertainty of S/N estimates gets very large.

	-- 73, Joe, K1JT

-------- Forwarded Message --------
Subject: Re: [wsjtgroup] thanks to the software team
Date: Wed, 5 Oct 2016 10:50:11 -0400
From: Joe Taylor joe@Princeton.EDU [wsjtgroup] 
<wsj...@ya...>
Reply-To: Joe Taylor <joe@Princeton.EDU>
To: WSJT Group <wsj...@ya...>

Hi Andy and all,

G4JNT wrote:
 > I'm puzzled by the quoted -36 and -37dB S/N reports.  These seem way
 > too low even for QRA-64 mode.

Perhaps this is a good time to remind everyone that estimates of 
signal-to-noise ratios for very weak signals *always* have an associated 
(if unexpressed) uncertainty.  When S/N is quoted in dB, this can have 
important consequences.

In a stochastic (noise-like) process, experimentally measured values 
will be scattered around the unknown "true" value; some will be pretty 
accurate, some too high, and some too low.

Suppose a signal's true S/N (in the detection bandwidth) is equal to 
1.0.  In a series of measurements of that signal, some of the estimated 
("measured") values will be close to 1; some will be higher, maybe as 
high as 2 (or even more), and some will be as low as 0 (or even less). 
These are *linear* values of S/N: estimated ratios of signal power to 
noise power.

When the S/N is expressed in dB -- a logarithmic scale -- you quickly 
see the problem.  A perfectly plausible estimated S/N=0.1 means that in 
dB, S/N_dB = -10 dB.  At S/N=0 we get "minus infinity dB".

Some people think it's a big deal when they see a JT65 decode displayed 
with an estimated S/N_dB of, say, "-30 dB".  This is nothing more than a 
statistical fluctuation of noise and an illustration of the nature of 
logarithms.

	-- 73, Joe, K1JT