Trio comes with support for 9 different color themes as well as Font Awesome icons as logos.
By default, Trio has two basic colors – black and baby blue. Black is used for all text and headings and this color is fixed. The other color (which is baby blue, by default) may be changed. Trio ships with 8 other colors (copied from Lanyon theme). These colors are listed in _sass/_colors.scss
. If you want to change the color theme, simply change the $theme-color
variable in _sass/_colors.scss
:
$theme-color: $base-08; /* Red */
Thanks to Mark Otto and Chris Kempson’s base16 for these themes. See the README.md
on GitHub Trio page for a screenshot of the red theme.
Trio also comes with support for logos, as you can see on the Trio homepage and this post. The logos are simply Font Awesome icons dipped in the current color theme. Post logos are shown both in the paginated index on the Trio homepage as well in the title of the blog post. In order to add a post logo, simply search for an icon on Font Awesome and find the icon keyword. Simply add icon keyword as the logo
field in the YAML from-matter to the post’s .md
file.
---
layout: post
title: Blog Post Title
logo: leaf
---
The above example will add a leaf
logo for the blog post.
Font Awesome has a few animated icons that can also be used. Animated icons could be useful to draw attention to a new post (such as this post).
In addition to individual post logos, Trio also supports a site logo that appears in the footer of all pages. Site wide logo is also a Font Awesome icon and may be set in a similar manner. The only difference is that instead of setting the logo in a .md
file, you need to set the logo in _config.yml
file:
fort_awesome_icon: 'cog fa-spin'


CSC 309 Minutes of the Node Team Meeting
hh:mm - hh:mm {AM,PM}, Day Month Year
Present:
Excused::
Absent:
The following are instructions for using this template; delete the
instructions after installation of the file.
-
Record meeting minutes in a separate file for each meeting; name each file
"ddmmmyy.html", e.g.,
7jan15.html
If more than one meeting is held on the same day, suffix each file name with
"a", "b", "c", as necessary. E.g., 7jan15a.html, 7jan15b.html. Store these
files in the project directory
administration/minutes/
-
Fill in your team name where "X" appears above.
-
Fill in "hh:mm - hh:mm {AM,PM}, dd Month yyyy" with the time and date of the
meeting, e.g.,
6:30 - 7:15 PM, 7 January 2015.
-
Fill in the Present: line with the names of those who attended
the meeting.
-
Fill in the Excused: line with the names of those who did not
attend the meeting who had a valid reason not to attend and who notified at
least one team member in advance that the meeting would be missed.
-
Fill in the Absent: line with the names of those who did not
attend the meeting who should have, i.e., missing team members.
-
Organize the minutes by major topic of discussion; record succinctly the
discussion of each topic.
-
As appropriate, conclude the minutes with a list of Action Items,
including the person(s) responsible for completing the items. Note that action
items need not record all of the normal work duties of team members, where
normal work means that prescribed in the milestone schedule. Action items are
specific tasks to be completed other than normal work, or certain normal work
duties that require immediate attention due to neglect or other reasons that
caused a delay of completion.


