CROSS-REFERENCE TO RELATED PATENT APPLICATION [0001] This is a utility application based upon and claims priority of application 63/195,490 filed on June 1, 2021. This related application is incorporated herein by reference and made a part of this application. If any conflict arises between the disclosures in this utility application and that in the related provisional application, the disclosure in this utility application shall govern. Moreover, the inventor(s) incorporate herein by reference any and all patents, patent applications, and other documents hard copy or electronic, cited or referred to in this application.

BACKGROUND Field of the Disclosure

[0002] The present disclosure relates generally to methods and apparatus that perform vehicle system communications.

Description of Related Art

[0003] On-board diagnostics ("OBD") systems enable a vehicle owner or technician to access vital information about and program various modules, systems, and sub-systems within a vehicle. Manufacturers have included OBD systems in their vehicles for many years. In a traditional repair setting, a technician utilizes a specialized scan tool that is adapted to interface with a given vehicle's OBD system using the vehicle's data link connector (“DLC”). Many such OBD systems operate through a controller area network (CAN) of the vehicle, which facilitates communications between interconnected sub systems of a vehicle. The scan tool is capable of reading data about the vehicle's modules, systems, and sub-systems for diagnostic purposes while also enabling some reprogramming of the modules, systems, and sub-systems. Typically, these scan tools are stand-alone handheld computing devices connected directly to a vehicle via a cable with a plug on one end that can plug into the vehicle’s DLC.

[0004] Numerous standards have been implemented for vehicle diagnostic systems and communication protocols, some mandated for tracking and inspecting such features as emission control. These communication standards include, for example, OBD-1, OBD-II, SAE J2534, SAE J1850 PWM (pulse-width modulation), ISO 15765, and ISO 9141-2. One common standardized feature of OBD systems has become the use of a 16-pin DLC, usually located under the dashboard of the vehicle. Many vehicle manufacturers utilize this connection system and have adopted the aforementioned communication standards that are shared with the public for performing basic diagnostic and reprogramming functions.

[0005] Many manufacturers also use these same OBD systems to repair and update various advanced computerized systems within a vehicle. There are some diagnostic/programming tools which can utilize personal computers and remote networking systems. A problem with using such systems, however, is determining the protocol and other parameters for communicating with a given vehicle’s OBD system, which can vary significantly across vehicles and may not be readily ascertainable from documentation. These parameters may include a communications bitrate, for example. Before facilitating remote communications with an OBD system, such as with a network communications device, the communications parameters of the OBD system must be determined.

SUMMARY

[0006] Embodiments of the present disclosure include systems and methods for implementing communications between vehicle on board diagnostics (“OBD”) systems and remote scan / programming tools designed for addressing issues in such communications. A communication system includes a vehicle-(or car-)side communications device that is configured to plug into or otherwise connect to an OBD system connector (e.g., DLC) and has a network communications interface for facilitating bi-directional communication between the OBD system and remote network devices. The system also includes a tool-side (or remote) communications device that has a connector which permits a scan / programming tool to plug into the tool-side communications device as if it were the connector to a vehicle’s OBD system. The tool-side device also has a network communications interface that facilitates bi-directional communications between a connected scan/programming tool and an OBD system connected to a car-side device through its respective network communications interface.

[0007] In some vehicle communications and/or vehicle tool systems, the bit-rate of the system is set or determinable by a protocol standard (e.g., utilizing OBD-II). In some systems, the bit rate of the system is not standardized or published (e.g., in some implementations of the CAN protocol). In some embodiments, where the bit rate is not known (e.g., is not standardized or published), the vehicle-side device is configured to determine a bitrate used by the OBD system (of either a vehicle-side or tool-side communications device) before providing network communications. In some embodiments, the bitrate is determined by monitoring a communication output (e.g., a signal on a connection pin) of an OBD connector of the OBD system/Tool and using an onboard computer clock of the vehicle/tool-side device that tracks elapsed time during the monitoring. The monitoring includes identifying when the state of the OBD output changes (e.g., a leading edge or falling edge of a signal) and tracking the elapsed interval between such events (e.g., pulse widths) using the onboard clock. One or more tracked elapsed intervals are analyzed to determine a corresponding communications bitrate. In some cases, a measured interval corresponds with only one of numerous possible bitrates, which is then selected for use. In some embodiments, multiple intervals are measured and analyzed to narrow the possibilities of which bitrate is used until the possibilities are narrowed to one possibility.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Embodiments of the disclosure may be described hereafter in detail with particular reference to the drawings. Throughout this description, like elements, in whatever embodiment described, refer to common elements wherever referred to and reference by the same reference number. The characteristics, attributes, functions, interrelations ascribed to a particular element in one location apply to that element when referred to by the same reference number in another location unless specifically stated otherwise. In addition, the exact dimensions and dimensional proportions to conform to specific force, weight, strength and similar requirements will be within the skill of the art after the following description has been read and understood.

