I don't need to see rr73 or 73. I prefer making contacts instead of
finding reasons not to have contacts. On CW or SSB working rare dx you
never get a 73 so why do you need it here? You don't! Have fun and log it.
W0MU
On 10/15/2018 2:11 PM, Bill Somerville wrote:
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
