locked contest reflection


George KF7NN
 

wondering if you can make the database time dependent for contests. 
Ie having a "since" button or something similiar in order to only look at qsos since a certain date /time .

right now i have to create a new database in my log and then have jtalert scan it for every contest,
the worst part is i have to import the contest log into my main log afterward and then rescan it.

maybe you have something already set up? as i really only want one log


Dave Garber
 

curious, what database, what log in jtalert???

Dave Garber
VE3WEJ / VE3IE


On Mon, Sep 20, 2021 at 8:05 PM KF7NN <george@...> wrote:
wondering if you can make the database time dependent for contests. 
Ie having a "since" button or something similiar in order to only look at qsos since a certain date /time .

right now i have to create a new database in my log and then have jtalert scan it for every contest,
the worst part is i have to import the contest log into my main log afterward and then rescan it.

maybe you have something already set up? as i really only want one log


HamApps Support (VK3AMA)
 

On 21/09/2021 10:05 am, KF7NN wrote:
wondering if you can make the database time dependent for contests. 
Ie having a "since" button or something similiar in order to only look at qsos since a certain date /time .

right now i have to create a new database in my log and then have jtalert scan it for every contest,
the worst part is i have to import the contest log into my main log afterward and then rescan it.

maybe you have something already set up? as i really only want one log

OM,

What Log type are you using with JTAlert?

You have a three options depending on how you want to approach the contest.
  1. If your contest participation is to work as many stations and multipliers as possible without any regard to you're current JTAlert needs. Start the contest with a new empty log then do a one-off Alert database rebuild which will take a second or two since the log is empty. At the end of the contest if you want to put the contest QSOs in your normal JTAlert log do an import of the contest QSOs. How you do that depends on the log type you're using, followed by an Alert database rebuild operation after switching back to your normal JTAlert log.

  2. If you're in the contest to pick up new ones as well as hand out numbers, set the JTAlert Worked B4 date to the date of the start of the contest. This will ensure that past QSOs before the contest will not be flagged as B4s and you will still be alerted to new ones you need. QSOs logged during the contest will be flagged as B4s. After the contest turn off the Worked B4 date. There is no need for an Alert database rebuild.

  3. If you're in the contest only to pickup new ones without any desire to work as many stations and multipliers as possible, you don't need to make any changes in JTAlert and treat the contest as just another day working the bands.

1. & 2. are essentially the same, except 1. leaves you with a dedicated contest log that you can use for submission and saving.

de Laurie VK3AMA


George KF7NN
 

jtalert B4 database and my dxkeeper log


George KF7NN
 

i didnt realize there was a worked before date that i can configure without rebuilding database, too bad it dont have time also. but that works for me.
thanks


HamApps Support (VK3AMA)
 

On 21/09/2021 4:01 pm, KF7NN wrote:
i didnt realize there was a worked before date that i can configure without rebuilding database, too bad it dont have time also. but that works for me.
thanks

The B4 UTC Data starts from 00:00 utc. There is no provision for starting at an arbitrary time within that date. This has never been requested. How common is it for contests to start at a time other than 00:00 utc?

de Laurie VK3AMA


Jim Brown
 

Fairly common.

On Tue, Sep 21, 2021 at 8:17 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 21/09/2021 4:01 pm, KF7NN wrote:
i didnt realize there was a worked before date that i can configure without rebuilding database, too bad it dont have time also. but that works for me.
thanks

The B4 UTC Data starts from 00:00 utc. There is no provision for starting at an arbitrary time within that date. This has never been requested. How common is it for contests to start at a time other than 00:00 utc?

de Laurie VK3AMA


Tom Melvin
 

Contest start time

Yes fairly common - many mid afternoon to mid-afternoon, 10am for 6 hrs, mid day to midnight - if you were to add (and its not high on my  ‘would like to have’ list) it - would need to specify any start time. Also knowing users no sooner than you do that the request for end time will appear - guess the argument will be ohh condition so good can’r spare the xx seconds to change the settings back again. :-)

Regards
Tom
GM8MJV

On 22 Sep 2021, at 04:17, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:

On 21/09/2021 4:01 pm, KF7NN wrote:
i didnt realize there was a worked before date that i can configure without rebuilding database, too bad it dont have time also. but that works for me.
thanks

The B4 UTC Data starts from 00:00 utc. There is no provision for starting at an arbitrary time within that date. This has never been requested. How common is it for contests to start at a time other than 00:00 utc?

de Laurie VK3AMA



Jim Reisert AD1C
 

On Tue, Sep 21, 2021 at 9:17 PM HamApps Support (VK3AMA) via groups.io <vk3ama.ham.apps=gmail.com@groups.io> wrote:
On 21/09/2021 4:01 pm, KF7NN wrote:
i didnt realize there was a worked before date that i can configure without rebuilding database, too bad it dont have time also. but that works for me.
thanks

The B4 UTC Data starts from 00:00 utc. There is no provision for starting at an arbitrary time within that date. This has never been requested. How common is it for contests to start at a time other than 00:00 utc?

That's probably overkill.  The likelihood of working a contest participant between 00z and the actual start of the contest is rather slim.  The only contest I know of that has multiple sessions on the same day is the CW Open in September, but per the name, it's not a digital contest.

--
Jim Reisert AD1C, <jjreisert@...>, https://www.ad1c.us