All seems OK.

Screenshots attached.

All seems smooth.

Screenshots attached.

All looks good.

Sceenshots attached.

All seems normal.

Screenshots attached.

When using the VETAR connected to the HDMI port of the root MACB the settings for all the MACB in the system 0x3.

This setting takes the Clock and Data line from the input HDMI and outputs it via teh HDMI output ports.

When using the Emulator connected via the SMA connectors on the back of the root MACB then the setting for the root MACB should be 0xD and all others should be 0x3.

Attached is the .jed file for programming the MACB and the .vhd source file to help with understanding of the settings.

Loaded new frimware into all 12 FEE64s in the system. IWR_Dec19_4.bin 

Booted ok after power-cycle.  

RESET/SETUP/GO all fine.

system wide checks ( SWC ) clocks, white rabbit ( WR ) OK, ADC calibrated : aida10 failed. Couldn't get them to calibrate.

Checked aida01 waveforms for ASIC1. set threshold for LED to 5000 to stop triggering in the noise.

Set White Rabbit register SYNC Rollover Target ( 14 ) to 0x4000 instead of 0xe to reduce the data rate to better understand the waveform activity.

All FEE64s are set to enable all channels of ASIC1 with low thresholds so a lot of data moving. Checked activity using statistics window.

Checked waveforms working for ASIC1 of aida01. Noisy but capturing the pulser pulse.

 Enabled all the waveforms on aida01 to see if they all function ok. After a few seconds waveform readout stopped. Not sure of the reason.

STOP, change all four thresholds to 5000, Check ASIC controls : all ok, GO. No activity.

RESET/SETUP ok.

SWC : clock failed, ADC failed , WR ok ????

Power-cycle...... concludes ok, RESET/SETUP ok, SWC : clocks all failed, ADC all failed, WR ok.

Checked WR status browser page for aida01. WR timestamp 0 ! status : 0xA should be 0 .

Checked tcl for SWC WR check and it doesn't check the status. Changed at DL and at GSI and now it does.

so SWC WR check no all fails.

Contacted NH and he found Fatima VME crate with WR source in had been switched off. It was powered on again.

RESET/SETUP , SWC: clocks all ok, ADC all ok, WR all ok.

set aida01 and all odd number  LED thresholds to 5000 and aida02 all even number thresholds to 10000 and activity of statistic Wave Good Events is similar across the system. 

Checked each of the Waveform capture controls pages ( only shows the status registers for ASIC1 ) and all are fine, nothing sticking.

enabled all the ASIC waveforms on aida01 again and it sticks, clear out three ASICs and operate the waveform reset in the System Functions and it restarts and runs.

So a qualified success. Don't enable too many channels at once ?

left running at 18:00 UK time and checked at 21:30 UK time , still operating ok.

Here is a document showing how and where to calibrate the LMK3200 devices that lock to the system clock and generate the clocks for the ADCs and the FPGA internal logic.

There is a new operation available in the System Functions menu in the System Wide Checks page. ( The page needs to be reset once when the FEEs are powered before this function will appear )

Check the Options files are all the same size

Using this function will provide a list of the file sizes of the Options/< fee name >/CONTENTS files along with the last time they were accessed as a list.

It's up to the user, at present, to interpret the results but more is possible if required ....

To Synchronize the FEE64 ASIC clocks to rise at the same timestamp time use the System function Synchronise the ASIC clocks in the System Wide Checks browser page.

The Server will read the current timestamp value and calculate, based on the number of FEEs and the access delay, a timestamp value sometime in the future. F_stamp

F_stamp is written to each FEE and the synchronization is enabled. 

In a state machine in the FEE ASIC clock control, logic is enabled to synchronize its ASIC clock. It compares the current timestamp with F_stamp and if the current timestamp is >= F_stamp then it will start the ASIC clock.

The report in the browser log window gives the 3 LSBs of the timestamp at the instant the ASIC clock is started. They should all be the same. They are from the 10ns timestamp.

14/4/21 @12:00 UK time

Corrected the failure of FADC re-calibration All modules. The problem was a missing > in the .tml file

Edited the sys.tcl file in /MIDAS/TclHttpd/Html/RunControl to comment out where the status of the waveform enable was able to stop the creation of the .W spectra. This will now function at SETUP.

Edited the sys.tcl file to remove the test for Master module at the enable of the Correlation Scalar readout. All modules will now be enabled.

Successfully re-calibrated the LMK3200 in aida09 to remove the clock fault reported in System Wide Checks.

Successfully "sync ASIC clocks" followed by calibrate all module FADCs ( except aida09 which required seperate attention. )

All the Edits first carried out and tested at Daresbury T9 system.

Please note that for the forseeable future the system function in the menu on the System Wide Checks browser page labelled as 

"Collect the Timestamp RAM values"  and "Start the Readout Timestamp error tracing" 

