Incorrect si_mode in certain cases

[taldcroft]

See email thread: subject:"feature" in commanded states data base from:nance

The commanded states processing just looks for commands in backstop
that have cmd type of ACISPKT and TLMSID starting with "WC" or "WT".
Then whatever is after that prefix is used to form the SI mode
according to:

 if tlmsid.startswith('WC'):
     add_trans(si_mode='CC_' + tlmsid[2:7])

 elif tlmsid.startswith('WT'):
     add_trans(si_mode='TE_' + tlmsid[2:7])

So it looks like we need to parse the start science command as well as
maintain a memory of the last CC or TE parameter block.

[taldcroft]

From the original problem report:

While trying to find the correct frametimes for observations, we found a feature or bug in the commmanded states database

I am looking at 2009:297:04:57:49.407.
(OCT1909 load)
We are transitioning from a TE si mode to a CC si mode.
The obsid change is correctly recorded in this case at 2009:297:04:52:26.807 13398881 MP_OBSID 10690

But....

ACIS stores the last SI_MODE used for TE and the last SI_MODE for CC. In this case, obsid 10690 is using SI_MODE CC_000FC. This SI_MODE is used on day 294, so ACIS has this stored EVEN THOUGH WE OBSERVE SEVERAL TE MODES INBETWEEN. This means the offline system does NOT reload the parameter block.

I assume you are getting the SI_MODE from the parameter block loaded. Since this parameter block is loaded in the CC slots on ACIS, the load doesn't load any parameter block for this observation and your cmd_states reports the SI_MODE for the PREVIOUS observation, which is a TE SI_MODE
2009:296:18:20:07.056 2009:297:04:49:26.807 372709273.24 372747032.991 10768 XTZ0000005 TE_00596

2009:297:04:58:58.614 2009:297:21:12:53.407 372747604.798 372806039.591 10690 XCZ0000005 TE_00596

The big clue here was that the command XTZ is a start science for the TE slots and XCZ is a start science for the CC slots.