Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Some of the E24 values are wrong!

Status
Not open for further replies.

Hero999

Banned
I've being trying to write a program that calculates the nearest set of parallel or series resistors to a specified value.

One thing that's made it more difficult is that the some E24 values deviate from the geometric sequence.

Correct rounded geometric sequance:
10
11
12
13
15
16
18
20
22
24
26
29
32
35
38
42
46

51
56
62
68
75
83
91

E24 values
10
11
12
13
15
16
18
20
22
24
27
30
33
36
39
43
47

51
62
68
75
82
91

Why couldn't they have just stuck to the rounded geometric sequence?

The E192 values also differs too but it's not too bad, 920 instead of 919. I don't know why it's not like they're rounding to the nearest decade when they have 301.:mad:

I don't suppose anyone cares, just letting off steam.
 
Probably so they could still use some of the E12 values. Imagine how many 2.7k and 330 ohm resistors are out there!
 
Even if it's an extension of the E12 series, it's still wrong because the E12 series was wrong: 27, 33, 39, 47, 82 are all wrong.

It does make a difference for the program: the formula [latex]R(i,b) = 10^{\frac{i}{b}}[/latex] generates incorrect values.

The first part of the program just gets the nearest E24 value, it works but because of the errors, I've had to fiddle it so it generates the right values.
 
It does make a difference for the program: the formula [latex]R(i,b) = 10^{\frac{i}{b}}[/latex] generates incorrect values.

Why on earth would you be using some weird formula? - use a lookup table for exact values - it's only 24 entries!.

I think I mentioned before, years back (pre-Windows) I wrote a program for parallel resistors. Just give it a value, and it displayed the most accurate results using two resistors in parallel - plus the percentage of error for each combination.

Unfortunately it was on a long defunkt DOS 386 laptop, but it wasn't a very long program, and was written in Turbo Pascal.
 
Last edited:
It's not just E24 values I'm doing it for the E192 values too. In the end I want to make it so you can choose between E3, E6, E12, E24, E48, E96 and E192 values.

There's nothing weird about that formula, it's just a standard geometric sequence, i is the index and b is the base. For example to calculate the 21th E48 value R = 10^(21/48) = 2.74.

To get the index from the value, transpose the formula. i = 48*log10(2.74) = 21.

If the value is not an exact E value then all we need to do is round the result to the nearest integer and it gives the index of nearest E value.

i = 48*log10(2.7) = 20.7 = 21.

I am using look up tables. The formula creates all the values and the above transposition of the formula indexes the tables. I could have used a search to find the value but that would probably have proven slow on the E192 values.

First the arrays are filled with E24 and E192 values and which are fiddled so they equal the standard EA values.

The program requests the desired value from the user.

The transposition of the origional formula is used to index the array to get the nearest value.

This is compared with the mantissa, if it's too big the next smallest value is used, if it's too bit the next largest value is used.

I'm using old QBasic because it's the only language I know. You can still download it from the MS website and there's an open-source clone FreeBasic which is 95% QB compatible.

Here's the program:
Code:
DEFINT A-Z ' Set default variable type to integer.
DIM SHARED values(1 TO 216)' An array for the E24 values and E192 values.
DIM SHARED lgb10 AS DOUBLE ' Define log10 so we don't have to recalculate it.
lgb10 = LOG(10)
 
CLS
 
FOR n = 1 TO 24 ' Calculate the E24 values.
 values(n) = 10 ^ (1 + n / 24)
 IF n >= 10 AND n <= 16 THEN values(n) = values(n) + 1 'Fiddle to fit E24
 values(n) = values(n) * 10
NEXT
values(22) = 820' Fiddle to fit E24
 
FOR n = 1 TO 192
 values(n + 24) = 10 ^ (2 + n / 192)
NEXT
values(209) = 920' Fiddle to fit E192
 
FOR n = 1 TO 24
 PRINT values(n)
NEXT
 
INPUT "Enter value"; value#
 
lgval# = LOG(value#) / lgb10' Take log10 of the value.
 
