DETERMINATION OF BIT RATES FOR REMOTE VEHICULAR COMMUNICATIONS

Abstract

One method of remote communication with a vehicle's on-board diagnostic (OBD) system involves connecting a vehicle communication device to a connector on the vehicle's OBD system, connecting a remote communication device to a connector on a vehicle tool, and establishing a network communication link between the vehicle communication device and the remote communication device. The vehicle communication device receives communications from the vehicle's OBD system via the connector. A bit sequence from the received communications is analyzed over a time interval. The amplitudes of one or more bit pulses are estimated based on this analysis. An OBD system bit rate is determined based on the estimated amplitudes of the bit pulse(s).Based on the determined bit rate of the OBD system, bidirectional communications are established between the OBD system and the tool device, using the network communication link established between the vehicle communication device and the remote communication device.

Description

DETERMINATION OF BIT RATES FOR REMOTE VEHICULAR COMMUNICATIONS CROSS REFERENCE WITH A RELATED PATENT APPLICATION [1] This is a utility application based on application 63 / 195,490, filed June 1, 2021, and claiming priority from it. This related application is incorporated herein by reference and forms part of this application. If any conflict arises between the disclosures in this utility application and those in the related provisional application, the disclosures in this utility application shall prevail. Furthermore, the inventor(s) incorporate herein, by reference, each and every patent, patent application, and other printed or electronic document cited or referred to in this application. FIELD OF INVENTION [2] This disclosure refers in general to methods and devices that perform vehicular system communications. BACKGROUND OF THE INVENTION [3] On-board diagnostic (OBD) systems enable a vehicle owner or technician to access vital information and program various modules, systems, and subsystems within a vehicle. Manufacturers have included OBD systems in their vehicles for many years. In a traditional repair setting, a technician uses a specialized scan tool adapted to interface with a specific vehicle's OBD system by utilizing the vehicle's data link connector (DLC). Many of these OBD systems operate via a controller area network (CAN). The vehicle's Recfr Ln / eznz / B / YiAi facilitates communication between the vehicle's interconnected subsystems. The scan tool can read data about the vehicle's modules, systems, and subsystems for diagnostic purposes, while also enabling some reprogramming of these modules, systems, and subsystems. Typically, these scan tools are standalone, handheld computing devices that connect directly to a vehicle via a cable with a plug at one end, which can be connected to the vehicle's DLC (Digital Location Center). [4] Numerous standards have been implemented for vehicle diagnostic systems and communication protocols, some mandatory for tracking and inspecting attributes such as emissions control. These communication standards include, for example, OBD-1, OBD-II, SAE J2534, SAE J1850 PWM (Pulse Amplitude Modulation), ISO 15765, and ISO 9141-2. A common standardized attribute of OBD systems has become the use of a 16-pin DLC, usually located under the vehicle's instrument panel. Many vehicle manufacturers use this connection system and have adopted the aforementioned communication standards, which are shared with the public to perform basic diagnostic and reprogramming functions. [5] Many manufacturers also use these same OBD systems to repair and update various advanced computerized systems within a vehicle. Some diagnostic / programming tools can utilize personal computers and remote network connections. One problem with using these systems, however, is determining the protocol and other parameters for communicating with a given vehicle's OBD system, which can vary significantly between vehicles and may not be easily discernible from documentation. These parameters may include a communication bit rate, for example. Recfr Ln / eznz / B / YiAi example. Before facilitating remote communications with an OBD system, such as with a network communications device, the OBD system's communication parameters must be determined. BRIEF DESCRIPTION OF THE INVENTION [6] The modalities of this disclosure include systems and methods for implementing communications between vehicle on-board diagnostic (OBD) systems and remote scan / programming tools, designed to address problems in these communications. A communication system includes a communications device on the vehicle (or car) side, which is configured to plug into or otherwise connect to an OBD system connector (e.g., DLC) and has a network communications interface to facilitate bidirectional communication between the OBD system and remote network devices. The system also includes a communications device on the tool (or remote) side, which has a connector that allows a scan / programming tool to plug into the communications device on the tool side, as if it were the connector to a vehicle's OBD system.The device on the tool side also has a network communications interface, which facilitates bidirectional communication between a connected scan / programming tool and an OBD system connected to a device on the car side, via their respective network communications interface. [7] In some vehicle communications and / or vehicle tooling systems, the system bit rate is established or determinable by a standard protocol (e.g., when using OBD-II). In some systems, the system bit rate is not standardized or published (e.g., in some implementations of the CAN protocol). Recfr Ln / eznz / B / YiAi In some configurations where the bit rate is unknown (e.g., not standardized or published), the device on the vehicle side is configured to determine a bit rate used by the OBD system (from a communications device on the vehicle side or on the tool side) before providing network communications. In some configurations, the bit rate is determined by monitoring a communication output (e.g., a signal on a connection pin) from an OBD connector on the OBD system / tool ​​and using an on-board computer clock on the device on the vehicle / tool ​​side to track elapsed time during monitoring. Monitoring includes identifying when the state of the OBD output changes (e.g., a leading or falling edge of a signal) and tracking the interval between these events (e.g., pulse amplitudes) using the on-board clock.One or more elapsed intervals are analyzed to determine a corresponding communication bit rate. In some cases, a measured interval corresponds to only one of numerous possible bit rates, which is then selected for use. In some modes, multiple intervals are measured and analyzed to narrow down the possibilities of which bit rate to use, until the possibilities are reduced to one. BRIEF DESCRIPTION OF THE DRAWINGS [8] The methods of disclosure may be described in detail below, with particular reference to the drawings. Throughout this description, similar elements, in any of the methods described, refer to common elements whenever they are referred to and referenced by the same reference number. The characteristics, attributes, functions, or interrelationships attributed to a particular element in a location apply to that element when it is referenced by the same number. Recfr Ln / eznz / B / YiAi reference in another location, unless specifically indicated otherwise. Furthermore, the exact dimensions and dimensional proportions, to conform to the specific strength, weight, or resistance, and similar requirements, will be within the ability of the material, after the following description has been read and understood. [9] All figures are drawn only for the easy explanation of the basic teachings of the present disclosure; the extensions of the figures with respect to the number, position, relationship, and dimensions of the parts to form examples of the various modalities will be explained or will be within the skill of the subject after the present disclosure has been read and understood.

