Project Soyuz 7K-T Custom

I think you got to the same result, from the shape of it at least:

Code:
incl = 51.77 * pi/180;  %fixed inclination
ink_period = 89.43 * 60;    %s
omega = 2*pi / 84952;        %rad/s sidereal day
orb = 0:1/60:1;
x = cos(2*pi*orb);
y = sin(2*pi*orb)*cos(incl);

latitude = asin(sin(incl) * sin(2*pi*(orb+0.25))) * 180/pi;
longitude = (atan(cos(incl) * tan(2*pi*(orb)))) * 180/pi;
longitude2 = atan2(y, x) * 180/pi;

for i = 1:length(longitude)
    if (longitude(i) < 0)
        longitude(i) = longitude(i) + 180;
    end
    if (orb(i) > 0.5)
        longitude(i) = longitude(i) + 180;
    end
end

for i = 1:length(longitude2)
    if (longitude2(i) < 0)
        longitude2(i) = longitude2(i) + 360;
    end
end

%would then add the offset from Earth's rotation here

%plot(orb, latitude)
figure(1)
plot(orb, longitude2)
figure(2)
plot(orb, longitude)

longitude would be the original source, longitude2 was the other way I found and they're a match. Then just adjust either as needed to be [0, 360]. orb would represent the globe's orbital animation, so 0 to 1 is a full orbit. Ignoring Earth's rotation to keep it simpler. (the orbital rotation of the globe is just a rotation around Orbiter's x axis, btw)

Only using an offset with latitude, with longitude the animation 0 state corresponds to 0º longitude.

In Orbiter it's the same thing, just adapted to work step by step in PreStep rather than loops, though only using the atan version.

I do not have the full overview of what you're doing, but hopefully it could be useful to see the calculations I did for my copy/remake/extension of the MapMFD. See here, starting from line 4279: https://github.com/asbjos/MapMFD2/blob/7df311d71f0c41fcddb8fefe1e3b2208a4f53b4e/MapMFD2.cpp#L4279

I get the impression that you've forgotten to implement the LAN, so that your code for the longitude believes that you start at the equator going northwards when orb = 0.

In my code, you can naturally ignore the calculation from MnA to TrA, as you assume a circular orbit.

Best of luck! When I worked on my Project Mercury X, the Earth Path Indicator / globe was my favourite cockpit tool to implement, so I envy you the pleasure when you sort your problem out!

Final note, why do you use 84952 seconds as the sidereal day? Shouldn't it be 86164 seconds?
 
I get the impression that you've forgotten to implement the LAN, so that your code for the longitude believes that you start at the equator going northwards when orb = 0.
You know what, you might be right, I'll need to check later. I intentionally dismissed it but on an incorrect assumption I suppose. I figured since I was starting with 0 longitude and 0 rotation aligned in the mesh, I wouldn't need that offset. But now I think of it, of course, the curve between 0 and 90 isn't the same as between 90 and 180, and I should be starting at 90. It's not that I don't need any offset, I need two rather. Even more frustrating in hindsight since I did have to take the equator reference into account for latitude...

So I figure that orb + 0.25 offset comes back in to start at the right point of the curve, and then have a -90º offset to correct to the mesh.

Best of luck! When I worked on my Project Mercury X, the Earth Path Indicator / globe was my favourite cockpit tool to implement, so I envy you the pleasure when you sort your problem out!
Yeah instrument-wise it might be the most interesting, the program timer is a good challenge too. Although crude as they are, figuring out the autopilots is a good match in terms of satisfaction.


Final note, why do you use 84952 seconds as the sidereal day? Shouldn't it be 86164 seconds?
Indeed. Maybe sidereal day isn't the best term. The "documentation" of the instrument has:
"One turn of the globe around the axis of the daily rotation occurs in a time equal to the sidereal day, taking into account the precession of the orbit relative to Earth's axis caused by the asymmetry of the Earth's gravitational field."

and also specifies:
"Period of the daily rotation of the globe is 23 hours 35 minutes 52 seconds." aka the 84952 seconds.

I did wonder back then why such a difference, and haven't been able to find other references to this particular time duration. I've been assuming that's the "taking into account the precession of the orbit" part in play. So far I haven't noticed too much deviation even though if I'm honest I never quite learned to work with non-spherical sources and have it off, but it gets trickier to simulate multiple days since time acceleration will probably also introduce errors of its own.
 