[0009] All figures are drawn for ease of explanation of the basic teachings of the present disclosure only; the extensions of the figures with respect to number, position, relationship and dimensions of the parts to form examples of the various embodiments will be explained or will be within the skill of the art after the present disclosure has been read and understood.

[0010] FIG. 1 is an illustrative diagram of a remote vehicle communications system according to some embodiments.

[0011] FIG. 2A is an illustrative diagram of a vehicle-side communications device according to some embodiments.

[0012] FIG. 2B is an illustrative block diagram of the components of a vehicle-side communications device according to some embodiments.

[0013] FIG. 3 is a process flow diagram for remotely communicating with an onboard vehicle diagnostics system according to some embodiments. [0014] FIG. 4 is a process flow diagram for remotely communicating with an onboard vehicle diagnostics system according to some embodiments.

[0015] FIG. 5 is an illustrative chart of signals and device registers used for determining the bitrate of a communications device according to some embodiments.

[0016] FIG. 6A shows an illustrative bit stream using a 5-bit stuffing protocol.

[0017] FIG. 6B is a table of bit-rates and the number of respective bits transmitted during a particular time period.

[0018] FIG. 7 is a table of timer increments for particular numbers of bits and bitrates according to some embodiments.

[0019] FIG. 8 is a process flow diagram for selecting a bit rate among possible bitrates of an onboard vehicle diagnostics system according to some embodiments.

[0020] FIG. 9 is a table of possible pulse widths for selected bitrates of an onboard vehicle diagnostics system according to some embodiments.

DETAILED DESCRIPTION OF THE INVENTION

[0021] In order that embodiments of the disclosure may be clearly understood and readily carried into effect, certain embodiments of the disclosure will now be described in further detail with reference to the accompanying drawings. The description of these embodiments is given by way of example only and not to limit the scope of the disclosure. It will be understood that when an element or layer is referred to as being "on", "connected to", "coupled to", or "adjacent to" another element or layer, it can be directly on, connected, coupled, or adjacent to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being "directly on," "directly connected to", "directly coupled to", or "immediately adjacent to" another element or layer, there are no intervening elements or layers present.

[0022] FIG. 1 is an illustrative diagram of a remote vehicle communications system according to some embodiments. A vehicle-side communications device 120 is connected to the on-board diagnostics (OBD) system of a vehicle 100. In some embodiments, the vehicle-side communications device 120 is connected through a built-in connector (e.g., 16-pin connector 215 of FIG. 2A) of vehicle 100. The vehicle-side communications device 120 may be further connected to a wide-area network (WAN) 125 (e.g., the internet) such as through a network adapter. A diagnostics/programming tool 150 (e.g., a “scan tool”) is connected to a tool-side communications device 140 that is further connected to WAN 125.

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

[0024] Tool-side device 140 and vehicle-side device 120 are configured to communicate with each other and thereby facilitate communications between a tool 150 and the OBD system of vehicle 100. In some embodiments, a connection between tool-side device 140 and a vehicle-side device 120 is used to simulate or mimic a direct- wired connection between vehicle 100 and tool 150. In order to communicate with the vehicle’s OBD system, a tool-side device is configured to determine the communication bitrate of the OBD system such as further described herein. In some embodiments, the bitrate is determined by monitoring communications transmitted from the OBD system and analyzing the toggling of bit states of the communication signal over known time intervals.

[0025] In some embodiments, additional remote devices (e.g., remote device ) may be used to operate, configure, and or communicate with tool-side device 140, tool 150, server 170/database system 160, vehicle-side device 120, and/or vehicle 100 through WAN 125 and or LAN 145. Lor example, a remote vehicle shop may use a remote user/shop device 110 to facilitate/observe a remote programming/diagnostics session between tool 150 and vehicle 100.

