Aside from stability, it is worth noting that the feedback system of a regulated power supply factors out external disturbances from the output (such as coupled interference and noise from a non-isolated power line). This is inherent with any feedback system.

The open loop transfer function would be B/E while the feedforward transfer function would be O/E. (O = output)

We can get the transfer function via superposition (getting the effect of each individual input while ignoring the other)

O1 = G1 x G2 x E = G1 x G2 x (I – B) = G1 x G2 x (I – (O1 x H1))

Simplifying:

O1 = G1 x G2 x I – G1 x G2 x H1 x O1

O1 x (1 + G1 x G2 x H1) = G1 x G2 x I

O1 = I x G1 x G2 / (1 + G1 x G2 x H1)

O2 = G2 x (N - (O2 x G1 x H1)

O2 = G2 x N – O2 x G1 x G2 x H1

O2 x (1 + G1 x G2 x H1) = G2 x N

O2 = N x G2 / (1 + G1 x G2 x H1)

Adding the together yields:

O = O1 + O2

O = G2 x (

By making either the gain G1 or the feedback gain H1 very high, O2 becomes negligible.

Since G1 isn’t physically identifiable in a typical electronics circuit, we can focus our attention on H1.

However, increasing feedback gain too much can bring us back to the stability problem, so caution must be exercised.

Speaking of stability, we can also derive from the equation that the tendency of the system to oscillate is not a function of noise (N is in the numerator, and

the typical deciding factor for stability are the factors in the denominator).

I’d also like to add that if this were a discrete system, it would be useful to keep in mind the transformation formula between the s and z domain:

So tediously transforming the characteristic equation in the time domain to the z-domain manually (if any symbolic processing tool isn’t available) won’t be necessary.

While recently engaged in coding a program for automated measurement, I encountered an unexpected problem (when did a programmer ever not?) on the first run.

Unexpected - because I thought that the code was flawless since I’ve been exposed to the architecture of the programming language for a long time now.

The problem was time variant. After the program has gathered a few samples, an instrument (the supply) would then display errors.

Why is that? There were no syntax errors, nor were there any runtime errors.

Then I checked the structure of my program again.

Why is the error happening only after the program acquired a number of samples?

Then my suspicions shifted to the GPIB connections. I noticed that I only had 1 “open-close” conversation with the instrument, and I was gathering

I thought it wouldn’t be a problem knowing 500 floating numbers or so would only consume a few Kbytes of memory, right?

Well, I was wrong. When I placed the commands for initiating and terminating a GPIB connection inside the acquisition loop of my program, the problem disappeared.

Lesson learned.

PLC. No it is not Papa Jack’s latest program segment in Love Radio. It is an instrument setting that helps average erratic measurements due to a very noisy power supply line.

A higher PLC means a higher acquisition time (more localized towards the target but is time expensive), however it can also mask certain IC responses that are as fast as the integration time of the set PLC.

Ignoring such a hazard could mean erroneous measurements, and if suspicions arise, a scope may come in handy.

And then it hit me, from the premise of equal potentials between both terminals, KVL becomes possible from the output passing along the feedback path then through both terminals then to ground (keeping in mind that no current can pass through the terminals). Since KVL is as inviolable as the law of conservation of energy, both op-amp terminals are considered “electrically” connected.

He went through his codes and formulas and settings again and knew that he didn’t miss a thing. Bewildered, he sought the advice first of a supporting Cadence specialist. Unsuccessful in resolving the problem, he was then advised to forward it to the department head (the overseer of all simulation tasks). Still failing to reach a satisfactory resolution, he went to consult his colleagues as a last resort. Since I finished my engagements ahead of schedule, I managed to find time to analyse his dilemma.

My colleague wanted to sweep a voltage supply while monitoring a certain pin within an IC. He did this by assigning a variable to the supply voltage then sweeping it using the sweep variable option under DC analysis. And so, he simulated the circuit and after extracting the results, the graphs were returning x-labels with no units. He couldn’t just manually add the units on the labels by himself because there were just too many graphs. So what was the problem? At first, I tried another plotter to see if the graphing utility was the source of the problem. It turns out that the results were the same, so the source of the problem must be before the simulation. I gave the analysis a thought and realized that if he were sweeping the variable, how would the machine know the unit of the variable? At first, he was reluctant to acknowledge the cause of the problem to be such a trivial matter. But when I re-simulated the schematic using the component parameter sweep under DC analysis (instead of the sweep variable option) and found the unit appended, he submitted to the idea. I guess this is a lesson that spawns from an idealogy that the late Bob Pease once used to uphold – that we can’t just rely too much on computers – or in this case - expect them to know everything.

The open loop transfer function would be B/E while the feedforward transfer function would be O/E. (O = output)

We can get the transfer function via superposition (getting the effect of each individual input while ignoring the other)

*Ignoring disturbance:*O1 = G1 x G2 x E = G1 x G2 x (I – B) = G1 x G2 x (I – (O1 x H1))

Simplifying:

O1 = G1 x G2 x I – G1 x G2 x H1 x O1

O1 x (1 + G1 x G2 x H1) = G1 x G2 x I

O1 = I x G1 x G2 / (1 + G1 x G2 x H1)

*Ignoring input signal:*O2 = G2 x (N - (O2 x G1 x H1)

O2 = G2 x N – O2 x G1 x G2 x H1

O2 x (1 + G1 x G2 x H1) = G2 x N

O2 = N x G2 / (1 + G1 x G2 x H1)

Adding the together yields:

O = O1 + O2

O = G2 x (

**N**+ (G1 x I)) / (1 + G1 x G2 x H1)By making either the gain G1 or the feedback gain H1 very high, O2 becomes negligible.

Since G1 isn’t physically identifiable in a typical electronics circuit, we can focus our attention on H1.

However, increasing feedback gain too much can bring us back to the stability problem, so caution must be exercised.

Speaking of stability, we can also derive from the equation that the tendency of the system to oscillate is not a function of noise (N is in the numerator, and

the typical deciding factor for stability are the factors in the denominator).

I’d also like to add that if this were a discrete system, it would be useful to keep in mind the transformation formula between the s and z domain:

s=(z-1)/(z+1)s=(z-1)/(z+1)

So tediously transforming the characteristic equation in the time domain to the z-domain manually (if any symbolic processing tool isn’t available) won’t be necessary.

### GPIB Queues

While recently engaged in coding a program for automated measurement, I encountered an unexpected problem (when did a programmer ever not?) on the first run.

Unexpected - because I thought that the code was flawless since I’ve been exposed to the architecture of the programming language for a long time now.

The problem was time variant. After the program has gathered a few samples, an instrument (the supply) would then display errors.

Why is that? There were no syntax errors, nor were there any runtime errors.

Then I checked the structure of my program again.

Why is the error happening only after the program acquired a number of samples?

Then my suspicions shifted to the GPIB connections. I noticed that I only had 1 “open-close” conversation with the instrument, and I was gathering

**500 samples**from it.I thought it wouldn’t be a problem knowing 500 floating numbers or so would only consume a few Kbytes of memory, right?

Well, I was wrong. When I placed the commands for initiating and terminating a GPIB connection inside the acquisition loop of my program, the problem disappeared.

Lesson learned.

### PLC

PLC. No it is not Papa Jack’s latest program segment in Love Radio. It is an instrument setting that helps average erratic measurements due to a very noisy power supply line.

A higher PLC means a higher acquisition time (more localized towards the target but is time expensive), however it can also mask certain IC responses that are as fast as the integration time of the set PLC.

Ignoring such a hazard could mean erroneous measurements, and if suspicions arise, a scope may come in handy.

### Op-amps and Virtual Grounds

Operational amplifier analysis commonly uses the assumption that both its input terminals are at the same potential and are shorted under the presence of a feedback loop. But why is that? (whew, I really like asking this question a lot) The answer wasn’t very obvious to me at first but then when I asked myself – “What is there in a feedback loop that isn’t when it is removed?” The answer is, of course, a feedback loop. A connection between output and input, with a shunt capacitor added at times when one wants to increase stability.And then it hit me, from the premise of equal potentials between both terminals, KVL becomes possible from the output passing along the feedback path then through both terminals then to ground (keeping in mind that no current can pass through the terminals). Since KVL is as inviolable as the law of conservation of energy, both op-amp terminals are considered “electrically” connected.

### Choosing the right simulation type with similar settings can make a difference

One of my younger colleagues had a problem recently with extracting simulation results, due to the documentation leaving out the units for the graphs of the transient response.He went through his codes and formulas and settings again and knew that he didn’t miss a thing. Bewildered, he sought the advice first of a supporting Cadence specialist. Unsuccessful in resolving the problem, he was then advised to forward it to the department head (the overseer of all simulation tasks). Still failing to reach a satisfactory resolution, he went to consult his colleagues as a last resort. Since I finished my engagements ahead of schedule, I managed to find time to analyse his dilemma.

My colleague wanted to sweep a voltage supply while monitoring a certain pin within an IC. He did this by assigning a variable to the supply voltage then sweeping it using the sweep variable option under DC analysis. And so, he simulated the circuit and after extracting the results, the graphs were returning x-labels with no units. He couldn’t just manually add the units on the labels by himself because there were just too many graphs. So what was the problem? At first, I tried another plotter to see if the graphing utility was the source of the problem. It turns out that the results were the same, so the source of the problem must be before the simulation. I gave the analysis a thought and realized that if he were sweeping the variable, how would the machine know the unit of the variable? At first, he was reluctant to acknowledge the cause of the problem to be such a trivial matter. But when I re-simulated the schematic using the component parameter sweep under DC analysis (instead of the sweep variable option) and found the unit appended, he submitted to the idea. I guess this is a lesson that spawns from an idealogy that the late Bob Pease once used to uphold – that we can’t just rely too much on computers – or in this case - expect them to know everything.

## Comments

## Post a Comment