[10] Figure 1 is an illustrative diagram of a remote vehicular communications system, according to some modalities.

[11] Figure 2A is an illustrative diagram of a communications device on the side of the vehicle, according to some modalities.

[12] Figure 2B is an illustrative block diagram of the components of a vehicle-side communications device, according to some modalities.

[13] Figure 3 is a process flow diagram for remotely communicating with an on-board vehicle diagnostic system, according to some modalities.

[14] Figure 4 is a process flow diagram for remotely communicating with an on-board vehicle diagnostic system, according to some modalities. Recfr Ln / eznz / B / YiAi

[15] Figure 5 is an illustrative diagram of the device signals and registers used to determine the bit rate of a communications device, according to some modalities.

[16] Figure 6 shows an illustrative bit sequence when using a 5-bit padding protocol.

[17] Figure 7 is a process flow diagram for selecting a bit rate from among possible bit rates of an on-board vehicle diagnostic system, according to some modalities. DETAILED DESCRIPTION OF THE INVENTION

[18] In order for the disclosure methods to be clearly understood and easily implemented, certain disclosure methods will now be described in greater detail with reference to the accompanying drawings. The description of these methods is provided by way of example only and is not intended to limit the scope of disclosure. It is understood that when reference is made to a layer or element being on, connected to, coupled to, or adjacent to another element or layer, it may be directly on, connected to, coupled to, or adjacent to the other element or layer, or intermediate elements or layers may be present. In contrast, when reference is made to an element being directly on, directly connected to, directly coupled to, or immediately adjacent to another element or layer, no intermediate elements or layers are present.

[19] Figure 1 is an illustrative diagram of a remote vehicular communications system, according to some embodiments. A communications device on the side of vehicle 120 connects to the on-board diagnostic (OBD) system of vehicle 100. In some embodiments, the communications device on the side of vehicle 120 connects via an integrated connector (e.g., the 16-pin connector 215 in Figure 2A) of vehicle 100. The device Recfr Ln / eznz / B / YiAi communications on the vehicle side 120 can also connect to a wide area network (WAN) 125 (e.g., the Internet), such as through a network adapter. A diagnostic / programming tool 150 (e.g., a scan tool) connects to a communications device on the tool side 140, which in turn connects to the WAN 125.

[20] Tool 150 may be a computer installed with diagnostic / programming software, configured to perform diagnostics / programming on a vehicle (e.g., vehicle 100) via the vehicle's OBD system. Tool 150 may be a tool system (e.g., a networked system of computers / devices) that includes multiple configurable / selectable tools for use with multiple vehicle types. Tool 150 may also be a dedicated scan tool (e.g., mobile / portable). The device and / or software may be authorized / produced by the vehicle manufacturer (e.g., an OEM scan tool) and designed to establish a direct / local bidirectional connection with the vehicle (e.g., directly via an integrated OBD connector).A network server 130, and an associated database system 160, can be connected via a local area network (LAN) 145 and / or WAN 125, to assist with the operation / updating of the tool 150, the vehicle-side communications device 120, and / or the tool-side communications device 140. The database system 160 can be configured for the distribution / maintenance of configurations and / or tools, to perform diagnostics / programming on a wide variety of vehicle years / makes / models and their OBD systems.

