. . . .

Web Design Image Map

 

updated:2016.07.13

RPM Version 5

PCB Description

Information

This sidebar needs to align with the PCB image so that its links and their related areas in the image show at the same time. For this the PCB image (and taskbar) are placed in a table with the linkbar. The rest of content can flow under the linkbar.

Site Map   Home   Home   Prev   Next  
Text Size
Please reload page for style change
9602330-rev P14

PCB IMAGE MAP (CLICK on items for details)

RPM5 PCB

PURPOSE

The Right Panel Module is our most poorly defined module. It provides the APU's scan chain access to all of the fluid controls located on the right panel of the instrument. This includes many special devices that have not been finalized, particularly shear valves, y-valves, and fluid sensors.

The interim RPM contains many technical errors. In fact, none of the special device interfaces function at all. The design was reviewed in System Design Report 7 topic Right Panel Module / Interim Design Errors [Cdxsys- InterimDesignErrors]. Based on this report, Maha redesigned the board, correcting both the original errors and errors in the review. System Design Report 14 topic Right Panel Module [Cdxsys-RightPanelModule] contains some of her findings and suggestions, particularly regarding the shear valve interface.

In hindsight, we spent too much time on the new shear valve interface. We aren't even sure that shear valves will be used and, if they are, the old circuit is adequate and needs only a few bits of the scan chain for control. However, the design work has already been done and the only penalties are a somewhat larger PLD and the drivers, which don't have to be stuffed. Maha nearly finished the complete redesign. Unless we find some problem that could be solved by eliminating the new shear valve interface, we may as well keep it. No matter what we do with the RPM at this point, it can't be optimal because we don't know what the final instrument configuration will be. Since any instrument needs the RPM, we should probably produce a limited number of the Maha's version, knowing that another redesign is likely.

SCAN CHAIN

CONFIGURATION

  1. Place jumper on JSCLK pins 1-2.
  2. For Status board 9601920 place jumpers on J1 pins 1-2 and JLED_INV.
  3. For 2MHz SCK (APU2) place jumper on JPLDI1 (YV1 is permanently deselected).
  4. To enable JSOL4 to 7 (SOL 1 to 4) place jumper on JBP4 pins 2-3.
  5. To enable JSOL8 to 11 (SOL 5 to 8) place jumper on JBP3 pins 2-3.
  6. To enable JSOL12 to 15 (SOL 9 to 12) place jumper on JBP2 pins 2-3.
  7. To enable JSOL16 to 19 (SOL 13 to 16) place jumper on JBP7 pins 2-3.
  8. To enable JSOL20 to 23 (SOL 17 to 20) place jumper on JBP6 pins 2-3.
  9. To enable JSOL24 to 27 (SOL 21 to 24) place jumper on JBP5 pins 2-3.
  10. To enable GENSNSR 1 to 8 place jumper on JBP1 pins 2-3.

GENERAL SCAN CHAIN ADDRESSING

MSM MOSI and MISO addresses shown here apply when connected to JLDRIO with JU17 pins 1-2 and JU12 pins 1-2 connected. For all, output is space 2, input space 3.

