File Formats

• Visualyse Binary Files
• Shaped Beams Gain Tables
• ITU Graphical Data
• Logged Data
• Terrain Data General Import File Format
• Land Use Generic File Format
• View Overlay XML Files
• Text File Format
• Service Area Wizard
• TLEs
• FS Import
• Import Tx System
• Import Rx System
• Import Non-GSO Orbit Elements

Visualyse Binary Files

Visualyse Interplanetary binary files are stored complete with all the information that is required to describe a scenario including the windows used. The file format is not available to the user.

Shaped Beams Gain Tables

The shaped beams are constructed as a table, with a grid of azimuth and elevation angles, and a gain value for each point on the grid. To ease defining complex gain tables, the data can be read in from a text file.

Two formats are available:

1. HP-CON
2. Visualyse Interplanetary

HPCON

HPCON is a standard format for antenna pattern data. The format is defined by TICRA Copenhagen, the world leader in antenna design and analysis software.

The format used is described below:

Additional data may follow such as the phase of field for each azimuth and elevation, but this is ignored.

Visualyse Interplanetary

There are two possible file formats whereby the data is read in in rows or columns.

The fields are text, separated by one of the following:

1. tabs
2. commas
3. spaces

Format 1:

The file format is described below. The square brackets would not appear in the actual file.

[AzStart] [AzStep] [AzNum] [ElStart] [ElStep] [ElNum]

[Gain X-1 Y-1]

:

[Gain X-n Y-1]

[Gain X-1Y-2]

:

[Gain X-nY-2]

:

:

[Gain X-1Y-m]

:

[Gain X-nY-m]

where:

[AzStart] = start (smallest) azimuth in degrees

[AzStep] = spacing between azimuth grid points (degrees)

[AzNum] = number of azimuth points

[ElStart] = start (smallest) elevation in degrees

[ElStep] = spacing between elevation grid points (degrees)

[ElNum] = number of elevation points

[Gain Az-i El-j] = gain of i-th Azimuth point, j-th Elevation point in dB

Format 2:

The file format is described below using the same notation as for the previous version:

[AzStart] [AzStep] [AzNum] [ElStart] [ElStep] [ElNum]

[Gain X-1 Y-1]

:

[Gain X-1 Y-n]

[Gain X-2Y-1]

:

[Gain X-2Y-n]

:

:

[Gain X-nY-1]

:

[Gain X-nY-m]

Shaped Antenna Type: Multiple Tables File Format

This section describes the file format to load Multiple Tables into a Shaped Antenna Type. The Antenna Type should use an electronically steered beam.

File Type

The fields are text, separated by one of the following:

1. tabs
2. commas
3. spaces

Header Format

The file format is described below for Shaped Antenna Type with N gain tables. The square brackets would not appear in the actual file.

[DataTypeCode] [NumberOfTables = N]

[GainTable 0]

[Azimith-1] [Elevation-1]

[GainTable 1]

:

[Azimith-N-1] [Elevation-N-1]

[GainTable N-1]

The following DataTypeCodes are valid:

101 = Gain tables dependent upon azimuth only and the elevation can be set to zero. Visualyse will select the gain table with skew angle closest to the given azimuth angle, rotate until the pattern has the same skew angle and then rotate the pattern around the sub-satellite point to align with the target pointing direction.

102 = Gain table dependent upon both azimuth and elevation. Visualyse will select the GainTable with (azimuth, elevation) closest to the beam pointing direction, and then rotate the pattern so it aligns with the target pointing direction.

The format of the field [GainTable N] is given in the following section.

The gain table Gain(az, el) reflects the beam when it is pointing at a direction = (azimuth, elevation). So, in most cases, the gain table should have it’s peak gain at the given (azimuth, elevation).

The 0-th gain table is the sub-satellite one i.e. for an (azimuth, elevation) = (0, 0) so there is no need to enter the azimuth or elevation angles for that table.

GainTable Format

The file format is described below. The square brackets would not appear in the actual file.

[AzStart] [AzStep] [AzNum] [ElStart] [ElStep] [ElNum]

[Gain X-1 Y-1]

:

[Gain X-n Y-1]

[Gain X-1Y-2]

:

[Gain X-nY-2]

:

:

[Gain X-1Y-m]

:

[Gain X-nY-m]

where:

