>All,
>
>Starting around 17:30 UTC, the level II files coming in over the NEXRAD
>feed are unreadable by gempak, wxp, whatever.
>
>The 1km composites are ok though.
>
>Did something bad and unexpected happen when they switched over
>to the new Linux servers?
>
>Yet another update to Gilbert's last status update:
>
>
>NOUS72 KNCF 131721
>ADMNCF
>PLEASE PASS TO MIC, HIC, ESA, SOO AND ITO:
>IN ORDER TO ALLEVIATE LATENCY IN SENDING TO THE AWIPS SBN, THE NCF
>INTENDS TO MOVE UPLINK OF THE GATEWAY (NWSTG) CHANNEL TO A NEWLY
>INSTALLED LINUX UPLINK. THIS WILL OCCUR AT APPROXIMATELY 18Z.
>
>NCF/KJ
>
>
>Pete
>
>--
>+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
>^ Pete Pokrandt V 1447 AOSS Bldg 1225 W Dayton St^
>^ Systems Programmer V Madison, WI 53706 ^
>^ V poker@xxxxxxxxxxxxxxx ^
>^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
>^ University of Wisconsin-Madison V 262-0166 (Fax) ^
>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
I'm receiving corrupted NEXRAD Level II files.
I have my own indexing software which works on NEXRAD data files, whether they
are LDM, tape, or live/RIDDS. Up until today, it has always worked fine.
Today, it core dumps on some 88D files.
Due to a design flaw in BZIP2 format, there is no way of knowing the length
of data when it is uncompressed without uncompressing it. As a result, the
format for LDM has segments that have an encoded length in it followed by
data. This pattern repeats until the end of the file. This normally up to a
5 digit number. Today, I'm seeing 10 digit lengths at the corruption point.
Something is making a mess of the data.
Kevin W. Thomas
Center for Analysis and Prediction of Storms
University of Oklahoma
Norman, Oklahoma
Email: kwthomas@xxxxxx