Checking again Marco's A3818:
- Port #2 (third from top of card) is acting up.
- change the SFP makes no difference.
- Symptoms: Get stuck on Rx/Tx.
- Need more investigation...

Added pair of 10TB hard-drives in raid-1 to ds-proto-daq.  MIDAS data files will get written to this raid volume.

[dsproto@ds-proto-daq tmp]$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        9.1T  180M  8.6T   1% /data
[dsproto@ds-proto-daq tmp]$ cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdc1[1] sdb1[0]
      9766435648 blocks super 1.0 [2/2] [UU]
      [>....................]  resync =  0.9% (88214784/9766435648) finish=4372.8min speed=36886K/sec
      bitmap: 73/73 pages [292KB], 65536KB chunk

unused devices: <none>

I added javascript webdisplay of the V1725 waveforms to the Darkside setup.  You can see the waveform display here:

https://ds-proto-daq.triumf.ca/CS/webdisplay

You can also see the webdisplay that comes built into the JSROOT webserver here:

https://ds-proto-daq.triumf.ca/rootana/

For Pierre: I went through and reset the baselines for all the channels.

Wrong MAC address fixed in CERN network setting, now the machine is visible from external network too:

From CERN network (even laptop) can connect by 

ssh -XY dsproto@ds-proto-daq2.cern.ch.  (same password as local account in ds-proto-daq)

From ds-proto-daq can also connect by:

ssh darkside01

That is to say that the two network card are now associated to two different names.. but the "real" name is still darkside01.

(will fix).

 enjoy

The analysis server from Roma (darkside01) is now connected to the local network. It is not yet connected to CERN.

There are 2 network ports on the rear of the machine:
* The port labelled "1":
 * MAC: 9c:71:3a:22:d5:62
 * Name: enp2s0f0
 * Configured for DHCP
 * Connected to local switch
 * Assigned IP 192.168.1.10 by ds-proto-daq
* The port labelled "2":
 * MAC: 9c:71:3a:22:d5:63
 * Name: enp2s0f1
 * Configured for DHCP
 * Should be connected to CERN network

I have set up password-less ssh between ds-proto-daq and darkside01. 

There are 3 problems connecting to the CERN network:
1) The long cable that was created does not work. I tried using it to connect ds-proto-daq to socket 0001/06 (i.e. the socket ds-proto-daq is normally connected to) and there is no link light - the cable is broken.
2) Socket 0001/07 does not seem to be operational. I tried connecting ds-proto-daq to socket 0001/07 using the cable we know works, and there was no link light. Either CERN have disabled the connection intentionally, or it is broken.
3) When I used the good cable to connect to the good socket (0001/06), CERN claimed the machine was unregistered. Marco told me that the interfaces have MACs 9c:71:3a:22:d6:4[ab] (rather than 9c:71:3a:22:d5:6[23]), so presumably the wrong MAC addresses were registered with CERN.

So, we need to register the correct MACs, fix the cable, and either get 0001/07 working or connect to a different socket.

The cable has been fixed. Socket 0001/007 is still not active.

Run 1050

Gas pocket: ON (unknow)

Fields: drift 200 V/cm, extraction 2.8 kV/cm

Threshold: 1000 ADC below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  245 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1051

Gas pocket: ON (unknow)

Fields: drift 200 V/cm, extraction 3.78 kV/cm

Threshold: 1000 ADC below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  260 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1052

Gas pocket: ON (thinkness 7mm)

Fields: drift 500 V/cm, extraction 3.78 kV/cm

Threshold: 1000 ADC below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  245 mbarg

SiPM HV: 65 V

Number of events: 10k

Stopped. Problem with DAQ

Run 1090

Gas pocket: ON (thinkness 7mm)

Fields: drift 200 V/cm, extraction 3.78 kV/cm

Threshold: 1000 ADCc below baseline

Trace length: 100us total, 50 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  220 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1091

Gas pocket: ON (thinkness 7mm)

Fields: drift 200 V/cm, extraction 3.78 kV/cm

Threshold: 400 ADCc below baseline

Trace length: 100us total, 50 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  220 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1092

Gas pocket: ON (thinkness 7mm)

Fields: drift 200 V/cm, extraction 3.78 kV/cm

Threshold: 1000 ADCc below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  220 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1093

Gas pocket: ON (thinkness 7mm)

Fields: drift 500 V/cm, extraction 3.78 kV/cm

Threshold: 1000 ADCc below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  220 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1094

Gas pocket: ON (thinkness 7mm)

Fields: drift 200 V/cm, extraction 2.8 kV/cm

Threshold: 1000 ADCc below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  220 mbarg

SiPM HV: 65 V

Number of events: 10k

Run 1095

Gas pocket: ON (thinkness 7mm)

Fields: OFF 

Threshold: 1000 ADCc below baseline

Trace length: 200us total, 100 us pre-trigger

Threshold extend:  5x16 = 80ns

TPC Pressure:  220 mbarg

SiPM HV: 65 V

Number of events: 10k

17:30

Took a set of IV curves using 0.5V steps from 30-50V and 0.05 steps above 50V.

Curves all look as expected, although reducing the step size makes the breakdown voltage harder to see on the plots.

Will use 0.02V steps in future.

Data can be found on dsproto machine at: /home/dsproto/online/dsproto_sy4527/ivdata_191111

Summary plot attached to this entry.

19:15

Refilled outer dewar for 10 mins

I have set up automatic copying of data from ds-proto-daq to darkside01, using the lazy logger.

There are 2 lazy logger channels set up - one for lz4 files and one for gz files. It will take some time for all the files to copied over. Note that lazy logger writes a message into the midas log for every file that it copies. The lazy logger channels can be started from the Program page like all the other midas-related programs.