[AzStart] = start (smallest) azimuth in degrees

[AzStep] = spacing between azimuth grid points (degrees)

[AzNum] = number of azimuth points

[ElStart] = start (smallest) elevation in degrees

[ElStep] = spacing between elevation grid points (degrees)

[ElNum] = number of elevation points

[Gain Az-i El-j] = gain of i-th Azimuth point, j-th Elevation point in dB

The gain values are loaded in azimuth rows (from lowest azimuth to largest azimuth) starting with the lowest elevation row.

ITU Graphical Data

Visualyse Interplanetary has the ability to read/write files based on the format for shaped beams specified in ITU CR/58. The file format structure is text with sections as used by Microsoft Windows INI files, i.e.:

[SectionName1]

key1=value1

key2=value2

[SectionName2]

key1=value1

key2=value2

The sections are:

1. FormatInfo: specifies the file format

2. GeoMain: contains general information such as name and satellite location

3. COHeader: specifies parameters such as number of contours and boresights

4. Bi: one section for each boresight

5. Ci: one section for each contour, specifying level and series of lat/long points

   These sections are described in more detail in the sections below.

FormatInfo

This has a single field to specify the version which is set to one, i.e.:

GeoMain

This section contains global information about the file. The fields are:

COHeader

This section describes the contours contained within the file. The fields are:

Visualyse Interplanetary adds a field to this section to specify the peak gain of the beam. This would not affect how the file is read by other systems, but is required to completely define the pattern. This field has the following structure:

Bi

There is a separate section for each of the boresights. Each section has the section name of the form Bi, for example the first boresight would have section name B1.

Each boresight section has the following keys:

Ci

There is a separate section for each of the contours. Each section has the section name of the form Ci, for example the first contour would have section name C1.

Each contour section has the following keys:

Visualyse Interplanetary will convert open contours to closed contours when reading in.

Example

The following file was produced by creating a contour antennas in Visualyse Interplanetary and then using the export to ITU file format option.

[FormatInfo]

format_ver=1

[GeoMain]

adm=DK

ntwk_org=DK

sat_name=GSO_Test_A

long_nom=-105.000

n_diag=1

[COHeader]

beam_id=1

emi_rcp=E

polar_disc=C

reason=A

gain=+30.00

n_bore=1

n_cont=3

[B1]

gain=+0.00

p=-99.559;+40.189

[C1]

gain=-3.00

n_point=30

p1=-109.008;+50.377

p2=-114.173;+49.623

p3=-120.598;+48.491

p4=-123.370;+47.547

p5=-124.126;+42.075

p6=-122.866;+37.170

p7=-120.724;+34.151

p8=-117.449;+32.264

p9=-114.551;+29.434

p10=-109.260;+28.679

p11=-105.102;+25.660

p12=-99.685;+23.208

p13=-96.913;+25.849

p14=-90.488;+28.679

p15=-86.079;+26.981

p16=-81.921;+23.396

p17=-77.890;+21.321

p18=-76.252;+21.321

p19=-77.008;+25.472

p20=-76.504;+31.887

p21=-74.866;+35.660

p22=-70.709;+39.434

p23=-68.945;+42.830

p24=-69.323;+46.415

p25=-72.724;+50.566

p26=-83.307;+51.698

p27=-90.866;+50.000

p28=-97.291;+49.811

p29=-105.228;+50.755

p30=-109.008;+50.377

[C2]

gain=-6.00

n_point=19

p1=-112.535;+62.453

p2=-124.882;+60.377

p3=-129.921;+51.887

p4=-131.307;+37.358

p5=-126.520;+28.113

p6=-116.189;+22.264

p7=-110.016;+16.415

p8=-99.433;+12.642

p9=-91.244;+12.453

p10=-80.787;+14.151

p11=-75.244;+12.642

p12=-69.701;+17.547

p13=-66.173;+35.472

p14=-64.283;+43.208

p15=-67.685;+55.660

p16=-78.898;+59.623

p17=-98.299;+62.264

p18=-108.882;+63.019

p19=-112.535;+62.453

[C3]

gain=-30.00

n_point=5

p1=-140.000;+70.000

p2=-60.000;+70.000

p3=-60.000;+0.000

p4=-140.000;+0.000

p5=-140.000;+70.000

Logged Data

