<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Yuri,
<div class=""><br class="">
</div>
<div class="">Here's what I've noticed so far with R1 M2.</div>
<div class=""><br class="">
</div>
<div class="">Prior to doing anything U1, U3, U4 always fail on register 17 on the first random pass (which means they passed the all zero test) register 18 sometimes passes, but mostly fails at varying random passes (most often at #1, but I saw a #5). U2 has
no issues.</div>
<div class=""><br class="">
</div>
<div class="">I de-cabled the L1C and inspected the data cable and pins. Nothing obviously wrong on the cable and the pins on J3 look good (which has the pins used by the register test). The bent pins as noted before on J2 are for U3 (since they're near the
edge it's the coretalking and gothit signals, possibly out6-out5).</div>
<div class=""><br class="">
</div>
<div class="">Swapping data cables had the same result, maybe slightly more passes on register 18, but always fails on 17.</div>
<div class=""><br class="">
</div>
<div class="">Moving to a different VSCM card (went from slot 3 connector 2 to slot 5 connector 2) had the same result as above.</div>
<div class=""><br class="">
</div>
<div class="">I tried changing the analog voltage from 2.7998 to 3.25 with no change (but none was expected).</div>
<div class=""><br class="">
</div>
<div class="">The module is now back to the previous cables.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">The fact that U2 always passes leads me to believe it isn't the data cable as the register test uses the same lines for all of the chips, if the cable itself it was bad we should see much more failures.</div>
<div class=""><br class="">
</div>
<div class="">I'm not sure what else I can try. Maybe another data cable or different VSCM setup?</div>
<div class=""><br class="">
</div>
<div class="">Do you know if R1 M2 has bad channels that need to be masked out? If not, then while definitely not a good situation maybe it can still be used as-is? Register 17 is for the kill mask to get rid of bad channels from the data stream and register
18 is the inject mask when injecting a pulse on a channel.</div>
<div class=""><br class="">
</div>
<div class="">One major issue I saw is that when I first pulled back the plastic covering there is a lot of icing/condensation on the barrel, see attached picture. There needs to be some purging in this area and/or better insulation.</div>
<div class=""><br class="">
</div>
<div class=""><img apple-inline="yes" id="3E8E3567-1279-4499-8F76-CFC6ADD4E753" src="cid:0893102F-F9A8-42AB-8B4B-D8989D716BFD@jlab.org" class=""></div>
<div class=""><br class="">
</div>
<div class="">I also reconfigured the MFC for the 86 subnet so this can now be used.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<blockquote type="cite" class="">On Apr 23, 2021, at 11:24 AM, Yuri Gotra <<a href="mailto:gotra@jlab.org" class="">gotra@jlab.org</a>> wrote:<br class="">
<br class="">
Hello Brian,<br class="">
<br class="">
Thank you for your help. Since DSG could not help us, labeling the cables we shared between Armen, Rafayel, and myself. It took some time from our workflow but we survived :-). We already integrated one of the 3 BMT sectors, connected the cables and all the
pedestals are good.<br class="">
What I saw was all 4 chips of SVT R1S2 failed the same way. The weird thing is that first time they failed on Monday, nobody touched the SVT during the w/e and they were good on previous Friday. It would be great if you could help us with debugging, you knowledge
of the FSSR2 chip is essential for this task. Once the issue is understoold and solved, we will proceed with connection region 2.<br class="">
<br class="">
On 4/23/21 11:06 AM, Brian Eng wrote:<br class="">
<blockquote type="cite" cite="mid:MN2PR09MB5515FE65A608B615955D60D7A5459@MN2PR09MB5515.namprd09.prod.outlook.com" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
Hi Yuri,<br class="">
<br class="">
I'm still on vacation but trying to catch up on emails, I'll try and troubleshoot R1 M2 some more on Monday night. There isn't really any pins specifically for registers 17 & 18 so it's a bit concerning that only those are failing. It's just shift in, shift
control, shift out and the bco clock lines to read the registers, but those are shared among all the chips on a module. So it being a bad cable or connector if 3/4 of the chips pass 100% and 1/4 chips pass on all but 2 registers would be strange indeed.<br class="">
<br class="">
For the MVT cables, is help still needed there? If so is there some sort of procedure that someone could follow or is it just a visual inspection of the cables? For the labeling do we need to provide the supplies or are they already on-site? Is there a naming
scheme to follow for them?<br class="">
</blockquote>
<span id="cid:7CD5196E-8E94-494A-AEC8-3DCDC1E71FA2@jlab.org"><gotra.vcf></span><br class="">
</blockquote>
<br class="">
</div>
</body>
</html>