[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20050207: 20050203: dcmetr problem



Bill,

Our search is hopeless in referring to old links.
Below is an example.
The format should look like

ZCZC NNNMTRCCC
SAUS80 KWBC 122100
.....
NNNN

or you could use the fos characters SOH \r \r\n
and \r \r\n ETX (but the clear text characters are probably easier.

Steve Chiswell
Unidata User Support




>From address@hidden Wed Nov 12 13:17:04 2003
>       by unidata.ucar.edu (UCAR/Unidata) with SMTP id hACKH4Ob019046;
>       Wed, 12 Nov 2003 13:17:04 -0700 (MST)
>Message-Id: <address@hidden>
>Organization: UCAR/Unidata
>To: "David Bernhardt" <address@hidden>
>cc: address@hidden
>Subject: 20031112: problem with dclsfc with synoptic bulletin 
>In-reply-to: Your message of "Wed, 12 Nov 2003 01:57:05 PST."
>Date: Wed, 12 Nov 2003 13:17:03 -0700
>From: Unidata Support <address@hidden>
>X-Spam-Status: No, hits=0.2 required=5.0
>       tests=AWL,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,
>             SPAM_PHRASE_00_01,UPPERCASE_25_50
>       version=2.43
>X-Spam-Level: 


David,

The metar decoder is built to allow both FOS style (^A^M^M\n.....^M^M\n^C) 
bulletin separators, and AFOS style (ZCZC.....NNNN) separators
as found in the $GEMPAK/source/bridge/mt/mtdcod.f routine, where
the call to DC_GBUL will determine which of the styles the bulletin is,
and call either DC_GHDR for FOS or DC_GPIL for AFOS.

The dclsfc decoder routine $GEMPAK/source/bridge/ls/lsdcod.f only has a call to
the FOS style header routine, so is not built to expect AFOS style ZCZC....NNNN 
delimeters. You could add the check on iftype returned from DC_GHDR through.

On a FOS style header, the AFOS style PIL identifier you have is not present.
Rather, you should have metar bulletins that look like either:

^A^M^M
sequence number (eg 999, etc)
WMO header (eg SAUS80 KWBC 121800 etc)
....

^M^M
^C

For an AFOS Metar,
ZCZC NNNMTRCCC
SAUS80 KWBC 122100
.....
NNNN


Since dclsfc is expecting FOS bulletins only, your bulletin should look like:
^A^M^M
999
SMCN23 CWAO 120900
AAXX 12094
71300 NIL=
71301 NIL=
71303 NIL=
71304 NIL=
....
^M^M
^C


I created a header and trailer for your bulletin with:
echo 'AMML' | tr 'AMLC' '\001\015\012\003' >! header
echo 'MMLC' | tr 'AMLC' '\001\015\012\003' >! trailer
and then edited your WAO....file placing the header and seq. number at
the top and the trailer at the end and eliminated the AFOS 9 character pil.
At that point, it will decode.

Steve Chiswell





>From: "David Bernhardt" <address@hidden>
>Organization: NOAA
>Keywords: 200311121524.hACFOPOb010204

>This is a multi-part message in MIME format.
>
>----39713cc067b879d
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: 7bit
>
>I have had persistent problems with gempak decoder dclsfc handling 
>surface synoptic observations. I am feeding my ldm with an asynchronous 
>feed from my AWIPS.
>I have attached files containing the following:
>stuff_RR1.csh is the script I run to test the writing of the input to
>              a gem file.
>WAOSSMWAO is the file as I get it through the async scheduler
>WAOSSMWAO1 is the file after I write a ^A to the beginning of the file.
>           The only reason I have tried this is because of what I had to
>           do to get the MTR/SAO files to ingest.
>x.log is the resulting log file.
>
>Any suggestions?
>
>I also have problems with my surface MTR decoder with files coming 
>through my async scheduler. I have to grap the files and prepend each 
>with a ^A and end each with a ^C before the decoder will handle them.
>
>Dave Bernhardt
>NWS Great Falls
>
>----39713cc067b879d
>Content-Type: text/plain
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment; filename="stuff_RR1.csh"
>
>IyEvYmluL2NzaA0KDQojIEEgcHJvZ3JhbSB0byBzdHVmZiBicm93bmluZyB3aW5kcyBpbnRv
>IGEgZ2VtcGFrIGZpbGUNCiMNCiNzZXQgZGF0ZQ0KY2QgL3VzcjEvbGNsX3Byb2dzL3N5bm9w
>DQoNCnNldCBnbXR5ciA9IGBkYXRlIC11ICsleWANCnNldCBnbXRtbiA9IGBkYXRlIC11ICsl
>bWANCnNldCBnbXRkeSA9IGBkYXRlIC11ICslZGANCnNldCBnbXRociA9IGBkYXRlIC11ICsl
>SGANCnNldCBocnBvc3QgPSAiMDAiDQoNCiNzZXQgZ210ZHkgPSAiMDgiDQpzZXRlbnYgREFU
>RSAkZ210eXIkZ210bW4kZ210ZHkNCnNldGVudiBUSU1FICRnbXRociRocnBvc3QNCg0KDQov
>dXNyMS9uYXdpcHMvYmluL2xpbnV4L2RjbHNmYyAtdiAxMiAtYyAke0RBVEV9LyR7VElNRX0g
>LWIgMTIgLWQgeC5sb2cgLXAgL3VzcjEvbmF3aXBzL2dlbXBhay90YWJsZXMvcGFjay9zZnN5
>bi5wYWNrIFwNCi1zIC91c3IxL25hd2lwcy9nZW1wYWsvdGFibGVzL3N0bnMvc3lzdG5zLnRi
>bCAke0RBVEV9X3guZ2VtIDwgV0FPU1NNV0FPMSANCg0KDQptb3JlIHgubG9nDQo=
>----39713cc067b879d
>Content-Type: text/plain
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment; filename="WAOSSMWAO"
>
>WkNaQyBXQU9TU01XQU8NClNNQ04yMyBDV0FPIDEyMDkwMA0KQUFYWCAxMjA5NA0KNzEzMDAg
>TklMPQ0KNzEzMDEgTklMPQ0KNzEzMDMgTklMPQ0KNzEzMDQgTklMPQ0KNzEzMDUgTklMPQ0K
>NzEzMDYgTklMPQ0KNzEzMDcgTklMPQ0KNzEzMDggTklMPQ0KNzEzMDkgTklMPQ0KNzEzMTAg
>TklMPQ0KNzEzMTEgTklMPQ0KNzEzMTIgTklMPQ0KNzEzMTMgTklMPQ0KNzEzMTQgTklMPQ0K
>NzEzMTUgTklMPQ0KNzEzMTYgTklMPQ0KNzEzMTkgTklMPQ0KNzEzMjMgTklMPQ0KNzEzMzQg
>TklMPQ0KNzEzMzUgTklMPQ0KNzEzMzYgTklMPQ0KNzEzMzcgTklMPQ0KNzEzMzggTklMPQ0K
>NzEzMzkgTklMPQ0KNzEzNDAgTklMPQ0KNzEzNDEgTklMPQ0KNzEzNDIgTklMPQ0KNzEzNDMg
>TklMPQ0KNzEzNDQgTklMPQ0KNzEzNDUgTklMPQ0KNzEzNDYgTklMPQ0KNzEzNDcgTklMPQ0K
>NzEzNDggTklMPQ0KNzEzNDkgTklMPQ0KDQpOTk5O
>----39713cc067b879d
>Content-Type: text/plain
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment; filename="WAOSSMWAO1"
>
>XkENClpDWkMgV0FPU1NNV0FPDQpTTUNOMjMgQ1dBTyAxMjA5MDANCkFBWFggMTIwOTQNCjcx
>MzAwIE5JTD0NCjcxMzAxIE5JTD0NCjcxMzAzIE5JTD0NCjcxMzA0IE5JTD0NCjcxMzA1IE5J
>TD0NCjcxMzA2IE5JTD0NCjcxMzA3IE5JTD0NCjcxMzA4IE5JTD0NCjcxMzA5IE5JTD0NCjcx
>MzEwIE5JTD0NCjcxMzExIE5JTD0NCjcxMzEyIE5JTD0NCjcxMzEzIE5JTD0NCjcxMzE0IE5J
>TD0NCjcxMzE1IE5JTD0NCjcxMzE2IE5JTD0NCjcxMzE5IE5JTD0NCjcxMzIzIE5JTD0NCjcx
>MzM0IE5JTD0NCjcxMzM1IE5JTD0NCjcxMzM2IE5JTD0NCjcxMzM3IE5JTD0NCjcxMzM4IE5J
>TD0NCjcxMzM5IE5JTD0NCjcxMzQwIE5JTD0NCjcxMzQxIE5JTD0NCjcxMzQyIE5JTD0NCjcx
>MzQzIE5JTD0NCjcxMzQ0IE5JTD0NCjcxMzQ1IE5JTD0NCjcxMzQ2IE5JTD0NCjcxMzQ3IE5J
>TD0NCjcxMzQ4IE5JTD0NCjcxMzQ5IE5JTD0NCg0KTk5OTg0K
>----39713cc067b879d
>Content-Type: application/octet-stream
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment; filename="x.log"
>
>WzExOTcyXSAwMzExMTIvMDIzNCBbREMgM10gIFN0YXJ0aW5nIHVwLiBWZXJzaW9uIDUuNi5q
>DQpbMTE5NzJdIDAzMTExMi8wMjM0IFtEQ0xTRkMgOF0gIERDTFNGQyB2ZXJzaW9uOiAgMS42
>DQpbMTE5NzJdIDAzMTExMi8wMjM0IFtEQyAyXSAgcmVhZCA0MjQvMTAyMzk5IGJ5dGVzIHN0
>cnQgMCBuZXdzdHJ0IDQyNA0KWzExOTcyXSAwMzExMTIvMDIzNCBbREMgLTEyXSAgQ2Fubm90
>IGdldCBoZWFkZXIgaW5mb3JtYXRpb24uIEVycm9yIGluIGhlYWRlciBmb3JtYXQuDQpbMTE5
>NzJdIDAzMTExMi8wMjM0IFtEQ0xTRkMgMl0gIFpDWkMgV0FPU1NNV0FPIFNNQ04yMyBDV0FP
>IDEyMDkwMCBBQVhYIDEyMDk0IDcxMzAwIE5JTD0gNzEzMDEgTklMPSA3MTMwMw0KWzExOTcy
>XSAwMzExMTIvMDIzNCBbREMgMl0gIHJlYWQgMC8xMDE5NzYgYnl0ZXMgc3RydCA0MjQgbmV3
>c3RydCA0MjQNClsxMTk3Ml0gMDMxMTEyLzAyMzQgW0RDIC05XSAgRW5kIG9mIGlucHV0IGRh
>dGEgZmlsZS4NClsxMTk3Ml0gMDMxMTEyLzAyMzQgW0RDIDVdICBOb3JtYWwgdGVybWluYXRp
>b24uDQpbMTE5NzJdIDAzMTExMi8wMjM0IFtEQyAyXSAgTnVtYmVyIG9mIGJ1bGxldGlucyBy
>ZWFkIGFuZCBwcm9jZXNzZWQ6IDENClsxMTk3Ml0gMDMxMTEyLzAyMzQgW0RDIDZdICBTaHV0
>dGluZyBkb3duLg0KWzEyMzE3XSAwMzExMTIvMDI0MiBbREMgM10gIFN0YXJ0aW5nIHVwLiBW
>ZXJzaW9uIDUuNi5qDQpbMTIzMTddIDAzMTExMi8wMjQyIFtEQ0xTRkMgOF0gIERDTFNGQyB2
>ZXJzaW9uOiAgMS42DQpbMTIzMTddIDAzMTExMi8wMjQyIFtEQyAyXSAgcmVhZCA0MjgvMTAy
>Mzk5IGJ5dGVzIHN0cnQgMCBuZXdzdHJ0IDQyOA0KWzEyMzE3XSAwMzExMTIvMDI0MiBbREMg
>LTEyXSAgQ2Fubm90IGdldCBoZWFkZXIgaW5mb3JtYXRpb24uIEVycm9yIGluIGhlYWRlciBm
>b3JtYXQuDQpbMTIzMTddIDAzMTExMi8wMjQyIFtEQ0xTRkMgMl0gIFpDWkMgV0FPU1NNV0FP
>IFNNQ04yMyBDV0FPIDEyMDkwMCBBQVhYIDEyMDk0IDcxMzAwIE5JTD0gNzEzMDEgTklMPSA3
>MTMwMw0KWzEyMzE3XSAwMzExMTIvMDI0MiBbREMgMl0gIHJlYWQgMC8xMDE5NzIgYnl0ZXMg
>c3RydCA0MjggbmV3c3RydCA0MjgNClsxMjMxN10gMDMxMTEyLzAyNDIgW0RDIC05XSAgRW5k
>IG9mIGlucHV0IGRhdGEgZmlsZS4NClsxMjMxN10gMDMxMTEyLzAyNDIgW0RDIDVdICBOb3Jt
>YWwgdGVybWluYXRpb24uDQpbMTIzMTddIDAzMTExMi8wMjQyIFtEQyAyXSAgTnVtYmVyIG9m
>IGJ1bGxldGlucyByZWFkIGFuZCBwcm9jZXNzZWQ6IDENClsxMjMxN10gMDMxMTEyLzAyNDIg
>W0RDIDZdICBTaHV0dGluZyBkb3duLg0K
>
>----39713cc067b879d--
>



>From: Bill Cottrill <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200502071509.j17F9av2012747

>Hi again Steve,
>
>The site that contains the information is helpful and I understand what
>has to be done, I think.
>The link to the page that will describe what I need to do to replace the
>control characters seems to be broken. Is there a way to see the process
>elswhere?
>
>I am sure that code could be written but if it already exists the time
>savings would be wonderful.
>
>GO NOLES!
>BC
>
>On Thu, 3 Feb 2005, Unidata Support wrote:
>
>>
>> Bill,
>>
>> Sounds like your data has been striped of the metar bulletin
>> delimeters. Without these delimeters, dcmetr won't find
>> and bulletins to process. The easiest way to add delimeters is
>> using the ZCZC and NNNN (AFOS) delimeters shown here:
>> http://my.unidata.ucar.edu/cgi-bin/getfile?file=/content/support/help/MailAr
> chives/gempak/msg02678.html
>> http://my.unidata.ucar.edu/cgi-bin/getfile?file=/content/support/help/MailAr
> chives/gempak/msg02661.html
>>
>> Steve Chiswell
>> Unidata User Support
>>
>>
>>
>>
>> >From: Bill Cottrill <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200502031745.j13HjCv2012213
>>
>> >Good day,
>> >
>> >I am attempting to run archive metar data through "dcmetr" and am having a
>> >bit of trouble.
>> >
>> >When running the program as interactive I use the following command:
>> >
>> >dcmetr -c 040404/0000 gemsurf/0404040000.gem < 2004040400.metar
>> >
>> >It runs and places an entry into the log file but output to the directory
>> >requested.
>> >
>> >The log file indicates that there was a possible error but I can not find
>> >any information on what the error is.
>> >The log file output follows:
>> >[16372] 050203/1240 [DC 3]  Starting up. Version 5.6.l.1
>> >[16372] 050203/1240 [DC -9]  End of input data file.
>> >[16372] 050203/1240 [DC 5]  Normal termination.
>> >[16372] 050203/1240 [DC 2]  Number of bulletins read and processed: 0
>> >[16372] 050203/1240 [DC 6]  Shutting down.
>> >
>> >Can anyone please let me know what I am doing wrong?
>> >
>> >Cheers,
>> >BC
>> >
>> --
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ----------------------------------------------------------------------------
>> NOTE: All email exchanges with Unidata User Support are recorded in the
>> Unidata inquiry tracking system and then made publicly available
>> through the web.  If you do not want to have your interactions made
>> available in this way, you must let us know in each email you send to us.
>>
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.