IARU HF Championship

[Nate Bargmann]

I only operated about four hours--Saturday evening and Sunday morning,
all CW. I am still getting the muscle memory reprogrammed and that will
come with time.

Thinkgs I like, setup is quick since my radio and CW port connections
were already defined and operational. The program is not too busy and
shows what I need to know. No loss of data occured or any such thing.

Interesting behavior I noticed is that when I entered an HQ station's
association acronymn incorrectly, pressing <Enter> resulted in my call
being sent again even though the cursor was in the Exchange field in S&P
mode.

On a couple of occasions in the Exchange field I simply typed the
received zone/HQ after the prefill value. Upon inspectiong the Cabrillo
file for those QSOs, the received signal report was replaced by the
prefill value. As the signal report cannot be accessed in the edit
window, I corrected the values using SQLite Browser and regenerated the
Cabrillo file..

I also ran a bit on 15m and that worked well. I began to wonder if an
automatic CQ timer might be useful.

I still have not tried the SDR or the 2R portions of the program. It is
filling my need of a logger quite well. I'm a casual contest op but
like to use the right tool for the job. Highlight was working
Kahzakstan as he had no pileup.

73, de Nate >>

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

[R. Torsten Clay]

On Mon, Jul 16, 2012 at 12:47 PM, Nate Bargmann <n0...@n0nb.us> wrote:

I only operated about four hours--Saturday evening and Sunday morning,
all CW.  I am still getting the muscle memory reprogrammed and that will
come with time.

Thinkgs I like, setup is quick since my radio and CW port connections
were already defined and operational.  The program is not too busy and
shows what I need to know.  No loss of data occured or any such thing.

Interesting behavior I noticed is that when I entered an HQ station's
association acronymn incorrectly, pressing <Enter> resulted in my call
being sent again even though the cursor was in the Exchange field in S&P
mode.

I will have to look into that
 

On a couple of occasions in the Exchange field I simply typed the
received zone/HQ after the prefill value.  Upon inspectiong the Cabrillo
file for those QSOs, the received signal report was replaced by the
prefill value.  As the signal report cannot be accessed in the edit
window, I corrected the values using SQLite Browser and regenerated the
Cabrillo file..

That is supposed to work (just typing the replacement), and does work for
some other contests. It should be easy to fix.
 

I also ran a bit on 15m and that worked well.  I began to wonder if an
automatic CQ timer might be useful.

Yes, I want to add that eventually.
 

I still have not tried the SDR or the 2R portions of the program.  It is
filling my need of a logger quite well.  I'm a casual contest op but
like to use the right tool for the job.  Highlight was working
Kahzakstan as he had no pileup.

73, de Nate >>

I made 2100 qso's single-mode CW so I pushed the program pretty hard :)
Some things I noted that need fixing:


-the program should check for and display the setting of the "Insert key"

-is it possible to show a cursor in the call/exchange fields? Sometimes when using
grab keyboard the location of the cursor gets lost. This is important when editing calls

-grab keyboard should allow log editing. Major pain. I also don't like the default behavior
where the first keypress after selecting a cell totally overwrites the contents of the
cell. Too easy to lose/forget what you originally had this way. Better to append new
letters to what is already there.

-I observed the funny behavior where the program does not advance to the
exchange field many times. When this happens one has to press the down arrow
twice to get there. The first down arrow key press is strangely eaten with no effect in this
situation.

-some bugs with alt-D (method for working calls on 2nd radio). Sometimes the 2nd
radio call entry is blank/unresponsive. esc several times fixes this. This will be hard
to track down.

-once the "TX" indicator in the bandmap got stuck on "TX". The program must have
missed the status indicator from winkey. It was reset on the next transmission.

-check the behavior with calls that are not identified by the CTY file. In this
contest, TO5U.


Tor
N4OGW

[Nate Bargmann]

* On 2012 16 Jul 14:54 -0500, R. Torsten Clay wrote:
> That is supposed to work (just typing the replacement), and does work for
> some other contests. It should be easy to fix.

Good. I thought that was the intended behavior which is why I mentioned
it.

> I made 2100 qso's single-mode CW so I pushed the program pretty hard :)

Nice job. It was a surprise to hear you on 15m Saturday evening.

> Some things I noted that need fixing:

> -grab keyboard should allow log editing. Major pain. I also don't like
> the default behavior where the first keypress after selecting a cell
> totally overwrites the contents of the cell. Too easy to lose/forget
> what you originally had this way. Better to append new letters to what
> is already there.

