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.
Hi Martha, re: > Yesterday I upgraded our system that is used to decode NOAAPORT data > to Centos 5.5. This upgrade was performed because we were seeing frame > packets dropped and LDM was failing which was presumably caused by the > older LINUX kernel we were running (we ran successfully with that kernel > for several weeks with the new NOAAPORT receiver, but all of a sudden > the LDM system started having the packet dropping problem). Since you ran with the old kernel successfully for several weeks, I would think that the problem you were seeing was due to something other than a need for an OS upgrade. For instance, perhaps the kernel tuning parameter was edited out of the configuration file? re: > After the install was complete and the kernel tuning parameter for > ip_frag_max was altered, I rebuilt LDM (version 6.9.8) and McIDAS 2009. You don't mention rebuilding the NOAAPort ingest package. It is our recommendation that the NOAAPort package be rebuilt/reinstalled after the installation or rebuild of the LDM. This is the first thing I would do before spending a lot of time on other troubleshooting: - stop the LDM - rebuild and then reinstall the NOAAPort package NB: there should be no need to download the package again. Simply do a 'make distclean' in the noaaport-1.x.x.x directory followed by running 'configure', 'make' and then 'make install'. - after the NOAAPort package has been successfully rebuilt, restart the LDM Also, you should check to make sure that the OS upgrade did not wipe out an IPTABLES configuration that explicitly allowed all traffic from the Ethernet interface that the Novra S300 is plugged into. I assume that it did not given that you say that you are once again decoding IDS|DDPLUS data into McIDAS MDXXnnnn files. Also, you should make sure that SELINUX is disabled so that your LDM logging will work correctly. re: > After restarting LDM, and after a few bumps along the way, we are now > successfully getting MDXX data, and our data from the CONDUIT are coming > in and being filed. > > However, the NEXRAD data are not being filed. The indicators on the XCD > statdisp show no problems for NEXRAD, but we are collecting nothing of > type NEXRAD. Are you using McIDAS-XCD to process NEXRAD3 data? Most sites FILE the NEXRAD3 products directly from actions in an LDM pattern-action file (e.g., pqact.conf). If you are doing this, then statdisp will not show anything related to NEXRAD Level III processing. re: > I am attaching a screen capture of the statdisp screen, > and a tar file containing the *.conf files from /usr/local/ldm/etc. 'statdisp' output would be a red herring _if_ you are filing the NEXRAD3 products from an LDM pattern-action file. re: > None of the ldm conf files were changed; these are the versions we were > running with successfully before the OS upgrade. > > I kept the file system where we are writing the NOAAPORT data intact, > and all permissions seem to be correct. OK. re: > Any advise you can offer will be much appreciated. <after looking at the pqact.conf files you sent> OK, I see that you _are_ relying on McIDAS-XCD to handle your NEXRAD3 products... Here are some additional things to check: - check to make sure that the XCD data monitor for NEXRAD products is active: <as 'mcidas'> cd $MCDATA decinfo.k LIST If DMNEXR is not active, activate it. - check to see that your LDM is receiving/seeing the NEXRAD3 products: <as 'ldm'> ldmadmin watch -f NEXRAD3 If you are seeing NEXRAD3 products being inserted into your LDM queue, there is some configuration problem on the McIDAS-XCD side. If you are not seeing NEXRAD3 products being inserted into your LDM queue, you have a problem on the NOAAPort ingest side. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: TYJ-792885 Department: Support McIDAS Priority: Normal Status: Closed