Interior Exploration Using Seismic Investigations, Geodesy, and Heat Transport (InSight) Mission
Rotation and Interior Structure Experiment (RISE)
PDS Archive
Software Interface Specification
Rev. 1.0
June 27, 2017
Prepared by
Dustin R. Buccino
Jet Propulsion Lab, California Institute of Technology
<EMAIL_ADDRESS>InSight
RISE
PDS Archive
Software Interface Specification
Rev. 1.0
June 27, 2017
Custodian:
Dustin R. Buccino Date
RISE Instrument Operations Engineer
Approved:
Sami W. Asmar Date
RISE Co-Investigator
William M. Folkner Date
RISE Co-Investigator
Raymond Arvidson Date
PDS Geosciences Node Manager
Contents
2.6 RISE Instrument Description
2.6.2 InSight Telecommunications System
2.6.6 Operational Considerations
3.3 Standards Used in Generating Data Products
3.3.3 Data Storage Conventions
4 RISE Archive Organization, Identifiers and Naming Conventions
4.4.1 RISE Raw Data Collection
4.5 InSight Document Bundle and Collections
5 RISE Archive Product Formats
5.1.1 Raw data file data structure
Appendix A Support staff and cognizant persons
Table 1: Document change log........................................................................................................ 6
Table 2: List of TBD items.............................................................................................................. 6
Table 3: Abbreviations and their meanings..................................................................................... 6
Table 4: InSight lander location in IAU_MARS frame................................................................ 12
Table 5: InSight antenna coordinates with respect to lander physical center................................ 14
Table 6: InSight mission name, abbreviation, and ID code........................................................... 14
Table 7: DSS distribution among complexes................................................................................. 17
Table 8: Cartesian coordinates for DSN stations in ITRF93 Reference Frame, Epoch 2003.0.... 23
Table 9: Site velocities for DSN stations....................................................................................... 23
Table 10: Data processing level definitions................................................................................... 26
Table 11: RISE data products overview....................................................................................... 28
Table 12: RISE data product naming convention......................................................................... 31
Table 13: RISE Bundles................................................................................................................ 31
Table 14: Collections in the RISE Raw Data Bundle................................................................... 32
Table 15: Examples of RISE Raw Data LIDs.............................................................................. 33
Table 16: Collections in the InSight Document Bundle................................................................ 33
Table 17: Record types contained in a TRK 2-34 file................................................................... 35
Table 18: Format of the weather data file..................................................................................... 37
Table 19: Archive support staff..................................................................................................... 40
This software interface specification (SIS) describes the format and content of the Rotation and Interior Structure Experiment (RISE). Planetary Data System (PDS) data archive. It includes descriptions of the data products and associated metadata, and the archive format, content, and generation pipeline.
Table 1: Document change log
|
Version |
Change |
Date |
Affected portion |
|
0.1 |
Initial draft |
March 12, 2015 |
All |
|
0.2 |
Updates for new Product_Ancillary |
July 29, 2015 |
All |
|
1.0 |
Post-peer review version |
May 31, 2017 |
All |
|
1.0 |
Removed Appendix B, Example Labels. The two Product_Observational labels are too large to include, and they are not useful in the document. |
June 1, 2017 |
Appendix B |
|
1.0 |
Accept changes from previous version, added MGA locations, finalized DSN station locations |
June 8, 2017 |
All |
|
1.0 |
Accept changes from previous version, updated author affiliation, added acknowledgements, updates from peer review |
June 27, 2017 |
All |
Table 2 lists items that are not yet finalized.
Table 2: List of TBD items
|
Item |
Section(s) |
Page(s) |
|
N/A |
Table 3: Abbreviations and their meanings
|
Abbreviation |
Meaning |
|
APSS |
Auxiliary Payload Sensor Subsystem |
|
ASCII |
American Standard Code for Information Interchange |
|
Atmos |
PDS Atmospheres Node (NMSU, Las Cruces, NM) |
|
BWG |
Beam Waveguide (DSN Antenna) |
|
CDR |
Calibrated Data Record |
|
CDSCC |
Canberra Deep Space Communications Complex |
|
CHDO |
Compressed Data Header Object |
|
CODMAC |
Committee on Data Management, Archiving, and Computing |
|
CSP |
Control Statement Processor language |
|
DOM |
Distributed Object Manager |
|
DOY |
Day of Year |
|
DSN |
Deep Space Network |
|
DSS |
Deep Space Station |
|
EDR |
Experiment Data Record |
|
FEI |
File Exchange Interface |
|
FOV |
Field of View |
|
FTP |
File Transfer Protocol |
|
GB |
Gigabyte(s) |
|
GDSCC |
Goldstone Deep Space Communications Complex |
|
GEO |
PDS Geosciences Node (Washington University, St. Louis, Missouri) |
|
GNSS |
Global Navigation Satellite System (e.g. Global Positioning System) |
|
GSFC |
Goddard Space Flight Center (Greenbelt, MD) |
|
HEF |
High Efficiency (DSN Antenna) |
|
HGA |
High Gain Antenna |
|
HK |
Housekeeping |
|
HP3 |
Heat Flow and Physical Properties Package |
|
HSB |
High-Speed Beam Waveguide (DSN Antenna) |
|
HTML |
Hypertext Markup Language |
|
ICD |
Interface Control Document |
|
IDA |
Instrument Deployment Arm |
|
IM |
Information Model |
|
ION |
Ionosphere (in reference to Ionosphere calibration files) |
|
ISO |
International Standards Organization |
|
JPL |
Jet Propulsion Laboratory (Pasadena, CA) |
|
LGA |
Low Gain Antenna |
|
LID |
Logical Identifier |
|
LIDVID |
Versioned Logical Identifier |
|
LVO |
Label Value Object |
|
MAG |
Magnetometer |
|
MB |
Megabyte(s) |
|
MD5 |
Message-Digest Algorithm 5 |
|
MDSCC |
Madrid Deep Space Communications Complex |
|
MGA |
Medium Gain Antenna |
|
NAIF |
Navigation and Ancillary Information Facility (JPL) |
|
NASA |
National Aeronautics and Space Administration |
|
NAV |
Navigation |
|
NSSDCA |
NASA Space Science Data Coordinated Archive |
|
PDS |
Planetary Data System |
|
PDS4 |
Planetary Data System Version 4 |
|
PPI |
PDS Planetary Plasma Interactions Node (UCLA) |
|
RA |
Restricted ASCII |
|
RAD |
Radiometer |
|
RDA |
Raw Data Archive |
|
RFS |
Radio Frequency Subsystem |
|
RISE |
Rotation and Interior Structure Experiment |
|
RS |
Radio Science |
|
RSS |
Radio Science Subsystem |
|
SCT |
Spacecraft Team |
|
SDST |
Small Deep Space Transponder |
|
SEIS |
Seismic Experiment for Investigating the Subsurface |
|
SFDU |
Standard Formatted Data Unit |
|
SIS |
Software Interface Specification |
|
SIS |
Software Interface Specification |
|
SNR |
Signal-to-Noise Ratio |
|
SPICE |
Spacecraft, Planet, Instrument, C-matrix, and Events (NAIF data format) |
|
SPK |
Spacecraft and Planetary ephemeris Kernel (NAIF) |
|
TBD |
To Be Determined |
|
TNF |
Tracking and Navigation File (TRK 2-34) |
|
TRO |
Troposphere (in reference to Troposphere calibration files) |
|
TSAC |
Tracking System Analytic Calibration |
|
URN |
Uniform Resource Name |
|
VID |
Version Identifier |
|
WEA |
Weather (in reference to DSN Weather files) |
|
WU |
Washington University, St. Louis |
|
XML |
eXtensible Markup Language |
Many of these definitions are taken from Appendix A of the PDS4 Concepts Document, pds.nasa.gov/pds4/doc/concepts. The reader is referred to that document for more information.
Archive – A place in which public records or historical documents are preserved; also the material preserved – often used in plural. The term may be capitalized when referring to all of PDS holdings – the PDS Archive.
Basic Product – The simplest product in PDS4; one or more data objects (and their description objects), which constitute (typically) a single observation, document, etc. The only PDS4 products that are not basic products are collection and bundle products.
Bundle Product – A list of related collections. For example, a bundle could list a collection of raw data obtained by an instrument during its mission lifetime, a collection of the calibration products associated with the instrument, and a collection of all documentation relevant to the first two collections.
Class – The set of attributes (including a name and identifier) which describes an item defined in the PDS Information Model. A class is generic – a template from which individual items may be constructed.
Collection Product – A list of closely related basic products of a single type (e.g. observational data, browse, documents, etc.). A collection is itself a product (because it is simply a list, with its label), but it is not a basic product.
Data Object – A generic term for an object that is described by a description object. Data objects include both digital and non-digital objects.
Description Object – An object that describes another object. As appropriate, it will have structural and descriptive components. In PDS4 a ‘description object’ is a digital object – a string of bits with a predefined structure.
Digital Object – An object which consists of real electronically stored (digital) data.
Identifier – A unique character string by which a product, object, or other entity may be identified and located. Identifiers can be global, in which case they are unique across all of PDS (and its federation partners). A local identifier must be unique within a label.
Label – The aggregation of one or more description objects such that the aggregation describes a single PDS product. In the PDS4 implementation, labels are constructed using XML.
Logical Identifier (LID) – An identifier which identifies the set of all versions of a product.
Versioned Logical Identifier (LIDVID) – The concatenation of a logical identifier with a version identifier, providing a unique identifier for each version of product.
Manifest - A list of contents.
Metadata – Data about data – for example, a ‘description object’ contains information (metadata) about an ‘object.’
Object – A single instance of a class defined in the PDS Information Model.
PDS Information Model – The set of rules governing the structure and content of PDS metadata. While the Information Model (IM) has been implemented in XML for PDS4, the model itself is implementation independent.
Product – One or more tagged objects (digital, non-digital, or both) grouped together and having a single PDS-unique identifier. In the PDS4 implementation, the descriptions are combined into a single XML label. Although it may be possible to locate individual objects within PDS (and to find specific bit strings within digital objects), PDS4 defines ‘products’ to be the smallest granular unit of addressable data within its complete holdings.
Tagged Object – An entity categorized by the PDS Information Model, and described by a PDS label.
Registry – A data base that provides services for sharing content and metadata.
Repository – A place, room, or container where something is deposited or stored (often for safety).
XML – eXtensible Markup Language.
XML schema – The definition of an XML document, specifying required and optional XML
elements, their order, and parent-child relationships.
The purpose of this SIS (Software Interface Specification) document is to provide users of the Rotation and Interior Structure Experiment archive with a detailed description of the data products and how they are generated, along with a description of the PDS4 archive bundle, the structure in which the data products, documentation, and supporting material are stored. The users for whom this document is intended are the scientists who will analyze the data, including those associated with the project and those in the general planetary science community.
This SIS covers raw data products generated by RISE that are intended to be archived in the Planetary Data System (PDS). In particular, these products are TRK 2-34 Tracking and Navigation Files (TNF), Troposphere calibration files (TRO), Ionosphere calibration files (ION), and DSN weather files (WEA).
This SIS describes how the RISE instrument acquires data, and how the data are processed, formatted, labeled, and uniquely identified. The document discusses standards used in generating the data products and software that may be used to access the products. The data structure and organization are described in sufficient detail to enable a user to read and understand the data.
[1] Planetary Data System Standards Reference, Version 1.8.0, March 21, 2017.
[2] PDS4 Data Dictionary, Abridged, Version <IP_ADDRESS>, March 10, 2017.
[5] DSN Telecommunications Link Design Handbook, DSN No. 810-005, Rev E. JPL D-19379. October 28, 2015. http://deepspace.jpl.nasa.gov/dsndocs/810-005/
[9] Folkner, W.M., Asmar, S.W., Dehant, V., and Warwick, R.W., The Rotation and Interior Structure Experiment (RISE) for the InSight mission to Mars (2012). 43rd Lunar and Planetary Science Conference, 1721. http://www.lpi.usra.edu/meetings/lpsc2012/pdf/1721.pdf
The PDS4 Documents [1] through [3] are subject to revision. The most recent versions may be found at http://pds.nasa.gov/pds4/doc/. The RISE PDS4 products specified in this SIS have been designed based on the versions current at the time, which are those listed above.
References [6], [7], and [8] are included in the documents collection in this archive.
This document serves both as a Data Product SIS and an Archive SIS. It describes the format and content of RISE data products in detail, and the structure and content of the archive in which the data products, documentation, and supporting material are stored. This SIS is intended to be used both by the instrument team in generating the archive, and by data users wishing to understand the format and content of the archive. Typically these individuals would include scientists, data analysts, and software engineers.
InSight will be launched in March 2016 and will place a single geophysical lander on Mars on September 20, 2016, to study its deep interior. The Surface Phase consists of Deployment and Penetration, and Science Monitoring. It ends after one Mars year plus 40 sols.
The science payload comprises two instruments: the Seismic Experiment for Interior Structure (SEIS) and the Heat-Flow and Physical Properties Probe (HP3). In addition, the Rotation and Interior Structure Experiment (RISE) will use the spacecraft X-band communication system to provide precise measurements of planetary rotation. SEIS and HP3 are placed on the surface with an Instrument Deployment System (IDS) comprising an Instrument Deployment Arm (IDA), Instrument Deployment Camera (IDC), and Instrument Context Camera (ICC). There are also several supporting instruments. The Auxiliary Payload Sensor Subsystem (APSS) includes the pressure sensor, the magnetometer, and Temperature and Wind for InSight (TWINS) sensors and collects environmental data in support of SEIS. These data will be used by SEIS to reduce and analyze their data. The radiometer (RAD) will be used by the HP3 team to measure surface temperature and thermal properties to support their data analysis.
The landing site is targeted for Elysium Planitia with estimated coordinates of 4 deg N latitude and 138 deg E longitude. The predicted Cartesian coordinates are shown in Table 4 in the IAU_MARS reference frame relative to the Mars center (SPICE code 499). Please note that these are pre-launch estimated position of the lander in the IAU_MARS frame, and should not be confused with the any estimated positions or coordinate systems after InSight landing.
Table 4: InSight lander location in IAU_MARS frame
|
|
X (km) |
Y (km) |
Z (km) |
|
InSight Lander |
-2432.124 |
2351.137 |
263.853 |
The RISE instrument utilizes the X-band telecommunications capability of the InSight lander in combination with the coherent Doppler tracking equipment at the Deep Space Network (DSN) to perform radio science experiments to determine the precession and nutation of the Martian spin axis. The spacecraft part of the radio science instrument (RISE) is described in Section 2.6.2 followed by a description of the DSN (ground) part of the instrument in Section 2.6.3.
For more information about RISE, refer to Folkner, et.al. 2012 [10].
The objective of RISE is to estimate the precession and nutation (the “wobble”) of the Martian spin axis. Through the estimation of the spin wobble, the size and density of the Martian core can be derived. The estimations of precession and nutation are based on the Doppler tracking between the InSight lander and the Earth-based observing stations of the Deep Space Network. A DSN station transmits a carrier at a known frequency to the InSight lander where the signal is detected and retransmitted back to the DSN, where the received frequency is measured.
The Doppler is a measurement of the relative velocity between InSight and the DSN station. The measurements are crucial for navigation of the spacecraft during cruise before arrival at Mars. RISE measurements begin once the spacecraft has landed on the surface. These measurements are used as the input to the orbit determination process, where the Martian spin axis parameters are estimated alongside the coordinates of the lander.
Because RISE is a radio science experiment, other radio science investigations may be performed using the Doppler data, for example, length-of-day (LOD) variations.
The InSight telecommunications system uses both X-band and UHF systems for communications. The X-band system utilizes a Small Deep Space transponder (SDST) for uplink and downlink tracking and communications during cruise and surface operations. The UHF system is used during EDL for downlink-only communications and uplink and downlink communications during surface operations. The UHF system is used in relay-mode: the lander will communicate with current Martian orbiter assets which will relay the information to and from Earth.
RISE will utilize Doppler capability the X-band communications only. No ranging data are planned for RISE. Although Doppler tracking is possible from the UHF system, the long wavelength and wide-band antennas cause too much multipath and are thus not useful for geodesy purposes. A block diagram of the X-band communications system as configured for RISE on the surface is shown below.
Figure 1: InSight telecommunications configuration for RISE
The SDST transmits a signal through the Solid-State Power Amplifier (SSPA), which amplifies the power for transmission. The signal goes through the diplexer where the switch (S) selects between using the West-facing medium-gain antenna (MGA) and the East-facing MGA.
Due to the geometry of the lander, the East MGA will always be used during Mars morning and the West MGA will always be used during Mars evening. Thus, by knowing the local solar time at the lander’s location, it is possible to determine which antenna is being used.
The table below describes the physical coordinates of the antennas mounted on the lander. The coordinate system is the Lander Mechanical Frame, referred to as the “INSIGHT_LANDER” frame in SPICE Kernels.
Table 5: InSight antenna coordinates with respect to lander physical center
|
Antenna |
X (meters) |
Y (meters) |
Z (meters) |
|
West MGA |
0.00 |
-0.72 |
-0.13 |
|
East MGA |
-0.19 |
0.82 |
-0.13 |
InSight is identified by the Deep Space Network using a spacecraft identification code shown in Table 6.
Table 6: InSight mission name, abbreviation, and ID code
|
Mission Name |
Abbreviation |
Spacecraft ID |
|
InSight |
NSYT |
189 |
The Deep Space Network (DSN) is the ground network that provides tracking and communications for InSight. A description of the DSN from the perspective of Doppler tracking is described in this section.
Three Deep Space Communications Complexes (DSCCs) comprise the DSN tracking network. The Goldstone DSCC (GDSCC) is located near Barstow, CA; the Canberra DSCC (CDSCC) is located near Canberra, Australia; and the Madrid DSCC (MDSCC) is located near Madrid, Spain. The complexes are strategically placed roughly 120 degrees in longitude apart to give continuous coverage of the sky. Each complex is equipped with several antennas, including at least one each 70-m, 34-m High Efficiency (HEF), and 34-m Beam WaveGuide (BWG), and associated electronics, and operational systems.
Primary activity at each complex is radiation of commands to and reception of telemetry data from active spacecraft. Transmission and reception is possible in several radio-frequency bands, the most common being S-band (nominally a frequency of 2100-2300 MHz), X-band (7100-8500 MHz), and Ka-band (31800-32300 MHz). Transmitter output powers of up to 400 kW are available.
Ground stations have the ability to transmit coded and uncoded waveforms which can be echoed by distant spacecraft. Analysis of the received coding allows navigators to determine the distance to the spacecraft; analysis of Doppler shift on the carrier signal allows estimation of the line-of-sight spacecraft velocity. Range and Doppler measurements are used to calculate the spacecraft trajectory and to infer gravity fields of objects near the spacecraft.
Ground stations can record spacecraft signals that have propagated through or been scattered from target media. Measurements of signal parameters after wave interactions with surfaces, atmospheres, rings, and plasmas are used to infer physical and electrical properties of the target.
The Deep Space Network is managed by the Jet Propulsion Laboratory of the California Institute of Technology for the U.S. National Aeronautics and Space Administration.
The Deep Space Communications Complexes (DSCCs) are an integral part of Radio Science instrumentation, along with the spacecraft Radio Frequency Subsystem. Their system performance directly determines the degree of success of Radio Science investigations, and their system calibration determines the degree of accuracy in the results of the experiments. The following paragraphs describe the functions performed by the individual subsystems of a DSCC. This material has been adapted from Asmar, et.al. 1995 [10] and DSN 810-005, Telecommunications Link Design Handbook [5].
Each DSCC includes a set of antennas, a Signal Processing Center (SPC), and communication links to the Jet Propulsion Laboratory (JPL). The general configuration is illustrated below; antennas (Deep Space Stations, or DSS – a term carried over from earlier times when antennas were individually instrumented) are listed in the table.
Figure 2: General configuration of the NASA Deep Space Network, showing the Goldstone Deep Space Communications Complex in detail.
Table 7: DSS distribution among complexes
|
Antenna Type |
Goldstone SPC-10 |
Canberra SPC-40 |
Madrid SPC-60 |
|
26-m |
DSS-16 |
DSS-46 |
DSS-66 |
|
34-m HEF |
DSS-15 |
DSS-45 |
DSS-65 |
|
34-m BWG |
DSS-24 DSS-25 DSS-26 |
DSS-34 DSS-35 DSS-36[1] |
DSS-54 DSS-55 |
|
34-m HSB |
DSS-27 DSS-28 |
|
|
|
70-m |
DSS-14 |
DSS-43 |
DSS-63 |
|
Developmental |
DSS-13 |
|
|
Subsystem interconnections at each DSCC are shown in the diagram below, and they are described in the sections that follow. The Monitor and Control Subsystem is connected to all other subsystems; the Test Support Subsystem can be.
Figure 3: DSCC subsystem interconnections
The DSCC Monitor and Control Subsystem (DMC) is part of the Monitor and Control System (MON) which also includes the ground communications Central Communications Terminal and the Network Operations Control Center (NOCC) Monitor and Control Subsystem. The DMC is the center of activity at a DSCC. The DMC receives and archives most of the information from the NOCC needed by the various DSCC subsystems during their operation. Control of most of the DSCC subsystems, as well as the handling and displaying of any responses to control directives and configuration and status information received from each of the subsystems, is done through the DMC. The effect of this is to centralize the control, display, and archiving functions necessary to operate a DSCC. Communication among the various subsystems is done using a Local Area Network (LAN) hooked up to each subsystem via a network interface unit (NIU).
Multi-mission Radio Science activities require support from the 70-m, 34-m HEF, and 34-m BWG antenna subnets. The antennas at each DSCC function as large-aperture collectors which, by double reflection, cause the incoming radio frequency (RF) energy to enter the feed horns. The large collecting surface of the antenna focuses the incoming energy onto a subreflector, which is adjustable in both axial and angular position. These adjustments are made to correct for gravitational deformation of the antenna as it moves between zenith and the horizon; the deformation can be as large as 5 cm. The subreflector adjustments optimize the channeling of energy from the primary reflector to the subreflector and then to the feed horns. The 70-m and 34-m HEF antennas have 'shaped' primary and secondary reflectors, with forms that are modified paraboloids. This customization allows more uniform illumination of one reflector by another. The BWG reflector shape is ellipsoidal.
On the 70-m antennas, the subreflector directs received energy from the antenna onto a dichroic plate, a device which reflects S-band energy to the S-band feed horn and passes X-band energy through to the X-band feed horn. In the 34-m HEF, there is one 'common aperture feed,' which accepts both frequencies without requiring a dichroic plate. In the 34-m BWG, a series of small mirrors (approximately 2.5 meters in diameter) directs microwave energy from the subreflector region to a collection area at the base of the antenna -- typically in a pedestal room. A retractable dichroic reflector separates S- and X-band on some BWG antennas or X- and Ka-band on others. RF energy to be transmitted into space by the horns is focused by the reflectors into narrow cylindrical beams, pointed with high precision (either to the dichroic plate or directly to the subreflector) by a series of drive motors and gear trains that can rotate the movable components and their support structures.
The different antennas can be pointed by several means. Two pointing modes commonly used during tracking passes are CONSCAN and 'blind pointing.' With CONSCAN enabled and a closed loop receiver locked to a spacecraft signal, the system tracks the radio source by conically scanning around its position in the sky. Pointing angle adjustments are computed from signal strength information (feedback) supplied by the receiver. In this mode the Antenna Pointing Assembly (APA) generates a circular scan pattern which is sent to the Antenna Control System (ACS). The ACS adds the scan pattern to the corrected pointing angle predicts. Software in the receiver-exciter controller computes the received signal level and sends it to the APA. The correlation of scan position with the received signal level variations allows the APA to compute offset changes which are sent to the ACS. Thus, within the capability of the closed-loop control system, the scan center is pointed precisely at the apparent direction of the spacecraft signal source. An additional function of the APA is to provide antenna position angles and residuals, antenna control mode/status information, and predict-correction parameters to the Area Routing Assembly (ARA) via the LAN, which then sends this information to JPL via the Ground Communications Facility (GCF) for antenna status monitoring.
During periods when excessive signal level dynamics or low received signal levels are expected (e.g., during an occultation experiment), CONSCAN should not be used. Under these conditions, blind pointing (CONSCAN OFF) is used, and pointing angle adjustments are based on a predetermined Systematic Error Correction (SEC) model.
Independent of CONSCAN state, subreflector motion in at least the z-axis may introduce phase variations into the received Radio Science data. For that reason, during certain experiments, the subreflector in the 70-m and 34-m HEFs may be frozen in the z-axis at a position (often based on elevation angle) selected to minimize phase change and signal degradation. This can be done via Operator Control Inputs (OCIs) from the LMC to the Subreflector Controller (SRC) which resides in the alidade room of the antennas. The SRC passes the commands to motors that drive the subreflector to the desired position.
Pointing angles for all antenna types are computed by the NOCC Support System (NSS) from an ephemeris provided by the flight project. These predicts are received and archived by the CMC. Before each track, they are transferred to the APA, which transforms the direction cosines of the predicts into AZ-EL coordinates. The LMC operator then downloads the antenna predict points to the antenna-mounted ACS computer along with a selected SEC model. The pointing predicts consist of time-tagged AZ-EL points at selected time intervals along with polynomial coefficients for interpolation between points.
The ACS automatically interpolates the predict points, corrects the pointing predicts for refraction and subreflector position, and adds the proper systematic error correction and any manually entered antenna offsets. The ACS then sends angular position commands for each axis at the rate of one per second. In the 70-m and 34-m HEF, rate commands are generated from the position commands at the servo controller and are subsequently used to steer the antenna.
When not using binary predicts (the routine mode for spacecraft tracking), the antennas can be pointed using 'planetary mode' -- a simpler mode which uses right ascension (RA) and declination (DEC) values. These change very slowly with respect to the celestial frame. Values are provided to the station in text form for manual entry. The ACS quadratically interpolates among three RA and DEC points which are on one-day centers.
A third pointing mode -- sidereal -- is available for tracking radio sources fixed with respect to the celestial frame.
Regardless of the pointing mode being used, a 70-m antenna has a special high-accuracy pointing capability called 'precision' mode. A pointing control loop derives the main AZ-EL pointing servo drive error signals from a two- axis autocollimator mounted on the Intermediate Reference Structure. The autocollimator projects a light beam to a precision mirror mounted on the Master Equatorial drive system, a much smaller structure, independent of the main antenna, which is exactly positioned in HA and DEC with shaft encoders. The autocollimator detects elevation/cross- elevation errors between the two reference surfaces by measuring the angular displacement of the reflected light beam. This error is compensated for in the antenna servo by moving the antenna in the appropriate AZ-EL direction. Pointing accuracies of 0.004 degrees (15 arc seconds) are possible in 'precision' mode. The 'precision' mode is not available on 34-m antennas -- nor is it needed, since their beamwidths are twice as large as on the 70-m antennas.
70-m Antennas: Each 70-m antenna has three feed cones installed in a structure at the center of the main reflector. The feeds are positioned 120 degrees apart on a circle. Selection of the feed is made by rotation of the subreflector. A dichroic mirror assembly, half on the S-band cone and half on the X-band cone, permits simultaneous use of the S- and X-band frequencies. The third cone is devoted to R&D and more specialized work.
The Antenna Microwave Subsystem (AMS) accepts the received S- and X-band signals at the feed horn and transmits them through polarizer plates to an orthomode transducer. The polarizer plates are adjusted so that the signals are directed to a pair of redundant amplifiers for each frequency, thus allowing simultaneous reception of signals in two orthogonal polarizations. For S-band these are S-band High Electron Mobility Transistors (HMT); for X-band the amplifiers is a X-band High Electron Mobility Transistor (HEMT).
34-m HEF Antennas: The 34-m HEF uses a single feed for both S- and X-band. Simultaneous S- and X-band receive as well as X-band transmit is possible thanks to the presence of an S/X 'combiner' which acts as a diplexer. For S-band, RCP or LCP is user selected through a switch so neither a polarizer nor an orthomode transducer is needed. X-band amplification options include two Traveling Wave Masers (TWMs) or a HEMT Low Noise Amplifier (LNA). S-band amplification is provided by a HEMT.
34-m BWG Antennas: These antennas use feeds and low-noise amplifiers (LNA) in the pedestal room, which can be switched in and out as needed. For X-band, the options are TWMs or HEMT. At Ka-band, the LA is a HEMT. Typically the following modes are available:
1. Downlink non-diplexed path (RCP or LCP) to LNA-1, with uplink in the opposite circular polarization
2. Downlink non-diplexed path (RCP or LCP) to LNA-2, with uplink in the opposite circular polarization
3. Downlink diplexed path (RCP or LCP) to LNA-1, with uplink in the same circular polarization
4. Downlink diplexed path (RCP or LCP) to LNA-2, with uplink in the same circular polarization
For BWG antennas with dual-band capabilities (e.g., DSS 25) and dual LNAs, each of the above four modes can be used in a single-frequency or dual-frequency configuration. Thus, for antennas with the most complete capabilities, there are sixteen possible ways to receive at a single frequency (2 polarizations, 2 waveguide path choices, 2 LNAs, and 2 bands).
The Receiver-Exciter Subsystem is composed of two groups of equipment: the closed-loop receiver group and the open-loop receiver group. This subsystem is controlled by the Receiver-Exciter Controller (REC) which communicates directly with the DMC for predicts and OCI reception and status reporting.
The exciter generates the S-band signal (or X-band for the 34-m HEF only) which is provided to the Transmitter Subsystem for the spacecraft uplink signal. It is tunable under command of the Digitally Controlled Oscillator (DCO) which receives predicts from the Metric Data Assembly (MDA).
The diplexer in the signal path between the transmitter and the feed horn for all three antennas (used for simultaneous transmission and reception) may be configured such that it is out of the received signal path (in listen-only or bypass mode) in order to improve the signal-to-noise ratio in the receiver system.
Closed Loop Receivers: The Block V receiver-exciter at the 70-m stations allows for two receiver channels, each capable of L-Band (e.g., 1668 MHz frequency or 18 cm wavelength), S-band, or X-band reception, and an S-band exciter for generation of uplink signals through the low-power or high-power transmitter.
The closed-loop receivers provide the capability for rapid acquisition of a spacecraft signal and telemetry lockup. In order to accomplish acquisition within a short time, the receivers are predict driven to search for, acquire, and track the downlink automatically. Rapid acquisition precludes manual tuning though that remains as a backup capability. The subsystem utilizes FFT analyzers for rapid acquisition. The predicts are NSS generated, transmitted to the CMC which sends them to the Receiver-Exciter Subsystem where two sets can be stored. The receiver starts acquisition at uplink time plus one round-trip-light-time or at operator specified times. The receivers may also be operated from the LMC without a local operator attending them. The receivers send performance and status data, displays, and event messages to the LMC.
Either the exciter synthesizer signal or the simulation (SIM) synthesizer signal is used as the reference for the Doppler extractor in the closed-loop receiver systems, depending on the spacecraft being tracked (and Project guidelines). The SIM synthesizer is not ramped; instead it uses one constant frequency, the Track Synthesizer Frequency (TSF), which is an average frequency for the entire pass.
The closed-loop receiver AGC loop can be configured to one of three settings: narrow, medium, or wide. It will be configured such that the expected amplitude changes are accommodated with minimum distortion. The loop bandwidth (2BLo) will be configured such that the expected phase changes can be accommodated while maintaining the best possible loop SNR.
Nominal carrier tracking loop threshold noise bandwidth at X-band is 10 Hz. Coherent (two-way) closed-loop system stability is shown in the table below:
|
Integration Time (secs) |
Doppler Uncertainty (one sigma, microns/sec) |
|
10 |
50 |
|
60 |
20 |
|
1000 |
4 |
The Transmitter Subsystem accepts the X-band frequency exciter signal from the Receiver-Exciter Subsystem exciter and amplifies it to the required transmit output level. The amplified signal is routed via the diplexer through the feed horn to the antenna and then focused and beamed to the spacecraft.
The Transmitter Subsystem power capabilities range from 18 kW to 400 kW.
The Tracking Subsystem primary functions are to acquire and maintain communications with the spacecraft and to generate and format radiometric data containing Doppler and range.
The DSCC Tracking Subsystem (DTK) receives the carrier signals and ranging spectra from the Receiver-Exciter Subsystem. The Doppler cycle counts are counted, formatted, and transmitted to JPL in real time. Ranging data are also transmitted to JPL in real time. Also contained in these blocks is the AGC information from the Receiver-Exciter Subsystem. The Radio Metric Data Conditioning Team (RMDCT) at JPL produces a Tracking and Navigation Service File (TNF), which contains Doppler and ranging data.
In addition, the Tracking Subsystem receives from the CMC frequency predicts (used to compute frequency residuals and noise estimates), receiver tuning predicts (used to tune the closed-loop receivers), and uplink tuning predicts (used to tune the exciter). From the LMC, it receives configuration and control directives as well as configuration and status information on the transmitter, microwave, and frequency and timing subsystems.
The Metric Data Assembly (MDA) controls all of the DTK functions supporting the uplink and downlink activities. The MDA receives uplink predicts and controls the uplink tuning by commanding the DCO. The MDA also controls the Sequential Ranging Assembly (SRA). It formats the Doppler and range measurements and provides them to the GCF for transmission to NOCC.
The Sequential Ranging Assembly (SRA) measures the round trip light time (RTLT) of a radio signal traveling from a ground tracking station to a spacecraft and back. From the RTLT, phase, and Doppler data, the spacecraft range can be determined. A coded signal is modulated on an uplink carrier and transmitted to the spacecraft where it is detected and transmitted back to the ground station. As a result, the signal received at the tracking station is delayed by its round trip through space and shifted in frequency by the Doppler Effect due to the relative motion between the spacecraft and the tracking station on Earth.
The Frequency and Timing Subsystem (FTS) provides all frequency and timing references required by the other DSCC subsystems. It contains four frequency standards of which one is prime and the other three are backups. Selection of the prime standard is done via the CMC. Of these four standards, two are hydrogen masers followed by clean-up loops (CUL) and two are cesium standards. These four standards all feed the Coherent Reference Generator (CRG) which provides the frequency references used by the rest of the complex. It also provides the frequency reference to the Master Clock Assembly (MCA) which in turn provides time to the Time Insertion and Distribution Assembly (TID) which provides UTC and SIM-time to the complex.
JPL's ability to monitor the FTS at each DSCC is limited to the MDA calculated Doppler pseudo-residuals, the Doppler noise, the SSI, and to a system which uses the Global Positioning System (GPS). GPS receivers at each DSCC receive a one-pulse-per-second pulse from the station's (hydrogen maser referenced) FTS and a pulse from a GPS satellite at scheduled times. After compensating for the satellite signal delay, the timing offset is reported to JPL where a database is kept. The clock offsets stored in the JPL database are given in microseconds; each entry is a mean reading of measurements from several GPS satellites and a time tag associated with the mean reading. The clock offsets provided include those of SPC 10 relative to UTC (NIST), SPC 40 relative to SPC 10, etc.
Calibrations of hardware systems are carried out periodically by DSN personnel; these ensure that systems operate at required performance levels -- for example, that antenna patterns, receiver gain, propagation delays, and Doppler uncertainties meet specifications. No information on specific calibration activities is available. Nominal performance specifications are shown in DSN 810-005 [5].
Prior to each tracking pass, station operators perform a series of calibrations to ensure that systems meet specifications for that operational period. Included in these calibrations is measurement of receiver system temperature in the configuration to be employed during the pass. Results of these calibrations are recorded in (hard copy) Controller's Logs for each pass.
Station locations are documented in detail in DSN 810-005, Module 301: “Coverage and Geometry” [5]. Cartesian coordinates are copied here for reference along with the respective velocities at each DSN complex.
Table 8: Cartesian coordinates for DSN stations in ITRF93 Reference Frame, Epoch 2003.0
|
Antenna |
Cartesian Coordinates |
|||
|
DSS ID |
Description |
X (m) |
Y (m) |
Z (m) |
|
DSS-13 |
34-m R&D |
–2351112.659 |
–4655530.636 |
3660912.728 |
|
DSS-14 |
70-m |
–2353621.420 |
–4641341.472 |
3677052.318 |
|
DSS-15 |
34-m HEF |
–2353538.958 |
–4641649.429 |
3676669.984 |
|
DSS-24 |
34-m BWG |
–2354906.711 |
–4646840.095 |
3669242.325 |
|
DSS-25 |
34-m BWG |
–2355022.014 |
–4646953.204 |
3669040.567 |
|
DSS-26 |
34-m BWG |
–2354890.797 |
–4647166.328 |
3668871.755 |
|
DSS-342 |
34-m BWG |
–4461147.093 |
2682439.239 |
–3674393.133 |
|
DSS-35[2] |
34-m BWG |
−4461273.090 |
2682568.925 |
−3674152.093 |
|
DSS-362 |
34-m BWG |
–446168.415 |
2682814.657 |
–3674083.901 |
|
DSS-43 |
70-m |
–4460894.917 |
2682361.507 |
–3674748.152 |
|
DSS-45 |
34-m HEF |
–4460935.578 |
2682765.661 |
–3674380.982 |
|
DSS-54 |
34-m BWG |
4849434.488 |
–360723.8999 |
4114618.835 |
|
DSS-55 |
34-m BWG |
4849525.256 |
–360606.0932 |
4114495.084 |
|
DSS-63 |
70-m |
4849092.518 |
–360180.3480 |
4115109.251 |
|
DSS-65 |
34-m HEF |
4849339.634 |
–360427.6637 |
4114750.733 |
Table 9: Site velocities for DSN stations
|
Complex |
X (m/year) |
Y (m/year) |
Z (m/year) |
|
Goldstone (1x & 2x) |
-0.0180 |
0.0065 |
-0.0038 |
|
Canberra (3x & 4x) |
-0.0335 |
-0.0041 |
0.0392 |
|
Madrid (5x & 6x) |
-0.0100 |
0.0242 |
0.0156 |
The Doppler Effect is caused by the relative motion between a transmitter and receiver. The frequency received at the ground station will differ from the frequency as transmitted by the lander. In the case of one-way Doppler (non-coherent), the spacecraft transmits a signal which is received at a DSN station. The downlink carrier phase is then measured and recorded as the received frequency. The Doppler measurement is then constructed as the difference between the transmitted and received frequency. In the case of two-way Doppler (coherent), the DSN station transmits a signal and the uplink carrier phase is then measured and recorded as the transmitted frequency. The spacecraft receives the signal, which is then multiplied by the turn-around ratio and re-transmitted back to the DSN station. The DSN station then measures and records the downlink carrier phase. The Doppler measurement is then constructed as the difference between transmitted frequency and received frequency divided by the turn-around ratio. A three-way Doppler measurement can be constructed in the same manner as a two-way measurement using a different DSN station for transmission and reception.
Sequential (SRA) Ranging is a direct measurement of the round-trip light-time between the DSN station and the spacecraft. A signal is coded on the uplink transmission from a DSN station and given a time stamp, which is then received back at Earth some time later and also time stamped. The received time minus transmit time is then a measurement of the round-trip light-time, or range, to the spacecraft. Sequential ranging can be conducted in two-way or three-way modes.
Please note that although range data may be collected between the spacecraft and the lander, they are not utilized in the RISE investigation.
Both the DSN and InSight’s X-band telecommunications system can be configured in different modes for the desired link type.
Nominally, four tracking passes are scheduled per week for RISE science, 45 minutes in duration each. Each pass is conducted in coherent mode, described in section <IP_ADDRESS> (below). Depending on the project requirements, there may or may not be telemetry modulated onto the transmission back to the DSN. For RISE, Doppler measurements are made at times at low elevation at the lander, where the Doppler signature due to the rotation of Mars is at its largest.
The closed-loop receiver AGC loop can be configured to one of three settings: narrow, medium, or wide. Ordinarily it is configured so that expected signal amplitude changes are accommodated with minimum distortion. The loop bandwidth is ordinarily configured so that expected phase changes can be accommodated while maintaining the best possible loop SNR. The loop bandwidth is nominally 10 Hz, but can be changed depending on real-time operational considerations. The carrier loop bandwidth used for any given Doppler measurement is specified in the TRK 2-34 file’s Downlink Carrier Phase CHDO.
The frequency of the signal transmitted from the spacecraft can generally be controlled in two ways - by locking to a signal received from a ground station or by locking to an on-board oscillator. These are known as the coherent (or 'two-way') and non-coherent ('one-way') modes, respectively. Mode selection is made at the spacecraft, based on commands received from the ground. When operating in the coherent mode, the transponder carrier frequency is derived from the received uplink carrier frequency with a 'turn-around ratio' typically of 880/749. In the non-coherent mode, the downlink carrier frequency is derived from the spacecraft on-board crystal-controlled oscillator. Either closed-loop or open-loop receivers (or both) can be used with either spacecraft frequency reference mode. Reception in two-way mode is usually preferred for routine tracking and is the nominal mode for the RISE data collection. Occasionally the spacecraft operates coherently while two ground stations receive the 'downlink' signal; this is sometimes known as the 'three-way' mode.
The InSight mission is divided into four phases: launch, cruise, EDL, deployment, and science monitoring. RISE does not begin until the deployment phase after landing, when instrument checkout is performed. Since RISE is not a deployed instrument, nominally one pass will be conducted each week using the X-band telecommunications system for RISE. During science monitoring, nominally four passes will be conducted per week.
On rare occasions the spacecraft may enter safe mode to protect itself from anomalous circumstances. During these times, RISE data were not collected.
System-level or hardware calibrations are performed routinely by DSN personnel and before each pass during “pre-cal”, or pre-calibration. For a brief description of this calibration, refer to section <IP_ADDRESS>, DSN Calibration.
Earth’s troposphere and ionosphere cause delays and phase changes on the transmitted and received signals. These must be corrected for using derived troposphere and ionosphere models. The DSN typically provides calibration files for tracking parameters in CSP (Control Statement Processor) format often referred to as CSP cards (see DSN 810-013, TRK-2-23 [7] for more details). CSP cards effectively give the mapped zenith delay, in meters, of either Earth’s troposphere or ionosphere as a function of time using polynomials. These corrections apply both to ranging measurements (not applicable for RISE) and Doppler measurements. Troposphere CSP cards are derived from surface meteorology (temperature, pressure, humidity, etc.). Ionosphere CSP cards are derived from measurements of the ionosphere using Earth-based systems such as GNSS.
RISE data products are radio science data products routinely produced by the DSN for tracking and navigation of spacecraft. The primary data type is the TRK 2-34 data product: Tracking and Navigation Service Data files, or TNFs. TNFs are the most primitive (and most voluminous) product of the closed-loop system.
TRK 2-34 files are binary files in Standard Formatted Data Unit (SFDU) format. There are 18 distinct types of SFDUs organized into five groups. An overview of the format is provided in Section <IP_ADDRESS>.
Each TRK 2-34 file is produced in near-real time (NERT) as the spacecraft is being actively tracked by a given DSN station. SFDUs are ordered in the TRK 2-34 files in time-ascending order by the DSN. One file is produced per pass. TRK 2-34 files are reformatted for archival purposes, grouped by SFDU data type. A detailed process of the reformatting is described in Section 3.2.3.
DSN Weather files are plain-text ASCII tables and are generated in near-real time from station monitoring data. These contain meteorology data such as temperature, pressure, humidity, etc. at a given DSN complex. These files are reformatted into tabular format for archival purposes.
Troposphere and Ionosphere files are plain-text ASCII stream files containing adjustments that should be made to the tracking data. These calibrations are provided in CSP (Control Statement Processor) cards. Each file is updated every several days and span one-month in duration.
This section describes the processing of RISE data products, their structure and organization, and their labeling.
Data processing levels mentioned in this SIS refer to the PDS4 processing level described in Table 10.
Table 10: Data processing level definitions
|
PDS4 processing level |
PDS4 processing level description |
CODMAC Level (used in PDS3) |
NASA Level (used in PDS3) |
|
n/a |
Telemetry data with instrument data embedded. PDS does not archive telemetry data. |
1 |
0 |
|
Raw |
Original data from an instrument. If compression, reformatting, packetization, or other translation has been applied to facilitate data transmission or storage, those processes are reversed so that the archived data are in a PDS approved archive format. Often call EDRs (Experimental Data Records). |
2 |
1A |
|
Partially Processed |
Data that have been processed beyond the raw stage but which have not yet reached calibrated status. These and more highly processed products are often called RDRs (Reduced Data Records). |
3 |
1A |
|
Calibrated |
Data converted to physical units, which makes values independent of the instrument. |
4 |
1B |
|
Derived |
Results that have been distilled from one or more calibrated data products (for example, maps, gravity or magnetic fields, or ring particle size distributions). Supplementary data, such as calibration tables or tables of viewing geometry, used to interpret observational data should also be classified as ‘derived’ data if not easily matched to one of the other three categories. |
4+ |
2+ |
RISE data products described in this SIS are considered NASA Level 0 or 1A (Raw) data products.
DSN tracking data (Doppler and Range measurements) are generated in near-real time (once every second) by the Downlink Tracking and Telemetry (DTT) Subsystem of the DSCC as the spacecraft is actively communicating with the ground. Tracking data are sent to the Tracking Data Delivery Subsystem (TDSS) which distributes tracking data in TRK 2-34 format to the Radiometric Data Conditioning (RMDC) Team. Tracking data are finally delivered via FTP server to the RISE team.
DSN weather, troposphere, and ionosphere calibration files are generated by the Tracking System Analytic Calibration (TSAC) group and delivered via FTP server to the RISE team.
Table 11 describes each file type, size, generation frequency, and source.
Table 11: RISE data products overview
|
File |
Abbrev. |
File Type |
Generation Frequency |
Update Frequency |
File Size |
Source |
|
Tracking and Navigation File (TRK 2-34) |
TNF |
Binary |
Per-pass |
Real-time |
5 MB/hour (X-up/X-down) |
RMDC |
|
Ionosphere Calibration File (TRK 2-23) |
ION |
ASCII |
Monthly |
Weekly |
028 kB/month |
TSAC |
|
Troposphere Calibration File (TRK 2-23) |
TRO |
ASCII |
Monthly |
Weekly |
160 kB/month |
TSAC |
|
Weather File (derived from TRK 2-24) |
WEA |
ASCII |
Yearly |
Daily |
1.1 MB/year |
TSAC |
This section describes only those portions of the InSight data flow that are directly connected to RISE archiving. A full description of InSight data flow is provided in the InSight Archive Generation, Validation, and Transfer Plan [4].
The RISE team performs minimal reformatting of the TRK 2-34 Tracking and Navigation File for delivery to PDS. For archival purposes, the TRK 2-34 file is re-grouped such that common-type SFDUs are together and are not necessarily in time-ascending order. For example, all Format Code 00 (uplink carrier phase) are grouped together at the start of the file, followed by all Format Code 01 (downlink carrier phase), etc. Note: each file will only contain the SFDU data types that were generated for that particular pass, e.g. not every TRK 2-34 file will contain every data type.
Additionally, TRK 2-24 DSN Weather Files are reformatted into tabular format.
It is important to note that although these two data products have been reformatted to be PDS4-compliant, no processing has been performed on the data.
Once in PDS-compliant format, the RISE team generates XML labels, assembles the data and documentation into archive bundles, and delivers the bundles to the PDS Geosciences Node. Deliveries take place according to the release schedule agreed upon by the InSight project and PDS as specified in the InSight Archive Plan [4]. The Geosciences Node validates the bundles and makes them available to the public online.
RISE products and labels comply with Planetary Data System standards, including the PDS4 data model, as specified in applicable documents [1], [2] and [3].
All data products in this archive use the UTC (Universal Time Coordinated) standard time format.
The data products contained in this archive are not dependent on the definition of a coordinate system.
Coordinates for the DSN stations are provided in ITRF93 and coordinates for the spacecraft antenna locations are provided in the spacecraft-fixed reference frame. See Section 2.6 for more details.
RISE products are stored in either binary or ASCII format depending on the data product: TRK 2-34 Tracking and Navigation Files are stored as uncompressed binary data files with integer, complex, floating point, and string data in most-significant byte first order (i.e. big-endian). DSN Weather files are ASCII tables with floating-point data. Troposphere and Ionosphere calibration files are stored as ASCII text in CSP cards.
Software for parsing, reducing, and analyzing data such as these have been developed at several institutions. Because such software must usually operate at the bit-level and is written for a narrow range of platforms, it is not suitable for general distribution. No software is included with this archival data set.
The SPICE toolkit is generally useful for analyzing data that are derived from these tracking data and is available on the NAIF node of PDS: http://naif.jpl.nasa.gov/naif/toolkit.html.
The Geosciences Node keeps two copies of each archive product. One copy is the primary online archive copy, another is a backup copy. Once the archive products are fully validated and approved for inclusion in the archive, a third copy of the archive is sent to the NASA Space Science Data Coordinated Archive (NSSDCA) for long-term preservation in a NASA-approved deep-storage facility. The Geosciences Node may maintain additional copies of the archive products, either on or off-site as deemed necessary.
This section describes the basic organization of the RISE raw data archive under the PDS4 Information Model (IM) (Applicable Documents [1] and [3]), including the naming conventions used for the bundle, collection, and product unique identifiers.
Every product in PDS is assigned an identifier which allows it to be uniquely identified across the system. This identifier is referred to as a Logical Identifier or LID. A LIDVID (Versioned Logical Identifier) includes product version information, and allows different versions of a specific product to be referenced uniquely. A product’s LID and VID are defined as separate attributes in the product label. LIDs and VIDs are assigned by PDS and are formed according to the conventions described in sections 4.1.1 and 4.1.2 below. The uniqueness of a product’s LIDVID may be verified using the PDS Registry and Harvest tools.
LIDs take the form of a Uniform Resource Name (URN). LIDs are restricted to ASCII lower case letters, digits, dash, underscore, and period. Colons are also used, but only to separate prescribed components of the LID. Within one of these prescribed components dash, underscore, or period are used as separators. LIDs are limited in length to 255 characters.
InSight RISE LIDs are formed according to the following conventions:
· Bundle LIDs are formed by appending a bundle specific ID to the base ID:
urn:nasa:pds:<bundle ID>
Example: urn:nasa:pds:insight_rise_raw
The bundle ID must be unique across all products archived with the PDS.
· Collection LIDs are formed by appending a collection specific ID to the collection’s parent bundle LID:
urn:nasa:pds: <bundle ID>:<collection ID>
Example: urn:nasa:pds:insight_rise_raw:trk234_trknav
Since the collection LID is based on the bundle LID, which is unique across PDS, the only additional condition is that the collection ID must be unique across the bundle. Collection IDs correspond to the collection type (e.g. “browse”, “data”, “document”, etc.). Additional descriptive information may be appended to the collection type (e.g. “data-raw”, “data-calibrated”, etc.) to insure that multiple collections of the same type within a single bundle have unique LIDs.
· Basic product LIDs are formed by appending a product specific ID to the product’s parent collection LID:
urn:nasa:pds: <bundle ID>:<collection ID>:<product ID>
Example: urn:nasa:pds:insight_rise_raw:trk234_trknav:nsyt_maro_2008_015_1541xmmv1
Since the product LID is based on the collection LID, which is unique across PDS, the only additional condition is that the product ID must be unique across the collection. Often the product LID is set to be the same as the data file name without the extension. See section 4.5 below for examples of RISE data product LIDs.
Product Version IDs consist of major and minor components separated by a “.” (M.n). Both components of the VID are integer values. The major component is initialized to a value of “1”, and the minor component is initialized to a value of “0”. The minor component resets to “0” when the major component is incremented. The PDS Standards Reference [1] specifies rules for incrementing major and minor components.
RISE files are named per the following convention. In the table below, yyyy, ddd, and hhmm indicates the four-digit starting year, three-digit starting day of year, and four-digit starting time in HHMM format; successive yyyy and ddd indicates the four-digit ending year and three-digit ending day of year; ss indicates the two-digit DSN station (if more than one DSN station is in the file, mm will be written for multiple DSN station); and vv indicates the major version, e.g. v1.
Table 12: RISE data product naming convention
|
Data Product Type |
Naming Convention |
|
TRK 2-34 Tracking and Navigation Files |
nsyt_maro_yyyy_ddd_hhmmssvv.tnf |
|
Weather/Surface Meteorology |
nsyt_maro_yyyy_ddd_yyyy_ddd_ss.wea |
|
Troposphere Calibration Files |
nsyt_maro_yyyy_ddd_yyyy_ddd_tro.csp |
|
Ionosphere Calibration Files |
nsyt_maro_yyyy_ddd_yyyy_ddd_ion.csp |
The highest level of organization for a PDS archive is the bundle. A bundle is a set of one or more related collections which may be of different types. A collection is a set of one or more related basic products which are all of the same type. Bundles and collections are logical structures, not necessarily tied to any physical directory structure or organization.
The complete InSight RISE archive is organized into the bundles described in Table 13. This SIS addresses only the Raw Data Bundle.
Table 13: RISE Bundles
|
Bundle Logical Identifier |
PDS4 Processing Level |
Description |
|
urn:nasa:pds:insight_rise_raw |
Raw |
RISE Raw Data Bundle |
|
urn:nasa:pds:insight_rise_derived |
Derived |
RISE Derived Data Bundle |
Collections consist of basic products all of the same type. The RISE Raw Data Bundle contains the collections listed in Table 14. These are described in section 4.5.
Table 14: Collections in the RISE Raw Data Bundle
|
Collection Logical Identifier |
Collection Type |
Description |
|
urn:nasa:pds:insight_rise_raw:trk234_trknav |
Data |
TRK 2-34 Tracking and Navigation Data File (TNF) |
|
urn:nasa:pds:insight_rise_raw:trk223_ionosphere |
Data |
TRK 2-23 Media Calibration Interface Files, Ionosphere |
|
urn:nasa:pds:insight_rise_raw:trk223_troposphere |
Data |
TRK 2-23 Media Calibration Interface Files, Troposphere |
|
urn:nasa:pds:insight_rise_raw:trk224_weather |
Data |
DSN Weather Files |
|
urn:nasa:pds:insight_documents:document_rise |
Documents |
Documentation in support of the data contained in the insight_rise_raw bundle |
A PDS product consists of one or more data objects and an accompanying PDS label file. PDS labels provide identification and description information for labeled objects. The PDS label includes a Logical Identifier (LID) by which any PDS labeled product is uniquely identified throughout all PDS archives. PDS4 labels are XML-formatted ASCII files.
The tables below give examples of LIDs for data products in the RISE collections.
The following table gives examples of LIDs for raw data. The LID for a raw data product is formed by appending the file name, without its extension, to the collection LID.
Table 15: Examples of RISE Raw Data LIDs
|
Data Product Type |
Example LID |
|
TRK 2-34 Tracking and Navigation File |
urn:nasa:pds:insight_rise_raw:trk234_trknav:nsyt_maro_2008_015_1541xmmv1 |
|
TRK 2-23 Troposphere Calibration File |
urn:nasa:pds:insight_rise_raw:trk223_troposphere:nsyt_maro_2008_001_2008_032 |
|
TRK 2-23 Ionosphere Calibration File |
urn:nasa:pds:insight_rise_raw:trk223_ionosphere:nsyt_maro_2008_001_2008_032 |
|
DSN Weather File |
urn:nasa:pds:insight_rise_raw:trk224_weather:nsyt_maro_2008_001_2008_366_10 |
Documents are also considered products by PDS, and have LIDs, VIDs and PDS4 labels just as data products do. The InSight archives include an InSight Document Bundle, which consists of collections of documents relevant to the mission itself and all the science experiments. The RISE Team is responsible for the RISE document collection in this bundle.
Table 16: Collections in the InSight Document Bundle
|
Collection Logical Identifier |
Description |
|
urn:nasa:pds:insight_documents:document_mission |
InSight mission, spacecraft and lander descriptions |
|
urn:nasa:pds:insight_documents:document_apss |
APSS SIS, instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_camera |
Camera SIS, instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_hp3rad |
HP3/RAD SIS, instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_ida |
IDA SIS, instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_mag |
MAG SIS, instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_rise |
RISE SIS (this document), instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_seis |
SEIS SIS, instrument description, and other relevant documents |
|
urn:nasa:pds:insight_documents:document_spice |
SPICE relevant documents |
Documents in the InSight Document Collections are assigned LIDs based on file names such that they are unique identifiers.
Data that comprise the RISE raw data archive are formatted in accordance with PDS specifications (see Applicable Documents [1], [2] and [3]). This section provides details on the formats used for each of the products included in the archive.
This section describes the format and record structure of each of the data file types.
Full documentation of the TRK 2-34 file is provided in PDF/A format in the documents collection in the RISE raw data archive under the name “TRK-2-34-REVN-L5_TNF.PDF”. This is an official DSN document with the name “TRK 2-34 DSN Tracking System Data Archival Format”. This document is one of several in the DSN 820-013 collection. A summary of the contents is given below.
TRK 2-34 files are binary files in a Standard Formatted Data Unit (SFDU) format. There are 18 possible record types in a TRK 2-34 file, distinguished by a unique Format Code in the Primary CHDO.
Table 17: Record types contained in a TRK 2-34 file
|
Format Code |
Secondary CHDO Type |
Description |
SFDU Length (bytes) |
|
0 |
Uplink |
Uplink Carrier Phase |
162 |
|
1 |
Downlink |
Downlink Carrier Phase |
358 |
|
2 |
Uplink |
Uplink Sequential Ranging Phase |
194 |
|
3 |
Downlink |
Downlink Sequential Ranging Phase |
304 |
|
4 |
Uplink |
Uplink PN Ranging Phase |
276 |
|
5 |
Downlink |
Downlink PN Ranging Phase |
388 |
|
6 |
Derived |
Doppler Count |
200 |
|
7 |
Derived |
Sequential Range |
330 |
|
8 |
Derived |
Angles |
178 |
|
9 |
Derived |
Ramp Frequency |
124 |
|
10 |
Interferometric |
VLBI |
204 |
|
11 |
Derived |
DRVID |
182 |
|
12 |
Filtered |
Smoothed Noise |
164 |
|
13 |
Filtered |
Allan Deviation |
160 |
|
14 |
Derived |
PN Range |
348 |
|
15 |
Derived |
Tone Range |
194 |
|
16 |
Derived |
Carrier Frequency Observable |
182 + 18*n |
|
17 |
Derived |
Total Count Phase Observable |
194 + 22*n |
Each SFDU is organized as illustrated in Figure 4. Only one of the 18 possible content blocks (the last element in the tree) in shown will appear in any given SFDU. Only its parent Secondary CHDO will appear before it in the SFDU.
Figure 4: TRK 2-34 SFDU format
Due to the complexity of the file, the detailed TRK 2-34 format is not given here; see [6] included in the documents collection of the RISE raw data bundle.
A typical RISE TRK 2-34 file should contain the following data types:
· Uplink carrier phase (Format code 00)
· Downlink carrier phase (Format code 01)
· Ramp (Format code 09)
· Doppler count (Format code 06)
· Carrier frequency observable (Format code 16)
· Total count phase observable (Format code 17)
Note that Format codes 16 and 17 can be variable in length. For RISE, they are fixed with one observation (n=1) per SFDU. Additional data types may be present depending on the configuration of the DSN during the RISE pass.
Troposphere and Ionosphere files are plain-text ASCII stream files containing adjustments that should be made to the tracking data. These calibrations are provided as CSP (Control Statement Processor) “cards.” Each file is updated every several days and spans one-month, including both reconstruction and prediction if the release data is in the middle of the month. The file format and how to read CSP cards are described in “TRK-2-23-REVC-L5_ION_TRO.PDF”, provided in the documents collection in this archive with the name “TRK 2-23 Media Calibration Interface” [7].
These files are labeled as Product_Ancillary files [2], [3]. Multiple TRK 2-34 Tracking Data Files may be calibrated by a single TRK 2-23 file.
DSN Weather files are plain-text ASCII tables and are generated in near-real time from station monitoring data. Meteorology points are stored in the table every hour. One file is produced per year and continually updated every few days. The DSN weather file is reformatted from the original format into tabular format to be PDS4-compliant. The original file format is described in “TRK 2-24 DSN Tracking System Interfaces: Weather Data Interface”, provided in the DOCUMENT directory in this archive with the name “TRK-2-24-REVA-L5_WEA.PDF” [8].
The DSN Weather file included in the RISE raw data archive is reformatted from the original TRK 2-24 format into tabular format for archival purposes. The plain-text ASCII table has fixed-width records with nine right-justified fields. Each record is terminated with a carriage-return new-line. The record structure is specified as follows:
Table 18: Format of the weather data file
|
Field Number |
Description |
Number Format |
Start Byte |
End Byte |
|
1 |
DSN Complex ID 10 = Goldstone DSCC 40 = Canberra DSCC 60 = Madrid DSCC |
Integer |
1 |
10 |
|
2 |
Calendar year |
Integer |
11 |
20 |
|
3 |
Day of year |
Integer |
21 |
30 |
|
4 |
Time of day, in HHMM format |
Integer |
31 |
40 |
|
5 |
Dew Point Temperature, in Celsius |
Float |
41 |
50 |
|
6 |
Surface Air Temperature, in Celsius |
Float |
51 |
60 |
|
7 |
Surface pressure, in millibars |
Float |
61 |
70 |
|
8 |
Water partial pressure, in millibars |
Float |
71 |
80 |
|
9 |
Percent relative humidity |
Integer |
81 |
90 |
Documents in this archive are provided as PDF/A (www.pdfa.org/download/pdfa-in-a-nutshell) or as plain ASCII text if no special formatting is required.
Each RISE product is accompanied by a PDS4 label. PDS4 labels are ASCII text files written in the eXtensible Markup Language (XML). Product labels are detached from the files they describe (with the exception of the Product_Bundle label). There is one label for every product. A product, however, may consist of one or more data objects. The data objects of a given product may all reside in a single file, or they may be stored in multiple files, in which case the PDS4 label points to all the files. A PDS4 label file usually has the same name as the data product it describes, but always with the extension “.xml”.
Documents are also considered to be products; they have PDS4 labels just as other products do.
For the InSight mission, the structure and content of PDS labels will conform to the PDS master schema and Schematron files based upon the PDS Information Model [3]. By use of an XML editor the schema and Schematron files may be used to validate the structure and content of the product labels. In brief, the schema is the XML model that PDS4 labels must follow, and the Schematron files are a set of validation rules that are applied to PDS4 labels.
The PDS master schema and Schematron files documents are produced, managed, and supplied to InSight by the PDS. In addition to these documents, the InSight mission has produced additional XML schemas and Schematron files which govern the products in this archive. These documents contain attribute and parameter definitions specific to the InSight mission. A list of the XML documents associated with this archive is provided at http://pds.nasa.gov/pds4/schema/released/.
This work was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.
Copyright 2017 California Institute of Technology. U.S. Government sponsorship acknowledged.
Appendix A Support staff and cognizant persons
Table 19: Archive support staff
|
RISE Team |
||
|
Name |
Affiliation |
|
|
Dustin R. Buccino |
JPL |
<EMAIL_ADDRESS>|
|
Sami W. Asmar |
JPL |
<EMAIL_ADDRESS>|
|
William M. Folkner |
JPL |
<EMAIL_ADDRESS>|
|
|
|
|
|
PDS Geosciences Node |
||
|
Name |
Affiliation |
|
|
Raymond Arvidson |
Washington University |
<EMAIL_ADDRESS>|
|
Edward Guinness |
Washington University |
<EMAIL_ADDRESS>|
|
Susan Slavney |
Washington University |
<EMAIL_ADDRESS>|