I find that I have to double click to enable editing and then click
again to clear the highlight. It seems to me that selecting a cell
should not highlight it, but that seems to be default GUI toolkit
behavior even though I think it ought to be a property that is
configurable by the programmer.

> -I observed the funny behavior where the program does not advance to
> the exchange field many times. When this happens one has to press the
> down arrow twice to get there. The first down arrow key press is
> strangely eaten with no effect in this situation.

I did not run enough to see this. I did have a case where I had
manually backspaced the call remnant I had entered and then the program
insisted on sending the exchange or some such. A couple of <ESC>
presses later and hit <Tab> to get back to S&P and I was on my way.

> -check the behavior with calls that are not identified by the CTY
> file. In this contest, TO5U.

I had forgotten to update the CTY file which could have been a mistake.
This brings up another question. Even though the CTY and SCP files are
installed with 'sudo make install', perhaps the program should check for
newer versions in ~/.so2sdr, or, in the directory where the contest .cfg
and .log files are placed.

[R. Torsten Clay]

On Mon, Jul 16, 2012 at 12:47 PM, Nate Bargmann <n0...@n0nb.us> wrote:

On a couple of occasions in the Exchange field I simply typed the
received zone/HQ after the prefill value.  Upon inspectiong the Cabrillo
file for those QSOs, the received signal report was replaced by the
prefill value.  As the signal report cannot be accessed in the edit
window, I corrected the values using SQLite Browser and regenerated the
Cabrillo file..

There is a problem here. So far the program allows one to enter a RST other than 599.
With just CW you can always distinguish between a RST and a zone. But what to do
with an Australian station on SSB where you enter "55 59"? Is that a 55 signal and zone
59, or a corrected zone?

I do want to keep the "free form" exchange entry rather than putting in separate
boxes for each element. But non-599 RST's are very very rare in contests.

1. One option is to show the RST column in the log, so you could edit it. But why show
something that is the same for 99.99% of all qso's?

2. Another option is to have a "full edit" for the qso that brings up a dialog where everything
in the qso can be changed. It could be selected by a right click or similar.

3. Another option is to look for a string like "RST569" in the exchange box in order to
set a non-standard RST.

I think having both #2 and #3 might be the best way to go.

Tor
N4OGW

[Nate Bargmann]

* On 2012 18 Jul 17:20 -0500, R. Torsten Clay wrote:
> On Mon, Jul 16, 2012 at 12:47 PM, Nate Bargmann <n0...@n0nb.us> wrote:
>
> >
> > On a couple of occasions in the Exchange field I simply typed the
> > received zone/HQ after the prefill value. Upon inspectiong the
> > Cabrillo file for those QSOs, the received signal report was
> > replaced by the prefill value. As the signal report cannot be
> > accessed in the edit window, I corrected the values using SQLite
> > Browser and regenerated the Cabrillo file..
> >
> >
> There is a problem here. So far the program allows one to enter a RST
> other than 599. With just CW you can always distinguish between a RST
> and a zone. But what to do with an Australian station on SSB where you
> enter "55 59"? Is that a 55 signal and zone 59, or a corrected zone?
>
> I do want to keep the "free form" exchange entry rather than putting
> in separate boxes for each element. But non-599 RST's are very very
> rare in contests.

Sometimes there is an op that thinks that "real" reports are needed.

> 1. One option is to show the RST column in the log, so you could edit
> it. But why show something that is the same for 99.99% of all qso's?
>
> 2. Another option is to have a "full edit" for the qso that brings up
> a dialog where everything in the qso can be changed. It could be
> selected by a right click or similar.
>
> 3. Another option is to look for a string like "RST569" in the
> exchange box in order to set a non-standard RST.
>
> I think having both #2 and #3 might be the best way to go.

If you look for 'rst' preceeding a numeric value, then I presume that
the program would apply the change to the zone if the string is not
present? As I recall, for one of the contacts the prefill zone value
was '8' and I changed it to '6', which was sent. The Cabrillo output
showed an '8' instead of '599' which I didn't expect and '6' for the
zone as expected.

I like option #2 with an option to "full edit" the log with a key
combination like Alt-E or some such.

The downside of option #3 is more characters to type and the need to
remember to type them!

Perhaps I'm not thoroughly sold on the free-form exchange field having
only used fixed fields before. It may well be that I haven't gotten
into the situation where it shows its advantage. After less then 200 Qs
over two events, that is quite likely the case. Still, it seems that
there would be less code for handling fixed fields, but that's just my
guess. Heh!

