Full screen

Server Notice:


Public Pad Latest text of pad szSyawATIq Saved April 22, 2012

Welcome to the ISSLive! Challenges Challenge! 
The ISSLive! project (“bringing the International Space Station to every generation”) is an exceptional example of NASA’s commitment to data and mission transparency in an interactive, participatory environment. Go here to visit ISSLive. The project offers 4 challenges to help it go to the next level. 
1) API: Help create a REST-based API that ties the existing 200 Telemetry values (space station system parameters) and XML crew timeline data (what the astronauts do onboard the station) for web based access  here so that it is easily usable for outside of NASA developers. In addition to the API itself, developers will build and document a small, simple sample app that utilizes this API and present a step-by-step tutorial on how it was built. Developers could take this further to create a REST-style Web based Application Programming interface (API) for Space Station Data and Astronaut timelines. This sample app could be small and simple or as creative as the students can make it. There is a lot of potential here, depending on participants’ initiative. For example someone could tie the crew activities in our XML timeline to a social media platform app, or build a small mobile app that indicates space station orientation, etc.  
2) Mobile Operations: Build a simple mobile app that takes some of the ISSLive values and presents in them in straightforward operational perspective. The app would tie into existing ISSLive data and utilize mobile app web-based development frameworks to work on latest devices. For example, develop a way for to see Station Communication status (KU & S Band) and communication pass information next to upcoming crew and ground activity times in the XML timeline.
3) Limit Notification System: Use the ISSLive! API to develop an application to send notifications and/or write a log entry when a telemetry value matches or exceeds a user defined limit.  For instance if the user wants to be notified whenever the partial pressure of CO2 on the Station exceeds 180 mmHg, the user creates a rule and the application listens to the ISSLive! telemetry feed waiting for that condition to be true.  When it happens the application issues a notification. 
4) Telemetry Tracking System: Use the ISSLive! API to build a graphing and trend-finding application.  The application should listen to ISSLive! provided telemetry from the Space Station and produce a graph of the last ‘X’ values (X is user defined).  The user should be able to apply various trend-finding algorithms to predict future values (basically fit a variety of functions to the data).  The calculation of confidence levels, predicted time to a limit, and handling of LOS (loss of signal and therefore no data) periods are all encouraged. 
How to connect a WEB page to a Lightstreamer push server:
The first step is identifying the ISS Live Public Data Symbol that will be subscribed for the ISS Live data source. Once that has been established a javascript array of variables will be used to list the group of symbols. Additionally, since a data symbol can be used more than once on a web page, a count of the symbols will be required. So what we have at this point is a java script array of symbols and a hash table that uses the symbol names as the key to keep track of the number of symbols on the page.
        var group = new Array();
        group[0] = "MYWEBPAGE";
        group[1] = "MYWEBPAGE.TIME_000001";
        group[2] = "MYWEBPAGE.P1000001";
        var symbolList = new Object();
        symbolList["TIME_000001"] = "TIME_000001+1";
        symbolList["P1000001"] = "P1000001+1";
