Hi guys,

I 'm a little bit stuck on question 17 on this website : https://www.allaboutcircuits.com/worksheets/time-constant-calculations/
My Maths teacher has recently set a similar question for us to do at home. I have worked out the capacitor voltage but not the current. Could you please help me on this!

Many thanks!
Marci

 

A charge change dq produces a voltage change dq/C when charging or discharging a cap.
Current = dq/dt (= rate of change of charge).

 

Hi guys,

I 'm a little bit stuck on question 17 on this website : https://www.allaboutcircuits.com/worksheets/time-constant-calculations/
My Maths teacher has recently set a similar question for us to do at home. I have worked out the capacitor voltage but not the current. Could you please help me on this!

Many thanks!
Marci

Please show your best attempt to answer it, so that we can look it over and see what you are doing correctly and what is going astray.

 

Please show your best attempt to answer it, so that we can look it over and see what you are doing correctly and what is going astray.

HI, I have done
τ = RC
RC = 33,000Ω x 10 x 10-6F
= 0.33s
4τ = 3 x 0.33
= 1.32s
the equation is V(1 – e^-t/RC)
when it is 0s, it is 0v
when it is 0.25s, it is 9.5616
when it is 0.50s, it is 14.044
and so on until 1.50s, it is 17.809v

 

So what do you know about the current in a capacitor, given the voltage across it?

Do you know calculus? If not, what have you been shown as far as how to solve these types of circuits?

 

Hey MarciYe, welcome to the forums!

OK, so you have V(1 – e^-t/RC), which looks good to me. You have an 18V battery driving the capacitor and the resistor, and the cap and resistor are in series.

If you know the cap and the battery voltage, you can compute the resistor voltage, right? And knowing the voltage across a resistor and the resistance you can compute the current, right?

See if those hints help you any.

 

HI, I have done
τ = RC
RC = 33,000Ω x 10 x 10-6F
= 0.33s
4τ = 3 x 0.33
= 1.32s
the equation is V(1 – e^-t/RC)
when it is 0s, it is 0v
when it is 0.25s, it is 9.5616
when it is 0.50s, it is 14.044
and so on until 1.50s, it is 17.809v

Oh, and it is worth pointing out that

V(1 – e^-t/RC)

is

\(
V\(1 \, - \, \frac{e^{-t}}{R}C \)
\)

You need to get in the habit of writing things with the correct order of operations. If you don't, it WILL come back to bite you.

This should be written as

V(1 – e^(-t/(RC)))

 

Hi,

Yeah i see cheating on the writing of exponents a lot. Even e^-t isnt right although we usually accept it because it is hard to interpret the wrong way. But once we get more in there it becomes impossible to decipher:
e^-t/RC

is it e^(-t/RC) or is it (e^(-t))/RC or is it C*e^(-t)/R.
The best way is probably e^(-t/(R*C)).

If i use RC i try to make a note that RC=R*C, as in e^(-t/RC).

I also see "sin x" sometimes which i also hate. It should be sin(x) because of what usually comes after it.
"sin x a", "sin x a+b" starts to get funny to interpret.

In complete works like a whole book there is usually a precedence set beforehand and so the interpretation can be had knowing that, but on the web there is usually very little context to go on because the threads are usually short.

 

Hi,

Yeah i see cheating on the writing of exponents a lot. Even e^-t isnt right although we usually accept it because it is hard to interpret the wrong way. But once we get more in there it becomes impossible to decipher:
e^-t/RC

is it e^(-t/RC) or is it (e^(-t))/RC or is it C*e^(-t)/R.
The best way is probably e^(-t/(R*C)).

If i use RC i try to make a note that RC=R*C, as in e^(-t/RC).

I also see "sin x" sometimes which i also hate. It should be sin(x) because of what usually comes after it.
"sin x a", "sin x a+b" starts to get funny to interpret.

In complete works like a whole book there is usually a precedence set beforehand and so the interpretation can be had knowing that, but on the web there is usually very little context to go on because the threads are usually short.

Actually e^-t is correct by every set of precedence rules I know, including the age-old by-hand rules. The negative sign is a unary operator and, in most cases, unary operators are higher precedence than binary operators. So this would parse as e^(-t).

 

Actually e^-t is correct by every set of precedence rules I know, including the age-old by-hand rules. The negative sign is a unary operator and, in most cases, unary operators are higher precedence than binary operators. So this would parse as e^(-t).

Hi again,

Yes you're right and maybe i should have said e^(-t) is 'better' than e^-t.

It's usually not that simple however. There ends up being other stuff after that which causes the confusion, but i've even seen calculators that will parse a^-b as (1/a)*b=b/a.

I think on here either way is ok as long as nothing else follows it that makes it hard to interpret,
for example: e^-t a+b

The real problem is lazy expression typing. Too lazy to type parens or whatever else is needed, or too much in a hurry. Notice i used the 'abbreviaton', "parens", here too which some people dont like, they want to see the whole word typed out That's where i draw the line.

 

Hi again,

Yes you're right and maybe i should have said e^(-t) is 'better' than e^-t.

It's usually not that simple however. There ends up being other stuff after that which causes the confusion, but i've even seen calculators that will parse a^-b as (1/a)*b=b/a.

I think on here either way is ok as long as nothing else follows it that makes it hard to interpret,
for example: e^-t a+b

The real problem is lazy expression typing. Too lazy to type parens or whatever else is needed, or too much in a hurry. Notice i used the 'abbreviaton', "parens", here too which some people dont like, they want to see the whole word typed out That's where i draw the line.

I can see where the calculator is getting that result -- basically it is replacing a unary minus sign with (-1)* so that e^-t becomes e^(-1)*t which then parses as [e^(-1)]*t. But I suspect that the writer of the parser is not implementing the semantics associated with the syntax. But certainly adding the parens is safe (it better be!) and it makes it so that almost any halfway correct parser and code generator can't mess it up.

I agree that their is a huge problem with lazy expression writing, but that laziness stems mostly from not understanding the subtle points of how we write expressions manually and so they can't translate them accurately to how we have to type them in using text. We have a numerator and denominator above and below a horizontal line -- so people think that the '/' represents the horizontal line and that they put the numerator to the left of it and the denominator to the right of it. Simple. Done. What they fail to grasp is that the very way we write fractions implies a set of parens around the numerator and another set around the denominator. But after writing it incorrectly, the then interpret what they wrote through the same incomplete understanding and so they see what they want to see. The same with exponents -- the very way we write it implies a set of parens. But when writing text, the parens must be made explicit whenever the implied parens are important.