Are for the use of engineers only unless otherwise instructed. 

There is no harm in using them but the results may be confusing and it is not possible, at present, to detail a definitive set of instructions for their use.

After tests in the Daresbury T9 system.

Disabling the waveform ADCs in an FEE64 which is running with the FPGA over temperature will drop the FPGA temperature by 10 degrees.

To disable the ADCs open the Local Control browser window and set the ADC Control register , @2, to 0xFF

The easiest way to restart the waveform ADCs correctly is to rerun SETUP from the control window selecting just the FEE that is affected.

Alternatively STOP acquisition, set the ADC Control  register back to 0 and rerun the calibrate ADCs in the FADC Align and Control browser window.

The Pi console monitor program now outputs a full date/time to file for each line of report.

The System Wide Checks has been upgraded to include a check of the PLL lock monitor counters. A baseline is taken when the software starts, or at the users command, then subsequent operation of the command compares the current counter value with the baseline. There are two PLLs on the pcb, LMK3200, and the remainder are in the FPGA. Should there be a disruption in the external clock source to the FEE64 then it is possible the Lock signal from one or more of the PLLs will go false to indicate the PLL is not locked to the input frequency. This transition is counted in the FPGA. If the clock source recovers then this is the only way to understand that a hiatus has occurred.

Noted this morning that the Options file sizes are different and there is no common update date across the 16. I will further improve this function to try and indicate differences ... if required ?

aida07 ADCs will not calibrate. I have attempted to understand why but I have not seen this behaviour before. I suggest, if this is a problem, that a power-cycle be carried out  and then the module is replaced if no improvement is noted.

Merger message logging. I have transferred across my version of the New Merger to the npg folder. /home/npg/Patrick/NewMerger. It runs from the command  /home/npg/Patrick/NewMerger/MergeServer/bin64/run and is currently set for 16 links. The only changes to the NewMerger code have been made in the message.c file. The rest is untouched.

This version will create a log file directory in /MIDAS/log/Merge_Logs. A new directory structure is created here each time the New Merger is started. The directory is named using the date and a number which refers to the number of times the New Merger has been started on that date.  ( /MIDAS/log/Merge_Logs/16_02_22_5 )

Within this directory are text files storing the messages from each of the processes in the New Merger system. The link file messages are stored in a sub-directory as they are currently named by the process number and not the link number. (/MIDAS/log/Merge_Logs/16_02_22_5/links/Link_1529.txt )

The purpose of this change is to be able to correlate error messages reported from the FEE64 consoles with information from the Merger processes.

The system is currently running  with this software for the next fortnight.

Study of the FEE64 power supply distribution has yielded the following :-

The most sensitive regulator, as regards the device voltage input, is the TPS51100 that supplies the DDR memory reference voltages. This requires +4.75 to +5.25 volts. This is supplied from the Power input connector +5v input.

The common LT3080 regulator used over much of the board is a Low Voltage Dropout regulator. This requires 0.5v difference between input and output voltage as minimum. This is not a problem with the +4.75v minimum for the TPS51100 requirement setting the voltage for the board.

The supply to the mezzanine is direct from the power connector +5v input. On the mezzanine there is an LT3080 for each ASIC supplying the required 3.3v. These regulators would possibly benefit from a 1uF capacitor at the Control voltage input.

The simplest approach would be to add a capacitor to the bottom layer where the Control voltage enters the mezzanine. 

The power cable has a nominal resistance of 13.3ohms/km. The 3 conductors of the cable are supplying 10A when all is in operation. So the expected voltage drop would thus be ( 10 x 13.3 x 0.007 ) /3 => 0.3v each core. 

The conclusion would be that the voltage at the power supply should drop to 5.25 v thus ensuring the TPS51100 is supplied as required regardless of the operation of the FEE. 

This will be tested at Daresbury.

There are three Merger statistics that can be used to better understand how the data flow through the Merger system is proceeding.

Two are from the Link task and one is from the Merger.They are all "No data buffers avaliable" with #1, #2, #3 at the end.

#1: This is incremented when the Link task has a data item to put in the queue for the Merge process but there is no room.

#2: This is incremented when the Link task has found no room in the queue for the Merge process ( #1 ) , waited , tried again and failed. 

#3: This the other end of the queue. When the Merge task requests a data item from a Link task queue and there is nothing available.

1:18 (CET) No rate in AIDA 07.

Oscar did a AIDA DAQ reset and a quick wide check.