Output. Total 64 bits

  1. Byte 0 (APU @510000, MSM @500012)
    • Remove JSV0_EN jumper to enable SV0.
    • Remove JSV1_EN jumper to enable SV1.
    • Place jumper on JNEW_SV to select "new" SV control with driver on RPM.
    • SOL1 is enabled if JSV0_EN jumper is on (disabled) or JNEW_SV jumper is off (SOL1 or SV0 may be connected but not both).
    • SOL2 is enabled if JSV1_EN jumper is on (disabled) or JNEW_SV jumper is off. (SOL2 or SV1 may be connected but not both).
    • Place jumper on JPLDI4 to enable YV0, else MOSI4,5->JPLDO7,6.
    1. SV0 CW/CCW. JOSV0 pin 5. Alternately JSOL1_HI (SOL1_HI)
    2. SV0 ON. JOSV0 pin 4. Alternately JSOL1_ON (SOL1_ON)
    3. SV1 CW/CCW. JOSV1 pin 5. Alternately JSOL2_HI (SOL2_HI)
    4. SV1 ON. JOSV1 pin 4. Alternately JSOL2_ON (SOL2_ON)
    5. YV0_On. YV0 if JPLDI4 on, else JPLDOp7
    6. YV0_CW. YV0 if JPLDI4 on, else JPLDOp6
    7. YV1_On. JPLDO9
    8. YV1_CW. JPLDO8
  2. Byte 1 (APU @510001, MSM @500013)
    1. Fluid sense (JSNS1 to 8) strobe. Posedge triggers 10us pulse.
    2. Beep (1 = on)
    3. Green (1 = on)
    4. Yellow (1 = on)
    5. Red (1 = on)
    6. JTESTp1 (PLD pin 60)
    7. JSOL3_HI (SOL25_HI)
    8. JSOL3_ON (SOL25_ON)

STROBED FLUID TRIGGER

The strobe (output bit 8) is low normally. Writing a 1 to it triggers the 10 usec pulse to the sensors. It is a low-to-high edge triggered event. The bit can be be written back to a low at any time during or after the 10 usec. The next low-to-high transition of the bit will cause another 10 usec pulse. The fluid sensors are 1 when open, 0 when sensing fluid.

CIRCUITS

Y-VALVES

JYV0 and JYV1

STATUS BOARD INTERFACE

JSTAT is the direct I/O interface to the Status Board. JSB is a scan chain interface to an obsolete version of the Status Board.

STROBED FLUID SENSORS

The strobed fluid sensors

GENERAL PURPOSE SENSORS

The general purpose sensors

POWER

Power is supplied through JPWR. Fuses

SHEAR VALVES

Two types of shear valves are supported. The old provides its own drivers. The RPM board contains the drivers for the new version.

CONFIGURATION OPTIONS

JPLDI and JPLD0 provide a means of connecting to the PLD pins for alternate uses. The configuration jumpers

PLD CONFIGURATION AND TESTING

The PLD is configured through JTAG. It is tested in a JTAG scan chain through JTEST. The clock speed selector JSCLK

SCAN CHAIN REGISTERS

Scan chain input registers, output registers, bypass jumpers

JLPM is the scan chain downlink to the LPM. JAPU is the scan chain uplink to the APU.

SOLENOID DRIVERS

Solenoid drivers can control any device that

PAGE DESCRIPTION

This page illustrates several useful constructs for presenting technical information, particularly where an image of a physical object can be displayed. Here the image is of a printed circuit board. Different users would be browsing this page from different perspectives. A repair technician might be trying to determine the purpose of an item that can be seen on the unit, for example an IC or a jack, in which case, the entry point is the physical image. An instrument developer might know the name of something but not the location of related objects on the physical board. In this case, the entry point would be the items listed in the side bar. This would also be the entry point for an engineer trying to learn how the unit operates but, in this case, the detailed text would be of more interest than the location of related items in the image.

This page has been developed to illustrate web page techniques. The contents of the example topics are taken from real documentation but are truncated. The full text consumes many pages. Similarly, not all items of interest in the PCB image are represented in the image map. Page coding topics of special interest are:

IMAGE MAP AND LINK JAVASCRIPT ROLLOVER

Image map is a standard HTML mechanism for creating hyperlinks over selected areas of an image. When the mouse is located over an image hotspot area, clicking causes the hyperlink to be taken. The basic mechanism is deficient in several ways. One is that all browsers indicate when the mouse is located over a hotspot only by showing a tooltip. This is a particularly poor feedback means because the user doesn't know where any hotspots are and must wait at each guessed position for the tooltip to appear. Even then the feedback is inadequate because there is no indication of the extent of the hotspot. The mouse can easily be located on the border of one hotspot while the user is actually trying to refer to an adjacent item.

