RG1 1.8v regulator

As shown in Troy Mackay's post on Jul 28 it seems to me that we could mod our PI's to work more as the chips were designed.

I think that this could make the PI more stable, from the looks of it.

I am not a designer Just an old tech, but I think we need to find a way to FIX what we now know is an error in the board.

So could someone do some practical testing to see if there is something that can be done to easly fix the current board, rather than wait for RPI foundation to fix it by waiting for a board redesign?

i will love to try out the hack Troy mackay has done also and then test again with that fix on the board, but i have looked into this and i most say it is very well done by Troy as i think it is to small for me todo and i done have an microscope as need for this.

so yes if some one can findout where to make an cut to split the LAN9512 1v8 from the lod 1v8 then i will try this also.

Tooms

Roger Wolff wrote:

 

Some people are expressing views that paralleled regulators will have one delivering ALL the current, and the other one none. This is not always the case, This would be the case if they are both ideal voltage sources (with an ideal diode in series). However in practise, both regulators would have a measureable output impedance. So if regulator 1 delivers 1.85V with an impedance of 1 ohm, and the other delivers 1.80V with an impedance of 0.1ohm, the first 50mA will be mostly delivered by the first regulator, but increasing the current draw to 100mA, the second regulator will provide about 50mA of that.

The thing is, that isn't how regulators work, they aren't a voltage source with a resistive output.

Regulators, including the two linear regulators we're dealing with here pretty much always consist of a voltage reference with a feedback circuit controlling a variable resistance between the input power pin and the output power pin provided by either a FET or a bipolar transistor. If the voltage on the output pin is above the reference voltage by more than a tiny amount then the feedback circuit will shut off the output transistor and nearly all the power will be provided by the device with the higher reference voltage. Where it gets funny is when the two reference voltages are very close, both regulators provide part of the power and you can get into oscillations and all sorts of fun and games depending on the impedances around the circuit.

A TRM is written as much for the manufacturer's own staff as for the external audience.  If a company can't be bothered to describe to its own staff how its product works, it doesn't inspire any confidence that its staff actually knows how it works, so you can expect support and the company's support products to be poor or non-existent.

You've not worked at any of the places I have then

Reality tends to be that there'll be a warts-and-all document that only the design team in question will have access to. Someone will get tasked to produce a tidied up version which will then get sent to a dedicated team of technical writers who have no real knowledge of the device and somewhere in that loop it'll go to the lawyers before any sort of document can be made available internally, never mind publicly.

You'll also probably have four levels of document, publicly available, available after signing NDA, internally available and design team warts-and-all. So how much substance remains in the public doc ?

It's also highly likely they'll have some sort of records retention policy to make sure anything that could potentially be requested for a court case gets deleted ASAP.

IMHO, the lawyers probably have more input to the public doc than the design team does!

It might be nice to live in an ideal world where everything was done properly, the world we actually live in is more about protecting IP and maximising shareholder profit. In the eyes of the business people that means something completely different to what the engineers want.

To give you an idea, I've worked places where even employees use google to find the docs. Says a lot about the internal organisation..

It gets better, you'll probably find that nobody at SMSC/Microchip will know what the actual capabilities of the in-built regulator are. Their chip designers won't have designed a regulator from the bottom up, they will have included a regulator from a design library, it will have been specified to have a little bit of headroom over what the LAN9512 requires for its own operation. Beyond that we're into "experimental" territory.

Andrew Warbrick wrote:

Regulators, including the two linear regulators we're dealing with here pretty much always consist of a voltage reference with a feedback circuit controlling a variable resistance between the input power pin and the output power pin provided by either a FET or a bipolar transistor. If the voltage on the output pin is above the reference voltage by more than a tiny amount then the feedback circuit will shut off the output transistor and nearly all the power will be provided by the device with the higher reference voltage. Where it gets funny is when the two reference voltages are very close, both regulators provide part of the power and you can get into oscillations and all sorts of fun and games depending on the impedances around the circuit.

Mostly correct.

But if that "tiny amount" is very very small, or equivalently the gain in that feedback circuit is very large, then even with just ONE regulator, the result will be oscilations. So that's why 1) They don't design for inifinite gain in that stage 2) they specify that (usually 100nF) capacitor near the regulator to stabilize the output.

