Using Streaming Mode for Long-Duration Protocol Monitoring

Some bugs happen once an hour. Others once a day. Traditional logic analyzer captures use a fixed memory buffer — you arm, trigger, and capture a window of data. That approach works perfectly for reproducible problems, but it completely fails when you are hunting an intermittent fault that might take hours or days to appear. Streaming mode solves this by continuously transferring captured data from the instrument to your PC, using disk storage instead of instrument memory.

When Streaming Mode Is Essential

Intermittent bus errors: An I2C sensor that NACKs once every few hours, an SPI peripheral that occasionally returns corrupted data, or a UART link that drops characters under specific thermal conditions. These problems cannot be caught with a single-shot capture because you would need to know exactly when to trigger.

Long-term reliability testing: Validating that a system operates correctly over extended periods is a requirement for automotive, medical, and industrial applications. Streaming mode lets you record protocol activity for the entire duration of a reliability test and analyze it afterward.

Compliance logging: Some standards require continuous logging of bus activity during certification testing. Streaming mode provides an unbroken record of every transaction.

Rare event correlation: When a system failure occurs infrequently and involves multiple buses, you can stream multiple protocol channels simultaneously and correlate events across buses after the failure occurs.

Setting Up Streaming Capture

Hardware Requirements

Streaming mode transfers data over the USB connection between the instrument and PC in real time. The sustained data rate depends on bus activity:

• TravelLogic: Streams via USB 2.0. Suitable for lower-bandwidth protocols (I2C, UART, SPI at moderate clock rates). The practical sustained streaming rate supports continuous capture at sample rates up to roughly 50 MS/s across active channels.
• LA4000: Streams via USB 3.0. Handles higher-bandwidth captures and more channels simultaneously. USB 3.0’s 5 Gbps bandwidth allows sustained streaming at significantly higher sample rates.

On the PC side, ensure you have sufficient disk space and that you are writing to a drive with adequate sustained write speed. An SSD is strongly recommended. A spinning hard drive may not keep up with high-activity captures and can cause data loss.

Storage Requirements

A rough estimate for storage consumption:

For a 24-hour I2C monitoring session with typical sensor polling, plan for roughly 2-5 GB of storage. For higher-activity captures, scale accordingly. The software displays an estimated storage requirement based on your configuration before you start the capture.

Configuration Steps

1. Select streaming mode in the capture settings. This switches from the default buffer mode to continuous streaming.
2. Set sample rate based on the fastest protocol you need to decode. For I2C at 400 kHz, a sample rate of 2 MS/s is sufficient. For SPI at 10 MHz, you need at least 40 MS/s.
3. Choose active channels to minimize data throughput. Only enable the channels connected to signals you need. Every additional channel increases the data rate proportionally.
4. Configure the storage path to point to an SSD with adequate free space. The software writes captured data in segmented files to prevent any single file from growing unwieldy.
5. Set a capture duration or leave it to run indefinitely until you manually stop. For unattended captures, setting a maximum duration prevents filling the disk completely.

Trigger-While-Streaming

The most powerful aspect of streaming mode on Acute instruments is the ability to set protocol-level triggers that fire during streaming without stopping the capture. When a trigger condition is met, the software marks that point in the stream with a timestamp and optional annotation.

This means you can configure a trigger for an I2C NACK condition and let the system stream for 24 hours. At the end, instead of scrolling through millions of normal transactions, you jump directly to each NACK event using the trigger markers.

To set this up:

1. Enable streaming mode as described above.
2. Configure your protocol trigger normally (for example, I2C NACK on any address).
3. In the trigger action settings, select “Mark and Continue” instead of “Stop.” This flags the event without halting capture.
4. Optionally configure a pre/post-trigger snapshot that saves a high-resolution window of data around each trigger event, even if the streaming sample rate is lower for storage efficiency.

Analyzing Large Captures

A 24-hour streaming capture can contain millions of protocol transactions. The analysis software provides several tools to make this manageable:

Protocol-level filtering: Display only specific transaction types. For I2C, filter by address, read/write direction, or NACK status. For UART, filter by specific byte patterns. For SPI, filter by command bytes.

Trigger marker navigation: Jump between marked events using keyboard shortcuts or the event list panel. Each marker includes a timestamp and the decoded transaction that triggered it.

Statistical summary: The software generates statistics across the entire capture: transaction counts by type, error rates, timing distributions, and throughput over time. A graph of I2C NACK frequency over 24 hours can reveal time-of-day patterns that point to thermal or load-dependent issues.

Export and scripting: Export decoded transactions to CSV or binary formats for processing with external tools. If you need custom analysis beyond what the built-in tools provide, the exported data includes timestamps and all decoded fields.

Practical Scenario: Catching Rare I2C NACKs

Consider a temperature sensor on an I2C bus that occasionally NACKs its address, causing a system log error. The failure happens roughly once every 4-6 hours and has resisted all attempts at reproduction.

Setup: Connect the TravelLogic to the I2C SDA and SCL lines. Select streaming mode with a 4 MS/s sample rate. Configure an I2C trigger for NACK on the sensor’s address (for example, 0x48) with “Mark and Continue” action. Start the capture and leave it running overnight.

Analysis the next morning: The capture ran for 14 hours. The trigger marker list shows three NACK events at 02:17, 06:43, and 11:02. Jumping to the first event, you examine the transactions immediately before the NACK. You notice that each NACK was preceded by a burst of rapid-fire reads from a different device on the same bus, suggesting a bus contention or clock stretching issue. The timestamps also correlate with a periodic background task in the system firmware.

Without streaming mode, catching all three events in a single session would have been impossible with fixed-buffer capture. The protocol-level trigger markers turned a 14-hour capture into three specific points to investigate, and the surrounding context in the stream provided the clues needed to identify the root cause.

Best Practices

• Always verify your setup with a short test capture before starting a long-duration stream. Confirm that the protocol decoder is correctly parsing transactions.
• Monitor the streaming status indicator during the first few minutes to ensure no data overflow warnings appear. If the data rate exceeds the USB or disk throughput, reduce the sample rate or disable unused channels.
• For unattended captures, enable the software’s disk space watchdog, which automatically stops capture when remaining disk space drops below a configurable threshold.