From: "Patrick Coronado" To: Cc: Subject: Real-Time Software Telemetry Processing System (RT-STPS) Date: Mon, 4 Feb 2002 18:15:26 -0500 X-Priority: 3 (Normal) Importance: Normal Sender: owner-direct_broadcast_users@listserv.gsfc.nasa.gov Reply-To: "Patrick Coronado" Status: Direct Broadcast Community, The Direct Readout Lab at NASA-Goddard is pleased to announce the release of version 2.0 of the Real-Time Software Telemetry Processing System, RT-STPS for short. This new version supercedes version 1.0 of STPS that some of you have been using. For those of you that are not familiar with this system, it is a Java application that ingests raw Terra or Aqua telemetry data right from the receiver/ingest card and produces level zero products (EOS PDS standard) such as sorted CCSDS packets and VCDUs, which include Reed Solomon and PN decoding. You can run it in batch mode (a one-time run with a data file and a configuration file as input) or as a server that is always running. The server or batch processor can send data across TCP/IP ports, to files, or to both at the same time depending on the setup file. Some of you have asked about the differences between STPS (Version 1.0) and RT-STPS (Version 2.0). Here they are: 1. STPS is written is C, which means it must be compiled and linked (if possible) on every target system. RT-STPS is written is Java, so it can run everywhere that a Java Virtual Machine can be installed. It does not require recompilation. 2. RT-STPS runs as fast or faster than STPS. 3. RT-STPS is more configurable than STPS. For example, you can write frames directly from the Frame Synchronizer to a file or TCP/IP socket while simultaneously doing packet reassembly to sockets and/or files. 4. RT-STPS can create EOS PDS and EDS files "on the fly." For STPS, you must run "Sorcerer" to perform this function post-pass. Note however, that Sorcerer does sorting by time, and it removes duplicate packets. The Sorcerer that is embedded in RT-STPS does not. This decision was made for reasons of reducing processing latency. Time sorting requires that a single pass be made through the entire data file, which takes time. Since Direct Broadcast science data is transmitted in real-time this feature could be eliminated resulting in near real-time PDS generation. 5. RT-STPS comes packaged with a Java viewer and controller tool that you can run on the same machine as the server or a different that can see the server machine via the network. The STPS has a very simple text interface. 6. RT-STPS can process EOS Aqua data and can create Aqua PDS files. STPS (and Sorcerer) cannot create proper Aqua PDS files. 7. STPS can do VCDU header error detection and correction. RT-STPS cannot do this at this time. However, this feature is not a priority for RT-STPS since EOS CADU headers are not encoded. 8. STPS can handle NRZ-L/NRZ-M correction. RT-STPS cannot. This feature will be incorporated into RT-STPS in the next release this summer. 9. RT-STPS can handle most spacecrafts that are CCSDS-compliant. The frames must be version 2 CADUs, and it can send out packets, VCDUs, and bitstream M_PDUs. If you wish to obtain the RT-STPS software package and/or information, it is available for download at: http://directreadout.gsfc.nasa.gov/software_main.html Once there, go to: Protocol Processing --> Terra or Aqua --> RT-STPS When you click on the Download button you will be asked to register, please do so. This will prevent you from having to fill out the registration form every time you wish to download a software package from our site. You will be immediately emailed with your user ID and password once registered. If you require the RT-STPS JAVA/C source code please let me know via direct email and we will stage it for you. We hope this software system becomes useful to the DB community. Feedback is always welcome. regards, Patrick ********************************* Patrick Coronado NASA Goddard Space Flight Center Code 935 Bldg 28 Rm. W186 Greenbelt MD., 20771 Tel: 301-286-9323 Fax: 301-286-1776 *********************************