Tue., Nov. 22nd

Was thinking of doing some work today on improving time resolution of CTU.

First, an issue list with the current CTU setup:

• [ ] For some reason, the Wi-Fi board failed to connect when I powered up the system today.  But then, after some fiddling, it started working again.  Loose connection somewhere?  Watch out for this to happen again, try to diagnose.
• [ ] When the CTU firmware receives a blank line on its input, at present it generates an "UNK_CMD" (unknown command) error message.  Instead it might make more sense to simply ignore these lines.
• [ ] After being powered off for a while (like overnight), the GPS module seems to have difficulty acquiring satellites again.  This is perhaps because the time-of-day is wrong.  (At the moment, the GPS thinks it's 19:50 GMT, when actually it is 20:17; so the GPS is running almost half an hour slow.)  One way to address this:  Have the CTU query the server to find out the current time, then send a command ("$PDME,9,...") to the GPS to set the time (as well as setting the position)
• [ ] When restarting, sometimes there are server errors on the 2nd (or later) connection attempts.  These need to be tracked down and fixed at some point.

Samad is here and he brought the new 10-pin connector with him.  I showed him the proto board I picked up the other day at Fouraker's and the extra breakaway headers and jumpers I ordered from Adafruit, so that he can work on soldering up our power distribution board.  We discussed the connections needed.  He is going to write it all up and include it in the presentation #3 (SLDR), as well as the next report (DDR).

I scanned the bare proto board for him, so if he runs out of time to finish the soldering today, he can at least still make a nice sketch of the wiring for the presentation:

Bare proto board, to be used for soldering
prototype of main power distribution board.

Back on the GPS - I inserted two fresh AA batteries into the GPS kit as a battery backup, so that once we get a fix we don't lose it again.  Although, this conflicts somewhat with the use of the $PDME,9 command, because the docs for that say it needs to be done right after startup to be most effective.

Based on aerial photos from Google Earth (latest imagery), the coordinates of the windowsill where the GPS antenna is currently located are as follows:

• Latitude:     30°25'41.65"N
• Longitude:  84°17'6.00"W

This is a little west of where it looked like the window was in earlier images, but I think the current image is more direct (from overhead), so let's go with that.

Using the coordinate converter at GPSVisualizer.com, in terms of just degrees and minutes (what we get back from the GPS) this is:

• Latitude:     N30°25.694167
• Longitude:  W084°17.1

and in terms of just degrees (which we supply on the $PDME,9 line), it is:

• Latitude:     30.42823611111
• Longitude:  -84.285

Altitude, guesstimating from Google Earth, is about 50 m (164 ft).  So, the actual $PDME,9 command line would be (right now, 2011 Nov. 22nd, 21:12:00 GMT):

• $PDME,9,30.428236,-84.285,50,2011,11,22,21,12,00

Now, the only problem is, getting this information to the GPS will be somewhat involved, requiring changes to the CTU firmware, the Wi-Fi script, and the server.  I think perhaps as a short-term solution, I will get the GPS set up manually, and just rely on the batteries for a while to keep the fix active.  Remember, though, to later go back and solve this issue more permanently!

Muting GPS echo and stopping timer.  Exiting from Wi-Fi.  Powering off CTU.  Yes, GPS still has power (from batteries).  Unplugging level shifter.  Plugging in COM1 cable.  Setting UwTerminal to 57600, no flow control.  Sending commands from UwTerminal:  NMEA-off.txt, hot-start.txt, init-pos.txt (with the new location/time as above).  Still no satellites!  Maybe I need to re-run the eval app.  Have to revisit this on Monday.  Happy Thanksgiving all!

Mon., Nov. 21st

This is a short week due to Thanksgiving.  Some things to tackle:

1. [/] Get GPS module acquiring satellites again.
2. [/] Disable CTU debugging output under control of a slider switch.
3. [/] Burn working CTU design to DE3 board.
4. [ ] Maybe experiment with faster clock for GPS timing edge capture in CTU app.
5. [ ] Start writing up some notes on Python server code for use by Cp.E. students.

Working now on satellite acquisition.  Using UwTerminal, I streamed command files to select the default configuration.  Then I hooked up the kit to the PC via USB and attempted to initialize using the approximate site coordinates in minutes & seconds (30*25' N, 84*17' W) and the current system time (14:50 EST).  I briefly saw a satellite flicker from gray into red once or twice, but not enough to get any coordinates or even download an updated almanac?  Although I'm not sure about the latter b/c the satellites are moving slowly.

Aha, finally got a fix after letting it sit for a while.  Now, let's see if I can switch into my custom config and start the GPS app...  Here are the steps for that:

1. Turn off debug stream with "$PDME,13,5,0" command.
2. Exit GPS kit eval app.
3. Plug in PC's COM1 cable with null modem back into NMEA port.  (With left switch in left position.)
4. UwTerminal at 4800, no flow control.
5. Plug in 6V adapter, unplug USB (it interferes with serial).
6. Stream C:\Users\Mike\Documents\My Dropbox\FAMU\COSMICi\GPS FPGA app\NMEA command files\NMEA-off.txt
7. Next, show-backup.txt.  Yes, custom config is still in flash.
8. Next, select-backup.txt.
9. Next, hot-start.txt, & switch baud rate to 115,200.
10. Unplug COM1 cable.
11. Plug in pin 24 of J5 from DE3, power on DE3, unplug AC adapter.  That works!
12. At this point you can burn the Quartus .sof file to start the design running.

At this point, I added the capability to switch off the debug output.  I added a new PIO from the slider switches and added macros PRINTF() and PRINTF_R() to check that slider switch 1 is up before sending any output.  This worked.

Next we (Darryl is here) tried burning the design to the board (to the EPCS device) so it would run automatically on power-up.  This worked, but 20 seconds was (in this test) not quite long enough for the Wi-Fi to finish starting up.  Changed it to 30 seconds (for now) and added a countdown display on the 7-segment digits so that the user doesn't get too impatient.

We also cleaned up the formatting a bit on the NMEA-formatted output.  There is a minor existing weirdness where it doesn't finish receiving & processing the WIFI_READY message (from just before the script main loop is entered) until a subsequent command line is typed.  Maybe I didn't terminate that line properly?  Anyway, go back and figure that out someday.  Everything else works fine.

Fri., Nov. 18th

Plan for today:

1. Finish testing CTU with new connections.
2. Maybe add a PLL to the CTU for improved resolution of GPS time measurements.

Tweaking pin assignments some more:

• GPIO 0 (Wi-Fi) - Inner header
• Pin 11 = +5V power supply to Wi-Fi module.
• Pin 9 (GPIO0_D6) <-- Serial CTS input from Wi-Fi kit
• Pin 10 (GPIO0_D7) --> Serial RTS output to Wi-Fi kit
• Pin 12 = GND supply to Wi-Fi module.
• Pin 13 (GPIO0_D8) <-- Serial RxD input from Wi-Fi kit
• Pin 14 (GPIO0_D9) --> Serial TxD output to Wi-Fi kit
• GPIO 1 (GPS) - Outer header
• Pin 27 (GPIO1_D20) <-- PPS input from GPS kit, J4 pin 15.
• Pin 29 = +3.3V power output to GPS kit.
• Pin 30 = GND supply to GPS kit.
• Pin 31 (GPIO1_D22) <-- Serial RxD input from GPS kit, J5 pin 15 (UART0TX).
• Pin 32 (GPIO1_D23) --> Serial TxD output to GPS kit, J5 pin 16 (UART0RX).

...Then I spent the whole afternoon doing a lot of tinkering and fiddling which I'm not going to go into all the details of.  Suffice it to say, I discovered the following:

For some reason, pin 31 of GPIO 1 on the DE3 board seems to be "broken," in the sense that it pulls to 0 even when it's only being used as an input.  Thus, I'm now using pins 39+40 for Rx/Tx to GPS instead of pins 31+32.

It doesn't seem to work to communicate with the GPS kit directly though pins 15+16 of the kit's J5, perhaps because its MAX3222 can't be disabled; so instead, I have plugged the SparkFun level-shifter onto J6 (powered with +3.3V from DE3's GPIO1) and meanwhile I am also supplying +5V power to the GPS module from GPIO1 through pins 4+24 of J5.

