Test and measurement instrument and data analysis method

Abstract

To efficiently analyze data of a bus.SOLUTION: A test and measurement instrument 10 includes: one or more ports to connect one or more devices under test (DUTs) 26 and 28 through a serial bus to one or more channels 16; a user interface 18 to allow a user to provide inputs including a designation of mixed mode for the serial bus; a display 19 to allow a user to view information about the DUTs; and one or more processors 24. The processors 24 are configured to: receive one or more packets from one DUT of the one or more DUTs 26, 28; determine a version of a serial bus standard with which the one DUT complies by identifying characteristics of the packet; use the version of the serial bus standard to decode the packet to produce decoded data; and analyze the decoded packet to monitor traffic on the serial bus and determine if the one DUT of the one or more DUTs 26, 28 is operating correctly.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to decoding and analyzing data on a serial bus that conforms to a particular protocol, and more particularly to decoding and analyzing data in a mixed-mode network having devices that use different versions of the protocol. [Background technology]

[0002] The evolution of computers, capable of higher data rates, has led to communication protocols operating at faster speeds. While some of the newer speed-enhancing standards are backward compatible with older standards, the packet structures differ for each standard. This applies to both low-speed and high-speed serial buses.

[0003] For example, the CAN (Controller Area Network) standard, a low-speed serial bus, has four different versions. CAN 2.0 was introduced first and supports data rates up to 1 Mbps with 8 bytes per message. CAN FD 1.0 (CAN Flexible Data Rate) supports data rates up to 5 Mbps with 64 bytes per message. The standard also has non-ISO and ISO (International Organization for Standardization) versions, but the non-ISO version is largely obsolete. CAN XL (CAN with eXtended Field Length) supports data rates up to 20 Mbps with 2048 bytes per message. ISO standard 11899-1 includes the CAN XL standard. The CAN XL standard is intended to bridge the bit rate gap between CAN / CAN FD and Ethernet 100Base-T1. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2023-115003 [Patent Document 2] Japanese Patent Application Publication No. 2023-550645 [Non-patent literature]

[0005] [Non-Patent Document 1] "How CAN Data Communication Works," Measuring Instrument Lab, Keyence Corporation, [online], [Retrieved July 28, 2025], Internet<https: / / www.keyence.co.jp / ss / products / recorder / lab / candata / mechanism.jsp> Summary of the Invention [Problem to be solved by the invention]

[0006] Because these CAN standards operate at different data rates, users testing CAN networks must configure the selected CAN bus standard for each test. If users want to monitor data across the entire network, they must add a different bus for each standard. This makes it difficult to correlate data from different bus standards within a single network. Furthermore, because each CAN standard has a different packet structure, it is difficult to individually search and identify packets of each CAN standard using multiple user-defined buses.

[0007] Universal Serial Bus (USB) specifies another serial bus standard that has evolved with different data rates for each version of the standard. USB is a high-speed serial bus. Other serial bus standards include Peripheral Component Interconnect Express (PCIe) and DisplayPort. The ability to examine transmissions between devices with different versions of each bus standard to verify the operation of a device under test (DUT) has the same limitations. [Means for solving the problem]

