
Release 1
DAMS-NT DigiRIT Operation Manual
12/14/2012
Microcom Design, Inc.
13
Times are included, Bit 4 of the ErrorFlags field in the DAMS-NT Header will be set (see
Section 1.3.2.1).
As with many of fields in the DAMS-NT DCP Message Interface, the DigiRIT Receiver cannot
determine the Carrier Times, they must be present in the LRIT stream to be reported. Currently,
the LRIT stream appears to include this information on all messages except “informational”
messages. Informational messages are pseudo DCS messages created by the NOAA receive
system(s) that are sent out to notify the owner of a platform that some anomaly was detected, e.g.
a “missing message” or a message “outside of its assigned time window”; since these are system
generated messages, Carrier Times are not applicable.
The important point here is that the DigiRIT will report the Carrier Times if there are present in
the LRIT DCS message stream, and can not if they are not present. In either case, the Carrier
Times bit in the ErrorFlags field in the Header will be set accordingly.
1.3.3.
LRIT TCP/IP Interface
While the primary intention of the Microcom DigiRIT Receiver is to extract DCS messages from
the LRIT stream and re-format them per the “DAMS-NT Network Interface Specification” (see
Section 1.3.2), the DigiRIT Receiver also provides a separate LRIT TCP/IP interface to allow
access to the full LRIT data stream. Primarily intended for custom developers, this interface is
provided via a separate network connector with a different IP address.
With a few notable exceptions, this interface is essentially the raw LRIT transmission. Figure 5
shows a block diagram of the LRIT TCP/IP interface processing. The most obvious exception is
that the network interface is byte-wise oriented while the raw LRIT signal transmits data in a bit-
wise fashion.
BPSK
Demod
~293 kbits/sec
Viterbi
Decoder
Rate ½
~146.5 kbits/sec
1ACFFC1D
VCDU Primary
Header
+
+
+
+
Descrambler
Scrambled Data
VCDU Data Zone
Reed Solomon
Check Symbols
32 bits
8160 bits
1ACFFC1D
4 bytes
6 bytes
886 bytes
128 bytes
VCDU
LRIT TCP/IP
Interface
16 kbytes/sec
Figure 5: DigiRIT LRIT TCP/IP Processing
The BPSK signal is first demodulated into a bit-wise data stream at approximately 293 kilobits
per second. The DigiRIT first applies a Rate ½ Viterbi Forward Error Correction Decoder to the
incoming stream, which results in a reduced bit stream of about 146.5 kilobits per second. The
LRIT data is framed into 8192 bits or 1024 bytes. Each frame begins with a specific 32-bit or 4-
byte pattern as shown in Figure 5.
Once the DigiRIT identified two frame synchronization patterns spaced 8160 bits apart, it
declares it has frame sync and begins processing data. After the 4-byte frame sequence is 8160
bits or 1020 bytes of “scrambled” data. The DigiRIT applies the LRIT defined descrambler to
the data to produce what is called the Virtual Channel Data Unit or VCDU. Each VCDU
consists of a 6-byte header, an 886-byte data zone, and 128 bytes of Reed Solomon encoded
check symbols.