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

So I guess it is not worth me publishing here what I know and what I can measure?

I do take issue with your final comment - it has been a success so far - with some measure of "success failure" thrown in.

I've been talking to users who just have one or two and are over the moon with them (faults issues and all) and they tell me that they have already learnt so much.

My overall positive view may yet be proved wrong, but as I said right at the outset it isn’t perfect, never will be - we just have to remember why we are clearing the swamp!

Off to watch the Olympics on TV

Pete

I am not a hardware guy, but I am quite surprised to see that hardware

schematics aren't clear about the direction of power flow.

In many years of working in the subcontract hardware assembly business I've seen hundreds of schematics from all sorts of companies, from the biggest names to tiny one man outfits and I've rarely seen anything indicating power direction.

This sort of thing wouldn't have been a problem in years gone by as it was rare for IC's to have internal regulators and often power was supplied from an off board supply so it was obvious.

Things change, technology gets more complex, leaving room for ambiguity and errors to creep in.

IME Petes schematics are pretty good, they lack some things you'd normally find on much larger schematics like a cross reference of refdes and signals to page and location, but for four pages most of that stuff isn't really necessary.

lol.. nope.. it's like one of those russian dolls you keep removing another layer until you get to the 0201 smt cap somewhere inside

So I guess it is not worth me publishing here what I know and what I can measure?

I'd certainly appreciate anything you're willing to share Pete

PeteL wrote:

 

 

 

I remember saying at the outset that Pi would never be perfect - just doesn't happen in engineering there is always something to be optimised, improved.

There is a story about a craftsman who made beaten copper doors for the Tsar of Russia's throne room.  He would take a large sheet of copper and beat it over and over with a hammer, creating beautiful swirling patterns.  Someone asked him "how do you know when you're done?"  He answered: "It's never done.  I just keep hitting it until they take it away from me."

Engineering is like that -- especially software engineering.

Thank you for being open to suggestions, Pete!

Pete,

>So I guess it is not worth me publishing here what I know and what I can measure?

You are being way too defensive.  Nobody is blaming you for the design error.

If I understand your earlier comment correctly, the error was copied from the

alpha board that you didn't design yourself.  And I don't think it matters much

to hear that you have found a happy customer.  On this forum and the RPi

forum, happy customers are hugely outnumbered, not that that matters either.

It would be very nice for you to publish what you know and what you

can measure.  However, regardless of what further information you can

provide, I think it is clear enough at this point that the lan chip is not

supposed to be blisteringly hot, as people have been complaining about

in vain for months, and it is essential to promptly tell those customers what

their remedy is, rather than what they have been told so far, which is that

hot chips are normal in PCs.

Going forward it is clear enough that the foundation has limited resources

for debugging their hardware and software, and would greatly benefit from

a bit more openness with regard to schematics, and a bit more cooperation

with those who point out problems.

Hi Pete,

PeteL wrote:

 

I see the issue with 'higher' temp but now I get the feeling you are looking to fix something else with this mod?  Can you confirm?  There is mention of the USB issue - point me at it please and anything else you think is connected.

I'm a big fan of reliability and uptime, after a few kernel panics I was hoping that this might help with stability, it didn't seem to though. Still worth a try. I can trigger a kernel panic by using nfs pretty reliably. Software upgrades seem to have helped significantly, and development is ongoing. It is a pretty harsh test, blasting udp packets from a gigabit nic to the Pi with all error correction done in software. I've since not been able to get it to crash repeatably with other (more polite) tcp based protocols.

I'm also interested in increasing power efficiency, as I plan to build battery powered robots and data loggers.

So no, I personally don't have a specific hardware issue.

This sort of thing wouldn't have been a problem in years gone by as it was rare for IC's to have internal regulators and often power was supplied from an off board supply so it was obvious. Things change, technology gets more complex, leaving room for ambiguity and errors to creep in.

 

Selsinork,

  Thanks for the explanation.  It makes sense. 

Here I've assumed that at least since Intel's fdiv bug, hardware

guys have had the advantage over software guys because they

use mostly formal verification techniques where we rely mostly

on ad hoc testing.

  I couldn't figure out at first why it was difficult to verify that

all the components on the RPi board were properly connected

to power, which I assumed to be a pretty fundamental property

to be sure was verified, until I saw that power flow isn't

specified on the schematics.

  It makes one wonder what is meant by the claims that the RPi

design was carefully checked.  How can you check something

that isn't specified, especially when the datasheets for the ICs

