Project Soyuz 7K-T Custom

[diogom]

Just dropping this here which I found recently. Mostly Salyut 6, but there's a couple of good* 7K-T shots:

*well, better than the existing sample pool of, like, zero

 

[diogom]

Tried to tackle the issue that the Vzor can see through the fairing during launch, but feel like I might be hitting an Orbiter/D3D9 limitation. Basically the cameras see through meshes up to a certain distance in front of them, so even though the camera position has a fairing in front of it (double sided mesh, so no face orientation issues), I would need to move them too far "up" the periscope from the correct position. For the central view, that won't work when in docking orientation, though I could always reset the position at separation from the rocket. But for the peripheral view, with its 77º aperture camera facing down, it needs to be set so far up that it then starts to see the ship "above" it and just looks like a mess. Still, physical blocking would have been the ideal and simplest solution.

Alternatively, I could force the views off in software during launch. Not sure if I have a way of asking the rocket if the fairings are still on, but making spacecraft separation the trigger would be kinda lame, to be honest. Could be altitude based, but I'm not sure that it will be consistent across every launch, I'd need to know what the rocket uses as the trigger (likely elapsed time, but again, not sure I have access to that). In any case, I've set it so that it's off by default in a launch scenario, and the pilot is encouraged to not mess with it until in orbit.

Anyhow, gonna see if I can finally pick some steam back up, after way too long procrastinating. Wanna prioritise tying up some loose ends, like that annoying bug with the orientation modes where opposing thrusters get stuck on, or making the program modes more robust. But also look to something new, which I'm feeling like might be a more in-depth fuel system, which would then also give me a reason to introduce the KEI, as gas and prop pressures are displayed there. Which means I have some reading up on pressure-fed engines. I suppose what I'm looking for is the relationship between "amount of usable propellant left" and "pressure of the gas and propellant tanks", since Orbiter only works with propellant amounts.

 

[Urwumpe]

I would say, turn them off until you detect fairing separation. Not sure about HOW to do that. Does it use attachments?

 

[diogom]

They show as focus vessels, so I suppose they do use attachments. Could get the interface and ask about those attachment points. Just need to figure out which they are, trial and error I guess without the source, though VesselM does a lot with config files.

 

[diogom]

Which means I have some reading up on pressure-fed engines.

One day. It took one day to fall down a rabbit hole and ramble about it here. But is this not the fun in choosing a poorly documented vessel?

Made my way to the KTDU-35, reminded that it was a pump-fed engine assembly, open cycle, in contrast to the pressure-fed Soyuz-T and beyond, and landed on this interesting website that had somehow eluded me so far:

Kosmonavtika - par Nicolas Pillet

To the point (Soyuz 19/ASTP upskirt extracted from kosmonavtika):


So what if what I've been assuming this whole time were 4 DPO (RCS) thrusters, were instead the nozzles for the preburner exhaust?

I mean, fair point, it has to come out somewhere right, and alternatives aren't plenty. Several of the KTDU assemblies shown do include the 4 nozzles. The symmetrical arrangement seems a bit unnecessary considering other gas generator engines I'm aware of, but then again these engines were comparatively much lower thrust, so maybe an unsymmetrical arrangement would matter more? No TVC on the SKD after all. Why would they be angled though? There's a really neat video in that page of a test of both the SKD and DKD, but it neither confirms nor denies this, since I can't discern any preburner exhaust anywhere, due to quality and contrast, I'm assuming. Could it be possible it's the two small holes on opposite sides of the SKD instead?

So assuming this is the case, what are the implications? Well, the DPO arrangement comes into question, specifically the forward translation and yaw control. Previous assumption was yaw was only possible with the two "horizontal" nozzles, especially them being angled in giving better rotation moment, though it never sat right with me since clearly there are pitch thrusters pointing +Y and -Y on the very aft, which would provide much better pitch control than the "vertical" angled nozzles. But if instead both pitch and yaw were controlled by these back nozzles, then what are the +Y-Y ones for? Compensating torque introduced by vertical translation, I guess. But forgetting about the 4 nozzles, are there alternatives? Well...





