Well - first off - let me thank everyone for the data. I must admit
this hasn't been an easy thing to "wake up" to, but I have tried to
keep my chin up.
And now I have something good to report. I have found the problem.
I can recreate it 100 percent of the time and so can you...
Make sure you have packet enabled in your LOGCFG.DAT file (you won't
even need to hook it up however). Now type TR PACKET and TR will
start with 10 packet spots loaded in.
Now use the Control-U command to look at the 10 spots. Use the tab
key then the down arrow and move over to GW3YDX (or GI3OQR or ON4UN)
and then press RETURN twice. Your computer is now hung.
The routine that is used to delete an entry in this menu that you
have just worked is broken and can end up in an endless loop with
the right conditions.
The fix will be easy now - and I will have it done before I leave
for Louisana for anyone who really wants to use packet during the
SS CW.
I know one or two of you had problems without packet - or with
different symptoms. I will continue thinking about those, but
they may be more of the isolated event type thing.
Before I found the problem this way, I added a new startup command
to TR - TR PACKETSIMULATE. In this mode, it asks for a serial port
and then starts spewing out packet spots at better than one per
second! I ran this on the BBS computer (sorry for the downtime)
and ran the spots over to the other computer's "packet" port.
Then I used the TR READ feature so I was not only receiving packet
spots, but working QSOs at several thousand per hour. This test
didn't fail at all!!
This bug was probably created in version 6.01, but it is possible
it was there before that in another form.
Tree N6TR
tree@contesting.com
--
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
|