Serial Cable Redux

Today I soldered up a 9-pin male D-sub (DE9) connector to the appropriate pins of the 40-pin ribbon cable connected to GPIO1 on the DE3 board.  The pin connections are:

GPIO1/Ribbon      FPGA       Wi-Fi     DE9 connector

Cable pin #     function    function     pin #

------------    --------    --------     -----

     4             Rx          Tx          2

     5             Tx          Rx          3

     6           DTR out     DTR in        4

     8             RTS         CTS         7

     9             CTS         RTS         8

    12            (common ground)          5

Then Samad arrived, and our next task was to get the GPS app running again.  Despite the new, more robust GPIO1 serial connection with the ribbon cable, we again experienced intermittent problems getting the board programmed and running.  These are troubling, but with some retries & fiddling, we got past them.  

One problem that we did manage to diagnose was why the serial I/O to the Wi-Fi board was still not working - the Wi-Fi script's baud rate had been changed to the maximum (115,200 baud) when I was trying to maximize the pulse rate - but the GPS app SOPC system still had its default rate set to half that (57,600), which I had done before to try to reduce serial errors.  So, no wonder the communication was not working!  After fixing this, everything was working normally again (except that during this run, the GPS did not seem to have proper time lock).

Note: I am using Rev_A of the GPS App, because I think that Rev_B may have just been leftover from when I was starting to experiment with using the DRAM SIMM to store GPS data for analysis. 

To measure power, we manually wired up the 12-pin power connector to external supplies, using the nice jumper wires from Adafruit that I just got at home & brought in.  

At the moment, the +3.3V OCXO is still being powered through the DE3 board.  Here are the sources we used.

• The Keithley Sourcemeter for the +3.3V.  With the demo running, this is maxing out at 1.05A.
• The Agilent +6V supply for the +5V.  With the demo running, this is using a steady 0.32A.
• The Agilent +12V supply for the +12V.  With the demo running, this is drawing zero current.  Inspecting the manual reveals that the +12V is used to run an optional cooling fan (not needed in this app).

We next separated the +3.3V supply for the OCXO and the main board, powering the OCXO from the <25V supply on the Agilent (no longer needed for the +12V), so we could distinguish the two parts of the total power draw.

• The OCXO starts at 0.86A and after a while settles down around 0.31 A.
• The DE3 (running the demo) draws about 0.51 A on the +3.3V.  Note: In this test, the serial level-shifter to the GPS serial cable is also being powered through the DE3.

With the real GPS app running on the DE3 board, and communicating successfully with both the GPS kit and the Wi-Fi, here are the figures:

• +3.3V to DE3 board draws 0.346 A.
• +5V to DE3 board draws 0.336 A.

Samad took notes on all this, and is going to write a "Power Analysis" appendix to include in the Project  Plan report.

Juan (Calderin) and Michael (Dean) showed up about the time that Samad was leaving, and we spent a little time going over their changes (so far) to the Quartus code, and the content of their draft report, and talking about what needed to be in the report.

Ray spoke to LeCroy about his triggering issues but didn't get a clear response from them.  He wants to run some text for the paper by me.

It might be a good idea to replace the wire-wraps on GPIO0 with a ribbon cable soon as well, or at least with my nice new Adafruit jumper wires.  Pins currently used are:

• GPIO0 pin 13 - GPIO0_D[8] - TxD for FEDM's uart_2
• GPIO0 pin 16 - GPIO0_D[11] - RxD for FEDM's uart_2
• GPIO0 pin 40 - GPIO0_D[31] - PPS_IN from GPS
• GPIO0 pin 29 - +3.3V out - Can be used to supply uart_2's level shifter
• GPIO0 pin 30 - GND - For uart_2 / to level shifter