[0008] An embodiment of the present application relates to a test and measurement instrument's ability to verify the operation of a device under test (DUT) when the DUT transmits data over a serial bus. This ability allows different devices on the same bus to use different versions of a serial bus standard, eliminating the need for users to specify different devices on different buses. This allows users to decode and analyze data from buses with different versions of a single serial bus standard without changing their settings. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram of a test and measurement instrument that can be connected to one or more devices under test (DUTs). [Figure 2] FIG. 2 shows a flowchart of an embodiment of a method for detecting a serial bus standard from characteristics of packets on the serial bus. [Figure 3] FIG. 3 shows a diagram of an embodiment of a Controller Area Network (CAN) with multiple devices of mixed CAN standards. [Figure 4] Figure 4 shows an embodiment of a user interface that allows for the selection of a mixed mode. [Figure 5A] FIG. 5A shows a diagram of the different frame structures of the various CAN standards. [Figure 5B] FIG. 5B shows a diagram of the different frame structures of the various CAN standards. [Figure 6] FIG. 6 shows a flowchart of an embodiment of a method for identifying a CAN standard. [Figure 7] Figure 7 is an image of the decoded data from a CAN2.0 device. [Figure 8] Figure 8 shows images of decoded data from CAN XL, CAN 2.0 and CAN FD frames in mixed mode. [Figure 9] Figure 9 shows a diagram of multiple USB standards connected to a USB hub. [Figure 10] FIG. 10 shows a test and measurement device connected to a USB hub. [Figure 11] Figure 11 shows an embodiment of a user interface that enables mixed mode in the USB standard. [Figure 12] FIG. 12 shows a flow chart of an embodiment of a method for determining the format of a USB packet for decoding. [Figure 13] Figure 13 is an image of the decoded data for USB version 2.0. [Figure 14] Figure 14 is an image of the decoded data for USB version 3.0. DETAILED DESCRIPTION OF THE INVENTION

[0010] FIG. 1 illustrates an embodiment of a test and measurement instrument. The test and measurement instrument 10 is connected to a test fixture 14, which in turn is connected to one or more devices under test (DUTs) 26 and 28. In one embodiment, the DUT 26 may comprise a storage device, and the DUT 28 may comprise a computing device, such as a personal computer (PC). This connection may include one or more probes on the test fixture. Although both are referred to as DUTs, the decoding operation applies to either the computing device 28 or the storage device 26 that is transmitting the data. The test fixture 14 transmits USB data through one or more channels 16 on the test and measurement instrument 10. In some embodiments, the test fixture 14 may include the probes. As noted above, the present embodiments typically use only one probe and one channel of the test and measurement instrument, although many more may be used.

[0011] If the data from the test fixture 14 is analog, it is converted to digital by one or more analog-to-digital converters (ADCs), such as ADC 20. The ADC 20 converts the analog data to digital data so that one or more processors, such as processor 24, can operate on the digital data. If the received data consists of digital data, the digital data bypasses the ADC 20. The test and measurement instrument 10 may include memory 22, which enables the one or more processors 24 to store digital and analog data, and may also include programs (code) executed by the one or more processors 24. The user interface (U / I) 18 enables the test and measurement instrument 10 to display at least the resulting current measurement values ​​to a user through a display 19 and may also include controls, such as buttons, knobs, sliders, and trackballs, to allow the user to interact with input signals and the like. The display 19 may include a touchscreen and form part of the user interface 18, such as a graphical user interface.

[0012] The test fixture 14 may provide a communication bus using serial bus standards such as Controller Area Network (CAN), Universal Serial Bus (USB), Peripheral Component Interconnect Express (PCIe), and DisplayPort. Devices 26 and 28 connected to the test fixture may send and receive data via the communication bus with the test and measurement instrument 10 or other devices connected to the test fixture 14. An equipment configuration may include the test fixture 14, which may be replaced by a probe. In some embodiments, the test fixture 14 may take the form of a USB hub, as described below. Other variations of this setup may exist for different protocols.

[0013] 2 shows a flowchart of an embodiment of a method for detecting a serial bus format to which a DUT conforms from characteristics of data transmitted by the DUT. A test and measurement instrument receives packets from one or more DUTs at 30. One or more processors within the test and measurement instrument execute code to perform the embodiment of the method. At 32, the characteristics of the packets are analyzed to determine the version of the bus standard on which the device is operating. These characteristics may include one or more of a number of items, such as the rate at which the DUT transmits the packets, the internal format of the packets (which may include values ​​of certain key bits), and so forth.

[0014] Once the test and measurement equipment determines the version of the serial bus standard used by the DUT, it can decode packets for that specific version at 34. This allows users to analyze transmission errors and analyze requests from different devices coming at different time intervals. This embodiment eliminates the need to add a separate serial bus for each standard or repeatedly change the USB bus speed in the bus configuration menu.

