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

19990921: NOAAPORT SBN question on the NWSTG format

Greg,

I think you'll find that not all nwstg products end with
the \r\r\n\ETX sequence. I can think of the
SDUS97 products off the top of my head right now for example.
You might want to check for that and add that trailer as necessary.

I use the product defnition header sequence number for the FOS-like
sequence number- not from the CCB. My comment was that I compute
the length of the CCB from the first 2 words of the CCB
rather than assuming it will be 20 bytes.

Steve Chiswell
Unidata User Support




>From: Gregory Grosshans <address@hidden>
>Organization: .
>Keywords: 199909221551.JAA02044

>This is a multi-part message in MIME format.
>--------------72D9632A38E59B672B4801E1
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Steve,
>
>Your correct about the prod.info.sz.  Now that I've updated it the products ar
> e
>correct.
>I left out the part about performing the MD5 checksum in my previous message.
>
>What field in the CCB are you using to compute the sequence number with the sb
> n
>modulo 1000?
>
>I'm presently only adding the SOH...FOS stuff to everything on the NWSTG
>data stream.  I'm leaving the GOES-EAST/WEST channels as is right now.
>
>Thanks for the information.
>
>Gregg Grosshans
>
>Unidata Support wrote:
>
>> Greg,
>>
>> It sounds like your prod.info.sz in the prod structure hasn't
>> been updated to reflect that you have memmoved the product
>> up into your allocated block. This is the size of the number of
>> bytes that you are inserting into the queue- and since you
>> get 20 extra bytes, it seems to coincide with the size
>> that you moved. Once you move the bytes, your
>> product size is 20 less.
>>
>> When I read the noaaport stream here, I actually calculate the ccb length
>> from the data stream (just in case someday they decide to change its size),
>> and I load into the product heap the product at the appropriate offset
>> so I don't have to move things later. I also compute the running
>> MD5 checksum as each fragment is obtained and placed into the
>> product data pointer (not a big deal with nwstg, but it would
>> take considerable time to compute the MD5 for a 26MB visible
>> image if not doing it as the fragments arrive).
>>
>> It sounds like you aren't computing the checksum which is used
>> for duplicate detection. Not a big deal.
>>
>> If you are trying to make your products look "FOS" like with
>> the SOH \r\r\n for use with other decoders, I'll mention that
>> the Gempak source/bridge/dc/dcghdr.f routine is looking for
>> the FOS sequence number following the SOH sequence that you are
>> already adding. The realtime IDD feed that we send out from
>> the NOAAport creates this sequence number from the sbn modulo 1000
>> for a 3 digit number followed by \r\r\n. We did this to make things
>> backwards compatible with the FOS stream so decoders wouldn't break.
>>
>> Note that the Gempak gini reader imgi2gm.f for the imagery
>> products does not expect the SOH.... FOS stuff in the product
>> so no need to do that for the imager (GOES-E, GOES-W and gms/goes/meteo
>> composites). Also, our grib readers (dcgrib and gribtonc etc don't care
>> if the SOH is there or not).
>>
>> Steve Chiswell
>> Unidata User Support
>>
>>
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>
>--------------72D9632A38E59B672B4801E1
>Content-Type: text/x-vcard; charset=us-ascii;
> name="grosshans.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for Gregory Grosshans
>Content-Disposition: attachment;
> filename="grosshans.vcf"
>
>begin:vcard 
>n:Grosshans;Gregory
>tel;fax:405-579-0700
>tel;work:405-579-0720
>x-mozilla-html:TRUE
>url:www.spc.noaa.gov
>org:DOC/NOAA/NWS/NCEP/Storm Prediction Center
>adr:;;1313 Halley Circle                               ;Norman;OK;73069;
>version:2.1
>email;internet:address@hidden
>x-mozilla-cpt:;0
>fn:Gregory Grosshans
>end:vcard
>
>--------------72D9632A38E59B672B4801E1--
>