Screaming Circuits: General interest

Weekend Wondering - is anything really new?

Last year, Screaming Circuits started closely following the Ti OMAP processor and it's package on package (POP) form factor. The OMAP 35XX processors are very nice on their own, being a very hi-performance ARM jobby, but the package on package made it something for us to take real notice of. POP had been done before, but this seemed to be the first broad-audience application of the technique.

But is it really the first common package on package application? I've seen some unintentional package on package, like the capacitor-under-connector pictured on the right in this post. That's not so fun, but it can POP old style keep your board size down - as long as you don't want it to actually work. And then, many, many network cards used to have a chip placed right under their ROM socket. Would you call that package on package?

How about the old Ti SN754410 motor driver? It's pretty common for robot POP 754410 builders to stack a pair of them to get two amps of drive from a pair of one amp chips. That's probably more a case of actual package on package than is the network card example. Maybe the network card should be called "package under package". I know, the OMAP is a BGA, but that might actually make it easier to manufacture. With the 754410, all of those leads have to be hand soldered. The OMAP, we just put it on our machines and they do all the work for us.

The other "new, but really old" subject I'm thinking about is cloud computing. Yes, it's the newest rage in the software and application world right now, but is it really that new? Or has just the name been changed so some pundit can claim to have invented a new concept? I learned software development in a cloud computing environment - back in the early 1980's.

Duane Benson
The story you are about to hear is old; only the names have been changed to protect the egos.

Controlling the Uncontrolled

A nice coincidence. Recently, I wrote a bit about choosing a microcontroller and some issues that crop up when people not used to microcontroller design are tasked with automating systems.

My supposition is that, traditionally, most folks in the industry concentrate on designing and choosing microcontrollers and tool sets from the perspective of an expert in embedded design. However, the new world has a lot of people tasked with microcontroller hardware and software design that are not electronics or software engineers. Mechanical engineers are tasked with integrating electronic controls into their systems. Pure digital engineers are being tasked with adding analog sections into their designs. Hardware engineers are having to learn microcontroller firmware programming. That changes the ground rules.

