locked A time logging question for the masses


vk7cej@y7mail.com
 

I think I have lost the plot...  I just cannot find the answer to this..     I am using Log4om, WSJT-X and JTAlert.    I mainly use FT8 and FT4 modes and recently noticed that log entries are being made using the start time..   I would prefer to log using the end time.    Does anyone here use these same 3 programs and can point me to where this particular setting is please ????

 

Regards

John


Michael Black
 

LOTW uses TIME_ON, not TIME_OFF -- so why would you want different?

Mike W9MDB




On Monday, October 4, 2021, 09:41:11 PM CDT, vk7cej@... via groups.io <vk7cej@...> wrote:


I think I have lost the plot...  I just cannot find the answer to this..     I am using Log4om, WSJT-X and JTAlert.    I mainly use FT8 and FT4 modes and recently noticed that log entries are being made using the start time..   I would prefer to log using the end time.    Does anyone here use these same 3 programs and can point me to where this particular setting is please ????

 

Regards

John


vk7cej@y7mail.com
 

Hello Mike....     I want it to use time off because there can be a vast difference between the start and end times.   Down here, it gets rather busy and the qrm means I dont always get to complete a contact because the caller vanishes, I work several other, then he calls again and it logs the "old" start time which can be several minutes out.

 

let me read that again.......   yeah, I think that explains it  :-)

 

John


Michael Black
 

LOTW has a 30-minute time match based on start time.
So if you get close to that and want a match better check with the other party to see their time too.
If they went to work somebody else though good bet they'll use the new time which means you should update it too.
If you get used to clearing the DX Call box then the time will reset when you click on them again.
Or you can simply change the time yourself which is bit more straight forward.


May an option for stop time to be recorded as start time would be a better bet though as stop time would most likely be closer to the real start time for a broken QSO.

Mike W9MDB


On Monday, October 4, 2021, 10:28:53 PM CDT, vk7cej@... via groups.io <vk7cej@...> wrote:


Hello Mike....     I want it to use time off because there can be a vast difference between the start and end times.   Down here, it gets rather busy and the qrm means I dont always get to complete a contact because the caller vanishes, I work several other, then he calls again and it logs the "old" start time which can be several minutes out.

 

let me read that again.......   yeah, I think that explains it  :-)

 

John


Michael Black
 

Or...maybe a warning if stop time is more than 29 minutes from start time to check your start time.  That would seem to be an easy one and a better overall solution.


Mike W9MDB




On Monday, October 4, 2021, 10:49:03 PM CDT, Black Michael <mdblack98@...> wrote:


LOTW has a 30-minute time match based on start time.
So if you get close to that and want a match better check with the other party to see their time too.
If they went to work somebody else though good bet they'll use the new time which means you should update it too.
If you get used to clearing the DX Call box then the time will reset when you click on them again.
Or you can simply change the time yourself which is bit more straight forward.


May an option for stop time to be recorded as start time would be a better bet though as stop time would most likely be closer to the real start time for a broken QSO.

Mike W9MDB


On Monday, October 4, 2021, 10:28:53 PM CDT, vk7cej@... via groups.io <vk7cej@...> wrote:


Hello Mike....     I want it to use time off because there can be a vast difference between the start and end times.   Down here, it gets rather busy and the qrm means I dont always get to complete a contact because the caller vanishes, I work several other, then he calls again and it logs the "old" start time which can be several minutes out.

 

let me read that again.......   yeah, I think that explains it  :-)

 

John


HamApps Support (VK3AMA)
 

On 5/10/2021 1:41 pm, vk7cej@... via groups.io wrote:

I think I have lost the plot...  I just cannot find the answer to this..     I am using Log4om, WSJT-X and JTAlert.    I mainly use FT8 and FT4 modes and recently noticed that log entries are being made using the start time..   I would prefer to log using the end time.    Does anyone here use these same 3 programs and can point me to where this particular setting is please ????

 

Regards

John


There is no setting in JTAlert.

JTAlert logs both TIME_ON & TIME_OFF values as well as the QSO_DATE & QSO_DATE_OFF values. It is up to the logger as to how it handles those values.

I just looked at my Log4OM log that I use for testing (my preference is DXKeeper) and it records a QSO Start date & time and a QSO End date & dime. Note the separate start and end times and dates...

   

There is nothing JTAlert can do to force Log4OM to use different values.

I suggest you manually change the TIME_ON value in the wsjtx "Log QSO" window before hitting the OK button if the QSO took a long time to complete.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 5/10/2021 2:49 pm, Michael Black via groups.io wrote:
If you get used to clearing the DX Call box then the time will reset when you click on them again.
Or you can simply change the time yourself which is bit more straight forward.


Or simply double-click (in wsjtx) the first decode received from a Station you have been trying to work for awhile. That will reset the start time to the time of the double-click.

de Laurie VK3AMA


vk7cej@y7mail.com
 

thanks Laurie..   I have been doing that, but was hoping for an "auto" option....  oh well, manual mode it is.    :-)

 

John


HamApps Support (VK3AMA)
 

On 5/10/2021 2:50 pm, Michael Black via groups.io wrote:
Or...maybe a warning if stop time is more than 29 minutes from start time to check your start time.  That would seem to be an easy one and a better overall solution.



I disagree. Too much automation or hand-holding by software encourages sloppy operating IMO.

de Laurie VK3AMA


Michael Black
 

I disagree with your disagreement :-)

Users don't even look at the fields after doing just a few QSOs.  So would never notice the time problem.  I don't consider it hand holding when the software could easily notice you might have a problem matching data that you don't even look at.   It's not sloppy operating...it's caused by habit....

As I recall you've said you don't operating much anymore but you would quickly find you won't even look at most the data being logged...if at all.

Mike W9MDB




On Monday, October 4, 2021, 11:04:38 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 5/10/2021 2:50 pm, Michael Black via groups.io wrote:
Or...maybe a warning if stop time is more than 29 minutes from start time to check your start time.  That would seem to be an easy one and a better overall solution.



I disagree. Too much automation or hand-holding by software encourages sloppy operating IMO.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 5/10/2021 3:03 pm, vk7cej@... via groups.io wrote:

I have been doing that, but was hoping for an "auto" option....  oh well, manual mode it is.    :-)


No need to manually change the Log QSO window entries, when you finally make contact with the station, simply double-click the first decode (in WSJTX) you receive from them. That will reset the start time to the time of the double-click discarding the start time that was set when the DXCall was set when you first called them, which could have been many minutes earlier. Double-clicking a WSJTX decode while in QSO has always reset the start time. This is behavior that goes back to the very early days of JT65 before the existence of WSJTX.

de Laurie VK3AMA


Captain Fantastic
 

It's actually unfortunate that LOTW doesn't use "TIME_OFF" instead of "TIME_ON"... as there would be a higher probability of a match.

Gregg