Do I spy two DPO thrusters? Nozzle size and shape seems consistent, just inset into the structure. That leaves 2 thrusters unaccounted for. Shame that I never found any thrusters that could explain DPO yaw, other than the KTDU ones, right? Yeah, well, let's take a closer look at Soyuz 19:



...have I really missed these all these years?

The ASTP mockup has something odd in that place:


It looks like it could be the extension of the aft-facing thrusters, but no yaw thruster installed. But why would this be exposed in the flight article otherwise? It places a DPO line at that very location, conveniently, which could be tapped off for the yaw thruster. They are all common supply, after all.

So, DPO forward translation, check. DPO yaw, check and making more sense, actually, since it would then mirror DPO pitch. It also means they wouldn't have had DPO lines going through the engine assembly. It also means the torque introduced by lateral translation could be cancelled by an opposing DPO thruster, which so far in my implementation was only possible with DO (conflicting with the documented tidbit that DPO and DO were not simultaneously operated).

What about what's in Orbiter? The mesh includes none of the 4 hypothetical thrusters, though it wouldn't be a hard addition. I think it also wouldn't change much in terms of the code, at most some rotation modes need their thresholds tweaked for yaw.

I don't know. I'm not 100% convinced, will try to dig deeper if possible, and ask for opinions as well, because I don't want to be blinded by confirmation bias (much in the way I will have been if this is true, ironically). But I'll be damned if it's not making more sense this way.

 

[diogom]

Been cross-referencing Soyuz 19, the NASM display model, the National Space Centre 7K-OK, and on the lookout for other sufficiently photographed examples. Keeping in mind the inherent limitations and the fact that ultimately these (besides 19) are models in unknown levels of completion and fidelity.

For documentation's sake, for the moment, I believe I can confirm a few aspects so far:

• There are indeed two DPO thrusters in the aft, in the XZ plane, present in all three articles. The models clearly show the connection to the propellant line;
• While 19 is inconclusive (but there is something clearly there), it would appear there are no radial DPO thrusters for yaw in the previous post's indicated location. The quest for yaw continues; Edit: I suppose firing one of the aft facing DPO thrusters would provide yaw control, it's just a lot more inefficient than pitch. Though maybe the logic was to save the two extra thrusters;
• The plot twist is, there are instead radial DO thrusters, in fact on all 4 quadrants (one thruster each quadrant for ASTP, two each for OK, redundancy?). This contradicts the current implementation of two tangential thrusters on each quadrant, as shown below. It also potentially settles a lingering inconsistency between the documented thruster count and the mesh. These therefore provide direct pitch and yaw control. Roll is provided in pairs by the other 4 which appear to be correct;
• While already documented in text, there's possible visual evidence supporting the independent DPO/DO propellant supplies in 7K-OK, and the common supplies for 7K-TM, with a switch in design at an unknown point in between. This common manifold is visible in the ASTP mockup running around the PAO, with the individual connections to each thruster, while in the 7K-OK two manifolds are present. It doesn't however exclude the possibility that the supplies could be made to be shared, hard to tell with the quality and spaghetti.

 

[diogom]

Mostly done with the review of the PAO model. Added the two missing aft-facing DPOs, slightly repositioned the forward-facing DPOs to be a bit closer and less angled to the hull based on photo eyeballing, and added some (crude) thermal covering to them. The 4 DO thrusters were corrected too. It also occurred to me that while this single-thruster-per-channel (+- pitch, +- yaw) configuration will be half the thrust as what I had, there's always the possibility that, by using the remaining 4 tangential thrusters (which by themselves provide roll, in pairs), you could actually use 3 thrusters per channel, so not quite 3 times the thrust due to cosine losses, but still closer to 3 kgf than 1 kgf. Of course, I doubt I have a way of knowing for sure what the actual spacecraft did here.

