Mon., Nov. 7th

Dr. O'Neal is out today because of a family medical situation.  Unfortunately, timesheets are due today because of the Veteran's Day holiday this Friday.  I don't know if Dr. O'Neal will be back soon enough that Sonja can still process timesheets for this pay period.  Darryl and I left ours in a folder on his office door so that he will see them as soon as he gets back to campus.  UPDATE: He texted he's on his way in; but, if he's not here by about 4:00, I'll run the timesheets over to Sonja unsigned so that she has time to enter the data.

George C. and Pascal D. (two of the ME Senior Design students) will be in the lab later this afternoon, around 3:30 or 4 or so.  I guess we'll discuss any issues relating to the enclosure/supports, and maybe they can do some temperature measurements.

I finished reading and marking up the Senior Design students' Project Proposal report over the weekend, and will give it back to them with my comments on it, along with my evaluation sheet, on Thursday.

I'm going to email Reed about the above/below ceiling issue, and the issue about him limiting us to only use half the classroom .  OK, did that; CC'd Ray and Michelle.

Some priorities to work on this week, from my perspective:

1. [ ] Start experimenting with LogicLock, for purposes of getting the speed back up to 500 MHz.  I should maybe also consider reverting to the original design with the double-edge-triggered carry-save counters, if that can be done while preserving high frequency.  However, I perhaps need to be careful here not to duplicate work of the Senior Design students too much.  However, it's difficult for them to do all of this work by themselves outside the lab, since they need the Stratix II license to be able to do the timing analysis.  Not quite sure yet re: the exact division of labor here.
   
2. [ ] Aarmondas is supposed to come by this week (Tuesday, with Juan and Michael D.?) so that we can start going over the design of the new input-capture datapath for the timing sync edges.  The interns (Darryl & David) can hopefully help w.r.t. bringing the new students up to speed on this.
   
3. [ ] We need to assemble the 3rd detector apparatus (gun case), and do some test runs with 3 detectors.  One thing we're missing is a coaxial cable to go inside the gun case, of the exact same length and type as the existing cables.  Their part number is 012125600 from Tektronix.  Sent them an RFQ thru their website.
   
4. [ ] The serial connection from the FEDM board is in pretty good shape now, but at some point I need to start working on similarly cleaning up the serial connections from the DE3 board (GPS app board) to its Wi-Fi board and GPS module.  
5. [ ] Also, we might want to remove the GPS kit's board from its protective (yellow and black plastic) enclosure since that will be redundant once it is inside our overall electronics enclosure.  The rubber feet on the enclosure can be removed to reveal the screws that need to be unscrewed to take apart the enclosure.  Sometime, we also need to address how the GPS kit will be powered exactly (barrel plug vs. USB connector, vs...)

I used the label maker to make some nicer-looking labels for gun cases #1 & #2.

George came by and took temperature measurements of the FPGA and the voltage regulators while the current FEDM firmware was running (without the cooling fan).  Of course, without the fan, the FPGA kept overheating and resetting itself, but at least this gives us some idea what the peak temperature would be currently without a cooling system.  The FPGA got up to about 50 C (122 F).

Also, George asked for mechanical details for all the boards.  I had given this information to Pascal earlier (I think I emailed him the docs), but for some reason Pascal apparently never passed this information along to George, because George didn't know about it!  (Tsk, tsk!!)  So this time, I just posted the key documents on the group blog so that everyone will have it.  The students really need to do a better job of sharing all pertinent project information with each other!  Everything relevant needs to go on the group blog, so everyone will have it!

George also didn't have access yet to the FEDM_design Dropbox folder, so I added him to the share list.

Pascal couldn't be here today because of a doctor's appointment.

George said he would come by again later in the week.

Changed nodeid.txt of EZURiO board #1 from 0 to 1, in preparation for running it simultaneously with EZURiO board for the CTU which will have node ID 0.  This was somewhat involved:

• Remove blue wire (M_RX) from pin #25 of J2 header of WiFi board to disable input from FEDM.
• Remove purple wire (+3V out) from pin #27 of J2 and connect it to pin #1 of J10 (GND) instead.  This re-enables external serial input from PC.
• Remove yellow wire (M_DSR in from FEDM) to disable script autorun
• Connect serial cable to COM1, start up UwTerminal, with DTR checked (no autorun).
• Power up FEDM (supplying +5V power to WiFi board).
• Use UwTerminal to Add File with the new version of nodeid.txt.

After this, oops, the AUXIO and UART bridge connections are no longer successfully opened, although the MAIN connection is still opened!  This may be a problem with the port numbers.  Let's examine C:\SHARED\Server Code\mainserver.py.  Oh, that's right, it dispatches command handling to commands.py.  The POWERED_ON message goes to the handle_node_on() method of CommandHandler.  That in turn dispatches to the sensor-net model, in model.py.  turnOn() is called on the newly-created node data structure, and this calls _setupBridgeServers() which adds the node number to the base port number.

