Code Monkey home page Code Monkey logo

goesdump's Introduction

GOES xRIT Dumper

This program receives a TCP Stream from decoder and decodes the channel in realtime generating .lrit files. It also depends on satdecompress to decompress LritRice (see Decompressor project).

With all LRIT files, you can use xrit2pic.

GOES Dump

goesdump's People

Contributors

hdoverobinson avatar n2cr avatar racerxdl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

goesdump's Issues

lost frame counter issues with no other errors

https://www.dropbox.com/s/2q0r2f2swlx247c/demuxdump-1492400420%20-%20Copy.bin?dl=0

7:16:13 AM/INFO  I don't have a demuxer for VCID 56. Creating...
7:16:31 AM/INFO  New HIMAWARI8 ABI - Channel 3 (IMG_DK01IR1_201704171350_007.lrit)
7:17:07 AM/ERROR Lost -12247583 frames. Last Frame #12247582 - Current Frame #0 on VCID 0
7:17:08 AM/ERROR Lost -9342745 frames. Last Frame #9342744 - Current Frame #0 on VCID 1
7:17:08 AM/ERROR Lost some frames on MSDU, the file will be corrupted. CRC Match: False - Size Match: False
7:17:17 AM/ERROR Lost -883619 frames. Last Frame #883618 - Current Frame #0 on VCID 61
7:17:30 AM/INFO  New HIMAWARI8 ABI - Channel 7 (IMG_DK01IR3_201704171350_002.lrit)
7:18:01 AM/ERROR Lost -1454799 frames. Last Frame #1454798 - Current Frame #0 on VCID 13
7:18:09 AM/ERROR Lost -16171254 frames. Last Frame #16171253 - Current Frame #0 on VCID 23
7:18:17 AM/ERROR Lost -9842067 frames. Last Frame #9842066 - Current Frame #0 on VCID 33
7:18:23 AM/INFO  New GOES 15 ABI - Infrared United States (gos15chnIR04rgnUSseg001res04dat107141753521.lrit)
7:18:24 AM/INFO  New GOES 15 ABI - Visible United States (gos15chnVS01rgnUSseg001res04dat107141753334.lrit)
7:18:25 AM/ERROR Lost -1057254 frames. Last Frame #1057253 - Current Frame #0 on VCID 60
7:18:32 AM/INFO  New GOES 15 ABI - Water Vapour United States (gos15chnWV03rgnUSseg001res04dat107141753540.lrit)
7:18:38 AM/INFO  New HIMAWARI8 ABI - Channel 7 (IMG_DK01IR3_201704171350_003.lrit)
7:19:43 AM/INFO  New GOES 15 ABI - Infrared United States (gos15chnIR04rgnUSseg002res04dat107141908643.lrit)
7:19:47 AM/INFO  New GOES 15 ABI - Visible United States (gos15chnVS01rgnUSseg002res04dat107141908419.lrit)
7:19:53 AM/INFO  New GOES 15 ABI - Water Vapour United States (gos15chnWV03rgnUSseg002res04dat107141908662.lrit)
7:19:53 AM/ERROR Lost -13815201 frames. Last Frame #13815200 - Current Frame #0 on VCID 41
7:20:20 AM/INFO  New GOES 13 ABI - Infrared Northern Hemisphere (gos13chnIR04rgnNHseg001res04dat107141919028.lrit)
7:20:20 AM/ERROR Lost -1195249 frames. Last Frame #1195248 - Current Frame #0 on VCID 59
7:20:34 AM/INFO  New HIMAWARI8 ABI - Channel 7 (IMG_DK01IR3_201704171350_004.lrit)
7:20:34 AM/ERROR Lost -1420740 frames. Last Frame #1420739 - Current Frame #0 on VCID 58
7:21:16 AM/INFO  New GOES 15 ABI - Infrared United States (gos15chnIR04rgnUSseg003res04dat107142028754.lrit)
7:21:21 AM/INFO  New GOES 15 ABI - Visible United States (gos15chnVS01rgnUSseg003res04dat107142028514.lrit)

Missing image generation for GOES-R ABI channels 14, 15

Goesdump stops generating images for channel 15 soon after starting. It generates images for channel 14 for a time but this channel sometimes begins to lag behind too. Occasional restarts of goesdump force the images to generate.

Reduce console logging width of messages on HRIT

The current text output on HRIT for many products is way too wide. Incoming file name along with output file name but with full path easily fills and wraps. Perhaps look at LRIT console logging and make HRIT logging like that. Or add a knob to allow user to turn down width verbosity.

Erase files after FLSCLR generation on windows broken

https://www.dropbox.com/s/0elpei8dtbiutro/demuxdump-1492397472.bin?dl=0

https://www.dropbox.com/s/771ko1szews8d0m/xrit_errors.log?dl=0