[0015] FIG. 3 shows an embodiment of a network with devices operating under the CAN standard. The various devices operate under different CAN standards. In this example, devices 40 and 48 operate under the CAN XL standard, which operates at speeds up to 16 Mbps. Devices 42, 44, 46, and 50 operate under the CAN FD standard, which operates at speeds up to 5 Mbps. FIG. 4 shows a menu 52 in the user interface of a test and measurement instrument. In FIG. 4, the user can select a mixed mode from drop-down menu 54, which includes CAN 2.0, CAN FD, and CAN XL, informing the test and measurement instrument that the devices under test are operating under different CAN standards. As a reminder, other fields include Source (select the input channel to which the signal is connected) and Threshold (specify the threshold level for detecting a "1" or "0" on the bus). Sample Point defines the bit duration, while the frequency varies as a percentage. The SD Bit Rate, FD Bit Rate and XL Bit Rate fields allow you to set custom bit rates for standard (SD), flexible data rate (FD) and extended length bit rate (XL).

[0016] Figures 5A-5B show different packet formats for different CAN standards. Frame 60 shows the Classic Base frame format. Frame 62 shows the Classic Base frame format for Remote frames. Frame 64 shows the Classic Extended frame format. Frame 66 shows the Classic Extended frame format for Remote frames. The term "Classic" refers to the CAN 2.0 standard. Frame 68 shows the Flexible Data Base frame format. Frame 70 shows the Flexible Data Rate Extended frame format. Figure 5B shows frame 72 of a CAN XL (extended length) frame.

[0017] As can be seen from these frames, there are several key bits that can be used to identify the frame. The Substitute Remote Request (SRR) and Identifier Extension (IDE) bits in CAN Extended Frames are always recessive (logical 1) (see Non-Patent Document 1), which is useful for distinguishing between CAN packets and CAN Extended Packets. In each standard, the next three bits after the 11-bit Identifier (ID) are useful for distinguishing between all non-extended frame packets: 000 is CAN 2.0 Data, 100 is CAN 2.0 Remote, 001 is CAN FD, and 011 is CAN XL.

[0018] 6 shows a flowchart of an embodiment of a method for determining the CAN standard to which a packet transmitted by a DUT and received by a test and measurement instrument conforms. When a packet is received, it is first determined at 80 whether the RTR bit is 0, whether the IDE bit is 0, and whether r0 is 0. If all of these are true, it is a CAN 2.0 frame at 82. Bits r0 and r1 are control bits.

[0019] If the RTR bit is 1 at 84 and the other two bits are 0, then it is a CAN 2.0 remote frame at 86. If the SRR bit is 1, the IDE bit is 1, RTR is 0, r1 is 0, and r0 is 0 at 88, then it is a CAN 2.0 extended data frame at 90. This process continues at 92, and if the SRR bit is 1, IDE is 1, RTR is 1, r1 is 0, and r0 is 0, then it is a CAN 2.0 extended data remote frame at 94. If the RRS bit (Remote Request Substitution) is 0 at 96, IDE is 0, FDF bit is 1, and res is 0, then it is a CAN FD frame at 98. FDF is the bit that distinguishes classic CAN frames from CAN FD frames. The "res" bit is a reserved bit. If SRR is 1, IDE is 1, RRS is 0, FDF is 1 and res is 0 at 100, then the frame is a CAN FD Extended Frame at 102. Finally, if IDE is 0, FDF is 1, XLF is 1 and resXL is 0 at 104, then the frame is a CAN XL Frame at 106. The XLF is a bit that identifies an XLF frame and the resXL bit is a reserved bit for XL frames.

[0020] Figure 7 shows an oscilloscope screen image 108 of a decoded CAN 2.0 package in mixed mode. Figure 8 shows an image of a decoded CAN XL frame, a CAN 2.0 frame, and a CAN FD frame in mixed mode. The image shows the search mark for the CAN XL frame at 110, the search mark for the CAN FD frame at 114, and the search mark for the CAN 2.0 frame at 112.