[21] The device on the tool side 140 and the device on the vehicle side 120 are configured to communicate with each other and, consequently, facilitate the Recfr Ln / eznz / B / YiAi Communications between a tool 150 and the vehicle's OBD system 100. In some modes, a connection between the device on the tool side 140 and a device on the vehicle side 120 is used to simulate or mimic a direct wired connection between the vehicle 100 and the tool 150. In order to communicate with the vehicle's OBD system, a device on the tool side is configured to determine the OBD system's communication bit rate, as further described in this document. In some modes, the bit rate is determined by monitoring the communications transmitted from the OBD system and analyzing the switching of the communication signal's bit states over known time intervals.

[22] In some modalities, additional remote devices (e.g., the remote device) may be used to operate, configure and / or communicate with the device on the tool side 140, tool 150, server 170 / database system 160, device on the vehicle side 120 and / or vehicle 100, via the WAN 125 and / or LAN 145. For example, a remote mechanic shop may use a remote user / workshop device 110 to facilitate / observe a remote programming / diagnostic session between the tool 150 and the vehicle 100.

[23] Figure 2A is an illustrative diagram of a vehicle-side communications device, according to some embodiments. The vehicle-side device 200 is configured to communicate with the vehicle 210, such as through the vehicle's OBD system. The vehicle-side device may include a cable and connector 215, adapted to plug directly into a vehicle OBD connector (e.g., a standardized 16-pin connector). The vehicle's OBD system can communicate signals through the connector by signaling different pins as on or off to reflect, for example, a bit 1 or 0, and modulating or holding these states at particular frequencies (or bit rates). The vehicle-side device Recfr Ln / eznz / B / YiAi The 200 is configured to match the bit rate of the vehicle's OBD system in order to effectively read communications from the OBD system and forward them to a device on the tool side (for example, the device on the tool side 140 in Figure 1). The device on the tool side 140 may also need to adapt its communications with the 150 tool to reflect the bit rate used by the vehicle.

[24] Figure 2B is an illustrative block diagram of the computational components of a vehicle-side communications device, according to some modalities. The computational components 220 include a microprocessor 240, a display 225, and input circuitry 230. The microprocessor 240 in turn includes read-only memory (ROM) 245, memory registers 250, and timer or clock circuitry 255, which are used to monitor / track the timing of signal changes from connected OBD systems in order to determine their bit rates, as further described in this document.

[25] The vehicle communications interface 265 may include an OBD connection interface (e.g., for connecting via a cable and connector 215). The vehicle communications interface 265 may include a pin selector 260 that enables / disables communication via particular pins (e.g., 1 to 16, as shown on connector 215), which can be configured to correspond to the pins used by a particular vehicle / OBD system with which it communicates. In some modes, the pin selector is configured based on information (e.g., a database with VIN records and pin configurations) for connection to the particular vehicle 210. A network interface 235 is used to communicate with other systems via a network (e.g., via the WAN 125), including with a remote communications device on the tool side (e.g., the Recfr Ln / eznz / B / YiAi device on the side of tool 140) and also with a connected programming / diagnostic tool (e.g., tool 150 in Figure 1).

[26] A microprocessor 240 can be programmed with instructions to determine the bit rate of communications received from a vehicle OBD system, such as by using hardware-triggered interrupts and memory registers 250. The programming can first be loaded into RAM 270, transmitted from an external and / or internal storage device (e.g., disk drive, cloud storage), and executed by the microprocessor 240. In some modalities, other components of device 200 and / or external connected devices (e.g., servers, network devices, storage devices, and others not shown) can be configured to implement the attributes and processes described in this document, alone or in combination with device 200.

[27] A computer display 225 (e.g., as shown in device 200) can be used to provide status messages about the communications process and / or other information. User input / output (I / O) 230 (e.g., mouse, alphanumeric keyboard) can be used by an operator to control the vehicular communications device 200, such as to initiate communications, select parameters, and / or perform / program other operations. In some configurations, the computer display 225 operates as an I / O device (e.g., a touchscreen).

[28] The device on the vehicle side is configured to convert vehicle communications 210 into packets that can be communicated to a remote device on the tool side via a 235 network interface. Likewise, the 235 network interface can receive packets from a communication device on the tool side and convert those packets into corresponding pin signals that are transmitted to the vehicle's OBD system via connector 215. In some RQCb Ln / eznz / B / YiAi modalities, a communications device on the tool side can be configured similarly to device 200, in order to communicate with a tool.