20:46:09 ERROR   Error processing image (SysExcpt) 1492486837-GOES 15-Special interest or unspecified: System.IO.FileNotFoundException: Could not find file 'F:\sw\goes_xrit_viewer\goes_xrit_viewer\bin\Debug\channels\Images\Area of Interest\gos15chnWV03rgnXXseg001res04dat107034209587.lrit'.
File name: 'F:\sw\goes_xrit_viewer\goes_xrit_viewer\bin\Debug\channels\Images\Area of Interest\gos15chnWV03rgnXXseg001res04dat107034209587.lrit'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at System.IO.File.OpenRead(String path)
   at OpenSatelliteProject.Tools.FileParser.GetHeaderFromFile(String filename) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\XRIT\Tools\FileParser.cs:line 13
   at OpenSatelliteProject.ImageTools.GenerateFullImage(OrganizerData data, Boolean crop) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\XRIT\Tools\ImageTools.cs:line 105
   at OpenSatelliteProject.ImageManager.ThreadLoop() in F:\sw\goes_xrit_viewer\goes_xrit_viewer\GoesDecoder\ImageManager.cs:line 180

20:46:09 DEBUG   Starting Generation of Water Vapour for GOES 15-Special interest or unspecified-WV-1492486837.png.

20:46:09 ERROR   Error processing image (SysExcpt) 1492486837-GOES 15-Special interest or unspecified: System.IO.FileNotFoundException: Could not find file 'F:\sw\goes_xrit_viewer\goes_xrit_viewer\bin\Debug\channels\Images\Area of Interest\gos15chnWV03rgnXXseg001res04dat107034209587.lrit'.
File name: 'F:\sw\goes_xrit_viewer\goes_xrit_viewer\bin\Debug\channels\Images\Area of Interest\gos15chnWV03rgnXXseg001res04dat107034209587.lrit'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at System.IO.File.OpenRead(String path)
   at OpenSatelliteProject.Tools.FileParser.GetHeaderFromFile(String filename) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\XRIT\Tools\FileParser.cs:line 13
   at OpenSatelliteProject.ImageTools.GenerateFullImage(OrganizerData data, Boolean crop) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\XRIT\Tools\ImageTools.cs:

Weather data processing not precise

When disabling weather data file generation the ingester is not precise. Charts, text etc. are still generated. Many users don't care about this low res stuff and the files add up quickly and are a pain to manually delete. Please add the appropriate product/sub-product ids to make weather data disablement more accurate.

Purge files over x days in Channels directory

"Can there be an option to remove any files in the channels directory over 7 (or 14, etc) days old? Images, lrit, etc. Anything older than X days. Basically to keep the directory size from growing massively large"

Add counter for decompression failures

In the case of EMWIN on HRIT, there are errors (perhaps on uplink) that results in bad decompression. These are not currently recorded. Add a counter so it obvious to the user that over time there is a problem with decompression. I suppose you could also have one for RICE decompression failures too.

Informative Labels

Now we will have Informative Label support with XRIT 1.2. The "OpenSatelliteProject blalba" in the bottom is customizable for anything.

image
image
image
image

DemuxManager RecordToFile not thread safe

Setting RecordToFile to True, False, True periodically while running will result in following:

21:05:49 ERROR Error writting demuxdump file: System.ObjectDisposedException: Cannot access a closed file.
at System.IO.__Error.FileNotOpen()
at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
at OpenSatelliteProject.DemuxManager.parseBytes(Byte[] data) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\DemuxManager.cs:line 117

21:05:49 ERROR Error writting demuxdump file: System.ObjectDisposedException: Cannot access a closed file.
at System.IO.__Error.FileNotOpen()
at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
at OpenSatelliteProject.DemuxManager.parseBytes(Byte[] data) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\DemuxManager.cs:line 117

21:05:50 ERROR Error writting demuxdump file: System.ObjectDisposedException: Cannot access a closed file.
at System.IO.__Error.FileNotOpen()
at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
at OpenSatelliteProject.DemuxManager.parseBytes(Byte[] data) in F:\sw\goes_xrit_viewer\goes_xrit_viewer\DemuxManager.cs:line 117

21:05:50 ERROR Error writting demuxdump file: System.ObjectDisposedException: Cannot access

Many more errors are repeated like this. I am assigning RecordToFile from another Thread. Seems like it's not thread safe yet.

Add counter for Unknown products

Sometimes new products are sent. Add a counter for Unknown products so user knows to check that directory for content.

Example: GOES 16 is current sending product ID 7 LRIT files. These segment files are put into Unknown directory but there is no status indication otherwise like we have for ABI products etc.

