Anomalous FEM levels for Ant8

[sageyu123]

We have identified consistent quality discrepancies in the EOVSA synoptic images across multiple dates, including but not limited to October 12 and 13, 2024. This issue was initially observed in the comparison of images from these two specific dates:

EOVSA fdimg for 10/12 and 10/13

The image from 10/12 shows significant quality issues compared to the clear image from 10/13. To diagnose the problem, I compared the MS data for both days, using the 10/13 data as a reference due to its good quality.

The two figures above illustrate the amp vs time for MS data from 10/12 and 10/13, respectively. The five panels in each figure display the cross-power amp for antennas eo01, eo06, eo08, eo09, and eo10, respectively. This issue seems to originate from unusually high amplitudes at the start of the day, introduced during the importeovsa stage. The importeovsa task, which corrects the FEM level of EOVSA IDB and UDB data, involves the udb_corr function that calls apply_fem_level function. This adjusts the antenna gain levels as a function of time and frequency.

Below are the antenna gain plots for antennas 1-15 at various frequencies on both Oct 12 and 13:

Antenna Gain Plots:

• 
• 

Noticeably, the gain of antenna eo08 (Ant8) at the start of 10/12 is over 1e6, in stark contrast to the normal levels around 1 seen in other antennas. This anomaly is directly reflected in the MS data file by large amplitudes.

• Additional dates showing similar issues with antenna eo08 (Ant8):
  • 
  • 

I could't find any reports regarding FEM glitch for eo08 (Ant8) on these days in the slack channels. The antenna tracking positions didn't show anormoly either.

Antenna Tracking Data:

• 
• 

The cause of the high gain values remain unclear. I will let @dgary50 @oweng1 and @clselhorst chime in.

To mitigate this issue, a easy way is to implement a data flag for the IDB/UDB files in the udb_corr for times and frequencies when antenna gain values exceed a certain threshold, e.g., 100. This flag would propagate to the MS files when importeovsa is run, ensuring that data is not compromised by these anomalies. Thoughts?

[binchensun]

I think it is reasonable to set a threshold to check whether the FEM gain is in a reasonable range, although I do not know what exactly that should be.

[oweng1]

We will want to be careful about what range to use. The FEM attenuations can get quite high during a large flare. Normally if there is a problem with the FEM, the attenuation and dBm will be either Nan or zeros.

[sageyu123]

We will want to be careful about what range to use. The FEM attenuations can get quite high during a large flare. Normally if there is a problem with the FEM, the attenuation and dBm will be either Nan or zeros.

You're absolutely right about the need for caution with the threshold. In this instance, the total added Attn was 62 dB (31+31 for the 1st and 2nd Attn), which remained flat for over 3 hrs. This converts to a decimal value for antenna gain of 1,584,893.1924611141 when applying the formula 10^(Attn / 10). Given that the FEM uses an 8-bit index, it was effectively saturated over this extended period. Perhaps a conservative approach would be to flag the gain only if it remains saturated for an extended duration. Thoughts? @oweng1 @binchensun @dgary50

[oweng1]

Dale will have a better idea than me, but the only time I have seen attenuators saturate like that is during calibrations when we deliberately put in maximum attenuation, for example during the gaincal and when we do other specific tests. 31 dB is the maximum attenuation that we can put in for each attenuator.

[dgary50]

Probably a calibration set the attenuation to maximum and then the system somehow missed the command to return it to its nominal value. In that case, any residual receiver noise would get multiplied by the very high correction value. A flare will never need such high attenuation, so I can easily flag for that case.  Sent from my iPhone

On Oct 24, 2024, at 11:13 AM, oweng1 @.***> wrote: Dale will have a better idea than me, but the only time I have seen attenuators saturate like that is during calibrations when we deliberately put in maximum attenuation, for example during the gaincal and when we do other specific tests. 31 dB is the maximum attenuation that we can put in for each attenuator.

[sageyu123]

Probably a calibration set the attenuation to maximum and then the system somehow missed the command to return it to its nominal value. In that case, any residual receiver noise would get multiplied by the very high correction value. A flare will never need such high attenuation, so I can easily flag for that case.  Sent from my iPhone … On Oct 24, 2024, at 11:13 AM, oweng1 @.***> wrote: Dale will have a better idea than me, but the only time I have seen attenuators saturate like that is during calibrations when we deliberately put in maximum attenuation, for example during the gaincal and when we do other specific tests. 31 dB is the maximum attenuation that we can put in for each attenuator.

Good to know!