# MAVEN NGIMS PEF Review

## Uplink Bundle Review 

### First Steps 

Determine valid orbit range in Science Week announcement

Download and uncompress the attached wk###.tar.gz

Change directory to sci_wk###

`update_orb.py`

`procpef.py > pef.txt`

Open pef.txt in text editor

Skip down to one before first valid orbit

### Standard Science Runs 

Look for the following after orbit segment IB_SIDE

    NGM_LOAD_TBL "d:/ngm/sciperi_1884.bas" 201 "sciperi_1884.bas
    NGM_LOAD_SCRIPT "d:/ngm/sci_peri_osion_1886.cfg" UPLOAD_APPE

followed by NGM_SCRIPT commands: run, set_peri_time ######, go

Most activites are started in the IB_SIDE segment

Just skim and look for anything off. This is the bulk of what should be
in the pef

Under \"wizard\" commanding, there are now \"COMM\" and \"RELAY\"
segments that can cause the usual IB_SIDE, PERIAPSE, OB_SIDE and APO
segments to be replaced. In these cases, you must verify the timing with
the second column of the PEF (aka offset from altitude minimum):

-   Verify that script is kicked off around -4350 sec. Relays can delay
    this time. A standard science script should not be started within 10
    minutes of the OB_SIDE, corresponding to a value greater than 556s
    in the second column

### Special Activities 

Verify all special activities in the Science Week announcement have been
implemented

#### Wind Scans 

For neutral wind scans

    NGM_LOAD_TBL "d:/ngm/sciwind_1907.bas" 201 "sciwind_1907.bas

followed by NGM_SCRIPT command: run

and then a SPECIAL segment with a VM_SPAWN_TAG that refers to a file
starting \'ngm_wind_scans_neu\'

For ion wind scans

    NGM_LOAD_TBL "d:/ngm/windion_xxxx.bas" 201 "windion_xxxx.bas

followed by NGM_SCRIPT command: run

and then a SPECIAL segment with a VM_SPAWN_TAG that refers to a file
starting \'ngm_wind_scans_ion\'

#### High-Speed Argon Scans 

This activity bookends the usual science scans with scans focusing
exclusively on m/z 40, also extending the range of continuous scanning
to an earlier point in the orbit. Although there is no difference
between them in the pef commanding, there is a high-altitude version
where the spacecraft begins ram pointing earlier in the orbit. For all
argon scans, look for this script commanding:

    NGM_LOAD_TBL "d:/ngm/science_1373.bas" 201 "science_1373.bas
    NGM_LOAD_SCRIPT "d:/ngm/sci_arhigh_osion_1905.cfg" UPLOAD_AP

followed by NGM_SCRIPT command: run

**Note:** don\'t plan two sets of like Argon scans (e.g. two 500km runs)
closer to each other than a week (i.e. last orbit of one set occurs \< 7
days before first orbit of like set). From a science perspective, it\'s
basically same observation and standard science loses out to a redundant
special observation.

#### OSNB Background 

For bi-weekly OSNB backgrounds:

    NGM_LOAD_TBL "d:/ngm/science_1373.bas" 201 "science_1373.bas
    NGM_LOAD_SCRIPT "d:/ngm/sci_loemis_osnb_1538.cfg" UPLOAD_APP

followed by NGM_SCRIPT command: run

Note: Unlike most activities, OSNB backgrounds start in the OB_SIDE
segment. This activity runs 1h40m.

### CPT

For bi-weekly CPT:

    NGM_LOAD_TBL "d:/ngm/funct_650.bas" 201 "funct_650.bas" 1664
    NGM_LOAD_SCRIPT "d:/ngm/functional_cpt_em2_829.cfg" UPLOAD_A

followed by NGM_SCRIPT command: run

Note: Unlike most activities, CPTs (aka functionals) start in the
APOAPSE segment. This activity runs 1h12m. 

Be on the look out for a DTCI toggle in the middle of the CPT: 

    VM_GV_SET_INT GV_NGM_DTCI_CFG 1
    VM_GV_SET_INT GV_NGM_DTCI_CFG 0

When GV_NGM_DTCI_CFG is set to 1, the interface between the instrument and the spacecraft is suspended. No data that the instrument sends will be recorded. In orbit 21061 and 21149, this happened during a Mass Memory scrub operation on the spacecraft resulting in lost CPT data.

### Complications

#### Relay

Relays will cause NGM_STOP followed by a log of commands including
\"NGM_MAIN_PWR OFF\"

When if comes back, there should be \"NGM_MAIN_PWR ON\" with several
other commands then NGM_GO

At that point, if the orbit is between IB_SIDE and ten minutes prior to
OB_SIDE, the normal sciperi script should start, and internally it will
resume in the middle to reclaim a portion of the orbit for scanning
science data

If the instrument power down occurs soon after a script begins, the
sudden on and off of the filament can cause undesirable wear and tear.
Please ask for an empty sequence to prevent NGIMS commanding if the
delay between script start (EXEC_IMMED 0x676f0000 aka 'go') and NGM_STOP
is less than 210 seconds.

#### DTCI Disable 

For some spacecraft activities (e.g. memory scrub), the interface (DTCI)
between the spacecraft and NGIMS will be turned off. The NGIMS
instrument can continue running during this period where the DTCI is
disabled, but no telemetry from the instrument will be recorded. In some
cases, commanding may include a DTCI disable in the middle of a script.
Be on the lookout for such commanding errors during the bundle review,
especially during the OSNB background and CPT scripts.

In the pef, DTCI disable commanding looks like this:

    NGM_SCRIPT 244 0x21200000 232 EXEC_IMMED 0x7379732e 0x7a6f6e65 0x5f616c65 0x727
    b'sys.zone_alert_action=-1'
    VM_GV_SET_INT GV_NGM_DTCI_CFG 1

In the pef, DTCI enable commanding looks like this:

    VM_GV_SET_INT GV_NGM_DTCI_CFG 0
    NGM_SCRIPT 244 0x21200000 232 EXEC_IMMED 0x7379732e 0x7a6f6e65 0x5f616c65 0x727
    b'sys.zone_alert_action=4\x00'

Note: the NGM_SCRIPT script line is truncated by procpef.py, so they
appear identical. The translation of the hex to ascii that appears below
it will include the entire command. From the NGIMS FSW reference:
sys.zone_alert_action=-1 ignores zone alerts, while a value of 4 is the
default. That is, the instrument will assume it is in a high density
zone and go safe upon missing 4 zone alert pings.