Home

Documentation

Project Support

Changes in Version 7 of GraspSwControllerCmdPixtype

Author:
isani
Timestamp:
Wed May 20 12:05:30 2015

Legend:

Unmodified
Added
Removed
Modified

  • GraspSwControllerCmdPixtype

    v6 v7
    1 1  '''[wiki:GraspSwControllerCmd pixtype]''' 
    2 2  [[TracNav(GraspContents)]] 
    3 3  ||Command:||'''pixtype'''|| 
    4 4  ||Contexts:||Network socket, serial console.  Applies only if the CCD is an "OTA" device.|| 
    5 5  ||Function:||Tell the controller which pixel structure design the OTA has.|| 
    6 6  ||Required Parameters:||'''type'''='''0'''|'''1'''|'''2'''|'''102'''|'''103'''|'''104'''|| 
    7 7  ||Optional Parameters:||'''dev'''='''all'''|'''0'''|'''1'''|| 
    8 8  The following table explains the possible values for the '''type''' field: 
    9 9  ||'''0'''||The CCD is not an OTA, and can only shift "up" and "down" 
    10 10  ||'''1'''||The CCD has MITLL OTA Type 1 pixel structure 
    11 11  ||'''2'''||The CCD has MITLL OTA Type 2 pixel structure 
    12 12  ||'''102'''||The CCD is an STA with Type 1 pixel structure but STA phase wiring 
    13 13  ||'''103'''||The CCD is a newer STA device with yet another variation 
    14 14  ||'''104'''||Also for STA, like 103, but with modifications (see below) 
    15 15  === MITLL Devices === 
    16 16  Original MITLL OTA pixel designs had two types, called "type 1" and "type 2".  The basic layout of the parallel phases is illustrated below: 
    17 17  [[Image(phases_mitll_type1_and_2.png)]] 
    18 18  Pixel type 2 was never built.  All MITLL CCID58, CCID64, and CCID71 use type 1.  Other than the general geometry of the phases, the orientation of the pixel with respect to the serial register, and output are important, as are the connections of parallel standby high (PSH) and low (PSL).  The figure below attempts to show all of this for pixel type 1: 
    19 19  [[Image(phases_ccid64.png)]] 
    20 20  The figure shows a device with a 2 phase serial register.  CCID58's with 3-phase serial registers have identical parallel structure and therefore use the same type 1 clocking patterns.  For all MITLL CCID58, CCID64, CCID71, the correct form is: 
    21 21  {{{ 
    22 22  pixtype dev=all type=1 
    23 23  }}} 
    24 24  After sending this command, the [wiki:GraspSwControllerCmdOt ot command] will sequence the parallel phases in the following way for various shifts: 
    25 25  ||'''Shift Parameter'''||'''Sequencing'''|| 
    26 26  ||shift1p (move image along axis1 toward output)||P1>P2>P4>P1|| 
    27 27  ||shift1n (move image along axis1 away from output)||P2>P1>P4>P2|| 
    28 28  ||shift2p (move image along axis2 toward serial register)||P1>P2>P3>P1|| 
    29 29  ||shift2n (move image along axis2 away from serials)||P2>P1>P3>P2|| 
    30 30  All patterns start and end with P1+P2 in the high state.  This way there are no unwanted clock transitions whenever an OTA cell is taken in or out of standby mode, because P1+P2 are the phases connected to PSH.  The phase sequencing in the table above will only result if [wiki:GraspSwControllerCmdClvset clvset ppg4=] contains a parallel pattern P1>P2>P3>P1 that starts and ends with P1,P2 high.  Matching pixtype 1 with anything else is a configuration error (and the code should probably check and warn, but it does not presently do that.) 
      31  === Newer (>r5775) Controller Firmware === 
      32   
      33  As of r5775, the pixtype command has been deprecated.  Rather than trusting it to calculate the correct patterns for OT shifts, new [wiki:GraspSwControllerCmdClvset clvset] parameters are used to set up each of the four shifting directions.  This more generic approach allows us to handle other pixel structures (such as STA, below) without making assumptions to generate the patterns for "shift1n/p" and "shift2n/p".  It also allows a different parallel clocking speed to be selected for all [wiki:GraspSwControllerCmdOt ot command] operations because the pattern stored in "id=2" is automatically used, while "id=0" is used for science readouts and "id=1" is used for video/guide cells. 
      34   
      35  To set the clocking patterns for id=2, first start with a normal, "downward" parallel shift pattern as might be used in the full readout operation.  Adjust its speed as desired, and store it as "id=2 ppg4=". 
      36  {{{ 
      37  clvset dev=all id=2 ppg4=ecbb:cbb2:bb2e:65d8:5d97:38ba:6622:3154 
      38  }}} 
      39  The above is our commonly used "90 usec/row" parallel shifting pattern.  To obtain the code for a reverse ("n"egative sense) shift for ppg4o2n, which will get applied for any "shift2n" ot command), the simplest method is to reverse the order of time for the forward ppg4= pattern using cestlavie -e.  One could also just draw up the new pattern from scratch.  Another other method, which requires a little less editing, is to exchange a couple of pairs of states and leave the time durations in their original configuration.  The "middle" state of the pattern will stay the same, as will the first and last which are always "P1+P2" high for MITLL OTAs.  So that results in the following for a reverse shift, which would work on both OTAs and regular CCDs: 
      40  {{{ 
      41  clvset dev=all id=2 ppg4o2n=ecbb:cbb2:bb2e:65d8:5d97:38ba:5511:3264 
      42  }}} 
      43  For OTA devices, one has to examine the pixel structure closely to determine how to change an axis1 parallel clocking pattern into an axis2 parallel clocking pattern.  Doing so, and also studying the "sequencing" table above reveals that simply swapping in P4 instead of P3 will change the pattern into an orthogonal shift.  Loading the original ppg4= into cestlavie -e and changing all the P3 to P4 gives the result: 
      44  {{{ 
      45  clvset dev=all id=2 ppg4o1p=ecbb:cbb2:bb2e:65d8:5d97:38ba:aa22:3198 
      46  }}} 
      47  Finally, there are two easy ways to generate the reverse orthogonal shift pattern.  Flipping the patterns or reversing time as we did for ppg402n would work, as would taking that ppg4o2n pattern and replacing all P3's with P4's. 
      48  {{{ 
      49  clvset dev=all id=2 ppg4o1n=ecbb:cbb2:bb2e:65d8:5d97:38ba:9911:32a8 
      50  }}} 
      51  All four shift patterns can be combined into a single command, sent to each controller: 
      52  {{{ 
      53  clvset dev=all id=2 ppg4=ecbb:cbb2:bb2e:65d8:5d97:38ba:6622:3154 ppg4o2n=ecbb:cbb2:bb2e:65d8:5d97:38ba:5511:3264 ppg4o1p=ecbb:cbb2:bb2e:65d8:5d97:38ba:aa22:3198 ppg4o1n=ecbb:cbb2:bb2e:65d8:5d97:38ba:9911:32a8 
      54  }}} 
      55   
      56  Note that cestlavie only knows about one ppg4 parameter, which it takes as "ppg4=".  If the pattern you have generated is to be used for a "shift1n" for example, add the "o1n" when passing to clvset but do not pass ppg4o1n=" to cestlavie! 
      57   
    31 58  === STA Devices === 
    32 59  STA produced several variants which were apparently intended to be a clone of the MITLL type 1 pixel, however the pixel was "flipped" and the parallel phases were numbered differently.  In an attempt to deal with this, types "102", "103", and "104" have been created, loosely intended to be used on STA "lot 2", "lot 3" and "lot 4" devices.  (If someone has better names for these STA "lots" please update this information.)  We believe that the following figure is representative of the two most recent "lots": 
    33 60  [[Image(phases_sta_lot3_and_4.png)]] 
    34 61  Although the layout of the pixel appears to match MITLL type 1, we can only infer that the output is supposed to be on the left while MITLL shows it on the right of their figures.  Also, while the central triangular phases are connected to PSH, they are numbered '''P2 and P3''' instead of P1 and P2.  As a result the controller clocking engine will need to be configured to generate different waveforms for these devices.  We believe that type=102 should not be used unless older devices with additional quirks (which are fixed in the latest lots) are being used.  We have had some signs of success with type=103, but added type=104 after realizing that neither type 102 nor 103 were generating patterns which would start and end with P2+P3 high, which would cause unwanted transitions when switching a cell from standby to active.  102 and 103 have been left in so they can be tried for comparison, but we believe 104 should be the best choice for the latest STA devices: 
    35 62  {{{ 
    36 63  pixtype dev=all type=104 (*** NOT YET IMPLEMENTED, and to be replaced 
    37 64   by a new "ot_setup" command with four individual clocking patterns.) 
    38 65  }}} 
    39 66  Just as with the MITLL devices, after sending this command, the [wiki:GraspSwControllerCmdOt ot command] will sequence the parallel phases in the following way for various shifts: 
    40 67  ||'''Shift Parameter'''||'''Sequencing'''|| 
    41 68  ||shift1p (move image along axis1 toward output)||P3>P2>P4>P3|| 
    42 69  ||shift1n (move image along axis1 away from output)||P2>P3>P4>P2|| 
    43 70  ||shift2p (move image along axis2 toward serial register)||P2>P3>P1>P2|| 
    44 71  ||shift2n (move image along axis2 away from serials)||P3>P2>P1>P3|| 
    45 72  All patterns start and end with P2+P3 in the high state.  This way there are no unwanted clock transitions whenever an OTA cell is taken in or out of standby mode, because P2+P3 are the phases connected to PSH (versus P1 and P2 in the case of the MITLL OTA.)   The phase sequencing in the table above will only result if [wiki:GraspSwControllerCmdClvset clvset ppg4=] contains a parallel pattern P2>P3>P1>P2 that starts and ends with P2,P3 high.  Matching pixtype 103 with anything else is a configuration error (and the code should probably check and warn, but it does not presently do that.) 
    46 73  === Notes: === 
    47 74  Shifts along axis2 (the normal parallel direction) typically tend to function even if the pixtype setting is wrong.  See also [wiki:GraspSwControllerCmdOt ot command]. 
    48 75  If dev= is omitted, the last default dev applies (which can be either 0 or 1, but not "all"). 
    49 76  === Bugs: === 
    50 77  Pixtype makes assumptions about ppg4 (parallel clocking pattern) and swaps phases around (e.g., exchanging the states of P1<->P2 to reverse direction) without verifying that such manipulations are valid for the current ppg4 setting.  Read carefully the notes for your device type and check your parallel clocking pattern.