**DCS DCP Manufacturers' Certification Meeting**

**Day 1**

Virginia Beach, Virginia

Wednesday, March 22, 2004

**Minutes**

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

The first day of the Manufacturers' DCP certification meeting was called
to order at 9:00 a.m. by Tom Button of the NOAA/NESDIS Data Services
Division. Tom explained that the primary purpose of the meetings was to
explore proposed changes to the DCP transmitter standards for the GOES R
era, [and to bring the specifications up to current practice as well as
to increase capacity.]{.underline} This was followed by self
introductions by all who were there.

**[Introduction to the DCS Manufacturers Meeting]{.underline}**

Peter Woolner of Mitretek Systems presented slides giving an overview of
his work in developing the proposed revision to the certification
standards. He explained that the primary goal was to dramatically
increase the data collection capacity of the GOES DCS. He hoped that
there would be discussions which would lead to agreements on the
technical issues. Peter said that he would be presenting his best
guesses and that there would be a need for verification of their
reasonableness. There would be an anticipated application of the new
standards within the next 10 years with 2012 as a target. A second goal
then would be to allow manufacturers and users sufficient time to
conform to the changes. He next provided details of the DCS capacity.
This and all of Peter's presentations are included as attachments.

It was pointed out in attendee response that the DCS system efficiency
is also important as well as increased capacity. Also that loading
analysis has previously been done and that there was a need to know how
the GOES changes will affect the load capacity. There was a discussion
and question about whether the next generation (GOES N) downlink would
require a receive G/T for DRGS of 12 or 15 db EIRP. MIT/Lincoln Labs.
said they would check and report the correct value. Peter added that
GOES N had been undergoing thermal/vacuum testing with good results.

**[Proposed DCPRS Certification Changes]{.underline}**

**[Timing]{.underline}**

Peter presented his suite of certification changes that were to be
considered.

The first major topic was timing. Peter would like to change this
requirement to +/- 0.1 second for both the 300 bps and 1200 bps
services. The 1200 bps channels currently have 0.5 sec. accuracy.
Comments from the audience indicated that the UTC service will be
discontinued in the future. There was also a comment suggesting doing
away with the leap second and using some other mechanism such as going
to 2 leap seconds per year. Therefore the need exists for some kind of
continuous time availability. GPS was suggested but there would be
potential problems with its utilization to the DCS due to the
requirement for periodic GPS updates. It was also pointed out that the
GPS almanac update takes up to 12.5 minutes. It was also mentioned that
cellular systems use oven-controlled oscillators to achieve their
required accuracy. Leap seconds usually occur on January and July. All
of these facts could affect the desired 0.1 second accuracy.

Peter emphasized that he would like transmissions to be staggered by 0.1
seconds to minimize the size of step changes to the transponder load.

It was also mentioned that this requirement is for 10 years from now and
would be associated with a more advanced DAPS which would have the
features and functions necessary for the management of such a design.

More discussion followed on the problem of getting GPS fixes and the
problem of users who cannot readily get to their DCPs in order to
correct timing problems.

Peter raised the possibility of using a DCPI channel as a means of
getting the required timing data to DCPs. It was also commented that it
could be as accurate as 1 microsecond, but that it would require more
complicated technology such as receivers.

Peter added that the DCPI service (RF band) could be lost if the DCS
cannot justify keeping it. The DCPI band currently occupies about 50
kHz, for three 12.5 kHz channels. A response to the NTIA is due within a
few weeks. Also, NESDIS needs to be able to say that the existing power
flux density problems have been remedied. A suggestion was made to have
the STIWG take an action to explore the DCPI question. The DCPI has been
allocated the 460-470 MHz band partition, but the DCS is considered a
secondary user of that band segment.

**[Format]{.underline}**

Peter is proposing the elimination of the long preamble and only
allowing the short preamble on all data rate messages. It was mentioned
that the GMS and Meteosat still use the long preamble. It was also
reported that NOAA is ending the 100 bps DCS services by 2012.

**[Data Scrambling]{.underline}**

Peter reported that he had only rewritten the contents of this section
of the standards for clarity, without changing any contents.

# [Encoder Flush]{.underline}