ex = INT(lgval#)' Exponent is the integer part of log 10 of the value.
 
dec#= lgval# - ex' store the decimal part of log10.
 
el = dec#* 24' Work out the nearest preferred number.
 
mnt = 10 ^ (2 + dec#)' get the mantissa.
 
ex = ex - 2' Preferred numbers in the array are multiplied by 100 so /100.
 
IF el = 0 THEN ' If zero, wrap round to highest value and /10 to compensate.
 ex = ex - 1
 el = 24
 mnt = mnt * 10
END IF
 

' A fiddle to align the result to the preferred number.
dif = values(el) - mnt' The difference between the ideal and preferred value.
IF el > 1 THEN IF dif > mnt - values(el - 1) THEN el = el - 1
IF el < 24 THEN IF dif < mnt - values(el + 1) THEN el = el + 1
 
PRINT "Index"; el
PRINT "Mantissa"; mnt
PRINT "Exponent:"; ex
PRINT "Nearest E24 Value"; values(el) * 10 ^ ex
Just for referance, here's a program which finds the nearest E96 value. E96 values are just a standard geometric sequance so no silly tweaking or look-up tables are required. Look at how much simpler the program is. I could have done it all in one line if I'd wanted to.

Code:
DIM lg10 AS DOUBLE
DEFINT A-Z

lg10 = LOG(10)
INPUT "Enter value"; r#

lg10r# = LOG(r#) / lg10

ex = INT(lg10r#)

PRINT ex

E96 = CINT(10 ^ (2 + CINT(96 * LOG(10 ^ (lg10r# - ex)) / lg10) / 96)) * 10 ^ (ex - 2)
PRINT E96
For those who don't know QBasic.

CINT rounds the number to an integer, i.e CINT(9.6) = 10 and INT converts the number an integer simply by removing all the decimal places, i.e INT(9.6) = 9.

When a interger variable is set to a floating point value, it's just rounded to the nearest integer.

LOG is the natural logarithm, there's no way to to Log to the base x in QB, you have to do LOG(n)/LOG(b).
 
Last edited:
I am using look up tables. The formula creates all the values and the above transposition of the formula indexes the tables. I could have used a search to find the value but that would probably have proven slow on the E192 values.

Tables are incredibly fast, FAR faster than any maths you might be doing, I don't see any reason for a formula at all, which as you say, doesn't work anyway.
 
Why create the tables on the fly? Are you that short on eeprom or data flash space?
 
Woah... I missed that he was doing this on a PC :p just kind of went in one eye and out the other :rolleyes: typical for me.

Yeah, no point in using a calculation when you can just drop in a static table for something like that.
 
Last edited:
With QBasic you might put entire look-up tables in data lines to read on request.

Still faster than Turbo-Pascal.

Boncuk
 
With QBasic you might put entire look-up tables in data lines to read on request.

Still faster than Turbo-Pascal.

So you think interpreted QBasic is faster that compiled Turbo Pascal :p

You've obviously never used Turbo Pascal, it compiles blindingly fast, and runs blindingly fast.

The Borland Turbo range of compilers were named that for good reason, incredible speed from them, particularly the Pascal version.
 
Will Qbasic programs even run on windows?
 
Last edited:
Will Qbasic programs even run on windows?

Same applies to Turbo Pascal, both are DOS only - but may run in a DOS window. Anything compiled with Turbo Pascal may also need the EXE file patching, if it uses the delay() function - as faster processors mean the original code isn't capable of working, the delay loops exceed their maximum capacity - same for all the Borland Turbo series.

But you can download a simple patch program, that rewrites the EXE file.
 
So you think interpreted QBasic is faster that compiled Turbo Pascal :p

Sorry Sir, I don't think it. I know it.

We made a speed test simply using a stop watch for the same math problem to be executed using Turbo Pascal and QBasic.

There were some complicated formulas involved to calculate a certain retirement payment for a certain time and how many years someone would have to save a certain amount of money in monthly deposits to have the money "consumed" after the time period calculated for.

QBasic was the winner - almost double speed.
 
Boncuk, what does that have to do with a table lookup?
 
Sorry Sir, I don't think it. I know it.

We made a speed test simply using a stop watch for the same math problem to be executed using Turbo Pascal and QBasic.

There were some complicated formulas involved to calculate a certain retirement payment for a certain time and how many years someone would have to save a certain amount of money in monthly deposits to have the money "consumed" after the time period calculated for.

QBasic was the winner - almost double speed.

Sorry, but I don't believe you - an interpreted BASIC doesn't run faster than a compiled language (it runs MUCH slower).

Are you perhaps referring to QuickBasic rather than QBasic?, as QuickBasic is a compiler.

As for potential speed differences, I would suggest it depends entirely on how the two programmes were written - particularly if you were doing complicated maths with them.
 
Boncuk, what does that have to do with a table lookup?

Sceadwian, nothing, it was just a respond to Nigel's post.

Nigel, it was QBasic I mentioned.

What is the speed difference when executing an interpreter based program and a compiled program with two lousy numbers out of a limited selection? :)

Hans
 
Last edited:
Boncuk you're not serious are you? Use a basic stamp interpreted from eeprom (pic based) and the SAME pic with the SAME effective program in flash. The PIC will beat the stamp 4 to one or better, probably much more.
 
Boncuk you're not serious are you? Use a basic stamp interpreted from eeprom (pic based) and the SAME pic with the SAME effective program in flash. The PIC will beat the stamp 4 to one or better, probably much more.

It depends on the amount of instructions which have to be executed. Every keyword has to pass the interpreter using any kind of Basic. The more keywords are used the slower will be program execution.

I once built an air data computer (for air movement purposes) using a Z80 MCU. I burnt the entire Basic software including the interpreter into an EPROM and still had to make delay loops since the results on the display changed too rapidly (dealing with 1/10 Pascals of air pressure).

Of course will machine language software run faster than any high language.

I used Locomotive Basic (Amstrad) to calculate all possible combinations of parallel resistors for a desired (non standard) value. Even with a dozen of possibilies the results were on screen within a very short time, almost unnoticeable.

Also the memory space in MICROCHIPs as well as in ATMELs is very limited and won't allow to use a basic interpreter, which I guess would be appreciated by many people. :)
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top