RG1 1.8v regulator

I just did some digging in the NCP1117 data sheet (ONsemi version).

RG1 is an NCP1117-1v8 fixed linear LDO regulator.  We have suggested that if RG1's regulation voltage Vreg is greater than IC3's (LAN9512) internal Vreg, then RG1 will supply 1.8V current instead of IC3, reducing IC3's power consumption.

The NCP1117 has a "adjustable output" version which sets Vreg using external resistors instead of internal resistors like the NCP1117-1v8.  In addition, you can adjust Vreg of the "fixed" version with an external resistor plus a stabilization capacitor.  Take a look at Figures 31 and 32.  In Figure 31, a 50 Ohm resistor between the NCP1117's GND pin and circuit GND shifts its output by 300 mV.  Figure 32 uses a variable resistor.  Shifting RG1's Vreg up by 90 mV (+5%) might do a nice job of cooling down IC3 -- probably a 15 Ohm resistor.

Figure 31 also confirms that if two NCP1117's are connected in parallel, the LDO with higher Vreg does switch off the LDO with lower Vreg.

Figure 31 also confirms that if two NCP1117's are connected in parallel, the LDO with higher Vreg does switch off the LDO with lower Vreg.

The engineer in me asks which electrical characteristic on the datasheet defines the voltage differential required to turn the regulator off? 

Hi all, first post from another refugee...

selsinork wrote:

 

Figure 31 also confirms that if two NCP1117's are connected in parallel, the LDO with higher Vreg does switch off the LDO with lower Vreg.

The engineer in me asks which electrical characteristic on the datasheet defines the voltage differential required to turn the regulator off? 

It's simply the way that the average linear regulator works (caveat alert: there's no schematic in my 1117 datasheet, so I'm assuming a standardish circuit). A linear reg (very basically) dumps current into a load while monitoring the voltage on it's output pin with reference to it's ground pin. A feedback loop varies the current from input to output to keep the output pin at setpoint. If you apply a voltage higher than setpoint to the output pin via a low impedance source the regulator has no way of dumping current from output to to ground internally, so the output voltage is pulled high. The internal error correction then takes a dump (technical term!). So then in this case, the regulator with even a marginally higher output voltage supplies all the current to the surrounding circuitry, while the other is shut down. As has already been mentioned there may be parasitic oscillation, thermal effects... allsorts going on too. There's no easy way to make fixed regulators work in parallel either - best to let the right one do all the work! What's the upper voltage limit of the 1V8 line anyway?

Hope this all makes sense.

There's a report today that adding a heatsink cures networking problems:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=24&t=14478&start=4

by lajos » Thu Aug 16, 2012 3:01 pm

So I did an experiment. I installed heatsinks on both the SOC and memory chip. It's a small heatsink, the SOC still gets pretty hot (I don't have a surface thermometer, but it's not comfy to the touch.) But now the ethernet works without dropping out.

 

Before heatsink, I would get at tops 40-50KB/s transfer rate, with frequent stalling, with heatsink I can move large files at ~2.0MB/s.

 

Although there is a contrary report as well:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12097&start=247

I added a radiator to the chip but there was no difference. Perhaps it was too small.

 

That is sort of a synonym for "unreliable."

-J

Hope this all makes sense.

Possibly, but everything you say is based on assumption with no actual reference to defined behaviour.

There was a very simple reason for asking that question. If the behaviour is not defined you have no basis to rely on it, you simply don't know if it'll work or not. Saying "It's simply the way that the average linear regulator works" is not an acceptable substitute for actual defined behaviour.  Doesn't anyone question why the behaviour isn't defined ?

The only reference appears to be Figure 31 and that suggests you need 300mV to (reliably?) turn the regulator off. So how does the SoC, RAM etc react 2.1v on it's 1.8v input ?

On the other hand, if it's only a couple of mV then you'll have lots of fun with oscillations as the voltage measurably changes by a few mV depending on how you load the cpu/gpu.

Without a definition of the behaviour it's only ever going to be a bad engineering decision to use it, rely on it, or expect it to work.

