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.
Kevin, The GRIB data is that between the GRIB.....7777 section. The NOAAPORT feed is wrapped with a WMO FOS style broadcast wrapper which is the SOH \r \r \n SEQNO \r \r \n beginning and \r \r \n ETX at the end. The CONDUIT data is GRIB data from a file which hasn't been broadcast with a WMO header. This would be the same as ftp'ing one of those files from the NWS server and decoding the products from the file. Any software which processes GRIB data should look for the GRIB sequence, and then determine the GRIB version, and product size from the message and check for the 7777 string at the appropriate location. The FOS wrappers are outside of the GRIB packet, so should be just bytes skipped over by a decoder. Steve Chiswell Unidata User Support >From: Kevin Baggett <address@hidden> >Organization: UW-SSEC >Keywords: 200511302228.jAUMS87s025208 >Hi, >We are getting GRIB data through the NOAAPORT and CONDUIT feed here at >UW-SSEC. >We have noticed that the NOAAPORT feed has a header separating its data >consisting of 8-bit integer 01 13 13 10 (start of heading/carriage >return/carriage return/line feed). >The CONDUIT feed apparently does not have this separation - is this correct? >It is causing some of our XCD software to not process the CONDUIT GRIB >files correctly. >Thanks! >Kevin Baggett > -- 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.