A new discovery also required modification: the four side-facing DPOs were not at 90º offset from eachother, nor at 45º each relative to the Y and Z axes (in Soyuz coordinates, not Orbiter). Nor are they angled to fire through the centre of mass (or X axis, at least). Instead, they're each closer to the adjacent retro DPO and a bit slanted towards Y. This means that firing opposite pairs now provides the long and last missing link: DPO roll control. Not really the most efficient way to get roll, but it's clever in that it tackles both roll and lateral translation with the same 4 thrusters, potentially saving them at least 2 thrusters. Edit: though opposite-facing tangential pairs at the top and bottom would achieve the same with better roll and translation efficiency, but I'm sure they had their reasons going with this.



Similarly, I'm thinking the forward and aft-facing DPOs do the same reuse with fwd/aft translation and yaw, saving 2 dedicated yaw thrusters:



Yet to test this, but this configuration probably cancels out a lot of the longitudinal drift introduced.

In the process of counting antenna elements to approximate the new roll thruster positions, it also became apparent the telemetry antenna array encircling the PAO forward section had fewer elements than supposed, so these have now been bumped up to 42 and the size of each element reduced to match. Some other minor geometry and material adjustments, and to finish off, added two telemetry and comms antennas to the aft section. Based on ASTP pics and documentation, as far as I can tell, no indication they were an ASTP exclusive.




As to the 4 "mystery" thrusters around the SKD: documentation describes them as attitude control thrusters for use in DKD (backup engine) operation, to cancel torque, with their own driver taking in signals from the rate gyros, while control during nominal SKD use falls on DPO. Whether they're preburner exhaust or not, not sure why they would be used for DKD but not SKD, or likewise why they wouldn't also use DPO with the DKD, since a failure of the SKD shouldn't imply a failure of DPO, being separate systems. The engines would likely have separate turbopump assemblies, but maybe it's not as simple as redirecting both to the same output? Would still leave the question of where the SKD's is let out, unless that one's closed cycle. Not like the KTDU needs it unless I introduce varying centre of mass (but based on what?).

A loose end is left for the BO, which I'd been meaning to get to again anyway for other reasons: pretty sure an ion sensor is missing, which I now know how it would look like.

Now, inevitably, the material settings for PBR will have been entirely messed up and require redoing, besides coding the new thrusters and antenna animations, and retuning programs. Hopefully none of the mesh group numbers changed, which would be entirely my fault.

 

[diogom]

Materials sorted, thrusters are in. But I've been wondering if it's not a good opportunity to revisit the matter of centre of mass. I still feel like it would coincide with the plane of those translation thrusters (that IED 50401 document would answer this, gotta get to it and others).

I figured TMA would be similar, even if a lot changed internally (and with thruster arrangement), and I have this indicating which thrusters are used in each mode:



Thing is, it acknowledges the need for correcting torque during translation, but... the corrections are always to torque caused by the centre of mass shifting vertically or laterally, never longitudinally (yaw with longitudinal translation, roll with vertical translation). So either this is incomplete, or not much provision is made for what I'd assume to be just as serious torque if the CoM weren't in the thruster plane (in any case, there's no way it doesn't shift forward as fuel and consumables are spent).

I believe I arrived at the current CoM (lower third of the SA) with the shipedit tool and some offset, but of course there's a lot more that needs to go into it because modules aren't uniform. Pretty sure the PAO would be pretty rear-heavy, with the quoted 300kg dry mass KTDU + 500 kg minimum of propellant mass on one end, that's 30% of the total mass concentrated at the very aft. Plus batteries and other consumables in the aft compartment. So it doesn't seem unreasonable to put it roughly where those thrusters are.

