[TRLog] Bandmap bugginess in version 6.67

[Ronald Rossi]

Log reply with comments in line...

Mike Heideman wrote:
> 
> "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.

I and another beta user tried it. You do need to set USE BIOS KEY CALLS
= FALSE.
6.68 includes support for ASK FOR FREQUENCY = TRUE

> 
> > > 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.

Hmmm. No band info comes in from packet. The program determines the
mode. Maybe it was an SER hit to the RAM?

> 
> 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).

I find setting SEND QSO IMMEDIATELY = FALSE cures that. Then you can
edit with no problems. I will consider the LOG EDIT ENABLE command. It
sounds reasonable enough!

> 
> 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?

Yeah. That IS a bit of a tough nut, but a good point well taken. 

> 
> 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.

Hmmm a potential solution. Let me think about that.

> 
> 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.

Faster is better. Assuming you have SMARTDRV or similar enabled the
machine speed IS the issue. Otherwise turn on a disk write cache. I have
never waited SECONDS. Maybe a second, but rarely and generally much
less. This was at W1MOO FD a couple years ago with some 386 real
poopers.

> 
> 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.

Yes shades of VI! Well that is how the program works and when you learn
it is one of its most powerful assets.

> 
> 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.

Neither will I =;-)
> 
> 73,
> -Mike, N7MH

-- 
73 es God Bless de KK1L...ron (kk1l@arrl.net) <><
QTH: Jericho, Vermont
My page: http://www.qsl.net/kk1l