Pascal talked to the construction firm, and they referred him to the architecture firm for the more detailed engineering drawings of the room. Michael, Juan, David and Darryl were here and worked on the changes for the new input capture datapath for a bit, then once all the Senior Design students were here, they all broke off for their internal team meeting (which they're now holding in the library conference room), and meanwhile Darryl and David worked with Ray on the paper. Meanwhile, while all this was going on, I continued my testing of the new FEDM setup with the (now) 3 input-capture datapaths.
Re-testing the board with 100 Hz pulse source on SMA#1.
Current configuration ("Configuration #1") is:
- SMA#1: Tektronix function generator (100 pps, -2.5V pulses).
- SMA #2: Case #2 (near window). --> ~86 pps
- SMA #3: Case #1 (near hallway). --> ~196 pps
In this configuration (spreadsheet "C:\SHARED\Server Code\Pulse-Counts.ods"), the pulse rates (averaged over a period of about a minute) seem to be as shown above.
But, mega-weird! If I switch cables on SMA#2 and SMA#3 ("Configuration #2"), I get:
- SMA#1: Tektronix function generator (100 pps, -2.5V pulses).
- SMA #2: Case #1 (near hallway). --> ~72 pps
- SMA #3: Case #2 (near window). --> ~303 pps
Suppose we put the pulse generator on the apparently-weakest input (#2), what do we get?
(Configuration #3)
(Configuration #3)
- SMA #1: Case #1 (near hallway). --> ~172 pps
- SMA #2: Tektronix function generator (100 pps, -2.5V pulses).
- SMA #3: Case #2 (near window). --> ~287 pps
So, at least we seem to have some consistency in the sense that when a given case (#2) is on a given input, and the reference is moved between inputs, the measured pulse rate from that case stays the same.
Let's switch case #1 & #2 again. (Configuration #4.) Now we get:
- SMA #1: Case #2 (near window). --> ~241 pps
- SMA #2: Tektronix function generator (100 pps, -2.5V pulses).
- SMA #3: Case #1 (near hallway). --> ~196 pps
Might as well finish up by doing the other two arrangements.
Configuration #5:
Configuration #5:
- SMA #1: Case #1 (near hallway). --> ~168 pps.
- SMA #2: Case #2 (near window). --> ~81 pps.
- SMA #3: Tektronix function generator (100 pps, -2.5V pulses).
Interestingly, the above is the only arrangement (so far) where I don't get FIFO_FULL errors - perhaps because the pulse rates are lowest.
Case #2 on SMA #2 is still pretty close to 83-84 Hz.
Last arrangement (Configuration #6):
- SMA #1: Case #2 (near window). --> ~238 pps.
- SMA #2: Case #1 (near hallway). --> ~69 pps.
- SMA #3: Tektronix function generator (100 pps, -2.5V pulses).
Case #1 on SMA #2 is still about 70 pps.
Here is a summary of all the data (all figures are averaged pps):
| Case #1 | Case #2 | |
| SMA#1 | 170 | 240 |
| SMA#2 | 70 | 83 |
| SMA#3 | 196 | 296 |
Some comparisons:
- On average, Case #2 generates ~36% more pulses than Case #1 (fairly wide range though, 18-51% more, depending on which input pathway we're talking about).
- On average, SMA#1 detects ~2.6x (2.4-2.9x) more pulses than SMA#2.
- On average, SMA#3 detects ~3.2x (2.8-3.6x) more pulses than SMA#2.
In terms of a close ratio between the two detectors, the best configuration is #4; the ratio of pulse rates there is only 1.2x (241 vs. 196 pps).
The team swarmed in after their team meeting, and I clarified for them again what connects to what in the overall system design (CTU + detector electronics), and they took more photos in preparation for figuring out the exact arrangement of boards within the enclosure.
Samad and I found an appropriate connector on Digi-Key to connect to the cable from the power supply and mount on a breadboard or proto board for splitting out the power connections to the various destinations. He is going to order one out-of-pocket, so he can begin playing around with the power supply setup.
Addendum: It occurred to me on the drive home that if the students have difficulty getting the speed of the FEDM design back up to 500 MHz, one possible workaround (for Phase I) might be to jumper the comparator outputs over to the DE3 board (which has a larger and faster FPGA) and do the time-to-digital conversion over there. This would also simplify the Phase I system design, since all of the firmware could just run on that board, and we could eliminate one of the Wi-Fi modules. The high-speed clock produced by the PLL could be directly slaved to the OCXO input, which would eliminate the need for the extra timing sync capture datapath, and save some coding time associated with that (in the firmware & on the server).
Addendum: It occurred to me on the drive home that if the students have difficulty getting the speed of the FEDM design back up to 500 MHz, one possible workaround (for Phase I) might be to jumper the comparator outputs over to the DE3 board (which has a larger and faster FPGA) and do the time-to-digital conversion over there. This would also simplify the Phase I system design, since all of the firmware could just run on that board, and we could eliminate one of the Wi-Fi modules. The high-speed clock produced by the PLL could be directly slaved to the OCXO input, which would eliminate the need for the extra timing sync capture datapath, and save some coding time associated with that (in the firmware & on the server).
Some downsides:
- We would need to add 15 jumper wires arching from the FEDM over to the DE3. (5 DAC levels x 3 PMT inputs).
- The rise times on these signals would probably be relatively large (several ns maybe), and there could be nonuniform signal delays, leading to additional sources of error in the time measurements, errors which would be difficult to quantify since they would depend sensitively on the exact physical arrangement of the wires. (We could do some simple experiments pretty easily though with a scope to get a rough idea of how bad these problems are.)
- There would be some additional design time involved in merging the two firmware applications (but on the other hand, we have yet to see how much design time will be required to get the FEDM performance back up to 500 MHz in the current setup - could be less, could be more).
- This alternative approach would less directly lead into the Phase II design (with the optical sync), since for Phase II we would effectively have to undo the merging of the two applications, and figure out again how to get the FEDM back up to the desired speed. So in a way it just postpones solving that problem.
I'll ask Ray for some feedback on this idea, see if he thinks we should let the students explore it.
Ray says he'd prefer to continue pushing the current approach as far as we can first...
Emailed Sachin to see if he knows if we could access the EEPROM as a ROM.
Another idea: Just checked the SOPC design, and currently we are using a Nios II/f, which takes 1,400-1,800 logic elements, plus 3 M4K blocks and then some more M4Ks for the memory cache. If necessary, we could back off to a smaller Nios II/s (or maybe even Nios II/e) and save some of these resources.
Ray says he'd prefer to continue pushing the current approach as far as we can first...
Emailed Sachin to see if he knows if we could access the EEPROM as a ROM.
Another idea: Just checked the SOPC design, and currently we are using a Nios II/f, which takes 1,400-1,800 logic elements, plus 3 M4K blocks and then some more M4Ks for the memory cache. If necessary, we could back off to a smaller Nios II/s (or maybe even Nios II/e) and save some of these resources.
No comments:
Post a Comment