Trigger data for spectrogram expected to be scaled appears to be compressed

[grazwegian]

The spectrogram data requests that were made during the Feb 2024 fight software update to test the new trigger scaling seems to show some odd results. These correspond to UIDs 2402021788 , 2402025308, 2402076469, 2402075738. The step size between trigger values seems to be higher when the total rate is higher as was usual for the previous compression scheme rather than constant as expected for the new scaling scheme. UID 2402021788 was requested with a scale factor of 15 while the others were requested with the standard value of 30. I understand that the files would all have been pressed assuming f=30 but I would expect this should only cause a discrepancy of a constant factor.

For 3 out of the 4 (the ones corresponding to f = 30) the trigger compression scheme in the control structure of the FITS file (and in the packets on the platform) shows the previous standard 053 rather than the scaled value of 007.

However the even the one which does show that the triggers should be scaled 2402021788 shows the same issue with the step size at high rate being much larger than for low rates although for the scaled data it should be constant. The time bin size is at the maximum 0.5 second value for this so it is unrelated to that.

The data for the request seems to suggest that the data should have been scaled with the appropriate factors. Operation request #1284 - PDOR_SSTX_S296_ASW186ConfigAndTest_00003.SOL https://datacenter.stix.i4ds.net/view/ior/overview/1284

2402021788_trigger_difference.pdf

[samaloney]

So far for UIDs 2402025308, 2402076469, 2402075738 these request seem to show the compression scheme as 053 in the raw packet data.

For UID 2402021788 the raw packet data contains a mix of 007 and 053 as the compression scheme. With the update code this is reflected in the fits file but is not handled correctly as don't expect the compression scheme to change in a single request.

I think this is the same issue we had with the pixel masks before highlighting the danger of this approach of changing parameter and waiting the "right amount" of time for stix to process the data before changing the parameter again.

You can see this in the packet data here for UID 2402021788 https://datacenter.stix.i4ds.net/view/packet/bsd/32287 look at the first and 15th packets for example and the NIXD010-NIXDO12 params. Similarly for 2402025308 https://datacenter.stix.i4ds.net/view/packet/bsd/32290 I don't see any 007 packets.

From the raw packet extracted in python for 2402021788

trig_skm
array([[0, 0, 7],
       [0, 0, 7],
       [0, 0, 7],
       [0, 0, 7],
       [0, 0, 7],
       [0, 0, 7],
       [0, 0, 7],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3],
       [0, 5, 3]], dtype=uint8)