Up the Creek...

Paddle assembly #1 (in gun case #2), which was responding more weakly than the other one, has been removed and replaced by the other paddle assembly (not yet yested).  Call this paddle assembly #3.  I put masking-tape labels on paddles #2+3 to tell them apart.

Let's now begin a new data-collection run, to see if the new paddle is performing any better than the old one.  Let these notes also serve as a guide for students as to how to start a new run.

First, I moved the previous set of server log & transcript files (COSMICi.server.log, COSMICi.node0.log, node0.auxio.trnscr, node0.uart.trnscr) to "C:\SHARED\Server Code\logs 2011-10-05" (labeling them with today's date, as is my convention).

Now, restarting "C:\SHARED\Server Code\COSMICi_server.py".  The Python interpreter's Windows console ("C:\Python31\python.exe") and the main TikiTerm window "COSMICi Server Console [Main Window]" open as expected, and the server starts generating heartbeats.

Now switching on the Wi-Fi board.  The TikiTerm windows for the 3 automatic connections from the board open up:

1. MAIN connection window ("Main Server Connection #0 from 192.168.0.6:49646") for log messages and other commands from the Wi-Fi board to the server.
   
2. AUXIO connection window ("Node #0 AUXIO Bridge #0") for auxilliary text output from the Wi-Fi script for diagnostic messages, user command prompt, etc.
   
3. UART connection window ("Node #0 UART Bridge #0") for data bridged directly from the FEDM UART.

Now, power up the cooling fan, currently powered at ~4.5 V.  The thermoelectric plate is outputting ~ 2-3 mA (wonder why?).

Next, power up the FEDM at 6 V (5 V is also OK).  Current is 1.86 A.  An old version of the firmware is programmed in.  Before going on, I want to update it.  The Quartus license server is still running.  Starting Quartus.  Selecting Q:\COSMICi_FEDM.qpf.  Starting Programmer.  Selecting mode "Active Serial" to reprogram EPROM.  Switching JTAG connector from U7 to J1.  Selecting "New_with_Nios_trim.pof" programming file ("New_with_Nios_trim" being the current project revision).  Selecting "Program/Configure" and "Verify" options, and clicking "Start".  We get the expected startup message from the latest firmware:

FEDM_STARTING,v0.6
DAC_LEVELS,-0.300,-2.500,-0.400,-0.500,-0.600,-0.700
FEDM_READY
BADUMP,1
BADUMP,2

Now Juan is here, and we plugged in the detectors.  The new paddle assembly (#3), in gun case #2, plugged into SMA connector #1, is now responding more strongly than the others!

Juan is going to set up the Macs so that VirtualBox runs only in one dedicated account which we all share.

I shared the FEDM_design Dropbox folder with Juan.  He is going to look into how to do version management in Quartus development.

Samad came by and we verified that the current draw of the detector is about 20 mA, which is what we had expected based on the quiescent power dissipation figure from the manual for the bases.

We also probed the voltages on the DE3 power supply.  Pins 2 (black) and 3 (green) have to be connected to cause the supply to turn on.  We determined the voltages supplied on the other pins: Altogether, the levels available are +3.3V, +5V, +12V, and -12V.  Samad and I discussed that in stage 1 of the design we might be able to just use this supply to power all our electronics from that supply.

After Samad left, I hooked up both the Wi-Fi board and the FEDM to the +5V output from the DE3 supply.  That is working fine.

Meanwhile, since the pulse rate on the new paddle is high, we are getting hanging problems again.  I ran the firmware under the debugger, and during a hang I suspended execution and observed that it was in the output code under the heartbeat callback.  The "reentrant" stdio routines aren't really re-entrant!  Perhaps because uC/OS-II isn't running.  Anyway, I commented out the heartbeat setup and am running again.  If that is the only problem, maybe it won't crash now!