Another problem is more of an unrealized opportunity. The image map provides a one-way link from the image to related topics. If the user wants to find out what something is this provides real value. If the user already knows what the items are in the image, this is nothing but a visual gimmick providing no utility beyond what could be presented by a list of names. If the user wants to find something knowing the name but not the physical representation in the image then this gimmick is an annoying waste of time. If the hot spot topics were also displayed by name in a separate list and rolling over those names caused the corresponding image hotspots to be highlighted, both the user only interested in the topics and the user wanting to find the location of items known only by name would be satisfied.

Image map cannot be improved without using JavaScript. To at least retain normal capability if scripting is disabled, a standard HTML image map provides the foundation for the JavaScript improvements. If scripting is disabled, this image map will function normally.

Each hotspot in an image is defined by an HTML area tag. Most style rules do not work with areas. Otherwise, every tag could be styled with no border but restyled with a visible border at rollover. It might even be possible to provide this in a CSS rollover to avoid scripting. But this wouldn't support highlighting hotspots when rolling over list items and is wishful thinking anyway since CSS cannot control an area's border.

Image map areas can be circles and polygons as well as rectangles. CSS and JavaScript can only create rectangles, which they do by controlling the border property of an element. To avoid depending on a plug-in (e.g. Java applet) which can draw anything, the hotspots are limited to rectangles.

Because an area element cannot provide its own border for highlighting, a floating transparent element is used. This element can be positioned over the area and its border displayed to give the appearence of the area's own border (if it had one). The floating box element can be either a transparent image or an anchor. In either case, the underlying map area is occluded so that the hyperlink can only be activated via the overlying box element. If the box element is an image, the link is activated by onClick="location.href=this.href;" The problem with this is that Firefox has a bug that causes all animated GIFs (e.g. the anchor bg image aniblue4.gif) to freeze after this code is executed. No other browser (not even Mozilla under Linux) has this problem.

If the box is an anchor, showAreaById assigns href from the map area to the anchor and this link works without problem under all browsers. However, IE insists on showing the href in the status bar, overwriting the more user friendly note that we try to show. Since this note is identical to the title, which shows as a tooltip, it isn't essential, but the annoying tooltip behavior (delay to show and then uncontrolled disappearance) is partially compensated by this duplication. However, it doesn't work in all cases other than IE. By default Firefox doesn't allow scripts to change the status.

Another minor anchor problem with anchor is that only an empty anchor tag draws the border exactly in all cases. This may not be legal but with a pair of open and close tags browsers extend the bottom border of the box for certain elements but not others.

The FF dead animation bug can be corrected by assigning location.hash instead of location.href when the target is a local anchor. Although this is a lot of complexity for one little bug, it does tip the balance toward image instead of anchor.

Notes

The improved image map means shown here does not function without JavaScript enabled, but the page degrades gracefully to normal area map behavior if it is not.

The transparent area overlay box element is created by the following code:

CSS (in tech.css)

.AreaBox { // Image map area outline overlay. 
  width: 1px; height: 1px;
  position: absolute; left: 0; top: 0;  
  border: solid 1px yellow;
  display: none;
}

HTML

<img src="x.gif" alt="" class="AreaBox" id="areaBox0" title=""
 onMouseOver="window.status = title; return true;"
 onClick="jumpBox()" />

This AreaBox element is hidden and does not afford a means to reveal itself. It appears only when the mouse rolls over either an image map area element or a list item. Its own onMouseOver displays the title of the underlying area element. Once an AreaBox has been placed over the area, the area won't see any mouse events so the AreaBox has to provide the hyperlink. It might also hide itself at onMouseOut but browsers frequently miss this event. Consequently, all visible AreaBoxes are removed when one or more others are displayed. Often this action leaves the last box(es) displayed even when the cursor leaves the image and the associated links. This doesn't hurt and, in some circumstances, improves the user interface. For example, when the cursor rolls over an associated link, the related areas are outlined. If the user clicks to go to the topic, the areas remain highlighted; the browser next and back buttons toggle the view between the topic and the image with the related areas still highlighted. For hyperlink, the AreaBox calls the script function jumpBox at onClick. The underlying area has an href but the AreaBox itself is an img, which doesn't afford automatic hyperlinking.

