Is your feature request related to a problem? Please describe.
Open MCT supports buffering on a per-parameter basis. The VIPER telemetry dictionary includes a mix of parameters at different expected data rates. Some parameters (especially ground parameters) can fire updates at 50Hz+, while other parameters may only be 1Hz. Open MCT supports per-parameter buffering, but only a single configurable buffer size right now. This means that to accomodate the highest data rates, a developer must set a buffer size that is far too large for slower parameters.
Describe the solution you'd like
One potential solution to this is to support a configurable default buffer size that can be overridden on a per-parameter basis. Because the expected data rate is not encoded in the dictionary right now, this will probably need to be a separate configuration that is overlaid on the dictionary at start time.
Describe alternatives you've considered
A large single buffer for everything has been considered, which is attractive due to simplicity. However the concern with this approach is that high frequency parameters will drown out lower-frequency parameters.
Is your feature request related to a problem? Please describe.
Open MCT supports buffering on a per-parameter basis. The VIPER telemetry dictionary includes a mix of parameters at different expected data rates. Some parameters (especially ground parameters) can fire updates at 50Hz+, while other parameters may only be 1Hz. Open MCT supports per-parameter buffering, but only a single configurable buffer size right now. This means that to accomodate the highest data rates, a developer must set a buffer size that is far too large for slower parameters.
Describe the solution you'd like
One potential solution to this is to support a configurable default buffer size that can be overridden on a per-parameter basis. Because the expected data rate is not encoded in the dictionary right now, this will probably need to be a separate configuration that is overlaid on the dictionary at start time.
Describe alternatives you've considered
A large single buffer for everything has been considered, which is attractive due to simplicity. However the concern with this approach is that high frequency parameters will drown out lower-frequency parameters.