[NA-User] Slow F4 and INS type ahead

Mon Jan 12 11:29:18 EST 2004

As far as the Yaesu CAT light, there are several approaches to fixing 
that problem one local found - both are from the same manufacturer.

I have seen both part number 33 and part number 88 used to fix this 
problem.  Correctly trimmed and fitted they do a great job of fixing the 
CAT light problem.

Manufacturer for both is Scotch, aka 3M.

Personally I think that the Yaesu rigs should have to changes in their 
polling scheme to become more contester friendly - do it faster and more 
frequently.  Why 4800 baud, this is really slow - this is slowest thing 
in the shack next to this old farte...

And why poll so infrequently? If this slows down the computer when it 
happens I have never "felt" it - why not do it more often?  When you 
tune the band and it ain't packed you tune pretty fast... if you 
overshoot the bottom of the band and the rig polls at that moment then 
you get an "out of band" message...

Enough Yaesu bashing...

Heah Dave you know how many years I have been using NA - for the first 
time EVER in a contest it locked up on me this past weekend. I do not 
know if I hit a couple keys simultaneously or what but for the first 
time it froze on me.  I rebooted the computer and all was fine and jolly 
- lost about a minute and a half.

Thanks for NA - I wonder how many tens of thousands of QSOs I have 
logged on it!

73,

Jim, K4OJ

Dan Zeitlin wrote:

> Thanks for the fast response Dave.
> I understand.  I will install SMARTDRV.  I should have
> thought of that (or read the manual) myself.
> WRT the CAT light, I could live with the faster blink.
>  Perhaps the next time you are modifying code, you can
> think about a command line switch to increase the
> blink rate.
> 73,
> Dan
> 
> --- "David A. Pruett" <k8cc at comcast.net> wrote:
> 
>>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
>>
>>
>>_______________________________________________
>>NA-User mailing list
>>NA-User at contesting.com
>>http://lists.contesting.com/mailman/listinfo/na-user
>>NA on the web:  http://www.datomonline.com/
> 
> 
> 
> =====
> Dan Zeitlin
> Annapolis, Maryland
> http://members.tripod.com/~danzee/index.htm
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> _______________________________________________
> NA-User mailing list
> NA-User at contesting.com
> http://lists.contesting.com/mailman/listinfo/na-user
> NA on the web:  http://www.datomonline.com/
> 