Prefered resistor range

[Larry Brasfield]

This script doesn't work as advertised using perl under cygwin (suprise). What version of perl is it targeted towards? If you send
me some sample output, I'll take a look. It's probably something simple.

Thanks for the report and offer. While I mentioned
the ActiveState distro, I am actually using the cygwin
version here. To wit (with extranea cut):

set | findstr .pl= .pl=perl
perl -v

This is perl, v5.8.6 built for cygwin-thread-multi-64int

What version are you using? I will be happy to find
and fix the problem if I can replicate it (or if you want
to send me its blurp via email). And if your difficulty
reflects a shortcoming in the admittedly sparse "help",
I will be more than happy to fix that. I wrote that
script for my own purposes, so it probably has plenty
of room for improvement in a wider context.

Here is a simple session that "should" replicate, with a newline
inserted after certain commas for legibility and the prompt reduced:
=========== begin near screen scrape ===============

perl \bin\stdvals.pl

Usage:
stdvals tolerance
or
stdvals tolerance value [2a|2p|2r]
or
stdvals -n decsplit
Standard tolerances are: 1% 10% 20% 5% 50%
Standard decade splits are: 12 24 3 6 96

perl \bin\stdvals.pl 5% 588p 2a

Approximate 5.88e-10 with (5.6e-10 + 2.7e-11),
yielding 5.87e-10 (ratio = 1.0017)

perl \bin\stdvals.pl 1% 63.54k 2p

Approximate 63540 as 1(1/66500 + 1/1.43e+06),
yielding 63544.9 (ratio = 1.0001)

perl \bin\stdvals.pl 1% 63.54k 63400
perl \bin\stdvals.pl 10%

1.0 1.2 1.5 1.8 2.2 2.7 3.3 3.9 4.7 5.6 6.8 8.2

perl \bin\stdvals.pl -n 96

Standard 1% values:
1.00 1.02 1.05 1.07 1.10 1.13 1.15 1.18 1.21 1.24 1.27 1.30
1.33 1.37 1.40 1.43 1.47 1.50 1.54 1.58 1.62 1.65 1.69 1.74
1.78 1.82 1.87 1.91 1.96 2.00 2.05 2.10 2.15 2.21 2.26 2.32
2.37 2.43 2.49 2.55 2.61 2.67 2.74 2.80 2.87 2.94 3.01 3.09
3.16 3.24 3.32 3.40 3.48 3.57 3.65 3.74 3.83 3.92 4.02 4.12
4.22 4.32 4.42 4.53 4.64 4.75 4.87 4.99 5.11 5.23 5.36 5.49
5.62 5.76 5.90 6.04 6.19 6.34 6.49 6.65 6.81 6.98 7.15 7.32
7.50 7.68 7.87 8.06 8.25 8.45 8.66 8.87 9.09 9.31 9.53 9.76

perl \bin\stdvals.pl -n 6

Standard 20% values:
1.0 1.5 2.2 3.3 4.7 6.8

=========== end near screen scrape ===============

 

[Robert Monsen]

This script doesn't work as advertised using perl under cygwin (suprise). What version of perl is it targeted towards? If you send
me some sample output, I'll take a look. It's probably something simple.

Thanks for the report and offer. While I mentioned
the ActiveState distro, I am actually using the cygwin
version here. To wit (with extranea cut):

set | findstr .pl= .pl=perl
perl -v

This is perl, v5.8.6 built for cygwin-thread-multi-64int

What version are you using? I will be happy to find
and fix the problem if I can replicate it (or if you want
to send me its blurp via email). And if your difficulty
reflects a shortcoming in the admittedly sparse "help",
I will be more than happy to fix that. I wrote that
script for my own purposes, so it probably has plenty
of room for improvement in a wider context.

Here is a simple session that "should" replicate, with a newline
inserted after certain commas for legibility and the prompt reduced:
=========== begin near screen scrape ===============

perl \bin\stdvals.pl

Usage:
stdvals tolerance
or
stdvals tolerance value [2a|2p|2r]
or
stdvals -n decsplit
Standard tolerances are: 1% 10% 20% 5% 50%
Standard decade splits are: 12 24 3 6 96

