Project Soyuz 7K-T Custom

Gargantua2024

The Desktop Orbinaut
Joined
Oct 14, 2016
Messages
1,042
Reaction score
1,250
Points
128
Location
San Jose Del Monte, Bulacan
Indeed, since all subsequent solo flights of the 7K-T variant (except Soyuz 13 because that too had solar arrays) never last beyond 2 days because of chemical battery limitations. It might be that Cosmos 496's service module was even a leftover 7K-OK or 7K-OKS hardware
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Yeah, that's what it sounds like, Soyuz book mentions it was an already built ship (number 33 I think it was). Some post Soyuz 11 modifications, but removing solar wouldn't be as simple as just removing the arrays on a finished ship.
I'm guessing Zak there just assumed it had none and power saving sounds plausible enough to explain 6 days. Chertok is inconclusive on this too.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Some more thoughts (I like dropping info all in one place as I find it in case someone out there Googling finds it helpful, considering how spread out it is online):

For one, I've settled on operating voltage range between 34 V down to 23 V. This was so for Soyuz-TM and it probably did not change. Silver-zinc also seems to be known for a pretty flat voltage curve, so I've estimated that down to 10% charge left, at which point it drops much faster from 32 V to 23 V. Also as far as -TM goes, the warnings seem to go off when 24.3 V is reached, seems reasonable for 7K-T as well.

Found a curious thing: Soyuz-TM solar panels are stated to output 26 A at 34 V at a maximum. So 0.88 kW, just a bit over Astronautix's claimed 0.84 kW average consumption. Seems a bit too close to be a coincidence, even being completely different ship generations, my first guess is that allows it to meet the max power demands and have some left over to charge the buffer battery. For 7K-OK Chertok mentions 23 to 25 A needed to charge the battery, which I'm interpreting as "worst case, maximum power drain isn't above 850 W (25 A at 34 V)".
7K-T of course has no solar panels so charging is irrelevant, but I can extract info from it. So feeling a bit more confident about picking 0.84 kW, or something in the ballpark, as the base consumption rate on top of which I can add the equivalent for certain systems, like SSVP or IKP, when on. Having an actual value makes it easier for the individual systems I do have numbers for.

On that note, the INT dial now displays the current voltage, as calculated from the current battery charge, low voltage signal is tuned for 24.3 V on the main battery, and main, backup and SA batteries are in the code. Battery life is just a bit under 48h currently, not counting the backup battery, and SA battery is similar to the backup in capacity.
Next is actually making main and backup interchangeable for when main is about to die, working in the consumption variations I have for the moment, and ultimately the nuclear option: power goes out, ship is dead. Dead electronically that is, switches still move and of course, backup battery can still be connected from a dead main battery (independent bus).

1666753108044.png
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
Hi Diogon,

i am trying to follow your flight tutorial ... really helpful, almost managed to do a full mission, but still something i am doing wrong, so please if you could explain i would be highly appreciated.

1) when you need to set the orbital period in the "globe" ... i saw that in the pdf manual you can control/set also the decimals after the minutes (the 2 red digits), but both using the english / russian text i don't get these two digits to appear ...is a my computer graphic issues? maybe screen resolution?

2) about setting the "globe" once in orbit...not sure if i am doing correctly: once in orbit i open mapMFD and i read off the lat/long position, than i move the globe with the inner/outer knob to have the crossair to the same approx lat/ong (=as written in the globe chart (the grating...)) .... and i also see if they coincide with the values displayed on the globe lat / long indicators (left/top) ... is ok doing like that?

3) didn't get how to engage "orientation to the sun" via M-16 command: basically once in orbit i enter into prograde attitude, once the orientation is established i get sensors errors 1 deg, than i switch the mode off via K-2, i wait to be in day light to see the sun and i do: K-4 to activate the BDUS and then M-16, in the HUD i got the message that the soyuz is rotating to acquire the sun but it seems never enter into the attitude, it keep slowly spinning and i never see the "45K aligned" message ... do i need to be in free drift with all rates to 0-0-0 deg/sec before to engage this mode? or am i not engaging the program K-4 correctly?

3) how to use P-6? when i am suppose to use it? you didn't mention it in the manual as well as in the flight doc but i saw you add it in your command matrix...

