Professional Documents
Culture Documents
Version: 0.12
Date: July 7, 2006
Sabre
User’s Manual
DRAFT
I.3. AUDIENCE
This document is aimed at readers with a technical understanding of hardware
engineering fundamentals, as well as a basic understanding of the VME bus and
computer graphics hardware and software.
1 INTRODUCTION
Sabre is a display processor for graphics, video and radar applications. It
combines a high-performance processor with dual-head graphics, flexible
video capture and sophisticated video mixing capabilities to offer an
embedded display processor for VME or network-based command and
control display solutions.
Sabre can function as a VME card in a chassis with other cards, including a
host processor to run the application software. Alternatively, Sabre can
function as a network-based display processor, for example in a standalone
enclosure, which interfaces over a high-speed network for graphics, video
and radar data receipt.
Sabre-L - Sabre Graphics Card. Supports dual head graphics with straight 8
or 24 bit architecture (no underlays, overlays, video, or radar). Single slot
assembly.
Sabre-G - Sabre Graphics Card. Supports dual head graphics with underlay
and overlay framestore. (no video, no radar). Single slot assembly.
Sabre-V - Sabre Graphics + Video. Support Graphics and Video capture from
TV, RGB. Single slot assembly. Includes embedded X Server and video
windows control software.
Dual 10/100/1000 TX
Ethernet
Embedded X Server
providing colour graphics on
dual heads
The Sabre card shown in Figure 1 is fitted with the Eagle-S scan-converter
and the heatsink is removed to show all the components.
PCI Bus 0
PowerPC
750GX Processor PCI Bus 1 PMC Site
P4
M9 Graphics M9 Graphics
Video on PMC P4
Processor Processor connector, for example
VME
from Eagle-S radar scan
Interface Overlay Underlay Overlay converter
Underlay
32M
FLASH
Head A analogue +
256/512 MB DDR
Video Mixer DVI-D video output
Memory UART
Discovery Overlays, Mixing and Alpha Blending
III
Bridge Head B analogue +
USB DVI-D video output
Screen
Ethernet Video Scaler Video Scaler
capture
(Front panel)
GigaBit
PHY
There are two parts to the Sabre software. The Sabre embedded software
runs on the card and is started automatically when the card initialises. The
Sabre client software is a set of software libraries that run on your
application processor and talk to Sabre for control and data exchange.
For most situations, there is no need to be aware of the embedded software
running on Sabre, other than through the well-defined interfaces that they
present to the application software. Sabre software interfaces, including RVP
where it is being used, are shown in Figure 3
Application Software
Radar
Video
Processing
X Windows
RVL RVP MPF
Libraries
Client Client
(Motif, Xt, Xlib,
Libraries Libraries RVL
X11, GTK) X Server
Server
Network Interface
RVP Control
Messages
RVL Control
Messages
RVP Software
X Windows
protocol
Network radar
video RVP
Radar Video Processor
In the normal mode of operation, Sabre takes all its control and data input
from the network interfaces. For this reason, although it can be deployed in
a chassis with other VME cards, it is equally at home as a standalone display
card that receives graphics requests, radar and video data and connects
directly to the display.
Although Sabre has its own on-board graphics capability, in some situations
it may be desirable to use an external graphics card, restricting Sabre’s role
to being a radar or video display server. In this situation, Sabre may be
fitted with Curtiss-Wright’s Eagle card (instead of the Eagle-S that is
normally supplied as part of the Sabre-R configuration). This configuration
allows Sabre to be used with a Windows-based graphics application for
example. The output of the Windows graphics card would be an input to the
Eagle scan-converter fitted on Sabre. Sabre would be responsible for
inserting the radar or video picture inside the graphics display. Although this
problem could be solved in other ways (for example in PCI configurations
use the Advantage-Xi in the same rack as the graphics card), the Sabre
solution allows for a clean decoupling of graphics and radar ensuring that
the activities of one do not affect the activities of the other.
RVP Servers User Manual – Describes the RVP server in more detail.
2 CONFIGURATION
This card uses components that are sensitive to electrostatic discharges. It must
be kept in its conductive package until just before the installation begins. Remove
the card from its protective package only at a grounded workstation while
wearing an approved grounding wrist strap. Avoid touching any metal contacts on
the card; static discharge can damage integrated circuits.
Warning
Sabre cannot function as a VME slot 1 controller. Sabre must either be the
only card installed on the bus, or else the bus must provide a slot 1
controller elsewhere.
Paddle boards are available for Sabre to provide access to the P2 signals.
There are two available Sabre paddle boards, described below:
Sabre must be installed in a chassis with adequate air flow. The card
requires an air flow of 10 cubic feet minute for operation at the extreme of
temperature. For air flows less than this the operating envelope of the card
is affected.
Aim for 400 Linear Feet per Minute (LFM), or about 2 m/s of airflow across the
heat sink of the card. You can usually get this much air with a fan rated at 100
Caution CFM.
2.7 CONFIGURATION
For initial testing and set-up of Sabre it is highly recommended that a
terminal is connected to the COM A serial interface on the Sabre board. The
same serial interface is available on the P2 connector and is brought out on
the Sabre paddle card. This interface provides a command prompt where it
is possible to interact with the Sabre card and adjust power-up settings such
as network addresses and display resolution.
Your card should have been supplied with a serial cable (part number
900520 or CBL-C900-0-0520) to connect to the on-board serial interface.
Refer to Section 1.3 for the location of the serial connector for
communications port A (COM A).
The COM A serial interface is set to work at 115200 baud, 8 bits, no parity, 1
stop bit and no flow control.
DEVICES
DEV 0: base - 0xf4000000 size - 8M bytes width - 8 bits - UARTs + Reg
DEV 1: base - 0xf4800000 size - 8M bytes width - 32 bits - Dual-Port SRAM
DEV 2: base - 0xf5000000 size - 8M bytes width - 8 bits - JPEG encoders
DEV 3: base - 0xf5800000 size - 8M bytes width - 8 bits - Video
BOOT: base - 0xfc000000 size - 64M bytes width - 16 bits
FLASH: 32 MB
PCI Scan: Found Bus 0, Device 2, Function 0
PCI Scan: Found Bus 0, Device 2, Function 1
PCI Scan: Found Bus 0, Device 2, Function 2
PCI Scan: Found Bus 1, Device 1, Function 0
PCI Scan: Found Bus 1, Device 2, Function 0
In: serial
Out: serial
Err: serial
Net: In MV6446x_eth_initialize
mv_enet0, mv_enet1
Hit any key to stop autoboot: 0
## Booting image at ffd00000 ...
Image Name: Linux-2.6.14Sabre-beta2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1187658 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Uncompressing Kernel Image ... OK
IP address: 192.168.129.185
Sabre login:
When the boot of the card is complete the login prompt “Sabre login” should
be shown.
Connect a display to the Head 1 video output connector on the front of the
card. The factory default is a 1280 x 1024 x 60 Hz picture output on both
the analogue and DVI-D signal lines. The initial picture is the X Windows root
screen, which is a grey stipple pattern with a cursor centered in the screen.
Connect a USB keyboard and mouse to the front-panel USB connectors. This
can be done with power applied to the card.
Verify that movements of the mouse cause movements of the pointer on the
display.
From the “Sabre login” prompt, login to the card using the login root, with
no password. Sabre runs embedded Linux, and the standard Linux facilities
are available for basic maintenance and administration. Do not change or
edit files in Sabre, unless following a procedure described in this manual or
from instructions provided by Curtiss-Wright support engineers.
Sabre has two physical Ethernet interfaces, one on the front panel and one
on the VME P2 connector. Both of these interfaces can operate at 10, 100 or
1000 Mbits/sec speeds.
The active interface has an Internet Protocol (IP) address that must be
consistent with the addressing class used on the network that Sabre is
connected to. In general you will have to change network address of the
Sabre card from the factory default.
From the monitor prompt, set the new IP address with the following
sequence of commands:
where the desired IP address is aaa.bbb.ccc.ddd. Reset the card using the
front-panel reset switch.
For 010 version boards, reset the card with the front panel switch to restart
with the new IP address.
For 020 version boards, power down the card, remove the BOOTM link and
restart.
Sabre has two network interfaces. At the time of writing only one of them is
configured as the active interface. The factory default uses the front-panel
Ethernet interface. The active interface can be set as follows.
Use a terminal interface and interrupt the Sabre start-up to get into the
Sabre monitor. At the command prompt, enter the following command to
configure the interface for front-panel
The card will need to be reset using the front-panel reset switch for the
change to take affect.
To configure the card for this, use a terminal interface and interrupt the
Sabre boot to get the monitor prompt.
Sabre has a VME slave interface, which means that it can be accessed by
master VME devices on the same bus.
The VME interface is currently unsupported on Sabre Beta-2 boards.
It is not possible to change Sabre’s video output format from a program. The
change currently has to be made in the configuration file and then the card
reset.
Note that the xorg.conf.sabre file is not used to configure any input
formats for video grabbing. That configuration occurs through software in
the RVL programming interface.
Within Sabre, graphics and video are processed with independent data paths
(specifically the video data does not go through the graphics processor),
meaning that the video processing can be set to acquire and scale dual video
sources with no impact on the graphics performance. Furthermore, because
the video display uses a separate display frame store to the graphics,
overlays or even underlays to the TV video can be created without the
complexity of intermediate buffers.
All video inputs are received through the VME P2 connector. Supported input
types are shown in the table below:
Video Scaler A 1 x RGBHV Non-interlaced video from 640 x 480 Separate H & V
up to 1600 x1200. syncs or sync on
green
Interlaced video from 640 x 480 to
875 line.
Video Scaler B 1 x RGBHV Non-interlaced video from 640 x 480 Separate H & V
up to 1600 x1200 syncs or sync on
green
Interlaced video from 640 x 480 to
875 line.
Refer to Section 2.5.3 and 7.3 for details of the paddle boards that provide
connectivity for the video inputs.
There is a one-to-one mapping between the video scalers (A and B) and the
video windows on the display. This means that an input that is physically
wired to scaler A cannot be displayed by scaler B, for example. Similarly, the
same input cannot be simultaneously displayed in two windows.
V1
Sabre can display up to 2 video
windows, which can appear on head
V2
1 or head 2 or one on each head. A
typical set of video display modes are
shown in Figure 8. Two video windows on head 1
V1
V2
V1 V1
x V2
If two video windows are created on the same head it is possible to change
the priority of the two windows.
If video and radar windows are created on the same head then the video
window always has priority (must be on top) of the radar window.
With RVP configured and connected to the network, Sabre is able to receive
compressed radar video. This video can be decompressed by Sabre and
scan-converted to give a PPI or B-scan display. Refer to Figure 3 for a
typical software configuration that includes Sabre, RVP and an application
processor.
The Eagle-S scan-converter fitted to Sabre receives radar video over the
local PCI bus from the Sabre main card. Under software control from the
application (using RVL), the Eagle-S will generate one or more radar views.
The output from Eagle-S is then connected back into the Sabre main card,
where it is mixed with the graphics display. Under normal mode of
operation, Sabre combines the underlay graphics with the radar to allow the
radar video to appear to semi-transparently mix with the underlay. This
mixing is automatic and is handled by the Sabre hardware, so that the
application programmer need only write graphics data into the underlay
display screen for it to appear blended with the radar video. The contents of
the overlay screen is then combined with the underlay and radar, such that
the combined radar and underlay is only visible where the overlay shows the
chroma key colour. Refer to Section 5.1.2 for more details of the colour
mixing.
Sabre can only use one of the two display heads for radar display. There can
be several windows supported simultaneously, but they must all be on the
same head. Refer to the RVL programming documentation for an explanation
of how to change the display head used for radar.
Sabre can be used on a network with a number of RVP servers. Since RVP
uses a multicast approach to distribute the video, there can be any number
of Sabre-type display clients that are receiving the video with no
degradation of network performance.
It is possible to use Sabre with a network source of radar video that is not
provided by RVP. Sabre will expect to receive the video in Curtiss-Wright’s
MPF (Message Passing Format), so the radar server will need to generate
this. Further, the radar video will need to be compressed with Curtiss-
Wright’s RACE compression scheme. The RACE libraries are available for a
number of platforms. Refer to the factory for more information if you would
like to use your own source of radar video. Where possible, it recommended
that RVP is used as the network source.
The RX model of Sabre is available with a fitted radar interface card that
allows direct connection to radar interfaces. The interface will include
analogue or digital radar video, trigger and turning data provided by
ACP/ARP signals or RADDS data stream. In this configuration, Sabre is a
two-slot module. The single PMC site on the card is split into two sites for
the radar interface card and the radar scan converter.
In principle it is possible to use the VME interface to bring radar video from
another processor card. This is not implemented as standard. Consult the
factory to discuss details of your requirement.
If two radar windows are created on the same head it is possible to change
the priority of the two windows using the RVL software.
If video and radar windows are created on the same head then the video
window always has priority (must be on top) of the radar window.
5 PROGRAMMING SABRE
Sabre is programmed through a number of application programming
interfaces (APIs). Depending on your application and which version of Sabre
you are using, you may need require all of these interfaces.
In a radar display application, it is possible that the source of the radar video
is a remote radar video server, such as Curtiss-Wright’s RVP product. In this
situation, the application software will also be responsible for configuring
RVP.
The X Windows client libraries are normally supplied with the operating
system of the application processor. (Curtiss-Wright generally does not
supply the client libraries) The X Windows software release will comprise a
set of libraries, header files and pre-built executables. For example, one
simple pre-built application is called xclock. It is a simple X client program
that displays a clock showing the current time. When this program is run on
the application processor it will need to know the address of the X server
that will provide the display - the Sabre X Server will be listening at this
address. The xclock program will send graphics requests to the server to
display the picture. Significantly this can happen without the application
processor knowing that it is connected to a Sabre card – the X protocol is a
standard interface that will work out-of-the-box with any application
processor supporting an X Windows display environment.
from the application processor will give an xclock display on each of the two
heads of the card.
This section does not apply to the Sabre-L card, which does not support
separate underlays and underlays.
Looking at one head graphically, the overlay displays the xclock window on a
grey (by default) background by using the following program from the
application processor:
output display shows two clocks. The one in the upper right is visible
because it is in the overlay. The one in the lower right is visible because it is
in the underlay and the overlay shows magenta in that area. The
background of the display shows yellow because the overlay is filled with the
chroma key colour and the background of the underlay in yellow.
Figure 10:
Overlay and
Underlay
Combination
with chroma
keying
Useful experience with Sabre’s colour handling and overlays/underlays can be achieved
using command–line programs such as xclock and xsetroot. It is recommended that
application developers familarise themselves with these principles before writing any X or
Note
RVL software. Use xclock to create a client window, as described in the text, and use
xsetroot to fill a screen with a solid colour, for example:
will fill the underlay on head 1 with yellow (assuming Sabre is at the default IP address).
Refer to standard X programming documentation for full details of the parameters that can
be used with these client programs.
There are two ways to change the chroma-key colour in Sabre. The first is to
change the default value that the card uses in the card configuration file.
The second way is to set the chroma-key colour programmatically with RVL.
The facility to change the default value is not supported in the Beta-2
software.
The details of how to change the chroma-key colour through the RVL
software interface is contained in the RVL Programming Guide.
8-bit Pseudo colour 8-bit pixels mapped to 24-bit RGB through look-up table
8-bit GrayScale 8-bit pixels mapped to 24-bit RGB through look-up table
8-bit StaticColor 8-bit RGB organised as 3-3-2 mapped to 24-bit RGB through
look-up table
8-bit TrueColor 8-bit RGB organised as 3-3-2 converted into a 24-bit RGB
output.
16-bit DirectColour 16-bit pixels organised as 5-6-5 (RGB) converted to 24-bit RGB
through 3 x 8-bit look-up tables
24-bit DirectColor 24-bit RGB indirectly output through 3 x 8-bit look-up tables
24-bit TrueColor with 8- 24-bit RGB directly output with programmable transparency on
bit transparency the window.
24-bit DirectColor with 24-bit RGB indirectly output through 3 x 8-bit look-up tables
8-bit transparency with programmable transparency on the window
If the display is configured for 8-bits per pixel, each pixel is converted into a
colour using an 8-to-24 look-up table. In terms of the Sabre overlays and
underlays, the overlay transparency colour (by default magenta) must then
be programmed into one (or more) entries of the look-up table and then
that entry index must be used as the transparency value in graphics
operations.
For 16-bit colour modes, the frame-store holds an RGB value with 5-bits for
red, 6 bits for green and 5 bits for blue. This gets converted to a 24-bit
output using a separate look-up table for each of the 3 colour components,
converting red, green and blue separately. It is important to understand that
the 16-bit mode is not a pseudo colour visual in the same way as the 8-bit
mode.
For a 24-bit TrueColor the contents of the frame store are held as 24-bit
RGB values, and these values are output directly. There is no look-up table.
This is the most direct way of controlling colours – what gets written into the
frame store is what comes out.
For a 24-bit DirectColor mode, the frame store holds a 24-bit RGB value, but
this is converted on the output into another 24-bit RGB value using three
separate look-up tables. The look-up tables convert the red, green and blue
components of the colour separately and are often used to implement
gamma correction to allow an application to display colours accurately on
different monitor types.
will start two instances of the mwm Window Manager, assuming Sabre is at
the default IP address. Note that the 0.0 and 0.1 suffixes instruct the
instances of the Window Manager to manage screens 0 and 1 in the X
Server. These are the two overlay screens.
For the purposes of video and radar acquisition and display, Sabre uses the
RVL software libraries and interfaces. This is similar to, but different from,
the PARIS interface that is used with other Curtiss-Wright products.
Although Sabre provides a separate screen for underlays and overlays, some
applications may prefer to use only the overlay. This may be because of
constraints of a third-party toolkit as described in Section 5.1.7, or it may be
that the application has already been written to use only one physical layer
of graphics.
The green power LED should come on when power is applied and stay on all
the time. It lights when the +5V and +3V3 external supplies and the on-
board +2V5 and processor core supplies are above their minima. If it fails to
light, check the external +5V and +3V3 - if these are good, then the card
may be faulty.
The red LED should come on briefly for half a second at power-up or reset,
then blink twice then stay off. Pressing the reset button will always bring this
LED on. If the red LED is always on and nothing is happening, the card may
be stuck in reset. In this situation, check the VME reset jumper (refer to
Section 2.2).
Boot Sabre with a serial console (see Section 2.8) connected and verify the
IP address is set-up correctly for your network. Use the ping utility from a
remote machine to verify that Sabre is responding at the expected IP
addfress.
Verify the current monitor environment against the default at the end of this
section.
Check serial console settings are correct – should be 115200 baud no parity
8 bits.
Boot Sabre with a serial console attached then interrupt the boot during the
start-up to get the monitor prompt: Type the following command:
=> imls
Image at FFD00000:
Image Name: Linux-2.6.14Sabre-beta2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1187658 Bytes = 1.1 MB
Check whether the Kernel you are running verifies correctly. If the kernel
fails to verify, then the image must be re blown to flash using the U-Boot
boot monitor and a tftpboot server loaded with an appropriate kernel image
file.
From the Sabre prompt, type printenv to get the environment variables.
The factory-default settings are as follows:
Sabre=> printenv
bootdelay=1
baudrate=115200
loads_echo=0
serverip=192.168.129.254
rootpath=sabretestme.img
make_cmdline=setenv bootargs root=${root}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${interface}:off
gatewayip=192.168.0.5
netmask=255.255.255.0
console=ttyS0,115200n8
interface=eth0
hostname=Sabre
root=/dev/mtdblock1 ro rootfstype=jffs2 rootflags=noatime fastboot
ethact=mv_enet0 ethaddr=00:0d:26:61:20:0e eth1addr=00:0d:26:61:20:0f
ipaddr=192.168.129.185
bootargs=root=/dev/mtdblock1 ro rootfstype=jffs2 rootflags=noatime fastboot
ip=dhcp bootcmd=run make_cmdline; bootm 0xffd00000; stdin=serial stdout=serial
stderr=serial
7 CONNECTIONS
7.1 FRONT PANEL
1 PWR 3 DP[H]
2 DP[L] 4 GND
7.2 P2 CONNECTORS
Sabre VME P2 Connections
Z A B C D
1 ET MX1[H] +5V USB 3 DP[H]
2 GND ET MX1[L] GND USB 3 DP[L]
3 ET MX2[H] USB 3 PWR COM A - RTS
4 GND ET MX2[L] A24 USB 3 GND COM A - DTR
5 ET MX3[H] A25 USB 4 DP[H] COM A - CTS
6 GND ET MX3[L] A26 USB 4 DP[L] COM A - DSR
7 ET MX4[H] A27 USB 4 PWR
8 GND ET MX4[L] A28 USB 4 GND COM B - Tx
9 ET SCREEN A29 COM A Tx COM B - RTS
10 GND COM A Gnd A30 COM A Rx COM B - DTR
11 SCA-VS[H] A31 SCB-VS[H] COM B - Rx
12 GND SCA-VS[L] GND SCB-VS[L] COM B - CTS
13 SCA-HS[H] +5V SCB-HS[H] COM B - DSR
14 GND SCA-HS[L] D16 SCB-HS[L] COM B - Gnd
15 TMDSA-D0[H] D17 GND TMDSB-D0[H]
16 GND TMDSA-D0[L] D18 GND TMDSB-D0[L]
17 TMDSA-D1[H] D19 +3V3 (IN) TMDSB-D1[H]
18 GND TMDSA-D1[L] D20 +3V3 (IN) TMDSB-D1[L]
19 TMDSA-D2[H] D21 +3V3 (IN) TMDSB-D2[H]
20 GND TMDSA-D2[L] D22 +3V3 (IN) TMDSB-D2[L]
21 TMDSA-CK[H] D23 GND TMDSB-CK[H]
22 GND TMDSA-CK[L] GND GND TMDSB-CK[L]
23 SCA-TV1[H] D24 SCB-TV1[H] SCB-TV3[H]
24 GND SCA-TV1[L] D25 SCB-TV1[L] SCB-TV3[L]
25 SCA-TV2[H] D26 SCB-TV2[H] SCB-TV4[H]
26 GND SCA-TV2[L] D27 SCB-TV2[L] SCB-TV4[L]
27 SCA-RED[H] D28 SCB-RED[H] SCA-TV3[H]
28 GND SCA-RED[L] D29 SCB-RED[L] SCA-TV3[L]
29 SCA-GRN[H] D30 CB-GRN[H] CA-TV4[H]
30 GND SCA-GRN[L] D31 SCB-GRN[L] SCA-TV4[L]
31 SCA-BLU[H] GND SCB-BLU[H] GND
32 GND SCA-BLU[L] +5V SCB-BLU[L]
ET is Ethernet.
USB is Universal Serial Bus.
COM is serial communications (RS-232).
SCA is analogue video inputs for video scaler/window A.
SCB is analogue video inputs for video scaler/window B.
TMDSA is DVI-D input for video scaler/window A.
TMDSB is DVI-D input for video scaler/window B.
RGB input is through the VME P2 connector. There are two video scalers,
designated as Scaler A and Scaler B. Inputs to these scalers are:
TV (or S-video) input is through the VME P2 connector. There are 4 video
inputs for each scaler. Inputs to the scalers are:
Under software control, each scaler can display video from one of the four
TV inputs.
In the case of S-video, TV1 and TV3 represent the Y and C input
respectively. Refer to the RVL Programming Guide for full details of the
control of video inputs.
1 SCB-VS[H] 23 SCB-TV2[H]
2 SCA-VS[H] 24 SCB-TV4[L]
3 SCA-HS[H] 25 SCA-RED[H]
4 - 26 SCA-BLU[L]
5 - 27 SCA-TV3[H]
6 SCA-TV2[H] 28 SCB-RED[L]
7 SCB-TV1[H] 29 SCB-GRN[H]
8 SCB-TV3[H] 30 -
9 SCB-TV4[H] 31 SCB-HS[L]
10 SCA-GRN[H] 32 SCA-VS[L]
11 SCA-BLU[H] 33 -
12 SCA-TV4[H] 34 -
13 SCB-RED[H] 35 SCA-TV1[L]
14 SCB-BLU[H] 36 SCA-TV2[H]
15 - 37 SCB-TV2[L]
16 SCB-VS[L] 38 SCB-TV3[L]
17 SCB-HS[H] 39 SCA-RED[H]
18 SCA-HS[L] 40 SCA-GRN[L]
19 - 41 SCA-TV3[L]
20 - 42 SCA-TV4[L]
21 SCA-TV1[H] 43 SCB-GRN[L]
22 - 44 SCB-BLU[L]
3 - 15 -
4 - 16 --
5 - 17 TMDS Data0[L]
6 - 18 TMDS Data0[H]
7 - 19 -
8 - 20 -
9 MDS Data1[L] 21 -
10 TMDS Data1[H] 22 -
1 - 6 DSR
2 Rx 7 RTS
3 Tx 8 CTS
4 DTR 9 -
5 GND
1 - 6 DSR
2 Rx 7 RTS
3 Tx 8 CTS
4 DTR 9 -
1 MX1[H] 6 MX2[L]
2 MX1[L] 7 MX4[H]
3 MX2[H] 8 MX4[L]
4 MX3[H] 9 -
5 MX3[L]
1 PWR 3 DP[H]
2 DP[L] 4 GND
1 PWR 3 DP[H]
2 DP[L] 4 GND
The proxy server is the application that is responsible for receiving radar
video (for example from RVP). The executable program is called proxyrvp
and resides in /home/CWDEV.
8 SPECIFICATION
8.1 SABRE VIDEO OUTPUTS
1
Input signals at resolutions of 1024 x 768 and below can be scaled down to
0.5 times input size. Input signals above 1024 x 768 resolution have a lower
scaling limit of about 0.65. For example, a 1280 x 1024 input can be scaled
down to about 832 x 665 pixels. Further reduction in size would required
clipping of the image.
2
Requires Sabre-RX fitted with Osprey radar interface. Consult the factor for
the full range of options for radar input cards.
8.10 MECHANICAL
Size: 6U VME form-factor: 233mm x 160mm
Weight: TBC
8.11 ENVIRONMENTAL
Notes
3
Sine vibration based on a sine sweep duration of 10 minutes per axis in each of three
mutually perpendicular axes. May be displacement limited from 15 to 44 Hz, depending on
specific test equipment.
4
Random vibration 60 minutes per axis, in each of three mutually perpendicular axes
5
Three hits in each axis, both directions, 1/2 sine and saw tooth. Total 36 hits
9 PROBLEM RESOLUTION
At the time of writing there is no Open-GL support for Sabre. Consult the
factory if you have specific requirements in this area, as this support may be
possible.
Can I use Sabre to display radar and video and use my own graphics
card?
Yes. Although Sabre has its own on-board graphics, these do not need to be
used. For example, if an application is Microsoft Windows-based, Sabre can
still be used as a standalone radar or video display processor that takes the
output of the graphics card and inserts radar or video. In this configuration
Sabre would be fitted with Curtiss-Wright’s regular Eagle card that has a
front-panel DVI input. Refer to the factory for more details of this.
No. The PCI site is used by Curtiss-Wright cards, for example the Eagle
scan-converter. This is generally no provision for customers to write their
own application software to run on the card.
A break-out module is being developed that will allow Sabre to host two PMC
sites. One application of this is to support the Osprey and Eagle on the card,
allowing Sabre to receive radar signals as well as a network feed. When
Sabre is fitted with the PMC break-out module it becomes a two-slot
assembly.
The preferred control method for Sabre is through one of the Ethernet
interfaces. For control and or transfer of data over the VME bus please
consult the factory for available options.
The standard mode of operation is that one of the two Ethernet interfaces is
used for control and data transfers. In principle it is possible to use both
interfaces simultaneously, each having its own IP address. This is a
specialised mode operation – consult the factory for available options.
9.2 M AINTENANCE
The Sabre board requires no regular service, but if used in a particularly
dirty environment, periodic cleaning with dry compressed air is
recommended.