perl \bin\stdvals.pl 5% 588p 2a

Approximate 5.88e-10 with (5.6e-10 + 2.7e-11),
yielding 5.87e-10 (ratio = 1.0017)

perl \bin\stdvals.pl 1% 63.54k 2p

Approximate 63540 as 1(1/66500 + 1/1.43e+06),
yielding 63544.9 (ratio = 1.0001)

perl \bin\stdvals.pl 1% 63.54k
63400

perl \bin\stdvals.pl 10%

1.0 1.2 1.5 1.8 2.2 2.7 3.3 3.9 4.7 5.6 6.8 8.2

perl \bin\stdvals.pl -n 96

Standard 1% values:
1.00 1.02 1.05 1.07 1.10 1.13 1.15 1.18 1.21 1.24 1.27 1.30
1.33 1.37 1.40 1.43 1.47 1.50 1.54 1.58 1.62 1.65 1.69 1.74
1.78 1.82 1.87 1.91 1.96 2.00 2.05 2.10 2.15 2.21 2.26 2.32
2.37 2.43 2.49 2.55 2.61 2.67 2.74 2.80 2.87 2.94 3.01 3.09
3.16 3.24 3.32 3.40 3.48 3.57 3.65 3.74 3.83 3.92 4.02 4.12
4.22 4.32 4.42 4.53 4.64 4.75 4.87 4.99 5.11 5.23 5.36 5.49
5.62 5.76 5.90 6.04 6.19 6.34 6.49 6.65 6.81 6.98 7.15 7.32
7.50 7.68 7.87 8.06 8.25 8.45 8.66 8.87 9.09 9.31 9.53 9.76

perl \bin\stdvals.pl -n 6

Standard 20% values:
1.0 1.5 2.2 3.3 4.7 6.8

=========== end near screen scrape ===============

I'm using 5.8.5. However, I figured it out. You keep typing '1%' in your
examples. The program, however, seems to want '1' as opposed to '1%',
and adds on the % internally. If you type in the percent sign, it fails,
and prints the usage.

I wonder if you posted a version of the script that is a different
version than the one you are running?

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

 

[Larry Brasfield]

news:[email protected]...

[sniiiip]
I'm using 5.8.5. However, I figured it out. You keep typing '1%' in your examples. The program, however, seems to want '1' as
opposed to '1%', and adds on the % internally. If you type in the percent sign, it fails, and prints the usage.

That is because the shell you are using has been
swallowed something. Usage is blurted for any
unrecognized arguments.

I wonder if you posted a version of the script that is a different version than the one you are running?

Not a bad supposition. The problem is that I am
using a command-line shell (4NT) that is nowhere
near as brain-dead as the cmd.exe that ships with
Windows. I think, given that most people on that
platform put up with that shell, (which I remember
mainly like bad dream), I'll revise my script to not
use the '%' at all and repost. It was a PITA to type
anyway. I'm reviewing the help for sufficiency and
adding a few comments so nobody thinks I am a
complete bozo, (at least not for that reason! ;-)

If anybody ever sees a comprehensive, complete
and accurate explanation of the quoting rules for
that miserable shell, I would like to see them.

 

[The Phantom]

G'Day All,
I seem to have lost the formula that calculates the 1% 'preferred' range of
resitors.
Can anyone help out please ??

I posted a general solution to this problem last fall. What's neat
about this routine is that, unlike a straight root-of-10 solution, it
actually returns the correct standard values for 20%, 10%, and 5%
ranges.

" Quite a few years ago, more than 20, somebody published the
following little Basic routine in one of the free magazines. I have
lost the original article and cannot give proper credit. This routine
accepts a resistor value that perhaps came from an exact calculation,
and a tolerance, and returns the nearest standard value from that
tolerance range.

10 INPUT "R, TOLERANCE? ";R,T
20 Z4=.0119926*INT(1+1.5*T+.004*T^2)
30 Z3=INT(LOG10(R)-INT(2.2-3*Z4))
40 R=R/(10^Z3)
50 FOR I=1 TO 2
60 Z(I)=INT(EXP(Z4*(INT(LN(R)/Z4)+I-1))+.5)
70 Z5=.0000188*Z(I)^3-.00335*Z(I)^2+.164*Z(I)-1.284
80 Z(I)=Z(I)+INT(Z5*INT(3*Z4+.8))
90 IF Z(I)=919 THEN Z(I)=920
100 NEXT I
110 R=10^Z3*Z(INT(R/SQR(Z(1)*Z(2)))+.5)
120 PRINT R

