I was the lead on the ISSLive project that released this at NASA back in 2011 - we used an Ajax light streamer server to serve select (approved) space station telemetry parameters and astronaut schedules and we also
Built mobile apps and a 3D website with an immersive Mission Control experience in Unity
Sadly the sites lost funding - but glad to see the IssMimic project and data still available- as a former ISS flight controller I have fond memories of my time there
One of those values is "ISS total mass." Is that calculated using launch/deorbit weights or is there some kind of sensor on board that can measure that? I figure if you did a specific type of burn you could calculate the weight from that, but I'm wondering if they have something more clever.
It's just an estimate and isn't that accurate. Yes, the closest you can get is orbit determination before and after the reboosts, and acceleration data.
Not an expert but I think its possible, the problem is that the gyroscope alone wouldn't be sufficient. When the gyro rotates once, the massive spacecraft will obviously have rotated exactly once relative to the gyroscope. However if you could track the space station's rotation relative to an independend stationary observer in space (lets say an array of pulsar data), then you could count the amount of turns of both the gyro and the spacestation relative to the background of space. Then the amount of turns of the gyro times the mass of the gyro would give you the mass of the space station minus the independend floating objects. Meaning you'll need to add the mass of the gyro itself as well.
Please correct me if i'm missing something obvious. This should work right?
Not its mass directly, but you can use it to calculate the moment of inertia. Move the CMGs a fixed angle and looking at the responding change in rate of the ISS. Mass can be determined from maneuvers when you fire the thrusters. Assuming you know the force from the thrusters very well (this has its own errors) you can look at the acceleration from the orbit determination before and after the thruster burns and back out the mass.
In a uniform gravitational field, it isn't. On the earth's surface, acceleration due to gravity is 9.8 m/s^2, independent of the mass of the falling object. See Galileo's Leaning Tower of Pisa experiment.
The field is not uniform though. So in theory, if you know the orbit and firld exactly, you can calculate it.
In the present case, I guess the precision with which one knows the orbit and other stuff (like the exact gravitational fiel of the earth) doesn't work out.
If you've never tried it, I highly recommend playing Kerbel Space Program[1] (it works on Linux, Mac, and Windows!).
That game taught me so much about orbital mechanics, which led to rabbit holes of textbooks and videos[2].
The first big lesson KSP taught me was: why, when launching a rocket, you don't just go straight up but, instead, have to lean over pretty aggressively.
What's the reason behind using the "Off"/"Not-Off" notation for "on-off status" instead of "On"/"Off" or even "On"/"Non-On"? I see some "state" parameters marked as "ON".
I am a controls engineer and saying something is CLOSED when it is actually only observed to be NOT OPEN is my personal windmill I tilt at regularly. People have deied before because what the screen said was that the valve is closed, but what the PLC actually observed is that the valve had left the open position, which was the only limit switch present. Maybe the valve is travelling slowly, jammed halfway open, etc. When operators make the complaint you just did I tell them that what I've told them is reality and if they want a true closed we need a closed limit switch.
Ugh! I've had to deal with this in a situation where we needed two sensors to tell if an object was present or not, but there was only space for one. So we could tell if the payload was not present, but not if it was.
This meant that we would have to make assumptions like "you (other subsystem) say you had the payload and you gave it to me, and I believe you, but I can't prove that you did until much later in time."
And if it turns out that we weren't actually holding it, then recovering from that state required unwinding a whole series of decisions and actions made some time in the recent past.
Suffice to say, it made error handling for certain cases... challenging!
This was my first guess, although I do not have explicitly experience in life-or-death type of control systems. In such systems, does it make sense to have more than two states? Something like "open", "unknown but not open", "unknown but not closed", "unknown", "closed"? (Assuming that you have enough limit switches.)
That's exactly what you do. In all systems you should have two switches, and you annunciate on / off / travelling / error to the operator. Often you inherit something that doesn't have that.
In anything that really matters you have a continuous position transmitter instead of switches so your state is more obvious. In safety systems you might have 2 or 3 of those transmitters so you can have a backup or a vote
Certain controls -- like valves or vent dampers -- are not binary. Even if normal operation is either fully-closed or fully-open, it can technically be anywhere in between.
Having an absolute position sensor would tell you this, but is complex and expensive compared to having two binary state switches (fully-open vs fully-closed) which is also more expensive than a single state switch.
Probably in many cases it just isn't worth it to instrument beyond the single state, especially if the affect of the control is being monitored (eg: flow, temperature, power). However, communicating the state as accurately as possible is important to avoid confusion ("This valve says ON, so that's not the problem" vs "I can see this valve is NOT OFF, but let's double check it's fully-on?").
Guessing here: If you have a breaker switch after an additional switch, labelling the breaker with 'on/off' may be misleading as 'on' doesn't necessarily mean the connected device is powered. It may be off because the other switch is off.
Reading this post led to one of those moments of realization about "no shutdown" in Cisco IOS and similar environments.
The config file can't guarantee the interface will be up when it's loaded as that depends on external factors but it can guarantee the interface will not be shut down.
I've used "no shutdown" as an example of illogical UI for decades because it seems backwards as the user, especially when new to IOS and trying to learn by exploring, but from this perspective it makes sense.
"Several years ago, NASA provided some of the data to the public in order to spur interest in the ISS and space exploration under the ISSlive project (https://isslive.com/) using the lightstreamer service (http://demos.lightstreamer.com/ISSLive/)"
Incredible! I wonder how much delay there is between the sensor data coming in to ISS, being relayed to NASA, fetched by these guys and forwarded to their model's actuators.
Is this the datetime format they use onboard on the ISS or why is it being used in this webui?
This is the first time I come across this particular format, but also never near space-stuff so wouldn't surprise me if they use some specific format for some specific purpose.
Yes, using Day of Year for time GUIs and measurements is pretty common in spacecraft operations. Generally easier to do/plan operations for things like "we need to perform this maintenance activity every 5 days"
Scott Manley reported three days ago about an apparently current, non-threatening leak https://youtu.be/MZgaLzYFCrU at about the 18 minute mark if you're interested.
