Forget IoT – Focus on AFE
Bob Frostholm — JVD, Inc
I remember maybe 30 years ago or more when the Internet was just getting popularized and no one really understood it, analogies were made to the Interstate Highway System (officially called National Interstate and Defense Highways Act) enacted by President Eisenhower in 1956. We were told to think of the wires and optical cables as the roads, the data packets as the cars and trucks and the really important stuff, the information content embedded in the packets, as the people and cargo being moved from Point A to Point B.
If you think about it, the highway system was pretty secure back in the day. There weren’t a lot of highwaymen stopping folks and robbing them along the way. And “Things” (homes and businesses) were pretty well connected… You could mail a letter or send a parcel to anyone who had an address or access to a general post office. And you could make a wireline phone call to most people. And, with enough time and persistence, you could get yourself just about anywhere in the world.
According to multiple internet sources, Kevin Ashton is credited with coining the term “Internet of Things” to describe a system he was working on at Proctor & Gamble in the late ‘90s, where the Internet is connected to the physical world via ubiquitous sensors…in his example, RFID to manage inventory. Since then, the term has been used and abused to the point that we’ve all become numb to it. In fact, when I see IoT in an article, I generally stop reading because I figure from that point on there will be little new to learn. I’m being sarcastic… please read on.
While the roads that carry the cars and trucks and wires that carry our voices are critical to the successful delivery of the intended cargo, isn’t it the cargo itself that’s important? It seems to me we’ve lost track of that along the way. Therefore, I declare that for me it’s no longer IoT, but EoT… “Enough of This”. What I care about is content; the cargo.
Let’s focus on the cargo… the information that we are so desperate to move from here to there and back again. When you order something online and it arrives the next day, what’s the first thing that comes to your mind? How it got to you? The fact it was put into a box (a small packet), loaded into a truck (a larger packet), driven to your door (using a highway)? That’s the physical analogy to the Internet… how it got from Point A to Point B. As long as you got it, do you really care how it got there? … how many frequent flier miles it accumulated along the way? I don’t. I’m concerned about what’s inside the box. Is it what I ordered? Is it the right color? Is it the right size? We all care about the cargo, not how we got it.
An IoT concern we read about daily is interoperability…getting one network to talk to another. Different standards are needed for a host of reasons…power consumption, isolation, bandwidth, security and much more. One network is not feasible…just like in the earlier example, moving cargo from Honolulu to San Francisco (boat/airplane) cannot be accomplished on that same network when moving it from San Francisco to Mountain View (road). Interoperability concerns are nothing new. They’re just much more complicated. Protocol conversions can be cumbersome. Speaking of which, a great list of IoT Standards and Protocols can be found at: Internet of Things Protocols
I fear that the maniacal focus on the Internet of Things diverts our attention from the quality of the content we receive which is determined not by the means by which we receive it but by the source from which it came. Forget the roads and shipping lanes and focus on the content.
A big buzz word associated with IoT is sensors; those ubiquitous devices that sense something (usually analog) and then digitize it before passing that information along a circuitous route over multiple protocols to a destination where something will decode and act on the received information.
However, sensors need an interface circuit to process the phenomenon they observe whether photons, aeromantic hydrocarbons, sounds, pressure, radiation, chemical reactions or any of thousands of other physical attributes. That information is digitized and forwarded to the MCU. These circuits are often referred as Analog Front-End (AFEs). AFEs consist of a biasing circuit, amplifier, comparators, digital to analog convertor (DAC), analog multiplexers, voltage references, a filter network for noise suppression and error suppression techniques like offset removal, and an analog to digital converter (ADC) to digitize the sensor data.
A massive amount of effort goes into preserving the integrity of the original signal as these transitions take place. What really counts is the content. And accurate content is a first order function of the Analog portion of the signal chain. Sure, things can still go wrong once the information is digitized, but the inherent noise immunity of digital plus the availability of FEC and other error correction techniques make it less likely the be the source of a problem. Let’s forget about the “Internet” part of the IoT equation and focus the “Things”….and the heart of the issue, the Analog Front End of the Signal Chain.
This is the make or break portion of the device. When something goes wrong, when unexpected results are observed, this is the place to begin trouble shooting. Unfortunately, this is also often the least understood portion of your design. Why? Because you more than likely relied on someone else to design it for you…perhaps using off the shelf precision analog ICs from a reputable company like Linear Technology (aka Analog Devices), Texas Instruments, STMicro or another quality analog supplier. Yes, maybe your engineers put the blocks together (see diagram above) but the heavy lifting…the difficult analog design in each chip …was done by one of these guys.
Today, many new microcontrollers contain most if not all of the above referenced blocks on a single chip but the analog portion’s specifications may not meet your exact needs. A “fits most applications” all-in-one-microcontroller IC may not fit yours, forcing you to individually select each critical analog elements and marry them to a basic microcontroller. Assembling these elements can sometimes make your end product too big…especially of it is a wearable medical device. It’s not an insurmountable problem. Your next course of action is to seek out an ASIC company with Analog capability. There are hundreds, perhaps thousands, to choose from.
However, selecting the right ASIC company to meet your needs can in fact present a challenge. Analog ASICs, especially those requiring precision, accuracy, noise immunity and near zero power consumption require highly trained analog design engineers who are equally adept at understanding semiconductor wafer fabrication processes including device design and process development to make the perfect marriage between the application and sensor’s environment.
Sensor parameters can be intimidating to those not fully versed in the field. A real world pressure sensor requirement may include:
- Pressure range 300 … 1100 hPa (equiv. to +9000…-500 m above/below sea level)
- Relative accuracy ±0.12 hPa, equiv. to ±1 m
- Temperature coefficient offset 1.5 Pa/K, equiv. to 12.6 cm/K
The matching AFE parameters can be equally stringent.
- ADC: 22 bit
- Current consumption 2.7μA
- Temperature range -40 … +85 °C
- Equivalent noise contribution from the ASIC: <10LSB
- 20 bit internal temperature sensor
- Support I2C and SPI
- 64 byte OTPROM
- Standby Current 0.015uA
When investigating Analog ASIC suppliers, be sure they have the resident analog skills to meet your needs. It is not possible for every Analog ASIC company to have the depth of technical resources to cover 100% of all possible requirements. What is important is that the one you select has as much as possible and has the ability to easily contract the rest. Don’t be misled by the Analog ASIC pretenders, those companies who make false claims about their capabilities. AFEs can be the most difficult chips to design.
Analog IC design is not something learned in schools. It is learned on the job by sitting next to and working with experienced mentors for decades. Yes, I said decades. Each member of the design team you engage should possess at least 20 yrs of Analog IC design experience. Don’t let your project get assigned to a “B” team or “C” team.
Look around. The world is analog. Converting physical phenomena to electronic signals that can then be digitally manipulated requires extreme precision if the end result is to be meaningful. A highly integrated ASIC AFE allows you to tailor the design to precisely meet your application’s needs. No more selecting off the shelf components that “almost” do everything you want. Working with a highly skilled design team allows you to offload this heavy lifting and concentrate on other aspects of the system requirements.
About Us: JVD is a privately-held company founded in 1982 whose mission is to achieve analog performance in their customers ASIC designs. Whether an ASIC, ASSP, or SoC design, JVD’s differentiated analog approach allows its customers to compete successfully in consumer, wireless, high-speed computing, power management, medical, industrial and networking applications. For more information, please visit www.jvdinc.com
Bob Frostholm, Vice President, Marketing & Sales at JVD Analog ASIC
Semiconductors. (San Jose, CA.)
Email: bob [dot] frostholm [at] jvdinc [dot] com
Bob has held Sales, Marketing and CEO roles at established and startup Analog Semiconductor Companies for more than 45 years. Bob was one of the original marketers behind the ubiquitous 555 timer chip. After 12 years with Signetics-Phillips, Fairchild and National Semiconductor, he co-founded his first startup in 1984, Scottish based Integrated Power, which was sold to Seagate in 1987. He subsequently joined Sprague’s semiconductor operations in Massachusetts and helped orchestrate its sale to Japanese based Sanken Electric, creating what is now known as Allegro Microsystems. In 1999, as vp sales and marketing, he rejuvenated sales revenues and facilitated the sale of SEEQ Technology to LSI Logic. Bob is the author of several technical articles and white papers and in his spare time, an occasional screenplay. Other interests include Home Remodeling, Amateur Radio, Porsche Club Activities and Grandkids. Email: bob [dot] frostholm [at] jvdinc [dot] com