`SCANNER_DATA_1' error when rebuilding in Monodevelop (Release)

In goesdump/master commit ef32c60, when I did a "Rebuild goesdump" in Monodevelop, got the following error (5 times) when set to "Release". There are no errors when rebuilding as "Release Headless"

/home/k4kdr/osp/goesdump/goesdump/Main.cs(82,82): Error CS0117: OpenSatelliteProject.PacketData.Enums.NOAAProductID' does not contain a definition for SCANNER_DATA_1' (CS0117) (GOES Dumper)

ABI Channel 08 images no longer being generated

ABI Channel 08 LRITs are still ingested but images are no longer being generated as of 2018-02-09. The LRITs are still readable by xritimg.

find /root/osp-build/bin/goesdump/output/Images/FM1/ -type f -name '*.png' | grep -v -e 'Channel 7' -e 'Channel 9' -e 'Channel 14' -e 'Channel 15' -e 'Mesoscale' -e 'IR' -e 'FSCLR' -e 'VIS'

returns no images.

Proposed change for ABI LRIT filename

Per Trango email with NOAA contact, their Dartcom receivers output LRITs that have segmentation sequence numbers between 1 and 16 and do not contain the Image ID in the filename:

OR_ABI-L2-CMIPM1-M3C02_G16_s20173500704305_e20173500704362_c20173500704430.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_001.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_002.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_003.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_004.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_005.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_006.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_007.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_008.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_009.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_010.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_011.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_012.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_013.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_014.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_015.lrit
OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274_016.lrit

Goesdump should follow this format for compatibility

Himawari PNG generation broken

look like Himawari images are broken with OSP organizaer
it's not generating the PNG because it thinks it already has done it. and then it erases everything.

i see this file was HIMAWARI8chnFull DiskrgnFull Diskseg000res00dat generated but with no suffix... add .png and its the final image. however since it has not timestamp no more himawari images will be generated since organizer things it already did that image.

bin file for reproducing

https://www.dropbox.com/s/tjnmvrx80isbulw/demuxdump-1495166529.bin?dl=0

Make ShapeFile Draw Mask Cache

Currently OSP can draw shapefiles in all images, but it takes lots of time for full disks ( > 10 seconds ), so we need to figure out a way to cache the overlays.

DemuxManager reset() throws exception

when you get a chance test the Reset() call into your DemuxManager()
it throws an exception
Collection was modified; enumeration operation may not execute.
foreach (var k in demuxers.Keys) {
demuxers[k] = new Demuxer(this);
in the reset() method

UseNOAAFileFormat option does not work for GOES-R imagery

if (UseNOAAFileFormat) {
contains unnecessary checks that don't allow GOES-R LRIT filenames to be used as image names.

The following was substituted in:
if (UseNOAAFileFormat) {
origName = origName != null ? Path.GetFileName (origName) : "";
string baseName = Path.GetFileNameWithoutExtension (origName);
return $"{baseName}.png";
}

This produces images with the same filename as the first LRIT in their respective segmentation sequences. False Color images are no longer produced - have to look into how to identify those images in the UseNOAAFileFormat if statement so they can retain their OSP filename

ImageManager.EraseFiles enhancement

Setting ImageManager.EraseFiles = true; does not seem to impact *.lrit files when False Color generation is set to false. Would be nice to assume a user may have false color complete off and just want IR, WV and VIS generated PNG/JPG.

Proposed image generation change

Allow segmented full disk sequences to be generated after a timeout even if not all segments are present-

Occasionally HRIT will deliver 15/16 segments of a GOES-16 full disk. Goesdump currently does not attempt to generate the image in this scenario. This incomplete image could still be generated with black or white bars filling in for the missing LRITs after a timeout. The timeout would be longer than the normal amount of time we expect to receive all 16 segments of a full disk.

Discontinue use of OSP-format image filenames for non-false color images

Currently, different types of images output from GOES-16 HRIT have very different filename schemes:

G16-Mesoscale-GOES 16 ABI_None
G16-Mesoscale-VIS
G16-Full Disk-39048_Channel 7
GOES 15-Full disk-IR

This is broken and does not provide more value than NOAA's LRIT naming scheme. I propose that goesdump use the filename of the LRIT the image was derived from by default. Segmented images would be named after the first LRIT in the sequence e.g. OR_ABI-L2-CMIPF-M3C15_G16_s20173500745418_e20173500756191_c20173500756274.png (with segment number removed)

For false color images, the image could be named after the first LRIT for the visible channel, but the channel number could be changed to C00 or CFC e.g. OR_ABI-L2-CMIPF-M3CFC_G16_

Features suggested by @hwboy4

So just to keep track, here are the changes @hwboy4 suggested on OSP Rocket Chat:

  • Ability to specify path for received files (?by type)
  • Syslog on Linux/Unix/FreeBSD and to the console (as-is now) on Windows.
  • Enable / Disable streams (LRIT, EMWIN, DCS, etc.)
  • Make headless an option in the config file
  • Specify output filename format (printf format) in config file to allow interfacing with other programs.
  • Use of custom LUT files in false color generation (again in config file)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.