[29] Figure 3 is a process flow diagram for remotely communicating with an on-board vehicle diagnostic system, according to several modes. In block 310, a connection is established between the communication device(s) on the vehicle side (e.g., device 120 in Figure 1) and the communication device(s) on the tool side (e.g., device 140 in Figure 1). A network server (e.g., server 130 in Figure 1), for example, can help facilitate connections between the devices (e.g., to establish links, parameters, etc.). In some modes, numerous devices on the vehicle and tool sides are connected / available via one or more networks (e.g., LAN 145 and WAN 125).In block 320, the communication devices on the vehicle side and the tool side (e.g., communication devices 120 and 140) are paired to facilitate a communication session (e.g., between a tool 150 and a vehicle 100). This allows communication between communication devices not intended for each other to be ignored.

[30] In block 330, a communications device on the vehicle side connects to a vehicle in order to establish communication between the vehicle and the tool using communications devices on the tool side and the vehicle side. The connection can be made via a vehicle OBD pin connector, for example, and a cable extending between the connector and a communications device on the vehicle side. Recfr Ln / eznz / B / YiAi

[31] For some vehicle diagnostic systems, the communication bit rate of a vehicle or tool is not published or standardized (e.g., as with many that operate under the general CAN protocol). In some cases, performing scans / programming with a particular tool begins by first determining the bit rate of the vehicle diagnostic system and / or tool. In some vehicle diagnostic systems, the bit rate of a vehicle OBD / CAN system or tool is standardized or published, such as with those that comply with certain standardized protocols (e.g., in compliance with the OBD-II standard).

[32] In block 340, the bit rate of the vehicle OBD system and / or tool is determined so that the communications device on the vehicle side or tool side can communicate with the vehicle and / or tool. In some modes, information about the vehicle (e.g., VIN, make / model / manual input) is used to configure a device on the vehicle side / device on the tool side to use the appropriate bit rates, protocol parameters, and / or tools to communicate with the vehicle. In such cases, some modes proceed without independently determining the bit rate by monitoring / analyzing bit streams, as further described in this document. In some modes, the bit rate used by the vehicle OBD system cannot be determined without obtaining additional information about the OBD system.

[33] In some modalities, the bit rate of the vehicle OBD system or tool is determined by monitoring communications from the vehicle OBD system or tool. The device on the vehicle side or on the tool side may be configured with an integrated timer and registers (e.g., timer 255 and registers 250 in Figure 2B) in which changes in the states (e.g., pin bit states) of the OBD system communications trigger the communications device to record the timing of the changes (e.g., drops). Recfr Ln / eznz / B / YiAi or ascend) in the registers (for example, as shown in Figure 5). The recorded timing differences of the changing states are then analyzed to identify the bit rate of the vehicle's OBD communications. In some modes, information about the protocol used by the vehicle or tool (for example, a bit-stuffing protocol) is used to determine the bit rate, as further described in this document.

[34] In block 350, the OBD system programming protocol and parameters are determined to facilitate communication using the identified bit rate. The protocol and parameters can be determined based on known vehicle information (e.g., VIN, make / model / manual input) or based on monitored OBD system / tool ​​communications using the identified bit rate. For example, monitoring and analyzing certain vehicle / tool ​​communications may indicate specific protocols.

[35] In block 360, if not already selected, a device on the tool side (e.g., diagnostic scan tool, vehicle programming tool) is selected to perform diagnostics and / or programming on the vehicle via the communication link between the communication device on the tool side and the communication device on the vehicle side. The tool can be selected (or configured) based on a predetermined bit rate and / or programming parameters / protocols to ensure compatibility with the vehicle's OBD system.

[36] In block 370, by using the determined bit rate between the device on the vehicle side and the vehicle, and by using the selected tool, diagnostics and / or programming are performed by means of the communications link between the communications device on the tool side and the communications device on the vehicle side. Recfr Ln / eznz / B / YiAi of the vehicle. In some modes, the bit rate between the device on the tool side and the tool is set to be the same as that used between the device on the vehicle side and the vehicle (or vice versa) in order to simulate direct communication between the tool and the vehicle.

[37] Figure 4 is a process flow diagram for remotely communicating with an on-board vehicle diagnostic system, according to several modalities. In block 410, network communications are established between a communications device on the vehicle side and a communications device on the tool side. The device on the tool side (and / or a network server) can be configured to identify / authenticate the device on the vehicle side by a unique identifier (e.g., an identifier directly encoded in the ROM of the communications device on the vehicle side).