Marc Mimram: Structure | Light: Landscapes of Gravity through the Lens of Erieta Attali
- about 21 hours
Description via Amazon. Marc Mimram ( born 1955), the award-winning French architect and engineer, presents his work of architecture and structure through the lens of Erieta Attali (born 1966), world-renowned architectural photographer, who explores the relationship between human-made structures and the landscape.Architecture is often represented as a product or disembodied object. This view transforms inhabitants into spectators of an architecture that is dematerialized, delocalized, dehumanized and reduced into an image of itself. The collaboration between Mimram and Attali aims for an all-encompassing approach, placing the architecture within its time-frame and physical environment, rather than presenting mere glossy images of the projects.
This three-volume publication builds a new visual vocabulary through which to interpret the structures. The social functionality of public architecture is addressed, largely absent in architectural photography and the communication of built space until now. The first volume focuses on a two-year photographic documentation of the construction of the Airtime building in Paris. The second volume presents an overview of Mimram’s works around the world: bridges, train stations and academic institutions from France to Morocco and China. The third volume focuses on the newly redesigned venue for the French Open, Roland-Garros. With texts by Marc Mimram, Erieta Attali, Ariel Genadt, Jean Attali, Paul Chemetov, Zvi Hecker and Sir Peter Cook.
- ISBN —<PHONE_NUMBER>034
- Title — Marc Mimram: Structure | Light: Landscapes of Gravity through the Lens of Erieta Attali
- Author — Marc Mimram, Erieta Attali
- Publisher — Hatje Cantz
- Publication year — 2019
- Binding — Hardcover
- Language — English
Marc Mimram: Structure | Light: Landscapes of Gravity through the Lens of Erieta Attali Buy now Buy from amazon.com


