[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Datastream #TVM-187420]: USPLN feed test and decoder info

Hi Chris,

re:
> I hope all is good on your end.  I'm looking forward to a visit to
> "fall" in a week or so.  (-:

Things are going well, thanks.

> I have two items relating to the USPLN data feed.  The first is an offer
> to feed Unidata with the data as a starting point.

Sounds good.

> The second is a question relating to the development of a decoder.
> 
> The data can be obtained from our server wxdata.db.erau.edu [155.31.114.31]
> 
> The feed request should look like:
> ldmd.conf:# USPLN 1 min lightning data
> ldmd.conf:request       EXP     "USPLN1-ltg"    wxdata.db.erau.edu

OK.

> Our pqact entry is
> # USPLN 1 minute lightning data
> EXP     ^.*\/(.+\.uspln)$
> FILE    -overwrite      -close  data/lightning/\1
> #

I just setup a feed request on yakov.unidata.ucar.edu.  I used the
following pqact.conf action to file the data:

# USPLN 1 minute lightning data
EXP     (USPLN.*uspln)$
        FILE    -overwrite      -close
        data/uspln/\1

> Data format:
> 
> Each 1 minute packet sent has an ASCII header, followed by a record for
> each lightning detection during the past 1 minute.
> 
> Header
> The ASCII header provides information on the creation time of the one
> minute packet and ending date and time of the file.
> 
> Sample Header:
> USPLN-LIGHTNING,2004-10-11T20:45:02,2004-10-11T20:45:02
> Description:
> Name of Product: USPLN-LIGHTNING
> Creation of 1 min Packet (yyyy-mm-ddThh:mm:ss): 2004-10-11T20:45:02
> Ending of 1 min Packet (yyyy-mm-ddThh:mm:ss): 2004-10-11T20:45:02
> 
> NOTE: All times in UTC
> 
> Strike Record Following the header, an individual record is provided for
> each lightning strike in a comma delimited format.
> 
> Sample Strike Records:
> 2004-10-11T20:44:02,32.6785331,-105.4344587,-96.1,1
> 2004-10-11T20:44:05,21.2628231,-86.9596634,53.1,1
> 2004-10-11T20:44:05,21.2967119,-86.9702106,50.3,1
> 2004-10-11T20:44:06,19.9044769,-100.7082608,43.1,1
> 2004-10-11T20:44:11,21.4523434,-82.5202274,-62.8,1
> 2004-10-11T20:44:11,21.8155306,-82.6708778,80.9,1
> 
> Description:
> 
> Strike Date/Time (yyyy-mm-ddThh:mm:ss): 2004-10-11T20:44:02
> 
> Strike Latitude (deg): 32.6785331
> Strike Longitude (deg): -105.4344587
> Strike Amplitude (kAmps, see note below): -96.1
> Stroke Count (number of strokes per flash): 1
> 
> Note: At the present time USPLN data are only provided in stroke format,
> so the stroke count will always be  1.
> 
> Notes about Decoding Strike Amplitude
> The amplitude field is utilized to indicate the amplitude of strokes and
> polarity of strokes for all Cloud-to- Ground Strokes.
> 
> For other types of detections this field is utilized to provide
> information on the type of stroke detected.
> 
> The amplitude number for Cloud-to-Ground strokes provides the amplitude
> of the stroke and the sign (+/-) provides the polarity of the stroke.
> 
> An amplitude of  0  indicates USPLN Cloud Flash Detections rather than
> Cloud-to-Ground detections.
> 
> Cloud flash detections include cloud-to-cloud, cloud-to-air, and
> intra-cloud flashes.
> 
> An amplitude of  -999  or  999  indicates a valid cloud-to-ground stroke
> detection in which an amplitude was not able to be determined. Typically
> these are long-range detections.
> 
> 
> =================================================================
> Contents of a whole sample file:
> data/lightning/USPLN1-ltg-2005_10_12_20_09_00.uspln
> =================================================================
> USPLN-LIGHTNING,2005-10-12T20:09:00,2005-10-12T20:09:00
> 2005-10-12T20:07:37,13.8752023,-88.2602127,63.9,1
> 2005-10-12T20:07:37,19.9283448,-72.2355437,-60.0,1
> 2005-10-12T20:07:43,14.3640739,-91.065487,63.1,1
> 2005-10-12T20:07:43,14.384812,-91.0455761,35.8,1
> 2005-10-12T20:07:44,13.6433034,-87.5136569,-81.2,1
> 2005-10-12T20:07:44,13.6512184,-87.5139921,-61.4,1
> 2005-10-12T20:07:45,15.543949,-92.6727685,-69.6,1
> 2005-10-12T20:07:45,12.8693563,-84.3675079,-41.3,1
> 2005-10-12T20:07:45,20.2312222,-75.6646041,-59.9,1
> 2005-10-12T20:07:45,15.4917439,-92.7155251,-70.8,1
> 2005-10-12T20:07:45,12.8693563,-84.3675079,-41.3,1
> 2005-10-12T20:07:45,20.2149802,-75.6863884,-55.4,1
> 2005-10-12T20:07:47,12.6726903,-85.3809302,-40.1,1
> 2005-10-12T20:07:47,12.6231612,-85.4346719,-76.9,1
> 2005-10-12T20:07:47,12.6231612,-85.4346719,-76.9,1
> 2005-10-12T20:07:47,12.6726903,-85.3809302,-40.1,1
> 2005-10-12T20:07:51,39.2553503,-73.8431729,0.0,1
> 2005-10-12T20:07:51,39.2553503,-73.8431729,0.0,1
> 2005-10-12T20:07:57,13.7678684,-88.1891308,30.2,1
> 2005-10-12T20:07:57,13.8548719,-88.2030632,-58.3,1
> 2005-10-12T20:07:57,13.7678684,-88.1891308,30.2,1
> 2005-10-12T20:07:57,13.852999,-88.203148,-40.8,1
> 2005-10-12T20:07:58,4.7910496,-73.4840528,74.8,1
> 2005-10-12T20:07:58,4.7910496,-73.4840528,74.8,1
> 2005-10-12T20:08:00,16.962226,-70.0230614,-52.3,1
> 2005-10-12T20:08:00,16.962226,-70.0230614,-52.3,1
> 2005-10-12T20:08:01,24.6922398,-103.9048725,-35.2,1
> 2005-10-12T20:08:01,24.8889562,-103.8802151,-31.5,1
> 2005-10-12T20:08:02,24.4799841,-103.9469041,18.5,1
> 2005-10-12T20:08:02,24.4799841,-103.9469041,18.5,1
> 2005-10-12T20:08:07,12.6975799,-85.0127337,-57.6,1
> 2005-10-12T20:08:07,12.801512,-85.060067,81.4,1
> 2005-10-12T20:08:07,12.6975799,-85.0127337,-57.6,1
> 2005-10-12T20:08:07,12.7113148,-85.0381058,91.2,1
> 2005-10-12T20:08:12,11.9326096,-72.3578376,-40.9,1
> 2005-10-12T20:08:12,11.9326096,-72.3578376,-40.9,1
> 2005-10-12T20:08:14,19.6151758,-87.867389,-43.3,1
> 2005-10-12T20:08:14,19.799032,-87.7683861,-53.3,1
> 2005-10-12T20:08:14,19.4643971,-87.8324759,-36.2,1
> 2005-10-12T20:08:14,19.6536455,-87.8392604,-42.7,1
> 2005-10-12T20:08:14,19.4643971,-87.8324759,-36.2,1
> 2005-10-12T20:08:14,19.4132435,-87.8278626,-41.0,1
> 2005-10-12T20:08:14,19.799032,-87.7683861,-53.3,1
> 2005-10-12T20:08:14,19.4132435,-87.8278626,-41.0,1
> 2005-10-12T20:08:17,14.5388788,-91.8154783,-73.4,1
> 2005-10-12T20:08:17,14.6274115,-91.8046745,-35.5,1
> 2005-10-12T20:08:17,14.6367676,-91.8161731,-64.9,1
> 2005-10-12T20:08:17,14.5422168,-91.8131209,-71.9,1
> 2005-10-12T20:08:22,13.8385631,-76.3506736,-106.8,1
> 2005-10-12T20:08:22,13.8385631,-76.3506736,-106.8,1
> 2005-10-12T20:08:27,22.9973058,-103.858737,-25.1,1
> 2005-10-12T20:08:27,22.9973058,-103.858737,-25.1,1
> 2005-10-12T20:08:28,13.6481682,-87.5374172,-110.6,1
> 2005-10-12T20:08:28,15.2882288,-92.7335146,-34.5,1
> 2005-10-12T20:08:28,13.6481682,-87.5374172,-110.6,1
> 2005-10-12T20:08:28,15.2882288,-92.7335146,-34.5,1
> 2005-10-12T20:08:28,15.5064306,-92.6543315,-67.4,1
> 2005-10-12T20:08:28,15.5064306,-92.6543315,-67.4,1
> 2005-10-12T20:08:33,24.5634837,-62.317054,-51.2,1
> 2005-10-12T20:08:33,24.5634837,-62.317054,-51.2,1
> 2005-10-12T20:08:33,24.5625564,-62.2852672,-74.2,1
> 2005-10-12T20:08:33,24.5625564,-62.2852672,-74.2,1
> 2005-10-12T20:08:35,19.9501222,-102.3994538,-40.6,1
> 2005-10-12T20:08:35,19.7796444,-102.4004261,21.3,1
> 2005-10-12T20:08:35,19.7796444,-102.4004261,21.3,1
> 2005-10-12T20:08:35,19.9501222,-102.3994538,-40.6,1
> 2005-10-12T20:08:35,22.6844625,-82.6075161,0.0,1
> 2005-10-12T20:08:35,22.6844625,-82.6075161,0.0,1
> 2005-10-12T20:08:36,13.0020285,-86.0277717,40.2,1
> 2005-10-12T20:08:36,13.0020285,-86.0277717,40.2,1

The data format is a lot like (but not exactly like) that for the NLDN data.
Since I will be working on the ldm-mcidas decoder package in the very
near future, this will be a good time for me to update the NLDN lightning
decoder to be able to handle the USPLN data.

> Item two is a question about the development of a decoder.
> 
> We've poked a stick at the pieces that make up the NLDN decoder and
> thought that one "easy" solution to a USPLN decoder might be to just
> write the input stream (ascii) as a binary stream in-line with the
> passing to the decoder.  It seems to me that the data are conceptually
> the same variables, just presented a little differently (perhaps).

Chiz and I already handle the ASCII NLDN data with decoders for our
packages (GEMPAK and McIDAS, respectively).

> We've got some C code that will read the input stream and parse the
> data.  We were thinking of adding a part that does a binary write to
> stdout that matches the NLDN format.  Do you think this is a reasonable
> approach?

Sure.

> Could someone offer either the format specifications for the
> NLDN data,

I will send along the NLDN format when I get working on the ldm-mcidas
decoder for lightning data.

> or the willingness to write this piece for us?  (-:

It'll cost you ;-)

> Thanks for your help!

No worries.  The data is flowing nicely to my machine:

[ldm@yakov ~]$ cd ~ldm/data/uspln/
[ldm@yakov uspln]$ ls
USPLN1-ltg-2006_09_20_00_35_00.uspln  USPLN1-ltg-2006_09_20_00_38_00.uspln
USPLN1-ltg-2006_09_20_00_36_00.uspln  USPLN1-ltg-2006_09_20_00_39_00.uspln
USPLN1-ltg-2006_09_20_00_37_00.uspln  USPLN1-ltg-2006_09_20_00_40_00.uspln

I'll probably change this to filing into hourly subdirectories.

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: TVM-187420
Department: Support Datastream
Priority: Normal
Status: Closed