What should be noted is that the first entry in the “group” array identifies the “listener” that Lightstreamer will broadcast to. In the typical Lightstreamer setup, as demonstrated by Lightstreamer, they would use the symbol itself as the “listener”. The side effect of this approach is each symbol will be updated at slightly varying rates causing a Christmas tree blinking effect. To circumvent this effect, a single “listener” is established, causing the display to update in unison. The Lightstreamer data adapter looks for a subscription request that has a single entry and uses this entry as the “listener” name to broadcast to. In addition to the single entry, the double “dot” entry is used to discern between the “listener” and a “subscription” request. (I’m currently working on a version that will eliminate the first entry requirement and just use the double “dot” nomenclature.)
The second part of the setup requires establishing the actual connection to the Lightstreamer server.
        var pushPage = new PushPage();
        pushPage.context.setDebugAlertsOnClientError(true); // (false=production)
        pushPage.context.setDomain("nasa.gov"); // domain=web, mycompany.com
        pushPage.onEngineCreation = function(lsEngine) {
            lsEngine.connection.setLSPort("80"); // production port=80
        pushPage.createEngine("ISSWeb", "http://spacestationlive.jsc.nasa.gov/js/lib/ls", "SHARE_SESSION");
        // this table has the symbols for subscription
        var schema = ["message", "timestamp"];
        // the group arg is injected into the page by the code-behind
        var nonVisualTable = new NonVisualTable(group, schema, "MERGE");
        pushPage.addTable(nonVisualTable, "MyHiddenTable");
        // this table has the keyword for updating the page
        var pushtable = new OverwriteTable(null, null, "MERGE");
        pushPage.addTable(pushtable, "MyTable");
The PushPage establishes the connection with the Lightstreamer server.  In production the Lightstreamer server pushes on port 80. If the Lightstreamer server and WEB server live on the same physical box, then Lightstreamer must be setup to push on a different port. This parameter is located in the “lightstreamer_conf.xml” file. For localhost testing, the DNS entries can be added to the hosts file.
The final piece to this solution involves hooking up the Lightstreamer “onChangingValues” event handler.
        pushtable.onChangingValues = function (itemPos, updateInfo, itemName) {
            // process for this item group
            if (updateInfo !== null) {
                // our 'group' is created by the code-behind
                if (typeof (group) != "undefined") {
                    processGroup(group, updateInfo);
The “onChangingValues” function is a Lightstreamer provided API and is referenced by added the appropriate javascript files. These come with the distribution and are found in the installation folder, e.g. “installation folder for Lightstreamer\DOCS-SDKs\sdk_client_web\lib
<script type="text/javascript" language="javascript" src="http://spacestationlive.jsc.nasa.gov/js/lib/ls/lscommons.js"></script>
<script type="text/javascript" language="javascript" src="http://spacestationlive.jsc.nasa.gov/js/lib/ls/lspushpage.js"></script>
The “processGroup” is a javascript API developed while implementing the interface to Lightstreamer.  The MSK application environment includes a text file as input to the desktop client. For rendering purposes the MSK requires absolute coordinates and other very specific attributes in order to display the data. To support this functionality standard html “<div> or <span>” can be used with custom attributes to define a similar rendering capability.
<div title="TIME_000001"style="position: absolute; left: 150px; top: 40px;
white-space: nowrap; font-family: fixed; font-size: 12px; font-weight: Regular;"> 
<span id="TIME_000001" columns="12" format="%mT" formatType="sprintf" fgOn="Lime" bgOn="Black" fgOff="Cyan" bgOff="Black" screenFg="White" screenBg="Black" >
<span source="lightstreamer"table="MyTable"item="MYWEBPAGE"field="TIME_000001"></span> 
<!— display example for TIME_000001: 055/18:37:31 -->
<div title="P1000001"style="position: absolute; left: 150px; top: 40px;
<span id="P1000001" columns="12" format="%5.4f" formatType="sprintf" fgOn="Lime" bgOn="Black" fgOff="Cyan" bgOff="Black" screenFg="White" screenBg="Black" >
<span source="lightstreamer"table="MyTable"item="MYWEBPAGE"field="P1000001"></span> 
<!-- display example for P1000001: 3467.5525 -->
<div title="USLAB000001"style="position: absolute; left: 150px; top: 40px;
<span id="USLAB000001" columns="64" format="0=NOT IN USE|1=IN USE" formatType="enum"fgOn="Lime"bgOn="Black"fgOff="Cyan"bgOff="Black"screenFg="White"screenBg="Black"> 
<span source="lightstreamer"table="MyTable"item="MYWEBPAGE"field="USLAB000001"></span> 
<!-- display example for USLAB000001: IN USE -->
The above describes how this particular data symbol will be displayed. It provides a position attribute that specifies where the symbol will be placed within the browser’s viewable area. An alternative would be to place the symbol within a style sheet using CSS attributes.  At a minimum the “<span>” that defines lightstreamer as a source, is the Lightstreamer specific entry and is required. The item attribute will refer to the “listener” named discussed earlier and must match the “group” array entry name. The field must match the list of symbols given in the same “group” array. The table refers to the PushPage “addTable” entry. 
Again, in the example above this was used to implement a WEB based MSK web client application that could leverage the same attributes values found in an MSK display file. For ISSLive this probably will not be required, but it should be noted that the current Lightstreamer data adapter does perform calibration of the data. The raw value and calibrated value is sent across in a JSON string. The client can choose to use the calibrated value as is or format the data the way they want to see it. As can be seen in the above example the “format” is “%mT”, this follows the current MSK application format specification, which in this case is for a time. The “processGroup” function will take these attributes and process them based on the current MCC protocol for handling telemetry.  For instance when the data goes LOS (loss of signal), the symbol status will change to “static”, MCC application will turn all telemetry values to “cyan” and display the status symbol, which in this case will be “S”. To handle these different scenarios for ISS Live data source, a java script library was created and could be used.
<script type="text/javascript" language="javascript" src="Scripts/isp.js"></script>
This library provides the necessary support to emulate what an MCC application would do for the various ISS Live data (telemetry) scenarios and formats.
The current format of the JSON string that is sent across follows this format:
                // the JSON object currently (Nov. 2012) follows this pattern
                // {
                //    "Name": "the-symbol-name", // the name of the symbol
                //    "Status": {
                //        "Class": <some-status-value>, // the status value sent from ISS Live Data Source
                //        "Indicator": " ", // the indicator sent from ISS Live Data Source
                //        "Color": "White"  // the color sent from ISS Live Data Source
                //     },
                //     "Data": [
                //       {
                //           "Value": "some-string-double-value",
                //           "TimeStamp": “time-double-value” // the value's timestamp
                //       }
                //      ]
                //      “Calibrated-Value”: “formatted-value”, // calibrated value
                // }
It should be noted that the “Data” field can be an array of values. This would support multi-sample data, e.g. 30Hz data = up to 30 samples a second can be delivered each cycle. In most cases, only one sample is delivered. For multi-sample data, the end consumer must know what to do with the data, which is how to perform computational analysis of it. For ISSLive, the data is currently only displayed, so the first sample or the last may be adequate. For educational processing, the multi-sample data may be used. ISS Live data source typically delivers data on a cycle (heartbeat) which occurs every second. It’s during this cycle that the data adapter collects all the data that has changed (COD = change only data). This data is then sent to the Lightstreamer server which in turn broadcasts it to all clients. Currently only the raw data is sent which is a double value. For enumerated data, the value will be 0.0 or 1.0, etc… The data adapter today delivers a calibrated value, which means the client can elect to simply display this computed value or continue to perform their own formatting.  For instance for enumerated values, 0 can mean Disabled, while 1 could mean Enabled. Other enumerated data though may have several numeric values that have different meanings. So for enumerated data, the end user should be shown the English translation rather than the numeric value. For the raw numeric data, the value can very large. Typically the data will be formatted using a sprintf format specifier such as “%7.4f”. Other numeric data may just be an integer value that uses a sprintf format specifier like this, “%d”. So depending on the data and how it is used, the displaying of the data can vary. 
Relevant links and reminder of tags
  • Recorded video
  • Interviews with people
  • Formal talks
  • Explanations and tutorials from team
  • Link to github
Notes for problem and solutions
  • Relevant dataset link and description
  • Tried this, didn't work, trying this instead
  • So and so is working on this aspect
Teams in cities working on this can be listed below:
About this pad:
Edits   you make are in your selected color, but you can wipe color after   editing phase is done (click the color wheel up top after highlighting   text you want to de-colorize). There is a time slider so you can  recover  things that might have been deleted.
We   can share a read-only version on the public face, and use the editing   link for people AT the event if anyone is concerned about trolls.