F1/F2 polyfuses gone

I just love it how the fanboys on the original forum praise the modification that makes their Pi even the more perfect design.

Using one capacitor for both usb ports (but with a sufficient value) shouldn't work much different than using a capacitor for each port. It will have a bit higher ESR, but it's not there to continuously flatten ripple voltages.

A bigger capacitor is a more expensive component, and we all know how hard it is to keep the low price for the board.

The camera and dsi connector make me wonder if education is really the goal of the foundition, or if that is just a fog screen to rectify the 'non profit' nature of the foundation? They missed the start of the 2012 - 2013 schoolyear. Their low price setting is great, but for a workable classroom setup, you need to add the price of a monitor, a keyboard, a mouse, a hub and a housing. The board on it's own is just part of the setup. So the only benefit compared to a netbook or cheap tablet is the fact that students can go back to basics, except, that such requires an open approach upon hardware an software? Maybe they can learn how to do reverse engineering of the binary blob. It will give them great job opportunities later on in chinese cloning factories. Altough I hope no one tries to clone the synoptics otg usb stack.

I suppose that the polyfuse fix is a "pragmatic engineering solution" - it's a low cost item and a board fix just for the USB power problem is hard to justify (especially when a fix for the 1V8 issue may be in the pipeline). The important thing is that possible caveats regarding total power draw are written large by the Foundation and not hidden under a rock, as previously happened. Similarly, I don't see why the "upgrade" to zero ohm resistors was kept quiet. While the specsheet for just about every bit of hardware typically contains wording like "specifications liable to change without notice", this is just a disclaimer, not an obligation!

I guess that the Foundation were worried about threads along the lines of "Boo-hoo, if I'd known about an upcoming upgrade I'd have delayed my purchase..."

@Luc Cool: I was a little taken aback by the announcement of the camera as the first addon (not including the Gertboard, of course). When I first became aware of the Pi (and it's educational leanings) last year I imagined that it may mature into a lower budget version of .net gadgeteer, with various plug in expansions. Top of the "obvious" list would be simple i/o like maybe an lcd display, button / keypad thingers, some basic sensors and perhaps a small touchscreen

Instead we get a camera. Have Broadcom started manufacturing CCD's?

I guess that from an educational POV such gadgets would benefit from an integrated software development environment (rather than just plugging in and messing around with Python until *something* happened) and the Pi at the moment is "just" a desktop Linux box awaiting dedicated applications. Still, I imagine that a touchscreen module would be very popular with more advanced hackers for their carputer / burglar alarm / environmental control, etc. projects. It's easy to forget that it's early days yet though...

Edit: Of course hackers are prepared to buy various bit and bobs in the hope that they'll be able to get them working via GPIO, but in an educational environment time spent troubleshooting means less time programming, so I'm sure that schools would rather pay a bit of a premium for "known good" peripherals / software and support thereof. I'm quite intrigued to see what the actual package will be. What else will they get apart from a box containing a Pi (and probably an SD card, PSU, keyboard and mouse)?

I agree that the usb power issues are widely spread all over the forum.

The other usb issues however are well hidden in 1 or 2 threads in the troubleshooting section.

The last question how progress was going in relation to fixing this issues got answered with the message that last weekend was banking holiday in GB, so not much work was done....

It's a strange reply for a non profit organisation that has most of it's engineering done by volunteers that have another full time day job. You would expect them to have more time to work on it on a long holiday. If they are open about the usb issue, I can only conclude that their is no progress at the moment. Gordon who was examining the issue suddenly dissapeared from their Forum. (Maybe he got banned?) Dom seems to be working on it now, but he also has time to create a firmware that allows hardware mpeg decoding based upon the soc serial number and some license key. So it looks like usb is not a high priority problem for the foundation. 

Issues that are difficult to fix can often become lower priority in favour of less important (but easier to implement) stuff.

Interesting point about the Bank Holiday. Does "free time" mean:

a) time at work when the boss isn't lookng, or:

b) time at home?

If b) then the summer Bank Holiday is a time when English folks traditionally pile their kids, partner, dog etc. into the car and subject them to crushing traffic jams on the way to / from some godawful theme park. Nothing else gets done, except maybe some gardening, shopping for the start of the new school year, or maybe a trip to the pub!

English traditions aren't my strongest point I am afraid.

I could ask the free time question on the Pi forum, but I don't think that will make me more popular around there. (My credits are rather low already.)

Drew Fustini wrote:

 

