Re: 20000623: NLDN data

Hi Steve,
     Yes Bob contacted me as well.
There have been no changes to the ingest and processing
code since the y2k fixes that needed to go in.
Perhaps there were problems with that fix
(I found one already that had to be fixed
after the fact).
     If we can feed higher time resolution data
without effecting other users I'm all for it.
Stange about fields apparently getting truncated...
I can look into it a little more next week,
but since the code is mostly c and c++ 
I'm not sure how much good it will do
(I also have to look at it again since the
ingest files are not being properly scoured).
It might be the difference in the compilers used
too I suppose. Or perhaps the way the data
is fed to us has changed (I know we have had
to change satellite receivers, maybe their
were subtle changes in the data format that
were not brought to our attention).
If you want to poke around
Tom has info on passwords and software location.
David
> 
> Dave,
> 
> I've had some questions from Bob Holzworth at U. Washington regarding
> the NLDN data.
> 
> He is primarily concerned with the nanosecond field which appears to
> be rounded to the nearest 1/10s. I've also noticed that the 
> CHI2, ECC, and ANG fields appear to always be 0 now. I think
> they were non-zero at some point in history. 
> 
> Is there any information you can provide regarding the processing
> of the data for the IDD?
> 
> Thanks,
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> 
> 
> 
> ------- Forwarded Message
> 
> >To: Unidata Support <address@hidden>
> >cc: Bob Holzworth <address@hidden>
> >From: Robert Holzworth <address@hidden>
> >Subject: Re: your mail
> >Organization: UCAR/Unidata
> >Keywords: 200006222212.e5MMCUT04849
> 
> Dear Steve Chiswell,
> Thanks for the quick reply.  I have bought "stroke level
> data" from Geomet Data in the past, and so I know
> they store the data at least to the millisecond.  It
> is interesting that they dont give it that way to you.
> Sincerely,
> Bob Holzworth
> ************************************************
> Prof. Robert H. Holzworth
> Graduate Program Advisor in Geophysics
> University of Washington
> Room 202 ATG Building
> GEOPHYSICS 
> Box 351650                   
> Seattle, WA 98195-1650, USA 
> ************************************************
> address@hidden 
> http://www.geophys.washington.edu/People/Faculty/bobholz/
> ************************************************
> 206 685 7410 (office & voice mail)
> 206 685 3815 (fax)
> ************************************************
> 
> 
> On Thu, 22 Jun 2000, Unidata Support wrote:
> 
> > Date: Thu, 22 Jun 2000 15:41:04 -0600
> > From: Unidata Support <address@hidden>
> > To: Robert Holzworth <address@hidden>
> > Cc: address@hidden, address@hidden
> > 
> > 
> > Robert,
> > 
> > The nldn files on the IDD transmit a field for "nanoseconds", which
> > is used to create the milliseconds field that DCNLDN is storing.
> > Looking at the data that is being transmitted, the nanoseconds value
> > is always appearing as an even tenth of a second multiple, eg:
> > 
> > sec 961704003 nsec 300000000
> > 
> > Thus, converting the nsec value to 300 milliseconds is not losing any
> > presicion in the decoding at your end. Rather, it is already being
> > coded as a number with 1/10s resolution when the data file is
> > created by the provider.
> > 
> > We will see if the providers of our NLDN data stream can give us more
> > information on how the data is being processed to create the IDD
> > datastream products and if the data values are being truncated.
> > 
> > Steve Chiswell
> > Unidata User Support
> > 
> > 
> > 
> > 
> > 
> > 
> > >From: Robert Holzworth <address@hidden>
> > >Organization: UCAR/Unidata
> > >Keywords: 200006221835.e5MIZXT27254
> > 
> > >Re: NLDN time resolution in data to UW
> > >Dear Unidata,
> > >I am a professor at the Univ. of Washington and Harry Edmon
> > >(Atmospheric Sciences Department) suggested you may be able 
> > >to answer my question.  
> > >We get NLDN from you on a regular basis, but it seems to have time
> > >resolution only to the 1/10 of a second level (0.1s), right?
> > >
> > >How can we get millisecond resolution?  The data files you
> > >send have the time with space for the digits to the
> > >millisecond, but the 10ms and 1ms digits are always zero:
> > >time: 23.100  instead of 23.132 for an event at 132 ms after
> > >the 23rd second.
> > >
> > >I realize this will make our data set expand somewhat because
> > >multiplicity will then always be 1, I guess.  However, for
> > >experiments I am doing this month and next we will need
> > >stroke-level NLDN data.  
> > >
> > >Is it possible to increase the time resolution for us?  If
> > >this is a problem for the routine processing, would it be
> > >possible to get stroke level data after the fact for
> > >particular subsets of the data?  
> > >
> > >Thanks,
> > >Bob Holzworth
> > >************************************************
> > >Prof. Robert H. Holzworth
> > >Graduate Program Advisor in Geophysics
> > >University of Washington
> > >Room 202 ATG Building
> > >GEOPHYSICS 
> > >Box 351650                   
> > >Seattle, WA 98195-1650, USA 
> > >************************************************
> > >address@hidden 
> > >http://www.geophys.washington.edu/People/Faculty/bobholz/
> > >************************************************
> > >206 685 7410 (office & voice mail)
> > >206 685 3815 (fax)
> > >************************************************
> > >
> > 
> > ****************************************************************************
> >  <
> > 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/     
> >  <
> > ****************************************************************************
> >  <
> > 
> 
> 
> ------- End of Forwarded Message
>