[0021] The above description focuses on the CAN standard. However, the process of the embodiment also applies to other standards. The description now turns to USB (Universal Serial Bus). USB standards include USB 1.0, 1.1, 2.0, 3.0, 3.1 Gen 1, 3.2 Gen 1, and 3.2 Gen 2.

[0022] 9 shows a configuration in which several devices (devices A-D 122-128) are connected to a USB hub 120. In some embodiments, the USB hub 120 acts as a test fixture in this configuration. In some embodiments, the USB hub 120 may be connected to a computing device 130 that acts as a host for the USB hub.

[0023] In one embodiment, device A 122 is USB version 2.0 compliant, and device B 124, device C 126, and device D 128 are USB version 3.x compliant. When communication occurs between host 130 and hub 120 when all devices are connected, the speed automatically drops to 480 Mbps. This selected speed is not visible to the user until the user confirms the speed.

[0024] To decode this communication to reveal transmission errors, a user may utilize a test and measurement instrument 10, such as an oscilloscope (also known as a "scope"), to capture either the transmitted or received signal. This configuration is shown in FIG. 10. The oscilloscope 10 may be connected to a hub 120 or a host 130, either of which allows the oscilloscope 10 to detect and track transmissions across the bus. Before the user can decode the data with the oscilloscope and determine if there are any errors in the transmission, the oscilloscope 10 must identify the version of the USB standard to which the device conforms. Adding this capability to the oscilloscope allows the oscilloscope to track the data rate.

[0025] Prior to the present embodiment, a user would have had to select a specific speed to properly decode the acquired data. In one situation, if device A 122 were to be disconnected from hub 120, the speed would automatically change to 5 Gbps because all remaining devices were version 3.0 compliant. The user would then have had to change the bus configuration settings to select the appropriate speed to decode the data.

[0026] By adding options to the oscilloscope or test and measurement equipment, the user does not need to reconfigure the bus when the bus speed changes due to the addition or removal of a specific device, such as device A122. Oscilloscope 10 detects the speed and automatically identifies the device standard.

[0027] FIG. 11 shows an embodiment of a user interface 132 that allows a user to select a mixed mode 134 for a bus. This mixed mode causes the test and measurement instrument to "know" that multiple devices on the bus may conform to various versions of the bus standard. Other portions of the interface allow the user to specify the source, display format, and thresholds that allow the detection of logic 0s and 1s on the bus. The DUT under test typically has a set of guidelines that include the data rate at which the device operates. The vendor may modify this speed. If the user does not know the data rate, the user may add a data rate measurement and then select the same in the "Data Rate" drop-down list dedicated to each standard.

[0028] FIG. 12 shows a flowchart of a method for detecting a USB standard based on packet transmission speed characteristics. At 140, a test and measurement instrument is instructed to operate in mixed mode. At 142, the test and measurement instrument detects the speed of the transmission. One or more processors then execute a program for determining which USB standard the device is conforming to when sending the transmission. The process then begins a process for identifying the bus standard at 144 using the speed. If the speed is between 1 Mbps and 12 Mbps, the device transmission is identified at 146 as coming from a Version 1.0 or Version 1.2 compliant device. If the speed is 480 Mbps at 148, the packet is identified and decoded as Version 2.0 at 150. If the speed is 5 Gbps at 152, the packet is identified and decoded at 154 as Version 3.0, Version 3.1 Gen 1, or Version 3.2 Gen 1. If the speed is 10 Gbps at 156, the packet is decoded at 160 as version 3.1Gen2 or version 3.2Gen2.

[0029] Figure 13 shows decoded data for USB version 2.0 on a test and measurement instrument screen 170. Note that the data rate badge 172 indicates a speed of 12.00 Mbps. Figure 14 shows decoded data for USB version 3.0 on a test and measurement instrument screen 174 in mixed mode. The data rate badge 176 indicates a speed of 5 Gbps.

