[14:47:11] NASSP Logging has been started by indy91 [14:47:55] and I've seen no code for driving the antenna all the way to the manual angles in reacq mode when it runs into the scan limit. I guess that is coming later [14:48:18] hmm try it again [14:50:44] yes on the reacq mode. quick fix once I get the auto mode working [14:51:39] try what again? [14:54:00] I just pushed my build to CSM-antennas again [14:54:57] hmm, I'm not seeing the change here: https://github.com/n7275/NASSP/tree/CSM_Antennas [14:55:30] last commit 10 hours ago, that was already up [14:57:22] maybe I need to go watch a few videos on github... [14:58:35] so, I tested some code in Thermal.cpp to make the sun heat all sides of the cabin with 0,0,0 as a position vector [14:58:44] https://www.dropbox.com/s/2yide03l0f1az6h/Screenshot%202020-04-25%2008.53.29.png?dl=0 [14:59:20] n7275, maybe you did a commit? That's just a local upate [14:59:23] update [14:59:37] git push etc. is what updates it on Github [15:01:00] AlexB_88, looks good. Maybe it should be a lower value than the 1372 though [15:02:08] well, higer if anything [15:02:11] higher* [15:02:29] from what I have seen in testing [15:02:44] the LM cabin still gets very cold in TLC [15:03:09] that logic should give the tank as much heat as if it was pointed directly at the sun [15:03:19] but if I make it higher then of course it will overheat when I add crew + activate systems and such [15:03:25] right [15:04:23] but even 1372è only makes it go up a bit with crew in cabin + fully activated LM [15:04:26] I am working on tracing heat flow right now [15:04:41] Seeing why the heat from the cabin is not getting cooler from the ECS [15:05:48] I have to go be social today, aparently, lol. catch you all tomorrow. indy I'll push again. [15:06:08] but the problem I am having is that if I want to make the cabin in TLC not drop too low, I have to increase the value A LOT lol [15:06:20] so I dont think this is a viable solution [15:06:56] Well ideally I can remove that radiator [15:07:00] yeah, I don't think that heat is the problem [15:07:12] I am working to see if I can improve the cooling power in the ECS [15:07:19] Without cheating [15:07:22] right [15:07:29] Because the suit loop works fine [15:07:39] But I just am not getting Q removed from the cabin [15:07:41] or the radiator is too strong [15:10:39] Its a balance between the radiator and the heat exchanger attached [15:10:45] But yeah it very well could be [15:16:03] I mean, I think my code could still be realistic though, but it will not keep the cabin at a reasonable temp during TLC like I thought it would, but it will go down less then with the sun only coming in from one side [15:16:44] indy91, but yeah maybe a smaller number [15:18:31] and it would help the temps not go too low, but it will still need some other ways to get the temps reasonable, I guess what you're working on, Tyan [15:18:35] Ryan* [15:20:39] Yeah trying to [15:27:27] Heres something interesting [15:27:48] On the Oxygen flow schematic, the temp of air going into the cabin is 90-95 degrees? [15:27:56] And leaving the cabin 110 degrees [15:28:40] 150-170 leaving the suit fans [15:28:55] 48-54 leaving the cooling HX [15:29:36] But according to this cabin air in and out is like 100F [15:30:19] So cooling has to take place elsewhere [15:34:09] yeah [15:34:32] thats 100F going into the cabin? seems high [16:01:52] I wonder if thats assuming astronauts in suits [16:03:40] In that case it would make sense [16:03:53] But that also means cabin heat has to be leaving somewhere else [16:09:22] Also, a thought [16:09:52] The crew was at least partially suited in the LM most of the time correct? [16:10:19] Maybe we keep them in suits instead of the cabin tank like the CM? [16:19:26] maybe [16:19:35] does the CM even have a cabin tank? [16:20:17] Yes [16:20:29] maybe they came to the same conclusion with the CM lol [16:20:33] But the crew is always in the suit circuit (a massive 1000L tank lol) [16:20:58] I mean its not unreasonable [16:21:13] That would mean the crew heat is added to the suit loop [16:21:19] And rejected via the suit loop [16:21:33] I mean that is what I have been doing anyway (keep the crew in suits) to avoid the cabin heating up [16:23:13] it might simplify things for now to only have suit mode (and PLSS) [16:24:29] What does the cabin stay at when you do that? [16:27:17] Comment from 12 [16:27:18] [The Apollo 11 cabin was very cold during the lunar stay and Armstrong and Aldrin reported that, during their rest period, it was too cold to sleep. For Apollo 12, procedures were changed to make sure that the ECS air heater was on enough of the time to maintain the cabin temperature at a comfortable level.] [16:27:42] Still leads me to believe we need heat loss in the cabin [16:27:49] yes [16:28:04] so it stays pretty hot still, but not as bad as with crew [16:28:29] but yeah we would need more cooling I think [16:31:04] I would think radiative cooling is the answer [16:35:00] so like the current radiator? [16:35:20] I mean the one we are testing with [16:41:40] Well ideally we want radiative cooling on all tanks [16:41:43] Based on isolation [16:46:51] some of my scenarios around the moon, the cabin gets very hot (with crew in suits) but other scenarios it stays at a reasonable temperature in the 60-70s, I dont understand why its different [16:47:12] like the Apollo 11 PDI scenario, the cabin temps there stay very good 60-70s [16:48:11] I think Niklas flew that mission, dont know what he did to keep the temps so stable [16:48:15] Its the systems that put heat in the cabin like lights [16:48:21] I am going to look at those numbers [16:48:34] Keep the lights off or low and its good [16:51:25] so should we just remove cabin mode for the astronauts? [16:52:17] Not sure yet but its an idea [16:54:27] morning! [16:55:48] Hey Mike [16:57:41] I am so tempted to just work on the thermo code [16:57:56] Make Q transfer a function of heat capacity as well as dT [16:59:19] will that affect CSM ECS though? [16:59:34] Probably [17:01:15] maybe we shouldnt mess with the panelSDK stuff too much for now if it will affect the CSM, and keep that work for NASSP 9 [17:02:15] Well yeah if it breaks anything I wont use it [17:02:18] just curious [17:02:30] right [17:02:50] test away then lol [17:03:18] I quess thats what testing branches are for [17:04:27] btw, you are right, the lights have a big effect on cabin temp [17:06:28] Yeah [17:06:42] I know I planned on using like 65% of the energy as heat [17:06:48] But I dont know if I did that for all of them [17:12:32] The air wouldnt absorb the heat that fast though especially at 5psi [17:27:49] I reduced all lighting heat to 65% to see [17:28:07] I also increased the isol number on the cabin [17:28:14] See what this does without the radiator [17:34:26] interesting it has a pretty big effect [17:41:40] cabin is cooler? [17:46:25] I mean it heats and cools dramatically [17:47:09] oh interesting [17:47:32] is that good? [17:48:44] It could be? [17:49:35] haha [17:49:45] LM ECS in a nutshell [17:50:47] yeah [17:51:58] Amen [17:52:22] Ryan, what isolation are you testing with? [17:52:31] for the cabin [17:52:47] 0.005 right now [17:52:59] ok [17:53:13] Without the radiator [17:54:03] right [17:54:25] I have reverted to the main branch and Ill test the 0.005 on my end [17:56:41] Ok [17:59:32] It feels like it doesnt cool fast enough [17:59:36] But it certainly heats [18:03:08] so it retains heat better from the increased isol? [18:06:28] well no, increasing that number increases the amount that it heats and cools wrt the sun exposure [18:06:56] With some adjustments around, 0.002 is actually working well with crew in the suit loop [18:07:16] ok [18:07:37] and I guess that is the 65% heat from the lights you were saying [18:10:07] Yeah [18:10:19] it still gets a little warm though because of the sun [18:10:46] Wonder if we should change that direction so its the front of the LM? [18:10:53] I wondered too [18:11:42] but did you look at what I was testing? Making the heat from the sun heat all sides, and we can reduce the value to an average that would be realistic [18:12:31] maybe half of the full strength as an average? (when LM is facing the sun) [18:14:43] this is the code I came up with: https://www.dropbox.com/s/2yide03l0f1az6h/Screenshot%202020-04-25%2008.53.29.png?dl=0 [18:15:17] but maybe with a lower dumber then 1372 [18:15:22] number* [18:25:43] I am all for trying it [18:26:12] So would that heat all sides or heat the side facing and cool the other side? [18:28:22] well it would just always heat at a constant rate whenever the LM is in the sun [18:28:40] a rate we can adjust [18:30:46] What about cooling [18:30:56] I am more concerned with it not cooling fast enough [18:31:46] we can adjust the rate to find the balance we need [18:32:22] that function doesnt do any cooling I think its just a value of how much heat is added by the sun [18:32:42] right now its based on what direction the cabin is wrt the sun [18:33:32] Yeah I think we need it to give more heat to space [18:33:51] pointing towards its 100& of 1372.0 and away 0% [18:34:15] so we can use my code with maybe 50% of 1372 to start [18:34:30] and if we need more cooling reduce it [18:36:54] Where is the cooling? [18:36:56] Any idea? [18:37:30] hmm, you mean in general? [18:38:44] Yeah what allows a vessel to cool in space [18:39:53] well it will go to -300 with the radiator you added :D [18:40:41] I mean without a radiator, there has to be something letting a vessel cool right? [18:41:06] also in thermal [18:41:19] I think it's a similar calculation to the radiator [18:41:51] Radiator: double Q = rad * size * 5.67e-8 * dt * pow(Temp - 3.0, 4); //aditional cooling from the radiator?? [18:42:07] Thermal object (like tank): Q3 = (float) (q * pow(runner->Temp - 3.0, 4)); [18:42:34] small q being: float q = (float) 5.67e-8;//Stefan-Boltzmann [18:42:52] and some heating and cooling added together, Q3 here: Q -= Q3; [18:43:01] and then that whole thing does [18:43:01] runner->thermic(Q * runner->Area * dt * runner->isolation); [18:44:36] Ah i see that [18:46:53] just seems like it isnt powerful enough [18:48:17] if only there was a way to do this all in a more scientific way [18:48:59] maybe I'll try to put the calculations we do in various place like thermic.cpp in MATLAB and produce some graphs [18:50:32] That would be awesome [18:54:53] nearly done with my coelliptic sequence processor update, after that I can properly help [19:00:03] Sweet! [19:00:52] I don't think I can contribute much code/model-wise but if there's any documentation you don't have that might help let me know and I can try to help dig it up [19:07:30] I have found MSC documents for simulating the CSM EPS and the LM DPS in great, but never somthing good about the ECS unfortunately [19:07:39] in great detail* [19:09:25] AlexB_88, the optimal CSI calculation is only 5 seconds off nominal for Apollo 11... when the CSM does the rendezvous maneuvers [19:09:51] kind of asking myself if the MCC is calculating the maneuvers for the CSM instead of the LM right now :D [19:18:32] indy91, I think I fixed it [19:18:56] there is definitely an update on Github now [19:19:59] yeah, if you push without committing, nothing happens... [19:20:05] indy91, awesome [19:20:32] it would be more awesome if it was so close for the nominal rendezvous with the LM doing the maneuvers though :D [19:20:51] the launch window processor also still uses some conic calculations, it will come from that [19:23:42] n7275, looks pretty good, I guess the only piece missing now is the behavior in reacquire mode, that it drives the HGA all the way to the manual angles before trying to reacquire again [19:23:52] Apollo 13 actually had an issue with that [19:23:56] just before the explosion [19:24:19] https://history.nasa.gov/afj/ap13fj/pdf-hr/31-a13-anomaly-report2-high-gain-problem.pdf [19:24:33] maybe that document helps [19:24:59] that's where I found the scan limit and scan limit warning functions [19:25:05] in A and C-axis coordinates [19:25:10] instead of body pitch and yaw [19:30:44] hmm, scanlimit doesn't seem to be used in the code anymore [19:31:08] not even in auto mode. Am I seeing that right? [19:33:00] darn it, forgot about scan limit [19:33:23] is scan limit warning doing anything? [19:33:34] It used to have a caution and warning light [19:33:43] but that probably flew on no mission [19:33:51] well I didn't touch the c/w light [19:34:00] oh yeah, we removed that [19:34:05] a while ago [19:34:14] it's in an old Systems Handbook [19:34:23] but it was an old configuration that probably never flew [19:35:11] the Systems Handbook says about reacquire mode: "stops tracking and switches to manual at scan limit. Inhibits fine tracking during acq in scan limit warning zone" [19:35:28] so scan limit warning would still be used a little bit at least [19:36:02] whatever it means with fine tracking [19:36:12] narrow beamwidth? [19:36:27] but that's probably a minor feature [19:36:35] that's what the logic diagram in the CSM handbook says [19:36:42] yeah [19:37:22] so the fine/course acquire/track modes should work [19:37:33] right [19:37:56] just need to add the check for scanlimit[warn] in the appropriate spots [19:38:05] yeah [19:38:15] from restricted NTRS: "19700080750 Internal environment simulator LSP430-5500-1 validation 1968" [19:38:22] LSP is a technical specification [19:38:26] I guess all you need to do is add a bool that keeps track if the antenna is very close to the manual pitch and yaw controls [19:38:49] and use that for the logic that drives it after loss of signal at the scan limit in reacq [19:38:54] not sure why that would be restricted... may be worth requesting, but it may take two years instead of just one given the current situation :P [19:39:27] they flipped a coin to decide what is restricted [19:39:32] it's truly that random [19:42:18] n7275, it would probably be a latching relay. It's set in reacq at the scan limit. And reset when the manual angles are reached [19:42:34] and it would simply inhibit auto tracking [19:44:22] I'd love to get HGA electronics schematics, we have it for so many other systems [19:44:52] did NAA build them? [19:44:55] well, at we know other systems down to the relay and relay contacts level at least [19:45:05] not sure, probably subcontracted [19:47:23] I wish the CSM systems handbooks had a list of drawing references like the LM ones [19:48:40] yeah [19:53:56] "In February 1965, a subcontractor was selected to provide the S-band HGA for [19:53:56] the CSM." [19:56:24] but the Apollo Experience Report fails to mention who that is... [19:57:23] uhh [19:57:31] February 23, 1965: NASA awarded a fixed-price contract (worth l.5 million) to IBM to design a backup guidance and navigation computer for the Apollo CM. [19:57:41] what this [20:00:23] wait what [20:00:24] Dalmo-Victor had the subcontract for the CSM HGA [20:08:09] thewonderidiot, any idea what that IBM computer is? [20:12:26] no, I've never heard of such a thing [20:13:23] UHCL has the document that is the source for that [20:13:36] I found it here: https://www.hq.nasa.gov/office/pao/History/SP-4009/v3e.htm [20:13:49] it quotes: "MSC, "Quarterly Activity Report for the Office of the Associate Administrator, Manned Space Flight, for the Period Ending April 30, 1965," p. 24." [20:14:22] IBM always wanted the AGC contract, I wonder if that is some shortlived thing that has to do with that [20:14:47] a study to replace the AGC with something more simple [20:14:53] something like that [20:14:58] almost sounds familiar... [20:16:36] I know they were fighting to use the LVDC in place of the AGC for a while [20:17:36] yeah [20:48:57] night! [08:22:54] .loggingstatus [08:25:10] n7275, still awake? [12:13:18] I'm awake now [12:15:32] oh hey [12:15:54] some additional files have somehow made their way into your PR [12:17:06] like a FraMauro.cfg [12:17:19] when our file for that is actually called Fra Mauro.cfg [12:17:21] quite weird [12:18:04] git can count lines in a mesh file. 429,214 new lines of code would be some impressive first contribution :D [12:18:26] https://github.com/orbiternassp/NASSP/pull/521/files [12:18:38] oh dear [12:19:27] yeah dont know where those came from [12:20:20] should only be csm_telecom.cpp and .h [12:20:57] maybe you commited all changed files in your NASSP folder or so [12:22:21] some files from an earlier NASSP version [12:22:31] the LM meshes there have been removed since [12:23:53] yeah, probably, whoops [12:23:54] you probably don't need to delete all the additional files, although it might be the easiest way [12:24:22] I'll do some spring cleaning [12:24:37] sounds good [12:24:44] there also is a NASSP "Submodule" [12:24:47] whatever that is [12:25:08] ? [12:27:34] oh [12:27:51] now I'm more confused [12:28:15] I need to do some major cleaning [12:29:07] and I tested the changes, look good [12:29:19] I don't get any signal strength in wide beamwidth [12:29:42] in one test I did I was in racquire, narrow, before AOS [12:29:57] when the Earth came over the horizon it was in the scan limit warning zone [12:30:14] which I guess means it doesn't do narrow beamwidth automatically, but wide instead [12:30:37] so same issue, if it's an issue, zero displayed signal strength in wide, even if it is tracking fine [12:30:57] tracking ok*, fine might be a confusing word to use :D [12:31:37] If you have a submodule that means you've cloned a git repo into a git repo. [12:33:00] according to the csm systems handbook the gauge reads in dBm from -130 to -50. it should be about -128 at lunar distance so the gauge is only moving by about 2% in wide mode [12:33:43] *2.5% [12:34:52] @Thymo, yes I probably did that on my first install. I've removed it [12:35:31] At any point you can also run git reflog to see what actions you've done on the repo. [12:35:42] that's weird with the signal strength [12:37:24] @Thymo, yes I probably did that on my first install. I've removed it [12:38:16] I thought it seemed a little low, but I was going by the numbers [12:41:23] where did you get the -128 number? [12:41:59] friis equation [12:46:43] using the gains (rx) listed in the handbook 50dB for the ground station (85ft antenna) [12:47:18] wavelength is 0.014m [12:47:44] I've read somewhere that below 60% indicated signal strength voice comm is already degraded [12:47:56] so wide bandwith is only really useful for acquiring? [12:49:09] beam width* [12:50:13] wide mode is only amplifying 3.9dB, and recieved power is on the order of femtowatts [12:50:51] I think it's only for acquisition [12:50:55] ok [12:51:24] oapiGetSize(hEarth)/2 [12:51:32] oapiGetSize already returns the radius [12:51:40] so I don't think you need to divide by 2 [12:52:52] does the S-Band power amplifier do anything for the HGA? [12:56:57] https://www.ibiblio.org/apollo/Documents/HSI-208962.pdf [12:57:03] maybe this also has some useful information [12:57:06] CSM Data Book [12:57:37] Ohh performance [12:58:09] performance? [12:58:33] constraints and performance [12:58:43] On the first page lol [12:58:50] Thats all that loaded for me when I typed it [13:00:07] haha [13:00:14] it's a large document [13:00:32] I linked it for n7275 though, maybe has some more info on the HGA [13:00:41] but essentially the HGA update seems done [13:00:50] I'll be back in a bit [13:01:30] Ohh I didnt have context thats why I was confused [13:32:29] context is overrated [13:57:01] I'm still downloading that pdf... internet's a little slow here today [13:58:59] https://www.ibiblio.org/apollo/Documents/HSI-41539.pdf [13:59:05] this is another version of it [13:59:10] only about 1/10 the size [14:19:55] thanks [14:20:27] I saw the HGA stuff go in, is that tied to the ground station stuff in MCC at all or did you guys find better data? [14:24:12] it's just the high gain antenna electronics [14:24:35] it could be tied to MCC ground station data [14:24:37] Oh. Drat, I was hoping someone had found a better station list. [14:24:41] but for now it's just "Earth in view" [14:24:44] A lot of mine was just guessing. [14:25:06] well it will also be mission dependent [14:25:14] somewhat [14:25:47] I've seen some stuff on ground stations [14:26:04] detailed coordinates [14:26:19] That's most of what I didn't have, there was docs on STADAN and docs on the network as it was when things wound down but not much about state of the network during the actual missions. [14:26:28] I had coordinates for all of the major stuff [14:26:33] Obviously not ARIA as they moved [14:27:12] I know some stations were only manned during shifts but there was no info on how that worked [14:28:56] there was a good document on the Honeysuckle website [14:29:11] which is a great website in general [14:29:44] https://www.honeysucklecreek.net/msfn_missions/Apollo_11_mission/AS-506_NOD_Supplement.html [14:30:47] definitely has a network configuration list [14:30:51] for Apollo 11 [14:33:08] somewhere I had seen a list of coordinates though, can't remember where [14:35:43] I thought it was in one of the RTCC documents, used to send out acquisition messages to the stations [14:38:52] Hey folks. AGC question if anyone is happy to help my understanding. Running Apollo 9 and just manoeuvring for a burn using V49. Works fine and I get into the desired attitude, confirmed by the needles (V62). But when I run P40, and it flashes V50N18, the pitch attitude is off by 5 degrees and the needle shows an error in pitch. Same problem for R [14:38:53] and Y but not to the same magnitude. A V25 to change to the original desired angles does not help, and it goes just to the gimbal test option. I’m at a loss to explain this difference. I have noticed this in different missions too. Obviously a 5 degree pitch difference is significant for burns. Any thoughts? [14:41:13] hmm [14:41:59] Using a build from 2 weeks ago (not quite latest). Fresh MCC scenario (not broken) etc [14:42:14] the attitude you used in V49 came from a MCC supplied Maneuver PAD? [14:42:40] and yeah, P40 doesn't allow you to change the attitude [14:43:33] hey [14:43:46] hey Alex [14:45:52] Yes. This was SPS-1 at ~6hours. The angles were R000, P356, Y001. V49 manoeuvre went fine and precisely and held with min deadband. Went to P00, loaded P40 and the 50 18 displays: R +00041, P +35936, +00030. My DAP is loaded with min deadband. This is Orbiter 2016 beta as well [14:46:46] To be fair R and Y seem within deadband, but still i don’t know why they differ from V49 [14:47:18] it should at least agree within 1 degree yeah [14:47:40] REFSMMAT is still the launch one, so I don't think it could be the wrong REFSMMAT [14:48:21] was there already a state vector uplink? [14:49:47] and as it is a docked burn, did you enter the right gimbal trim angles in V48? [14:50:13] I had a SV uplink per the flightplan, I believe just after 3hrs. The next MCC uplink was the target load and mnvr PAD [14:50:24] right [14:50:29] yes, V48 was per MCC values [14:52:17] in our old scenario it's 357° in pitch, so closer to your Maneuver PAD values than your P40 [14:52:40] and P40 agrees in the old scenario [14:53:31] I have a scn saved just after the V49, and about to load P40, if that might be of interest? [14:53:34] CSM and LM weights loaded correctly in V48 as well? [14:53:39] yes, I can check that [14:54:36] oh wait a moment [14:54:46] there is a P52 option 1 before SPS-1 [14:55:02] Yes, just checked V48 weights and they appear correct (at least CSM, I haven’t touched LM weight, but it seems about right: ~32k lbs) [14:55:05] Oh [14:55:12] the comment on the Maneuver PAD reads: "Gimbal angles with pad REFSMMAT" [14:55:28] the P52 option 1 you do changes it [14:55:45] ideally that would then give 0,0,0 as the burn angles [14:56:11] that could be off a bit if you update the masses and trim gimbal angles only after the P52, maybe the checklist has the order wrong, I remember something like that [14:57:06] Yes. I did do that P52 option 1 (and I was confused about: since the AGC still had launch REFSMMAT stored, why not just do a preferred option? But then I observed the FDAI while torquing, and it was several degrees - enough to account for the difference I’m now seeing). [14:58:12] when you uplink a target load and then do P30 and then just for the first display also P40, then the AGC calculates a new desired REFSMMAT [14:58:22] stored at the same location as if one was uplinked [14:58:29] and the next P52 option 1 then uses that [14:58:48] and as I said, ideally that would give all zeros for the burn [14:59:09] during the actual mission the pitch was even closer with the launchpad REFSMMAT [14:59:19] 004:53:03 Roosa: Houston confirms the PAD. I would also now like to give you your gimbal angles used in the PAD REFSMMAT for SPS-1. [14:59:19] 004:53:14 McDivitt: Go. [14:59:20] 004:53:16 Roosa: Roger. It's roll 00, pitch 359, yaw 001. [14:59:29] so I think everything is normal then? Probably [15:00:33] Apollo 9 did a P52 option 1 before most burns [15:01:47] it just so happens that SPS-1 is at a location in orbit where it gives nearly the same pitch angles as the launchpad REFSMMAT [15:02:11] Thank you. I might go and do a P52 Option 1 then before the V49. Should I expect that the P40 values be the same as V49? [15:02:18] 90° of orbital travel before KSC [15:02:59] I don't think so [15:03:06] when are you maneuvering? Before the P52 option 1? [15:03:38] if so, then you would use v49 to get to the 356° in pitch [15:03:45] which is already the burn attitude [15:04:09] and then you do the P52, which will torque the IMU to 0° pitch ideally [15:04:19] so not you are maneuvering after that, but the IMU and FDAI do :D [15:04:31] I think I understand! [15:04:35] and then not another V49, or one using 0/0/0 [15:05:28] could be that some checklist there is a bit confused [15:05:50]