BICAS: Use L1/L1R QUALITY_BITMASK for detecting thruster firings

[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.

[ErikPGJ]

This issue can most likely not be fixed until a ROC/L1/L1R QUALITY_BITMASK bug is fixed: https://gitlab.obspm.fr/ROC/RCS/BICAS/-/issues/48

Note that the bug is formally about L1/L1R QUALITY_BITMASK using the wrong fill value (255), but even if the dataset zVariable contained the correct fill value (65535), then the data is still missing.