Lots of good points passed along from several people.
Still, it seemed odd that the 20m station computer would lock up when a dupe
call was entered......that was the only time it would ever happen. RF
problem seems logical to me on the 10m station but if it were rf on the 20m
station I just cannot understand why the lockup only happened on dupes and
at no other time.
However, after finally getting a chance to get back into the shack five days
after the contest I started up the entire computer system with radios turned
on. The only thing missing was rf. I entered several dupe calls on the 20m
station and it could not duplicate the problem. Having done this I have no
choice but to believe it was an rf problem..........but it is still quite
confusing that only dupes (during the contest) were the exact point at which
the lock-up would happen. Coincidence? If so, at least 20 of them.
The network cable runs are indeed laid out differently than they were when I
was running a link. Basically they are in bundles from each computer to the
central hub. Perhaps I need to get some really good shielded serial cables
and use them. Maybe the shielding is not good enough in what I used.
If rf was the problem on the CAT cable on the 10m station.........I guess I
need to put some beads on the CAT cable and see if that helps. The 10m
station has never had this problem before which in a way leads me to believe
that it might not be via the CAT cable. Again, the ONLY thing that has
changed is changing from a LINK network to a LOOP network.
The qso rates were not blistering but everyone knows the number of packet
spots that were coming in and in my setup it is sent down via the internet
computer to each computer in the network (each station getting spots only
for the band they are on). That is a lot of data being transferred.
I suppose at this point my only course of action would be to replace all of
the network cables with something that is seriously shielded and also put
some beads on the CAT cables (might as well do it on all 5 stations).
If the problem does not go away I am not sure what I should do next.
Just FYI, all of the antennas are well away from the shack. The nearest
antenna is 130 feet from the shack (20m). 10m tower is 180 feet away, 15m
tower is 225 feet away, main 20m tower is 325 feet away and the 40m tower is
300 feet away.
Thanks for all of the suggestions.
Guess I will give it another run in IARU and see if I made any progress.
73,
Bob NX5M
----- Original Message -----
From: "Bob Glasgow" <bob.gm4uyz@btinternet.com>
To: "'Robert Pack (NX5M)'" <nx5m@txcyber.com>; "'NA User'"
<NA-User@contesting.com>
Sent: Monday, May 29, 2006 3:02 AM
Subject: RE: [NA-User] More Detail on WPX Issues
> 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/
|