Actually what I mentioned is WRONG on when the time gets set (When dealing
with 75,000 lines of digital code they tend to blend together.) This was
changed a couple of years ago to stop exactly what you mentioned below.
This is the actual routine that sets the time
If UsesDigitalTimeRoutine And (Index = ExchangeButton Or Index =
HisCallButton + 120 * (ExchangeButton + 1) Or InStr(1, aString, "{TIME2}",
CompareMethod.Text)) Then
If Len(CallSign.Text) > MinCallSignLen And ct.MiscText = "" Then
ct.MiscText =
Station.CurrentContest.SetSentTimeForContact(ct)
End If
End If
What this says is if the UsesDigitalTime Rotine =true and if you have
pressed the Exchange F-key or the F5/F2 combination and {TIME2} is in the
exchange being sent, then set the MiscText field in the database to the
current time.
So if the user edited the call it would not change the time that had been
locked in.
During the BARTG test there were a couple of versions released in attempt to
fix the errors that were being reported. When it was found that the users
were not using the {TIME2} macro and that was
the cause of the issues John K3CT who coded the fixes during the contest
made the decision to use the qso time as the sent time if that field was
missing from the database.
" What happened to the received time values that were terminated with a Z?
Or, what was sent when someone asked for an exchange re-send?"
On the 20th after it was brought to my attention that users were unable to
click on a time with a Z in it. I made a change which corrected that on the
21st. As in the past any calls that were clicked on that had a Z in them the
Z is removed before the time gets logged. It has always been that way. What
was sent when someone for a resend depended on if they user had {TIME2} in
there macro string or not. If they did then it sent the locked in time. If
they did not it more than likely sent whatever time format was in the macro
they used.
If the user used the {TIME2} macro in their strings then the time sent and
logged and outputted in the cab file should be the same and nothing for them
has changed at all before during and after the contest. If the user did not
use the {TIME2} macro (Their own fault for not reading the setup
instructions.) Then their time sent was probably going to be different.
Hope this answers all the questions..
73 Rick N2AMG
-----Original Message-----
From: RTTY [mailto:rtty-bounces@contesting.com] On Behalf Of Ben Antanaitis
- WB2RHM
Sent: Thursday, April 09, 2015 6:15 PM
To: rtty-contesting.com
Subject: [RTTY] BARTG HF Contest 2015 Preliminary Results
Rick,
With all due respect to the programmers of N1MM+, this has been a monumental
and wonderful effort by a dedicated team, but it still is a work in
progress.
With regard to the status of N1MM+ time handling, and the BARTG contest
programming in particular, this year:
1) What happened to the value saved for TIME2, if the user 'corrected' any
partial/incomplete/incorrect call already entered in the entry field, using
the keyboard to either add extra characters, delete extra characters, or
retype the call entirely, anytime during the QSO, before the TU or TU AND
NOW exchange?
OR
2) What happened to the original TIME2 value, if the user 'fixed' a current
but incorrect callsign, already showing inside the Entry window, by
double-clicking on the 'correct' call being displayed in any DI window at
anytime during the QSO before the TU or TU AND NOW exchange?
Was the 'stored'/Reported' Time2 value still the 'original' one, or did it
get 'updated' due to 'retyping', or 'double-clicking' during the middle of
the QSO?. What time showed in the 'log page' or the Cabrillo report? Were
they the same value?
What happened to the received time values that were terminated with a Z?
Or, what was sent when someone asked for an exchange re-send?
What happened to the F11 or TIME2 value sent?
I know there were at least two N1MM+ '{TIME2}/Time field'
related updates that were released during the course of the BARTG contest
weekend, during the contest period. One Official update and one
'experimental' update. I belive that a contester could have begun operation
and then operated the whole contest without knowing there were
updates/changes to the TIME2/time handling at all.
Then, on Monday morning after the BARTG completed, another Official
N1MM+ update was released, that would affect how certain Cabrillo
'exchanges' were reported for BARTG entries.
In all fairness, how does the BARTG contest committee reconcile these
differences in the exchanges that were transmitted during the contest
vs the 'modified' ones reported in the cabrillo before or after the
'weekend decision' of the programmers?
As I understand it, all of the above situations, totally apply to the
user who were using the {TIME2} macro properly and correctly. To say
that the problems were caused by the Users not using the TIME2 macro
properly is just not correct.
73,
Ben - WB2RHM
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|