5) about the rendezvous ... i am practicing using the scenario you provided at approx. 100km distance ... at 30 km i engage the igla for approach ... i saw it fires thrusters and it Chage orientation but i arrived at approx. 5-6 km with still more than 20 m/s velocity and it didn't null it, basically i just miss the salyut .... the breaking burn (to null the relative velocity) was supposed to be done by the igla ? of should i fire the SKDU manually ? if so, when? (i guess it may also be a my computer issues, as i saw that with the vizor implemented i now have very low fps ... ) .... i loaded that scenario with the two vessel docked, i undock and go away few kms than i engage the igla and try the approach again and this time it docked. So maybe i am missing a manually activate SKDU burn , after the one done to intercept the salyut with transX?

thank you for any suggestions.
nice craft...
 

Attachments

  • test 1.JPG
    test 1.JPG
    11.2 KB · Views: 4
  • red digits in manual.JPG
    red digits in manual.JPG
    11.6 KB · Views: 4
  • russian no red digits.JPG
    russian no red digits.JPG
    16.3 KB · Views: 4

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Hey, thanks for the feedback

1) when you need to set the orbital period in the "globe" ... i saw that in the pdf manual you can control/set also the decimals after the minutes (the 2 red digits), but both using the english / russian text i don't get these two digits to appear ...is a my computer graphic issues? maybe screen resolution?

This one is weird. I've been somewhat dreading resolution issues, since I'm testing on one machine/screen only. It's 1080p but I run it windowed at slightly less than full screen. But not sure yet if that explains it, the first counter looks fine. As I understand it, Orbiter operates on the fixed size textures. Just to be sure, this is with D3D9 right? And it's just for the period counters? So the rest of the globe instrument, the clock's elapsed time counters, digital unit's Delta-V counter, all good?
Edit: actually, even the "90" is missing the contour around the digits, which should be fixed in the texture. Can you confirm if this bit of "Sirius7k_Dynamic_Displays.dds" in Textures\Sirius_7k\ looks like this? You might need something like Paint.NET to open it. Maybe there's some conflict with an older version of the texture.

1667062932182.png

2) about setting the "globe" once in orbit...not sure if i am doing correctly: once in orbit i open mapMFD and i read off the lat/long position, than i move the globe with the inner/outer knob to have the crossair to the same approx lat/ong (=as written in the globe chart (the grating...)) .... and i also see if they coincide with the values displayed on the globe lat / long indicators (left/top) ... is ok doing like that?

Yeah, that. In real life I guess all they had was looking out of the windows/vzor, and it kinda helps that it's a fixed inclination, so it's a matter of "how far in a straight line from Tyuratam are we". But that's not always easy even in Orbiter without MapMFD. Especially since the Soyuz 18-1 scenario launches into a sunset.

3) didn't get how to engage "orientation to the sun" via M-16 command: basically once in orbit i enter into prograde attitude, once the orientation is established i get sensors errors 1 deg, than i switch the mode off via K-2, i wait to be in day light to see the sun and i do: K-4 to activate the BDUS and then M-16, in the HUD i got the message that the soyuz is rotating to acquire the sun but it seems never enter into the attitude, it keep slowly spinning and i never see the "45K aligned" message ... do i need to be in free drift with all rates to 0-0-0 deg/sec before to engage this mode? or am i not engaging the program K-4 correctly?

I'd recommend killing rotation before turning on any of the orientation modes. If that doesn't help, stopping the program (K-1 modes off), killing rotation and re-starting might work. First step is a pitch rotation until the ship's +Y (side facing away from Earth on prograde mode) is within 90 degrees of the sun. Then it aligns the roll channel, and finally does pitch again until it's within 6º of the sun. There's a chance one of these thresholds might fail, and so far I haven't been quite able to reproduce it consistently, but when it has happened reseting helped.

3) how to use P-6? when i am suppose to use it? you didn't mention it in the manual as well as in the flight doc but i saw you add it in your command matrix...

Thanks for pointing it out, forgot to leave a note in. But for now it's very minimal. Basically, depending on whether the Free Gyros ("off") or BDUS ("on") are selected, the maximum deviation in attitude when the Inertial Orientation mode is on is either 8º or 6º, respectively (if that is exceeded, the mode is automatically switched off). In theory, since Inertial actually corrects the attitude in pitch/roll/yaw when each changes by more than 2º, this condition should never be reached. I'm still not sure from what I've read if Inertial actually corrected back, or simply stopped rotation over a certain threshold, and over time an error would accumulate and reach either 6º or 8º, at which point you would need to re-orient the ship. Lately I've been leaning towards the latter.

Anyway, whenever programmed manoeuvres (in attitude) are implemented this will play a bigger role, since choosing one or the other had an effect on how quickly it rotated, and for example with the free gyros the manoeuvres were done only in roll and yaw.