Checked the server logs and it seems the port number is getting incremented twice for some reason.  Aha, bridge.py increments it again, and we are passing in the already-incremented number.  OK, fixed that problem.  Restored the normal connections between FEDM & WiFi board.

I had a task from last week to decrease the startup time for the WiFi board, so that the FEDM doesn't get hung up trying to communicate with it before it's ready.  Some ideas for this:

• Turn off info-level logging to the server in the WiFi script.
• Turn off the default help menu display (user can always type "help" to see it anyway, if needed).
• We can probably also somewhat decrease the 1-second delay where we wait for the server to open listeners on the bridge ports allocated for the node after receiving the node's powerup message.  Half a second may well be enough if the server isn't heavily loaded.  Anyway, the connection attempt should automatically retry for a while, so even if it doesn't work the first time, no big deal.

Also, we can add a delay to the FEDM, and/or add a protocol whereby the FEDM actually waits to receive the startup message from the WiFi module, and/or bounces a ping off the server.

Also, note to self: After the node number that's active on a given MAIN server connection is identified, the title of that connection window should really be updated to reflect this. (Add "(Node #1)" or something like this to the window title.)  This should be a pretty easy change to the server code.

Sat., Nov. 5th

I am wondering whether it might be best to locate the detectors farther apart in the building at CLC, to improve our angular resolution.

I got a building outline from the Leon County GIS.  It is not very detailed, but it gives you some idea of the building size and layout.  Here are a couple of views (click to zoom):

Building plat with image overlay from
Property Appraiser GIS.  This one has
dimensions of various line elements.

Building plat with image overlay from
Base Map GIS.  This one has terrain contours.

I have overlaid on these a triangle showing one (potentially) possible arrangement of detectors for maximum spacing.  The long side of the triangle is about 185' and the shorter sides are about 150'.  Altitude of the building is about 190' above sea level.

Here is another, slightly higher-resolution image from Google Earth:

Another aerial building image, from Google Earth.

For future reference, the location of the push-pin is 30°26'25.32"N,  84°17'0.22"W.  Google agrees that the altitude there (where the ground used to be, I assume) is about 190' above sea level.

Finally, here's another, even higher-resolution, but skewed, image from Google Maps:

Aerial or satellite image from Google Maps.

According to Google Maps, the coordinates of the green arrow are 30.440406, -84.283404.  Converted using http://www.gpsvisualizer.com/calculators, that is N30°26'25.462", W84°17'0.254", i.e., within less than 1 second of arc of the Google Earth coordinates from earlier.  A second of latitude is 101 feet and a second of longitude at this latitude is about 87'.  Based on the differences of 0.142" and 0.034", we're within ~14' on the N-S axis and about 3' on the E-W axis.  The larger N-S difference can be accounted for by the fact that the aerial photos were taken at different angles, so it was hard to eyeball where the green arrow should be.

After we install our GPS unit, we should take long-term averages of the position readings to get a more accurate idea of the position of the antenna.  (We could include code for this in the server, and test it here in the lab.)

Fri., Nov. 4th

The Senior Design students gave their Project Proposal presentation today.

Samad (EE guy) & the ME students proposed to distribute wired +12V power from the DE3 supply to the detectors via conduits above the ceiling tiles.  That sounds fine.  The coax signal cables (for phase 1) can also follow the conduits the other way, back to the central electronics unit.

There seems to be a disconnect with CLC regarding whether the detectors will be visible to the public - Reed wants to put them above the ceiling panels - but the whole point of locating them in the classroom to begin with is so that they would be visible to students - Ray and I need to talk to Reed and straighten this out.  Reed may not be aware of what the original agreement with CLC was.  Also, Reed wanted the detectors in only half of the classroom, but we need them to be spread out as far as possible to improve our angular resolution.  If they can't hang below the ceiling in one room, then they might as well be in different rooms from each other, or even farther apart, on opposite sides of the building, say!  

Brian Kirkland is coming by the lab on Monday to discuss the cooling system design (which needs some work), and the computer engineering students (including Aarmondas) are coming by on Tuesday to discuss next steps on the gelware, such as the new timing datapath and the performance optimizations.

Also on Monday, Ray and I may work on putting together the 3rd detector.  We have another long BNC-to-SMA 50-ohm coax, but we need another short 50-ohm BNC-to-BNC coax to go inside the gun case (same length as existing ones).  A new cable of the right length may still need to be ordered.

Turns out, according to Reed, there is an easy solution for the GPS antenna (run it along the same path as the connections to the roof solar panels), but we probably still need to order a new antenna with a longer antenna cable.  Need to contact DeLorme about this to see if we can order the new antenna cable through them, or if they can recommend a supplier of these.

I spoke with Michelle (director of CLC) this morning at the COE faculty meeting, and thanked her for her support, and apologized for missing Reed's replies to my earlier emails (which happened when my FAMU email was failing to be pulled by my gmail due to an outdated password).

Wed., Nov. 2nd

