Realtime telemetry from ISS internal components(iss-mimic.github.io)
iss-mimic.github.io
Realtime telemetry from ISS internal components
https://iss-mimic.github.io/Mimic/
50 comments
This is being used to sync a 1:100 model of ISS with the actual station: https://github.com/ISS-Mimic/Mimic
This is incredibly cool!
Cool to see this data still live! And on HN
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
More details on the original project here: https://youtu.be/xAhw_8B25N0?si=geMXrliwdKkt5fY8
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
More details on the original project here: https://youtu.be/xAhw_8B25N0?si=geMXrliwdKkt5fY8
ISS mimic team member here - if you're still in the Houston area I'd love to buy you a drink sometime
Thanks for making ISSlive
Thanks for making ISSlive
I'm SO going to build a Grafana dashboard from that!
I would love to see that!
So, uh, I actually did. Built a small Prometheus exporter to read the official data stream, and ingest it in Grafana.
Anyone up helping me create all the charts? It’s over 300 of them :D
https://iss-metrics.9dev.de/public-dashboards/bccf319b13ff4b...
Anyone up helping me create all the charts? It’s over 300 of them :D
https://iss-metrics.9dev.de/public-dashboards/bccf319b13ff4b...
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.
The ISS uses Control moment gyroscopes to stabilize it's orientation. Couldn't those be used to calculate its mass?
https://en.wikipedia.org/wiki/Control_moment_gyroscope#Inter...
https://en.wikipedia.org/wiki/Control_moment_gyroscope#Inter...
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?
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.
Hopefully I'm not embarrassing myself with this question, but:
If you know an satellite's orbital path and velocity, and the Earth's gravitational strength, is that enough to compute the satellite's mass?
If you know an satellite's orbital path and velocity, and the Earth's gravitational strength, is that enough to compute the satellite's 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.
https://en.wikipedia.org/wiki/Galileo%27s_Leaning_Tower_of_P...
https://en.wikipedia.org/wiki/Galileo%27s_Leaning_Tower_of_P...
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.
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.
True. It turns out, it also applies for the two body problem, as long as one body is much more massive than the other.
https://en.wikipedia.org/wiki/Orbital_period#Small_body_orbi...
https://en.wikipedia.org/wiki/Orbital_period#Small_body_orbi...
[deleted]
> Hopefully I'm not embarrassing myself with this question, but:
Yup, I'm kind of embarrassed :) I forgot that maintaining orbit is just a matter of falling at the same pace that the earth is falling away from you.
Yup, I'm kind of embarrassed :) I forgot that maintaining orbit is just a matter of falling at the same pace that the earth is falling away from you.
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.
[1] https://store.steampowered.com/app/220200/Kerbal_Space_Progr...
[2] https://www.youtube.com/watch?v=dhYqflvJMXc
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.
[1] https://store.steampowered.com/app/220200/Kerbal_Space_Progr...
[2] https://www.youtube.com/watch?v=dhYqflvJMXc
> maintaining orbit is just a matter of falling at the same pace that the earth is falling away from you
Perhaps a better visualization: moving sideways fast enough that you miss the earth? :)
Perhaps a better visualization: moving sideways fast enough that you miss the earth? :)
The mass data is calculated from all the launched mass but I have no idea why it's a telemetry value unless the ISS echoes it back for some reason
I assume it’s calculated from the propulsion positioning system.
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 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
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
Thank you! Do you have any good references for voting systems? I've always wanted to learn more about those.
I thought this was an interesting and very related read that touches on voting controls: https://ntrs.nasa.gov/api/citations/20020039704/downloads/20...
Thank you!
quantum switch
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?").
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.
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.
> moments of realization about "no shutdown" in Cisco IOS and similar environments
> but from this perspective it makes sense
No, it's just a clunky way to remove the config line, it has nothing with the engineering safety.
It's still better than Huawei's lingo, though.
> but from this perspective it makes sense
No, it's just a clunky way to remove the config line, it has nothing with the engineering safety.
It's still better than Huawei's lingo, though.
Which NASA API/data feed is being used to get this telemetry?
"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.
Can anyone explain what the number before the timestamp is?
GMT 66 / 43 / 41
As a date command format string:
```
```
$ date -u '+GMT %-j/%R:%S'
GMT 66/17:05:57
It's the DayOfTheYear followed by Hours, Minutes and seconds in UTC.
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.
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"
That's very common in ISS operation schedules - next spacewalk is on GMT xx next launch on GMT xx, etc
I expect it's easier and more useful to track days until event or days since event
I expect it's easier and more useful to track days until event or days since event
66 could be the day of the year.
[deleted]
It has a year field, when would that one be updated? Using UTC?
So where is the ‘leaky’ Soyuz module? Haha
All the leaky Soyuz spacecraft have returned to earth at this point
The coolant leak: https://en.m.wikipedia.org/wiki/Soyuz_MS-22
The air leak: https://en.m.wikipedia.org/wiki/Soyuz_MS-09
The coolant leak: https://en.m.wikipedia.org/wiki/Soyuz_MS-22
The air leak: https://en.m.wikipedia.org/wiki/Soyuz_MS-09
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.