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.
No Comments