On 15/10/2018 20:16, IK1HJS Carlo De Mari wrote:
Hi to all, I've just got into the reflector. I understand that In FT8
you usually use pre-compiled messages and , although it's possible,
nobody sends private messeges out of pre-compiled usually.
This means that the purpose of this mode is to make quick qso's in
the shortest time possible.
Now...after the received and sent report the qso can be logged (as far
as I know), so... why sending 73 and waiting for the 73 reply ? That
makes sense in a cw, rtty, ssb where qso is much quicker and
personalized, but I don't unerstand it in a precompiled-message. I
suppose that there was the idea to be polite and follow the normal
standard qso, but how you can be essential if 73 is pre-compiled ? You
are forced to send a personal 73 in a non personal qso and mode.
It seems also that somebody else(a lot of people) thinks the same and
don't send the 73. In this way all recipients are waiting for it and
sending the last report message again to get the 73 to be sent again.
I think that this 73 is cousing more qrm than being a polite way to
say hello while the qso is already finished.
Sorry if there was a previous discussion on this, but I didn't find
it. Somebody could address me so that I can understand a bit more.
Thanks
73 de Carlo IK1HJS
Hi Carlo,
welcome to the list! Please start a new topic for a new subject rather
than replying to an existing thread and changing the subject line,
otherwise your post may be missed by those of us that use threaded email
readers.
The purpose of the modes in WSJT-X is to make QSOs even with the weakest
received signal strengths, this requirement leads to the need for
strictly formatted messages as they can be compressed in a very
efficient way and less data bits means more time and bandwidth can be
used to add FEC and more energy to each symbol. Related to this is that
at the weakest signal levels decodes are not guaranteed, in fact on EME
and MS paths decodes are often only at a low rate with many periods of
no decode. This makes it important that the QSO protocol follows a
strict sequence with each new piece of information being confirmed
before the next is attempted. To that end a 73 message is necessary to
confirm receipt of a final RRR message from the other station. There is
no official requirement to confirm receipt of a 73 message, if there
were then there would need to be another confirmation in return and so
on - QSOs would never end! On HF where signals are often well above the
decoding threshold it is common to send a 73 back after a 73 message is
received and these messages are regularly free text messages with some
casual sign off information, any free text message containing the word
73 will serve as a 73 message. Also on HF where signals are usually
strong and the probability of decoding is very high it is not uncommon
to substitute an RR73 message for the RRR message, this should only be
done if you are very certain that it will be decoded as there is no
obligation to reply to an RR73 message with a 73 message.
Many have concerns about when a WSJT-X QSO can be added to your station
log. The best answer is slightly different for each of the QSO partners.
For the station sending an RRR or RR73 message; they can log the QSO as
soon as they send that message, note that that is not necessarily the
end of the QSO as they may have to repeat that message one or more
times. For the other station; they can log the QSO as soon as they
either decode an RRR or RR73 message. That does leave some ambiguity in
that second station may not log the QSO if they never receive an RRR or
RR73 message but that should be unlikely since they will repeat their
R+SNR message until the first station's RRR or RR73 is decoded. This
last bit can be a problem on MS and EME where decoding may stop due to
lack of propagation, this is normally resolved by confirming that the
QSO is complete by either sending a number of 73 messages in reply to a
73 message (RR73 is unlikely in MS QSOs) or by confirming via a
different communications channel that it is safe to stop as the QSO has
been completed and logged.
Some operators refuse to log QSOs if they don't decode a 73 in reply to
their 73 message, this is unreasonable and unnecessary although it does
absolutely confirm on-air that the QSO is logged by both parties.
Personally I am quite happy to log a QSO that may not get confirmed,
particularly if it is on a very difficult path like random MS, I know
that I have confirmed everything I need to log the QSO but sometimes on
rare occasions the confirmation of confirmation at the other end cannot
be achieved on-air, nevertheless, if they have received my 73 they will
have logged it and we have a valid two-way QSO confirmation.
I suppose the key points to be taken here is that logging a QSO is not
necessarily the end of the QSO and that there is no problem with using a
customized free text message as a 73 message substitute so long as it
contains the word 73, e.g I often use "TU 3W 4EL 73". It is also worth
noting that FT8 was not designed for HF use, it's purpose was to make
QSOs more likely on 6m during multi-hop DX sporadic E openings where
signals are fairly strong but fading is rapid and deep and openings are
short lived, often only a minute or so long between potential QSO
partners. The design goal was to achieve successful QSOs under those
conditions where JT65 or JT9 could not get the job done and was
implemented by trading off sensitivity with the time taken to send a
message and also with signal spectrum density (FT8 is about 1/4 of the
message transmission time but uses more spectrum space than JT65 or
JT9). It is a happy accident that FT8 is so effective on HF, that is
because the timing characteristics are valued by users and the lower
sensitivity is acceptable to almost all users on HF given an overall QSO
rate higher than modes like JT65 or JT9(slow).
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
