Mon., Mar. 12th

Things to maybe work on today/tomorrow:

• [ ] Get timesheet signed (turn in tomorrow). - Forgot to give it to Ray today before he left but can do it tomorrow.
• [.] More testing of GPS initialization code. - Some incremental improvements.
• [.] Maybe start developing the (very important) Timekeeper module. - Wrote file header.
• [ ] Maybe work some more on the automated startup-sequence code.  As things stand right now, we get through GPS initialization; but then we also need to wait for the FEDM to start up, and then start generating timing-sync pulses and sending them to it.
• [ ] Write up some notes for the students on things they can work on later in the week while I am away.
• [ ] Consider maybe starting a time data collection run before I leave town, so it can be running while I'm away.  One issue:  Will it keep running even if I'm logged out?

Juan came in and I showed him how to use Design Partitions.  He's going to try that for the FEDM design.

Aarmondas is here.

Tomorrow David & Darryl should be here, and we can all talk about the paper, maybe go over my latest round of markups which I sent to them over the weekend.

Remark:  Sometimes the GPS module eliminates all (or all-but-one) of the satellites from the solution.  This seems silly, since what then is it basing the "solution" on, and ?  In such cases, it might be good to do a hot restart.  Not sure yet; need more experience with this case.

Currently, if you invoke a restart manually, the server does not automatically turn on TRAIM and POSHOLD modes again, because it thinks they are already turned on.  Just fixed this in the case of TRAIM; haven't yet done it for POSHOLD - first need to subscribe to POSHOLD messages.

I wrote a header with a description for timekeeper.py, but haven't written any of the code for it first.  It will take some time to develop, b/c I have to research topics like how to do database interfaces in Python, how to draw graphs in TkInter, etc.

Before we start trying to archive real data in databases, it probably makes sense to work a little more on the startup sequence so that we can start runs in a more automated fashion, and also because the timekeeper will need to be informed when the start of the run actually happens - getting the startup sequence automated will help with that.

Let's get set up to do a full test run, so we can see where we are in terms of the startup sequence.  The GPS is already on and (last we checked) acquiring satellites.  So now, just:

1. Plug in PMTs.
2. Put cooling block on FEDM.
3. Power on CTU Wi-Fi.
4. Power on DE3.
5. Power on FEDM + fan.

At this point, the FEDM goes thru its startup (HOST_STARTING, DAC_LEVELS, HOST_READY) starts spitting out various operating messages:  NC_PULSES, FIFO_FULL, and real PULSE messages.  (There also are a couple of ACK and ERR scattered in there, in response to the WIFI_READY message from the EZURiO module.)  Initially, all the pulse messages start with 0,0 meaning that no timing-sync data has been received yet, until one sends the "HOST START" command to the CTU.

Now, really, as soon as the server gets HOST_READY from the FEDM, it is OK to go ahead and send the "HOST START" command to the CTU.  Now, where to implement that behavior?

By the way, should NC_PULSES also include the most recent timing-sync data?  Probably so.  OK, did that (loaded new FEDM FW via JTAG; not yet compiled into Quartus programming files in Q:\).

Should we also be putting timestamps on our FIFO_FULL messages?  It might be a good idea.  OK, that's done too.

I'm renaming PULSE message to CON_PULSE (given that coincidence filtering is turned on), since this makes this message the same length as FIFO_FULL and NC_PULSES, which makes for a prettier display.

OK, this is looking pretty good now.  Here's some FEDM output right after starting the CTU:


NC_PULSES,1618,3352941653,3352948689,115,68,203
FIFO_FULL,2392,3407048110,3,1
CON_PULSE,3186,3462552667,3,1,3462608072,2,(0,(2,2),5)
CON_PULSE,3186,3462552667,2,3,3462608072,2,(0,(1,4),2)
NC_PULSES,3286,3469543165,3469557613,93,70,200
FIFO_FULL,4738,3571045202,3,1
NC_PULSES,4848,3578734750,3578768009,94,58,206
CON_PULSE,6044,3662341109,3,2,3662381026,2,(0,(0,8),3)
CON_PULSE,6044,3662341109,2,4,3662381026,2,(0,(1,5),2)
NC_PULSES,6559,3698342174,3698393175,85,65,200
CON_PULSE,7476,3762445043,2,5,3762466512,1,(0,4)
CON_PULSE,7476,3762445043,1,3,3762466515,1,(0,2)
NC_PULSES,8491,3833398601,3833429056,112,78,200
NC_PULSES,10654,3984603078,3984613854,118,71,201
NC_PULSES,12294,4099247249,4099252435,105,65,204

Let's sanity-check the relative speeds at which the sync-pulse counter and PLL clock cycle counter are increasing.  

Currently, with the 375 MHz PLL clock in the CTU, its dual-edged counter is incrementing at 750 Mcps.  The low 18 bits will take 2^18 = 262,144 counts to roll over, which is 349.5253 us (i.e., we now have a 2,861.023 kHz frequency for the timing-sync pulses).

Meanwhile, my version of the FEDM is still clocked using a 200 MHz version of the PLL (students still are working on the speedup task), so the PLL counter increments every 5 ns.

OK, so let's look at the time interval between the first two NC_PULSES message above (each pair of NC_PULSES should have about the same time interval between them, if there's a steady rate of background pulses):

NC_PULSES,1618,3352941653,3352948689,115,68,203
NC_PULSES,3286,3469543165,3469557613,93,70,200

So, in terms of the timing-sync pulses, we have 3,286 - 1,618 = 1,668 of those.  Multiplying by 349.5253 us gives 583.0082 ms between the last pulses reported in each of these two reports.  (This implies that the approximate pulse rates on the three input channels was 160 Hz, 120 Hz, and 343 Hz respectively.)

In terms of the PLL cycles, we have 3,469,543,165 - 3,352,941,653 = 116,601,512 of those.  Multiplying this by 5 ns gives 583.0076 ms.

In other words, the figures are only different by only roughly 1.03 ppm, which is in line with the specified frequency calibration of the FEDM board clock, which IIRC was about 1 ppm.  The additional excess could come from other sources, such as the OCXO clock, whose frequency calibration is usually off by about 1.3 ppm.  (Actually, this result suggests that the FEDM board clock and the OCXO clock have their frequencies off in the same direction, so that the relative discrepancy is less than that for the OCXO by itself.)

Anyway, this result is a good validation test, and is evidence that the FEDM is still not missing any timing-sync pulses (if it even missed one, then the two times would be off by hundreds of ppm).

It would probably be a good idea at some point to do a diagnostic graphical display showing the rates of non-coincidence pulses on the three detectors as a function of time.

Perhaps I'll start an overnight data-collection run as a test?  Actually, let me wait and not do it right now - first I want to actually burn the new FEDM code onto the board.  Starting a Quartus compile in Q:\ to prepare the new programming files.

Of course, at this point, all of the FEDM messages are still unrecognized by the server, so before we can do anything with the FEDM data (like graphing it) we have to remedy that situation.  More server programming...

Juan & Aarmondas have been working on trying to get the design partitions working in the FEDM.  They ran into some fitting issues which Aarmondas is working on.