Oh, and BTW right now the OCXO board (which I soldered the temporary SMA connector onto) is being supplied +3.3V from GPIO0, while meanwhile the Wi-Fi board is powered by +5V from GPIO0.  So we're using all 4 of the power outputs on the GPIO boards!

Here is a photo of the fully assembled and running CTU electronics:

Assembled CTU electronics.  The GPS module, level-shifter and
OCXO board are all drawing their power through the DE3 board.

Some next steps:

1. Add a compile-time (or better, DIP-switchable) option to disable debugging output.
2. Burn design to EEPROM.
3. Test power-up sequence.

Just for fun, I did a test with both the CTU and the FEDM powered up and talking to the server at the same time.  That worked fine.  This works because currently CTU is node #0 and FEDM is node #1, based on the nodeid.txt files loaded into their respective Wi-Fi boards (#3 and #1).

One more thing: The GPS seems to be still having trouble acquiring satellites; I may need to go into the DeLorme app and tinker around with it until it is healthy again.

Thu., Nov. 17th

Had a little time between meetings, so decided to come into the lab to test the connections on the newly-soldered 40-pin header on Wi-Fi board #3.  Actually, I realized I can't test the connections to J9 because that is on the other side of the 0-ohm resistor jumpers R7-R14, which are not presently populated (their pads are underneath the level-shifter chip U3).  So instead, I'll test by running the GPS app on the DE3 board.

