Project Soyuz 7K-T Custom

[diogom]

...aaand ended up redoing the module itself:

Shape matches up better plus it turned out to be a bit long, is now 2200x2400 mm. SSVP+ring needed a slight scaling up, though once it fit the collar, the hatch works out to bang on the known 800 mm which leads me to trust the proportions on the diagram as it matches there too (after a slight y scale adjustment to fit to the known 2200x2400).

Корабль Тесея, I suppose

 

[diogom]

So I thought this is neat, if not entirely relevant: I'm mostly down to the assorted sensors up front and trying to determine what is what, and went down a TMA rabbit hole regarding ion sensors, because it occurred to me I didn't remember reading about those ever in that context. For 7K that was of course the way to determine angle deviation from the orbital vector, since it directly outputs that error signal. So if they did away with those on the later generations, how the hell do they establish and maintain the orbital orientation?

The IR sensor continues its job of outputing signals relative to the local vertical, in pitch and roll channels, and a corrective angular rate is determined based on that. If when local vertical is aligned the long axis happens to match the orbital vector, naturally the roll rate required to maintain the local vertical is ~zero. If the long axis happens to be perpendicular to the orbital vector, the roll rate is at its maximum and corresponds to the orbital rate (~0.067 º/s). So what they do is assign the yaw rate a value equal to the roll rate multiplied by a constant, and the ship will gradually (0.1 - 0.3 º/s) yaw over to align the long axis with the intended direction. If that doesn't happen within a minute, it sets a more aggressive 1 º/s rate until it passes a certain theshold. Then as the roll rate approaches zero, so does yaw until it's aligned.

 

[diogom]

Some more findings on ion sensors: after finding a missing link (to me) on RGANTD, it seems they used two distinct types over the years, simultaneously in some cases, and would explain some discrepancies. Unclear how they differ functionally.

There's the (seemingly) later type, seen on at least 7K-TM:


Smithsonian mockup with more detail:



But if that's the case, where are they on 7K-OK? Because I've never seen that type of sensor on those, plus the torus in the way of where they'd be:


Enter RGANTD and Salyut 4:


Where 4 is identified as ИД-7 and 6 as ИД-М, both simply "Ion Sensor". Curiously, the latter are facing radially, not along the longitudinal axis. Type 4 I had seen before, but not with this connection. Considering 4, the 7K-OK makes more sense as they seem to match the two features on the torus at 3 and 6 o'clock above. Looking also at Soyuz-9, there they are, just about distinguishable:



Curious though that forward facing type 4 aren't really evident on any of the -OK evidence I've seen, except for this (maybe):



As I understand it this is Kosmos-186/188, which would have been #5 and #6 (the IR sensor was introduced on #7 due to ion unreliability). Maybe these were covered later on to help with the recurring issues? I recall there were issues early on with thruster interaction with the ion sensors, among others, per Chertok.

The ASTP documentation backs up the existence of three ion sensors on 7K-TM, but in the next paragraph also backs up what the KSU matrix says: selection is between two sensors, not three. Does this mean only the two aft facing ones have redundancy? Perhaps due to, as in other aspects, the focus on the reentry contingency. The RGANTD stuff does seem to reinforce to me these sensors only work in one direction (with a 60º FOV, which has other implications), so it would make sense to have them at both ends for prograde and retrograde, and would thus make it an imperative that at least one be present on the BO as well, on both 7K-OK and 7K-T.

This is my current struggle, because consistency in what little I have found of 7K-T doesn't exist much and I don't think I've unequivocally found either type on any example. Makes sense that things might have changed a bit over the years, spanning a decade and several stations, but it seems practically impossible to date anything precisely.

Four such examples of varying configurations:

 

[diogom]

Hit a photo and video trove hiding in plain sight: https://www.kosmonavtika.com/vaisseaux/dos/missions/missions.html






Should also point out some of what I've been seeing, including what was referred to as Soyuz-31 a few posts back, is in fact Progress, which looked like this:

Lack of Vzor of course, the single light on Plane I forward, the mast at 45º further aft between Planes I and II, and overall different setup of cameras. Soyuz itself is looking like cameras on Planes I and III, off centre, with light(s)(I would guess) next to the Plane III camera:

Ion sensor TBD.

Also have established that on 7K-T the BO depress manifold was forward on the BO, between Planes I and II around 45º, as visible on multiple angles of Soyuz-10, Soyuz-25, Soyuz-26, one other unidentified 7K-T which may very well be Soyuz-26 though, Soyuz-40 and 7K-TM (both ASTP and -22).

 

[diogom]

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.

Long time overdue, but anyway this one is fixed. Ballsed up one condition when -180/180 was the target and it was unintentionally practically always true. Couple more gremlins to work through on the attitude hold part from looking at preventing the situation that sometimes shows up where two opposing thrusters are stuck on.

BO is pretty much done for now, some minor PAO improvements too. I think I might need to go deeper on the PAO later on due to geometry but I don't want to get too distracted by more visual stuff until the next one is out. I think the focus now should go back to systems and dynamics (I have some ideas here but they're not structured enough yet).



