Martino FerrariandClaude Sonnet 4.6
eacb3f5efc
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
- 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 the spec states, for documented reasons in `README.md`:
|
|
|
|
- **`todo.md` item 2 — relative timing.** Implemented as `--relative-time`. The retained history
|
|
in this mode is **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 spec and the original plan both quoted
|
|
~22%, which is wrong; the per-byte figure of 75% is also 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.
|