5) about the rendezvous ... i am practicing using the scenario you provided at approx. 100km distance ... at 30 km i engage the igla for approach ... i saw it fires thrusters and it Chage orientation but i arrived at approx. 5-6 km with still more than 20 m/s velocity and it didn't null it, basically i just miss the salyut .... the breaking burn (to null the relative velocity) was supposed to be done by the igla ? of should i fire the SKDU manually ? if so, when? (i guess it may also be a my computer issues, as i saw that with the vizor implemented i now have very low fps ... ) .... i loaded that scenario with the two vessel docked, i undock and go away few kms than i engage the igla and try the approach again and this time it docked. So maybe i am missing a manually activate SKDU burn , after the one done to intercept the salyut with transX?

Yes, my code is too realistic, it even simulates Igla unreliability :D
No, I've since noticed this too, and yes, Igla should be full auto.
For the last version I changed the scenarios a bit to have Salyut a bit further away on launch time, but the pre-rendezvous scenario is still based on the older case. So since Igla was working every attempt on that one, I figured it was ok since the flight profile would always be very similar (foolish, I know). But the other day I did a flight from launch with the new Salyut position, started the approach under seemingly the same conditions (transX setup, phasing orbit of 250 km, approach from below, Igla on at 30 km) and Igla just refused to do any burns. I think it's skipping something in the sequence and probably "thinks" it's already done a burn or two which it didn't. I'll need to setup a convenient scenario to reproduce it and debug it. During the approach, up until 1 km or so, how do the "Burn_seq" and "LOS burns values change?

I'd have to double check during approach specifically, but I've been mostly keeping stable 60fps. I've been concerned if some things might break at lower frames, and don't want to discard that, but since we apparently had the same issue, frame rate might not be the issue here. Hopefully. I'd expect thruster burns to be less accurate but not cease to exist. But it is strange you get it on a scenario which for me works, since in that case the initial conditions are the same (speed, trajectory).

The battery stuff is mostly done for now, IKP was the plan next but since discovering that and if it's also happening to others, I think I'll tackle Igla next, can't stay like this. I was going to revisit it anyway, since right now the way the relative velocity is calculated is very sensitive to rotation, which leads to high and false readings during rotations. I'd also like to eventually review the orientation autopilots, since they were done pretty early on and I might be able to do a bit better.
 
Last edited:

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
Hi Diogon,

Thank you for your fast reply, I am not so fast as you …

1) About the globe and missing red digits … thanks to your guide I find out what I was doing wrong; I just reinstalled a new orbiter 2016 + your new version and everything is ok, I get the red digits to set the decimals part of the orbital period both using Russian and English cockpit (before I just unzipped your new version on my old installation, so some files were not properly copied/updated) ... basically i saw that in the texture folder there is only a english folder, containing not all files resident in the texture folder itself; in my case i saw a russian folder (=meaning that i did it, coping all russian files, before to copy the english files into the texture folder, but i also saw that the file with the digits is not in the english folder, so it was supposed not to be changed, as i didn't realise it, when the new revision come out i immidiatly copied the english folder and so i overwrite the new file with red digits with the old one, and even going back to russian i was still coping the old file without red digits....sorry for the confusion.

2) ok, thanks to confirm.

3) ok, indeed calling mode-off and killing rotations than solar orientation did engaged.
I realized that when it got mad I was in orbital orientation established in orbital pitch rate, than I called mode-off but of course the angular rates were not zeroed … upon zeroing them and go to solar orientation everything worked as you said … thanks.

4) about the gyros and BDUS … sorry, it WAS described in the new manual, I just missed it, so you didn’t forget to mention it, I just missed to read it, now everything is clearer

5) ok…I will try to re-check the scenario and I will also try to plan the rendezvous from lift off and I will let you know…maybe it will take me few days to try it out…
about the flight guidance modes: .... I did see that when the igla was running there were some sort of “sequence numbers” … I remember to have seen 3 and 8 I guess … is it possible for you to explain which number correspond to which phase? So I may try to follow more closely what igla is doing at each step?
Anyway, I will try again and report to you all events.

Nice to see the battery is almost over and you were already thinking to implement the programs…that’s would be really nice.