{% include 'header.html' %}
GO terms
{% include 'signatures/selector.html' %}
Aspects
Biological Process
Molecular Function
Cellular Component
QuickGO
QuickGO


Qualitative Research
Endorsed by Andrew Kakabadse, who is highly skilled at this
Endorsed by 2 of Phillipa’s colleagues at Work Psychology Group
Psychometrics
Endorsed by Dr Anna Koczwara and 2 others who are highly skilled at this
Organizational Development
Endorsed by Michelle Penelope King, who is highly skilled at this
Psychology
Change Management
Assessment Center
Research
Consulting
Psychological Assessment
Mental Health
SPSS
Culture Change
Leadership Development
Management
Job Analysis
Workshop Facilitation


Add, Update and Delete Admin
Add, Update and Delete Manufacturer
Add, Update and Delete Distributor
Add, Update and Delete Retailer


Thank you for sharing your opinion with us.
What is your highest degree or level of school completed?
Do you believe that the coronavirus exists?
Do you wear a face mask to prevent a potential spread of the virus and to protect others?
Do you know directly someone who caught the coronavirus?
Would you agree to get regularly tested in order to flatten the curve (until the vaccine arrives)?
Will you get vaccinated against the coronavirus?
Are you at increased risk for severe illnes that could be caused by the coronavirus (do you have any underlying condition)?
Do you travel regularly? Please check all that apply.
Comments