So, as the voltage on the output drops due to increasing load, the difference between the reference voltage and the feedback voltage increases and the output transistor is driven more and more (to a lower resistance as you say).

The end result is that you can measure a real output resistance on regulators.

You're absolutely right, but the point I was making is that actually pretty small differences in reference voltage result in one regulator of two connected in parallel providing nearly all the current. Yes, the gain in the feedback circuit isn't infinite but it's high enough that you don't need much difference in the outputs for one regulator to be doing nearly all the work. I won't pick nits over the semantics of resistance versus output impedance, you're right, the output does look like a resistor for small changes in load.

I think I already said it a couple of times, that connection to the 1V8 power plane is an ERROR, that needs to be fixed.

The default action from RPF/Distributors for existing users would probably be "screw them", but that problem and the others (again where is the list?) must be fixed to stop screwing new users.

You can theorize and overanalyze what should happen if you put some extra load on those pins, well, if a car wasn't designed to fly, don't insist making it fly...

Connecting LDOs in parallel could lead to very nasty side effects, including oscillation, no proper regulation, decreased output voltage, noise incjection into the core, etc, etc, etc.

About the USB issues, besides what are probably limitations and problems with the actual module inside the SoC and its drivers, until you fix the issues with power and how it is delivered to USB devices, will be hard to do many tests with various devices, it will be just an empirical list of what things work and what apparently don't. I can tell you by a fact that without removing the polyfuses I had a very hard time to make anything wireless work.

-J

selsinork wrote:

 

It's also highly likely they'll have some sort of records retention policy to make sure anything that could potentially be requested for a court case gets deleted ASAP.

When I hear the phrase "records retention policy", I immediately think of this Dilbert: http://dilbert.com/strips/comic/2004-03-22/.  I expect that arbitrarily-imposed records retention policies, especially automatic deletion of old e-mail, will result in some large firms collapsing as vital information is no longer available.  However, this will help small firms who have the luxury (and necessity) of being sensible.

selsinork wrote:

 

It might be nice to live in an ideal world where everything was done properly, the world we actually live in is more about protecting IP and maximising shareholder profit. In the eyes of the business people that means something completely different to what the engineers want.

I completely agree with selsinork's comments above, but I'd like to point out to semiconductor manufacturers, their lawyers, and their bean counters that the way to maximize shareholder profit is to sell as many chips as possible, and withholding documentation means that engineers cannot include your chips in their products, or if they do, it will be ever so much harder to get those products working because of a lack of information.  You will not get any revenue from products that fail because good software could not be developed in time because of a lack of documentation.  If you're worried about lawsuits, tell your politicians to change the laws so that you can spend your revenue on product design instead of lawsuits.  Politicians will listen to you because you have deep pockets.

There are several reasons to keep documentation hidden:

• Keep track of who has documentation, so that you can notify them when an "erratum" is found.
• Keep the documentation from view from competitors. Knowing the exact "API" eases copying.
• Keep track who wants to implement things with your chip. It might be useful to send a salesguy over when <somebigcompany> is considering using your chip. (which you know because they requested the docs for that chip).

And when you can't find docs for a chip that you want to use in your hobby project, you have to realize that selling ONE more chip is not what they are after. Even if you manage to convince 9 of 99  friends to duplicate your project.

I'm not saying that I agree with these things, but knowing WHY they might have these policies helps in finding strategies to change them.

jamodio wrote:

 

You can theorize and overanalyze what should happen if you put some extra load on those pins, well, if a car wasn't designed to fly, don't insist making it fly...

+1

There's a reason why engineers devise circuit blocks like LDOs, both conceptual and implemented, and the reason is so that you can black-box functionality and hence ride on the shoulders of giants, instead of crawling along on the ground reinventing everything.  If you break a black box, the giant evaporates and you land on your ass.

Connecting two LDOs in parallel has that effect.  All bets are off.

Fortunately, it doesn't need discussing, as Pete acknowledges the issue.  The only question is what happens now.  As usual RPF is completely opaque on that.

Morgaine.

There are several reasons to keep documentation hidden:

