1. ICOM Frequency Errors - I am taking a new approach and working with
VK5GN to isolate the problem. I am going back to a previous version to
establish that it didn't have the problem - and then will move forward
from there to the current version. This brute force method should
eventually result in understanding what is causing the problem and
then we can look at corrective actions.
2. ESCAPE Key not aborting CW messages. Last night, I ran a test -
with my 486 at 8 MHz and no smartdrive. With a log of about 2200
QSOs, a disk update took several seconds. This was without
SMARTDRV running. Even with SMARTDRV running, it was in the order
of a second or two. This was enough time for a lot of CW to be sent
after pressing the ESCAPE key.
This problem becomes a lot worse at a multi-multi - because disk
activity can occur at any time - instead of when you have initiated
a QSL MESSAGE (which is typically a safe time to have the system
ignore the keyboard for awhile). This was a problem at W7RM when
using a 386 computer.
Currently, I would say for a serious multi-multi - the minimum
computer you should consider running is something like a
486DX66 - with a fast hard drive - and SMARTDRV running.
I would suggest turning off the UPDATE RESTART FILE ENABLE command
as this will speed up the logging to file process. It does mean
that if you restart the program - it will take longer for it to
come up.
I am going to think about buffering up network QSOs so they are logged
to the disk when you log your next QSO - or after some timeout period.
This might help the situation enough for most people - even with
slower computers. It would also make the network more responsive.
Tree
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|