A single instance of the AreaBox would suffice for the direct area rollovers. However, the associative rollovers could benefit from being able to highlight several items at once. Often multiple areas in the image are related and have the same hyperlink href. A simple and useful functional relationship would be to highlight all areas that have the same href as the list name that the mouse rolls over. It would be tedious and error prone to create an arbitrary number of AreaBox elements in the HTML code. Instead, a JavaScript, executed when the page loads, creates additional boxes by cloning the areaBox0 defined by HTML. The first element of array refBox is assigned a reference to the original HTML box. Successive array elements are assigned references to the cloned boxes. Subsequently, all referencing is through these elements and, therefore, none of the boxes need to be named except the original, which the script finds using getElementById. However, all of the clones have to be named anyway because otherwise they all have the same id, inherited from the original, which is illegal. The script synthesizes their names as areaBox1, etc. For subsequent run-time efficiency, this script also assigns references to the image and its div parent and the HTML map element to global vars refMapImg, refMapDiv, and refMap.

JavaScript (in area.js)

refBox[0] = document.getElementById( "areaBox0" );
for( idx = 1 ; idx < boxCnt ; idx++ )
{
  refBox[idx] = document.getElementById("areaBox0").cloneNode( true );
  refBox[idx].id = "areaBox" + idx;
  document.body.appendChild( refBox[idx] );
}
refMapDiv = document.getElementById( "mapDivId" );
refMapImg = document.getElementById( "mapImgId" );
refMap = document.getElementById( "mapId" );

An image area's outline is drawn by assigning the position and size of an AreaBox to match the area element's coordinates; and the areaBox's display property is changed from none to inline. Since this operation is the same whether triggered by direct or associative rollover, it is implemented by one function, showAreaByRef, which is called in either case. In either case, the function does a little extra work to provide something that only the other case needs. The direct rollover needs to copy the hyperlink href from the underlying area to make it available in case of mouse click. This serves no purpose for the associative rollover but doesn't hurt. For the associative rollover, the function has to select the next free AreaBox and advance the refBox index so that successive invocations highlight additional areas. The direct rollover always uses exactly one AreaBox.

JavaScript (in area.js)

function showAreaByRef( aref )
{
  if( boxIdx >= boxCnt )
    hideShowAreas(); // Correct for browser missing mouse outs.
  var posLeft = -refMapDiv.scrollLeft;
  var posTop = -refMapDiv.scrollTop;
  for( var ref = refMapImg ; ref != document.body ; ref = ref.offsetParent )
  {
    posLeft += ref.offsetLeft;
    posTop += ref.offsetTop;
  }
  var coords = aref.coords.split( "," );
  window.status = aref.title;

/* Copy href from the underlying area to global jumpHref Unlike other 
* attributes that are copied from the AREA to the refBox object, this doesn't 
* exist when the refBox object is an IMG instead of an A. Fortunately, also 
* unlike the other elements, only one href is needed. When it is assigned by 
* AREA mouseOver, it defines the jump target. That it is reassigned at 
* additional refBox activations is irrelevant for two reasons. One is that 
* multiple refBoxs are active only due to mouseOver another element (normally 
* an A) in which case the AREA href wouldn't be used. The other reason is that 
* all active refBoxs would have the same href anyway (and it would be the same 
* as the other element) since that is the tie that binds them all in the first 
* place.
*/
  jumpHref = aref.href;
  refBox[ boxIdx ].title = aref.title;
  refBox[boxIdx].style.display = "inline";
  refBox[boxIdx].style.left = posLeft + parseInt( coords[0]) + "px";
  refBox[boxIdx].style.top = posTop + parseInt( coords[1]) + "px";
  refBox[boxIdx].style.height = parseInt( coords[3]) - parseInt( coords[1]) + "px";
  refBox[boxIdx].style.width = parseInt( coords[2]) - parseInt( coords[0]) + "px";
  boxIdx++;
}