A side question about SKD DV burns …. I saw that once you know how much DV you need to burn, say 30 m/s, by activating the accelerometer and firing the SKD when the accumulated DV in the HUD get to 30 m/s you may cut off the engine; but all this is done looking at the HUD … how this “cut off” was supposed to be performed by the crew? Using the programs that you were mentioning you are going to implement?
Or were you suppose to set the DV in the DV counter next to the reserve DV counter (i saw that it is set to 50.5 but the number can be changed with the knob below, but it never change upon firing the SKD) and upon ignition it was supposed to count down to zero, signaling the crew when to cut off the engine? or the engine was automatically cut off?

very weird automation/avionic compared to Gemini/Apollo S/C back then ... still i am amazed by the simplicity of the cockpit and instrumentation design, so that after all they were using much more automation than US spacecrafts at that time .... or in reality the crew had to rely heavily on ground communications to know the spacecraft system status, orientations, orbital data and so on .... ?? just wondering...

Thank you for now.

I would like to discuss with you some others Soyuz issues, general topic not specific to this project of your, can I send you a PM to avoid cluttering this post?
Thanks!
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
Hi Diogon,

I just tried again the rendezvous from the default scenario “Soyuz 18-1 pre-rendezvous”.

As I noticed that in the VC I get only 18-20 fps while in HUD view I got 55-60 fps (depending if the earth is in view or not) I tried to run the mission almost always in the HUD view and so I also took some screenshots along the way, you can see them sequentially in the zip file, I tried to save one of them anytime I saw something changing in the HUD, like: igla number, LOS burn or Burn seq counter…here are a summary of what I noticed, all details can be read off from the HUD data following my trip.

I engaged IGLA at about 28.5 km from prograde orientation.

From 28.5 to 17.7 km target range I had “igla 1” , “LOS burn”=0, “Burn seq”=0 , DO was firing (ELS indicator)

From 17.3 to 16.7 km I got “igla 12”, “LOS burn”=0, “Burn seq”=0, DO and DPO lights were on/off in ELS indicator

From 16.6 to 15.2 km I got “igla 4”, “LOS burn”=0, “Burn seq”=0, all jets off

At 14.8 km I got “igla 9”, “LOS burn”=0, “Burn seq”=1, DPO firing

At 14.6 km I got “igla 11”, “LOS burn”=0, “Burn seq”=1, SKU firing

At 14.5 km I got “igla 13”, “LOS burn”=1, “Burn seq”=1, SKU cut-off, and DO/DPO firing

From 14.5 to 14 km I got “igla 13”, “LOS burn”=1, “Burn seq”=1, and DO/DPO firing

From 13.4 to 12 km I got “igla 8”, “LOS burn”=1, “Burn seq”=1, and DPO firing

At 11.9 km I got “igla 12”, “LOS burn”=1, “Burn seq”=2, DPO firing

From 11.9 to 9 km I got “igla 12”, “LOS burn”=1, “Burn seq”=2, and DPO firing

Actually from 8.9 to 2.9 km I saw that igla was alternating from “igla 12” to “igla 4” and viceversa many times ...

At 2.9 km I had 25.8 m/s CVEL from dockingMFD, I was in “igla 4”, “LOS burn”=1, “Burn seq”=2

At 2.0 km I saw a change to “Burn seq”=4, the rest was still the same: “igla 4”, “LOS burn”=1, and the CVEL was 17.9 m/s on dockingMFD

After nothing more happened, rapidly the Salyut passed away, the target range drop to approx. 1.5 km, the CVEL drop to zero and then started to increase, as well as the target distance, when I was far away 2 km I took the screenshot, and it was still in “igla 4”, “LOS burn”=1, “Burn seq”=4

At approx. 4 km, 5 km away from the station I saw again DO/DPO activities switching between “igla 4” to “igla 12” in trying to keep centered the station in the docking HUD box (see my screenshots).

I don’t know if I missed the “Burn seq”=3 from 2.9 km (when it was still at 2) to 2.0 (when I saw it was 4) as i was not looking at it or it didn't happened.
(i guess between 2 and 4 there should be a 3rd burn...)

hope this help.

***

Anyway, I have the following questions now before to try again from lift-off:

What is the meaning of “igla 1, 4, 8, 9, 11, 12, 13 modes which appeared in the HUD?
And why there are not the intermediate numbers: 2-3-5-6-….?

LOS burn I guess it is line of sight burn…right?

What is “Intz” ? I saw tha while in “igla 12” it was always changing its value, while on all others “igla” numbers intz was always zero.

Last LOS roll ? why also this sometimes was changing and sometime not?

thanks!
 

Attachments

  • ezyZip.zip
    5.6 MB · Views: 6

thermocalc