Data can be logged to text file, where it has the following format (the entries in square brackets are fields with values that will depend upon the simulation setup):

Log data from run: [Filename]

Number of logs: [Number of variables logged, n]

Timesteps between logs: [Timesteps between file updates]

Elapsed Time [Var-1 long name] … [Var-n long name]

Time since start [Var-1 short name] … [Var-n short name]

s [Var-1 units] … [Var-n units]

[t-0] [Var-1 at t-0] … [Var-n at t-0]

[t-1] [Var-1 at t-1] … [Var-n at t-1]

: : :

[t-m] [Var-1 at t-m] … [Var-n at t-m]

Terrain Data General Import File Format

The General file format is a flexible documented format to the standard set of terrain file formats (USGS GTOPO 30, SRTM etc). Users can translate terrain of their own format into the General file format for loading into Visualyse Interplanetary.

The first terrain data point read is the height at the bottom left of the terrain region specified. The file is binary and each spot height is 2 bytes.

By default values of -9999 will be displayed as sea on the map so as to differentiate from land with height zero. The Propagation models and Path Profile will use a height of zero in place of -9999.

The first height data point is taken to be the terrain height at the bottom left the next. All the fields are twos compliment, little-endian (Intel) integers and the file is packed binary.

Terrain data can be imported into Visualyse Interplanetary using the following file format:

Where Nlats is the number of latitude points and Nlongs is the number of longitude points.

An example of the alternative sources of data is the Shuttle Radar Topography Mission (SRTM), which can be found at:

http://edcsns17.cr.usgs.gov/srtm/index.html

Land Use Generic File Format

The clutter data is assumed to be structured as in the figure below:

There is a grid of clutter codes starting from bottom left. Each clutter code represents the environment across the whole of the pixel: therefore with a grid of n lat/long lines there are n pixel codes not n+1 (as for terrain).

The location of the bottom right of the rectangle is defined via the (LatitudeBottom, LongitudeRight) point. The other corner of the rectangle is calculated from:

LongitudeRight = LongitudeLeft + LongitudePoints * LongitudeSpacing

LatitudeTop = LatitudeBottom + LatitudePoints * LatitudeSpacing

Each clutter code is assumed to be an integer in the range [0..15] so that there are sixteen possible clutter environments.

Mapping of codes to propagation parameters

The clutter codes are mapped to propagation parameters such as height of clutter and distance to clutter in the Visualyse Interplanetary configuration dialog as shown in the figure below:

Reference Geoid

The clutter file format does not specify the reference geoid and all data used in a simulation (clutter data, terrain data and station locations) should use the same reference geoid.

File Format

Generic clutter data can be imported into Visualyse Interplanetary using the following file format.

The field “Type” should be set to 200 and the field “Version” should be 100.

Strings should be ASCII coded zero terminated and padded to a length of 20 bytes including zero.

All the fields are twos compliment, little-endian (Intel) integers and the file is packed binary.

View Overlay XML Files

It is possible to overlay images such as maps and vector data such as boundaries, roads etc on top of the Mercator, Plate Carree and 3D views. This section gives the file format for the XML file that describes the data.

The XML file and any referenced graphics files must be located in the “Visualyse Interplanetary/Overlays” directory at the time that Visualyse Interplanetary is started.

• View Overlay Images
• View Overlay Vector Line Data
• View Overlay Point Data
• View Overlay Drawing Objects

View Overlay Images

Images in formats such as JPG and BMP can be displayed on top of Visualyse Interplanetary’s views. An XML file is used to define the four corners (lat, long) in either degrees or radians, and also point to the relevant file.

The format is given below, with the fields to complete contained within square brackets and in capital letters - i.e. [MAP_NAME]

<?xml version="1.0" encoding="utf-8"?>
<image xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" name="[NAME]">
    <texture>[FILENAME]</texture>
    <bottomLeft units="[UNITS]" latitude="[LAT_BL]" longitude="[LONG_BL]" />
    <topLeft units="[UNITS]" latitude="[LAT_TL]" longitude="[LONG_TL]" />
    <topRight units="[UNITS]" latitude="[LAT_TR]" longitude="[LONG_TR]" />
    <bottomRight units="[UNITS]" latitude="[LAT_BR]" longitude="[LONG_BR]" />
    <colour>[TTRRGGBB]</colour>