• Part of the design isn't yours and you simply don't have the rights to release any docs.

As a couple of others have commented, various bits probably got bought-in or imported from a design library. So you may not have the docs or may be contractually bound not to disclose them. I'd take a guess that there's all sorts of stuff like that for the reasons Morgaine mentions - and it all comes back to money. Why employ an engineer who understands the inner workings of an LDO when you can simply buy in a cheap design pattern with no knowledge required.

It's not like I'm any different, I'll happily use a chip when I have no real idea how it works as long as there's just enough docs to let me accomplish my goal.

There are several reasons to keep documentation hidden:

• Part of the design isn't yours and you simply don't have the rights to release any docs.

As a couple of others have commented, various bits probably got bought-in or imported from a design library. So you may not have the docs or may be contractually bound not to disclose them. I'd take a guess that there's all sorts of stuff like that for the reasons Morgaine mentions - and it all comes back to money. Why employ an engineer who understands the inner workings of an LDO when you can simply buy in a cheap design pattern with no knowledge required.

It's not like I'm any different, I'll happily use a chip when I have no real idea how it works as long as there's just enough docs to let me accomplish my goal.

Using black boxes is good, not bad!  Without it we'd still be scratching on cave walls instead of landing 1-ton rovers on Mars.  But those black boxes must be respected, and not compromized by using them out-of-spec.

The giants can evaporate very easily.

The giants can evaporate very easily.

Yes, and that's a risk that never seems to get factored in.  Sooner or later the original designers of the black box have left the company, died, and the knowledge has been lost.

What's then the cost to re-engineer that black box from zero when other reasons demand a change of spec ?

selsinork wrote:

 

The giants can evaporate very easily.

Yes, and that's a risk that never seems to get factored in.  Sooner or later the original designers of the black box have left the company, died, and the knowledge has been lost.

The answer is very simple, yet it is almost always dismissed out of hand by those who look only inwards and lack a global perspective:

Mankind's advances need to be fully open, so that nothing is lost.  Period.

The amount of wasted effort today is just beyond comprehension, as people compete instead of cooperate.  I don't know how one could even begin to quantify the waste, but I very much doubt that more than 1% of Mankind's effort is retained over time and leads to the advance of civilization.  More likely it's 0.001%.  Certainly the vast bulk of all commercial software effort is totally lost to humanity, all those millions of man-years down the drain as soon as software is EOL'd.

It's very sad when you sit back and think about it philosophically.  Technical progress could be running thousands or millions of times as fast as it is today if the fruits of all effort were open rather than zealously protected and then lost.  It's scary to think where we would be today.

Morgaine.

Morgaine Dinova wrote:

 

The amount of wasted effort today is just beyond comprehension, as people compete instead of cooperate.  I don't know how one could even begin to quantify the waste, but I very much doubt that more than 1% of Mankind's effort is retained over time and leads to the advance of civilization.  More likely it's 0.001%.  Certainly the vast bulk of all commercial software effort is totally lost to humanity, all those millions of man-years down the drain as soon as software is EOL'd.

 

It's very sad when you sit back and think about it philosophically.  Technical progress could be running thousands or millions of times as fast as it is today if the fruits of all effort were open rather than zealously protected and then lost.  It's scary to think where we would be today.

OTOH, philosophical progress must keep up with technological progress or mankind can build the tools to destroy itself without developing the wisdom to avoid doing so.  We seem to have dodged the bullet (for now) regarding nuclear self-annihilation, but climate change could easily do the job instead.

John Beetem wrote:

 

developing the wisdom

Not a chance, if you're referring to humans.  It hasn't happened over the few millennia of what we recognize as "civilization", and there's no sign of any change whatsoever now.

It's only our technological capability that progresses, not Homo sapiens itself --- natural evolution is simply not fast enough.  The only way the leading species on the planet will "develop the wisdom" is by integrating with our machinery and in due course leaving Homo Sapiens and its self-destructive grey matter behind.

That possibility is pure speculation, alas.  There is no guarantee that our mental activity can be integrated with machinery even with full control of everything down to atomic level, so the future may unfortunately be either/or, rather than a slow evolution from our unwise past into a logical future.

Morgaine.