[0030] In this way, users can decode and analyze data packets from a DUT that conforms to any serial bus standard without specifying the bus version. While the above examples show the CAN and USB bus standards, it should be understood that these are examples of how test and measurement equipment can automatically detect and decode packets based on packet characteristics such as packet speed and key bits.

[0031] Aspects of the disclosed technology may operate on specially created hardware, firmware, digital signal processors, or specially programmed general-purpose computers, including processors that operate according to programmed instructions. The terms "controller" or "processor" herein contemplate microprocessors, microcomputers, ASICs, and dedicated hardware controllers, among others. Aspects of the disclosed technology may be implemented with computer-usable data and computer-executable instructions, such as one or more program modules, executed by one or more computers (including a monitoring module) or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc., which, when executed by a processor in a computer or other device, perform particular tasks or implement particular abstract data types. Computer-executable instructions may be stored in computer-readable storage media, such as hard disks, optical disks, removable storage media, solid-state memory, RAM, etc. Those skilled in the art will appreciate that the functionality of the program modules may be combined or distributed as desired in various embodiments. Furthermore, such functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Certain data structures may be used to more effectively implement one or more aspects of the disclosed technology, and such data structures are considered within the scope of the computer-executable instructions and computer-usable data described herein.

[0032] The disclosed aspects may, in some cases, be implemented in hardware, firmware, software, or any combination thereof. The disclosed aspects may also be implemented as instructions carried by or stored on one or more computer-readable media, which may be read and executed by one or more processors. Such instructions may be referred to as a computer program product. As used herein, computer-readable media refers to any medium that can be accessed by a computing device. By way of example, and not limitation, computer-readable media may include computer storage media and communication media.

[0033] "Computer storage media" means any medium that can be used to store computer-readable information. By way of example and not limitation, computer storage media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory and other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) and other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage and other magnetic storage devices, and any other volatile or nonvolatile, removable or non-removable medium implemented in any technology. "Computer storage media" excludes signals themselves and transitory forms of signal transmission.

[0034] A communication medium means any medium usable for communicating computer-readable information. By way of example, and not limitation, communication media may include coaxial cable, fiber optic cable, air, or any other medium suitable for communicating electrical, optical, radio frequency (RF), infrared, acoustic, or other types of signals. Example

[0035] The following examples are provided to aid in understanding the technology disclosed in this application. Embodiments of the technology may include one or more of the examples described below, and any combination thereof.

[0036] Example 1 is a test and measurement instrument comprising: one or more ports for connecting one or more devices under test (DUTs) to one or more channels of the test and measurement instrument via a serial bus; a user interface that allows a user to provide input to the test and measurement instrument, including a specification of a mixed mode of the serial bus; a display that allows a user to view information about the one or more DUTs; and one or more processors, the one or more processors configured to execute a program that causes the one or more processors to perform the following processes: receive one or more packets from one DUT among the one or more DUTs; determine a version of the serial bus standard to which the one DUT complies by identifying characteristics of the packet; decode the packet using the version of the serial bus standard to generate decoded data; and analyze the decoded data to monitor traffic on the serial bus and determine whether the one DUT among the one or more DUTs is operating correctly.

[0037] Example 2 is the test and measurement instrument of Example 1, wherein the mixed mode includes a mode in which the one or more DUTs operate using a single bus even though each of the one or more DUTs complies with multiple versions of the serial bus standard.

[0038] A third embodiment is the test and measurement instrument of either the first or second embodiment, wherein the serial bus includes a CAN (Controller Area Network) bus.

[0039] Example 4 is the test and measurement instrument of Example 3, wherein the version of the serial bus standard is one of CAN 2.0, CAN FD (CAN with Flexible Data Rate), and CAN XL (CAN with Extended Data Field Length).

