Wed., Mar. 21st

Juan is here, and working on finishing up Michael Dean's changes to put all of the high-speed components into a single entity under the top-level schematic.

I am going to install my current Q:\ compile onto the FEDM.  The PLL frequency is 300 MHz.  The Fmax from this particular compile is 340.02 MHz.

Spoke to Ray about forthcoming goals:

Hardware goal:  Mounting hardware/brackets installed in CLC by April 7th, also electronics mounted in case, cooling system installed but not glued to the chip (thermal paste OK if easily removed).  We may need to wait a little longer than this to actually move the electronics box to CLC, in case we are still doing development work on the system.

Today I will continue working on the server-side code to support the FEDM.  First trying to see if my changes to recognize the FEDM messages are working.

[ ] Still need to fix the GPS Manager so that it automatically turns POSHOLD mode back on after a manual reset.

The GPS is acting a little odd today - it keeps eliminating all satellites from the timing solution.

Having an issue that we're not seeing the HOST_STARTING message from the server b/c it's sent before the Wi-Fi is ready?  Let me try again.

For some reason, the UART bridge connection from the FEDM board keeps closing itself shortly after it opens.  Not sure how.  Maybe a buffer overflow in the bridge implementation in the Wi-Fi firmware, caused by too much data being streamed to the Wi-Fi board before the bridge is fully established?

Having trouble even getting that Wi-Fi board (node #1) to establish a connection now.  Wonder if the script got erased?  That happens sometimes.

OK, the disconnects were a server bug.  Fixed that.  Now I'm having another problem: Flaky connection from the OCXO, which has come unsoldered again, for like the 3rd time.  We   However, by holding it in place manually I managed to get some pulses.  Here are a couple of adjacent output lines from the period during which the OCXO output seems to have been connected:

NC_PULSES,26595,23828622948,23828752409,118,78,203
NC_PULSES,28763,24055954150,24056162251,135,84,201

Let's just look at the two time-reference data points (first two fields of each line).  The difference in sync pulse counts is 28,763 - 26,595 = 2,168.  Divided by the new nominal sync pulse frequency of 2,861.022,949,218,75 kHz gives a time interval of 0.757,770,922,67 seconds.  Meanwhile, the difference in PLL clock cycle counts was 24,055,954,150 - 23,828,622,948 = 227,331,202.  Dividing that by the current PLL clock frequency of 300 MHz also gives 0.757,770,673 seconds.  The two clocks (OCXO vs. FEDM's TCXO) are thus out of calibration with each other by only about 0.33 ppm; not too shabby.

So, this verifies that the PLL cycle counter on the FEDM really is working at 300 MHz in the current compile, so that's good.  However, there were a few outputs from the pulseform-capture datapath that seem to have got corrupted somehow, e.g.:

Wed Mar 21 17:19:32 2012 + 697 ms: < CON_PULSE,0,0,1,1,1026250529,3,(0,(1,(2,6),7),7)

Wed Mar 21 17:19:32 2012 + 698 ms: < CON_PULSE,0,0,3,1,1026250530,4,(0,(0,(1,(3,5),8),6),11)

Wed Mar 21 17:19:32 2012 + 699 ms: < CON_PULSE,0,0,2,1,1026250531,3,(0,(1,(1,11),6),3)

Wed Mar 21 17:19:32 2012 + 701 ms: < CON_PULSE,0,0,2,2,1026250531,2,(0,(443296,7),4)

What happening here?  First, in the first 3 lines, we see a nice-looking shower event where all three detectors cross the 1st threshold (-200 mV) within 2 PLL clock cycles (i.e., 6.7 ns) of each other, and all of them cross 3 or 4 thresholds with roughly similar-looking patterns.  Then, we get a spurious 2nd pulse from channel #2 that supposedly starts in the very same clock cycle as the previous one (how is that even possible?), and only crosses 2 thresholds, with an anomalous time delta (1.48 ms) between crossing the first and second threshold (this could very easily be the time delta between two completely separate pulses).  Something is clearly screwy there!  And this same kind of glitch seems to happen during most of the other shower events.  I didn't notice these kinds of glitches when we were running at 200 MHz, so possibly there is some kind of timing issue at work.

Hm, I wonder if I should add a synchronizer chain when feeding the low-speed data consumer's (cs_combine's) handshake-acknowledge signal back into the high-speed front-end pulse-capture module?  Without that, there are possible metastability issues that could come into play, which could conceivably destabilize the updating of the pulse-cap module's high-speed state machine temporarily, possibly causing the spurious extra outputs.  This might be worth a try.  However, the day's about over so we'll worry about that tomorrow.

The ME students came by at one point today and took some more measurements for the chassis construction.