Wed., Oct. 26th

Ray reminded me to respond to Sachin's email.  Looks like I didn't receive it because Gmail hasn't known my FAMmail password since June!  Fixed that, and scanning the email subjects to see if I missed anything else important...  Aha, replies from Reed Lambdin, and some emails about Zemax.  Anyway, replied to Sachin just now to see if he can continue to give us advice as we modify the board design.

Today I'm going to try out the Wi-Fi board with the new 40-pin header for the hand-wired serial port.

Regarding DSR, apparently I did indeed have it wrong in the original rat's nest - pin 10 (not 11) *is* DSR.

On the new Wi-Fi board (labeling it "#1"), I need to hook up pins 1+2 of J10 temporarily to ground the /EN input of U3, i.e., to enable the level-shifter on the main serial input so I can configure it from the PC.  Using one of my new Adafruit jumpers (a purple one) since I am short on jumper bridges.

Starting UwTerminal on COM1.  Hooking up serial cable (#1) from PC to main serial input.  Hooking up USB power.  Switching board on.  Get the usual "\00\00" as the serial port initializes (sending null bytes).  Hit enter and get the usual "00" prompt.  Enter "at" and get it again.  Enter at+dir and it looks like all the files are there.  However, I'm not sure if this board really has the most recent version of the script, so I'm going to re-burn it.

Entering "at & f *".  Get "01 E03C MEDIA_CORRUPT" as expected.  Power-cycle.  Board now back to just factory.def.pc in the filesystem.  Entering at+set 42="128", 40="1000", 41="1000" (three separate at+set commands).  I hope this board has the right version of the firmware!  Now, Download->Data->Data File+ on nodeid.txt and strings.txt in the "My Dropbox\FAMU\COSMICi\Wi-Fi Script" folder.  Then do Cross-Compile+Load on "autorun.uws" in that same folder.  Now loading.  I think the firmware version is right, or the cross-compiler wouldn't have worked.

OK, got everything in there now.  Now, start the server (C:\SHARED\Server Code\COSMICi_server.py).  Server is up and running.  Now, let's test the autorun feature.  First, we'll test with the control coming from the PC.  With DTR checked in UwTerminal, we'll power-cycle the board.  No autorun!

Now, uncheck DTR in UwTerminal, and power-cycle the board again.  That worked; we got the 3 TikiTerm terminals popping up.

Let's now disconnect the serial cable from UwTerminal, and try just manipulating pin 10 of J2 (DSR, new yellow jumper).  First, typing "exit" command over the wireless, so script exits to 00 prompt.  Next, re-routing pin 2 of J10 (purple jumper wire) over to pin 27 of J2, which is 3Vout from the module.  Now, we'll power-cycle again.  That worked, and the autorun activated.  Again, this could be due to a pullup resistor on DSR.

To test this, let's try wiring the DSR input to ground.  Pin 38 of J2 is a ground pin.  Plugging the other end of the yellow wire into that.  Now, power-cycle again.  This time, the autorun did NOT activate!  This confirms that setting DSR to *high* is what activates autorun (matches the documentation).  Also, it tells us that when a box is "checked" in UwTerminal, the corresponding logic signal gets set LOW, not high.  So the checkbox in UwTerminal is telling us the line level, not the logic level.  And pin 10 of J2 is indeed the right pin.

With all this confirmed, we are ready to wire up our new logic-level serial "cable" (really just a wire bundle) to the FEDM board.  The pins are nicely labeled in the male socket on the board.  So we can just plug directly into that, as follows:

• Black     - Common GND (Pin 5)
• Red        - WiFi M_TX --> RxD on FPGA (Pin 2)
• Blue       - WiFi M_RX <-- TxD on FPGA (Pin 3)
• Orange   - WiFi M_RTS --> CTS on FPGA (Pin 8)
• Green     - WiFi M_CTS <-- RTS on FPGA (Pin 7)
• Yellow   - WiFi M_DSR <-- DTR on FPGA (Pin 4)

Now, looking at the OrCAD schematic, pin 4 (DTR) on the FPGA side can be tied to ground through J50, but really we want to tie it to Vcc to make sure autorun is enabled.  So instead, we can use J46 to tie it to pin T7 of the FPGA, and then set it in firmware - maybe!  But will it be set soon enough?  It takes some time for the design to load from EEPROM.  Really, we want it to be high as soon as the boards power up.  So let's identify a +3V line we can connect to instead.  Node +3.3VDOWN is available on pin 1 (top pin) of JP12.  So, connect a yellow wire (representing a constant ~3V signal) from there to pin 1 (right pin) of J46.  Now we can hook up the pins above directly to the connector.

A thought: Should we go ahead and try supplying the +5V power through RI (pin 9) as planned?  If we want to avoid actually clipping the metal loop jumper on pins 1 & 2 of J8, and soldering a new bridge between pins 2 & 3 of J8, however, we cannot actually supply it there, i.e., on PC_RI (which is really on the DE9 connector J7, anyway).  The +5V can also be supplied on the tip of the barrel plug (J6), and on pin 3 of JP3, which is a bare thru-hole at present (not populated).  It does NOT come in on J2 at all!  (So my old orange RI/+5V input wire on my old Wi-Fi board #3 rat's nest was totally wrong-headed.)

I'm thinking the easiest thing might just be to solder a new male pin header onto pin 3 of JP3, and connect to that - that way I don't even need to use the barrel plug.

Clipped a new male pin header off of the extra-long, double-ended ones I got from Adafruit, and soldered it on there.  Connecting a white (for "white-hot" +5V) F-F jumper wire to that; will add it to the serial "cable" (bundle of jumper wires).  So now we have:

• Black     - Common GND (Pin 5)
• Red        - Wi-Fi M_TX --> RxD on FPGA (Pin 2)
• Blue       - Wi-Fi M_RX <-- TxD on FPGA (Pin 3)
• Orange   - Wi-Fi M_RTS --> CTS on FPGA (Pin 8)
• Green     - Wi-Fi M_CTS <-- RTS on FPGA (Pin 7)
• Yellow   - Wi-Fi M_DSR <-- DTR on FPGA (Pin 4)
• White    -  Wi-Fi DC_IN <-- "RI" (really +5VCC) from FPGA (pin 9)

So, I hooked up all these connections to the FEDM board just now, and tested it by switching on the Wi-Fi (and then switching on the +5V power to the FEDM), and it worked perfectly!  The Wi-Fi board ran the autorun script, popped open its windows, sent the "WIFI_READY" message to the FEDM, and the FEDM sent the acknowledgement back via the Wi-Fi board to the UART bridge window.

The new, simplified, neat-and-pretty version of the detector electronics.
At left: FEDM board.  At right: EZURiO Wi-Fi dev. board.  Look ma, no wires!

At some point, we need to change the FEDM firmware (as well as that of the GPS app) so that it waits to receive the "WIFI_READY" message from the Wi-Fi board before it starts transmitting data - this is to make sure that its early output doesn't get lost in the serial input buffers of the Wi-Fi board before the Wi-Fi autorun script has finished configuring the bridge connection to the server.

Juan C. and Michael D. came by and delivered their code for the 56-bit version of the datapaths.  We started a compile and fixed a few bugs till it got past synthesis.  However, it later stopped in the fitter because the device was not set.  However, the code is now I think ready to import into the main folder.  The changes in the top-level file need to be merged into my latest top-level file.