Notice that both LOG10 and LN are used. Some Basic's may not have
both. Make the appropriate changes.

Line 90 is there to correct a peculiarity of the E192 series of
resistor values. It seems that when the original series was created,
a slight rounding error occurred. The expression for the 186th value
in the series would be 10^(185/192) which gives 9.19478686, which
rounded to 3 digits would give 9.19; but the official value is 9.20.
Since the routine above would give the mathematically correct value
which would not be a standard part, line 90 is needed.

This routines works for 20%, 10%, 5%, 2%, 1%, .5%, .25%, and .1%
resistor series. "

 

[Terry Given]

I can appreciate the humor here, abstractly.
But after designing the Nth precision active filter,
countless dividers, and other precise circuits, I
got tired of table lookups. To lookup just one
value is not overly hard, just tedious. You start
with what you want, look at the table, and do a
little simple arithmetic (often by eye) to decide
which value is closest. Maybe you adjust that
choice according to which way it went for some
nearby resistor(s).

Now, if I want a 63.54k resistor, I enter:
stdvals 1% 63.54k
and get back 63400. This saves just a little time,
so I cannot argue any clear superiority there.

Here is where an algorithmic approach really pays.
I really want something closer, and I am willing to
parallel two parts to get it. I enter:
stdvals 1% 63.54k 2p
and quickly get a useful result:
Approximate 63540 as 1(1/66500 + 1/1.43e+06),
yielding 63544.9 (ratio = 1.0001)
This saves some real time. (I can remember when,
during my stint as an engineering tech, I was given
the task of doing approximately this same search
for a short list of resistors. If not for the aid of an
HP-35, it would have taken days, not the hours I
had to spend on it.)

A common task in active RC filter design is to
come up with capacitor pairs that deliver a close
approximation to the values you really want. Ask:
stdvals 5% 588p 2a
and ye shall receive:
Approximate 5.88e-10 with (5.6e-10 + 2.7e-11),
yielding 5.87e-10 (ratio = 1.0017)

Any of you who have done this by hand know
the lingering doubt that remains when you have
not used an exhaustive search to find whatever
answer you settled upon. Or you know just
how tedious the exhaustive search is. Or both.

I guess the natural extension of Rich's joke is:
Who needs calculators or computers? I've
got tables of values and logarithms, a slide rule,
and my trusty pencil and pad. Valves forever!

I do this with Brute Force (ie matlab). I have a simple s-file that
takes an array of available values, which may or may not be entire
ranges - smt design optimisation usually involves minimising the number
of different parts.

Then I calculate every possible 1,2,3,4 resistor combination, using:

1 resistor
2 series
2 parallel
1 paralleled with (2 series)
2 paralleled with (2 series)

and for each of the 5 cases sort the result in order of increasing error

I specify a required accuracy, then throw away all results which are worse.

then display the first 10 entries in each of the 5 combinations.

Yeah, it makes HAL9000 do a *lot* of calculations, but so what - it
results in a barely perceptible delay between hitting <enter> and
getting the answers.

Cheers
Terry

 

[Rich Grise]

Now that you have the answer to your first question, don't you want to
know why the 10% and 5% standard values don't result from a simple
root-of-10 formula?

Of course. Why is that?

Thanks,
Rich

 

[Rich Grise]

When I evaluate 1.024^96, I get 9.7453 on my HP32S. (And
this agrees with another calculator I checked.) For the E96 series
starting with 1, the 96th and last member is 9.76. So your method
requires one more step (times 1.024) to reach the next decade. It
produces 97 values per decade, (assuming we round off to 3 digits
at each closest approach to whole powers of 10), whereas all the
tables I've seen have only 96 values per decade.

This is called "The Fence Post Effect". There are 97 values, if you
count both ends. There are 96 _steps_. The first of the 97 is the
zeroth step.