Pico-8
Pico-8 is a fantasy console. But on our computers it’s real and is super cool.
Beast
- 128x128 16 colours
- 128 8x8 sprites
- 32k
- 4 channel chip blerps
Projects
Here are few side projects free to download and use. Make awesome game on those sprites!
Download images and load them in Pico-8 emulator.
Cartridges
Codename Dream
Free game engine / Tileset
Happy Little Island
Happy island full of life
Redhood
Hangover Game Jam game
GrassLand
Free tileset
Infinite
Free tileset
CPULand
Free tileset


Tutorials¶
This section presents some tutorials illustrating the process of creating standalone and template-based symbolic models.
The figure below shows a high-level activity diagram of a typical usage flow of the uraeus framework, where we have three swim-lanes representing a main layer of the three activity layers of the framework.
Here we are concerned with the first swim-lane that represents the symbolic environment layer and the symbolic model creation activity.
Symboilc Models¶
The uraeus.smbd python package provides two main types of symbolic models to be constructed, standalone models, and template-based models.
Standalone models stands for symbolic models that are fully described in one topology graph, where all the bodies and connections are already defined in the model graph, and therefore, the model is fully independent and does not need any other topological information.
Template-based models, on the other hand, are not fully described in one topology, as they need to be assembled with other templates to form a complete assembled topology. For example, this is the case for creating a full vehicle assembly, where we model the vehicle subsystems as templates, then we assemble them together to form the desired vehicle assembly.
The creation of template-based models’ database can be found in uraeus.fsae, which is an under-development multi-body systems database for formula-style vehicles implemented in the uraeus framework.