[38] In block 420, a communications device on the vehicle side and / or the tool side connects to the connector of a vehicle OBD system (for example, the 16-pin connector 215 in Figure 2A). In some configurations, the communications device on the vehicle side has a connector (for example, a 16-pin connector) compatible with that of the vehicle's OBD connector. Before forwarding communications to a remote tool, the communications device on the vehicle side is used to determine / confirm the bit rate of the vehicle's OBD system.

[39] In block 430, the communications device on the vehicle side or tool side monitors communications transmitted from the OBD connector in a listening mode. In some modes, communications received from a vehicle by a vehicle communications device, during listening mode, are not forwarded to a communications device on the tool side. Recfr Ln / eznz / B / YiAi example, since the vehicle's bit rate may not have been determined, these communications may not be transferred properly.

[40] In block 440, the bits received from the vehicle during listen mode are analyzed to calculate / determine the bit rate used by the vehicle's OBD / CAN system. These bits can be analyzed by monitoring the state (e.g., high or low) of an output channel (e.g., a pin on a pin connector) of the vehicle. In some modes, a timing circuit (e.g., clock / circuit 255 in Figure 2B) of the communications device on the vehicle side operates to increment the clock cycles (e.g., each increment represents a number of nanoseconds) during listen mode. In some modes, the communications device on the vehicle / tool ​​side is configured to be triggered (e.g., by hardware-triggered interrupts) to record the clock count by the timing circuit when the signal state of a pin switches (i.e., from low to high or from high to low).

[41] In block 450, signal pulse amplitudes are estimated based on an analysis of the timing of bit state changes. For example, Figure 5 shows an illustrative diagram of the device signals and registers used to determine the bit rate of a communications device, according to some modalities. Register A is used to record the first pin state change (e.g., high to low or low to high), while register B is used to record the next pin state change. In some modalities, an interrupt handler is responsible for reading the register values ​​and calculating the difference between them to determine the pulse amplitude in timer ticks (and, consequently, the total time). Multiple pulse amplitudes can be calculated for multiple signals. η / СZЖРЖ / В / ХЙЛЙ

[42] Referring again to Figure 4, in block 460, based on the pulse amplitude(s) of the bit(s) estimated in block 450, the OBD system bit rate is determined. In some modes, after measuring a number of pulse amplitudes, certain bit rates are eliminated as possibilities until only one possible bit rate is identified. For example, if a pulse amplitude of two microseconds is detected from the possibilities in Tables 1 and 2, the only remaining possibility is a bit rate of 500 kHz. Table 1. Bit Pulse Times with “Fill” Synchronization Protocol Recfr Ln / eznz / B / YiAi 5 Bit Bit Rate 1 bit 2 bits 3 bits 4 bits 5 bits 500 kHz 2 ps 4 ps 6 ps 8 ps 10 ps 250 kHz 4 ps 8 ps 12 ps 16 ps 20 ps 125 kHz 8 ps 16 ps 24 ps 32 ps 40 ps 100 kHz 10 ps 20ps 30ps 40ps 50ps 50kHz 20ps 40ps 60ps 80ps 100ps Table 2. Possible Timer Tic Values ​​Using a 16-Chord Clock MHz Bit Rate 1 bit 2 bits 3 bits 4 bits 5 bits 500 kHz 32 64 96 128 160 250 kHz 64 128 192 256 320 125 kHz 128 256 384 512 640 100 kHz 160 320 480 640 800 50kHz 320 640 960 1280 1600

[43] In some modalities, information about the standards or boundary conditions used by the OBD system / vehicle tool (e.g., a bit-stuffing protocol) is used to determine or expedite the determination of the OBD system's bit rate. For example, if a particular vehicle make and model is known to use only a subset of possible bit rates, this information can be used to narrow down the possible bit rates with the recorded pulse amplitudes.

[44] With reference to Figure 6A, for example, it can be determined that an OBD system / tool ​​uses a particular synchronization protocol regardless of the bit rate. In some OBD systems, to maintain synchronization between two controllers, for example, a bit-stuffing protocol is used that establishes a maximum consecutive number (e.g., five) of bits of the same polarity. As shown in Figure 6A, after five consecutive bits of the same polarity, a bit of opposite polarity is inserted. This bit is inserted by the sending controller and removed by the receiving controller, and it is not part of the transmitted data. Figure 6A illustrates a bit sequence showing the logic-level bit sequence that has the stuffing bits displayed as X. Although bit stuffing is designed for synchronization, in some modes the maximum number of consecutive bits is used to speed up bit rate determination.

