[dsg-hallb_svt] Debugging SVT DAQ

[Brian Eng]

Hi Yuri,

Here's what I've noticed so far with R1 M2.

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.

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).

Swapping data cables had the same result, maybe slightly more passes on register 18, but always fails on 17.

Moving to a different VSCM card (went from slot 3 connector 2 to slot 5 connector 2) had the same result as above.

I tried changing the analog voltage from 2.7998 to 3.25 with no change (but none was expected).

The module is now back to the previous cables.



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.

I'm not sure what else I can try. Maybe another data cable or different VSCM setup?

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.

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.

[cid:0893102F-F9A8-42AB-8B4B-D8989D716BFD at jlab.org]

I also reconfigured the MFC for the 86 subnet so this can now be used.


On Apr 23, 2021, at 11:24 AM, Yuri Gotra <gotra at jlab.org<mailto:gotra at jlab.org>> wrote:

Hello Brian,

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.
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.

On 4/23/21 11:06 AM, Brian Eng wrote:
Hi Yuri,

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.

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?
<gotra.vcf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/dsg-hallb_svt/attachments/20210427/e8ba406b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icing.JPG
Type: image/jpeg
Size: 2729501 bytes
Desc: icing.JPG
URL: <https://mailman.jlab.org/pipermail/dsg-hallb_svt/attachments/20210427/e8ba406b/attachment-0001.jpe>