Screaming Circuits: General interest

How Fast Is Fast? I Mean, Really?

We talk a lot about speed here at Screaming Circuits. Back in 2003, one of the main reasons our parent company started us up was because their customers were telling them that they needed prototypes faster.

So, I know that getting everything built is faster these days - we can ship fully built boards as fast as 24 hours after we receive a kit, and you can get the raw fabbed PCBs in a day too. Certainly, everyone knows that you can place an order with Digi-Key and have the parts on your desk (or in our shop) the next morning. But has the rest of the process gotten faster too? [See if you can find the shameless plug in there. Sorry]

Whether you're using Sunstone PCB123, Ultiboard, Eagle, Pads, Altium, Allegro, or any of the common Bb input pwr sect CAD packaged, you'll probably spend most of your prototyping time in the software. It's also probably the least predictable segment of the process.

What takes longer? The schematic capture or the layout? Or are both completely variable and totally unpredictable? If your boss came running into your office and said:

"Bob! Quick! We just spilled something. We need an underwater temperature sensor with a video camera that can send a real-time temperature data stream and live video feed a mile back a cable to a host computer. And we need it NOW!"

How long would "NOW" take for you?

Duane Benson
Changing your reaction to the duration of time since 2003...

Don't Do It

Friends don't let friends wire-wrap.

Quit with the wire-wrap already.
Do people still do this? Do you still do this? When's the last time you did some wire-wrap?

Digi-Key still sells an assortment of wire-wrap wire and wrapping tools, including the simple little hand tool that I own priced at - holy mackerel! - for $34.35! I should sell mine on ebay. Somebody must still be doing this if they've got such a nice selection. Amazing.

Duane Benson
Who wants spaghetti?

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.