>>I cannot think of ANY condition where you WOULD NOT want to ground the
>>tower to the pool.
>>The goal is to keep all "grounds" at the same potential, so a strike does
>>not flow through, say your A/C wiring to get to another, better ground.
Steve,
As you may recall, I used to do electrical work and this is one of those
things I could never understand. Despite the apparent logic of tying all
grounds together, you may be better off by NOT tying the grounds together
from your tower to your pool.
The reason this is most likely true is that the NEC, National Electrical
Code, has specific requirements for pool grounding. The only thing the
writers of the NEC are interested in is safety. If you do not follow the
requirements exactly as stated in the code, you may be held liable if there
is anyone injured by a electrical shock in your pool. Likewise, if all of
your grounding is not done according to code, you may not be able to claim
any damages on your homeowner's insurance from lightning damage.
I would check with your electrician and local building code officials before
doing anything that to most of us "makes sense". Believe me, a lot of the
things in the NEC don't make sense from an engineer's or technician's point
of view.
Stay safe (and out of court) - 73,
Bob Naumann
KR2J@AOL.com
>From howie cahn <wb2cpu@world.std.com> Sat Aug 19 17:26:31 1995
From: howie cahn <wb2cpu@world.std.com> (howie cahn)
Subject: MultiTasking
Message-ID: <Pine.3.89.9508191704.B962-0100000@world.std.com>
On Fri, 18 Aug 1995 K8DO@aol.com wrote:
> I agree with the thrust of your argument... b u t..... Regardless of the
> code, threaded or not, and regardless of the brand name on the OS, the
> computer has to have a copy of each program in RAM (i.e. ya can't multitask
> on a 640K radio shack 1000)... If the OS has to resort to disk swapping of
> code it is going to be _slow_ ... So, no matter whose multitasker is used,
This isn't really true! Modern O/S's (OS/2, NT, Win 95, Unix, Mac Sys 7,
etc.) use virtual memory schemes where you can run programs much larger
than the machine's physical RAM size and without a significant performance
penalty. Of course, these operating systems won't run on a 640K machine,
so, in that sense you're right.
73... howie
wb2cpu@world.std.com
>From km9p@is.net (Bill Fisher) Sat Aug 19 22:56:56 1995
From: km9p@is.net (Bill Fisher) (Bill Fisher)
Subject: DSP power
Message-ID: <199508192156.RAA06836@mail1.is.net>
>>This is not to say it's impossible...it's not! It's being done right now,
>but not in a consumer device. I would not bet against it being in a
>competitive radio by the year 2000...
I hope they don't try to incorporate a CPU into the internal structrure of
the radio... so they can mark it up too!
The smart play for the consumer will be to design a radio that has a port,
of one sort or another, that connects the radio to the computer which does
the DSP functions. I'll take my chances on being able to buy a faster and
cheaper CPU than Yaesu, Kenwood, or Icom can put in a radio. I'll also take
my chances on smart hams to write better programs for doing the filtering.
I can just see it now... Year 2001 CQWW CW. I have 5 computers on the
desktop. 2 DSP computers, 2 logging computers, and 1 XT to run TERMINATE.
The NCJ is open and I'm reading about the latest in DSP contesting software
offered by Harvard Radio!
Can't wait!
|