Thu., May 3rd

Tried to see if I could remotely access my desktop using VNC, so I can help resolve any problems while I'm away.  That didn't work, so I submitted an application for VPN access to EIT.  Hopefully that helps.

Ray and I are planning to run a test of the detector with one battery.  We did that, but it didn't work - we found it has a short between the two conductors.  Emailed Samad to find out where it came from.

Wed., May 2nd

New student is visiting; Ray is talking to her about the project.

I re-mounted the FEDA board to the platform, reinstalled the cooling unit onto it, and reconnected the +5V power to the FEDAM, and the +12V power to the fan, and reconnected the 3 detector cables and the timing-sync cable to the newly-soldered SMA jacks in our preferred arrangement.  Getting ready to show Ray the startup sequence...

The FEDAM's Wi-Fi (Node #1) seems to be having trouble getting enough power through the FEDAM board; possibly this is because the hand-made connector through the gender bender keeps coming loose.  I made a new power connection for it directly from Samad's board.  That works, but some day we need to make a more robust connector.

Went through the startup sequence and data format with Ray.  Need to write up a little document on the startup sequence and data format.  OK, did that; created "COSMICi User Manual" document on docs.neutralino.org and shared it with Ray.

Tue., May 1st

Samad dropped off the batteries; I just need to figure out how these barrel-plug connectors on them are supposed to be used; [x] look that up. - Couldn't find one, and Samad said he couldn't either.  My main question is whether the first battery's output can be plugged into the second battery's charging input as a way of effectively connecting both batteries together in parallel.  If the first battery's level fell below the second's, the second would spill charge over into the first and fill it up to the point where they're equal again; amirite?

Also need to revise the PCB design for the new OCXO board.  OK, did that, and uploaded the new CAM files.  Order is ready to submit to Sunstone now.  Here's a layout image:

Layout of the new breakout board for the OCXO module.  Decreased line width on
output trace from 50 mils to 20 mils to minimize parasitic capacitance on this signal node.
Also added dimensions, a board descriptor, & added my initials to the vanity tag.

Other things to possibly do today:

• [/] Solder down SMA connectors on FEDM board.
• [/] Drill holes in platform for fastening down power cables.
• [ ] Use circular saw to make a larger hole to run cables through - maybe do some more planning first though.
• [ ] Make sure Ray understands the startup sequence. - He left for the day before we had time for this - we can do it tomorrow though.

OK, I soldered the connectors:

Right-angle SMA connectors soldered onto the appropriate pads of the FEDA module.
Slight discoloration around the pads is leftover cleaning fluid which I used to wash off the
excess solder flux.  If I knew where our can of air was, I would try drying it more quickly...

The FEDA (Front-End Data Acquisition) board needs to be re-tested, although perhaps I should wait for the cleaning fluid to dry completely first.  Idea:  Lay it on my household cooling fan (pointed straight up).

My little personal cooling fan doubles as an electronics dryer.

If I can get it looking dry before it's time for me to go today, I will reinstall it on the main platform and try running a system test.

Meanwhile, I drilled holes in the main platform to allow me to fasten down the ATX cable with cable ties (as opposed to the earlier electrical tape, which looked messy and was pulling away):

New ATX power cable arrangement.  Appropriately-sized holes were drilled in the main
platform at appropriate locations to allow me to pass large cable ties through the platform
which allows the ATX cable to be held down securely in a compact configuration.

The FEDA board is still not quite dry, so I don't think I'm going to be able to reassemble and retest the whole system today.  Guess I'll leave it drying overnight...

Meanwhile, did one more little thing:  Found some new top washers to hold down the cooling system bracket, to replace the larger ones that the guys had to cut down earlier (presumably to help them install/remove the cooling system around the board more easily).

New smaller washer to go under bolt head;
compare to the larger one which stuck out too
far and had to be cut back.  We'll still use the
large ones on the back side of the board, though.

Foo

Fri., Apr. 27th

Did two things today:

1. Installed thermometer/hygrometer on the silver quarter-circle next to the kiosk, where the electronics platform will go, using double-sided tape; I will leave it there for several weeks (until I get back from China probably), to measure the maximum temperature & maximum relative humidity over this period.  I asked Reed to remove it and check the values if he notices the display going dim, since this would probably indicate the battery is dying.  I don't know if it will really last the 7 weeks until I get back.  

2.  Went up on roof, and took a photo of the air vent we will use to feed the GPS antenna cable into the building:

Air vent on the roof of CLC that we will use to feed the GPS antenna cable into the building.
We will ground the lightning surge protector to the grounding cables seen here.  

