Enter a ZIP code to get a forecast:
Setup Location

WRN Logo
NOAAPORT Unisys Channel
Data Specifications and Content
December 2001

Data Specifications

The Unisys Channel is available to provide data in a NOAAPORT format that is not currently available on the standard NOAAPORT channels.  The content is a variety of legacy data, commercially available data and value added products. Because of the proprietary nature, the data on the channel is encypted and compressed. In order to access the data, a decryption program and key files will be provided.

Data Encryption and Compression

The encryption uses a public domain encyption API and the ZLIB deflate/gzip for compression. This requires a slightly different structure to the data content.  The NOAAPORT CCB (header) is the same.  The WMO header is developed to mimic WMO standards so data can be classified using existing WMO categories even though any WMO header could be used. The originating location will be ZUNI to denote Unisys as the source.  Every product will have an AWIPS header that describes more closely the data content.  These headers will be described in more detail below in the Data Content section.  In addition, there will always be a Unisys header following the AWIPS header. This header describes the type of data, the encryption key name and compression type (if used). Here is an example header:
DFAA91 ZUNI 040334
454FAA
UNISYS=V1.0 TYPE=FOS KEY=FOS6041A COMP=GZIP PAD=!!!!!!!
This example is for FAA 604 data. The data type is "FOS".  The encryption key name is "FOS6041A" and the data is GZIP compressed.  There will be a different key name for each type of data on the channel.  This gives Unisys the ability to control access to each data type.  So individual data types can be turned on and off at any time by changing parameters in the encryption key file (see below).  The PAD is for word alignment for encryption.

Encryption Key Files

This file contains a mapping between data key names and encryption key values.  The values are fed into the encryption API to decrypt the data.  The filename will always be "mykeybox.inf". Here is a sample key file:
CRYPTOKEY=NatMos1B CRYPTOVALUE=NONE
CRYPTOKEY=NatMos1A CRYPTOVALUE=NONE
CRYPTOKEY=RegMos1B CRYPTOVALUE=NONE
CRYPTOKEY=RegMos1A CRYPTOVALUE=NONE
CRYPTOKEY=DIFAX1B CRYPTOVALUE=NONE
CRYPTOKEY=DIFAX1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSPPS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSPPS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSDDS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSDDS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSIDS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSIDS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOS6041B CRYPTOVALUE=6CQ5S9jT8tTr9TwJC5i2Dfne
CRYPTOKEY=FOS6041A CRYPTOVALUE=wyyfekmM7rE4MQqW9YBk4osA
Each type of data (such as FOS604) on the channel will have a specific key and decryption value.  For each data type, there will be two keys: an A and a B key (FOS604A and FOS604B). At any time, one of the two is active but at a predetermined time, the key will change.  For example, if the current active key is A, the A key will be used.  This is determined by the "KEY=" tag in the Unisys header.  If the key changeover is set for 00Z, at that time, the key will be B, rather than A.  The key file contains both so that there is no interruption in data if a new key file is not received prior to the changeover.  After the changeover time, a new key file will be sent with the current B key and a new A key that will be used after the next changeover.  

The key files will be sent 3 times during the afternoon to make sure the enduser receives it.  They will be sent at roughly hour intervals between 19 and 22Z.  The key files are themselves encrypted and keys must be used to decrypyt these.  Here is a header from a key file:
NLIC99 ZUNI 022100
KUNI03
UNISYS=V1.0 TYPE=KEY KEY=UNISYS3 COMP=NONE PAD=!!!!!!!!
The end user will be provided with a key name specific to the customer and value to decrypt this file.  Once decrypted, the file will be written to "mykeybox.inf" and can be used to decrypt the other data types.

Product Manager Setup and decode Program