Peter said that he has increased the number of bits from 16 to 32 to
ensure an EOT. He also is suggesting a "within" 1 msec. time limit at
the end of the last symbol be included in the standards. A comment from
the manufacturers questioned the need for two flushes and suggested that
it could be done at the transmitter and not at the receiver. A
discussion followed that indicated the need for more decoder flush bits.
There is a technical requirement for sufficient bits for proper error
correction and for the Viterbi encoder.

More discussion ensued which indicated that the additional bits would
improve the efficiency of EOT determination. It should become more
important as the system uses shorter windows, as NESDIS plans in the
future.

**[Interleaver]{.underline}**

Peter reported that he could not find good reason for keeping the
Interleaver. The downside times are too long in his estimation adding to
the system overhead. Therefore it should be eliminated. Comments from
the manufacturers indicated that it did provide burst error protection
and aided in message length determination. Remedies which were mentioned
included fixed message block length and a shorter Interleaver. The
possibility of adding the message length in the header was also
mentioned. Some manufacturers indicated a preference for the Interleaver
and would like to keep it. Peter asker for examples of conditions
(interference) that have resulted in the Interleaver being needed.

**[Prohibited Characters]{.underline}**

Peter would like to allow the transmission of any characters except the
EOT, and listed the specific changes (see the attachment). In the
discussion it was mentioned that the NWS adds them for message
separators on the ground, using ASCII characters. But this should not
prevent the implementation of the change.

**Action: Kay will check with the NWS to determine what if any impact
the change will have on them.**

**[EOT Character]{.underline}**

Peter suggested formalizing the 32^nd^ bit. There was a suggestion for
leaving out the character for a binary format. Peter also thought that
would be a good idea. Other ideas were voiced by the group such as bit
or byte stuffing similar to Meteosat which uses bit stuffing (e.g. 23
bits and then a stuff bit or else the first 24 bits (3 bytes) and then a
byte stuff). The concept of adding the message length to the header was
also mentioned. There followed a general discussion of the relationship
of change propagation from transmitter through the ground receiving and
processing systems.

**[Maximum Message Length]{.underline}**

Deleted in the standards

**[Room Temperature Frequency Adjust]{.underline}**

Deleted in the standards

**[RF Output Power]{.underline}**

Peter gave a separate presentation on this DCS topic which is included
as an attachment. A minimum of 50 dBmi and a maximum of to 53 dBmi areis
being proposed for the 1200 bps links and 47 to 50 dBmi for the 300 bps
links. He also recommended improved DCP power control, and the use of
non-omni antennas. He brought up the design goal of flexible DCP power
levels and opened the question of who would be responsible for the
control of the levels. The possibility of remote power level control was
added. Peter said that the current DCS performance is downlink limited.
An improvement could be achieved with polarization of the east and west
GOES. This would ideally allow use of all channels without guard bands,
and not have to worry about the east/west interference problem.

Peter discussed the appro he used in riving at his power
recommendations. His power analysis used a full 533 channel loading with
adjacent satellite channels being 6db down (i.e. west GOES into east
GOES). He is also assuming the need to keep the output within the 3db of
that specified for the 300 and 1200 bps DCPs.

Peter made a strong case for the use of a DCPI link to stabilize the
system. He outlined a method for using the DCPI link to remotely control
the maximum DCP platform power output. The new demodulators which NESDIS
has recently purchased allow close monitoring of DCP performance and
could thus aid in the optimal control of DCP output power levels. Peter
said that if these guidelines are followed the system will perform
adequately for all users. But it does require user cooperation or remote
power control. User point of view that was voiced is that NOAA is going
to have control the system remotely in order to have compliance.

There was a request from the group for the addition of an antenna
certification requirement. Also the need was voiced to allow transmitter
certification with variable power for different antenna types.

Peter returned to the encoder flush slide to emphasize the 1 ms
requirement, e.g. the turnoff time limit.

**[Frequency Plan]{.underline}**

Peter's plan to double the DCS capacity involves dividing the current
300 bps bandwidth in half (from 1.5 kHz to 0.75kHz) and likewise halving
the 1200 bps bandwidth (from 3.0 kHz to 1.5 kHz). A model channel
allocation plan for the increased capacity system was presented and is
included in the attachments. He emphasized the plan to NESDIS saying
that the DAPS computer will have to have the required intelligence to
select the proper channel to be assigned.