Here's some Soyuz-40 eye candy, featuring what seems to be Igla at work with some pretty thruster plumes narrated in Romanian:

https://www.kosmonavtika.com/videos/saliout6ep11-v7.mp4

 

[diogom]

Ok, so I've been thinking about something that could make things a bit more interesting/immersive, based on some already existing stuff. Been waiting on properly launching it here to explore one implementation avenue first, but that's probably going nowhere, so f it. [Edit: was wrong, standby]

Basically have some companion application, an MFD would be the obvious implementation option but not an absolute, that functions as a Mission Control of sorts. Handle all the stuff the poor sods aboard Soyuz wouldn't be able to do themselves. I'm not 100% sure what the state of the art is regarding the orbital dynamics stuff, some homework for me to do but I'm not sure if any of the tools can be easily applied to this in such a deterministic way, because there are intermediate steps that only set things up for later. The planning required isn't particularly complicated I don't think, and there's already some good stuff out there, but the Salyut profile was specifically predictable. Launch such that rendezvous happens around orbit 17 in daylight (and potentially over comms coverage), set up the phasing orbit around orbit 3-4, catch up, do a bi-elliptic transfer of sorts with 3 burns: 1st burn orbit raise, 180º later burn to set up the intercept another 180º later with an rvel no higher than 15 m/s (maybe aim for 10 tops), at which point Igla takes over as the 3rd burn (as Kurs does today) within a certain range. So I think this could have the specificity of the profile neatly in one package, among other things, and make it possible to have a self-contained experience replacing using OrbitMFD and whatever else.

Loosely, this is my idea, in no particular order of priority:

• Taking inspiration from N_Molson's implementation back in the day, introduce the idea of communication/tracking zones. As I understand it, the rendezvous profiles are very much conditioned by the ground tracking coverage and the time required to adequately measure orbital parameters and calculate the next move and update info, and it's the reason the 6h or shorter dockings became possible, the tracking and in-vehicle state vectors improved to make it possible. So this orbital info would only be sent to the app when in tracking range for computing stuff, and same goes for outputs only being uplinked after such determinations in comms range;
• The core feature, the rendezvous planning. The launch dates, insertion orbits and station TLEs are known as initial conditions for the scenario. The inputs are the orbital parameters of Soyuz and Salyut at a given time. Given the constraints of rendezvous in orbit 17ish, plan the phasing orbit that allows for it, and the 3-burn intercept. Outputs are burn time and Delta-V;
• Landing opportunities. This would require a somewhat predictable reentry implementation, and defining a few landing spots. Outputs would be orbit number, burn time, and INK landing angle (Ugol Posadki, angle between landing site and de-orbit burn). Delta-V is assumed to be one of the fixed values depending on altitude intervals, though this needs confirming;
• Uplinked relevant orbital information. Output the orbital period for adjustment on the INK. Find some way to determine day-night orbit proportions from the date, altitude and inclination, I'd imagine, and also determine time to sunset/sunrise. This would allow completing the INK's functionality with the sun/shade indicator;
• Make the UI Soyuz-y, whatever the hell that means. Nothing fancy, probably still just text-based, but the display formats at TsUP seem to have stayed consistent over the years, so it'd be based on that. Configurable dual-language support would be ideal.

If I were to do this myself, it would require some amount of time and work in advance, since I'd be starting from scratch on learning how to do this kind of stuff in many aspects, but mostly the orbital dynamics stuff. I mean I'm interested and want to learn more about it either way, but I'd also be open to opening this up if someone's interested, just let me know. Development can probably be done with any vessel as far as I can think of to facilitate things, though obviously it would have Soyuz's limitations and application in mind.

 

[n72.75]

Ok, so I've been thinking about something that could make things a bit more interesting/immersive, based on some already existing stuff. Been waiting on properly launching it here to explore one implementation avenue first, but that's probably going nowhere, so f it.

Basically have some companion application, an MFD would be the obvious implementation option but not an absolute, that functions as a Mission Control of sorts. Handle all the stuff the poor sods aboard Soyuz wouldn't be able to do themselves. I'm not 100% sure what the state of the art is regarding the orbital dynamics stuff, some homework for me to do but I'm not sure if any of the tools can be easily applied to this in such a deterministic way, because there are intermediate steps that only set things up for later. The planning required isn't particularly complicated I don't think, and there's already some good stuff out there, but the Salyut profile was specifically predictable. Launch such that rendezvous happens around orbit 17 in daylight (and potentially over comms coverage), set up the phasing orbit around orbit 3-4, catch up, do a bi-elliptic transfer of sorts with 3 burns: 1st burn orbit raise, 180º later burn to set up the intercept another 180º later with an rvel no higher than 15 m/s (maybe aim for 10 tops), at which point Igla takes over as the 3rd burn (as Kurs does today) within a certain range. So I think this could have the specificity of the profile neatly in one package, among other things, and make it possible to have a self-contained experience replacing using OrbitMFD and whatever else.

