[13:40:28] NASSP Logging has been started by indy91 [13:40:30] hey [13:42:12] I've developed a bad habit of being overly ambitious and having to delete all my progress again because I can't get it to work with older code [13:42:29] otherwise I would already have a good ECA update [13:43:32] oh no [13:44:26] Side note, I have started a tracker for LM cb's and implementation of power and heat [13:44:35] I am slowly filling it in now [13:45:32] slowly working to fill it in [13:45:45] but I replicated the cb chart from the systems handbook [13:47:06] sounds like a good approach [13:48:58] just something to keep it all in one place [13:53:40] so how much heat would go into the ECA? [13:56:04] a function of power load? [13:56:10] or current [13:58:48] hmm [13:59:10] thats a good question [13:59:27] The ECA breaker heat loads are where I would start though [13:59:58] seeing as the "heat load" on them is a lot higher than the power load, it might take that into account [14:00:38] I think thats a good steady state value to start with [14:01:25] those 10 Watts [14:01:58] yeah [14:02:13] the ascent is interesting though with 20W of heat but 5 on the cb [14:02:50] but I think it would have additional heating based on how much power is flowing through it of course [14:03:01] which could be what a lot of these cb heat loads refer to [14:03:42] the DES ECA circuit breakers really don't do much [14:03:56] only the power supply for the battery instrumentation and control in the ECAs [14:04:03] including current monitor [14:04:13] for over and reverse current [14:04:35] so that heat load should go all into the ECA [14:05:04] the CONT breakers dont have an associated heat load, just power load [14:06:23] only momentarily [14:06:30] they only switch relays [14:06:36] yeah [14:06:39] latching ones [14:06:49] probably why theres no heat load [14:06:56] there is one relay that would be under permanent power if you were to hold the switch to Off/Reset haha [14:07:05] hey [14:07:10] don't think we should give that a heat [14:07:11] lol [14:07:11] hey Alex [14:07:15] agreed [14:07:17] morning Alex [14:07:30] I see four heat loads all called ECAHEAT [14:07:41] you mean 4 plates? [14:07:50] ECAHEAT LM-SCERA-ECA-Plate [14:07:54] ECAHEAT LM-DESBAT1-ECA-Plate [14:07:55] etc [14:08:06] ok so right now "ECA HEAT" is one thing [14:08:19] Ideally each ECA will get its own [14:08:28] and those directed to the appropriate locations [14:08:30] and they should have different names [14:08:33] yes [14:08:52] since ECA heating wasnt a thing yet, I didnt name them separately yet [14:09:22] I guess the PanelSDK would only have a problem with that when you want to get a pointer to them [14:09:48] We will need an DESECA1HEAT DESECA2HEAT [14:09:49] etc [14:09:54] indy91, so I was experimenting with the landed vessel hack that was posted on the Orbiter forums [14:09:57] easy to add [14:11:30] 4 ECAs correct? [14:11:36] 2 DES 2 ASC? [14:11:39] yes [14:12:17] ok I will retarget the .cfg file to represent that [14:12:41] just need to check which ECAs are where [14:13:03] why do I have the feeling that it's my fault that there needs to be a landed vessel hack... [14:13:27] or does that also apply to Orbiter 2016 [14:14:36] well, I think that the hack won't work very well for the LM unfortunately [14:15:00] does it break GetWeightVector again [14:15:50] well, the advantage was supposed to be that you would not have the LM jiggling around on the surface when landing on an uneven surface [14:16:49] it would just go straight to the landed state when touching down...this hack does do that, but at the same time it always puts the attitude at "wings-level" (i.e. FDAI 0,0,0) [14:17:43] and that is not very realistic in my opinion... I think you still want to see a tilt visually if there is to be one [14:19:06] yes [14:19:11] so not viable for us then [14:19:40] I guess Ryan has to try and not land directly on the slope of the Surveyor crater then :D [14:19:44] but there is another area where we can use it amd it works very well [14:19:59] hold the saturn V in place during pre-launch [14:21:11] it basically locks the vehicle in a landed position so any thruster firing does nothing at all to the state [14:24:30] sounds useful [14:25:05] I already have code added to the ML in my local branch [14:25:41] it could in theory remove the need for the addforce we use I guess [14:26:42] so how I am testing it is at T-1s (SATE_LIFTOFF) the vehicle is "released" [14:28:23] but I guess the addforce is still needed to simulate the "Soft-Release Pin Dragging" [14:30:13] Haha I also had a "hovering" LM by Surveyor [14:30:57] quick question, the lem doesn't use any of the powermerge classes does it? [14:31:08] it does [14:31:11] it has one [14:31:13] rcflyinghokie, you using linear interpolation? [14:31:20] and I am just adding two new ones haha [14:31:35] yeah [14:32:19] ahh okay [14:33:16] oh I lied [14:33:25] it has a lot of PowerMerge for the pyro system [14:35:51] okay, but just PowerMerge, by the looks of it, no nwaypowermerge [14:38:37] if that's the case it will make my project way easier [14:39:08] yeah, no nway one [14:40:55] we only have 2 of them then, total [14:41:41] I found an ECS mistake in doing this anyways [14:42:00] there are only 2 cold plates not 4 in the des stage [14:42:18] I have fixed it in the cfg and added the ECA 1-4 heat [14:43:09] while I am here, let me see which inverter goes on which plate [14:43:45] Ah scratch that...we can cross that when looking at the inverter again since it only has 1 pointer right now [14:47:42] indy91 PR made [14:48:06] wish i caught that error earlier [14:54:03] bat 1 2, pyro a, and eca1 all share a plate....bat 3 and 4 and eca2 share a plate [14:56:23] you now have a heat load for each ECA [15:01:05] ok [15:18:40] ah need to edit my pr lol, forgot the staging code with old plates [15:33:26] I think I'm finally getting somewhere with the ECA [15:33:32] not super clean solution, but good enough [15:36:46] nice! [15:36:54] mind if I take a peek? [15:38:15] what do you want to look at? I would just push it to the Orbiter2016 branch once I am done. [15:38:33] and it's not about heat yet [15:38:56] it adds ECA classes, temperature, over and reverse current monitoring, saving/loading of the relays for that [15:39:04] battery caution and component lights [15:39:38] ah ok never mind [15:48:58] hi [16:01:12] good afternoon [16:06:14] morning! [16:09:26] hey Mike! [16:09:35] Hows the bonding coming lol [16:09:55] presumably fine lol [16:10:25] my current issue is that Craig's DSKY display, while very pretty, is kinda slow and can't keep up with an emulator [16:10:51] so until I can get in contact with him.... I'm trying to figure out how to dump its firmware so I can reverse engineer it and install my own :P [16:12:20] haha good luck [16:15:20] hey Jordan [16:21:38] indy91, this is what I added for the ML: https://github.com/jalexb88/NASSP/commit/eae73f7ce73bc3f9ce0bbdfdfe1c4e95b0a56c49 [16:22:40] the effect is the vehicle is locked into place until T-1s or if a hold is active [16:24:16] Ive been looking for a solution like this for a while, since I don't like the way the vehicle can "creep" off position if a thruster is fired [16:32:33] I can probably also further confine it to state > STATE_ROLLOUT && state < STATE_LIFTOFF [16:32:48] so that it doesnt affect roll-out scenarios [17:10:45] AlexB_88 Hi alex, I'm fighting with Indy for a solution. I want to create multiple branches, just like you e.g. LMVC, LC39, LUT, etc. However, they should have the orbiternassp/NASSP/Orbiter2016 as a basis. I didn't make it. No matter what I do as a base, my Jordan-64/NASSP/Orbiter2016 is used. Do you have any idea? Or any of you other guys? [17:23:46] hmm, I have orbiternassp/NASSP/Orbiter2016 as my upstream [17:23:56] someone who knows more about git than me can help better, but I think it has to be based off of your orbiter2016 branch [17:24:17] by basis are you talking of the origin? [17:24:29] if so then yes it would be Jordan-64/NASSP/Orbiter2016 [17:24:49] and then you can keep up to date with the main branch my merging in from upstream [17:25:50] when I'm working on long projects I I periodically fetch and pull from upstream to whatever branch I'm working on [17:26:19] same here [17:31:59] AlexB_88, hmm, maybe we should come up with something more clever to determine the position where the Saturn V gets held [17:33:43] the way I have it now is it detects where the vehicle is in the scenario [17:34:06] and then calculates the distance from which pad it should be at [17:34:15] works quite well in the tests ive made [17:34:33] so on Apollo 10, it will snap to pad 39B [17:37:29] https://github.com/jalexb88/NASSP/commit/e09b4ad0eae7e9d3a90e7ec18542384882d56ad5 [17:39:47] that is also the same way the ML detects where to put place the vehicle in the rollout code [17:40:08] that if clause is scary [17:40:26] that's really not code that should use the Hold parameter [17:43:29] right [17:43:50] I mean its the only way for now I think to detect that case [17:44:56] if (sat->GetStage() < LAUNCH_STAGE_ONE && state > STATE_ROLLOUT) [17:45:00] why does that not work [17:45:19] ah [17:45:20] LAUNCH_STAGE_ONE is when it has commited to lift off [17:45:40] because I never think of the simple way at 1st :D [17:45:54] haha [17:49:07] so should I just leave out the hold case for now? [17:49:54] or does it never go to LAUNCH_STAGE_ONE in that case? [17:50:07] it should never go to LAUNCH_STAGE_ONE [17:50:10] ah ok [17:51:18] it checks if it can commit to launch [17:51:25] and then it calls [17:51:26] IuUmb->Disconnect(); [17:51:29] in the ML code [17:51:36] IU umbilical disconnect [17:51:39] right [17:51:46] and then in IU code it does [17:51:47] //Set the launch stage here [17:51:48] if (!IsUmbilicalConnected() && lvCommandConnector.GetStage() == PRELAUNCH_STAGE) [17:51:49] { [17:51:49] lvCommandConnector.SetStage(LAUNCH_STAGE_ONE); [17:51:50] [17:51:51] on the next timestep [17:52:10] so umbilical disconnect is what causes it to go to the launch stage [17:52:21] which never happens in a hold [17:53:12] nothing really happens anymore with a hold :D [17:53:29] no capability to recycle or something [17:53:32] eventually... [17:55:14] makes sense [17:55:22] anyways the change works well [17:55:28] I will test a full launch [17:56:08] then check the IU SV and if good then this is quite good I think [17:56:23] yeah [17:56:35] already tested pad aborts [17:57:33] wonder if this change might even help IU accuracy [17:57:38] I wonder* [17:57:56] since it basically forces the vehicle into a perfect psoition at GRR [18:00:18] could be [18:00:36] although I've never seen more than a few meters position error [18:00:39] at liftoff [18:17:21] indy91, so at [1+10.450000] (T+10s) SV Accuracy: 0.064873 0.038905 2.642830 [18:19:37] ok [18:19:57] that 2.6 meters is an error in height [18:20:27] I think I once fine tuned that then you change the touchdown points and it changed the height of the rocket haha [18:20:50] haha [18:21:01] that must of been ages ago though [18:21:10] yeah [18:28:34] post-insertion: SV Accuracy: 106.424517 2.013095 44.501722 [18:32:17] indy91, just checking off these boxes, I see in the LM RGA, you have a guessed value. Its powered via the ATCA AGS breaker wouldnt you want to use that power/heat? [18:36:53] The Systems Handbook values for that breaker? [18:37:11] Is the RGA the only thing that the ATCA AGS circuit breaker powers? [18:37:32] I dont know I am backtracing it now [18:37:54] and the values for the breaker are 2W and 2W [18:38:18] no idea where I got the 8.7 [18:40:33] AlexB_88, one of these days I have to enable drag in the LVDC orbit navigation [18:40:37] orbital* [18:40:41] maybe that helps a bit [18:41:18] not that we have much drag, but that's what I thought about the CSM, too, and it turned out to be somewhat relevant [18:52:39] nah [18:52:42] 0.05 Newton drag [18:52:52] I doubt that's relevant at all [18:53:48] maybe I am missing it, but does the ATCA AGS breaker power the RGA? [18:54:06] I don't know, that's what you said :D [18:54:31] it doesn't [18:54:38] oh no, I am basing it on your RGA class lol [18:54:42] the normal ATCA breaker [18:55:04] rga.Init(this, &SCS_ATCA_CB, (h_HeatLoad *)Panelsdk.GetPointerByString("HYDRAULIC:RGAHEAT")); [18:55:16] ATCA AGS is "SCS_ATCA_AGS_CB" [18:55:21] Ahh ok [18:55:28] blame Grumman [18:55:29] Looks like the RGA gets AC and DC power [18:55:37] ATCA, ATCA AGS, ATCA PGNS... [18:55:46] yeah I can never keep those straight [18:56:15] I think ATCA AGS and PGNS do very little [18:57:01] and now I understand [18:57:06] SCS_ATCA_AGS_CB powers the RGA test signal [18:57:19] but SCS_ATCA_CB powers the RGA in general [18:57:24] ah ok [18:57:39] I have some power numbers for the RGA from the LM-10 handbook [18:57:53] otherwise ATCA AGS mainly powers the RCS from the AGS side [18:57:58] LM 10 vol 1 pdf 201 [18:58:14] and ATCA PGNS does the same for the PGNS [18:58:18] Starting power SS power and transient power both AC and DC on there [19:05:24] I need to look at those a little more [19:20:42] I have a working battery fault light [19:20:56] and battery light in the CWEA [19:21:32] I don't think we can get the overcurrent or reverse current conditions [19:21:39] reverse probably doesn't work at all [19:21:50] and for the overcurrent the voltage drops too much for anything to work [19:21:59] because it drops too much [19:22:17] as n7275 said we should look into changing the voltage as a function of current model [19:22:50] absolutely, batteries in general could use scrutiny [19:23:15] just curious, were you able to get an overheat by turning off the glycol/evap [19:23:32] I was able to get overheat by editing the scenario :D [19:23:42] haven't seriously tried turning off the glycol [19:23:54] probably would take a while to heat up [19:25:17] but I will try again [19:25:26] I'm basically done, just some more testing like that [19:28:25] haha just curious [19:37:49] because of n7275 I can't even test this with Apollo 5 anymore [19:37:57] he fixed the LM overheating before launch :D [19:56:16] good to hear [19:58:01] i just said a bunch of things about my work on powermerge, but my irc client was only pretending to be connected [19:59:14] well I haven't actually tried Apollo 5 again, but you said you fixed it. [19:59:31] nice from your IRC client [20:00:54] when I tested 5 it didn't overheat [20:01:15] I should try again with the ecs updates [20:01:34] whenever I tried Apollo 5 it was a good test case for the IMU light on the DSKY working... [20:02:02] TEMP light of course [20:02:09] but that's IMU temperature [20:11:22] indy91, PR sent [20:16:46] Apollo 5's scn might need to be reinitialized with the current ecs [20:22:17] yeah [20:32:33] AlexB_88, I want to think about your PR for a bit more. I'll probably merge it tomorrow. [20:33:18] no worries [20:39:52] indy91 if you want I can reinitialize Apollo 5 I just need the details of what the ECS state was supposed to be at launch [20:41:46] We also have a cold and dark scenario at T-1 hour without any ECS stuff init. I'll probably just activate the LM from there to get a new T-60 seconds scenario. Have done that twice before. [20:42:01] might write down the procedures for that this time haha [20:43:35] oh ok cool [20:43:52] that will start the glycol at about 55F [20:44:00] but the cabin will be empty [20:45:00] yeah [20:45:51] doesn't really matter, in the past I've activated the ECS only as much as to not need any changes during the mission [20:46:08] filled the cabin of course [20:48:09] yeah I think just filling the cabin will work, the rest can initialize as necessary [20:49:24] all that shouldn't be different than before, right? [20:49:55] doesn't have to be perfect and exactly like the real Apollo 5 mission. As long as the ECS isn't doing anything annoying during the mission [20:51:42] That T-1 hour scenario should be as clean as possible, as the T-4 hours scenarios for the other missions. No or very little changes required with updates like your big LM ECS one. [20:52:32] yeah that will be fine, the LM just will initialize with no pressure in the cabin (as it would if "spawned" before TDE) [20:53:03] problem with that is it will likely consume LM O2 when trying to repress it [20:53:35] you could just include the cabin at sea level composition in that and let the rest initialize clean [20:54:34] haha, I'm not worried about that. There is enough O2 for a repress and no astronauts consuming any. Or creating CO2. [20:56:24] the mission is more like a demo. Not manual switch changes required. [20:56:43] I can just switch away from monitoring the descent O2 level and nobody will notice :D [20:57:28] when I have activated everything I usually switched to the ascent ECS configuration [20:57:40] so that everything still works after staging [20:58:00] might have to check again if the programer should do any of that and if we are still missing something [21:00:09] night! [12:49:38] good morning [12:52:11] hey [13:40:40] how's it going today? [14:00:18] got here early to watch the Crew-2 launch [14:13:34] and looking at LVDC drag calculations [14:13:55] might have a question for Mike later, for the AS-206RAM program listing [14:14:49] did you ever get yourself the listing from Ron? [14:29:14] no, I dont think so. [14:32:26] you just have to prove to him that you are a US citizen haha [14:38:51] ahh, okay. that should be easy to do [14:39:24] only if you are actually interested in the LVDC code of course [14:39:48] Mike has some experience reading LVDC code so I'm sure he can answer my specific question [14:43:00] our S-IVB doesn't have very realistic aerodynamics [14:43:33] in its normal attitude, pointing to the velocity vector, the drag is very, very small [14:43:41] because we use a CD of only 0.1 there [14:43:48] oh wow [14:44:09] should probably be something like 2.5-3.5ish [14:44:20] good guess [14:44:25] it's difficult to compare directly to LVDC drag calculation [14:44:42] it uses a mass normalized parameter which even partially has the area in it [14:45:28] and I'm also not 100% sure how the legacy drag model in Orbiter works [14:45:37] you define [14:45:38] SetCrossSections (_V(167,167,47)); [14:45:39] SetCW (0.1, 0.3, 1.4, 1.4); [14:46:00] so if it's pointing forwards it would use the 0.1 for CD and 47 m² for area [14:46:21] and e.g. 90° pitched upwards it would be 1.4 and 167 [14:46:29] 0.3 is the CD for pointing directly backwards [14:46:46] I haven't read that part of the api guide in a few years [14:47:00] not exactly sure how it calculates in between though [14:47:17] for cross section and CD [14:48:48] not sure, my guess would be something very simple x*sin(theta)+etc... [14:48:56] yeah [14:49:27] have to fix my test calculations for that, I'm doing it wrong [14:49:54] but for the case of 0° and Apollo 11 Earth orbit mass I'm getting a CD of 2.2 to get the same as the LVDC [14:50:05] I think our cross section numbers are mostly right [14:53:26] I don't really want to change our aerodynamic properties until the RTCC is properly accounting for drag in all trajectory calculations [14:53:36] but I can adjust LVDC parameters