Scene Capture Boundaries

A scene is a fixed-size receiver capture. This page defines the time terms used by scene composition and the rule for a signal or a propagation echo that reaches the end of that capture.

Terms

  • Sample: one complex in-phase/quadrature (IQ) time value. At a sample rate of 2 MHz, the receiver records two million samples per second.

  • Event: one emitter’s generated transmission, placed at a particular time in a scene. With scene.event_duration.mode: fixed, every event generated for that scene has the configured emitted duration.

  • Scene: the logical result of composing one complete, fixed-length synthetic receiver capture: receiver IQ, scene metadata, and zero, one, or several accepted events. It is not the persisted dataset item. After labels are attached it is one LabeledScene, which a projection stores as exactly one record however many receivers it holds.

For example, a 1 ms scene at 2 MHz contains 2,000 samples. A 0.25 ms event at the same rate contains 500 samples. If it starts at sample 1,200, its emitted extent is samples 1,200 through 1,699:

scene capture:  0 |------------------------------------------------| 1,999
event:                         |--------------|                    500 samples
                               1,200          1,699

The event is the transmission that the emitter generated. The scene is the logical, bounded receiver observation of that transmission and of any channel effects. Records, Receivers, and Assets defines how that result becomes persisted records. The scene-rate meaning of start_sample, emitted duration, and their mapping to per-RX sample indexes is defined by Coordinate Systems. This page defines the additional capture-boundary rule applied to that shared time coordinate.

Fixed capture, fixed emitted duration

rfgen keeps a scene’s capture length fixed. When a fixed scene.event_duration policy is configured, it also keeps the generated duration of every emitter event fixed. Time placement must fit that emitted event entirely within the scene:

0 <= event start <= scene samples - emitted event samples

Thus a 500-sample event in a 2,000-sample scene can start at any integer sample from 0 through 1,500. A placement implementation that returns a start outside that range is invalid and the composer rejects it; rfgen does not silently crop the emitted event to make it fit.

This fit check is deliberately about the emitted waveform before propagation. After TX processing, resampling, and frequency placement, the composer prepares per-emitter or geometry-backed propagation for that waveform. It then draws and validates the event start against the emitted footprint above; an accepted start only controls where the prepared received IQ is mixed into the fixed capture. Statistical propagation configured for scene application remains a post-sum operation. This order does not make channel delay or impulse-response length a hidden placement constraint.

Omitting scene.event_duration retains full-scene event generation: the emitted event duration resolves to scene.duration_s. The same boundary rule then permits only start sample 0 for a full-scene event.

Propagation tails at the receiver boundary

Propagation can produce delayed copies of an emitted waveform: channel models represent multipath with paths/taps that have different delays (for example, 3GPP TR 38.901 V17.1.0 Release 17, §7.5, “Fast fading model”. That physical fact is separate from rfgen’s product policy below. The receiver still has a fixed capture window. If an otherwise valid event ends at the edge of the scene, a channel-induced tail may extend beyond that window and is absent from the stored scene IQ:

scene capture:  |-----------------------------------------------|  fixed window
emitted event:                               |-----------------|  fits in window
propagation tail:                                              |--- outside window
stored scene IQ: |-----------------------------------------------|  tail beyond edge is not recorded

This is receiver-window clipping, not a shorter emitted event. rfgen does not increase the scene length to retain that tail, and it does not reserve a channel-realization-dependent amount of placement room. As a result, scenes remain a uniform fixed shape for storage, batching, and model inputs.

Component metadata, time-frequency boxes, and segmentation describe the emitted event’s planned start and generated duration. They do not redefine the event to include, or to be shortened by, a delayed propagation tail that falls outside the receiver capture. The scene-level IQ is consequently the receiver’s finite observation; the component label remains ground truth for the emitted transmission.

The coordinate conversion from scene/channel-rate start_sample to a receiver-record index is not redefined here; see Coordinate Systems § Component-to-record time mapping.

Why the distinction matters

Treating propagation tails as a reason to grow the scene would make capture length depend on the realized channel. Treating them as a reason to shorten the event would make the declared event duration disagree with its metadata and labels. The fixed-capture policy avoids both problems:

  • Event duration states what the selected emitter generated.

  • Scene duration states how long the receiver recorded.

  • A propagation tail past the capture edge is a real but unobserved receiver effect, not a change to either duration.

For configuration and a runnable generic-RF example, see Generic fixed-duration bursts. This policy is generic RF scene composition; it does not claim to model the packet cadence, hopping, framing, or calibrated captures of Wi-Fi, Bluetooth, drones, or another named protocol.