20020214: Metar formatting question?

Chris,

The decoders require that the data bulletins be identified
by defined control character sequences in order to
ensure that a complete bulletin is obtained, eg:
$GEMPAK/source/bridge/dc/dcgbul.c

When you look at a metar transmitted on the IDD, you will find that 
a bulletin has the format such as:
^A^M^M
616 ^M^M
SPCN51 CWAO 010013^M^M
SPECI CZCP 010013Z AUTO 07015KT 9SM M32/ A2981=^M^M
^M^M
^C


The characters that dcgbul.c uses to identify the start of the
product are "SOH" "\r" "\r" "\n". (Above ^A is SOH , ^M is \r).

The end of the bulletin is signified by "\r" "\r" "\n" "ETX".
(ETX ascii 003, eg ^C).

Steve CHiswell
unidata User Support


>From: "Allen Christopher L" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200202142022.g1EKMDx10457

>To anyone who may know the answer,
>
>I have been recently trying to take data from civilian piers and format them 
>to Metar data so that i can use them in Gempak with the DCHRLY or DCMETR 
>command. The problem is, is that when i try and use some of my created 
>METAR's in the DCHRLY program it doesn't read anything, yet when i do the 
>same operation on METAR reports i have downloaded from the nws, they work. 
>These METAR's that we have created are in the right format, but are missing 
>some kind of return or aski command. We have narrowed the problem down to a 
>formating issue in our METAR reports as compared to the ones recieved from 
>the nws. Is there some program that we can use here at A&M that will format 
>these so that DCHRLY will read them or have ya'll run into this problem from 
>someone else? Any info would be greatly appreciated.
>
>
>Chris Allen
>Texas A&M University
>