Plan for today is as follows (or at least, as far as we can get on this):

1. [/] Recompile latest firmware into gelware image (.sof/.pof files).
2. [/] Burn new .pof file to EEPROM (set as baseline code to revert to on power-up).
3. [/] Import files from Juan & Mike's new 56-bit version of datapath into master project folder.
4. [/] Do a test compile; fix any problems.
5. [/] Inspect space remaining (all types) after fitting.
6. [/] Check maximum PLL clock speed in timing analyzer.  Increase PLL clock speed if possible.
7. [/] Determine whether further compression of datapath will be necessary to add 3rd datapath.
8. [/] If not, add 3rd pulse-capture datapath to design
9. [/] Wire up LVDS inputs for "PMT #4" input to 3rd datapath (if not already).
10. [/] Recompile design with 3rd datapath, check space remaining & maximum clock speed again.
11. [/] Use Dremel tool to file down a 3rd SMA connector, populate it on "PMT #4" footprint.
12. [ ] Work with Ray to set up 3rd paddle/guncase assembly, connect it to board.
13. [/] Adjust firmware to look for data on all 3 input capture datapaths (currently it just checks 2).
14. [,] Do a first run gathering data from all 3 detectors!  This will be the acid test of the new 56-datapaths, to make sure that none of those design changes screwed up the functionality.

Here we go:

Task 1.  Starting Quartus license server.  Starting Quartus on Q:/COSMICi_FEDM.qpf project, New_with_Nios_trim revision.  Starting full compile with the latest .hex files (hexadecimal memory initialization files containing the latest compiled firmware).  This will take a while...

It occurs to me that it might be nice, at some point, to introduce a version identifier for the gelware too; this could be implemented as (for example) an LPM_CONSTANT megafunction that feeds a PIO input to the Nios core, which the C code can read and then report in the FEDM_STARTING message.

Compile successful (of course; nothing changed but the .hex files).  Some stats:

• Slow corner fmax for high-speed counter:  211.28 MHz
• Logic utilization:  24,314/27,104 (90%) =  2,790 remaining
• Dedicated logic registers used:  21,878/27,104 (81%) = 5,226 remaining
• M512 blocks: 193/202 (96%) = 9 remaining
• M4K blocks: 144/144 (100%) = 0 remaining
• M-RAM blocks: 1/1 (100%) = 0 remaining (but we may be able to use a bit more of the space)

Task 2.  Starting C:\SHARED\Server Code\COSMICi_server.py; it pops up its windows.  Powering up Mastech supply at ~4.5V driving fan (on metal block on FPGA), and then powering up Agilent supply at 5V driving FEDM + (via FEDM) WiFi board.  Total current draw: 2.11A.  Actually it just occurred to me I could power the fan from the same supply.  Now the total current draw is about 2.21A peak (fluctuating due to the EMF feedback from the fan motor).  Hope the voltage level isn't too unstable for the application.  It seems to be fine.  A new set of windows popped up of course when I power-cycled (b/c the Wi-Fi drops the old connections).  OK, let's burn the new firmware in there.  Switched burner to Active Serial mode, selected New_with_Nios_trim.pof file, added ByteBlaster hardware, doing program/configure + verify.  Finished programming; new firmware (0.7) is now installed and running.

Task 3.  I think I put Juan & Mike's new code into the C:\LOCAL\q91_56\ folder.  I need to copy all the _56 design files from there to Q:\, and then merge their changes to the toplevel schematic into a new version of my toplevel schematic, and then set it as the new toplevel file.

Let's do this in Cygwin.  cd to /cygdrive/c/LOCAL/q91_56 and type "ls *_56.*", and get:

COSMICi_FEDM_top9_56.bdf
FIFO_reader2_56.bsf
FIFO_writer2_56.bsf
cs_combine_56.bsf
cs_combine_56.vhd
cs_combine_56.vhd.bak
fifo_reader2_56.vhd
fifo_reader2_56.vhd.bak
fifo_writer2_56.vhd
fifo_writer2_56.vhd.bak
hspeed_counter_56.bsf
hspeed_counter_56.v
hspeed_counter_56.v.bak
our_fifo2_56.bdf
our_fifo2_56.bsf
our_fifo_v3_56.bdf
our_fifo_v3_56.bsf
pmt_ic_datapath2_56.bdf
pmt_ic_datapath2_56.bsf
pmt_ic_datapath_v3_56.bdf
pmt_ic_datapath_v3_56.bsf
pulse_cap_56.vhd
pulse_cap_56.vhd.bak
pulse_combine_56.bsf
pulse_combine_56.vhd
pulse_combine_56.vhd.bak
pulse_prep_56.bdf
pulse_prep_56.bsf
pulseform_FIFO_v2_56.bsf
pulseform_FIFO_v2_56.qip
pulseform_FIFO_v2_56.vhd
pulseform_cap_56.bdf
pulseform_cap_56.bsf
se_pulse_cap_56.bsf
se_pulse_cap_56.vhd
se_pulse_cap_56.vhd.bak
se_reg_en_56.vhd
se_reg_re_56.vhd
se_reg_re_56.vhd.bak
stream_pulse_data_56.bsf
stream_pulse_data_56.vhd
stream_pulse_data_56.vhd.bak