Last week, I signed into a virtual conference on motor control (I started writing this post as I was listening to the virtual conference, but didn't get around to finishing it until today). I signed in late to start listening to the keynote address by John Hanks, of National Instruments and John was at that moment, discussing this very subject. As he described it, domain experts in such fields as solar, wind, and other areas are being asked to add additional automation into those systems. As domain experts, they may know more about their field than an EE or SE, but they likely have not been trained in the application of hardware, firmware and software development.

Interestingly, this group has a lot in common with the electronics hobbyist community. In both cases, the concepts and the tools are frequently quite new to them. In both cases, the budget for training and tools is frequently pretty minimal. In both cases, we have smart people who many not be trained in our field.

Those of us that create tools and offer services in this industry need to keep this trend in mind if we want to fully serve the new engineering audience.

Duane Benson
See us at ESC next week in booth 827

Who are your tool sets made for?

I've been thinking a lot lately about who's using microcontrollers and why these days. There's a lot at stake with this question. And, not just in terms of which microcontrollers are and will be the most popular. There's an element of the Toyota question in here too.

Traditionally, I suspect that electronics component manufactures, hardware EDA tool vendors and software tool vendors assume that their customers have been trained in EE, CS or similar discipline. I think to a point, that serves the industry well. But change is afoot in our industry. Because of a number of factors - too many to list here - virtually everything is getting some level of electronic control now. Years ago, that would have resulted in the hiring of a lot of electronics and software engineers. But not today.

The tried and true EE, accustomed to designing with logic and letting someone else worry about firmware, is now often tasked with designing in a microcontroller and then producing the firmware as well. Or a mechanical engineer is tasked with the same thing; something he or she never trained for. From what I can see, all sorts of technical folks that don't have programming experience, or any electronics design experience, are now being given that task. Schematic designers are now responsible for the board layout. Pure digital folks are often being required to add in a few RF sections.

What happens if all of the software tools (CAD packages, compilers & tool changes) are designed for well trained experts, but intelligent but untrained, in that field, folks need to use them?

When cars suddenly accelerate, MRI machines over-radiate or satellites fail, it's all good to look for tin whiskers, cosmic rays, manufacturing defects, software bugs and causes of that sort. But, what if the root cause is simply that someone trained and practiced in pure digital design was tasked with the "simple" function of adding in a few analog sensors and a tiny microcontroller. What if that designer had to learn a new discipline, a new tool set and still make budget and a tight deadline?

Maybe twenty years in digital design didn't prepare that designer for the quirkiness that goes with analog signals from sensors, or for the challenges involved in writing a small, but bullet proof SPI interface code. Maybe the designer is well used to determining spring strength and durability but now has to design a small electronic circuit to replace that spring. What does that do to quality and reliability? Food for thought.

Duane Benson
Thought is hungry today

Red Ring of Death Solved?

I've been reading a lot lately on the supposition that the X-Box® red ring of death problem is caused by the lead-free BGA balls cracking under the BGAs due to thermal stress. In truth, I haven't seen any actual evidence that Pb-free solder and processing is related to the issue; just speculation.

RoHS has been with us for nearly four years now and in general, the Industry has a pretty good handle on how to make it work. However, Screaming Circuits has been studying a number of lead-free pc boards assembled in other places that have been sent to us for examination and possible rework.
Pb contamination has been in evidence in a number of these cases.

Unfortunately, rather than using a quality Pb-free solder paste, as is used in 4552402825986Screaming Circuits lead-free processing, the boards were assembled with Skippy® brand crunchy peanut butter. Jelly was not detected. As you can clearly see in the photo on right, Skippy brand crunchy peanut butter, while part of a healthy school lunch, and quite delightful when spread on fresh celery, is somewhat unsuitable for use as a lead-free solder paste. Contrast the solder joints above with the clean, quality solder joints as you find on boards processed at Screaming Circuits, shown on the bottom.

Not only does Screaming circuits NEVER use Skippy brand crunchy peanut butter in place of Pb-free solder paste, we x-ray inspect all BGA and leadless parts to detect any solder bridges, misaligned parts or unwanted peanut chunks.

Fuane Benson
It's leg pullin' time in Montana
Happy April Fool's Day!

Screaming Circuits introduces new Cordwood assembly service!

Tired of all those small parts? Can't figure out how to route traces to all 1,900 balls on that hot new FPGA? If 0201 passives have you running scared and the possibility of 01005 parts coming soon has you on the floor, Screaming Circuits has the answer.

Forget POP (Package on Package) and 0.4mm pitch - Take a few steps back and use our new Screaming CordwoodTM assembly process. It'll feel good to put your hands on a honk'n 2-Watt, through-hole resistor again. No need for fancy, multi-headed SMT assembly robots with Screaming Cordwood. No need for precision anymore. Just put those parts a quarter inch apart and you'll be suckin amps just like the good old days. And if you don't think it's high-tech enough; consider that Cordwood construction has taken man to the moon and back. You can't say that about surface mount!

And keep checking back for our soon to be released Vacuum Tube Value Valve process.

Fuane Benson
It's leg pullin' time in Kansas
Happy April Fool's Day!

Mysteries of Engineering

I (and many, many of us, presumably) have been reading more about all of the Toyota woes and the to-date unanswerable questions. Still, so much of the material written about the issues seems to be coming from the untrained. Certainly, human behavior suggests that some of these problems could be the result of operator error. But, I'm not an expert in human behavior, so I can't really say. And, certainly, problems do crop up in complex machinery, like cars. I don't know if that supposition falls within my area of expertise, but a few decades of operating motor vehicles gives me some personal empirical data on that one.

The area that does bother me the most is probably those that speculate that since the problem hasn't been found, it doesn't exist. This is an area where I can claim some level of expertise as well as plenty of personal empirical data.

It is possible to spend uncountable hours testing various possible conditions and still never uncover the one scenario that will cause a systems failure in the hands of the general public. Many years ago, I worked for a company that designed, built and sold projectors. In that day, these were big things with short-life, very hot, incandescent lamps. We thought that we had done a very through job of testing under various conditions and had been selling the product for a little while when reports started filing in of bulbs exploding. It wasn't just a simple break. The bulbs were exploding with such force that the bulb area was filled with a fine grained, razor sharp glass dust. Nasty.

ExplosionDuring a weekend burn in session with a couple dozen projectors, including some returned from the field, the engineer monitoring the process thought he heard a gunshot and dove to the floor. It wasn't a gunshot, but it was the first clue in a long investigative process that did end up finding the problem. It seemed that if a bulb was too deeply seated in the socket by a couple of millimeters, the reflection of the filament in the mirror would exactly line up with the actual filament, causing it to melt and arc. The arc would run in one direction, down the filament leg to the base and stop.

One filament leg had a few coils of small diameter tungsten wire wrapped around it. The other leg did not. Depending on the orientation of the supposedly non-polar bulb, the arc would either run down the leg with no coil or the leg with the coil.

If the arc ran down the leg without the coil, nothing happened other then the bulb needed to be replaced. If it ran down the leg with the coil, that small amount of additional vaporized tungsten increased the internal pressure sufficiently to explode the quartz bulb in a very catastrophic manner. Okay, now that's weird and obscure. Technically, you could call it operator error. If the customer had just inserted the replacement bulb the exact same way we inserted the bulbs during production, the problem would never have happened. But, realistically, it was a design flaw that set the customers up for a failure.

Duane Benson
Duck and cover

Is Geek Cool?

When I was young, "Geek" was not cool. Neither was "Nerd". Working on cars was cool as was logging and shooting Bambi's uncles with high powered rifles, at least where I came from things were that way. On the other hand, every little town had a Radio Shack where you could buy tubes, transistors, ICs and other assorted electronic components. You don't see that so much anymore. Grocery stores sold publications like Byte Magazine, 101 Electronics Projects and Radio Electronics. Those magazines were about building things. People who read and wrote those and others like them created an industry in their garages, basements and bedrooms. They started a new Industrial Revolution.

Still, back then, tech folks were more likely thought of as mad monks and strange people like Eddie Deezen as "Mr Potato head" (Malvin) in the 1983 movie War Games. You didn't want to be one. I like to think that attitudes have changed over the years, and I think the signs are there.

The FIRST Lego league with its robotics tournaments has created a legitimate "sports like" atmosphere for geek-types in school. 50,000 plus Arduinos being sold shows that the electronics hobbyist world is moving again like it did in the 80's. The maker and bender communities illustrated by Hackaday, Makezine and supported by companies like Adafruit and SparkFun show that creating with chips is as alive as it was in the late 70's and 80's. TV shows like Mythbusters, Jimmy Neutron and Prototype This have glorified the geek.

And why do we care? Because the more engineers we build out of the masses, the better we can design and build our economy. The more mainstream and acceptably technology is, the more educators will work to encourage and foster the environment and attitudes that allowed Apple, Dell, Google and SparkFun to thrive. We need that. We need robotics competitions to be as socially acceptable as football games.

Duane Benson
The rooms were so much colder then

Than Thara Wara Nona

I recently received an email comment about my blog writing that I think does a very good job of illustrating one of the frustrations that many design engineers face.

"Please have someone teach Duane the difference between "then" and "than". It really makes him look dumb, and I very much doubt that Duane is dumb. It's just painful see these everywhere in his blog. regards"

I've also been called out on "it's" vs. "its" before too. At least, I seem to mostly have the "to", "too" and "two" down. Now, I'm a reasonably educated person and writing is a significant part of my job, so you would think that I wouldn't fall into traps like this. Undeniably, I do. It drives me nuts. I even have a couple of websites that I refer to (when I think about it) to help with such things. Site one and site two, but obviously I still fall into the traps.

So, how does that relate to the frustrations of a design engineer? Well... read my blog. Most of my writing is about a very similar issue. Check this one about via in pad. And this one about parts libraries. Or this one about shorting potential under a QFN.

None of those problems were created by "dumb" people. Likely all of those boards were created by intelligent, highly skilled, well trained engineers - people who got picked on in school for blowing the curve, or were called "Spock" by the kids not on a college track. Yet, what does such an error get? It may get a blog post here. It may get a Twitter comment like this that I wrote about. Of course, some times silly little oversights like this have more dire or more expensive consequences.

And the moral of the story - attention to detail and continuous learning. Never stop trying to learn. Never stop double checking. I have to keep referring to my two grammar sites and other references. If you're a designer, never stop researching. Dig into those data sheets. Read up on best practices. If you're working a job over multiple sites, always make sure everyone's using the same rules.

Now over the next few days, I'm going to go back through my past posts and see how many of these "than/then" errors I can find and rework. Ugh.

Duane Benson
Never give up. Never surrender.

The Next Industrial Revolution - Is Happening In 1910

Matt, our product manager, sent me a couple of interesting links about the next Industrial Revolution. The first was an article in Wired Magazine by Chris Anderson. The second was a rebuttal in Gizmodo by Joel Johnson. Both had some interesting points. Both, as far as my thoughts go, have some truth and both have some silliness, again as far as my thoughts go.

RCA12ax7_sq_arms Regarding the idea that what is going is something new and revolutionary, well, maybe the products are new, but the process really isn't, but for a few specific details. A while back, the country was coming off of an economic down turn and a wholesale group of young folk with tools at hand built an industry in garages and barns. That was the auto industry.

All of those farm kids grew up around machinery. They all had the tools at hand and the knowledge to use them. Communications (teletype, telephone, newspapers) was changing the way information flowed around the country and world. Transportation (railroad and the autos/trucks that they were building) was in revolution and changing the accessibility of new markets.

Car companies were coming and going all over the place. Sound familiar? Then there was consolidation, conformity, near-monopoly, bloatware and then crash. Yeah, and the same thing started with electronics and computing back in the 60's, 70's and 80's. It's happening again now too. Big surprise. It happens whenever there is a convergence of the cycles of low-barrier to entry (good, cheap tools), emerging technology and bright young folks with time on their hands.

I see some of what Chris is talking about in our electronics manufacturing customers. I just have a bit of a different take on it. First, rather than seeing this all as new, I kind of feel like "here it goes again." Second, I think what he misses is the concept of scale. On certain scales, what he says is very true and very workable. However, companies that spend a few years developing their products would like to eat food and send their kids to college, so they need to earn money for that intellectual property they have developed. That being the case, they still need a place to build their things, but a place that wont steal that intellectual property and deny the company's kids their college education and food.

There's a place for the model Chris is describing. There's also a place for megalithic industry producing gajillions. And there's a place for companies like Screaming Circuits that cost more than open source but focus on making life easy for an engineer and can build prototypes or flexible low to mid volume manufacturing without the hassle of big industry or the risk of losing a livelihood to people with a very liberal interpretation of who owns what. (see #1101 in this post)

Duane Benson
Danger Will Robinson!

Want Data

RCA12ax7_sq_arms So, I tried to participate in this SparkFun "free day" this morning. They were giving out $100.00 worth of goodies for free per customer (up to a combined total of $100,000), starting at 9:00am MST (8:00am PST here in Oregon).

I was pretty excited about it and had decided to get a new PIC programmer and some pre-assembled jumper wires. I hate crimping those little things by hand. I put it on my calendar for the night before and again for that morning. Then, I found out that I had forgotten a dentist appointment at 8:00 that morning. Bummer.

Just in case it would take more than an hour to burn through that $100K, I went ahead and got ready. I logged in and put the items in my cart. I left the browser sitting there waiting. All I had to do was click the "Place Order" button when I returned after getting my teeth scraped.

But, alas, when I got back, the site was timed out and not accessibly. I refreshed, tried a different browser, refreshed again, etc. I did once get enough of the site to load to see that they had only sold through about $19,000 thus far. Okay. That's not so bad. I could finish making my latte and get in to the office. Maybe try there.

Then, at the office, I was never able to get anything at all from the site to load. All full up. I had to go to a meeting at 10:00 and I thought that if they stayed at around $20K per hour, I might just have a chance of getting through when the meeting was over. But, it was not to be. When I checked in again at 11:30, all $100,000 was sold through. My guess is that so many people were trying in the first hour that the servers only had enough bandwidth to process $20K. After that, enough people gave up trying that the hardware could get the final $80K through in the next 44 minutes ad 50 seconds.

Now here's where my quest for data comes in. I was never able to get more then one click into the process. If all connections were equal, I would presume that everyone would have had the same results. Even if by random chance, someone found a pause long enough to get one page loaded, the chances of each subsequent step would drop astronomically. So, what is it about the Internet that gives some people priority over others? I'd love to see a geographic overlay of the folks that got an order placed combined with their distance from a backbone. Is it distance from a backbone (in hops or in miles) or is it distance from the SparkFun server?

In any case, good for them. It was a fun idea and great gesture of "thanks" Bummer for the inability to handle the load. Here's a Twitter quote from Chris Anderson on the subject: "Google's servers can't keep up with Nexus demand; Free Day brings down Sparkfun. It's 2010--why do we still have these scaling problems?" Ironically, when I first went to Twitter to copy that quote, Twitter was reporting over capacity and I had to wait a while for all the tweets to come back.

Duane Benson
If only my packets were more aggressive...