Hi Nico,
Thank you for your quick response from the opposite side of the earth (not
exactly antipodal point but far from us).
In fact, after reading the following sentence in “QRA64” article in
https://wiki.oevsv.at/index.php?title=QRA64, I thought QRA64 preamble
inherently has more than 7bits distinguishable information without independent
information flag located after preamble, which we normally do and we can do if
it is required.
“The signal consists of 64 tones. QRA64 uses a new synchronization method based
on a 7x7 Costas array<https://en.wikipedia.org/wiki/Costas_array> . There are
200 different Costas arrays of order 7. The Costas array used for FT8 is the
permutation (2,5,6,0,4,1,3).”
Unfortunately, I do not follow your (complicated structured English) words
“besides the usually unknown time delay between the transmitter and receiver
clocks, besides the unknown frequency offset and drift”. Perhaps, I guess you
are describing the nature of ionosphere propagation in HF but my understanding
is that It would not be a problem for FT8 structure by its sufficient symbol
length and wide frequency deviation. Anyway, I am still in undecodable
situation. I hope you are kind enough to spend your precious time for my
education.
See you soon.
Regards,
take
de JA5AEA
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Nico Palermo <nico...@microtelecom.it>
Sent: Saturday, September 1, 2018 8:55:03 AM
To: WSJT software development
Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
Hi, Take. Greetings from Italy :-)
A variable transmission rate would be appreciable indeed but we often forget
that the main purpose of the WSJT-X modes was that of allowing some reliable
amateur communication in the "energy limited" part of the channel
capacity/energy per bit plane given some real channel model.
This is what I understood from Joe's work at least.
Flexibility comes always at the expense of something else: a more flexible
system would not be as optimal, as i.e.FT-8 is, from the energy point of view
as you would need to transmit some more information to instruct the receiver at
what rate the transmitter is using and this takes more energy than that a fixed
rate system requires.
The larger the number of the possibilities a receiver has to understand and
cope with, the least the signal to noise margin is.
If you are not so sure about this fact try to decode a signal in which, besides
the usually unknown time delay between the transmitter and receiver clocks,
besides the unknown frequency offset and drift, you add some other parameter,
unknown to the receiver, which a receiver must necessarily estimate in order to
decode with some success what has been transmitted.
But ok, history doesn't stop in 2018 and I'm not so pessimistic. I think that
we will continue to see something new and possibly even more amazing :-)
73
Nico / IV3NWV
2018-08-31 14:04 GMT+02:00 Tsutsumi Takehiko
<ja5...@outlook.com<mailto:ja5...@outlook.com>>:
Hi Nico Greeting from JA,
And, here is another noise from floor expecting your comments.
To mitigate the dilemma of message size and required power you and Joe
described, It is a common practice to provide the variable code rate feature
(from current FT8 fixed r=0.5). The benefit of this feature is able to avoid
system incompatibity from the information length difference (among FT8, FT8+,
WSPR…) if the system provides the identification flag.
Does FT8+ have already considered this?
Regards,
take
de JA5AEA
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Nico Palermo <nico...@microtelecom.it<mailto:nico...@microtelecom.it>>
Sent: Friday, August 31, 2018 7:04:31 AM
To: WSJT software development
Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
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<mailto: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<mailto: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<mailto: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