Great.  Now doing "cp *_56.* /cygdrive/q".  That is done.  Now in Quartus, opening for inspection "COSMICi_FEDM_top9_56.bdf", which is their new top-level file.  Basically, the only thing that should be changed in it is the new datapath implementations, pmt_ic_datapath2_56 (M512 fifo block type version), and pmt_ic_datapath_v3_56 (Auto fifo block type version).  

Oops, they forgot to create pulseform_FIFO_56 using the M512 blocks, use pulseform_FIFO_56 in their our_fifo2_56, and use pulseform_FIFO_v2_56 in their our_fifo_v3_56.  Did that for them.

Created new _top11 version of top-level schematic, added appropriate version comment, replaced the two ic datapath blocks with their new versions. Also replaced hspeed_counter with hspeed_counter_56.

Task 4.  Doing test compile...  Oops, forgot to replace the high-speed counter with new version.  Fixed that.  Forgot to add some .vhd components (not automatically included) to project.  Fixed that.  This is going to take a while, so I'm going to get a soda...

Compilation successful!

Task 5.  Let's look at the stats:

• Slow corner fmax for high-speed counter:  213.13 MHz (only slightly better)
• Logic utilization:  22,007/27,104 (81%) =  5,097 remaining (almost 2x as much left)
• Dedicated logic registers used:  19,463/27,104 (67%) = 7,641 remaining (about 25% better)
• M512 blocks: 188/202 (93%) = 24 remaining (more than 2x better)
• M4K blocks: 144/144 (100%) = 0 remaining (same as before)
• M-RAM blocks: 1/1 (100%) = 0 remaining (same as before)

This is, I think, about as I had expected. 

Task 6.   It's not yet possible to increase the PLL speed.  Will probably need to use LogicLock first.

Task 7.   Let's look at the resource usage of each ICDP now:

pmt_ic_datapath2_56 (M512 version, 4 pulses):

• Block memory bits:   2,700
• Combo ALUTs:          2,442
• Logic registers:          5,598
• M512 blocks:             38

pmt_ic_datapath_v3_56 (Auto version, 8 pulses):

• Block memory bits:    0
  
• Combo ALUTs:           2,410
  
• Logic registers:           11,576
  
• M512 blocks:              0

I don't think further compressions of the datapath will be needed.  The actual FIFO in the latter one is 6,083 logic registers, so if we cut it in half, we might save about 3,000 logic registers, I think at this point we might be able to fit two copies of it in the design.  Let's try.

Task 8.  Added 3rd input capture datapath on channel 2 of type pmt_ic_datapath_v3_56.

Task 9.  Wired up its LVDS inputs, skipping the one for DAC #2, as with the other datapaths.

Task 10.  Starting Quartus compile.  Compile successful!  Let's look at the stats:

• Slow corner fmax for high-speed counter:  212.49 MHz (only slightly better)
  
• Combinational ALUTs:  10,017 / 27,104 (37%)
• Dedicated logic registers used:  25,678/27,104 (95%) = 1,426 remaining
  
• Logic utilization:  26,664/27,104 (98%) =  440 remaining
  
• M512 blocks: 188/202 (93%) = 24 remaining (same as with 2 datapaths)
  
• M4K blocks: 144/144 (100%) = 0 remaining (same)
  
• M-RAM blocks: 1/1 (100%) = 0 remaining (same)

We probably will still need to free up some space before we can add the extra timing-sync edge-capture datapath.  We might conceivably be able to do that by getting rid of extra_RAM, and using more of the M-RAM (extra 8K in there, not currently allocated to anything).  If not, then we will have to shrink down the main input capture datapaths (and/or the firmware code size) further.  We could recompile with optimization for minimum code size turned on, and see if that lets us shrink the size of our RAM blocks.

Task 11.  While compile was running, Dremeled down the pins of another SMA connector to fit the thru-hole footprint.


Task 12.  Ray is out swimming.  Texted him that we need the 3rd guncase soon.


Task 13.  Back now in the Nios II design tools for Eclipse IDE, changed the value of NCHANS_TOBUF from 2 to NCHANNELS (i.e., 3) in pulsebuf.c.  This should cause the coincidence detector to now expect to receive pulses on all 3 input channels, and look for coincidences between any pair of them.  (Further filtering for 3-way coincidences can be done on the server side.)  I'll wait to recompile with this option until the Quartus compile is working.  OK, that's done now; recompiling the project.


