[11:21:21] NASSP Logging has been started by indy91 [12:41:54] goo dmorning @indy91 [12:42:22] just trying to do a p52 in the lem but i have no clue what to do [12:43:14] yeah, it's quite different than in the CSM [12:44:22] first, you actually have to maneuver the LM to point the AOT at a star [12:44:41] the AOT has a bunch of detents, but is not movable like the CSM sextant [12:46:46] then, you never have to 100% center the star in the AOT [12:47:00] instead you want to put the star on the X or Y axis [12:47:12] those axis are visible in the AOT [12:47:30] and you mark with Q on the x-axis and Y on the y-axis [12:47:36] also, you are doing 5 marks [12:47:38] not just one [12:58:47] okay [12:58:59] i was confused as to where to point the star [13:09:10] for on orbit sightings you always want to use the front detent, labeled "F" [13:09:21] so make sure that detent is selected on the AOT [13:17:23] can i place the star anywhereon the axix line [13:17:30] axis* [13:18:43] yes [13:18:56] but I still like to have the star approx. centered [13:19:10] i will try that [13:19:38] the reason for this procedure is that the LM is difficult to get to 0 attitude rate, especially the ascent stage [13:19:51] so the star will always have a bit of movement in the AOT [13:20:15] and you just mark when it's crossing one of the axis [13:20:30] and you need to do x and y axis marks back and forth [13:20:54] P52 always stores the last 5 marks [13:21:13] so if you do e.g. 7 marks then P52 probably won't complain, but it will only use the last 5 marks [13:21:29] and the last thing to know, you will not get the same precision as with the CSM sextant [13:22:18] I'm not sure what the guideline is though [13:22:31] +00005 is probably still acceptable [13:22:39] for the star angle difference [13:23:03] you can get about the same precision as in the CSM, but it's much more difficult to do [13:32:36] hey [13:32:39] hey [13:32:43] https://github.com/dseagrav/NASSP/issues/338 [13:35:18] hmm thats odd [13:37:08] maybe there are some panel areas overlapping now? [13:40:40] maybe [13:53:32] almost done with this DKI update [13:53:43] I've added a new page just for options [13:54:05] the time differences between maneuvers aren't customizable yet, but a bunch of other settings are [13:55:54] nice [14:00:20] and I implemented a nice little trick for the PDI+12 [14:01:02] if you type "PDI+12" instead of a time as the DKI TIG then it will take the PDI TIG from the PDI PAD and add 12 minutes and use it as the DKI TIG [14:01:27] that assumes you have a valid PDI PAD of course [14:03:19] sounds neat [14:06:23] i got a dx9 error too [14:06:28] but in the lem [14:12:37] you broke it all Alex :D [14:18:10] haha well I did not change the LM MFDs ecept for that added check which made it like the CSM codewise [14:19:02] and that might be the same error I was getting for a long time before too [14:19:29] well [14:19:46] i was using 0.1 time acceleration then the error came up but it didn't ctd [14:19:57] something about direct x client failing [14:20:13] it only happen once and my dsky got prog alarms [14:21:10] i dont think it was the panels [14:26:11] indy91, I think I know the issue with the LEB MFDs [14:27:05] sounds good [14:27:40] easy fix? [14:27:53] just pushed my DKI changes [14:27:56] I think the user who had the issue may have been using split panels because my update does not display properly with the panels split [14:28:05] yes, I think [14:28:13] the rescue 2 sequence described in the Apollo 13 document can also be done by it [14:28:27] oh, I see [14:28:56] its just that with the continuous panels the offsets work, but with the split panels, the left most MFD boarder goes off the end of the middle panel [14:29:30] so just a question of sliding all 4 a bit to the left [14:29:34] ok [14:29:37] to the right* [14:29:42] easy [14:30:12] I am not 100% certain that is the cause of his error but it looks likely [14:32:56] already 2300 commits since 7.0 :D [14:33:00] hmm [14:33:10] -9.3NM HP sounds a bit unhealthy [14:35:38] yeah, this doesn't work yet for the rescue 2 sequence [14:36:13] because with that sequence the rescue burn is the height maneuver and CSI is the phasing maneuver [14:36:22] usually it's the other way around [14:36:59] so for now keep N=1 on the DKI option page. That's the same N as in P32, so half revs between CSI and CDH [14:42:13] so N is the number of REVs between CSI and CDH? [14:42:38] yes [14:42:40] no [14:42:42] half revs [14:42:52] usually you use +00001 there in P32 [14:42:55] so half a revolution [14:43:48] ah ok [14:43:59] so 2 would be 1 REV [14:44:15] yes [14:44:42] but in 2 half revolutions you will be at the same altitude as right now [14:45:03] so in that case the height and phase maneuvers are exchanged [14:45:27] with the 2 profiles the DKI can currently handle the first maneuver is always a phase maneuver [14:45:35] and the second maneuver (CSI) is a height maneuver [14:45:57] but if N is even, that logic is the other way around [14:46:55] whats the difference between Maneuver Line and Specified DTs? [14:47:38] Maneuver line has maneuvers 180° apart [14:47:52] so all maneuvers are on a line [14:47:57] assuming Kepler orbits [14:48:14] specified DTs currently has hardcoded DTs between maneuvers [14:48:21] but that will be customizable soon [14:48:51] I think I'll add "Rescue 2" as a third profile to choose from [14:49:16] looking at the table in the Apollo 13 document that would be about right [14:49:32] CSI/CDH sequence, HAM-CSI/CDH sequence and rescue 2 sequence [14:49:47] and some really special cases [14:49:54] for manual ascent and anytime LM lift off [14:50:10] but I'll deal with those later [14:50:29] did you see the one where you insertion happens 1 NM below the CSM? [14:50:46] sounds interesting [14:50:46] haha, no [14:50:59] the last one in the list? [14:51:03] time critical [14:51:10] yeah time critical [14:51:42] that probably requires a precise liftoff time more than anything else [14:51:57] CSM does a burn before it too [14:52:11] yeah [14:54:42] No PDI+12 solution +96.9 0 -49 [14:54:46] looks good [14:54:56] I guess HAM would be near 0 [14:55:23] Good morning [15:00:22] hey [15:03:06] So I tried pressurization yesterday, it doesnt add up the pressures properly with a liquid and gas [15:03:20] But individually the tanks look good [15:04:58] But when mixed, even though it clearly shows the liquid and gas states existing in the tank, the pressure barely increases [15:06:22] right [15:19:49] I think the tank pressure calculation sums the partial pressures [15:20:01] Which would make sense if everything is the same state of matter [15:20:31] yeah [15:20:39] so that is basically the issue we expected [15:20:45] interaction of liquid and gas [15:21:08] Yeah [15:21:43] Basically, in the simplest form, if we add the pressure of helium in the tank to the pressure of the liquid it could work [15:21:55] Instead of a partial pressure computation and addition [15:27:33] I have a fix almost ready for the MFDs [15:35:34] PR sent [15:36:36] merged [15:39:31] there are some rescue cases where you have to use N=10 in P32, haha [15:40:01] if the LM wanted to do a PDI2 + 12 but the engines failed for example [15:40:29] then the CSM needs to do a rescue and a CSI burn and then coast for 5 revolutions [15:42:22] oh wow lol [15:43:23] so, I guess I need to implement each techniques described in chapter 3 [15:43:27] chapter 5* [15:43:37] 5.1 and 5.2 are implemented [15:43:49] 5.3 (rescue 2 sequence) is almost done [15:44:06] 5.4 and 5.5 also mention the DKI [15:47:43] i would like to clarify am i supposed to simply line up the star anywhere on the line? [15:49:01] yes [15:49:21] if it's on the x-axis, mark x (so press Q). if the star is on the y-axis, mark y (press y) [15:49:39] and the top to bottom line is y axis right? [15:50:55] yes [15:58:31] AlexB_88, so I guess the general techniques for the time critical insertion is to place the perilune of the CSM orbit at the approximate insertion longitude of the LM [15:59:36] P12 target would probably be 0 radial velocity and horizontal velocity targeted for 60NM [15:59:42] and the rest is done manually [15:59:55] P12 TIG is of course extremely critical [16:02:04] yeah [16:02:19] hard to imagine they can actually pull that off from the sound of it [16:03:52] it's not that much more difficult than the short rendezvous profile really [16:04:02] from a targeting standpoint [16:04:25] they had a really accurate insertion prediction, the tweak burn was not always needed [16:05:05] so it probably would take a lot of RCS to achieve the rendezvous, but it might be possible [16:07:15] I recently found the list of maneuvers that the General Purpose Maneuver could calculate for Apollo 10 [16:07:38] I guess the CSM maneuver would be type 6 (HOL) [16:07:47] "Height maneuver at a specified longitude" [16:09:38] General Purpose Maneuver Processor* [16:14:00] We dont have any other cases of vapor added to liquid do we? [16:16:21] If not, I think I might have a solution if I can figure out how to code it [16:18:01] That way it doesnt break anything currently simulated [16:24:47] For this case, if we keep it from adding partial pressures, and add the pressure of the fuel in the tank to the pressure of helium in the tank, the fuel tank will pressurize to the correct values in the checklist [16:25:15] Because as soon as the gas is introduced, the code computes the fuel partial pressure as zero since it is not a gas [16:25:29] And leaves the tank pressure = parial pressure of helium alone [16:25:32] partial* [16:26:43] So if it can use the tank pressure plus the helium pressure added and add those, we get about 250PSI [16:29:52] I just dont fully understand how it sums up the partial pressures in the code [16:39:54] yeah, I've never really looked at the code for this [16:45:11] I just dont have a good hold on the variable usage [16:45:56] Fundamentally if multiple substances are present, the pressure equals partial pressures of all substances within, which is perfect for a gas mixture [16:46:25] But for a liquid and gas, the tank pressure needs to be equal to the pressure of the liquid and the pressure of the gas, not the partial pressures [16:46:45] Otherwise it returns just the gas partial pressure in the tank [16:57:19] I guess the current code just doesn't really handle these two phases [16:59:59] Yeah I think we can make a special condition that can handle it though I need to cogitate more on how to best approach it though [17:01:06] I'd rather like a longtime solution than a special condition, if possible [17:01:31] As would I [17:02:04] Only gases work in mixing/calculating pressures right now [17:02:14] I need to figure out how it computes liquid pressure [17:02:36] And then I can use the bulk modulus to allow a gas to compress it further [17:02:51] Or to pressurize the tank around the liquid [17:03:21] But first I need a better understanding on how the current implementation works with liquids, I understand the gas portion [17:04:59] I mean I can also look at it, but I don't really have an advantage there. [17:05:06] chemistry isn't exactly my specialty [17:05:19] or thermodynamics [17:06:03] I get that area, I just need to figure out what variables are used for what [17:06:27] right [17:11:55] AlexB_88, more DKI updates pushed [17:12:15] the rescue 2 sequence and you can now specify time differences between maneuvers [17:12:28] pretty good planning tool now [17:12:39] I have a feeling if I can get the pressure to calculate properly we can actually do this the right way and pressurize tanks [17:12:49] The numbers add up [17:12:50] that would be fun [17:13:02] we could potentially use it for all propellants [17:13:08] Yep [17:13:13] And water tanks [17:13:30] indy91, awesome! [17:13:38] and it shouldn't be too difficult to remove the right amount of propellant that has been burned [17:14:05] for the No PDI+12 you can calculate PDI PAD, then type the PDI+12 to get the TIG as I explained [17:14:18] and then I changed the DT between abort and Boost to 55 minutes on the options page [17:14:31] and then the times work out with the schedule in the procedures [17:14:47] same can be done with PDI0 [17:16:23] for the rescue 2 sequence though they would not have used the fixed 1 hour DTs between maneuvers though [17:16:46] so that always uses the maneuver line option, maneuvers every 180° of travel [17:17:20] so would 00008 for the lem p52 be too high? [17:18:04] i think you said 00005 is the max [17:18:34] yeah, but I'm not sure what they really used as max [17:18:43] 00008 isn't so bad [17:19:23] rcflyinghokie, any idea for the actual number? [17:19:25] and for the p40 for doi the angles matched up with the pad angles does that mean the alignment is good [17:20:18] no, that just means your state vector is good, haha [17:20:25] okay [17:20:30] I am not sure actually [17:20:32] Let me check [17:21:28] the LGC will calculate the angles based on the DV vector and state vector at ignition [17:21:47] the alignment is more a question of if the LM actually has the angles that the LGC thinks it has [17:23:08] Hmm the G&N manual and the AOH dont state the limits [17:23:19] I'm pretty sure I've seen limits somewhere [17:23:23] looking for it [17:23:50] would the p52 limit be in the mission rules? [17:24:07] Could be [17:24:14] i am checking that now [17:31:15] morning! [17:31:49] hi mike [17:34:28] well my internet is very slow but the number on the real mission was 00003 [17:38:21] yes [17:39:07] as in the lem timeline [17:41:18] Apollo 14 had 0.04° [17:41:48] so I guess the 0.05° guideline still seems good to me [17:42:14] yeah i will try to get it as loww as possible [17:42:23] low* [17:48:36] AlexB_88, one other small feature I added for the DKI TIG is "PeT". If you input that then the next periapsis time will be used as the TIG [17:48:41] might be useful for PDI0 [17:51:03] ah nice [17:57:00] now I probably should check if all the things I implemented actually cover all the Apollo 13-17 procedures [17:57:21] Apollo 17 does the CSI/CDH sequence with the 50 ft/s radial [17:57:29] that is supported [17:59:00] UHCL has the additional abort and rescue plan documents for Apollo 14-17 as well, if we really want them [17:59:05] don't need them right now [17:59:39] the PeT feature seems to work with all pages [18:00:00] uhh, some of them, yes [18:00:17] like the orbit adjust pages [18:00:22] yep [18:00:30] quite handy [18:00:38] indeed [18:00:44] Skylab rendezvous page as well [18:00:50] and DKI page [18:01:44] although for the orbit adjust page that will be changed, because it should be a separate option to have a maneuver at periapsis or apoapsis [18:02:07] 53 different options as of Apollo 10, haha [18:02:15] that would take a while to implement all... [18:04:38] 53 options for what, rendez-vous maneuvers? [18:05:03] no, in the general purpose maneuver processor [18:05:14] that is 53 options to change the shape of the orbit [18:05:23] examples [18:05:30] plane change at equatorial crossing [18:05:34] height maneuver at apogee [18:05:52] maneuver to shift line-of-apsides to a specified longitude [18:05:54] and so on [18:06:09] so maneuvers for one vehicle, changing the orbit in any way you can imagine [18:09:36] and that would be in the RTACF, developed from Gemini [18:11:51] so basically what our orbit adjustment page is doing [18:11:55] yes [18:11:58] plus many more options [18:12:03] right [18:12:04] but a lot of them are easy to implement [18:12:12] I can work on that some time [18:12:15] and back to rendezvous, Apollo 16 PDI1+12 uses the CSI/CDH profile with the 50 ft/s radial [18:12:30] but the No PDI2+12 uses Boost and HAM [18:12:44] so that can all be done with the DKI page now [18:13:12] not sure about Apollo 15 [18:14:00] For Apollo 14 both use Boost and HAM [18:14:04] and the 50 ft/s [18:14:27] and PDI0 with CSI 1 hour after the abort maneuver [18:14:34] what weird about 16 is there is the LM data book has no times (>__ PDI 1 >__) [18:14:52] data card booK? [18:15:19] as in they are blank spaces which seemed to have been entered during the mission [18:15:31] yeah on the PDI-1 PAD of Apollo 16 [18:15:56] insted of say >1 PD1 >15, there are no numbers, just blank spaces [18:16:03] oh [18:16:08] look at the very first page [18:16:15] "incorporates Apollo 17 procedures" [18:16:34] so, I don't think this really even is a Apollo 16 LM Data Card Book [18:16:50] it's the earliest version for the Apollo 17 one [18:17:00] based on Apollo 16 [18:17:11] so maybe we should try to find an earlier version [18:17:46] aha! [18:17:58] https://www.ebay.de/itm/Apollo-16-Lunar-Module-Data-Card-Book-Owned-by-Flight-Director-Donald-Puddy/302499831570?hash=item466e651f12:g:zT4AAOSwl9RZ72Oy [18:18:34] that one has times there [18:21:04] nice [18:21:20] He took just the right pictures for us :) [18:26:05] UHCL has a bunch of data card books for 15, 16, and 17 [18:26:21] and one for 12 [18:26:51] oh hey Mike, didn't see you there :D [18:27:19] hi! [18:27:25] he have 12, and it seems pretty complete [18:27:31] missing pages 1 and 2 or so [18:28:12] This is going to be a far fetched question, but is anyone around now a days that helped wrote the thermo/substance code? [18:28:15] we have Apollo 15, missing page 1 or so [18:28:19] helped write* [18:28:52] we have all 3 diferent revisions for Apollo 17 [18:29:09] so yeah, just this weird "Apollo 16, but actually AFTER Apollo 16" version [18:29:23] haha [18:29:33] rcflyinghokie, I wouldn't even know who wrote it [18:29:41] dseagrav would know [18:29:42] I thought so [18:30:13] That could potentially be a big help [18:30:34] I just am having a hard time seeing exactly what it is doing especially with the quadratics in play [18:31:28] And how it differentiates calculating tank pressure with only a liquid versus using the partial pressures [18:32:17] I think once I understand that, I can come up with a solution, I just might need help coding it should I figure one out [18:33:59] Gotta run though [18:44:03] SIGNIFICANT CHANGES TO LM ( LUNAR MODULE ) ABORT AND rescue plan FROM MISSION G TO MISSION H-1 [18:44:24] this would probably be the next document for rendezvous abort stuff [18:48:51] haha, sounds about right [18:57:16] AlexB_88, I am thinking about changing the Lambert page to be more like what the actual Two-Impulse Processor was able to do [18:57:53] have you ever used that page for anything else than TPI or NCC like maneuvers? [18:58:08] actually I have [18:58:20] Like No PDI+12 on Apollo 11/12 [18:58:51] I targeted the approximate position of CDH to achieve a solution if I recall [18:58:56] ah yeah, but that is basically the same style of maneuver as NCC-1 on Apollo 7 [18:59:17] I'm thinking about making it only work for this kind of maneuver [18:59:22] and I think CSI is close to 0 [18:59:36] so no out-of-plane position etc. [18:59:43] and you would switch between two modes [18:59:46] oh and I have used it for the tweak burn on the direct ascents [18:59:51] ah right [19:00:16] I wonder if UHCL has any document with details about the tweak [19:01:43] does the direct ascent lunar liftoff page actually target a TPI at orbital midnight? [19:02:19] because the concentric mode seems to, but direct ascent mode seems to give a TPI 20 minutes later or so [19:03:09] direct ascent mode doesn't [19:03:55] I think it uses a standard profile [19:04:00] and TPI just ends up being somewhere [19:08:14] I think what I used to target the tweak burn was lambert page with TPI location of -29 0 15 [19:09:09] based on what the SCOT described as for relative position of the LM from the CSM for the TPI burn on direct ascent [19:10:21] so, I think that would still be easily supported by a change to the two-impulse processor [19:10:36] targeting TPI directly instead of a CDH point [19:10:55] right [19:11:21] so if I wanted to rework that page, all I really needed to keep working is NCC/NSR, TPI/TPF and tweak burn [19:11:38] yeah [19:12:12] so it would be like you input TIG, Time of TPI and offsets would be automatic? [19:12:42] all predetermined basically [19:12:50] for the tweak [19:13:13] you would have options for TIG and arrival time [19:13:30] TIG is fixed, unless it's for TPI, then it's at a specific elevation to the target [19:13:46] arrival time is fixed for tweak and TPI [19:13:50] but not for NCC [19:13:57] which is the same as a No PDI on Apollo 12 [19:14:13] and for the offsets you only specify DH and phase angle [19:14:16] not X,Y,Z [19:14:41] phase angle like the 130 degrees [19:15:07] relative to the target, so more like the -1.32° on Apollo 7 for the NCC-1 maneuver [19:15:25] oh [19:15:28] and I checked, that angle is constant for the Apollo 12 No PDI1+12 and No PDI2+12 [19:15:47] but I guess you could specify the 130° for the TPI/TPF option as well [19:16:02] all that does it calculate the time it takes the target to travel 130° [19:16:08] and take that as the DT [19:16:12] that's what the AGC does [19:17:07] the added capability of my changes are that a specific TPI time can be achieved for a Apollo NCC-1 style burn or an Apollo 12 No PDI+12 [19:17:12] would be* [19:17:29] oh, I found something for Ryan to request :D [19:17:36] LM ( LUNAR MODULE ) DESCENT / PHASING SUMMARY DOCUMENT Mission F FINAL [19:51:29] also unrelated, I came up with a dumb name for my home-built AGC [19:51:44] the ARGH Computer (Apollo Replica Guidance Hardware) [19:51:45] :P [19:52:47] ARGHHHH [19:53:16] Mike when another memory core doesn't want to switch its state [19:53:32] so yes, good name :P [19:53:45] hehehe [20:33:18] night! [13:58:27] het AlexB_88 [13:59:14] dor my doi i left the number of revolutions blank is that not good? [14:01:12] hey [14:01:22] which mission? [14:05:55] 11 [14:06:08] yeah 0 is good then [14:06:30] my attitude was P108 Y105 [14:06:53] only in later missions DOI is done many orbits before PDI, but Apollo 11, its DOI, then 0.5 orbits later PDI [14:07:44] yaw should be 180 [14:07:50] i thought it meant which revolution the doi was performed on which was 13 [14:07:59] no [14:08:21] good thing i didn't set it to anything [14:08:21] it means how many revolution between DOI and PDI [14:08:53] i have to do it again as i set the throttle to 40% way too late [14:09:09] your yaw for DOI should be either 180 or 0, not 105 like you wrote [14:10:28] as for my refsmmat it should just be refsmmat and not desired right? [14:10:45] sorry I mean yaw should be 0 [14:11:53] thats already done during activation, you only have to realign with option 3 [14:12:09] well my loi was 5 minutes late so i set the doi time to the time in the flight plan [14:12:26] yes [14:12:32] and the ignition time it calculates was around 101:44 [14:13:39] sounds right [14:13:46] whats your DOI attitude again? [14:13:57] P180 Y105 [14:15:44] where are you looking to get those numbers? [14:15:55] in the maneuver pad [14:16:10] oh R180 P105 [14:16:19] oh [14:16:35] there is no yaw angle one the maneuver PADs [14:16:42] its always Y000 [14:16:47] yeah theres only two numbers i forgot [14:17:22] but looks like you are in good shape for DOI [14:17:57] for yaw i got 088 in the p40 [14:21:13] and the attitude is fairly close to that ball in the fdai [14:23:21] If your yaw is 088 then you need to manually yaw back to 0 [14:23:32] okay [14:23:43] and then P40 will update the burn with yaw 0 [14:24:36] just yaw back to 0 then press PRO on the 50 18 display [14:50:27] hey [14:50:36] hey [14:52:16] I was looking at the blank Apollo 16 data card book and noticed that we can probably fill out the variable targeting switchover times from the Apollo 16 timeline book which we do have [14:53:02] well obviously we found the picture from ebay [14:53:12] or whatever auction that was [14:53:29] yes [14:54:11] I won't have much time today to do stuff, but I started adding a 3rd option for the lunar launchtime prediction, for the time critical direct profile [14:54:45] anyways I am starting to wrap my head around these later mission abort/rendezvous procedures [14:54:46] nice [14:55:53] all the aborts before PDI should now be possible to calculate with the RTCC MFD [14:56:27] great [14:56:29] any abort during descent is another story [14:56:40] depends on the variable targeting [14:56:43] yeah [14:56:52] procedure wise it shouldn't be too difficult [14:57:14] I just tested an Apollo 17 PDI abort at 10:15 [14:58:19] did it spit you out with the right apolune altitude? [14:58:22] insertion was quite close to what the timeline book suggests at the PDI+10 minutes abort [14:58:30] ok [14:58:30] with 5 nm [14:58:37] within [14:58:43] so then it's just Boost/HAM/CSI [14:58:47] yes [14:58:53] 50/60/50 [14:59:06] TPI time would be the later time [14:59:26] I even used the DKI after insertion to verify it [14:59:32] ah, great [15:00:02] and I guess the TPI time from it can then be used [15:00:13] yeah [15:01:24] what was the DV from the DKI? [15:01:30] 0.7 [15:01:32] wow [15:01:42] yeah [15:01:46] pretty good [15:02:08] I guess that Apollo 17 had the padloads from that simulation though [15:02:10] and for the actual procedure I wouldn't expect much more than that for the HAM maneuver [15:02:20] right [15:02:31] yes, Apollo 17 variable insertion targeting should be pretty good [15:02:35] for PDI1 at least [15:04:44] I am comparing the PDI summaries of Apollo 16 and 17 and the variable targeting table looks quite similar [15:05:01] I wonder if the 17 padloads work on 16 [15:05:12] probably less accurate but might still work [15:05:26] there are two differences between those missions [15:05:29] the planned DOI-2 [15:05:37] and the perilune location [15:05:52] for Apollo 17 not at the PDI point, but much further downrange [15:06:21] but that all wouldn't matter too much for the variable insertion [15:06:34] rendezvous profiles should be quite similar [15:06:49] right [15:16:58] I dont know if the missions before that would work with the 17 padloads though [15:17:35] Apollo 14 and 15 seem to be structured more like 13 for the variable targeting by comparing the data books/timelines [15:18:32] the insertion apolune is a function of phase angle [15:18:57] so if everything after insertion is basically identical, the the padload should work with 14 and 15 as well [15:19:09] ah [15:19:25] I guess it's mostly the phase angle at PDI that is different [15:19:32] so the switchover time is much different etc. [15:19:45] yeah [15:20:10] but the switchover times are calculated dynamically based on the phase angle I guess? [15:20:22] by the PGNS I mean [15:21:30] yeah [15:21:49] it's just 5 padloaded numbers for the Apollo 12-17 Luminarys [15:22:36] at abort initiation it checks the phase angle [15:22:52] and if the angle is greater than THETCRIT, it uses one pair of parameters [15:22:59] and otherwise the other set [15:23:26] and does AGS have a similar padload? [15:24:33] I can't remember the specifics, but yes, it's similar [15:26:34] also a function that results in the desired semi-major axis [15:26:46] it's quite simple in the LGC really [15:26:52] a = J+K*theta [15:27:12] J and K are one set of padloaded parameters [15:27:17] theta is the phase angle [15:27:22] a is the targeted semi-major axis [15:27:55] Luminary099 has an overly complicated polynomial for the insertion horizontal velocity [15:30:15] @AlexB_88 i will try that [15:37:25] It would be great if we could prioritize and fix the oxygen flow in v8. I think many have left v7 for v8 but are still on the Apollo 7/8 stage. Is there a lot of work to fix the problem? [17:26:21] one thing I notice on Apollo as consistent is that on Apollo 13-15, the time from CSM circ burn to PDI is about 2h55 [17:26:45] and on Apollo 16-17 that same time is about 54 minutes [17:33:28] one revolution longer between undocknig and PDI on 13-15 [17:33:33] indy91, for that reason I am thinking should we not make 14 and 15 have the same padloads as Apollo 13? I see that THETCRIT on 13 is way different -17.183277. On Apollo 17 it is 6.432346 [17:33:33] [17:35:06] yes, that might be right for the padload [17:36:05] just the 5 variable abort padloads you spoke of that is [17:36:41] Are they the same address between Luminary131 and 210? [17:37:18] I don't think so [17:37:39] Luminary210 reorganized a lot of the erasable memory [17:41:32] tried to do pdi then it got stuck with solid verb 63 [17:42:06] Verb 63? [17:42:24] do you mean you did a V37E 63E? [17:42:27] not the first one [17:42:45] i will pull up the checklist and tell you [17:43:19] it might have been PROG 63 [17:44:13] V63 would have been a radar test [17:44:22] P63 is the powered descent program [17:46:26] and i am pretty sure i got a program alarm on the radar test [17:46:44] i think there was a procedure that alex gave me for the dsky [17:47:31] isn't that part of the Checklist MFD now anyway? [17:47:44] i don't know [17:48:19] i will try it gain and see how it goes [17:49:29] hmm [17:49:29] it happen around pdi -4 when it says enter to go to noun 62 the prog 63 was solid [17:49:47] says there is a hidden delay for 60 seconds i think [17:50:05] doesn't look like Ryan updated the Apollo 11 checklist yet with the procedures from the LM timeline book [17:50:27] would that explain the prog alarm [17:50:28] ok, the DSKY froze on the ENTR when going to N62 [17:50:37] what program alarm was it [17:50:43] 5 something [17:50:46] i thinl [17:50:49] think* [17:51:27] 5XX would be something radar related, yes [17:52:11] did you have the 50 18 up when you pressed ENTR? [17:52:16] in P63 [17:52:23] i cant remember [17:52:37] but i will go at this again and tell you [17:52:56] ok [17:53:07] but you managed to start P63 without a program alarm? [18:01:31] yes [18:01:42] and also i am needing alot of verb 96's [18:03:57] then something is wrong [18:04:01] probably a state vector [18:04:51] but if you managed to enter P63 without an alarm, then it's probably the CSM state vector in the LGC that is bad [18:07:20] so J1PARM, K1PARM, J2PARM, K2PARM, THETCRIT are the abort constants if I read this right [18:09:21] maybe RAMIN too [18:11:27] yes, RAMIN as well, but that doesn't really need a change [18:13:46] that's just a limit on the apolune [18:13:59] On Luminary131 those are from 2550-2563 And on Luminary210 2545-2560 [18:14:59] so looks quite easy to take the 131 numbers and put them in the 14 and 15 padloads at the correct addresses [18:15:31] I can do that and update the padload work sheets if you want [18:16:20] just trying to find myself excuses to fly Apollo 15 :D [18:17:04] fly Apollo 15 and just abort all the time [18:17:11] sure, update it [18:25:02] morning [18:26:47] hey Mike [18:27:36] what's up? [18:28:47] not much [18:30:36] working a bit on time critical lunar liftoff time calculation [18:30:51] one of the procedures from the Apollo 13 document Alex got from UHCL [18:32:40] direction insertion to an orbit that ends at the CSM after just half an orbit [18:32:43] direct* [18:32:58] oh fun [18:35:57] not for the astronauts tha thave to pull it off [18:36:13] the procedure is meant for a ascent stage water tank leak [18:36:30] so you wouldn't have any cooling after quite a short time after liftoff [18:39:56] oof [18:40:57] should be fun to try in NASSP though [18:48:06] PR sent [18:48:22] I will test this of course soon [18:50:56] looks good [19:00:55] hey Ryan [19:02:45] so what should i do about that csm state vector? [19:03:02] do i have to go back to the docked lm csm scenario [19:03:08] no [19:03:16] just do a V66 [19:03:33] in the lem? [19:03:33] that copies the LM state vector to the CSM state vector [19:03:36] yes [19:03:41] okay [19:03:49] and should at least prevent any issues like the DSKY locking up [19:04:12] after that you can update the CSM state vector in the LGC with the RTCC MFD if you want [19:04:12] indy91, do you have a spare PDI scenario for Apollo 15? [19:04:19] an old one [19:05:15] wait, how did V66 work? [19:05:55] maybe I can revive it haha [19:05:58] it copies the state vector of "this" vessel into the state vector slot of the "other" vessel [19:06:09] right but how does it work, wiring-wise? [19:06:40] LM->CSM in the LGC, CSM -> LM in the CMC [19:07:29] the crosslink hardware wasn't used, right? so it must have gone out a downlist and into the other as an uplink command or something? [19:07:49] both CSM and LM state vectors are just a bunch of erasable memory data in the AGC [19:08:01] right [19:08:25] I'm sure the AGC has a simple way of copying one memory location into another [19:08:37] ohhhhhhhh I understand now [19:08:45] it's not going from the CMC to the LGC and vice-versa [19:08:48] no [19:09:12] herp derp [19:09:14] I need more sleep [19:09:15] they did something like you described just after insertion though [19:09:27] downlinked the LM state vector in the LGC and uplinked it to the CMC [19:09:32] but indirectly of course [19:09:39] LM->Earth->CSM [19:09:54] right [19:09:55] https://www.dropbox.com/s/r3n6jytgenflj26/Apollo%2015%20-%20Before%20P63.scn?dl=0 [19:09:57] AlexB_88 [19:10:07] thanks! [19:10:32] Ill plug in the Apollo 13 abort constants and test it [19:12:12] I'm testing the time critical ascent in an even older Apollo 11 scenario [19:17:21] sounds fun [19:19:04] just looking if the insertion parameters are about right [19:19:14] haven't actually put the CSM in the 11x60 orbit [19:35:53] doing the ascent now, CSM is basically above me [19:36:09] I'll calculate a tweak burn directly to the CSM [19:37:30] nice [19:40:37] my 1st test with your scenario was an early PDI abort with the DPS at PDI+3 minutes [19:41:29] looking at the Apollo 14 timeline book PDI summary, gave me an insertion apolune within 1 nm [19:42:27] very nice [19:42:49] I tabbed out and I had the engine start button pressed in [19:42:57] so the ascent stage burned to depletion :D [19:43:23] but the phase angle was about right for a 180° transfer [19:44:26] so the HAM/BOOST procedure is used in the Apollo 15 early LM aborts and the DKI showed me a phasing of 0.4 fps [19:44:42] hmm, APS or RCS for that :D [19:45:11] nope I need rescue from CSM ;) [19:45:15] clearly [19:46:03] I mean obviously the DKI is not what Id use to fix my insertion, but its good as a tool to judge the accuracy I guess [19:46:20] yes, it should be [19:46:31] the insertion IS the phasing maneuver [19:46:37] right [19:47:04] gives a lot of confidence in this variable targeting [19:47:15] yeah [19:48:25] what kind of rescue sequence is this? [19:49:08] HAM-CSI/CDH I think [19:49:13] just with the CSM [19:49:36] which also should be possible with the DKI right now [19:49:56] just -15NM instead of 15NM [19:50:18] and 208.3° elevation angle [19:50:19] oh rendezvous from above? [19:50:22] instead of 26.6° [19:50:31] yes, should be possible to do [19:50:36] with the CSM [19:50:38] yes [19:50:47] you could even use P31 for the HAM [19:50:54] right [19:53:01] Apollo 13 has a non-zero HAM for this [19:53:18] HAM 2 hours after insertion [19:53:24] ah of course [19:53:29] boost is missing if the CSM rescues [19:53:45] it has -13.7 ft/s for the HAM [19:53:49] I guess should get about the same [19:53:57] CSI 1 hour after HAM [19:55:43] I've never flown a MINKEY rendezvous [19:55:59] I'll probably do that with a profile like the one you currently have [19:56:27] UHCL has "OPERATIONAL LUNAR MODULE abort AND rescue PLAN FOR APOLLO 15 ( MISSION - J1 )" [19:56:30] just saying :D [19:57:13] but I guess we know 90% of it already [19:57:19] because it's so similar to 13 [20:13:04] I can definitely request more docs, I may as well request a few of them [20:14:52] I don't really need them right now for RTCC or MCC. But I am not stopping you from requesting anything of course, haha [20:15:06] and eventually we will need them [20:16:34] night! [21:36:09] hey @AlexB_88 i dont know if you remember this but there was a procedure for the dsky right before pdi do you remember what the numbers were? [22:06:37] ? [22:10:32] @AlexB_88 or is it already in the checklist mfd? [22:32:51] yes [22:32:55] okay [22:33:04] its V25 N07E [22:33:14] then 110E [22:33:19] 40E [22:33:27] and then 0E [22:34:30] just checked the checklist file and its already in there [22:38:27] Ryan just added quite recently [22:38:33] added it* [12:25:37] hey [12:25:42] so i crashed into the moon [12:26:03] when it asked to to take manual control i didn't [12:26:58] @indy91 i have a feeling this is gonna be difficult [12:28:28] crashing into the Moon is no fun [12:28:47] I guess this happened during the powered descent [12:29:52] right at the end [12:30:29] and i was getting alt and vel lights [12:31:09] the landing radar stops working a few meters above the ground [12:32:09] and that will turn on those lights again [12:32:29] did the computer make it to P64? [12:32:55] also, did you ever allow the landing radar to update your state vector [12:34:39] yes it was in p64 [12:34:46] i have no idea about the state vector [12:36:02] the lem pretty much went upside down [12:36:24] right at the last minute [12:37:30] interesting [12:37:44] were you giving it any LPD changes? [12:37:47] the mode control was in auto still [12:37:53] i have no idea what that is [12:38:33] so in P64, before you take over manual control, you can look out of the window and change the landing site visually by giving inputs with the ACA [12:38:49] that is called the landing point designation (LPD) [12:39:06] i did not do that at all [12:39:27] if you do that too much you can confuse the computer and the LM might end up upside down [12:39:32] that's why I am asking [12:40:10] did you look at V16 N68 at all? [12:40:32] yeah [12:40:43] cant remember what is said [12:41:06] one of the things it shows there is LR altitude vs. LGC altitude [12:41:20] when the LR updates the computer, then that delta height will go down [12:41:44] i rememer a verb 57 with the delta height [12:41:53] remember* [12:42:09] ah, right [12:42:53] maybe on your next attempt you can look at the 16 68 every so often [12:43:25] if the LR is properly updating the LGC and all other things like alignment etc. are right, then it really shouldn't crash you [12:44:13] is it difficult to land the lem manually in your opinion [12:45:00] completely manually, yes [12:45:04] that would be with P67 [12:45:10] manual attitude control and manual throttle [12:45:24] with the computer assisted mode, P66, the computer is still controlling the throttle [12:45:27] i dont remember a v67 [12:45:31] P67 [12:45:32] ah [12:45:33] not verb [12:46:02] so i would assume i am controlling the rate of descent in this case? [12:46:36] in P67, yes. I think you need to have the throttle control mode in manual for that [12:46:52] in P66 you are controlling the descent rate with the ROD switch [12:47:22] am i controlling the attitude still [12:48:11] yes, for that you need to have the PGNS mode control switch in att hold [12:48:23] so it's doing attitude hold for you, if you don't do any ACA inputs [12:48:28] yeah i remember that [12:49:13] you can take over attitude control any time in P66 [12:49:15] P64* [12:49:24] with att hold? [12:49:28] yes [12:49:30] and it will switch to P66 on the first ROD switch input [12:50:03] we don't have a ROD switch on the panel I think [12:50:12] it's in a very weird location in the real LM cockpit [12:50:25] on a QWERTY keyboard you use equals and minus for it [12:50:38] next to backspace [12:50:40] beside the backspace button [12:50:42] okay [12:51:02] and then you should be looking on your tape meter [12:51:06] and i am guessing plus is for increase and minus for decrease [12:51:08] for the descent rate [12:51:39] well i am going to grab some coffee and try this again [12:51:40] I am always getting confused by which button is doing what, haha [12:51:50] I think + is "up", - is "down" [12:52:59] so the usual order of things in late P64 is [12:53:03] mode control to att hold [12:53:11] and then +/equals [12:53:24] "+ or =" button I mean [12:53:36] then it should switch to P66 [12:53:43] okay [12:53:48] see you in a bit [12:53:51] cya [12:57:55] hey [12:58:56] hey Alex [12:59:03] got outsmarted by Artemis today [12:59:35] I did the same abort case as you did, Apollo 15 PDI+3 minutes abort [13:00:09] and then I changed to the CSM and tested the HAM program, P31 [13:00:42] and not only did it have the right elevation angle (208.3°) and travel angle between TPI and TPF (130°) preloaded [13:00:47] it also had the right HAM TIG [13:00:54] I thought: "How can you know???" [13:01:16] but it looks like P31 uses a default HAM TIG 0.5 revolutions before CSI [13:01:30] you can change that of course, but that is what it defaults to [13:02:43] pretty neat [13:03:14] DV was like 1.5 ft/s [13:03:29] haha was just going to ask [13:03:36] thats quite low [13:04:16] yeah [13:04:40] I think as long as the insertion gets the phasing about right, then any other insertion dispersions are compensated with CSI and CDH [13:04:45] and not so much the HAM [13:06:49] so it's not that the variable insertion targeting gets the orbit THAT much right [13:07:04] it's just that it gets it right as much as it's relevant for the HAM [13:09:15] yeah [13:09:39] stil, it's pretty good [13:09:43] still* [13:10:04] and I tried some later PDI aborts (PDI+8 minutes or so) with no BOOST/HAM of course [13:10:29] P32 1st pass was ok, DH of about 17-18 NM [13:12:07] one thing that needs to be taken into account is that one some of these aborts TPI is not planned for orbital midnight [13:12:12] on* [13:12:27] but instead 16 minutes before sunrise [13:12:32] that is a few minutes later [13:12:47] and is done because the time between CDH and TPI would be too short otherwise [13:13:30] so with a later TPI the DH would get smaller [13:13:36] closer to 15NM again I would bet [13:14:05] if you used the orbital midnight option for TPI of course [13:14:13] ah [13:14:23] I did use orbital midnight [13:14:43] the Apollo 13 document has the details [13:14:51] when the 16 minutes before sunrise is used and when not [13:16:13] PDF page 23 [13:16:27] ground rule "r." [13:17:25] and PDF page 25 [13:17:25] last night I noticed some weird behavior during APS abort insertion with P71 [13:18:05] I flew a PDI+8min abort with Apollo 13 and at insertion my Rinc with the CSM was 0.3 [13:18:18] which is quite high usually its 0.01 [13:18:27] hmm [13:19:01] you sure the LGC had an up-to-date CSM state vector? [13:19:10] although even then [13:19:16] So I tried the whole descent/abort again but without any LR updates before the abort and no N69 update which I had done crossrange -4000 feet [13:19:22] and it was 0.01 [13:19:42] So I am thinking its one of those 2 [13:19:51] ah, so there were LR updated before the abort [13:19:54] updates* [13:20:04] yeah [13:20:09] N69 update only changes the landing site position [13:20:15] right [13:20:16] so it has to be the LR [13:20:41] but I am sure Ive done this abort before, on previous missions and did not have this issue [13:20:51] after having done LR updates too [13:20:53] weird [13:21:19] so, I think the worst LR issues, whatever they may be, happen at fairly high altitude [13:21:32] yeah [13:21:34] just when the LR has locked on basically [13:21:46] then the LR induces an out-of-plane component [13:22:03] so it could be that [13:22:12] because if I fly the landing and incorporate LR very low like just before pitch-over, I land pretty much bang on target [13:22:19] yeah [13:23:35] This is one issue Id like to get to the bottom of lol [13:23:56] I've tried many things to fix it [13:24:01] or to find the cause [13:24:21] I am testing the abort again [13:25:07] Could it be an issue with the LR in DES position [13:26:16] I don't think so [13:26:21] I can check [13:29:24] ok I confirm its the LR updates with my latest test [13:30:37] so the only workaround now is to make LR updates very late in the descent, or else not only do you land off track laterally but if you abort, your insertion will be off [13:45:41] Mike had the theory that is has to do with time lag between LR reading a velocity and the LGC getting it. [13:45:53] I had tested that a little bit, but not fully yet [13:46:57] but would that not also cause a down-range error as well? [13:51:42] kind of, yes, but the radar velocity beams are not directly in the local axis [13:51:54] the error should be even more on the downrange axis though [13:52:08] so I'm not sure there [13:52:11] the thing is, it is not in my tests [13:52:41] downrange error is almost nil at landing in my tests [13:53:24] have we tested if the error comes from the range beam or the velocity beams? [13:53:26] I think we did [13:53:27] if (range > 10.0 && range < 50000.0) [13:53:28] { [13:53:29] velocityGood = 1; [13:53:29] } [13:53:44] hmm [13:53:50] if you would comment out the velocity good line, then it will only update the LGC with the range beam [13:53:59] haha read my mind [13:54:12] and maybe you could test another abort with that [13:54:20] sure [13:54:35] or I can just land and compare P68 with PAMFD [13:55:35] right [13:55:40] but careful with that [13:56:04] the LGC won't have precise knowledge of its velocity [13:56:21] so rather trust the LR readings for the tape meter close to the landing [13:56:27] instead of the LGC ones [13:56:41] for your ROD especially [13:57:09] right [13:57:29] worst case Ill take manual control of the throttle [14:06:55] ok [14:06:59] it is velocity [14:07:08] I landed bang on without it [14:07:42] PAMFD latitude -3.67 [14:07:49] LGC -3.67 [14:07:52] ok [14:08:02] 0.01 error in longitude [14:10:52] and that could easily be an accumulation of a bunch of smaller errors [14:11:47] the 0.01 error you mean? [14:13:08] yes [14:14:10] right [14:14:42] its the same error I was getting before in longitude, but 0.01 error is probably expected [14:15:11] yeah, many potential errors end up in a longitude error [14:15:15] latitude error was about 0.04 to 0.06 error before with the velocity readings [14:15:24] including the simpler gravity model used in Average G [14:16:45] back when we had LGC clock issues the LR velocity readings managed to make auto landings possible. So close to the surface the LR velocity is definitely quite good [14:16:56] yeah [14:24:38] messed up again it didn't flip over but the altitude keep going higher and i couldn' [14:24:45] control the rate of descent [14:34:35] @indy91 just wondering what would happen if i kept it on auto [14:36:15] it will land automatically if you keep PGNS switch to auto [14:36:51] astronauthen96__, did you ever enter P65, P66 or P67 on this attempt? [14:37:06] no [14:37:23] weird [14:37:40] are you using a joystick? [14:37:41] i entered p66 i think [14:37:46] oh, ok [14:38:08] the behavior could also be explained by a manual throttle command [14:38:23] on the thrust meter, were the commanded and actual thrust identical? [14:38:58] i dont think they were [14:39:33] indy91, so I have noticed that the landings with Apollo 15/17 with rough terrain before the landing site, seems to make the error worse at landing. [14:39:45] the latitude error [14:40:13] astronauthen96__, if you are using joystick, it needs to be at the minimum thrust setting [14:40:24] keyboard [14:40:28] ok [14:40:40] did you ever throttle up manually with it? [14:40:47] no [14:40:59] i couldn't control the rate of descent [14:41:30] the manual throttle control is with Ins/Del on the numpad [14:42:05] i thought it was the minus and plus beside the backspace [14:42:14] that is not throttle [14:42:18] okay [14:42:22] that might help [14:42:33] not really [14:42:34] i am guessing insert is for increase [14:42:50] plus/minus on the keyboard (not numpad) is for the ROD switch [14:43:03] that just is an input into the computer, only for P66 [14:43:13] 1 button press changes the descent rate by 1 ft/s [14:43:30] ins/del in the numpad however is the actual manual throttle control [14:43:40] that is always added to the auto throttle commands [14:43:46] from the LGC [14:43:57] during a normal landing the manual throttle command should always be 0 [14:44:01] so if i just keep it on auto do you think it will land [14:44:03] so you really shouldn't use that [14:44:16] unless you use P67, completely manual landing [14:44:31] it should land on its own with Auto, yes [14:44:37] okay [14:44:38] if not, then something else is wrong [14:45:04] at the very end i don't remember when it starts but the altitude starts to increase [14:46:27] in P66? [14:46:56] maybe you pressed the ROD commands too often [14:47:29] it was during p66 but i dont know when it started to increase [14:47:55] without any inputs, P66 would just keep the current descent rate [14:57:09] I found 6 padloads in the LGC that I am curious about [14:57:15] "LR VEL WEIGHTING FUNCTIONS" [14:57:33] sorry 9 padloads [14:57:53] from LRVMAX to LRWVFF [14:58:00] I wonder if those hold any clues [15:02:06] @AlexB_88 for my problem? [15:03:10] astronauthen96__ no, a separate issue [15:03:15] okay [15:03:32] astronauthen96__, your issue will be either user error or something in the LM isn't correctly set up before PDI [15:03:32] i will try it again and keep it on auto the whole time [15:04:06] AlexB_88, LVRVMAX and LRVF are thresholds for the LR weighting function [15:04:19] if velocity is above LRVMAX, then it won't use the LR velocities at all [15:04:55] between LRVF and LRVMAX it trusts the LR velocities more and more as you become slower [15:05:36] I see [15:05:51] below LRVF it trusts the LR quite a bit and really only does a reasonability test on it [15:06:01] and LRWVZ,Y,X are 0.3 [15:06:03] I find that interesting though [15:06:14] 2000 ft/s is used for Apollo 11 [15:06:39] same for Apollo 13 [15:06:42] later it's 2500 ft/s [15:06:49] yeah, noticed that too [15:06:55] if you are above that velocity it shouldn't incorporate velocity readings at all [15:07:52] I guess at 8 minutes you are already below that though [15:08:40] hmm I guess maybe thats why I get slightly more latitude error with the later missions [15:09:03] it starts reading it 500 ft/sec earlier [15:09:22] might be, yes [15:10:25] do you know what LRWVZ,Y,X and LRWVFZ,X,Y are? [15:12:31] weighting the LR measurement [15:12:46] the ones with F might be for P66 [15:12:54] in each LR velocity axis [15:13:09] what it basically does is this [15:13:18] dq = LR vel - LGC vel [15:13:31] LGC vel = w*dq [15:13:36] w being a number between 0 and 1 [15:13:49] 0 nothing from the LR measurements [15:13:56] 1 fully trust LR [15:14:02] it's always in between [15:16:21] LGC vel += w*dq [15:16:31] that of course, not only "=" [15:21:39] so LRWVZ,Y,X is the "w" in that equation? [15:24:11] in P63 and P64 below LRVF, yes [15:24:40] https://www.ibiblio.org/apollo/NARA-SW/R-567-sec5-rev8-5.3.pdf [15:24:45] PDF page 61 [15:25:22] so all those numbers are just for weighting the LR measurements against the current LGC velocity [15:25:30] none of them can cause our issue [15:25:50] they can make it worse or better by not letting high velocity LR measurements through, sure [15:25:52] right [15:26:39] I am testing Apollo 15 with 2000 ft LRVMAX on your Apollo 15 PDI scenario [15:27:26] I want to see if the Latitude error is consistent with the earlier missions which have that set to 2000 ft/sec [15:43:56] not much difference [15:46:29] what altitude is the LR supposed to start taking velocity readings? Wasnt it around 24000 feet? [15:53:14] that's in Luminary099 only [15:54:41] so reducing LRVMAX to 600 feet/sec gives a near perfect landing [15:55:39] basically equates to ~10000 feet altitude when going through 600 ft/sec [15:56:12] So the issue must lie above that velocity [15:56:16] so all the bad velocity readings are before 600 ft/s [15:56:21] or all of them that matter [15:56:59] yeah, before slowing through 600 feet/sec [15:57:31] as with my test it only started reading velocity below 600, and landed right on [16:02:17] @indy91 houston uhhh tranquility base here the eagle has landed [16:02:34] great! [16:02:38] auto landing? [16:02:40] P65? [16:03:08] hey Ryan [16:04:03] Did you know UHCL has "LM ( LUNAR MODULE ) DESCENT / phasing SUMMARY DOCUMENT MISSION F FINAL"? [16:05:00] yes auto land and i wasnt looking at the dsky in the final moments [16:05:24] i am going to do doi and pdi again and record it [16:05:56] No I didnt [16:06:08] not a big fan of the attitude hold [16:06:35] well i am going to take a break for a few hours and get some more Tylenol [16:06:43] I wonder how different it is from the prelim phasing [16:06:59] very different I would imagine, especially the LGC procedures [16:07:07] and once again, PRAISE NASSP [16:09:50] And thank you for finding bugs :) [16:09:55] indy91 do you have a link? [16:09:59] no problem [16:10:06] I'd say that should certainly be requested [16:10:16] https://historycollection.jsc.nasa.gov/default.htm [16:10:22] search there [16:10:30] and this wasnt really a bug but at the part where it rolled over it maneuvered pretty quickly [16:11:10] UHCL requests with: Title, Date, Record Number, Location [16:11:22] well, you know the drill :D [16:12:19] Yep I do [16:13:16] next document it's my turn again, haha [16:16:21] Hmm what do you think this would have in it: [16:16:21] F MISSION REQUIREMENTS SA-505 ( SATURN APOLLO 505 ) / CSM-106 ( COMMAND SERVICE MODULE 106 ) / LM-4 ( LUNAR MODULE 4 ) [16:17:37] we have at least one of those, let me find the link [16:17:50] https://history.nasa.gov/afj/ap17fj/pdf/a17_mission-requirements.pdf [16:18:34] I don't think it's terribly exciting though [16:18:45] it will have descriptions of the DTOs I guess [16:19:47] Just saw it when I was searching other F mission stuff [16:21:18] right [16:22:25] They also have the J mission rendezvous procedures [16:22:54] LM ( LUNAR MODULE ) RENDEZVOUS PROCEDURES, J-2 & J-3 MISSIONS * FINAL REVISION 1 * APOLLO 16, APOLLO 17 [16:24:22] https://www.hq.nasa.gov/alsj/a16/a16-a17_rendezvous.pdf [16:24:39] Ah [16:25:10] Request sent [16:25:32] great [16:25:41] Now I have been digging through this code for the pressures and I understand a lot of it, however there is one thing I cannot figure out [16:26:06] I do not know how it is computing the pressure of a tank when there is just one liquid in it [16:26:35] Because if I add a gas to it, the pressure in the tank instantly turns into the gas partial pressures that exist in there [16:27:21] And of course for a liquid that would be zero [16:28:58] weird [16:29:06] Lauren is out of the office until tomorrow btw [16:29:26] ah, automatic reply [16:29:30] Yep [16:29:51] So depending on how long she was gone there might be a backlog before I get a reply haha [16:30:04] But anyways [16:30:17] I see how it computes the pressure of the tank using partial pressures of gases [16:30:35] However I dont entirely see how it computes the tank pressure when there is say just one liquid [16:31:10] If I can figure out how that is done, I think I have a solution for the problem [16:32:01] is that the vapor pressure stuff? [16:34:03] I don't even know where this code is, haha [16:36:50] Haha all in hsystems [16:37:06] h_volume::ThermalComps [16:37:41] What i need to know is how it is computing a tank volume with just one liquid in it [16:40:25] I also discovered the gas constant was incorrect haha [16:40:30] very minor change but still [16:45:53] Too many names on! [16:46:44] dumb me set 2 networks in range to connect automatically [16:47:01] So they fought eachother [16:48:16] morning! [16:51:11] Hey good morning [16:51:34] indy91, for example if I have the fuel tank by itself loaded up, I get a tank pressure of 105psi [16:51:44] When I release the He into it [16:51:59] My tank pressure equals just the partial pressure of helium within [16:52:06] Basically ignoring the liquid [16:53:14] hey Mike [17:02:07] ibdy91, any other ideas of what I could test for the velocity readings to the LGC? Maybe throw a debug line somewhere? [17:02:22] indy91* [17:20:07] I wonder if it would be possible to have a SV compare debug line similar to what is done in the LVDC [17:20:23] to monitor the position error of the LM as it descends [17:21:01] or maybe just a display the LGC's current lat long so as to compare with PAMFD [17:35:21] hey Mike [17:35:29] o/ [17:35:38] rcflyinghokie2, that sounds really buggy [17:36:20] Yeah [17:36:33] AlexB_88, it would be tricky to get that debug line accurate due to timing issues [17:37:08] indy91 yeah its very hacky indeed [17:37:17] I am keeping track of units through this code [17:37:35] The partial pressure computations makes sense but the handling of liquids I still cannot make sense of [17:37:57] There is a delta computation that is troubling me unit wise [17:38:20] double delta = NV * NV - 4.0 * m_i * PNV; [17:38:54] It comes out to (L)(L)(L*Pa)(L/Pa) [17:38:59] Or L^4 [17:41:53] But in order for the next equation to work [17:42:41] good old quartic liters [17:43:07] Press = (-NV + sqrt(delta)) / 2.0 / PNV; [17:43:30] sqrt delta has to be a L^2 [17:43:40] And then it will return Pa [17:44:02] So I think somethings wrong here unless I messed up my tracing of units [17:45:09] I am going to check that quadratic [17:48:54] sounds like a plan [17:50:54] Maybe the LGC just cant handle high velocities (up to 2000 fps) in Orbiter 2016 [17:51:18] Found a math error I think [17:51:19] Maybe we just need an LRVMAX that is calibrated for Orbiter 2016 [17:52:20] As I have tried as low as LRVMAX 600 fps and that works well [17:52:40] but Maybe something in between 2000 and 600 would do as well [17:53:33] cant handle high velocity updates from LR is what I meant* [17:53:34] AlexB_88, what do you even mean by that, haha, "can't handle high velocities" [17:53:37] ah [17:53:44] haha sorry [17:54:10] so I am using an Orbiter API function to get the velocity relative to the surface [17:54:27] but I alredy tested that by using the global velocity and doing a bunch of calculations [17:54:27] or maybe the function used to return the velocity is not to good at higher velocities [17:54:32] exact same number [17:54:53] I see [17:56:05] I think it's still possible that I have some general flawed logic with the calculation or conversion of the velocity [17:56:37] the other theory that the LR delay is the issue seems unlikely, because there would be higher errors in the other axis [17:56:46] yeah [18:05:56] hmm [18:06:06] looking at the debug string with the LR measurements [18:06:22] the y-axis is the most sensitive to small attitude changes [18:08:49] well sometimes [18:10:37] yeah [18:11:45] Ive been monitoring the change in latitude during the descent and it seems most of the error is built up from 25000 feet (2000 fps) down to about 16-17000 feet (1100 fps) [18:11:59] I still cannot figure out it's determination of a liquif pressure [18:12:01] on Apollo 13 that is [18:12:01] liquid* [18:12:16] Everything in liquid form should return zero here [18:12:30] AlexB_88, how did you monitor it? [18:13:07] That tells me it is done somewhere else [18:13:22] well, I take a quick save just before it starts looking at velocity (2200 fps) then at a certain interval I just call P21 [18:13:29] and compare with PAMFD [18:13:32] haha, ok [18:13:40] didn't know that works [18:13:53] it does but it stops P63 [18:14:03] so what I did is quicksaved before each time [18:15:13] I will try setting LRVMAX to maybe 1100 fps and test that [18:16:43] one thing that is probably possible is to look at specific erasables [18:17:35] the LGC velocity that it uses to compare against the LR [18:17:38] might be possible to find [18:19:59] hmm, so I am pretty sure the LR issue still is happening just as bad late in the descent [18:20:10] it just doesn't affect the state vector too much anymore then [18:20:24] but all this rolling and yaw before the landing, when in auto mode [18:23:21] I'll give this LR delay thing a try [18:23:46] thewonderidiot, how much of a delay did we settle on? [18:23:55] at throttle down the error rate must go down too [18:24:06] uhh [18:24:08] 100ms, I think [18:24:13] right [18:30:55] indy91, not sure if you can help me find it, but I am trying to figure out where the code adds up partial pressures to return pressure [18:31:44] I see where it computes the partial pressures, but I cannot figure out where it is getting the value for say space.Press [18:32:44] ah, I think I know that [18:34:36] ah no, was thinking of something else [18:34:47] Press = (-NV + sqrt(delta)) / 2.0 / PNV; [18:34:50] isn't it this? [18:35:05] space is a h_Volume that h_Tank owns [18:35:12] so that press is the tank pressure [18:35:23] So where does it use added partial pressures [18:35:41] And I think that equation is wrong btw [18:35:51] double delta = (NV * NV) - (4.0 * m_i * PNV); //delta of quadric eq. P^2*PNV+ P*NV + m_i = 0 [18:35:51] if (PNV) [18:35:52] Press = (-NV + sqrt(delta)) / (2.0 * PNV); [18:35:57] Its a quadratic [18:36:12] I think my version is correct [18:37:44] it doesn't look like it even works with added partial pressures [18:38:09] it adds up for the total pressure in the first for loop [18:38:11] not the second [18:38:24] Yeah which is why I am confused [18:40:09] Is my quadratic math change correct though? [18:40:40] the denominator of the quadratic should be 2a [18:40:43] I'll check [18:40:47] a in this case is PNV [18:40:54] so /(2*PNV) [18:41:03] not /2/PNV [18:41:20] you sure that equation in the comment is correct? [18:41:30] No idea where that came from honestly [18:42:00] But using that equation is where I figured the change [18:42:02] looks like some real gas equation [18:42:31] Looks like they use ideal gas equations everywhere else though [18:42:49] So seems weird to throw a real model in there [18:44:14] well, I say it looks like real gas, but that might not be true [18:44:31] I just didn't remember ever having something like this with ideal gas :D [18:44:36] Nope [18:45:00] Maybe it was unfinished because you can use Tcrit and Pcrit to compute real gas approximations [18:45:09] Those are in the header but I dont think they are used [18:46:32] But with that pressure calculation, it uses m_i [18:46:36] that is moles of gas [18:47:08] so if it is not a gas, that delta goes to zero [18:47:26] leaving press=-NV/2PNV [18:47:36] I cant math... [18:47:50] press=-NV+NV^2/2PNV [18:50:12] So with the quadratic that makes -NV+NV/2PNV [18:50:20] Or zero [18:50:44] So I dont know where the liquid pressures come from [18:56:58] your version is identical to the one in the code [18:57:04] Press = (-NV + sqrt(delta)) / (2.0 * PNV); [18:57:10] Press = (-NV + sqrt(delta)) / 2.0 / PNV; [18:57:14] same thing [18:57:55] order is important without the () [19:00:55] Ohh [19:01:01] Ok well that explains why nothing broke [19:01:51] Are the tanks assumed to be spheres? [19:03:16] no idea [19:06:35] any luck with the LR delay? [19:07:57] haven't started yet [19:20:52] Well I have some solutions for the liquid and vapor together, but I need to fully understand the current implementation [19:21:17] I just cannot figure out how it calculates without gases right now as all that code depends on a vapor state [19:22:17] the partial pressures are calculated that way, yes [19:22:24] but what are those even used for in the code [19:22:36] Apparently they sum up [19:22:48] Press has a comment of sum of all partial pressures [19:23:13] And that makes sense because when I add helium to the fuel tank, the total pressure all of a sudden is equal to heliums partial pressure [19:23:30] well as you said, it would be good to be able to talk to whoever implemented this, haha [19:23:37] Very much [19:23:53] Somewhere there has to be a computation for the non gas case [19:24:04] Because all of that code returns zero if there is no vapor mass [19:24:15] So the liquid pressures are coming from something else [19:24:26] I'll hunt for it later, back in a bit [20:02:05] about the abort constant, I just noticed we have the AGS abort constants in the timeline books for Apollo 14 and 16 [20:03:26] those could probably easily be converted to LGC EMEMs, probably just by inputting them into the worksheet [20:04:01] hmm, maybe [20:04:53] I noticed the Apollo 13 LM data card has the AGS abort constants, and some of the numbers are identical to what we have in the Luminary131 worksheet [20:05:01] where are they in the timeline book? [20:05:23] well on Apollo 14 actually its in the activation checklist [20:05:29] 2-28 [20:05:32] ah, I was looking in the Apollo 14 Timeline Book [20:05:43] 224/225/226/305/662/673 [20:05:52] and Apollo 16 in the timeline book [20:06:39] does the AGS have the two segments like the LGC? [20:06:58] hmm that I am not sure [20:07:15] I guess that is for the two PDI opportunities? [20:07:21] no, never [20:07:39] the padloaded parameters are always for PDI1 [20:07:50] updates would have been done for PDI2 [20:07:51] right [20:09:58] J1PARM/K1PARM and THETCRIT from the Luminary131 padload workbook (based off the actual padload I think) [20:10:14] those are identical to the numbers in the Apollo 13 LM data card book [20:10:33] except for J2PARM/K2PARM [20:10:37] the AGS ones in the data book? [20:10:43] yes [20:10:55] ah, I think there actually are special procedures for a late abort on the AGS [20:11:01] Apollo 13 LM data book has the AGS abort constants [20:11:51] right [20:12:02] well, that means the AGS is using the same logic [20:12:19] so the first segment, K1 and K2 can probably be safely translated into LGC constants [20:12:50] tested a landing with delayed answer from the LR [20:12:57] doesn't change a thing [20:13:03] damn [20:13:05] 0.01° off in longitude, 0.08° in latitude [20:14:37] My new workaround for this is using a lower value for LRVMAX [20:20:37] the LGC was reacting really quickly on the radarupt though [20:20:48] I set the time delay back to 0 when the data was ready [20:21:11] and on the next timestep the LGC was never sending out the output bits anymore that requested the data [20:22:00] thewonderidiot, is the LGC doing that immediately when receiving the radarupt or something? [20:24:08] lemme check [20:26:01] let's see, so first thing it does is check the selection bits to see what reading it got [20:26:42] then it resets the activity bit, which is interesting [20:26:55] with RXOR, even [20:27:17] ah, the activity bit [20:27:29] so that already bypasses everything in the LR code [20:27:45] without that no output processing is ever done [20:30:14] ah wait [20:30:16] I am dumb [20:30:22] lem->agc.SetInputChannelBit(013, RadarActivity, 0); [20:30:34] that is done in LR code right now, haha [20:30:39] so yes, reset very quickly... [20:32:01] AlexB_88, pushed a few updates I commited earlier today. The time critical lunar liftoff time calculation and the requested DAP PAD page for the RTCC MFD. [20:32:09] night! [22:18:27] hey @thewonderidiot [22:19:00] yo [22:19:19] i dont know if you heard but i landed on the moon [22:19:26] nice! [22:21:23] so I think I'm the only one in here that hasn't yet :P [22:22:46] you should one day [22:24:17] one day! [22:24:24] but not in the next year or so lol [22:33:16] slowly raises hand [22:33:34] I need to land too still [22:34:15] oh nice [22:34:23] :D [23:40:48] @Thymo you have not done a mission yet? [23:41:39] Thymo has spent lots and lots of time in 7 and 8, iirc [23:46:29] i didnt think i would make it this far honestly [12:04:46] hey indy [12:06:30] @indy91 i think i may have landed in the wrong spot [12:08:04] hey [12:08:10] why do you think that? [12:08:35] i saw your 11 lunar landing video and where i landed i dont see any craters everything is flat and dark [12:09:25] i think you said something about microtextures in one of your comments on your video [12:09:46] yes [12:09:57] so what you saw in the video is actually an old texture that has since been removed [12:10:19] only meant to give the flat Orbiter 2010 Moon a better look at the landing site [12:10:45] the Apollo 15 video might have already used the microtextures [12:10:58] that is a special download for the DX9 Client [12:14:53] the microtextures are basically some randomly generated craters etc. so that the Moon looks nice at close up [12:15:13] http://users.kymp.net/p501474a/Orbiter/MicroTextures.zip [12:15:19] that's the download [12:15:26] I really recommend using it, looks great [12:15:56] that download just has to be extracted to the Orbiter folder [12:17:29] i just got it [12:17:57] there was already a microtextures cfg file but ny moon texture files [12:19:04] no* [12:20:00] well i am gonna go and record my pdi and put it on youtube now [12:21:55] have fun. I'll watch the video and give some feedback on your landing technique, haha [12:22:05] okay [12:22:14] i 've done it about 5 times [12:22:20] its mainly automatic [12:22:35] and this time with the microtextures [12:23:12] you really should try it with P66, it's a lot of fun [12:43:44] hey [12:44:44] hey Alex [12:45:06] nice job on the DAP pad [12:46:46] and the time critical insertion of course [12:46:59] Ill have to try that soon [12:49:30] I'm working on two things you will enjoy [12:49:42] Apollo 11 launch scenarios for July 18th and 21st [12:49:49] but those will take a bit [12:50:03] and today I really want to get the PGNS downlink into the AGS register [12:50:18] that has to be done anyway, even if it still doesn't work yet because of timing issues [12:50:31] it might work in 0.1x after today though :D [12:51:16] oh nice [12:51:48] I was thinking about that yesterday looking at all the V47s in the timeline books [12:53:39] btw I just realised we have an Apollo 15 timeline book (minus the abort section) [12:54:42] its hidden away in the Apollo 15 Delco manual, there you have the nominal descent and ascent timelines [12:55:11] which pages? [12:55:18] in the delco manual [12:55:47] 292 of the PDF is the descent timeline [12:56:30] and 325 of the PDF is the ascent timeline [12:57:17] oh wow [12:57:20] it's complete [12:57:23] yep [12:57:36] even has AGS pad :) [13:02:15] so much good stuff is hidden away, you never know what you find [13:02:28] so I think we have AGS abort constants for every mission now [13:02:31] yeah [13:02:54] AEA source code is just an appendix to the AGS guidance equations document after all, also not something one would expect [13:03:28] one LM cue card document has all the CSM cue cards as well [13:03:33] so many examples of this, haha [13:04:00] @indy91 was it you that added a dap pad? [13:04:12] yes [13:04:18] quite useful I guess [13:04:41] yes very [13:04:43] I already added it to the MCC before, just had to add an interface on the RTCC MFD [13:05:33] just one comment about it, would it be possible for it to display ascent stage only weight, before staging? [13:05:52] Maybe with the ascent stage/descent stage selector on the config page [13:07:38] yeah, I guess that is possible [13:10:32] great [13:11:22] thats useful for before lunar ascent, you enter the ascent stage weight into V48 of course [13:17:14] I tested an Apollo 13 PDI abort (late) using AGS with the abort constants from the LM data card. DKI check after insertion 0.2 fps or something stupidly low like that [13:17:26] DH of 14.3 [13:19:09] and using the 16 minutes before sunset now instead of TPI at orbital midnight [13:19:25] right [13:19:31] great [13:23:05] MSC is down [13:23:57] seems like a new error [13:24:19] ah [13:24:26] it's all of ibiblio this time [13:24:30] even the Virtual AGC page is down [13:39:22] for the last minutes of the descent it was coming down pretty fast and when the lunar contact light came on it was pretty much on the ground is that normal? [13:41:55] yeah, it doesn't simulate the probes yet [13:42:06] so the light comes on when the LM already is on the ground [13:58:58] So I guess you've found a way to get the PGNS data to AGS [14:07:23] I'll need help from Mike for it [14:08:03] https://www.youtube.com/watch?v=-hizK00x3pA&feature=youtu.be [14:08:05] but with or without running the PGNS and the AGS in a timestep together, the downlink data need to go through the output channels to the AGS register [14:11:20] astronauthen96__, skimming through the video, noticed two things already [14:11:49] first, Orbiter Sound isn't very compatible with Orbiter 2016 it seems [14:11:57] the altitude callouts [14:12:08] those seem to be relative to the mean lunar radius [14:12:12] and not the actual altitude [14:12:36] and Tranquility Base is quite a bit below the mean radius of the Moon [14:12:59] pretty funny, it sounds like you are crashing into the Moon at high speed with the callouts :D [14:13:17] but it's just the LM reaching the 0 altitude above mean radius [14:13:42] I have disabled the altitude callouts [14:13:54] that can be done in the SoundConfig exe [14:14:23] the other thing I noticed is that you weren't using the LPD window/panel at all [14:14:30] that's from the main panel left and then down [14:14:43] that is what you usually use for the landing [14:14:43] yeah i forgot what the engine stop keyboard command was [14:14:51] i would have used it if i remembered [14:14:52] minus key on the numpad [14:15:28] P65 did a good job, so you didn't really need the LPD window :D [14:15:49] but for any manual or semi-automatic landing the LPD panel is the best one [14:16:44] did you manually yaw to heads up or did the computer do that? [14:16:57] t didnt do anything manually [14:16:58] astronauthen96__ nice video! [14:17:04] thanks alex [14:18:23] I think the Apollo 11 procedure is to start PDI face down, as you did, and then manually yaw 180° to heads up at about 4 minutes into the descent or so [14:19:17] ideally you want to be heads-up before you do the V16N68, V57E [14:19:34] yeah, I wonder how the LR even had lock on in that attitude [14:19:53] that is the "Yaw Right 174° entry in the checklist [14:20:49] astronauthen96__ V16N68, V57E.. that tells the computer "please start integrating landing radar data into my state vector" [14:20:53] ah [14:20:55] it didn't [14:20:59] ALT light was still on [14:21:17] i didn't know when to enter v57 [14:21:43] but your landing radar was still pointing into empty space :p so you yaw to heads-up to point the landing radar at the lunar surface, then hit V57E [14:22:07] yeah, you do the yaw maneuver when the checklist says "yaw right 174°" [14:22:16] actually, before hitting V57E, you confirm that the ALT and VEL lights are also out on the DSKY [14:23:23] I think it's register 3 of Noun 68, the DH [14:23:29] it said +9999.9 for you [14:23:38] well [14:23:41] +99999 [14:23:50] that means the LR has no good data yet [14:30:49] Looks like Lauren's fast turn around will pull me off thermodynamics for a bit [14:30:51] https://www.dropbox.com/s/4fqkjko8jt3x38b/HSI-36576.pdf?dl=0 [14:33:09] She's quite efficient lately :) [14:33:57] And she was just out of the office yesterday no idea how long (got an automated email) [14:35:58] what mission is that doc for? [14:37:53] 10 [14:38:04] ah right [14:38:09] We only had the pre;im phasing [14:38:12] prelim [14:39:36] So this will help with any issues in procedures and previous digressions from the flight plan [14:39:47] hey Ryan [14:39:49] hmm [14:40:05] I can't easily tell the date of this document [14:40:11] February? [14:40:49] Yeah [14:42:37] so still a bit outdated [14:43:10] 2 months [14:43:13] 3 [14:43:21] so I am sure the document has some great updated procedures, but I would still be careful with taking any DSKY inputs for granted [14:44:02] I have them side by side right now looking for differences [14:45:25] First I see if using a V47 using undocking [14:45:31] is using* [14:46:06] And 15 minute time difference for undocking [14:46:09] Maybe the Apollo 11 timeline book would be a better reference? [14:46:23] Not for phasing [14:46:40] Remember this isnt the rendezvous [14:46:40] right [14:48:47] Looks like MSFN updates the CSM SV after sep, no longer a V76 [14:49:50] that can be cross referenced in the flight plan [14:49:56] if that is done or not [14:50:20] morning! [14:50:35] Yeah there are a few little differences throughout [14:50:57] in addition to those Delco manuals at UHCL which can't be scanned, Virginia Tech has 12, 14, and 17 [14:51:23] I need to get back down there [14:52:22] hey Mike [14:52:53] I have decided that we are putting PGNS data on the AGS downlink input register today :D [14:53:16] but I won't be able to do it without you [14:53:29] they also have CSM and LM "Guidance and Control Data Book"s which I am getting increasingly curious about [14:53:34] hahaha [14:53:59] you know right when you logged off last night I was about to say that the radar timing would be perfectly handled if we integrated my counters branch of virtualagc :P [14:54:13] and we will do that eventually [14:54:42] so what do you need help with for AGC->AGS? [14:54:43] but your counter branch doesn't assemble the 40 bit downlink word [14:54:58] does it? [14:55:09] hmm, you're right, it might not [14:55:16] we are doing it in PCM code [14:55:23] I need to fix that then [14:55:24] but the downlink goes to both AGS and PCM [14:55:50] so for now I'll try to assemble it in the NASSP LGC electronics code [14:55:58] so I have channels 34 and 35 [14:56:03] what do I have to do with them :D [14:56:47] the assembled downlink word is 40 bit, but the AGS only gets 18 bits or so [14:56:52] so the first bit comes from a different channel [14:57:03] I guess it's not as easy as sending channel 34/35 data directly to the AGS [14:57:10] channel 13? [14:57:41] 13 bit 7, yeah [14:57:43] DownlinkWordOrderCodeBit [14:58:01] so the value of that bit will be the first bit in your 40 word downlink [14:58:06] is it a safe assumption that that bit gets set first? [14:58:13] yeah, just copy the value of that bit [14:58:19] ok [14:58:52] I'm using the ChannelOutput function right now [14:59:03] we have special processing for specific channels [14:59:06] after that, I believe the next 15 bits come from channel 34 [14:59:08] and I just added 34 and 35 to it [14:59:12] then the 15 bits from channel 35 [14:59:23] and then 7 empty bits or so [14:59:31] and then the remaining bits are just repeated from the start of channel 34 [14:59:35] ah right [14:59:57] and what exactly is the AGS getting from this? [15:00:33] AGS is just getting this data fed straight into it, along with (I assume) a clock from the PCM [15:00:47] ok, but the AGS register is only 18 bits [15:00:57] well that's a problem :D [15:01:12] so would that be: 1 bit from channel 13, 15 bits from channel 34? [15:02:20] one of the documents you got us from UHCL says "AEA accepts first sixteen bits of each PGNCS 40-bit downlink word" [15:02:38] so I wonder if it would be sufficient to send channel 34 plus that one bit [15:02:39] oh really? [15:02:43] it might be then [15:02:58] I even tried that already, but it didn't work. But I forgot about the leading bit [15:03:11] yeah it's going to need that leading bit to sync [15:03:35] how do I put that bit there [15:04:02] what form do you have it in? just the full channel 13 word? [15:04:54] yeah, as unsigned int [15:05:13] and the nice and easy solution would be to have this in ProcessChannel34 [15:05:21] which is called whenever the AGC writes to that channel [15:05:34] it would just add that channel 13 bit there and send it directly to the AGS? maybe [15:06:28] unsigned int ags_word = ((ch13_value & 0100) << 9) | ch34_value; [15:06:52] grab the bit in position 7, move it up to position 16, and OR it onto channel 34 [15:07:44] ah [15:07:51] see, this is the kind of stuff I needed you for :D [15:08:00] my brain just doesn't work bitwise [15:09:00] ok, I'll try that [15:09:07] valx = SignExtendAGS(val) * 4; [15:09:07] valx &= 0377774; [15:09:08] SetInputPort(IO_6200, val); [15:09:14] I think I also need to do this? [15:09:43] because, yaAEA wants the most significant bit "in front" of the 18 bit word [15:09:56] at least I have to do this with the CDU data [15:10:18] that will do the trick, if that's what it wants [15:10:25] ok [15:10:28] and what about AGSDownlinkTelemetryStopDiscrete [15:10:46] probably should be set whenever something was completely sent to the AGS [15:11:01] AEA resets it whenever it is reading from it [15:11:32] I assume that's DLKEND from the PCM as well [15:11:54] probably, although there seem to be a few stop pulses [15:11:55] so yeah, just set it when you write anything into it [15:13:16] and inversed logic [15:13:22] so set that discrete to false [15:14:19] hmmmm [15:14:20] valx = SignExtendAGS(val) * 4; [15:14:28] why is the link to the AEA programming reference dead [15:14:31] is the 4 correct for the conversion from 16 to 18 bits? [15:14:42] because ibiblio is dead right now [15:14:45] Virtual AGC page [15:14:46] our forum [15:14:54] sigh [15:15:12] State->InputPorts[IO_2020] |= 0200000; // downlink stop discrete. [15:15:19] this is was yaAEA does to reset it [15:15:26] | is OR [15:15:31] so it should set the bit to 1 [15:15:33] right? [15:15:49] so I have to set it to 0 [15:16:07] in the channel 34 code [15:16:18] oh [15:16:23] 0200000 [15:16:29] ah no, that is an AGS word [15:16:35] channel 13 is AGC [15:16:43] so we are using the right bit from that [15:18:12] yeah, here: https://web.archive.org/web/20160710064648/http://www.ibiblio.org/apollo/Pultorak_files/AEAProgrammingReference.pdf [15:18:13] page 17 [15:19:10] it takes the first 18 bits of the downlink word, and gets a stop pulse discrete "from the PGNS" (meaning, I assume, the PCM) [15:19:54] so yeah, looks good assuming the 2020 bit is correct [15:22:21] where'd you get the 0200000? [15:22:58] State->InputPorts[IO_2020] |= 0200000; // downlink stop discrete. [15:23:04] aea_engine.c [15:23:10] line 481 [15:24:55] that is resetting the bit, when the data was read from the register [15:25:13] oh perfect [15:26:18] hmm [15:26:30] yeah so if you want to set it to 0 [15:26:48] State->InputPorts[IO_2020] &= ~0200000; [15:27:09] or much easier, already have a function that does this for any of the input bits :D [15:27:19] haha sure [15:27:21] SetInputPortBit(IO_2020, AGSDownlinkTelemetryStopDiscrete, false); [15:27:38] I debugged a bit [15:27:54] it is calling that line in aea_engine shortly after I do a 414+1 on the DEDA [15:28:02] that starts the search for good PGNS data [15:28:19] after that I have to press PRO in V47 to start the downlink [15:28:29] then the LGC sends the downlink ten times [15:28:43] so at least the AEA is already reading the register [15:28:56] and I guess it's waiting for the ID word [15:29:00] yep [15:29:09] 77776 [15:29:26] I guess that is without the preceeding bit from channel 13? [15:29:28] just to check you're using a matching pair, right? Luminary 99 + FP6 or Luminary 210 + FP8? [15:29:38] oh [15:29:43] I am using Apollo 10 [15:29:49] Luminary 69 and FP6 [15:29:55] hmmmmm [15:30:07] let's start with two we know flew together, and then get the others to work :D [15:31:13] ok [15:31:22] it's not working yet at least [15:31:26] 414 stays 1 [15:31:39] that should become 0 once the update is done [15:34:01] what exactly is FP6 looking for in the downlink? [15:36:14] probably good to check if the AEA is getting the ID word [15:36:18] be back later [15:39:05] yeah I need to get to work [15:39:17] but I'll dig out what exactly it's looking for [16:10:21] AlexB_88, adding another utility page for the RTCC MFD in the mean time [16:10:31] for the LVDC [16:10:41] that page will have IU state vector update I guess [16:10:54] but for now I am just adding the launch azimuth calculation that you wanted for a while [16:15:30] great! [16:20:14] interesting [16:20:30] Apollo 11 for July 18th has a launch azimuth polynomial that is from 72° to 108° [16:20:37] but nominal launch is at 89.295° [16:20:42] flight plan confirms that [16:20:57] July 21 launch 94.6675° even [16:26:19] pushed [16:26:39] LM ascent stage weight for the DAP PAD as well [16:28:42] the July 18 scenario has all the LVDC presettings for that day now, but I haven't started with CMC or LGC yet [16:30:16] our Apollo 14 LVOT only has numbers for January 31 [16:30:59] and we have an Apollo 12 LVOT for the September launch month, G Mission reflight [16:31:26] and that has presettings for September 13, 15 and 18 [16:33:35] and if we ever get the complete Apollo 8 LVOT, it should have numbers for December 20-27 [16:33:40] maybe even January, can't remember [16:34:15] just December launch month I think [16:41:34] lots to choose from [16:43:08] yeah, it would be great if I could get the MCC to work with all those G-Mission launch dates [16:43:31] back! [16:45:54] welcome back [16:47:10] so the 18-bit sync word the AGS will be looking for is 0777770 [16:48:26] oh, ok [16:48:53] that's what should be written into the register [16:49:03] I'll add a debug string and check if that is done [16:49:25] I think. that's with the word order bit set and the ch34 contents shifted up 2 positions [16:49:37] ah damn, had a typo [16:49:42] we can definitely ignore everything in ch35, because this is one of the first things FP6 does: [16:49:47] might even work now then, haha [16:49:48] LRS 2 # DISCARD UNWANTED BITS [16:49:54] ah, those 2 last ones? [16:49:55] right shift 2 [16:49:59] yeah [16:50:46] about timing requirements [16:50:55] LGC sends out 50 downlink words per second [16:51:23] I guess 60fps aren't good enough for that all to work right [16:51:42] I don't think it matters that much [16:51:43] PGNS makes a 1/60s timestep, AEA makes a 1/60fps timestep and so on [16:52:16] both are at the whim of the PCM here -- there's nothing inherent to either that dictates 50 words per second [16:52:40] if you run at 60, you just slightly increase computational load [16:52:57] oooh [16:53:08] I think it did something [16:53:11] ! [16:53:29] 414 is 0 [16:53:32] let me do that again [16:55:49] 414 is 0, I like the sound of that! [16:56:00] I don't [16:56:06] it even does that without starting V47 [16:56:12] that can't be right [16:56:37] heh [16:57:15] but at least it's different from before [16:57:22] it never was set to 0 before [16:57:23] what exactly is the procedure to do the initialization? [16:57:44] V47E [16:57:49] starts the routine [16:57:50] 414+1 [16:57:56] makes the AEA look for the downlink [16:57:57] PRO [16:58:00] starts the downlink [16:59:05] hmm [16:59:11] and I am never seeeing the debug string [16:59:23] so I don't think this is all worknig right yet [16:59:35] unsigned int ags_word = ((OutputChannel[013] & 0100) << 9) | val.to_ulong(); [17:00:02] val is a "ChannelValue", 16 bit bitset [17:00:29] OutputChannel[013] is an unsigned int [17:00:57] .py oct(0o100 << 9) [17:01:17] should work [17:02:03] and then you shift that up 2 more places right? [17:02:15] so [17:02:17] first it is 0177776 [17:02:25] yes that's right [17:02:26] and then I do [17:02:28] valx = SignExtendAGS(val) * 4; [17:02:28] valx &= 0377774; [17:02:41] that function does [17:02:42] if (i & 0400000) [17:02:42] i |= ~0777777; [17:02:43] return (i); [17:02:58] SignExtendAGS that is [17:03:10] .py oct((0177776 * 4) & 0377774) [17:03:19] oh [17:03:45] I think you're dropping the most significant bit there, that should come out to 0777770 [17:04:02] I'm just reusing what I did with the CDU data, haha [17:04:05] get rid of the sign extend and stuff [17:04:12] ok [17:04:24] replace [17:04:28] valx = SignExtendAGS(val) * 4; [17:04:29] with [17:04:39] << 2 [17:04:40] valx = val << 2; [17:04:42] yes [17:04:48] I am learning [17:04:52] slowly [17:05:00] and the valx &= 0377774; [17:05:09] yeah get rid of that too [17:05:11] ok [17:07:04] ! [17:07:12] I think that worked [17:07:15] :D [17:07:17] 414 stayed 1 for a bit [17:07:24] and then became 0 [17:09:37] range rate check doesn't work out [17:10:07] part of the normal procedure to compare PGNS and AGS [17:10:15] boo [17:11:39] not really sure what could be going wrong... [17:11:53] let me check really fast that the word order bit is just a dumb flip-flop that doesn't have any fancy logic [17:12:22] trying again with a L099/FP6 scenario [17:13:07] yes, nothing special about the word order bit, it's just a dumb flip-flop [17:13:42] range rate comparison before the update was right [17:13:50] and now the DEDA shows a bad number [17:14:13] come on AGC [17:14:17] play nice [17:15:06] the 414 is behaving fully correct now I believe [17:15:10] it's just the data now [17:15:32] right, but where could it be going wrong [17:16:15] maybe it is timing [17:16:33] how so? [17:17:18] hmm [17:17:31] that should only really depend on the input discrete [17:17:42] which gets set whenever something new is written to the register [17:17:47] yeah, should be fine [17:17:59] but maybe the next data is already written before the AGS can react at all [17:19:02] isn't it writing to the register 50 times per second? [17:19:07] ah, that could be [17:19:24] I can test for that I think [17:19:30] you could try dropping the rate to 30Hz [17:19:33] just do it every other frame [17:19:57] which rate [17:20:27] well how fast are you doing it now? you said it was nominally 50 words per second right? [17:22:41] that's how fast the AGC is sending downlink words I think [17:23:24] oh you mean change the frequency of downrupts [17:23:40] ? [17:23:42] yeah [17:24:42] is the PCM doing one downrupt per word? [17:25:41] yeah, this is all totally controlled by the PCM [17:25:52] the PCM sends a start discrete, then 40 clocks, then a stop discrete [17:26:03] when the AGC sees the stop discrete, it triggers a downrupt [17:26:40] so, one downrupt for each PCM-controlled downlink word, that happens when the PCM sends the stop bit [17:27:07] all I can see right now is that our PCM does one timestep for every 13.3333333 AGC timesteps [17:27:14] AGC cycles [17:27:54] heh [17:28:17] well hopefully it's not generating downrupts that quickly :P [17:28:32] no, it's not [17:30:13] aha [17:30:20] that rate is 6400 per second [17:30:50] and it goes through 128 words before doing another downrupt [17:30:57] 6400/128 = 50 [17:31:01] so that seem correct [17:31:04] seems [17:31:25] matches the LGC ICD [17:36:32] indy91, is your AGS time bias set right? [17:36:50] maybe, haha [17:37:06] but the relative conditions should still be right then I imagine [17:37:22] ok, I added a test counter [17:37:50] and it's showing that occasionally the discrete hasn't been reset yet by the AGS [17:37:51] at 1.0X [17:38:20] yes that will wreak absolute havok [17:38:46] looks good at 0.1x [17:39:20] that word order bit is going to be where it syncs, and everything after that is just based on the number of words since seeing that bit [17:39:47] testing a whole update at 0.1x now [17:39:49] I saw in something this morning a note about how often the stop discrete is checked [17:39:50] no lost words yet [17:40:14] I'll wait until 414 becomes 0 [17:40:14] fingers crossed [17:40:31] I just did a update at 1.0x, probably broke the state vectors in the AEA [17:40:46] so if they are good after this test, then we have this essentially working [17:40:55] minus the timing issue that I expected to be there anyway [17:41:08] ah damn, had 1 lost word [17:41:19] "To achieve proper synchronization with the data transmissions, the Stop Raise Discrete is sampled twice each 20 msec interval with a minimum separation between samplings of 1 msec." [17:41:22] so not even 0.1x would be 100% reliable [17:41:31] that's what the AGS should be doing [17:41:38] if it's not we may have another AGS bug [17:41:59] might just have been a quick drop in framerate [17:45:21] it shouldn't be that marginal though [17:45:32] it's sampling at 2x the downlink rate [17:53:30] success! [17:53:35] !! [17:53:38] the downlink at 0.1X worked [17:53:51] hahaha [17:53:53] range rate identical [17:53:59] well that's a good start [17:54:03] not really ideal :P [17:54:05] I had 2 missed words in all of this [17:54:36] had a phone call and stepped away for 10 minutes [17:54:42] so those 2 were in that time [17:54:48] :D [17:55:01] when the AGS stopped resetting the discrete the counter starting going up again of course [17:55:09] yeah [17:57:49] so next up is running LGC and AEA in a loop together [17:57:57] that should make it 100% reliable at 1.0X [17:58:08] oh yes, I forgot they were in separate loops [17:58:14] that's almost certainly the cause of the problem [18:00:49] yes [18:01:15] apart from that though [18:01:29] and not to trivialize what you've done there [18:01:37] I'm pretty pleased with how easy this seemed to be :D [18:01:50] in its condensed form it's really only a bunch of added lines [18:02:25] it's just that none of those lines are something I am good at [18:02:29] looking forward to not have to do manual AGS SV updates lol [18:02:30] bitwise operations etc. [18:02:34] hehehe [18:02:39] you're learning though! [18:02:52] yeah [18:03:25] I was thinking about something [18:03:48] what causes the AGC to do its cycles at a specific rate in the real AGC? [18:03:55] it has a precise clock, right? [18:03:59] and that is used by the PCM [18:04:10] what is clocking the AEA? [18:04:29] for downlink? also the PCM [18:04:39] both computers have their own oscillators [18:04:43] ah, right [18:04:48] but downlink timing is done by the PCM [18:05:02] although, I think the PCM gets a 1.024MHz clock from the AGC, and derives its own stuff from that [18:05:08] or something like that [18:05:09] yeah [18:05:16] I think the PCM also has a backup oscillator or so [18:05:30] sounds right, wouldn't want telemetry to disappear because of a dead AGC [18:05:44] but the AEA is still reading from the register under its own timing [18:05:50] not PCM [18:05:52] yes that's true [18:06:28] so if the AEA was running at the wrong speed, or the timer it's using for the check is programmed wrong, or something, we would also see this [18:07:04] the AGS stuff has really fallen out of my mind since I was debugging the instruction problem, lol [18:07:23] I had FP6 pulled up to see what it was doing this morning and it looked like it was written in an alien language [18:07:49] haha [18:07:55] so just like it has always been for me [18:08:10] haha yeah [18:08:23] what's a bit annoying is that the yaAGC and yaAEA cycles are different [18:08:29] just funny because whenever we did that I knew the instructions and their side effects in and out to be able to spot the misbehavior [18:08:30] yaAGC has a fixed timing [18:08:49] aea_engine returns a delta time of the length of the instruction it just executed [18:09:35] probably even more annoying for you, the block 1 yaAGC has timing like aea_engine [18:09:51] Ron now prefers that way, and wishes he had done the original yaAGC that way [18:10:01] no that's not so bad, I would implement a whole new interface class for that anyway [18:10:06] apolloguidanceb1 or so :D [18:10:12] although I'm pretty partial to the way yaAGC does it [18:10:22] making it a fixed cycle time made the counter stuff much easier [18:11:07] I'm not sure what's going on in Florida right now, but in the off chance we do actually get scans of Block I schematics, I reserve the right to make the block 1 emulator behave the same way as block 2 :P [18:12:21] haha, sure [18:13:09] back later [18:13:21] also if it would make your life easier for aea_engine to change, we might be able to accommodate you [18:13:58] but, either way the timing is going to be different -- the fundamental timestep of the AGC is 11.73 microseconds, and I imagine the fundamental timestep of the AEA is not quite that [18:15:07] oof, maybe [18:15:28] instructions in the AGS don't nicely divide into multiples of a timestep like the AGC [18:16:30] they can take 73, 70, 13, 10, or 16 cycles (with variations during runtime), where a cycle is 0.9765625 microseconds [18:24:54] I'll figure something out [18:27:16] PCM and ASA sync are also in the timesteps, so that doesn't make it easier [18:27:35] lol [20:02:14] back [20:03:48] indy91, I tested the LVDC launch azimuth function, works quite well [20:04:09] and the ascent stage weight in the DAP pad as well [20:04:15] good [20:05:03] so I guess well have to do our V47s at 0.1x :p [20:06:16] I mean, I can push that version right now if you want, haha [20:06:39] still looking at the timesteps though [20:07:36] haha its no hurry, I am sure you will figure it out [20:08:22] yeah, I think I will [20:12:07] but not today [20:12:09] night! [11:06:58] good morning [11:07:24] hey [11:08:26] just wondering is the ags used in the lunar liftoff? [11:09:19] not normally, no [11:09:22] but it can be [11:09:27] good [11:11:13] because i have no clue how to use it right now [11:11:26] but i guess i could learn [11:11:45] yeah, no big problem. Learning 2 computers at the same time is a bit much too ask, haha [11:12:05] and i don't plan on making any aborts right now [11:12:07] once you think you have mastered the LGC you can always start getting properly into learning the AGS [11:13:25] half the time i don't even know what i am doing but in my opinion its one thing to just flip a switch but its another to actually know what the switch or button does [11:13:46] indeed [11:13:54] and I guess there are two ways of learning this [11:14:05] through repetition of procedures with the help of the Checklist MFD [11:14:22] and doing a loooot of theoretical reading of the AOH etc. [11:15:07] and i think it was you that said i have to know the agc well to do the rendezvous [11:15:44] yeah, fairly well. Rendezvous is challenging. [11:17:02] and it helps to know how the rendezvous profile looks like, the basic orbital mechanics of it etc. [11:17:13] and that's not something you can learn through following the Checklist MFD [11:17:34] so a bit of theoretical knowledge does help with that [11:17:51] yeah i have the procedures for the g mission [11:21:56] so, in the long run you will probably do both. Learn through repetition, but occasionally read up what certain switch do, how systems work etc. [11:22:13] learning an Apollo spacecraft is always going to be a steep learning curve though [11:24:52] and there is probably not going to be a shortage of new things to try [11:25:06] lots of missions to fly, lots of fun backup procedures to try etc. [11:25:16] flying a reentry manually is a lot of fun [11:49:47] and also eva's maybe with V9 [11:52:47] yeah, that will come in the future [11:53:02] and a detailed simulation of the lunar rover should also be fun [11:53:43] and also the transearth eva would be fun too just seeing the earth and the moon [11:55:26] and Apollo 9 had an EVA as well [13:10:48] morning [13:17:00] hey [13:17:28] https://github.com/indy91/NASSP/tree/ComputerTimestep [13:17:46] testing branch for the PGNS/AGS synchronized timestep [13:17:52] I don't fully trust it yet [13:18:41] there could be LGC, PCM, AEA or ASA issue. LGC and AEA clocks, general functionality (especially with the AEA/ASA) and of course the PGNS to AGS downlink could use a bunch of testing [13:18:46] issues* [13:19:27] Ill test that right away [13:20:03] so at 0.1x? or can it survive a 1x downlink now too? [13:20:35] that branch enforces PGNS/AGS timesteps to happen every 1 millisecond [13:20:45] so it should do a good update at any time acceleration [13:20:54] try it at 1x a bunch of time maybe [13:21:23] awesome [13:21:26] will do [13:36:18] I think eventually I should implement it in a more fancy way [13:36:33] where the computer cycles are actually done in a loop together [13:36:39] not just the general AGC and AEA timesteps [13:37:09] but enforcing 1ms max between LGC and AEA timesteps should work [13:37:28] at 0.1x with 60fps you are a bit higher than that [13:37:55] and according to the specifications the AEA should never try reading from the register more often than 1ms intervals anyway [13:38:29] and this implementation is also independant from framerate [13:40:57] but if this doesn't cause any new clock issues or other bad behavior, then it should work for now [13:43:46] building your testing branch now [13:50:52] ok 1st test [13:57:58] looks good [14:01:35] So I did the downlink and V83 vs. 440/317 match up almost perfectly [14:02:04] Ill try a pre AGS power up scenario and boot it up from scratch now [14:02:57] I'm still trying to come up with creative ways in how this implementation could be breaking things :D [14:04:50] can I just wipe out the AGS memory section in a scenario to do a fresh boot of the AGS? [14:05:24] I think so, yes [14:06:00] it should always initialize from the binary [14:06:10] and load over it anything from the scenario [14:06:13] just wipe out AEA_START to AEA_END I guess [14:06:21] yes [14:06:36] what about ASA? [14:06:48] better also delete that section [14:06:55] you will have the default padload then from the binary [14:07:06] ok [14:07:38] Ill configure all the AGS switches/cbs to OFF in the scenario beforehand as well [14:08:00] sure [14:08:19] potential clock issue are the same for AEA and LGC [14:08:24] issues* [14:08:55] but with your way you can definitely check if the state vectors that the AEA is getting are good [14:10:29] what do you mean clock issues? [14:11:59] so, previously the LGC and AEA timesteps were called at frame rate [14:12:25] and in these timesteps it determined how many LGC and AEA cycles it should do in that timesspan [14:12:36] although it actually used mission time to determine this [14:12:57] so it took the time between the current and the last mission time and used that to determine how many cycles should be done [14:13:09] now I put the AGC and AEA timesteps in a loop as well [14:13:27] which has a maximum step length of 1ms [14:13:53] and I had to be a bit creative to give that function a good "current" mission time [14:14:35] so this a whole new concept of how the code determines to do AGC and AEA cycles [14:14:40] or how often [14:14:55] that potentially could lead to clock issues in the long run [14:15:04] kind of like we previously had with the LGC [14:15:45] I think it should be working right, but you never know [14:16:24] I see [14:16:37] and this change also increases the amount of lines of code that need to be executed per timestep [14:16:38] I will definitely test for that today [14:16:46] and it probably does that a lot for time acceleration [14:16:55] not sure how much it affects frame rate [14:17:11] that is basically the bad thing about this implementation [14:17:31] who knows maybe on the contrary it will make the AGC even more accurate haha [14:17:33] a smarter one would require a lot more changes, but could be more efficient [14:20:19] yeah, so if this works without issues I will keep it, but I am not really happy with it. I will definitely revisit it [14:20:35] I have to anyway once I implement Mikes yaAGC update with the pulses [14:20:45] then the CDUs also need to be in that timestep etc etc [14:25:08] maybe I'll even implement it in such a way that there are timing pulses coming from the AGC clock [14:31:25] so y fresh AGS boot up was successful [14:31:30] so my* [14:31:46] now what to test next? [14:33:37] time acceleration [14:33:50] burn under AGS control, checking if the DVs work out etc. [14:34:13] AEA/ASA sync is also potentially a problem [14:34:28] I don't think there will be a problem, but you never know [14:34:33] ok [14:34:42] Ill try time accel 1st, 30x [14:36:09] just let it run for a few hours and then check LGC/AEA time and compare trajectory parameters between the 2 and PAMFD [14:39:49] sounds good [14:42:37] Ill fly a full PDI/landing followed by an AGS abort afterwards [14:43:18] the AGS abort constants on Apollo 13 worked very well for me previously, so I will see if it can match the previous performance [14:54:13] Good morning [14:54:41] hey Ryan [14:54:55] guess whats working now :D [14:55:07] AGS PGNS? [14:55:45] I saw Niklas and Mike start talking about that yesterday before I had to go [14:56:03] Niklas has a testing branch up for it and I have been doing tests for the past hour [14:56:13] works quite well so far [14:57:08] So the AGS is intercepting the PGNS downlink and copying the SV? [14:57:17] yep [14:57:32] V47 -> 414+1 [14:57:43] And 414 goes to zero when complete? [14:57:47] yep [14:58:09] its not in the main repo yet [14:58:19] I guess now we need a way to compute the K factor :P [14:58:29] Which is simple, really [14:59:35] Just take the difference in PGNS time and AGS time, and compensate the AGS time bias [15:00:19] But that's awesome that it is working [15:00:26] Are there any issues so far? [15:03:47] none yet in my tests [15:05:49] I am a little rusty on the downlink, but does the same channel carry the RR updates for FP8? [15:09:45] hmm not sure [15:14:38] yes, RR data works the same [15:14:55] it's really just a procedure difference. and different data being sent [15:15:51] Thats what I thought, that is awesome [15:16:02] hmm, we need to be careful with Apollo 13 [15:16:11] I wish i could figure out this tank pressure code as quickly :P [15:16:17] we are using FP8 for that it seems [15:16:39] but we are using Comanche 055 as the LGC version [15:16:51] I have to look at the procedure [15:17:05] Might need to revert to FP6 for 13 and 14 then? [15:18:17] hmm [15:18:32] it think FP8 is looking for the rendezvous downlink list actually [15:18:34] I* [15:18:44] hmm I dont think FP6 is a good idea for 13 and 14 [15:18:47] when you do the 411+1 [15:19:16] the abort constants format changed from 12 to 13 [15:19:37] 411+1 might be unsafe to do on Apollo 13 then [15:19:40] depends though [15:20:13] if the LGC changed the format of the rendezvous downlink list for the AGS, then attempting auto RR updates could be bad [15:20:25] if they only changed AEA code for it then it would work [15:20:27] AlexB_88 I think thats why we set 13 to use FP8 [15:20:37] Originally at least [15:20:39] yeah [15:20:49] no problem keeping FP8 for that [15:21:01] just, potentially the RR auto updates won't work [15:21:12] right [15:21:27] I dont think FP7 had the capability anyways so it wont be in any future procedures [15:22:08] so in NASSP Apollo 14 and later, it will work (Luminary210+FP8) [15:22:21] sorry [15:22:30] Artemis072+FP8 [15:22:43] no [15:22:48] haha I need more coffee [15:22:52] Me too :P [15:23:04] Luminary210+FP8 [15:23:12] 1374: 1116 077776 IDAI OCT 077776 # AGS INITIALIZE DOWNLIST ID [15:23:13] 1375: 1117 077775 IDRP OCT 077775 # REND./PRETHRUST DOWNLIST ID [15:23:31] so yeah, it's just looking for the rendezvous downlink list in the RR update mode [15:23:40] that list of course has the RR data [15:24:51] there definitely is stuff in that downlink list meant only for the AGS [15:25:53] Luminary131 downlink list is definitely different [15:26:20] so, procedure wise, you wouldn't try to that anyway on Apollo 13 [15:26:54] indy91, I have used a fresh Orbiter2016 folder to test your branch. (as I always do when testing a separate branch) Is there a way to have the Orbiter2016 planet textures from my main repo, called from the new temporary orbiter installation? [15:27:07] but if you tried, FP8 will recognize the rendezvous downlink list and then proceed to use a whole bunch of nonsense as the RR updates [15:27:26] AlexB_88, yes [15:27:28] a bit like Flight Simulator X/PREPAR3D does with panel/model folders [15:27:33] alias= [15:27:58] yes [15:28:08] I think you have to add some line to Orbiter_NG.cfg [15:28:36] ah great [15:28:42] Yeah its in the beta instructions somewhere [15:33:21] is 411+1 different on FP8? [15:35:13] that is used for the RR update [15:35:23] maybe there is no engine selection on FP8 anymore? [15:36:06] interesting [15:36:42] 0411 000000 S11 DEC 0 # AUTO RADAR SWITCH [15:36:46] this is FP6 [15:36:56] so the comment already refers to a radar procedure [15:37:08] but in FP6 411 definitely is engine selection, right? [15:37:57] Yes [15:38:05] oh [15:38:11] https://www.ibiblio.org/apollo/listings/FP6/FP6.aea.html [15:38:13] this is wrong [15:38:27] the comment in the actual FP6 listing is "RCS-DPS/APS Switch" [15:38:47] so, careful with any comment in FP6 :D [15:39:05] Interesting [15:39:17] Yeah my reference from that was the manual [15:40:12] But the reason they removed it is because the APS cant angle was removed as well [15:40:52] 411 allows the AGS to use the APS cant angles versus the longitudinal thrust axis [15:41:20] ah, right [15:41:26] But since the cant angle addresses are no longer used for cant angles in FP8, the eng select became unnecessary [15:41:27] so there basically was no difference anymore [15:41:31] Right [15:41:55] I remember that difference when doing the padloads [15:42:06] yeah [15:42:15] morning! [15:42:23] and the AEA only sends out "engine on" anyway [15:42:27] just a quick note, Ron never updated the HTML things [15:42:27] not DPS or APS engine on [15:42:37] haha, yeah, hi Mike [15:42:41] I proofed the comments in the .aea files in the repo, though, so you can trust those comments [15:42:42] Hey mike, I hear you guys got the AGS PGNS communication working :) [15:42:51] I am using the HTML version mostly [15:42:54] mostly Niklas [15:42:59] mostly Mike [15:43:16] Now I need someone to "mostly" help me figure out this tank pressure thing :P [15:43:56] I will dive back into that after these Apollo 10 phasing changes [15:43:57] there's a whole bunch of wrong/missing comments in the html versions, especially FP6 [15:44:06] haha, I won't be any help for that one for sure [15:44:09] The procedure is a lot smoother than the prelim one [15:45:35] anyways, gotta head to work, be back in a bit [15:46:39] rcflyinghokie, unrelated to the PGNS -> AGS downlink, I noticed some oddities with FP6 on my Apollo 12 scenario last night [15:47:21] Like what? [15:47:51] I had been trying some AGS aborts from about 1000 feet or so above the surface and the later missions (Apollo 13 and later) work very well especially since we have the abort constants in the docs [15:48:11] but on Apollo 12, the insertion altitude is very weird like 12x25 NM [15:48:51] and I cannot explain why, I have the abort constants in there from the Apollo 12 activation checklist and all is set up correctly in the AGS [15:49:10] That is odd [15:49:47] And yeah the padloaded ones are direct from the mission as well [15:49:48] Have you done any testing with Apollo 12? [15:49:58] I did, yes [15:50:01] AlexB_88, when did you abort [15:50:07] But I dont remember having that kind of orbit even down low [15:50:32] indy91, PDI+11 minutes about, just before landing [15:50:37] in the late abort bracket [15:50:39] I did a bunch of those [15:50:42] ah, that kind of explains it [15:50:52] My orbits were as expected in the abort books [15:51:51] that is consistent with Apollo 11 [15:52:04] or at least 11x30 would be [15:52:31] Apollo 12 10 minute abort is 35x11 or so [15:53:03] yeah but the trajectory I was in was way off from what PGNS was aiming for [15:53:20] doesnt PGNS have the Apollo 11 targets as well? [15:53:32] Apollo 11 and 12 are very different procedure wise [15:53:41] Apollo 11 late PDI abort is always 30NM apolune [15:54:05] PGNS does that as well [15:54:33] which is a bit clumsly procedure wise [15:54:45] so they changed it to the two segment logic in the PGNS for Apollo 12 [15:54:58] ah [15:55:16] I actually tried that abort with the PGNS once [15:55:20] because it's Apollo 11 only [15:55:31] CSM rendezvous procedure document has it [15:55:53] but I am not sure what should be padloaded for Apollo 12 in FP6 [15:56:05] So our Apollo 12 PGNS, is loaded with the Apollo 11 constants, which are wrongly have only 1 segment (for Apollo 12) [15:56:25] no, Luminary116 should be right [15:56:27] hmm [15:56:36] not sure about the abort constants [15:56:48] I wonder where we would have got them anyway [15:56:54] for the PGNS that is [15:57:16] the Apollo 12 AGS abort constants are in the A12 activation checklist [15:59:28] And I also have the ones from the transcript [15:59:36] When they verified the padload onboard [15:59:42] After the lightning strike [15:59:47] https://archive.org/stream/apollo12landingd00miti#page/n23/mode/2up [15:59:59] ah [16:00:04] that's where we got the Apollo 12 LGC padload from [16:00:08] Yep [16:00:09] rcflyinghokie, the AGS padload? [16:00:11] so we did have them [16:00:12] Yes [16:00:43] They read up all of those numbers to verify [16:01:27] so, abort at 11 minutes is interesting for Apollo 12 [16:01:45] 092:01:36 Lind: Roger. Location 454, the value is plus 00700; location 466, plus 00150; location 506, plus 02400; 523 is plus all zeros; 527, plus 00500; location 537, plus 00002; location 560, plus all zeros; location 561, plus 02436; plus - or location 564, minus 46314; location 565, plus 40611; location 566, plus 01531; 601, minus 75341; location 602, plus all zeros; 622, plus 00062; location 634, plus 00100; 654, minus [16:01:45] 62655; location 655, plus 03467; 657, plus 00015; location 661, plus 00031; location 662, plus 53603; 666, plus 04140; location 672, plus 20053; that's the end of the list. [16:01:48] because that is close to the switch point for the two segments in the PGNS [16:01:52] So I remember now, in my late abort Apollo 12 test (the PDI+11 one) PGNS got me on a good trajectory to make the rendez-vous per the A12 timeline book /data card book [16:01:59] but not AGS [16:02:03] AGS doesn't have two segments [16:02:09] ah [16:02:18] so I wonder how that works procedure wise [16:02:46] And of course [16:02:47] 106:03:47 Carr: Intrepid, Houston. Looks good, break; your AGS abort constants in the checklists are good. Over. [16:02:47] but AGS has a value for the switch-over angle [16:02:55] or maybe thats just FP8 [16:03:37] oh, it does? [16:04:09] If you look at the A13 LM data card 305 is -01718 [16:04:28] that is the same as THETCRIT in the 131 padload I think [16:04:28] FP6 doesn't [16:04:38] but I bet FP7 did have that [16:05:10] so this explains it then [16:05:24] 0305 766316 12J DEC -.299904B3 # PHASE ANGLE LIMIT FOR RETARGET [16:05:33] but not for Apollo 12 yet [16:05:36] did Apollo 12 fly FP7? [16:08:28] however in the A12 activation check, there does not seem to be a value for the phase angle [16:08:52] Its basically the same AGS PAD format as Apollo 11 [16:08:52] hmm [16:09:09] if you compare with the A11 timeline book excerpts [16:09:19] they have the AGS PAD in there too [16:09:20] right [16:10:19] so how does the late AGS abort work then, hmm [16:11:32] Apollo 12 had FP6 [16:12:01] At least from what i could interpolate from the addresses used [16:12:07] yeah, makes sense [16:12:14] just not procedure wise to me yet, haha [16:13:14] although [16:13:20] the difference isn't that bad [16:13:58] probably would need a different Boost maneuver then or so [16:14:58] SIGNIFICANT CHANGES TO LM ( LUNAR MODULE ) abort AND rescue PLAN FROM MISSION G TO MISSION H-1 [16:15:02] I guess we need this [16:16:00] oh that would be good I guess [16:16:11] Ill request it [16:16:25] great [16:16:35] any others while Im at it? [16:16:53] wasnt there an Apollo 15 one? [16:18:00] OPERATIONAL LUNAR MODULE abort AND rescue PLAN FOR APOLLO 15 ( MISSION - J1 ) [16:18:10] OPERATIONAL LUNAR MODULE ( LM ) abort AND rescue PLAN FOR APOLLO 16 AND APOLLO 17 [16:18:25] let me check if we have Apollo 9 [16:18:37] yes, we have [16:18:45] ok [16:19:01] then there are a few preliminary documents that I don't like [16:19:28] that's it at UHCL [16:19:42] Ill request those 3 [16:20:36] checklist wise they have the Apollo 14 and 15 CSM Rescue Books [16:21:05] I guess eventually we should request that as well, although we know the procedures from the document we already have [16:28:12] rcflyinghokie, as I said to Alex earlier, the PGNS to AGS downlink was not too difficult to do, but it's having timing issues. [16:28:28] So I worked out a solution to run AGC and AEA cycles together [16:28:53] I remember you said timing would be an obstacle [16:28:53] it's not a very elegant solution though and even if it works without issues (Alex is testing) then I'll revisit it eventually [16:29:19] Would there be an easy way to compute the K factor for the V47? [16:29:23] yeah, initially the AGS was not reading data fast enough [16:29:27] request sent [16:29:33] it just barely worked well at 0.1x [16:30:00] so, how did they do that in reality [16:30:12] looked at LGC and AEA clock time on the downlink and compared? [16:30:16] Yes [16:30:39] Because the AEA input isnt as precise as the PGNS [16:31:02] There was room for error [16:31:11] and the K factor then is the X hours and a few 0.1 seconds, right? [16:31:17] Yes [16:31:19] which you load in V47 [16:31:22] Correct [16:31:37] Assures a more accurate SV [16:31:38] I actually implemented a new method for the AGC clock update that looked at the clock time in the erasable [16:31:58] so that would just look at the AEA as well [16:32:01] and compare [16:32:10] Seems simple enough [16:32:18] I can add something to the RTCC MFD [16:32:27] And MCC/RTCC can use that [16:32:27] shouldn't be too difficult [16:32:36] yeah [16:33:21] This Apollo 10 procedure by the way follows, for the most part, the flight plan nicely [16:33:58] I have only found one difference from it and the FP (I am only on DOI) and that is the LGC update included a target load in the FP and not in this procedure [16:34:20] The rest flows very smoothly and is way better than the old one in my opinion [16:34:28] great [16:34:49] I should have changes done to it today at some point, and then back to tanks [16:35:20] oh, I flew a bit more of Apollo 10, found a checklist typo [16:35:41] Apollo 10 CSM checklist [16:35:43] flightplan [16:36:26] line 681 [16:36:33] I think that line just has to be removed [16:36:33] That was a weird disconnect [16:36:50] I missed the typo though [16:36:59] Apollo 10 CSM checklist, Flightplan group [16:37:02] line 681 [16:37:08] probably has to be removed [16:37:22] because the next line is "rest period begins" as well [16:37:25] Haha yeah [16:37:26] but then with the correct time [16:37:31] Whats funny is excel opened to that line [16:37:37] BEcause that was the last change I made [16:37:39] service [16:37:50] so you already fixed that [16:38:01] Locally yes [16:38:05] right [16:38:26] so yeah, I am up to that last rest period in lunar orbit [16:38:39] 4x4 landmark trackings done [16:38:47] just a bit more of it after the rest [16:39:01] I will probably be flying 10 right on your heels to test the modified doi/phasing procedures [16:39:24] But I really want to solve this tank pressure [16:39:29] Its bothering me [16:41:52] then you can test the MCC real good, haha [16:41:58] My pleasure [16:45:55] back [16:46:14] I wanted to ask you something, Mike, but I forgot [16:46:21] ah [16:46:23] AEA clock [16:46:27] is that just address 377? [16:46:36] or is that more for I/O [16:47:16] so if I wanted to look at the actual current AEA time [16:47:23] which address do I have to check [16:51:43] Should be 377 [16:52:51] There is another address in there for the time bias [16:52:56] 670 [16:53:07] I think that is what it uses from V47 but I am not certain [16:53:22] hmm [16:54:25] But I dont think any other addresses relate directly to the AEA clock, other than maneuver time calculations [16:56:30] yeah Ryan is much better suited to AGS questions like that than me :P [16:56:57] seems like it :D [16:57:11] 670 seems to be used for entering data into 377 [16:57:22] but 377 should still have the right time [16:57:28] without taking 670 into account [16:57:55] lol that sounds not unlike N36 and N65 on the AGC [16:58:03] haha, yeah [16:58:22] what about 353 [16:58:23] TA2 [16:58:26] what is that [17:01:13] the programmed equations document has a list of descriptions for symbol names [17:01:14] http://www.ibiblio.org/apollo/Pultorak_files/FP6_AGS_ProgrammedEquations.pdf [17:01:31] it says TA1 and TA2 form "Present time (sec)" [17:04:12] by the way, when your stream of requests to UHCL dies down, I noticed they have a LM G&C Data Book [17:04:58] based on what I can find it should be about 400 pages filled with data useful to G&C, such as engine performance, moments of inertia as propellant load changes, stuff like that [17:05:13] may be worth requesting at some point [17:05:36] Have a link? [17:06:24] it's record number 208390 at UHCL [17:06:56] indy91 I dont know 353 [17:07:09] page count estimate comes from how many folders it occupies at VT, and contents guesses come from various things that reference it :P [17:07:25] so are TA1 and TA2 together the double precision time? [17:07:36] that's what I'm thinking, but it's not super clear [17:08:03] TA1 alone already seems to be in millseconds [17:09:45] "Most significant half of the double precision AGS absolute time" [17:10:03] I think thats 353 [17:10:16] hmm [17:10:19] It is in seconds [17:10:53] Thats in the TM stream though [17:10:56] I'm looking at TA1 in a debug string [17:11:00] definitely not enough [17:12:53] TA2 doesn't seem to change at all [17:14:34] TA1 gets incremented by 1 bit every 2 seconds [17:14:51] Yeah thats the time computational cycle [17:14:57] updated every 2 seconds [17:15:13] Look at the programmed equations doc [17:15:17] pdf 13 [17:15:29] That might help it explains the two parts [17:17:00] 20ms and 40 ms computations as well as 2 sec computations [17:23:59] so both TA1 and TA2 are on telemetry [17:24:06] but I don't really understand it [17:24:46] That LM Data book is from 67 [17:25:03] Might be a little old [17:26:28] They both are? [17:27:11] I get the feeling that TA2 is mostly stored as a reference time [17:27:21] only TA1 is updated, every 2 seconds [17:27:39] but for any calculation that needs an accurate reference time TA1 and 2 are used together [17:27:42] And that would correspond to the 377 update of 2 seconds [17:27:54] so the AGS doesn't keep a precise current time [17:28:05] what a weird computer [17:28:21] it does these 20ms/40ms/2s cycles with counters I guess [17:30:02] Yeah that is interesting [17:30:11] It explains it but I dont understand it haha [17:30:51] I cannot seem to find much else on TA2 [17:31:02] so on telemetry they would maybe have to check for the exact moment that TA1 changes [17:31:15] indy91, I am noticing something odd between my normal repo and your testing branch [17:31:18] and at that instance TA1 and TA2 together are the current time [17:31:52] I dont know if it is related to the changes though, or something different between the settings of my 2 orbiter installations [17:32:04] Is that what is carried on TM word 43? [17:32:09] but there is a difference in frame rate [17:32:29] Alex, did you do the alias thing? [17:32:36] yes [17:32:43] I had trouble with framerates doing that [17:32:52] oh really [17:32:57] word 43 is TA1 (377) [17:33:18] word 23 is TA2 (353) [17:33:19] ok Ill have to test it again then after pysically moving the files [17:33:19] Yeah I dont know why I never looked into it, I just ended up making another copy of the texture files [17:33:34] Also check you are building in release :P [17:33:41] yeah [17:33:54] indy91 oh I see [17:34:06] rcflyinghokie1, what setting do you have for anti aliasing? [17:34:09] That is weird [17:34:19] I think I have it maxed out [17:34:23] ok [17:34:33] and when did you have issues with framerate? [17:34:47] When I first installed the beta [17:34:50] And used the alias thing [17:35:01] But they were on 2 different drives I thought that was why [17:37:03] ok, I don't really understand TA2 [17:37:13] if it only changes on input for 377 [17:37:18] shouldn't it be 0 or so? [17:38:57] but maybe that is the time into a computer cycle (2s) that you pressed ENTR [17:38:59] or so [17:41:18] so uhh, at this point, no idea how to get accurate, current AEA time [17:42:34] hmm ok so the textures are not responsible for the frame rate drop [17:43:06] its weird because my settings are identical between the 2 installations [17:43:48] the frame rates drop is during time accel, when I go to 30 x inside the LM or CSM panel, frame rates drop from 60 to about 20 [17:44:02] in my normal installation that does not happen [17:45:07] indy91 did you say TA2 was not changing in the debug line?> [17:45:36] AlexB_88, pretty sure I know what is doing this [17:45:55] it's my solution for doing the PGNS and AGS timesteps close together [17:46:08] I guess that confirms my doubts about it, haha [17:46:26] rcflyinghokie1, TA2 is only changing when I enter a new time into 377 [17:46:49] AlexB_88, so unfortunately that means, I have to rethink the solution [17:47:31] Because usually 30x time accel is no issue lol [17:47:58] indy91, could that be a delta to keep track of the precise time? [17:48:08] maybe it would drop a few fps when in the LM panel with both AGS and PGNS running, but not by half [17:48:31] rcflyinghokie1, what I am thinking is this [17:48:42] AEA starts doing cycles once you turn it on [17:49:35] when you enter a new time into 377, it stores the current time into a 2 second cycle in 353, to keep it as a time reference [17:50:11] I wonder if 353 is 0 on initial AEA activation [17:50:42] AlexB_88, there is no easy fix, I will have to use a completely new solution [17:51:36] can you confirm you get a fps drop in 30x time accel as well? [17:51:45] inside the LM panel [17:51:59] it doesnt happen in outside view [17:52:31] ah, yeah, I'll check [17:52:41] outside view has a significant better framerate usually [17:52:45] our panels are bad [17:52:52] really bad, especially the CSM main one [17:53:16] and it doesnt happen at 10x either [17:53:34] I am wondering if it may be a necessary evil, so to speak? [17:53:51] yeah, in my solution, it will get significant worse with higher time acceleration [17:53:55] I knew this could be case [17:54:02] no, I'll use another solution [17:54:08] ok [17:54:25] I can push a version that only has the PGNS to AGS downlink [17:54:33] just have to use 0.1x for now [17:54:39] should be quite reliable [17:54:53] sure [17:55:09] I would need to annotate that in the checklists though for any V47 [17:55:24] well its only temporary [17:55:45] Ok [17:56:12] not to put any pressure on you Niklas haha [17:56:15] get the same frame rate issue [17:56:29] rcflyinghokie1, well your current checklist solution is even worse :P [17:56:43] I'm pretty sure it already has the 414+1, right? [17:57:01] Yeah it is the proper procedure [17:57:07] that is a bad thing to do when then the AGS isn't receiving anything [17:57:15] you have to reset it by another procedure [17:57:27] 560+1 or so [17:57:36] I guess I always just ignored the AGS update haha [17:57:55] And just entered the SV whenever that came up [17:59:08] right [17:59:16] checklists can stay as they are [18:00:09] I forgot the recovery procedure [18:00:13] can't find the right one [18:01:56] but in any case, don't do the 414+1 right now, haha [18:02:24] No problem :) [18:08:32] oh and I have another minor bug report unrelated to the downlink [18:09:20] uhh [18:09:36] I even get the framerate issue without the computer timestep [18:10:01] already reverted that though, haha [18:10:17] I don't see how it can be the PGNS to AGS downlink though [18:10:22] I have noticed this for a while now but if you have the DEDA displaying something when you save a scenario (say 433) When you reload that scenario, the DEDA display is wrong [18:10:57] AlexB_88, ah, thanks, that should be easy to test and fix [18:11:06] say 433 velocity will read a wrong value and then simply clearing and re-entering 433R fixes that [18:11:08] maybe something isn't saved [18:11:13] right [18:11:25] wait, the address is wrong or the data register? [18:11:42] the data is wong [18:11:46] wrong* [18:13:12] during a readout [18:13:20] does it still update? [18:13:25] yes [18:14:12] but wrong numbers [18:14:24] yes [18:14:34] hmm it updates but not at the same rate [18:15:20] ok you can see the issue in the Apollo 11 PDI demo scenario [18:15:42] I get a bad framerate on the LM main panel even in the Orbiter2016 branch [18:15:46] starting at 30x [18:16:00] it already has 433 loaded, but the value is like 5330 or something, should be 5550 and counting [18:16:15] and when you reload 433, then its ok [18:16:51] did you get the bad frame rate before the AGS downlink changes? [18:17:09] oh in the Orbiter2016 branch [18:17:12] I get that DEDA issue as well [18:17:22] I have noticed it a lot with quicksaving with 500R [18:17:27] so thats without the downlink stiff [18:17:32] yes, without it [18:17:38] hmm [18:17:42] Usually I can clear and reload [18:17:45] so it must be a setting on my end [18:18:05] are you sure you are not getting that issue in the Orbiter2016 branch? [18:18:08] when did you test? [18:18:16] no not at all [18:18:23] panel elements shouldn't cause that [18:18:40] indy91, also I noticed something in this DOI procedure, it leaves throttle in auto, yet it says at 15s throttle up to 40 [18:18:43] they are simply updated at framerate [18:19:23] manual is added to auto thrust [18:19:38] Oh [18:19:40] Ok [18:20:07] AlexB_88, when did you test the framerate of the LM panel in the Orbiter2016 branch? [18:20:22] So even in auto, moving the throttle to 40 will advance it to 40 [18:20:32] yes [18:20:37] I never knew that [18:20:48] And it says this DOI burn lasts 27.5 seconds [18:20:59] indy91, just an hour ago or so as I was testing the same conditions between the Orbiter 2016 branch and the testing branch [18:21:01] LGC will never throttle up [18:21:14] Because of the manual throttling? [18:21:21] because of the burn length [18:21:23] with the exact same scenario too [18:21:29] Oh ok [18:21:30] I only recently learned that [18:21:35] it does a check pre ignition [18:21:38] That explains a lot of these procedures then haha thanks [18:21:46] check on 95 seconds burntime at 10% [18:21:55] if it is below that, it sets a flag [18:22:00] and never throttles up at 26s [18:22:44] that 95 seconds would translate to a 26 second burn at 10%, then 6.9 seconds at 100% [18:23:52] rcflyinghokie1, can you test a powered up LM scenario from inside the panel and see if you get a frame-rate drop? [18:24:00] at 30x that is [18:25:18] In the current build? [18:26:30] Orbiter 2016 branch [18:27:24] oh, something is bad [18:27:35] at 50x I even get a low framerate in the outside view [18:27:41] like, less than 10 frames [18:28:22] main branch? [18:28:26] yes [18:29:10] I stay at 60 fps inside and out in the main branch [18:29:36] what scenario? [18:30:42] if I use multithreading for the Virtual AGC then it doesn't happen [18:30:46] do you have that enabled? [18:30:55] yes [18:31:04] in the main and testing branch [18:31:07] ok [18:31:19] so thats what caused your frame drop? [18:31:24] yes [18:31:32] forgot I had that disabled [18:31:43] and can you test if you get that with the AGS changes? [18:32:01] I will [18:32:14] I am fine with 30x [18:32:28] Other than the pressure fluctuations [18:32:29] my timestep change definitely was messing with the multi threading [18:33:03] in the commit with the computer timestep [18:33:16] ah, yeah [18:33:19] that will have been it [18:35:58] no framerate issues [18:36:08] in the testing branch [18:36:21] at the most recent commit, which had reverted the computer timestep change [18:36:26] but still has the PGNS to AGS downlink [18:36:37] I'll test the previous commit as well [18:36:42] but that will have been it [18:37:37] I have to run out, take it easy! [18:39:24] yep, framerate drop [18:39:52] I have an email from Lauren [18:40:05] so I just need to find a better solution for this PGNS/AGS sync [18:40:05] she is quick these days [18:40:46] yeah :D [18:40:52] https://www.dropbox.com/sh/w0um2knc8e665ix/AADFnaM30N_U1CvJ31shDMmta?dl=0 [18:41:40] oooh [18:41:42] look at that [18:41:49] in the change document from G to H-1 [18:41:53] talking about the AGS [18:42:03] just as we hoped [18:43:10] says exactly what we were looking for in the first paragraph [18:43:12] perfect [18:43:36] so indeed a procedure difference between PGNS and AGS abort after PDI+10 minutes [18:44:48] nice [18:46:43] ah, all these documents are small [18:47:00] because they mostly consider cases that are changed from previous missions [18:47:39] hmm [18:47:48] the Apollo 16/17 seems incomplete though [18:47:50] only 6 pages [18:48:28] but the same was the case with the SCOTs [18:48:32] most were incomplete [18:48:44] so it's likely that they don't have the complete document [18:52:27] bummer [18:53:23] we seem to be able to calculate most of the 16/17 maneuvers already though [18:54:43] yeah [18:59:22] I guess I first have to research now how the multi threading works [18:59:30] before I can find a new solution for the timesteps [19:13:17] probably should implement the long term solution I was talking about [19:13:37] right [19:13:58] which will make it possible to implement the Virtual AGC counter simulation [19:14:02] thats the necessary evil :p [19:14:03] so Mike should be happy :D [19:14:20] yeah, better necessary evil than a bad framerate, haha [19:14:34] yeah [19:15:02] maybe end up fixing the LR velocity issues too [19:16:45] I guess the CSM will need that vAGC counters upgrade too? [19:17:17] yeah, IMUs will only properly work through CDUs then [19:17:23] or I guess both would have to be upgraded hand in hand [19:21:55] so yes, both [19:22:55] have some stuff to do, cya! [19:35:12] hi alex [19:35:48] so right after landing there is an alignment with a bunch of marks and i am wondering do i have to mark more than one star? [19:36:22] @AlexB_88 my results were 00146 [19:42:23] hey [19:42:45] it depends on the procedure, some of them you have to mark on more then one star [19:43:03] I have to go cya! [12:16:06] hey [12:17:17] indy91, when you have a chance, take a look at page 1 of the Apollo 12 rendezvous abort book ;) [12:18:17] ah [12:18:20] that explains it [12:18:23] good morning [12:18:24] well [12:18:28] now we know what that chart is for [12:18:29] hey [12:18:44] having slight problems with the p57 [12:19:10] should i use more then one star if so how many? [12:19:24] we all have slight problems with P57 stil [12:19:26] still* [12:19:47] the checklist should say which and how many stars to use [12:21:45] the surface checklist at least says how many P57s are done and when to recycle etc. [12:23:13] also, on Apollo 12 the HAM maneuver seems to be referred to as "CSI1" [12:23:31] and then the actual CSI "CSI2" [12:25:26] yeah, there is a procedure using P32 and a chart to get the HAM DV [12:25:35] I guess that's why it is called that way [12:26:03] yeah [12:26:33] it is 6 marks does that mean six different stars? [12:27:03] I'm not sure [12:27:14] where are you in the checklist? What is the GET? [12:27:28] its the first p57 after landing [12:27:34] ok [12:29:42] in the actual checklist document it looks like marks on two stars with 2 recycles each [12:29:48] so that would add up to 6 marks [12:38:32] I've progressed through all those landmark trackings and am finally at the Apollo 10 TEI [12:40:32] On your MCC test run I guess? [12:40:37] yes [12:40:43] fixing things along the way [13:05:35] I guess I am go for TEI [13:40:35] How are the TEI DVs? no large out of plane component? [13:41:46] not super large, no [13:41:56] +187.6 [13:42:06] oh thats quite low [13:42:16] Apollo 13 seemed to be quite low too [13:42:41] But its probably the most favorable of all the launch windows lol [13:42:52] LOI DVY was like 50 fps [13:43:38] so, the initial guess for the TEI calculation is using the CSM state vector at ignition, but in Earth referenced coordinates [13:43:50] and that kind of defines the plane in which the TEI solution will be [13:44:07] so for favourable trajectories like Apollo 10 and Apollo 13 apparently that will lead to low DVY [13:44:20] but for other cases it's much higher [13:44:31] it all depends on the initial guess and there is no optimization of it [13:45:43] right [13:45:47] so it's kind of random, but it will be quite good when the DVY is low anyway [13:47:11] Apollo 10 is coming home [13:47:19] flying the TEC shouldn't take too long [13:47:28] and I doubt there is going to be much to fix with the MCC [14:10:43] Any ideas so far for the LGC/AEA timestep issue? [14:12:13] no, not really [14:12:21] well, I have an idea how it could be done [14:12:25] just requires a lot of changes [14:13:39] the LGC/AEA in a single loop thing? [14:16:25] yes [14:19:02] I have found a few threads on the forums relating to the multi-threading implementation: [14:19:02] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1681.0 [14:19:10] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2170.0 [14:19:20] dont know if that can offer any clues [14:41:49] it probably make sense to have a thread with the computer timestep instead of the LGC one [14:41:52] makes* [14:45:40] yeah [14:45:55] just tried that 0.1x downlink... geez thats long :D [14:46:38] probably quicker just to do a manual one lol [14:47:26] I looked at the debug string, about 1 out of 10 AGS updates might be successful [14:47:32] so you just have to repeat it a bunch of times :D [14:47:38] probably not any less annoying... [14:50:17] haha Ill take the 0.1x option [14:57:46] Good morning [14:58:25] hey [15:01:02] Whats up? [15:02:36] well Lauren replied last night with the 3 docs I requested [15:02:37] https://www.dropbox.com/sh/w0um2knc8e665ix/AADFnaM30N_U1CvJ31shDMmta?dl=0 [15:03:25] And the Apollo 12 rendezvous changes notice confirms the behavior of late AGS aborts [15:03:25] Anything helpful? [15:03:30] Ah great [15:03:40] So the padloads work properly :) [15:03:54] Basically PGNS was loaded with the 2 segment abort, but not AGS [15:04:19] and if you did a late abort with AGS, you have to do a tweak burn at insertion + 2minutes [15:04:37] and there is a chart for that burn in the Apollo 12 rendezvous/abort book [15:04:59] Makes sense [15:05:55] so yeah padloads are all good [15:06:25] I think I will test a late AGS abort on 12 right now [15:06:34] and use the chart to fly the tweak [15:07:17] indy91, I guess the DKI could also be used to calculate the tweak in that case, it seems to be only a VGX burn [15:07:47] which the sets you up for the BOOST/CSI-1(HAM)/ CSI-2 [15:11:08] morning! [15:11:54] hey Mike [15:14:47] so, I was thinking... until the timestep is massively rearranged, we could make the AGS initialization more reliable by queuing up downlink words from the AGC and just feeding them into the AGS as it becomes ready for them [15:27:14] yeah, we'll need something along those lines as yesterday's LGC/AEA timestep experiment makes the frame-rate drop above 10x time accel [16:12:32] rcflyinghokie, I don't really like commiting these propellant tanks [16:12:45] we haven't even decided if we want to use them at all [16:12:46] I didnt want to add them [16:12:54] well, why did you then? :P [16:13:06] They were already pushed before the checklist changes [16:13:14] I didnt know how to just PR the checklists [16:13:41] by thinking ahead and making a development branch for the tank stuff [16:13:53] I also forget that too often [16:14:08] Haha I thought it would be straight forward :P [16:14:32] if we are consequent then any new features gets a development branch [16:14:38] I still am baffled as to how it computes a liquid pressure [16:14:44] nothing new directly in the Orbiter2016 branch except for minor bug fixes [16:15:16] but I also rarely do that, so who am I to expect that from others :D [16:15:48] ah, you closed it [16:15:52] I closed the PR [16:16:34] Is there a way I can revert my orbiter 2016 branch to that of the repo [16:16:58] so one thing you could do is copy the tanks into some other file, commit the reverted file, make a new development branch and copy the tanks back in [16:17:40] if you just reverted to the main repo state then you would loose your changes [16:17:56] your PR was ok to be merged, just not those tanks in the config [16:17:58] I just put my changes and current state in a new branch [16:18:16] But yeah I will fix the PR without the config changes [16:18:32] thanks [16:18:55] these new substances and them being liquid has really not been tested enough [16:21:32] thewonderidiot, your idea might work [16:21:49] just has to take into account that the register is getting flooded with the downlink all the time [16:23:53] indy91 ok the other changes are reverted [16:24:13] Well the substances by themselves behave properly [16:24:23] Its the liquid/gas mixing that has me confused [16:24:34] right [16:24:39] And I still cannot find how it computes pressure for a liquid in a tank [16:24:45] and there is no problem with adding new substances of course [16:25:16] merged [16:25:26] I hope the reverting didn't cause too much trouble [16:25:27] Ok now back to my dev branch :P [16:25:29] haha [16:25:34] Oh no it was easy [16:25:48] And my dev branch has the state before I reverted [16:27:12] Yep checked out just fine [16:27:33] back in a bit [16:28:06] indy91 do you have a save before Apollo 10 undocking? I would like to briefly test the phasing checklist changes [16:28:16] I have, sure [16:28:39] just flew Apollo 10 TEI today actually [16:28:49] and did MCC fixes along the way [16:29:01] Any checklist issues to report? [16:29:07] one very minor thing [16:29:14] there was a roll to 0° missing somewhere [16:29:16] let me check [16:30:52] Apollo 10 CSM checklist [16:30:53] flightplan [16:31:02] line 704 [16:31:09] well let me merge first [16:31:42] line 703 now :D [16:31:48] pitch to ORDEAL 338° [16:31:53] Yep I am there [16:32:05] Needs a roll 0? [16:32:14] you are at 180° roll at that point and the flight plan wants a roll to 0°, yes [16:32:32] it is followed by two p22 which need it [16:32:35] P22* [16:33:03] So "Roll 0° Pitch to ORDEAL P=338°" [16:33:30] yes [16:33:37] "R 000° and go orb rate 338° ORDEAL (heads up)" is the exact quote [16:34:11] I will test the checklist changes and then PR any fixes to that plus this after [16:34:41] But yeah as I said, the flow seems so much better and less congested in the revised version [16:34:48] And no P63 [16:34:53] yeah [16:35:13] Lots of frivolous steps were removed [16:36:04] The only thing that struck me as unusual is there is no mention of the asc eca cont cb when switching off the asc bats [16:36:16] Unless the apollo 10 undocking checklist had those closed [16:36:24] checklist starts just after undocking? [16:36:30] Just before [16:36:33] ok [16:36:43] my "before undocking" scenario is an hour before undocking, let me find a better one :D [16:36:51] Haha if not I can use that one [16:37:25] the scenario are older than a bunch of your checklist revisions, so you'll have to click yourself to the right point [16:37:34] the scenario at 97h was still at 94h in the checklist [16:37:40] Yeah I am used to doing that :P [16:37:46] I can imagine [16:39:02] But yeah I wonder why the phasing/doi checklist omitted those breakers [16:39:27] maybe it has them closed all the time? [16:39:48] https://www.dropbox.com/s/5k5uvi04q1ty8vt/Apollo%2010%20MCC%20-%20Before%20Undocking%200001.scn?dl=0 [16:40:02] I was thinking that, but the rendezvous checklist has them closed after activating the bats before insertion [16:40:16] that mission is about 15 minutes behind in the flight plan [16:40:20] unless it was a verify [16:40:27] I need to check that [16:40:28] so just do all the steps 15 minutes later than the checklist wants you to :D [16:40:32] No problem [16:43:31] I take that back the insertion checklist does not mention the batteries so I must have added that based on the ascent battery activation from the flight plan [16:43:40] So maybe they are always closed for this mission [16:44:40] That seems like a reasonable assumption [16:45:09] indy91: if the AGS is running at the right rate the queue should never overflow [16:45:16] if it does then the speed of something is off [16:46:17] well, the downlink will write to the register all the time [16:46:26] but the AGS is normally not reading it [16:46:33] so it's not resetting the discrete [16:46:55] I need this [16:46:56] https://historical.ha.com/itm/explorers/space-exploration/apollo-10-lunar-module-flown-lm-systems-activation-checklist-signed-by-and-from-the-personal-collection-of-mission-lunar-modul/a/6007-41016.s [16:46:57] so when does the queue start, if you know what I mean [16:50:21] I guess your concept is that the downlink isn't directly written into the register, but into a queue [16:50:42] and whenever the AGS is reading from it, it's removing one word from the queue [16:51:44] CH34 should only be written to once during a downrupt [16:51:51] which should only happen at 50Hz or whatever [16:52:20] oh [16:52:26] nevermind I get it now [16:59:04] yeah, for some reasons that is not good enough at fairly stable 60fps [17:01:11] Hmm another thing that must have been added is the closing of the inverter 1 breaker before DOI [17:01:22] That is not in my checklist but it is in the transcript [17:03:30] yeah, we can hardly expect a February procedures document and a May flown checklist to be identical [17:03:50] not in these early Apollo days at least :D [17:04:28] I am adding the inverter breaker [17:04:42] It was closed before both phasing and DOI [17:06:09] So was AELD [17:06:18] And abort stage [17:06:31] Quite important those be in there I inagine [17:07:00] yeah, without the AELD breakers the APS can't start [17:07:05] I cannot tell if AELD and abort stage were closed before the DOI [17:07:15] But they call it out before phasing burn [17:09:18] Were the ALED breakers redundant? [17:09:20] AELD [17:10:56] Looks like they closed them both [17:11:00] yes and no [17:11:09] it's a bit weird [17:12:04] procedure wise they are redundant [17:12:11] you would usually close both [17:12:23] and if one fails you still have the ability to start the APS [17:13:09] the AOH circuit breaker page says [17:13:18] "loss of engine on signal to ED sys B" [17:13:30] if the AELD breaker on panel 16 isn't powered [17:13:50] Based on the verbal flow, both were closed [17:13:52] same on panel 11 for ED system A [17:14:01] yeah, you would always have both closed [17:14:08] And what about abort stage? cb? [17:14:17] Probably both closed as well [17:15:07] yes [17:15:14] but I think the panel 16 one has more functionality [17:15:38] They are very clear about those for phasing but not for DOI [17:15:48] So I think they might have just been left open for DOI [17:15:55] could be [17:16:01] But they close inverter 1 for DOI [17:16:07] probably depends on the backup procedure for those burns [17:16:18] problem during DOI, let CSM rescue you [17:16:25] problem during phasing burn, try the ascent stage [17:16:27] maybe [17:16:29] That is done in case staging has to be done [17:16:45] yeah, that is definitely staging preparations [17:16:57] So I wonder why AELD and abort stage were not mentioned haha [17:17:09] But again they are very clearly mentioned in the phasing burn [17:17:15] and inverter one in both [17:18:04] well that is my theory, the didn't close those for DOI [17:18:11] because different procedure [17:18:30] reading through some documents, they wouldn't have simply backed up DOI with the APS [17:18:37] they would have flown a different rendezvous [17:18:49] probably too long on ascent stage batteries alone [17:19:04] but for phasing they might have just finished the burn [17:19:09] or done it completely with the APS [17:19:21] Ah that makes sense [17:19:38] really interesting procedures [17:19:51] the staging before DOI would be done 15 minutes before DOI [17:19:59] and same procedure with the 2 ft/s back and forth [17:20:08] DOI only to 40NM pericynthion [17:20:16] and I guess a one rev rendezvous [17:20:22] and not insertion/CSI etc. [17:21:20] yeah [17:21:27] so that is a completely different profile [17:21:38] so they wouldn't have finished DOI on the APS [17:21:46] hence no need to be prepared for a FITH [17:22:26] also no urgency [17:22:34] without DOI, the LM will simply arrive back at the CSM [17:22:35] Ok that all lines up then [17:22:43] Haha similar to Apollo 16 [17:22:45] football shaped orbit [17:22:52] or Apollo 9 [17:22:53] Though without PDI [17:23:05] Ah yeah the mini football that had me confused for a bit [17:23:45] which one? Apollo 9? [17:24:12] it's done on every lunar mission as well, sep burn being radially down or up [17:25:02] Yeah the Apollo 9 confused me [17:25:37] Back when I was still grasping the mechanics of a rendezvous [17:26:06] Ok I added the AELD, INV1 and Abort Stage breakers to phasing [17:26:09] Now to try the scn [17:28:21] And without evidence to the contrary I think I will ad the asc eca cont cb to the undocking cb configuration [17:32:06] Well I will try this later, real life calls, take care! [17:47:00] Orbiter 2016 is great. I can watch the onboard videos of the Moon from Apollo 10 and I recognize when I did the same maneuvers and had the same view. [17:52:40] :D [18:01:22] thewonderidiot, so back to your idea with the PGNS/AGS [18:01:36] a queue [18:02:31] back [18:03:30] yeah [18:03:44] doesn't work quite as well since AGS isn't always sampling it [18:03:51] yeah [18:03:57] but, the queue should theoretically only need to be 2-3 deep [18:04:21] so if you just keep the queue filled with the 3 latest, and let the AGS pop off the front if it wants to [18:04:29] it should all work out [18:04:41] yeah, having looked at the number of skipped downlink words, it wasn't more than 2 per second, sometimes a few seconds without issues at 1X [18:04:48] just, delayed by 60ms, which may or may not matter [18:08:33] this will need a aea [18:08:38] aea_engine change [18:08:54] when it's reading from the register [18:28:07] why? [18:28:49] or are you reaching into it for your debug string? [18:29:05] the debug string has all the info you need [18:29:17] in its timestep loop, check to see if the stop bit has been reset [18:29:23] if so, pop something off the queue and set it again [18:29:36] assuming the queue isn't empty [18:30:03] oh, you mean checking for the bit in the AEA timestep [18:30:22] after the cycles [18:30:29] yeah [18:30:49] during the cycles, even [18:31:44] right [18:33:35] I can even bypass writing any additional data to the queue [18:33:51] because if the AEA isn't reading from the register, writing new data isn't important [18:55:25] yeah [19:42:40] is this queue method of feeding the AGS data something that is easy to realize? [19:45:44] easier than any timestep madness, yes [19:45:59] haha [19:46:34] maybe the timesteps thing is better suited for NASSP 9 [19:47:30] or 8.1 or so [20:02:25] night! [20:02:54] good night [06:53:17] .tell indy91 I did a bit of profiling with the standalone yaAGS last night. it's not a representative load so the timing may not be the same as in NASSP. I set it up to print out total stop bit checks each second, with min and max time between two checks during that second [06:53:41] .tell indy91 the output is very consitent, with an example line being "100 samples, min=2.036ms, max=17.973ms" [07:02:04] .tell indy91 1/0.017973s = 55.639Hz, so if you're going at 60Hz some frames not checking the stop bit makes sense. [07:04:20] .tell indy91 the timing on FP6 and FP8 appears to be identical [11:53:28] hey [11:55:12] hey [11:55:15] yeah, I don't have much luck with this [11:55:40] hey [11:56:04] just took a break from nassp and i am gonna try the p57 again [12:17:04] AlexB_88, flying more Apollo 10 and am trying P23s [12:17:09] star/lunar landmark [12:17:36] it takes a bit of map knowledge and searching, but it's possible to find the craters that are used as landmark [12:19:19] so that works quite well thanks to Orbiter 2016 [12:26:26] nice [12:27:11] Probably easier then TLC/TEC P23s lol [12:28:24] you mean the horizon marks [12:28:30] I am in TEC [12:29:27] the landmark option (Earth or Moon) usually results in higher accuracy for us [12:32:14] I don't think I ever tried the lunar landmark option before though, especially not in Orbiter 2016 [12:33:10] ah I see [12:33:57] yeah I remember doing Earth landmark/star P23s a while back [12:35:26] and it did work better (using landmarks that were on a certain latitude that agreed with pisher ellipsoid) [12:36:46] no ellipsoid issues with the Moon, haha [12:36:55] and I wasn't even targeting any marker [12:37:08] just used the landmark coordinates in the flight plan [12:37:14] and found the right crater [12:37:20] there was a great map in the AFJ [12:37:25] https://history.nasa.gov/afj/ap10fj/pics/cislunar-landmarks.jpg [12:37:39] first P23 is on Taruntius P [12:38:10] I had to search a bit but then I found this cluster of craters, Taruntius G/H/K/P [12:40:15] What should work too, although I have never had much success is lunar horizon/star [12:41:56] I would imagine it being more accurate than with the Earth [12:42:02] because no atmosphere [12:42:57] what I still struggle with is a best practice for roll angle during the mark [12:43:29] and the moon is the same shape in Orbiter as in the CMC [12:43:30] during the P23* [12:43:48] should you always try to align the CSM in roll so that you can move the sextant up and down? [12:43:56] yes, Moon radius for the P23 should be mean radius [12:44:00] which is identical [12:44:57] I always used to align the CSM in roll yes [12:45:16] makes it so much easier [12:45:33] I dont know if that is proper procedure though [12:50:06] btw I flew the AGS late abort on Apollo 12 [12:51:19] used the tweak chart at insertion (42.7 fps) and that agreed very closely to a DKI solution [12:52:10] and I am flying the whole thing using AGS for the 1st time [12:52:46] fun, I have yet to do that [12:55:27] I kept the initial downlink testing branch in my 2nd Orbiter installation. Being able to do the V47s make the whole thing pretty seamless [12:56:10] I just make sure not to go over 10x time accel lol [13:10:20] but you tested that a lot now and it's definitely updating the AGS properly? [13:11:45] yes [13:11:56] its just the fps issue above 10x [13:12:46] ok, so then we know for sure now that it's working right [13:12:51] just the timing issue [13:13:01] yeah [13:13:02] I tried the queue method but without much success so far [13:14:06] the AGS late abort I flew was following an V47 pre-PDI, the full descent and AGS abort/insertion at PDI+11 minutes [13:14:46] and the AGS was still showing a very good state vector after insertion [13:15:45] then I flew the tweak/CSI-1/CSI-2 with the AGS external dv function and that worked very well [13:17:10] great [13:17:52] one thing that I am curious about in the procedures is the 417+1 "initialize radar filter" that is called after insertion [13:18:23] but it doesnt say then to actually do the manual RR marks into the AGS [13:19:11] in the Apollo 12 insertion/rendezvous procedures [13:19:19] 417+1 is like V93 [13:19:21] I think [13:19:42] and manual marks are only ever done if the PGNS is completely unavailable [13:19:43] I think [13:19:49] right [13:20:26] not sure if it does anything with the radar filter on a V47 [13:20:46] V47 is only done once, a few minutes after insertion [13:21:14] so the sate vector in the AGS surely isnt left to drift through the rest of the rendez-vous maneuver? [13:22:10] unless somehow the AGS is reading the radar data [13:23:08] no, it can't. just via manual updates into the DEDA or with a V47 [13:23:23] yeah, thats what I thought [13:24:07] I just find it weird that they would do a V47 after insertion, but not anywhere else (like after CSI,CDH,TPI) [13:25:16] Looks like they did that on Apollo 14 [13:25:28] more frequent V47s [13:26:26] depends on what the procedure is for [13:26:34] is that the nominal rendezvous procedures? [13:27:02] yeah [13:28:59] LM Rendezvous Procedures document for Apollo 11 has full AGS procedures [13:29:26] oh wait a minute [13:29:33] are the procedures doing any 415+1? [13:30:20] not in the nominal Apollo 12 ascent timeline [13:30:26] just the 417+1 a few times [13:30:58] but then you would think it would say 415+1 followed by the manual marks and such [13:32:31] maybe the V47s are implied to be done at convenient times [13:32:46] the full Apollo 11 procedures have them a few times [13:32:53] after insertion and at CSI-7 minutes [13:33:38] right [13:33:39] and again at CDH-7 minutes [13:33:49] so maybe it just isn't in this checklist [13:33:52] do they have the 417+1? [13:34:56] I don't see it, no [13:35:03] in the AGS procedures though [13:37:58] the Apollo 11 and 12 rendezvous procedures documents probably won't be very different from another [13:38:19] UHCL doesn't have the document for Apollo 12 [13:38:44] but for Apollo 14, 16 and 17 [13:38:52] and CSM one for Apollo 16 [13:39:15] ah, we of course already have the LM one for Apollo 16/17 [13:43:17] well we have the time line book rendezvous procedures for 12,14,15,16,17 [13:43:31] oh and now 11 too [13:44:40] yeah, but the Rendezvous Procedures documents have actually all switch settings for the guidance system [13:44:43] more details [13:45:40] right [13:46:01] and full AGS procedures [15:12:25] morning! [15:38:52] hey [16:11:39] quick question on P34... Should you re-enter your initial pad TPI time when entering P34? [16:11:48] Or just use the time that is presented [16:13:13] ah yes, it says to re-enter it in the Apollo 11 rendez-vous procedures doc [16:14:41] hmm, why though [16:15:03] isn't the initial guess calculated in P33 better? [16:16:09] maybe timeline-wise you want to start with the planned TIG [16:46:40] I seem to notice that the downlink works better with bit rate set to high [16:47:55] lol [16:48:10] LGC downlink doesn't work at all in low bitrate [16:48:40] uugh [16:48:42] haha [16:48:47] V47 checklist always wants that [16:51:23] my LM-1 learned this the hard way [16:51:41] during the long DPS burn the DAP is set off for a bunch of seconds [16:51:50] and it's sending special stuff on downlink during that time [16:52:02] and I think it was a downrupt that made the normal sequence continue [16:52:10] no downrupt, LM spins out of control [16:52:17] I had the switch in low [16:52:33] hehehe that was a fun one to debug [16:52:40] Sunburst had the best problems :D [16:52:59] yeah [17:01:57] indy91, any luck with the ags initialization queue? [17:02:09] since it's reading 100 times per second it will catch up with the queue very quickly [17:02:51] just wanted to write about that [17:03:08] AEA is reading 100 times per second? [17:03:15] yep [17:03:40] and every single second there is 2.03ms between the two closest readings, and 17.3ms between the two furthest apart ones [17:04:04] that is within specification, good :D [17:04:09] but the LGC only sends 50 words per second [17:04:11] I didn't dig further into what the distribution was there [17:04:12] yeah [17:04:18] so how does that work [17:04:35] but 17.3ms is slower than 60Hz framerate which explains the drops [17:04:39] when the AEA reads the register it resets the bit [17:04:58] so, how I was checking this was just setting the bit as quickly as I could and logging when it was reset [17:05:02] and then it will on average only find something new in the register every other time? [17:05:13] yep [17:06:02] so it will read the register, despite the bit being reset, and just reset the bit again [17:06:19] and not use anything it found, because it can't have been anything new [17:06:25] the bit being reset is a byproduct of checking the register, the code isn't explicitly doing that [17:06:34] yeah [17:06:45] so it's just checking the register, seeing there isn't anything waiting, and then going onto the next thing [17:07:03] ok [17:07:05] that helps [17:07:19] I've been having trouble with the fixed size queue [17:07:32] because it's checking at 100Hz, it's much easier than I thought [17:08:06] basically you just make an std::queue [17:08:13] ok [17:08:17] when the AGC writes to channel 34, do [17:08:42] if (ags_queue.size() < 3) ags_queue.push(ags_value); [17:08:58] and then in the loop, roughly [17:09:25] if (stop bit reset) { val = ags_queue.pop(); put_value_into_ags(val); set_stop_bit(); } [17:09:44] ah right, this way I can still use that standard queue type [17:10:13] sounds good, I'll try that [17:13:30] that's roughly what I had, just with my own bad queue code [17:13:36] haha [17:14:32] so when the AEA starts reading from the queue, it will be full [17:14:40] yeah, but it will catch up very quickly [17:14:45] right [17:17:10] pop() doesn't return anything [17:17:18] ags_queue.front() maybe? [17:18:43] well just finished my 1st AGS rendez-vous [17:18:54] PGNS assisted of course [17:19:11] great [17:19:36] seriously, pop doesn't return anything? [17:19:41] that's dumb [17:19:42] and that after a late AGS abort requiring a chart derived tweak [17:19:51] then yeah [17:19:55] change that to [17:19:56] and a chart derived HAM [17:20:08] put_value_into_ags(ags_queue.front()); ags_queue.pop(); [17:20:10] and pop it afterwards of course [17:20:14] yeah [17:21:26] AlexB_88: everything work like it should? :D [17:21:56] and it crashed [17:22:08] ags_queue.size() was -7 when it happened :D [17:22:12] what [17:22:33] how [17:22:56] if ((vags.InputPorts[IO_2020] & 0200000) != 0) [17:22:57] { [17:22:57] SetInputPort(IO_6200, ags_queue.front()); [17:22:58] ags_queue.pop(); [17:22:58] PGNCSDownlinkStopPulse(); [17:22:59] } [17:23:05] I guess it tried to do pop too often [17:23:30] oh hm [17:23:48] I guess add "&& (ags_queue.size() > 0)" to that conditional [17:24:00] thewonderidiot, yeah AGS looks to work very well, there were a few challenges but thats more just me trying to figure out how to work it [17:24:22] it's not exactly user-friendly :P [17:25:16] that should be safe at least [17:27:45] hmm, now it doesn't set 414 back to 0 [17:27:58] the queue size always appears as 0 after a AEA timestep [17:28:02] but that is probably ok [17:28:23] I wonder if I am doing anything wrong with data types now [17:29:50] it wasn't clear to me yesterday... does the AGC send the AGS init just once, or multiple times? [17:30:27] 10 times [17:30:33] okay, that should be fine [17:31:13] I did notice that after 414+1 the AGS doesn't actually start checking the stop bit for what felt like 3-5 seconds [17:31:19] yep [17:31:35] but that shouldn't matter [17:31:35] hmm [17:33:03] okay two questions based on your code [17:33:23] is SetInputPort() taking care of the "<< 2"? [17:33:38] and if not, is the queue uint16_t or uint32_t? if the << 2 is done before pushing values uint16_t can't hold them [17:33:46] if (ags_queue.size() < 3) ags_queue.push(val << 2); [17:33:53] in LEM_AEA::SetDownlinkTelemetryRegister(int val) [17:34:04] what's your queue type? [17:34:09] as you wrote it [17:34:17] std::queue ags_queue; [17:34:19] yeah, you're losing some bits then [17:34:24] make it uint32_t and it should work [17:34:24] ah, that makes sense [17:34:40] any disadvantage of using 32? [17:34:53] except for a few bytes more :D [17:35:00] 3 wasted bytes? haha [17:35:03] that's pretty much it [17:35:05] ok [17:35:11] it's negligible [17:35:20] let me try it the other way [17:35:25] << 2 in the AEA timestep [17:35:34] that also should work [17:35:56] SetInputPort(IO_6200, ags_queue.front() << 2); [17:36:01] yep [17:36:16] that should make it read the initial bit again [17:38:13] ok, I see 414 is 0 [17:38:19] now the range rate check... [17:39:01] it's good! [17:39:06] \o/ [17:39:13] :D :D [17:39:48] ok, now let's think about this [17:39:54] queue max size is 3 [17:40:02] that should work perfectly fine at 60fps [17:40:18] let's assume you don't have 60fps [17:40:42] I'd like to have it working properly at about 30fps still [17:41:03] unlikely on the LM main panel, but not impossible [17:41:16] so, 30fps timesteps are 33.33ms [17:41:30] the AGC should only be generating an output once every 20ms [17:42:00] right? or am I thinking about this backwards [17:42:34] it's generating an output at 20ms in any case [17:42:43] yeah [17:42:47] but now the frame step length is longer than that [17:43:02] so you may start to run into danger when the framerate drops to 25Hz [17:43:04] so worst case is 2 downlink words per timestep [17:43:10] right [17:43:15] because then it's possible for the AGC to put two items into the queue instead of 1 [17:43:30] but even then, the AGS will certainly read both of them [17:43:42] I think the framerate would have to get pretty bad for a queue depth of 3 to not be enough [17:43:52] ok, so size 3 would be ok down to 25fps? [17:43:57] pretty sure [17:44:00] great [17:44:24] then I'll clean it up and let Alex find out in what way it still is broken :D [17:44:30] hehehe [17:45:42] ah, one thing [17:45:55] where all should it set the bit? [17:46:05] in the timestep, after reading from the queue [17:46:20] but also still in the PGNS to AGS downlink? [17:46:25] or only in the timestep [17:46:35] only in the timestep is fine [17:46:37] yeah [17:46:44] only there it does the SetInputPort [17:48:38] AlexB_88, development branch has been updated [17:48:46] great [17:49:05] I have to go to work soon, but I can make a quick test now [17:49:47] ok [17:51:46] thanks for the help Mike [17:52:05] my pleasure :D [17:52:20] and I don't expect there to be many issues with LGC/FP compatibility [17:52:26] only Apollo 13 [17:52:46] which flew FP7, which already must have had the PGNS to AGS downlink of RR data [17:53:15] no wait... [17:54:07] Apollo 13 is only a problem procedure wise [17:54:14] because we have no FP7 [17:54:16] that way around [17:54:43] sigh. I still feel like FP7 should be one of the easiest missing programs to find [17:54:49] right? [17:55:30] I like how the 440R shows up immediately with data [17:55:39] but the cross check with V83 takes a while to load [17:55:48] yeah [17:55:57] 1:0 for the AEA :D [17:56:12] I sometimes cheat and look at the RR tape :p [17:57:00] that works [17:57:23] but might not be accurate enough for the +/- 2.5ft/s difference check [17:57:44] true [17:59:19] reading the Apollo 10 technical debriefing for their P23 technique [17:59:37] with the amount of features they come up with for the AGC you can fill another AGC worth of memory [17:59:55] hahaha [18:00:28] indy91, 1st test went great [18:00:34] but John Young does talk about a auto maneuvering capability so that the star and landmark/horizon is oriented on a line [18:00:59] :D [18:01:08] so pretty sure they did that manually every time [18:02:30] and that feature was of course added later [18:04:46] yeah [18:05:27] so my 1st few PGNS->AGS downlink tests are very good... Looks like we can call the AGS fully implemented now! [18:05:42] \o/ [18:06:04] good work guys [18:08:28] yeah, quite happy that this works now [18:08:41] there still is that DEDA bug [18:08:53] I can do more testing on it tomorrow morning [18:09:18] yeah, I'd like a bit more testing on it [18:09:24] oh the one about the DEDA display after reloading? [18:09:25] but my 2nd and 3rd tests were good as well [18:09:28] yeah [18:09:40] right [18:09:53] I've checked, I don't think it's a simple DEDA loading issue [18:10:06] odd [18:10:07] maybe some AEA/DEDA sync issue [18:10:52] after all the AEA/DEDA have this weird setup with shifting data in and out of the DEDA [18:10:55] at least its not a deal-breaker as it only seems happens when loading the scenario [18:11:01] yeah [18:11:32] anyways im off to work...later! [19:29:44] indy91: so what remains to be done for 8.0? [19:32:29] @thewonderidiot mcc updates for apollo 11 [19:35:34] and Apollo 9 [19:35:50] any more work on the lem? [19:35:52] once that is done NASSP 8.0 will be in the Beta stage [19:36:05] well, no big new features for the LM anymore I think [19:36:09] lots of smaller changes and fixes [19:36:13] making the ECS more stable [19:36:22] and a bunch of other things [19:37:12] and for the evas in possibly 9.0 do you know yet what they will be like [19:40:48] no, not really [19:41:00] we have some age old EVA code that is currently disabled [19:41:06] we will first have to check if it is usable [19:44:59] but, we will probably try to create a full simulation of the spacesuit systems [19:49:43] night [11:48:52] good morning [11:50:05] Hey [11:50:27] hello [11:50:46] i was thinking trying apollo 9 along with 11 and i was wondering what you think is the most challenging part of it? [11:51:46] Well 11 of course has the landing. 9 stays in LEO. [11:53:29] would it be more difficult then apollo 7 or 10? [11:55:16] more difficult than 7 probably, yes [11:55:39] there is a bunch of RTCC stuff that hasn't been fully developed for Apollo 9 yet [12:07:44] okay [12:07:51] i think i'll stick with 11 for now [12:08:11] i dont even have an after touchdown save yet because i took a break for a couple of days [13:31:12] .stoplogging [13:31:15] .quitlogginf [13:31:17] .quitlogging [13:31:22] Log ended by Thymo, total logging length 612601 seconds [13:31:22] .endlogging