On 11/11/2015 22:43, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> I was about to reply, but I see that you have now found the discrepancy
> between User Guide and program action.
>
>>> What is not working?
>> Ah OK, I see the discrepancy against the User Guide where the generated
>> reply to a CQ call is not a type 1 compound call message. IIRC this was
>> done because a change was made such that a type 1 compound call user
>> would have a standard message with their base call sign flagged as for
>> them i.e. red background to the decode. Therefore the grid need not be
>> dropped since a standard message suffices. The final 73 from the
>> replying station uses the full compound call sign to indicate that the
>> correct call is being logged. Another change at the same time ensured
>> that the correct call is logged by the replying station.
> Probably I should have caught this before, but was not paying close
> enough attention.
There was a lengthy discussion that was mostly related to type 2 
compound call signs. It was HF focused because at the time WSJT-X only 
supported that.
>
> I think it's important for the program to generate messages as the User
> Guide describes for Type 1 compound callsigns.  Especially important for
> VHF and up, for historical reasons.  Conventions there for what makes a
> valid QSO are rather more stringent than those in use at HF, and a few
> in the anti-digital, CW-at-any-cost fringe fuss endlessly about it.
> These guys certainly don't consider the following to be a valid QSO,
> although it's considered perfectly OK at HF:
>
> CQ HC8N
>            K1ABC
> K1JT 599
>            599 TU
> 73 HC8N
>
> They're likely also to be unhappy with the following sequence:
>
> CQ K1ABC/VE1 FN75
>                       K1ABC G0XYZ IO91
> G0XYZ K1ABC –19
>                       K1ABC G0XYZ R–22
> G0XYZ K1ABC RRR
>                       K1ABC/VE1 73
>
> because final Rogers were sent before both full callsigns have been
> copied by both operators.  K1ABC confirmed a valis QSO without having
> copied his own full callsign.
That is debatable as it is up to the receiving station to decide if they 
have copied the correct c/s. This same debate happens in contests where 
those aiming to maximize their QSO rate get annoyed when stns replying 
to a CQ send the CQ caller's c/s. The station calling CQ knows their own 
callsign and if the caller hears it wrong then that is their problem. 
Agreed that the stn running the frequency may lose points if logs are 
cross checked but I don't think that actually happens. For example here 
is a quote from a submission report for CQ WW FONE 2013:

"Stations Copying Call Incorrectly - This is a list of all contacts we 
could identify where the station you worked copied your call 
incorrectly. You do not lose credit for these contacts. They are 
provided for your information. If you have many similar errors, you 
should concentrate on ways to send your call differently that may be 
easier for others to correctly copy."

Agreed the above is an HF World view but nothing in my license 
conditions says that I have to log my QSO partners call correctly.
>
> By HF standards this is a complete non-issue.  Moreover, it may be the
> best we can do for Type 2 compound callsigns.  But for peace of mind I
> think we should advocate using it only when necessary.
It is no problem to change especially as it has not been released in a 
version that includes non-HF modes. I suppose the real problem is that 
when tail-ending it is easy to not realize the full compound c/s of a 
stn running a frequency, especially if the stns worked cannot be 
decoded, although there should always be a period when "QRZ HK0/G4WJS" 
should be sent but I suppose that could be not decoded at the 
tail-ender's stn. Should the 73 message be a standard one with base call 
signs or is the shortened free text version with the QSO partner's 
compound c/s we currently generate the best option?

There is a further complication that occurs if both call signs are 
compound ones, I believe the present implementation deals with that OK 
but I'm not so sure using messages along the lines suggested in the User 
Guide will work out as well without further work..
>
>       -- Joe, K1JT
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

Reply via email to