</image>

The fields to enter are therefore:

NAME used to display this image on list of possible overlays

FILENAME filename may include full path or be relative to overlays directory

UNITS either “degrees” or “radians”

LAT_BL latitude in relevant units of bottom left of image

LAT_TL latitude in relevant units of top left of image

LAT_BR latitude in relevant units of bottom right of image

LAT_TR latitude in relevant units of top right of image

LONG_BL longitude in relevant units of bottom left of image

LONG_TL longitude in relevant units of top left of image

LONG_BR longitude in relevant units of bottom right of image

LONG_TR longitude in relevant units of top right of image

TTRRGGBB codes in hex for the Transparency, Red, Green & Blue to use

Note that it is necessary to define the lat/long of all four corners of the image rather than just top (top left and bottom right) as some images could be rotated. For example, maps generated in Universal Transverse Mercator (UTM) or local variants such as the UK’s National Grid do not always align with vertically with the North-South line.

An example of this format is given below:

<?xml version="1.0" encoding="utf-8"?>
<image xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="Google Maps Seattle">
    <texture>C:\Program Files\Visualyse Interplanetary\Overlays\Seattle Area.bmp</texture>
    <bottomLeft units="degrees" latitude="47.17" longitude="-125.6121825" />
    <topLeft units="degrees" latitude="49.81" longitude="-125.6121825" />
    <topRight units="degrees" latitude="49.81" longitude="-120.5035395" />
    <bottomRight units="degrees" latitude="47.17" longitude="-120.5035395" />
    <colour>ffffffff</colour>
</image>

View Overlay Vector Line Data

Vector data such as roads, railways, borders, boundaries etc can be displayed on top of Visualyse Interplanetary’s views. An XML file is used to define a set of (lat, long) points and a line colour is used to connect them.

The format is given below, with the fields to complete contained within square brackets and in capital letters - i.e. [NAME]

<?xml version="1.0" encoding="utf-8"?>
<lines xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="[NAME]" colour="[TTRRGGBB]">  
<line units="UNITS">
<coordinates>
“[LAT_1]”, “[LONG_1]”,
“[LAT_2]”, “[LONG_2]”,
“[LAT_3]”, “[LONG_3]”,
...
“[LAT_n]”, “[LONG_n]”
</coordinates>
</line>
</lines>

The fields to enter are therefore:

NAME used to display this image on list of possible overlays

TTRRGGBB codes in hex for the Transparency, Red, Green & Blue to use

UNITS either “degrees” or “radians”

LAT_i set of latitudes

LONG_i set of longitudes

Any number of (lat, long) points may be used, though there could be performance implications for very large data sets.

An example of this format is given below:

<?xml version="1.0" encoding="utf-8"?>
<lines xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="Washington BEA" colour="8000ffff">
    <line units="degrees">
        <coordinates>
        39.194801,-79.487396,
        39.205856,-79.487099,
        39.279827,-79.487877,
        39.216099,-79.507797,
        39.194801,-79.487396
        </coordinates>
    </line>
</lines>

View Overlay Point Data

Point data such as capital cities can be displayed on top of Visualyse Interplanetary’s views. An XML file is used to define a set of (lat, long) points with a label.

The format is given below, with the fields to complete contained within square brackets and in capital letters - i.e. [NAME]

<?xml version="1.0" encoding="utf-8" ?> 
- <points xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="[NAME]">
  <poi units="[UNITS]" legend="[LEG_1]" latitude="[LAT_1]" longitude="[LONG_1]" /> 
  <poi units="[UNITS]" legend="[LEG_2]" latitude="[LAT_2]" longitude="[LONG_2]" /> 
  <poi units="[UNITS]" legend="[LEG_3]" latitude="[LAT_3]" longitude="[LONG_3]" /> 
  <poi units="[UNITS]" legend="[LEG_4]" latitude="[LAT_4]" longitude="[LONG_4]" /> 
  <poi units="[UNITS]" legend="[LEG_5]" latitude="[LAT_5]" longitude="[LONG_5]" /> 
  <poi units="[UNITS]" legend="[LEG_6]" latitude="[LAT_6]" longitude="[LONG_6]" /> 
</points>

The fields to enter are therefore:

NAME used to display this image on list of possible overlays

UNITS either “degrees” or “radians”

