Wed., Nov. 9th

Ray and I are planning to go over to the Challenger center at about 4:00 pm, to meet with Reed to finalize the issue of the detector locations.

Samad is coming by soon to talk about the power supply some more.  I emphasized to him the importance of building proper connectors to connect the power supply (and batteries) to other components.

Samad needs to get me quotes for the batteries, battery charger, and any connectors so that I can issue a requisition for them.

Also, the mechanical students need to design structures to hold the power supply INSIDE (not outside) the main electronics box, for neatness, and there should also be a little battery-holder box installed on one of the detectors (for a battery-powered detector demonstration).  Mechanicals need to coordinate with Samad on the requirements for this.

Cooling of the ambient interior temperature of the main electronics box should not be a problem, even with the power supply inside, as long as there is airflow with vents/fan.  Total system power dissipation is not all that large (20-30 W, laptop range).  Main requirement for cooling is a good heat pipe from the FPGA to the Peltier plate, to get the FPGA as close as possible to the cool end of its 0-85 C operating range.  And positioning the plate so any drips go into a tray and not onto the electronics.  Mechanicals should look into sealing all cold exposed metal parts inside a polymer/resin skin, spray-on perhaps, to reduce condensation.

Reed had to leave CLC before we arrived, but his assistant was there.  It looks like hanging the detectors below the ceiling is OK as long as they do not dangle down more than about 1' or so - ceiling height is 9'2".  Main concern is that people don't hit their heads.  Also, there are sprinkler clearances and location of above-ceiling girders to consider.  Requested blueprint for other half of room - Brian said Pascal had one half already, but it needs to be scanned and uploaded to the group blog so everyone can see it.

Brian is thinking now of arranging all boards on one plane, instead of using the blade approach.  This is probably a good idea since it will reduce the vertical profile of the enclosure.   Height of enclosure should probably be no more than 14".

Also, I discussed with Brian that the enclosure should NOT have RF shielding, since the Wi-Fi communication needs to pass through.  I don't think we're too worried about interference.  Also for educational purposes it would be nice if the electronics was visible.  We agreed that probably best is if 5 out of the 6 faces of the enclosure were transparent plexiglass (except where the exhaust fan and Peltier cooler are installed, obviously), and the other face can be metal that all the boards are bolted to (everything mounted upside-down under it).  That way, students can see all the electronics, and any indicator LEDs on the boards.

Tue., Nov. 8th

Ray and I are planning to go over to CLC at about 4 pm on Wednesday to talk with Reed about positioning of the detectors.  I created a Google Calendar event and sent them both an invite.

Ray points out that the highest-energy showers have a narrower area at ground level, so placing the detectors as far apart within the building as possible might not be the best approach.  He is going to ask Helio to help us find information about how the shower area varies as a function of primary particle energy.

Some things I could work on today:

• [/] Requisition for Tektronix BNC cables - submitted
• [,] Shrink existing design to make room for timing sync capture datapath (reduce code size, use more of M-RAM)
• [ ] Solder headers to 2nd Wi-Fi board, wire up its serial connection
• [ ] Reduce startup time of WiFi script / Increase startup delay of FEDM

I guess the quickest way to get the startup sequence working is just to add a delay to the FEDM firmware - we can always go back and optimize things later to reduce the delays on both sides (WiFi & FEDM).

Added a 20-second startup delay to the firmware in Q:\software_v4\FEDM_ctrl_fw; this firmware version is 0.9.

Incidentally, the linker space usage summary is as follows:

Info: (FEDM_ctrl_fw.elf) 69 KBytes program size (code + initialized data).
Info:                    62 KBytes free for stack + heap.

This might be a good time to try shrinking the code size.  Let's compile with space optimization.  In Nios II Design Tools for Eclipse, right-click fedm_ctrl_fw_bsp, select Nios II --> BSP Editor.  No, that's not it.  Select Properties instead from the pop-up menu.  Click "Nios II BSP Properties".  Select optimization level: Size.  Hit OK.  Select Nios II --> Generate BSP.  Select Project --> Build All.  Hm, that didn't seem to work - not enough files were recompiled.  Let's click "Generate" in BSP editor, and rebuild.  Still nothing.  Let's do a Project -> Clean, and clean all projects.  That'll force the issue.  OK, that does it - all files are getting recompiled with -Os.  Now we get in the linker summary:

Info: (FEDM_ctrl_fw.elf) 68 KBytes program size (code + initialized data).
Info:                    62 KBytes free for stack + heap.

Geez, we only saved 1 KB?  That's hardly worth it.  I think I'll change it back to the way it was.  (-O3 not -Os).  OK, that's changed back.

Next thing to try:  See if we can utilize the extra 8K of M-RAM (parity bits, not presently used).  Opening Q:\COSMICi_FEDM project, New_with_Nios_trim revision, SOPC builder.  Changing size of working_memory module from 64K to 72K.  This might let us get rid of extra_RAM.  System generation worked.   Extra_RAM is currently 9KB, and it uses M512 blocks, so getting rid of it might free up some space for other functionality.

OK, I went into the BSP editor, linker script tab, and changed the size of the working_memory linker region to 73,728 bytes (72 KB), and regenerated the BSP files.  After rebuilding, new linker stats are as follows:

Info: (FEDM_ctrl_fw.elf) 69 KBytes program size (code + initialized data).
Info:                    70 KBytes free for stack + heap.
So that worked as intended; we have an extra 8 KB now available in the stack + heap working memory.
So, the stuff that's currently going in extra_RAM could be shoved into there, maybe - except the problem with the M-RAM is that it can't be initialized!  So I'm not sure it really can be used for anything but stack & heap, unless we somehow work around the no-initialization restriction.  I guess .BSS sections can go in there too, but that's about it.  Damn, I just checked the linker script settings, and .BSS is already in there!

Darn, when I tried the Quartus compile, the fitter says it needs another M-RAM!  Maybe it can't allocate the extra 8K of parity bits as normal memory?  Let's see if it helps to change the word size to 16 bits (from 32 bits).  Nope, still no dice.  Sounds like I am going to have to stick with using 64KB of M-RAM, unless we find some other way to use the rest of it.  Also, when we try to generate with smaller word sizes, we get the following scary warning:

Warning: cpu_0.data_master/working_memory.s1: working_memory.s1 does not have byteenables. Narrow (less than 32-bit) writes from cpu_0.data_master will result in spurious writes to working_memory.s1

In other news, Juan and Michael Dean were here today, and I had them start work with Darryl & David on the new datapath for the timing sync capture.  Juan & Darryl are working on the new PIOs and the firmware changes, while Michael & David are working on the Quartus changes.  I copied the latest code (gelware & firmware) to the FEDM_design\FEDM_code\q91 folder so they could be working with the latest versions of everything.  Everyone got off to a good start today, but there is a lot left to do.  Juan & Darryl will give specs to Michael & David as to the PIO interface.

Aarmondas did not show up as promised.  Going to send him a strongly worded e-mail.

Also, Ray finished his data collection run that he started last night, in which the scintillators were overlapping at their centers.  It didn't change the location of the histogram peak much, for coincidence pulses due to showers propagating down through both detectors, so we are still thinking that 200 mV is the right level for the thresholds.

Speaking of which, currently the furthest threshold (DAC #6) is -1000 mV (off of a +2.5V DC bias) or in other words +1.5V absolute.  Thus, DAC #6 would be appropriate to use as the rising-edge threshold for the timing-sync input, since that pulse is going to be at (I believe, if I recall) the +3.3V logic level of the DE3 board.

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.