Furthermore there is no need to improve a protocol just to cope with energy
limits when a really variable medium, as the ionosphere is in the HFs, is
the limit itself. Of course we could think to a new mode in which a 2-way
QSO between two antipodal points on earth would require 50 mWatts instead
of 100 mWatts at the same information rate. But is there really any old man
out of this world who can't afford a 100 mWatts transmitter? The situation
is much different from the situation EME stations have to cope with, which
is much more demanding and where it would be really nice if we could gain
yet some other dBs. But who is really concerned about power requirements on
HFs? Aren't the current HF modes already fast enough? Would it be really
important if a QSO were carried out in 30 seconds instead of 60? And if it
were, what prevents to do double the transmission rate simply by doubling
the transmitter power?
Nico / IV3NWV
Il Gio 30 Ago 2018, 21:37 Joe Taylor <j...@princeton.edu> ha scritto:
> 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
>
------------------------------------------------------------------------------
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