[45] Figure 6B is a table of bit rates and the respective number of bits transmitted during a particular period. In one mode, a selected number of possible bit rates are possible for a given OBD system using a 5-bit padding protocol. The table in Figure 6B indicates the time interval for particular numbers of bits to be transmitted for each given possible bit rate, while Figure 7 indicates the corresponding clock cycles when used with a 16 MHz clock.

[46] In block 470, using the bit rate determined in block 460, it RQCb Ln / eznz / B / YiAi establishes bidirectional communication between the vehicle and a tool, through the communications device on the vehicle side and the remote communications device on the tool side. In some modes, the selected bit rate is confirmed, such as by monitoring communications using the selected bit rate and determining that errors indicative of an incorrect bit rate do not repeatedly occur.

[47] Figure 8 is a process flow diagram for selecting a bit rate from among possible bit rates of an on-board vehicle diagnostic system, according to several modalities. In block 810, the process for determining the bit rate of a vehicle OBD system (or tool) begins after a vehicle communications device is connected to the OBD system (or a communications device on the tool side is connected to a tool). The vehicle communications device is configured to monitor changes in the states of the bit signals (e.g., from an OBD connector). In block 820, a free-running clock (e.g., clock 255 in Figure 2B) is started, which cycles (ticks) at a known frequency (e.g., 16 MHz).In some configurations, the clock speed / frequency used / selected is based on the highest possible bit rate expected from the on-board diagnostic system. In some configurations, the clock frequency is set / selected to be at least approximately twice the highest possible bit rate expected from the vehicle's OBD system. For example, when the highest expected frequency of the vehicle's OBD system is 500 kHz, the clock speed / frequency should be at least approximately 1 MHz, and a 4 MHz clock can be used for bit rate determination instead of a 16 MHz clock. A person skilled in the art will recognize that there are a variety of ways to determine and adjust for different clock speeds / frequencies.

[48] ​​In block 830, by using bit state change monitoring, a first edge (falling / rising) of the bit sequence signal is detected. When the edge is detected, the clock cycle count is recorded in computer memory. η / СZЖРЖ / В / ХЙЛЙ In some configurations, an interrupt-triggered process records the clock tick count in a memory register when a falling or rising edge of a bit sequence signal is detected (for example, as illustrated in Figure 5). In block 840, a second edge of a pair of edges of the bit sequence signal is detected, and the number of clock cycles associated with the second edge is recorded in memory.

[49] In block 850, after the second edge is registered in response to an interrupt, the difference in the registered clock counts is calculated, and the pulse amplitude representing one or more bits is estimated based on the clock frequency. In some modes, various factors can impact the accuracy of the calculated pulse amplitudes, including, for example, bus capacitance, clock differences between controllers, and pulse alignment with OBD system clock transitions.

[50] In some modes, a tolerance (e.g., ±5% tolerance) is used when estimating pulse amplitudes, and the amplitudes can be adjusted based on their proximity to possible expected pulse amplitudes. In some modes, when an estimated amplitude is ambiguous with respect to multiple possible amplitudes, this ambiguity is factored into the calculation / estimation made in block 860. For example, if a possible detected pulse amplitude could be either 8 microseconds or 10 microseconds, based on the tolerances, this ambiguity can be factored into the elimination / narrowing of possible bit rates.

[51] In block 860, the measured amplitudes of one or more pulses are analyzed to determine whether the amplitudes correlate with a single possible bit rate, or a subset of possible bit rates. For example, Table 3 shows a sample table of detected pulse amplitudes and their corresponding possible bit rates. In some modes, the selection of possible bit rates is based on information about the vehicle or, more broadly, on bit rates in use. RQCb Ln / eznz / B / YiAi generally within the automotive industry and / or by manufacturers. Table 3. Possible pulse amplitudes for selected bit rates of an on-board vehicle diagnostic system. η / СZЖРЖ / В / ХЙЛЙ Detected Pulse Amplitude Option 1 Option 2 Option 3 4ps 250 kHz: 500 kHz: None 8ps 125 kHz: 250 kHz: 500 kHz: 10ps 100 kHz: 500 kHz: None 16ps 125 kHz: 250 kHz: None 20ps 250 kHz: None None 40ps 100 kHz: 125 kHz: None

[52] In some modes, edge detection is performed by a process (e.g., from a multi-process program) that queries / monitors the sending of a pin signal. When the bit signal state changes, the clock count is recorded by the process (e.g., in a memory register). After an initial state change is detected (e.g., the first edge), the process continues monitoring for a further state change. After the second state change is detected, the clock count is recorded, and an interrupt is called to calculate / estimate the respective pulse amplitude and determine if the bit rate can be determined in block 860.In some configurations, a circuit (e.g., the edge-driven SR circuit) can be configured to receive an input signal (i.e., from the OBD system) and trigger an output (i.e., a trigger / clock count) when a rising or falling edge occurs across the signal.