[0026] FIG. 2A is an illustrative diagram of a vehicle-side communications device according to some embodiments. Vehicle-side device 200 is configured to communicate with vehicle 210 such as through the vehicle’s OBD system. Vehicle-side device may include a cable and connector 215 adapted to directly plug into a vehicle’s OBD connector (e.g., a standardized 16-pin connector). The vehicle’s OBD system may communicate signals through the connector by signaling different pins as “on” or “off’ to reflect, for example, a 1 or 0 bit, and modulate or maintain these states at particular frequencies (or bitrates). Vehicle-side device 200 is configured to adapt to the bit-rate of the vehicle’s OBD system in order to effectively read the communications from the OBD system and forward them to a tool-side device (e.g., tool-side device 140 of LIG. 1). Tool-side device 140 may also need to adapt its communications with tool 150 to reflect the bitrate used by the vehicle.

[0027] FIG. 2B is an illustrative block diagram of the computing components of a vehicle-side communications device according to some embodiments. Computing components 220 include a microprocessor 240, display 225 and input circuitry 230. Microprocessor 240 in turn includes read only memory (ROM) 245, memory registers 250, and timer circuitry or clock 255 which are used to monitor/track the timing of signal changes from connected OBD systems in order to determine their bitrates such as further described herein.

[0028] Vehicle communications interface 265 may include an OBD connection interface (e.g., for connecting through a cable and connector 215). Vehicle communications interface 265 may include a pin selector 260 which activates/deactivates communication through particular pins (e.g., 1 through 16 as shown in connector 215), which may be configured to correspond with the pins used by a particular vehicle/OBD system being communicated with. In some embodiments, the pin selector is configured based on information (e.g., a database with records of VINs and pin configurations) for connecting with the particular vehicle 210. A network interface 235 is utilized to communicate with other systems through a network (e.g., across WAN 125), including with a remote tool-side communications device (e.g., tool-side device 140) and further with a connected programming/diagnostics tool (e.g, tool 150 of FIG. 1).

[0029] A microprocessor 240 may be programmed with instructions to determine the bitrate of communications received from a vehicle OBD system such as by using hardware-driven interrupts and memory registers 250. The programming may be first loaded into RAM 270, transmitted from an external and/or internal storage device (e.g., disk drive, Cloud storage), and executed by microprocessor 240. In some embodiments, other components of device 200 and/or external connected devices (e.g., servers, network devices, storage devices and others that are not shown) may be configured to implement the features and processes described herein alone or in combination with device 200.

[0030] A computer display 225 (e.g., as shown in device 200) may be used to provide status messages about the communications process and/or other information. User input/output (I/O)

230 (e.g., mouse, keyboard) may be used by an operator to control the vehicle communications device 200 such as to initiate communications, select parameters, and or perform/program other operations. In some embodiments, computer display 225 operates as an I/O device (e.g., a touchscreen).

[0031] Vehicle-side device is configured to convert communications from vehicle 210 into packets that can be communicated to a remote tool-side device through a network interface 235. Likewise, network interface 235 may receive packets from a tool-side communication device/tool and convert those packets into corresponding pin signals that are transmitted to the vehicle’ s OBD system via connector 215. In some embodiments, a tool-side communications device may be configured in similar fashion to device 200 in order to communicate with a tool.

[0032] FIG. 3 is a process flow diagram for remotely communicating with an onboard vehicle diagnostics system according to some embodiments. At block 310, a connection is established between vehicle-side communications device(s) (e.g., device 120 of FIG. 1) and tool-side communications device(s) (e.g., device 140 of FIG. 1). A network server (e.g., server 130 of FIG. 1), for example, may assist with facilitating connections between the devices (e.g., for establishing links, parameters, etc.). In some embodiments, numerous vehicle-side and tool-side devices are connected/available through one or more networks (e.g., LAN 145 and WAN 125).

At block 320, the vehicle-side and tool-side communications devices (e.g., communications devices 120 and 140) are paired with each other for facilitating a communications session (e.g., between a tool 150 and a vehicle 100). That way, for example, communications between communications devices not intended for each other can be ignored/dismissed.

[0033] At block 330, a vehicle-side communications device is connected with a vehicle in order to perform communications between the vehicle and tool via tool-side and vehicle-side communications devices. The connection may be through a vehicle OBD pin connector, for example, and a cable extending between the connector and a vehicle-side communications device. [0034] For some vehicle diagnostics systems, the communications bit rate of a vehicle or tool is not published or standardized (e.g., as many that operate under the general CAN Protocol). In some embodiments, performing scans/programming with a particular tool commences by first determining the bit rate of the vehicle diagnostics system and/or tool. In some vehicle diagnostics systems, the bitrate of a vehicle OBD/CAN system or tool is standardized or published such as with those compliant with certain standardized protocols (e.g., in compliance with the OBD-II standard).