i.e. you have a 100 foot border, and want to put up a straight
fence along that border, with a post every 10 feet. How many
fenceposts do you need to buy?

Cheers!
Rich

 

[Fred Bloggs]

Can you reconsider that assertion? I cannot make sense of it, being
stuck in the following thought pattern: If there are 96 distinct
values per decade, then for each 96 value steps, a whole power of ten
is traversed. Expressed mathematically, (and ignoring the rounding
necessary to get standard values), the E96 set can be obtained as
10^(N * log10(10) / 96) == 10^(N/96) for the 96 integer values of N
from 0 to 95. This corresponds to a multiplicative interval equal to
the 96th root of 10, not the 97 root.

Nice guess, wimp- but entirely wrong.

In addition to the problem outlined above, what you say is contrary
to the algorithm that I successfully applied to devise the program I
posted earlier on this thread.

You call that kluge an algorithm- it's slightly less than a table.

I tested that quite a bit, so I am quite sure that the decade should
be split logarithmically into 96 equal steps (sans rounding). In my
testing, I compared results with the table published by several
resistor manufacturers.

I seriously doubt your competence at testing too. What a worthless fool
you are.

 

[Fred Bloggs]

I can appreciate the humor here, abstractly.
But after designing the Nth precision active filter,
countless dividers, and other precise circuits, I
got tired of table lookups. To lookup just one
value is not overly hard, just tedious. You start
with what you want, look at the table, and do a
little simple arithmetic (often by eye) to decide
which value is closest. Maybe you adjust that
choice according to which way it went for some
nearby resistor(s).

What a crock of manure- good for nothing little pretentious nobody.

Now, if I want a 63.54k resistor, I enter:
stdvals 1% 63.54k
and get back 63400. This saves just a little time,
so I cannot argue any clear superiority there.

Here is where an algorithmic approach really pays.
I really want something closer, and I am willing to
parallel two parts to get it. I enter:
stdvals 1% 63.54k 2p
and quickly get a useful result:
Approximate 63540 as 1(1/66500 + 1/1.43e+06),
yielding 63544.9 (ratio = 1.0001)

Ooh my- well we have been down that road before and that is NOT how you
reasonably calculate a parallel combination. The idea that a fraud like
you should assume to teach us anything is a goddammed joke.

[...snip a bunch of worthless, unusable, pseudo-pedant bs...]

 

[Rich Grise]

I guess the natural extension of Rich's joke is:
Who needs calculators or computers? I've
got tables of values and logarithms, a slide rule,
and my trusty pencil and pad. Valves forever!

What joke? If I need a resistor value, I look it up. I might write a
program just for the fun of it, but if I did, it'd probably have a
look-up table.