[53] After each possible bit rate has been eliminated, the process terminates and the bit rate is selected in block 870. For example, if two of the three possible bit rates in Figure 9 are eliminated, the remaining bit rate is selected. In some modes, if multiple possible bit rates are correlated with the determined pulse amplitude(s), the process continues by resetting the routine in block 855 to register the first and second edges and calculating one or more additional pulse amplitudes starting in block 830. This cycle can continue until each possible bit rate has been eliminated, and only one possible bit rate remains and is selected. In some modes, the process may exhaust itself (abort) if a maximum number of iterations occurs and no single bit rate has been determined.

[54] In some modes, if every possible bit rate other than one cannot be easily eliminated based on the estimated pulse amplitudes after a particular number of pulses are recorded, the process can perform further analysis after that particular number of pulses occurs. For example, the process can be factored into a bit-stuffing protocol to further eliminate various possibilities. In one mode, the recorded pulse amplitudes that directly correlate with particular bit rates are compared with the presence of recorded pulse amplitudes that exceed certain amplitudes that satisfy the bit-stuffing protocol for that particular bit rate, but might not satisfy another possible bit rate, thereby further eliminating one or more possible bit rates.This process can continue (from analyzing sequences of the predetermined number of pulses / pulse amplitudes) until all but one possible bit rate are eliminated.

[55] The processes described in this document (for example, the processes in Figures 3, 4, and 8) are not limited to use with the hardware shown and described herein. They may be applicable in any computing or processing environment and with any type of machine or set of machines capable of running a computer program. The processes described in this document may be implemented in hardware, software, or a combination of both. The processes described in this document may be implemented in computer programs. Recfr Ln / eznz / B / YiAi executed on programmable computers / machines, each including a processor, a non-transient machine-readable medium or other manufactured item readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device to perform any of the processes described herein and to generate output information.

[56] The processing blocks (e.g., in the processes in Figures 3, 4, and 8), associated with the implementation of the system, may be carried out by one or more programmable processors executing one or more computer programs to perform the system functions. All or part of the system may be implemented using electronic hardware circuitry, which includes electronic devices such as, for example, at least one processor, memory, programmable logic device, and / or logic gate. All or part of the system may be implemented as special-purpose logic circuitry (e.g., an FPGA (field-programmable gate array) and / or an ASIC (application-specific integrated circuit)).

[57] The processes described in this document are not limited to the specific examples shown. For example, the processes in Figures 3, 4, and 8 are not limited to the specific processing orders illustrated. Instead, any of the processing blocks can be rearranged, combined, or removed, and performed in parallel or serially, as needed, to achieve the results set out above.

[58] The elements of different modalities, described in this document, may be combined to form other modalities not specifically set out above. Various elements, described in the context of a single modality, may also be provided separately or in any suitable subcombination. Other Recfr Ln / eznz / B / YiAi modalities, not specifically described in this document, are also within the scope of the following claims.

Claims

1. A method for remote communications with an on-board diagnostic (OBD) system of a vehicle, the method comprising: connecting a vehicular communications device to a connector of an OBD system of the vehicle; connecting a remote tool-side communications device to a connector of a vehicular tool device; establishing a network communications link between the vehicular communications device and a remote communications device; receiving communications at the vehicle-side communications device or tool-side communications device from the respectively connected vehicle OBD system or tool device via the respective connector of the OBD system or tool device; analyzing a bit stream of the received communications during a time interval;Estimating amplitudes of one or more bit pulses based on analysis of the bit stream; determining a bit rate of the OBD system based on the estimated amplitudes of the bit pulse(s); based on the determined bit rate of the OBD system, establishing two-way communications between the OBD system and the tool device by utilizing the network communications link established between the vehicular communications device and the remote communications device.

2. The method of claim 1, wherein analyzing the bit stream comprises calculating time differences between one or more pairs of leading and falling edges of a signal of the bit stream, and wherein determining the bit rate comprises selecting one of a plurality of possible bit rates based on the calculated time differences.

3. The method according to claim 2, wherein the determination is based on a predetermined synchronization protocol of the OBD system.

4. The method according to claim 3, wherein the synchronization protocol comprises a bit stuffing protocol, wherein at least one polarity change is inserted into the signal after five successive bits of the same polarity in the communications received from the OBD system.

