It works!

Gratz John!

I'm eagerly reading your experiences, the more fine details of voltages etc the better.  That has been somewhat missing from startup reviews thus far, so I'm very glad to see it.  And measuring the polyfuse resistances before applying power was an excellent idea.

Still waiting for mine ...

John,

  There seems to be a surprising amount of variation between what people

are reporting.   You seem to have relatively low resistance F1 & F2 compared

to 5 to 8 Ohms reported elsewhere.  Your temperatures are consistent with

others who have said 5 seconds is all they can touch the SoC & Lan chips,

but then other people report closer to body temperature.   Your 4.6V between

TP1 & TP2 seems lower than some people report, and I think will cause

flakiness with various power supplies (as you have already seen), and SD cards,

and USB devices.  Some people report that 4.8V is not enough.

I wonder what's causing such large variations?

Someone with a hot Pi must have an infrared imager too ...

coder,

the USB cables. I've ordered a set of micro USB cables from farnell and they claim 30 AWG in the datasheet. John says 28AWG. Already a lot better!

Calibration of cheap multimeters is probably a bit off. People reporting 4.7 might have 4.8 in reality.

Cheap multimeters will show larger voltages when their battery runs out. I've made the mistake: "It says low battery, but it works fine. I HAVE the battery for the swapout, so I'll change it when the meter really stops".

I have once measured the ability of my thumb to transport away about 1W of heat. So that's my rule-of-thumb nowadays (pardon the pun. :-) ).

My 'pi uses 440 mA alltogether or 2.2W. The power is split between the SOC, the lan chip and the regulators. This means there is less than one Watt in each of them. I can keep my finger (not even my thumb) on each of them without any problems.

Someone with an IR gun has measured his chips to be 100f, and the hottest one 120f. That is basically about 40-50 degrees centigrade, right? Up to 52 degrees centigrade you do not feel "auch! that's hot". (that temperature is surprisingly constant between people).

The SD card should work downto about 4.4V as the TP1 TP2 voltage: The SD card does not have any connection to the 5V rail. It works off 3.3V, and the 3.3V regulator will has an advertized dropout of less than 1.0V. So 4.4V should be enough.

The BCM2835 calls the 5V input the V_BAT. This means that the BCM2835 is probably designed to work with 3.0-4.2V there. But it will tolerate the 5V of the rpi design there. No problem. Again, there should be no problem with less than 5V on the 5V rail of the 'pi. The 1.8V regulator has plenty of headroom. And the 2.5V regulator has very little current draw. So no problems there.

That leaves us with the peripherals on the USB ports with too little power. I have a PL2303 serial adapter that is unreliable if I  power my 'pi through an USB cable. It works fine when I power it through a 12V -> 5V DCDC converter and a 30cm cable connected to a bare USB plug I bought.

100F=38C, 120F=49C

It sounds like some people are seeing around 40C, and some around 50C,

for reasons yet to be explained.  John's Midori seems unusually slow, so

there is possibly some unusual bus traffic or interrupt activity going on that

might also explain the high temperature.

Congrats on the new arrival !

I don't have an IR sensor, but my mostly used Pi, part of the 'original 8,000' gets pretty hot. I have one from a later order which doesn't seem to get quite as warm, but to be fair I probably haven't put it under as much load yet. Perhaps I will rectify that at the weekend.

I'll also dig my multimeter out and see what figures my two report.

Midori on the original Pi is usable, just.

Midori's problem is simply that there is no way to disable Javascript in this browser on a per-source basis.as one can do with the NoScript add-on in Firefox.  Because of that,  Midori's advantage in theory doesn't result in an advantage in practice.

It's much slimmer than Firefox and potentially far less demanding of resources, but today's web is at the mercy of clueless website developers who infest every page with wholly inappropriate scripting that reduces even the slimmest of browsers to a crawl.  Webbies should be locked up in a padded cubicle and not allowed access to anything sharp with which they can hurt themselves, or us.  And Javascript is sharp.

Disable scripts in Edit->Preferences->Behavior and Midori suddenly becomes virtually instantaneous on x86 machinery, regardless of website.  Unfortunately then half the web doesn't work.

Next time you see a webbie, give them a good kicking.  It provides useful stress relief, helps redress the balance of the universe, and while they're nursing their wounds then they aren't writing more Javascript.

Morgaine Dinova wrote:

 

Midori's problem is simply that there is no way to disable Javascript in this browser on a per-source basis.as one can do with the NoScript add-on in Firefox.  Because of that,  Midori's advantage in theory doesn't result in an advantage in practice.

 

It's much slimmer than Firefox and potentially far less demanding of resources, but today's web is at the mercy of clueless website developers who infest every page with wholly inappropriate scripting that reduces even the slimmest of browsers to a crawl.  Webbies should be locked up in a padded cubicle and not allowed access to anything sharp with which they can hurt themselves, or us.  And Javascript is sharp.

 

Disable scripts in Edit->Preferences->Behavior and Midori suddenly becomes virtually instantaneous on x86 machinery, regardless of website.  Unfortunately then half the web doesn't work.

 

Next time you see a webbie, give them a good kicking.  It provides useful stress relief, helps redress the balance of the universe, and while they're nursing their wounds then they aren't writing more Javascript.

 

Thanks for the advice!  Sounds like a great way to filter out useless cobwebs, like not having Flash available.  I think the biggest problem with web sites is that companies give developers fast computers and fast connections so they can't see what the web sites really do in the wild.  They should give them 80386SX machines with 56K dial-up.  Then then web sites will behave much better :-)

John Beetem wrote:

 

They should give them 80386SX machines with 56K dial-up.

+1

Although I turn it into comedy to make light of it, unfortunately it's factual.  Webbies have partially destroyed the Web through a combination of inadequate education and poorly conceived web architecture.

Education is relevant because writing web content does not require engineering knowledge and engineering sense, whereas programming does.  And the architecture of web scripting is such that poor Javascript programmers have no negative feedback because their programming uses resources on other peoples' machines instead of on their own.  That would invite trouble even if the programmers were experts.

Put those two things together, uneducated programmers and no negative feedback, and the result is a web that spirals towards unusability through resource misuse and exhaustion.  It's a bad combination.

Morgaine.

It would be nice to figure out if John's subjective sense that Midori

is way too slow, and Steve's sense that Midori is "usable, just", are

different ways of describing the same behavior, or if there's really

a difference, possibly involving the SD card, or firmware version, etc.

There is an easy to run javascript benchmark at

http://www.webkit.org/perf/sunspider/sunspider.html

nothing to download, just click on the link:

"Start SunSpider 0.9.1 now!" and wait for the results.

Or maybe by viewing some particular page without javascript,

you can measure how long it takes to load.