LEG_i set of legends

LAT_i set of latitudes

LONG_i set of longitudes

Any number of (lat, long) points may be used, though there could be performance implications for very large data sets.

An example of this format is given below:

<?xml version="1.0" encoding="utf-8"?> 
<points xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="Capital Cities of the World">
  <poi units="degrees" legend="Kabul" latitude="34.467" longitude="69.1833" /> 
  <poi units="degrees" legend="Tirane" latitude="41.3" longitude="19.81666667" /> 
  <poi units="degrees" legend="Algiers" latitude="36.7" longitude="3.133333333" />
  <poi units="degrees" legend="Plymouth" latitude="16.6802" longitude="-62.2014" /> 
  <poi units="degrees" legend="Saint Johns" latitude="17.1175" longitude="-61.8455" /> 
  <poi units="degrees" legend="The Valley" latitude="18.2249" longitude="-63.0668" /> 
</points>

View Overlay Drawing Objects

Basic shapes including Rectangles, Ellipses and Grids can be displayed on top of Visualyse Interplanetary’s views. An XML file is used to define the drawing object as below:

• Rectangle
• Ellipse
• Grid

Rectangle

The format is given below, with the fields to complete contained within square brackets and in capital letters - i.e. [NAME]

<?xml version="1.0" encoding="utf-8"?>
<drawing xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="[NAME]" colour="[TTRRGGBB]">    
<rect units="[UNITS]" top="[LAT_TOP]" left="[LONG_LFT]" bottom="[LAT_BTM] right="[LONG_RGT]" /> 
</drawing>

The fields to enter are therefore:

NAME used to display this image on list of possible overlays

TTRRGGBB codes in hex for the Transparency, Red, Green & Blue to use

UNITS either “degrees” or “radians”

LAT_TOP top latitude

LONG_LFT left longitude

LAT_BTM bottom latitude

LONG_RGT right longitude

An example of this format is given below:

<?xml version="1.0" encoding="utf-8"?>
<drawing xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="Test Rectangle" colour="8000ffff">
<rect units="degrees" top="37.0" left="-9.0" bottom="23.5" right="12.0" />
</drawing>

Ellipse

The format is given below, with the fields to complete contained within square brackets and in capital letters - i.e. [NAME]

<?xml version="1.0" encoding="utf-8"?>
<drawing xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="[NAME]" colour="[TTRRGGBB]">    
<ellipse units="[UNITS]" centrelat="[CTR_LAT]" centrelong="[CTR_LNG]" radiuslat="[RAD_LAT] radiuslong="[RAD_LNG]" /> 
</drawing>

The fields to enter are therefore:

NAME used to display this image on list of possible overlays

TTRRGGBB codes in hex for the Transparency, Red, Green & Blue to use

UNITS either “degrees” or “radians”

CTR_LAT centre latitude

CTR_LNG centre longitude

RAD_LAT radius latitude

RAD_LNG radius longitude

An example of this format is given below:

<?xml version="1.0" encoding="utf-8"?>
<drawing xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="Test Ellipse" colour="8000ffff">
<ellipse units="degrees" centrelat="60.0" centrelong="20.0" radiuslat="10" radiuslong="20" />
</drawing>

Grid

The format is given below, with the fields to complete contained within square brackets and in capital letters - i.e. [NAME]

<?xml version="1.0" encoding="utf-8"?>
<drawing xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="[NAME]" colour="[TTRRGGBB]">    
<grid areaunits="[UNITS]" top="[LAT_TOP]" left="[LONG_LFT]" bottom="[LAT_BTM] right="[LONG_RGT]" horzres="[HOR_RES] vertres="[VER_RES]" /> 
</drawing>

The fields to enter are therefore:

NAME used to display this image on list of possible overlays

TTRRGGBB codes in hex for the Transparency, Red, Green & Blue to use

UNITS either “degrees” or “radians”

CTR_LAT centre latitude

CTR_LNG centre longitude

RAD_LAT radius latitude

RAD_LNG radius longitude

HOR_RES horizontal resolution (km)

VER_RES vertical resolution (km)

An example of this format is given below:

<?xml version="1.0" encoding="utf-8"?>
<drawing xmlns="http://www.transfinite.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.transfinite.com overlay.xsd" 
name="Test Grid" colour="8000ffff">
<grid areaunits="degrees" top="30.0" left="-50.0" bottom="10" right="-30" horzres="300" vertres="300" />
</drawing>