The one argument to showAreaByRef is a reference to the area element to be highlighted. This is more convenient for the associative rollover than for the direct case. To simplify area attribute coding, the function showAreaById takes the id passed by an area's onMouseOver call and transforms it to a reference that it passes to showAreaByRef. Anchor elements outside the image trigger associative rollover highlighting by passing a self-reference ("this") to showRelArea. This function searches the map element's list of areas, calling showAreaByRef to highlight each area whose href matches that of the referrer. Both ShowAreaById and showRelArea first clear the previously displayed AreaBox (by calling hideShowAreas, which hides all of them) because OnMouseOut is not reliable. HideShowAreas clears every AreaBox simply by setting its display property to none. Simultaneously, it effectively frees the refBox elements by decrementing the refBox index. When the index reach 0 there are no more active boxes.

JavaScript (in area.js)

function showAreaById( id )
{
  hideShowAreas();
  showAreaByRef( document.getElementById( id ));
}

function showRelArea( aref )
{
  hideShowAreas();
  for( var idx = 0 ; boxIdx < boxCnt && idx < refMap.areas.length ; idx++ )
  {
    if( refMap.areas[ idx ].href == aref.href )
      showAreaByRef( refMap.areas[ idx ]);
  }
}

function hideShowAreas()
{
  while( boxIdx > 0 )
    refBox[ --boxIdx ].style.display = "none";
}

HTML Direct (AREA) and Associative (A) Rollover Element Examples

<area shape="rect" coords="20,4,60,17" href="#yvalve" 
  title="JYV0: Y-valve interface" alt="JYV0: Y-valve interface" 
  id="hsJyv0" onMouseOver="showAreaById( 'hsJyv0' );" >

<li><a href="#yvalve" 
 onMouseOver="showRelArea( this )" >Y-Valves</a></li>

With certain page layouts, Internet Explorer 6 draws the boxes two pixels to the left No other browsers, including earlier versions of IE exhibit this error. IE is infamous for positioning errors in general. In this case the discrepancy is clearly a program error rather than a difference of interpretation because the boxes are placed exactly where the DOM says the underlying areas are located. Either the image is placed incorrectly relative to the DOM information or the DOM misunderstands the page frame of reference.

The browser takes care of hyperlinking in the case of associative rollover because the anchor has a fully functional href. The equivalent action must be synthesized by script for direct rollovers because the overlaid img doesn't have this attribute. ShowAreaByRef copies underlying area attributes that the img tag also has, such as title, to the AreaBox img for use while hovering over the area. It copies the area's href to global var jumpHref. The areaBox's onClick calls jumpBox to effect a hyperlink jump. No arguments are needed because jumpHref identifies the jump target while the identity of the source is irrelevant. JumpBox could simply assign the value of jumpHref to the browser's location.href except for a bug in Firefox, as explained in the code shown here.

JavaScript (in area.js)

function jumpBox()
{
/* For all browsers except Firefox, we would only have to assign location.href 
* to successfully make the jump. Firefox stops playing animated GIFs (like my 
* anchor hover) when this means is used to jump to a local anchor. All of the 
* code here serves only one purpose-- to work around the FF bug. If the base of
* the target URL is the same as the current page then location.hash is assigned
* instead of the full href. The FF bug does not occur in this case. 
*/
  var boxAhref = jumpHref.split( "#" );
  if( boxAhref.length == 1 ) 
    location.href = jumpHref; // Target URL doesn't include an anchor point.
  else
  {
    var locAhref = location.href.split( "#" );
    if( boxAhref[0] == locAhref[0])
      location.hash = boxAhref[1];
    else
      location.href = jumpHref;
  }
}