Also we don't know what the 1.8v regulator inside the lan9512 is or what it's defined behaviour is, it could be a 1117 clone, or could be something vastly different in design, we simply don't know. We do have an answer from SMSC saying it's not designed to be used this way.

selsinork wrote:

 

Hope this all makes sense.

Possibly, but everything you say is based on assumption with no actual reference to defined behaviour.

 

There was a very simple reason for asking that question. If the behaviour is not defined you have no basis to rely on it, you simply don't know if it'll work or not. Saying "It's simply the way that the average linear regulator works" is not an acceptable substitute for actual defined behaviour.  Doesn't anyone question why the behaviour isn't defined ?

 

The only reference appears to be Figure 31 and that suggests you need 300mV to (reliably?) turn the regulator off. So how does the SoC, RAM etc react 2.1v on it's 1.8v input ?

On the other hand, if it's only a couple of mV then you'll have lots of fun with oscillations as the voltage measurably changes by a few mV depending on how you load the cpu/gpu.

 

Without a definition of the behaviour it's only ever going to be a bad engineering decision to use it, rely on it, or expect it to work.

 

Also we don't know what the 1.8v regulator inside the lan9512 is or what it's defined behaviour is, it could be a 1117 clone, or could be something vastly different in design, we simply don't know. We do have an answer from SMSC saying it's not designed to be used this way.

Very valid points, except perhaps the "fig 31...suggests you need 300mV to (reliably/) turn the regulator off" part. "Yes... and no" is probably the best answer I can give to that.

Who's to say that the nice folks at On Semi ever actually built and tested the circuit, rather than just lifting it from a cookbook and specifying a nice big differential voltage to allow for the vagaries of production tolerances, changes due to ambients and a lump more for safety? And on an unrelated note,  why would a "proper" engineer specify 50R instead of a more sensible (from an inventory POV) 47R? I see this all the time on application notes...

The fact that On specify applications with a resistor in the ground lead demonstrate that (like any other vanilla linear regulator) this one does not rely on a mechanism for dumping current to ground, therefore any overvoltage applied to the output above setpoint will be resisted by the feedback circuitry in the only way it knows how, i.e. by increasing the resistance of the series pass element. How a pair of regulators fight over current supply duties in this real world case will be more complicated (and will require real world analysis), but I'd bet a night's beer money given the output voltage regulation spec that it would take rather less than 300mV output overvoltage to switch one off. The actual setpoint may vary a tad due to the reasons above, but once it's exceeded by even a small amount, the regulator stops working, because there will be a high gain under the feedback loop. It all depends very much on the characteristics of the other reg too, which we're ignoring...

The bottom line is of course that it's not supposed to work like this and the usual "we'll work around it in software" hacks won't help. I really can't believe that they're still churning these things out at full pelt...

Very valid points, except perhaps the "fig 31...suggests you need 300mV to (reliably/) turn the regulator off" part. "Yes... and no" is probably the best answer I can give to that.

Well as it's not defined elsewhere, yes and no is about the best answer I'd expect   Taking a random sampling of datasheets from other manufacturers of equivalent parts, some include that circuit, some don't. I didn't find another one that mentioned the 300mV or defined this behaviour at all.  What is clear is that there must be an original manufacturer and they're all mostly cut&pasting the datasheet from one source. I couldn't easily work out who the original designer was so it's hard to pick any one of the datasheets as being authoritative.

And on an unrelated note,  why would a "proper" engineer specify 50R instead of a more sensible (from an inventory POV) 47R? I see this all the time on application notes...

I'd probably have picked 51R, but as 50OHM, 0.1W, 1% 50OHM, 0.1W, 1% and all sorts of strange values like 49.9R, 50.5R, 51.1R are available at the same cost as the 'standard' values. I agree though, it's a pain when somthing specifies some odd fractional value that you have to order up specially.

but I'd bet a night's beer money given the output voltage regulation spec that it would take rather less than 300mV output overvoltage to switch one off.

So would I.. The point was simply that we don't know and as there's no reference we're simply not in a position to judge whether this is suitable behaviour or not. The engineer side of me does things like "specifying a nice big differential voltage to allow for the vagaries of production tolerances, changes due to ambients and a lump more for safety?" as I suspect most of us do, unfortunately that's exactly what brings us to the 'undefined behaviour' vs real world application question.

