NA-User
[Top] [All Lists]

Re: [NA-User] More Detail on WPX Issues

To: "'Robert Pack (NX5M)'" <nx5m@txcyber.com>,"'NA User'" <NA-User@contesting.com>
Subject: Re: [NA-User] More Detail on WPX Issues
From: "Bob Glasgow" <bob.gm4uyz@btinternet.com>
Date: Mon, 29 May 2006 09:02:30 +0100
List-post: <mailto:na-user@contesting.com>
Hi Robert,

We have used NA in the MULTI-MULTI setup for a good number of years and we
have seen a few of the problems shown:

1. Going to the 160M -- That is definitely RF leaking in and we have
discovered in our case that it comes via the RADIO to COMPUTER CAT cable.
Remove this cable, obviously we now loose Cat, but the problem then
disappears. It doesn't happen all the time and it really seems to depend on
how things are laid out in the shack, how the RF is getting transmitted over
the shack (i.e. aerials very close to the actual shack and then transmitting
RF in the direction across the shack)
2. Serial Numbers out of step... a well known issue and this happens because
somewhere in the loop one of the computers is being "held up" on some other
action. The input buffer for the held up PC's loop network then overflows
because of the amount of data that arrives and then when the PC gets freed
and starts to allow data to flow again, data has been lost to get passed
on...hence out of step. We can certainly bring this on easily and normally
in the circumstances below.... 1 station is running full tilt making as many
QSO's as it possibly can, so lots of data being put into the loop network to
pass down the line. The next station in the line has grabbed a serial number
and is taking a long time to complete the QSO for whatever reason,
eventually makes the complete contact then presses return to complete the
log. Due to this it is holding up the network data which is not getting
passed down the line, data is lost and serial numbers are out of step. If
this happens with us we stop all stations and do a SAVELOG on the station
with the highest serial number. Then take the floppy with the savelog on to
the 1st PC out of step. Here we have a small DOS Batch file which changes
the savelog to the contest.qdf file, puts this in the na/log area and then
reloads the contest. PC now in step. This is then done on all the out of
step PC's. Before we then go live again we make sure we can do a GAB from
all PC's in the network. Note: this last description is just a rough guide
and if anyone is interested in the full in's and out's get in touch and I
will fill you in with the information.
I think NA software has to be amended to increase the buffer sizes for the
network so that it can at least hold about 500 QSO's or there needs to be
some FLOW Control added to the loop to stop the buffer overflow. In normal
comm's on a RS232 3 wire system then XON and XOFF would be used to control
the data flow. XOFF to stop the flow of data and XOn to restart it.

Hope this helps....

Regards,
 
 
 
Bob Glasgow GM4UYZ
 
Sec: Cockenzie & Port Seton Amateur Radio Club
Email: bob.gm4uyz@btinternet.com
Website: www.cpsarc.com 
Tel: 01875 811723

-----Original Message-----
From: na-user-bounces@contesting.com [mailto:na-user-bounces@contesting.com]
On Behalf Of Robert Pack (NX5M)
Sent: 29 May 2006 04:54
To: NA User
Subject: [NA-User] More Detail on WPX Issues

Just to recap............
This weekend I had all the computers connected in a LOOP network for a
multi-multi operation in the WPX CW contest.  
The first problem was the 20m station computer locking up when the spacebar
was pressed and the call was a dupe.  The computer totally locked up.
Thought it might be a keyboard issue and it was just coincidence that it
locked up at that exact moment.  K8BB suggested turn off the "Beep on Dupe
Callsign" in ALERTS control panel.  At first I thought that might have
solved the problem but it ended up happening again.  But once the system
cratered we had no choice but to shut the computer down and restart it.
The other issue was on the 10m station where the computer would sometimes
default to 160SSB (note that all radios are interfaced with the
computer/software).  Here again we would have to restart the computer.
I made the decision to go back to 10.60 and see how things would work there.
That changed nothing so I am sure it is not a 10.61 issue.
It has been suggested that rf may have been a problem.  If there was any
stray rf in the shack it was not detected in any of the equipment.  But it
could indeed have something to do with the problems.
This was the first time to use the newly installed LOOP network hub.  The
hub is in a metal case so it is shielded very well.  The cables may be the
problem as I am afraid they are not shielded.  I did this hub install over
the last few days and just used whatever cables I had around the shack.
The system was tested a week ago when I had 3 other ops here and we were
logging practice qsos so fast that the rate meter was pegged at 999 for 15
minutes.  We could not make the system fail.  Of course we never logged any
dupes either so I do not know what to think about the dupe issue I mentioned
above.
IF there was RF involved........why would the computer lock up every time a
dupe call was entered and after the spacebar was pressed......CRASH.  I'd
also like to mention that it also locked up a few times when a GAB message
was sent across the network......right at the instant the gab message was
displayed......CRASH.
Of course at the end of the contest none of the computers were showing the
same numbers (expected).
When the logs were merged I found that something was seriously wrong.  
I am going to skip all the stuff I did in between the final solution but
what I found was that there was a qso on the first line of the logging
screen.....above where our first actual qso was logged.
It looked like this:
   nr    band     time    call     rst    nr    mult
   0      40cw   .....              599           /////
QSO number zero, no time shown, no call and no number shown.  How did this
line end up in the log?
It corrupted the whole log until I finally figured out a way to remove it.
Going back into NA I was able to enter a call in the blank space and then
use the utility function (NAU/Remove a QSO) to get it out.  Once that was
done I was able to merge the qdf files from each computer to come up with
what I think is a valid qdf file that seems to be as close to accurate as I
can expect.

So what do you guys think?  It is hard to resolve what one cannot see.

Bob NX5M

_______________________________________________
NA-User mailing list
NA-User@contesting.com
http://lists.contesting.com/mailman/listinfo/na-user
NA on the web:  http://www.datomonline.com/

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.3/350 - Release Date: 28/05/2006
 

_______________________________________________
NA-User mailing list
NA-User@contesting.com
http://lists.contesting.com/mailman/listinfo/na-user
NA on the web:  http://www.datomonline.com/
<Prev in Thread] Current Thread [Next in Thread>