> f) However, I found that the frontend program still consistently failed with this error when the trigger rate
> was above the maximum sustainable:
> 
> Deferred transition.  First call of wait_buffer_empty. Stopping run
> [feov1725MTI00,ERROR] [v1725CONET2.cxx:685:ReadEvent,ERROR] Communication error: -2
> [feov1725MTI00,ERROR] [feoV1725.cxx:654:link_thread,ERROR] Readout routine error on thread 0 (module 0)
> [feov1725MTI00,ERROR] [feoV1725.cxx:655:link_thread,ERROR] Exiting thread 0 with error
> Stopped chronobox run; status = 0
> Segmentation fault

I sort of 'fix' this problem.  There is some sort of problems between the V1725 readout	thread and the system call
to esper-tools to stop the run.  Some collision between the system resources for these two calls causes the readout
thread ReadEvent call to fail.  I 'fix' the problem by adding in the end_of_run part a 500us pause of the readout
threads before I make the system call to esper-tool.  

Odd.  In principle I think that the system calls and the readout threads are running on different cores.  So not
clear what the problem was.  Should figure out better diagnosis and fix problem properly.

The ChronoBox latest FW is loaded. Let tme know if this is what the chronobox should look like in term of registers.

Are we monitoring the PLL Lock Loss  (odb: /DEAP Alarm ?)

Here is the dump of the 5 first sync triggers without any physics trigger behind.

1 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 
2 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 
3 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 
4 0x830b577 0x17d7855 0x6b33d22 0x6b33d22 8.992791 

1 0x830b581 0x2faf097 0x535c4ea 0x535c4ea 6.992792 
2 0x830b581 0x2faf097 0x535c4ea 0x535c4ea 6.992792 
3 0x830b581 0x2faf095 0x535c4ec 0x535c4ec 6.992792 
4 0x830b581 0x2faf095 0x535c4ec 0x535c4ec 6.992792 

1 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 
2 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 
3 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 
4 0x830b587 0x47868d7 0x3b84cb0 0x3b84cb0 4.992792 

1 0x830b5a1 0x5f5e119 0x23ad488 0x23ad488 2.992794 
2 0x830b5a1 0x5f5e119 0x23ad488 0x23ad488 2.992794 
3 0x830b5a1 0x5f5e117 0x23ad48a 0x23ad48a 2.992794 
4 0x830b5a1 0x5f5e117 0x23ad48a 0x23ad48a 2.992794 

1 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 
2 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 
3 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 
4 0x830b5ab 0x7735959 0xbd5c52 0xbd5c52 0.992795 


With the physics triggers:
1 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
2 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
3 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
4 0x830b5c1 0x1834497f 0xeffc6c42 0x100393be 21.493591 
1 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
2 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
3 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
4 0x830b5d3 0x1834abb5 0xeffc0a1e 0x1003f5e2 21.495601 
1 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
2 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
3 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
4 0x830b5dd 0x18350d7f 0xeffba85e 0x100457a2 21.497603 
1 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
2 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
3 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
4 0x830b5e3 0x183585e7 0xeffb2ffc 0x1004d004 21.500068 
1 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
2 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
3 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
4 0x830b5ed 0x1a10bb9b 0xee1ffa52 0x11e005ae 23.991535 
1 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
2 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
3 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
4 0x830b5fb 0x1a111f65 0xee1f9696 0x11e0696a 23.993578 
1 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
2 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
3 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
4 0x830b607 0x1a118115 0xee1f34f2 0x11e0cb0e 23.995577 
1 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 
2 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 
3 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 
4 0x830b611 0x1a11e2c7 0xee1ed34a 0x11e12cb6 23.997577 


The ZMQ0 banks:
#banks:5 Bank list:-ZMQ0W200W201W202W203-
Bank:ZMQ0 Length: 40(I*1)/10(I*4)/10(Type) Type:Unsigned Integer*4
   1-> 0x000a5f1c 0x000000c4 0x00000001 0x0ebd5273 0x00000001 0x00010001 0xffffffff 0x00000000 
   9-> 0xffff0000 0x00000000 
------------------------ Event# 10 ------------------------
#banks:5 Bank list:-ZMQ0W200W201W202W203-
Bank:ZMQ0 Length: 40(I*1)/10(I*4)/10(Type) Type:Unsigned Integer*4
   1-> 0x000a5f1d 0x000000c5 0x00000001 0x0ebd5279 0x00000001 0x00010001 0xffffffff 0x00000000 
   9-> 0xffff0000 0x00000000 
[dsproto@ds-proto-daq dsproto_daq]$ 

I have done a couple longer tests of the DAQ setup.  The runs were done with a high trigger rate of ~60Hz, with
the V1725 asserting their busy to throttle the trigger.

I found that after a couple hours (~5hours) that we would no longer be getting ZMQ packets from the chronobox. 
 You can see this with error message like

15:29:04.092 2019/04/11 [feov1725MTI00,ERROR] [feoV1725.cxx:1033:read_trigger_event,ERROR] Error: did not
receive a ZMQ bank.  Stopping run.
10:26:37.158 2019/04/11 [mhttpd,INFO] Run #657 started

If I start a new run I am still missing ZMQ packets.  However, if I restart the frontend program (and hence
re-initialize the ZMQ link), then the chronobox does start sending triggers again.  So it may be more of a
problem with the ZMQ setup in the MIDAS frontend.  Needs more investigation.

The DAQ seems to be ready for tests with proto-0 tomorrow.  

I had to invert the first busy input in order to get chronobox to produce triggers.  I modified the setup script

setup_chronobox.sh

so this is now the default.  Not sure why necessary.

Another interesting fact; it seems the chronobox only asks for a DHCP IP when it first boots.  I think that
chronobox and ds-proto-daq were rebooted at the same time; ds-proto-daq dhcp server was probably not running
when chronobox asked for IP.  chronobox got IP fine when it was power cycled.

Tried to get laser sync signal into chronobox (clkin1 input), apparently all triggers dropped by chronobox

Problem is that the same now happen also with the regular setup where the clkin1 signal is taken by the dual timer.

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 problem reported in ID 117 is somehow fixed this morning.