HTML

<table cellpadding=0 cellspacing=0 border=0 ><tr>
<td valign="top" width="100%" >
<div class="LinkBar">
...
</div>                <!-- End LinkBar  -->
</td>
<td valign="top">     <!-- taskbar and PCB image  -->
<ul class="TaskBar">  <!-- Begin Taskbar  -->
...
</ul>                 <!-- End Taskbar -->

<div class="Content"> <!-- Begin Content  -->
<div class="UnitId">9602330-rev P14</div>
<h2><span class="Hout">PCB IMAGE MAP 
<div id="mapDivId" > 
<img  src="rpm5map.jpg" 
</div> <!-- mapDivId -->
</div> <!-- Content --> 
</td></tr></table>

<div class="Content">
<h2 id="purpose"><span class="Hout">PURPOSE

For the indirect links to serve their purpose, the image and the sidebar must be aligned at least enough so that the corresponding image areas are visible when hovering over a sidebar link. To make this alinment, the contents of the sidebar can be arranged and/or padding added or removed from the image container. In any case, the sidebar and image container must be side-by-side, which requires that they be table cells or floated. The best result is achieved by float:left sidebar and overflow:auto image container. Overflow:auto gives the image its own horizontal scroll bar if needed without impacting the rest of the page. Unfortunately, only Mozilla/FF does this correctly. Therefore, this page uses a table. The side/link bar occupies one cell, while the top/task bar and image occupy the next cell in the single row of the table. The rest of the page can do anything. This page is fairly fluid, flowing paragraphs and code boxes around each other.

In the HTML code note that the TaskBar div inside of the td cannot be reduced to just a td with class TaskBar because the div props open the cell to prevent the browser from shrinking it when the window isn't wide enough for the image. This behavior is better than having the link list reformat just to give the image a few more pixels.


SPECIALIZED STYLING

A technical website has special style and formatting requirements that differ from what would be appropriate for a broader audience. This page and the external style sheet, tech.css, illustrate some of these requirements.

Overflow Auto

The image map, which is discussed at length above, plays a much more important role in a technical site than in a more general one, where it serves mainly to relieve the monotony of selecting topics from a list. Some users will be coming to the technical site with only the physical item for reference, for example a technician with a PCB in hand. The JavaScript image map augmentation is an obvious improvement. Less obvious is the use of the overflow: auto property. For browsers that support this, the image is scrolled independently of the text. Large images can often be divided into smaller ones either by sectioning or by hierarchical decomposition (i.e. coarse resolution of a more encompassing image linking to less encompassing images with finer resolution). However, certain types of technical images do not respond well to either of these techniques. The printed circuit board image on this page is a good example. Users need to see both the detail and the overall arrangement simultaneously. Small boards may display acceptably in relatively large browser windows but larger boards will have to be scrolled. The best user experience results from no scrolling but, if scrolling is needed, small differences in the image size are of little consequence. Keeping the page arrangement is more important than maximizing the image window, as demonstrated by comparing this page as rendered by Internet Explorer, which doesn't support auto overflow, and as rendered by Firefox, which does. Under Firefox, when the browser window width shrinks to impinge on the PCB image, the image acquires a scrollbar but remains in place and most of the associative rollovers are visible. Under IE, the PCB image jumps down to below the linkbar where the space available for the image is somewhat larger but the user can't simultaneously see the highlighted areas and the associated anchors.

Unfortunately, testing on various browsers has demonstrated that only Mozilla/FF correctly handle the overflow:auto in this example. Most other browsers make a mess of the page. Those that at least properly move the image down to under the linkbar still are making the advanced image map capability useless. To make this page work in most browsers the overflow:auto has been removed.

