Tue Feb 24 03:04:59 2015, CG, TD, Tues 24th Feb progress 9x
|
24/02/15
1200: Update the FEE firmware on nnaida1-16 without problem.
Gone from file FEE_Oct12_27Nov13.bin ----> FEE_Riken_Apr14_24.bin
Included are a screen shot of the temperature window showing the new firmware versions and a stats screen.
12.15 Update MIDAS DAQ software
su
cp -r /MIDAS@aiidas /MIDAS@aidas.240214 ( /MIDAS is a link to /MIDAS@aidas )
exit
cd <update directory>
cp -r Data_Acq /MIDAS
cp -r Merger /MIDAS
cp -r TclHttpd /MIDAS
New versions of merge64.AD and master64 were installed in /MIDAS/Merger but the process crashed at startup
with multiple messages of the type:
MIDAS Data Link (12345) : Received SEGV signal; exiting.
(see attachment 3)
Is this related to the recent changes to the MIDAS TapeServer software to resolve problems with MIDAS Data
libraries libdataspy.so and libxfer.so ?
As a temporary workaround I have copied the backups of merge64.AD and master64 back to the install
directory /MIDAS/Merger. With the old verison of the merger we continue to obtain error messages
(see attachments 4-8)
|
Mon Feb 23 11:10:44 2015, TD, Outline test plan - RIKEN - Feb 2015
|
With the exception of one AIDA FEE64 PSU configuration test (5) and the upgrades
of the AIDA FEE64 firmware (8) and MIDAS DAQ software (9) we have now completed all
of tasks described in the outline plan. |
Mon Feb 23 07:23:08 2015, J. Agramunt, H. Baba, A. Estrade, DAQ correlation test   
|
The attached figure shows the configuration used to test the synchronization of the DAQ systems using a
correlation scalar counted from a common clock signal (DAQcorrelation_diagram.pdf).
The chosen solution was to use a 25 MHz clock generated by the MACB modules of AIDA, which was distributed to
the other two systems by a SIS36/38xx module in the BRIKEN VME crate.
The correlation can be monitored online using the MIDAS DataXfer and DataSpy libraries
(http://npg.dl.ac.uk/MIDAS/DataAcq/Data.html). Each system operates a
DataRelay program that sends a data stream consisting only of IDs and time-stamps to a common DataSink (this
requires a DataRelay code that does some filtering of the raw data for each system). The scheme is shown in
attached diagram (DAQsoftware.pdf).
The DataPeek_Merge and SyncCheck codes use C++11 for parallelization of tasks, which is a helpful feature to
improve the efficiency of finding coincidences between the correlation pulses. Thus, the code will not run in
PCs with any Linux version. For example, it requires version 7 of ScientificLinux, which installed in the PC
being used for BRIKEN DAQ control that will stay at RIBF for the time being.
++ SYNCHRONIZATION RESULTS ++
The figure correlation_25Hz.png shows a correlation plot for the BRIKEN+RIBF+AIDA running with correlations done
by a pulser at 25 Hz. A large fraction of the pulsers appear in the double-coincidence plots (top row; same plots,
except the 'Partial' one is automatically cleared every ~10seconds).
The bottom plots show the pair-wise correlations between BRIKEN and RIBF or AIDA. BRIKEN was defined as the
'master' in this test, but current version of the program is flexible to select any stream as the master one.
The second figure (correlation_random.png) shows the same test, but using a non-periodic pulser to trigger the
correlation scalar. We observed the same level of synchronization (peaks look brader just because of the zoom level). |
Mon Feb 23 07:03:10 2015, TD, AE & CG, Monday 23 February 2015
|
14.30 Saved nnaida1-16 ASIC + Waveform configurations to directory (Data Base Key)
2015Feb23-12.11.40
(directory aidas1:/MIDAS/DB/EXPERIMENTS/AIDA/2015Feb23-12.11.40)
nnaida 1-2, 5-6, 9-10, 13-14 positive input ( front p+n junction strips )
nnaida 3-4, 7-8, 11-12, 15-16 negative input ( back n+n ohmic strips )
Standard ASIC configurations except
- shaping time 0xb (6,5us)
- peaking time 0x8 (16us)
- slow comparator 0x10 (~160keV)
- fast comparator (LEC/MEC) 0xff
- fast comparator (HEC) 0xff
nnaida 1-2, 5-6, 9-10, 13-14 negative input ( AIDA ASIC preamp output inverts input,
i.e. preamp with positive input produces negative input for sampling ADC )
nnaida 3-4, 7-8, 11-12, 15-16 positive input
Standard Waveform configurations except
- threshold 1000
- pre-trigger 0x100
- all channels disabled
2015Feb23-12.11.40 is now the default configuration file
Note: The directory (Data Base Key) which will contain the saved settings is created uid: npg, gid: npgstaff, perms 755.
However, its contents are written uid: nfsnobody, gid nfsnobody, perms 777. The default directory (Data Base Key) permissions
do not work - it is necessary to change the directory (Data Base Key) to perms 777 after its creation and before saving the
individual FEE64 configuration directories/files to it.
|
Sun Feb 22 06:47:23 2015, CG, AE, TD, Sunday 22 February 2015
|
22/02/15
am Testing various grounding configurations for the connection between the DSSSD and the FEE64 modules.
15.45 Obtaining error messages from Merger TTY console (see attachment 1)
1700: Summary of AM testing of grounding configurations.
Set up system as it was when we left last night to check reproducibility -> peak FWHMs all same to within 10%.
Throughout tests yesterday, nnaida8 was consistently worse than the other nnaida, why? Can it be improved?
Most obvious difference between 8 and the rest was that the nose was grounded through nnaida8.
Removed nose grounding cable and left to hang -> no appreciable difference in FWHMs.
It was then attached to the Cu piping using a croc clip -> no change.
Connected to nnaida6 -> no change.
The heavy duty Cu braiding was removed from all nnaida and the pulser FWHM in all nnaida increase significantly.
=> clearly the braiding is helping.
Put Cu braiding back in place and added shielding plates to nnaida1,3,8 (kapton in way on nnaida5/6, also useful as a reference point).
Each shield plate was fit onto the set screws with two spacers and sat over the kaptons, black tape was put over the vias to prevent them touching the plates.
No change with respect to the first measurements this morning.
=> the grounding changes implemented today have had no effect at the current noise level, but that is not to say they may not have an effect in combination with production detectors, new kaptons etc.
1715: Tested the new USB mains power switches for function (without load). All seem to function correctly and are controllable from the RPi.
|
Sat Feb 21 06:37:52 2015, CG, AE, TD, Sat 21st Feb progress 6x
|
21/02/15
1230: Developing the software to check synchronisation between DAQs. Below line runs program on aidas1 - sends data from TapeServer to BELEN.
./DataRelayFilter -n 10.32.6.196 -p 10307 -I 2
1500: Investigating pulser peak FWHMs as function of bias voltage.
Constant shaping time of 0x3, slow comp thresh 0x20, fast comp thresholds of 0xff. All other setting as standard. Detector MSL BB18 2977-20.
Results summarised in table directly below.
|
Pulser peak FWHM (ch) |
|
|
nnaida1 |
nnaida3 |
nnaida6 |
nnaida8 |
Bias (v) |
Leakage current (uA) |
1.9.L |
2.10.L |
1.9.L |
2.9.L |
2.10.L |
3.11.L |
2.10.L |
3.9.L |
75 |
10.700 |
166 |
133 |
174 |
156 |
176 |
168 |
271 |
285 |
100 |
10.905 |
165 |
131 |
174 |
158 |
168 |
166 |
272 |
285 |
125 |
11.090 |
167 |
151 |
175 |
158 |
167 |
160 |
271 |
285 |
150 |
11.410 |
179 |
140 |
178 |
158 |
169 |
166 |
271 |
283 |
200 |
12.275 |
----- |
------ |
175 |
159 |
------ |
------ |
272 |
286
|
At bias of -200V nnaida1+6 stopped outputting data but continued to produce SYNCs. Good event rate dropped from ~few thousand per sec to ~300 per sec.
After returning bias to -150V, nnaida1+6 started producing data again. No effect was seen in nnaida3+8.
nnaida8 peaks are not particularly Gaussian in shape. Look more skewed with one rolling edge and one side a relatively sharp drop.
No obvious trends with changing bias voltage. Will return to -100V.
1545: Investigating pulser peak FWHMs as function of shaping time.
Bias returned to -100V, with leakage current 11.000uA.
Settings for all nnaida: slow comp thresh = 0x20, fast comp thresh = 0xff, hold time = 0x4 if shaping time <= 0x8, 0x8 if shaping time > 0x8.
Pulser peak FWHM (ch) |
|
nnaida1 |
nnaida3 |
nnaida6 |
nnaida8 |
Shaping time (Hex) |
1.9.L |
2.10.L |
1.9.L |
2.9.L |
2.10.L |
3.11.L |
2.10.L |
3.9.L |
0x0 |
254 |
172 |
151 |
160 |
172 |
164 |
287 |
293 |
0x1 |
237 |
167 |
176 |
172 |
184 |
176 |
328 |
367 |
0x2 |
193 |
146 |
184 |
168 |
180 |
175 |
306 |
321 |
0x4 |
149 |
119 |
171 |
152 |
159 |
155 |
252 |
261 |
0x8 |
129 |
122 |
154 |
147 |
139 |
137 |
195 |
201 |
0xb |
133 |
129 |
160 |
148 |
137 |
135 |
184 |
188 |
0xf |
139 |
139 |
169 |
159 |
141 |
142 |
184 |
183 |
Visual 'analysis' suggested 0xb to be the optimal value so used that as shaping time in further tests.
(Graph to follow)
1900: Investigating effect of changes to slow comparator thresholds.
Settings: bias = -100V, hold timing = 0x8, shaping time = 0xb, fast comp thresholds = 0xff. Otherwise, standard settings.
Position of threshold (ch) |
|
nnaida1 |
nnaida3 |
nnaida6 |
nnaida8 |
Slow comp threshold |
1.9.L |
2.10.L |
1.9.L |
2.9.L |
2.10.L |
3.11.L |
2.10.L |
3.9.L |
0x20 |
32164 |
32378 |
33102 |
32990 |
32427 |
32261 |
33433 |
33433 |
0x18 |
32271 |
32481 |
32997 |
32890 |
32529 |
32369 |
33334 |
33349 |
0x10 |
32389 |
32589 |
32898 |
32788 |
32648 |
32449 |
33225 |
33260 |
0xd |
32420 |
32596 |
32858 |
32755 |
------ ? |
----- ? |
----- ? |
----- ? |
With threshold at 0xd, threshold position was very hard to determine for nnaida6+8, assume discirminator is running in the noise. Will ignore data for 0xd.
Assuming central position of 32768 and energy per channel of 0.7 keV, below table gives approximate position of threshold in keV.
Position of threshold (ch) |
|
nnaida1 |
nnaida3 |
nnaida6 |
nnaida8 |
Slow comp threshold |
1.9.L |
2.10.L |
1.9.L |
2.9.L |
2.10.L |
3.11.L |
2.10.L |
3.9.L |
0x20 |
423 |
273 |
234 |
155 |
239 |
355 |
467 |
467 |
0x18 |
348 |
201 |
160 |
85 |
167 |
279 |
396 |
407 |
0x10 |
265 |
125 |
91 |
14 |
84 |
223 |
320 |
344 |
Thus (very roughly), between 0x10 and 0x20, the above table shows the threshold moving by about 10 keV per increment in the threshold.
With the threshold at 0x10, the data rate show on the TapeServer window was ~3Mb/s (uncompressed?).
This was with 1 detector (BB18 2977-20) connected to 4 FEE64s with above settings, a 25Hz pulser and 241Am+207Bi sources (activities in ELog entry 40).
The Good Events rate averaged around 30,000-60,000/s per FEE64 card, with only a few Pause/Resumes coming through.
Example stats screen and hit patterns included below for final configuration. |
Fri Feb 20 10:48:09 2015, TD, How To Connect the FEE64 System Console Using PuTTY
|
Set permissions for the USB-serial device using the command
sudo chmod 777 /dev/ttyUSB0
Note: Vic Pucknell reports that he has sometime observed the device
rotate between /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2 etc - make\
sure you are using the correct device name with the command:
ls -l /dev/ttyUSB*
Start PuTTY
Select Connection Type 'Serial'
Enter Serial Line (/dev/ttyUSB0 or /dev/ttyUSB1)
Enter speed (9600)
Select 'Open'
Note: permissions for the USB-serial device will revert to their
default (mode 440) when the OS notices the change but by then
the serial line connection will have been established. |
Fri Feb 20 10:04:29 2015, CG, AE, TD, Fri 20th progress 
|
20/02/15
1400: Measured leakage current as function of bias V for the Caen 1419B high voltage supply and detector BB18 2977-20. (see attachment #1)
1500: Modified MACB installed and connected to BELEN and RIBF DAQs (see attachment #2 for signal flow diagram).
Increased noise in several nnaida, possibly due to grounding issues introduced by inclusion of modules for other DAQs. |
Thu Feb 19 08:21:33 2015, CG, AE, TD, Thrus 19th Feb progress 39x
|
19/02/15
1000: Check system gives same resolution as yesterday, removing only the Cu braiding connecting and grounding all adapter PCBs (also moved bias braid back to nnaida3).
Pulser FWHM in each FEE... nnaida1 ~800ch, nnaida3 ~110ch, nnaida6 ~2300ch, nnaida8 ~950ch. Rate in 6 and 8 ~5kHz per strip.
Re-added Cu braids, clipping on to LEMO connectors of adapter PCBs.
FWHM and rate/strip in nnaida1,3,6,8 now (respectively): ~600ch and 100Hz, ~120ch and 25Hz, ~2100ch and 6kHz, 1000ch and 6kHz. => small reduction in nnaida1+6
nnaida8 also has non-Gaussian pulser peaks.
No clear effect, but minor improvement and no negative effects mean we will keep Cu braids attached.
1045: Grounded nose to adapter PCB attached to nnaida7+8. No clear effect.
1055: Changed pre-amp reference settings in nnaida1+8.
nnaida1 0x30 -> 0x60. nnaida8 0xb2 -> 0x82.
No clear change. Reverted back to original settings.
1130: Changed to detector BB18 2977-20 and added 241Am (1uCi) and 207Bi (few uCi) sources 2cm from front of detector (see attached photos for arrangement).
Bias set at -100V with leakage current -10.9uA.
Pulser peak FWHMs for each nnaida are: #1 ~600ch, #3 ~150ch, #6 ~1300ch, #8 ~ 700ch. Minor improvement over previous detector.
1345: nnaida3 still much more well behaved than other nnaida. To test if kapton cables are source of issue, swapped kaptons for nnaida3+8 at FEE end.
Peak FWHMs and rates for nnaida3+8 having swapped cables are: #3 ~700ch and 300Hz, #8 ~200ch and 30Hz.
=> noise moved with kapton! Kaptons could be the issue. (For completeness, FWHM in nnaida1 ~800ch and nnaida6 ~1100ch.)
1435: Disconnected kaptons at detector end (still connected to FEE adapters).
Pulser FWHMs and rates/strip per strip now: nnaida1 - ~250ch and 25Hz, nnaida3 - ~120ch and 25Hz, nnaida6 - ~160ch and 25Hz, nnaida8 - ~120ch and 25Hz.
Waveforms for all nnaida looked similar and with little noise => no way of telling a 'bad' cable from a 'good' one, just from FEE + cable (without detector).
Current cable configuration/pairings: nnaida1-kapton A, 3-B, 6-C, 8-D.
Kapton B shows no alpha/beta spectrum from sources in 1.1.L, a problem which tracked across to nnaida8 when cables were swapped => suggesting break in cable for this channel.
Waveforms in all nnaida look relatively noise free (nnaida1 slightly noisier) and as expected.
1520: Changed some of the kaptons to check all were functioning properly. Kept nnaida3-kapton B combo as this was working as expected from DL tests.
Changed nnaida1 A->E (neither isolated), nnaida6 C->F, nnaida8 D->G.
After removal. noticed outgoing kaptons C+D did not have "Isolated" label on them (B does).
Without connecting new cables to detector, FWHMs and rates/strip in all nnaida ~130-150ch and ~25Hz, respectively.
1545: Connected kaptons to detector 2977-20 and with alpha+beta sources 2cm in front of detector.
Bias connected via nnaida6 (-ve core) and nnaida3 (low V ref braid). nnaida3+8 grounded.
nnaida-kapton pairings now as follows: nnaida1-kapton E, 3-B, 6-F, 8-G.
Pulser FWHMs and rates/strip now: nnaida 1 - ~190ch and ~60Hz, nnaida3 - ~250ch and ~60Hz, nnaida6 - ~180ch and ~40Hz, nnaida8 - ~350ch and ~100Hz.
Above rates seem sensible considering we have 25Hz pulser going into FEEs, plus alpha and beta sources.
MUCH better than previous! (apart from nnaida3 which remains about the same)
Further more, rate spectrum for each nnaida shows slow decline in rate with increasing bin number. Expected as 241Am placed centrally and outer strips will see lower rate as more alphas are stopped due to path travelled.
1645: Saving data to file with system configuration: Am+Bi sources, EBFG kaptons, Cu braid grounding between adapters and nose grounded to nnaida7+8 adapter.
File - /TapeData/Feb2015/Run1_*.gz.
Run stopped at 1715.
17:40: Providing one pulser signal to BRIKEN VME crate, which is in the same main bias supply as AIDA. Start a new run to check things are not changed
File - /TapeData/Feb2015/Run3_*.gz.
19.42 File /TapeDate/R3_1.gz closed (985+303Mb)
|
Wed Feb 18 11:25:54 2015, Patrick Coleman-Smith, Investigations into removing HV noise
|
With the system in T9 and a Keithley Source Meter supplying HV to the detector.
The source meter supplies 200V and measures the current ....
I noticed that the current value was not stable... varying by +/-0.5uA. In conversation with Marcello i learnt that normally much more stable than this.
I have carried out the following changes.
added a 22nF X7R capacitor at the detector end of the Kapton cable from the HV connector pin ( G/R ) to the ground plane of the Kapton.
added a 14k resistor in series with the HV supply +ve signal before it connects to the adaptor board.
isolated the G/R connection on the second Kapton that would normally be connected to the HV on the detector.
The HV now is a lot quieter +/-0.01uA.
Next i disconnected the HV -ve input from ground at the adaptor board. This resulted in all the FEE64 being equally noisy!!
Next I connected a 22nF X7R capacitor between the HV negative and ground at the adaptor. This resulted in all FEE64 becoming equally calm.
The FWHM of the spectra is not good at 250 to 300 but the fact that all FEE64 are equal now is interesting.
I will update this post with pictures.
Update:-
This change was not stable and repeatable. I changed back to the original connections and things haven't gone back.
So power down and leave for today.... It doesn't make sense to me ... but then that's nothing new :-)
It appears that something is heating/charging up during the day and the noise becomes swamped by this effect ???? |
Wed Feb 18 05:49:29 2015, CG, AE, TD, PJC-S, Wed 18th Feb progress 15x
|
18/02/15
1300: Error seen when trying to check ASIC settings. See Attachment #1. Power cycle removed error.
nnaida3 still performing much better than other three cards connected to detector (nnaida1,6,8). Why?
Noticed nnaida3 was connected to only adapter PCB which did not feature a metal shielding plate on the front?
Noise in other cards caused by possible short or capacitance between PCB pins and shielding plate?
-> Removed all shielding plates and no difference seen. Pulser peak widths all still approximately the same.
nnaida3+6 PCB grounds connected by thin braid, as well as nnaida1+8. These were all removed. No change.
1830: Still seeing errors when data is sent through them Merger, see attachments #2-6.
Attached heavy duty copper braiding in loop, connecting all nnaida PCBs in use. Improved FWHM of nnaida1 by factor of 2. No change in other nnaida.
Moved kapton and bias from nnaida3 to nnaida11 (same crate, next module along) and saw no appreciable difference in the spectra.
Changed voltages in PSUs for first 16 nnaida.
+5V -> +5.5V, -6V -> -6.5V, +7V -> +8V.
All +5.5V rails at 5.5V, however in PSU#1 (supplying inner FEE modules) -6.5V and +8V rails show variations of +- ~12mV and +- ~4mV respectively, between outlets.
Installed PSUs with updated voltages.
nnaida8 FWHM improved by factor of 2 but no difference in other nnaida.
Current configuration nnaida1,6,8,11. nnaida1+8 connected to p+n side, nnaida6+11 connected to n+n side.
Current FWHM: nnaida1 ~500ch, nnaida6 ~1500ch, nnaida8 ~600ch, nnaida11 ~120ch.
Update response from Patrick:-
Please see posting number 39 for ideas to improve noise and possible reasons why some FEE64 are quieter than others.
I think the SYNC problem is likely due to the version of VHDL perhaps not including the flush of buffers and with the widely different data rates. 224k against 3k.
This should improve with the VHDL update as I think the flush system is more efficient.
|
Mon Feb 16 09:41:45 2015, Patrick Coleman-Smith, [How To] Set up the Raspberry Pi for PuTTY
|
When logged in and before opening PuTTY open a cmdtool window.
cd /dev
sudo chmod 777 /dev/ttyUSB0
then you should be able to run PuTTY.
This is based on notes in my log-book.
|
Tue Feb 17 08:03:32 2015, Patrick Coleman-Smith, [How To] Set up the Raspberry Pi for PuTTY
|
Quote: |
When logged in and before opening PuTTY open a cmdtool window.
cd /dev
sudo chmod 777 /dev/ttyUSB0
then you should be able to run PuTTY.
This is based on notes in my log-book.
|
Tried this when we got in this morning and successfully changed the permissions for /dev/ttyUSB0, but made no difference to the error received when opening the PuTTY session, which was:
PuTTy Fatal Error
Unable to open connection to:
Unable to open serial port. |
Tue Feb 17 06:32:24 2015, CG, AE, TD, Tues 17th Feb progress 22x
|
17/02/15
1515: Installed detector BB18 2977-7 with 3 modified kapton cables, one unmodified (in nnaida1) with 207Bi source.
Bias voltage @ -100V with leakage current -11.6uA @ ambient temp of ~20oC.
nnaida1,3,6,8 connected to detector, all with shaping time of 2us and hold time 8us.
Slow comparator thresholds around 0x18 and fast comparators 0xf (see below images).
Pulser at 50,000 with x5 attenuator @ 25Hz. Both polarities supplied via use of Ortec 433A dual sum and invert amp.
nnaida1+6 p+n side, -ve bias. nnaida3+8 n+n side, ground.
nnaida3 most well behaved, with low rate similar to that of pulser rate and no missing channels. Waveforms look good.
Pulser peak has smallest FWHM @ ~150ch, compared to 1000s of ch for the other nnaida.
For comparison, nnaida7 (not connected to detector) has peak width of ~18ch FWHM.
nnaida1,6,8 have typical pulser peak widths of the order 1000-3000ch FWHM. Peak too broad in nnaida6 to be distinguishable from noise peak.
Waveforms from nnaida3 stable and as expected. nnaida1+6 slightly more variable and noisy.
Waveforms from nnaida8 see much greater noise and variability, including rail-to-rail transitions.
Increasing the pre-amp reference from 0x30 to 0x60, removes rail-to-rail transitions, but waveforms remain just as noisy.
1650: Successfully started Merge and Tape servers, writing data to disk.
Merge terminal window shows errors regarding Sync pulse timestamp sequence errors (see attachment #18).
1900: Installed Caen N1419 floating HV bias supply.
Connected to detector via nnaida3, positively biasing n-side through core with p-side as low V reference through braid. Saw no leakage current => open circuit.
After some problem solving found reversing the bias and negatively biasing p-side worked. Possible broken bond wires delivering bias on n-side.
Connected to nnaida8 (also positive bias to n-side) and found short circuit. Saw leakage current of 200uA (trip level) @ 5V.
Changed to negative polarity bias and connected to nnaida6 and saw sensible leakage current of -11.5uA @ -100V bias.
Spectra for each module showed FWHM for the pulser peaks to be: nnaida1 ~800ch, nnaida3 ~150ch, nnaida6 ~3000ch, nnaida8 ~1200ch.
FWHM in nnaida1 reduced by ~1/3, nnaida6 shows little change, nnaida8 reduced by ~1/2. nnaida3 shows no change, but in line with what was seen at DL. (w.r.t peak widths seen last night using Selena bias supply)
nnaida3 performing much better than other three cards connected to detector, but in line with what was seen at DL. Other 3 cards very noisy.
|
Mon Feb 16 12:17:21 2015, Patrick Coleman-Smith, MACB update for 50Mhz external clock
|
This version of the MACB has an additional selection at 5 for a ROOT module.
This will operate the Correlation Scalar signals used for RIBF and use the External Clock signal directly for the FEE64 50MHz distribution.
This has been tested at Daresbury with and external clock source and operates successfully with the merger.
|
Mon Feb 16 06:17:31 2015, TD, AEV & CG, Monday 16th Feb progress 10x
|
16/02/2015
1500: AIDA moved into operational position.
Water cooling circuit visually checked, fittings, etc for loose fittings/snags/kinks. No problems
Julabo FL11006 chiller moved into position with mains transformer, filled and turned on without problem (small leak from rear overflow, due to overfilling).
Took roughly 2 ~30L water containers to fill reservoir.
Brief leak at connection between back of chiller and yellow hose, bolt tightened and it stopped.
Having been turned on and loop filled, reservoir at ~50% full. Pressure ~10 psi.
No leaks observed in main coolant loop.
When standing downstream of AIDA RH flow gauge blurred due to high rotational speed, LH flow gauge rotating at ~1 rev/s.
Two FEE modules closest to centre in each block checked for power cabling, TS distribution and network cables. All ok.
MACBs front panel cabling checked, no obvious problems. TS distribution tree in order.
Power on for NIM bins and fan tray, network switches and Raspberry Pi. Not yet for the FEE module PSUs.
1 corner of each new USB power supply damaged in transit.
Fuses changed from 10A -> 16A in each PSU. Old 10A fuses taped to back of each module.
1730: Turned on nnaida1-16. Temperatures stable. All on firmware version 0xa4ed006.
Input pulser into all FEE cards. All FEEs bar nnaida5 well-behaving. nnaida12 has several missing channels.
Typical pulser peak width for -ve input modules was ~14ch FWHM with shaping time of 1us.
Typical pulser peak width for +ve input modules was ~27ch FWHM with shaping time of 1us.
Changing shaping time of nnaida10 from 1->2.5us reduced FWHM from 27ch to 23ch.
Attachment 1: temperatures & FEE firmware revisions nnaida1-16
|
Sun Feb 15 22:30:48 2015, TD, Julabo FL11006 Operating Manual
|
|
Sun Feb 15 06:12:00 2015, TD, AEV & CG, How to mount USB disk with NTFS
|
Mount external USB expansion disk with NTFS filesystems
with the (superuser) command:
su root
password:
mount -t ntfs-3g /dev/sdd1 /ntfs
[root@aidas1 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_aidas1-lv_root
50G 33G 15G 69% /
tmpfs 3.9G 4.3M 3.9G 1% /dev/shm
/dev/sda1 485M 61M 399M 14% /boot
/dev/mapper/vg_aidas1-lv_home
860G 201M 816G 1% /home
/dev/mapper/Data1-data10
1.8T 1.4T 309G 83% /data10
/dev/sdd1 3.7T 1.3T 2.4T 36% /ntfs |
Tue Feb 10 16:01:50 2015, Chris Griffin, Alfredo Estrade, High data rate - Pause/Resume 6x
|
06/02/15
A look at the data rate at which Pause/Resumes start to cause missing data.
Pulser settings:
Slow comparitor thresholds were altered using the ASIC4 page to artificially increase the data rate in the ASICs.
Default settings for all modules, apart from the changing slow comp threshold.
nnaida13+14 both functioning well. nnaida11+12 both have one noisy channel contributing to high data rate.
Echoing Alfredo's previous post, using the AIDA Good Events and AIDA Data Rate from the stats page as metrics, I found there to be no Pause/Resume items present in the data up to a Good Events rate of ~250-300 kHz and Data Rate of ~1-1.2 MHz.
Around this point the data shifts very quickly from containing no Pause/Resume items to having a rate of ~18 Hz, almost as a step function. At this point the Good Events and AIDA data rate sharply reach a maximum rate of 300 kHz and 1.2 MHz respectively. The rate of AIDA SYNC data items drops sharply at this point and decreases slowly with decreasing threshold.
Included are some plots showing this for each of the modules and some summary plots.
Further to the data rate at which the appearance of Pause/Resume items causes significant data loss, I looked at what happens when you break this threshold and then come back down, i.e. do the Pause/Resume items persist?
In short, no. Starting from a threshold of 64 and working down to 1, then taking the slow comparitor threshold back to a level at which no Pause/Resumes were present, the Good Events, AIDA SYNC and AIDA Data rates all went back to their original values within a couple of refreshes of the stats screen (and stayed as such thereafter). |
Mon Feb 9 11:52:52 2015, Patrick Coleman-Smith, [ How To ] Integrating AIDA with other systems
|
This document details how to integrate AIDA with other systems. |
Fri Jan 30 15:27:35 2015, Alfredo Estrade, [Analysis] 207Bi source (R61): check of monitor spectra 7x
|
A first look at the data from the 207Bi source (run described in previous elog entry, ID 27)
The main conclusions are (see description of spectra further bellow):
- NNAIDA11 and NNAIDA13 were running stable, even though NNAIDA11 had one channel with very high rate.
NNAIDA12 and 14 were running unstably with frequent instances of Pause/Resume. A possible explanation is
their higher data rates (due to a bad channel and noise, respectively).
- I think using only a window in time will not be sufficient to identify electron signals in the data.
This is a particular issue for the data of NNAIDA14, where there is a high noise and a energy threshold,
or some more ingenious condition, is likely required.
Plots were generated with the script in /Home/aestrade/AIDA/analysis/loopAIDAsort.cpp
Only a fraction of the 207Bi data was processed (corresponding to file R62_2).
+ Distribution of time-stamps
R61part_ts_dist_adc_hit.png: The spectra show the difference between the
time-stamp of a given ADC hit (ts_i) and the time-stamp of subsequent ADC
hits (ts_i+n):
Delta ts(i+n,i) = ts_(i+n) - ts(i)
So the first plot, for Delta ts(i+1,i), is the difference between each ADC
hit and the next ADC hit. The second plot is the ts difference between each
ADC hit and the second to next ADC hit, and so on...
The data mixes the spectra for all FEE cards and all ADC channels. One can
still see a clear structure with a peak at low values of Delta ts, and then
a second distribution up to Delta ts= 30*n usec. These is the time it takes
to loop through all 16 channels of the ADC (2 usec/channel), so is likely
the distribution generated by one channel is firing at a very high rate.
I'll make similar plots with conditions to mask out noisy channels and/or
pulser events to look for a value of the coincidence time-window to use to
reconstruct events.
+ Rates
R61part_rates.png: the spectra shows various rates (in Hz) as a function of
run time and of channel. The plots on the top are the rate of ADC hits (for
low energy range) of each FEE module, and one showing the rate of ADC hits
for the high energy range in all modules combined. The bottom row shows rate
per channel, and the rate of Information type hits.
some conclusions: NNAIDA11 and 13 show a flat rate, and as will be seen from other plots are very stable
during the run. NNAIDA11 has a larger rate than 13, but the difference is mostly due to a very high-rate
channel; the rate in most channels is consistent with a 100 Hz pulser for both.
NNAIDA12 and 14 show the largest rate that can peak at 35kHz, and looks quite unstable. These modules also
have a choppy run of the DAQ (many Pause/Resume). NNAIDA11 actually has similar rate to NNAIDA12 and 14,
but is still stable.
Both NNAIDA11 and 12 have one channel wiht very high rate compared to the
rest (rather than unusually noisy channel, could it be one that is always
above the threshold of the slow discriminator?).
+ ADC Rate with fine granularity
R61part_t1_hits_ts_adc.png: These spectra show the ADC hits (low range) vs time but with a higher binning
of the data (1 ms/bin). The one channel with a very high rate in NNAIDA11 and 12 is seen in red. Also that
the data readout from NNAIDA12 and 14 is frequently halted by Pause/Resume signals.
R61part_t1_hits_ts_adc_zoom.png: The second file hast the same spectra but zoomed in a narrow time window,
and one can see the hits from the pulser 10 ms appart (as vertial lines with hits in all channels for 2D
spectra). In between the pulser signals, as hits in individual channels, are hits from the source or from
noise. For NNAIDA14 this white noise was very high, so at the binning of 1ms/bin this spectra there are
many channels with hits in each time bin. I think it will be difficult to identify electron events from
such spectra using only a time window as requirement for coincidence.
+ Info Codes Rates
R61part_t1_hits_ts_info.png : The spectra show the rates of information words. The first plots are again
for a narrow section of the run (same as previous spectra). One can see the frequent sequence of
Pause/Resume for NNAIDA12 and 14. Also note discriminator data and ADC(high range) hits only come for
NNAIDA12 (we used very high value for discriminator threshold).
R61part_ts_info_fee.png: The figure shows the distribution of the different information codes for each FEE
module, but now for the full lenght of the run.
++ Sorted Root TTree fiels ++
All raw files of run R61 were processed with the 'beta' version of the Root
sort code for event reconstruction (/homes/npg/AIDAsort/ in DL PC), but only
up to the 'Calibration' step (no event reconstructino).
R61_207Bi_2_sort.root used for above plots.
Root tree saved here:
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_0_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_0_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_1_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_1_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_2_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_2_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_3_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_3_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_4_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_4_sort.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_5_calib.root
/Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_5_sort.root
A bug on the Root sort code was identified from this output: the code waits
for a SYNC100 pulse from *each* FEE card to update their corresponding
most-significant bits (MSB) for the timestamp, while one has to use *any*
SYNC100 pulse to update the MSB of all FEE modules. As a consecuence, a
(very small) fraction of the processed hits have the wrong time-stamp (off
by bit 28). |
|