are either non-existent or ambiguous themselves?

  As technology gets more complex, ambiguity has to be reduced

so checking can be increased, just to keep reliability from getting worse.

The engineering process after initial release is about identifying existing shortcomings and evaluating alternative solutions for future releases, and doing this iteratively for each new version or model.  It is not about pointing fingers at engineers (which is completely irrelevant and unhelpful), and it is not about those engineers reacting defensively when problems are identified.

Reacting defensively makes it hard to analyse technical problems because it personalizes them, and when the defensive reaction is as extreme as on the Foundation forums and leads to messengers being banned, the engineering process is completely stillborn.  We're free of the latter here, but please let's remain free of the former as well.

PeteL wrote:

 

I do take issue with your final comment - it has been a success so far - with some measure of "success failure" thrown in.

Pi Model B is most definitely not an engineering success.  Engineering success is a fairly measureable quantity related to how much of the engineering involved was actually successful, ie. how much of the product works as expected.  (And "success failure" is not a term any engineer should ever utter.)

If any other computing device had been found to have such a catalogue of compatibility problems when used with totally class-compliant USB devices, it is highly likely that it would have been recalled immediately and withdrawn from sales pending redesign.  The Pi is setting an example of USB incompatibility such as has not been seen since the first year of release of the USB spec and initial devices.

These USB problems appear to be in part fallout from least-cost BCM2835 SoC design and its USB  driver, and in part a consequence of excessively restrictive power design, but the board is a unit and its USB functionality is an extremely important part of its operation.  That key functionality has major faults.  It is not an engineering success (the only kind that concerns us here), because it is failing to operate as expected, and there are countless examples of how it is failing spread across the planet and reported on both RPF and Element 14 forums.

I'm going to assume that the objectively incontrovertible fact of widespread failures is accepted, because anything else would not be a professional engineering response given the evidence.  The big task then becomes to identify the reasons and find solutions, and that is why we are here, in my opinion.

Unless we can get past acceptance of the problems though, there is little prospect of finding solutions.

Regarding how the 1.8V design might affect LAN9512 operation, I have no evidence that they are related either, but I am just hoping that they are related in some way that we cannot currently see because otherwise it seems likely that the Pi's huge USB faults are with us to stay.

Morgaine.

Pete anything you are able and wish to share will be very valuable, I can say that so far I've not seen anything being shared yet...

I don't feel qualified to state if the mission of RPF has been or will be a success or not, my comment was referred to situations where people say "we tried hard," "we did our best."

Nobody will deny to acknowledge and appreciate the efforts but what it counts at the end are results.

At one time I had over 100 engineers working in my team and I never accepted that something that was accomplished by "doing their best" couldn't be done better and more efficiently, because as others said engineering is a cumulative process where we constantly learn and apply the new knowledge to do things better, and more efficient, and which will never be perfect.

I'm not a fanboi or a detractor of the R-pi, I still consider that it was a great idea and something worth to create, I'm not angry and I'm still using the 2 boards I purchased and planning to still work on some projects with them, now would I recommend it to local schools?, the answer at this time is NO.

BTW kudos to the UK and London for putting such a great 2012 Olympics.

Regards

Jorge

Pete anything you are able and wish to share will be very valuable, I can say that so far I've not seen anything being shared yet...

I don't feel qualified to state if the mission of RPF has been or will be a success or not, my comment was referred to situations where people say "we tried hard," "we did our best."

Nobody will deny to acknowledge and appreciate the efforts but what it counts at the end are results.

At one time I had over 100 engineers working in my team and I never accepted that something that was accomplished by "doing their best" couldn't be done better and more efficiently, because as others said engineering is a cumulative process where we constantly learn and apply the new knowledge to do things better, and more efficient, and which will never be perfect.

I'm not a fanboi or a detractor of the R-pi, I still consider that it was a great idea and something worth to create, I'm not angry and I'm still using the 2 boards I purchased and planning to still work on some projects with them, now would I recommend it to local schools?, the answer at this time is NO.

BTW kudos to the UK and London for putting such a great 2012 Olympics.

Regards

Jorge

Everyone doing their best is assumed.  It has no bearing on whether a product works or not, except possibly if the testers are ineffective and hence undermine everyone else on a project.  If anyone else in an engineering team fails, it should be caught at test to within certain limits (not 100%).

But more importantly and relevantly, that issue is not part of the engineering process.  That process at the core of our profession concerns the objects being engineered, not the people.