Friday, December 16, 2011

Fri., Dec. 16th

I have to leave a little earlier than usual today (5 pm) to pick up Colin, but here are some things I'm going to try to work on in the meantime.

  1. [ ] Do a test with all 3 detectors.  I finished assembling the 3rd detector and placed it over on the side of the room, about 10-15 feet away from each of the other two detectors.  (Really we'd like a somewhat larger separation, but this is OK for an initial test.)  I need to re-hookup the FEDM (which was washed on Wednesday) to do that test.
  2. [/] I also need to re-test the resistance between the +2.5VCC node and the PMT_3 (SyncPulse) internal node on which we are trying to receive our timing signal.  On Wednesday it was 10 ohms but it may be better now after the cleaning.  (It's not.)
  3. [ ] I need to check the voltage distribution on Samad's board.  First, double-check to make sure there are no shorts between different voltages.  After that's checked and the voltages are all verified, I can try powering the whole system through it.
  4. [ ] It might be a good idea to also re-test the bad DAC (#5) since it might conceivably have been healed by the cleaning.
  5. [ ] I can continue working on my slides for the workshop on the Python server.
Let's start with #2 since that is the easiest to set up.  JP14 pin 1 (top, +2.5VCC) <--> J59 pin 1 (top, PMT_3) = 9.54 ohms resistance.  Nope, still bad!

Continuity-tested Samad's board.  One of the grounds was disconnected from the others - bridged that with a solder blob. The +12V was shorted to ground through a loose fleck of metal - fixed that.  After those changes all connections were good.

Next, plugged in the power supply and tested voltage levels on the output pin headers.  The connector is still not very reliable - had to push down on it to make a good connection on all pins (like I've been having to do on the DE3 board itself).  After that, all voltages were correct.  What to do about bad reliability of connector?  Buy a new power cable?  Not sure.

Used 8" Adafruit F-F jumper wires (4 black = GND, 4 orange = +3.3V, 1 red = +5V, 1 green = PWR_N) to connect power from Samad's board to the DE3.  The DE3's power switch will thus turn on the power supply for the entire system.

Now let's try powering up the CTU through Samad's board.  No dice.  Maybe I need the +12V supply?  No, looks like it's just that the power connection to Samad's board (the mating between the connector and the jack) is EXTREMELY delicate.  It's very difficult to get it to make a solid connection without holding it in place.  (It's kind of just like the problem I have with my stupid phone when I try to plug it into the car charger.)  Not sure how we can fix this, except by buying a new power supply with a whole different kind of connector.  Or else, run jumper wires between the connector and the jack?  (It's kludgey, but it might work.)

Tried powering both CTU and FEDM through Samad's board simultaneously.  The Wi-Fi modules failed to establish a connection.  Thought at first they might be interfering with each other; tried turning off the FEDM's WiFi module but the CTU's still failed to connect.  Checked the +5V node and found its voltage was sagging significantly; it was about 4.4V instead.  I infer that the particular +5V wire coming out of the power supply that we're using is probably not itself rated to supply the full current we're drawing.  It looks like we are going to have to identify and procure a new power supply that is specifically rated to provide the full current we need at each of the voltage levels we use.

I next tried a test with the new detector (case #3, not yet labeled) connected to the SMA#3 input (the one labeled PMT#4), but the board failed to detect any pulses on it.  We checked its output on the scope, and sure enough it is producing pulses, several hundred mV big.  So there is something wrong here.

Aha, after failing to detect pulses from the Tektronix also, I realized that I had simply forgotten to reattach the +2.5V DC bias jumper at J64 (PMT_4 internal node, PMT4 footprint, input we're calling "SMA#3").  With it reattached, everything is working as expected.  Not all of the 2-way coincidences are also 3-way coincidences, but maybe 1 out of every 5 or 10 of them are.  Perhaps I'll leave this running over the weekend so we can collect some serious data on this.

No comments:

Post a Comment