I did wonder back then why such a difference, and haven't been able to find other references to this particular time duration. I've been assuming that's the "taking into account the precession of the orbit" part in play. So far I haven't noticed too much deviation even though if I'm honest I never quite learned to work with non-spherical sources and have it off, but it gets trickier to simulate multiple days since time acceleration will probably also introduce errors of its own.

I don't suspect you'll have much trouble with accuracy over time. The error source here will be in the round-off in simdt, and in the calculation. There's a good chance that this will be more accurate than the physical mechanism even with large time steps and a simpler Eüler's method incremental rotation.

The NASSP IMU used to unrealistically stable, even when multiplied by 3 rotation matrices every timestep....then we added drift rates.
 
And voila:

Thanks everyone for the help. Would have gone off on a wild goose chase with this staring back at me the whole time.

Now to give it a proper motion test, and figure out if МП will need any special attention, in theory no, since all I'm doing is applying an offset to the animation variables for the landing angle. This new top down camera also made it evident there's a bit of a misalignment which wasn't as easy to spot in Blender. Gotta reconvert the mesh at some point.

The NASSP IMU used to unrealistically stable, even when multiplied by 3 rotation matrices every timestep....then we added drift rates.
RCS and the gyros are definitely like that right now. I'm aware of some data existing concerning deadbands, drift not so sure, there'd be sensing error as well I guess, but just working with what Orbiter gives me, thrusters and gyros are way too good as is.
 
Alright, let's pretend it's Tuesday.

Yastreb update released! Changelog:
  • Custom clock, button, alarm, pyrotechnics sounds added (XRSound)
  • 150 m/s emergency delta-v alarm added
  • BTsI data entry method updated (linked to KSU), Accelerometer displays on BTSI during operation
  • INT dynamic scale (0 - 40/80 A) - visual and animation adjust
  • Vzor mechanical re-orientation takes 20 seconds
  • DO backup tank added
  • Orbit counter not updating fixed
  • Added VC camera position for top-down Globe view
  • SIO overhaul: DPO and DO thruster layout now accurate
  • Reworked SIO thruster logic: DPO yaw and roll, DO pitch and yaw, DPO and DO operation now independent
  • PAO model updated: geometry, antennae, ion sensors and materials
  • Basic thermal sensors implementation: on/off, auto-separation at 110 km
  • INK latitude and longitude tied to actual globe motion
  • RO modes kill rotation on switch-on
  • KSU matrix updated

To be clear, O2016 only still, have not tested anything in O2024 yet. As noted, new sounds are for XRSound.

The thermal sensor implementation is really quite basic, it's only checking for the altitude, 110 km being the altitude around which it would trigger. Ideally of course they trigger at 150 ºC, which will depend on the dynamic pressure and characteristics of the sensors, which is a whole can of worms which I don't know when/if I can get to.

Would be nice for the next one to maybe get the whole instrumentation set doing something with the KEI and IDT partially introduced, which would require some degree of simulation of the propellant system and life support. For now, research continues, onwards to Radon.
 
Hallo Diagon, nice to see you released a new version, I saw you are super busy also in others posts, and I guess also with the private life.
I just tried the new version, in all scenarios (launch, post insertion, docked) I have problems to use the retrograde orientation, it seems it always skip the "yaw Align" step.
Also using the Descent II program when it should orient retrograde it doesn't get there. BUT if want to go prograde it works, the yaw align is done.
I compared with the previous version, Baikal, when it always worked.
More in detail from the HUD I see the following steps:
roll search (omega-z goes to 0.45 deg/s) -> pitch align (omega-x 0.45) -> roll adjust -> pitch adjust -> attitude hold with omega-x +0.067, omega-y different from zero, omega-z zero, after a while of costing some jets are firing again to reduce omega-y but not to zeroing so that the spacecraft has now all 3 omegas different from zero and it spin like that ... on the ELS the blue light of the orientation established never light on, but in the HUD "attitude hold" is always displayed.
I tried all others functions, programs and everything seems ok.
any clue? Thanks.
 
any clue?
Hello! Yeah, a guess at least. So it just skips the yaw bit entirely? I didn't change that program itself much, but I did change how some other things interact with it, so maybe some variable somewhere slipped and it's leaving it in a weird state. I'll have a look, thanks
 
Did a quick experiment: so Astronautix quoted a 500 kg propellant mass, which I went with as it seemed reasonable enough with what's known, but I haven't really seen any primary source for that. Anyway, given a pic of a KTDU-35 including tanks, I got pixel counting.