Task 14.  Testing will have to wait until we get the 3rd detector hooked up.  I want to talk to Ray about that before putting it together to make sure it's OK with him to use a given paddle.  Well, we could hook the board up and test it with just two detectors, but that will confuse the coincidence-detection algorithm.  In the meantime, while waiting for the 3rd detector, I could perhaps start working on adding stuff to the gelware to allow us to positively verify the absence of a pulse in a given time interval.  Actually, it might be a good idea to first just do a test with the 56-bit version using just the first two channels.  Or, I could synthesize fake pulses on the new channel!  That last idea is probably best.

Doing another Quartus compile to pull in the new .hex files (to support the triple datapath).

Just remembered there are a couple more places in the firmware where I assumed there are only 2 input channels.  Going back & fixing those now...  In the NONCOIN_PULSES message...  Was that it?  I think so... Recompiling firmware & Quartus design again.  In the last compile, Quartus hung in the assembler (as it sometimes does).  Killing it and restarting.

Meanwhile, I hooked up the function generator to the "PMT#4" input port (which we're using as the new channel 2).  It is now outputing a 100 Hz, inverted, +2.5V pulse with 100 ns pulse width, 20 ns rise time, and 130 ns fall time, which makes it an asymmetric triangle (sawtooth) pulse.  Checked the pulse profile on the scope to make sure it looked OK.

Just remembered, I forgot to add the DC bias jumper for the new input port.  Checking the OrCAD schematic to confirm which one it was.  It is J63.  Adding an orange Adafruit F-F jumper there (I am out of bridges). Now I am ready to test, as soon as the Quartus compile finishes.  There, that's done.  JTAG programming new design... It's running.  Seems to be working as expected.  Here's an output sample:

Wed Nov 02 18:00:16 2011 + 636 ms: <
Wed Nov 02 18:00:16 2011 + 637 ms: < FEDM_STARTING,v0.8
Wed Nov 02 18:00:16 2011 + 842 ms: <
Wed Nov 02 18:00:16 2011 + 842 ms: < DAC_LEVELS,-0.200,-2.500,-0.299,-0.447,-0.669,-1.000
Wed Nov 02 18:00:16 2011 + 843 ms: <
Wed Nov 02 18:00:16 2011 + 843 ms: < FEDM_READY
Wed Nov 02 18:00:17 2011 + 915 ms: < NC_PULSES,245837961,201,100,123
Wed Nov 02 18:00:19 2011 +  37 ms: < NC_PULSES,469189411,203,90,112
Wed Nov 02 18:00:20 2011 + 223 ms: < NC_PULSES,706924408,201,90,119
Wed Nov 02 18:00:21 2011 + 456 ms: < NC_PULSES,954722914,205,94,123
Wed Nov 02 18:00:22 2011 + 670 ms: < NC_PULSES,1196743610,203,107,122
Wed Nov 02 18:00:23 2011 + 793 ms: < NC_PULSES,1422506353,202,98,112
Wed Nov 02 18:00:24 2011 + 873 ms: < NC_PULSES,1638620374,200,96,108
Wed Nov 02 18:00:26 2011 +  66 ms: < NC_PULSES,1876744706,200,94,120
Wed Nov 02 18:00:27 2011 + 371 ms: < NC_PULSES,2136745128,202,121,130
Wed Nov 02 18:00:28 2011 + 756 ms: < NC_PULSES,2414745580,203,104,139
Wed Nov 02 18:00:30 2011 +  53 ms: < NC_PULSES,2674182865,204,108,129
Wed Nov 02 18:00:31 2011 + 226 ms: < NC_PULSES,2908746387,203,91,118
Wed Nov 02 18:00:32 2011 + 354 ms: < NC_PULSES,3134746760,204,81,113
Wed Nov 02 18:00:32 2011 + 849 ms: < PULSE,2,1,3233112444,3,(0,(1,(1,3),4),2)
Wed Nov 02 18:00:32 2011 + 850 ms: < PULSE,1,1,3233112445,2,(0,(3,1),6)
Wed Nov 02 18:00:33 2011 + 493 ms: < NC_PULSES,3361671587,200,92,113
Wed Nov 02 18:00:34 2011 + 836 ms: < NC_PULSES,3630432436,201,116,134

Explanation:  The verbose timestamps at left (before the ":") are just when the server logged the data; they are not particularly accurate as event times (at best, to the 10s of milliseconds).  The "<" means this is input from the board (as opposed to output to the board on the return connection).  The FEDM_STARTING message says that the board has powered up, and gives the firmware version number (0.8 is the new version for 3 datapaths).  DAC_LEVELS message is there as a diagnostic to tell us what are all the voltage thresholds we set (relative to the +2.5V input bias).  This is a logarithmic ramp from -200 to -1000 mV, except that the 2nd value is null (-2.5) because that DAC is broken anyway.  FEDM_READY just tells us the firmware is entering the main loop.  NC_PULSES tells us how many non-coincidence pulses we have tallied up from each input channel as of a given (fairly arbitrary) point in time; this time is marked approximately by the arrival time (first threshold edge-crossing time) of the most-recently-arriving pulse in the tallied set, expressed in cycles of the high-speed counter.  PULSE expresses actual data about a pulse that is potentially a member of a shower, i.e., it arrived within +/- 50 ns of a pulse on another channel.  The fields are: Input port number (1, 2, 3); sequence number (out of coincidence pulses reported on this port), first edge-crossing time in HS clock cycles, number of thresholds crossed (1-5), time deltas (in HS cycles) between subsequent edges.  The ones after "(" are rising edges; the ones before ")" are falling edges.

A little later in the dataset (8 minutes later), we see an accidental coincidence between one of our synthesized pulses on port 3, and a real pulse on port 1.  This is evidence that coincidence detection is working between any pair of ports (not just ports 1&2) and that as expected the synthesized pulse crosses all 5 thresholds.  Its total measured width is 38*5 = 190 ms, which is about right considering its FWHM is synthesized at 100 ns and that we miss a little of the base (before it gets to -200 mV).

Wed Nov 02 18:08:21 2011 + 129 ms: < PULSE,1,17,96886924398,2,(0,(2,2),7)
Wed Nov 02 18:08:21 2011 + 130 ms: < PULSE,3,1,96886924408,5,(0,(1,(0,(0,(1,25),4),4),2),1)

One final note:  On power-up, the Wi-Fi script currently does not start up quite quickly enough to catch all the initial output from the FEDM board - so the earliest output (including the startup message and DAC levels) gets lost.   To prevent this, the FEDM firmware needs to be changed to actually wait to receive the WIFI_READY message before it turns on the input capture datapaths and starts streaming data.  However, this could create a problem in cases where the WIFI_READY message has already been sent earlier (like when restarting the FEDM via the JTAG).  There are a couple of ways to handle this:  (1) With a timeout, or (2) if WIFI_READY isn't seen within an expected interval, have the FEDM send a "PING" message to the server, which responds with a "PONG" that gets relayed via the Wi-Fi script to the FEDM, thereby confirming to the FEDM that the wireless link is up and running.  I can also work to reduce the Wi-Fi script's startup time (a lot of it right now is just unnecessary diagnostics), or (perhaps simplest) add a fixed delay in the FEDM firmware to give the Wi-Fi board time to start up.  Think about the various possible combinations of options here, & start working on them another day.

In other news, I started looking at the Senior Design students' report, & writing comments on it.  Emailed it to Ray and he also read it.  Ray (and I) noticed some lingering confusion about the project requirements in a number of places, and a general lack of specifics about the proposed cooling system design.  The students' presentation is scheduled for Friday, so we can give them our verbal feedback then.  I am hoping to get my written feedback done by tomorrow, so we can return the graded reports in class.

Tue., Nov. 1st

The specs of last night's run are as follows:

• SMA#1 <-- Gun Case #1 @ North end of room (near interior hallway)
• SMA#2 <-- Gun Case #2 @ South end of room (near window)

Both paddles were set to use an HV supply of 1,200 V (last I checked).

The start and end times on the run (current cut) are:

• Start:  Mon Oct 31 18:00:18 2011 + 835 ms: < DAC_LEVELS,-0.200,-2.500,-0.299,-0.447,-0.669,-1.000 (logarithmic ramp)
• End:  Tue Nov 01 14:40:51 2011 + 166 ms

Total length of run:  20 hrs, 40 min., 33 secs. = 1,240.5 mins. (approx.)

Number of pulses:  4,136
Number of pulse pairs:  2,068 (assuming all pulses were in pairs instead of larger clusters)

Rate of showers:  1.67 showers/min.  Tweeted about it.

Histogram of pulse heights:

• 1 threshold (200-300 mV) => 954 pulses
• 2 thresholds (300-450 mV)   => 2,244 pulses
• 3 thresholds (450-670 mV)   => 721 pulses
• 4 thresholds (670-1000 mV)   => 216 pulses
• 5 thresholds (>1000 mV) => 1 pulse - but time values were scrambled; probably have to disregard

Anyway, here's a plot of that data:

Rough histogram of pulse heights in last night's 20-hour run.

And (after running anal-pulses.sce on the data file), here is the histogram of the absolute time differences:

Histogram of time differences between the two detectors on last night's dataset.

For absolute time differences of 40 ns and above, the count of coincidences levels off, to the range 20-22 per 5 ns wide interval.  This is presumably the background rate of coincidences due to random happenstance.  For time differences of 35 ns and below, the rate is substantially higher, indicating that these are "genuine" concidences due to passing showers.  The detectors are only about 22 ft apart, which makes the existence of genuine coincidences with time differences at and above 25 ns somewhat mysterious.  Either the shower fronts are moving significantly slower than light, or the pulse amplitudes or rise times at the two detectors are substantially different, or some other, unidentified source of error is smearing out the measured arrival times of the pulses.  If the shower density is low, the amplitudes could be different due to shot noise in the number of shower particles intersecting the paddle area.  Low particle-number fluctuations could also more directly affect the arrival time of the pulse, since the shower front pancake has nonzero thickness; one detector might see a particle near the leading edge of the pancake, the other one a particle near the trailing edge.

It would be interesting to see if these anomalous time differences persist even after we are doing pulse shape reconstruction with its more precise identification of the pulse peak time.

Tomorrow Ray wants to do another histogram test on the scope with the overlapping orthogonal paddles, but this time with the paddles intersecting closer to the middle of the paddles rather than at their far ends.  This will maybe help us distinguish any effects due to differing light transmission properties of the two scintillator materials.

Mon., Oct. 31st

Need to change my FAMMail password again soon.  Remember this time to also change it in Gmail!

Ray called Mentor about the status of the donation and they asked him to forward the licensing agreement to someone who has legal signing authority on behalf of the university.  Ray is sending it to the General Counsel's office.

Ray said I can go ahead and start testing coincidence detection.  His pulse height peak in the current configuration (90 degree overlapping orthogonal paddle ends, 30" apart, 3 ns arrival time filter) was 241 mV for the paddle with the higher peak, and 236 mV for the lower peak.  (Bias voltage still 1,200 V.)  He suggests we set the first threshold at 200 mV.

I should perhaps change the firmware to count and periodically report the number of non-coincidence peaks, so we can see how many of them we are skipping.

I could perhaps integrate the (56-bit) changes by Juan and Michael Dean into the Quartus design before I test my code, but perhaps I'll wait; it might be better to just test one thing at a time.

Started "Nios II 9.1 Software Build Tools for Eclipse;" switched it back to my main workspace for the FEDM project ("Q:\eclipse_workspaces\mpf_workspace").

Opened pulsebuf.h and uncommented "#define FILTER_COINS"; this enables compilation of the code for coincidence filtering.

Edited pulsebuf.h and pulsebuf.c to define macros for normal & error return codes from pb_get().

Modifying server_stream_pulses() in pulsebuf.c to just count up the non-coincidence pulses, and output the counts periodically.

The guys helped me hook up the paddles on opposite sides of the room and tested.  That is working now, as far as it goes, except that for some reason I am seeing isolated pulses reported as coincidences - this should never happen, right!  Anyway, debug later.

Got David & Darryl started on calculating the standard deviation of the triangle distribution representing the analytical distribution over actual pulse widths for a given measured pulse width.

Found the bug in my coincidence detection code - forgot to update last_pulse_time[] when pulling pulses from the queue.  That's fixed now.  Started an overnight run.

Wed., Oct. 26th

Ray reminded me to respond to Sachin's email.  Looks like I didn't receive it because Gmail hasn't known my FAMmail password since June!  Fixed that, and scanning the email subjects to see if I missed anything else important...  Aha, replies from Reed Lambdin, and some emails about Zemax.  Anyway, replied to Sachin just now to see if he can continue to give us advice as we modify the board design.

Today I'm going to try out the Wi-Fi board with the new 40-pin header for the hand-wired serial port.

Regarding DSR, apparently I did indeed have it wrong in the original rat's nest - pin 10 (not 11) *is* DSR.

On the new Wi-Fi board (labeling it "#1"), I need to hook up pins 1+2 of J10 temporarily to ground the /EN input of U3, i.e., to enable the level-shifter on the main serial input so I can configure it from the PC.  Using one of my new Adafruit jumpers (a purple one) since I am short on jumper bridges.

Starting UwTerminal on COM1.  Hooking up serial cable (#1) from PC to main serial input.  Hooking up USB power.  Switching board on.  Get the usual "\00\00" as the serial port initializes (sending null bytes).  Hit enter and get the usual "00" prompt.  Enter "at" and get it again.  Enter at+dir and it looks like all the files are there.  However, I'm not sure if this board really has the most recent version of the script, so I'm going to re-burn it.

Entering "at & f *".  Get "01 E03C MEDIA_CORRUPT" as expected.  Power-cycle.  Board now back to just factory.def.pc in the filesystem.  Entering at+set 42="128", 40="1000", 41="1000" (three separate at+set commands).  I hope this board has the right version of the firmware!  Now, Download->Data->Data File+ on nodeid.txt and strings.txt in the "My Dropbox\FAMU\COSMICi\Wi-Fi Script" folder.  Then do Cross-Compile+Load on "autorun.uws" in that same folder.  Now loading.  I think the firmware version is right, or the cross-compiler wouldn't have worked.

OK, got everything in there now.  Now, start the server (C:\SHARED\Server Code\COSMICi_server.py).  Server is up and running.  Now, let's test the autorun feature.  First, we'll test with the control coming from the PC.  With DTR checked in UwTerminal, we'll power-cycle the board.  No autorun!

Now, uncheck DTR in UwTerminal, and power-cycle the board again.  That worked; we got the 3 TikiTerm terminals popping up.

Let's now disconnect the serial cable from UwTerminal, and try just manipulating pin 10 of J2 (DSR, new yellow jumper).  First, typing "exit" command over the wireless, so script exits to 00 prompt.  Next, re-routing pin 2 of J10 (purple jumper wire) over to pin 27 of J2, which is 3Vout from the module.  Now, we'll power-cycle again.  That worked, and the autorun activated.  Again, this could be due to a pullup resistor on DSR.

To test this, let's try wiring the DSR input to ground.  Pin 38 of J2 is a ground pin.  Plugging the other end of the yellow wire into that.  Now, power-cycle again.  This time, the autorun did NOT activate!  This confirms that setting DSR to *high* is what activates autorun (matches the documentation).  Also, it tells us that when a box is "checked" in UwTerminal, the corresponding logic signal gets set LOW, not high.  So the checkbox in UwTerminal is telling us the line level, not the logic level.  And pin 10 of J2 is indeed the right pin.

With all this confirmed, we are ready to wire up our new logic-level serial "cable" (really just a wire bundle) to the FEDM board.  The pins are nicely labeled in the male socket on the board.  So we can just plug directly into that, as follows:

• Black     - Common GND (Pin 5)
• Red        - WiFi M_TX --> RxD on FPGA (Pin 2)
• Blue       - WiFi M_RX <-- TxD on FPGA (Pin 3)
• Orange   - WiFi M_RTS --> CTS on FPGA (Pin 8)
• Green     - WiFi M_CTS <-- RTS on FPGA (Pin 7)
• Yellow   - WiFi M_DSR <-- DTR on FPGA (Pin 4)

Now, looking at the OrCAD schematic, pin 4 (DTR) on the FPGA side can be tied to ground through J50, but really we want to tie it to Vcc to make sure autorun is enabled.  So instead, we can use J46 to tie it to pin T7 of the FPGA, and then set it in firmware - maybe!  But will it be set soon enough?  It takes some time for the design to load from EEPROM.  Really, we want it to be high as soon as the boards power up.  So let's identify a +3V line we can connect to instead.  Node +3.3VDOWN is available on pin 1 (top pin) of JP12.  So, connect a yellow wire (representing a constant ~3V signal) from there to pin 1 (right pin) of J46.  Now we can hook up the pins above directly to the connector.

A thought: Should we go ahead and try supplying the +5V power through RI (pin 9) as planned?  If we want to avoid actually clipping the metal loop jumper on pins 1 & 2 of J8, and soldering a new bridge between pins 2 & 3 of J8, however, we cannot actually supply it there, i.e., on PC_RI (which is really on the DE9 connector J7, anyway).  The +5V can also be supplied on the tip of the barrel plug (J6), and on pin 3 of JP3, which is a bare thru-hole at present (not populated).  It does NOT come in on J2 at all!  (So my old orange RI/+5V input wire on my old Wi-Fi board #3 rat's nest was totally wrong-headed.)

I'm thinking the easiest thing might just be to solder a new male pin header onto pin 3 of JP3, and connect to that - that way I don't even need to use the barrel plug.

Clipped a new male pin header off of the extra-long, double-ended ones I got from Adafruit, and soldered it on there.  Connecting a white (for "white-hot" +5V) F-F jumper wire to that; will add it to the serial "cable" (bundle of jumper wires).  So now we have:

• Black     - Common GND (Pin 5)
• Red        - Wi-Fi M_TX --> RxD on FPGA (Pin 2)
• Blue       - Wi-Fi M_RX <-- TxD on FPGA (Pin 3)
• Orange   - Wi-Fi M_RTS --> CTS on FPGA (Pin 8)
• Green     - Wi-Fi M_CTS <-- RTS on FPGA (Pin 7)
• Yellow   - Wi-Fi M_DSR <-- DTR on FPGA (Pin 4)
• White    -  Wi-Fi DC_IN <-- "RI" (really +5VCC) from FPGA (pin 9)

So, I hooked up all these connections to the FEDM board just now, and tested it by switching on the Wi-Fi (and then switching on the +5V power to the FEDM), and it worked perfectly!  The Wi-Fi board ran the autorun script, popped open its windows, sent the "WIFI_READY" message to the FEDM, and the FEDM sent the acknowledgement back via the Wi-Fi board to the UART bridge window.

The new, simplified, neat-and-pretty version of the detector electronics.
At left: FEDM board.  At right: EZURiO Wi-Fi dev. board.  Look ma, no wires!

At some point, we need to change the FEDM firmware (as well as that of the GPS app) so that it waits to receive the "WIFI_READY" message from the Wi-Fi board before it starts transmitting data - this is to make sure that its early output doesn't get lost in the serial input buffers of the Wi-Fi board before the Wi-Fi autorun script has finished configuring the bridge connection to the server.

Juan C. and Michael D. came by and delivered their code for the 56-bit version of the datapaths.  We started a compile and fixed a few bugs till it got past synthesis.  However, it later stopped in the fitter because the device was not set.  However, the code is now I think ready to import into the main folder.  The changes in the top-level file need to be merged into my latest top-level file.