Hi Igor,
Earlier this month you made suggestions for a possible new protocol for
minimal weak-signal QSOs. I have been away on vacation since that time,
so have not had a chance to respond.
Of course there are many possible ways to make design trade-offs
involving message size, duration of transmissions, sensitivity,
bandwidth, undetected error rate, coding and modulation scheme, and so
on. In the modes implemented in WSJT, WSPR, and WSJT-X we have made
choices that I believe provide close to optimum solutions for a wide
variety of different Amateur Radio activities.
By all means, if you think your ideas have merit you should proceed to
develop a new mode along the lines you outline. But I should point out
that the particular goal your message seems to favor is close to that of
the "WSPR QSO Mode" that I introduced in May, 2008. A brief description
of this mode was published in the proceedings of the 13th International
EME Conference, held in Florence, Italy, later that year. A link to
this article may be found as Reference 11 here:
http://physics.princeton.edu/pulsar/k1jt/refs.html
"WSPR QSO Mode" reached a sensitivity of -29 dB and the required
bandwidth was only 6 Hz, but the mode never became popular. One reason
is surely that the supported message types (in 50-bit packets) were too
restrictive. Another reason is that the 2-minute T/R sequence length is
too long: QSOs were necessarily verrrry sloooooow. Scaling the
transmissions to 15 s sequences would make the bandwidth about 47 Hz and
sensitivity -20 dB. FT8 has about the same bandwidth, better
sensitivity, and a much wider range of supported message content. WSPR
QSO MOde was an interesting idea, but FT8 is far better.
-- 73, Joe, K1JT
On 8/8/2018 2:29 AM, Игорь Ч via wsjt-devel wrote:
Hello Joe and all,
.
We all have been missing JT65 mode sensitivity and proposed WSJT-X 2.0
new FT8 approach with 0.2 dB sensitivity penalty can make things even worse.
.
I would like to ask you to consider a new protocol where callsign hash
would be used instead of the real callsign in all messages but CQ and
incoming call, this way we can get back to -25..26dB SNR sensitivity
although will get more limited with the free message length.
.
CQ message: 28 bit callsign1 + i5bit + 12 bit CRC = 45 bit
incoming call: 10 bit call1 hash + 28 bit callsign2 + i5bit + 12bit CRC
= 55 bit
report message: 10 bit call2 hash + 10 bit call1 hash + i5bit + (10 bit
call3 hash for DXpedition) + 6 bit report + 12 bit CRC = 43(53) bit
roger+report message: 10 bit call1 hash + 10 bit call2 hash + 6 bit
report+ i5bit + 12bit CRC = 43 bit
73 message: 10 bit call2 hash + 10 bit call1 hash + 15 bit GRID + i5bit
+ 12bit CRC = 55 bit
RR73 message: 10 bit call1 hash + 10 bit call2 hash + 15 bit GRID +
i5bit + 12bit CRC= 52 bit
.
Spare bits can be used for nonstandard(special) callsign transmission in
CQ message. call1 hash could be omitted in the incoming call message if
this message is originated by the nonstandard(special) callsign.
.
Probably we can optimize protocol even better while a main idea is to
transmit a full callsign only once per each QSO and to transmit not more
than one full callsign in the message.
.
73 Igor UA3DJY
------------------------------------------------------------------------------
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