3.  Also, while on roof, measured the slope of the roof near the center point using the iCarpenter app on my iPhone.  Actually, the CLC staffer who let me up onto the roof was nice enough to do the measurement for me, following my instructions (climbing up on the planetarium roof would be tricky for one who warps space and time as strongly as I do).  He measured the slope at two points near the lightning rod at the center of the roof; one measurement was slightly below 9 degrees and the other was slightly above, so we'll say 9 degrees is the slope of the roof.  I'd guess that's probably accurate to within +/- 1 degree.  Close enough for government work.  Below is a close-up of the area near the lightning rod where he did the measurements.  You can't see much from this angle, but you get the idea...

Lightning rod at center of planetarium roof.
I'm currently thinking of placing the GPS antenna
somewhere nearby.

Note to self:   Before we actually place the order for the new OCXO board, it would probably be a good idea to change the width of the CLK_OUT trace from 50 mils to something like 10-20, to reduce parasitic capacitances, which otherwise might smear out our rise time a bit.

Thu., Apr. 26th

Coordinating w. Reed via email re: plans for mounting GPS antenna on rooftop.  We need to know roof slope and roofing material to design an appropriate attachment for a pole on which to attach an antenna like that Spectracom one I've been looking at (the ANT-35).  We can probably fabricate the pole/roof-mount assembly at the College machine shop.

The ME students installed the detector shelves and emailed photos of them, below.  They probably still need to be painted to match the walls or another thematic color of the exhibit hall interior, but that is relatively easy - I'll coordinate with Reed on that.

Southwest detector shelf.  Above exit sign near rest rooms in main exhibit hall at CLC.

Southeast detector shelf.  Above double doors leading into large classroom off main exhibit hall, next to LEM module model at Duval St. entrance.

Northern detector shelf.  Under awning next to display kiosk.  Just across from entrance to planetarium.

David and I created the CAM files for the new OCXO board design, and generated the quote through SunStone.  Ray said he'll pay for the boards to be ordered.

New OCXO board layout - about to be taped out to SunStone. 

Before I lose the piece of paper, here are the notes on which detector/cable currently connect to which SMA ports on the FEDA board.  This configuration leads to event rates on the three channels that are relatively more equitable with each other than in other configurations.

• Case #2 - Cable #2     - PMT #1 - Input channel #0
• Case #3 - Cable #3     - PMT #2 - Input channel #1
• Case #1 - Cable #1     - PMT #4 - Input channel #2
•                           NC    - PMT #3 - (Input disabled)
• DE3/CTU CLK_OUT - TimingSig - Timing sync datapath

Wed., Apr. 25th

Today I brought the new hygrometer and the tape measure and went over to the Challenger Center.

Spoke with Reed about the detector arrangement.  Michelle Personette expressed a preference that the detectors be placed out in the exhibit area for easier public viewing.  Some good spots seem to be:  

1. Hanging from I-beam above double doors leading into big classroom.
2. Hanging from I-beam above exit sign near the rest rooms.
3. Inside awning above blank circle quadrant beside kiosk (near entrance to planetarium).  A notch may have to be cut out of the edge of the shelf to prevent overlap with awning support.

Using my tape measure, Reed and I confirmed that #1 and #2 are very close to 30' apart, and #1 and #3 are very close to 30' apart.  (We didn't measure #2 to #3, but eyeballing, it looks pretty close.)

The ME students (George & Brian) went to get more mounting hardware, hopefully they will come back later this afternoon and do the install of the detector shelves at least, at the locations we discussed with Reed.  Reed says he is staying pretty late tonight (8:30 or so).

We discussed mounting the main electronics platform sideways on the blank circle quadrant next to the kiosk.  This will allow for much easier public viewing.  However, this will require new planning as to exactly how it will be mounted.  Also, I doubt that the copper cooling rod would be stable in that configuration - the thermal paste probably isn't strong enough by itself to keep it from falling.  This location for the electronics platform will probably also necessitate buying new, longer coaxial cables to feed to the three detectors, due to the paths along which some of the cables will have to be routed.  (This will cut our sensitivity slightly due to cable attenuation.)

Regarding the GPS antenna cable:  After considering a couple of possible paths, a consensus emerged that the easiest, shortest, and least-likely-to-run-afoul-of-building-codes solution was the following:  