For the polyfuse on the micro usb power input, I see on the eLinux wiki it is 1.1A with a hold current of 700mA.  Does that mean the Pi can only draw 700mA before the polyfuse starts to gain resistance and decrease the 5V input? 

Here's my understanding from a Littlefuse 2016L datasheet: a polyfuse has a trip current (in this case 1.1A) and a hold current (700mA).  If you don't exceed the hold current, the polyfuse will not trip.  If you exceed the trip current, the polyfuse will trip in some max number of seconds, dending on current and temperature.  What happens between 700 mA and 1.1 A is not specified, and the currents vary with temperature.  Polyfuses work by temperature-related changes to crystal structure, and as such work slowly and depend on temperature.  Real fuses are better, but still trip pretty slowly.

So when you plug in that USB hard drive, if it draws 1.5A you'll trip in a couple of seconds.  If you draw only 1 A, it will probably trip but may take a couple of minutes and meanwhile the polyfuse slowly gets more resistive and 5V drops to 4V, 3V, 2V, ... which may make your USB drive and your RasPi sad.

Fuses in general are crude devices designed to be the weak link in an electrical system.  Home fuses are there to keep you from dying... from a fire caused by overheated wiring.  They don't protect you from being electrocuted since the current needed to kill you is much smaller than a typical fuse.  That's why you need a ground fault circuit interrupter (GFCI).

Similarly, the fuse in an electronic circuit keeps the circuit from drawing enough current to catch on fire.  It takes a while for the fuse to get hot enough to blow -- plenty of time for permanent circuit damage.  You need to have protection diodes large enough so that they don't overheat while the fuse trips.  If you need accuracy and fast protection, you need a hot-swap controller.

Indeed. Supplying current protection for *whatever your customer may decide to connect together* is always going to be a fudge, unless the budget is large. Hopefully your customer will use a power supply with a sensible current rating that performs "current foldback" on being presented with a short circuit - the common 7805 regulator does this. If it sees a short on it's output then it will limit it's output current to (IIRC) 250mA, instead of the 1A+ that it is capable of supplying to a sensible load.

However, assume nothing! I saw a post on the Pi forum from a member that was considering using the +5 volt rail from a PC supply. Those things are rated at hundreds of Watts because they will deliver hundreds of Watts (with the +5V rail being the stiffest), so some form of input protection on your device is advisable. It might not save the device, but at least it may prevent a fire...

Before the things became ubiquitous (and reliable), early switched mode power supplies were renowned for sacrificing their transistors to save their output fuses.

I suppose that the polyfuse fix is a "pragmatic engineering solution" -

It is not a solution, just a fix, sort of a patch inspired by the community wisdom and trial and error approach of shorting the damn things to have a mouse or keyboard work.

A solution would be if at some moment they are really pragmatic and realize that while cutting cost is important, delivering a product that is expected to work at least with minimal standards.

BTW, still waiting to see "the list."

-J

jamodio wrote:

 

I suppose that the polyfuse fix is a "pragmatic engineering solution" -

 

It is not a solution, just a fix, sort of a patch inspired by the community wisdom and trial and error approach of shorting the damn things to have a mouse or keyboard work.

 

A solution would be if at some moment they are really pragmatic and realize that while cutting cost is important, delivering a product that is expected to work at least with minimal standards.

 

BTW, still waiting to see "the list."

 

-J

"Pragmatic engineering solution" = fix / bodge / fudge / get you home, etc.

I'm not being an apologist, but over the last few weeks I've seen the company line delivered by The Names In Green And Red change from "there are no planned revisions" to "in a future revision x,y,z may happen..." Progress?

Board revisions are tricky - modern computers are RF engineering. There's only so many simulations you can run before actually having to cut some metal and test in the real world (I think they may have learned their lesson re. testing in the lab under "perfect" conditions the first time round, as have Seneca). If there's a board change planned, then the "pragmatic" thing to do would be to "workaround" minor issues 'til major revision time. Incremental software updates may be a bit of a ballache, but incremental hardware upates can be.... ugh! The turnaround time on any resulting issues is much longer than with software, will take longer to fix, and those users with buggy hardware are stuck with it.

It's not perfect, but then it's an imperfect world, especially in the realm of cheap consumer electronics. You can get away with publicly beta-ing firmware on an unsuspecting userbase occasionally, but doing the same with hardware is asking for trouble. Change is a holistic thing - changing one component can affect the whole assembly - and in ways that are not always predictable. Baby steps or giant leap?

Thanks for the explanation John and Jonathan.