[Moon-net] QSO or not?

[Stewart Nelson]

Hi Jimmy and all,

> Could you please explain to me how is possible to have a QSO as complete in the
> log of an expedition, when the station calling them says it is not complete?
> However, expedition says it has data files for all QSOs. So does the station
> trying to work them. So where is the error?
 
It's not necessarily an error.

With any unreliable communication medium, even if the system never
delivers an incorrect or false message, there is a significant chance
that the parties will disagree as to whether a QSO is complete.  It is
impossible to design a protocol to avoid this.  It doesn't matter if you
are using CW, WSJT, or smoke signals.  It's just common sense:

At the start of the QSO, both A and B know it is incomplete.  Each station
determines that his QSO is complete, when he *receives* the last of whatever
acknowledgements are required.  It is obvious that one station will reach
this decision before the other.  Let's say it's station A.  At this point,
if conditions change such that B never receives another valid message, then
B must assume that the QSO is incomplete.

For example, in a classic EME QSO, station A might record a complete QSO
when he receives RO and sends RRR; station B when he receives RRR and sends
73.  In this case, if RRR is never received, A shows complete; B incomplete.
It does not help to make the requirements more stringent or the protocol
more complicated.  For example, if station A decides to consider the QSO
complete only if he receives 73, then if RRR is received but 73 is not,
A shows incomplete; B complete.

If desired, you can communicate out-of-band to resolve any ambiguity.  This
is what happens in contests when logs are compared.  A mismatch does not
necessarily indicate any operator dishonesty or negligence; it's just the
way the laws of nature work.

If you could solve this problem, you would be a very rich man, because there
are many real world applications where it is important.  For example, when
you withdraw cash from an ATM, many things can (and do) go wrong with the
machine or the network.  The bank wants to be certain that they don't debit
your account, unless you have actually received the cash.  But they also want
to be certain that if you did receive the cash they do debit your account.
Unfortunately, there is no protocol that can do the job.  If, just after the
server commands the ATM to release the money, the line goes dead, there is
no way to be sure whether you got the cash or not.  How are these ambiguous
cases resolved?  By out-of-band communication.  The ATM prints a record of
its activities on a local tape.  When the technician comes to refill the
machine, the tape is removed, physically transported to the bank, and
reviewed to resolve any discrepancies.  Gee, isn't this just like using
the Internet or a QSL card to know if the other party had a complete QSO?
Don't you think that if there were an in-band solution that the pros would
have adopted it?  An alternate communication channel is sometimes a necessity.

Of course, matters get much worse when you have a system that delivers a false
or incorrect message.  Unfortunately, any system practical for EME (adequate
sensitivity and speed) may occasionally provide an invalid message.  It's up
to the operator to use any available metadata (e.g. "?" flags, signal level,
frequency change) to minimize the probability of misinterpreting a message.

--Stewart KK7KA