To decrypt and decompress the data, there are two steps.  First is to decrypt the key file and the second is to decrypt the data. Here are examples using the WXP product manager:
#
# Key files
#
NLIC99            B|  /usr/prodman/bin/decode -k /usr/prodman/unisys/lic UNISYS3 120101UNISYS3KEYTEST -
#
# FOS/FAA 604 products
#
DFAA91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/faa604/%y%m%d%h%n.faa
DDDS91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.dds
DPPS91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.pps
DIDS91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.ids
The NLIC99 line takes the products with a NLIC99 WMO header and pipes the output through the decode program and outputs the "mykeybox.inf" file.  Since there are multiple customers using the channel, each customer will be issued a key name. In this case, it is "UNISYS3".  There will be more than one NLIC99 product that comes across (one for each customer) and the decode program will use only the product that has a key equal to UNISYS3 and will ignore all others.  The "-k" option tells the decode program that this is a key file.  The additional parameters include the directory to save the key file, the key name for the customer and the key value used to decrypt the file.  The "-" parameter is for addition file output and is ignored.

Once the key file is saved to disk, it can be used to decrypt other products on the channel.  Obviously each product will have to be piped through the decode program.  The "-f" parameter to decode tells the program to file the product.  The additional parameters determine the location of the key file, the input file name ("-" is standard input) and output filename.  In these cases, the product manager constructs the output filename from the tags/wildcards.  This will vary depending on the product manager.

The process for decrypting goes as follows:
  • The data for the product type is received and is sent to the decode program.
  • The Unisys header is read and the product key name is found.
  • The product key name is searched for in the key file and the key value is obtained
  • The key value is used to decrypt the data in the product
  • If the Unisys header specifies the data is compressed, the decode program will then decompress the data
  • The output is saved to the file name listed.

LDM Setup

If the product manager is the LDM, then the procedure is very similar to the procedure listed above. The only difference is that the "decode" program must be obtained for the particular platform the LDM resides on.  This could be Linux, Solaris, Intel Solaris, etc.  Check with Unisys to see if your platform is supported. Here is a sample "pqact.conf" entry
#  Key files
WMO     ^NLIC99
        PIPE    -close /home/ldm/bin/decode -k /home/ldm/unisys/lic UNISYS3 120101UNISYS3KEYTEST -
#  FOS data
WMO     ^DFAA91 .... ([0-3][0-9])([0-2][0-9])([0-5][0-9])
        PIPE    -close /home/ldm/bin/decode -f /home/ldm/unisys/lic - /home/ldm/unisys/faa604/(\1:yy)(\1:mm)\1\2\3.faa


Data Content

This is a list of the channel contents including WMO and AWIPS header and data format:

Radar Data

WMO Header
AWIPS Header
Description
Format
SDUS91
BR2MNA
2km base reflectivity national mosaic (prod=140)
NIDS+
SDUS91
BR4MNA
4km base reflectivity national mosaic (prod=141)
NIDS+
SDUS91
BR8MNA
8km base reflectivity national mosaic (prod=142)
NIDS+
SDUS91
CR4MNA
4km composite reflectivity national mosaic (prod=27)
NIDS+
SDUS91
CR8MNA
8km composite reflectivity national mosaic (prod=28)
NIDS+
SDUS91
CP4MNA
4km composite reflectivity national mosaic, precip only (prod=103)
NIDS+
SDUS91
ET4MNA
4km echo top national mosaic (prod=95)
NIDS+
SDUS91
R14MNA
4km 1 hour precipitation national mosaic (prod=90)
NIDS+
SDUS91
RA4MNA
4km precipitation accumulation since 12Z mosaic (prod=101)
NIDS+
SDUS91
RD4MNA
4km 24 hour (daily) precipitation mosaic 12Z-12Z (prod=102)
NIDS+
SDUS91
SATMNA
Storm attribute table for all sites (prod=100)
NIDS+
SDxx911
BR2MRC
2km base reflectivity regional mosaic (prod=140)
NIDS+
SDxx911
RD2MRC
2km 24 hours (daily) regional precipitation 12Z-12Z (prod=106)
NIDS+

NOTES:
1 -  Regional mosaics.  The WMO header characters "xx" denote the region.  These are: "NE" for northeast, "SE" for southeast, "NC" for north central, "SC" for south central, "CE" for central, "NW" for northwest and "SW" for southwest.


