Skip to content

BICAS: Use L1/L1R QUALITY_BITMASK for detecting thruster firings #147

Description

@ErikPGJ

Context

BICAS uses knowledge of thruster firings for

  • capping the L2_QUALITY_FLAG
  • indirectly to excluding L2 data being used for L3
  • maybe more...
  • (but not to set a new quality bit, since the L1/L1R QUALITY_BITMASK which is copied to L2 shall contain it)

Due to BICAS lacking a source of information on thruster firings, this information has so far been obtained by manually scanning L2 data (custom plots) and manually adding those to the NSO table (solo_ns_ops.xml) by @ErikPGJ. There is roughly one thruster firing per week so the workload is managable.

According to
https://confluence-lesia.obspm.fr/display/ROC/RPW+Data+Quality+Verification
L1 datasets already contain a quality bit on the presence of thruster firings.

TODO

TODO: Use L1/L1R QUALITY_BITMASK for detecting thruster firings instead of the NSO table.

TODO: Verify that this bit is actually set for old L1R datasets (that old L1R datasets have been reprocessed). Not obvious for how long this has been implemented.

Note: The manual procedure for adding thruster firings to the NSO table has included padding (in time) to the thruster firing, i.e. the time period labelled as a thruster firing (in the NSO table, and in output QUALITY_FLAG) is longer than the actually manually detected thruster firing.

  • 30 s padding before beginning (of manually selected time period).
  • 7 min padding after end (of manually selected time period).
    BICAS may need to add similar padding, depending on when exactly the thruster quality bit is set.

Metadata

Metadata

Assignees

Labels

BICASSolO/RPW BIAS Calibration Software

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions