**DCS DCP Manufacturers' Meeting**

Baltimore, Maryland

Thursday, November 10, 2005

**Minutes**

**[Call to Order and Welcome]{.underline}**

The Baltimore Manufacturers' DCS DCP meeting was called to order at 9:00
a.m. by Kay Metcalf, DCS manager from the NOAA/NESDIS Data Services
Division. There were 33 participants that included DCP manufactures and
DCS users. Kay added two topics to the day's agenda: (1) The Emergency
Data Distribution Network and (2) Channel Interference. There was also a
suggestion from a DCS user to add a discussion of data logger protocol.
Kay suggested that the data logger discussion first begin with a user
group rather than open it up to the manufactures prior to arriving at
standards. Kay suggested that ideas for a data logger protocol be sent
to Larry Cedrone who is heading a DCS standards group.

**[Emergency Data Distribution Network (EDDN)]{.underline}**

Ernest Dreyer of the USGS presented a Power Point overview of the EDDN
that the STIWG has been developing. The STIWG has promoted the concept
of a DCS data backup system based on a distributed network of DRGS
systems. Ernest said that the USGS especially liked this approach.
Consequently, the USGS and NESDIS have agreed to develop an emergency
backup system that would handle all channels. A proposal that details
the concept was generated by the USGS and NESDIS. Major points that were
stressed in the presentation included that the backup system will be
independent of the Wallops CDA. This is in contrast to the backup study
that required Wallops personnel to man such a system when the system was
activated. There will be limits on the original backup system. The
initial system might be called a barebones system that would fill in for
a Wallops CDA failure. However, the system could be upgraded as needed.
There was a question about error correction ability and the response was
that the function is to be included in the manufactures' DCP design and
not by the initial backup system. The system concept would also utilize
the DAMS NT protocol.

**[DAMS NT and the Interface Control Document]{.underline}**

The mention of DAMS NT resulted in a general discussion on the topic at
this time. Ilex Engineering has expanded the DAMS NT Network Interface
Specification to Version 8. Among the changes was increased time
resolution, while maintaining backward compatibility with version 7. It
was stated the intent of the changes was to allow vendors to be able to
insert data without a separate socket. The 3rd section of the
specifications covers the message interface. NESDIS pointed out that the
prohibited character problem needs to be addressed. Ilex Engineering
also said that they were trying to add the flexibility to allow binary
data in the future. The point was made that the specification needs to
be released from the DAMS NT history and allow expansion and
modification for things like binary data.

The importance of backward compatibility was stressed so that previous
implementations would function normally. Section 3.3 was added for
vendor-specific data that would allow certain statistics to be included.
But it was decided that manufacturer specific issues should not be
included in the standards. It was said that a fixed message header is a
limitation. A vendor voiced that they would like a more dynamic
protocol. However, there was an objection added that this would prohibit
the desired backward compatibility. A suggestion was made for a header
design that would allow a variable list of properties. A conclusion was
reached that much more thought needs to be given to the socket
specification modification. NESDIS added that they had some ideas for
streamlining the format to promote efficiency and adding some fields to
allow growth. The point was made that there was question as to who owns
the standard and who is going to manage it and that it is a good idea to
build in flexibility. It was said that the user community in this case
owns the standard. Buffer is the general data standard for the DCS at
this time. Another suggestion was made that the DCS community should
think into the future, say 20 years from now, and to work toward a
flexible standard. The question of changing to a more flexible header
brought responses from vendors that implementation of changes would
require a time consuming effort. A comment was made that the Interface
Control Document (ICD) was not really a standard but rather an "orphan"
standard and that NESDIS does not own the standard. A weakness of the
current standard is that the time standard is rounded to a second with
only a message start time and no end time. It was explained that Version
8 takes care of start and end time and also defines them more exactly
than before. NESDIS said there was a need to update the ICD table. It
was emphasized that the backup site needs to use a format that is
compatible with other sites.

**Action: Warren Dorsey of NESDIS is to write up his suggestions and
submit them to Ernest Dreyer.**

Ernest Dreyer recommended adopting version 8 of the ICD, but to first
have the vendors review it and submit comments to him. Some additional
comments from vendors included a recommendation for a source field in
the data header; use of four characters for the data rate (not an issue
of major concern); and the need for an auto baud (auto detect field).
Ernest Dreyer asked for input on the acceptability of the **Data
Acquisition Socket** from the vendors.

Ernest would like a well defined description of the events for the
**Event Processing Socket.** One of the vendors asked how the events
will be handled by the user, and it was responded that it depends on
what the event was. It was decided that a list of events was needed from
the vendors for Ernest to review. Ernest Dreyer will then see that they
are integrated into the standards.

It was felt that the EDDN system configuration could be a dangerous area
and a recommendation was to have only one person with that
responsibility. There was also an opinion that control console
configuration would be acceptable for the backup system and that one of
the vendors actually has this implemented.

There was a suggestion that Ernest post the comments on his web site as
soon as they are available. However, Ernest would like to stress data
acquisition and processing as primary interest areas for now. He also
wants the manufacturers to think about Operating System upgrades and the
best and most secure way to do them. He finished the EDDN presentation
by showing a flow chart diagram. The current plans call for the first
EDDN acquisition to be initiated sometime in January or February 2006.

**Action: Vendors are to supply comments to Ernest Dreyer as soon as
possible at**

<sedreyer@usgs.gov>.

**[DCS DCP Filter Study]{.underline}**

Bob Peters of Stellar Solutions presented a status report on the study
that is to determine which of the two filter designs, the Route Raised
Cosine Filter (RRCF) or a Bessel function design would best promote the
roughly halving of the DCS data bandwidths. He started by saying that
either one would actually do the job. The choice of the amplifier is
very important, especially the AM/PM (amplitude modulation/phase
modulation amplifier. Either filter will handle the doubling of capacity
or even (theoretically) tripling it. He reported that these results
differ from other studies due to the choice of parameters. Stellar
reported that they used uncoded data rather than use Viterbi code for
the simulations. There are multiple ways to implement a Bessel filter,
but generally the simulations required twice the calculations for the
Bessel compared to the RRCF. They decided that the initial amplifier
characteristics were unreasonably linear so some nonlinear amplifier
functions were introduced. Amplifiers with increasingly non-linear cubic
polynomials were used for the simulations. They also found that the RRCF
tends to compensate for noise that may be inherent with the transmit
filter. It was found that when the nonlinear amplifier is used in the
model, the Bessel filter behaves better in side lobe generation. It was
also stated that there was no clear advantage in using Viterbi coded
data.

Conclusion: There was about ½ dB differences in performance between the
RRCF and the Bessel with the RRCF doing better for linear amplification
and the Bessel doing better for non-linear amplification. The difference
is within the estimated accuracy of the model simulations. Either choice
will handle the doubling of 300 bps DCS service.

One of the manufacturers stated that the operation of the AGC needs to
be considered along with other downstream effects. Bob Peters replied
that it should not affect one type of filter more than the other.

The Stellar Solutions presentation is included with these minutes.

**[NTIA Transmit Standards]{.underline}**

Peter Woolner of Mitretek reported on his task that was assigned at the
Seattle meetings to talk to the NTIA about the DCS RF band and
specifically paragraph. 5.2.2.2. Peter said the NTIA is checking on
frequency use now more than in the past. It was determined that the
existing standards used by NESDIS do not meet the NTIA requirements, so
Peter introduced modifications to the Certification Standards Text that
would bring the DCS into compliance with the specifications. They are
summarized on page 9 of the attached presentation. It was noted that
Peter is recommending the RRCF over the Bessel filter. He recommended
that the DCS restrict the capacity increase to 2x (or 750 Hz bandwidth)
for the 300 bps with an a=1 compared to a=.22 and 2250 Hz bandwidth for
the 1200 bps channels. In summary there would be two channels for every
one of the current 300 bps channels; and three channels for every two of
the current 1200 bps channels.

There was a question regarding re-engineering effort needed to go to
RRCF, and Peter said that there would be re-engineering needed anyway
due to the NTIA changes in the Certification Standards. If there is
agreement, Peter will do a draft of new standards and make it available
for review.

**[Channel Organization]{.underline}**

Peter presented his recommendations for DCS channel reorganization. He
presented two plans with the first plan being the recommended one.
Channel 1 would be the same and proceeding up from there every 750 Hz
for the 300 bps channels due to the rather simple two for one
arrangement. The1200bps channels would be more complex but would allow
for most frequencies to be the same as the existing channels (see
attached presentation). Kay Metcalf explained however that the second
channel configuration would allow her to do a channel by channel
transition. Peter showed however that plan two would not really allow
this due to possible interference by the old style (heritage) demods.
Warren Dorsey wondered it the channel plan could be included in the DAMS
NT ICD. That idea received a positive response from the attending
vendors. Kay reminded all of the limitations of the current operational
DAPS. Peter recommended that we first decide on the best numbering
scheme and proceed from there regardless of technical limitations. The
draft Certification Standards that Peter Woolner will generate will
include the channel numbering scheme. The Channel Organization
presentation is included with these minutes.

**Action: Peter Woolner to generate a draft Certification Standards
Document.**

**[Modulation and Phase Noise]{.underline}**

Peter referenced a nominal error rate of 1 in 10 to the 9^th^ power
based on a Gaussian distribution. So he intends to include the 10\*\*9
in the new standards with 2.5 deg. RMS, and 1 deg offset. He then asked
the vendors to take a couple weeks to think about these values and get
back to him. A further discussion ensued about the offset definition and
how it will be defined in the new standards. There was agreement to
include a suitable reference in the new standards.

**Action: Vendors to send comments on the noise values to Pete Woolner
at**
[[pwoolner@mitretek.org]{.underline}](http://webmail.atl.earthlink.net/wam/AddrSendmail?addrid=47122143&x=-1857877913)

**[DCPI]{.underline}**

The DCPI service will not be on future satellites in its current state.
Peter has modified the DCPI description to allow us to keep it on the
satellite. It is the downlink portion that is vulnerable. Warren Dorsey
observed that the DCPI band is a public use band that is subject to
interference. The possibility of using CDMA for the 50 KHz DCPI band was
discussed. It is considered possible to use a slow data rate CDMA
technology even though the band is narrow. It was pointed out that the
STIWG is working on an initiative for system development and has a
teleconference scheduled for the upcoming week to discuss DCPI
requirements. Peter asked to be included in the call. Ernest Dreyer will
be arranging the teleconference. Peter emphasized the flexibility of
choosing a modulation technique for the new DCPI requirements. A general
discussion followed regarding CDMA technology and the upcoming limited
use a CDMA application on the DCS band by another government agency.

The possibility of two pilot tones was brought up. It was said that the
Wallops CDA now can generate two pilot tones at various locations.
However, the power level to the satellite is not very well known and it
is a difficult measurement to make. The Sioux Falls EDDN plans to have a
pilot of its own. General details of how a pilot could be installed and
maintained were discussed further.

Kay ended the meeting which received very positive comments from the
attendees.