[0040] Example 5 is a test and measurement device of any of Examples 1 to 4, wherein the program that causes the one or more processors to perform a process to determine the version of the serial bus standard by identifying characteristics of the packet includes a process to identify one or more key bits.

[0041] Example 6 is the test and measurement instrument of Example 5, in which the one or more key bits include at least one of a Remote Transmission Request (RTR), an Identifier Extension (IDE), a Remote Request Substitution (RRS), a Substitute Remote Request (SRR), a control bit r0, a control bit r1, a reserved bit res, FDF, XLF, and resXL.

[0042] Example 7 is the test and measurement instrument of any of Examples 1 to 6, wherein the one or more processors are further configured to execute a program that causes the one or more processors to display the decoded data with search marks so that the user can identify data for various versions of the serial bus standard.

[0043] Example 8 is the test and measurement instrument of any of Examples 1 to 7, wherein the serial bus includes a USB (Universal Serial Bus).

[0044] Example 9 is the test and measurement instrument of Example 8, wherein the version of the serial bus standard includes any one of USB1.0, USB1.1, USB2.0, USB3.0, USB3.1, USB3.2Gen1, and USB3.0Gen2.

[0045] Example 10 is the test and measurement instrument of Example 8, wherein the program that causes the one or more processors to perform a process to determine the version of the serial bus standard by identifying characteristics of the packet includes a program that causes the one or more processors to perform a process to identify the data rate at which the packet was transmitted.

[0046] Example 11 is a method including receiving input from a user to set a mode of a test and measurement instrument to a mixed mode indicating that packets may be based on one or more versions of a serial bus standard; receiving one or more packets from a DUT among one or more DUTs; determining a version of the serial bus standard to which the one DUT conforms by identifying characteristics of the packets; decoding the packets using the version of the serial bus standard to generate decoded data; and displaying the decoded data on a user interface of the test and measurement instrument.

[0047] Example 12 is the method of example 11, wherein the mixed mode includes a mode in which the one or more DUTs operate using a single bus even though each of the one or more DUTs complies with multiple versions of the serial bus standard.

[0048] Example 13 is the method of either example 11 or 12, wherein the serial bus includes a CAN (Controller Area Network) bus.

[0049] Example 14 is the method of Example 13, wherein the version of the serial bus standard is one of CAN 2.0, CAN FD (CAN with Flexible Data Rate), and CAN XL (CAN with Extended Data Field Length).

[0050] Example 15 is a method of any of Examples 11 to 13, wherein the process of determining the version of the serial bus standard by identifying characteristics of the packet includes a process of identifying one or more key bits.

[0051] Example 16 is the method of example 15, wherein the one or more key bits include at least one of RTR (Remote Transmission Request), IDE (Identifier Extension), RRS (Remote Request Substitution), SRR (Substitute Remote Request), control bit r0, control bit r1, reserved bits res, FDF, XLF, and resXL.

[0052] Example 17 is the method of any of Examples 11 to 16, further comprising displaying the decoded data with search marks to enable the user to identify data from various versions of the serial bus standard.

[0053] Example 18 is the method of any of Examples 11 to 17, wherein the serial bus comprises a USB (Universal Serial Bus).

[0054] Example 19 is the method of example 18, wherein the version of the serial bus standard includes any one of USB1.0, USB1.1, USB2.0, USB3.0, USB3.1, USB3.2Gen1, and USB3.0Gen2.

[0055] Example 20 is the method of example 19, wherein the process of determining the version of the serial bus standard by identifying characteristics of the packet includes a process of identifying a data rate at which the packet was transmitted.

[0056] Although the above-described versions of the presently disclosed subject matter have many advantages that have been described or that will be apparent to those skilled in the art, not all of these advantages or features are required in every version of the disclosed devices, systems, or methods.

[0057] All features disclosed in the specification, claims, abstract and drawings, and all steps in any disclosed method or process, may be combined in any combination, except where at least some of such features or steps are mutually exclusive combinations. Each feature disclosed in the specification, abstract, claims and drawings may be replaced by an alternative feature serving the same, equivalent or similar purpose, unless expressly stated otherwise.