Active member
Joined
Aug 18, 2014
Messages
217
Reaction score
78
Points
43
Location
Bangkok
i forgot two others issues:

while the target distance on the hud is almost the same as the distance in the dokcing mfd, why the target range rate is very different from the CVEL ?

next, if you see my screenshots, sometimes you see over imposed to the main hud some weird imagines of the soyuz external green parts ... well when i was taking the screenshot i paused orbiter, than go to VC view to see the ELS display and than back to HUD view ... and upon coming back the double imagine was there, upon unpausing orbiter the superimposed imagine disappeared almost instaneusly ... (just in case you noticed and were thinking why i saved such weird imagines) ... sometime is not there as i save the screenshot immidiatly (withoug hitting F8), but sometime i forgot and i saved once back to hud view and the double imagine was there.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Hey, thanks for the data. Most of that is debug information basically, but I'm glad I left it in. I'll have a look later on, compare to what I see.

I don't have much of a bearing on whether the Igla code is an overcomplicated mess or not, but I approached it as a sequence of several different states, each does it's own thing, and the code cycles through them as needed. These are on the upper left as "Igla x":
  • 1 is the initial rough orientation in pitch and yaw towards Salyut, it only runs once;
  • 2 you can't really see, because all it does is tell Salyut to start it's own Igla, and it's also a decision point based on the initial distance and speed;
  • 3 is the DPO translation correction. It's meant for the final phase, to keep Soyuz from drifting off to the sides;
  • 4 is the fine orientation in pitch and yaw, to keep it pointed at Salyut;
  • 5 is orientation in roll, to align the docking ports on the final phase of the approach;
  • 6 and 8 are the DPO pitch flips to 180º and 0º - so state 6 face away from Salyut, do the burn, then state 8 to face Salyut again;
  • 7 is the burn state, it's either an SKDU or retro burn, depending on that burn_seq and other parameters. burn_seq defines the speed target, for example, so state 7 knows when to stop burning;
  • 9 and 10 are like 6 and 8, but it's pitch down to 90º or pitch up to 90º - this is for the initial phase of the approach, the Soyuz uses the SKDU to cancel the lateral drift since it's more efficient that way (the DPO thrusters are too weak at large distances). So if a braking burn was just made facing away from Salyut, and a lateral burn is next, it chooses state 10. Otherwise, it chooses state 8 to point at Salyut again;
  • 11 is a dedicated state for that burn at 90º;
  • 12 is a special case of roll alignment to point the lateral drift vector towards the ship's +Y. There will always be some lateral drift which builds up over time, because the orbits of the two ships are different. Basically since Soyuz could only pitch 90º in the down direction (due to the antenna's gimbal range and position), you want Soyuz to be moving "up" relative to Salyut, so that when it pitches down 90º, it's burning in exactly the opposite direction.
Burn_seq was my way of changing the speed targets and the sequence, so the algorithm knows when to choose each state. It always starts at 0, and depending on the inital approach speed and distance when Igla is turned on, it decides on the next value. For example, 6 is to slow down to 0.3 m/s under 200 m, and 8 is sort of a loop which redirects to burn_seq 6 if the speed gets too high. LOS burn is a counter for how many of the 90º burns have happened, because throughout the approach, there are fixed distances which trigger one of those. Every time one happens, or isn't needed, it increments. So throughout the approach, these two values guide the sequence by keeping track of where it is in the sequence.
For a ~30 km start, after states 1, 2 and 4 run once, it should first use state 12 to roll correctly, then do a 90º burn, loop on state 4, and then at 10 km or so do the first braking burn. It's also possible it has to roll again after that first 90º burn, depending on the trajectory.

Intz was something I had to come up with for state 12. I get the angle between the drift vector and Soyuz's +Y axis to know when they are aligned, but was having trouble because it all broke down when the ship is rolling, it failed to stop at the right time. So now, when Igla decides it needs to roll using state 12, it saves how much it needs to roll. Then, as state 12 rolls it, it integrates the angular velocity over time, which is equivalent to "how much has it rolled so far", this is Intz. At the appropriate accumulated value, it starts cancelling the roll. So now, instead of comparing with the actual drift vector until the difference is small enough, it's a "dumb" "roll by x degrees and it should be close enough". Closed loop vs open loop, I guess.

On paper it makes enough sense to me, but I reckon with all the different thresholds, it's kinda hanging on wires and there's a lot of potential for specific situations to break the whole thing. I think the best I can do is gradually catch as many as I can and account for them.

