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).
No comments:
Post a Comment