We see a very strong line at the left end of spectrum, stronger than all other lines.
When we shift the target TE3UF_H from -35mm to -37mm it gete weaker, but -37mm is the end of drive.
In the other direction it becomes worse. At -25mm completely new peaks.
Also scan in Y direction TE3UF_V +25mm and +40mm give other fragments even very intense, while the old lines vanish.
So production happens in target frame. 
Use -37mm, +37mm as best target position.

We run with TCap only for some time hoping there is somewhere a peak of 70Se
running from about 9:15 to about 22:00
We set scrapers in the previous optimum position

still in the search of 70-Se

This some preliminary analysis results by using  NTCAP data.   The IQ rate of NTCAP is 20 MSamples/seconds. I analyzed data files recorded from May 7 
17:39 to May 8 2:20.  The frequency of 72Ge is bended by 4kHz at the beginning of some injections.  In order to check whether this frequency bending is 
due to isomer or unstable magnetic field. I compare the 72Ge with other isotopes. The similar bending was observed for other isotope in each 
corresponding injections. It seems that bend is due to unstable magnetic field.  

18:45  changed SIS, ESR setting for 70Se without predrilling blind change.
E-SIS =  446.55 MeV/u, is centerd as before on TE3UF target grid.
set beamline after taret as 78Kr 36+ E = 337.375 MeV/u
set ESR to A = 70, Z=34 at isochronous E/m + 0.8 MeV/u = 369.2 MeV/u
kicker delay unchanged

4 quadrupoles failed during the change, skip cycle and reset, they work again, (GE01QS0D, GE01QS1F, GE01QS2F, GE01QS4F)

Now many lines in Schottky.

also 2 corrector coils were off, on again, now good resolution.

last recorded filename:

E143-245MHz-2021.05.09.17.38.44.410.tiq

410 was not recording data in this period.

Following Xiangcheng Chen's analysis, I analysed 11 ms time slices separated by 25 ms to see the evolution of the potential isomer across the injection.

Attachment 1: Data from May 7th 19h-20h. -t 11ms progression from -s=5 to -s=5.175
Attachment 2: Data from May 8th 21h-22h. -t 11ms progression from -s=5 to -s=5.175

The extra resolution gained on the 8th (and potentially other settings too) make the isomer visible where it wasn't present on the 7th.

first filename in this recording:

E143-245MHz-2021.05.09.15.16.49.816.tiq

We accept larger m/q values than we like to. m/q(low) cut ~ 2.08. Decrease ESR energy from 369.2 -> 368.4 MeV/u
frequencies shifted by -37.5 kHz (at 60 MHz)

After looking at the spectrum it was concluded that the same isotopes, and no more, could be identified. 
Now we change the energy back to 441.7 MeV/u and will open the scrappers to see if Mn comes in. 

The picture shows the effect of going back to the previous energy and then the effect of opening the scrappers

Beam energy to be increase to move Mn into the ring. 
First step we set the energy to 445 MeV. 
The effect of the change can be seen on the plot: Right is how it was before and left after the change. 

For the whole morning shift there were no significant changes in the spectra.

Some of the obtained histograms are attached below. 
The python code was used and the histogram was plotted in ROOT with log y scale. 
The time, the used code options and the data type are marked in the filenames or in the description below. 

Attachment 1-4: 245MHz, options used " -s 5.1 -t 0.5 ", time marked in the filename (time as in the title of the files on the server (-1h of the real time)).

Attachment 5: 410MHz, with the same options for the python code, real time names. It is different from 245MHz histogram.
Attachment 6: Comparison between 245MHz histogram and 410MHz histogram for real time 10:00 - 11:00.
Note: This difference is observed in the histograms from the early morning hours too (checked up to 4 o'clock).

Attachment 7: 245MHz data, with options "-s 5.0 (Red) / -s 5.05 (Green) / -5.1 (Blue) -t 0.5" (real time 08:00 - 09:00)
Attachment 8: 245MHz data, with options "-s 5.0 (Red) / -s 5.05 (Green) / -5.1 (Blue) -t 0.1" (real time 08:00 - 09:00)
Attachment 9: 410MHz data, with options "-s 5.0 (Red) / -s 5.05 (Green) / -5.1 (Blue) -t 0.5" (real time 08:00 - 09:00)

So far, we keep the setting as it is and wait for experts to come in. 
Few spills are missing from time to time. One of the peaks stays usually in the spectrum when this happens. 
Analysis of the last hours is being performed by the remote shift, in case it is useful. Some plots in telegram. 

Summed up runs on the 245 MHz detector between 3-4am (computer time).
-s 0.1 -t 8.0

The tune last night was unfortunately not to 52Mn. The two "isomers" that were identified are instead 45Sc and 75Br. But separation looks okay. ESR morning shift should try to tune to 52Mn to identify the 21-min isomer at 378 keV.

Uploaded some pictures to prove that we were not asleep :-) but they are of limited use...at least my analyzer script and wget works now !! 

Summed up runs on the 245 MHz detector between 2-3am (computer time).
One has -s 0.1 -t 8.0
the other -s 5.1 -t 0.5

Not sure if it is useful but here it is :-)

Zoom into the triplet: the satellite peaks on the right are clearly visible.
This is just one file but one *might* see some substructure. Yuri mentioned a 318 ms isomer in 45Sc at 12 keV but that cannot be resolved.

Maybe someone can look at the added-up ROOT files if that looks better or is just statistics?

> Short update from Yuri: these are not our isomers. These are 45Sc (left, 12 keV isomer not resolvable) and 75Br (center), and the right-most peak of the triplet is a satellite (has a different line shape, much narrower).
> 

Attached is a summed spectra of all files taken between 1:17am and 1:59am (on the 245 MHz detector).

python3 e143_analyzer.py -s 5.1 -t 0.5 /home/dillmann/E143/e143-scripts/sparc-daq-02.gsi.de/E143-245MHz/E143-245MHz-2021.05.09.01.* -o Not_52Mn_245MHz_May09_1-2am
(Might need to adapt the skip time and read-in time, thou... used the same as for the 72Ge runs...)

This is due to the 50% trigger setting in the spectrum analyzers ))

This might have been answered before but I looked at one png file and one tiq file from the same run that was stored on the server. There seems to be an offset of 2.2 s. The png file from the server (right) shows the injection at ~5s, whereas when I look at the tiq file in the GUI (left), the injection is at ~2.8 s???? Is the looper introducing this offset?