This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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-- >