Pins of J2 that we need for the serial are:

• Pin 10 (yellow wire)   - (From DE3) Autorun (DE9 pin 4) -> M_DSR (To WiFi)        - Optional.
• Pin 11 (black wire)    - GND                          (DE9 pin 5)
• Pin 19 (green wire)    - (From DE3) RTS       (DE9 pin 7) -> M_CTS  (To WiFi)        - Handshaking in (optional)
• Pin 21 (red wire)       - (To DE3)     RX         (DE9 pin 2) <- M_TX    (From WiFi)
• Pin 23 (tan wire)        - (To DE3)     CTS      (DE9 pin 8) <- M_RTS  (From WiFi)    - Handshaking out (optional)
• Pin 25 (blue wire)      - (From DE3) TX        (DE9 pin 3) -> M_RX    (To WiFi)
• Pin 27 (purple wire)   - (To J10 pin 2 /EN)                      <- +3V out  (From WiFi)    - Disables level-shifted input.-

To start out, I'm just going to connect pins 11 (GNS), 21 (M_TX), 25 (M_RX), and 27 (/EN).

Starting the server to prepare for the run.  (First I moved the last round of log files to a subfolder with today's date.)

I have to open the GPS app project in Quartus.  Did that (version in C:\f).  Plugged in USB.  Powered up board.  It's running the builtin demo.  Starting programmer.  Selecting USB blaster.  Burning image.  Wait, forgot to start Wi-Fi first.  Powering DE3 off.

On Wi-Fi, connecting pins 1+2 of JP2 to enable USB power.  Now it's powering up.

Looking at the top-level file (DE3_GPSapp.v), it looks like I am going to have to add CTS/RTS after all, because the design is expecting them.  OK, added those two wires.

Now, powering up DE3 again, and re-programming design.  Nuthin!  (Just "--" on 7-seg display)

I have to go over to ECE now.  Things to try tomorrow:

• Hook up GPS module
• Check baud rate
• Run design in debugger (in legacy Nios II IDE)

*     *     *

Came back in later in the evening to work some more on the DE3 board connections.  I've now greatly simplified the design of the connections.  I've eliminated the ribbon cable and serial cable and all of the wire-wrap.  I did some reassignments of the DE3's GPIO header pins to group related pins closer together.  I also figured out that I can eliminate the level shifter (I think) by connecting directly to the GPS kit's internal logic-level Tx/Rx nodes instead of going through its level-shifter and DE9 connector.  And I figured out how to power the GPS kit directly from the DE3 board using +3.3V out.

New pin assignments:

• GPIO 0 (Wi-Fi) - Inner header
• Pin 11 = +5V power supply to Wi-Fi module.
• Pin 27 (GPIO0_D20) <-- Serial CTS input from Wi-Fi kit
• Pin 28 (GPIO0_D21) --> Serial RTS output to Wi-Fi kit
• Pin 30 = GND supply to Wi-Fi module.
• Pin 31 (GPIO0_D22) <-- Serial RxD input from Wi-Fi kit
• Pin 32 (GPIO0_D23) --> Serial TxD output to Wi-Fi kit
  
• GPIO 1 (GPS) - Outer header
• Pin 27 (GPIO1_D20) <-- PPS input from GPS kit, J4 pin 15.
• Pin 29 = +3.3V power output to GPS kit.
• Pin 30 = GND supply to GPS kit.
• Pin 31 (GPIO1_D22) <-- Serial RxD input from GPS kit, J5 pin 15 (UART0TX).
• Pin 32 (GPIO1_D23) --> Serial TxD output to GPS kit, J5 pin 16 (UART0RX).

The Adafruit jumper wires currently being used are not colored optimally, since I was running low on colors, but I ordered some more of them and they should arrive soon.  I can replace the temporary ones I have now with more sensibly-colored ones when they get in.

I think the new GPS communication setup is working because I got a "Yo" on the 7-segment display, indicating a line was received.  Still need to test communication in the other direction though.  (Sending config commands from the DE3 to the GPS.)

Tomorrow I'll hook up the new Wi-Fi board (it's drying at the moment; I had to solder a header pin for +5V power input) and do a complete test of this new CTU setup.