Assuming a known reference of 1.5 m, the radius of the 4 tanks comes out to about 0.29 m. So 2 for UDMH, 2 for AK27I.
Total UDMH volume = 0.204 m3; using 791 kg/m3 as density, that's 161.364 kg of UDMH.
Assuming a 1.85:1 ox:fuel ratio on the engines, that's 298.523 kg of AK27I.
Total propellant mass = 459.89 kg

Lots of approximations of course, not only with dimensions but also temperatures, but I'd say that's encouraging.
 
Figured I'd try dumping this straight into O2024, it actually runs out of the box.... sorta. Haven't had much time with it, didn't crash far as I got, but a lot of the VC is non-functional. Animations like the clock seem fine, buttons seem to at least partially work as they respond to clicks and animate, and it at least registers the action to switch columns on the KSU for example, battery status works as well, though some KSU actions don't seem to be registering. But it seems anything to do with blitting is out for the count, as I kinda feared it might.

Not sure how much of this could just need a recompile with the 24 SDK or is just fundamentally broken? Gonna need to experiment some more.
 
Figured I'd try dumping this straight into O2024, it actually runs out of the box.... sorta. Haven't had much time with it, didn't crash far as I got, but a lot of the VC is non-functional. Animations like the clock seem fine, buttons seem to at least partially work as they respond to clicks and animate, and it at least registers the action to switch columns on the KSU for example, battery status works as well, though some KSU actions don't seem to be registering. But it seems anything to do with blitting is out for the count, as I kinda feared it might.

Not sure how much of this could just need a recompile with the 24 SDK or is just fundamentally broken? Gonna need to experiment some more.

Which call do you use for blitting? Is the texture dynamic?
 
Which call do you use for blitting? Is the texture dynamic?
Just oapiBlt. oapiGetTextureHandle, register area with it, then oapiBlt in VDRedrawEvent.

I believe I exported them as dynamic, at least some are marked as such Blender-side, though the mesh file doesn't show it, I think I remember they're supposed to be marked as such on the file?
 
I think I remember they're supposed to be marked as such on the file?
Yes, the textures should have a D after the name.
Instead of painting in the texture you should look into shifting the UVs of the mesh, which seems to be cheaper in terms of performance.
 
Interesting, forcing the D on the file seems to have done it. Can't argue with the documentation, but curious that it's been working the whole time in 2016, guessing something changed here. Thanks for the tip both.

1763753405897.png

Vzor still dead in the water, but that gets into D3D9 camera stuff. But it was at least already protected for so it doesn't crash things. Otherwise looking promising.

I still probably want to move away from oapiBlt to Sketchpad though?

Instead of painting in the texture you should look into shifting the UVs of the mesh, which seems to be cheaper in terms of performance.

Yeah doing it this way seems a bit of a mess in terms of efficiency.
 
Interesting, forcing the D on the file seems to have done it. Can't argue with the documentation, but curious that it's been working the whole time in 2016, guessing something changed here. Thanks for the tip both.

View attachment 45713

Vzor still dead in the water, but that gets into D3D9 camera stuff. But it was at least already protected for so it doesn't crash things. Otherwise looking promising.

I still probably want to move away from oapiBlt to Sketchpad though?



Yeah doing it this way seems a bit of a mess in terms of efficiency.

I think the Clients for O2016 were simply more permissive than in O2024.... but the DX9client also cared for the D flag much more than the default Orbiter client.
 
Chasing a lead that had been in the back of my mind for a bit: it's not documented anywhere I've seen per se, but it seems clear via ASTP images both engines were covered, and it's known that Soyuz 19 performed at least one significant orbital maneuver unlikely to have been done with DPO. It's also stated here that Soyuz 32 had an incident where the SKD was fired without the engine cover being opened, in pilot error. Primary source seems to be the cosmonaut in question's memoirs [RIOUMINE, V., Год вне Земли], not checked yet but it's accessible, should be interesting as a whole. There is of course also the fact that it's very much known Soyuz-T onwards had/have such a cover and, more importantly, it's documented how it is that it can be operated manually:

1764476880772.png
(From Soyuz Crew Operations Manual (SoyCOM) (ROP-19))