HTML

<div id="mapDivId" style="overflow:auto;"> <!-- If the browser does this (IE doesn't) instead of
  moving other things to fit the image, a scroll bar is attached to the image. -->
<img  src="rpm5map.jpg" 
 id="mapImgId"
 alt="RPM5 PCB" 
 width=562 
 height=290 
 border=0 
 usemap="#map" />
</div>

JPG Optimization

All websites benefit from reducing image file size but certain technical images, such as PCBs, afford opportunities that may not exist in a more general site. The complexity of details in a PCB image dictate that JPG be used. Reducing the quality of a JPG image reduces file size but significant reduction leads to visible artifacts. These only appear in large flat spaces unless the quality is extremely reduced. In a general-purpose image such degradation is very evident and annoying. In a PCB image the opposite is true. Large flat spaces are of no interest whatsoever. Consequently, extreme optimization is feasible. Even where the size of the image is not reduced the size of a JPG PCB image file can be reduced to 5% of the original without degrading its effective presentation.

Technical Page Elements

A website presenting technical information often is considerably more repetitive than a more general site, where such repetition would likely bore most visitors. Consistency of presentation of technical material is especially important because the visitor is already unsure about how much importance to attach to content details. The technical style sheet, tech.css, defines some specific technical styles so that the web pages don't have to resort to HTML formatting or local styles.

CSS (in tech.css)

.UnitId  { /* Unit ID class for div or h used normally in upper, right corner of page. */
  margin: 0 10px; 
  padding: 0; 
  text-align: right;
  font-weight: normal;
  font-size: 20px;
  font-family: arial,sans-serif; 
}

.Hnote { /* span class for parenthetical note in heading */
  color: gray;
  font-weight: lighter;
  font-size: smaller;
  text-transform: lowercase; 
}

.Hitext { background-color: rgb( 194, 239, 255 ); } /* Light blue highlight. */

code { font: 120% "Courier New", Courier, monospace; color: blue; }

.CodeBox      { border: solid 2px blue; padding: 0 3px; margin: 10px 0; }
.LeftCodeBox  { border: solid 2px blue; padding: 0 3px; margin: 0 10px 10px 0; float: left; }
.RightCodeBox { border: solid 2px blue; padding: 0 3px; margin: 0 0 10px 10px; float: right; }
.CodeBox      * { margin: 0 2px 2px 2px; }
.LeftCodeBox  * { margin: 0 2px 2px 2px; }
.RightCodeBox * { margin: 0 2px 2px 2px; }

HTML

<div class="UnitId">9602330-rev P14</div>

<h2>PCB IMAGE MAP <span class="Hnote">(CLICK on items for details)</span></h2>

<li>The <code>Hitext</code> class style describes the rendering of highlighted 

<div class="LeftCodeBox">
<h3>CSS</h3>
<pre style="margin-top: 0">
...
</pre>
<h3>HTML</h3>
<pre style="margin-top: 0">
...
</pre></div>
Site Map   Home   Home   Prev   Next   Top   Valid HTML   Valid CSS  
JYV0: Y-valve interface JYV1: Y-valve interface JSTAT: direct I/O status board JSB: Obsolete-- don't use JSNS1-8: Strobed fluid sensors Fluid sense components JSNSR1-8: General purpose sensors JPWR: DC Power JSV1: Old shear valve interface JSV0: Old shear valve interface JNSV1: New shear valve interface JNSV0: New shear valve interface New shear valve driver JPLDI: PLD alternate use inputs JPLDO: PLD alternate use outputs Configuration jumpers JTAG: PLD programming JTEST: PLD testing PLD JSCLK: clock speed jumper Scan chain register bypass jumpers Scan chain output registers Scan chain input registers JLPM: Scan chain to LPM JAPU: Scan chain to APU Solenoid pre-drivers Fuses Solenoid drivers JSOL1-27: Solenoid jacks