Wed., Nov. 16th

Michael Dean came by my office yesterday and I answered some of his questions on the timing system.

Accidentally turned in the wrong timesheet yesterday (for the wrong pay period), so had to spend some time today running around getting the correct one (don't know why I didn't already have it), filling it out, getting it signed & turning it in.  The system for getting paid is so inefficient!

Today I want to try compiling with different versions of the Nios core and see how much space it saves.

As a baseline, the present design (with the Nios II/f) is as follows:

• Entire design (COSMICi_FEDM_top12):
• Comb. ALUTs:  10,017 / 27,104 (37%)
• Ded. log. regs.:   25,678 / 27,104 (95%)
• M512s:                   188 / 202       (93%)
• M4Ks:                    144 / 144       (100%)
• M-RAMs:                   1 / 1           (100%)
  
• SOPC system (FEDM_NiosSys):
• Comb. ALUTs:   2,324  (8.6%)
• Ded. log. regs.:    1,901  (7%)
• M512s:                  150  (74%)
• M4Ks:                   144  (100%)
• M-RAMs:                  1  (100%)
  
• Nios CPU (the_cpu_0):
• Comb. ALUTs:   1,396  (5%)
• Ded. log. regs.:    1,486  (5%)
• M512s:                      4  (2%)
• M4Ks:                     16  (11%)
• M-RAMs:                  0  (0%)

So at best, by changing the CPU to a much smaller one, we could bump up the available logic registers a bit (less than double), increase the available M512s from 14 to (at most!) 18, and increase the available M4Ks from 0 to (at most!) 16 (11% of the total number).  So it's not a huge difference, but it does potentially make some difference.  Need to keep this in mind if we run out of space again (or if we need to loosen things up for improved performance).  Later on, we can do some test compiles to see exactly how much space we can safe by moving to the Nios II/s or e.  (Note: It could however increase firmware size, due to the need for software multiply/divide instructions.  It could also reduce performance and lead to more dropped pulses.)

I had a thought earlier in the day, which is that we could add a PLL in the GPS app, to more precisely measure the PPS edge times relative to the OCXO clock.  The OCXO clock is 10 MHz, but it would be pretty easy now (given the code already written for the FEDM) to step this up to a much faster speed.  50 MHz?  100 MHz?  500 MHz?  It would be fun to try.