**[Frequency Stability]{.underline}**

Peter recommended a tighter frequency stability standard of +/- 30 Hz
compared to the old +/- 425 Hz. To support this requirement GPS was
recommended and also the use of the DCPI service. Graphical
presentations were supplied (included in the attachments) for both the
proposed 750 Hz 300 bps channels, and the 1.5 KHz 1200 bps channels.
Peter expressed a dislike for going to a smaller (less than 1) alpha
value due to the peak to average power ratio degradation and worse
intersymbol interference.

A comment from the manufacturers expressed concern about being dependent
on the GPS system, and also the need for a standard reference source. It
was emphasized that NESDIS is looking to manufactures for the best
solution to this reference standard dilemma.

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

It was proposed to reduce the phase noise requirement to 3.0 deg. RMS. A
comment from the manufacturers reminded NESDIS of the difference between
the loop noise bandwidth and closed loop bandwidth, and mentioned 1.5
Hz. for a closed loop bandwidth. Peter said that he would look into it
to see if there is a problem. Also Peter requested suggestions/proposals
from the manufactures for test procedures that NESIDS could use for
certification (appendix E).

**[Narrow Band Transmit Spectrum]{.underline}**

Peter suggested a change to -36 dBc for 300 bps, and to -40 dBc for the
1200 bps over 100 Hz. The resulting adjacent channel degradation is
estimated to be 0.25dB for 300 bps and 0.1 dB for 1200 bps services. He
maintained that it is the average level over the bandwidth is
predominantly important, and that the edges could be relaxed if the
average is sufficient. A comment from one of the manufacturers was that
the system as currently designed could handle a sufficient number of
DCPs compared to doubling the capacity by halving the channel bands.
NESDIS responding by saying that the current measurements do not
necessarily properly characterize future needs.

**[Fail-Safe Requirements]{.underline}**

Peter recommended a 105 second time limit for all messages, thus
limiting 300 bps service to 3,878 bytes and 1200 bps messages to 15,630
bytes. There was also a suggested additional specification for the reset
function. There was some discussion on these points and more
manufacturers, input is needed.

**[Manufacturers' Presentations]{.underline}**

**[Simulated Comparison of RRC Demod vs. DigiTrak IIR DSP
Demod]{.underline}**

Harry Betsill of Microcom Design presented the results of a study that
compared a simulation of a RRC demodulator with one using a filter
developed by Microcom for their demodulators. He first discussed the
various critical parameters in designing a high data rate system. He
explained the Sin x/x implementation and reasons for its inclusion (or
something like it) in DCS demodulator design. He then compared SXRRC
(Raised Route Cosine transmit filter with a IIR (Bessel filter) transmit
filter including graphics of the filter envelopes. Finally he reported
on a comparison of a 10dB Es/N0 "Recovered Signal" for both the RRC and
IIR demod filters. Both gave comparable performance for 10dB. Microcom
has demonstrated that 750 Hz channel bandwidth spacing worked
successfully without interference at 300 bps and 2.25 KHz channel
bandwidth for 1200 bps. This presentation is included as an attachment.

**[Observations and Recommendations]{.underline}**

Brett Betsill of Microcom Design presented comments from his experience
in developing high data rate DCS demodulators. He listed the benefits
that could be experienced from improvements in DCS channel timing and
channelization for NOAA, manufacturers, and users. He also mentioned
some disadvantages such as complexity and cost. Next were delineated
some actions that were considered necessary regardless of the future DCS
direction taken: tighter frequency tolerance, timing requirement
solutions, system management, and system verification and testing. 750
Hz channel spacing should not present an interference problem. A 2.250
KHz is currently achievable for the 1200 bps channel spacing. An SRRC
would be needed for 1.500 channel spacing for the 1200 bps
configuration, which would involve a power sacrifice of about 1.2 dB.
Microcom's measurements indicate a current system usage of 5 to 10% at
200 K messages/day. The above tested narrower channel bandwidth would
yield over 20 M messages/day. This presentation is included as an
attachment.