Callum Smith retains WBA super-middleweight title after testing battle
Londoner John Ryder was a big outsider but won many fans with his performance.
Callum Smith survived a stringent examination against John Ryder to hold onto his WBA super-middleweight title at the M&S Bank Arena in Liverpool.
Smith, a 20-1 on favourite at the first bell, had some anxious moments and was cut badly around the right eye, but took the decision 117-111, 116-112, 116-112 on the judges’ scorecards.
Ryder never took a backward step and the decision was met with some derision among the crowd.
“I didn’t underestimate John in training,” Smith told Sky Sports Main Event.
“I knew he was a tough fighter and it was going to be that type of fight, that he was going to get really close and stop me from what I’m good at.
“It wasn’t the best performance but I thought I won.
“He worked hard at the end, but I was due a bad one. It’s the first time I’ve been cut in a fight and I’ll be a better boxer because of it.”
It wasn't the best performance but I thought I won.Callum Smith
Ryder has been a notoriously slow starter during his career, but the 31-year-old Londoner began in confident fashion and possibly shaded the opening two rounds.
Smith’s usual snap in his punching was lacking and he struggled to make his significant reach advantage count against the compact Ryder.
But Smith launched a flurry of punches at the end of the fifth round, and noticeably had more success when he increased the distance between the two men.
There was a nasty clash of heads in the eighth and Smith was clearly upset by another collision in the ninth as he protested to the referee.
Ryder had Smith wobbling in the 11th round with a left hook as he sought to finish the fight.
But Smith held on and was relieved to hear the final bell and to keep hold of his world belt.


