Just pushed 0.2.0 with a fix, and also included the "Units" in the row selection, and as part of the object when you click to output "Both" data types (raw and formatted)
Well if it psi then it can't possibly be 740, there would be a big bang! Has it got the cabin pressure, that should be about 14psi?
Hmm. This is from https://iss-mimic.github.io/Mimic/
You beat me to it. 750 torr is more likely. That equates to a sensible 14.5 psi
That's annoying, my JSON was generated by their Telemtry.xlsx file: Mimic/Telemetry/ISS_Public_Telemetry.xlsx at main Ā· ISS-Mimic/Mimic Ā· GitHub, which definitely lists AIRLOCK000054 as PSI
0.2.1 just got pushed with the update to the units
I couldn't find the location (lat - long) , is there any way to get it?
It's not actually included in the standard Data Stream, as the stream is focussed on hardware data (e.g. digital twin) streaming from the ISS.
I normally use either:
- API calls to Open Notify -- API Doc | ISS Current Location
- Node-RED Satellites: node-red-contrib-satellites (node) - Node-RED
The latter is a more accurate position as it uses the satellite's TLE data to propagate the current lat/lon.
1 Like
Ok, thank you ....
Just to confirm @joepavitt your patch works like a dream
1 Like
@joepavitt in the dictionary file the descriptions are listed, but those are not exposed anywhere ? could they perhaps be included in the payload ? or displayed in the 'feeds' list ?
Because they're so long in some occasions, I'd left them out of the feed list, as its already an incredibly long list. I did however include it all in the README of the project, and you can read them all here: GitHub - joepavitt/node-red-iss-data-streamer: Node-RED node to subscribe to the Lightstreamer data feed from the International Space Station
I could, like I do with the units now, include a description property when you enable both feed types as output?
Your resources file Joe lists various status codes which have explanations/possible values.
eg for USLAB000044
0=DOING POSITION FIXES|
1=SV TIMING|
2=APPROXIMATE TIMING|
3=GPS TIME|
4=NEED INITIALIZATION|
5=GDOP NEEDED|6=BAD TIMING|
7=NO USABLE SV|
8=ONLY 1 USABLE SVs|
9=ONLY 2 USABLE SVs|
10=ONLY 3 USABLE SVs|
11=BAD INTEGRITY|
12=NO VEL AVAIL|
13=UNUSABLE FIX
It doesn't seem practical to include all these and the descriptions, better to refer back to the README?
Also relevant and only obtainable live (eg from from https://iss-mimic.github.io/Mimic/ ) is when the last value was received for each datum.
Some interesting topics, eg the solar arrays current, seem never to be updated.
That page also currently shows no telemetry at all received for the last 12 hours! 
All of those options are detailed in the help section for the node too, but I didn't go as far as including the descriptions there too.
Also relevant and only obtainable live (eg from from https://iss-mimic.github.io/Mimic/ ) is when the last value was received for each datum.
I'll have to check in with the ISS Mimic team to see how they get that, I suspect they're storing that themselves in a context variable per-say.
That page also currently shows no telemetry at all received for the last 12 hours!
It's rare to happen, but it can do. Nothing has happened to the ISS that I'm aware of!
I am a bit puzzled about the timestamps '1412.6884727778038' - how should/can they be parsed ? I see on the mimic page something like 'GMT 58/20:41:19' - not sure how to read the '50/' (ie. what does it mean)
It doesn't seem practical to include all these and the descriptions, better to refer back to the README?
I have made an parsed object that automatically injects the values/descriptions with each update, I don't see the problem with having it available directly with the telemetry data.
I recommend asking on the ISS Mimic Discord (linked on their GitHub) for that.
1 Like
I suspect the 58 may indicate the 58th day of the year. Today is day 60.
It seems an odd representation though.
And on the mimic page (on my PC in England) it gives times in GMT. But surely the space station of all places would work in Universal Time?
As for this 50/ of which you speak ... 
1 Like
After some digging, it seems to be:
Oh yeah timestamp is a little weird, it's hours past midnight Jan 1 UTC of the current year, resetting every year
This should work.
function getISO8601Timestamp(inputHours) {
const year = new Date().getFullYear();
const start = new Date(Date.UTC(year, 0, 1, 0, 0, 0));
const totalMs = inputHours * 3600000;
const resultDate = new Date(start.getTime() + totalMs);
return resultDate.toISOString();
}
const inputHours = 1412.6884727778038;
msg.payload = getISO8601Timestamp(inputHours); //2025-02-28T20:41:18.502Z
return msg
