You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Short version: takes the DCS data files and pushes them out a TCP socket immediate or "NONE\r\n" every 10 seconds. Thus fairly simple for downstream systems to process. (If you read the manual ignore all the control function; no one actually implements those.)
I've recently purchases and setup a Nooelec HRIT reciever and have goestools processing packets successfully. I'm not trying to figure out the "best" way to integrate the results into an OpenDCS/LRGS instance.
The complete commercial systems currently focus on just the data and serve the DCS feed over the DAMSNT for further processing.
So in my mind there are two approaches, though I think both might require changes/addition to this one.
Within the OpenDCS project: create a new "LrgsInputInterface" that uses JNI to wrap the assembler and do further processing within the OpenDCS eco system.
Add a DAMSNT service to this project.
Perhaps both, is the correct approach. I wanted to pitch the ask as it with option 1 it would be good to make sure the required portions are available as library that can be consumed downstream.
I'm offering and intending to do the work, I just want to make sure I'm not going in a direction that would interfere with other plans and projects.
The text was updated successfully, but these errors were encountered:
Presumably it shouldn't be too difficult to implement a DAMS-NT service to push out the DCS files as part of goesproc.
The HRIT/LRIT DCS format is very well documented, and all of the data fields needed to construct the DAMS-NT message are pretty straightforward to convert.
I did a little bit of work on at least parsing all of the header fields a few years again, so what you're looking to do probably isn't a very far leap from that at all. https://github.com/pietern/goestools/pull/50/files
The code in that pull request just sets up a DCS message handler and spits out the DCS data and headers to a semi-human-readable format in text files, so it's a start I suppose.
Given that I haven't touched that implementation in years and I haven't seen much more movement on the DCS side of things in goestools, I don't think you'd be interfering with anyone's plans going forward.
Reference: https://dcs1.noaa.gov/documents/DAMS_NT_Specification_V8.2.pdf
Short version: takes the DCS data files and pushes them out a TCP socket immediate or "NONE\r\n" every 10 seconds. Thus fairly simple for downstream systems to process. (If you read the manual ignore all the control function; no one actually implements those.)
I've recently purchases and setup a Nooelec HRIT reciever and have goestools processing packets successfully. I'm not trying to figure out the "best" way to integrate the results into an OpenDCS/LRGS instance.
The complete commercial systems currently focus on just the data and serve the DCS feed over the DAMSNT for further processing.
So in my mind there are two approaches, though I think both might require changes/addition to this one.
Perhaps both, is the correct approach. I wanted to pitch the ask as it with option 1 it would be good to make sure the required portions are available as library that can be consumed downstream.
I'm offering and intending to do the work, I just want to make sure I'm not going in a direction that would interfere with other plans and projects.
The text was updated successfully, but these errors were encountered: