Fri., Dec. 30th

Felt like doing a little work today (it was more appealing than cleaning up my desk, I guess).

Samad emailed me a couple of days ago asking me to re-send my email with my instructions re: the power supply.  Did that.

Also got another email over the break from Michael Sprouse; replied to it.

Then I spent several hours working on my presentation on the COSMICi server structure for the workshop.  Added several slides illustrating the communication between components, and several more discussing some of the new modules/classes that need to be added.  

Thinking about rearranging the presentation to move the detailed run-through of the existing modules to later in the presentation.

Mon., Dec. 19th

Today all I did was come in and stop the data-collection run.  Copied the raw transcript file (17.4 MB) to Dropbox (in folder "C:\Users\Mike\Documents\My Dropbox\Server Code\logs 2011-12-19") so we can analyze it.

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.

Wed., Dec. 14th

The ECE department approved a $750 budget for students to buy needed parts & materials for the project.  I spoke to Donna to confirm that this was FSU money, and emailed the students that they could begin contacting her to process purchases and reimbursements.

Sonja emailed me that the Tektronix cables have arrived.  This will let us finish putting together the 3rd (and last, for now) detector apparatus.  I will get it this afternoon (and turn in my timesheet and sign my Spring paperwork at the same time).

Whenever Ray is ready, we can try removing that unwanted surface-mount capacitor from the FEDM board using the techniques we reviewed yesterday on YouTube.  This will then allow us to finish putting together the timing-sync input channel and then we can test it.  I think Ray is going to buy some more tools first.

Meanwhile, I will continue working on my slides for January's workshop on the Python server code.

LabView sent us a quote for 1-year renewal of the development suite license, for some reason.  I don't think we're going to renew since we haven't been using it anyway.

We picked up the Tektronix cable.  There was only 1 cable instead of 2 as I expected - was I wrong before about how many came in the package?  Still, that's enough to assemble our 3rd detector.  Ray said that's the only other part we need.  Went ahead and did receiving on the cable.

Trying to get through to Altera on the phone to see if they can tell us why the CLK_OUT output is only producing a 1.5V pulse (instead of 3.3V as we expected).  They were in a meeting, said try again after 5 pm.

I measured the resistance between the PMT_3 node and the other side of the J60 jumper.  It is 1kohm, which is the resistance on the pullup resistor.  This kind of suggests that the PMT_3 node is somewhere shorted to the +2.5V supply directly or through a small resistance.  (Maybe that's why this supply voltage is only +2.4V as measured, because the voltage is sagging due to a short?)  Also, across JP14 which directly measures the +2.5V supply, there is only 1 kohm resistance there as well.  There is also about 2 kohm resistance (a bit more) across J59, which is consistent with a short between PMT_3 and +2.5V, plus a 1kohm between +2.5V and ground, plus the 1kohm pulldown R102.

Aha, I directly measured the resistance between PMT_3 and pin 1 of JP14 which is the +2.5V supply, and it is only 10 ohms!  (9.63 ohms, to be precise.)  This accounts for the problematic DC offset.

I'm wondering if cleaning off the board with an electronics cleaning spray might help.  Ray says try it.  I sprayed the board down pretty good in the sink, and am letting it dry overnight.

I ordered some "shorting jumpers" (what I call "jumper bridges") from Digi-Key.  Pack of 100, to be delivered to my home address.  This will cut down on the number of jumper wires we need.

Going back to the presentation now.  For reference, here is the module hierarchy I sketched yesterday in OpenOffice Impress (based on my handwritten notes from a couple of years ago).

First draft of COSMICi server module hierarchy diagram.

Now I'll start describing the new components.  I'll go bottom-up.  I'll start with "flag" (at the lower-right corner of the hierarchy).

Finished a couple of slides on flag.py and the Flag class.  Next up: timestamp.

Tue., Dec. 13th

Some to-dos for today:

• [/] Re-solder SMA connector to OCXO board.
• [/] Re-test DC signal level (and received signal strength) on the PMT_3 (a.k.a. SyncPulse) signal node, to see if I've successfully moved the DC level closer to 0V (GND) by assigning all 12 of the input pins fed by that node to be LVDS inputs (which should have no pullup resistors on those ports).  This may not affect the signal strength though (that will probably require removing the extra capacitor, C148).

I should probably test the received signal strength on the actual PMT3 input to see if it differs from the TimingSig input (it shouldn't, but I should probably check to make sure).

Sometime soon, I also need to start working on my slides about the Python server architecture.

After re-testing the DC signal level of the PMT_3 node, there is no improvement since the board was re-burnt with the new pin assignments.

Emailed Sachin to see if he has any clue where the +2.5V DC bias might be coming from.

Talked with Ray about removing the capacitor C148.  My suggestion was to just use pliers to yank it off, or else try to push it aside with the tip of a hot soldering iron.  There are no other components that we need nearby it or on the other side of the board.  However, Ray wants to be extra careful since this is the only one of these boards that we have.  He is ordering a kit called "Chip Quik" ($135) that is supposed to be for safely removing surface-mount components.  Some of the tools in that kit might be helpful, although we already have the main things I think we would need... A soldering iron and a pick.  Anyway, no big hurry I guess.

In the meantime, maybe I'll work on my slides about the Python server to present to the students at the workshop in early January (which we still need to schedule).

Started working on the presentation slides.  Got as far as finishing the rough module hierarchy based on my notes.  Saved it in the Server Code folder on Dropbox.  Still need to go through the modules one by one explaining their main features.

Mon., Dec. 12th

Plan for today: Finish testing the new timing-sync datapath.

Juan says he can come by Friday morning to help with testing.

[.] Ask ECE if they can contribute to the project. --> Emailed Simon; follow up later.

Worked with Darryl and David for a bit to try to diagnose the timing signal problems.  It looks like the received signal is roughly 10x weaker than expected (instead of only the 4x weaker that we would expect from the replicated resistor & capacitor).  We checked some resistor values on the board (50 ohm and 1kohm) to make sure that these were not wrong, and they were correct.  We also checked the voltages on the outside of the GND and +2.5V pullup resistors, and they were correct.  We tried moving the input to PMT1, and there the signal was still about 2x weaker than expected.  We then tried hooking the scope directly to the DE3 output (with 50 ohm cable and 50 ohm input impedance) and this factor of 2x was still there.  For some reason the DE3 board is only outputting a roughly +1.5V amplitude pulse instead of +3.3V as we were expecting.  Perhaps it is expecting a 100 ohm cable?   Anyway, this output is a problem even if we remove the extra resistor/capacitor because our lowest threshold currently is only +1.5V.  However, we could move it a little lower.

Also, there is another problem which we didn't figure out yet, which is that the baseline logic level for the timing signal input seemed to be stuck at +2.5V, even when tied via the 1Kohm pulldown resistor to GND.  I have a theory that maybe there are pullup resistors by default on the 12 FPGA input pins that this node fans out to.  I'm going to try adding the pin assignments for the other pins to make sure this isn't the case.

The pins in question are (from the OrCAD schematic):

• TimingSignal (if it were separate from PMT_3):
         Legacy port      Pin pair             Current input port name
• TDCIN[12]:  K20/K19    --> TDCIN3[0]
• TDCIN[13]:  J21/J20       --> TDCIN3[1]
• TDCIN[14]:  H22/H21     --> TDCIN3[2]
• TDCIN[15]:  H20/H19    --> TDCIN3[3]
• TDCIN[16]:  G22/G21     --> TDCIN3[4]
• TDCIN[17]:  F22/F21      --> TDCIN3[5]  (only one assigned at present)
• PMT_3:
• TDCIN[22]:  W1/W2       --> TDCIN4[0]
• TDCIN[32]:  K1/K2        --> TDCIN4[1]
• TDCIN[33]:  J2/J3           --> TDCIN4[2]
• TDCIN[34]:  H3/H4         --> TDCIN4[3]
• TDCIN[35]:  H1/H2         --> TDCIN4[4]
• TDCIN[36]:  G1/G2         --> TDCIN4[5]

OK, added all those assignments to the New_with_Nios_trim revision of the Q:\COSMICi_FEDM project. Also added the corresponding input ports TDCIN3[5..0] and TDCIN4[5..0] to the top-level schematic COSMICi_FEDM_top13.bdf, although of course the only one of these that is actually used at present is TDCIN3[5] --> pf3[5].  This one tells us when the TimingSignal input crosses the lowest threshold (DAC#6).  TDCIN4[] is just a copy of TDCIN3[], due to the bug in the schematic, and is not useful.

The compile is running now.  It will take a while.  OK, that's finally done.

Burned new design into FEDM's EEPROM.  Hooked up timing sync cable and scope to redo the test of the received timing-sync signal.  However, I just noticed that the SMA connector that I had hand-soldered to the OCXO board came disconnected at some point in the last few minutes of fiddling.  Really, that board needs to be completely redesigned!  So I need to re-solder that connection before I continue.  No time today, so I'll do that tomorrow.

Wed., Dec. 7th

Ray and I went over to the Tech Transfer office to talk about the Cosmic Cube disclosure.  They are going to file for a provisional.  They also are going to pay for us to take the course offered by the Entrepreneurial Excellence Program run by the Tallahassee/Leon County Economic Development Council.

The GPS app is still running from last night, with the 25 ns setting of <traim_alarm>.  At some point today I'll stop it and look at the data.  I think it might have excluded all satellites throughout the run, but we'll see.

Today I want to Dremel down the fourth SMA connector, mount it on the TIMINGSIG pad, and hook up the boards and look at the output from the output-test stub for the new timing-sync datapath.

Dremeling done; boards are now connected together with one of the 6" SMA cables.

I think we should monitor the received signal because there is a bit of a capacitive voltage divider effect going on between TIMINGSIG and PMT3 since they are both AC-coupled but their back ends are wired together (due to the board design bug).  Also due to the bug, there is an effective 25 ohm termination resistance for AC signals, instead of 50 ohm, since both TIMINGSIG and PMT3 have terminating resistors.  Both of these could cause problems.  One fix would be to remove the terminating resistor or the coupling capacitor on PMT3.  Ray would prefer not to irreversibly change the board though, so instead, I'll look at the signal.

Aha, the DE3 isn't driving CLK_OUT presently (that line was commented out of the top-level Verilog file).  Fixing that.

Still not getting a signal.  Trying to send the clock also out to a GPIO1 header pin, GPIO1_CLKOUTp1.  Still nothing; I think I had problems trying to use the CLKOUT pins before, so let's try a normal pin, GPIO1_D[11] (which is pin #16 on header GPIO 1).  Still nothing.

Tried sending EXT_CLK to GPIO1_D[11] to make sure the pin works.  It does.

Now I'm examining the PULSE control signal.  Upon inspection of the code, it should become 1 after the first PPS edge is received.  It does.  So why no pulses?

It had occurred to me earlier in the day that there might be a timing error (although unlikely with the slow 10 MHz speed of the OCXO clock), but TimeQuest shows a very unconstraining fmax (371 MHz) for EXT_CLK, so it doesn't look like that's the problem.

Getting desperate, trying adding an intermediate wire named "pulse_out_100ns" inside the GPSapp.v Verilog module to see if that helps any.

D'oh, it looks like the trigger point was just off the scope display horizontally!  Boy, do I hate when that happens.  Don't know why I didn't catch that earlier.  Slapping myself.

Tue., Dec. 6th

Aarmondas and David finished up the timing sync datapath, we hooked it up to the appropriate input and to stream_pulse_out_test for testing, and are presently recompiling to see if the design still fits.

Meanwhile, I'm recompiling the GPS app from 50 to 25 ns (value of the <traim_alarm> parameter) so I can do another overnight run.  (Last night's run stopped at some point but still got a good 37 MB of data at 50 ns that I can analyze.)  Recompiled Quartus, rebuilt EEPROM programming file (Rev_A.jic), now burning it into EEPROM.

The fitter succeeded.  Some notes:

• Combinational ALUTs:     10,089 / 27,104 (37%)
• Dedicated logic registers:  25,747 / 27,104 (95%)
• M512s:                            188 / 202 (93%)
• M4Ks:                             144 / 144 (100%)
• The new module tsedge_datapath_v1_56 takes:
• Combinational ALUTs:   25
• Dedicated logic regs:       19
• Memory blocks:              none

It looks like the whole thing isn't getting synthesized, perhaps because we are only showing the low 8 bits of each word on output?  Need to look at size again after it is hooked up to new SOPC system.  Anyway, it is looking like it will probably be small.

I could hook it up and do a test, but I really should Dremel down a new SMA connector first so that I don't have to mess with any the existing ones.  Got the connector out, I'll dremel it tomorrow.

Mon., Dec. 5th

Spoke with Dr. O'Neal about the possibility of saving my Spring salary money for summer.  This would also have the advantage of freeing up my computer in the lab for someone else to use.  I need to check with ECE first to see if they still want me to teach Digital Logic in the Spring.

Need to check whether the new 50 ohm cables arrived from Tektronix.  The PO was dispatched.  I called Tektronix and it looks like they haven't received it yet.  [ ] Need to call Purchasing tomorrow and make sure it was sent out, find out on what date, and maybe ask them if we can get a PDF of the PO.

The CTU is still running from this run that I started last week.  That's good that it didn't crash!  I should take a look at the data.  This was a run with <traim_alarm>=200e-9.  (Next I should try 50e-9, and maybe 25e-9.)

Copied the current log files (200 MB) to log folder, "C:\SHARED\Server Code\logs 2011-12-05" & started a new run.