Original poster: "Lau, Gary" <gary.lau@xxxxxx>
My 4/20's Rp is 3.9 Ohm, Rs is 9.0 KOhm. Single gap today is .060", I
can't be certain if it's been opened since the experiment, but I'm
certain that it did not change between measurements, and that it was
between .050" and .060".
Regards, Gary Lau
MA, USA
> -----Original Message-----
> From: Tesla list [mailto:tesla@xxxxxxxxxx]
> Sent: Thursday, December 02, 2004 10:06 AM
> To: tesla@xxxxxxxxxx
> Subject: Re: LTR cap BPS?
>
> Original poster: "Barton B. Anderson" <tesla111@xxxxxxxxxxxxx>
>
> Hi All,
>
> I'm still here, I've just been in lurk mode since March. I've been too
busy
> with real work to do any coiling or spend much time with TCML. The
last day
> I've had off at work was back in 2003.
>
> The BPS stated at 60 must be a rather large cap size or small NST
power.
> JavaTC does take into effect running at higher input voltages, but
does
> not account for inductive kick. Javatc will also account for resonant
rise
> if measured Rs and Rp are entered (there are inputs for measured NST
> values). The BPS can be above or below 120 depending on electrode size
and
> gap width, cap size, and nst specs. It is about as good as can be done
with
> calculation that I know of at this time, but of course, there are
> parameters within a gap setting which will effect your actual measured
> value. For example, heat!
>
> Because Gary showed his bps values for the various cap sizes, maybe he
> could run through Javatc and see how it faired, but seeing that it is
data
> from an old measurement, I know that gets difficult to do. Hard to do
anyway.
>
> For example, Gary's 4/20 NST run through Javatc (without actual
measured Rs
> and Rp values) showed the following "assuming 2 electrode static gap
at
> 1/4" electrode diameter" (of which I have no clue what it is). I also
have
> no clue of the effects of Gary's partially shunted 4/20. That really
throws
> things off. The only way I know about doing this is to input the NST
and
> known cap size and change gap widths until BPS is relatively close and
then
> wonder if gap width calc'd is near to the actual. From my vantage
point,
> this is impossible to do with any accuracy. It's in the hands of the
> builder to measure and test and show error. This has really not
happened as
> it should have with gaps. There are a few, but only a few (over many
years).
>
> Cap Meas. Calc. Gap
> Size BPS BPS @ Width
> ---- ------ ----- ------
> 0.012uF 297 299 0.045"
> 0.02uF 207 210 0.025"
> 0.025uF 157 154 0.021"
>
> It may be that the actual gap widths were all identical. But with the
> shunted and unmeasured Rs Rp values, who knows how it would really
play out.
>
> Although Javatc is fantastic with primary and secondary specs, I am
not as
> confident on the remaining power, rsg, or static gap sections of the
> program. Comparisons of measurements and calcs are still needed in
these
> remaining parts of the program to get that warm and fuzzy feeling.
>
> Take care all.
>
> Bart B. (in desperate need of a coiling vacation!)
>
> Tesla list wrote:
>
> >Original poster: FutureT@xxxxxxx
> >In a message dated 11/30/04 9:07:31 PM Eastern Standard Time,
> >tesla@xxxxxxxxxx writes:
> >
> >
> >>Well, my question comes from
> >>http://www.classictesla.com/java/javatc.html
> >>Seems like if I use its LTR suggestion, it states 60~ or so BPS at
any
> >>decently wide gap setting for the NST.
> >>Is this just the program screwing up and stateing 1/2 the BPS? or is
it
> >>really 60bps at those gap settings?
> >
> >
> >
> >Bart's JavaTC is very good, but I don't think I exactly agree with
> >his method of figuring the BPS, etc. I don't think JavaTC accounts
> >for the extra power that can be drawn out an NST beyond its
> >name-plate rating due to resonant or inductive kick and
> >input overvolting. This extra power permits the breakrate to
> >be higher than expected using a given cap value. Perhaps
> >Bart has updated his program, I don't know. A too-wide
> >gap will tend to reduce the breakrate of course. I do agree
> >with Gary Lau's previous comments regarding the breakrate.
> >
> >John
> >
>
>
>
>