Regarding logged time in cabrillo. Let's reason backwards: 1. Cabrillo is a file format used for submitting contest logs only. 2. Cabrillo is a file format normally created from an ADIF file that is created by specialized logging software, say N1MM Logger+, WinTest or some other contest software. 3. Logging softwares have no idea of when a QSO starts, because the only input they receive is when the logging of a QSO takes place, i.e. not until the contester finds the QSO to be complete, which is another way to say that logging takes place at TIME-OFF. 4. Matching of contest QSOs takes place if the time difference between the two involved logs are less than a specified time difference, which at least in the major contests is five minutes. 5. So, if you want to submit a cabrillo contest log, you should certainly make sure that the cabrillo file is created using TIME_OFF, no matter which software (contest software or not) you have used to log the QSOs during the contest. That also applies to using WSJTX_LOG.ADI as the ADIF contest log. 6. The time difference of 30 minutes allowed for QSO matching in LoTW obviously is not relevant for the time logged in the cabrillo log. They have two very different purposes, and LoTW has no bearing whatsoever of what a contest sponsor will accept. 7. Based on the above, starting from the origin and purpose of a cabrillo file, there is no reason to consider any other time than TIME_OFF for the cabrillo log.
73, Frode LA6VQ (LC6C in contest) <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virusfri.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> lør. 13. mai 2023 kl. 07:06 skrev Reino Talarmo via wsjt-devel < wsjt-devel@lists.sourceforge.net>: > 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 >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