As a side note, I'll try to work something up for the next one to have the Vzor "off" when not needed. If it has a significant impact in fps, it shouldn't be forced on. IRL the peripheral screens have shutters, and I think they have a lid to put on the central screen.

A side question about SKD DV burns …. I saw that once you know how much DV you need to burn, say 30 m/s, by activating the accelerometer and firing the SKD when the accumulated DV in the HUD get to 30 m/s you may cut off the engine; but all this is done looking at the HUD … how this “cut off” was supposed to be performed by the crew? Using the programs that you were mentioning you are going to implement?
Or were you suppose to set the DV in the DV counter next to the reserve DV counter (i saw that it is set to 50.5 but the number can be changed with the knob below, but it never change upon firing the SKD) and upon ignition it was supposed to count down to zero, signaling the crew when to cut off the engine? or the engine was automatically cut off?
I actually haven't seen any direct references to the counter decreasing during a manual burn, but maybe I missed/forgot something. It would make sense that it did and I think that's the case, but the info I've seen is more along the lines of knowing how long a burn should take. In any case, it was also used by the automatic burns, in that case they would input the delta-v and the program would use it for the burn. It's also likely they could have a semi-auto SKDU burn: since there's a "SKDU impulse" command on the KSU, and the separate "SKDU on/off" buttons on the main panel, I'm thinking through the buttons it was fully manual, but through the KSU it would start when you commanded it but turn off when the input Delta-V is reached. The idea with the main programs (as in Manoeuvre and Descent) is they consist of several "subprograms" (like orbital orientation) and commands (like activating the accelerometer), which are turned on sequentially on a time scale. The crew was supposed to be able to command each step manually in case the timing unit failed to, so it makes sense that option would be available.
But basically I'm leaving the VC side of the accelerometer for when the programs are implemented.

I would like to discuss with you some others Soyuz issues, general topic not specific to this project of your, can I send you a PM to avoid cluttering this post?
Sure, no problem.

while the target distance on the hud is almost the same as the distance in the dokcing mfd, why the target range rate is very different from the CVEL ?
That has to do with how the distance is calculated. Angles and speeds are calculated based on distance to Salyut's centre of mass, but for the displayed distance I adjust to distance to docking port. But the docking port is some 7 m away from the centre of mass of Salyut, plus it's not very well tuned. But even at small distances it shouldn't have a big impact.

next, if you see my screenshots, sometimes you see over imposed to the main hud some weird imagines of the soyuz external green parts ... well when i was taking the screenshot i paused orbiter, than go to VC view to see the ELS display and than back to HUD view ... and upon coming back the double imagine was there, upon unpausing orbiter the superimposed imagine disappeared almost instaneusly ... (just in case you noticed and were thinking why i saved such weird imagines) ... sometime is not there as i save the screenshot immidiatly (withoug hitting F8), but sometime i forgot and i saved once back to hud view and the double imagine was there.
Only when paused, right? That has to do with the camera resetting. On HUD mode, I'm forcing it to the Vzor's point of view on every frame, because if you switch to VC, the camera position changes and it needs resetting when you come back to HUD view, I might be missing a way to separate both cameras. So it looks through the BO, since it's still located near where the seats are. But yeah, Orbiter only updates the position when you unpause.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Starting to do some looking into the Program display, as far as the appearance went. Return From Orbit might be of great use here, on top of the documentation. I'm under the assumption they let them film in old sims (7K would have been retired by then), since the panels look pretty much identical. While the Igla fix should be the next priority, I'm skipping it for now because it's looking like a can of worms I don't have the time for right now, after a first pass at it. Either way, the plan is to get it in the next version, whatever the order of business.

My main question is, besides colours, is it a "lit background with different colour lit text" situation, or only text is lit.

This shot from "Salyut" seems to be an "all lit" test for the panel (or probably, for the ELS and IKP individually pressed at the same time):
1671045746879.png

One point in favour of light blue luminescent text with no backlight for the IKP. Also of interest is the ELS to the left, the bottom three rows are described as green here. Could be variation between models, variation between Soyuz/Salyut, or maybe one of them is misrepresented (flashbacks to "was the DSKY green or blue?"). In any case, while no text is visible it still looks like "text is the unlit portion" still holds weight, as in the off setting, text is barely visible. Later on, they moved on to lit background with overlaid black text on the glass.

But then there's this, seemingly the opposite:
1671046773255.png

But the panel also looks quite smaller and a different shape, so I'm not even sure it's meant to be the IKP (and if not, what then?). Bonus ELS also showing blue, an easy fix from the current green texture if a correction turns out to be needed.