So it would follow, given that, the existing option of manual burns, and the Soyuz 32 incident, that there would be a similar way to do the same with 7K, and that it wouldn't be an automated step out of the cosmonauts' reach. And here is where I've hit a wall, because both available complete sources for the KSU make no discernible mention of such a mechanism, far as I can tell. Maybe it's staring right at me and I just can't identify it yet, or it could be nested in with some related command. On the critical commands buttons, all their functions are accounted for enough that I don't see it being there, they are ON/OFF and a blocking system. So that's another mystery to solve.

Regarding the mechanism itself, ASTP:
1764478033567.png1764478048333.png

NASM piece:
1764478980915.png

RVSN museum piece (kosmonavtika.com):
1764478206822.png
"Do not touch, opens with a drive" - my interpretation is it rotates out of the way parallel with the surface, instead of rotating away "up" as in later Soyuzes. Regarding the secondary engine's covers, my guess here is they might have been sacrificial: if you had to switch to the DKD, I'm assuming the flight rules were "your only use of it will be to de-orbit", so it would end up being irrelevant if the engine blew the covers off.

Other things:

After seeing a recent discussion in the Forum, had the idea of investigating potential integration with UACS eventually. Only had a very brief look at what it offers, as far as astronauts it seems doable. What I was wondering in terms of making it more interesting is if it could maybe tie into the life support system. Not much to go on yet, just a possibility to look further into.

Finally got around to requesting, and just received, historical TLEs for Salyut 4 and Soyuz 17 from CelesTrak. The latter actually has 6 data points between launch and docking time, so maybe something useful can be gleaned, also when compared with other missions and the station's data, regarding the final intercept orbit. (context here being getting a better idea of the rendezvous profile re: setup for Igla)

Soyuz 17, credit to https://github.com/BrendanLuke15/TLE-Decoder-Converter?tab=readme-ov-file for the tool:
1764480471419.png
 
Finally got around to requesting, and just received, historical TLEs for Salyut 4 and Soyuz 17 from CelesTrak. The latter actually has 6 data points between launch and docking time, so maybe something useful can be gleaned, also when compared with other missions and the station's data, regarding the final intercept orbit. (context here being getting a better idea of the rendezvous profile re: setup for Igla)

Soyuz 17, credit to https://github.com/BrendanLuke15/TLE-Decoder-Converter?tab=readme-ov-file for the tool:
1764480471419.png
I think making a plot showing relative vertical and horizontal distances between the the Salyut and the Soyuz might be interesting. Here is one from the Shuttle rendezvous:
figure09.jpg

It won't be easy with the different TLE elements, but maybe it will help figure out when burns were performed and why, so the basic profile can be figured out.
A relative inclination plot may also help in placing plane correction maneuvers along the in-plane profile.
 
Not exactly new, but new to me, I think:

Documentary about Sigmund Jähn's flight, some nice archival footage in there, including a remarkably clear look at the BO of presumably Soyuz-31 at docking (20:58).
 
Found a new nugget on ntrs, from the 6th Aerospace Mechanisms Symposium 1971: "DOCKlNG DEVICES FOR SOYUZ-TYPE SPACECRAFT" (page 139 of the pdf). Notably talks about the original system on 7K-OK.

"ABSTRACT. Two docking-device designs for Soyuz-type spacecraft are compared. The
first was flight tested successfully; the second achieves rigid and exact joining of two
spacecraft while also incorporating changes t o allow for the intravehicular transfer of
crewmen. The main functions of the docking device are considered with the means by
which they are accomplished, and measures for increasing its reliability and flexibility in
service are noted."

1769726410187.png
 
Giving the BO a bit of a revamp based on the footage I've gathered. Not very clear footage at that, but still informative. WIP:

1771122567188.png

That notched RF netting on the side is there in multiple sources, including Progress. Did away with the older RF shield, which was probably based on the -OK one but which is clearly missing on anything after it, and added the two more modern-style ones on Plane I. Not 100% sure yet about them, especially the "lower" one. The other one it seems clear enough it's there from the way it occludes the RF netting behind it (yet to be added) even though it's pretty much invisible from any angle from above, and probably would have folded down for stowing the big Igla antenna mast, the lower one I'm less sure about, there's something there but what shape it takes isn't clear:
1771122985370.png
Almost as if it could be covered by the RF netting in a way, like forming a sort of canopy? It also seems like there's a 3rd such shield behind the other two closer to the antenna, but I'm not trusting my eyes so much there.
Other angles:
1771123016007.jpeg
1771123036460.png
(this one is a rare view I wish I could remember where I got it from, could be a Progress from the placement of the starboard Igla antenna, based on below)