Text File Format

• Structure
• Creating Text Files
• Batch Mode

Structure

Visualyse Interplanetary has a file format that allows complete definition of simulations in a standard ASCII text file. In it are definitions of all objects and their attributes required to specify any Visualyse Interplanetary sharing scenario. The file format can also be used to define single elements – for example a station or an antenna.

The format is based upon the Microsoft Windows INI structure, using section headers and field names as follows:

[Section Header]

[Field Name] = (value)

The section header describes the object being defined based upon the Visualyse Interplanetary object tree. Each simulation starts at the root object “Simul” and then has branches for stations, antennas, links etc separated by a period or “.”¹.

So the section header for the geographic location of a station called “FS TX” would be:

[Simul.Station List.FS TX.Start LatLongHeight]

Field names are the variables associated with the object defined by the section header – so for the geographic location the variables would be latitude and longitude. The section would then start as follows:

[Simul.Station List.FS TX.Start LatLongHeight]

Name=Start LatLongHeight

Description=Start Earth latitude, longitude, height

Latitude=N38:58'31.2034"

Longitude=W77:9'39.1658"

Creating Text Files

While in theory it is possible to create text files solely using a text editor, in practice it is easier to get Visualyse Interplanetary to make a template which you can then edit. This ensures the format is the one that Visualyse Interplanetary expects, as all the variables and objects must be specified in the correct format.

These can be done by either:

• Creating a simulation file (as normal) and then using the “Save As” option and selecting the text file format;
• Opening the Model View and saving the object required as a text file.

Batch Mode

It is also possible to run Visualyse Interplanetary in batch mode from the command line. This could be useful if there are many simulations to be run or an iterative approach is required.

With this file format the command line would be something like:

C:\\Program Files (x86)\\Visualyse 7\\Program\>visualyse –x mss-fs.txt

where the -x command closes Visualyse Interplanetary on completion of the run.

This command line would save the results into the file “mss-fs.txt” which could then be read in by other programs.

Service Area Wizard

Station locations can be read into Visualyse Interplanetary using the service area wizard. This requires a text file with a set of rows similar to this:

[Lat-1], [Long-1]

[Lat-2], [Long-2]

: :

The fields should be separated by commas.

TLEs

Satellites orbit data can be read into Visualyse Interplanetary using the Two Line Element (TLE) format.

This file format is defined in the document that can be found here:

http://celestrak.com/columns/v04n03/

FS Import

The FS Import tool uses a pre-defined format in which each row defines one point to point (PtP) link. The FS Import requires the following fields to be defined and then either pasted into Visualyse Interplanetary or be available in a CSV format file:

Fields marked (*) are not required in Visualyse Interplanetary but are there to ensure backwards compatibility.

Valid polarisation codes are given in the table below:

The gain patterns should match one of the following codes or text descriptions:

Import Tx System

The Import Tx System tool uses a pre-defined format in which each row defines one Transmit station and link. The Import Tx System tool requires the following fields to be defined and then either pasted into Visualyse Interplanetary or be available in a CSV format file:

Valid polarisation codes are given in table 3 in the previous section

The gain patterns should match one of the codes or text descriptions in Table 4 in the previous section.

The Icon should be a string of the form icon-name (R,G,B) where R,G,B are values in the range 0 – 255 to indicate colour. For example: dish-medium (200,60,25)

Tower Icons

Dish Icons

Satellite Icons

Handset Icons

Vehicle Icons

Broadcasting Icons

Marker Icons

Import Rx System

The Import Rx System tool uses a pre-defined format in which each row defines one Receive station and link. The Import Rx System tool requires the following fields to be defined and then either pasted into Visualyse Interplanetary or be available in a CSV format file:

Valid polarisation codes are given in table 5 in the previous section

The gain patterns should match one of the codes or text descriptions in Table 4 in the previous section.

The Icon should be as per the previous section.

Import Non-GSO Orbit Elements

The Import Non-GSO Orbit Elements tool uses a pre-defined format in which each row defines one Non-GSO station. The Import Non-GSO Orbit Elements requires the following fields to be defined and then either pasted into Visualyse Interplanetary or be available in a CSV format file: