Yesterday , the related channel applied to the DAC output sent to the DAQ has been renamed as ENV_NOISE_MAG_{C,N,W}EB_rd . 

This morning , between 2025-05-07-03h34m06-UTC and 2025-05-07-04h04m14-UTC, some investigations were done by  tuning the time relationship between the RT_CPU2 Acl tasks and the RT_CPU0 one, as the RT_CPU0 manage the I/O flow

• this plot shows that ,in the default state, the channels sent the DAQ by the ENVnoise server, the ENV_NOISE_MAG_{C,N,W}EB ones,  are OK while the ones, ENV_NOISE_MAG_{C,N,W}EB_rd,  used to drive the DAC output are noisy .
  • This suggests that there is a timing problem because the ENVnoise task is started at the end of the LSC_Acl task running on the RT_CPU0
• the following plots show that delaying the publications of the Acl channels from the ENVnoise server in the so-called channels buffer allows  to improve the situation
  • Channels buffer publication delayed by 4us : the channels sent the DAC are not OK while the ones sent to the DAQ are noisy
    • this test confirms that the issue a  timing relationship between the Acl tasks running on the RT_CPU2 and the last one running on the RT_CPU0: this is expected because the channels are first sent to the Tolm network and then to the DAQ
  • Channels buffer publication delayed by 8us  better but not enough and then 10us  that it's OK

As  the LSC_Acl_Moni, runnning on th RT_CPU2,  has an elapsed time of 10us , including already a channel buffer delay of 2us, a channel dependancy has been added on the ENVnoise server to run after the LSC_Acl_Moni on allowing to  have starting delay of 10us(see this plot )

The last plot show the trend of the several trials between 2025-05-07-03h34m06-UTC and 2025-05-07-04h04m14-UTC