Samad came by and we tried to solder the other 40-pin DIP header onto the other Wi-Fi board (#3), but had some problems, due to my hand shakiness; solder got stuck in some thru-holes, blocking them.  I tried several methods for removal, but no luck yet.  We may need to try again with another board.  Or, if I can find a small enough drill bit, we could re-drill the holes.  (I looked through all my Dremel tool attachments, but didn't find anything suitable.)

Finally managed to work the solder out of the holes by hand using a tiny eyeglass screwdriver, then soldered the second breakaway header strip of 20 pins.  After all the work with the solder tools there is a lot of charring of the board surface.  I cleaned the board as best I could with the electronics cleaner spray, then rinsed in water, shook the drops off, and placed it to try overnight on the exhaust vent of the soldering fan.  Test tomorrow to make sure it's working OK.

Not sure there's anything else I can really do at the moment.  Tomorrow I will test connectivity on Wi-Fi board #3 between pins of J2 (with the new header) and corresponding thru-holes of J9.  Once that's working, I will do a new serial connection between Wi-Fi board #3 and the DE3 board's GPIO1 header using a bundle of Adafruit jumper wires, like I did for the FEDM.  Then I'll test that Wi-Fi connection by running the existing GPS app.

Spent a little time playing around with using some of the Adafruit extra-long M-M pin headers and F-F jumper wires to supply the +3.3V, +5V, and +12V power on a small breadboard.  The quality of the power supply connection is poor though - it keeps going out, and you have to hold it in just the right way to maintain steady power.  So, getting the right connector from Digi-Key for mounting on a real proto board will be key here.

Temporary hand-made connector/wire bundle for distributing power supply voltages on breadboard.
Color code: Black/white = ground; Orange/gray = +3.3V; Green = /ON; Red = +5V; Yellow = +12V.

I am a little concerned about distributing +5V power (which will account for the biggest part of power consumption, I'm guessing roughly 4A = 20W worth, since it will drive the FEDM, both Wi-Fi boards, the GPS module, and the fan) via the relatively narrow-gauge jumper wire shown here.  This could potentially represent a fire hazard if this wire overheats.  It would be safer to use a slightly thicker-gauge wire such as the one used in the actual power-supply connector.  Alternatively, we could do an analysis to show that there is no hazard even with this narrow wire.

Tue., Nov. 15th

Still need to requisition the batteries/charger for Samad.  First, check to see if the vendor is in the vendor list.  It's not.  Emailed him asking him to either re-source it or get the vendor added.

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

This data makes it look like, Case #2 is producing more and/or stronger pulses, but in configuration #1, this is overwhelmed by the fact that SMA #3 is responding so much more strongly.

Suppose we put the pulse generator on the apparently-weakest input (#2), what do we get?
(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

Again, a particular assignment (Case#1 on SMA#3) gives a consistent rate (196 Hz) no matter which of the other two inputs the Tektronix is on.

Might as well finish up by doing the other two arrangements.
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 #1 on SMA #1 is still about 170 Hz.

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 #2 on SMA #1 is still about 240 pps.

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.

Note: It seems like on a RESET, the pulse buffer isn't getting cleared out properly - I get some junk when I start again.  Need to fix that at some point.

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).

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.

Mon., Nov. 14th

Still need engineering schematics/blueprints for both halves of the classroom at the Challenger Center - ping Pascal (or whoever I see today) about that.  Juan emailed me that he is planning to come by today.

Samad sent me quotes for the batteries / charger the other day, for demonstrating a wireless detector node.  Need to run them by Ray, and see if we should go ahead and requisition them.

Still need to solder the 40-pin breakaway header onto the other Wi-Fi board (the board labeled "#3").

Still need to work on the timing of the startup sequence for the FEDM+WiFi board combination... What I started doing last time was adding a delay to the FEDM startup sequence, to give the WiFi board more time to finish starting up before the FEDM started sending a large amount of serial data.

Changed gelware and firmware back to the original configuration for a 64KB working_memory module/linker section in M-RAM, except that the firmware now has the 20-second startup delay compiled in - I need to test that part, at least.  Rebuilt firmware; now recompiling gelware.

Plugged in the detectors (on SMA #1&2) and the function generator (on SMA #3) and the +5V power connector for the FEDM+WiFi unit and the cooling fan.

Moved existing server log files to "C:\SHARED\Server Code\logs 2011-11-14" and started the server.

To really test the startup sequence, I will need to re-burn a new image to the EEPROM via Active Serial, so that the newest gelware/firmware will load+run automatically on startup.  OK, it is burned.

OK, the new 20-second delay seems to be working, and seems to be adequate (just barely) to allow the present Wi-Fi script to finish starting up first.  (This is assuming that there aren't any networking issues.)

Weird, for some reason today I am getting a bunch of FIFO_FULL errors on SMA#1 (currently connected to Case #2), and the event counts seem higher than usual there relative to the others.

I switched the input connections (#1 and #2) and that seemed to fix the problem - which shouldn't happen!  Although to be fair, I don't know if perhaps the problem was just that the PMT in case #2 was still warming up, I didn't plug it in as soon as I plugged in #1.  Guess I could try switching them back...

Hitting STOP and HSC_STOP.  Switched cables back (Case #2 -> SMA #1, Case #1 -> SMA #2).

Whoa, that is weird!  Whichever way the cables are, the pulse counts are highest on SMA #1!  In the current configuration, the ratio is larger between SMA #1 and SMA #2&3.  OK, switched back to (Case #1 -> SMA #1, Case #2 -> SMA #2).  That has a more evenly-balanced ratio of pulse rates, but we still have a faster rate on SMA#1.

Theory: The parasitics on SMA #1 (impedance of on-board trace) could be smaller than those on SMA #2, even though these are (I thought) all supposed to be controlled-impedance traces.

I probably should also double-check all the pin assignments and the wiring from the DACs to make sure that the same threshold levels are being compared in all cases.  (Particularly the 1st threshold which controls detection.)

Let's see, looking at the OrCAD schematic, PMT_1 and VTH1 come to the pin pair TDCIN[0]/TDCIN[0](N), which are M21 and M20.  PMT_2 and VTH1 come to the pin pair TDCIN[6]/TDCIN[6](N), which are U22 and U21.  Let's check the layout.  M21 [/], M20 [/], U22 [/], U21 [/].  Yep, those connections all check out.  Now let's check the Quartus design.  TDCIN0[0]/TDCIN0[0](N) are M21 and M20, while TDCIN1[0]/TDCIN1[0](N) are U22 and U21.  TDCIN0-2 are all I/O standard LVDS.  Port TDCIN0[0] goes to signal pf0[0] and TDCIN1[0[ goes to pf1[0], and these go to thresh_pulse[1] of the corresponding datapaths.  So, no problems there.

To try tomorrow: Move the input from the pulse generator to SMA#1 and see if the weirdness persists (or if there is some other kind of weirdness).