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.