Some other miscellaneous things, there's a 7K-T exterior model which at first glance seems accurate and could be useful. Then again, the docking mechanism for example is lacking the "skirt" they added after Soyuz 10 and supposedly continued to this day, so who knows what else about it isn't quite right. Also, another point in favour of a cover for the red critical command buttons (below the ELS). I chose to have none based on Soyuz-35, but I should probably also keep in mind the cover (and other components) could have been removed post-flight for whatever reason, and everything else I've seen depicts the covers. Also should be a simple fix.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Two small corrections made for now:

Had myself fooled by the "контроля" terminology in documentation and had the ELS button as an On/Off, taking it literally as "control", but on closer look plus the above example, I now think it's actually "monitor" and just an "all on" lighting test like found on many aircraft. Same will eventually apply to the IKP. So there:
1671157614822.png

Another thing, for the same reason, had to reshuffle the battery buttons a bit, since what I was using for "Battery On/Off" turned out to be selectors for which voltage/current to observe on the INT. Here, the documentation explicitly uses "control" in the context of monitoring. Now the process is, by default the main battery is always on, the "prepare backup battery" button swaps to the backup battery, and the "remove backup" button swaps them back. So it's either/or. As per Soyuz-TM, and no reason to think otherwise for 7K AFAIK, both can actually be on at the same time for high-load situations, but I'm leaving that be for now. The SA battery is separate and can only come on and be checked after separation, acting as the main battery.

Of the main panel buttons, that leaves only the "mute" button to implement, which will remain useless in the absence of custom sounds. It's meant for alarms, as far as I can tell.

As far as the green goes, whoever is the winner on green vs blue, I think it needs to be toned down a bit anyway. But it does seem pointless to narrow down electroluminescence to one RGB colour, so I might end up taking the Apollo DSKY approach of "neither". Also did some quick experimenting with the "Emission" and "SpecialFX" properties to try and make it look less like a flat, non-emissive colour, but not sure it's going to work.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Got the base IKP texture done for the light test view:

1671334048038.png

This is the version found in the ASTP documentation. Missing is the time ticker, which will have to be separate so it can be dynamically blitted around as time goes on, frequency is once per minute. Most of the rest will be a combination of individual blits depending on the program and time, but the connecting lines will need some creativity, since blitting only works with rectangles and stuff will get in the way, probably.

As for time keeping, there is one thing I've been wondering: which is the more efficient/effective way? Track the MJD to count seconds/minutes, or increment a counter based on the timestep and a scale factor tuned to the interval I want, where reaching 1 means a minute/second has passed. I've used both so far, have a feeling the former might be more accurate over longer periods of time, and the latter depends on framerate more.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,647
Reaction score
1,318
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
As for time keeping, there is one thing I've been wondering: which is the more efficient/effective way? Track the MJD to count seconds/minutes, or increment a counter based on the timestep and a scale factor tuned to the interval I want, where reaching 1 means a minute/second has passed. I've used both so far, have a feeling the former might be more accurate over longer periods of time, and the latter depends on framerate more.

Increment a timer. This is the most flexible and realistic option:
timer += simdt;

NASSP has some clock drift in VirtualAGC, but that is running many many timesteps per orbiter timestep and its only about 0.3 seconds per 100 hrs, at least it was a few years ago, cant remember if we fixed that one.

If you try to go the MJD route, you will eventually encounter a situation where you need to pause or update timer, and the workarounds will grow unmanageable complex and will have the same or worse error, as compared with the more realistic solution.

To use NASSP as an example/cautionary tail again: we have a MissionTime variable that is completely separate from the the Mission timer, CTE, or AGC clock. It's the vestigial remains of days when the mission timer just updated some numbers on a panel, other timers weren't simulated. The result is that it is impossible for us to do countdown holds in-sim until we rewrite a bunch of stuff.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Thanks. Yeah, that makes sense. The analog clock was the first thing I did for the VC, and uses the MJD method, come to think of it, it did hint at getting a bit ugly, and it's not even completely functional. At the very least the numbers aren't intuitive at all to work with. Though I have to say it's convenient for the MET to synch it with the launch time, but it's supposedly editable in-flight. Other than that, only the 60 second delay in deploying antennas after launch uses MJD. Think it was the globe's animation being tied to a specific time gave me the timer idea and since then I've stuck with that.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Happy to report the first two programs, manoeuvre and descent, are in and working:

1671860958286.png

