New Kind Of Transistor Radios Shows Capability Of Nanotube Technology

The nanotube radios, in which nanotube devices provide all of the active functionality in the devices, represent “important first steps toward the practical implementation of carbon-nanotube materials into high-speed analog electronics and other related applications,” said John Rogers, a Founder Professor of Materials Science and Engineering at the University of Illinois.

Rogers is a corresponding author of a paper that describes the design, fabrication and performance of the nanotube-transistor radios, which were achieved in a close collaboration with radio frequency electronics engineers at Northrop Grumman Electronics Systems in Linthicum, Md.

“These results indicate that nanotubes might have an important role to play in high-speed analog electronics, where benchmarking studies against silicon indicate significant advantages in comparably scaled devices, together with capabilities that might complement compound semiconductors,” said Rogers, who also is a researcher at the Beckman Institute and at the university’s Frederick Seitz Materials Research Laboratory.

Practical nanotube devices and circuits are now possible, thanks to a novel growth technique developed by Rogers and colleagues at the U. of I., Lehigh and Purdue universities, and described last year in the journal Nature Nanotechnology.

The growth technique produces linear, horizontally aligned arrays of hundreds of thousands of carbon nanotubes that function collectively as a thin-film semiconductor material in which charge moves independently through each of the nanotubes. The arrays can be integrated into electronic devices and circuits by conventional chip-processing techniques.

“The ability to grow these densely packed horizontal arrays of nanotubes to produce high current outputs, and the ability to manufacture the arrays reliably and in large quantities, allows us to build circuits and transistors with high performance and ask the next question,” Rogers said. “That question is: ‘What type of electronics is the most sensible place to explore applications of nanotubes”‘ Our results suggest that analog RF (radio frequency) represents one such area.”

As a demonstration of the growth technique and today’s nanotube analog potential, Rogers and collaborators at the U. of I. and Northrop Grumman fabricated nanotube transistor radios, in which nanotube devices provided all of the key functions.

The radios were based on a heterodyne receiver design consisting of four capacitively coupled stages: an active resonant antenna, two radio-frequency amplifiers, and an audio amplifier, all based on nanotube devices. Headphones plugged directly into the output of a nanotube transistor. In all, seven nanotube transistors were incorporated into the design of each radio.

In one test, the researchers tuned one of the nanotube-transistor radios to WBAL-AM (1090) in Baltimore, to pick up a traffic report.
Links: http://www.sciencedaily.com/releases/2008/01/080129125521.htm

Doing design and debug on real-time distributed embedded applications

Real-time system designers and embedded software developers are very familiar with the tools and techniques for designing, developing and debugging standalone or loosely coupled embedded systems. UML may be used at the design stage, an IDE during development and debuggers and logic analyzers (amongst other tools) at the integration and debug phases.

However, as connectivity between embedded systems becomes the norm, what used to be a few nodes connected together with clear functional separation between the applications on each node, is now often tens or hundreds of nodes with logical applications spread across them.

In fact, such distributed systems are becoming increasingly heterogeneous in terms of both operating systems and executing processors with tight connectivity between real-time and enterprise systems becoming the norm.

This article will identify the issues of real-time distributed system development and discuss how development platforms and tools have to evolve to address this challenging new environment.

The idea of a ‘platform’ for development has long pervaded the real-time embedded design space as a means to define the application development environment separately from the underlying (and often very complex) real-time hardware, protocol stacks and device drivers.

Much as the OS evolved to provide the fundamental building blocks of standalone system-development platforms, real-time middleware has evolved to address the distributed-systems development challenges of real-time network performance, scalability and heterogeneous processor and operating system support.

And as has already happened in the evolution of the standard real-time operating system, new tools are becoming available to support development, debug and maintenance of the target environment ” in this case, real-time applications in large distributed systems.

The Distributed-System Development Platform
From the individual application developer’s perspective, there are three basic capabilities which must be provided by an application development platform when a logical application spans multiple networked computers:

1. Communication between threads of execution
2. Synchronization of events
3. Controlled latency and efficient use of the network resources

Communication and synchronization are fairly obvious distributed platform service requirements and are analogous to the services provided by an OS. However for distributed applications they have to run transparently across a network infrastructure of heterogeneous OS’s and processors with all that implies in terms of byte ordering and data representation formats.

It should ideally use a mechanism that does not require the developer to have an explicit understanding of the location of the intended receiver of a message or synchronizing thread so that the network can be treated as a single target system from an application development perspective.
Links: http://embedded.com/design/networking/205920767

Understanding the LIN PHY (physical) layer

The physical layer of the Local Interconnection Network is a key part of this automotive networking standard; it has unique attributes of which designers should be aware.

The Local Interconnection Network (LIN) standard defines a low cost, serial communication network for automotive distributed electronic systems. LIN is a complement to the other automotive multiplex networks, including the Controller Area Network (CAN), but it targets applications that require networks that do not need excessive bandwidth, performance, or extreme fault tolerance.

LIN enables a cost-effective communication network for switches, smart sensors and actuator applications inside a vehicle. The communication protocol is based on the SCI (UART) data format, a single-master/multiple-slave concept, a single-wire (plus ground) 12 V bus, and a clock synchronization for nodes without a precise time base (i.e., without a crystal or resonator).

