<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear <span>Hċkan,</span></p>
<p><span><br>
</span></p>
<p><span>if I understand correctly, if the GEO address is not set via software this number is determined by the position of a module in the VME crate. Thus, even if you have access to the main.cfg of a certain measurement, it is still unclear what the right
GEO number is. The only chance to determine the right number for a module would be to either have the information where the module was (and how this translates to the GEO number) or to look into the raw LMD data and search for the data block of the module
in question. This is not very convenient, in particular as in our most people will use the DAQ and the corresponding software as a black box.</span></p>
<p><span><br>
</span></p>
<p><span>If this is correct, maybe it would be a good idea to make the GEO check optional (if this is possible within the code, i. e. by defining geom = -1 as a wild card).</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<p><span>Best greetings</span></p>
<p><span>Günter</span></p>
<p><br>
</p>
<div id="x_Signature">
<div style="font-family:Tahoma; font-size:13px"></div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Hċkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Samstag, 27. April 2024 15:41:21<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] UCESB - SPEC file for CAEN V767</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
Hi Günter,<br>
<br>
thanks for the V767 .spec file. I have added it, with some modifications:<br>
<br>
The 0x767a767a marker word does as far as I see in the V767 manual not <br>
come from the module, but I suspect is a barrier inserted in the nurdlib <br>
configuration. That should be matched outside the module in the unpacker.<br>
<br>
The geom bits MATCH would be used for unpacking to find the correct <br>
module, independent of how the module 'learnt' which number it should <br>
have. I removed the #ifdefs around that.<br>
<br>
I suppose that the 64-channel version always has a zero in bit 30 of the <br>
data words?<br>
<br>
I hope I managed to put the CHECK_COUNT and MARK_COUNT correctly, such <br>
that the lngth checking passes for actual data...<br>
<br>
Please test.<br>
<br>
Cheers,<br>
Hċkan<br>
<br>
<br>
<br>
On Fri, 26 Apr 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> attached please find a first version of the SPEC file for the TDC module we<br>
> added to NURDLIB a while ago.<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
> <br>
></div>
</span></font>
</body>
</html>