[0058] Additionally, the description in this application refers to specific features. All features disclosed in this specification, including the claims, abstract, and drawings, and all steps in all disclosed methods or processes, may be combined in any combination, unless they are at least partially mutually exclusive. Each feature disclosed in this specification, including the claims, abstract, and drawings, may be replaced with an alternative feature serving the same, equivalent, or similar purpose, unless otherwise specified.

[0059] Furthermore, when this application refers to a method having two or more defined steps or processes, these defined steps or processes may be performed in any order or simultaneously, unless the circumstances do not preclude this possibility.

[0060] Although specific embodiments of the invention have been illustrated and described for purposes of illustration, it will be appreciated that various modifications can be made therein without departing from the spirit and scope of the invention. Accordingly, the invention should not be limited except as by the appended claims. [Explanation of symbols]

[0061] 10 Test and measurement equipment 14 Test Fixture 16 One or more channels 18 User Interface 19 Display section 20 One or more analog-to-digital converters (ADCs) 22 Memory 24 One or more processors 26 DUT (Storage device) 28 DUT (Computing Device)

Claims

1. 1. A test and measurement device comprising: one or more ports for connecting one or more devices under test (DUTs) to one or more channels of the test and measurement instrument via a serial bus; a user interface that allows a user to provide input to the test and measurement instrument, including a specification of a mixed mode of the serial bus; a display that allows a user to view information about the one or more DUTs; one or more processors It has the one or more processors receiving one or more packets from a DUT among the one or more DUTs; determining a version of the serial bus standard to which the one DUT conforms by identifying characteristics of the packet; decoding the packets using the version of the serial bus standard to generate decoded data; analyzing the decoded packets to monitor traffic on the serial bus and determine whether the one DUT of the one or more DUTs is operating properly; a test and measurement instrument configured to execute a program that causes the one or more processors to:

2. 2. The test and measurement instrument of claim 1, wherein the mixed mode includes a mode in which the one or more DUTs operate using a single bus even though each of the one or more DUTs complies with multiple versions of the serial bus standard.

3. 2. The test and measurement instrument of claim 1, wherein the serial bus comprises a CAN bus or a USB.

4. 2. The test and measurement instrument of claim 1, wherein the program that causes the one or more processors to perform a process to determine the version of the serial bus standard by identifying characteristics of the packet includes a process that identifies one or more key bits or a data rate of the packet.

5. 5. The test and measurement instrument of claim 4, wherein the one or more key bits include at least one of RTR, IDE, RRS, SRR, control bit r0, control bit r1, reserved bits res, FDF, XLF, and resXL.

6. 10. The test and measurement instrument of claim 1, wherein the one or more processors are further configured to execute a program that causes the one or more processors to display the decoded data with search marks to enable the user to identify data for various versions of the serial bus standard.

7. receiving input from a user to set the mode of the test and measurement instrument to a mixed mode indicating that packets may be based on one or more versions of the serial bus standard; receiving one or more packets from a DUT among the one or more DUTs; determining a version of the serial bus standard to which the one DUT conforms by identifying characteristics of the packet; decoding the packets using the version of the serial bus standard to generate decoded data; displaying the decoded data on a user interface of the test and measurement instrument; A data analysis method comprising:

8. 8. The data analysis method of claim 7, wherein the mixed mode includes a mode in which the one or more DUTs operate using a single bus even though each of the one or more DUTs complies with multiple versions of the serial bus standard.

9. 8. The data analysis method according to claim 7, wherein the version of the serial bus standard is one of CAN2.0, CAN FD, CAN XL, USB1.0, USB1.1, USB2.0, USB3.0, USB3.1, USB3.2 Gen1, and USB3.0 Gen2.

10. 8. The data analysis method of claim 7, wherein determining the version of the serial bus standard by identifying characteristics of the packet includes identifying one or more key bits or a data rate of the packet.

Images