- play() - Method in class productionproject.AudioPlayer
-
- play() - Method in class productionproject.MoviePlayer
-
- play() - Method in interface productionproject.MultimediaControl
-
- populateList() - Method in class productionproject.Controller
-
This method populate list is currently an empty method that will be used populate information
from the database.
- previous() - Method in class productionproject.AudioPlayer
-
- previous() - Method in class productionproject.MoviePlayer
-
- previous() - Method in interface productionproject.MultimediaControl
-
- Product - Class in productionproject
-
This controller document has the contains the product class for the Production Project2 GUI
project.
- Product(String, String, ItemType) - Constructor for class productionproject.Product
-
Product constructor holds a String of type name and manufacturer and a Item type called type.
- Product(int, String, String, ItemType) - Constructor for class productionproject.Product
-
Created a new constructor that also holds a id parameter for future use.
- productionAreaLog() - Method in class productionproject.Controller
-
This will be a new method that updates the text area with the production record log.
- productionLog() - Method in class productionproject.Controller
-
This method prints the Production log info to the console.
- productionproject - package productionproject
-
- ProductionRecord - Class in productionproject
-
This document has the contains the production record information for the Production Project2 GUI
project.
- ProductionRecord(Product, int) - Constructor for class productionproject.ProductionRecord
-
This method contains the fields used to increment the number of items for the serial number.
- ProductionRecord(int, Product, int) - Constructor for class productionproject.ProductionRecord
-
Production record field that contains the fields used to increment the number of items for the
serial number.


Traditionally, a ‘community animator’ is a person that connects people looking for partners on community conversations and projects. The app works much like a dating app. Instead of matching people who want a date, it connects people who want to come together to do something for their community.
Community Animator is currently being developed by The Center for Human-Computer Interaction at Penn State.


Chapter 15
Basic site
Testing enhance.js
Starting to build the home page with Foundation
The slideshow
Adding the blog section
Adding less.js
The header and the footer
The on-canvas menu: refurbishing the menu
Adding the history fix
The off-canvas menu
Putting it all together


Basic Linux Commands
- pwd- To know the directory/absolute path of where you are currently
- ls- To see files in current directory, to see list of all the files use
ls -a
- cd - To go into a directory. e.g.,
cd documents
andcd..
to go back a folder - mkdir & rmdir- Use
mkdir "foldername"
to creat a new filer andrm dir "foldername"
to delete a folder - touch "filename.extension"- To create a new file in your current directory
- cp- To copy files from current directory to the desired directory. For example,
cp "filename.ext" /home/documents/tutorial
- echo- It helps to move some data, usually text into a file. For example,if you want to create a
new text file or add to an already made text file, you just need to type in,
echo testing, 123 >> newfile.txt
- sudo- stands for "SuperUser Do". So, if you want any command to be done with administrative or root privileges
- cat- Use the cat command to display the contents of a file
- apt-get- Use apt to work with packages in the Linux command line. Use apt-get to install packages
- clear-To clear the terminal if it gets filled up with too many commands
Users can use the following to log into an already created docker container
$docker exec -it "container name" /bin/bash


Main Page
Classes
Files
Class List
Class Index
Class Hierarchy
Class Members
Class List
Here are the classes, structs, unions and interfaces with brief descriptions:
pluma::Host
Manages providers
pluma::PluginManager
Manages loaded plugins
pluma::Pluma
Pluma
plugins management
pluma::Provider
Interface to provide applications with objects from plugins
:: Copyright © 2011 Gil Costa, all rights reserved :: Documentation generated by
doxygen 1.7.4
::


