Log4OM

Last weekend I used LOG4OM in CQ WW SSB and tested the contest mode. Everything worked as designed. Nevertheless I would like to make two suggestions for improvements in contest mode:

1. LOG4OM remembers the Contest ID but unfortunately not the timespan (Contest start and end time). On the second day of the contest I did not realize that the timespan was resetted to zero which resulted in dupes. I had to configure again the start and end time. Then " search previous QSO in this contest only" worked again. I suggest that LOG4OM stores these data that nothing is lost after restart.

2. In the mode " search previous QSO in this contest only" the Cluster in contest mode still shows all spots and I have to click a spot first to get the message if I have worked this callsign already on this band. It would be a great help when the cluster in contest mode will remove all the spots which I have already worked om this band in the current contest.

If you will pardon the "Cockney" language but.......

Two bloody good ideas mate!

First idea is good, i'll ask terry to add with his comments on our tracking system.
Second one require a little bit more work, because for each spot i should go into log searching for those informations... a bit slow but possible.
But also... filter should be on same band or Whole cluster? and mode? things are not so simple if you think about...

ideas?

Hi Daniele,

yes no 2 might be more complex but perhaps I am too naive: LOG4OM has just to do what I did manually. When I click the cluster spot the "worked on same band" information is alreday avalable.

If this data cannot be used it should work with the following logic: When a new spot arrives it has to be analyzed before it will be displayed or skipped in the cluster window. The program has to look in the current contest log if the call is already in the log AND if the band is the same this call has to be skipped (not displayed in the cluster window). If there is no compliance no further action is necessary and the spot can be displayed as usual. At the beginning of the contest the log is small but with increasing log there might be a performance issue.

I think there should not be a mode check. The contest categories I know are only single mode (CW or SSB or RTTY) and the cluster information does not give reliable mode informations.

This is just a suggestion but it will help a lot to speed up the cluster assisted contest operation.

Yes Olaf, this is how it should work.
Problem is having an high rate of database access (search database for every new spot) without affecting overall performances and keeping cluster smooth