On a different note, according to the book, the overall length of the PAO mesh seems right, but the proportions of each section might be a bit off. But even assuming the few measurements it has are correct (for what it's worth, it says the thermal sensors are ion sensors, so what else is wrong), it's not that easy to find proper measurements even for modern Soyuz. Maybe I ought to go to Leicester with a tape measure.

 

[diogom]

So it doesn't seem unreasonable to put it roughly where those thrusters are.

Nope. TM/TMA documentation is clear, centre of mass in a fully loaded ship is in the SA seating area. It's also more specific by giving either -2650 mm or -2750 mm in the X axis (so starting at the plane of attachment to the rocket and going backward longitudinally). There may of course be differences to the older design, but looking more likely I actually have it right currently, and just have to accept correcting torque. Full quote from "Конструкция и компоновка (КиК) транспортного корабля «СОЮЗ ТМA»" after translation:

"The linked coordinate system (СвСК) is formed by parallel translation of the axes of the construction coordinate system to the center of mass of the transport ship. The center of mass is located in the area of the crew placement in the seats in the SA. The coordinates of the center of mass in СвСК are as follows (ship in launch orbit, solar panels and antennas are deployed):

x ≈	– 2,75 ± 0,1 м	–2750 ± 100 мм
y ≈	± 0,02 м	± 20 мм
z ≈	± 0,02 м	± 20 мм

"
I do wonder if it's an intentional design choice (and if so, why), or just something they had to live with given the structure.

 

[diogom]

Been looking into the digital unit (БЦИ). For now, its only use in the sim is to monitor the remaining Delta-V and input the desired Delta-V for an SKD burn. This last one was simplified, but I've been looking into just how much. The result is finally seeing a purpose for the "Settings" (Л) column in the KSU, partially shown here for 7k-OK from Tiapchenko's article, and the BTsI illustration:



The rough translation of the BTsI's section in that article has this to say:

"The device consists of six electromechanical decimal counters of drum-type sequential pulse counting with electromagnetic stepper drive and electroluminescent indicator with the inscription "Backup SKD". Five counters, designed to control the input settings, have 2 stepper drives each, which allows counting pulses both in the forward and reverse directions. The sixth counter ("SKD resource"), designed to control the remainder of the working fluid in the SKD cylinders, operates only in the reverse counting mode. At the stage of automatic correction of the flight trajectory, the values of the angles of rotation of the astrodome to the azimuth and elevation angle of the Sun - βс and γс, the angles of rotation of the object relative to the associated axes - αх and αу and the values of the setting for the operation of the correction engines (SKD impulse) are received at the input of the setting counters in the number-pulse code.

The counters of the settings in this mode are indicators, by the readings of which the cosmonaut can judge the magnitude and direction of the action of the impulse of the correcting engines, necessary for a given change in the trajectory of the spacecraft.

At the stage of manual correction, the cosmonaut enters the settings manually using special racks. The value of the settings is communicated from Earth. When entering, the counters work in the reverse mode. The input stops upon reaching zero, when a signal about zeroing is received from the corresponding counter. The reading frequency is 16.66 Hz. The gear ratio from the stepper drive to the drum of the least significant digit of the counter is chosen such that the receipt of one pulse changes the counter reading by 0.044 m/sec, which corresponds to the actual increment of speed during the operation of the engines for a time equal to the period of one pulse of the frequency of 16.66 Hz. (...)"

The ASTP doc also makes direct reference to "settings" in the context of these BTsI values, so I think it all firmly establishes the connection between KSU and BTsI.

My takeaway for the overall functioning is, the internal electronics send a certain number of pulses to the unit to rotate stepper motors, which set the right digits in the right counters. This is for when for example a burn is commanded by the ground, it will display the Delta-V it is targetting, and the angles for the burn. Unclear if it will also count down the Impulse counter as the burn happens down to zero, whether in automatic or manual burns. Interesting to note that the 0.044 m/s for each 16.66 Hz <-> 60 ms it mentions doesn't seem to line up with the engine thrust and vessel mass as documented. It works out to ~0.73 m/s^2, which for the stated thrust of 4090 N, would make the vessel mass much lighter than the stated 6800 kg (like 1000 lighter). Or the other way around, for 6800 kg, it would make thrust quite a bit higher. Anyway .

The manual input is more interesting. It would seem the cosmonaut would set the needed counter, and in reading mode pulses would then be sent to the stepper motor, in the reverse direction. It counts how many pulses it sends until it reaches zero, and that's how it knows what the cosmonaut entered. So at the end of the input stage, we'd end up with the counter at zero. I am then assuming that the process for the Delta-V would then work something like this:

-KSU L-1 press, manual settings on. What this would do internally/logic-wise, not sure, I suppose set the respective systems to expect inputs and stop any automated changing of the counters.
-Use the BTsI knob to set the desired value in the counter.
-KSU L-11 press, SKD impulse. The """computer""" then starts reading it by counting downwards to zero. Makes sense that there would be no off action for this mode (the two squares on the KSU indicator), since it's the equivalent of hitting Enter in a keyboard. This value is then fed into the integrating accelerometer.
-KSU L-2 press, manual settings off.

Something similar would happen for the angles for manoeuvres, I suppose. They seem to be unidirectional with the free gyros at least, so no signs, though I struggle to see then why there would be 4 digits for something that's between 0 and 360. There could be one decimal place, though unlike for the Delta-V's that's not depicted in any illustration nor visible in photos.

Remaining question is, why do the knobs move, what role does that play. From the look of it and photos showing them in a different position, it seems they move linearly left or right. I can't really reconcile them with the reading process if there's already a key to read data in, so my assumption is it could be a way to select which digit to change in the counter? With several detents in which the knob sits for each digit. The Globus has a similar concept to set the orbital period, but with a concentric knob. It's described above as "the cosmonaut enters the settings manually using special racks", the specific term for racks used in the original being кремальер. That directs me to rack and pinions type stuff, among other things, so it leads me to believe this motion of the knobs is what racks refers to. It would track, pun intended, with why the solar azimuth seems to have a wider rack(?), having one more digit than the others.

 

[diogom]

New ИНК feature!

The latitude scale is now tied to the actual motion of the globe, no more cheating getting the latitude from the API. Small thing, but it's one step closer to the mechanical wonder the real unit was.

Longitude to follow, which will be a bit trickier with more variables involved (Edit: or atan being fn annoying to work with). Based on good old Tiapchenko:



Inclination is of course constant, t/T is directly equivalent to the current animation state for the globe's orbital motion, just offset by 0.25 to account for the 0 state in the globe animation being the northernmost excursion of latitude, while the expression references t = 0 at the equator.

 

[Zenith]

New ИНК feature!

The latitude scale is now tied to the actual motion of the globe, no more cheating getting the latitude from the API. Small thing, but it's one step closer to the mechanical wonder the real unit was.

Longitude to follow, which will be a bit trickier with more variables involved (Edit: or atan being fn annoying to work with). Based on good old Tiapchenko:

View attachment 41608

Inclination is of course constant, t/T is directly equivalent to the current animation state for the globe's orbital motion, just offset by 0.25 to account for the 0 state in the globe animation being the northernmost excursion of latitude, while the expression references t = 0 at the equator.

That Globus made it until 2004! Globus inside;

 

[diogom]

That Globus made it until 2004! Globus inside;

Yep, I'd seen it, it was an epic find. Firing up the electroluminescent was the cherry on top. Wish they could get their hands on more, they were also a great source when doing the clock.

I did also find this the other day: https://www.rrauction.com/auctions/...nformation-display-system-control-panel-left/
Now I'm not saying it's cheap, but honestly, I easily expected at least double... Some other items also sold, including its right seat companion. From the lack of the dedicated SSVP/SKGS row, guessing 7K-OK sim hardware.

 

[diogom]

Longitude to follow, which will be a bit trickier with more variables involved

It is indeed putting up a fight. The Earth rotation part ended up being simple, that's working already, the longitude scale matches up with the globe crosshair when adjusting it at any latitude. The ship orbital motion, however, isn't adding up.

I've found other sources on longitude and they corroborate the Tiapchenko expression, so the math seems to be right for longitude in a circular orbit. However, while the four special angles match (0, 90, 180, 270, all hit at the right fraction of the orbit), anything in between is off between calculated angle and globe position, even when removing Earth's rotation as a factor. Must be something I'm missing in adapting the math into Orbiter, or with the globe implementation. Need to plot out what I'm getting visually on the globe vs the calculated angle, see if anything pops out.


(atan2, with negatives adjusted by +2pi, ignoring Earth's rotation)

 

[Urwumpe]

Can also be the case, that the globe instrument is simply less accurate than Orbiter. I doubt periodic perturbances are correctly calculated by that mechanism - while Orbiter and the real world have them.

 

[n72.75]

Can also be the case, that the globe instrument is simply less accurate than Orbiter. I doubt periodic perturbances are correctly calculated by that mechanism - while Orbiter and the real world have them.

I think the error is between expected instrument output and the implimentation, not between Orbiter and the inplimentation.

 

[diogom]

Can also be the case, that the globe instrument is simply less accurate than Orbiter. I doubt periodic perturbances are correctly calculated by that mechanism - while Orbiter and the real world have them.

Thing is it's no longer tied to the ship's actual position in Orbiter, it's all tied to the globe's animation. Basically I'm substituting the t/T in the expressions with the globe's orbital animation state, 0...1, which increments at a rate depending on the orbital period (or at a higher fixed rate when using the adjustment knobs), then the calculated angle determines the animation state on the longitude/latitude scales. The globe's motion itself lines up with Map MFD reasonably well, short term at least, and the latitude scale matches up visually with the globe. And by rotating it around the poles manually (using the corresponding knob), it also matches up (that's the omega * t bit, translated to polar_animation_state * 2*pi), so wherever the crosshair lands on, the scale reflects it.

But with longitude in orbital motion, what I'm getting is, for example: starting at the globe's default position, as modelled, which is 0º longitude and ~51.7º latitude (=inclination), and manually rotating along the orbital track a bit, the globe shows ~30º longitude, but the scale shows ~12º:

And the 12º add up with the math based on the current animation state, so the code seems to be correctly converting between angle and scale animation. The exception is 0/360, 90, 180 and 270 line up between scale/math and globe, which makes sense since those will always be hit at the same orbit fraction (0, 0.25, 0.5, 0.75, 1).

FWIW the globe mesh is a perfect sphere, which isn't the case with Earth, though it doesn't seem that the expressions account for that anyway. The meridian markings are evenly spaced, at 15º intervals adding up to 360º. There could be errors with projecting the rectangular texture on a sphere, or the texture itself, but I'm not seeing how longitude of all things could be problematic, as long as it's all evenly spaced and converging at the poles, which looks right on the mesh.

I mean if instead of cos(i) I brute force some value > 1 through trial and error, I could maybe get there. But I'd have no understanding of why.

 

[n72.75]

@diogom Could you post your code?

clear;
clc;

function l = GlobusLong (t, inclination)
  l = 0;
  if(t >= 0.0 && t < 0.25)
    l = ((atan(cos(deg2rad(inclination)).*tan(2*pi.*t))))/(2*pi);
  elseif(t >= 0.25 && t < 0.75)
    l = ((atan(cos(deg2rad(inclination)).*tan(2*pi.*t)))+pi)/(2*pi);
  elseif(t >= 0.75 && t <= 1.0)
    l = ((atan(cos(deg2rad(inclination)).*tan(2*pi.*t)))+2*pi)/(2*pi);
  else
    l = -1; ## error;
  endif
endfunction



t = linspace(0,1,1000);
inc = 51.8;

lambda = zeros(1,length(t));
for ii = 1:length(t)
  lambda(ii) = GlobusLong(t(ii), inc);
endfor


plot(t,lambda)
xlabel("Phase");
ylabel("Longitude State");
grid on;
grid minor;

Probably not a great implementation^^.

Is your 0.25 offset giving you a phase error? Like, are you lagging by the amount you should be leading?

This is what I'm getting:

 

[Urwumpe]

OK... I just remembered that 0, 90, 180, 270 are also the points where the insertion errors of an orbit are minimized, which is why almost all ICBMs are stationed at points that put them about 90° from their likely targets....

 

[diogom]

@diogom Could you post your code?

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

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.