Mon., Apr. 9th

Juan came in and re-did most of the needed work on the top-level file, and shared it with M. Dean and I in his Dropbox folder.  Juan and I are planning to meet at lab at 1:00 pm on Wednesday to finish it up (I think the old stuff in the top-level file still needs to deleted) and go through the design carefully and maybe get to the point of doing a compile.  With luck, maybe we'll be able to get a new Fmax value before the final presentation...  (Scheduled for 3:00 pm on Wednesday.)

David and I reconnected the electronics and reprogrammed the Wi-Fi boards to use the COSMOS router, and set up probes to to us look at the low byte of the data word for channel 0, so now we can generate scope screenshots that show input pulse and output data, vaguely similar to the ones we had earlier, for possible inclusion in the paper.  We still want to run this by Dr. O'Neal tomorrow to make sure these kind of scope shots are OK with him.

UPDATE 4/16:  After going over the new scope screenshots, Dr. O'Neal agreed that they are not very informative, so we will probably not bother including them in the paper.

Fri., Apr. 6th

The Design Fair demo yesterday went more or less as planned, although several steps took longer than I expected - loading everything into the car at FSHSRC without help took a solid hour, and setting everything up at the Design Fair took an hour and a half even with students' help.  Also, I forgot to include a much-needed lunch break, which I ended up taking between 12:30 and 1.  However, despite these additional delays, we were still all up and running by about 2:30 pm.  Everything pretty much worked as expected, although the GPS antenna position we used (just outside door in middle of connector) did not have as much of a sky view as I was hoping because the antenna cable was not long enough.  As a result the GPS only got 0-2 satellites, but it did get at least 1 or 2 most of the time.  David measured the antenna coordinates and I updated the sitedefs.pl file with them so that POSHOLD mode would give valid times.

One thing we forgot to do was adjust the size of the window for identifying coincidence events for the new faster clock speed (currently 300 MHz instead of 200 MHz).  This, together with the wider separation of the detectors at the Design Fair (compared to the lab) may account for why we were seeing fewer showers at the Design Fair than we were in the lab - we effectively filtered out shower events at low angles, because the number of clock cycles that passed between when the shower hit one detector vs. another may have been larger in some cases than the window size (10 cycles) we are currently using in the FEDM firmware.  The window size amounts to 33 ns, which theoretically should be adequate to catch all near-lightspeed shower fronts, however, some extra slop might be needed in case one detector happens to catch particles that are closer to the front edge of the pancake than the ones caught by another detector.  Anyway, we need to remember to go back and adjust this parameter, especially after we get the speed up to 500 MHz.

It would also be a good idea to verify on a scope that the cable delay is really the same on all 3 cables - say send a pulse from a signal generator down all 3, look at the traces side-by-side on the scope.

After I left the lab Wednesday night, the ME students succeeded in getting the new Peltier cooler and fan mounted over the FEDM.  We still have not tested with the Peltier cooler under power; one reason is that we still need to do some experiments to determine the proper power level for it (so as to not over-cool and cause excessive condensation), and also a new power supply subsystem still needs to be designed to supply it appropriately.