• GPS antenna on roof of planetarium (perhaps at center for easy cross-referencing to building blueprints), with a lightning protection device connected to the grounding cables strung along the roof.  (See Spectracom's technical note on lightning surge protection.)
• Antenna cable enters building through unused exhaust vent on roof of planetarium.  Protection device is installed where cable enters vent; ground runs from there to building's grounding cable which goes nearby.  See picture below.  (Damn, I should have taken iPhone photos while we were up there!  Go back tomorrow...)

• Antenna cable goes into crawl space/attic space above planetarium, and then down through area between walls, coming out ceiling tiles just inside the planetarium interest, then going over to the main electronics platform mounted there on that quarter-circle.

The length of the antenna cable in this configuration would be fairly short; perhaps even short enough that we wouldn't need a repeater, or at most just one repeater.

Let's do a calculation.  Suppose our total antenna cable length is 100'.  If we use RG213 (KX4) cable, that attenuates at 0.35 dB/m, so total cable attenuation would be 35.5 dB, including a 0.5 dB connector, plus another 1 dB for the Lightning Protection device gives 36.5 dB total attenuation.  This could be mostly compensated for by a high-gain antenna, e.g., SpectraCom's ANT-35 is +35 dB.

Interesting; Spectracom provides an OEM module that integrates a GPS receiver and an OCXO.  This might have simplified our CTU design a bit.  However, they only claim 25 ns accuracy, which isn't an enormous improvement over the 68 ns of the DeLorme board.  We might do better with averaging.

Regarding the dewpoint measurement:  I took a measurement near the kiosk, and got temp = 22.4 C, rel. humidity 48%, which imply dewpoint = 11 C - same as I got at home last night.  However, Reed warned that there could be significant seasonal fluctuations in temperature, and humidity might vary when people are coming in & out.

The hygrometer actually has a "MIN/MAX" feature to take minimum/maximum readings over an extended period; I could place the hygrometer at the approximate location of the electronics board and leave it there for a while; the maximum temperature/humidity values could then be used to calculate an upper bound on the dewpoint over that period.  I just need a little double-sided sticky-tape thingy to affix the hygrometer to the quarter-circle about where the electronics board will be.

Tue., Apr. 24th

I want to spend some time today trying to prioritize a list of things to accomplish before I leave for China.  I'm leaving May 4th, so that gives me 8 work days between now and then (including today) to get stuff done.  Here are some work items I can think of:

1. Ray requests an operating manual.  That should not take very long.  However, I want to do it last, so it can reflect the most up-to-date state of things.
2. I would like to do at least one example of a module that actually provides interactive real-time graphs of some meaningful data - e.g. the discrepancies between the intervals between subsequent PPS pulses and the nominal second defined by the OCXO reference (10M OCXO cycles, or 750M PLL cycles).  That way, if someone wants to pick up from there, and do some more graphs, they will have a model to use as a starting point.
3. Figure out the configuration of the GPS antenna cable and order the components we need for that, and work with Reed Lambdin to plan out the route that the cable will take.  First step:  Try to figure out how much attenuation the GPS module can tolerate while still receiving satellites.
4. Someone (not necessarily me) needs to solder the SMA connectors to the FEDM at some point before it is physically installed at CLC.  The FEDM should be re-tested afterwards.
5. Someone (not necessarily me) needs to go through the Quartus design that Juan and Michael Dean were working on, and identify whether it really implements the same logic as the previous version of the high-speed components - it seems to me that it can't, or else the Fmax would be the same.  One thing:  The XORs can be moved out; although that shouldn't really affect it.  We should also go through the compilation settings side-by-side and compare them with the baseline project (the one on Q:\).  Darryl expressed some interest in helping with them.
6. At some point, someone (not necessarily me) should figure out what is a reasonable voltage level to operate the thermoelectric plate at, and we should rig up a power supply for it.  Goal:  Keep FPGA package surface close to (but not below) the maximum indoor dew point in the classroom.  According to Wikipedia, a dewpoint of 13-16 C is "comfortable."  So 16 C might be a good guess.  But to be safe, we should probably measure the actual dewpoint in the classroom.  The dewpoint can be calculated from the temperature and relative humidity.  Cheap hand-held digital meters capable of measuring this information can be purchased at outdoor/sporting goods stores.  Maybe I'll pick one up on my way home.
7. At some point before we install, someone (not necessarily me) should fasten down more of the loose cables/connectors on the electronics platform.  Some of this has to wait until the SMA connectors are soldered.  The power cable needs holes drilled thru the board to run a heavy-duty cable tie through.
8. At some point, someone (not necessarily me) should cut the ventilation hole(s) and wiring hole(s) in the plastic enclosure.  Alternatively, someone also suggested that holes could be drilled in the platform for routing some (or all) of the cables - this might provide a neater look.  I think a circular saw hole (about 1" diameter) near the center of the platform would provide relatively easy access for all of the cables we'll need.  Here's a list of all these:
   • Main AC power cord for the ATX supply.  (This is the only power input, assuming here that we can also power the thermoelectric cooler through Samad's board.)
   • GPS antenna cable, snaking in from some long pathway coming down from the rooftop.
   • Bundle of 3 coax cables and 3 power cables (speaker wire), these to split out in pairs (one coax cable +  one speaker cable) to enter 3 conduits fanning out to the 3 detectors.
9. At some point soon, someone (not necessarily me) should construct the power cables for running the 12V power to the detectors.  Ray got the barrel connectors, so they just need to be soldered to one end of the speaker wire (cut to ~40' lengths), and for the other end, we still need to rig up some kind of connection for plugging into Samad's board.  Maybe yellow (+12V) and green (GND) jumper wires?  -  OK, I went ahead and pulled out three yellow/green pairs from the power supply board, each to a 2-pin male header - one end of the speaker wire can be soldered to this.  On the speaker cables, let's use white = +12V, copper (clear) = ground.
10. The new OCXO board (designed by David & Samad last week) needs to be "taped out" to CAM files (show David/Samad how to do this), and submitted to Sunstone for fabrication.  We have solder paste and a hot-air gun which should be suitable for the soldering the SMT OCXO parts, which are on order.  We have the other parts needed (male 2-pin header, and right-angle SMA connector) so we should be able to complete assembly as soon as the fabbed boards and the OCXO get in.
11. Empirically (using waveform generator and scope) measure signal propagation delays down the 3 main coaxial cables we're using.  This is important for reducing systematic error in our measurements of the relative arrival times of pulses at the 3 detectors, and also for reducing systematic error in our measurements of the absolute arrival times of pulses (i.e., arrival times relative to the GPS reference).  This should be easy, I have everything I need for it - signal generator, scope, and coax splitter.  Oops, no, correction:  I really first need an SMA-to-BNC adapter of the right type.  (SMA female to BNC male.)  The one we have is the other type.  [ ] Look for this at Radio Shack.

The "La Crosse Technology
Indoor Comfort Level Station"

I went out shopping for a hygrometer.  After striking out at Kevin's and Trail and Ski, at Lowe's I found a nice little digital combination thermometer/hygrometer for $20.  Tried it at home just now; got a temperature of 24.3 C (75.74 F) and a relative humidity of 44%.  Found a little iPhone app called DewPoint that calculates the dew point temperature from this data - it says the dew point is 11 C.

Let's try checking this figure against the approximate dew point formula on Wikipedia:  http://en.wikipedia.org/wiki/Dew_point#Calculating_the_dew_point.  Made a spreadsheet Dewpoint.ods (in my FAMU/COSMICi Dropbox) to perform that calculation.  Using the same inputs, it gives 11.256 degrees Celsius, suggesting that the little iPhone app and the Wikipedia formula are both reasonably accurate, or at least about equally inaccurate.  :)  Probably the app is rounding.

OK, now I  just need to bring this little measurement box into CLC, hold it up near the ceiling where the electronics platform will be, run the calculation in the app, and then we will have a baseline estimate for what the "typical" dewpoint at that location may be.  To get a clear idea of the maximum dewpoint, we'd probably need to take a lot more measurements at all different times of day/night, different seasons, different outdoor weather conditions (humidity, etc.).  This is a prohibitive amount of work (unless we set up some kind of automated data collection, which also is a lot of work), so instead, we should probably just take a few measurements and add a slop factor (safety margin).  Anyway, one would hope that the building's climate control system normally succeeds at keeping the humidity at a reasonably low level.  Not necessarily a very good assumption, but perhaps a reasonable starting point.

Mon., Apr. 23rd

The arXiv preprint of the FEDAM paper is now online here: (http://arxiv.org/abs/1204.5104), and I updated the COSMICi homepage to refer to it and also to summarize our accomplishments from this academic year.  I emailed Darryl some more comments on the paper.  I also forwarded it to Sachin.  Ray or somebody tweeted it on the APCRDRDL feed.

George stopped by the lab this afternoon and picked up some mounting brackets to install at CLC.

Fri., Apr. 20th

Did all night runs Weds. & Thurs. night.  No GPS time lock received even after all-night runs both nights. It occurred to me that maybe there was a reason why setting the time sets it 17 seconds behind?  I commented out that line and tried again and shortly afterwards we got a time lock.  This could have just been a coincidence; we need more testing.  I put the 17-second correction back in for now; we'll try again later.  Anyway I am letting the present run continue for a while.

Samad and David are here, I got them started working on designing the new OCXO board in PADS.  We basically finished and just have to do the CAM files.

Darryl is going to look through the Quartus design and try to pick up where Juan and Mike Dean left off.

Ray is getting barrel plug connectors at Fouraker's so we can make new longer power cables for the PMTs.

I need to re-order another OCXO chip....  That PO is in process now.

Thu., Apr. 19th

This afternoon, Ray, Darryl, David, and I worked together to put some finishing touches on the journal article preprint, and submitted it to arXiv.  And I finished writing my blog notes from yesterday.

Wed., Apr. 18th

Aarmondas stopped by my office to go over the database schema.  We spent a few minutes discussing it, and then we agreed he will come by the lab around 3 to go over it some more.

I brought into the lab the parts I picked up at Staples and Radio Shack last night - a replacement cartridge for the Brother P-touch labelmaker, some premium (high-strength) electrical tape, some speaker wire (for powering the detectors), intercom wire (a possible alternative to jumper wires for interconnections on the main board), and some "telephone spade lugs" for an improved connection to the screw terminals on the FEDM board.

I checked the result of the compile that Mike Dean started yesterday (high-speed entity only), and it was too low - under 250 MHz.  Something must be wrong in the design or the compiler settings, because we know we can get over 300 MHz (we are doing so now, in my current version of project w/o the refactoring).  I checked the compiler settings and adjusted the placement/routing effort to the values that have been working best for me (4.0 and 1.0 respectively).  I also noticed a bunch of extra components were in the LogicLock region, so I deleted all the LogicLock settings and am compiling just the high-speed entity now without LogicLock to make sure that something about LogicLock isn't interfering with getting an optimal compile.  If this still doesn't get us at least back up to the neighborhood of the ~350 MHz speeds we were getting before the refactoring, I will have to delve into the design to see if there are any mistakes (i.e., differences in logic (as opposed to organization) from the original design).

One thing I also want to do today is continue straightening up the cabling on the main board - fastening cables down, etc., labeling components, and testing power via Samad's board.

I also need to take a look at the GPS datasheet and see if there is any information there that might help me figure out how much attenuation of the satellite signal the module can tolerate; this is needed to determine how many repeaters we might need (depending on the length of the path at CLC and the gain of the receiving antenna).

By the end of the day, I got Samad's board successfully powering the whole system.  Here are a couple of photos:

Main electronics platform; all components powered through custom power distribution
board.  I have labeled all the major components and started binding up wires with cable
ties and fastening down wire bundles with electrical tape.

Custom power distribution board, designed by student Samad Nurideen.  Fabricated
at the ECE Department PCB shop by Mr. Donte Ford.  Assembled by Samad Nurideen.

Regarding the Quartus design:  The compile I started earlier in the afternoon still ended up only at under 250 MHz.  We know this can't be right (if the design is correct) because the present design is running at 300 MHz (with an Fmax of about 350 MHz).  So we are going to have to go through the design looking for mistakes.

Tue., Apr. 17th

Got a new gender-bender at Radio Shack yesterday.  Oops, left it in the car, 'scuse me while I go get it...

Inspecting the serial output in UwTerminal, I found that the GPS had lost all its configuration settings and was back at factory defaults.  Re-configured it.  That fixed that problem.  Power distribution board is currently successfully powering the following components together (all that I've verified so far):

1. DE3 board
2. CTU Wi-Fi board ("node #0").
3. GPS kit.

Over coming days I will continue to work on tests verifying that it's successfully powering more and more of the components...

Meanwhile, Michael Dean is here getting the newly refactored code to compile.  He did that.  However the speed for the high-speed stuff is back below 300 MHz.  Perhaps because the pipeline stages for the high-speed counter value were removed?  He put them back in and is recompiling.

David & Darryl were here working on the journal paper today; I helped them grab a new scope picture of the test pulse.  They are about to post a draft of the paper on the arXiv.

I spent some time making a new longer power cable for the CTU's Wi-Fi board.  Also soldered a new ground pin onto it.  Started fastening cables down to the backplane (currently using electrical tape).

I spent some time trying to figure out why the $PDME,9 command always seems to set the GPS module's time about 15 seconds behind the time actually specified.  No luck figuring that out.  Perhaps I should just compensate by setting it 15 seconds or so ahead of the actual time.  Doing that now.

The SMA connector for the OCXO broke off again.  We really need to design the new OCXO board soon.  Since we have a full PADS license now, this should be pretty easy.  I'm going to see if David and Samad can get together and start working on this before they go.  Emailed them.

I need to go by Staples or Wal-Mart and find replacement cartridges for the label-maker so I can finish labeling the components mounted on the backplane.

I also need to go back to Radio Shack and pick up some proper screw terminal flange thingies for the FEDM power connection.  Some more electrical tape might also be useful.

Don't forget:  Solder SMA connectors to FEDM board at some point soon.

Mon., Apr. 16th

Last week was pretty hectic what with the ME department's Open House and all of the final presentations for the ECE Senior Design projects.

My understanding is that the ME students picked up the main electronics platform Thurs. AM to display at the Open House, and returned it sometime later - it is back here in the lab now.

Hopefully students will be in & out of the lab this week finishing up various misc. tasks - I posted a list of items to be finished up in this blog, a few posts ago.

Latest word from Juan & M. Dean is that they are almost finished (again) with the refactoring of the high-speed logic - hopefully this week we can compile those changes, check for improvements in the Fmax value, and test.

Work Item:  Procure/Install GPS Antenna at CLC

* Emailed Reed about coming to meet with him a little later in the week to go over the GPS antenna situation, discuss possible routes, etc.  Note to self:  [ ] Bring tape measure.

* Emailed students to find out their schedule this week; I need to know this so I'll know when it's safe for me to go over to CLC.  Ray says he'll be around after 3:30, so maybe I will go today.

[/] Need to look through old email with DeLorme to look at the GPS antenna manufacturer they recommended.  OK, here's some stuff from Brian Stearns of DeLorme:

I’ve been asked this before… GPS Networking makes some fixed antenna mount kits...see: http://www.gpsnetworking.com/For an antenna and mount, see L1GPSA-N (Antenna) and L1RAMB or L1/L2RAMB (mount):http://gpsnetworking.com/GPS-antennae.asphttp://gpsnetworking.com/antenna-mounts.asp If the distance is long (>50feet), you'll need to use Plenum Cable instead of regular coax. Most buildings/local governments require surge protectors as well.See PCABLE and SURGEPRO: http://gpsnetworking.com/cables-connectors.asp You may need to re-amplify the signal after a long run.  See: http://gpsnetworking.com/standard-line-amplifiers.asp For a repeater take a look here for kits and the FCC Regulatory Policy:http://gpsnetworking.com/GPS-re-radiating-kits.asp

We need to consider attenuation, possible need for re-amplification, possible repeater (re-radiate through glass?), possible need for surge protection.

The re-radiating kits are kind of expensive (ranging from $400 - $2,100), so it might be a good idea to avoid that approach.  Also, if re-transmitting the GPS signal a long distance through the building, we might add some difficult-to-model extra delay.

Here's a nice white paper from SpectraCom about GPS antenna installation:  http://www.spectracomcorp.com/DesktopModules/Bring2mind/DMX/Download.aspx?EntryId=353&Command=Core_Download&PortalId=0&TabId=59

From this we can estimate the attenuation in dB, and maybe get some idea whether some kind of repeater is necessary.

Samad came by with his new 2x6-pin power-connector cable, and he fixed (jumpered over) the mis-pinned power-on connection on his power distribution board, and then we plugged his new power cable in, and also jury-rigged power/ground cables to the Wi-Fi node #0 (5V), GPS kit (5V), and OCXO (3.3V).  The Wi-Fi board and the DE3 seem to be powering up just fine, but the DE3 board is receiving no communications from the GPS kit for some reason.  I need to diagnose that problem.  The light on the level-shifter is flashing, suggesting data is being sent, but none of it is coming through.  I need to connect to the GPS kit from the PC to see what's up.  For that I will need a new gender-bender from Radio Shack, because I used the one we had to make a removable connection to the FEDM.  Good time to go out and run my other errands...

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.

Fri., Mar. 30th

David and Darryl were here today, and were thinking and talking with Dr. O'Neal about what to do next on the paper wrt updating the figures.

David went through part of a tutorial on PADS and learned about a lot of nice features.  Perhaps before the Senior Design students disappear, he can sit down with Samad and they can work together on designing the new OCXO board - this is an extremely simple board which will be good practice for both of them.

George stopped by with some SMA cables that he had picked up at Radio Shack, but they didn't have the right connectors to interface with our boards.  Brian thinks he can make his own cable, but I told George that they really need to order some off-the-shelf ones online as a backup, and also because making a good quality coax cable with no impedance nonuniformities (which can cause signal reflections) is in general quite difficult; making a cable that really offers a reliable high-quality connection suitable for GHz-bandwidth signals can be a challenge.  Brian supposedly has experience making coax cables, but we can't risk any more delays if they can't build a working cable.  We found 12" cables at Cables to Go (hopefully these will be long enough; 16" or 18" might also be suitable, if we can find them) and George says he will order them and they should arrive on Tuesday.  But hopefully he & Brian can make a cable before then that will work well enough to at least wire up & test the main electronics box assembly.

The main thing I worked on today was trying to configure the Wi-Fi connection using my Verizon MiFi 4G/LTE mobile hotspot.  We tried WEP 64-bit, but the modules wouldn't connect, perhaps because the MiFi would only let me enter a 10 hex digit (40-bit) key?  The Norton might have been blocking the connection, but I switched off the relevant features and this didn't fix the problem.  If I continue having problems, I'll uninstall Norton; it only has 11 days before the demo license expires anyway.  I went ahead and configured rules in Windows Firewall to open the needed ports.

In the meantime, I changed the Wi-Fi script to turn on info-level output, so I can see exactly where it is having problems.  I'm also trying to configure it for WPA2 Personal since that is the most secure level supported by the MiFi - as long as we're trying different things, we might as well try the most secure mode first.  The EZURiO does support WPA2 Personal, according to the docs; however I haven't tested this mode on it before.  I'm working on augmenting the script to support this mode as an option selectable in the site configuration.

* * *

Working while on a trip this evening, I finished the script changes to support WPA2-Personal security, and got the script to compile.  (As usual when adding code, this involved moving more strings out to the strings.txt file.)  The changes still need to be tested on a real Wi-Fi board next time I am in the lab (or at home).

Thu., Mar. 29th

It occurred to me this morning that we'll need a wireless access point at the Senior Design Fair. An easy solution would be my Verizon mobile hotspot. I can rename it "MikeRoCosm" (for Mike's Roaming COSMOS, or Micro-COSMOS) and configure it with minimal or no security and the modify the boards' Wi-Fi script to connect to it. Also, the server can run on my (or someone else's) laptop which can also be set up to connect to the AP. I can test this in lab on Friday. We need to arrive real early on Thursday to start setting up, duct-tape cables to the floor, find a good spot for the GPS antenna and the detectors, run electrical power, etc. I need to ask Donte about the power arrangements. It might be possible to write a real quick-and-dirty visualization over the next few days, maybe give that a shot. It will not be a permanent solution though.

Wed., Mar. 28th

Juan is here and working on timing optimization.  He found this nice tool called Timing Optimization Advisor that made suggestions of ways to improve the timing performance.  It had a couple of suggestions which looked promising that we are trying.

To help out, I am going to make a list of all the settings I have fiddled with:

• Compilation Process Settings:
• Use smart compilation - I don't know if this affects performance at all; it supposedly can improve compilation speed, so I've been leaving it turned on.
• Incremental Compilation:
• Incremental compilation = Full incremental compilation.  I think this is necessary for partitions & LogicLock to be helpful.
• Physical Synthesis Optimizations:
• Optimize for performance (physical synthesis):
• Perform physical synthesis for combinational logic = ON
• Perform register retiming = ON
• Effort Level = Extra
• Fitter netlist optimizations:
• Perform register duplication = ON
• Analysis & Synthesis Settings:
• Optimization Technique = Speed
• Timing-Driven Synthesis = ON
• Fitter Settings:
• Fitter effort = Standard fit (highest effort)
• More Settings...:
• Placement effort multiplier = 4.0
• Router Timing Optimization Level = Maximum

At least, these are all the settings that I think were helping.

I'm also looking at possibly changing the state encoding for the pulse_cap FSM to a one-hot encoding (this was one of the things that the Timing Optimization Advisor suggested).  Not sure yet if this will help at all because that logic was, I think, pretty well-optimized already.

589.28 MHz - Baseline speed for high-speed datapath.

455.37 MHz - Speed after switching to the one-hot encoding.  Nope, it didn't help!

Continued working on server coding.  When I left off at the end of the day, I was about to write the code for the GPS_Manager that would cause it to watch for the condition where the TRAIM is not eliminating all satellites from the solution and is reporting a non-null accuracy value (and maybe also verify that the current time as reported by the GPS is consistent with the system clock), and in this case, it should inform the application's main entity (the CosmicIServer instance) that the GPS time is good, by calling its yo_GPS_time_is_good() method, which will then relay this information to the RunManager instance, causing the RunManager to proceed to the next step in its startup sequence, which has not been implemented yet (empty method bodies for now);  that step will be to start up the Timekeeper and then the DataCollector (both of which have also not been written yet) and then (next step) start the CTU - that last step should be really easy to implement though, since all the infrastructure for it is already there.  (We can go ahead soon and test this & the rest of the startup sequence, leaving empty method bodies in the routines to start up the Timekeeper and DataCollector temporarily.)

Tue., Mar. 27th

My plan for today:  Work on the startup sequence.  Maybe create a new class/worker thread called RunManager that is responsible for overall management of the startup sequence and maintenance of the data-collection run?

Michael Dean is supposed to come in today; he can continue working on the refactoring of the FEDM gelware into high-speed vs. low-speed modules.

Darryl (if he's feeling better) & David are also supposed to be here; I can maybe work with them to collect some higher-quality data for inclusion in the paper.

Sometime, David might also work on the PADS layout modifications.  The FlexNet license server seems to be in a good mood today and David was able to run PADS on the Acer with no complaints.  I told David he also needs to install the OrCAD demo version on the Acer sometime so that he can inspect the schematics.  To modify the schematics, though, we'll have to use the OrCAD at the College of Engineering since the demo version we're using here won't let us save changes.  Sometime I need to go over with David in more depth how to actually modify layouts in PADS.

More thoughts about RunManager:

Here's what it does:

1. It waits for the CTU node to be created, and for its host to become ready.
2. It waits for the FEDM (ShowerDetector) node to be created, and for its host to become ready.
3. It waits for the GPS_Manager to report at least one valid TRAIM reading with finite accuracy and w/o all satellites eliminated from the solution.
4. It tells the CTU host to start running (generating PPSCNTR time-reference data and timing sync pulses).  (At the same time, the TimeKeeper worker thread is started, which is responsible for archiving/visualizing the time data.  Also, the DataCollector worker thread is started, which is responsible for archiving/visualizing the FEDM data.)  After this point, subsequent data output by the FEDM will be tagged with meaningful absolute time-reference data (previous data will have all "0" values for the time-reference fields).

Started writing the file, runmgr.py.

We managed to get some nice screenshots of PMT pulses crossing multiple thresholds for the paper:

Oscilloscope screenshot of a PMT pulse that crosses 4 out of 5 voltage thresholds,
spaced linearly at -200 mV intervals, together with the corresponding digital outputs from the threshold comparators.

We also have the data from this trace in spreadsheet form, so we can re-plot the traces for the figure in the paper if we want.  Darryl can work on incorporating this into the paper.

* * *

At home this evening, I spent a while making changes to the server code to parse FEDM messages.

Mon., Mar. 26th

David texted me earlier asking if he should come today or tomorrow - I told him tomorrow so he can work with Darryl on the paper, perhaps.

Ray stopped by to touch base on the project status.  We're hoping the ME students will get the wall/ceiling mounting brackets installed at CLC before the end of next week, and also get the electronics boards mounted to the chassis before the Senior Design Fair.

Juan is here, and I suggested he work on the Acer instead of the VirtualBox since it is faster, and loaned him my 8GB USB flash drive so he could transfer the files.  He is doing that.

Aarmondas is here, maybe I can start taking him through some things that need to be done on the Python code.  I re-shared the Server Code folder with him and it is downloading onto his laptop.  He's also installing Python v.3.1.4.

I saw some glitches in the 300 MHz pulseform-capture system when I tested it the other day; I wanted to work on that today (or soon).

Some things to do (coming up) on the server code:

• Put FEDM messages into data structures; publish them using the Publisher interface.
• Finish the startup sequence coding (automatically start CTU after FEDM is ready)
• Write some simple early visualization modules - e.g. graphical display of CTU time data

Back to testing/debugging.  I re-soldered the jury-rigged SMA connector onto the OCXO output (it had come detached last time I was working with the CTU - I'll be really glad when Samad and I get the new OCXO board made).

Aha, forgot to add support for the LOST_PULSES message.  Did that (skeleton at least).

OK, we're still getting the glitches in the 300 MHz data.  I had an idea the other day to try to fix this, which was to add a synchronizer chain on the handshake return in pulse_cap.  Let me do that...

OK, I added a 4-stage synchronizer chain to the hs_cons inputs to both se_pulse_cap_56.vhd and se_pulse_cap_tsedge_56.vhd.  Hope 4 stages is enough!  We'll see.  Note: Adding this synchronizer increases slightly the minimum "dead time" between separate pulses we can detect on a single input channel.  At 500 MHz, the increase will be by 4*(2 ns) = 8 ns.  However, it is already quite a bit larger than this, as cs_combine already takes a few 20 ns cycles to return its handshake.

Speed of new design:  587.89 MHz (high-speed components only); 353.23 MHz (whole design).

The change seems to have done the trick WRT eliminating the glitches.  The data we're collecting at 300 MHz looks clean now.

Aarmondas is looking at a couple of possible solutions for the database:  SQLlib (in Python), vs. MySQL.  I told him he should consider which approaches are most flexible in terms of allowing us to actively query the database from another process while the main server is still writing data to the database.  A separate database server process might be needed to do this (if we don't want to integrate a SQL server into the main server app).