Input T // Target value
scale(T) // multiply/divide as needed until 1 <= T < 10
for (i = 0, i < 97, i++) {
if (T > V) continue; // V[96] == table of values
}
if (i == 97) {
output V; // in case you fall off the end
}
else {
if ((T - V) > (V[i+1] - T) {
output V[i+1];
}
else {
output V;
}
}

Cheers!
Rich

 

[Rich Grise]

....
If you need 63.54K and you have the complete range of 1% tolerance resistors
available you have a problem that no elementary, or sophistacated,
calculator is going to solve

I bet you could get within .1% by finding two to put in parallel - here's
a case where a lookup table would really do the trick! Give it a target,
and a delta, and it'll give you a list of series and/or parallel
combinations of two and a list of what's in range with its delta.

Of course, the overall tolerance will be probably not quite 1%, but
you can get arbitrarily precise with the nominal value. ;-P

Cheers!
Rich

 

[Rich Grise]

You appear to have assumed that the resistors
to be used would be 1% tolerance. It happens
that the 0.1% tolerance parts come in the same
values, (or more, for more money), so there is a
use for calculations such as the above example.

Or, you can get some carbon composition resistors, a triangular file,
and some fingernail polish, and zero it in to the dead nuts. ;-p

Cheers!
Rich

 

[Michael A. Terrell]

This is called "The Fence Post Effect". There are 97 values, if you
count both ends. There are 96 _steps_. The first of the 97 is the
zeroth step.

i.e. you have a 100 foot border, and want to put up a straight
fence along that border, with a post every 10 feet. How many
fenceposts do you need to buy?

Cheers!
Rich

Nine fence posts and two corner posts. I guess you've never put up a
chain link fence before.

 

[Larry Brasfield]

Larry Brasfield wrote:

[Cut worthless spew and off-point material.]

Ooh my- well we have been down that road before and that is NOT how you reasonably calculate a parallel combination.

Ok, Mr. superior resistor calculator. Take the
above example and find a pair that more closely
achieves the specified result. If you cannot do
that, define "reasonably calculate" such that your
method beats a few seconds of typing.

[Cut more worthless spew.]

 

[Larry Brasfield]

Nice guess, wimp- but entirely wrong.

Entirely right. What do you have besides bare assertion
and invective to make your case? Nothing I'll wager.

You call that kluge an algorithm- it's slightly less than a table.

Tables are used only for certain limited arbitrary data
and to correct for those few results that do not agree
with the publish tables when computed algorithmically.

Your inability to discern an algorithmic approach when
it is there in plain sight marks you as the pretender with
respect to claims of intellectual power.

I seriously doubt your competence at testing too. What a worthless fool
you are.

Fred, I wish you could comprehend how disappointed I
would be if you liked me or respected me or my work.

 

[Robert Monsen]

news:[email protected]...

[sniiiip]

I'm using 5.8.5. However, I figured it out. You keep typing '1%' in your examples. The program, however, seems to want '1' as
opposed to '1%', and adds on the % internally. If you type in the percent sign, it fails, and prints the usage.

That is because the shell you are using has been
swallowed something. Usage is blurted for any
unrecognized arguments.

I wonder if you posted a version of the script that is a different version than the one you are running?

Not a bad supposition. The problem is that I am
using a command-line shell (4NT) that is nowhere
near as brain-dead as the cmd.exe that ships with
Windows. I think, given that most people on that
platform put up with that shell, (which I remember
mainly like bad dream), I'll revise my script to not
use the '%' at all and repost. It was a PITA to type
anyway. I'm reviewing the help for sufficiency and
adding a few comments so nobody thinks I am a
complete bozo, (at least not for that reason! ;-)

If anybody ever sees a comprehensive, complete
and accurate explanation of the quoting rules for
that miserable shell, I would like to see them.

I'm using bash on cygwin. I used the perl debugger to dig into your
code, which simply doesn't want the %. When it gets it, it fails. Look
at it again.

On line 83, $pick is the argument. You check for $pick to be a number.
If it is, you append a % to it, and use it to set $tolerance using the
stdtols hash. Otherwise, you go on to check for it being -n. Othewise,
you print usage and bail.

I'm guessing that it's YOUR shell that's swallowing the %...; % is used
as an environment variable introduction in windows. Windows is probably
just tossing it. Try it with the perl debugger "perl -d stdvals 1%", and
then look at the value $pick gets set to by the shift, or just 'p @ARGV'.

Insert this snippet before line 83 to fix it:if ($pick =~ m/^\d+%$/) {
if ($decsplit = $stdtols{$pick}) {
$tolerance = $pick;
}
else {
die $usage;
}
}
else
<<<
===

Christ I hate perl. What a monstrosity. I'd learn javascript if I were
you. Much easier to write, and you can put these kinds of things up on
the web and the computations all run on the user's machine. Here is a
simple example I hacked up that picks resistors for a divider from
standard values:

http://home.comcast.net/~rcmonsen/resistors.html

To view the source, open http://home.comcast.net/~rcmonsen/rv.html
and show source. Frames doesn't let you have the content and frames in
the same file, and the thing works by rewriting frame data.

BTW, the windows XP help area has a fairly extensive section on the cmd
program input syntax, environment variables, etc.

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

 

[Larry Brasfield]

[Regarding finding accurate resistor combinations]

I do this with Brute Force (ie matlab). I have a simple s-file that takes an array of available values, which may or may not be
entire ranges - smt design optimisation usually involves minimising the number of different parts.

Then I calculate every possible 1,2,3,4 resistor combination, using:

1 resistor
2 series
2 parallel
1 paralleled with (2 series)
2 paralleled with (2 series)

and for each of the 5 cases sort the result in order of increasing error

I specify a required accuracy, then throw away all results which are worse.

then display the first 10 entries in each of the 5 combinations.

Yeah, it makes HAL9000 do a *lot* of calculations, but so what - it results in a barely perceptible delay between hitting <enter>
and getting the answers.

What I did is almost brute force, in that it tries
a number of combinations. But because of the
algorithmic derivation of available value from
desired value, it is much less brutish than the
approach you outline. That said, I would not
be the one to criticize the approach merely
for using more likely spare cycles. Wetware
cycles are becoming the scarcer resource
these days, (excepting, naturally, the most
brilliant among us, whoever they are.)

If you are willing to share that code, I would
like to see it (via email).

 

[Larry Brasfield]

....
I'm using bash on cygwin. I used the perl debugger to dig into your code, which simply doesn't want the %. When it gets it, it
fails. Look at it again.

You are entirely correct, to my great surprise. (This
is the first time I can remember when 4NT has been
found to do something less sensible than cmd.exe.)

On line 83, $pick is the argument. You check for $pick to be a number. If it is, you append a % to it, and use it to set
$tolerance using the stdtols hash. Otherwise, you go on to check for it being -n. Othewise, you print usage and bail.

That code would be fixed per your later suggestion
if not for having been recently eliminated in favor of
a (usually) simpler invocation.

I'm guessing that it's YOUR shell that's swallowing the %...; % is used as an environment variable introduction in windows.

Yes, (again).

Windows is probably just tossing it.

The OS does virtually nothing to command lines
in the way of parsing, quoting, etc. There may
be an Ascii/Unicode translation, but that's it.

Try it with the perl debugger "perl -d stdvals 1%", and then look at the value $pick gets set to by the shift, or just 'p @ARGV'.

Echoing @ARGV reveals the issue clearly.

Insert this snippet before line 83 to fix it:
if ($pick =~ m/^\d+%$/) {
if ($decsplit = $stdtols{$pick}) {
$tolerance = $pick;
}
else {
die $usage;
}
}
else
<<<

Thanks, Robert. That does fix the older version I
had before I was prompted to simplify the invocation
and sidestep the '%' eating problem.

Christ I hate perl. What a monstrosity. I'd learn javascript if I were you. Much easier to write, and you can put these kinds of
things up on the web and the computations all run on the user's machine.

Javascript is nice, but for any given job, it tends to
take more code volume, although the result is more
comprehensible to those who do not live and breath
Perl. It can be used as a write-only language.

Here is a simple example I hacked up that picks resistors for a divider from standard values:

http://home.comcast.net/~rcmonsen/resistors.html

To view the source, open http://home.comcast.net/~rcmonsen/rv.html
and show source. Frames doesn't let you have the content and frames in the same file, and the thing works by rewriting frame data.

Thanks. I've pulled it down and looked at it.
I'm not up on browser/HTML conventions or
coding, so some of that is greek to me.

BTW, the windows XP help area has a fairly extensive section on the cmd program input syntax, environment variables, etc.

Yes, it does. But the poor program is so hacked
that documenting it is a loser's game. For laughs,
you should see the endless efforts of the 4NT
authors to make a reasonably compatible shell.
One undocumented quirk after another trickles in.

 

[The Phantom]

Of course. Why is that?

I don't know; I was hoping you would.

Seriously, though, I have never seen an explanation I would consider
truly authoritative. But some years the question came up in the
British magazine, Wireless World, and I believe that "Cathode Ray"
said that slight perturbations were made so that the color
combinations on the resistor body would be more distinguishable.
Perhaps John Woodgate can help us out here.

 

[The Phantom]

Entirely right. What do you have besides bare assertion
and invective to make your case? Nothing I'll wager.


Tables are used only for certain limited arbitrary data
and to correct for those few results that do not agree
with the publish tables when computed algorithmically

Have a look at the little Basic routine I posted. Whoever
originally wrote it did a good job of curve fitting and came up with a
formula (algorithm?) that properly calculates those oddball values
that a simple root-of-10 method doesn't get right. Thus you don't
need any tables.