"Ron D. Rossi" wrote:
> > I like to be able to see the section of
> > the bandmap for which I'm entering spots so that I can tell if
> > there are any big frequency gaps where I've missed a station.
> > Doing Ctrl-End and right-scrolling is not a very convenient way
> > to do this.
>
> Version 6.68 includes much improved performance when not interfaced to a
> radio. I will look at making the band map page track the last frequency
> entered. That would be a nice touch.
I agree that for a non-interfaced radio this would make a lot of sense.
> All that stuff COULD be related to the non interfaced radio. I would like to
> see how this works in version 6.68 before I did anything. Are you sure that
> you were using 6.67?
Yes, I'm sure. We used the CALL WINDOW SHOW ALL SPOTS parameter in our config
file which only became available in 6.65. I had forgotten to install 6.67 on
one
computer and it complained that it didn't recognize this parameter until I had
it
correctly installed.
> We tried using both the Ctrl-Delete and Ctrl-Insert features of
> > the new, improved bandmap but neither did anything. The latter
> > was tried both on interfaced and non-interfaced radios.
>
> This could be BIOS dependent. I had to get the scan codes for those keys
> empirically. They work on my two IBM laptops and a generic pentium pro
> desktop. I have USE BIOS KEY CALLS = FALSE in my LOGCFG.DAT (actually
> STDCFG.DAT).
I'll try USE BIOS KEY CALLS = FALSE and see what happens. Should Ctrl-Insert
work
with non-interfaced computers when ASK FOR FREQUENCY is TRUE? I found in my
scans
of the band that there were some stations that were either too weak on my
receiving antenna or always transmitted exactly at the same time as our run
station so that I couldn't copy the call. I tried Ctrl-Insert to capture the
frequency and it either didn't do anything or it toggled INSERT mode. Same
thing
on the interfaced computers.
> > We had BANDMAP ALL MODES set to FALSE but a packet spot for some
> > unusual prefix at 14280 ended up in the bandmap. Shouldn't the
> > default range for the CW band filter these out?
>
> I am sure that came from the uninterfaced radio. The problem prior to 6.68 was
> that with no radio interfaced the band map was stuck on CW. This should not
> happen in 6.68. Of course if everything was working perfectly I would not be
> so busy!
This spot came from packet, not from one of our logging computers. According to
Table 17 of the latest (6.63) manual, the default bandmap cutoff frequency for
CW
is 14100 kHz. So the problem is that somebody that wasn't in the contest
spotted
some rare DX in the phone band to packet which ended up in our CW bandmap.
Thanks for the quick and informative responses. Some of our operators have been
pushing for us to switch to WriteLog. We tried it in the NEQP and discovered
that
many of the useful features of TR were missing - no initial exchange from the
MASTER.DTA file, band maps not shared between computers, etc. As long as TR
continues to innovate and make it easier to maximize contest scores we'll stick
with it.
The biggest complaints we get from the WriteLog users (and my suggestions) are:
1. Why can't we edit the log?
Somebody always edits it anyway and I have to difference the logs from all the
computers to find the right info. Enabling editing of already-logged QSOs that
will propagate to all computers on the network, update the dupe sheet and
bandmap
correctly, correct initial exchange information, and adjust QSO and mult count
for
scoring would stifle all of these complaints. As long as TR continues to fail
to
deal with log edits I'd suggest adding a configuration parameter LOG EDIT
ENABLE,
which when FALSE disables Alt-E editing and prevents the up-arrow key from
moving
the cursor into the editable log area. One of our WriteLog enthusiasts kept
accidentally moving into the editable log window and typing things. He mostly
avoided screwing up the log, but one instance of N7IR got changed to A71R
(that's
why we can't use Post/Merge if the log is editable).
2. Why do we have to be so careful about not leaving the program in certain
states
when we leave, or take a meal or restroom break?
In looking back through the reflector I saw that Tree had added this problem to
his to-do list in 1997. It's still not fixed. This contest I was the culprit
when I used Alt-L to find something in the log to show someone else. Last
contest
our late-night 160-meter operator decided to study TR using Alt-H for several
minutes. Another contest it was someone leaving their logging computer after
duping a station on an uninterfaced computer with ASK FOR FREQUENCIES set to
TRUE. Another time it was using Ctrl-L to scroll through the log. All of these
and many more input scenarios prevent the multi-network traffic from circulating
through the network and eventually end up causing some computers to miss QSOs.
Why can't all of these input scenarios use a similar input scheme as is done
with
the Call Window and Exchange Window so that network traffic still flows even
while
they wait for possible input?
3. Why doesn't the program let us enter corrected calls into the dupe sheet?
This would be fixed if the log were truly editable as in 1 above. An example in
the past contest is when one of our operators incorrectly logged KX7M as KX6M on
10 meters. We noticed the error and put a note in the log. Unfortunately we
had
5 or 6 other operators come and operate 10 meters later and they all called KX7M
who told them that we'd already worked. There were several of these incorrectly
logged callsigns that we had noted but kept stumbling over.
Yes, I know that one solution is to enter a bogus QSO with the right callsign
but
then you also have to enter another note to explain it and delete it from the
log
later. In the absence of log editing, it would be extremely useful to be able to
simply hit a key that added the current contents of the Call Window to the dupe
sheet for the current band. This would work much like the PACKET SPOT KEY,
perhaps called DUPE ADD KEY (defaulting to ~ ?) which prompts the user as in
"Adding KX7M to 10 meter dupe list", where ENTER adds and ESC aborts.
4. Why do I have to wait several seconds for things to happen, like Esc to stop
sending CW or F1 to start sending CQ?
We have a couple of slow (33 to 66 MHz 486) computers that have this problem
once
the QSO count gets high. We just need to replace them with faster machines.
5. Why does this program use modal input? Don't the developers know that modal
input is hard to learn?
This does seem to be one of the hardest things for most new users to learn,
especially those accustomed to non-modal logging programs. The typical error is
sending CQ or the other station's callsign when you intended to send your
callsign
to answer a CQ. Not sure how to solve this - they'll learn eventually.
6. Why does the program need so many serial ports? Can't it use USB ports and
run
on Windows?
I won't touch this one.
73,
-Mike, N7MH
|