Raspberry Pi - Hardware Flaws and Fixups?

Now that people have actually started receiving the boards so the design in final, is the schematic close to being posted?  I looked around again in various likely places just now, but haven't spotted it yet.

actually, the design may not be quite final yet.  Liz said: "Happily, we’ve found it doesn’t need a shielded enclosure to reach Class B, although it will require a (very minimal) redesign." http://www.raspberrypi.org/archives/978, page 3, April 10, 2012 at 7:04 pm.

It hasn't been announced when such a change might be implemented, but probably better sooner rather than later, given the large production runs planned, perhaps along with a change to fix the SD card voltage issue.

Great work Roger! I've emailed you via the bitwizard site.

There are a few Chris Evans's about. I'm new to Linux!

Ha, I already wondered how long it would take you, to show something like this....

I think it is a good picture for the frontpage on raspberrypi.org....

Can you perhaps measure the pcb for me. I am getting different answers from people.

Best guess now is  85.0 x 56.0   or  85.0 x 56.2

Hans

Observation about USB power supplies: not sure if relevant to RasPi or not.

I was making some load measurements on a bunch of 5V USB power supplies here, unrelated to RasPi stuff. Got some confusing results, until I realized something I didn't know: some of those cable-less "wall wart" USB power supplies with just a USB jack, connect the internal ground pin (cable black wire) to the connector shield (cable braid), and some do not. So in some cases you'll have the ground return current flowing on the shield (if your device connects ground and shield) and in some cases, not. In case of interest.

Thanks for all the info Pete. A summary of possible 'minor' hardware changes that I've spotted in the forums:

1. I2S implement  as per the data sheet

2. SD card voltage option bank change, as per Dom's posting in: http://www.raspberrypi.org/forum/general-discussion/where-is-the-bottleneck#p62401

3. USB OTG Id Pin to spare GPIO pin (effective only on Model A) as per:

http://www.raspberrypi.org/forum/features-and-requests/cheap-but-crucial-model-a-feature-request-read-this?value=gpio%20usb%20pin%20request&type=2&include=1&search=1&ret=all

I'm not sure if the next two are technically possible!

4. Assisting POE (spare wires variant) adaptors exist that inject power onto the unused lines of ethernet and then split them out again after a cable

run see: http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=4D-RPI-POE-IS-C (The Raspberry Pi adaptor cables doubles the price!) but if R-Pi's RJ45 could be changed for a variant that took the extra lines Earth to R-Pi's Earth and the Injected Power lines to R-Pi 5V via a link.

Pros: simple for end users to setup and injector only cable should be cheap.

Cons: POE variant of RJ45 with magnetics needed [1], cost, Reduced Isolation and extra link needed.

5. Assisting POE (via GPIO daughter board) If a POE daughter board was plugged into the GPIO pins with the daughter board having a POE input

RJ45 on it, supplying power to the R-Pi. The four ethernet data line output from the daughter board being connected to currently unused GPIO pins. I suspect inputting ethernet via the GPIO pins breaks various rules and could add to RF output:-(

Original suggestion at: http://www.raspberrypi.org/forum/features-and-requests/routing-ethernet-pins-4578-to-the-expansion-port

[1] I found a mag jack that might the type needed at: http://www.adam-tech.com/catalog/2012/page_009-049.pdf

See page 37 of 41 (marked Page 45) layout M16

n.b. I'm intrigued, what do the two diodes on the underside near the USB sockets protect?

I'd thought the USB ports, but people have mentioned on the forums that they have (unreliably) powered R-Pis via one of the two USB ports.

mmm, I really hope those "power issues" turn out to be just bad cable/adaptors/ppl doing it wrong.

You guys are working on it I suppose.

btw PeteL, what is requiring redesign (for full compliance)? That's what is bugging me, since it leads to another question: when will this be implemented (and then re-certified)? Before or after the queue of orders?

I guess "what are the changes needed" is more your cup of coffee (or better tea), so that's what I'd really like you to enlight me on.

Btw, is it just me or those 2k units feel a lot like a pre-serie?

"those 2K" should be "those 10k". The other 8k are Guaranteed to be exactly the same: they were produced feb-march just like the first 2k that are delivered right now.

and yes, I too would want to know what changes seem to be neccessary and when they will go through.

What is the HD interface? (schematics P4 left top)

What value is typical for the built-in pullup/pulldown? I expect that to be on the order of 50-100k. In that case you can encode 3^4 different board revisions with the 4 board-revision strap resistors:

read value. If zero, enable pullup, if one enable pulldown. If value now changes, the strap is left "open", so that's the third value.  (Ah! found them!).

There is an error in the schematics. p3 mentions the "USB" part of the LAN9512 as "model A only". That should be "Model B only" of course.

R22-R25, R28, C28 are missing their "Model B only" tag.

Why is there a line going from R25 to R22?

Due to space constraints the 100M led is labeled 10M on the board. How about calling that "FE" for "Fast Ethernet"? That's what 100M was called back in the days.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

What is the purpose of D15, D16? I'm thinking: Protection against static discharges, right? The question is: Wouldn't it be better to connect their kathode to +5V0 instead of +5V0_HDMI? The +5V_HDMI is just a small net that only has the 100N C75 on it....

Are the HDMI_SDA and HDMI_SCL pins 5V tolerant? I wouldn't have guessed.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

 

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,full-duplex, lpa 0xC5E1

I agree with that, FDX led is not really usefull, it would be much better if that could be used as a gpio led.

That way you can directly let kids program the led without the need for extra hardware.

Hans

Well, in principle you can use the FDX as a GPIO LED.  The difficulty is that you need to talk to the LAN9512 in USB-speak to configure and toggle it, and the driver may make this difficult.  Still, students would learn a lot about USB drivers trying to do it :-)

Was it here that someone asked me to measure the physical size of the 'pi? Mine is 55.9 x 84.9mm.

Yes me...  thx Roger.

Hans

Yes me...  thx Roger.

Hans