Quick and easy ideas from ECHO readers inspired by Elf on the Shelf 29 Nov 2019, 11:32 by Gemma Jaleel Kate Hollingsworth: Nice game of hungry hippo1 of 58 Pandy Nicholas's elf is a cel-elf-rity -- get hom outta there!2 of 58 Pandy Nicholas: Elfis and Sooty have a snowball fight3 of 58 Kate Hollingsworth: Spuddy the Elf must of done something to upset Buzz4 of 58 Someone got their own back! Sent in by Pandy Nicholas.5 of 58 Kate Hollingsworth's daughter's tree was ruined by the Elf6 of 58 Alexa Crilly says that Buzz and Woody have sorted their elf out7 of 58 Kelly Johnston: Apparently Chippey fancied a swim8 of 58 Kelly Johnston's elf is enjoying a nice game of snooker.9 of 58 Stacy Alderson: Eric, my nephew's elf, got into his dad's beer and kebab10 of 58 Pandy Nicholas's elf reckons its payback time!11 of 58 Pandy Nicholas's elf is fewmin, we don't blame him, that's a lot of curlers!12 of 58 Pandy Nicholas's elf is clearly looking forward to the new Star Wars movie13 of 58 Pandy Nicholas's elf is a chef in disguise14 of 58 Kelly Gemmell Hardiman's elf looks like he might be a bit drunk15 of 58 Kelsy O'Rourke's elves stole the Nutella!16 of 58 But clearly he didn't learn anything! (Photo by Kelly Gemmell Hardiman)17 of 58 Kelly Gemmell Hardiman's elf is paying for his mischief18 of 58 Kelly Gemmell Hardiman's elf has also been at the marker pens!19 of 58 Annie Ruddy says that apparently the elf kept Jacob on his toes searching for him!20 of 58 Dawn McCutcheon: Look who we found hiding in a chocolate santa21 of 58 Kate Brandon: Ours was caught red handed making a mess this morning!22 of 58 Annie Ruddy: Our elf has been very busy!23 of 58 Dawn McCutcheon's elf needs help!24 of 58 Jenny Harrison: Not always naughty, having a tea party with his friends!25 of 58 Of course you realise, this means war! Photo by Stacey Brunnix26 of 58 Sam Sephton's elf has truly TPed this tree!27 of 58 Jenny Harrison: Louis wrapped some presents including a smelly sock and a shoe28 of 58 Stacey Brunnix's elf is having a casual game of bowling29 of 58 Mutiny! Stacey Brunnix's elf is in a bit of a fix30 of 58 Who needs snow when you have toilet paper and a flight of stairs? (Photo by Stacey Brunnix)31 of 58 Stacey Brunnix's elf has gone fishing32 of 58 Joanne McKevitt's elf made his own minions33 of 58 Sharon Pollard's elf clearly thought this tree could be better decorated34 of 58 Sharon Pollard: My cousin's little girl's elf has been up to all sorts35 of 58 Toasting marshmallows - he's getting smart36 of 58 "You're a wizard, elfie!" Looks like there's magic as well as michief in this picture by Margie Lavelle37 of 58 This naughty elf has been doodling! Sent by Kirsty Moore38 of 58 Kirsty Moore's elf is up to no good39 of 58 Elf on the Shelf picture sent in via Facebook by Kirsty Moore40 of 58 These two seem hungry - picture from Sharon Thomas on Twitter41 of 58 This elf is playing around - picture from Eliza Willis on Twitter42 of 58 Now that's just messy!43 of 58 Elf on a zip wire from Diane Worswick via Facebook44 of 58 From Samantha Roberts via Facebook45 of 58 Samantha Roberts's elves are making snow elves46 of 58 From Samantha Roberts via Facebook47 of 58 Sent in by Danielle Lamont, via Facebook48 of 58 Sent in by Danielle Lamont, via Facebook, who said: "Our elf has caught chicken pox off my boys."49 of 58 Sent in by Danielle Lamont, via Facebook50 of 58 Vicky Brandon, of Bromborough, sent in this picture of Bella, aged four's elf and said: "Buddy is a very cheeky little elf, loves building snowmen."51 of 58 "Thinking she's Miley Cyrus in a wrecking ball", said Claire Weston, who submitted this picture via Facebook52 of 58 Sent in via Facebook by Kirsty Moore53 of 58 Kirsty Moore's elf is ready for bathtime54 of 58 Sent in by Danielle Lamont, via Facebook55 of 58 Sent in by Natalie Harding via Facebook56 of 58 Posted by Jennifer Robinson, via Facebook57 of 58 Sonia Louise Burns's elfie has been causing mischief in their home58 of 58


Distributed Data Placement
A key aspect of distributed performance and functionality lies in the application of proper data placement techniques. To perform proper data placement, you should understand the manner in which each piece of data is accessed within the distributed environment. Analyzing which application or program accesses the data is not sufficient. Analyzing is merely one portion of the distributed data placement puzzle. You also need to analyze and understand the access patterns from each location on the network.
Normal data placement revolves around a single subsystem. The access patterns of programs and applications are recorded; based on that information, portions of the data are placed on DASD devices. Access-based data placement still must be done in the distributed environment. However, location access patterns must be analyzed also. Based on these patterns, portions of data can be placed at the appropriate locations within the distributed network.
The primary goal of distributed data placement is to optimize performance by reducing network transmission costs. Each piece of data should be stored at the location that accesses it most frequently. For example, storing Pittsburgh data at the Pittsburgh server makes more sense than storing it at the Chicago server. Such decisions are easy to make. Problems arise when
If the location does not have a server, place the data to the closest location on the network. For example, Pittsburgh data would be better stored in Cleveland than in Chicago, because Cleveland is physically closer to Pittsburgh than Chicago. For scenarios too close to call, the best approach is to choose a location and monitor performance. If performance is not up to par, consider migrating the data to another location.
|


Using the definition of a division function by bounded recursion given by the following text :
Require Export Arith. Fixpoint bdiv_aux (b m n:nat) {struct b} : nat * nat := match b with | O => (0, 0) | S b' => match le_gt_dec n m with | left H => match bdiv_aux b' (m - n) n with | (q, r) => (S q, r) end | right H => (0, m) end end.
Prove the following property:
bdiv_aux_correct2 : forall b m n:nat, m <= b -> 0 < n -> snd (bdiv_aux b m n) < n.


Admission Orders
Admission Orders
General Left
General Right
Admission Orders
General heading
- Core Orders...
- Bladder Management...
- Bowel Management...
- Respiratory...
- Medications...
- Consults...
- Laboratory...
- Imaging...
- Wound Admission...
Core Orders
Core
- Admission Orders (MRSA, NPO)
- Primary Diagnosis
- Condition: stable
- Vitals Q12Hrs
- Vitals orthostatic x2 sets
- Notify provider if SBP>180 mmHg or <80 mmHg,,
DBP>100mmHg or <60 mmHg, HR > 110bpm or T>38.3C
- EKG
- DVT prophylaxis
- Code status
- Turns q 2 hours while in bed (advance per RN protocol)
- Full pressure relief q15min when sitting up > 30 deg (e.g. in wheelchair
- Autonomic Dysreflexia risk Alert - follow protocol
- Activity
- Bed rest (flat protocol) completely flat
with no reverse Trendelenburg positioning
- Timed sitting q _ hours
- Activity per nursing/PT/OT evaluations
- Specific Mobility Restriction
- Diets/NPO/Tubefeeding
Bladder Management
Nursing Text Orders
- Foley
- Suprapubic Tube
- Intermittent Cath q4h - follow Nursing protocol
- Void attempts, bladder scans and intermittent cath prn for retention > 250 mL - Nursing protocol
Anticholinergics
- Oxybutynin SA (Ditropan XL) 10 mg po qhs
- Trospium (Sanctura) 20 mg po BID
- solifenacin (Vesicare) requires PADR
Alpha antagonist
- Tamsulosin (Flomax) 0.4mg po daily
Beta agonist
- mirabegron (Myrbetriq) 25mg po daily
- Non-formulary drug request (PADR)
Anesthestics
- Lidocaine 2% gel topically to urethra prn for painful catheterization
- Lidocaine 2% solution prn instill 5 mL in bladder via suprapubic tube before suprapubic tube change to prevent autonomic dysreflexia
Bowel Management
Bowel Program
- Digital stimulation - AM
- Digital stimulation - PM
- In seated position if/when able to tolerate
- Manual disimpaction - AM
- Manual disimpaction - PM
Oral Medications
- Docusate 100 mg bid
- Senna 8.6 mg daily with lunch (for PM bowel program)
- Senna 8.6 mg qhs (for AM bowel program)
- Bisacodyl 5mg tab daily with lunch
- Bisacodyl 5mg tab qhs
- Milk of magnesia daily with lunch
- Milk of magnesia qhs
- Polyethylene glycol (Miralax) 1 packet daily
- Psyllium 1 packet daily
- Fibercon 625 mg bid
Rectal Medications
- Magic bullet with bowel program
- Enemeez with bowel program
- Enemeez plus PR with bowel program
- Dibucaine 1% ointment PRN for painful bowel program or autonomic dysreflexia with bowel program
- Lidocaine 2% ointment rectally prn for painful bowel program or autonomic dysreflexia with bowel program
- Preparation H top bid prn
- Preparation H supp QID prn
Devices
Consults
SCI/D Service
- Physical Therapy
- Occupational Therapy
- Speech & Language Pathology Inpatient
- Respiratory Therapy
- Telehealth
- Psychology
- Recreation Therapy
- Wound Care
- SCI/D Center
Other Departments
- Pulmonary
- Infectious disease
- Neurology
- Palliative Care
- Plastic Surgery
- Orthopedic Surgery
- Interventional Radiology
- Urology
Medications
Pain
- Acetaminophen 1000 mg tid prn
- Acetaminophen 650mg q6h prn
- lidocaine 5% topical tid prn
- Icy Hot q6h prn
- capsaicin 0.25% top tid prn
- diclofenac 1% top 4g tid prn
Sleep
- trazodone 50 mg qhs prn
- melatonin 3 mg qhs prn
- diphenhydramine 50 mg qhs prn
- zolpidem 5 mg qhs prn
Nausea/GI
- calcium carbonate prn
- ondansetron 4 mg q6h prn
Blood Pressure
- midodrine 10mg 0800-1300
- fludrocortisone 0.1mg daily
- pseudoephedrine 60 mg qid
- neosynephrine 1-2 drops q3h prn each nare
Respiratory
- Respiratory Therapy Consult
- ABG
- FVC
- NIF/MIP
- Albuterol MDI 90 mcg, 2 puffs q 4 hours prn shortness of breath
- Albuterol 2.5 mg/3 mL nebulizer, 2.5 mg q 4 hours prn shortness of breath
- Combivent inhaler q 6 hours prn shortness of breath
- guaifenesin 200mg q4h prn
- Cough assist
- Percussive therapy
Laboratory
- CBC with or without diff
- Basic metabolic panel
- Comprehensive metabolic panel
- Cystatin C
- Magnesium
- Phosphorous
- Prealbumin
- Vitamin D level
- PT/INR, PTT
- TSH
- A1c
- CRP
- ESR
- Lipid panel
Imaging
- Chest x-ray +/- confirm PICC placement
- KUB +/- confirm feeding tube placement
- KUB constipation in the setting of neurogenic bowel
- PA/Lateral cervical spine
- PA/Lateral thoracic spine
- PA/Lateral lumbar spine
- Bilateral lower limb ultrasound
- Renal/Bladder ultrasounds
- MRI C-Spine
- MRI T-Spine
- MRI L-Spine
- MRI Pelvis w/wo
- Three phase bone scan
Pressure Injury Admission
Serum Labs
- Prealbumin
- CBC
- ESR
- CRP
- PT/INR
- Nicotine
- Hemoglobin A1C
- Vit. D
- Total Cholesterol
- CMP
- HCV
- HIV
Imaging
Consults
- Plastic Surgery
- Orthopedic Surgery
- Wound Care
- General Surgery
- Infectious Disease
- Nutrition
Bone Biopsy
- Interventional Radiology Order (for - for bone biopsy), placed as Imaging order not a Consult
- Culture: Tissue/Bone w/ Gram Stain
- Culture: Mycology (Tissue/Bone)
- Culture: Anaerobic Tissue/Bone
- AFB: Tissue/Bone


Island Grill Restaurant
Web Design & Development | Art Direction for Photoshoots
islandrestaurant.co.uk
Island Grill Restaurant | London
Viewfinder.photo
Web Design & Development | Art Direction for Photoshoots | Food Styling
viewfinder.photo
Viewfinder.photo | London
Royal Lancaster London
Marketing Strategy | Graphic Design | Email Marketing | Photography
Concept Creation | Creative Direction for Photoshoots
Royal Lancaster London Hotel | London


--- layout: page title: "students" description: "This is what I do." header-img: "img/mb-track.jpg" ---
See Mr. DeWitt's RMHS page


There is no strong relationship between latitude and wind speed. However, the data showned is that most of the cities have very high wind speeds.