FORMAT: The NIDS+ format is essentially the NIDS rastor format.  The source ID rather than being the site ID is a number greater than 10000 (10000 for national mosaics, 10001-10007 for the regional mosaics).  The rastor data is placed on a Lambert Conformal projection centered at 98 west and having true latitudes of 33 and 45 north.  The grid resolution is specified in the description for the product and the center of the projection is the latitude and longitude in the NIDS header.

Family Of Services/FAA Data

This is not stream data but 3 minute collectives.  The contents of the files are identical to the stream data.

WMO Header
AWIPS Header
Description
Format
DPPS91
1xxPPS 1
Public products data (3 minute file)
ASCII
DDDS91
2xxDDS 1
Domestic data (3 minute files)
ASCII
DIDS91
3xxIDS 1
International data (3 minute files)
ASCII
DFAA91
4xxFAA 1
FAA 604 data (3 minute files)
ASCII

NOTES:
1 - The number "xx" denotes the minute of the hour for the particular data ranging from 00-57 every 3 minutes.

Difax Charts

The charts are the standard set of Difax charts distinguished by chart number and saved in PNG image format.

WMO Header
AWIPS Header
Description
Format
QDFX11
xxxDFX 1
Difax charts
PNG image

NOTES:

1 - The 3 digits "xxx" denote the difax chart number ranging from 001 to 290.

Satellite Imagery

These files are in two formats.  The first is a rastor dump format.  There is an ASCII header imbedded into the first several pixels of the image that describe the image size, time and type. Here is a sample:
hs107 x1024 y1024 wr11185 hr11185 iddisk_vis b2 ssn8 sln2 esn9164 eln2291 sr1 lr5 fld1007494368 v10137 end
The image size is defined in the "x" and "y" values.  Other parameters can be used with navigation information specific to the satellite to do more precise navigation of the image.

The second format is standard GIF image format.

WMO Header
AWIPS Header
Description
Format
TIGM91
VFDGMS
Visible full disk GMS image
Rastor
TIGM91
IFDGMS
IR full disk GMS image
Rastor
TIGM91
WFDGMS
Water Vapor full disk GMS image
Rastor
TIGM91
VASGMS
Visible GMS image, eastern Asia sector
Rastor
TIGM91
IASGMS
IR GMS image, eastern Asia sector
Rastor
TIGM91
VINGMS
Visible GMS image, India sector
Rastor
TIGM91
IJKGMS
IR GMS image, Japan/Korea sector
Rastor
TIGM92
VFDGMS
Visible full disk GMS image
GIF image
TIGM92
IFDGMS
IR full disk GMS image
GIF image
TIGM92
WFDGMS
Water Vapor full disk GMS image
GIF image
TIGM92
VASGMS
Visible GMS image, eastern Asia sector
GIF image
TIGM92
IASGMS
IR GMS image, eastern Asia sector
GIF image
TIGM92
VNPGMS
Visible GMS image, north Pacific sector
GIF image
TIGM92
INPGMS
IR GMS image, north Pacific sector
GIF image
TIGM92
VINGMS
Visible GMS image, India sector
GIF image
TIGM92
IJKGMS
IR GMS image, Japan/Korea sector
GIF image
TIME91
VFDMET
Visible full disk Meteosat image
Rastor
TIME91
IFDMET
IR full disk Meteosat image
Rastor
TIME91
WFDMET
Water vapor full disk Meteosat image
Rastor
TIME91
VEUMET
Visible Meteosat image, Europe sector
Rastor
TIME91
IEUMET
IR Meteosat image, Europe sector
Rastor
TIME91
VPGMET
Visible Meteosat image, Persian Gulf sector
Rastor
TIME91
IPGMET
IR Meteosat image, Persian Gulf sector
Rastor

Encryption Key Files

WMO Header
AWIPS Header
Description
Format
NLIC99

Encryption key file
ASCII