Wednesday night the ME students also mounted Samad's existing power distribution board, since he had run out of time to make another board.  It is bolted down on one end, with a rubber stopper holding up the other end.  We can go ahead and try using Samad's board to power the system as soon as he re-routes that one pin (the green "supply on" pin) which is a change that can be patched in by hand, and find or make a longer cable (say 15") to run from the power board to the DE3.  I submitted a couple of RFQs for this cable to some custom shops.  Also, someone needs to make power cables for the detectors, with an appropriate connector at each end (barrel plug at the detector, two jumper wires with female sockets at the power distribution board).

Let me try to make a (more or less) methodical to-do list of all the various miscellaneous things that need to be done to finish up the hardware/gelware/firmware.  Many of these tasks require EE/ME collaboration.

• [ ]  Buy a new GPS antenna with a much longer (100'?) antenna cable for installation at CLC.  (Check with Reed to make sure this length will be long enough.)
• [ ]  Measure absolute signal propagation delays on all three of the 50 ohm coax BNC cables running from the detectors to the FEDAM.  (We can just measure them one at a time for end-to-end delay using a signal generator, splitter, and scope.)
• [ ]  Buy or make a new longer (15"?) power cable assembly from Samad's board to DE3 board.
• [ ]  Make some custom cable assemblies (~20' length?) for powering the detectors from Samad's board.
• [/]  Also wire up power from Samad's board to the GPS, CTU Wi-Fi board, and FEDAM.
• [ ]  Design & build new OCXO board.  (Remember to include a power capacitor this time.)
• Designed, but still needs to be taped out for fab.
• [ ]  Experimentally determine proper voltage level for powering Peltier cooler to achieve desired chip temperature with minimal condensation.
• [ ]  Design & build a supply that delivers the desired voltage to Peltier cooler with adequate current.
• [ ]  Cut suitable hole (s) in plastic cover for cabling & ventilation.
• Or, cables can go thru a hole circular-sawed through the platform.
• [ ]  Need a plastic tube to go down to main cooling fan from top of cover.
• [ ]  Maybe also install an air outflow fan or fans.  Regular 12V fans are probably fine.  Hopefully Samad's board can power all fans (including the one on the Peltier cooler) from his 12V outputs.
• [ ]  Solder the SMA connectors onto the FEDAM.
• [ ]  Finish gelware changes / Quartus compilation settings needed to get FEDAM running at 500 MHz.
• [ ]  Firmware:  Adjust the width of the coincidence-detection window appropriately for new speed.
• [ ]  Install mounting brackets at CLC for 2 shelf detectors, 1 ceiling detector, & t he main electronics chassis.  Run cable conduits above ceiling for the power & signal cables from the chassis to the 3 detectors.
• [ ]  Get network parameters for CLC's Wi-Fi network (SSID, WPA2 access passphrase); burn these into the Wi-Fi boards.
• [ ]  Physically install detectors & chassis at CLC.
• [ ]  Set up kiosk Mac with appropriate software (VirtualBox, Python 3.1.x, MySQL (or whatever DB we're using), UltraVNC server).  The UltraVNC server will allow development of our server software & visualization code to continue remotely.
• [ ]  Physically install the kiosk Mac, and set it up on CLC's network.  I recommend not giving the public any access to the mouse/keyboard initially, at until the visualization software is complete.  Also, the monitor should be left turned off until the visualization is ready.  Also, before opening to the public, some way needs to be found to prevent the public from escaping out of the visualization application and popping back up to the OS.  I recommend no keyboard access (so user can't hit any of various escape sequences), and operating in a full-screen mode so the user can't close windows, etc.

Of course, there is lots of work left on the pure software side (server Python code) to do as well.  Here is a relatively high-level breakdown of just some of the new modules/classes that will be needed:

• [ ] Database - Choose a Python API & a back-end database server.  Define tables.
• [ ] Graphing - Find or write a Python module for scrollable, zoomable real-time graphs.
• [ ] Timekeeper - Write interpolation code.  Use DB and graphing modules to track/plot time data.
• [ ] PulseModel - Provide & update parameterized models of pulse shapes.
• [ ] PulseFitter - Infer idealized pulse form from pulse data points.
• [ ] Triangulator - Infer Earth-relative shower heading (incidence angles) from timing data.
• [ ] DataCollector - Use DB, PulseFitter, Triangulator, to track data in real-time and pre-analyze.
• [ ] Visualizer - Use DataCollector, Timekeeper, Graphing, DataCollector to make various plots.
• [ ] ShowerEvent - Data type for storing data associated with a candidate cosmic-day shower event.

And I'm sure that isn't even close to being an exhaustive list...

Thu., Apr. 5th

SENIOR DESIGN FAIR DAY!

Plan for today:

• 7:30 am - Clean out back of minivan; lower all seats to prepare to load equipment.
• 7:45 am - Leave home.
• 8:15 am - Arrive at Loewe's.  Buy non-tacky tape for floor cabling, extra extension cords & power strips.
• 8:45 am - Drive from Loewe's to FSHSRC.
• 9:00 am - Park at FSHSRC loading zone.  Load all equipment (w. help from Ray).
• 9:30 am - Drive back over to the College of Engineering.
• 10:00 am - Arrive at COE.  Park in rear lot?  Leave equipment in car temporarily.  
• Print out plenty of rubrics for the Design Fair for all ECE faculty (say 8 for each review committee member, 4 for each other faculty), and plenty of Final Hardware Demo rubrics for the review committee members (3 for each ECE-led team or 30 total), and put them in faculty mailboxes.
• Email the ECE faculty as well as the advisors group on Blackboard to remind them to visit the design fair and evaluate the posters and hardware.
• 12:00 noon (or ASAP) - Coordinate with Donte and begin helping set up tables & easels, running extension cords & power strips, etc.  Make sure track for SoutheastCon is brought down as well.
• 1:00 pm (if not earlier) - Bring COSMICi equipment in from car, position detectors, tape down cables, power up electronics, boot up demo.
• 2:00 pm - ECE SENIOR DESIGN FAIR.
• 5:00 pm - Teardown.
• 6:00 pm - Drive COSMICi equipment back over to FSHSRC, bring it back up to lab.
• 6:45 pm - Head home.

Wed., Apr. 4th

Yesterday, M. Dean experienced a mishap wherein VirtualBox crashed while he was in the middle of saving the new top-level schematic, and as a result the file was corrupted and he lost almost all of the work that he and Juan and done over the last few days.  Juan is not here today due to a work conflict.  It therefore doesn't look like it will be possible to get the 500 MHz target met before the Senior Design Fair tomorrow.  I'm hoping they can still get it working before they turn in their Final Report next week.

Meanwhile, today I need to finish getting the electronics back up and running again with the new longer cables that will facilitate mounting the electronics on the wooden backplane that the ME guys are constructing.  Hopefully they will bring it by around mid-afternoon today and we can mount all the boards on it and re-test.

I'm going to disconnect the +3.3V supply from the DE3 board to the GPS module to prevent unintentional back-powering of the DE3 from the GPS.  (Of course, I'll leave the grounds connected, however, since a common ground reference is a necessity in any event.)  OK that's done.  Even though the +5V supplies are still connected, the lights on the DE3 don't turn on when the only back-powering is through that one.

Note to self:  Remember to re-burn Wi-Fi with INFO-mode condition reporting turned back off.  Let me go ahead and do that now so I don't forget.  OK, did that, and for the FEDM's Wi-Fi as well.

It occurred to me to stick a gender-bender in the FEDM's DE9 port and stick M-M double-ended header pins in there; wiring to that instead of the thicker DE9 pins will avoid damaging our jumper wires.  However, the thinner pins have a tendency to pop out of the F DE9 connector.  So, not sure if this will really be a good solution....

Derp, I just realized that the reason the GPS hasn't been receiving any satellites the last couple of days is because I never plugged its antenna cable back in!  OK, that's fixed now.  

Fixed a few bugs in some new server code that only got exercised after the GPS was working...

The ME guys are here now with the backplane.  They left briefly to get a drill.  The plan is, we'll mount the electronics on their board this evening before I leave, and they'll finish up the cover tonight and mount it tomorrow.  Samad is on his way with his power board.

As of right now (4:40 pm), the recent server changes to automatically start the run after the CTU and FEDM are both ready and the GPS time is good appears to be working.  Currently doing a run collecting actual absolute-time-referenced data.

Also good news:  My new, longer interconnect cables seem to be working more reliably than the previous cables; I no longer need the separate breadboard that I was using before to wire all the grounds together.  Here is a photo of the present desktop setup:

COSMICi electronics; final test before mounting on backplane.  Everything is working.  (FEDM PLL still @ 300 MHz, though.)

Samad is here with a newly resoldered board to fix his via issues.  He still needs to solder the capacitors and make a new cable to power the DE3 board.  I asked him to do a negative continuity test, and once that's done we can test his board under power from the ATX supply to make sure we get the right voltages on all of the outputs.  Then after he makes his DE3 cable, we need to test the voltage levels at the end of that before we plug it into the DE3 board.  Then, and only then, can we try using his board to power the DE3 and the other boards in the system.

The ME guys can drill Samad's board tonight before everyone leaves, and then Samad can go home and finish the soldering he needs to do.  I'm doubtful there will be enough time for us to test it thoroughly before the Design Fair.  If not, we can always power the GPS and CTU's WiFi via USB (as we are doing now) temporarily.  (In any event, we will probably be forced to power the detectors through their wall-plug supplies, since no one has made long power cables for them yet.)

As soon as the ME guys get back, we need to work on mounting the electronics to the backplane.

* * *

The ME guys were away quite a bit longer than I expected.  While hanging around waiting for them to get back, I ran out of other more useful things to do, so I started working on cleaning up my desk drawer.

After they finally got back, they finished drilling needed holes on the backplane and I helped them mount all of the PCBs on it and reconnect all of the electronics.  (George took a photo of the mostly-finished assembly to use in the presentation, but I did not get a chance to take one of my own yet.)  We re-tested the electronics (with the new cooling fan) and everything still worked except for the GPS, which was stubbornly refusing to acquire any satellites again.  The antenna was connected this time, so that's not the problem; we could try to blame high-altitude haze (making a ring around the moon) or simple bad luck in terms of the number of satellites in the portion of sky visible from the windowsill.  The server is already automatically trying all of the commands (resets, setting date & time) that I know of that might help with acquisition.  There's not much else we can do, except for cross our fingers and hope that enough satellites will be visible from the lawn between the Engineering building, or wherever our GPS antenna ends up tomorrow (depending on exactly where we set up).  Regardless of whether the GPS is really acquiring accurate times, we can still demonstrate the rest of the system tomorrow; it just requires typing a manual "HOST START" command to the CTU (since the automatic startup waits for the GPS to be ready).

When I finally left (at about 8:30 pm) the ME students were starting work on setting up the support structure for the new Peltier cooler and cooling fan.  Hopefully they will finish getting the new cooling system all assembled before tomorrow.  Maybe they will also mount the cover, but if not, it can always be attached later, at the Design Fair or afterwards - that is an easy part.  I am planning to come by to pick up all the equipment at around 9:00 am and load it into my van to take it over to ECE.  I will be busy with general design fair preparations at ECE from 10-noon, and am planning to start physically setting up tables, power cords, etc. around noon.

I'm planning to swing by Loewe's in the morning and pick up some non-tacky tape for taping cables to the floor, and maybe a new extra extension cords and power strips.

Tue., Apr. 3rd (PM)

The lab has been BAKING HOT in the afternoon for the last couple of days.  It's hot outside, but still...  Someone needs to complain to FAMU Physical Plant - they need to crank up the A/C in the building.  In the meantime, I texted Antony asking if he could remotely shutdown the Xserve nicely.  I really think we need to start turning off all of the major computing systems when we're not actively using them.

My plan for today:  Continue putting together the new, longer jumper wires for the test setup so that they can be mounted on the main board (and still remain functional) as soon as the ME students bring it back in.

I'm wrapping my makeshift "connectors" (really, just bundles of single-pin sockets) in electrical tape to hold the wires in the canonical order I'm defining.  (Based on the signal order on a DE9 connector.)

My present color code is as follows, for the 

• (#1) Red:        Host   Rx <-- Wi-Fi Tx
• (#2) Blue:       Host    Tx --> Wi-Fi Rx
•    Yellow:       Host DTR --> Wi-Fi DSR (autorun)
• Not presently included - instead hotwire on Wi-Fi board from J2 pin 27 (+3V out).
• (#3) Black:     Host GND --> Wi-Fi GND.
• Presently Wi-Fi is also grounded to PC via USB port.  Ultimately, need to ground it directly to Samad's power distribution board.
• (#4) Green:     Host RTS --> Wi-Fi CTS.
• (#5) Orange:   Host CTS <-- Wi-Fi RTS.
• (#6) White:     Host +5V --> Wi-Fi RI/+5Vin.
• Presently Wi-Fi is also receiving +5V via USB from PC.  Ultimately, need to supply +5V directly from Samad's power distribution board.
•       Purple:     WiFi CB1 pin 3 (3VOUT) --> WiFi J10 pin 2 (MAX3237E /EN)
• Presently this is hot-wired directly on the Wi-Fi board to disable input through the level-shifter from the RS-232 port (disable this when not debugging).  When debugging, move the source end of this jumper wire to J10 pin 1 (GND), when host is not powered up.

Now, let's take another look at the wires I'm currently using on GPIO1:

• GPIO1 pin 11 - Host +5V out --> GPS J5 pin 4 (USB5V in).
• Presently, we are also supplying this node from a PC via USB.  Eventually, we need to supply it from Samad's board.
• GPIO1 pin 12 - Host GND out --> GPS J5 pin 23 (GND in).
• Presently, we are also supplying this node from a PC via USB.  Eventually, we need to supply it from Samad's board.
• GPIO1 pin 27 (gpio1_d[20]) - Host PPS_edge <-- GPS J4 pin 15.
• GPIO1 pin 29 - Host +3.3V out --> Vcc in (on Sparkfun level-shifter)
• GPIO1 pin 30 - Host GND out --> GND in (on Sparkfun level-shifter)
• GPIO1 pin 39 (gpio1_d[30]) - Host Rx <-- GPS Tx (on Sparkfun level-shifter)
• GPIO1 pin 40 (gpio1_d[31]) - Host Tx --> GPS Rx (on Sparkfun level-shifter)

We could potentially tie the +3.3V levels on the GPS, the SparkFun level-shifter, the DE3 board, and the OCXO board together, using extra header pins on the GPS, as a way to help make sure the signal levels are all compatible.  Let's use Brown wires for those connections:

• SparkFun level-shifter VCC pin <-- GPS J12 pin 1 (3V3)
• GPS J4 pin 1 (3V3) <--> GPIO1 pin 29 (+3.3V)

And ditto for GND (black):

• SparkFun level-shifter GND pin <-- GPS J4 pin 2 (GND)
• GPS J4 pin 19 (GND) <--> GPIO1 pin 30 (GND)
• GPS J5 pin 24 (GND) <--> GPIO1 pin 12 (GND)

And we can tie the +5V nodes together (white):

• GPS J5 pin 4 (USB5V) <--> GPIO1 pin 11 (+5V)

One problem with making these power connections, however, is that the GPS kit can kinda-power the the DE3 board backwards along the connections.  I'm not really sure if this is a problem or not...  Once all the boards get powered-up simultaneously, it shouldn't matter...

Had an issue where GPIO1 pin 31 (which I tried using as the new host Rx pin for input from GPS) was stuck low for some reason.  I think I vaguely remember running into this issue before.  Now using pin 24 instead (and 25 for Tx output to GPS).

OK, the CTU's serial ports are up and running again with the new cables, but now there's an issue where the GPS module forgot what day it was (I unplugged all its power and the batteries weren't in), so now it's "confused" again.  At least this gave me the chance to exercise a little more of the GPS initialization code.  Fixed a bug that was preventing the time from getting initialized.  It's still not acquiring satellites though...  Part of this might just be due to the heavy rain / thunderstorms happening outside, which may be interfering with the GPS signal.  Not much I can do about that today...  Probably a good time to go home...

Tue., Apr. 3rd (AM)

Woke up early this morning and couldn't get back to sleep, so I got up and finished the coding work to automatically start the CTU as soon as the CTU and FEDM hosts are both ready and we are getting accurate time values from the GPS.  The new code still needs to be tested, of course.  Once it's working, the server should automatically start the run shortly after all of the boards are turned on and ready.

However, the Timekeeper and DataCollector modules still have not been implemented, so we still are not really doing anything meaningful with the data, such as processing & visualizing it.  To recap, the functions of these modules will be:

• (in timekeeper.py) timekeeper.Timekeeper - Worker thread class.  The Timekeeper gets created just before the CTU is started up.  Its function is to take in all of the data from the CTU (including both PPS  time-references and GPS data records) and do several things with it:
• (1) Store it in memory, at least for a while (although older records may be rotated out of memory eventually), and also store it persistently in a database file that can be queried offline from other processes;
• (2) Based on the stored data, provide a service of reconstructing accurate absolute times (ideally to an uncertainty of only a few ns) given relatively "raw" time data for an event.  The CTU currently marks time in 4/3 ns intervals from the start of the run - so the core function would be to take some number of "ticks" of this clock (>0) and return a data structure representing the corresponding absolute time in some more standard format (day, hour, minute, second) with few-ns accuracy.  The function from ticks to absolute time should be monotonically increasing, but is not necessarily perfectly linear, since there may be some gradual drift of the OCXO clock frequency over time which will need to be measured & accommodated when shaping the translation function.  Also, the function is not necessarily unchanging, since as we receive more data, we may continually refine the mapping.  Ideally the output structure would also provide some idea of the uncertainty of the time value, based on the current data.
• (3) Display some kind of real-time graphical visualizations of important data having to do with the timekeeping function.  This could include, e.g.:
• (a) Graphing the history of key information reported by the GPS, including the number of satellites we're currently receiving data from, and the number that are "good" vs. "bad" in terms of whether their time data has been eliminated from the timing solution.
• (b) Graphing the time-deltas between PPS pulses with a vertical scale marked according to the deviation in Hz between the implied OCXO frequency and the nominal frequency (10 MHz).  Superimpose a horizontal line showing the average frequency (over some appropriately-sized time window).
• (c) Graphing the cumulative phase wander of the GPS PPS signal vs. OCXO since the start of the run; this provides a nice visual indication of any excursions which may result from e.g. satellites going out of range, etc.  Superimposed on this curve can be another curve representing the reconstructed mapping from OCXO-based times to absolute times; the latter curve ignoring excursions due to a lost signal, and applying appropriate averaging to improve the accuracy of the inferred times beyond the accuracy of individual PPS edges.  A gray region around the latter curve indicating the uncertainty of the inferred times can also be shown.  The user should be able to zoom in & out on this graph using the mouse to inspect portions of it in detail, to examine the quality of the time reconstruction at particular points.
• (d) Graphing the Allan deviation of the two time references against each other?  Not sure if it's feasible, CPU-wise, to update this one in real time, but we can have a separate background thread that updates it periodically.
• (in datacollector.py) datacollector.DataCollector (worker thread class) - The DataCollector gets created just before the CTU is started up.  It takes in time-tagged event data of various types from the FEDM and does several things with it:
• (1) Store it (at least recent data) in memory, and also store it persistently in a database that we can separately query. (Like with the TimeKeeper.)  Data will be organized into tables based on what kind of data it is - candidate coincidence pulses, non-coincidence pulse counts, or error events.
• (2) Do real-time processing of the candidate-coincidence data via a number of steps:
• (a) From the raw data points, reconstruct a model pulse shape in some appropriate way.  Ideally this would involve some Bayesian inference of the ideal shape that best explains the data.  But in practice we will probably do some simpler least-squares fit of the model parameters to the data points.  When there are not enough data points to e.g. calculate the leading-edge to trailing-edge width ratio, we can use an average of previously inferred ratios as a placeholder.
• (b) Once inferred peak times for pulses have been inferred, cluster them into the most-likely shower sets based on how close-together in time the peaks are on the 3 detectors.
• (c) For each candidate shower event, infer the source heading (angle of incidence).  Store the so-processed data for shower events in another database.  A separate astronomy module should perhaps take care of mapping ground-relative headings and times to locations on the celestial sphere.
• (3) Do real-time visualization of various data:
• (a) Graph the number of error events (FIFO full, lost pulses) seen at each detector over time.
• (b) Graph the total number of pulse events (coincidence & non-coincidence) seen at each detector over time.  (A histogram of pulses of each height would also be nice.)
• (c) 2D polar scatter plot of the inferred ground-relative headings of all accumulated shower events since the start of the run.  (Since this is ground-relative, a celestial point source would revolve around the North star on a diurnal basis.)
• (d) Similar plot in inferred galactic coordinates on an elliptic projection - although this should perhaps be taken care of by a separate astronomy module.

Mon., Apr. 2nd

Juan is here and working on finishing up the refactoring of the FEDM gelware (separating the high-speed components into one entity).

I am getting ready to test the wireless communication through my Verizon hotspot, which is presently configured with WPA2 Personal security.  My laptop is successfully able to connect to the Internet through it.

The script seems to be hanging.  Turning on debug output to UART and trying again...  Went through a few rounds of turning on more and more options to display more output, finally narrowed things down to the attachment failing after the new security steps...  Reordered the steps (the main change being to set the key before turning on security), it works now.  Turned debugging modes back off.  OK, all the server connections open again, now over my access point & with WPA2-Personal security.

After I finished that test, the ME guys (George and Brian) showed up with the main board for the electronics box and tested the mount points for the spacers to make sure the two major PCBs (DE3 and FEDM) would fit on them.  With some fiddling, that worked.  They also identified where to mount Samad's board and the clamp that will hold the OCXO board.  They brought their hand-made SMA cables; I can rig up a test to look for signal reflections where I connect the DE3 to the scope through those cables and look at the waveform quality.  Still to do on the ME side:  Assemble bracket to hold the cooling system (I told them, make height adjustable!), drill mounting holes in Samad's power board (1/8" hole diameter, 1/8" from edge to hole center), drill holes in main board to hold Samad's board and the OCXO board clamp.  They also wanted to do another coat of paint & clear-coat, so took the board with them to do that.  Also, we still need a permanent solution for the various signal & power wires between boards (to get adequate lengths), but we can perhaps rig up something temporary for that.  Maybe I'll stop by Fouraker's and/or Radio Shack on my way home this evening and look for a solution.

Also, Samad stopped by earlier and we discussed the need to solder through-hole pins to both sides of his board since the holes are not plated.  I gave him a pack of breakaway headers with longer pins to make that easier.  He will see if he can get the mounting holes drilled at ECE.

After the kids left, I spent some time rebuilding the serial "cables" (really jumper wire bundles) to both Wi-Fi boards to standardize the wire color-codes and go through a double-sided M-M header for easier connect/disconnect and longer length.  This is still just a temporary solution, however, and something that makes a more solid/reliable connection is still needed for later.  I hooked node 0 back to the CTU (whose serial port on GPIO 0 I also re-wired) and verified that that connection still works.

Powering the Wi-Fi board through the DE3 still doesn't work reliably, so we still need Samad's new power board to supply +5V to the Wi-Fi board (or else just power it through USB in the meantime).

Next up (tomorrow):  Do the same thing (extend the cables) with the serial connection to the GPS and the other miscellaneous connections to the GPS, and the connections to the OCXO board; get whole current demo working with new longer cables.