“Integration of In-Vehicle Electronics for IVHS and the Electronics for Other Vehicle Systems”

Total Page:16

File Type:pdf, Size:1020Kb

“Integration of In-Vehicle Electronics for IVHS and the Electronics for Other Vehicle Systems” U.S. Department of Transportation. National Highway Traffic Safety Administration DOT HS 808 261 March 1995 Final Report “Integration of In-Vehicle Electronics for IVHS and the Electronics for Other Vehicle Systems” This document is available to the public from the National Technical Information Service, Springfield, Virginia 22161 This publication is distributed by the U.S. Department of Transportation, National Highway Traffic Safety Adminis- tration, in the interest of information exchange. The opinions, fiidings and conclusions expressed in this publication are those of the author(s) and not necessarily those of the Department of Transportation or the National Highway Traffic Safety Administration. The United States Government assumes no liability for its contents or use thereof. If trade or manufac- turers’ name or products are mentioned, it is because they are considered essential to the object of the publication and should not be construed as an endorsement. The United States Government does not endorse products or manufacturers. Technical Report Documentation Page 1 Report No. 2. Government Accession No. 3. Recipient’s Catalog No. DOT HS 808 261 1. Title and Subtitle 5. Report Date March 31, 1995 "Integration of In-Vehicle Electronics for IVHS and the Electronics for Other Vehicle Systems” 6. Performing Organization Code 8. Performing Organization Report No. 7. Author(s) TR95019 David Lee,Robert McOmber, Ron Bruno 3. Performing organization Name and Address 10. Work Unit No. (TRAIS) Stanford Telecommunications, Inc. 1761 Business Center Dr. 11. Contract or Grant No. Reston, Va. 22090 DTNH22-93-D-07317 13. Type of Report and Period Covered 12. Sponsoring Agency Name and Address Task Order Study National Highway Traffic Safety Administration (NHTSA) Sept. 1994 through March Office of Collision Aviodance Research (OCAR) 1995 400 7th St. SW, Rm. 5301 14. Sponsoring Agency Code Washington, DC 20590 NRD-51 15. Supplementary Notes 16. Abstract The increasing sophistication of automotive electronics has prompted NHTSA to investigate the feasibility of using advanced electronics for in-vehicle Intelligent Vehicle Highway Systems(IVHS) . Specifically,OCAR wishes to find the most feasible approach to integrating in-vehicle IVHS safety systems with other in-vehicle electronic systems. Such integration could yield benefits such as reduced cost, increased functionality,and safer, more reliable vehicles. This report investigates the use of off-the-shelf automotive electronic multiplexing and networking standards and electronic bus architectures to achieve this integration. Issues addressed include whether existing standards are adequate to support the required types of interfaces and the anticipated data traffic volumes that such integrated systems would impose,and whether safety and reliability issues have been adequately addressed. A number of hypothetical in-vehicle integrated IVHS safety system architectures are proposed and evaluated against most of the currently known automotive electronic protocol standards. 7. Key Words 18. Distribution Statement Intelligent Vehicle Highway Systems, automotive electronics, automotivemulti- This document is available to the plex, automotive networks, in-vehicle public through the National safety systems,SAE 51850, CAN, automotive Technical Information Service electronic standards, automotive control Springfield, VA 22161 systems 9. Security Classif. (of this report) 20. Security Classif. (of mis page) 21. No. of Pages 22. Price Unclassified Unclassified Form DOT F 1700.7 (8-72) Reporoduction of form and completed page is authorized i TABLE OF CONTENTS SECTION PAGE 1 EXECUTIVE SUMMARY..................................... l-l 1.1 TaskOverview.............................................. l-l •’ 1.2 Task Methodology........................................... l-l 1.3 Summary of Findings......................................... l-8 1.4 Recommendations for Further Effort............................... l-10 2 GENERAL NETWORKING CONCEPTS.........................2-l 2.1 Overview.................................................. 2-l 2.2 Multiple Access Networks...................................... 2-l 2.2.1 Time Division Multiplexing..................................... 2-4 2.2.2 Random Access............................................. 2-5 2.2.3 Controlled Access............................................ 2-6 2.2.4 OS1 Reference Model......................................... 2-8 2.2.5 OSI Implementation......................................... 2-10 2.2.6 FrameStructure............................................ 2-12 2.3 Network Performance Issues................................... 2-14 2.4 Fault Tolerance and Reliability.................................. 2-17 3 AUTOMOTIVE PROTOCOLS................................ 3-l 3.1 SAE Protocol Classes........................................ 3-l 3.2 SAE Networking Standards.................................... 3-3 3.3 OEM Networking Standards.................................... 3-5 3.4 Comparison of Protocol Specifications and Performance................ 3-8 3.4.1 Physical and Logical Layer Specifications.......................... 3-8 3.4.2 Physical layer.............................................. 3-8 3.4.3 Logicallayer.............................................. 3-11 3.4.4 Message Formats............................................ 3-l1 3.4.5 Latency and Throughput....................................... 3-14 3.4.6 ISO Fault Tolerance......................................... 3-15 4 INDUSTRY PRACTICE...................................... 4-l 4.1 Standards Committees and Organizations............................4-l 4.2 Networking Standards Usage..................................... 4-l 4.3 Manufacturing Practice........................................ 4-4 4.4 Enabling Technologies......................................... 4-6 4.4.1 Sensors................................................... 4-6 4.4.1.1 Class C Sensors............................................. 4-6 4.4.1.2 Class A Sensors............................................. 4-8 31 March 1995 iii R95019.TOC NTS (Continued) SECTION PAGE 4.4.1.3 IVHS Sensors............................................... 4-8 4.4.2 Actuators.................................................. 4-9 4.4.2.1 Class CActuator........s .................................... 4-9 4.4.2.2 Class A Actuators............................................ 4-9 4.4.2.3 IVHS Actuators............................................. 4-9 . 4.4.3 Control Modules............................................ 4-10 4.4.3.1 Design and Functionality....................................... 4-10 4.4.3.2 Processors Characteristics...................................... 4-10 4.4.3.3 Memory Characteristics........................................ 4-10 4.5 Architecture Approaches...................................... 4-11 4.5;1 Existing and Near-Term Future Architectures........................ 4-11 4.5.2 Mid-Term Future Architectures.................................. 4-11 4.5.3 Long-Term Architectures...................................... 4-l 3 4.6 Manufacturing Practice....................................... 4-16 4.6.1 Electronic Systems.......................................... 4-16 4.6.2 Semiconductor Components.................................... 4-18 4.6.3 IVHS Systems............................................. 4-19 4.6.4 Software Controlled Design, Manufacturing, and Diagnostic Tools.........4-20 5 SYSTEM CONCEPTS...................................... ..5-l 5.1 Existing Vehicle Control Systems................................. 5-l 5.2 IVHS In-Vehicle Safety Systems: Overview and Assumptions...........5-13 5.3 IVHS In-Vehicle Safety Systems: System Specifications, Data Flows, and Information Needs....................................... 5-19 6 INTEGRATION OF IVHS CRASH AVOIDANCE SYSTEMS AND OTHER IN-VEHICLE ELECTRONICS......................... .......6-1 l 6.1 Overview of the Assessment Approach............................. 6-l 6.2 Assumptions...............................................s . 6-l 6.3 Assessmemt Criteria........................................... 6-3 6.3.1 Access to Candidate Network Bus................................ 6-4 6.3.2 Support for Information Sharing and Coordinated Control................6-4 6.3.3 Bus Support to Upgrades and Expansion............................ 6-4 6.3.4 Short-Term Message Error Rate, and Error Type/Distribution..............6-5 6.3.5 Data/Message Thmughput and Latency............................. 6-5 6.3.6 Network Reliability (Long-Term Failure Rate)........................ 6-6 6.3.7 Cost Factors................................................ 6-6 iv 31 March 1995 R95019.TW TABLE OF CONTENTS (Continued) SECTION PAGE 6.4 Network Scenarios for IVHS Safety System Integration.................6-6 6.4.1 Near-Term Scenarios.......................................... 6-7 6.4.2 Mid-Term Scenarios......................................... 6-17 6.4.3 Far-Term Scenarios.......................................... 6-23 7 ASSESSMENT OF IVHS CRASH AVOIDANCE SYSTEM INTEGRATION 7-l 7.1 Detailed Assessments......................................... 7-1 7.1.l NearTerm................................................. 7-l 7.1.1.1 Standalone IVHS Systems....................................... 7-1 7.1.1.2 Integrated IVHS Systems....................................... 7-9 7.1.2 Mid Term ................................................ 7-12 7.1.3 FarTerm................................................. 7-12 7.2 Summary Evaluations.......................................
Recommended publications
  • PCI20EX PCI Express (Pcie)
    PCI20EX PCI Express (PCIe) Bus ARCNET® Network Interface Modules INSTALLATION GUIDE INTRODUCTION The PCI20EX series of ARCNET network interface modules (NIMs) links PCI Express (PCIe) bus compatible computers with the ARCNET local area network (LAN). Since most PC motherboards have migrated from the legacy PCI and PCI-X Bus, a PCI Express style NIM is required. The PCI20EX series is compliant to the PCI Express Card Electromechanical Specification Revision 2.0 and both standard height and low-profile brackets are provided. The PCI Express interface allows for jumperless configuration and Plug and Play operation. The module operates with either an NDIS driver or a null stack driver in a Windows® environment. The PCI20EX incorporates the COM20022 ARCNET controller chip with enhanced features over the earlier generation ARCNET chips. New features include command chaining, sequential access to internal RAM, duplicate node ID detection and variable data rates up to 10 Mbps. Bus contention problems are minimized since the module’s interrupt and I/O base address are assigned through Plug and Play. The PCI20EX exploits the new features of the COM20022 which includes 10 Mbps communications utilizing the various EIA-485 transceiver options. Each PCI20EX module has two LEDs on the board for monitoring network operation and bus access to the module. It is equipped with an 8 position, general purpose DIP switch typically used to assign the ARCNET node address. Ultimately, the node address is configured via software so the DIP switch can also indicate user-defined functions such as data rate, cable interface, or master/slave status of the system.
    [Show full text]
  • Datasheet for Onenand Power Ramp and Stabilization Times and for Onenand Boot Copy Times
    TMS320DM365 www.ti.com SPRS457E–MARCH 2009–REVISED JUNE 2011 TMS320DM365 Digital Media System-on-Chip (DMSoC) Check for Samples: TMS320DM365 1 TMS320DM365 Digital Media System-on-Chip (DMSoC) 1.1 Features 12 • Highlights – Support for 32-Bit and 16-Bit – High-Performance Digital Media (Thumb® Mode) Instruction Sets System-on-Chip (DMSoC) – DSP Instruction Extensions and Single Cycle – Up to 300-MHz ARM926EJ-S Clock Rate MAC – Two Video Image Co-processors – ARM® Jazelle® Technology (HDVICP, MJCP) Engines – Embedded ICE-RT Logic for Real-Time – Supports a Range of Encode, Decode, and Debug Video Quality Operations • ARM9 Memory Architecture – Video Processing Subsystem – 16K-Byte Instruction Cache • HW Face Detect Engine – 8K-Byte Data Cache • Resize Engine from 1/16x to 8x – 32K-Byte RAM • 16-Bit Parallel AFE (Analog Front-End) – 16K-Byte ROM Interface Up to 120 MHz – Little Endian • 4:2:2 (8-/16-bit) Interface • Two Video Image Co-processors • 8-/16-bit YCC and Up to 24-Bit RGB888 (HDVICP, MJCP) Engines Digital Output – Support a Range of Encode and Decode • 3 DACs for HD Analog Video Output Operations, up to D1 on 216-MHz device and • Hardware On-Screen Display (OSD) up to 720p on the 270- and 300-MHz parts – Capable of 720p 30fps H.264 video – H.264, MPEG4, MPEG2, MJPEG, JPEG, processing WMV9/VC1 Note: 216-MHz is only capable of D1 • Video Processing Subsystem processing – Front End Provides: – Peripherals include EMAC, USB 2.0 OTG, • HW Face Detect Engine DDR2/NAND, 5 SPIs, 2 UARTs, 2 • Hardware IPIPE for Real-Time Image MMC/SD/SDIO,
    [Show full text]
  • Wishbone Bus Architecture – a Survey and Comparison
    International Journal of VLSI design & Communication Systems (VLSICS) Vol.3, No.2, April 2012 WISHBONE BUS ARCHITECTURE – A SURVEY AND COMPARISON Mohandeep Sharma 1 and Dilip Kumar 2 1Department of VLSI Design, Center for Development of Advanced Computing, Mohali, India [email protected] 2ACS - Division, Center for Development of Advanced Computing, Mohali, India [email protected] ABSTRACT The performance of an on-chip interconnection architecture used for communication between IP cores depends on the efficiency of its bus architecture. Any bus architecture having advantages of faster bus clock speed, extra data transfer cycle, improved bus width and throughput is highly desirable for a low cost, reduced time-to-market and efficient System-on-Chip (SoC). This paper presents a survey of WISHBONE bus architecture and its comparison with three other on-chip bus architectures viz. Advanced Microcontroller Bus Architecture (AMBA) by ARM, CoreConnect by IBM and Avalon by Altera. The WISHBONE Bus Architecture by Silicore Corporation appears to be gaining an upper edge over the other three bus architecture types because of its special performance parameters like the use of flexible arbitration scheme and additional data transfer cycle (Read-Modify-Write cycle). Moreover, its IP Cores are available free for use requiring neither any registration nor any agreement or license. KEYWORDS SoC buses, WISHBONE Bus, WISHBONE Interface 1. INTRODUCTION The introduction and advancement of multimillion-gate chips technology with new levels of integration in the form of the system-on-chip (SoC) design has brought a revolution in the modern electronics industry. With the evolution of shrinking process technologies and increasing design sizes [1], manufacturers are integrating increasing numbers of components on a chip.
    [Show full text]
  • VICTORIA UNIVERSITY of WELLINGTON Te Whare W
    VICTORIAUNIVERSITYOFWELLINGTON Te Whare Wananga¯ o te UpokooteIkaaM¯ aui¯ School of Engineering and Computer Science Te Kura Matai¯ Pukaha,¯ Purorohiko¯ PO Box 600 Tel: +64 4 463 5341 Wellington Fax: +64 4 463 5045 New Zealand Internet: offi[email protected] Development of an IoT System for Environmental Monitoring Jolon Behrent Supervisor: James Quilty Submitted in partial fulfilment of the requirements for Bachelor of Engineering with Honours. Abstract The Greater Wellington Regional Council currently uses data loggers to mon- itor the environment. These loggers and accompanying software are provided by a single supplier which effectively locks the Council into using them for all monitoring. The Council wants to develop a low-cost, open-source Internet of Things solution with a connection to a cloud platform. This report looks at the development of a successful proof-of-concept device capable of reading from sensors and transmitting the data to Azure. Contents 1 Introduction and Background 1 1.1 Introduction . .1 1.1.1 Objective . .1 1.1.2 Overview . .2 1.2 Background . .2 1.2.1 HyQuest Solutions Data Loggers . .2 1.2.2 SDI-12 . .3 2 Design 5 2.1 Design Constraints . .5 2.1.1 Power Consumption . .5 2.1.2 Size . .6 2.1.3 Cost . .6 2.2 Microcontroller Selection . .6 2.3 Modem Selection . .7 2.4 Capacitor Selection . .8 2.5 Regulator Selection . .9 2.6 PCB Design . .9 2.7 Enabling Local Wireless Connection . 10 2.7.1 Reed Switches . 11 2.7.2 Hall Effect Sensors . 11 2.8 SDI-12 Design .
    [Show full text]
  • GS3 Greenhouse Sensor 2365 NE Hopkins Ct / Pullman, WA 99163 USA Volumetric Water Content, Electrical Conductivity, and Temperature
    GS3 Greenhouse Sensor 2365 NE Hopkins Ct / Pullman, WA 99163 USA Volumetric Water Content, Electrical Conductivity, and Temperature APPLICATIONS DESCRIPTION . Greenhouse substrate monitoring. The Decagon GS3 sensor is an accurate tool for . Volumetric water content measurement. monitoring electrical conductivity, volumetric water . Soil/Substrate water balance. content, and temperature in soil and soilless . Irrigation management. substrates. The GS3 determines volumetric water . Electrical Conductivity measurement. content (VWC) by measuring the dielectric constant . Salt management. (εa) of the medium using capacitance / frequency- . Fertilizer movement. domain technology. The sensor uses a 70 MHz . Soil/Substrate temperature measurement. frequency, which minimizes textural and salinity . Modeling processes that are affected by effects, making the GS3 accurate in most soilless temperature. substrates. The GS3 measures temperature using an onboard thermistor, and electrical conductivity using a stainless steel electrode array. ADVANTAGES For a more detailed description of how this sensor . Digital sensor communicates three makes measurements, refer to the User Manual. measurements over a serial interface. 2-probe EC measurement. Robust thermistor for accurate temperature AUDIENCE measurements. Decagon provides the information in this integrators . Low input voltage requirements. guide to help GS3 customers establish . Low power design supports battery-operated communication between these sensors and their data loggers. data acquisition equipment or field data loggers. Robust epoxy encapsulation and stainless Customers using data loggers that support SDI-12 steel needles to resist corrosive environments. sensor communications should consult the user's . Supports SDI-12 or DDI-Serial 1-wire serial manual for their data logger. These sensors are fully communications protocols. integrated into Decagon's system of plug-and-play .
    [Show full text]
  • Parallel I/O Interface
    從微算機原理到系統 宋開泰教授 國立交通大學電機與控制系 工程五館 EE709 Phone:5731865(校內分機:31865) E-mail:[email protected] URL:http://isci.cn.nctu.edu.tw Microcomputer Systems & Lab Microcomputer bus 1 Digital Signal Waveform 1 0 Single-signal waveform 1 0 Multiple-signal waveform Microcomputer Systems & Lab Microcomputer bus 2 Read Timing for External Code Memory Microcomputer Systems & Lab Microcomputer bus 3 Microcomputer BUS • A bus is a set of conducting wires interconnecting the CPU, memory, and I/O devices. • There are three types of bus: Address bus, Data bus and Control bus. There are also utilities in a bus system, such as Vcc and ground lines. • To drive a bus, a bus driver is needed. To receive data from the bus, a bus receiver is needed. The bus driver and bus receiver can be combined to form a bus transceiver. Microcomputer Systems & Lab Microcomputer bus 4 Connecting to a bus • A bus should be driven by no more than one device at any time. Otherwise, bus contention will occur. When bus contention occurs, the devices that are involved in bus contention could be damaged. • A device is disconnected from the bus when the driver-enable and receiver-enable signals are deasserted. When the enable signal is deasserted, the output of the driver or the receiver is in a high-impedance state in which no current flow into or out the device involved. Microcomputer Systems & Lab Microcomputer bus 5 Interconnecting the CPU, Memory, and I/O Devices Memory unit 8 bits 1,048,575 Clock generator 64 672,356 Address Instruction pointer (IP) System address bus Selector/ z System 6 memory 672 356 decoder 5 4 Instruction register 3 2 64 1 Location 0 INC AX Instruction decoder Internal databus System control bus Arithmetic logic unit Memory read Memory write Accumulator I/O write I/O read I/O write I/O read I/O write 26+1=27 System data bus Video monitor I/O devices: Printer keyboard Floppy disk drive z General-purpose registers I/O port Selector/decoder Central processing unit (CPU) Microcomputer Systems & Lab Microcomputer bus 6 System Bus • Internal data bus is used to classify a microprocessor.
    [Show full text]
  • Teros 21 Gen 1 Integrator Guide
    18204-06 6.30.2020 TEROS 21 GEN 1 INTEGRATOR GUIDE SENSOR DESCRIPTION The TEROS 21 Soil Water Potential Sensor measures a wide range of soil water potentials without user maintenance. This dielectric water potential sensor can be packed into a hole, plugged into a data logger, and left to log water potential data. While the TEROS 21 sensor does not have the accuracy of tensiometers, its extended range makes this sensor ideal for measuring the water potential in natural systems or other drier systems where cavitation of tensiometers is a concern. The added temperature measurements can be used to determine approximate soil water potential in frozen soils. NOTE: The TEROS 21 measures the matric component of water potential. For more information on matric potential and the other components of water potential visit Defining water potential. APPLICATIONS • Deficit irrigation monitoring and control • Water potential monitoring in the vadose zone • Crop stress • Waste water drainage studies • Plant water availability • SDI-12 implementation ADVANTAGES • Three-wire sensor interface: power, ground, and data • Digital sensor communicates multiple measurements over a serial interface • Robust thermistor for accurate temperature measurements • Low-input voltage requirements • Low-power design supports battery-operated data loggers • Robust epoxy encapsulation resists corrosive environments • Supports SDI-12 or DDI serial communications protocols • Modern design optimized for low-cost sensing • Does not require a skilled operator • Can measure drier systems where tensiometer cavitation is a concern • Needs no user maintenance Figure 1 TEROS 21 sensor PURPOSE OF THIS GUIDE METER provides the information in this integrator guide to help TEROS 21 Soil Water Potential Sensor customers establish communication between these sensors and their data acquisition equipment or field data loggers.
    [Show full text]
  • Topic 10 Bus Architecture & Interconnects Introductions & Sources
    Introductions & Sources X We will consider a number of issues related to bus architectures in digital systems. Topic 10 X Useful references: • “Bus Architecture of a System on a Chip with User-Configurable System Bus Architecture & Logic”, Steven Winegarden, IEEE JOURNAL OF SOLID-STATE CIRCUITS, Interconnects VOL. 35, NO. 3, MARCH 2000, p425-433. • “AMBA: ENABLING REUSABLE ON-CHIP DESIGNS”, David Flynn, IEEE Micro, July/August 1997. Peter Cheung • AMBA™ Specification (Rev 2.0), ARM Ltd., 1999 Department of Electrical & Electronic Engineering • The CoreConnect Bus Architecture, IBM, Imperial College London http://www.chips.ibm.com/products/coreconnect • VSI Alliance Architecture Document, version 1.0, 1997. • Draft Chapter, “System-on-Chip”, Flynn & Luk URL: www.ee.imperial.ac.uk/pcheung/ E-mail: [email protected] PYKC 6-Mar-08 E3.05 Digital System Design Topic 10 Slide 1 PYKC 6-Mar-08 E3.05 Digital System Design Topic 10 Slide 2 Basic concepts: Basic concepts: Bus basics: order and broadcast properties Cycles, messages and transactions X Communications on buses must be in strict order: serial nature of bus X Buses operate in units of cycles, Messages and transactions. • Cycles: A message requires a number of clock cycles to be sent from sender to receiver over the bus. • Message: These are logical unit of information. For example, a write message contains an address, control signals and the write data. • Transaction: A transaction consists of a sequence of messages which together form a transaction. For example, a memory read X It can broadcast a transaction – sending to multiple components simultaneously requires a memory read message and a reply with the requested data.
    [Show full text]
  • MACE Xci User Manual - 12 - MACE Xci User Manual - 13 - Product Support
    Table of Contents Using the HydroMACE XCi Manual 12 HydroMACE XCi 12 Product Support 14 About MACE 15 WARNINGS 16 Introduction to FloCom+ 17 Introducing the HydroMACE XCi device 18 Installing an HydroMACE XCi device 20 Opening procedure 20 Sensor and power cables routed inside the pole 21 Sensor and power cables routed through conduit 24 Sensor and power cables routed through conduit 28 Installing XCi power options 29 Solar panel installation on a 2" pole 30 Installing a MACE mains powered trickle charger 37 Powering the XCi device with an external battery 38 Introduction to FloSeries3 cards 39 Installing FloSeries3 Cards 40 About the I/O Card 44 Connecting sensors to the I/O card 46 Frequency input 46 Digital or Counter input 46 Shaft encoder input 47 Two-wire 4-20mA input 48 Three-wire 4-20mA input 48 Voltage input 48 Digital output 49 4-20mA output 50 About the WebComm card 51 Preparing and installing a Webcomm card 52 Add a WebComm site on the web 54 Configure a WebComm card using FloCom+ 57 HTTP Upload 58 FTP Upload to In-Situ HydroVu Data Server 60 FTP Upload 61 Edit HydroVu Headers 62 The "WebComm Utility" 66 Test an HTTP Upload 66 Test an FTP Upload 67 Error messages table: 68 Using "AT+ commands" to troubleshoot a WebComm card 70 Initial upload routine: 71 Common AT+ commands 72 Editing/Viewing a WebComm site on the web 75 Site data 75 Download site data 75 Show latest record 76 Delete site data 76 Site details 77 Site Details 77 Site keys 77 Site alarms 78 Site users 78 Remove site 78 Alarm history 79 All about Webcomm SMS/Email
    [Show full text]
  • ELM325 J1708 Interpreter
    ELM325 J1708 Interpreter Description Features With the advent of electronic engine controls, • Supports both SAE J1587 and J1922 many vehicles also adopted some form of diagnostic • High speed RS232 interface tools to help monitor their operation. As more modules began to be used in vehicles, there was • Works with standard RS485 transceivers also a need for the devices to share information • Fully configurable with AT commands rather than each independently obtain this from separate sensors. • Wide operating voltage range (1.8 to 5.5V) In the 1980’s, the SAE J1708 standard was • Low power CMOS design created to provide a specification for a common data bus to be used in heavy duty vehicles. It used RS485 wiring (already proven to be reliable in noisy environments), and a UART-based low speed data Connection Diagram format. The SAE J1587 standard followed a few PDIP and SOIC years later to describe the mechanism by which (top view) messages and data should be sent between vehicle modules. The ELM325 allows a PC or similar device to be VDD 1 14 VSS used to monitor and query devices on a J1708 data XT1 2 13 RO bus, using simple commands that can be sent from almost any terminal program. It is able to work with XT2 3 12 RE either the J1587 or the J1922 data formats. InvDE 4 11 DE RS232 Rx 5 10 J Tx LED Applications RS232 Tx 6 9 J Rx LED • Diagnostic trouble code readers RS Rx LED 7 8 RS Tx LED • Heavy duty vehicle scan tools • Teaching aids • ECU Simulators Block Diagram 3.58 MHz InvDE XT12 3 XT2 4 Timing and Control 13 RO RS232 Rx 5 RS232 J1708 11 DE Interface Interface RS232 Tx 6 J1587/1922 Interpreter 12 RE RS Rx LED 7 10 J Tx LED RS Tx LED 8 9 J Rx LED ELM325DSA Elm Electronics – Circuits for the Hobbyist 1 of 31 www.elmelectronics.com ELM325 Contents Electrical Information Copyright and Disclaimer.............................................................2 Pin Descriptions..........................................................................
    [Show full text]
  • RVT-7 User's Manual
    RVT-7 7” Rugged Android Vehicle Display Terminal User’s Manual Version 1.0.0 1 Revision History Version Release Time Description 1.0 2019.06 Initial Release Modify chaper 4: docking station using 1.1 2019.07 instruction 1.2 2019.08 Modify Chaper5: Accessories 1.3 2019.10 Add “3.3.3 GPIO specification” Disclaimer The information in this document is subject to change without prior notice in order to improve the reliability, design and function. It does not represent a commitment on the part of the manufacturer. Under no circumstances will the manufacturer be liable for any direct, indirect, special, incidental, or consequential damages arising from the use or inability to use the product or documentation, even if advised of the possibility of such damages. About This Manual This user’s manual provides the general information and installation instructions for the product. The manual is meant for the experienced users and integrators with hardware knowledge of personal computers. If you are not sure about any description in this manual, consult your vendor before further handling. We recommend that you keep one copy of this manual for the quick reference for any necessary maintenance in the future. Thank you for choosing Seatronx products. 2 CONTENT 1.1 Product Highlights .............................................................................................................. 7 1.2 Parts of the Device .............................................................................................................. 7 1.3 Extended Cable Definition
    [Show full text]
  • Trademarks Copyright Information Disclaimer of Warranties
    Trademarks Autel®, MaxiSys®, MaxiDAS®, MaxiScan®, MaxiTPMS®, MaxiRecorder®, and MaxiCheck® are trademarks of Autel Intelligent Technology Corp., Ltd., registered in China, the United States and other countries. All other marks are trademarks or registered trademarks of their respective holders. Copyright Information No part of this manual may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without the prior written permission of Autel. Disclaimer of Warranties and Limitation of Liabilities All information, specifications and illustrations in this manual are based on the latest information available at the time of printing. Autel reserves the right to make changes at any time without notice. While information of this manual has been carefully checked for accuracy, no guarantee is given for the completeness and correctness of the contents, including but not limited to the product specifications, functions, and illustrations. Autel will not be liable for any direct, special, incidental, indirect damages or any economic consequential damages (including lost profits). IMPORTANT Before operating or maintaining this unit, please read this manual carefully, paying extra attention to the safety warnings and precautions. For Services and Support: pro.autel.com www.autel.com 1-855-287-3587/1-855-AUTELUS (North America) 0086-755-86147779 (China) [email protected] For details, please refer to the Service Procedures in this manual. i Safety Information For your own safety and the safety of others, and to prevent damage to the device and vehicles upon which it is used, it is important that the safety instructions presented throughout this manual be read and understood by all persons operating or coming into contact with the device.
    [Show full text]