The designer of this battery changeover ciruit (ON Semi's fig 31) was intending to set a difference so that one regulator would do all the work if the ac power was present. The 300mV (which is obtained by assuming the nominal 6mA quiescent current flowing through the 50R resistor) gives a margin over the +/-100mV tolerance of the regulators' output voltages. It's not  a good design because the minimum quiescent current is not specified so the intended 300mV might easily be only 200mV and then a worst case pair of regulators would be sharing the load.

What we do know is that the 1117 regulator can be used in pairs but since the SMSC chip makers explicitly say that their part should not the RPi circuit is still uncharted territory (and obviously just a mistake).

I can't believe that they don't just put it right.

Michael Kellett

The designer of this battery changeover ciruit (ON Semi's fig 31) was intending to set a difference so that one regulator would do all the work if the ac power was present. The 300mV (which is obtained by assuming the nominal 6mA quiescent current flowing through the 50R resistor) gives a margin over the +/-100mV tolerance of the regulators' output voltages. It's not  a good design because the minimum quiescent current is not specified so the intended 300mV might easily be only 200mV and then a worst case pair of regulators would be sharing the load.

What we do know is that the 1117 regulator can be used in pairs but since the SMSC chip makers explicitly say that their part should not the RPi circuit is still uncharted territory (and obviously just a mistake).

I can't believe that they don't just put it right.

Michael Kellett

which is obtained by assuming

See, that's the bit I don't like

I can't believe that they don't just put it right.

Hopefully they will, but for now all we have is another assumption that theres no quick and easy way to do that.  If there's a pcb respin needed then it makes sense to take some time and fix as many problems as can be identified in one go - alignment of the RJ45 would be quite high on my personal list. 

There's likely to be some number of bare pcb's in the pipeline, so even an immediate fix could take some time to filter through to customers. We have no details of any of that, nor would I expect to ever see it, so we're left with more of those pesky assumptions

Hi selsinork and thanks for the reply. You're absolutely right  - no amount of assuming on our part is going to move any copper! Putting on my optimistic to the point of naïveté hat for a moment then if a board revision does come it will take some time to proto and test (properly!) - way longer than the factories' stock of the current boards (which will be pretty skinny). Raspberry Towers may be wary of moving that connector (or doing anything else that isn't absolutely imperative) given the amount of fubar already. Who knows with that lot? They certainly make assuming stuff difficult. I do detect a little more humility on the forums over there lately though. Sometimes. With certain staff. When no-one's looking. Most of the fanbois are just as obnoxious as ever though.

I wonder whether the rollout (if it does happen) will be accompanied by fanfares, or whether it will be a subdued affair...

selsinork wrote:

 

If there's a pcb respin needed then it makes sense to take some time and fix as many problems as can be identified in one go - alignment of the RJ45 would be quite high on my personal list.

I'm just incredulous that with so many expert hardware engineers on the various forums, the Foundation's people are so full of themselves that they refuse to do the redesign in open consultation, despite the fact that it is the community that has found all these faults.

selsinork wrote:

 

If there's a pcb respin needed then it makes sense to take some time and fix as many problems as can be identified in one go - alignment of the RJ45 would be quite high on my personal list.

You would have hoped that Pete had a bunch of fixes pretty much

ready to go by now, and that this one would just get added to the list

without much further delay.

But I don't get the impression that Pete has been very active on RPi

issues lately, based on him being absent from this forum (not even

monitoring the hardware flaws and fixups thread that he started)

and based on his recent comment that this issue was just one on

his list of board issues to look at.  It sounds to me like the returned

boards have just been piling up unopened in his office.

Since we aren't getting much help from Pete in understanding how

the regulators work, is anyone able to attach a scope and measure

any oscillations?

In post #74, Pete wrote:

"Of the returns I have for analysis, I have still have not found a real ‘steamer’. These could be in part due to poor underfill or even a short/defect elsewhere on top of what we are asking the chip to do."

I find this interesting in regard to element14's limited warranty, which says:

"Newark element14 warrants that the Raspberry pi will be free from defects in material or workmanship for a period of 12 months from the date of Newark element14's shipment of the Raspberry pi to you, the Customer."

http://www.farnell.com/datasheets/1627216.pdf

Notice that "design defects" are not explicitly mentioned.  So I wonder if

"poor underfill" would be a covered defect in workmanship, but an error in

the schematics would be an uncovered design defect?  I presume if the

temperatures are hot enough to be considered a safety issue, that it would

be covered by law in most jurisdictions regardless of whether it was a

considered to be a design issue or not.

Hopefully someone from element14 will speak up soon as to how the

warranty applies to this design error.

coder27 wrote:

 

But I don't get the impression that Pete has been very active on RPi

issues lately, based on him being absent from this forum (not even

monitoring the hardware flaws and fixups thread that he started)

and based on his recent comment that this issue was just one on

his list of board issues to look at.  It sounds to me like the returned

boards have just been piling up unopened in his office.

 

Since we aren't getting much help from Pete in understanding how

the regulators work, is anyone able to attach a scope and measure

any oscillations?

It's rather likely that we've been guilty of wishful thinking regarding Pete's visits to this forum, sometimes seeing it as vindicating our view that (Foundation minus Pete) is on drugs whereas Pete as their engineer retains his professional standards and distances himself from the shenanigans of the rest of the Foundation.  Unfortunately, that's almost certainly naive in the extreme.  He knows that his toast is buttered on the RPF side, and that being seen as a small hero here does not pay the rent.  His absence and silence probably reflects reality rather than our wishful thinking:  we misjudged his desire to do the right thing for the community.

We still don't have the old gerbers despite countless requests and no rational reason for them to be withheld, we still have no information on whether the first revision is intended to be minimal or extensive, and we still don't  have any engineering feedback about Model A operation despite the continued false advertising of "$25 computer" (it would be valuable to quantify USB faults in the absence of the LAN9512).  If Pete wanted, he could be pushing the Foundation towards being more open about these things, but this has not happened.

While wishful thinking makes all us feel better, the facts are not encouraging:  Pete spent at most a few hours on a number of occasions gathering input from the Element 14 forum, but the information flow has been completely one-way.  I think it's time to put the rose-tinted spectacles aside.

Morgaine.

Since we aren't getting much help from Pete in understanding how

the regulators work, is anyone able to attach a scope and measure

any oscillations?

On the scope I can see just a little bit of noise less than 20mV but no oscillations, I'm hitting the ethernet port with flood packets.

I'll put the ScopeMeter on a long term plot of 1V8.

About my comments on analysis, etc, the issue is that we have many variables moving at the same time that induce a large deviaton on any measurements, we are not following a common test procedure or similar instruments while testing different boards to be able to produce a reasonable bell curve.

So "it works for me" is valid report too, actually so far it has been working for me too in some aspects.

I'm still wating to see what else Pete has on his "list" ...

BTW I'm playing with the MK802 and the thing works out of the box with Android 4.0, no issues with the RF keyboard/touchpad, video and audio are great, yes I paid $72 for it but includes a power supply, HDMI cable, USB cable, USB adaptor, comes with a nice box and btw has a case !!, ohh and 1GB RAM, 4GB FLASH, the Cortex-A8 runs at 1GHz and the GPU at 500MHz. With all that now the R-pi feels more expensive ...

I've the little Gizmo attached to one of the corners of my monitor.

I'll try some time later to get Ubuntu running on it

-J

Cute, thanks for the pic.

Cortex-A8 seems a good foundation on which to base a multi-machine home ARM capability.  My BeagleBone and original-version 7" Samsung Galaxy Tab both use Cortex-A8, and so does the forthcoming Olimex A13-based board (all those A10 gadgets too).  Moreover, Cortex-M3 and M4 microcontrollers use the same ARMv7 instruction architecture, so in principle one could do development on a Cortex-A8 Linux machine to target a Cortex-M3/4 series microcontroller without needing cross-compilation.

More advanced application processors like Cortex-A9 MPcore and Cortex-A15 still retain the same basic ARMv7 instruction architecture as Cortex-A8, so there's a solid growth path into the future there too.  ARMv7 is effectively ARM's equivalent of the ubiquitous x86.

Morgaine.

Morgaine Dinova wrote:

 

He knows that his toast is buttered on the RPF side, and that being seen as a small hero here does not pay the rent.

I'm not sure the RPF is paying Pete much rent money either,

given that they have long claimed not to have any paid employees.

I think it's much more likely that he hasn't been doing much if any

RPi work lately because they aren't paying him much if anything. 

When Pete first responded to this issue, he didn't say the RPF

asked him to respond, or that he was responding on behalf of the

RPF, he said Mike Powell of element14 asked him to respond.

Of course, the RPF may have later asked him _not_ to respond further.

I suspect there is some checking going on regarding Pete's work

in designing the board, to see who is liable for fixing the problem.

If Pete did the work as an employee of RPF, then RPF would probably

be liable.  If Norcott was involved, then Norcott might be liable.

I notice that Pete appears to be deflecting some of the blame toward

Broadcom, in saying that the error was in the earlier prototype boards

and his work was extensively checked by the SoC experts.  I don't see

anybody stepping up and taking responsibility.

Morgaine Dinova wrote:

 

Cortex-A8 seems a good foundation on which to base a multi-machine home ARM capability.  My BeagleBone and original-version 7" Samsung Galaxy Tab both use Cortex-A8, and so does the forthcoming Olimex A13-based board (all those A10 gadgets too).  Moreover, Cortex-M3 and M4 microcontrollers use the same ARMv7 instruction architecture, so in principle one could do development on a Cortex-A8 Linux machine to target a Cortex-M3/4 series microcontroller without needing cross-compilation.

 

More advanced application processors like Cortex-A9 MPcore and Cortex-A15 still retain the same basic ARMv7 instruction architecture as Cortex-A8, so there's a solid growth path into the future there too.  ARMv7 is effectively ARM's equivalent of the ubiquitous x86.

 

Morgaine.

Cortex-A8 uses the ARMv7-A instruction set which includes both 32-bit ARM instructions plus 16/32bit Thumb/Thumb2  instructions.  Cortex-M3/4 use the ARMv7-M instruction set which only has Thumb/2 instructions.  So if you compile your programs and libraries using Thumb/2, you'll be able to run on both (unless you use integer divide -- Gotcha!)   But if you use ARM instructions, the binaries won't run on Cortex-M3/4.  Yes, it really is this complicated.  Take a look at the latest ARM ARMs (Architecture Reference Manuals).  Or better yet, download the quick reference cards.  They read like railroad time-tables with myriad footnotes.  OTOH, I am truly impressed that they're able to squeeze the intricacies of the ARM/Thumb/2 instruction sets into a few pages.

I guess ARMv7 is equivalent to the x86 in that both evolved from a simpler architecture into a dog's breakfast.  Both are a far cry from my personal favorite, PowerPC, which was a clean, well-designed architecture long before it was implmented as an IC.  OTOH, you can't get a PowerPC board that can run GNU/Linux for under US$120.

jamodio wrote:

 

BTW I'm playing with the MK802 and the thing works out of the box with Android 4.0, no issues with the RF keyboard/touchpad, video and audio are great, yes I paid $72 for it but includes a power supply, HDMI cable, USB cable, USB adaptor, comes with a nice box and btw has a case !!, ohh and 1GB RAM, 4GB FLASH, the Cortex-A8 runs at 1GHz and the GPU at 500MHz. With all that now the R-pi feels more expensive ...

 

I'll try some time later to get Ubuntu running on it

Thank you for the MK802 photo.  Cute little board, though it obviously has limited I/O.  Please let us know how Ubuntu (or any other GNU/Linux distro) goes.

I'm also going to watch the US$49 cubieboard (http://en.wikipedia.org/wiki/Cubieboard, http://cubieboard.org/).  If cubieboard becomes real and a good community develops, it (and other A10-based boards) could be effective competitors to RasPi.  Love those 2 mm headers!