[10:48:28] NASSP Logging has been started by thymo [10:48:40] Good morning! :) [10:49:44] Patched all my machines. Means that I now see a nice cpu_insecure bug set. :| [12:14:07] Okay, got a CM align of all balls, P52 option 3. Now, does that carry across to the gimbal angles for the transform for LM docked coarse/fine align via PAMFD? (button LGC, so I can V41/V42 for its IMU and balls) [12:16:01] I think PAMFD does the conversion for you, yes. Then you can enter those numbers into the LGC. [12:39:17] Either I messed up my outer gimbal math (359.05 degrees minus 60 degrees is 259.05 degrees, right?) or the calculation for the V41N20 angles in PAMFD is incorrect. (It says the LM OG should be 300.95 degrees.) The AOH says (pp 4.9-16, step 4) "Lo and thou shalt calculate thine LM ICDU angles: LM OG = +- Docking interface roll calibration angle? (0 in our case) - CM OG - 60 degrees... [12:51:22] indy91 will know. [12:51:23] [13:39:16] Either I messed up my outer gimbal math (359.05 degrees minus 60 degrees is 259.05 degrees, right?) or the calculation for the V41N20 angles in PAMFD is incorrect. (It says the LM OG should be 300.95 degrees.) The AOH says (pp 4.9-16, step 4) "Lo and thou shalt calculate thine LM ICDU angles: LM OG = +- Docking interface roll calibration angle? (0 in our case) - CM OG - 60 [12:51:26] Hey :) [12:51:47] hey Thymo [12:53:28] 359.05-60=299.05 [12:54:41] but that is not the right outer gimbal calculation [12:55:25] OG = 300 + RC - CM + LM [12:55:37] no wait [12:55:45] OG = 300 + RC - CM [12:56:05] 300°+0°-359.05° [12:56:17] that gives 300.95° [12:56:22] as PAMFD says [12:58:05] well, the AOH math works as well [12:58:15] 0°-359.05°-60° [12:58:29] that gives -419.05° [12:58:46] which is the same [12:59:36] this isn't super difficult, but tricky and important enough to explain why the Apollo 13 crew wanted this to be cross checked by MCC [12:59:51] I wonder if entering a negative angle in the AGC would still yield valid alignments. [13:00:13] either yes or you get an operator error [13:00:23] I bet on operator error [13:00:26] Like +350° and -010°. [13:00:30] Let's try. [13:01:35] Ah, so *I* screwed up my math. (Doh.) [13:02:05] it happens [13:02:15] It works! [13:02:16] still P51 issues? [13:02:30] I enterd -01000 and it automatically converted it to +35000. [13:02:40] what about -419.05 [13:03:01] Cannibal^, did you have a good alignment with the rear detent till yesterday? [13:03:10] since* [13:03:38] I rolled back to just before undocking. I'm goiung to try again. [13:03:47] landing, I mean. [13:04:00] I'd like to look at your scenario, just as a check that your LGC is in good shape [13:04:48] just upload it on Dropbox or so, that seems to be the usual method around here [13:05:10] It probably isn't at all. Don't worry about it. [13:05:49] I wonder if you could send stuff via DCC on freenode. That way you can directly send it over IRC. [13:06:03] well, if the padloaded AOT angles in your scenario are wrong somehow, then you will never get a good alignment [13:06:53] I have good marks in the CM today: Got all balls on P51 and P52 option 3. [13:07:03] that's good [13:07:09] the AOT angles are not in fixed memory in the LGC, so they can be changed or be broken [13:07:20] I can tell you which memory address to look at [13:08:23] just copy&paste these addresses from the LM part of the scenario: EMEM3404 to EMEM3417 [13:08:51] STBY. [13:08:54] these addresses will exist in the CMC as well, so make sure you are looking in the lower half of the scenario [13:11:38] EMEM3404 65253 [13:11:50] EMEM3406 12525 [13:12:03] EMEM3407 25253 [13:12:20] EMEM3410 37777 [13:12:27] EMEM3411 52525 [13:12:36] EMEM3412 10000 [13:13:00] rest are also 10000 I guess [13:13:08] then they are all correct [13:13:09] Exactlky [13:13:48] so your LGC knows which detent of the AOT is pointing in which direction [13:14:33] too bad, that would have been an easy solution to fix those addresses [13:17:02] It might've been operator error. I'll find out when I land again. [13:20:06] Am I supposed to have a red AGS light, both RCS REGs red, and white RCS, ECS, GLYCOL, WATER QTY and S-BD RCVR lights? [13:27:38] CWEA needs work [13:27:46] Thymo's job ;) [13:29:13] shrugs. can't do anything to get the red ones out, the white one for ECS water qty went out when I cycled the valve and hit CWEA reset. [13:31:03] yeah, I think the logic for the AGS light is mostly missing right now [13:31:09] so you can't really do anything about it [13:31:44] and RCS helium regulator light has no logic at all [13:31:47] it's always on [13:34:40] Oh crap, V42 N20 scaling is is xx.xxx but the v42 button in PAMFD gives the middle number as +179.067 [13:38:34] (Yes, I had to look up the scaling for N93 R2. It's the same as R1 and R3.) [13:39:28] well, V42 is not really meant for any larger corrections like that anyway [13:39:40] V42 is for a fine adjustment [13:40:14] so should do a V41 N20 with the desired angles [13:40:34] and once you have about the right alignment, then use V42 for a small adjustment [13:41:16] if you are using the nominal procedures and end up having to do a 180° adjustment with V42, then something went wrong [13:42:50] Oh you can get those red lights out. There is a CWEA breaker for that. :P [13:42:57] Turn my stack around so the CM IG is 181.56? [13:43:15] rather than 1.56? [13:44:03] no, that wouldn't work [13:44:19] ? [13:44:32] the PAMFD V42 angles are comparing the current LM IMU and CSM IMU attitude [13:44:47] and it has the right logic for a docked alignment [13:45:08] so if you got your LM IMU the right docked alignment, then PAMFD will show you all 0° for the V42 [13:45:21] V42 is an attitude increment, while V41 sets an absolute attitude [13:46:45] if your CSM and LM are docked and PAMFD calculates 180° as the V42 angles, then your LM IMU has an attitude that is wrong by 180° [13:53:45] But then optics wouldn't have lined up on stars in P51! [13:57:50] hmm, weird [13:59:09] At least, not under CMC control. [13:59:48] wait, do you mean P51 in the CSM or LM? [14:00:07] CSM [14:01:13] what do you need a P51 in the CSM for? [14:01:59] all the docked alignment procedures assume that the CMC has a valid alignment and that CSM and LM have the same REFSMMAT [14:02:40] maybe the REFSMMAT is the issue [14:03:10] although, that isn't relevant for the docked alignment procedures [14:03:34] just then later when the LM is undocked [14:21:00] Well I'm screwed up somehow, but how? [14:23:31] docked alignments can be tricky. First you have to make sure the CMC really has a good alignment and then one you want. [14:23:37] the* [14:24:20] how did you uplink the REFSMMAT to the LM? [14:25:48] RTCCMFD. [14:25:53] which options? [14:26:07] landing site REFSMMAT I guess [14:27:11] also, did you use the "REFSMMAT" option or the "Desired REFSMMAT" one? [14:27:54] that gets cycled with the TYP button [14:32:25] RTCC: REFSMMAT page: Cycled to "landing site, time an hour into the future, coordinates provided for tranquility. MCC "Direct", calculate, upload. As to the CM side, P52 option 3, and I *THINK* I uploaded the same REFSMMAT. [14:33:59] ok, that sounds all good so far [14:34:12] so, the LGC in its initial state doesn't have a REFSMMAT at all [14:34:49] so during LM activation you are uplinking the first REFSMMAT directly to the REFSMMAT memory address, and not in the temporary slot. [14:35:05] that is what you are choosing when you press TYP [14:35:15] you almost always want it to say "Desired REFSMMAT" [14:35:34] just the first REFSMMAT uplink to the LGC would use the other option [14:36:04] the temporary slot is what P52 option 1 is using. [14:36:32] if you directly uplink a REFSMMAT then you usually break your alignment, which is of course not good [14:37:26] Hmm, off to the LEB to half-complete a P51 [14:38:31] P52, I mean. [14:40:58] I'm look at that PAMFD page again [14:41:36] the initial angle display is already doing the docked alignment math for you [14:41:53] so you would use the LM angles displayed there in V41 N20 [14:42:07] Which I did. [14:42:29] and then when the LM IMU has this initial alignment, you probably have to do the V40 to get rid of the NO ATT light, right? [14:42:45] and then after that you press the V42 button in PAMFD to get the fine alignment angles. [14:42:55] those should be very small at that point [14:43:59] and then when you have used the angles with V42, I usually press the button again to calculate the V42 angles again [14:44:10] at that point they should all say 0 [14:44:24] and of course all of this only works when the CSM+LM are still docked [14:48:23] Thymo, I found the reason why the LM needed to do 4 timesteps until it could do any systems timesteps! [14:48:29] it's because of the complicated LM EPS [14:48:37] all these ECAs, bus feeds etc. [14:48:45] they were not run in the right order [14:49:14] so during the first timestep the voltage didn't properly propagate, so to speak [14:49:30] Right. I noticed it took some time for the voltage to settle. [14:50:46] Grr. What REFSMMAT should I be using for the CM in lunar orbit? [14:52:14] landing site [14:52:24] with the options: Desired REFSMMAT, direct [14:52:59] CSM and LM should have the same REFSMMAT in lunar orbit. [15:02:28] looks like I fixed the initialization problem by changing the LM EPS order [15:02:36] I have DC and AC power on the very first timestep [15:03:28] Awesome [15:04:06] Then I need to look up the minimum voltage for the mission timers again. I had a custom value initially but I don't remember if that was valid or not. [15:07:39] I still need to be careful [15:07:46] I don't think it actually should work yet [15:10:03] mainly because there is a circuit breaker in the power chain between batteries and CDR/LMP Bus [15:10:12] and the circuit breaker does the timestep elsewhere [15:10:46] indy91: Yeah, that solved everything. The CSM didn't have the landing site REFSMMAT. V41 is now +30.970, +78.674, and -41.341 [15:11:09] is that a good V41? [15:12:29] V42 is probably more telling [15:12:53] s/V41/V42 [15:13:06] ok [15:13:40] you should probably do that as a V41 [15:13:49] and then check again what the V42 angles would be [15:16:54] but obviously not +30.970, +78.674, and -41.34 for V41 [15:21:02] ah, circuit breakers don't need a refresh [15:21:21] that probably means this init issue is actually solved [15:24:58] really complicated EPS [15:25:26] between the main DC buses and the batteries are 7 additional electrical devices we simulated [15:25:40] at least in the case of the descent batteries [15:25:49] ascent batteries is "only" 6 [15:26:58] battery -> ECA -> descent stage bus -> bus feed B -> Feed Tie 1 CB -> bus feed D -> bus feed A -> bus feed E -> CDR Bus [15:27:21] and that's just on of several variants how the power flows [15:27:23] ne* [15:27:46] and don't even start with cross feed, x-lunar feed... [15:29:07] Funny I come into seeing that, because I was just looking at how to add ECAS heat loads and saw alot of that lengthy connectivity [15:29:18] ECA's [15:29:48] yeah, that chain did its timesteps in the wrong order [15:30:20] so we had to do 4 systems SDK timesteps before any of the LM systems would work [15:30:31] or else the end of the chain wouldn't have a voltage [15:31:07] now we can run IMU etc. on timestep 1 after loading a scenario [15:33:14] Is the X-lunar bus even in yet? I thought it wasn't. [15:36:04] uhh, how else would we power the LM from the CSM? [15:37:49] I thought there was an issue that X-lunar wasn't properly implemented. You can't get power back if you disconnect all batteries. Or am I imagining things? [15:38:18] ah, that is correct [15:38:34] so it's probably not fully implemented yet [15:38:37] and needs work [15:39:05] great, just yesterday this still worked: http://nassp.cvs.sourceforge.net/ [15:39:18] and now I can't look at the CVS commit history anymore there [15:45:46] thewonderidiot: https://github.com/virtualagc/virtualagc/pull/1057 [15:48:44] indy91: That does provide me with some nice command. Currently pulling down the telemetryClient. [15:49:57] with a CVS client? [15:50:01] rsync [15:50:51] Shall I commit it to a new git repo? [15:53:34] Every file has ,v appended to its name. Thanks CVS. [15:54:13] yeah, please create a new git repo for it [15:55:48] LM EPS update has been pushed [15:55:58] now I can start working on moving systems to PreStep [15:56:12] Oh neat. I actually get to use shopt for once. The bash recursive ** is not enabled by default. [16:00:20] And I have a different kind of rename. Not gonna work. [16:04:49] Blah I am confused at how these radiators work [16:05:04] I see it calculates a Q and removes it but I dont know what parameters go in the config [16:07:09] example [16:07:10] ECSRADIATOR1 <0.0 1.0 0.0> 270.0 [16:07:11] 18.0 5.0 10000 [16:07:11] [16:08:14] 0.0 1.0 0.0 is the position, or rather direction [16:08:34] that's relevant for the radiative energy calculations [16:08:43] so sun shining on the radiator [16:09:33] 270 is a temperature [16:09:52] in Kelvin [16:10:15] 18 is the volume [16:10:44] gets used as "size" in the timestep [16:11:09] that is relevant for how much cooling the radiator can do [16:11:32] 5.0 is the isolation [16:11:58] but careful [16:12:07] that is used as the variable "rad" in the radiator timestep [16:12:13] there also is the variable isolation [16:12:17] that is a different one [16:12:38] isolation belongs to the thermal class. h_Radiator is derived from thermal [16:12:50] Right [16:13:01] Is it the same isolation as is found on the tanks? [16:13:02] so rad is used in the cooling equation [16:13:21] and isolation in the calculation for radiative heat from the sun [16:13:27] Ok [16:13:30] And the last number? [16:13:35] yeah, I think so. Tank is also a thermal object [16:13:36] Q? [16:13:43] so it would be the same isolation variable [16:14:02] last one is called mass [16:14:12] only gets used for the thermal object [16:14:55] in the parser, first it does this: [16:14:55] new_one->mass = mass; [16:14:59] and then [16:15:04] new_one->SetTemp(temp); [16:15:12] and in that function [16:15:13] Temp = _t; [16:15:13] energy = Temp * c * mass; [16:15:23] so it calculates an energy for the radiator [16:15:40] not sure how relevant that variable is for the radiator [16:15:55] but temp certainly is [16:16:04] it gets used in the radiator equation [16:17:51] Now how is all that stuff in the IMU section tied in [16:18:49] I see some was commented out, and probably because those values are set in the config [16:19:01] But it still keeps isolation and Area [16:21:56] And that 1/4 V is still puzzling [16:29:10] indy91: One downside with the way I pulled it with rsync is that we'll lose the CVS commits. [16:29:23] hmm [16:29:43] probably not toooo bad for the telemetry client [16:30:12] I'm not sure how it was setup on CVS but I think it lived in the same CVS repo as NASSP so the only way would be to clone that and remove everything else and commit that. [16:30:31] Copyright information and such should still be in the files though. [16:31:42] https://github.com/Thymo-/telemetryClient [16:36:24] great, thanks [16:41:13] So. Now that we have multiple repositories as a project. Should we consider making a NASSP organisation? They've done this with the VirtualAGC project and it's working really well. You can add multiple repo's to that organisation and assign permissions to people that are in the organisation. [16:44:07] Does anyone have an idea as to why new_one->Area = (1.0 / 4.0 * volume); was used as an equation? [16:44:17] It really makes no sense unless I am missing something significant [16:44:41] considering dseagrav owns the repo, I would suggest making a post about it on the forum advertising that approach [16:46:36] rcflyinghokie, I have no idea [16:47:05] Considering the IMU code says this is surface area, I wonder if this math should be changed [16:47:40] Unless it is computing it for something else [16:48:29] Because its not surface area of a sphere lol [16:48:36] we can't simply change it [16:48:49] it would change every radiator we have [16:49:00] Yeah I know, thats why i am thinking there is a reason for it [16:49:08] Just bugs me that I cant figure out the math [16:49:59] essentially the 1/4 factor is a relation between the radiative heat from the sun and the cooling effect of the radiator [16:50:33] so with one parameter in the config, you can change the overall behavior, and that relative factor stays at 1/4 [16:51:41] Oh its not simply a conversion [16:52:23] Well for now I will leave the radiator alone, However I want to make the IMU generate heat when the OPR cb is in [16:53:23] put it in the IMU SystemTimestep [16:54:05] I guess it would have the same overall effect if I leave the radiator/heater code alone and just make it give the excess heat to the glycol [16:56:59] // FIXME: IMU Enabled-Mode Heat Generation Goes Here [16:57:04] That was easy to find haha [17:01:56] Is there an Init for the IMU? [17:02:11] yes [17:02:34] hmm [17:02:36] but don't use it [17:03:14] The if statement will go in the timestep under the code to turn off the heater, correct? [17:03:32] I don't know what you want to do [17:03:58] Ok right now I am trying to make it generate heat when the opr CB is in [17:04:04] Or when it is powered [17:04:11] like you did with the GASTA [17:04:31] However I am running into a few mental snags with how I want to do this [17:04:36] hmm, this could be a bit complicated [17:04:44] Here is my "ideal" situation: [17:05:16] the CSM has: IMUHEATER [17:05:43] When in standby, the heater keeps the IMU at a constant temperature and vents any excess off to space via the radiator (I think this is how it is done now) [17:06:08] When in operation, the heater turns off when above a certain temperature and the heat is directed to the glycol instead of the radiator [17:06:47] One fundamental problem with this is temperature monitoring, what do you measure for IMU case temperature in that scenario [17:07:35] it's a thermal object, so it has a temperature [17:07:56] I guess you mean LM-IMU-Case [17:12:02] Yes [17:13:35] What i would love to have happen is the radiator can vent only x amount of heat per unit time, and if it has more heat than that to reject it puts it into the glycol if that makes sense [17:13:40] rcflyinghokie: Would sampling the IMU's state every tenth of a second and dividing by 36 (maximum anular rate is 360 degrees/sec about all axes) and 72 (in a single axis) and using that as its heat contribution to the glycol hurt too much? (It'd also allow IMU overheating.) [17:13:52] angular* [17:14:03] one question, what did you mean with "when in standby". Standby heater or standby mode? [17:14:32] When the breaker is in standby, so the heater is kicking on and off via the temperature switch and venting excess heat into space [17:15:03] is the standby heater not on in normal operation? [17:15:40] Let me check but I believe it is controlled by a temperature switch in standby or operation [17:16:05] And Cannibal^ I don't exactly follow, is that to compute the heat generated by the IMU as it does work? [17:16:31] I think that goes one step too far for now [17:17:59] Yeah constant heat load is where we need to start [17:18:37] And for the heater, its on a thermostatic switch to maintain 130F +/- 4F [17:19:37] rcflyinghokie: Yep. I'm thinking that as the next increment because servos get hotter the more they work, and there was a mention yesterday about adding more failures. [17:20:01] Yeah that can be done down the road once we have the heat paths down [17:21:00] hmm [17:21:29] And when in operation, blowers are activated to transfer heat from the case to the glycol [17:22:07] we could write a simple controller class for this in lm_ecs [17:22:11] "The blowers are turned off when temperature exceeds +139F" [17:22:17] That seems weird [17:22:31] Unless it's a typo [17:22:52] Or they arent needed at higher temperatures to get the heat to the glycol [17:23:39] Ah yeah thats the case I think, the schematic has the switch open at 139F [17:24:13] It might need a controller [17:24:31] PDF pg 96 in the LM 10 AOH V1 [17:24:38] Has a good diagram [17:29:11] I think your suggestion is good [17:29:56] a controller class that switches between radiator and glycol [17:30:48] my question is, apart from the standby heater, does the CSM IMU have the same setup? [17:30:49] Now the question with that is what do you use to measure temperature of the IMU case [17:30:58] Let me look [17:31:06] imucase->Temp [17:32:14] So it still measures the case temp, but excess heat beyond the radiators limits goes to glycol as the heat load? [17:32:26] And for the CSM, the IMU doesnt generate heat [17:32:30] Just has a boiler as a heater [17:33:10] Yeah just a boiler [17:33:13] I meant the real CSM [17:33:17] Oh haha [17:33:34] It might but I will look [17:34:03] hmm [17:34:49] IMUHEATER in our CSM is basically just the heat load, right? [17:35:26] Yeah [17:35:46] Also its the heater to keep the temp up [17:35:53] right [17:36:08] so what is wrong with that setup for us? [17:36:25] for the LM* [17:37:14] ah, it's all confusing [17:37:41] The real CSM IMU is identical [17:37:53] except standby heater I guess [17:38:14] whoo needs that anyway, the CSM IMU survived Apollo 13 [17:38:25] That it did [17:38:34] I wonder if it was at operating temperature at EI [17:39:19] the AGC would complain otherwise [17:40:26] Our CM takes the IMU heat and places it directly into the radiator/glycol [17:40:40] yeah [17:41:11] Well into the glycol, which then rejects to a radiator via H/X [17:42:23] But I dont think it simulates operating heat, just a constant heat [17:44:09] I don't really know what the best way forward is [17:44:31] I'd prefer we start with ECS fine tuning soon and not get lost in details [17:45:14] I guess for now I can but my boilers back on for heat [17:45:19] *put [17:45:25] That way everything can be worked out [17:45:37] But that presents always on or always off [17:45:54] The heat loads are necessary to fine tune for temperature controlling [17:46:33] Thats why, as much as it sucks, I think adding at least some system heat is necessary for fine tuning rather than the boilers [17:48:36] Would a simple controller work for now, in standby leave it as is, and in operation add a heat load to the glycol? [17:48:51] Nothing fancy just a simple switchover [17:50:12] I think we have encountered a weakness in the simple heat load implementation [17:50:32] I have assumed the heat always comes out of nothing [17:50:53] not directly connected to anything, just closely related to e.g. the circuit breaker [17:51:18] but in the case of the IMU we have a device that would do the heat generation [17:51:20] the IMU case [17:51:38] The IMU case is a radiator though [17:52:14] yes, but that is basically what we have as IMU temperature, right? [17:52:32] the temperature of that radiator [17:52:40] morning! [17:52:57] hey [17:54:37] I think so [17:54:44] I havent experimented much with it [17:55:00] shouldn't we actually put the heat into that radiator? [17:55:13] Yes [17:55:37] Thats why I was saying any excess heat the radiator cannot eliminate on its own goes to glycol [17:55:58] But you are saying instead of a heatload, use that radiators heat [17:56:14] but what is this excess heat [17:56:20] relative to what? [17:57:23] It could be conditional [17:57:45] So if the IMU is in standby, the boiler keeps the radiator at a certain temperature [17:58:03] It radiates heat and is filled back up by the boiler so to speak [17:59:01] In operation, the heater (or at least power consumption) is turned off, the heat is added to the radiator at a higher rate, and the glycol via a heat exchanger can keep it regulated based on the temperature parameters [17:59:13] Would that work in principle? [17:59:58] I don't know much about our heat exchangers [18:02:07] It is simply a Q pump if that makes sense [18:02:15] And it can be set to temperature control [18:02:18] hmm [18:02:21] that is interesting [18:02:34] a lot of this could be done in the config [18:02:44] Yeah you got me thinking about just that [18:03:04] Perhaps using a radiator as the device that adds heat from the system to the glycol? [18:03:32] Just like the IMU case in this, well, case [18:04:10] heat loads can be connected to any thermal system [18:04:22] so the IMUHEAT would go to the radiator instead of directly the glycol [18:04:27] Right [18:04:44] and then a heat exchange between the IMU case and the glycol [18:04:47] Yes [18:05:08] Question is do we want this method for all the heat sinks attached to glycol [18:05:16] GASTA for example is not done this way [18:06:50] yeah, but the GASTA doesn't have a standby heater [18:07:05] we probably need to do this for systems with an extra heater [18:07:11] but not for the others [18:07:57] Yeah true [18:08:07] with this setup we don't even need to disable the IMU standby heater. which would be wrong anyway [18:08:23] No we dont, it should just be temperature controlled [18:08:36] Unless, of course, the IMU STBY is pulled [18:08:40] yes [18:08:43] Or not powered [18:08:47] but that's how it already works [18:08:55] but we need the equivalent of the blowers [18:09:05] We need to remove the code that turns the heater off when in operation [18:09:15] oh, I didn't know we had that [18:09:23] The blowers can simply be the heat exchanger I guess [18:09:43] if(IMU_OPR_CB.Voltage() > 0){ [18:09:43]