Mpos 7 CMS Scope DQFlag Issue

[LucasMiller]

I want to report an issue with the Galileo EPD data. It appears that an artifact occurs in the TP measurements at the motor 7 position.

This artifact was pointed out in a comment (https://doi.org/10.1029/2020GL091550) on a paper I published last year (https://doi.org/10.1029/2020GL087806). In a reply to the comment we tried to discuss the cause of the artifact (https://doi.org/10.1029/2020GL091550). The artifact seems to be anti-correlated to TH1, more in section 2 of the reply. We also identified the issue in TP1, TP2, TP3, TO1, TO2, TO3, TO4, and TS3 channels, always at the motor 7.

Maybe this is an issue that can be documented on the archive, to make sure other people don't make the same mistake? Perhaps this has already been documented, I'm sending this email just in case.

[LucasMiller]

I need to review the relevant linked papers; but my initial reaction is that we can set the DQ flags for these channels to a custom value (5 perhaps). And then reference the comment and paper in the DQ flag documentation.

[LucasMiller]

Hi Steve,

This is good timing. I have spent some time over the last week restructuring how the data quality flags are being set in the new EPD data product. So, I went ahead and set a flag on the MPOS 7 for the channels in question that will reference the user to the paper comment (https://doi.org/10.1029/2020GL091550).

Here is the revised DQ flag rubric:

PRBEM flux variables (FIDU, FeDU, FepIU, FPDU, FADU, FODU, FOSDU, FFeDU)

• 10: highest quality available data • 4: suspicious data (flux value as set to negative as described in Kollmann 2019) • -1: non-existent data

RawRates: Raw channel rates from the original binary files

• 10: data exists, onboard dqflag was good, no other reasons for flagging it. Considerable care needs to be taken when using this data, however, as many instrument artifacts and other factors need to be reviewed and carefully considered. • 5: data exists, onboard dqflag was good, MPOS = 7, and this is a channel that is potentially affected by the artifact described in comment https://doi.org/10.1029/2020GL087806 • 3: Channel is behind the foreground shield, MPOS = 0 and the channel is from the 0deg end of the scope. • 3: Channel is obscured by the foreground shield and the magnetometer boom, MPOS =4/5/6, channel is from the 180deg end of the scope • -1: data does not exist or the onboard dqflag was bad.

BackgroundRates: RecordMode --> Nearest motor position zero record within 165 second tolerance. This is 5s over the nominal 160 seconds required for 8 full spins of the spacecraft. If the spacecraft is in its nominal stepping pattern this would be enough time to gather a Mpos=0 background record. Note that if the instrument was in "staring" mode, parked at Mpos=4 for instance, then no background records will have been gathered and this variable will be set to fill values. RealTime --> all RealTime records include a foreground and a background rate record. The foreground record is slotted into the RawRates variable and the background record into the BackgroundRates variable.

• 10: data exists, onboard dqflag is good, no other reasons for flagging it, and this channel comes from the 180deg end of the scope (since otherwise it would be behind the foreground shield). • 3: data exists, onboard dqflag is good, no other reasons for flagging it, and the channel is from the 0deg end of the scope (and therefore obscured by the foreground shield). • -1: data does not exist. In the event that MPOS = 0 for the current record this will always be -1 (as there is no background record to a background record).

Please, let me know if you see anything wrong with this rubric or have any constructive additions to make to it.

Best regards, Lucas

[LucasMiller]

Sent an email to Peter Kollmann asking whether the corrected flux values in the APL Pdart 2019 product were adjusted to account for this issue or not. If not then I should flag them as well.

[LucasMiller]

[LucasMiller]

Resolved these issues: Commit 4bd39f49.