[0035] At block 340, the bitrate of the vehicle OBD system and/or tool is determined so that the vehicle-side or tool-side communications device can communicate with the vehicle and/or tool. In some embodiments, information about the vehicle (e.g., VIN number, make/model/manual entry) is utilized to configure a vehicle-side device/tool-side device to use the proper bitrates, protocol parameters, and or tools for communicating with the vehicle. In such instances, some embodiments proceed without independently determining the bitrate by monitoring/analyzing bit- streams such as further described herein. In some embodiments, the bitrate used by the vehicle OBD system cannot be determined without obtaining additional information about the OBD system.

[0036] In some embodiments, the bitrate of the vehicle OBD system or tool is determined by monitoring communications from the vehicle OBD system or tool. The vehicle-side or tool-side device may be configured with a built-in timer and registers (e.g., timer 255 and registers 250 of FIG. 2B) in which changes in the states (e.g., bit states of the pins) of communications from the OBD system trigger the communications device to record the timing of the changes (e.g., falling or rising) in the registers (e.g., as shown in FIG. 5). The recorded timing differences of the changing states are then analyzed to identify the bit-rate of OBD communications from the vehicle. In some embodiments, information about the protocol used by the vehicle or tool (e.g., a bit-stuffing protocol) is used to determine the bitrate as further described herein.

[0037] At block 350, the protocol and programming parameters of the OBD system are determined to facilitate communications using the identified bitrate. The protocol and parameters may be determined based on known information about the vehicle (e.g., VIN number, make/model/manual entry) or based on communications monitored from the OBD system/tool using the identified bitrate. For example, monitoring and parsing certain communications from the vehicle/tool may be indicators of certain protocols.

[0038] At block 360, if not already selected, a tool-side device (e.g., diagnostics scan tool, vehicle programming tool) is selected for performing diagnostics and/or programming on the vehicle through the communications link between the tool-side communications device and the vehicle-side communications device. The tool may be selected (or configured) based on the determined bitrate and or programming/protocol parameters so as to be compatible with the vehicle OBD system.

[0039] At block 370, using the determined bitrate between the vehicle-side device and vehicle and using the selected tool, diagnostics and or programming are performed via the communications link between the tool-side communications device and vehicle-side communications device. In some embodiments, the bitrate between the tool-side device and tool is configured to be the same as that used between the vehicle-side device and vehicle (or vice versa) so as to mimic a direct communication between the tool and vehicle.

[0040] FIG. 4 is a process flow diagram for remotely communicating with an onboard vehicle diagnostics system according to some embodiments. At block 410, network communications are established between a vehicle-side communications device and a tool-side communications device. The tool-side device (and/or a network server) may be configured to identify/authenticate the vehicle-side device by a unique identifier (e.g., a hard-coded identifier in ROM of the vehicle- side communications device).

[0041] At block 420, a vehicle-side and or tool-side communications device is connected to the connector of a vehicle OBD system (e.g., a 16-pin connector 215 of FIG. 2A). In some embodiments, the vehicle-side communications device has a connector (e.g., 16-pin connector) compatible with that of the vehicle’ s OBD connector. Prior to forwarding communications to a remote tool, the vehicle-side communications device is used to determine/confirm the bitrate of the vehicle’ s OBD system.

[0042] At block 430, the vehicle-side or tool-side communications device monitors communications transmitted from the OBD connector in a “listening mode.” In some embodiments, the communications received from a vehicle by a vehicle communications device during the listening mode are not forwarded to a tool-side communications device. For example, because the bitrate of the vehicle may not have been determined, these communications may not be properly transferred.

[0043] At block 440, the bits received from the vehicle during the listening mode are analyzed in order to calculate/determine the bitrate used by the vehicle’s OBD/CAN system. These bits may be analyzed by monitoring the state (e.g., high or low) of an output channel (e.g., pin of a pin connector) of the vehicle. In some embodiments, a timing circuit (e.g., clock/circuit 255 of FIG. 2B) of the vehicle-side communications device operates to increment clock cycles (e.g., each increment representing a number of nanoseconds) during the listening mode. In some embodiments, the vehicle/tool-side communications device is configured to be triggered (e.g., by hardware-driven interrupts) to record the clock count by the timing circuit when the signal state of a pin toggles (i.e., from low to high or high to low).