Loosely, this is my idea, in no particular order of priority:

• Taking inspiration from N_Molson's implementation back in the day, introduce the idea of communication/tracking zones. As I understand it, the rendezvous profiles are very much conditioned by the ground tracking coverage and the time required to adequately measure orbital parameters and calculate the next move and update info, and it's the reason the 6h or shorter dockings became possible, the tracking and in-vehicle state vectors improved to make it possible. So this orbital info would only be sent to the app when in tracking range for computing stuff, and same goes for outputs only being uplinked after such determinations in comms range;
• The core feature, the rendezvous planning. The launch dates, insertion orbits and station TLEs are known as initial conditions for the scenario. The inputs are the orbital parameters of Soyuz and Salyut at a given time. Given the constraints of rendezvous in orbit 17ish, plan the phasing orbit that allows for it, and the 3-burn intercept. Outputs are burn time and Delta-V;
• Landing opportunities. This would require a somewhat predictable reentry implementation, and defining a few landing spots. Outputs would be orbit number, burn time, and INK landing angle (Ugol Posadki, angle between landing site and de-orbit burn). Delta-V is assumed to be one of the fixed values depending on altitude intervals, though this needs confirming;
• Uplinked relevant orbital information. Output the orbital period for adjustment on the INK. Find some way to determine day-night orbit proportions from the date, altitude and inclination, I'd imagine, and also determine time to sunset/sunrise. This would allow completing the INK's functionality with the sun/shade indicator;
• Make the UI Soyuz-y, whatever the hell that means. Nothing fancy, probably still just text-based, but the display formats at TsUP seem to have stayed consistent over the years, so it'd be based on that. Configurable dual-language support would be ideal.

If I were to do this myself, it would require some amount of time and work in advance, since I'd be starting from scratch on learning how to do this kind of stuff in many aspects, but mostly the orbital dynamics stuff. I mean I'm interested and want to learn more about it either way, but I'd also be open to opening this up if someone's interested, just let me know. Development can probably be done with any vessel as far as I can think of to facilitate things, though obviously it would have Soyuz's limitations and application in mind.

Do we have much information by way of how this was done IRL?

If I understand correctly, you're looking to create something like NASSP's RTCC MFD?

 

[diogom]

If I understand correctly, you're looking to create something like NASSP's RTCC MFD?

I believe so. Basically something tailored to the specific Salyut ferry flight, that simulates the kind of inputs a crew would receive in getting there by way of burn parameters. There wasn't really any onboard navigation capability, any "knowledge" of where it is, that I'm aware of, so it was essentially entirely determined on the ground. Regarding the radio coverage sim, nothing too complicated, just a simple radius/line of sight thing based on historical locations, probably not much point getting into the radio side of things.

Do we have much information by way of how this was done IRL?

Do you mean info about the flight profile? I'm mostly going off the modern procedures with Mir/ISS and Kurs (Ch. 8 of the -TM Crew manual has some stuff, for instance), plus bits and pieces of descriptions from the flights, TLEs, or stuff like Sven Grahn's trackings. There will inevitably have to be some guesswork and approximation since I'm yet to find an actual flight plan put to paper relative to 7K with burn times and technical terms, in the way one might for Shuttle or Apollo. Closest might be ASTP but that was atypical. Things might also reveal themselves more clearly as the thing gets built.

One difference in those days was they selected a one day/17 orbit intercept due to the battery limitation without solar panels, as opposed to two days/34 orbits. Otherwise, I understand they were also constrained in overflying the Soviet Union for orbit determination, and possibly for the docking to be in comms and in daylight. The first 2 orbits are dedicated to checkouts of the motion control system and the docking system, that plus confirming the orbit, leading to setting up the phasing orbit with two burns around orbits 2-3 in TM's case (~20 to 30 m/s stated). Feoktistov mentions (in 1980) up to 4 corrections leading to docking with a station, I would think minimum two, one for phasing, one for the actual intercept. TLEs for Soyuz 17 for example seem to have the phasing orbit quite elliptical, 274x348 (latter was roughly Salyut's apoapsis), up from a 186x249 launch, so I'm wondering if the phasing orbit setup wasn't just one single burn on this one, and potentially one burn to intercept since it has already been half raised to Salyut height.

As far as Kurs goes, the intercept is described such that "The target vector ΔV.пр is the difference between the station circular velocity in the target point and the
spacecraft apogee velocity in the same point.", that being 15 m/s. Considering Igla's limitations and some descriptions of dockings, that seems reasonable for 7K too but incompatible with a direct intercept from a relatively very elliptical orbit since that 274x348 would make it 21+ m/s, thus needing one final orbit raise to intercept. Perhaps 3 total burns if the needed phasing orbit doesn't cross the station's to begin with, 4th could either be for the phasing orbit or maybe an optional correction to account for drag/perturbations (-TM is said to have up to 2 such brief burns in orbit 17-18, with 1 being typical). Though they kept the station orbit consistent across launches.