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.
Josh, Run "pqing -f HDS ....etc...." That will retype all products with SDUS[2357] to feedtype NNEXRAD and add the PIL (eg N0Rccc, etc) to the WMO identifier so that the LDM identifier will look like: SDUS[2357]. CCCC DDHHNN /pNxxxxx The pil identifiers are only created when the feedtype on the command line is a subset of the WMO feedtype (eg DDS, PPS, IDS, HDS, DDPLUS, etc). The NIDS products are rettyped to feedtype NNEXRAD automatically. Steve Chiswell On Wed, 2004-03-24 at 13:15, Josh Sholes wrote: > Steve, > I am my own source for the data. *grin* The data ingestor machine is reading > data from the NOAAPort satellite stream using the pqing utility on a named > pipe, then sending it via LDM to the (much beefier, processor-wise) decoder > machine. Can you give me any information on how to configure pqing/LDM on > the ingestor to add the /pPILs? > > Thanks for the help so far. > > --Josh > > On Wednesday 24 March 2004 14:55, you wrote: > > Josh, > > > > The Unidata NEXRAD data stream has LDM product identifiers with the > > /pPILs following the WMO identifier. This is done by the IDD ingestion > > software to identify the different NEXRAD products that use the same WMO id > > to transmit different products. > > > > Your source for the data is apparently not providing a product identifier > > that adds the PIL, so the examples you find showing its use will not > > be valid for your application. You either need to have that done at the > > ingestion point, or pipe your products to a program which can access the > > PIL line of the Level III radar product for file name identification. > > > > Steve Chiswell > > Unidata User SUpport > > > > On Wed, 24 Mar 2004, Josh Sholes wrote: > > > Recently, my site was attempting to configure LDM to get data for the > > > GEMPAK decoder package. > > > We added the lines from the examples, specifically: > > > > > > ANY ^SDUS[2357]. .... > > > ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...) > > > FILE -close data/gempak/nexrad/NIDS/\5/\4/\4_(\1:yyyy)(\1:mm)\1_\2\3 > > > > > > to the pqact.conf file, and got no data at all in the appropriate > > > directories. Amending the lines to > > > > > > ANY ^SDUS[2357]. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9]) > > > FILE -close data/gempak/nexrad/NIDS/(\1:yyyy)(\1:mm)\1_\2\3 > > > > > > got lots of radar data, but not seperated in the way GEMPAK expects. > > > Since then, we have noticed that none of our pqact.conf lines which > > > include the "/p" construction (which, if I'm not mistaken, is supposed to > > > tell pqact to jump down and start reading the second line of the header) > > > seem to work at all. Is this a known problem, a change in syntax from > > > when the examples were written, or what? > > > > > > Thanks for any help you can give. > > > > > > -- > > > Josh Sholes > > > ZedX Inc. > > > address@hidden