[0044] At block 450, the widths of signal pulses are estimated based on analyzing the timing of the bit state changes. For example, FIG. 5 shows an illustrative chart of signals and device registers used for determining the bitrate of a communications device according to some embodiments. An “A” register is used to record a first change in pin state (e.g., high to low or low to high) while a “B” register is used to record the next change of pin state. In some embodiments, an interrupt handler is responsible for reading the values from the registers and calculating the difference between them to determine the width of a pulse in timer ticks (and thereby total time). Multiple pulse widths for multiple signals may be calculated.

[0045] Referring again to FIG. 4, at block 460, based on the width(s) of bit pulse(s) estimated at block 450, the bitrate of the OBD system is determined. In some embodiments, after a number of pulse widths are measured, certain bitrates are eliminated as possibilities to the point where a single possible bitrate is identified. For example, if a pulse width of two microseconds is detected among the possibilities of FIGs. 6B and 7, the only remaining possibility is a bitrate of 500 KHz. [0046] In some embodiments, information about the standards or boundary conditions used by the vehicle OBD/tool system (e.g., a bit-stuffing protocol) are used to determine or accelerate determination of the bitrate of the OBD system. For example, if a particular vehicle make and model are known to use only a subset of possible bitrates, this information may be used to narrow the possibilities of bitrates with the recorded pulse widths.

[0047] Referring to FIG. 6A, for example, an OBD/tool system may be known to use a particular synchronization protocol regardless of bitrate. In some OBD systems, to maintain synchronization between two controllers, for example, a bit stuffing protocol is used that sets a maximum consecutive/successive number (e.g., five) of bits of the same polarity. As shown in FIG, 6A, after 5 consecutive bits of the same polarity, an opposite polarity bit is inserted. This bit is inserted by the sending controller and removed in the receiving controller and is not part of the data being transmitted. FIG. 6A illustrates a stream of bits showing the logic-level bit stream having the stuffed bits shown as “X”. While bit stuffing is designed for synchronization, some embodiments utilize the maximum number of consecutive bits to accelerate determination of the bit rate.

[0048] FIG. 6B is a table of bitrates and the number of respective bits transmitted during a particular time period. In an embodiment, a select number of possible bit rates are possible for a given OBD system that utilizes a 5-bit stuffing protocol. The table of FIG. 6B indicates the time interval for particular numbers of bits to be transmitted for each given possible bit rate while FIG. 7 indicates the corresponding clock cycles using with a 16 MHz clock.

[0049] At block 470, using the bitrate determined at block 460, bidirectional communications are established between the vehicle and a tool through the vehicle-side communications device and the remote tool-side communications device. In some embodiments, the selected bitrate is confirmed such as by monitoring the communications utilizing the selected bitrate and determining that errors do not repeatedly arise indicative of an incorrect bitrate.

[0050] FIG. 8 is a process flow diagram for selecting a bit rate among possible bit rates of an onboard vehicle diagnostics system according to some embodiments. At block 810, the process for determining the bitrate of a vehicle OBD (or a tool) system begins after a vehicle- communications device is connected to the OBD system (or a tool-side communications device is connected to a tool). The vehicle-communications device is configured to monitor changes in the states of bit signals (e.g., from an OBD connector). At block 820, a free-running clock (e.g., clock 255 of FIG. 2B) is started which cycles (“ticks”) at a known frequency (e.g., 16 MHz). In some embodiments, the speed/frequency of the clock used/selected is based on the greatest possible bit rate expected of the on-board diagnostics system. In some embodiments, the clock frequency is adjusted/selected to be at least about twice that of the greatest possible bit rate expected of the vehicle OBD system. For example, where the greatest expected frequency of the vehicle OBD system is 500 KHz, the clock speed/frequency should be at least about 1 MHz, and a 4 MHz clock may be utilized for bit rate determination rather than a 16 MHz clock. One of ordinary skill in the art will recognize that there are a variety of ways to determine and adjust to a variety of clock speeds/frequencies.

[0051] At block 830, using the monitoring of changes in bit-states, a first (falling/rising) edge of the bit stream signal is detected. When the edge is detected, the number of clock cycles is recorded in computer memory. In some embodiments, an interrupt-driven process records the tick count of the clock in a memory register when a falling or rising edge of a bit-stream signal is detected (e.g., as illustrated in FIG. 5). At block 840, a second edge of a pair of edges of the bit- stream signal is detected and the number of clock cycles associated with the second edge is recorded in memory.