Progress:
1771123027844.jpeg


Other miscellaneous things:
  • Adjusting the colouring on the antennas, the current strong yellow was probably based on the museum -OK pieces, which are detailed but flight hardware doesn't seem to reflect this;
  • Relocated and reshaped the smaller Igla TX antenna, photo evidence shows it curved, likely to conform to the BO's shape when stowed for launch. Progress' being shaped differently (straighter) might also suggest this, given its less spherical forward compartment;
  • Material changes on antenna masts;
  • Reshape the BO base where it attaches to the SA;
  • Did away with the handrail on Plane III near the hatch;
  • Will add some stuff up front on the docking ring: the current camera might move slightly off centre and be covered in thermal insulation (as on ASTP), next to it would probably have been a floodlight based on some video evidence, thus likely accounting for the two elements on the bottom on the pic below. On top there are two further elements, expectation would be one of these elements is an ion sensor, though neither two on top quite look like what on the ASTP version is documented as said ion sensor;

1771123543438.jpeg
1771125746691.png

  • With the floodlight moving forward, will probably do away with the bottom mast on the BO aft currently handling the lights, but there's some indication the top one might have still been there, if in a different location and angle;
  • The antenna elements around the middle of the module need some attention: currently they're all the TV antenna type, missing the type below for radio commands link. There's also evidence there were only two elements total, not four;
1771124824557.png

- Looking into the existence of a second BO vent manifold: there still is and seems to have been one by the BO ingress hatch, but some footage could indicate another up front near the docking ring. Possibly also seen on ASTP, will also try to verify with modern Soyuz, though that's no guarantee of prior existence or lack thereof
1771125569876.png

- Finally, the RX Igla antenna (starboard): presently not relevant for Salyut 4, but I should start thinking of the eventual variant for Salyut 6+ and Almaz which retracted to provide clearance with the station (as configured on all footage above). I saw some video recently which showed it in motion but didn't save it and can't for the life of me remember what it was from. In any case, the angle between the antenna element itself and the mast is off, almost 90º based on photographs and video (also of Soyuz-T), and fully deployed it would likely look more like this rough mockup:
1771126278324.png

Edit: actually starting to wonder if the mechanism itself, that is that handle-like bit, wasn't added specifically for the retractable versions. 7K-OK just had the single mast type visible here, for instance, but from the grand total of one Salyut 1 era pic I have, it sort of looks like the same principle, just stowed differently.

Other than this, research slowly continues and will get to tidying up the auto modes. No promises but might bring back Igla on the next one. Based on a few bits of data now, and I'm sure I could find more especially with Salyut 6, it seems the profile indeed was a shallow intercept, from a slightly higher orbit during which Igla was switched on. I'd like to figure out a consistent way of setting this up and match up the flight plans, as they were usually pretty consistent on which orbit # they intercepted on, and designed the launch windows around that. But this puts significantly less strain on Igla and hopefully back within the limits of my implementation.

With the N1-L3 project I've figured out the whole UV coordinate move thing for the dynamic textures, so I'll also start thinking of a migration plan here, since some things like the KSU might not be perfectly set up for it. Will also eventually introduce actually emissive electroluminescent signals so they're actually visible in the dark.
 
Last edited:
I saw some video recently which showed it in motion but didn't save it and can't for the life of me remember what it was from.
Found it on a Roscosmos TV dive:


It's a Soyuz-T though, but there should have been commonality. Reworked the antenna, estimated angles from the few top-down photos (~120º between both antenna mast pieces, ~104º between the "forearm" and the actual antenna element) and making the assumption that when extended, the antenna is completely facing forward:

1771692023385.png1771691908563.png


Also found several variations of the same clips at different quality in different videos, plus some Salyut-7 EVA stuff, and not so sure anymore about actual RF shields as present on old and new:


It's looking to me like they just had the reflective material propped up at the front in the middle but attached to the MLI on the remaining sides, forming a sort of canopy that looks like the triangular shields from the front, in poor quality footage. I'd be curious how they iterated this to be the optimal solution for reflection mitigation.

This would also explain what was seeming like a 3rd shield nearer the main Igla antenna mast. It's also apparent there's a seam down the middle of these features forming a bit of an edge. The small structure visible between the first and second such feature would likely be a support for the main Igla antenna when stowed, of the type seen for Kurs antennas.

1771691728557.png
 
Back
Top