Let me relate some experiences with TR and linking in the recent CQww. We
ran a 4 site multi single hookup for the link using a variety of computers
(DX4-100,386 SX16, 386SX33, and a486-75 laptop). We also ran packetcluster
for the first time. The serial data was monitored on a scope just to see
what went on, and if any RF etc made it onto the RS 232 cable (it didn't).
In testing before the contest, not all spots made it to all the computers,
some taking several minutes and some never showing up; but all logged
contacts and messages worked 100% and quick. Using TR SLOW to start didn't
seem to make any difference.
Changing the order of the computers by the time the contest started seemed
to help and things would work fine UNTIL the network got bogged down for
some reason. The data would be a continuous stream, instead of the short
bursts usually seen on the scope. The network broken message would come up
on some computers and many QSO's did not get passed properly. But the
system still passed many Q's and packet spots even though this message
came up. Shutting packet off would finally get the system settled back
down (after all the retries stopped, I guess). I assumed this was not a
big problem - when the logs are all merged the duplicate contacts would be
removed as an "obvious duplicate". Some were but many (300+) stayed and
were marked as dupes for 0 points, so not a real problem. But these
weren't sorted in order by time properly so some of the reporting routines
didn't like that (like the H command in the OH2MM routine). It was a
hassle for m/s because of the need to split the run and mult logs and
check for 10 minute rule situations - being out of chronological order
made the log look in violation, but when the times are checked, it wasn't
really. I could easily remove all DUPE contacts with an editor but I don't
want to - some ARE really dupes that shouldn't be removed - I just want to
remove the program generated dupes.
Keeping track of the run and mult station is best done using the computer
id and changing them to "M" or "R" I guess, but would be nice to be able
to do that from "ALT + ???" menu. We didn't try it but can two computers
use the same id on the network - we had two mult stations - and since the
id is only one letter long, using M1 or M2 wouldn't be an option. And
using a search and replace editor after the contest isn't a good option
since one letter followed by a space is not a unique situation.
More of a problem, and my main reason for asking - several calls that were
corrected in the editable window were passed around the network and showed
in the final merger as valid contacts showing both the original and
corrected calls. It's impossible to tell which one is right now. The SEND
QSO IMMED was used because it was m/s we need to know ASAP who has worked
what so we don't work a non mult on the mult station. This happened (I
believe) whether or not the link was bogged down or not, but I'm not sure
it happened on every corrected call. How does the linked network treat
these corrections, or how should it?
The band map and radio control (FT 1000mp) worked great and it certainly
was nice to send packet spots to whatever station was on that band only.
Anyway, I'm cutious to know how you other m/s ops deal with these network
situations - especially passing the correct and incorrect call thru the
system - or am I doing something wrong? By the way we used v5.85. Noticed
that we could not log D44BS - the system crashed - but I see this was
fixed in v5.86.
73 Don
VE6JY is Don Moman email: ve6jy@freenet.edmonton.ab.ca
Box 127 Lamont, Alberta
T0B 2R0 (403) 895-2925
|