Hi Saku Some comments in-line. A bit long email, sri. It's time for the new candidate release discussion.
73, Reino OH3mA > From: Saku via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] > Sent: perjantai 12. toukokuuta 2023 21.22 > if you calling CQ (TX1) and someone(s) answer to it qso starts from point you > start first TX2 transmission (to any of answering stations). >It is very clear. There is no exchange happened yet, and your TX2 will start >the exchange chain (= qso). > Same if you try to answer someones CQ. Once he sends first TX2 qso begins. Reino: LoTW states that "both QSO descriptions specify start times within 30 minutes of each other". So in that sense start time gets one plus point. > In case of missed TX2 receive you will get different start time than the > opponent, that is true. However the base of qso starting definition is clear. Reino: That issue is a real challenge especially on pile-up situations. You may need to send your Tx2 even hours e.g. as a Hound, before the Fox picks your call into the QSO list (= potential earliest start time on the Fox point of view). Even the so started QSO may fail and Fox never sends RR73 to you. Now would it be a new QSO start, if you send even once again Tx2? > End time of qso is more or less unclear. It is clear (by rules) when both > sides have exchanged reports and got confirmation to them. > You get confirmation with report as "R-xx" and you confirm it by sending > "RRR" or "RR73". Reino: That is recommended in the User Guide with a potential need for a resending RR73 or RRR due to a repeated "R-xx". To me that is a clear point of time as the operator feels the QSO is completed, he has sent RR73 (RRR) or received RR73 or 73 and no more a reception of "R-xx". User may need to correct the proposed end time in that case. > What I mean "unclear" is that someone requires 73 after RRR or RR73 to see > the qso complete, someone else do not. > There has been lot of conversation about this in past and I do not want to > make another "split argue" with this. Reino: Fully agree that there are at least two strong opinions on that and absolutely no need to restart any discussion on that issue. As an example is DXpedition mode, where Fox simply logs QSO at the sending the RR73. There is simply no action defined in that protocol for a reception of 73. For that reason there are dupes, but who cares. The same applies to some contests, where the sending of the 73 is not defined or stated optional. If there is a disagreement between operators, then simply there is no QSO (a NIL). That's a different issue, isn't it. Reino: My comment is also "what about interleaved QSOs or QSO attempts?". Well, normally QSO order in a log does not matter. BUT for a program that generates some challenges. E.g. how may QSO attempts (sending the first Tx2) it needs to remember? > My 5 cents is that qso start time is easier to define so that all can agree > with definition and should be used with Cabrillo, like it is used with CW and > phone, too. However the periodical exchange and poor conditions can make big differences in log times. That is the thing that contest log checkers should take account when defining accepted time windows for qso checks with FT8 qsos. It is different than with CW/Phone. Reino: Yep! The problem is the same for the start time and the end time. I think that the end time is in that sense a bit less uncertain and less variable. AND easier to implement in the program. > And it is not getting any easier of one logging program uses "time_on" and > other "time_off" when producing Cabrillo log. Reino: Perhaps both times should be presented! It may depend on the contest which one is actually used, but how well that is defined in the contest rules? Perhaps this a wrong forum for the discussion, hi! _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