(Power cycle

All back to normal.

Attachment 1 - FEE64 temperatures illustrating (we assume) a faulty PSU temperature sensor for aida07

Attachment 2 - FEE64 temperatures following replacement of aida07

Attachment 3-5 - 1.*.W waveforms for aida01 - aida03 - LED settings for aida02 incorrect, aida01 adaptor PCB 
incorrectly aligned

Attachment 6-7 - 1.*.W waveforms for aida02 and aida04

Attachment 8-9 - aida01 - aida04 1.8.L spectra full range and expanded scale
                          pulser peak width c. 15-20 channels FWHM

Attachment 10-12 - good events stats for all FEE64s and all statistics for aida01 and aida05
                   Note aida01 - aida04 show rates expected, all other FEE64s show very rates due to noise
                   aida01 - aida04 adaptor PCB are well grounded to FEE64 copper mezzanine/cooling plate, the other 
FEE64s are not

Attachment 13-14 - aida01 - aida04 rate spectra before and after correcting alignment of aida01 adaptor PCB

Attachment 15 - aida01 - aida04 1.8.L spectra, expanded scale

Attachment 16 - illustrates high frequency noise (period 5 samples = 100ns) for aida01 which is not observed for 
aida02 - aida03
                subsequently determined that this is not due to a possible adaptor PCB fault by changing the adaptor 
PCB
                Note that with bias turned on this noise did appear when Bias was on but all the other groudning
connectors for aida05-aida12
were not in effect.

Attachment 17-19 - PuTTY connection to CAEN 1419ET 4ch high voltage supply illustrating PuTTY, N1419ET configuration 
and leakage current with 100V applied to adaptor PCBs (no input cabling or DSSSD connected)

Note the CAEN N1419ET appears as a 'USB ACM' device and we connect using /dev/ttyACM<n>. 

Kernel panics during boot cab be observed in files ttyUSB1 and ttyUSB5

In each case the FEE64 successfully completed reboot c. 5 minutes later

On the 18th of September we installed DSSD 3208-14

Was found to have problems including exponential leakage behavior

  V      Ic
 -5   15.4uA
 -10  53uA
 -15  Tripped at over 100uA

Cables were double checked, bond wires were checked and no problems could be observed.

DSSD replaced with 3208-15

Bias at -100V Ic 10.2uA GP/grnd Jumpers removed,
                         rising upwards, possible short circuit as well.

Jumpers replaced

Bias -100V Ic 1.6uA
Bias -160V Ic 1.62uA

Possibility that mechanical sample 3208-17 and 3208-14 have been swapped. (To check at later date)

FEEs powered up and Adapter boards and all grounding installed with DSSD going to 9,10,11 and 12

Rates shown - attachment 1
Waveforms - attachment 2-4
1.8.l Spectra - attachment 5
FEEs 10 and 11 around 60FWHM and 9 and 12 around 80-90FWHM
Stats page - attachment 6

Aluminium foil used to make sure all ports are light tight shows a stats drop of around half - attachment 8

New peak widths

aida09 - 79.65
aida10 - 67.37
aida11 - 59.99
aida12 - 97.83

Going to begin a systematic study of shaping time

                              FWHM
Shaping Time   aida09   aida10   aida11   aida12
   
     8          79.65   67.37    59.99     97.83
     7          97.55   70.84    62.67     115.34
     6         100.72   70.04    62.77     120.05
     4         147.47   80.64    71.34     167.23
     2         217.62   114.98   133.35    232.47

Shaping time 8us 1.8.L Shots 
Shaping time 4us Stats appear obviously worse - attachment 7
                 1.8.L Widths - attachment 8
Shaping time 2us Stats appear worse again - attachment 9
                 1.8.L Widths - attachment 10
Shaping time 6us Stats are better than 2 and 4 - attachment 11
                 1.8.L widths - attachment 12
Shaping time 7us Stats are better than 6 - attachment 13
                 1.8.L widths - attachment 14


8us is the optimum shaping time.
Taken back to 8us and similar shaping times are observed.

Connected the ground of all 4 adapter boards with direct cables. Observed improvements in both FEEs 9 and 12
however the noise in 11 went
through the roof >500kHz - attachment 15

Tested just having 9,10 and 12 connected the rates are comparable to when disconnected - attachment 16

All 4 grounded together with a ground running to the snout as well stats No difference to all 4 together -
attachment 17
              1.8.L Widths - attachment 17
aida09 104.76
aida10 84.58
aida11 281.77
aida12 82.58

Tested just having 10 and 12 directly connected. Same side of the DSSD: Noise is the same as when disconnected.
Stats - attachment 19
1.8.L spectra - attachment 20

aida09 107.13
aida10 67.02
aida11 66.78
aida12 131.51

Tested having 11 and 12 connected directly. This is the two adapter boards responsible for the bias with 11
carrying the core and 12 the braid.
Massively reduced noise in 9 and 12, comparable noise in 10 but much more noise in 11. Stats - attachment 21
aida09 63.96
aida10 76.64
aida11 125.96
aida12 68.05
1.8.L spectra - attachment 23



18:39 Alpha run started in /TapeData/Sep18/R2
      Writing at 96kb/s
      11 Was fast at start bus asic control brought it down