Steve,
Thank you for your comments.
Ok, I understand what is the disagreement between us.
First, I do not fully understand the point why you object my +4dB gain but I
need to find modulation theory book in my book sheves (never opened for more
than 20 years) and check about “ *bit* SNR, Eb/N0” related area before my final
response. If I can not solve for myself, I can call my local experts without
bothering you anymore. But, I am thinking the longer symbol proposal does not
heart any RF performance including the delay spread, fading performance,
interference performance and a fraction of a dB gain with non-coherent
detection given from you is another goody.
Concerning the “second +4dB term”, I remember Bill’s suggestion included
hashing of callsign (I used the number of (28-15) x 5 = 65 bit reduction). I
also reduced five 7x7 synch to one 7x7 synch, which I am not sure whether Bill
included. I will not further describe the details to defend my ballpark number
but I can say I disagree with your 0.6dB gain calculation, here.
Thank you very much spending your precious time to comment on my +8dB challenge.
Joe,
As I write to Steve, I do not have any intention to sell or stick to my +8dB
number. If you feel uncomfortable, please deal it to + (1~8)dB additional gain
proposal .
take
de JA5AEA
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Steven Franke via wsjt-devel <wsjt-devel@lists.sourceforge.net>
Sent: Wednesday, July 4, 2018 6:32:00 PM
To: WSJT software development
Cc: Steven Franke
Subject: Re: [wsjt-devel] Observation on Expedition Mode
Hi Take-san,
I meant QRAXX as “Q-ary Repeat-Accumulate Codes for Weak Signal Communications”
in Nico’s literature but I do not have any intent to modify wsjt-X “QRA64”
mode to this discussion.
Understood. But why not scale the well-known results from Nico’s excellent
QRA64 mode to see what should be possible?
By the increase of symbol length to 64mS (FT64) and 74.7mS (FT128) from 32mS
(from 160mS FT8 symbol length speed up by factor 5), the gain is 10LOG(64/32) =
+3dB and 10LOG(74.7/32) = +4dB.
You have shown that the *symbol* SNR (Es/N0) will be doubled if we use 64FSK
instead of 8FSK, but what matters is the *bit* SNR, Eb/N0.
A single 64FSK symbol conveys 6 bits of information, whereas the 8FSK symbol
conveys only 3 bits. You neglected to factor this into your calculations. While
the 64ms 64FSK symbol contains twice the energy of the 32ms 8FSK symbol, the
energy-per-bit is the same, either way.
There *is* a slight modulation-detection-efficiency advantage to using 64FSK
instead of 8FSK if the symbol detection is done noncoherently on a
symbol-by-symbol basis, but the gain is fraction of a dB. Furthermore, any
such advantage vanishes if the 8FSK demodulator is configured to detect
sequences of, say, 2 or 3 symbols rather than individual symbols.
In any case, the 64FSK vs 8FSK advantage was already included in the scaled
QRA64 example that I described earlier. I stand by my conclusions.
I also fully agree with Joe’s objection to your "second" +4dB term. Each FT8
message conveys 75 bits. If we send five of them serially, then we are sending
375 bits. If we were to combine the essential information into a single
packet, it would need to convey a total of 11 callsigns (the Fox call, 5 calls
to be printed with RR73, and 5 calls to be printed with signal reports_ plus 5
signal reports. This is a total of 11*28 + 5*3 where I have conservatively used
only 3 bits for each signal report. Thus, the available savings is
10*log10(375/323) = 0.6 dB.
73, Steve k9an
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
