udpscope/SPECS.md

• Initialize 2 identical large buffer at initialization (default 200MB each, configurable as cli argument) to use as sample buffer for the rest of the application
• Uses deps/plotter for plotting
• Uses deps/udpsclient/udps_client.h to connect to one stream source
• the application should be composed of:
  1. main toolbar that contain:
     • time window selection
     • plot layout selection
     • pause/resume button
     • enable/disable trigger mode
     • show/hide and reset cursors [horizontal and or vertical]
  2. when in trigger mode a collapsable right panel to configure trigger logic:
     • select signal to use as trigger
     • select edge detection type (rising, falling, both)
     • select trigger level
     • select pre trigger window size (in %)
     • select trigger hold off time (default 10ms)
     • select trigger mode [normal], [single]
     • arm/disarm trigger button
  3. a collapsable signal panel:
     • list with all available signals
     • enable/disable signal to acquire
     • calibrate signal: popup to select offset and gain for signal
     • drag and drop signal on plot to start plotting it
     • button to show signal info in a popup (unit, range, rate, type, quantisation etc)
  4. main view with plot:
     • multiples plots depending from selected layout
     • each plot have it x-axis sync
     • each plot can have y-axis with [right click menu]:
       1. auto scale (default)
       2. fixed range (user definable)
     • each plot can show one or more signals
• signal acqusition:
  • the memory buffer should be split in N+1 (where N is the number of enabled signals) and +1 is for the shared time base
  • only if the time window * signal sample rate is greater than size of signal buffer decimate input signal
  • the buffer should be used as circular buffer
  • the time should be computed from the time associated with the signal (not from the client but from the streamed data)
  • in trigger mode data visualisation should not be refreshed till next event, that's why 2 identical buffer, one is the currently viewed event, the other used to acquire live data for next event

Deviations from the spec

The following were built differently from what was asked for, each for a reason README.md states in full:

• The buffer is budgeted in samples per signal, not megabytes (line 1 asked for "default 200MB each, configurable as cli argument"). --buffer-samples N (default 10M, k/M/G suffixes) is the number of samples kept for every acquired signal and for the shared time ring, rounded down to a power of two ("up to"; 10M gives 8 388 608), and a separate application setting, --memory-limit-mb (default 8192, also in Preferences), is the hard ceiling on the ring bytes, halving the sample budget when the rings would not fit. The retained history therefore no longer depends on the channel count or on relative time. There is no --buffer-mb and no compatibility shim; a stored buffer_mb is ignored. The "2 identical buffers" were already a single ring plus latched snapshots (see below).
• todo.md item 2 — relative timing. Implemented as --relative-time. As first built (under the old byte budget; superseded by the item above, where both modes keep the same span and only the memory differs) the retained history in this mode was 41.943 s against the default 83.886 s (measured at 100 kS/s, 4 channels, --buffer-mb 200): exactly half, because a second f64 ring for absolute time raises a tick's cost from 24 to 32 bytes — a third more — and Partition::time_capacity is floored to a power of two, so a third more weight costs a full halving. The design document and the implementation plan both put the cost at ~22%, which is wrong; the per-byte figure of 75% is wrong for the same reason. Absolute stream time is preserved in a separate ring and used for the export's abs_seconds column, exactly as todo.md requires.