editor's blog
Subscribe Now

Just What Is the New IEEE Sensor Standard?

IEEE published a sensor-related standard recently. And, depending on what headline or report you read, you may end up with a wide variety of conclusions as to what it’s all about. The original press release linked it to an eHealth memorandum of understanding (MOU) between IEEE-SA and the MEMS Industry Group (MIG); NIST issued a press release regarding their participation; and various stories described it as a “sensor hub” standard.

All of which surprised me, because I was only aware of one standard effort underway, and it was none of those things. Well, not directly, anyway. Of course… things can happen without my knowing about them, so I scrambled to see what I had missed.

Turns out I hadn’t missed anything. This P2700 standard is the very same one we overviewed in May of 2013. Which is nine months before the eHealth MOU. It’s about sensor datasheet parameters. It’s also part of a process in which NIST was indeed involved, although the specific effort was spearheaded by a number of companies (as described in a yet earlier overview of MEMS standards efforts); NIST was in the list of acknowledgments, not the list of contributors. It is fair to say that some of the discussion probably got a start in yet another NIST effort regarding MEMS testing that predated all of this.

But the bottom line is that the main motivator was the fact that different sensor manufacturers were defining their datasheet parameters differently, making it impossible to compare one sensor’s performance to that of another. This is a fundamental driver of standards, and has been for a long time.

Here are the purpose and scope of the standard, as included in the draft submitted to IEEE:

1.1 Purpose of Document

This document presents a standard methodology for defining sensor performance parameters with the intent to ease system integration burden and accelerate TTM. Here within, a minimum set of performance parameters are defined with required units, conditions and distributions for each sensor. Note that these performance parameters shall be included with all other industry accepted performance parameters.

1.2 Document Scope

This document is intended to drive the sensor industry toward common nomenclature and practices as cooperatively requested by mobile platform architects. It clearly outlines a common framework for sensor performance specification terminology, units, conditions and limits. The intent is that this is a living document, scalable through future revisions to expand as new sensors are adopted by the platforms. The intended audience of this document is sensor vendors, ISVs, platform providers and OEMs.

Can the sensors affected by this be used in eHealth? Yes, of course. And all kinds of other things. It’s not specifically eHealth-related.

Was NIST involved? Yes, as was MIG, although more with coordination than with content.

Will the sensors involved in this standard be connected to sensor hubs? Undoubtedly. Will the sensor hub code be simplified, as claimed in some stories? That’s actually not clear to me. Sensor hubs need to talk to sensors, extract their values, and compute with them. There’s nothing in the standard that deals with how that’s done.

I suppose that, when doing sensor fusion, some adjustment algorithms might be needed to adapt to different sensors if the readings from different manufacturers mean different things. Then again, this standard is about what’s in the datasheet and the testing conditions for different parameters; it’s not clear if that affects the actual readings. I don’t think any chips are changing as a result of the standard.

One other quick note regarding IEEE. There are actually 2 flavors of IEEE, as we discussed a few years back. There’s IEEE-SA (“Standards Association”) and IEEE-ISTO (“Industry Standards and Technical Organization”). One is more “independent,” with a thorough vetting process; the other allows companies sponsoring efforts to keep some control over the process. It had been a while since I thought about that, and so I wanted to be sure about which IEEE this standard had gone through.

IEEE-SA is the traditional arm of IEEE. So this standard has received the nod from the more exacting side of IEEE. And it did so in relatively short time (for IEEE), with little in the way of change to the original submitted draft, as told to me by IEEE-SA’s Director of Global Business Strategy and Intelligence, Alpesh Shah.

All of which means that the team that put the draft together did yeoman’s work.

Leave a Reply

featured blogs
May 12, 2021
The ICADVM20.1 ISR18 and IC6.1.8 ISR18 production releases are now available for download at Cadence Downloads . For information on supported platforms and other release compatibility information,... [[ Click on the title to access the full blog on the Cadence Community site...
May 11, 2021
Human vision in indispensable and often taken for granted. Similarly machine, or embedded, vision influences daily human life in ways thought impossible. Simply, machine vision refers to the ability of embedded systems to “see”. Key system components include camer...
May 6, 2021
Learn how correct-by-construction coding enables a more productive chip design process, as new code review tools address bugs early in the design process. The post Find Bugs Earlier Via On-the-Fly Code Checking for Productive Chip Design and Verification appeared first on Fr...
May 4, 2021
What a difference a year can make! Oh, we're not referring to that virus that… The post Realize Live + U2U: Side by Side appeared first on Design with Calibre....

featured video

The Verification World We Know is About to be Revolutionized

Sponsored by Cadence Design Systems

Designs and software are growing in complexity. With verification, you need the right tool at the right time. Cadence® Palladium® Z2 emulation and Protium™ X2 prototyping dynamic duo address challenges of advanced applications from mobile to consumer and hyperscale computing. With a seamlessly integrated flow, unified debug, common interfaces, and testbench content across the systems, the dynamic duo offers rapid design migration and testing from emulation to prototyping. See them in action.

Click here for more information

featured paper

Bring a "Can-Do" Attitude to Your Industrial Drone Design

Sponsored by Maxim Integrated

Providing predictable and error-free communications, CAN bus networks have been the workhorse of the automobile industry for over thirty years. But they have recently found a new lease on life in other industrial applications, including drones. This design solution shows where and how CAN transceivers can be used in drone designs and explains why it is important that they come with high levels of electrical protection.

Click to read more

Featured Chalk Talk

Easy Hardware and Software Scalability across Renesas RA MCUs

Sponsored by Mouser Electronics and Renesas

There are a bewildering number of choices when designing with an MCU. It can be a challenge to find one with exactly what your design requires - form factor, cost, power consumption, performance, features, and ease-of-use. In this episode of Chalk Talk, Amelia Dalton chats with Brad Rex of Renesas about the small-but-powerful Renesas RA family - a flexible and scalable collection of MCUs that may be exactly what your next project needs.

Click here for more information about Renesas Electronics RA Family Arm® Cortex® Microcontrollers