The note from Scott, W5WZ might be typical of users first attempt at using
an NA network. Let me explain how NA networks work, which will answer some
of his questions, and then we'll offer some advice on how to better use it.
An NA network consists of two or more computers running NA and connected
with serial cables. When you log a QSO using an NA network, the QSO data
is passed from computer to computer. There is no confirmation that any
other computer received the data - it is simply sent out any configured
network COM port. If a computer receives the data, the QSO is added to the
log kept on that computer. If the computer is shut off, or NA is not
running, the QSO will not be received, nor will it be passed to other
computers in the chain. If the computer is later restarted, there is no
"synchonization" to re-align the logs.
To put it another way, the network is to allow the computers in the network
to share information. The QSO is always, safely, stored on the computer
that logged it. While the QSO *may* also appear in the other logs (i.e.,
the network functioned as intended), it will be handled when the logs are
merged. Barring some sort of catastrophic failure of one of the computers,
no QSOs will be lost.
BTW, this is how the CT network works as well. TRLog (which only works in
loop mode) retries sending the QSO if it does not see it return through the
loop. While this seems to be an improvement, I've heard comments from
users that it seems to cause its own headaches.
Keeping the computers in sync is only critical in contests with serial
numbers being handed out a more than one computer. One example would be
multi-single in CQ WPX, where you might have two stations (run/mult
perhaps) sharing a single set of serial numbers. Our experience has been
that two computers almost always stay in sync. With multi-multi in WPX,
serial numbers are by band so the problem does not exist unless you have
multiple computers on a single band.
If the computers wind up out of sync, the logs from each computer should be
merged to create the final log to be submitted. Before doing this, each
computer should be checked to see if a file called FILENAME.LOS is present.
This file lists any QSOs which were edited across the network but which the
original QSO could not be found. The only time this occurs is if a QSO
comes in from another computer while a particular computer is off-line, and
then later another computer tries to edit this QSO.
To address W5WZ's example, RS-232 is rated for up to 50' using typical
cable. However, this addresses only signal degradation due to cable
capacitance. In an RF environment, its another story, particularly since
its unlikely that the three stations were sharing a common ground.
Shielded cable is absolutely necessary for this application. Some guys try
to use network cable or twisted pair, but these are only of limited value
since RS-232 is a single-ended, un-balanced system.
The only other tips to keep in mind are:
- Don't shut any of the computers down. If one crashes, its no big deal
but if you want to stay synchronized, stop logging QSOs until the offender
is brought back up.
- Don't get into one of the pop-up menus are leave it there for long
periods of time. QSOs are not being logged and eventually the network
buffers will overflow. The buffers can handle approximately 40 QSOs before
this happens, so this should not be a problem unless you've shut down for
the night.
73,
Dave/K8CC
--
Submissions: na-user@contesting.com
Administrative requests: na-user-REQUEST@contesting.com
WWW: http://www.contesting.com/datom/
Questions: owner-na-user@contesting.com
|