[11:21:55] NASSP Logging has been started by indy91 [11:21:57] hmm yeah, you better do a +X translation at CSM sep, or else the venting is going to push the LM into the CSM [11:22:16] did they really leave thw venting on during TD&E, that just seems not a good idea [11:22:36] SIVb active docking [11:24:57] right? [11:25:01] could the tank pressures after TLI be low enough that there is neglegable thrust, obviously the tanks would need to be pressurized during the burn though [11:26:47] this is Apollo 9 [11:27:05] on the other missions the CVS isn't on after TLI, or at least all venting is turned off before TD&E [11:27:08] oh whoops haha [11:27:27] yeah just Apollo 9 where this is a question mark, potential issue [11:28:18] maybe they thought the risk of a tank rupture from a valve sticking closed was higher than the risk of a collision. both seem pretty bad though [11:28:58] yeah, not long after TD&E the S-IVB was going to do a burn [11:29:21] CVS graphs in the flight evaluation report are a bit garbage [11:29:47] bad scan or bad data? [11:30:38] https://www.ibiblio.org/apollo/Documents/lvfea-AS504-Apollo9.pdf [11:30:41] PDF page 139 [11:31:24] I think it's fairly clear from this that the vent was on all the time until "TLI" [11:39:27] hmm [11:40:12] yeah, CVS is on for quite a while [11:40:44] are the acelerations here matching up with yours? [11:42:05] roughly. LVDC state vector is pretty bad, have to look if the navigation equations are right [11:42:32] oh actually [11:43:03] the LVDC venting numbers for Apollo 9 are pretty high [11:43:42] so it's the numbers, not the equations, I think [11:45:44] https://i.imgur.com/LYPjuz7.png [11:46:17] definitely looks like guidance is higher there than actual [11:49:35] might be something Apollo 9 specific. In the LVDC it's a constant acceleration over a time segment, and at some point the CSM and LM are gone, mass a lot lighter, acceleration higher [11:50:48] yeah, at some point it becomes just a very large, very thin aluminum tube. [11:52:00] at 3h GET there is a difference of 10km already between LVDC venting model and my NASSP solution [11:52:13] for Apollo 11 and 14 it was only about plus and minus 1km [11:53:15] just would like to find a line mentioning these things, venting during TD&E etc. Just to be sure [11:55:32] "A notice-ably higher closing rate with the S-IVB was also noticed. The propulsive [11:55:33] venting was visible on both sides of the forward part of the S-IVB." [11:55:43] in the mission report, describing docking [11:56:28] Throughout the exercise, the S-IVB remained a very stable base, and [11:56:29] with the exception of the venting acceleration, no S-IVB motion was de- [11:56:30] tectable. The magnitude of the propulsive venting was greater than ex- [11:56:32] pected. Very little forward thrust was necessary to null the initial [11:56:32] separation velocity; and subsequent station-keeping and docking maneuvers [11:56:33] were performed using aft thrust almost exclusively. [11:57:06] so that clears that up! [12:09:08] oooo we should add some venting particles [12:12:03] yeah, I have nothing right now. Also, only one thruster. It is two vents, right? Must be to not create an attitude rate [12:18:40] two propulsive vents and two non propulsive ones [12:18:50] on opposite sides [12:21:27] yeah [12:21:47] I'll probably not get into that, I'm only interested in trajectory and RTCC and LVDC right now [13:11:59] TD&E was pretty good [13:12:04] I'm beginning to think that my systems project is a bit more effort than it's worth. [13:12:07] nice [13:12:23] yes the S-IVB is thrusting towards you [13:12:34] but only about 0.1 ft/s every minute or two [13:12:46] ah damn [13:14:00] what makes it so complicated? [13:19:45] I'm just thinking that if I need to spend a month or two of effort on this, and making another breaking change, maybe there is something better for that effort to go toward [13:20:16] yeah I know that feeling [13:23:07] I still would like to improve the systems, but with my accumulated effort so far I definitely could have implimented lookup tables or something like that [13:24:22] my gravity model pull request for Orbiter is a good example of implimenting a feature without reinventing the wheel [13:31:11] I've often had projects that didnt really lead anywhere, but at least most of the time I learned something for the next time I was trying to implement something [13:34:20] speaking of projects that were totally worth it [13:34:24] my CSM produces lift [13:34:28] all of 0.8 mN [13:37:15] yes that is a good perspective. [13:40:37] haha 0.8mN what sort of L/D does that work out to? [13:41:39] about 1/1000 [13:41:48] oh wait, got a lot more right now [13:41:55] L = 0.003 N [13:42:00] D = 0.235 N [13:42:40] what I actually implemented are axial and normal aerodynamic coefficients [13:42:46] and then lift and drag get calculated from it [13:43:07] with the free flow regime (orbital altitudes) you never get any relevant amount of lift [13:43:11] not even in the CM [13:45:48] that makes sense. you kinda need viscosity for lift [13:47:53] good point, that is the explanation [13:53:24] its more of a particle collider than aerodynamics [13:57:06] any "lift" is just some momentum transfer from hitting angled surfaces [15:19:21] hey [15:31:02] hey Alex [15:38:18] Turry on the Discord is complaining about wrong textures again :D [15:38:34] and CSM cryo tank needles being wrong [15:45:41] yeah I'll have some time in November to fix up the VC's, I have a growing list :D [15:46:23] haha ok, that sounds good [15:46:53] I started thinking about the clcikspot logic again, too [15:47:32] I guess we eventually want them to be quadrilateral? [15:47:59] like, only use left mouse-click [15:48:23] and right only for things like the cover operation [15:49:06] hmm yeah, maybe [15:49:29] it's probably better for not accidentally clicking when you just want to move the view direction [15:49:41] well have to figure out a system for that I guess [15:49:46] will be a lot of work [15:50:37] unless we can figure out something clever that utilizes the current clickspot locations [15:51:52] doing something clever is probably better [15:55:09] I had at one point tried making a function that calculates the 4 corner coordinates from one single vector [16:20:40] hmm yeah, I'd have to look what the Orbiter API needs [16:22:22] but with vector math I could maybe be a help [16:36:16] morning! [17:00:46] hey Mike [17:00:57] how is Block I going [17:10:53] got the sense amps tested last night [17:11:32] building up the structure + backplane with the malco pins today [17:11:47] and then testing as much of the other stuff as I can [17:14:00] figured out how to read data in a coherent order yet? :D [17:14:08] I think so! [17:14:10] hopefully [17:15:25] my goal is to read this module tomorrow evening, but that might be overly ambitious [17:16:18] ah right, you have one with you [17:16:43] what was that one again? [17:18:32] module B22 of Sunrise 69 [17:20:26] that does sound ambitious [17:21:09] uff, my LVDC state vector now has a 50km error... [17:21:28] I blame the LVOT you got us ;) [17:24:53] hehehehe [17:25:30] its like they didnt take the CSM and LM mass into account when they calculated these accelerations caused by venting [17:26:30] bad mission to test this, actual venting acceleration was a lot lower on the actual mission, too [17:26:44] Apollo 9 [18:58:57] indy91, I think EntryOpt has issues with TEC after a fast PC+2 [18:59:09] with ATP midcourse solutions [18:59:52] I think just corridor control burns work, but if you try to target a longitude as well it seems to fail [19:00:37] I see the PC+2 PAD is calculated with RTEMoonOpt [19:02:36] I think EntryOpt is Earth centered-logic only [19:02:48] well [19:02:51] the function RTCC::EntryTargeting [19:03:07] hmm isn't MCC-5 still in moon SOI? [19:03:39] oh you mean the first MCC after a PC+2 [19:03:45] yeah [19:03:50] usually that should already be in Earth SOI [19:04:11] right [19:04:38] fast PC+2, so using the higher reentry speed constraint [19:05:08] the other problem with PC+2 is TEC is too quick for the normal timeline [19:05:50] MCC-5 is after MCC-6 [19:06:07] using the normal times [19:06:20] so I tried sending it to the generic MCC logic [19:06:36] which is an MCC 5 hours after TEI (PC+2) [19:06:56] and then it sends it straight to the MCC-7 in the normal timeline [19:07:24] but I think 5 hours after PC+2 is too early I guess (still in lunar SOI) [19:08:07] there would probably be only 2 MCCs in this case [19:08:22] right [19:09:04] thats sort of what the generic MCC logic does (generic MCC, MCC-7) [19:09:05] if its in Earth SOI then EntryTargeting should already be able to handle it [19:09:21] right [19:09:57] I just need to make the generic MCC a bit later then PC+2 + 5 hours [19:10:54] I guess so its at the same moon-earth position as MCC-5 would have been [19:11:21] maybe your MCC-5 is in Earth SOI, but pretty close to the Moon [19:11:24] and something fails there [19:11:35] yeah [19:12:05] I wonder if P37 could handle that case [19:12:31] probably takes 20 minutes to calculate [19:17:03] I think I can make the generic MCC happen at EI-25 hours, after a PC+2 [19:17:28] that way it should be far enough from the moon, but still an ATP solution [19:30:11] ah yes [19:30:25] it works well at EI-25 hours [19:31:05] I mean I don't know if we have any documents that would show the TEC timeline after a fast PC+2 [19:31:56] but I think an MCC at EI-25 hours, then a 2nd at EI-3 hours (MCC-7) sounds reasonable [19:34:05] oh and to support the flyby and PC+2 aborts, I made the TEC MCC check for docking status [19:42:29] ah ok [21:22:16] night! [14:03:43] good morning [14:15:50] hey Alex [15:58:12] indy91, I have a PR with some abort updates to Apollo 12 MCC [16:08:22] morning! [16:08:58] hey Mike [16:21:07] AlexB_88, yeah I'll take a look a bit later [16:21:10] hi everyone [16:21:25] hey [16:21:29] indy91, ok [17:31:30] thewonderidiot, Project "Read Block I rope by Sunday night" is a go or not anymore? :D [17:32:16] hahaha I dunno, I'm 50/50 on it [17:32:51] don't succumb to go fever [17:36:38] oh I'm definitely not [17:36:47] I tested all the inhibit drivers earlier and am now taking a break haha [17:39:05] everything looking fine so far? [17:47:02] yep! [18:26:19] strand selects are all good [18:26:43] so I think I just need to work out the reworks I need to do for the set/reset drivers and module select [18:29:18] ....and do the software changes [18:31:57] software being more challenging this time around? :D [18:32:21] hah I thought it would be... and it might still be I guess [18:32:32] but right now I'm thinking those are pretty easy [18:54:56] hmm, math is suggesting that replacing the 9.1 ohm coarse tuning resistors in the set/reset drivers with 11 ohms will bring them from 450mA right to 400 [18:58:57] you want 400? [19:08:23] yep! [19:08:26] 400 +/- 13mA [19:08:34] Block I tolerances are very loose :D [19:10:17] ohhh crap I'm an idiot and bought the wrong package reistors though [19:10:23] so I think it will not be today haha [19:21:06] oh noo [19:22:03] looks like Tuesday then [19:22:33] like any good Orbiter project [19:23:53] good news: the equations the RTCC uses to take drag into account analytically work fine!. Bad news: it's only semi-analytical and right now it only works with a pretty small step size, so not analytical at all! [19:24:12] hahahaha [19:24:46] good news for me is that I can pretty comfortably finish everything else for the Block I reader today [19:24:48] also bad news, the IBM RTCC document does not give me the step size they actually used... [19:25:07] booo [19:25:13] yeah, that sounds pretty complete [19:26:19] the RTCC uses strange unit for all of this, not only the Earth radii and hours, but something else. But when I translated it all to SI units it did work right on the first try, so that's pretty encouraging [19:26:50] although -- maybe I can do this with the fine tuning resistors, if I have some small values for those.... [19:26:54] what's the something else? [19:28:34] it is omitting the square root of the standard gravitational parameter from an equation... so, my best best it is basically in normal units but with that as a factor that you have to add if you change units [19:28:59] there is a few conversion factors in the equations that I could not really figure out completely [19:29:27] but it works in SI units, so I could probably figure them out if I try hard enough [19:32:30] yeah, the document calls them "characteristic units" and I can find a few examples in the literature that use those [19:33:42] but I have to convert everything. It doesn't use kg, it uses pounds. Not square meters, but square feet. So how do I go from density, kg/m^3 to characteristic units... do I want to find out :D [19:39:36] hahahaha oh boy [19:40:20] or I just use my SI units as usual and don't even have to do any conversions like that [19:46:41] okay I think I have come up with a resistor combo that I already have and should work [19:46:53] I might need to take advantage of the loose Block I tolerance but it should get me to 400ish haha [19:48:00] why do I hear the MacGyver theme song [19:51:43] hehhe [19:53:16] definitely doing this to my test board first instead of the real thing [20:28:39] night! [14:24:38] hey [14:25:24] hey hey [14:25:31] your PR looks good [14:26:44] ah great [14:27:53] I mean, it's not like I have test flown it. But probably the best solution with the aborts, even if slightly messy with the different cases and setting the EI times etc. [14:29:38] yeah, I mean eventually maybe it can not need an EI time to be set [14:30:16] like, after the abort, it checks the EI time by propagating the SV to EI or something? [14:31:28] makes sense [14:31:36] do we have a function for that? like PericynthionTime(cm); after the flyby/pc+2 [14:31:45] unlikely, but it could also happen that it doesn't go to EI [14:31:50] if the burn was off [14:31:55] right [14:32:13] but maybe a check on perigee time would be enough [14:32:27] as a initial guess [14:33:07] there are old and new functions one could use :D [14:34:54] PMMCEN is a good function for this [14:35:00] I need to better document it... [14:43:02] ok, documented [14:43:04] I guess you set an end condition? [14:43:12] prepare for spam [14:43:14] /INPUT [14:43:15] //sv: input state vector [14:43:16] //tmin: minimum time to integration before beginning to search for ending condition [14:43:16] //tmax: maximum time to integrate for desired ending condition (not used for time option) [14:43:17] //opt: 1 = time, 2 = flight path angle, 3 = radius [14:43:18] //endcond: desired ending condition, for option 2 the sine of the flight path angle [14:43:20] //dir: Search direction, +1.0 for forwards, -1.0 for backwards [14:43:23] [14:43:27] //OUTPUT [14:43:29] //sv_out: output state vector [14:43:30] //ITS: type of stop indicator (same as opt) [14:43:54] what I usually do in cislunar space is set tmin to 0 and tmax to 10 days (10.0*24.0*3600.0) [14:44:06] so you want option 3, search for radius [14:44:27] if it does not find the radius within 10 days, the stop indicator ITS is 1 (for time) instead of 3 (for radius) [14:45:15] nice [14:45:34] this is the function that e.g. TLMCC and RTE are using and iterating on [14:46:03] for this same purpose, finding EI, the Space Digitals display uses another function, which also includes drag [14:46:06] that could also be used in the TEC MCC code for setting the tz [14:46:09] but I think PMMCEN is good enough [14:46:50] TEC MCC need a tz? [14:47:00] oh for the case it does longitude control [14:47:50] yeah for MCC's before EI-24 hrs [14:50:33] which would only use longitude control under off-nominal conditions, but what exactly that means I haven't really figured out [14:51:00] it's only a mission rule that MCCs after EI-24 hrs will NEVER try longitude control [14:51:22] now if I can figure out a way to find TEI time without setting it in the abort code, I will say hold off on merging the PR lol [14:52:31] right [14:52:47] you mean an initial guess time? [14:53:04] yeah because I set them for every TLC abort [14:53:11] along with the EI time [14:53:27] do you mean an actual TEI [14:53:36] yes [14:53:49] maybe with MoonRevTime? [14:53:51] or sorry, abort maneuver time [14:54:59] I mean for the for the TLC aborts, where I set rtcc->calcParams.TEI for each case [14:56:58] right [14:57:05] PC+2 and flyby are special cases of course [14:57:33] for the others, your "TEI" time there is a course correction after the initial abort, right? [14:57:41] I feel like I have seen a burn schedule somewhere [14:57:51] more for the no-comm case [14:57:52] but still [14:58:44] the generic MCC is 5 hours after the TEI time [14:59:06] the TEI time being the TIG of the abort maneuver [14:59:33] yeah, that's what the Apollo 8 checklist say for no-comm [14:59:38] except for flyby, which sends you to the normal TEC timeline [14:59:38] 5 hours after the direct abort [14:59:47] right [14:59:50] and then EI-2 hours [15:01:00] oh btw I think I can use a better way to detect TEI after abort initiated from lunar orbit [15:01:19] instead of setting the TEI time, just check on the eccentricity [15:02:16] like I did with the LOI-1 evaluator [15:02:27] would that need to calculate the eccentricity on every timestep? [15:02:57] or is it just the logic that checks if TEI even happened [15:03:27] hmm [15:04:02] your LOI logic checks at LOI+7 minutes, once [15:04:10] that's a good way to do it [15:04:35] well my idea as I thought it might be every timestep yeah, don't know if that would be bad [15:04:58] unless it can be a periodic check [15:05:07] like once every rev [15:05:20] right [15:07:59] what I am trying to accomplish is the lunar orbit abort mode (AbortMode = 7) being able to detect any particular TEI you try to burn, without setting having to set a TEI time as a threshold for it to switch to the TEC timeline. [15:10:09] I guess like you said earlier there is a lot of messy code setting values like TEI and EI for every case, so making the MCC smarter to avoid having to set them [15:33:54] ok I am testing some code have it do a check on eccentricity > 0.7 once every rev [15:34:11] every time MoonRevTime goes back to 0 [15:36:13] hmm that might not work to well if TEI happens shortly after it went to the next rev lol [15:38:40] maybe it can be a certain amount of time into the new rev [16:07:14] maybe roughly when there would be AOS [16:07:16] after the TEI [16:07:29] that's also when the RTCC actually switches into a different mission phase [16:08:02] from lunar orbit to trans earth coast. That runs different display automatically, we don't really simulate that in the RTCC yet, although with our MCC we do use similar mission phases [16:10:19] AOS is roughly 15 minutes after TEI, looking at the flight plan [16:29:40] morning! [16:30:33] indy91, as you can see I am re-thinking the whole abort functionality for 12... lets hold off on merging it [16:30:50] I will set it to draft [16:30:55] hey Mike [16:32:51] hey [16:32:57] yeah, sounds good, take your time [16:38:48] during TLC, is there a way to "detect" a direct abort has been preformed, like a check on trajectory or velicity chnage? [16:39:01] velocity change* [16:40:39] but ideally not something running every time step but maybe every few minutes once a TLC abort is initiated [17:05:16] off to work, cya! [21:08:18] night! [15:10:30] hey guys [15:13:10] hey [16:01:31] I've decided that I haven't quite given up on the systems thing yet. [16:07:15] I had the brilliant idea that I could just read some papers on efficient methods of solving cubic equations of state for mixtures, rather than making my own [16:08:45] *lightbulb* lol [16:09:22] morning! [16:12:19] the big challenge was "how will I solve for equilibrium pressures without some sort of Newton-Raphson nonsense?" [16:13:50] the answer to which is: with the Antoine equation...which we already use for calculating partial pressures and boiling [16:14:41] hey Mike [16:18:53] haha yes we do [16:19:14] Antione is how I also did many of the initial states for the LM ECS [16:32:34] as long as no one needs to simulate microwaving pure water in a nucleation-site free container, I can improve the phase change behavior as well [16:37:57] thewonderidiot, congrats on recovering your first Block I data :D [16:38:04] thanks! :D [16:38:56] not quite enough yet for plugging it into my Block I branch, right? How many modules does Sunrise have? [16:42:26] 4 modules [16:42:49] and module B22 is as disconnected from the other 3 as possible -- everything in it you have to manually start with V30/V31 [16:43:03] so, definitely not enough for running yet [16:43:25] I should get the other three modules (if they still work enough) in an upcoming trip [16:43:33] haha ok, but good progress. Parity bits be praised [16:44:06] Block I technology, not quite as much praise :D [16:44:19] those damn 1006751 diodes [16:45:42] I'm so glad we don't have to worry about those for any flight Block II ropes [16:48:24] yeah, that could lead to many disappointments [16:50:55] what exactly do those diodes do again? [16:52:46] they do strand selection [16:53:06] in Block I, there's 8 sets of 16 sense wires that go through every core [16:53:15] each set of 16 wires is a "strand" [16:53:32] so when you flip a core, you have to pick out which strand you want connected to your sense amplifiers [16:53:46] you do that by forward-biasing the diodes on that strand, and reverse-biasing all of the others [16:54:03] but it means that if one of the diodes fails, the circuit is no longer complete for that sense wire and you get nothing [16:54:56] or if the diodes drift and become unmatched, you effectively see a DC offset at the sense amplifier, and if that offset is big enough the sense amp will always register a "1" even if no core is flipping [16:56:09] okay that makes sense [16:58:33] this Sundial module is actually doing something interesting on the parity bits for two of the strands [16:58:43] those have drifted enough that they now almost always read as "1" [16:59:10] but the amount they've drifted is almost exactly the same magnitude as a flipping core [16:59:33] so in the cases where they do pick up a core flipping, but the induced voltage is negative -- the drift and the core cancel each other out so the parity bit reads as "0" there [16:59:44] er, Sunrise [17:02:06] are these the diodes that are encased in potting material? [17:03:17] yup [17:07:38] fun fun [17:17:10] thewonderidiot, kind of reminds me of your first attempt at reading the erasable memory from your AGC restoration. Wasn't there something wrong bit one bit, too? [17:17:19] with one bit* [17:18:29] I need to dedicate some time to rewatching the restoration series. [17:20:15] never watched it? [17:20:19] oh [17:20:21] rewatching [17:33:29] yeah our erasable module had one bit that was completely dead [17:33:44] broken wire inside the module [17:34:08] so we had to change the backplane wiring to run the parity bit of the module into the sense amplifier for the bad bit [17:34:20] and disabled parity checking [17:34:29] i.e. we gave up parity in exchange for 15 working bits [17:34:52] right, now I remember [17:35:04] that was straight up a broken wire though -- no diodes at fault there [21:22:26] rcflyinghokie, are you the moderator of the reddit Apollo page? [21:41:17] Haha no [22:06:53] ahh, darn [22:54:08] the spam is annoying [23:23:38] Yeah I'd like to be one to be honest [14:41:27] hey [14:49:14] hey Nik [14:53:33] what's up? [14:58:29] not too much. made some more progress on my systems update last night [15:01:25] ah nice [15:01:32] I'm activating Spider right now [15:02:03] during the night my CSM+LM got spun up quite a bit by aerodynamics [15:04:52] LM has hardcoded drag coefficient of 2 right now [15:05:00] I wonder if that is too little [15:05:14] maybe the supervessel gets spun up by a difference in drag [15:05:40] CSM and LM have about the same mass right now, but CSM up to 3x the drag, depending on attitude [15:14:02] yeah, LM probably needs a bit more drag [15:25:11] hey [15:28:34] hey Alex [15:45:58] hey [16:31:43] morning! [16:49:30] making good progress on the Sunrise B22 disassembly! almost all of bank 26 is done except for a few weird bits and bank 27 is going very smoothly [16:49:43] I'm close to 100% confident now this is a completely good dump [16:54:13] hey Mike. Ah that's great news! [16:57:08] what are the weird bits? [17:06:42] first weird bit is that the leadin for ALGNTST/SXTNBIMU is very different [17:07:21] it puts up a V24 instead of a V21 like Solarium, and does some extra processing on the second register [17:07:34] Sundial and Aurora both do that as well but their extra processing is different [17:07:43] then there's a thing at the very end of the bank that I haven't identified at all [17:07:59] I'm hoping bank 27 will have some more clues as to what it is [17:08:31] indy91, question on PMMCEN [17:09:41] do you know what is the proper end condition for opt 3 [17:09:43] ? [17:10:04] entry interface [17:10:19] OrbMech::R_Earth + 400000.0*0.3048 [17:10:25] ah ok [17:10:40]