[18:17:55] NASSP Logging has been started by alexb_88 [18:17:57] animating the hatch today [18:44:04] looks like freenode had a bit of a hiccup [19:08:07] merged the PR from ggalfi [19:14:43] awesome [19:15:28] nice! [19:46:30] that's a lot of vibrations during launch [20:06:07] indy91, did you get [20:06:08] 7>c:\orbiter14\orbitersdk\samples\projectapollo\src_csm\saturnvc.cpp(1593): warning C4101: 'tmpoffs': unreferenced local variable [20:06:25] yes [20:06:32] how dare he add a build warning :D [20:07:34] but he also introduced another Apollo 13 quote so its all good :D [20:12:44] it is a lot of vibrations, but I think it lines up with what astronauts reported in reality [20:13:05] wouldn't want to try and flip any switches in the first few seconds after launch [20:13:09] but afterwards it's ok [20:21:39] yeah [21:58:35] night! [14:41:38] hey [14:46:54] hey Matt [14:56:16] I'm implementing the AGC equations for the RTCC reentry simulation [14:56:20] it's a lot of equations [15:10:13] yeah, I bet [15:11:58] I've never looked at our CM aerodynamic tables, but I imagine those are just arrays of cl, cm, and cd from one of the data books? [15:12:32] basically, yeah [15:12:42] it was a long time ago when I did some tweaks to them [15:15:04] my academic background is actually in aeronautical engineering, so I get excited about stuff like that. [15:26:06] same [15:26:17] the model for the CM is a bit simple, but does its job [15:26:29] the only problem right now is roll resistance [15:26:39] have to turn that down, because a rolling reentry doesn't work [15:26:46] the roll rate gets slowed down too much [15:29:41] would be a very easy change, but I never found any number on that [15:34:33] what file is that in? [15:37:39] CMCoeffFunc [15:37:43] in saturnmesh.cpp [15:37:50] is the aerodynamic coefficients [15:38:18] SetRotDrag is the function that does the resistance to rotation [15:39:14] there are also functions for the launch escape vehicle (CM+LET) [15:39:22] boy did I search long until I found those [15:39:29] or something usable at least [15:39:42] reminds me, we still don't animate the canard on the LET [15:59:26] stepped away for a sec. back now. [16:15:35] yeah, that a hard one to estimate [16:17:17] not a complicated shape, but flow conditions are rather extreme [16:19:23] morning! [16:22:47] hey mike [16:43:05] what's up? [16:48:54] hey [16:49:51] hey Alex [17:02:45] oh, not too much. [17:02:51] hey alex [17:09:20] indy91, vI added the AnimState2 to Saturn class [17:09:23] I* [17:09:30] the side hatch is animated with it [17:25:59] hey guys [17:26:15] by adding you mean added animations.h to the Saturn VS projects? [17:39:55] oh, my RTCC simulation of AGC entry guidance hit the landing target within a mile! [17:40:07] I thought I would have to do days of fixing things... [17:43:10] and I already saw something interesting. There was a change in the AGC, some parameters in the final phase table. Apollo 11 and before overshoot the target in my simulation [17:43:23] While with the parameters of Apollo 12 and later it's undershooting [17:44:56] indy91. to the projects [17:45:02] yes* [17:47:54] oh interesting [17:47:59] the other things is the rotaries that are on the hatches, I couldn't define their animations the normal way [17:48:36] instead, I put those animations directly in the class of the Side Hatch/Forward Hatch [17:49:03] the reason is that those animations have to be a child of the main animation (door animation) [17:49:40] so they really have to be defined together [17:50:36] and nice to hear about the RTCC sim accuracy! [17:51:24] having the animation in the class makes a lot of sense to me anyway [17:51:50] there were two changes, but only one really affects the final landing point [17:52:01] I'm sure we get similar behavior [17:52:19] I'm using the Apollo 15 CM aerodynamic model, could affect things as well [17:53:15] thewonderidiot, fun fact, to simulate the astronaut flying a constant G level during reentry manually they took some parts of the constant drag routine from the AGC and put it in the RTCC sim [17:53:37] hah that is fun :D [17:56:02] so this is going up for auction again next month: https://www.worthpoint.com/worthopedia/apollo-lm-acg-sundance-mit-manual-1840156163 [17:56:16] as are LM-4, CSM-108, and CSM-113 operations handbooks (all volume 1) [17:57:15] a J-mission Volume 1 would be nice to have [17:58:32] alright, I'll focus on that one :) [18:00:05] don't spend any money on my behalf, I'm just saying it would be nice to have a PDF of one :) [18:00:23] I've been wanting a CSM AOH copy anyways [18:00:57] 20160014402 Apollo Operations Handbook: Lunar Module 4 1968 [18:01:04] restricted NTRS [18:02:24] of course any documents with those numbers (and there are a bunch with 2016+) it's a bit pointless to search for an archived version from 2010-2011... [18:02:35] yeah [18:06:33] 19800078134 Apollo operations handbook. Block 2 spacecraft. Volume 1: Spacecraft description 1971 [18:06:54] there is no way we wouldn't be able to get this on the public NTRS [18:07:06] the AFJ is hosting the earlier version of the AOH from 1969 [18:07:36] oh nice [19:20:10] hatches: [19:20:11] https://www.dropbox.com/s/j916mdpfj82j18l/Screenshot%202021-03-26%2013.19.40.png?dl=0 [19:20:21] https://www.dropbox.com/s/pdulju9y5xn7ehd/Screenshot%202021-03-26%2013.18.57.png?dl=0 [19:26:01] those look great! [19:26:34] what are your plans for the open-hatch, docked state? [19:28:22] if you are docked and the hatch is open, it will show the drogue of the LM [19:28:57] and if the LM overhead hatch is open, then you will see the inside of the LM [19:29:14] if thats what you were asking? :D [19:29:50] its basically the same as in the 2D panel [19:30:54] okay, cool. [19:31:15] I have to update the interior of the external view LM mesh [19:31:43] that way you will see more detail from the viewpoint of the CSM looking through the tunnel into the LM [19:33:12] what I am thinking of doing is taking parts of the LM VC and adding that to the external view ascent stage mesh (no switches, just a few panels and details) [19:33:41] that will also make you see a bit more detail if looking into the LM from the external view through the windows [19:38:56] does orbiter have a switch to vessel function? I feel like it must. wonder if we could do that with a click spot [19:40:37] yeah I think AMSO does that [19:40:52] Im sure it can be done with a clickspot [19:41:17] yeah there is a function for it [19:43:19] also, I have been looking for a way to use a click-spot to switch to the 2D panel in a specific view, i.e. for accessing the 2D panel optics from the VC [19:44:00] but I dont know if its possible to switch between 2D/3D panels other then with F8 [19:49:56] hmm [19:50:07] I'm only seeing a function to get the current cockpit mode, but not to set it [19:51:14] yeah [20:29:41] know anything about this custom camera thing https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-579330 [21:09:25] COAS https://www.dropbox.com/s/emxboyxyld4s4lt/Screenshot%202021-03-26%2015.09.13.png?dl=0 [21:22:50] awesome! [21:39:16] fancy [21:41:46] maybe I can even get the COAS switch to turn the reticle on/off [22:02:41] night! [00:42:36] https://www.dropbox.com/s/s27vfxwl8p9m29q/Screenshot%202021-03-26%2018.42.09.png?dl=0 [00:42:39] this is fun! [01:25:53] how are you doing this so quickly? this is amazing. [01:28:33] jsut loads of time really :D Im on call at work, but their not calling me haha [02:01:36] oh, so the forum thread I posted earlier. I'll have to look into it a bit more, but as I understand the d3d9 client api, there is a way to draw a "camera view" on a texture. I wonder if we could do that for the optics. [02:53:46] n7275, sounds interesting for sure [02:55:53] optics right now are probably the only thing I don't have a grasp on how to make for the VC [03:18:00] luckily we have all of the engineering drawings for the optics ;) [03:45:56] gcAPI.h has all the fun stuff in it [03:59:31] gcSetupCustomCamera() oh boy, what can I break with this... [04:32:47] just did a full TD&E from the VC with the new COAS :) [04:33:07] much more fun then it was in the 2D cockpit [04:33:53] don't forget the COAS power switch, it actually does something now! [04:35:21] will have to check that out asap [04:35:39] later tonight, ill push my latest [04:35:51] is it pollinated [04:35:58] *collimated [04:36:05] haha [04:36:17] oops [04:36:35] damn phone [04:36:41] its not projected as it should be unfortunately [04:39:02] the reticle mesh ideally would have been placed further out in front of the CM, and made so its only visible when looking through the glass part [04:39:20] I guess like an HUD or HGS system is [04:42:26] I couldn't get that to work unfortunately as I don't think Orbiter has a way to get the current view angle which I would need [04:45:01] i.e. oapiCameraAzimuth, but that only works in oustide view [04:47:23] hmm, yeah that's a tricky one. [04:47:52] as long as the view position is fixed though, that should be fine. [04:48:21] yeah [04:51:28] I could restrict the camera rotation range..but the downfall is you wont be able to do other stuff that panning around would allow you [04:52:41] and the COAS can be stowed, so that view can be used for other stuff...so I dont think Ill restrict the camera [04:54:42] this view sort of show how I did it: [04:54:43] https://www.dropbox.com/s/avoltsea10k5897/Screenshot%202021-03-26%2022.54.16.png?dl=0 [04:55:26] I wouldn't say its properly collimated, but if you're looking at it centered then the effect is the same I think [05:09:22] ahh, nice. [07:40:34] n7275, latest state pushed [07:40:40] night! [13:38:52] good morning [13:40:20] hey [13:44:34] I think I'm sufficiently confident that my PR won't break anything at this point. if theres anything else you think should be cleaned up, let me know. [13:48:49] ok, I'll take a look [13:55:25] one last discussion of this whole loadResistance/power_load thing [13:55:49] is the fuel cell code the best place to decide how much of a power draw each system does with voltage? [13:55:55] I'm pretty sure our batteries don't do that [13:56:30] so with load sharing and the batteries being the ones powering the CSM the amount of energy required for the same power load is different [13:56:34] hey [13:56:38] hey Alex [13:57:16] so I'm pretty sure we are violating some laws of physics [13:58:38] I would have a better feeling if we were still doing calculations based on the actual power draw [13:58:48] and then maybe do a change to all systems delivering the power at once [14:02:40] I'll have to give that some thought. [14:03:25] sure. Otherwise the PR is in a good state I think [14:03:40] I have more philosphical problems left with it than code problems :D [14:06:01] the batteries are a good point. [14:10:05] I think philosophically the change I'm making is. changing DrawPower( double watts), to DrawPower(double impedance_times_current_squared) [14:14:58] assuming that the impendance is a constant value [14:15:15] which is probably a better assumption than with the power load?! [14:19:17] yeah, assuming impedance is constant. two cases where this might not be true: tungsten filaments at wildly varying temperatures, and loads with inductive or capacitive loads, where we'd be changing the frequency substantially [14:24:57] sounds like a good assumption then, as we shouldn't have anything that varies as wildly as that [14:27:12] yeah, anything like that we'd need something like PSpice for, and definitely couldn't do in real time [15:28:21] I have basically the whole day tomorow free, so I'll take a hard look at the load sharing with the batteries. [15:30:46] sure [15:31:11] but for your PR, please don't make a big change to how our batteries work [15:31:23] if anything make that a separate PR later on [15:32:21] indy91, new COAS is done, I flew a few TD&E's yesterday with it [15:32:34] https://www.dropbox.com/s/s27vfxwl8p9m29q/Screenshot%202021-03-26%2018.42.09.png?dl=0 [15:33:08] looks awesome [15:33:24] and don't think you can get away with forgetting the COAS power switch now :D [18:43:52] in the VC, the ORDEAL altitude rotary does not need to paint the altitude anymore, since the rotary can display many more states of rotation [18:44:31] it just rotates smoothly around now [18:53:03] awesome [18:53:38] listening to RETRO at T-4 hours. I'm trying to find when he is calculating the Block Data 1 PAD that each mission launch with, even lunar ones [18:53:50] launched* [18:54:25] he just said he wants to do some weight and aerodynamic parameter updates, so I think that would come right after [18:54:34] the more numbers he says on the loop the better :D [18:56:13] the logistics behind that PAD have to be interesting [18:56:23] Houston calculates it after T-4 hours definitely [18:56:30] and it somehow ends up onboard [18:56:50] the examples we have are neatly handwritten, so probably not some astronaut doing it while suiting up :D [19:01:57] yeah [19:02:38] I would probably be refused at NASA just based on my handwriting [19:04:46] so I was thinking of making some keyboard commands for the ORDEAL slew switch [19:05:18] since we cannot really cheat in the VC the same way as the 2D panel and have both ORDEAL and FDAI visible at once [19:05:58] how did that work in reality [19:06:13] wasn't the ORDEAL stored somewhere for launch and then put somewhere else? [19:06:29] it is kind of possible in the CM to zoom all the way out and have part of the ORDEAL visible while looking at the FDAI, but thats really awkward [19:07:29] https://www.dropbox.com/s/fqhq21vp9wg80fs/Screenshot%202021-03-27%2013.06.42.png?dl=0] [19:07:40] I think thats the only place it goes [19:08:02] but in reality, its very easy to use the switch while looking forward at the FDAI [19:09:10] I guess that is where the ORDEAL is mounted [19:10:04] ah wait [19:10:09] there is a way I think [19:10:28] you can click the switch in a way to hold it up or down [19:10:46] then quickly turn the view to the FDAI [19:14:27] sounds awkward [19:14:36] no wait [19:14:45] sounds like an ordeal [19:15:16] a bit lol [19:23:11] "That's when Clint Burton [Apollo 10 EECOM] went ahead and had the waste tank [in the CSM] dumped to zero to find out what the zero point was" [19:26:38] I guess related to this [19:26:39] 007:31:47 McCandless: 10, this is Houston. Understand that. Would you be interested in showing a water dump? We're having some problems with the waste-water transducer and we're interested in dumping down to zero to verify the transducer. Over. [19:31:46] NARA has the programming manual for the Apollo Block Data Program, likely having all the calculations of it. A bit better than the user manual, but out of reach for now I guess [20:08:26] indy91, you're right about the batteries. something weird is going on. [20:11:19] they're not sharing load, they're fighting each other. [20:11:48] hmm [20:11:54] load sharing is based on voltage [20:12:00] is the voltage instable? [20:12:06] and it shifts load back and forth? [20:15:38] I think so. will take a fair amount of debug strings to figure out for sure [20:16:21] the fuel cells do not have diodes on their output, but the batteries do [20:18:45] if the batteries were an ideal voltage source, that didn't drop in voltage with increasing current, then that would result in reverse current through the fuel cells [20:19:24] but they're not, thankfully. [20:29:19] all the work you put in for the FC voltages and the batteries are screwing it up, qute annoying haha [20:32:29] indy91, so im down to the last thing to animate in the VC, the altimeter [20:32:48] which I am wondering where to place the animation [20:32:56] hmm [20:33:09] the function for it is RedrawPanel_Alt in staurnpanel.cpp [20:33:24] that should probably be moved to its own class, including the 2D panel [20:33:28] 2D panel redraw [20:33:44] right [20:33:56] any idea where that class would go? [20:34:03] satswitches [20:34:23] all the meters are there, too [20:34:33] if you have to add it to the Saturn class and we can move it later [20:35:24] haven't found the Block Data calculation, but RETRO set up some init parameters for the RTCC deorbit calculations [20:35:34] including that LVLH attitude [20:35:47] 0° roll, -48.5° pitch, 180° yaw [20:36:37] -48.5 is very close to what I had to put the 31.7° on the horizon, for 150NM altitude [20:37:20] I get the feeling that the nominal deorbit solutions might come from the RTCC, but the Block Data (as the name says) comes from the Block Data Program [20:38:55] I guess it would be derived from SaturnRoundMeter [20:39:52] I mean, you don't have to derive it from anything at first [20:40:11] basically just a class that only has RedrawPanel_Alt as a function [20:40:17] and then add VC stuff to it [20:40:40] ah, right [20:41:12] hmm [20:41:17] why is there RedrawPanel_Alt and RedrawPanel_Alt2 [20:42:29] if only stuff like #define ALTIMETER_X_CENTER differs then you could make two instances of the class, with those defines as Init parameters [20:42:47] classic programming challenge [20:49:35] ah because the docking window version is bigger [20:50:51] hmm [20:51:07] but it wouldn't be right to have that as two instances of the class [20:51:11] as it's only one altimeter [20:51:19] I can just add the 2 function to 1 class and call each separately from the respective AID [20:52:06] sure [21:00:12] so public: nothing? [21:00:57] for the class I made "Altimeter" [21:01:40] or should that be SaturnAltimeter [21:01:57] what do you mean public nothing? [21:02:50] class Altimeter [21:02:57] without the : public after [21:03:20] oh, yeah, it's not a derived class (at least right now), so it does't need that [21:03:54] I guess I need to give it a pointer to saturn [21:03:59] yeah [21:08:47] DrawNeedle in saturnpanel.cpp also needs to be accessed [21:09:13] does anything else need that? [21:09:21] maybe you can just move it into the class [21:09:46] yeah I think its only the altimeter [21:10:27] yep [21:28:43] ok I will test the class and make sure I didnt break the 2D panel version lol [21:29:00] then I will add an animation function to it [21:33:46] damn CDT [21:33:50] CTD* [21:35:50] ah I forgot to pass the saturn pointer in the init function [21:38:55] classic mistake, I've done it many times [21:45:49] afternoon! [21:48:49] hey [21:49:29] wait, it's afternoon here too. what sorcery is this [21:50:14] hahaha [21:51:39] hey Mike [21:53:11] rrauction space auction preview is up, and I was exactly wrong -- all three of those AOHs are volume 2 [21:53:25] hmm [21:53:32] don't need that as much :D [21:54:12] if you want to sink some money I have a NARA document with many pages to be scanned haha [21:54:28] hehehe [22:32:07] still listening to MOCR audio, I like how they refer to the switch position for the FDAI that powers both FDAIs (1/2) as "one half" [22:32:18] that means 1 AND 2 not one half :D [22:34:10] that's a very odd way to refer to it [22:34:17] lol [22:34:34] well it's the prelaunch checklist they go through with the LCC personell [22:34:41] they probably don't know better [22:35:00] it is unambiguous what they mean :P [22:35:45] hmm [22:35:58] doesn't the switch say "Both" instead of "1/2"? [22:36:08] ah no [22:36:13] they mean the FDAI select switch [22:36:17] that one says 1/2 [22:36:32] still means 1 and 2 of course [22:49:05] night! [12:05:25] good morning [12:11:24] hey [12:21:42] I have the whole day and virtually unlimited coffee. Let's see if I can solve this battery thing [12:26:13] haha [12:26:50] So the main issue is unstable voltage and load being shifted back and forth between FCs and batteries? [12:44:00] yes [12:45:09] What's odd is that the fuel cells don't do this do each other, even if there's 3 of them on the same bus, and they're at very diferent temperatures [12:45:15] have you tried the version where the power load is constant instead of the load resistance? [12:52:47] haven't yet, still thinking of the best way to do that and still keep a model that outputs voltage, as a function of temperature and current. and still maintain conservation of charge with the fc chemistry [12:53:23] hmm [12:54:45] may have something [12:54:49] one sec [12:57:09] if (batPower.Voltage() > fcPower.Voltage() + .7) // diode bias [12:57:10] busPower.WireToBus(2, &batPower); [12:57:11] else if (batPower.Voltage() < fcPower.Voltage()) [12:57:12] busPower.WireToBus(2, NULL); [12:59:17] with the battery bus tie on, voltage is oscilating between the on/off state of our diodes [13:11:34] https://download.datasheets.com/pdfs/2014/8/7/0/50/21/252/njs_/manual/16521n3288r-1n3297r.pdf [13:21:02] what is the normal behavior for the load sharing? I think I remember the CSM Data Book having a bunch of graphs [13:28:47] it does, looking now [13:36:38] https://drive.google.com/file/d/1QmohDcDj2l34MpGwcyZMWzRUukkPO3zK/view?usp=sharing [13:41:07] hey Ryan [13:54:09] so indy91, two things, I think our entry batteries need our CM batteries might need a few parameters adjusted a little, and the diodes need a soft-voltage drop rather than on/off [13:54:19] morning [14:12:28] hey Ryan [14:12:40] wow, I butchered that last sentence... [14:12:58] doesn't sound too big of a change, and the batteries can use some adjustments anyway [14:14:32] the last time they were modified was 2006 [14:24:13] I'm still wondering what leads to the bad behavior [14:24:30] fuel cell has all of the power load [14:24:39] you switch the batteries on the bus [14:24:46] battery voltage is higher [14:26:21] DCBusController has a NWayPowerMerge [14:26:32] which splits up the power load based on voltage [14:27:06] the battery now has some of the power load, meaning the power load for the fuel cells is lower [14:27:14] fuel cell voltage increases [14:27:28] enough to not have the batteries being used at all [14:27:38] is that how it works? [14:29:36] this probably happens because the fuel cell voltage is now a bit lower than before in general [14:30:00] not much, but that + 0.7 V as the diode bias was probably adjusted for the old behavior [14:30:19] it's the 0.7V that's causing the issue [14:30:33] so the power load being kept constant in the fuel cell code (instead of the load reistance) probably won't help much with the behavior [14:30:49] nope [14:30:58] it's just voltages being closer now [14:31:22] did it even use the batteries with the old behavior? [14:31:44] I'll have to check, I'd imagine it did [14:32:21] wouldn't that mean the FC voltage was lower before? Maybe I didn't see that right [14:32:58] yes, it was fixed at 28.8V [14:33:19] ah right [14:33:19] and the batteries are 37.5-ohmic losses [14:33:25] larger gap [14:44:17] well, diodes are not particularly dificult to model [14:47:27] rcflyinghokie, I'll trade you a diode class for an accumulator class. [14:47:34] haha [15:30:59] well I have mostly stabilized the glycol pressures [15:31:18] but the accumulator just isnt doing what I want when i add it in [15:33:58] ...and I shouldn't count my chickens before they hatch, with this diode thing. [15:34:19] I have been experimenting with volume changing code but I cannot get it to work, I think its just my weak C++ [15:35:15] trying to use while loops [15:37:03] but sadly I cant get orbiter to launch with my attempts lol [15:42:46] did you try making it really big to see if it's a timestep issue? [15:43:49] I mean orbiter wont launch at all [15:55:21] oooooh. that's not good. [15:58:25] hey [16:02:17] afternoon [16:04:36] hey alex [16:15:00] ugh dilemma [16:15:36] smaller valves help stabilize the LM glycol..however now the pressure doesnt drop very fast when I turn a pump off and I cannot get auto transfer to work :( [16:39:10] very much open to ideas lol [16:42:55] doesn't sound like an easy task to stabilize that ECS! [16:45:02] its not [16:46:20] I have it stable right now with pumps on or pumps off [16:46:34] but the problem is the pressure decays so slowly due to small valves [16:46:39] morning! [16:48:14] hey Mike [16:48:29] rcflyinghokie, I see [16:49:04] yeah haha [17:06:17] rcflyinghokie, so you're adding a constant 0.001*dt per timestep to the volume? [17:08:40] what if you make that 0.001 a function of (5.6-target_pressure) [17:10:22] and then say if(5.6-target_pressure>max_dVdP){dV = max_dVdP) [17:10:31] *} [17:11:29] not quite following [17:17:39] but before I go further I need to work this glycol loop more [17:36:06] takes a minute 45 for the dP light to come on [17:37:04] could that be due to the "stabilizing" code? [18:04:31] indy91, "Implement reentry numerical integrator" Is that something that can be used already by the RTCC MFD? [18:52:07] not yet [18:52:29] but it's the method that will generate the numbers for the Entry PADs that are still missing [18:52:46] blackout begin/end, better EMS initialization [18:53:22] and it's used for deorbit and return-to-Earth calculations [18:53:29] and displays [18:55:21] the Gemini reentry simulation calculates the blackout times at fixed heights, probably have to use something smarter for Apollo, probably isn't the same for lunar vs. Earth orbit entry [18:56:18] indy91 can you explain that LM ECS "stabilizing" code? [18:57:27] hmm? [18:57:29] what is that? [18:57:45] Alex said you put something in to stabilize the ECS? [18:58:05] looks like in the glycol pump controller [18:58:10]