// application note

AN0013 Replaying a captured I2C bus onto real hardware with the Binho Pulsar

A logic analyzer records what a controller did to a target that was present and answering. This application note takes such a recording and puts it back on a live bus from a Binho Pulsar, so an exchange observed once can be issued again on demand: to reproduce a fault, to drive a peripheral whose initialization sequence is known only from observation, or to exercise a target without its original host. It supplies the utility that does it twice over, once in Python on pyCosmicSDK and once in C++ on CosmicSDK, reading a Saleae I2C analyzer export, recovering the transactions from it and replaying them. The two are held to the same output: on the capture supplied with this document they print the same 155 lines. Every result is measured with the analyzer watching both the original and the replay, so the comparison is between two measurements rather than between a measurement and an intention. It is equally about what a replay cannot carry: a read is a fresh question to the current target, a refusal ends its own transaction, a repeated START survives on the wire but not in the timing, and a target that silently discards a write is indistinguishable from one that stored it.

Products: Binho Pulsar
Protocols: I2C
Topics: Bus Replay
Revision: Rev 1.0 · November 6, 2026

// outcomes

What you'll walk away with

This document covers:

reading a Saleae I2C analyzer CSV export and recovering transactions from it
replaying those transactions from a Pulsar, in Python or in C++
what the adapter reports when a target refuses, and what it does not report
establishing on the wire, with the analyzer watching both runs, that the replay matches
provoking a refusal deliberately, using a second adapter as an emulated target
the limits: reads, transaction framing, timing, silent refusals and ten-bit addressing

It does not cover replaying SPI, I3C or UART captures, driving a replay from Mission Control 3, or reconstructing a capture from an analyzer session file. The utility reads the analyzer's CSV export, not its native session.

// background

Background

An engineer with a working system and a logic analyzer has, in the capture file, an exact record of a bus exchange that worked. The natural next question is whether that record can be replayed.

This document answers it for I2C with a Binho Pulsar. It supplies the utility that does the replay, the procedure that produced every number below, and an account of the ways a replay legitimately diverges from its capture. The divergences are the substance: re-sending the bytes is only the first half of the problem.

// applicable devices

Applicable devices

Role	Part	Identifier	Basis
Replay controller	Binho Pulsar	hardware revision C, firmware 4.4.0	measured, this document
Replay controller	Binho Supernova	hardware revision C, firmware 4.5.0	the code path is shared with the Pulsar; not separately measured as the controller
Emulated target	Binho Supernova as an I2C target	hardware revision C, firmware 4.5.0	measured, this document
Capture instrument	Saleae Logic Pro 8	Logic 2 v2.4.46, I2C analyzer	measured, this document
Capture instrument	Acute TravelBus	8 channels	decodes the same bus; its export is not read by the utility