Above the Orbital Manoeuvre program in progress, which will execute a prograde/retrograde SKDU burn 70 minutes after activation, according to the Delta-V set on the BTSI with simultaneous turning on of the inertial hold. The Inertial 1/2 and SKDU Pressurization commands are eye candy for now.

The one weird thing is the descent program has, supposedly, module separation 12 minutes after de-orbit. This makes it well above 200 km, while sources for -TM onwards all point to ~140 km, probably as a timer started at retro burn and a function of the starting altitude. Unclear if this was a change, or the program's timing doesn't actually mean the separation itself (разделение seems as unambiguous as translations go). Either way, the transition to the SUS is smooth, so from orbit to landed with one button click.

Still unclear what the Astro-Orient/Auto-Manoeuvre "side" programs did and how they worked along with these.
 

keelfirst

New member
Joined
Dec 24, 2022
Messages
1
Reaction score
1
Points
2
Location
Planet Nine
Having just got back into Orbiter after many years, I'm very impressed by this addon! What seems like a humble "station taxi" proves to be an interesting challenge to fly, with its analog nav aids and narrow capabilities (the battery update will likely add to this). The slow rotation of the INK globe, the periodic corrections in Orbit Orient mode... there's real charm to this craft.

I've run into some already reported issues - low FPS in VC and Igla failing to dock. After a few attempts Igla's error seemed different but consistent depending on scenario: in the "Pre-RdV" .scn the approach is straight and on target but the SKDU burn is never performed. With a manual transfer from "Post launch" .scn, strange attitude changes are seen after the initial "alignment with Salyut" phase. A single SKDU burn usually does occur, but fails to set up a proper approach.

Very excited to see more - many thanks for your work!
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Having just got back into Orbiter after many years, I'm very impressed by this addon! What seems like a humble "station taxi" proves to be an interesting challenge to fly, with its analog nav aids and narrow capabilities (the battery update will likely add to this). The slow rotation of the INK globe, the periodic corrections in Orbit Orient mode... there's real charm to this craft.

I've run into some already reported issues - low FPS in VC and Igla failing to dock. After a few attempts Igla's error seemed different but consistent depending on scenario: in the "Pre-RdV" .scn the approach is straight and on target but the SKDU burn is never performed. With a manual transfer from "Post launch" .scn, strange attitude changes are seen after the initial "alignment with Salyut" phase. A single SKDU burn usually does occur, but fails to set up a proper approach.

Very excited to see more - many thanks for your work!

Thanks for the feedback, yeah, unfortunate about the fps, I'm a bit blind to that on my end. I suspect the Vzor might play a big part and definitely will prioritise a way of turning it on and off. I think if it's specific to the VC, issue probably lies with all the "screen" updating, Vzor included. I should look into optimising it a bit more, since a lot of these are being updated every frame when they don't have to.
Igla tests my resolve, I'll be honest. Hopefully it's a matter of fine tuning and bug hunting, and not a fundamental issue. I've been thinking though of extending the manual approach with Igla data to the full range, even if temporarily, if it comes down to it. So Salyut will still do its part, and the Soyuz's part can be done manually and still have the info for alignment and speeds.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,354
Reaction score
387
Points
98
Finished reviewing the VC rendering. Now every single "screen" is only updated when a change is needed, driven by a flag, the only exception for now being the remaining Delta-V counter. The background surface to render to is also only defined when an update is needed, so this should help with performance. For the KSU, due to how it's set up, the refresh is periodic instead of event driven (2 Hz for now), since with the growing number of commands and signals and their varying nature, throwing up a flag each time would quickly get too complex. Twice per second seems like a good balance between performance and apparent input lag. If anything, as a silver lining it's probably a bit more realistic to have some delay to signalling turning on and off.
As for the Vzor, both screens can be toggled now, since there's no working around refresh rate. Peripherals linked to the "peripheral shutter" knob, and central linked to the "light filter" knob, seemed to be the most appropriate. For now, they're simple on/offs, the peripherals have physical shutters but I need to look into what those look like and how they work (guessing they are internal somewhere along the periscope, and not "external" covers on top of the lenses) to work up an animation if needed.

Next few steps, figure out an acceptable power drain for SSVP (idle and during mechanical actions), work in the dynamic scales for the current gauge (0-40A or 0-80A, for measuring solar current (INOP) or load current (though I don't know when more than 40 A would be drawn)), some miscellaneous autopilot work, and finally try to improve on Igla. At that point I'd say it's ready for a new release.
 
Top