Once files have been copied to darkside01 (by lazy logger) and to EOS (by Pablo/Edgar) we can delete files from ds-proto-daq. We will probably not be able to do this until tomorrow (copying is quite slow).

This morning tried to get some data with Vbias=65 V, which seems better for the SiPM in MB1.

Busy handling still erratic.

At the beginning it seemed to work fine with busy_invert off and busy_enable on.

After a while (maybe after the first busy signal?) the only work around seemed to be to disable the busy_enable

The CAEN VME crate now gets its IP address from the ds-proto-daq DHCP server. To do this, I set the IP address of the crate to 0.0.0.0 (using the front panel interface) then reset the crate (not just a power cycle - pressing the reset button is required).

I am now able to ping the crate, but am NOT able to load the webpage it is supposed to serve (I just get a "connection refused"). I can't see any configuration settings that would disable the webpage or would cause it to be served on a non-standard port. I may have missed something though.

Pierre and I got the CERN proxy setup for the Darkside prototype.

Using your CERN single-sign-on identity, you should be able to login to this page

https://m-darkside.web.cern.ch/

and see our normal MIDAS webpage.

The CERN server is proxying the port 80 on ds-proto-daq.  You can also see all the other services through the
same page:

elog:
https://m-darkside.web.cern.ch/elog/DS+Prototype/

chronobox:
https://m-darkside.web.cern.ch/chronobox/

js-root:
https://m-darkside.web.cern.ch/rootana/


_________________________________

Technical details

1) We followed these instructions for creating a SSO-proxy:

https://cern.service-now.com/service-portal/article.do?n=KB0005442

We pointed the proxy to port 80 on ds-proto-daq

2) On ds-proto-daq, we needed to poke a hole through the firewall for port 80:


firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="188.184.28.139/32" port
protocol="tcp" port="80" accept"
firewall-cmd --reload

[root@ds-proto-daq ~]# firewall-cmd --list-all
public (active)
...
	rule family="ipv4" source address="188.184.28.139/32" port port="80" protocol="tcp" accept

This firewall rule is pointing to some particular IP that seems to be the proxy side of the server:

[root@ds-proto-daq ~]# host 188.184.28.139
139.28.184.188.in-addr.arpa domain name pointer oostandardprod-7b34bdf1f3.cern.ch.

It is not clear if this particular IP will be stable in long term.

3) We needed to modify mhttpd so it would serve content to hosts other than localhost.  So changed mhttpd
command from 

mhttpd -a localhost -D

to 

mhttpd -D

Found that the Trigger out from the CB is on output1
Trigger / Not used
Clock   / Not used

Set frontend to use NIM in/out instead of TTL as there is a nice
NIM-TTL-NIM adaptor CAEN Nim module available

/home was getting very full on ds-proto-daq, so I moved the history files onto the /data disk. There is now a symlink from ~/online/history to /data/dsproto/history/.

The chronobox isn't serving the human-interactive webpage that should be visible at https://m-darkside.web.cern.ch/chronobox/ - it responds with "File not found". Oddly, it is still responding to API calls at /read_var, /write_var etc.

So shifters can still change between laser/noise/physics runs using the "Run type" page at https://m-darkside.web.cern.ch/?cmd=custom&page=Run%20type (which uses the API), but can't as easily monitor / sanity check the chronobox behaviour.

In the first instance, I think it would be useful to power-cycle the chronobox. If that doesn't work, I'm not sure how to proceed.

People: Edgar, Simone

Installed differential to single-ended converters in VME crate, and turned crate back on. elog:47/2

Channel count in the converters is 0 to 15 starting from the low end. Wired according to:
left board, channels 0..15 = PDM slot 1..16
right board, channels 0..8 = PDM slot 17..25

N.B. V1725 board #0 logic level is set to TTL (boards #1, #2, #3 to NIM) elog:47/3

In ODB / Equipment / V1725_Data00 / Settings /  set Channel Mask to 0x1555 for all V1725 boards (enables channels 0 2 4 6 8 10 12)
(board 0 receives 7 PDM inputs, boards 1,2,3 receive 6 PDM each)

In https://ds-proto-daq.cern.ch/chronobox/ , set Enable Channel [ch_enable] = 0x3F3F3F7F , Channel Assignment [ch_assign] = 0x00393340.
9 central PDM's assigned to "top" group, external PDM's assigned to "bottom" group elog:47/1

Wiki instructions with the script to get the CDM back into a sensible state seem outdated. The variables seem fine, though ... 
[dsproto@ds-proto-daq ~]$ esper-tool read 192.168.1.5 cdm ext_clk
[49999632]
[dsproto@ds-proto-daq ~]$ esper-tool read 192.168.1.5 lmk pll1_ld
[1]
[dsproto@ds-proto-daq ~]$ esper-tool read 192.168.1.5 lmk pll2_ld
[1]

> V1725 board #0 logic level is set to TTL (boards #1, #2, #3 to NIM) 

There was a problem with CMakeLists for the V1725 driver, and the frontend was only connecting to 1 board. This is now fixed, and all the boards should have the same (TTL) logic level.

I modified the analyzer so that it shows data from all four modules.

I find that there is evidence of corruption of the V1725 ADC data on a couple channels.   You can see an example of a waveform with corruption in the attachment.  You see that there seems to be a bunch of fluctuations of exactly 16 
ADC counts, which seems unphysical.  So far I see this problem in these channels:

module 0, ch 0
module 0, ch 1
module 0, ch 13
module 1, ch 4
module 3, ch 6

I saw corruption similar to this on the V1730 readout.  CAEN does have a scheme for ADC calibration (by poking a register), which worked well for the V1730.  I thought that I implemented this ADC calibration for the V1725, but I might 
have messed it.  I'll look at this again.