With a Beagle USB Protocol Analyzer or a Beagle I2C/SPI Protocol Analyzer and Data Center Software, users can capture and analyze USB, I2C, or SPI traffic in real time. The GUI stores captured data in computer RAM, with a configurable capture limit set up to 80% of available memory. Once this limit is reached, the capture will automatically stop or begin overwriting old records, depending on the circular buffer setting. 

For longer sessions or larger data sets, APIs or Telnet terminal allow for continuous data collection without memory constraints. These methods allow traffic to be streamed directly to disk (like an SSD or external drive) for logging large amounts of data over multiple hours or even days. This process can also be automated, enabling remote, long-term streaming and monitoring.

Examples of Long-Term USB, I2C, and SPI Protocol Debugging

There are many scenarios where streaming protocol traffic directly to a disk for long-term capture and analysis is necessary. Some examples of this include:

• Debugging over Extended Test Cycles: During reliability, firmware, or stress testing, devices may operate continuously for 12–48 hours or more. Capturing protocol traffic throughout these long cycles helps identify intermittent issues like dropped packets or disconnections that shorter captures might miss. Continuous logging ensures complete visibility without gaps caused by RAM limits.
• Debugging Video Devices: Capturing raw USB traffic over several hours is necessary to analyze frame drops, resolution switching, or timestamp issues. Analyzing packet timing and data continuity reveals gaps or irregularities in the video stream that may not appear during shorter captures.
• Testing USB Microphones/Audio Interfaces: Multiple sample rates and buffer sizes will need to be tested to reliably diagnose audio glitches, latency spikes, or protocol errors over long recording sessions.
• Capturing large amounts of sensor data for Artificial Intelligence (AI) training: Uninterrupted I2C or SPI data streams over long periods of time is needed for machine learning (ML) and anomaly detection training. Streaming this data directly to disk ensures no data loss or bottlenecks in post-capture analysis.
• Reproducing USB Performance Issues for Analysis: Intermittent performance issues may only occur after hours of use. For example, external drives may experience slower performance due to thermal throttling, firmware leveling, or internal flash management complications; which all tend to occur after prolonged use. Streaming USB traffic to disk will provide a full trace for post-event inspection.
• Compliance Testing and Validation: Certain compliance regulations may require complete protocol logs. For devices that are designed to function for multiple hours or days continuously, streaming the protocol data to a disk enables users to acquire full traces of the device in its intended use.
• Manufacturing Line Diagnostics: If devices on an assembly line are periodically failing functional tests, users may need to capture protocol data over hundreds or thousands of cycles. Disk-based logs can be timestamped and analyzed after long captures, helping to identify the bottlenecks in production.
• Analyzing Idle Behavior in USB Devices: Idle periods can reveal critical information about a USB device, including background communication, power management, and firmware activity. Long-term capture is required for non-stop, passive monitoring of the USB bus, including idle activity.

Streaming Data Capture to Disk

There are two solutions available for streaming long durations of protocol traffic to disk: Using APIs or using a Telnet terminal.

1. Using the Beagle Software API to Stream USB, I2C, or SPI Traffic to Disk

Anything that can be done in the Data Center Software is fundamentally possible with the Beagle Software API. Users can write their own application using the API to capture long durations of protocol logs from a Beagle USB Protocol Analyzer or the Beagle I2C/SPI Protocol Analyzer. The API supports macOS, Windows, and Linux operating systems, multiple languages (C, Python, Visual Basic, and C#), and includes examples. Below is a C example we created for the Beagle USB 480 Protocol Analyzer that saves the logs on a text file to a local disk on a Windows machine. Please note that while this has been implemented for the Beagle USB 480 Protocol Analyzer and a Windows machine, it can be emulated to suit your requirements and setup.

Beagle USB 480 Protocol Analyzer – Windows – example C code

2. Controlling Data Center Software with a Remote Telnet Terminal

Users can also use a Telnet terminal to connect to and control Data Center Software, enabling protocol captures over long durations. The remote terminal takes the same commands as the internal Command Line interface. For more information, see section 5.1.5 of the Data Center Software User Manual. Additionally, this blog explains how to automate certain tasks with an example Python script that uses the Telnet module to connect to the Data Center Software running on the same machine. It sends the command to start the capture, waits for 3 seconds, then sends commands to stop, save, and clear. Here are the steps to use a Telnet port to control Data Center Software from a remote PC.

1. Connect the Beagle Protocol Analyzer to the host PC (PC-1), and configure it with Telnet.
2. Configure a remote analysis PC (PC-2) with Telnet, and open Telnet terminal access to PC-1.
3. In PC-2, navigate to the bin folder from the Data Center Software download package.
4. In PC-1, run the datacenter.cmd as follows in the command line:
   • > datacenter.cmd -r 6000
5. In PC-2, run this python script with these changes:
   • Replace ‘localhost’ with PC-1’s IP address in:
     tn = telnet.lib.Telnet(‘localhost’, 6000)
   • Replace save path to a desired path in PC-1 in:
     SAVE = "save(u'/tmp/foo_%s.tdc', {'no_timing': False, 'filtered_only': False}, True)"

Note that the above script is programmed to start a capture at 8:00am and stop the capture at 5:00pm. This can be altered. For an infinite capture, we suggest creating the following algorithm: 

1. Start Capture
2. Run Capture for a certain amount of time (A)
3. Stop Capture
4. Save into a disk file
5. Loop back to Step 1.

One limitation of this procedure is that Step 4 takes time to process, which can lead to data loss during that interval. The longer the capture duration (A), the longer it takes to save the file, therefore increasing the risk of dropped data.

More detailed directions for this process can be found in this support blog.