[0052] At block 850, after the second edge is recorded in response to an interrupt, the difference in recorded clock counts is calculated and the width of the pulse representing one or more bits is estimated based on the clock frequency. In some embodiments, various factors may impact the precision of the calculated pulse widths including, for example bus capacitance, clock differences between controllers, and alignment of the pulses with clock transitions of the OBD system.

[0053] In some embodiments, a tolerance (e.g., ±5% tolerance) is utilized when estimating pulse widths and the widths may be adjusted based on their proximity to expected possible pulse widths. In some embodiments, when an estimated width is ambiguous with respect to multiple possible widths, this ambiguity is factored into the calculation/estimation made at block 860. For example, if a possible detected pulse width could be either 8 microseconds or 10 microseconds based on tolerances, this ambiguity can be factored into eliminating/narrowing possible bitrates. [0054] At block 860, the determined widths of one or more pulses is analyzed to determine whether the widths are correlated with a single possible bitrate or a subset of possible bitrates. For example, FIG. 9 shows an exemplary table of detected pulse widths and corresponding possible bitrates. In some embodiments, the selection of possible bitrates is based on information about the vehicle or more broadly on bitrates used generally within the automobile industry and/or manufacturer.

[0055] In some embodiments, edge detection is performed by a process (e.g., of a multi-process program) that polls/monitors the output of a pin signal. When the bit signal state changes, the number of clock counts of a clock is recorded (e.g., in a memory register) by the process. After an initial state change (e.g., the first edge) is detected, the process continues monitoring for an additional state change. After the second state change is detected, the value of clock counts is recorded, and an interrupt is called for calculating/estimating the respective pulse width and determining if the bit rate can be determined at block 860. In some embodiments, a circuit (e.g., edge -triggered S-R 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 over the signal.

[0056] After each of the possible bitrates has been eliminated as a possibility, the process is finished and the bitrate is selected at block 870. For example, if two of the three possible bitrates of FIG. 9 are eliminated, the remaining bitrate is selected. In some embodiments, if multiple possible bitrates correlate with the determined pulse width(s), the process continues by resetting the routine at block 855 of recording first and second edges and calculating additional pulse width(s) beginning at block 830. This cycle may continue until each of the possible bitrates is eliminated and a single possible bitrate remains and is selected. In some embodiments, the process may “time-ouf ’/abort if a maximum number of iterations occurs and a single bitrate has not been determined.

[0057] In some embodiments, if each possible bitrate other than one cannot be readily eliminated based on the estimated pulse widths after a particular number of pulses are recorded, the process may perform additional analysis after that particular number of pulses occurs. For example, the process may factor in a bit-stuffing protocol to further eliminate various possibilities. In an embodiment, recorded pulse widths that correlate directly with particular bitrates are compared to the presence of recorded pulse widths that exceed certain widths compliant with the bit-stuffing protocol for that particular bitrate but would not comply with another possible bitrate, thereby further eliminating one or more possible bitrates. This process may continue (of analyzing sequences of predetermined number of pulses/pulse widths) until all but one possible bitrate is eliminated.

[0058] The processes described herein (e.g., the processes of FIG. 3, 4, and 8) are not limited to use with the hardware shown and described herein. They may find applicability in any computing or processing environment and with any type of machine or set of machines that is capable of running a computer program. The processes described herein may be implemented in hardware, software, or a combination of the two. The processes described herein may be implemented in computer programs executed on programmable computers/machines that each includes a processor, a non-transitory machine-readable medium or other article of manufacture that is 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.

[0059] The processing blocks (for example, in the processes of FIGs. 3, 4, and 8) associated with implementing the system may be performed by one or more programmable processors executing one or more computer programs to perform the functions of the system. All or part of the system may be implemented using electronic hardware circuitry that include electronic devices such as, for example, at least one of a processor, a memory, a programmable logic device, and/or a 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)). [0060] The processes described herein are not limited to the specific examples described. For example, the process of FIGs. 3, 4, and 8 are not limited to the specific processing orders illustrated. Rather, any of the processing blocks may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth above.

[0061] Elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Various elements, which are described in the context of a single embodiment, may also be provided separately or in any suitable sub combination. Other embodiments not specifically described herein are also within the scope of the following claims.