IEEE-P1451.2 Smart Transducer Interface Module Stan P. Woods Janusz Bryzek, Ph.D. Steven Chen Jeff Cranmer Edwin Vivian El-Kareh Mike Geipel Fernando Gen-Kuong John Houldsworth Norm LeComte Kang Lee Michael F. Mattes David E. Rasmussen Hewlett-Packard Company Intelligent MicroSensor Technology Aeptec Microsystems Lucas Control Systems Products AB Networks Eurotherm Controls Endevco Eurotherm Controls Texas Instruments National Institute of Standards and Technology SSI-Controls Technology Hewlett-Packard Company Abstract This paper provides a technical overview of the smart transducer interface module (STIM), the key element of the proposed IEEE-P1451.2 Draft Standard for Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheets (TEDS) Formats. The draft standard is released for balloting as of August, 1996. Objectives and genealogy of this standard are summarized. Key technical innovations such as the TEDS, representation of physical units, general calibration model, triggering of sensors and actuators, variable transfer rate between a host and the STIM, and support for multivariable transducers are briefly discussed. Detailed descriptions of the STIM, TEDS, digital interface, and plugand-play operation are also provided. The specifics of physical units encoding, an example of a TEDS, and an example of timing requirements for taking a sensor reading are also included to aid the overview. 1. Objectives of IEEE-P1451 The Draft Standard for A Smart Transducer Interface for Sensors and Actuators, IEEE-P1451, aims at simplifying transducer connectivity to existing networks. IEEEP1451 consists of two parts: • P1451.1, developing a network independent common object model for smart transducers. • P1451.2, enabling connection of transducers to net- work microprocessors. 2. Introduction Imagine that you can: • Select the transducer best suited to solve the measurement or control problem independently of the selected control network. • Use the same transducers on multiple control networks. • Select the control network best suited for the application without transducer compatibility constraints. • Achieve automatic self-configuration when a transducer is connected to a network microprocessor. These are goals the IEEE-P1451.2 Smart Transducer Interface1 is helping to meet. This paper describes the progress made to date by the IEEE-P1451.2 Transducer to Microprocessor Working Group to facilitate the ease of connecting transducers to microprocessors. At the core of this effort is a transducer electronic data sheet (TEDS), which is a data structure stored in a small amount of nonvolatile memory, physically associated with the transducer. The TEDS is used to store parameters which describe the transducer to the network capable application processor (NCAP), making self-identification of the transducer to a system possible. The working group has defined the contents of the TEDS and a digital hardware interface to access the TEDS, read sensors, and set actuators. The resulting hardware partition encapsulates the measurement aspects2 in a smart transducer interface module (STIM) on one side of 1 These goals are being met in combination with IEEE1451.1 which is not covered in this paper. 2 Covered by P1451.2. the digital interface, and the application related aspects3 on the NCAP. This paper describes the hardware block diagram of the STIM, including the TEDS and the digital interface. 3. Background Control networks provide many benefits for transducers,4 such as: • Significant reduction of installation costs by eliminating long and large numbers of analog wires. • Acceleration of control loop design cycles, reduction of commissioning time, and reduction of downtime. • Dynamic configuration of measurement and control loops via software. • Addition of intelligence by leveraging the micro- processors used for digital communication. One major problem for analog transducer manufacturers is the large number of networks on the market today. It is currently too costly for many transducer manufacturers to make unique smart transducers tailored for each network on the market. In September 1993, the proposal of developing a smart sensor communication interface standard was accepted by IEEE-TC9.5 In March, 1994, the National Institute of Standards and Technology (NIST) and the Institute of Electrical and Electronics Engineers (IEEE), hosted a first workshop to discuss smart sensor interfaces and the possibility of developing a standard interface that would simplify connectivity of smart transducers to networks. Since then, a series of four more workshops have been held and two technical working groups formed in February, 1995: • The P1451.1 working group concentrating on a common object model for smart transducers along with interface specifications to the model [1] [2] [3]. • The P1451.2 working group concentrating on defining the TEDS, the STIM, and the digital interface including connector pin allocation and a com-munication protocol between the STIM and the NCAP [1] [4]. 4. Key technical features Figure 1A. depicts a STIM and the associated digital interface as described in the P1451.2 draft. The STIM is shown here under the control of a network-connected microprocessor. In addition to their use in control networks, STIMs can be used with microprocessors in a variety of applications such as portable instruments and data acquisition cards as shown in Figure 1B. The STIM embodies specific unique features of this proposed standard, which are briefly described below. 4.1 Single general purpose TEDS The TEDS as presently defined supports a wide variety of transducers with a single general purpose TEDS structure.6 This approach makes the rest of the system easier to implement and the implementation scaleable. If specific fields are not required for a given transducer, these fields have zero width, saving the required memory. 4.2 Representation of physical units The P1451.2 draft adopts a general method for describing physical units sensed or actuated by a transducer. The method, described in the table in Appendix A, employs a binary sequence of ten bytes to encode physical units. A unit is represented as a product of the seven SI7 base units and the two SI supplementary units, each raised to a rational power. This structure encodes only the exponents; the product is implicit. Appendix A contains examples for distance, pressure, acceleration, and strain. The U/U forms (enumerations one and three in Appendix A) are for expressing “dimensionless” units such as strain (meters per meter) and concentration (moles per mole). The numerator and denominator units are identical, each being specified by subfields two through ten [5]. 3 Covered by P1451.1. 4 “Transducer” is defined by IEEE-P1451 working groups as either a sensor or an actuator. 5 Technical Committee 9 (TC-9) on Sensor Technology of the Instrumentation and Measurement Society 6 As opposed to creating a unique TEDS structure for each kind of transducer: for example, one TEDS structure for temperature sensors and another TEDS structure for servo actuators, each structure with unique required fields. 7 Le Système International d’Unités Network DCLK DOUT DIN Network Capable Application Processor (NCAP) or Host Microprocessor NIOE NTRIG NTRACK NIO_INT +5 V Common Interface logic TEDS Signal conditioning and conversion Transducer #1 . . . Transducer #255 STIM Networked sensors Data acquisition cards Portable instruments (Networking / P1451.2 digital (Encapsulated application) interface measurement) A) = P1451.2 transducer B) Figure 1: Hardware partition proposed by P1451.2 and possible uses for the interface 4.3 General calibration model The P1451.2 draft provides a general model to optionally specify the transducer calibration. It is very flexible yet can collapse to an acceptable size for a simple linear relationship. The scheme supports a multi-variable, piecewise polynomial with variable segment widths and variable segment offsets. 4.4 Triggering of sensors and actuators The proposed digital interface has hardware trigger lines to allow the NCAP to initiate sensor measurements and actuator actions, and to allow the STIM to report the completion of the requested actions. The NCAP can trigger an individual channel, or all transducer channels at once. In the latter case, there are TEDS fields provided to specify timing offsets between the STIM’s channels and to determine when each measurement or actuation has occurred relative to the single trigger acknowledgment. The draft proposes that the slowest channel be the reference channel and that all the offsets be specified relative to this channel. 4.5 Variable transfer rate between host and STIM The hardware data clock line is driven by the NCAP. There is a field in the TEDS which specifies the maximum data transport rate that the STIM can support. This provides a flexible mechanism to match NCAPs and STIMs. 4.6 Support for multi-variable transducers P1451.2 includes support for multi-variable transducers in a single STIM. A STIM may have up to 255 inputs or outputs allowing the creation of multi-variable sensors, actuators, or combinations thereof. Several multi-variable STIM examples are shown in Figure 3. 5. STIM Figure 2 shows the block diagram for a STIM, along with the interfaces between each module. A TEDS is incorporated into a STIM. In addition to the TEDS, the STIM contains logic to implement the P1451.2 interface, the transducer, and any necessary signal conditioning and signal conversion.8 Only interface “A” is defined by P1451.2. Interfaces “B”, “C” “D”, and “E” allow transducer manufacturers to continue to obtain competitive differentiation in areas of performance, quality, feature set, and cost by choosing how these interfaces are implemented. At the same time P1451.2 offers the opportunity to design transducers to a common interface between a STIM and NCAPs enabling the use of the same transducer across many networks and applications [6]. The first example in Figure 3A demonstrates a single channel analog sensor implementation. A) Temperature sensor STIM P1451.2 9 Micro-controller ADC TEDS Temperature sensor STIM B) Eight channel digital I/O STIM P1451.2 9 Micro-controller TEDS In Out STIM P1451.2 9 A P1451.2 logic block Signal conversion Signal Transducer conditioning (Sensor or Actuator) TEDS C D E B STIM Figure 2: STIM block diagram The P1451.2 logic block shown in Figure 2 may be implemented in several ways. The working group has now implemented STIMs using a field programmable gate array (FPGA) and a low-cost microcontroller to serve as the logic block. These methods demonstrate that P1451.2 STIMs can be built today using off-the-shelf parts. The microcontroller option provides the additional advantage of potentially combining all the logic, TEDS, and signal conversion into one integrated circuit, where the P1451.2 logic block is implemented using microcontroller firmware. Figure 3 shows four examples of STIM configurations using a low-cost microcontroller. These examples demonstrate the flexibility in STIM design provided by P1451.2. 8 Signal conditioning and signal conversion are not covered by P1451.2. C) Four channel sensor STIM P1451.2 9 Micro-controller TEDS ADC STIM Temperature sensor Pressure sensor Flow sensor pH sensor D) Sensor and actuator STIM P1451.2 9 Micro-controller TEDS ADC DAC Digital STIM Temperature sensor Pressure sensor Proportional valve Relay Figure 3: STIM examples The second example in Figure 3B demonstrates the implementation of a digital input/output (I/O) module with four digital inputs and four digital outputs. The TEDS model in P1451.2 allows this STIM to be described as an eight-channel STIM or alternatively it could be described as a two-channel STIM with one input channel and one output channel each with a length of four. This flexibility in the model allows digital I/O modules with thousands of inputs/outputs to be implemented if such a product were needed. The third example in Figure 3C shows a STIM with multiple analog sensors. These four sensors could be measuring a process liquid. Figure 3D illustrates that combinations of sensors and actuators can be combined into one STIM to support all the transducers used in control system solutions. The code implementing the control loop could reside either in the NCAP or the microcontroller used to implement the P1451.2 interface. 6. TEDS The TEDS is one of the main technical innovations introduced in P1451.2. A TEDS, which carries information about the transducer and its performance, is not a new concept. Companies have been embedding data structures in memory associated with their products for many years [7] [8] [9] [10]. What is new is the general model of a transducer behind the P1451.2 TEDS which supports a wide variety of sensors and actuators. The TEDS contains fields that fully describe the type, operation, and attributes of the transducer. If the transducer is moved to a new location, it is moved with the TEDS. This way the information necessary for using the transducer in a system is always present. Figure 4 shows the main addressable sections of the TEDS along with examples of the content for each segment. The sections shown with dotted lines (calibration-TEDS, application specific-TEDS and extension-TEDS) are optional. The calibration specification in the TEDS permits the sensor manufacturer to describe a multi-dimensional calibration for each channel. To eliminate high order polynomials it is possible to specify a segmented calibration where each segment can have a variable width and offset. It is expected that a general correction engine will be present in the NCAP that understands this calibration scheme so that it can be run “blindly” no matter which transducer is attached. An example of a multisegment calibration curve with simple linear segments is shown in Figure 5. Meta-TEDS One per STIM: Contains the overall description of the TEDS data structure, worst case STIM timing parameters, and channel grouping information. Channel TEDS Calibration TEDS One per STIM channel: Contains upper/lower range limits, physical units, warm up time, presence of self-test, uncertainty, data model, calibration model, and triggering parameters. One per STIM channel: Contains the last calibration date, calibration interval and all the calibration parameters supporting the multi-segment model. Application specific TEDS Extension TEDS Multiple per STIM: For application specific use. Multiple per STIM: Used to implement future and industry extensions to P1451.2. Figure 4: Overview of the TEDS structure Appendix B contains an example of the complete P1451.2 TEDS for a single channel pressure sensor. It is a ceramic pressure sensor with an analog output between 0 to 5 V dc corresponding to 0 to 20,684,190 Pa (3000 lb/in2) pressure input. The sensor has a 10 ms response time, no appreciable warm-up requirement and the maximum nonlinearity is measured to be 0.56% of Vsupply. The primary components of the single channel STIM are a serial 12-bit analog-to-digital converter (ADC) for data conversion (75 µs conversion cycle), and an 8-bit PIC-type processor with 4K by 12-bit on-chip EEPROM (8 MHz operation). Calibration is fixed and is specified using five equal segments with non-zero offsets for each segment. This allows first order calibration functions to be used to reduce the non-linearity in the analog output (0.56% reduced to 0.03%). Physical units ADC counts Figure 5: Multi-segment calibration curve This specific TEDS implementation in Appendix B required the following amount of memory: Meta TEDS 366 bytes Channel TEDS 96 bytes Calibration TEDS 103 bytes Total 565 bytes Out of the 565 bytes, the manufacturer identification consumed 55 bytes, and product description consumed 205 bytes, for a total of 260 bytes or 46% of the TEDS. The TEDS in Appendix B was created by Texas Instruments to demonstrate how a real transducer could be described by P1451.2. This does not imply that Texas Instruments will be offering this as a product. 7. Digital interface Figure 1A shows the digital lines specified in the digital interface. Basic communications between the NCAP and STIM require four lines (DCLK, DOUT, DIN, and NIOE). DCLK is driven by the NCAP. The data transfers are based on SPI-like (serial peripheral interface), bit-transfer protocol. The NCAP drives the NTRIG line to initiate a measurement or action, and the STIM uses the NTRACK line to acknowledge that the requested function has been performed. The STIM can notify the NCAP of any exception conditions by use of the NIO_INT line. The P1451.2 draft defines a set of status registers to support notification of standard exceptions such as hardware errors, busy channels, STIM power cycle, calibration failure, and self-test failure. A power supply of +5 V is also a part of the interface specification. Appendix C shows a timing diagram of the digital interface while reading from a sensor. 8. “Plug and play” operation The operating mode for P1451.2 transducers is “plug-andplay.” Since the TEDS resides with the transducer, one is able to move the transducer from one NCAP to another and simply plug it in to achieve self-identification. Figure 6 shows a temperature STIM connected to an NCAP of one vendor’s network. The pressure STIM can be connected either to the same network or plugged into any of the NCAPs on the second network. “Plug & play” operation requires standardization of a connector. The P1451.2 draft proposes three types of connectors which have been defined for different environments where the standard may find use. Control network “A” NCAP STIM (temperature) NCAP Control network “B” STIM (pressure) NCAP NCAP Figure 6: “Plug-and-play” model of use It is important to note that P1451.2 may be implemented as a single row of pins or wires connecting two circuit boards (an NCAP and a STIM) together. This implementation could be used internally on a product where the separation between NCAP and STIM is not visible to the user. A company may want to build several networked transducers and use a common internal interface (P1451.2) to join the transducer portion with the network/application portion of the networked smart transducer. Figure 7A shows the NCAP hardware support required to drive a STIM. This may be as simple as firmware driving an eight bit microprocessor port or it may be hardware assisted. Figure 7B shows a very simple NCAP firmware block diagram with three blocks: STIM driver, application code and the network protocol stack. The STIM driver is composed of four major functions: • “Bits and bytes” is responsible for getting data across the interface. • “TEDS parser” has knowledge about the P1451.2 TEDS structure and assembles the data into meaningful pieces. • “Correction engine” is the algorithm that converts raw readings from the STIM into units specified in the TEDS for sensors or units specified in the TEDS into STIM settings for actuators. • “P1451.2 application programming interface (API) driver” provides access to TEDS blocks, sensor readings, actuator control, triggers and interrupt requests. A) NCAP hardware NCAP P1451.2 HW interface STIM B) NCAP firmware NCAP Network Application STIM protocol firmware driver stack STIM P1451.2 API driver Correction engine TEDS parser Bits and bytes Figure 7: NCAP support required for P1451.2 Most of the TEDS’ contents need not be parsed and kept on the NCAP. This will depend on the measurement or control problem being solved and differentiation desired in NCAP products. If the application needs the contents of the TEDS for use in another part of the system, then the TEDS may be read from the STIM and sent out over the network with very little parsing. If the NCAP will be making sensor measurements and sending sensor readings in engineering units, then the calibration factors must be parsed and kept on the NCAP for use by a correction engine. In principle only one STIM driver for each kind of NCAP is required to support P1451.2. For each microprocessor family supporting this proposed standard there could be a single software driver for the P1451.2 interface, a single TEDS parser, and a single conversion engine. It is expected that the drivers for the popular networks will be developed by the network providers. In past demo implementations, three network providers developed IEEE1451.2 drivers for their network’s NCAPs: Allen-Bradley Company (DeviceNet™), Echelon Corporation (LonWorks™) and Honeywell Micro Switch Division (Smart Distributed System™).** 9. Status of proposed standard The working group has released IEEE-P1451.2 D2.01 [11] to IEEE for balloting by approximately fifty IEEE Members. Persons interested in participation in the working group please contact: Kang Lee at NIST (301)-975-6602 Email: Kang.Lee@NIST.GOV 10. Acknowledgments The authors would like to thank all the people who have contributed ideas for this proposed standard, in particular those who have participated in the working group meetings and demonstrations of the key concepts of selfidentification of transducers and transducer plug-and-play operation on multiple networks. 11. Summary We have presented an overview of the technical aspects of IEEE-P1451.2. In addition, some of the practical considerations for implementation and support of the standard have been discussed. The working group has made progress and has reached the first official IEEE ballot milestone permitting a wider audience to obtain a copy of the working group’s efforts. References [1] Janusz Bryzek, et al., “Common Communication Interfaces for Networked Smart Sensors and Actuators,” SENSORS, pp. 14-23, September, 1995, Helmers Publishing. [2] Janusz Bryzek, “Introduction to IEEE-P1451: the Emerging Hardware Independent Communication Standard for Smart Transducers,” Proceedings of Eurosensors X, September, 1996, Leuven, Belgium. [3] Jay Warrior, “IEEE-P1451 Network Capable Application Processor Information Model,” Proceedings Sensors Expo Anaheim, pp. 15-21, April, 1996, Helmers Publishing. [4] Stan Woods, “IEEE-P1451 Transducer to Microprocessor Interface,” Proceedings Sensors Expo Anaheim, pp. 9-14, April, 1996, Helmers Publishing. [5] Bruce Hamilton, “A Compact Representation of Units,” HP Laboratories Technical Report HPL-96-61, HewlettPackard Company, Palo Alto, California, May, 1996. [6] Bill Travis, “Smart-Sensor Standard Will Ease Networking Woes,” EDN, pp. 49-55, June 22, 1995, Cahners Publishing. [7] Paul DuPuis, “Pressure Sensor Case Study #5”, Fourth IEEE/NIST Workshop on Smart Transducer Interface Standards, Chicago, IL., September 14, 1995 [8] John C. Eidson and Stan P. Woods, “A Research Prototype of a Networked Smart Sensor System,” Proceedings Sensors Expo Boston, pp. 223-232, May, 1995, Helmers Publishing. [9] Rick West, “Automatic Calibration of Strain Gauges,” SENSORS, pp. 44-46, July, 1995, Helmers Publishing. [10] Albert E. Brendel, “Sensor Stores Calibration Data in Nonvolatile ROM,” p. 32, Test & Measurement World, June, 1996. [11] “IEEE P1451.2 D2.01 IEEE Draft Standard for A Smart Transducer Interface for Sensors and Actuators Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats”, Institute of Electrical and Electronics Engineers, August, 1996. ** Certain commercial products are identified in this paper in order to adequately describe the proposed standard. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the products identified are necessarily the best available for the purpose or the only ones that could be used. Appendix A: Physical units encoding Field # 1 2 3 4 5 6 7 8 9 10 Description ENUMERATION 0: Unit is described by the product of SI base units raised to the powers recorded in fields 2 through 10. 1: Unit is U/U, where U is described by the product SI base units raised to the powers recorded in fields 2 through 10. 2: Unit is loge(U), where U is described by the product of SI base units raised to the powers recorded in fields 2 through 10. 3: Unit is loge(U/U), where U is described by the product of SI base units raised to the powers recorded in fields 2 through 10. 4: The associated quantity is digital data (e.g. a bit vector) and has no unit. Fields 2-10 shall be set to 128. 5-255: Reserved (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 (2 * ) + 128 # bytes 1 1 1 1 1 1 1 1 1 1 Each value in the P1451.2 representation is 128 + 2 x (the value of the logical representation of each SI base unit) to scale the TEDS value to nonnegative integers. Examples: 1) Distance in meters logical representation: 0, 0, 0, 1, 0, 0, 0, 0, 0, 0 TEDS fields: 0, 128, 128, 130, 128, 128, 128, 128, 128, 128 2) Pressure in Pascals or m-1*kg*sec-2 logical representation: 0, 0, 0, -1, 1, -2, 0, 0, 0, 0 TEDS fields: 0, 128, 128, 126, 130, 124, 128, 128, 128, 128 3) Acceleration in meters*second-2 logical representation: 0, 0, 0, 1, 0, -2, 0, 0, 0, 0 TEDS fields: 0, 128, 128, 130, 128, 124, 128, 128, 128, 128 4) Strain in meter/meter logical representation: 1, 0, 0, 1, 0, 0, 0, 0, 0, 0 TEDS fields: 1, 128, 128, 130, 128, 128, 128, 128, 128, 128 Appendix B: TEDS example (single channel pressure sensor) Field types: U8, U16, U32 F32 STRING UNITS are unsigned integers of length 8, 16 and 32 bits respectively. is a single precision IEEE floating point number is an array of character bytes is the representation described in Appendix A Meta TEDS Field Description Field Length # (Bytes) Data structure related information 1 Meta-TEDS Length 4 2 IEEE 1451 Standards Family Working Group Number 1 3 TEDS Major Version Number 2 4 Future Extensions Key 1 5 CHANNEL_ZERO Industry Extensions Key 1 6 End Users' Application Specific TEDS Key 1 7 Number of Implemented Channels 1 8 String Language Code 1 9 Bytes per Character 1 Timing related information 10 Worst Case Channel Data Model Length 1 11 Worst Case Channel Data Repetitions 2 12 Worst Case Channel Update Time 4 13 Worst Case Channel Write Setup Time 4 14 Worst Case Channel Read Setup Time 4 15 Input/Output Response Time 4 16 Calibration TEDS Write Time 4 17 Worst Case Data Clock Frequency 4 18 Worst Case Channel Sampling Period 4 19 Worst Case Unit Warm Up Time 4 Channel grouping related information 20 Channel Groupings Data Sub-Block Length 2 21 Number of Channel Groupings = G 0 22 Group Name Length 0 23 Group Name (<= 255) 0 24 Group Type 0 25 Number of Group Members = N 0 26 Member Channel Numbers List = M(N) (<= 255) 0 Data integrity information 27 Checksum for Meta-TEDS 2 Field type U32 U8 U16 U8 U8 U8 U8 U8 U8 U8 U16 F32 F32 F32 F32 F32 U32 F32 F32 U16 U8 U8 STRING U8 U8 array of U8 U16 Field Contents 48 2 2 0 (NONE) 0 (NONE) 0 1 0 1 2 1 2.00E-05 0 8.00E-05 5.00E-04 0 2.00E+05 2.00E-04 1 0 - 62856 Data structure related information 28 Meta-Identification TEDS Length Identification related information 29 Manufacturer's Identification Length 30 Manufacturer's Identification (<= 255) 31 Model Number Length 32 Model Number (<= 255) 33 Revision Code Length 34 Revision Code 35 Serial Number Length 36 Serial Number (<= 255) 37 Date Code Length 38 Date Code (<= 255) 39 Product Description Length 40 Product Description (<= 65535) Data integrity information data sub-block 41 Checksum for Meta-Identification TEDS 4 U32 310 1 U8 55 55 STRING Texas Instruments Incorporated Control Product Division 1 U8 9 9 STRING EX3514.XX 1 U8 2 2 STRING 01 1 U8 5 5 STRING SN-01 1 U8 25 25 STRING November 1, 1995, Shift 1 2 U16 205 205 STRING Description: Ratiometric Pressure Transducer Part Number: EX3514.XX Serial Number: SN-01 Pressure Range: 0 To 3000 PSIA Input Voltage: 5 Vdc Output Voltage: 0 To 5 Vdc Temperature Range: -40 To 85° C 2 U16 38702 Channel TEDS Field Description Field Length # (Bytes) Data structure related information 42 Channel TEDS Length 4 43 Calibration Key 1 44 Industry Extension Key 1 Transducer related information 45 Lower Range Limit 4 46 Upper Range Limit 4 47 Physical Units 10 Field type U32 U8 U8 F32 F32 UNITS 48 Unit Type Key 49 Unit Warm Up Time 50 Self Test Key 51 Uncertainty Data converter related information 52 Channel Data Model 53 Channel Data Model Length 54 Channel Model Significant Bits 55 Channel Data Repetitions 56 Series Increment 57 Series Units 58 Channel Update Time 59 Channel Write Setup Time 60 Channel Read Setup Time 61 Data Clock Frequency 62 Channel Sampling Period 63 Timing Correction 64 Trigger Accuracy Data integrity information 65 Checksum for Channel TEDS Data structure related information 66 Channel Identification TEDS Length Identification related information 67 Manufacturer's Identification Length 68 Manufacturer's Identification (<= 255) 69 Model Number Length 70 Model Number (<= 255) 71 Revision Code Length 72 Revision Code (<= 255) 73 Serial Number Length 74 Serial Number (<= 255) 75 Channel Description Length 76 Channel Description (<= 65535) Data Integrity information 77 Checksum for Channel Identification TEDS 1 U8 4 F32 1 U8 4 F32 1 U8 1 U8 2 U16 2 U16 4 F32 10 UNITS 4 F32 4 F32 4 F32 4 U32 4 F32 4 F32 4 F32 2 U16 4 U32 1 U8 0 STRING 1 U8 0 STRING 1 U8 0 STRING 1 U8 0 STRING 2 U16 0 STRING 2 U16 Field Contents 80 1 (FIXED) 0 (NONE) 0 20684190 Pa (0,128,128,126,130, 124,128,128,128,128) 0 (SENSOR) 1 0 (NONE) 206842 0 (N BYTE) 2 12 1 0 0 2.00E-05 0 8.00E-05 2.00E+05 2.00E-04 0 5.00E-06 59968 8 0 - 0 - 0 - 0 - 0 - 65527 Calibration TEDS Field Description Field Length # (Bytes) Data structure related information 78 Calibration TEDS Length 4 Calibration related information 79 Last Calibration Date-Time 4 80 Calibration Interval 4 81 Number of Correction Input Channels = n 1 82 Correction Input Channel List 1 83 Correction Input Channel-Key List 1 84 Channel Degree List = D(k) 1 85 Number of Segments List = Nk 1 86 Segment Boundary Values Table (Pa) 24 (segment 1 high boundary) (segment 2 high boundary) (segment 3 high boundary) (segment 4 high boundary) (segment 5 high boundary) 87 Segment Offset Values Table (Pa) 20 (segment 1 offset) (segment 2 offset) (segment 3 offset) (segment 4 offset) (segment 5 offset) 88 Multinomial Coefficients 40 A00 (Pa) A01 (Pa/count) A10 A11 A20 A21 A30 A31 A40 A41 Data integrity information 89 Checksum for Calibration TEDS 2 Field type U32 U32 U32 U8 U8 U8 U8 U8 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 U16 Field Contents 99 0 0 1 1 0 1 5 0 4136838 8273676 12410514 16547352 20684190 5051 5051 5051 5051 5051 -126372 5244 -44141 5144 111220 5049 331826 4959 610811 4874 57092 Appendix C: Timing diagram example (reading from a sensor) NTRIG NTRACK tupd tplsx NIOE DIN DOUT trst tior msb function address lsb msb channel DCLK >0 lsb start byte msb most significant byte data least significant byte lsb msb lsb msb lsb tupd- Channel update time specified in the Channel TEDS (field #58) tplsx- NTRACK pulse width (> 20 nsec) trst- Channel read setup time specified in the Channel TEDS (field #60) tior- I/O response time specified in the Meta-TEDS (field #15)