We started moving the pleiades detectors at 16:13 04-04-2025.

We have the inside pocket (GE01DD2IG) at 2mm. 
The outside pocket (GE01DD2AG) cannot be moved by the Device Control program, some problem with the tolerance (error message: outside of tolerance). Need to go in in a short break and check what is wrong.

We will partly scrape the beam.

last file with old setting:

RSA01-2025.04.08.21.55.22.661.tiq

new plunger position 410: 13mm
new plunger position 245: 390mm

new frequency 410: 413555918
new frequency 245: 243.497403


first good file in this setting:

RSA02-2025.04.08.22.09.53.178.tiq

new settings:
1.8 seconds recording on 245 MHz on RSA02

starting from file name:

2025.04.04.18.36.32.895


settings are in the attachment

anything from RSA01-2025.04.01.02.54.25.976.tiq onwards is good data

recording parameters:

5 MHz with 6.25 MSPS, 2.5 seconds, analyzer span 100 khz, trigger at 5%

All analyzer times are now set to summer time
file time stamps are correct

settings are in the attached pictures.

NTCAP Started

RSAs started:

New plunger settings for 410 --> 20mm
frequencies: 410 -->
245 -->

recording time: 1.7s
ACQ BW--> 5 MHz
fs --> 6.25 MSPS
trigger --> 8%

lframes = 65536
nframes = 160

first good file in this setting is: 20:34 onwards

mesycontrol process starts but shows no GUI at all.

Around 02:51 we wanted to record leakage currents for PLEIADES. 
The windows of the mesycontrol were not present on the screens. 

We followed the instructions for restart:
-ssh -X into x86l-128 (-X is important, otherwise qt will not be initialized)
-mesycontrol

as a result we see nothing but the terminal is busy, and the process exists. 
We noticed that ssh connection establishes very slow, the terminal after the connection responds to typing with a delay of several seconds(one press 'm', after 1-2 sec that letter appears on 
the screen).
 
htop hanged the terminal entirely without showing a thing. Several minutes before we started htop and 12th thread(processor?) has been fully busy, 100%.

our assumption is that GUI has been closed because computer had not enough resources for sustaining it. We would not expect such a slow response even in terminal. 
Could anybody have a look on x86l-128 and figure out why is it so slow? 

UPD: started mesycontrol around 03:40, until 04:02 nothing happened except first two commands. 
Tried to start it from x86l-124 and everything works fine except that the connection to /dev/tty/USB0 can't be established (because it is occupied by x86l-128?)
So we are not able to read leakage currents. 

 

datafile = "/data.local/G22-00018_00203/results/analyzers/RSA01/RSA01-2025.03.31.22.18.16.965.tiq_spectrum.npz"
filep = "/data.local/G22-00018_00203/scripts/OnlineDataAnalysisSystem/rionid_exercises/exercise_194Pb_Exp_2025/New_TEline2022-ESR-194Pb-208Pb-nostripper_524MeV.lpp"
alphap = "1.4"
harmonics = "212"
refion = "194Pb+82"
circumference = "108.34"
mode = "Bρ"
value = "7.196596"
reload_data = true
nions = "100"

all settings are done.
any files coming after this one is good:

RSA01-2025.04.01.03.52.59.247.tiq

~ 20:00 changed E-SIS to 524.0 MeV/u to get 194Pb at the Brho of the primary beam before (=7.2008 Tm).
which corresponds to gamma = 1.400 for 194Pb82+. 
Before it was E-SIS = 480.5 MeV/u after Be-1839 mg/m^2 target Brho = 7.2014 Tm.
Keep target and beamlines and ESR the same, only SIS and TE-line before target is changed.

1. convert copy a tdms file into the folder:
(pyroot) gpuuser@appc256:/data.local/G22-00018_00203/data/ntcap/sc/SC_2025-03-28_18-48-51$ cp /mnt/ntcap-data2/G22-00018_00203/data/ntcap/sc/SC_2025-03-28_18-
48-51/0000216.sc.tdms ./
2. convert the tdms file into root file.
(pyroot) gpuuser@appc256:/data.local/G22-00018_00203/data/ntcap/sc/SC_2025-03-28_18-48-51$ /data.local/G22-
00018_00203/scripts/OnlineDataAnalysisSystem/iqt7/convert_iqt_sc -i 0000216.sc.tdms  -o ./
3. plot the result.
picture 1,2: trigger vs time
picture 3: solfware trigger vs time

new analysis settings for NPZ files:

[analysis]
nframes = 190
lframes = 65536
navg = 1


first file with this setting:

'RSA02-2025.04.07.18.57.17.454.tiq', 'RSA02-2025.04.07.18.57.02.328.tiq', 'RSA02-2025.04.07.18.58.17.958.tiq', 'RSA02-2025.04.07.18.57.40.143.tiq', 'RSA02-2025.04.07.18.58.25.520.tiq', 
'RSA02-2025.04.07.18.57.09.892.tiq', 'RSA02-2025.04.07.18.57.32.580.tiq', 'RSA02-2025.04.07.18.57.25.017.tiq', 'RSA02-2025.04.07.18.58.10.395.tiq', 'RSA02-2025.04.07.18.57.55.271.tiq', 
'RSA02-2025.04.07.18.56.54.765.tiq', 'RSA02-2025.04.07.18.58.02.833.tiq', 'RSA02-2025.04.07.18.57.47.707.tiq', 'RSA02-2025.04.07.18.56.47.202.tiq'

frequency of 194Pb82+ at 211 408606000
frequency of 194Pb82+ at 126 244001000

changed storage place to bank 1 of the NAS
restarted the NTCAP with new address
restarted Analyzers with new address
restarted the queqiao script
restarted looper scripts

new files on RSAs start from:

2025-04-07 15:23 onwards

new files on NTCAP have their corresponding time stamp on the directory

This is a preliminary result during 4:00-19:00 April 1st 2025. 
I correct the frequency drift of 194Pb82+ ions injection by injection.

I have analyzed all injection data during 4:00-19:00 and calculated the frequency of 194Pb82+ for each injection. This is the frequency of 194Pb82+ as 
a function of time. You can clearly see that the frequency of 194Pb82+ was drifted from 408.603 to 408.600 MHz. The variation of frequency is about 
3kHz.

here are all TOML config files of the automatic scripts.