You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: