[NA-User] Slow F4 and INS type ahead

[David A. Pruett]

At 02:47 PM 1/11/04 -0800, Dan Zeitlin wrote:
>I noticed a disturbing NA behaviour this weekend that someone may be able 
>to shed light on.  I run CT more often than NA, so it is possible that 
>this condition existed in the past without notice, but I don't think so.
>The first two problems below only occur when I have Autocheck enabled, 
>independent of which callsign database is used.  I tired them all from SS 
>through All.
>
>1.  There is a significant delay (>1 sec) from when I hit F4 my call is 
>sent.  I think this condition got worse as the QSO count increased.  I 
>only made about 650 Q's.

At the K8CC multi-op station, we used to have a room full of 486 computers, 
from 486DLC-40s, 486DX2-66s and even some 486DX4-100s, all running DOS 
6.22.  We did a number of multi-ops where we put several thousand QSOs in 
the logs.  While the response time does slow down a little with a very 
large log, we had no complaints from our ops.

The secret is having disk cache software enabled.  Disk cache is a software 
program with a big blob of memory which buffers the hard disk so that data 
stays in memory (which is very fast) and does not have to be retrieved from 
the drive (which is not so fast).

DOS 6.22 comes with a disk cache called SMARTDRV.  It can be implemented by 
adding the following line to your AUTOEXEC.BAT file:

         C:\DOS\smartdrv.exe /x

This assumes your DOS files are in a subdirectory called DOS.

SMARTDRV needs to have enough memory to hold your log, plus the MASTER.DTA 
file so it's not swapping the contents in and out as you CheckPartial, then 
log a QSO, CheckPartial, log a QSO, etc.  With 256MB of memory as you 
describe, just enable SMARTDRV and you should be in good shape..

All of this is covered in the NA manual in Section 6 under "Callsign 
Database Checking", so you can find this same info there.

>2.  When RUNning, if I hit INSERT with an incomplete call and fill in the 
>remainder on the fly, always staying ahead of NA's actual sending of the 
>call, the "on the fly" part of the call is not sent.  I noticed this right 
>away, early in the contest.

This is related to #1 above.  The master call database checking updates 
with each keystroke and has to finish the previous key before reacting to 
the INSERT.  Implement the suggestions given to fix the checking speed and 
this problem will disappear.

>3.  The update rate of the CAT interface is a bit slower than I would like 
>for updating the bandmap.  This one appears independent of Autocheck.

The update rate on Yaesu radios is every three seconds while others are 
every one second.  Yaesu radios is deliberately set slower because of the 
@#%&@%#&% blinking "CAT System" lamp.  When I got my FT-1000D in 1995, I 
found that the slower update rate bothered me a whole lot less than having 
"CAT System" blink in your face every second.


Dave Pruett, K8CC
DATOM Engineering

datom at contesting.com
http://www.datomonline.com