5. The method according to claim 2, wherein the calculated time differences comprise time differences between a plurality of pairs of leading and falling edges, and wherein the analysis comprises comparing the time differences with possible total transmission times of a plurality of possible successive bits of the same polarity.

6. The method according to claim 5, wherein each of the time differences is correlated with one or more possible bit rates, and wherein the bit rate of the OBD system is determined based on the correlation of a combination of the time differences with a single possible bit rate.

7. The method according to claim 5, wherein each of the time differences is correlated with one or more possible bit rates, and wherein the OBD system bit rate is determined based on correlating a Recfr Ln / eznz / B / YiAi combination of the time differences with the most probable of a plurality of bit rates.

8. The method according to claim 2, wherein the calculation of the time differences, between one or more pairs of leading and falling edges of a signal of the bit sequence is iterated until a bit rate of the OBD system is determined, or a maximum number of iterations occurs.

9. The method according to claim 2, wherein the plurality of possible bit rates comprises one or more of 50 KHz, 100 KHz, 125 KHz, 250 KHz or 500 KHz.

10. The method according to claim 1, wherein the analysis of the bit sequence of the communications received during a time interval comprises operating a clock on board the vehicular communications device to count clock cycles to estimate the amplitudes of the bit pulse(s).

11. The method of claim 1, wherein establishing two-way communications comprises: communicating from the vehicular communications device via the vehicle OBD system connector using the determined bit rate; and communicating from the remote communications device via the vehicle tool device connector using the determined bit rate.

12. An on-board diagnostic (OBD) vehicle communications system, the system comprising: a vehicle-side communications device comprising a first pin connector adapted to be connected to an OBD system of the vehicle, and a first network interface configured to perform network communications; a remote tool-side communications device comprising a second pin connector adapted to be connected to a vehicle tool device, and a second network interface configured to perform network communications with the vehicle-side communications device;wherein at least one of the vehicle-side communications device or the tool-side communications device further comprises one or more processors programmed and configured to cause the respective vehicle-side or tool-side communications device to: receive communications at the respective vehicle-side or tool-side communications device from a respective vehicle OBD system or vehicular tool device, via a respective first or second pin connector; analyze a bit stream of the received communications during a time interval; estimate amplitudes of one or more bit pulses based on the analysis of the bit stream; determine a bit rate of the OBD system based on the estimated amplitudes of the one or more bit pulses;based on the determined bit rate of the OBD system, establishing two-way communications between the OBD system and a vehicle tool device by using a network communications link between the vehicle-side communications device and the remote tool-side communications device; 13. The system of claim 12, wherein analyzing the bit stream comprises calculating time differences between one or more pairs of leading and falling edges of a signal of the bit stream, and wherein determining the bit rate comprises selecting one of a plurality of possible bit rates based on the calculated time differences. Recfr Ln / eznz / B / YiAi 14. The system according to claim 13, wherein the determination is based on a predetermined synchronization protocol of the OBD system.

15. The system according to claim 14, wherein the synchronization protocol comprises a bit stuffing protocol, wherein at least one polarity change is inserted into the signal after five successive bits of the same polarity in the communications received from the OBD system.

16. The system according to claim 13, wherein the calculated time differences comprise time differences between a plurality of pairs of leading and falling edges, and wherein the analysis comprises comparing the time differences with possible total transmission times of a plurality of possible successive bits of the same polarity.

17. The system according to claim 13, wherein each of the time differences is correlated with one or more possible bit rates, and wherein the bit rate of the OBD system is determined based on the correlation of a combination of the time differences with a single possible bit rate.

18. The system according to claim 17, wherein each of the time differences is correlated with one or more possible bit rates, and wherein the bit rate of the OBD system is determined based on correlating a combination of the time differences with the most probable of a plurality of bit rates.

19. The system according to claim 13, wherein the calculation of the time differences, between one or more pairs of leading and falling edges of a signal of the bit sequence is iterated until a bit rate of the OBD system is determined, or a maximum number of iterations occurs.

20. The system according to claim 13, wherein the plurality Recfr Ln / eznz / B / YiAi of possible bit rates comprises one or more of 50 KHz, 100 KHz, 125 KHz, 250 KHz or 500 KHz.

21. The system according to claim 12, wherein the vehicular communications device comprises an on-board clock, and wherein the analysis of the bit sequence of the communications received during a time interval comprises operating the on-board clock to count clock cycles to estimate the amplitudes of the bit pulse(s).

22. The system of claim 12, wherein establishing two-way communications comprises: communicating from the vehicular communications device via the vehicle OBD system connector using the determined bit rate; and communicating from the remote communications device via the vehicle tool device connector using the determined bit rate.

Images