Having never used TR, how does it deal with this?

[Nate Bargmann]

I received the following from the robot:

2012 IARU HF World Championship Contest

Callsign: N0NB
Single Operator, CW Only, Low Power

Category-Operator: SINGLE-OP
Category-Transmitter: ONE
Category-Mode: CW
Category-Power: LOW
Category-Station: FIXED (*** see below)
Category-Assisted: NON-ASSISTED
Location: Kansas - KS
Name: Nate Bargmann
Address: 511 North 4th
Log Deadline: 2012-08-14 12:00:00 UTC
Received at: 2012-07-21 13:43:27 UTC
Reported QSOs: 115
Confirmation #:

Thank you for your participation in the contest and for submitting
your log to iar...@iaru.org. While the Contest Robot was able to
process your log, it has discovered some potential problems. Please
correct the problems identified below and resubmit your log. We want
to make sure that we have your information right!

If you believe you have received this message in error or if you are
having problems creating the required log file, please contact me at
cont...@arrl.org and I will try to help.

73.

ARRL Contest Branch



*** Informative Messages from the Contest Robot ***

[X] No value is found for CATEGORY-STATION: -- I was expecting FIXED or MOBILE or PORTABLE or HQ, so I set it to the default value of FIXED.

---- >8 ----

It looks like the 'Category-Station' field is lacking from the SO2SDR
Cabrillo output. Also, the 'Location' field was blank and I manually
edited 'KS' into it.

[R. Torsten Clay]

On Mon, Jul 23, 2012 at 5:28 PM, Nate Bargmann <n0...@n0nb.us> wrote:

* On 2012 18 Jul 17:20 -0500, R. Torsten Clay wrote:
> On Mon, Jul 16, 2012 at 12:47 PM, Nate Bargmann <n0...@n0nb.us> wrote:
>
> >
> > On a couple of occasions in the Exchange field I simply typed the
> > received zone/HQ after the prefill value.  Upon inspectiong the
> > Cabrillo file for those QSOs, the received signal report was
> > replaced by the prefill value.  As the signal report cannot be
> > accessed in the edit window, I corrected the values using SQLite
> > Browser and regenerated the Cabrillo file..
> >
> >
> There is a problem here. So far the program allows one to enter a RST
> other than 599.  With just CW you can always distinguish between a RST
> and a zone. But what to do with an Australian station on SSB where you
> enter "55 59"? Is that a 55 signal and zone 59, or a corrected zone?
>
> I do want to keep the "free form" exchange entry rather than putting
> in separate boxes for each element. But non-599 RST's are very very
> rare in contests.

Sometimes there is an op that thinks that "real" reports are needed.

I usually receive one or two a year out of several thousand contest qso's :)

 

> 1. One option is to show the RST column in the log, so you could edit
> it.  But why show something that is the same for 99.99% of all qso's?
>

I think I will probably show the received RST anyway. For all the contests that
 use it, there is enough room.
 

> 2. Another option is to have a "full edit" for the qso that brings up
> a dialog where everything in the qso can be changed. It could be
> selected by a right click or similar.
>
> 3. Another option is to look for a string like "RST569" in the
> exchange box in order to set a non-standard RST.
>
> I think having both #2 and #3 might be the best way to go.

If you look for 'rst' preceeding a numeric value, then I presume that
the program would apply the change to the zone if the string is not
present?  As I recall, for one of the contacts the prefill zone value
was '8' and I changed it to '6', which was sent.  The Cabrillo output
showed an '8' instead of '599' which I didn't expect and '6' for the
zone as expected.

yes
 

I like option #2 with an option to "full edit" the log with a key
combination like Alt-E or some such.

After some beating my head against the Qt event and table display widgets I
think the editing is working much better. I also have a detailed editor working.
Hopefully it will get uploaded in a few days.
 

The downside of option #3 is more characters to type and the need to
remember to type them!

Perhaps I'm not thoroughly sold on the free-form exchange field having
only used fixed fields before.  It may well be that I haven't gotten
into the situation where it shows its advantage.  After less then 200 Qs
over two events, that is quite likely the case.  Still, it seems that
there would be less code for handling fixed fields, but that's just my
guess.  Heh!

Having never used TR, how does it deal with this?

 

TR is free-form also, and does update the exchange without having to backspace.
I don't remember exactly how it handles some of these issues however.

Tor
N4OGW