Typical LIN applications are associated with body-control electronics for occupant comfort, such as assembly units for doors, steering wheel, seats and mirrors, and motors and sensors in climate control, lighting, rain sensors, smart wipers, intelligent alternators and switch panels. With LIN, automotive subsystem designers can connect modules for these applications to the car’s network and then have them accessible for a variety of diagnostics and services.

LIN versus CAN

Compared to CAN, LIN offers the advantage of lower cost per node when the bandwidth and performance of CAN is not needed. LIN’s lower cost results from the use of single-wire communications, a lower implementation cost due to its lower UART complexity versus CAN, and need for crystals or ceramic resonators in the slave nodes.

The tradeoff for LIN’s lower cost is the more restrictive nature of a single-master network and lower bandwidth, Table 1.

Links: http://embedded.com/design/205920657

How to roll your own linux distro

DIY: Do It Yourself. That’s how Linux got started. A group of volunteers, inspired and led by Linus Torvalds, created the greatest DIY operating system the world has ever seen. You, too, can create your own Linux distribution. Here’s how.

It sounds daunting, and there’s a lot that’s definitely not for beginners. But in terms of what you can learn along the way and what you end up with, it’s on a par with building your own PC from scratch. Granted, as with building a PC from scratch, there are still plenty of reasons to buy something off the shelf — or to grab an existing distribution and simply use that. That said, there are a few solid rationales for rolling your own distro:

For education. Sometimes the best way to get to know something is just to stick your hands under the hood and get ‘em dirty — with a little guidance, of course. There’s no guarantee that you’ll get to know everything, but you will gain a fearlessness about the process of learning and a sense of where to go to get answers about something (and how to get those answers) that you may not get by simply installing a populist’s distribution and getting quotidian work done.

For specific problem-solving or filling a gap. If there’s some oddball hardware configuration that you want to work with, for instance, you can create a customization of a given distribution to work well with that hardware. This might be something as simple as adding kernel-level support for a given device, or something more elaborate. Or maybe you want to create a distribution that fills a very specific need. (A while back, I wrote about Hikarunix, a sadly-now-discontinued distribution devoted to Go players; it doesn’t get more specialized than that.)

For fun. I call this the “why not?” rule. Linux exists to be tinkered with, so tinker with it, and have a blast. Obviously you won’t want to trust any production data to a system you’re doing such work with, but that’s no reason you can’t have fun with it. And if something gets messed up, you can always wipe the slate clean and start over. (After all, you’re not doing any of this in a production environment, right?)

Links:  http://embedded.com/columns/technicalinsights/205918715

The Bathtub Curve and Product Failure Behavior

Reliability specialists often describe the lifetime of a population of products using a graphical representation called the bathtub curve. The bathtub curve consists of three periods: an infant mortality period with a decreasing failure rate followed by a normal life period (also known as “useful life”) with a low, relatively constant failure rate and concluding with a wear-out period that exhibits an increasing failure rate. This article provides an overview of how infant mortality, normal life failures and wear-out modes combine to create the overall product failure distributions. It describes methods to reduce failures at each stage of product life and shows how burn-in, when appropriate, can significantly reduce operational failure rate by screening out infant mortality failures. The material will be presented in two parts. Part One (presented in this issue) introduces the bathtub curve and covers infant mortality and burn-in. Part Two (presented in next month’s HotWire) will address the remaining two periods of the bathtub curve: normal life failures and end of life wear-out.

The bathtub curve, displayed in Figure 1 above, does not depict the failure rate of a single item, but describes the relative failure rate of an entire population of products over time. Some individual units will fail relatively early (infant mortality failures), others (we hope most) will last until wear-out, and some will fail during the relatively long period typically called normal life. Failures during infant mortality are highly undesirable and are always caused by defects and blunders: material defects, design blunders, errors in assembly, etc. Normal life failures are normally considered to be random cases of “stress exceeding strength.” However, as we’ll see, many failures often considered normal life failures are actually infant mortality failures. Wear-out is a fact of life due to fatigue or depletion of materials (such as lubrication depletion in bearings). A product’s useful life is limited by its shortest-lived component. A product manufacturer must assure that all specified materials are adequate to function through the intended product life.

Note that the bathtub curve is typically used as a visual model to illustrate the three key periods of product failure and not calibrated to depict a graph of the expected behavior for a particular product family. It is rare to have enough short-term and long-term failure information to actually model a population of products with a calibrated bathtub curve.

Also note that the actual time periods for these three characteristic failure distributions can vary greatly. Infant mortality does not mean “products that fail within 90 days” or any other defined time period. Infant mortality is the time over which the failure rate of a product is decreasing, and may last for years. Conversely, wear-out will not always happen long after the expected product life. It is a period when the failure rate is increasing, and has been observed in products after just a few months of use. This, of course, is a disaster from a warranty standpoint!

We are interested in the characteristics illustrated by the entire bathtub curve. The infant mortality period is a time when the failure rate is dropping, but is undesirable because a significant number of failures occur in a short time, causing early customer dissatisfaction and warranty expense. Theoretically, the failures during normal life occur at random but with a relatively constant rate when measured over a long period of time. Because these failures may incur warranty expense or create service support costs, we want the bottom of the bathtub to be as low as possible. And we don’t want any wear-out failures to occur during the expected useful lifetime of the product.

Links: 

http://www.weibull.com/hotwire/issue21/hottopics21.htm

http://www.itl.nist.gov/div898/handbook/apr/section1/apr124.htm