[11:09:32] NASSP Logging has been started by indy91 [19:04:35] morning! [19:13:39] good evening [19:13:42] what's up? [19:15:22] fixing some minor LOI targeting bugs and listening to the Apollo 13 FIDO audio [19:15:41] Midcourse specialist: many interesting things [19:15:57] FIDO: not much of an idea what he is talking about, "uhh, sure, I'll think about it for a while" [19:16:09] hahahaha [19:17:05] the night shift FIDO [19:18:01] and you? [19:18:30] working on transcribing PINBALL for retread [19:18:39] also will not be sad that this is the last full PINBALL transcription I have to do :P [19:19:11] also, the very last MIT system status report has an exact word count for Luminary 92, broken down into pretty small categories [19:19:25] that's pretty nice [19:19:25] and it has me wondering if the answer to what changed between 96 and 97 is hiding in there somewhere [19:19:49] since we have memos describing 92-96 and I already have reconstructed 97 [19:20:15] it's not a "definitely the final version" revision from 96 to 97? :D [19:20:43] nah, the bank 5 checksum changed [19:21:06] I'm kinda worried that it might be ephemeris related, and this is what Jim Kernan is remembering when he is thinking of 99 rev 2 [19:21:33] could be [19:21:35] since Raytheon did manufacture 96, and they had to remanufacture a module for 97 [19:22:36] also kind of hoping I will find the answer in with all of the anomaly reports that I'll be scanning soon :) [19:23:21] there is a decent chance for that [19:23:41] I need to sit down this weekend and prioritize what all to read/scan [19:23:43] knowing what most of the Luminary anomalies were... [19:23:49] that sounds good [19:24:18] I want any and all information about Sundance and Sundial, for the disassemblies [19:24:46] all of the PCRs, PCNs, and LNYs [19:25:15] also as much as I can find about the Apollo 13 Luminary changes [19:28:14] enough material to reconstruct some more LGC software versions :D [19:28:56] haha hopefully [19:33:30] Hey [19:34:20] hey Alex [19:39:10] LOI targeting still progressing well? [19:40:03] yeah, was testing some Apollo 11 and 17 [19:40:15] the 60x60 orbit after LOI-22 needed some fixes [19:40:20] LOI-2* [19:40:32] nice [19:40:46] mainly to skip the calculation of the intersection solutions, if there is no interersection [19:41:11] and for Apollo 17 the LDPP is not working right for DOI it seems [19:41:37] which might be right, the Apollo 13 document you got us from UHCL mentions that the LDPP only works in some cases for the CSM DOI [19:41:42] if DOI is at apolune [19:42:20] most cases really [19:42:24] Apollo 17 is just special [19:42:43] and because Apollo 14 was working well I started to try some TLMCC calculations again [19:42:48] but not very far with that yet [19:51:22] So did Apollo 17 use another processor for DOI? [19:51:39] I'm not sure what they would have used [19:52:12] but Apollo 11 did a CDH rendezvous calculation for LOI-2, so who know what crazy ideas they had! [19:52:27] haha [20:02:32] Off to work, cya! [20:23:40] oh indy91 [20:23:53] which of the LM-3 AOH and LM-3 systems handbook would be more useful to scan first? [20:24:13] Systems Handbook [20:26:02] okay, I'll get started on that [20:26:07] awesome! [20:32:15] I wish I could occasionally contribute when it comes to scanning, because usually I am the one who is causing other people to do the work [20:33:30] all the relevant documents are in the wrong country! [20:38:14] hahaha [20:46:02] FIDO: "Midcourse, let's go through this from square one" [20:46:07] that's what I like to hear [20:46:24] :D [21:24:10] by the way [21:24:21] almost all of the references in this handbook are LDW xxx-53xxx [21:24:50] https://photos.app.goo.gl/tEB9VoMtQi8wBetB8 [21:25:17] the commander's window and docking window parts of that drawing are both different from the LM-8 handbook [21:29:23] that's the figure that apparently changed for LM-8 as well [21:29:28] with the LDW xxx-58xxx [21:30:06] yup [21:30:55] not that I can really see a difference [21:31:35] the outline of the docking window changed a lot [21:32:55] and got a curtain :P [21:35:08] right [21:37:39] okay, all of the intro scanned [21:37:41] now to enter foldout hell [21:45:06] haha [21:45:07] okay [21:45:12] try #1 [21:45:58] http://i.imgur.com/5BTW8IB.png [21:46:09] nope [21:46:22] http://i.imgur.com/5BTW8lB.png [21:46:41] is that good enough? [21:46:54] yeah, I think so [21:47:29] I keep being impressed with how good the LM-8 and CSM-112 Systems Handbook scans look. That is what you are up against :D [21:47:37] hahaha [21:50:28] hmm [21:50:33] it seems black and white and not grayscale though [21:50:43] which is not the settings I set up for [21:50:50] let me try that slightly differently [21:54:49] mm nevermind [21:54:55] that's just how my copy looks [22:00:35] that would be impressive, the scan having more colors than the original [22:00:44] http://i.imgur.com/bp3h5aV.png [22:04:26] definitely good enough [22:06:54] http://i.imgur.com/ItgcDEl.png [22:07:20] this isn't so bad :) [22:08:15] the LM-8 handbook didn't even have that I think [22:08:30] oh cool [22:09:07] oh yeah they changed the structures drawings a lot for LM-8 [22:09:25] and there were some drawings missing completely from LM-8 [22:09:33] not many, but I remember it being some annoying ones [22:09:39] which I mostly found on the Internet [22:09:45] from some auctions [22:09:53] but still [22:11:39] good night! [07:54:09] .tell indy91 I've scanned up through section 9. all of the raw scans are here: https://drive.google.com/open?id=1pExROOS1jGW5hovuE6KImE-VCeT-AMws [07:54:54] .tell indy91 this is with foldouts stitched, but without final rotating/pdfing/OCRing [12:32:17] . [15:44:06] hey [15:47:15] hey Alex [15:48:13] looking at my Apollo 13 scenario now, calculating MCC-2, LOI, DOI [15:48:34] I made one change to the TLMCC targeting which might have done something good [15:51:59] ah, great [15:52:23] I guess DOI DVZ should be close to 0 [15:52:41] it is for Apollo 13 now [15:53:06] Apollo 14 not so much. Although the new LOI targeting continues to get the DOI apolune consistently to 60NM [15:53:24] but Apollo 14 probably needs some better initial guesses to find the right solution [15:53:56] does Apollo 14 maybe have a planed non-zero DVZ? [15:54:15] Apollo 13 and 14 both had DOI DVZ in the SCOT [15:54:21] but in real time it was 0 [15:54:38] Apollo 15 and 16 have 0 in the SCOT as well [15:54:46] ah [15:55:11] I continued with the Apollo 13 FIDO loop, some very interesting conversations [15:55:24] the pro contra on this topic is [15:55:44] it's desirable to have the LOI not rotate the ellipse for monitoring reasons [15:55:51] but that gets you a DOI DVZ [15:56:18] alternative is let LOI rotate the ellipse [15:56:27] all of which I already knew [15:56:43] at this point the main question is really, how were the available tools used to accomplish this [15:57:16] Apollo 13 FIDO loop only helps a little, as their TLMCC and LOI targeting was still different to the later missions [15:57:37] well, it helps a bunch, just not for explaining the use of their calculation processors [15:57:46] right [16:00:27] the TLMCC targeting simply does an optimization [16:00:32] finding a local optimum [16:00:46] so it needs some good initial guesses [16:01:14] flight path angle at LOI is probably an important parameter to play with [16:01:19] so what parameters need the good initial guess the most? [16:01:24] ah [16:02:25] the one change I did immediately resulted in DOI having 2 ft/s DVZ for Apollo 13 [16:02:34] although the DOI apolune was a bit low [16:02:46] with the height bias I could get the DOI apolune to 60NM [16:02:50] and 10 ft/s DVZ [16:02:55] which is still not much at all [16:05:39] yeah [16:06:06] so the height bias is to tweak the DOI apolune? [16:06:35] it has that effect yes [16:07:09] you can use the same bias in the TLMCC targeting actually [16:07:24] although I hadn't added it yet as an input parameter there [16:07:47] so, without the height bias, I sometimes get no LOI2DV on the LOI display [16:07:59] which means that the LOI and DOI ellipses don't intersect [16:08:12] it basically can't find a solution for that [16:08:45] with the bias I can make it find a solution, but it is either changing the DOI height or the DOI DVZ for the worse [16:08:52] but at least it's finding a solution [16:11:59] but to be honest, I still haven't fully understood the need for the height bias :D [16:13:06] what is "height" referring to? [16:14:40] well it's an input to the LOI processor [16:14:49] and TLMCC processor, but barely mentioned or even explained there [16:15:06] it is only relevant for the intersection solution in the LOI processor [16:15:17] the solution type interesting for the LOI/DOI geometry [16:15:20] in the LOI document it says this [16:15:37] but its the height of what, DOI apolune? [16:15:57] "For the intersection solutions, the amount that perilune of the first lunar orbit should be above or below the second lunar orbit at perilune of the first is specified by a MED" [16:16:27] I wish it was as simple as a bias to the DOI apolune [16:17:17] but it is basically a parameter to somewhat control the intersection between the post-LOI and the post-DOI ellipse [16:17:44] "the second lunar orbit" is that referring to the DOI orbit? [16:17:47] yeah [16:17:54] ok [16:18:14] you have two ellipses in lunar orbit, there are lots of names for them it different document [16:18:17] documents [16:18:30] the first is called: LOI ellipse, first lunar orbit, LPO1 [16:18:38] second: DOI ellipse, second lunar orbit, LPO2 [16:22:18] I guess what it means is that, in the ideal case, you have LOI perilune and DOI apolune at the exact same spot [16:22:34] and the height bias is a difference between those [16:22:51] meaning that DOI will probably rotate the orbit, aka, has a DVZ component [16:23:46] so if you want to have no DOI DVZ then you need to set up the orbits already so that you don't need a height bias [16:24:21] if you want to let DOI rotate the orbit a bit then you can use the height bias to do that [16:25:15] I guess you would do that if your DOI apolune was too low? [16:25:52] or maybe if you need to rotate the orbit so much that you don't want to let LOI do all of it [16:25:59] which is what Apollo 17 did I think [16:29:56] for Apollo 13-16 we should definitely try to get DOI DVZ to 0, and probably without using the height bias [16:30:37] I guess that means TLMCC parameter tweaking [16:30:51] yeah, some of the skeleton flight plan table parameters should do it [16:37:45] yeah [16:37:49] flight path angle is doing it [16:37:58] for Apollo 14 [16:38:05] flight path angle at LOI that is [16:38:54] so I think with the one TLMCC fix it's definitely possible now to get all constraints right [16:39:00] just a bit labor intensive for now [16:40:17] as they didn't stick to the SCOT for Apollo 14, maybe UHCL has some interesting document about the targeting [16:40:24] like the one you got about Apollo 13 [16:40:57] Apollo 14 NAVIGATION RESULTS [16:41:05] this one is quite interesting for Apollo 15 [16:41:40] Apollo 14 FLIGHT DIRECTOR REPORT FLIGHT CONTROL DIVISION [16:41:51] "COLLECTION OF DOCUMENTS ON Apollo 14" whatever that is, lol [16:42:24] what was the TLMCC fix? [16:43:03] allowing it to iterate on the LOI flight path angle to optimize DV [16:43:19] I think that is an error in the RTCC document [16:43:31] it didn't mention the LOI flight path angle at all in the optimization step [16:44:06] in another place, the list of inputs and outputs from the data table (skeleton flight plan), it does however say that the parameter is used in that step [16:44:41] before it simply kept the flight path angle at LOI fixed [16:45:02] which was probably quite bad [16:45:24] so it must have been an error, that got not even fixed in the change document [16:46:02] the equivalent step in mode 2 did allow iterating on it [16:46:32] right [16:47:55] so looks like the LOI targeting/TLMCC fix is in a quite good state already [16:48:21] it's working well, just need some better inputs and smarter users [16:48:33] haha [16:48:44] not that I am impressed with the knowledge of the Apollo 13 FIDO [16:48:55] but callsign Midcourse, he knows what's up [16:49:15] ah really [16:49:55] whenever he and the FIDO talk about MCC-2 I learn something [16:50:48] I was devastated when, on the previous shift, the FIDO told Midcourse to personally come to him and talk about MCC-2 [16:51:02] because that then didn't get recorded of course [16:53:42] yeah thats a bummer [16:58:50] Is the sate of the LOI targeting already good enough to push? I have a few days free, would love to do a bit of testing with it [16:59:56] yeah, I think so [17:00:35] did a first commit of it earlier today [17:01:04] before that I was lazy and hadn't added all input functions yet to the LOI init page :D [17:01:33] done [17:01:48] and not too long now before I can merge into dseagrav/NASSP again [17:01:51] thanks [17:01:55] ah, ight [17:01:58] right* [17:05:09] Apollo 14 ( JAN 31 1971 ) CSM 110 ( COMMAND SERVICE MODULE 110 ) PRELIMINARY CMP ( COMMAND MODULE PILOT ) SOLO BOOK [17:05:19] I didn't know UHCL had this [17:06:34] POSTFLIGHT EVALUATION OF THE APOLLO 14 SPACECRAFT TRAJECTORIES [17:06:39] this is the one I will get [17:06:50] that will have info about targeting [17:12:14] alright, just built the modules [17:12:39] I see approach azimuth is 270, so I guess equivalent to -90 [17:12:46] using Apollo 167 [17:12:49] 16* [17:12:59] yeah, the LOI targeting wants positive numbers [17:13:11] TLMCC as well, I'll change that some time [17:13:25] min and max azimuth is not that relevant [17:13:50] it doesn't influence any of the 8 solutions [17:14:00] only the two numbers on the left of the LOI display [17:14:19] but there is some bug with that calculation, so the numbers aren't shown yet [17:19:41] so I have made a LOI calculation on the LOI planning display [17:19:44] looks good [17:19:54] each solution has 2 versions [17:20:00] yes [17:20:26] positive and negative solutions [17:20:45] "positive solution is one whose perilune is rotated ahead (i.e. in the direction of motion)" [17:21:08] that is basically equivalent to the old rotation direction option [17:21:56] the last number, all the way to the right, is the true anomaly on the ellipse [17:22:17] that should usually be different for the positive and negative solution [17:25:14] right [17:28:09] I explained "Theta" to you, right? [17:31:06] yeah, yesterday I think [17:31:25] well, I might need to revisit it though haha [17:31:51] right now I am testing with MCC-1 + LOI + DOI on Apollo 16 [17:33:10] intersection 1 gave me an DOI perilune height of +115 NM, ouch haha [17:33:33] however intersection 2 gave me a perilune height of 61 NM, but a quite high DVZ [17:33:53] I guess tweaking the LOI flight path angle should help with that [17:33:55] solution 1 has always been useless to me [17:34:04] solution 2 is where it's at [17:34:08] right [17:34:10] which is consistent with what we had before [17:34:37] of the two old LOI solutions it was usually solution 2 that was the good one [17:35:22] you just have to look at HPC on the LOI display [17:35:32] solution 1 had 30-40NM usually [17:35:34] which is way too low [17:36:46] right [17:37:18] "DVLOI2" that is just if you had an LOI-2? It wouldnt also include the predicted DOI DV? [17:37:49] it calculates the second maneuver, whatever it is called [17:38:00] ok [17:38:16] it says 0 for solution 2 [17:38:19] the DV at the intersection of the two orbits, specified by the HA and HP variables [17:38:27] yeah, it says 0 when there is now intersection [17:38:35] ah [17:38:37] that's where the height bias might come into play [17:38:39] no* [17:38:41] right [17:38:48] LOI init page, top right [17:38:51] try 1NM [17:38:53] then 2NM [17:39:00] should I go right into the height bias, or 1st play with LOI flight path angle [17:39:07] try to use as little as possible, but so that it gives you a DVLOI2 [17:39:08] which itself is 0 [17:39:28] hmm [17:40:15] for Apollo 16 we can consult the SCOT [17:40:57] figure 4.7-1 LOI geometry [17:41:44] looks like LOI is post pericynthion [17:42:04] hmm [17:42:05] or is it [17:43:06] it's difficult to judge, as we need to find these numbers for an impulsive LOI [17:43:49] right [17:45:21] I haven't play around with it yet, but in the TLMCC without flight path angle fix I was never able to raise the pericynthion altitude [17:45:32] and for Apollo 16 it should be 71NM [17:46:28] maybe try LOI flight path angle 5 and -5 [17:46:34] and then -10 or 10 if you must [17:47:06] hmm [17:47:15] well, those numbers are initial guesses [17:47:27] and I confused the numbers with the true anomaly [17:47:42] flight path angle probably should be smaller numbers [17:48:46] and there are some other numbers which might have to be changed [17:54:50] like, if you are not at 0° flight path angle after LOI [17:55:02] then you will spent less than 2 full orbits until DOI [17:55:13] which is the REVS1 parameter [17:55:24] using 1.9 for Apollo 16 does some things [17:55:29] not sure about good things [18:06:14] I tried a DHBIAS of +5 which made the DVLOI2 give a solution, but now the DOI apolune is 55 NM [18:08:08] I never needed that much [18:08:18] but I am also not having too much luck with Apollo 16 [18:08:24] it's all so... unintuitive [18:08:43] if you change one parameter then you probably also need to change two others [18:09:12] morning! [18:09:41] I think the TLMCC just needs more work [18:09:43] hey Mike [18:09:48] some nice looking scans [18:10:27] one page that is completely new is the detailed DC power schematic [18:10:38] missing from the LM-8 Systems Handbook [18:10:41] awesome :D [18:10:52] and I found an Apollo 15 version, but the LM EPS was changed quite a bit for those missions [18:12:04] so that's the only detailed DC schematic for pre Apollo 15 I have seen, I think [18:14:39] I think I should be able to finish it off today [18:16:05] nice [18:16:28] I looked at a bunch of the scans, but I think I'll wait for the full PDF before downloading anything [18:16:53] I confused myself multiple times when I wanted to look at your Astrionics Handbook [18:17:10] hahaha [18:17:11] I only found the partial and separate scans in my folders, haha [18:17:25] "wait, where do I have the full PDF?" [18:18:14] the .tiff files of that [18:18:19] were they higher quality? [18:18:28] if not I will once and for all download the folder [18:18:32] uhh [18:18:33] delete [18:18:50] no, at least I think the PDF is full quality [18:19:07] ok [18:19:31] that was the intent :) [18:27:52] indy91, all my MCC solutions have a pericynthion height of ~58 NM, while the SFP has 72.76 as initial guess [18:28:05] so yeah thats not quite right I guess [18:28:19] try changing REVS1 [18:28:30] 1.9 gave better results [18:29:50] lowered it even more haha [18:30:40] it didn't forme [18:30:42] for me [18:30:58] together with some LOI flight path angle [18:32:22] what about ETA1 [18:33:08] good question [18:33:25] I think in the currentl version that's also only an initial guess [18:33:37] TLMCC document change 2 from December 1971 makes eta1 more important [18:33:50] I was switching between that version and the older one [18:33:58] currently implemented is the older version [18:34:04] so eta1 shouldn't be too important [18:34:07] I think [18:36:06] what I find hard to believe is that you would need to change multiple parameters manually just to get the LOI rotation right [18:42:39] haha [18:42:50] got DOI DVZ down to 22 fps [18:43:13] HPC 59.18 [18:43:36] basically just by playing with flight path angle at LOI [18:43:48] and using your suggestion of 1.9 [18:43:52] for REVS1 [18:45:30] I tweaked the flight path angle to get as close as possible to H PYCN of 72.76 on the midcourse tradeoff display [18:45:49] closest I got was 68.518 [18:46:15] and that is with LOI flight path angle of -7.8 [19:06:29] here is what I will do [19:06:44] I have learned some things from the LOI processor I want to apply to the TLMCC processor [19:06:51] and then I will implement the "change 2" version again [19:07:17] what might be the case, not 100%, is that you can entirely control how much LOI is rotating the orbit with the ETA1 parameter [19:13:37] right [19:20:40] the real Apollo 16 DOI had a DVZ of -45.5 [19:22:49] no maneuver plan survives the first contact with the enemy [19:22:59] or in this case, with the FIDO in charge [19:29:38] so you're saying the machine is only as good as FIDO :D [19:32:08] which makes me worried for the MCC functionality [19:32:22] these new processors are quite capable, but apparently need some manual work [19:32:27] not easily automated [19:32:42] yeah [19:33:26] the good news is I have a very good LOI + DOI solution on Apollo 16 [19:33:37] TIGs and DVs match the real pads very closely [19:34:00] lunar landing time error of 45 s [19:34:06] not bad [19:34:46] using which numbers? [19:34:55] the one you said above? [19:34:59] ones* [19:35:35] well yeah, the REVS1 1.9 and LOI flight path angle of -7.8 [19:37:38] hopefully I'll have some improvements tomorrow [19:38:05] the ETA1 parameter? [19:44:33] the whole "change 2" of the TLMCC document [19:44:52] which includes making the eta1 parameter, apparently, more powerful [19:45:02] and simplifies a lot of equations actually [19:45:11] it doesn't even iterate on the node altitude anymore [19:45:30] that is entirely determined by the LOI1 orbit parameters and the eta1 [19:46:13] right [20:15:30] this thing has too many darn foldouts [20:15:55] I'm up to 10.16 [20:17:02] section 10 is pretty large [20:17:05] not much after that [20:53:46] aaalmost done with section 10 [21:13:18] indy91, REVS1 = 1.9 for Apollo 16, is that a special case for that mission, or could it be expected for others as well? [21:13:45] 1.9 would mean 1.9 orbits between LOI and DOI [21:13:58] right [21:14:06] so LOI happening after pericynthion [21:14:34] it could be not 2.0 for any mission that tries to have 0 DOI DVZ [21:14:39] non 2.0* [21:16:16] I think right now that parameter matters the most when trying to have LOI rotate the orbit [21:22:49] 10 done, finally [21:22:53] the last foldout was a pain [21:23:32] just did not want to stitch [21:28:37] awesome [21:29:02] are there any in there you wanted to see? [21:30:10] potentially [21:30:20] especially any pages that were not in LM-8 [21:30:42] might be difficult to say what that would be [21:36:06] yeah [21:36:17] I do at least have all of the drawings that say they were deleted [21:38:58] I'll look at the completed document when you are done [21:39:04] I am sure I will discover many things [21:39:16] the sections so far are also often quite different to the LM-8 handbook [21:41:03] this is a good exercise though, for getting my laptop set up with all of the tools I need for scanning, heh [21:41:19] have had to install many things for this [21:41:57] haha, I bet [21:42:16] I do think Microsoft has improved ICE some though [21:42:25] because most of these foldouts have just stitched together instantly with no coaxing [21:43:15] I think the weakest part of this toolchain is the PNG -> PDF step for the foldouts [21:43:36] which seems like it should be easy, but I still haven't found the perfect tool for it [21:44:52] 11 done! [21:45:09] does it have more than 12 sections? [21:45:19] 13 [21:45:33] where 13 is Development Flight Instrumentation [21:45:34] ah right, the additional programer section [21:45:46] Development Flight Instrumentation, that's what I meant :D [21:45:52] hehe [21:45:54] but that's real small [21:47:01] the CSM also had DFI [21:47:10] Apollo 7 and 8 had some extra 10 circuit breakers for it [21:47:17] panel 277 [21:47:22] we don't simulate it [21:47:34] oh wow [21:48:41] was that also a descendent of the programer? [21:49:09] I lied [21:49:16] 10 instrumentation circuit breakers in total [21:49:21] all missions had 4 [21:49:28] operational instrumentation [21:49:33] so it's 6 just for DFI [21:49:42] and I don't think it's related to the programer [21:50:05] there were some separate data recorders [21:50:09] like the DSE [21:51:19] I doubt they had telemetry for those [21:51:28] so they were probably evaluated after the mission [21:51:40] just some additional data collection I believe, I don't have much info [21:54:27] there is an Apollo Experience Report about it [21:55:41] good night! [22:15:01] scanning and stitching complete! [22:15:07] now I just need to assemble all of this into a PDF... [22:57:37] huh [22:57:46] turns out GIMP can save off perfectly good looking PDFs [23:02:29] yep this will work great [23:57:52] pages spliced together and rotated. now just need to run the final OCR pass [23:58:53] this is going to take a while :P [00:17:24] nice! [02:57:53] jeez very long [02:58:00] it's only on 43% done [07:09:06] .tell indy91 OCR is being a pain. here's the completed PDF, sans OCR: https://drive.google.com/open?id=173g0JUcLz9T9A1vYKWNBKeoN5YaSh6jo [09:06:29] oh shit, the last run of the night may have been successful [09:13:02] hmm, no, it mostly worked but screwed up some pages [16:01:00] hey [16:01:44] hey Alex [16:02:01] I think I have it! [16:02:09] TLMCC targeting [16:02:18] I have pushed the latest update [16:02:22] just saw the update [16:02:27] nice [16:02:35] and what you want to do is modify the REVS1 parameters for the TLMCC targeting [16:02:51] there is a corresponding ETA1 parameter that gets you DOI at perilune [16:03:03] I let it automatically calculate that ETA1 if you changes REVS1 [16:03:14] so REVS1 is the only parameter you need to manually tweak [16:03:30] to get DOI DVZ to 0 [16:04:31] for Apollo 13 for example the magic number is 1.96 [16:04:34] instead of 2.0 [16:05:51] ah [16:06:06] so, definitely do small changes like that [16:06:11] so just tweaking that backwards very slowly [16:06:23] either way might be right [16:06:29] ok [16:06:31] so larger than 2 could be right as well [16:06:39] Im going to test Apollo 14 [16:06:40] but you will not have to do it many times [16:07:15] the only issue I have with Apollo 13 is that it doesn't end up having exactly 60NM apolune after DOI [16:07:19] only 59.6NM or so [16:07:24] small issue I guess [16:07:45] but I can look into that, I have some ideas why it could be a little less accurate than you would hope [16:10:32] so I still add LOI and DOI to the MPT to check the DOI apolune for each tweak of REVS1? [16:11:13] I guess, yeah [16:11:33] and you also then need to use the REVS1 and ETA1 you used in the TLMCC on the LOI init page [16:11:43] 1.96 works great for me for Apollo 14 as well [16:11:59] ah right [16:12:38] also, the desired LOI apolune/perilune on the LOI page should be the same as the constants in the TLMCC [16:12:43] ? [16:13:18] probably, yeah, but it's not that critical [16:13:26] ok [16:13:28] especially the LOI perilune for the intersection solutions [16:13:40] that gets ignored, as it calculates a perilune altitude itself [16:13:47] right [16:14:17] most parameters just need to be the same for fine tuning [16:14:23] same in TLMCC and LOI [16:15:08] Apollo 14 does need REVS2 set to 10 and SITEROT -16/344 in all processors I guess [16:15:14] oh [16:15:19] is it really 10? [16:15:21] oops [16:15:32] quite sure [16:15:43] oh wait [16:15:46] sorry Apollo 16 [16:15:51] in the TLMCC I changed the SITEROT sign to agree with the LOI processor [16:16:07] so it's -15° if the landing site is post perilune [16:16:23] so always -15 and -16 and +10° for Apollo 17 only [16:16:32] the LOI display has 345° [16:16:50] but, you need to input it as -15° or else the math doesn't work [16:16:57] it looks at the sign of that number in some cases [16:17:26] and yeah, we will need to update and tweak some of the default mission parameters [16:18:27] oh seems to work well [16:25:25] testing Apollo 16 [16:25:35] I think you need quite a bit of change [16:32:35] 1.96 for Apollo 16 [16:32:42] got DVZ to 0 [16:32:47] well very close [16:33:02] Apollo 14** [16:33:21] jeez Im getting those 2 mixed up this morning :D [16:33:41] DOI apolune 59.58 [16:34:26] yeah, same [16:34:39] for Apollo 16 I went as low as 1.90, but that seems too much [16:34:55] it still likes to keep LOI close to pericynthion [16:35:13] one thing though, the DOI DVZ is 0, but the landing time is off by ~5 minutes [16:35:14] only the post LOI true anomaly is large [16:35:35] with constraint on LOI time? [16:35:55] yeah [16:36:16] I forced it to the correct LOI TIG [16:36:21] hmm [16:37:12] what about the DOI TIG? [16:37:52] its actually earlier then the flight plan by ~2 minutes [16:41:24] oh my LOI intersection 2 solution did not give a DVLOI2 value with REVS1 1.96, but the DOI itself looks good [16:41:37] I guess thats not to big of a deal [17:09:56] morning! [17:13:31] hey Mike [17:14:09] what's up? [17:14:27] testing Niklas's new TLMCC updates [17:22:57] AlexB_88, either the DOI calculation in the LOI targeting or the targeting for the CSM DOI in the LDPP might need some more work. Or both :D [17:23:05] thewonderidiot, thanks for the scan! [17:24:14] I made LOI and DOI ellipses in the TLMCC and LOI processors match the flight plan, 170x57.1 and 58.4x8.2 [17:24:15] sure thing! let me know if you find any egregious stitching problems [17:24:27] I'm going to give OCR another few attempts tonight [17:24:28] looks good [17:24:43] that actually moved it 2 minutes closer [17:24:44] OCR needs a super computer it seems [17:25:00] and the real Apollo 14 LOI was 1.5 minutes early [17:25:13] so I did that to and it brought it quite close [17:25:26] it's not that it needs a supercomputer, it's just that all of the tools are janky and screw things up in different ways [17:25:29] might be because the SCOT (and probably the flight plan) were based on on ellipse rotation during LOI [17:25:39] and it takes an hour or so to test each one [17:25:46] on no ellipse rotation* [17:25:58] I got one super close last night, but it just completely changed the contrast on like 3 random pages [17:26:21] Ron is also OCRing documents [17:26:22] it did great on the actual OCR bit though. I just wish it wouldn't mess with the image [17:26:34] yeah, I might have to ask him what he's using [17:27:43] Alex, which landing time was off? On the LDP display? [17:28:43] yeah [17:28:58] and looking at PDI ignition [17:29:01] that might not be very reliable right now, especially for many revs between DOI and PDI [17:29:07] but I am not sure [17:29:14] it might be off by a minute or two [17:29:21] right [17:29:26] because of conic calculations being used [17:30:59] so for this whole MCC/LOI/DOI sequence the LDPP is probably the one that needs the most work now [17:33:16] and Apollo 13 already had some update it the LDPP that we don't know anything about [17:33:24] to the* [17:39:09] I guess for now getting DOI on time is the best gauge to getting the landing time right [17:40:08] or maybe they simply aimed for that REV2 meridian time [17:40:30] we also have the gravity field difference between Orbiter and the real Moon [17:40:42] that method seemed to work quite well with the old mode 4 targetting [17:40:48] they had to target a different orbit at DOI, to achieve the right parameters at PDI [17:41:04] we don't have to do that [17:57:59] indy91, I also maybe should have mentioned I am using an Apollo 14 scenario with a 2.5 hour launch delay [17:58:22] yeah [17:58:24] that can probably screw the times up a bit too I guess [17:59:01] I did if course compensate all the required values for the delay [17:59:02] well, Apollo 14 is a constant arrival time mission [17:59:09] yes [17:59:23] so after the clock update everything should be quite like the flight plan [17:59:30] so I subtracted 2.5 hours for my TLMIN target [17:59:38] right [17:59:47] my test was pre-MCC2 [18:00:02] and you updated the liftoff time in the RTCC MFD [18:00:29] update as in, MFD has the same time as the CMC currently [18:01:19] in any case, that can be confusing, haha [18:02:34] yes [18:19:56] yeah, Alex [18:20:15] although I would like to figure it a bit more than just trial and error [18:20:37] right [18:21:35] and I think some parts of the targeting also need more tweaks [18:21:39] not just th einputs [18:22:22] if DVLOI2 shows 0 on the LOI planning display, should I always set a height offset for it to give a solution? [18:22:35] because it seems to work even if I dont [18:22:55] I mean, it will find a solution [18:23:07] just not at 60NM [18:23:19] ah ok [18:23:20] you can give it a bias to get the DOI apolune to 60 [18:23:27] probably helps with timing post DOI [18:23:35] but it will give you a DVZ that won't go away [18:23:48] in my, so far very limited, experience with playing around with it [18:24:26] not a large one if everything else was already properly tweaked [18:24:38] oh btw, Marcel found somebody's stash of technical shuttle (and some apollo) documents online: https://djtrxhspk3vbzxnwufnm3q-on.drv.tw/Gandalf.Digital.Net/Shuttle/ [18:24:50] one of them has relatively detailed CPU flow diagrams of the AP-101 [18:25:30] ignore the sketchy-looking URL, we came to the conclusion that it is probably fine :D [18:25:51] intersting URL [18:26:25] according to Ken, drv.tw is a Google-Drive-to-web-page service and the djtrx... is Google's identifier for that drive folder [18:27:20] so using the flight plan LOI/DOI ellipses on my nominal Apollo 14 scenario helps as well [18:27:53] AlexB_88, but won't that get you into the wrong orbit shapes? [18:28:34] right [18:29:08] 169.3x58 post LOI [18:29:09] thewonderidiot, looks like a lot of documents I downloaded from NASA Spaceflight while I had a paid subscription there [18:30:04] and 58x8.2 post DOI, off the MPT [18:30:24] if it works good for PDI timing [18:30:31] but you will have trouble with the circ burn [18:30:40] well thats what I am getting at [18:30:41] true [18:31:28] I guess the real landing time was optimized around the fact that they have to get those modified ellipses [18:31:49] and that we should just stick to 170x60 and live with a slightly off time [18:32:00] hmm [18:33:19] if we look at the later missions, then there is the rev 2 crossing time constraint and also some later constraints [18:33:27] we should try and keep close to them [18:33:32] right [18:33:43] that worked well for me in the previous TLMCC mode 4 [18:33:44] orbital parameters aren't critical unless needed for future maneuvers [18:33:46] like PDI and circ [18:34:07] I just need to see how to find the REV 2 time now, from pre MCC-2 [18:34:14] right [18:34:47] Apollo 13 didn't have that time constraint yet, so the FIDO didn't try anything for that [18:35:07] he put time constraints on LOI to keep close to the flight plan [18:35:16] but I am still many hours out from MCC-2 in the FIDO audio [18:36:32] I'm sure it's possible to get the rev 2 time with realistic mission control tools we already have implemented [18:39:42] who knows, the answer might be as simple as the Midcourse Tradeoff display showing that time [18:40:18] I don't have a picture of that display, so I am free to be creative :D [18:41:27] haha [18:41:48] it would be useful [19:02:54] testing Apollo 15 now [19:07:28] bang on [19:08:09] LOI on time, DOI on time, DVZ -7.4 [19:08:38] and that just because I am too lazy to tweak REVS1 anything finer then 1.9 :D [19:13:36] haha, nice [19:22:44] maybe a trick to get a good initial guess is to play with the REVS1 parameter until the H PCYN value on the midcourse trade-off display matches the desired pre LOI pericynthion [19:25:32] yeah [19:25:55] doing Apollo 16 now [19:33:45] 1.87 seems to do it [19:33:53] is that what you found as well? [19:35:02] I got to 1.9 and then didn't really like it [19:35:18] I think the number is too far off 2.0 [19:35:24] but I am not quite sure [19:35:36] I looked at the ignition altitude compared to actual [19:35:55] 1.87 might be good [19:36:12] 46.8° in true anomaly is a looooot though [19:36:43] is the LOI DVZ large? [19:36:53] LOI that is, not DOI [19:37:10] let me check [19:37:43] -208 [19:37:46] LOI DVZ [19:37:49] that's ok [19:38:27] real PAD had even more [19:38:57] I think the real DOI pad had 45 fps DVZ [19:39:01] for Apollo 16 [19:39:23] but planned was 0 [19:39:24] but my LOI DV's are almost the same as the SCOT [19:39:28] right [19:39:34] yes it was planned 0 [19:39:45] they really couldn't stick to the SCOT, like ever [19:40:05] either because they didn't want to (Apollo 13 and 14) or because they couldn't due to trajectory dispersion [20:04:19] I want to test Apollo 17 but I think your were saying the LDPP has issues with it [20:13:58] well that was before the fixes today [20:14:04] you can try it [20:14:30] they didn't plan to have DOI DVZ as 0 for 17, but I am not sure what they were then targeting for [20:15:07] hmm [20:15:20] maybe no LOI rotation at all [20:22:38] if I try Apollo 17 it doesn't calculate MCC-2 at all [20:22:45] maybe an old scenario [20:24:34] or a bad skeleton flight plan [20:50:00] my LOI DVZ on Apollo 14 was just over 500 fps. Seems Kind of high [20:51:50] oh and about Apollo 17, if its my old scenario, there might have been a launch delay on it [20:58:43] I think the problem with the DV is that the targeting seems to place LOI at pericynthion and it then needs to rotate the orbit a lot to achieve the desired DOI geometry [20:58:53] what it probably should do is have LOI a bit earlier or later [20:59:11] not quite sure why it doesn't optimize that, but I have some ideas where to look for an error [21:01:38] yeah it might be an issue in the LOI DV calculation [21:09:51] night! [15:34:17] hey [15:34:22] hey Alex [15:35:03] tried some changes to the LOI DV calculation, don't really improve things [15:35:20] but I think some of the fairly extreme true anomalies (ETA1) we are getting are right [15:35:50] still, the LOI DVZ for Apollo 14 and 16 look a bit off [15:35:56] ah [15:35:58] yeah [15:36:09] I'm following along with the Apollo 13 FIDO loop, I am definitely getting good results there [15:36:40] I even heard them mention the true anomaly needed for a specific rotation [15:36:54] they have 12.5°, which agrees fairly closely with the number I got [15:37:36] Midcourse apparently has a chart of pericynthion altitude vs. true anomaly [15:37:51] hmm, so they might of had part of the DOI as LOI-2 geometry functions? [15:37:54] so basically how much the orbit is being rotated [15:38:47] what do you mean? [15:39:43] if they could control that in the TLMCC targeting? Or do you mean they simply adjusted pericynthion height with a chart? [15:40:34] yeah I am wondering that, too [15:40:46] they seem to be able to control the pericynthion height quite directly [15:40:59] but Apollo 13 had some intermediate TLMCC targeting [15:41:08] there is a separate RTCC Requirements document for it [15:44:22] so perycinthion altitude is really what controls LOI rotation I guess [15:44:32] yeah [15:44:57] if you want 60x170 and your pericynthion is 71NM then you'll get at least 40° or rotation [15:45:04] as I find every change of REVS1 affects peri height the most [15:45:07] or you'll end up at least at 40° true anomaly [15:45:53] yeah, in this "change 2" version it tries to achieve a specific node radius [15:46:06] calculated from the LOI orbit (60x170) and the ETA1 parameter [15:46:29] and as I made it so that a REVS1 change also changes the ETA1 parameter by the same amount, that has a strong effect [15:48:13] with Apollo 13 I am also observing the issue that with LOI on time, DOI and everything after is off by multiple minutes [15:48:43] we probably should sacrifice LOI being on time in order for all orbital events being on time [15:48:58] and I still need to look at the LDPP again, how accurate it really calculates the DOI [15:49:02] the early DOI [15:49:58] and I am also annoyed that the LOI targeting never comes up with a DVLOI2, even though the orbits seem good [15:51:00] I found what helped with that is using the elipses heights from the SCOT/flightplan and that got times closer, I guess though in our case that is bad though so maybe changing LOI time is the way to go [15:51:44] yeah [15:52:02] in the MCC and LOI processors they will have input the desired orbital parameters at LOI and landing [15:52:08] so 170x60, 60x8 [15:52:19] both processors do a backwards integration [15:52:37] so that would, in reality, lead to the perturbed orbits you are seeing in the SCOT and flight plan [15:52:40] at DOI TIG [15:52:47] right [15:53:47] btw well have to update some constants, like Apollo 14 for example REVS2 should be 10 not 11 [15:53:59] Apollo 16** [15:55:01] yeah [15:55:41] if that is true then they ran their simulations wrong in October 1970 [15:56:45] yes, it's 10 [15:56:46] weird [15:56:56] maybe they ran the simulation for a different launch day [15:57:14] https://i.imgur.com/THJBg90.png [15:57:23] this even has the Apollo 14 landing coordinates [15:57:36] and clearly has 11 as REVS2, haha [15:58:38] hmm [15:58:59] the LOI targeting outputting a landing site time would be useful [15:59:08] it's not on the display [15:59:10] but [15:59:23] some processors are really spamming the online monitor display [15:59:35] so I think I'll add a message for that there [15:59:45] and I will also put a rev 2 crossing time from the TLMCC there [16:00:08] right [16:00:28] that would be great haha [16:01:16] just look at it [16:01:17] https://i.imgur.com/qhYjmEP.png [16:02:03] PMMLDP is the PDI time calculation [16:02:11] PMMLDI is the descent simulation module [16:02:15] so many outputs from them [16:02:24] touchdown velocity [16:02:26] touchdown time [16:02:32] throttle recovery time [16:02:46] how many iterations the engine-on algorithm needed [16:02:50] so many messages [16:02:54] yeah [16:03:27] I haven't really used the online monitor yet [16:04:41] well there isn't much to see yet [16:04:48] I'll add messages over time [16:04:57] I know many of the realy messages that would be shown there [16:05:01] real* [16:07:08] I tried Apollo 17 last night [16:07:30] I fixed the SFP by adjusting the GMT of LOI [16:07:48] it seemed to be way too far in the future [16:10:04] oh [16:10:14] did I math wrong [16:10:42] 109:52:24 [16:10:44] GMT [16:11:20] 89:00:00 GET would be right [16:12:37] did I calculate it from central standard time or something :D [16:13:42] planned launch was about 3am GMT [16:13:54] yeah, that's totally wrong, haha [16:14:16] 92h GMT rougly would be right [16:15:38] from the Apollo 13 flight plan, "solar corona photography" [16:15:42] no corona please, thank you [16:15:45] I just used LOI GET + the default launch time in the RTCC MFD (2:53 AM) and came up with about that, yeah [16:16:30] yeah no kidding [16:18:57] so having fixed the SFP, I made some tests with Apollo 17, but I was not able to get anything good out of it [16:20:13] to me it looked like they did no LOI rotation [16:20:56] ah [16:21:00] the LDPP is the problem [16:21:21] it will always put DOI at a specific geometrical point removed from the landing site [16:31:17] lots of numbers are different in the TLMCC constraints for Apollo 17 than the default [16:31:18] right [16:31:39] by using all the right numbers I am getting 46NM pericynthion [16:31:54] too low, but before changing parameters I got something in the 30s [16:32:03] what are the right numbers? [16:32:45] 170x51.3 [16:32:50] 60x13.17 [16:32:58] revs: 2.0 and 10 [16:33:01] I think it's 10 [16:33:07] SITEROT +10° [16:33:21] ok [16:33:26] Apollo 17 DOI does not happen at perilune [16:33:29] but LOI does [16:33:41] so this might be a case where REVS1 is not 2.0, but ETA1 is 0 [16:35:52] I can definitely get the pericynthion up that way [16:36:28] ah yes [16:38:33] but not enough really [16:41:50] there is one further fix the TLMCC targeting needs, although I don't know how much difference it is going to make [16:42:04] it is a bit difficult to implement, has directly to do with the generalized iterator [16:42:09] I'll try that next [17:08:32] morning! [17:22:39] hey [17:31:37] hey Mike [17:31:59] indy91, pre-Apollo 14 LOI's, I use plane solution, correct? [17:32:12] yeah [17:32:18] pre Apollo 13 [17:32:52] ah right [17:36:21] plane solutions gives you the desired orbital plane and the specified HA and HP exactly [17:37:03] right [17:37:59] and you should make it a 60x60 LOI-2 orbit for the right backwards propagation [17:40:03] I requested an Apollo 16 document from UHCL which might be interesting for all this [17:40:07] already scanned, 564 pages [17:40:16] I like the number of pages :D [17:40:32] but I don't really know what it is going to be [17:41:01] just tested Apollo 12 with the new LOI targeting [17:42:05] I haven't done much testing on the earlier missions yet, so there could be undiscovered bugs [17:42:21] TLMCC option 5, force LLS azimuth -75, and GET at node to achieve on-time LOI, then LOI plane solution 8 [17:42:40] LOI-2 and DOI are both on time [17:42:46] looking very good [17:43:07] nice [17:44:37] we have some saved LOI ellipse height inputs in various missions for the LOI targeting [17:44:56] yeah [17:45:07] I guess those should all be set back to 170x60 and 60x60/60x8 [17:45:10] same as we had before [17:45:16] probably [17:45:22] maybe not Apollo 17 [17:45:38] I set them back in all my tests [17:46:06] definitely not Apollo 17 [17:46:17] but at least Apollo 12 and earlier all 170x60 and 60x60 [17:46:18] yeah [17:51:46] did a test with the landmark tracking pad on Apollo 12, LS coordinates and 109:00:00 GET shows a crossrange error of 0.6 NM [17:52:16] for comparison that error used to be ~5 NM with the old LOI targetting [17:52:27] impressive [17:52:38] oh that's worse than I thought, haha [17:53:26] but Apollo 12 should be the worst mission when it comes to crossrange [17:53:32] well this is with a T1/T2 time of 110:11:15, about 20 minutes prior to landing [17:54:23] or maybe that is irrelevant [17:54:42] shows the cross-range for that pass I guess [17:55:24] but yeah, Apollo 12 was really bad for that [18:08:59] inyd91, option 2 has all the same new functionality as option 4 with regards to the LOI/DOI geometry? [18:09:12] indy91* [18:12:10] it should, yes [18:13:06] I think it would need some new values for the SFP though [18:13:32] yeah [18:21:32] for fun I am doing Apollo 12 with option 4 and an DOI as LOI-2 [18:22:58] works well [18:23:28] landing time is 40 minutes early but that is normal with being in the DOI orbit many hours earlier [18:23:50] yeah, probably [18:24:24] 3-4 minutes per orbit difference [18:24:28] that works [19:11:23] for Apollo 13 I found REVS1 1.96 [19:11:30] is that about what you got? [19:17:13] Hey [19:19:34] hey Thymo [19:19:58] AlexB_88, yep [19:48:44] I have some ARCORE constants fixes, notably the REVS2 correction for Apollo 16 and 17 in my copy, I can make a PR with them if you want [19:51:57] got tired of always manually changing them :D [20:01:33] sure [20:02:20] ok [15:12:05] hey [16:42:33] hey Alex [16:44:44] found a bug in the DVLOI2 calculation, as I had suspected [16:45:29] I forgot to include the Apollo 17 Pericynthion GMT fix in my PR last night [16:45:39] just made another one with it [16:47:14] merged [16:47:30] thanks [16:49:25] and I also have an update [16:49:46] with the DVLOI2 calculation, moved new LOI targeting to their own files and I added some online monitor messages from the LOI targeting [16:49:48] about the DVLOI2, nice find [16:50:09] great [16:50:11] the one they got a bunch of times on Apollo 13 is "pericynthion is above HALPO altitude" [16:50:29] when they had forgotten to add MCC-2 to the MPT, haha [16:50:48] haha [16:51:01] listened a bunch more to the FIDO loop, still nearly 12 hours away from MCC-2 [16:51:09] some good banter, but not much more about MCC-2 [16:51:48] the S-IVB APS thrusters always fire uncoupled [16:52:09] they noticed that in state vector tracking [16:52:09] they wanted to ask if the S-IVB did an attitude maneuver at the time [16:52:31] but the support people at Marshall had already gone home [16:53:01] so they made fun of them a bit "9 to 5 job" "that's why we only have daytime launches" [16:55:15] yeah [16:57:29] it's pretty much just the Booster flight controller in MCC-H doing anything with for the S-IVB [16:57:32] at 19h GET [16:57:40] slowly watching the S-IVB systems dying [16:58:59] sounds depressing :D [17:00:21] yeah, haha [17:00:55] im testing the updates now [17:02:05] for the plane solution, it might actually be helpful to see DVLOI2 being 0 [17:02:12] that can of course still happen [17:02:26] nonspherical gravity is taken into consideration [17:02:44] so a 170x60 at LOI TIG might not actually intersection with 60x60 at LOI-2 time [17:02:50] so you would want to lower the perilune a bit [17:03:01] less than 1NM needed definitely though [17:05:16] the LOI perilune? [17:05:29] yeah [17:06:41] only relevant for LOI-1/LOI-2 and the plane solutions [17:06:53] as the intersection solution perilune already takes that into account [17:08:01] I see the online monitor spits out a landing time [17:09:42] yeah [17:10:02] and the error that will happen every time in cislunar space [17:10:22] it tries to find the ascending node for some displays [17:10:25] FIDO orbit digitals I guess [17:10:48] happens every time on a trajectory update [17:10:55] which includes adding maneuvers to the MPT [17:11:01] you mean RMMASCND thing [17:11:03] yeah [17:11:14] maybe that should be disabled in cislunar space [17:11:20] but I am not quite sure [17:12:17] oh, and replacing maneuvers does work [17:12:20] at least partially [17:12:35] you don't have to remove LOI from the MPT every time you calculate it new [17:13:17] just re-calculate and re-add it to the MPT [17:20:05] some of the "move maneuver to MPT" MEDs have a replace option, others automatically delete every maneuver from the MPT that are before their TIG [17:20:30] and the actual LOI TIG is before the impulsive TIG of the new LOI you are adding [17:20:36] usually at least [17:20:41] unless the LOI TIG changes a lot [17:22:23] right [17:22:37] so the landing time display, includes DOI? [17:23:36] yeah [17:23:48] it's the time at the LLS from the backwards propagation [17:24:12] it's mainly a good check if you have e.g. REVS2 wrong [17:24:38] and that's time above the LLS without PDI [17:24:55] so not super useful to compare to PDI or landing time [17:25:02] just if it's in the ballpark [17:25:10] right [17:25:26] and what about the REV2 crossing time? [17:27:03] I'll try to add that next [17:30:23] morning! [17:36:31] hey Mike [17:40:09] what's up? [17:40:17] doing more testing with Apollo 16. Did you still have trouble with LOI DVZ? Because its showing pretty good numbers right now [17:40:51] a bit smaller then planned DVZ, im showing -197 fps [17:41:04] and DOI DVZ zeroed? [17:41:16] thewonderidiot, doing more tests with Niklas's new updates [17:41:18] yes [17:41:25] and everything on time [17:41:30] using what REVS1? [17:41:37] 1.88 [17:42:32] I used to think that was excessive, but it's the only way you can get a 71NM pericynthion [17:42:45] yeah [17:43:48] I still kind of believe the LOI DV calculation the MCC processor needs changes [17:44:02] but the changes I tried didn't really improve things [17:44:19] or worse, the LOI intersection solution gave weird results once [17:44:26] Although that might not be the fault of the MCC [17:45:10] my workflow for it right now: 1. Adjust REVS 1 so that H PYCN on midcourse tradeoff shows the correct height 2. calculate LOI+DOI and check DOI DVZ, then tweak REVS1 until its nulled 3. Tweak TLMIN/TLMAX for correct arrival time [17:45:14] works quite well [17:45:53] and most of that would be done preflight anyway [17:46:01] with some tweaking during the mission [17:46:09] the night shift FIDO gets rather bored [17:47:03] do you think specific REVS1,TLMIN,TLMAX values would have been pre-loaded? [17:47:16] I don't know about TLMIN and TLMAX [17:47:29] well [17:47:52] the Apollo 13 FIDO used some values from the get-go [17:48:04] maybe some from premission simulations [17:48:28] but REVS1 and ETA1 definitely [17:48:39] ok [17:49:14] I can figure out working values for REVS1 for each mission right now and then add them to ARCore [17:49:19] hopefully we find some document or audio that talks about this eventually [17:49:45] Apollo 13 won't be much of a help with that [17:49:47] sure [17:50:03] Apollo 13 didn't have the updated LOI processor and only some intermediate MCC processor [17:50:27] more manual tweaking during the mission than later flights I assume [17:50:32] with that done, it wont be much harder to calculate MCC-2 then it used to be with the old TLMCC [17:50:38] except Apollo 17 [17:51:10] no reply from UHCL yet. Which is unusual, they haven't needed more than a day to at least say "working on it" [17:51:31] I requested an Apollo 16 document which might or might not help [17:53:30] we need to creep Lauren's contact info, then beg her to come back :D [17:53:58] haha [17:54:11] well she was so good, probably has a better job now [17:54:18] regarding Apollo 17 [17:54:42] the Apollo 13 MPAD Support document had a passage about the use of the LDPP for DOI [17:55:06] it said it was feasible to use for Apollo 13 [17:55:18] but not for the originally planned next mission, Apollo 14 to Littrow [17:55:26] but it doesn't say what else to use [17:55:54] some creative use of the GPM might work [17:58:16] the desired orbit HA and HP together with a maneuver at perilune maybe [17:58:41] but that won't directly ensure the right perilune location [17:58:52] so you have to manually check and tweak [17:58:57] interesting [18:04:30] I mean, you have a specified perilune longitude in the SCOT [18:04:59] DOI TIG with input HA and HP needs to be tweaked until that has the correct value [18:05:16] and I am still sure Apollo 17 did no LOI orbit rotation [18:06:16] so REVS1 = 2.0 and ETA1 = 0.0 [18:07:07] ok [18:07:20] but then isnt pericynthion height too low? [18:08:12] well, the MCC processor doesn't like those inputs, yeah [18:09:47] im testing this now [18:10:28] GPM with code HBT I guess (Apo/Peri change & Time) [18:10:44] yeah [18:10:45] hmm [18:10:49] for Apollo 17 [18:10:55] TLMCC mode 5 maybe? [18:11:48] hmm [18:11:55] didnt think of that [18:11:56] there is a perilune MED input [18:12:04] is that implemented? [18:12:43] no and yes [18:12:51] not as a MED, but it uses the data table value [18:18:10] hmm, using TLMCC mode 5, only COPLANAR & MIN THETA seem to give valid LOI solutions [18:19:36] oh wait [18:19:50] mode 5 does not even use the backwards propagation [18:19:58] was just a crazy idea, haha [18:20:04] its because I forgot to force the -90 LLS azimuth [18:20:15] now it gives valid solutions [18:20:44] the node that MCC and LOI processors are finding might be different for mode 5 [18:33:56] so the DOI perilune longitude should be simply the LLS longitude + 10 degrees I guess [18:34:38] oh but I guess that doesn't take into account the 10 orbits that elapse [18:35:36] anyway, I found it in the SCOT as you said [18:37:18] yeah [18:37:31] FIDO Orbit Digitals calculates data for HA and HP [18:37:46] but that probably wouldn't work before LOI [18:40:24] the weird thing is, with REVS2 and TLMCC mode 4, and LOI on the MPT, when I get to DOI time (93:13:00) I am at 169 NM [18:40:48] but I should be closer to perilune if I want to have a DOI near that time [18:40:49] uhh [18:41:08] is something off by an hour? [18:41:31] hmm [18:41:38] unless this is my delayed scenario [18:41:45] but I didnt think so [18:42:12] what's the LOI time? [18:42:29] ohhh [18:42:46] stupid me I put the wrong TLMIN/TLMAX, wrong by 1 hour [18:43:11] yeah, sounded like it with DOI being at apolune instead of perilune :D [18:44:43] ok this makes sense [18:45:13] at planned DOI time DVX -188, DVZ +88 [18:45:17] now to tweak [18:46:26] LONG P, that should be what I need? [18:46:30] yeah [18:46:42] its directly on the GPM display [18:46:46] oh right [18:46:48] haha [18:46:49] of course [18:47:14] should be 20 E [18:47:22] right now its says 40.65 [18:47:38] that can change a lot with TIG change [18:49:01] ok so, one issue is that the TLMCC mode 4 really likes to sacrifice the LOI perilune altitude for the right DOI geometry right? [18:49:17] that's why the pre LOI pericynthion is also very low [18:49:47] so maybe for Apollo 17 only, playing around with the SITEROT parameter works to get the perilune right [18:58:28] trying that [19:02:56] oh I think that dis some good [19:03:00] did* [19:05:57] so DOI 2 minutes late, LONG P 20.01, 60x13.17 and DVZ is +79 [19:06:08] maybe just a bit more tweaking [19:06:20] but I used a SITEROT of 27 [19:13:26] so SITEROT of 30 makes DOI on-time, DVZ of +45 [19:13:37] and the SCOT DVZ is ~+50 fps [19:13:42] for DOI [19:28:36] the only thing is my post-LOI perilune is 55 NM [19:33:26] too high :D [19:36:22] yeah [19:36:31] well at least we're close [19:39:28] "we lost the platform, we lost the LVDC and we got rates of 2.5°/s" [19:39:31] sounds healthy [19:43:07] and APS thrusters still firing. The tracking people love it...not [19:46:32] thought you were talking of Apollo 12 for a sec there :D [19:46:42] but of course they didnt lose the LVDC [19:49:53] yeah [19:50:02] just one accelerometer was a bit bad afterwards [19:50:17] although they couldn't say if that really was due to lightning [19:50:34] but this was of course from the Apollo 13 FIDO audio, nearly 20h GET [19:52:49] right [20:39:41] alright I've got the REVS1/ETA1 for Apollo 13-16 almost ready [20:39:56] wont bother with 17 right now [20:44:32] if the document I requested from UHCL is good, there is the same one for Apollo 17 also [20:45:50] and some others which might or might not be helpful [20:52:15] PR sent [20:56:46] merged [20:57:33] thanks [20:58:14] as of now you should get a valid MCC-2/LOI without any input changes up to Apollo 16 [20:58:44] you just need to maybe adjust the node GET to get the proper times [20:58:57] but at least a new user will not be too lost haha [21:00:40] yeah [21:01:05] I'll write some chapters for the RTCC MFD manual before this gets merged back into dseagrav/Orbiter2016 [21:01:17] but it's getting close now to that I guess [21:01:59] yeah, now that DOI as LOI-2 is working again [21:02:34] flight dynamics OFFICERS APOLLO 14 POSTFLIGHT REPORT [21:02:41] that would be interesting [21:03:03] let me know if you want me to make some requests [21:03:23] yeah you can request that one, haha [21:03:30] sure [21:04:27] so I have found that the constants we have work quite well even for off-nominal cases like dispersed trajectories (my manual TLI) and launch delays [21:04:56] good to know [21:05:15] at least for option 4/5 [21:08:06] yeah [21:08:12] "09/28/1976 ON ORBIT SOFTWARE SCRUB " [21:08:18] this is a sad day [21:08:39] pretty sure this document would be about all the fun programs being scrubbed from the Shuttle onboard software [21:08:51] they were as ambitious as for Apollo [21:09:13] and equally could not get all they wanted into th ememory [21:10:45] oh no [21:10:49] I didn't know it happened to them too [21:12:17] yeah, MIT wrote some early memos with very ambitious programs [21:14:32] Orbital Maneuver Processor [21:14:36] giant rendezvous program [21:14:53] that is the same name as the program they used in mission control later [21:14:56] so maybe it is related [21:15:20] Orbital Maneuver Processor (OMP), JSC-09339, Revision 1, July 1975 [21:15:24] now that is a document I want to find [21:15:32] I have a flow chart of onboard software [21:15:34] the next item is [21:15:38] SCRUB [21:16:00] and what follows is rendezvous capabilities barely more than Apollo 7 [21:18:31] flow chart of onboard rendezvous software history that is [21:19:21] aha [21:19:33] "On-board OMP did not [21:19:33] become actual software requirements due to the 1976 [21:19:34] software scrub led by Apollo 13 astronaut Fred Haise. [21:19:34] The 1975 on-board OMP algorithms did form the basis of [21:19:35] a later version of OMP used in Mission Control for [21:19:36] targeting burns during the Shuttle Program." [21:19:41] why Fred [21:20:06] damnit Fred [21:20:45] UHCL has the document! [21:20:53] already scanned even [21:21:01] JSC-09339 Preliminary Detailed Requirements for the ORBITAL MANEUVER Targeting Module for the Orbiter Onboard Computer, Revision 1 * This 302 page document has been scanned Section 056 1 * July 11, 1975 [21:21:36] wow, this is going to be gooooood [21:22:26] now they just need to get back to me for my request from yesterday for a document that is already scanned... [21:22:52] alternately I would also take direct server access to the documents already scanned [21:23:13] oh man that would be great [21:32:59] who knows, maybe they even planned to put the Analytic Ephemeris Generator into the Shuttle computer. Very useful for rendezvous calculations, very bad on your fixed memory [21:39:35] I forgot to add something else to ARcore that I wanted, TLMCC AZmin=AZmax for Apollo 8,10,11,12 [21:39:55] for mode 3/5 [21:41:20] ah [21:41:24] well, feel free [21:44:52] PR sent [21:51:36] merged [21:51:44] have you already send the request for the Apollo 14 document? [21:52:09] ill do that right now [21:52:12] no stop [21:52:22] would you mind adding the Shuttle rendezvous document to it? :D [21:52:36] sure [21:52:39] great [21:52:44] it's in the archive search [21:53:02] just look for JSC-09339 [21:53:21] and of course mention that it's already scanned [21:53:53] I'm sure they would know that as well before starting to do scanning, but you never know :D [21:54:39] so 71-FC54-27 [21:54:55] yeah, I think that was the other one [21:56:13] so to archives@uhcl.edu [21:56:34] yep [21:56:53] with all the info on the document, box, title etc. [21:56:56] you know the drill [21:57:16] also I have left out the box number on my latest request, as that has already been scanned, too [21:57:31] I just copy/paste the full format into the email haha [21:58:00] yeah, I format it slightly, but the same full info, haha [21:58:47] I don't usually fix the weird mixture of upper case and lower case letters though [21:58:51] in the title [21:58:54] way too much work [22:00:18] so only JSC-09339 is scanned? [22:03:14] ah, there is a way to tell if it's been scanned or not actually [22:03:40] in the history search, there is an asterisk next to the location [22:03:44] right [22:03:50] request sent [22:03:57] 079-43 [22:03:59] not scanned [22:04:00] 079-43 * [22:04:03] already scanned [22:04:20] in the archive search, and sometimes in the history search, it sometimes says it in the title [22:04:36] so yeah, the Apollo 14 one had been not scanned yet [22:04:53] JSC-09339 has been scanned, 302 pages [22:04:58] I have a predecessor of that document [22:05:00] from 1973 [22:05:08] 59 pages :D [22:05:11] it grew a "bit" [22:05:27] barely more than the Skylab rendezvous profile in that 1973 document [22:05:52] thanks for the request! [22:06:04] hopefully the Apollo 14 document helps us a bit [22:06:17] good night! [17:25:29] morning! [17:27:13] hey Mike [17:28:21] heard anything from UHCL? [17:32:29] I have the feeling a certain virus might be the reason why there is no reply [17:33:05] Ron is also in almost the only NARA facility that is still open [17:33:47] sent him some LOI display pictures [17:33:50] oh yeah, that could be it [17:34:28] my favourite part of his reply was this: "Your doc took 5 minutes; Mike's took 3 hours." [17:35:02] hehehehe [17:35:20] sorry Ron [17:35:32] but I do think it was worth it :P [17:35:42] I think he said that with the two docs I requested before that as well [17:35:51] might have to ask for a CSM Data Book or something next [17:36:11] Operational Trajectory Volume II Trajectory Parameters is also usually nearing 4 digit pages [17:36:16] for the time being I'm out of things to ask for from Ron [17:36:21] yeah same [17:36:45] although the Apollo 11 version of the operational trajectory that shows RR shaft and trunnion angles would be really great to have [17:36:53] right [18:47:40] Hey [18:48:09] hey Alex [18:48:17] any reply from UHCL yet? [18:48:38] nothing yet [18:48:59] I have the feeling that could take a while [18:49:12] UHCL is not even having classes anymore this month [18:50:24] thanks Corona [18:52:02] indeed [18:52:39] and now it’s even got Tom Hanks! [19:07:45] at least he didn't get the measles [19:11:43] found another case where the DVLOI2 isn't calculated on the LOI display [19:11:47] and [19:12:02] there is one thing I hadn't added yet to the display [19:12:14] during the Apollo 14 simulation run it showed this [19:12:19] "RA-RP GT 10.0" [19:12:29] I'm not entirely sure what it means [19:12:50] there are some tolerances used in the LOI processor without values given [19:13:10] one tolerance is for the intersection of the LOI1 and LOI2 orbits, for the DVLOI2 calculation [19:13:19] maybe this is it? [19:13:29] I used 1 meter so far [19:13:40] with the display value it would probably be 10NM, haha [19:14:08] Hmm interesting [19:14:19] the tolerance is between two radii in that function [19:14:24] not directly RA and RP [19:14:35] but it could be under ideal circumstance [19:14:44] RP of LOI1 orbit, RA of LOI2 orbit [19:14:53] would be the same [19:15:10] without DOI orbit rotation [19:15:30] the value of 10NM definitely ensures that DVLOI2 is being calculated for all reasonable cases [19:15:43] so I am inclined to use it like that [19:15:53] the LOI document doesn't list this as an input [19:16:09] but that doesn't have to mean too much [19:23:12] oh and something funny from the Apollo 13 FIDO loop [19:23:22] FIDO and BOOSTER talking about Marshall again [19:23:54] same thing as yesterday, nobody there in the night, 9 to 5 job, that's why we only have daytime launches [19:24:22] suddenly the voice of Gene Kranz "that is being lenient" [19:24:39] that came rather unexpected :D [19:25:42] haha [19:25:51] Gene was the Flight Director of the shift, but I had heard him maybe once or twice the whole shift on the FIDO loop [19:27:09] those Marshall guys don’t seem to get a break lol [19:27:17] oh they get lots of breaks [19:27:18] all night [19:27:29] true haha [19:27:54] they also ran the program to generate new descent abort constants but had some trouble with it. Not the FIDO, but his backroom people [19:28:04] FIDO's comment: That is already two unexpected things [19:28:27] trouble with the descent abort constants calculation and an abort being necessary being the other one [19:28:38] well, we know how that turned out... [19:29:19] right [19:30:34] maybe 8-9 hours to MCC-2 [19:30:47] I'll continue with the FIDO loop until the explosion I think [19:30:55] should still be some interesting things for LOI etc. [19:31:14] yeah [19:31:28] the FIDO said he wants to try (for the first time) to generate some nominal Maneuver PADs for the mission through descent in his next shift [19:31:41] if he manages to do that then it would still be before the explosion [19:31:45] could be interesting [19:32:32] the Apollo 13 in Realtime website will go live tonight btw [19:32:42] with all the audio and videos and transcripts etc. [19:33:03] Oh nice [19:33:09] https://apolloinrealtime.org/ [19:33:18] Including what you’re listening? [19:33:21] yeah [19:33:31] same as they did for Apollo 11 [19:33:36] digitized all the MCC audio [19:36:18] I'm sure they will do all the Apollo missions [19:36:25] but it will take years [19:38:22] I would bet on either Apollo 14 or 17 next [19:38:35] 17 because they already have the Apollo 17 in realtime [19:38:41] just not with the MCC audio [19:38:48] and 14 would be chronological [19:39:13] in either way, probably not to be expected before the anniversaries of those missions [19:51:39] I guess 17 would give some good clues on the LOI targeting inputs [19:53:13] yeah, I think so [19:53:37] and 14 to 17 would all help in a different way as 13, as the MCC and LOI targeting we now have applies to those missions [19:55:45] I did find that messing with SITEROT in the LOI targeting seemed to help for 17 [19:56:09] yeah [19:56:40] it's going to slightly make the orbit plane worse, so crossrange at the landing site [19:56:46] probably a very small effect though [19:57:03] the MCC targeting really likes to sacrifice the LOI perilune altitude for the right geometry [19:57:06] Right [19:57:21] so getting that to the desired value really can only be done by manipulating the SITEROT [19:57:40] there is one improvement for that coming some time, but it won't change much [19:57:46] it's a little complicated to do [20:04:34] I have to run, cya! [20:05:17] cya [20:05:27] an checked my email again but still nothing [20:05:33] cya [20:11:13] ohhhhhhhhhhhhh man [20:11:19] I just made a big discovery [20:11:44] you know Icarus Verilog, the logic simulation tool I use for the AGC hardware sim? [20:12:10] https://i.imgur.com/VMybLEl.png [20:12:13] sure [20:12:24] waves [20:12:29] I just learn that it can do real numbers and trig functions alongside the digital logic [20:12:41] sounds useful [20:12:41] I'm going to be able to simulate the entire CDU in this thing [20:12:49] :D [20:12:49] aaaah, nice [20:13:18] because I can break down the coarse system module into trig functions very easily [20:13:38] yeah [20:14:18] and the FAZxHI signals I have shown there are all coming out of the CDU's NOR logic :D [20:14:30] this is gonna be great [20:18:22] so is it just a big simplification of the simulation or would it not have been possible to simulate the CDU in full before you discovered that? [20:18:36] not really possible, without building it [20:18:41] I'm still going to build it of course [20:18:50] but now I can also simulate the whole thing :D [20:57:34] night! [17:13:50] morning! [17:21:10] https://i.imgur.com/NwbkZLv.png [17:21:19] CDU sim is progressing quickly [17:21:25] hey [17:21:32] I don't have a read counter yet, but I do have enough of a digital mode module to support a single channel [17:21:34] looks great :D [17:21:38] and a mathematical model of the coarse system [17:21:55] that is me manually setting coarse system switches to null the sum (ATLC1H stops wiggling), and then going too far [17:22:23] and you can see that the read counter logic wants to count up (AUPLVL = 1) up until the point I go too far, and then it wants to count down (ADNLVL = 1) [17:22:24] :D [17:22:52] that's what it should do, hehe [17:23:21] I need to trace back through some error counter & logic module stuff, but then tonight I should be able to start putting in the read counter [17:24:23] guess I can try implementing the OCDUs again soon, now that I have someone to ask questions to [17:24:29] hahaha yeah [17:24:47] https://apolloinrealtime.org/13 [17:24:49] it's up! [17:24:55] and now that I have a hardware simulator, I can expand this out to include the full error counter and digital-to-analog bits too [17:25:00] oh nice! [17:26:18] GUIDO loop might be interesting to you [17:26:53] what are they talking about? [17:27:11] uhh, I meant in general [17:27:31] haha [17:27:36] well then, what do they generally talk about? :P [17:27:39] I am sure they talk about many interesting things in the full mission :D [17:27:59] GUIDO is responsible for the AGC [17:28:53] I've been listening to the first 20 hours of the FIDO audio in the last few weeks [17:29:16] and when the Apollo 11 audio became available I did the same for that mission [17:29:36] GUIDO is the person who will talk to callsign AGC the most [17:29:50] the support person directly responsible for the AGC [17:30:34] nice, I'll have to check it out [17:30:35] Jack Garman was "AGC" during the Apollo 11 landing [17:30:51] the explosion happened at an annoying time [17:30:58] heh [17:30:59] close to switchover time from Earth to Moon reference [17:31:17] so one thing they talked about early on is if RTCC and AGC are compatible with their reference switch [17:31:26] normally during that time you wouldn't uplink a state vector [17:32:21] the only issue would be accuracy. If the AGC gets a state vector in the wrong reference (Earth vs. Moon) it should do the first integration step in that reference and then switch [17:32:22] I think [17:33:20] if you are in LPO and get an Earth referenced state vector the state vector might be totally screwed up though [17:34:21] I could see how that would be really not great [17:35:51] GUIDO loop might be especially interesting during Apollo 11 after landing until ascent [17:36:01] they probably try to figure out what went wrong [17:36:13] on Apollo 13, hmm, not sure [17:37:29] the time after the accident will be interesting on any loop, haha [17:38:52] the AGC audio isn't separately recorded unfortunately [17:39:00] I bet you would get phone calls with MIT on there [17:42:09] ahhh that's too bad [17:42:13] those would be great to hear [17:43:54] even COMP SUP audio was recorded [17:43:59] usually called "computer soup" [17:44:04] in charge of the RTCC computers [17:44:18] but not the AGC audio [17:44:38] :( [17:49:34] there are two GUIDO channels though [17:49:41] on one of them AGC is very clear to hear [17:50:02] in one case he isn't even talking to GUIDO [17:50:14] sounds promising, but I'll have to listen to it some more [18:21:56] https://archive.org/stream/apertureCardBox523NARASW_images#page/n466/mode/1up [18:22:00] LM-3 top-level drawing [18:22:07] next box will get us LM-4, whenever that happens [18:24:14] very nice [21:33:10] night! [16:48:05] morning! [16:54:40] hey [16:56:11] what's up? [16:57:45] making the RTCC MFD less Orbiter API dependent [16:57:49] and you? [16:58:14] working on the read counter logic [16:58:27] I found something annoying in the CDU logic last night [16:59:08] https://i.imgur.com/t5gvUEX.png [17:00:19] hmm [17:00:22] ATPCA = system sum, ATPC1 = coarse ternary level, ATPS = selected error signal, ATPPI = read counter input [17:00:34] this simulation is me nulling the sum in the coarse system [17:00:41] but the read counter still counts at max rate forever [17:01:06] reading through the logic, as far as I can tell, the coarse system by itself doesn't know how to stop counting [17:01:22] in order for the read counter to stop incrementing at max rate, you *must* transition over to the fine system [17:01:34] which means that I have to model that now too [17:01:52] how does it switch to fine align? [17:02:10] isn't that software controlled? [17:02:20] nope, not on the analog to digital side [17:02:28] ah right, A/D [17:02:55] when the coarse sum gets below 0.56Vrms (which is about 8.4 degrees on the shaft), the coarse system is nulled and the ATPC1 signal goes away [17:03:20] at that point it is apparently not only possible, but required that the fine system is still producing one of its two error signals, ATPF1 or ATPF2 [17:03:52] and the read counter logic will automatically switch over to using that as the source of increments instead [17:04:52] right [17:05:07] so you have to implement the read stuff all at once to really be able to test it [17:05:12] yeah [17:05:28] but the fine system is complicated as hell [17:05:45] so I'm just putting in the read counter gates now since I have a signal to make them count, heh [17:07:27] I mean, it's looking like it is properly working [17:07:30] it just never stops working [17:10:16] hahaha yeah [17:10:33] what's going to happen, I think, is that it's just going to bounce back and forth around the right angle [17:12:03] sounds like my attempt at using our CDU implementation for the OCDUs [17:12:10] hehehe [17:12:15] in the opposite direction of course, D/A [17:15:19] all this CDU talk really makes me want to attempt and implement that again [17:15:36] I had more RTCC than I can handle anyway [17:15:58] hahaha [17:16:17] it's probably going to be a few days at least before I can get to the error counter and D/A side [17:16:39] but sure, I also really want to implement those now that I have a hardware sim :D [17:17:13] I think you said before the configuration differences between the different CDU types were done only with some jumpers, right? [17:18:03] same modules, different backplane wiring [17:18:15] the read counter actually has a bunch of backplane wiring differences that I don't understand yet [17:24:52] alright, here we go [17:25:11] each bit of the read counter is 10 nor gates and I have my first group of 10 done [17:25:15] let's see if it toggles :D [17:27:10] each bit is 10 nor gates, that's an interesting solution [17:28:13] well, it has to be able to count up and down, and make the next stage correctly count up or down [17:28:22] right [17:29:07] the DECA probably has something like the CDUs for the throttle commands [17:29:18] Descent Engine Control Assembly [17:29:56] bunch of flip-flops [17:30:51] yep [17:32:38] cool, it's toggling with each PIHI all right :D [17:36:38] and since it's 10 gates, and they numbered them consistently, it's very easy to add new bits [17:36:48] just copy paste the block of 10 and increment all of the numbers by 10 :D [17:37:36] two-bit read counter works! [17:39:55] such high resolution [17:52:58] up to five bits... [17:58:08] 8 bits, halfway there :D [18:02:59] I'm surprised they didn't want to run this faster than 51.2kHz [18:03:06] the coarse system is really not fast haha [18:12:39] how many degrees per second would that be? [18:12:56] mm [18:13:03] well, it counts at 12.8kpps [18:14:57] each bit is 0.0055 degrees [18:15:21] so, 70.4 degrees per second [18:15:58] plenty fast [18:18:47] 15 bits working [18:18:52] 16th bit is wired differently [18:20:14] I bet it is [18:20:16] and then it's just a small handful of gates for the coarse logic and it should do nulling on its own :D [18:25:59] alright, read counter itself is done [18:32:55] I hate COVID-19. College shutdown, work from home, all social activities cancelled. [18:33:00] And worst of all [18:33:03] No toilet paper! [18:34:03] then you didn't hoard toliet paper, or not early enough! [18:35:11] Of all products, why toiletpaper???? [18:35:51] I mean if it was, I don't know, pizza. I'd understand. [18:36:03] But who in hell needs this much toilter paper? [18:36:10] one person started a rumour, everybody starts buying [18:36:28] They don't even have enough food stocked in their home to generate enough shit to use it all! [18:37:11] well in one year without toilet paper production they will the ones laughing! [18:37:36] at least it's not some perishable food that gets wasted [18:38:22] I suppose [19:01:12] okay, read counter is fully hooked up to the coarse system [19:01:18] let's see how horribly wrong this goes :D [19:01:56] lol, so far not good [19:08:02] uhhhhhhhhhhhh [19:08:13] wow it counted the wrong way I think and then just went haywire [19:08:14] hmm [19:08:39] sounds like it went horribly wrong [19:09:12] ohhhh I think I have the switches inverted [19:09:45] yeah that would do it [19:11:36] it works!! [19:12:32] https://i.imgur.com/tqfhRO8.png [19:12:44] that is it nulling the sum (ATPCA) succesfully! [19:13:09] now, what was the read counter when it finished [19:13:16] I have the shaft angle set to 67.5 degrees :D [19:13:48] awesome [19:13:55] speaking of things that go horribly wrong [19:14:31] now that I have an easy way of switching AGC versions and now that I am a bit tired of RTCC stuff it is time to activate Terminus [19:14:45] uh oh [19:14:54] yeah that is definitely going to go terribly wrong :D [19:15:10] found a good scenario before LM activation [19:15:15] Apollo 17 [19:15:30] it will need some padload fixes [19:15:37] and then I'll apply power [19:21:57] hmmm [19:22:06] my read counter appears to have settled on 105 degrees [19:22:10] which is not quite 67.5 [19:24:31] hmmmmm [19:24:46] it's going backwards through the switches [19:28:24] lol, wtf is going on [19:32:01] bad things apparently :D [19:33:16] time to activate the Challenger [19:34:40] hmm [19:35:10] I thought we had the Apollo 17 LM Activation Checklist [19:35:42] I thought so too [19:35:55] UHCL definitely has it, haha [19:36:04] already scanned even [19:36:18] but that doesn't help right now, or in the next time... [19:38:11] uhh [19:38:15] I think my scenario is old [19:38:30] there is no LM ECS :D [19:38:42] guess I have to pump it full of oxygen first [19:38:50] at least it isn't an outdated LM ECS [19:39:13] hahahaha [19:39:18] that is very old :D [19:39:42] from mid 2017 [19:46:36] maybe my square wave reference from the interrogate module shouldn't be inverted [19:48:12] hell yeah, there we go [19:48:16] it counted up to 68 that time :D [19:51:17] great [19:54:00] this still feels wrong though [19:54:10] I'm pretty sure this signal is supposed to be inverted [20:00:10] man I feel like you right now [20:00:19] there are many places in here where I may have gotten a sign wrong :D [20:03:43] maybe I shouldn't be inverting the resolver outputs [20:05:36] well, V35 works in Terminus [20:05:40] so much I can already say :D [20:08:44] hahaha it would be bad if I broke that :P [20:09:59] and self test passed [20:11:36] also good haha [20:11:46] okay I think my coarse ternary level signal was inverted [20:11:49] now it looks way happier [20:12:09] let's give it a more challenging angle than 67.5 :D [20:34:05] hmmm [20:34:24] trying to get it to find 169 degrees [20:34:36] which triggers the ambiguity detector and that works to bring it around to 225 [20:34:37] sounds more challenging [20:34:45] but it gets stuck before it makes it below 200 degrees [20:37:15] fun [20:41:00] oh wait am I missing a sign flip on S9? [20:41:10] the ladder seems to be able to overpower the primary coarse switches [20:42:36] oh or are all of the rest of the ladder switches inverted [20:44:25] you do sound like me, when I implemented the transistors and logic gates for the CSM Electronic Control Assembly [20:44:28] hehehe [20:44:54] I think I had the signs on switches S10 through S12 wrong [20:44:57] it seems much happier now [20:45:02] let's see what angle it found... [20:45:33] 177.15 degrees [20:45:46] just within the 8.4 degree accuracy of the coarse system :D [20:46:32] works as designed then [20:49:01] yeah this is fully working now :D [20:51:36] awesome [20:53:51] hell yeah [20:53:57] a working CDU simulator :D [20:56:16] a working CDU read counter simulator :D [20:57:52] haha fair [20:58:03] but great job so far, haha [20:58:07] thanks! [20:58:24] I actually think that this is at a point where I can give it a SLEW/AUTO TRACK reading and watch what happens [21:00:44] oh slew/auto track? [21:05:11] yeeaaah [21:05:24] let's start off with an 11 degree phase difference [21:06:05] okay, nulled it [21:06:07] let's see... [21:07:04] hmm [21:07:12] I got a restart [21:07:15] during the RR test [21:07:31] I have a very vague memory that I got something like that in Zerlina... [21:08:01] ouch [21:08:09] more of it when I do the V63, part of the test [21:08:13] whelp [21:08:14] together with a program alarm [21:08:16] lol [21:08:22] 21501 [21:09:03] it worked normal on the second attempt though [21:14:45] weird [21:14:52] also, the CDU most definitely does not like this [21:15:09] where are the circuits that generate up and down counts to the AGC... [21:17:07] hmmmm [21:22:16] OH weird [21:22:25] they go out through the D/A module [21:22:29] no wonder I haven't seen them [21:22:48] haha [21:22:53] so it's kind of D/A/D [21:30:57] okay the digital version comes from the error counter module [21:31:06] and I already had the gates integrated into the sim [21:31:21] so with my current settings, the CDU gets stuck pulsing 4 bits in one direction and then 4 bits in the other [21:34:40] ok done with the Apollo 16 LM Activation Checklist, now I can use the proper checklist [21:34:45] Apollo 17 LM Timeline Book [21:34:48] there is a DOI-2 [21:34:54] might be the first real test for Terminus [21:45:19] uh oh [21:45:25] lol [21:46:20] bad alarm when starting P47, but it might be my fault [21:48:52] a flag was set wrong [21:48:57] pretty sure I set it correctly earlier [21:49:04] one of them few you set manually [21:50:06] hmm [21:50:21] V82 (apoapsis, periapsis height) also gives bad numbers [21:50:26] might also be my fault though [21:54:36] hmmm [21:54:40] I still have a sign error somewhere [21:56:23] put in a temporary fix, and now it should switch between fine/coarse as expected [21:56:41] and now hopefully the RR behavior will be imore interesting [21:57:01] ok, I found a definite Terminus bug [21:57:32] because when I reload the scenario with Luminary210, after clicking away a program alarm, I get the expected result [21:58:08] and I might be able to track down the bug quite precisely [21:59:51] it's in R30 btw [22:03:49] ok, not that easy, haha [22:04:14] hehehe yeah [22:05:24] the orbital parameters it displayed almost looked to me like it was calculating them for Earth orbit instead of Moon orbit [22:05:58] but the relevant part of the R30 code is identical in Luminary 210 and Terminus [22:06:18] don't think the issue is in the coasting integration routine [22:06:30] that would have screwed up the state vector earlier already [22:08:54] hmm, right now I am only getting moderately annoyed CDUs, not manic CDUs [22:10:10] so progress [22:10:35] sort of [22:14:35] hmmm [22:14:43] maybe it needs to be out of phase just enough [22:14:59] enough to throw off the sum but not the coarse detector [22:19:07] wow this is tricky [22:19:23] if I have this modeled right, getting the alarm-causing condition is way harder than I thought [22:19:37] damn [22:20:09] oh, and I couldn't prove my theory that R30 used an Earth orbit parameter by accident [22:20:19] might still be the case, but I don't know [22:21:37] darn [22:22:21] it basically should show me in a 60x15 orbit [22:22:25] and Luminary 210 does so [22:22:38] Terminus shows 1000 x -400 or something like that [22:23:22] ouch, that's pretty bad, haha [22:26:10] afternoon [22:27:45] hey Alex [22:27:58] no news from UHCL yet unfortunately [22:28:17] same [22:28:23] I wouldn't expect anything anytime soon [22:28:45] we can try again when people buy toilet paper normally again [22:29:37] thewonderidiot, V83 works fine, which requires many of the same things being correct, state vector etc. [22:29:44] just an V82/R30 issue [22:29:57] strange [22:32:28] ok, got to undocking, will continue from there once we found the issue [22:32:48] good night! [22:57:34] thewonderidiot, the logs tell me you had some CDU success, nice! [22:58:42] a bit! :D [22:58:59] still haven't succeeded in recreated the Apollo 11 problem [22:59:05] which I thought would be easy [23:00:41] ahh I'm close [23:00:49] I have an unnullable sum but the coarse error isn't being detected [23:02:44] sounds promising [23:03:26] hmm [23:04:00] so the most vulnerable angles are probably those with S9 set but no other ladder switches [23:05:32] since S9 is the biggest 28vrms reference contributor [23:11:23] alright well [23:11:37] I'm gonna let this sit for now and start working on a math model of the fine system [23:14:03] is this working connected to an FPGA/Virtual AGC? [23:17:38] nah, this is just a standalone simulation right now [23:17:44] equivalent to my AGC hardware sim [23:18:30] right [00:37:09] man the CDU is an inconsistent sign disaster [00:56:37] I'm having a hard time following but [00:56:53] I think the CDU Zero discrete might actually force the read counter to all ones instead of all zeroes [01:07:29] cant say I haven't been screwed by a bad sign before :D [01:14:27] if I'm right about that then I have at least 3 sign errors in here :P [01:18:48] good luck with that, night! [06:56:25] ahhhhhhh I think I may have found my sign [06:56:55] I think that the description in ND-1021043 is bad, and the summing amplifier in the coarse system module might be inverting [07:22:59] yesss I'm almost positive that's it [14:37:40] hey [14:47:59] hey Alex [14:48:19] well Terminus worked ok yesterday until undocking, then the problems started, haha [14:49:27] did a bit more RTCC work, some internal restructuring [14:49:46] also, with every MED input, the online monitor now writes a message if the input was successful or not [14:50:07] so if something unexpected happens there you can at least see if the input worked or not [14:53:59] sounds convenient [14:57:32] that's what the real RTCC does as well [14:57:47] and I think it also would give a little more information about any wrong input [14:58:02] like if you used an input value out of the allowed range [14:58:16] then it would say something like "input 3 was above the upper limit" or so [14:58:39] happened on the Apollo 13 FIDO loop [15:00:44] yeah, I listened to it a bit last night [15:01:18] ah nice [15:01:41] it took me quite a while to understand much what was being said when I first listened to it [15:06:46] at least on the FIDO loop [15:06:58] especially all the talk about tracking and state vectors [15:07:07] lots of unknown (to me ) acronyms etc. [15:08:46] oh and right now I am working on the iterate option when moving a maneuver to the MPT [15:09:19] you might have noticed that LOI usually gets a 169.6NM apolune or so on the MPT [15:09:37] that's because the iterate option uses my own implementation that we have been using for a long time [15:09:53] works quite well, but is not 100% accurate for a long burn like LOI [15:10:04] so I am now finally implementing the real RTCC method for it [15:32:11] ah [15:33:17] what my old method couldn't do is accounting for ullage or less than 100% DPS thrust [15:33:50] there the improvement will be more significant than that 0.4NM difference in LOI [15:34:24] right [15:34:27] so listening to the FIDO loop near MCC-2, it seems there was a bit of discussion on adjusting the perilune to have a zero z-dot for DOI [15:34:31] interesting stuff [15:35:00] LOI-1 perilune* [15:35:05] yeah [15:35:09] well I have been listening to the whole FIDO loop until about 22h GET by now [15:35:21] and I guess the approach node height [15:35:22] and of course a bunch of talk about that already [15:35:46] but I'm sure closer to MCC-2 there will be some more talk of it [15:35:53] ah sorry dont want to spoil it for you :D [15:35:56] haha [15:36:03] what timespan did you roughly listen to? [15:36:18] 28:20 to 29:00 about [15:37:27] yeah, that's probably where the final inputs are done [15:37:40] last tracking vector is done [15:37:50] and then a final calculation [15:38:15] it seems they really had to manually adjust the heights for the proper ellipse rotation [15:38:25] and probably didnt have a REVS1 parameterÉ [15:38:30] ? [15:39:40] there is a separate set of RTCC Requirements for the TLMCC for Apollo 13 [15:39:50] intermediate solution for the DOI geometry [15:40:04] and the LOI targeting was still the same as in the previous missions [15:40:26] we don't have those RTCC Requirements [15:40:40] but I have not heard any inputs for REVS1, REVS2 or so [15:41:10] only the constraint on the pericynthion [15:41:20] which I don't know how they did that [15:42:45] in the previous TLMCC targeting the optimization was allowed to choose the pericynthion height [15:43:13] kind of the same in the Apollo 14+ targeting, although there the node is strictly constraint to happen at the right height [15:45:30] in mode 5 of the Apollo 14 and later targeting you can specify a percynthion height directly [16:50:29] I think Ill fly a mission to test the new TLMCC+LOI & LOI/DOI geometry [16:50:54] so Apollo 13-16 [16:51:12] probably 14 [17:15:25] maybe this time Apollo 14 with a launch on time :D [17:18:40] oh I wouldn't count on that :p [17:18:55] but yeah I think I am due for an on-time launch :D [17:19:54] it's a trick, you are going to launch Apollo 11, July 18 launch window... on time [17:23:57] ah yes I forgot about that one [17:24:03] They just shut down all primary and highschools, all restaurants, cafés, bars and sports venues and all higher education has been suspended till the 6th of April. [17:33:27] strange times [17:53:45] morning! [17:54:29] Thymo, sounds like a good time to get back into NASSP :D [17:59:44] hey Mike [18:01:49] yo [18:02:17] how's the CDU doing [18:02:35] I think I finally tracked down my sign errors [18:02:46] so now I'm back to the fine system [18:02:55] ...and am dealing with new sign problems [18:04:49] part of my problem is that they define low voltage as logic high, and high voltage as logic low [18:05:00] which is mind-bending in the documentation when trying to figure out which they are talking about [18:06:53] haha [18:07:17] if you get frustrated you can fix Terminus bugs instead. Surely that is less frustrating :D [18:07:23] hehehe [18:10:07] Yeah, it's been a while. [18:10:34] I take it you're working on a CDU implementation for yaAGC, thewonderidiot? [18:11:49] nope, CDU hardware sim [18:12:23] it may eventually transition into something like that, but for now this is verilog simulation [18:13:17] What toolchain do you use for your FPGA development? College wants me to work with Quartus II from Intel but it is proprietary and works like crap. [18:13:50] haha, Quartus isn't so bad, there are much much worse [18:13:57] it's one of the better ones, I think [18:14:09] I've been using Vivado for my Zynq board recently [18:14:56] but for the hardware sims, it's all (currently) non-synthesizable software verilog sims [18:15:06] I use Icarus Verilog + GTKWave for that [18:16:45] Do they work with VHDL too? [18:17:08] no idea [18:17:16] so far I've successfully avoided VHDL [18:17:56] They teach it here, and they claim Verilog is more of an US thing and VHDL is Europe and the rest of the world. [18:18:05] Not sure if that's true [18:18:40] huh, I've never heard that [18:18:58] mostly what I've heard is that Verilog is to C as VHDL is to assembly [18:19:14] and over here SystemVerilog is starting to really take over as the industry standard [18:21:19] I've also heard the comparison of Verilog->C and VHDL->Pascal [18:27:15] my new favorite thing with icarus verilog is that it lets me have real-valued signals and supports trig functions on them [18:27:34] so while I have to do math models of circuits instead of actual component sims, I can do mixed analog/digital [18:29:07] https://i.imgur.com/Nh1yOXW.png [18:29:29] that's the current CDU sim holding around an angle [18:30:01] read counter value at the bottom, + and - pulses to the AGC above that, and then the various sine waves that it's using to determine that angle :) [18:32:51] Nice. [18:32:51] also holy shit, I'm not crazy [18:33:24] good morning [18:33:25] The thing about Quartus is that the UI code is so shit that it doens't fit on my laptop screen and I can't resize it small enough [18:33:26] for the fine equations these guys are using logic high = 1, and for the coarse equations they're using logic high = 0 [18:33:43] hey astronauthen96__ [18:33:49] Hey [18:34:00] have you seen the apollo 13 in real time website? [18:34:01] yo [18:34:08] I sure have! [18:34:10] it's great [18:34:35] I've been listening to the Apollo 13 FIDO audio loop a lot [18:35:03] oh hell, no they didn't, it's because the fine system they documented is the CM trunnion version [18:35:04] gah [18:35:49] oh there is a difference in the CDU fine align systems between CDU versions? [18:36:15] oh yes [18:36:36] there is a large difference in which read counter bits control which fine system switches [18:36:53] but it's only for the optics trunnion as far as I can tell [18:37:48] also no I was wrong, unless they just decided to go halfway and combine the two different things into one equation that is wrong for both [18:38:17] I think I know why [18:39:24] there is an offset for the trunnion [18:39:37] does it have to do with that? [18:39:45] Apollo 15 Delco Manual PDF page 509 [18:40:25] also, the trunnion uses a 64x resolver instead of a 16x resolver [18:40:47] right [18:41:02] I think it's more that than the bias probably maybe? [18:41:17] could be [18:41:22] now that I think about it [18:41:28] the software has to do with the offset [18:41:31] to deal* [18:41:37] happens during OCDU Zero [18:42:09] yeah [18:42:13] although it is interesting [18:42:22] and I don't really know how that would affect things inside the CDU yet [18:42:33] need to implement the error counter first [18:43:19] that manual does directly contradict ND-1021043 though [18:43:30] and looks more consistent with the actual hardware for these switch equations [18:43:43] don't ever believe something in the Delco manual over any other document [18:43:51] well the thing is [18:44:12] in this case it might be more correct? :D [18:44:48] ND-1021043 says that switch S8 = read counter bit 11, and switch S11 = read counter bit bit 10 inverted [18:45:05] but in the actual hardware both are attached to the same sides of the flip-flops [18:45:11] so that is impossible [18:45:53] delco manual says they both have the same polarity, which is what I see in the schematics [18:46:04] and I'm willing to trust delco manual + schematics over ND-1021043 :) [18:46:26] two sources over one, yes [18:49:26] although, there is one more possibility [18:49:52] it may be that switches S8 and S10 behave differently -- maybe one opens and one closes when given a high signal [18:50:06] in which case I have to invert some of the logic equations [18:50:07] hmm [18:51:42] no, the switches appear to be the same... [18:52:46] cya guys! [18:54:46] man this is the worst lol [18:55:49] I've had this many times, I know how it feels [18:55:49] okay I think they just got D7 and D8 backwards [18:58:41] okay yeah [18:59:02] fine switches are 0 volts == switch closed [18:59:19] and ND-1021043 has D7 and D8 wrong [18:59:31] I think that should clear things up... [19:02:26] whoever designed the CDU was a maniac [19:02:38] who clearly never really communicated with the AGC logic design team [19:02:39] lol [19:05:36] must be the same person who designed the Block I CDU [19:05:40] and got lazy [19:33:50] huh, I'm going to have the entire read counter module done (for IMU, RR, and optics shaft) as soon as I finish up this fine switch logic [19:38:11] sounds great [19:40:37] once you have iterated through every possible sign convention :D [19:40:57] heheh... yeah [19:50:58] read counter done! barring bugs [20:23:44] fine switch logic looks believable [20:23:55] now to do all of the sine math [20:24:02] the sine sign math :D [20:28:03] haha [20:52:25] actually quadrant selector for the fine system is not so bad [20:53:39] the cos(theta - phi) reference generator still scares me though [20:58:20] sounds interesting [20:59:50] and I think I can completely ignore the quadrature reject circuits [21:00:03] since my pure path models of everything have no quadrature component [21:05:11] ohhhh huh okay [21:05:39] cos(theta - phi) = cos(0) = 1 when theta and phi are equal [21:06:08] which is what they really want from this thing [21:06:21] but it's going to be off if the read counter isn't exactly right [21:06:33] ...so why the hell didn't they just use the reference directly like they did in the coarse system [21:28:28] night! [16:36:14] morning! [16:58:17] indy91, the fine system works and my CDU can find angles :D [17:23:26] sounds great! [17:31:38] still trying to find any cases in which it may not work [17:31:42] gimme a random angle :D [18:12:29] from 0 to 360? [18:15:31] CDU failure, c. "Cosine(theta - psi) - Voltage less than 4 Vrms. This voltage is normally 4 Vrms when the read counter agrees with the resolver voltage" [18:15:56] was that what you were talking about two days ago or so? [18:15:59] yeah, 0 to 360 [18:16:04] uhh, sounds like it [18:16:34] I wanted to give you an angle from Apollo 16 where they had CDU issues :D [18:16:36] that's really interesting and easy to check [18:16:46] I have very few voltages for the internals of the fine system [18:17:00] oh that would be perfect [18:17:32] bumping the access panel to the CDU helped, so probably not an angle specific issue [18:17:43] you might want to read the Apollo 16 mission report then [18:17:52] starting on page 14-7 [18:18:32] probably has little that you don't know yet [18:18:35] but it has a few numbers [18:19:34] 240 40 42 Mattingly (onboard): 180 roll, 40 degrees yaw, and 130 degrees in pitch. [18:19:39] not very interesting angles [18:20:40] hmmmm [18:21:32] AGS gyro calibration happened at specific angles [18:21:54] "This step eliminates possibility of degraded AGS gyro calibration due to coarse or fine ICDU switching transients" [18:22:28] I want 11.25° [18:22:34] hmmmmm [18:22:46] I might have 4.8Vrms for that [18:22:50] desired angles are 22.5° or multiples of it [18:22:52] unless I'm looking at the wrong thing [18:22:57] haha okay [18:23:14] 4 Vrms for the alarm or for normal operation? [18:23:17] 4.8* [18:23:26] that's what I'm seeing for normal operation [18:23:30] ah [18:23:38] but I'm probably looking in the wrong place [18:24:07] it's a mission report, I wouldn't give much about precision of numbers stated there [18:24:21] mmm [18:24:26] it's worth looking into [18:25:37] there is a Anomaly Report [18:25:55] https://ntrs.nasa.gov/search.jsp?R=19730018171 [18:26:16] https://i.imgur.com/abEuVaw.png [18:26:30] has little more information though [18:26:39] I put a scaling factor on my read counter so it shows degrees instead of the count [18:26:45] but, it found it quite exactly :) [18:26:49] nice [18:27:08] I expected 11.25° to be the switching point of something [18:27:23] if 22.5° and multiples of it are good, then the halfway point must be bad :D [18:27:47] well, there is a spike on the fine error right when it switches to 11.25 [18:27:50] but it nulled it alright [18:27:58] I think the problem with 11.25 was leaking capacitors or something [18:28:08] right [18:30:05] maybe something slightly off of 22.5 [18:31:07] well 22.5*16=360, so that checks out [18:32:08] https://i.imgur.com/RTF6uBd.png [18:32:15] found 23.2 fine [18:32:44] AMTPA looks interesting [18:32:58] that's the fine error [18:33:28] getting that below 0.07Vrms is what makes it stop counting [18:35:10] all this kind of reminds me of when I was working on the Gyro Display Coupler [18:35:17] there is a "secant amplifier" [18:35:29] basically calculates 1/cos(Yaw) [18:35:36] oh weird [18:35:54] when that approaches Yaw = 90° the amplifier should be in trouble [18:36:02] and that would be the SCS version of gimbal lock [18:36:11] but I don't know exactly how it would behave [18:36:13] super weird [18:36:20] I wished I knew more [18:36:47] I only knpw that large yaw angles are also not so good for the SCS [18:36:51] like for the IMU [18:37:01] just degraded accuracy I would guess though [18:37:18] yeah [18:37:18] my code for this is [18:37:20] /Assumption: secant amplifier gets saturated at +/-80° yaw [18:37:21] pitchrate *= min(5.75877, max(-5.75877, 1.0 / cos(Attitude.z))); [18:37:36] but that's not really based on much [18:37:56] I'm quite proud of my GDC work [18:38:09] works like the real thing, integrating attitude rates in an analog way [18:38:13] and super accurate for that [18:39:07] haha nice :D [18:39:28] but how the "gimbal lock" would exactly work is just a guess [18:39:35] only thing I would want to improve at this point [18:41:44] GDC align has some of the same math needed as the CDU read counter I guess [18:42:10] you set an angle in the attitude set control panel and it will drive the GDC attitude to that angle from the current angle [18:43:11] it's driven by the sine of the angle difference [18:45:01] yeah that sounds pretty similar [18:45:23] as far as the CDU goes, are most of your questions focused on the error counter? [18:45:51] yes and no [18:46:16] does the CDU, internally, change the error counter, caused by a change in the read counter? [18:46:26] I'm pretty sure the answer is yes, at least for the OCDUs [18:46:29] and maybe ICUDs [18:46:34] but not RR CDUs [18:46:46] alright, I'll start working on implementing the error counter tonight [18:46:52] because I don't know the answer to that yet [18:47:05] so far I have not found any wiring differences between the IMU and RR [18:47:45] when I first tried the OCDU I was pretty sure I got the scaling right [18:48:09] but it overshot the targeting angle and went back and forth over it [18:48:26] computer didn't seem bother updating the error counter very often [18:49:16] and the Delco manual has those figures where it indicates the error counter gets changed by the same amount that the read counter is changing [18:49:22] but only for the OCDUs [18:49:37] and maybe ICDUs, I forgot [18:49:48] good morning [18:50:03] hey [18:50:17] i read on the forum that the LM Probe removal isn't simulated yet [18:50:30] do you know how that will work yet? [18:52:01] not really. It's not so easily simulated in the Orbiter world of 2D and 3D panels [18:52:15] mouse clicks with lots of conditions on it is my guess, haha [18:52:29] so, like the hatches [18:52:40] only opens when the pressure differential is smaller than 0.08 psi etc. [18:52:57] I guess there are a few things like that [18:53:16] the power cables for connecting the LM to CSM power [18:53:41] not really possible to simulate that in any detail in Orbiter [18:55:35] so it's not really something that will come in the near future [18:56:07] will support for apollo 12 come soon or will that be later this year? [18:56:23] hmm [18:56:25] like checklist mfd or Mcc support [18:56:30] right [18:56:38] what I am hoping on is a stable Orbiter release soon [18:56:50] Orbiter 2016P1 or Orbiter 2020 or something like that [18:57:00] that is then the version that NASSP 8 will be released for [18:57:26] and once NASSP 8 is done, supporting Apollo 7-11, we can support more missions fully [18:58:08] the Orbiter Beta is too much work setting up, that's not what I want to release NASSP 8 for [18:59:14] once such an Orbiter release happens there will certainly be a more concetrated effort to get a nice and stable NASSP release going [19:00:45] it can't be Orbiter 2016 as that has 1-2 big issues for NASSP [19:15:15] has there been any word on when the next orbiter release will be? [19:28:56] I don't think so [20:30:49] well, things are getting fun here [20:31:09] all of san francisco/silicon valley just announced a mandatory shelter in place for 3 weeks [20:34:25] what does that all apply to? All non essential travelling? [20:34:56] yeah [20:35:05] and only grocery stores and health centers are allowed to remain open [20:36:01] damn [20:38:22] they don't plan to have that here in Germany [20:38:32] but most businesses are closed [20:38:35] or going to be closed [20:45:34] yeah [20:45:37] fun times [20:46:08] oh, now that I have a CDU simulation, I wanted to revisit angles during the Apollo 11 landing [20:47:08] and also about SLEW mode -- when you go to SLEW nothing outside of manual input would make the antenna move, right? it doesn't do an inertial hold or anything like that? [20:50:41] correct [20:50:51] hmm [20:50:53] interesting [20:56:47] so I think we said they were around 80 degrees and 180 degrees when they went to slew [20:57:07] but I think it's going to be much more important what the angles were when they went to auto track, and how they changed up until the point of going to slew [20:58:52] ok [21:44:58] hey [21:47:22] hey Alex [21:47:46] I got the iterate option for the MPT transfer mostly working [21:48:07] buuuut it still has about 169.4NM on the MPT for the LOI apolune [21:48:23] it's due to nonspherical gravity and completely normal, haha [21:48:32] nice [21:49:24] does it help with the sometimes high DVZ component of LOI? [21:49:40] not that I've seen it higher then 500 fps or so [21:50:53] no, it won't have an effect on that [21:51:10] it is just a very accurate method to calculate a finite burn from an impulsive one [21:51:23] and it seems like my own, previous method was already quite good [21:51:30] right [21:51:34] not at fault for the slightly off LOI apolune [21:51:48] but still, the new method is still better for any burn that has different burn phases [21:52:11] like ullage, DPS throttle etc. [21:52:44] a good case might be a DPS burn for returning to Earth [21:53:10] that would definitely be a bit improved [21:53:55] ah, yes [21:55:50] it's not much I guess, but it's what they used in the RTCC so I am always going to implement that :D [21:56:52] it was fairly well document, in the IBM RTCC documents [21:57:01] always the best source when it's available [22:00:16] I guess it could have some un-expected advantages, when making it 1:1 [22:04:08] things become more compatible with each other is what I have noticed [22:04:32] implementing bits and pieces of the RTCC software can be difficult to make work with my older RTCC MFD code [22:04:43] but once a lot of functions are in place it works together quite well [22:06:38] right [22:23:38] night! [15:14:05] I just hooked up my laptop to all my desktop stuff. I'm set for working from home for the next three weeks. :) [15:21:27] great [15:38:09] Mike working on the CDU simulation has inspired me to take a look at that again for NASSP as well [16:12:01] Hey [16:12:46] morning! [16:12:55] hey guys [16:13:10] OCDU read counters are working in NASSP [16:13:22] Oh cool [16:13:25] which is nice, but it's also the easy part, haha [16:13:59] awesome! [16:15:50] I have yet to reproduce the behavior described in the Grumman report on RR CDU testing [16:15:58] and am starting to wonder if it is not correct [16:16:06] haha wow [16:16:28] indy91, got a reply from UHCL [16:16:35] ooh [16:16:39] “A member of our staff will begin work on this as soon as possible. Hopefully, we will be able to make these materials available to you by next week” [16:16:45] nice [16:16:56] I had sent my request a day earlier and nothing, haha [16:17:05] haha [16:17:27] scanning > sending a PDF I guess [16:17:39] yeah [16:18:01] which makes no sense but I don't know their system :D [16:18:05] Hopefully they’ll be able to send the scanned one sooner [16:18:07] haha [16:19:02] or they answer their emails that piled up in the reverse order [16:19:16] Maybe lol [16:19:37] or they know that responding to that Niklas guy can only lead to trouble :D [16:20:26] hey, my last two requests had no additional scanning! [16:20:39] I started out with trouble though [16:20:40] hehehe [16:20:45] my first request was all of the SCOTs [16:20:52] a few hundred pages each [16:20:56] yeah that was a hell of a request [16:21:25] worst request since then were the IBM RTCC documents [16:21:45] anyways I have to run, cya guys! [16:22:07] that was fast, haha [16:22:24] https://i.imgur.com/JAra2RN.png [16:22:36] so this is by far the most common CDU failure I see [16:22:52] it gets stuck somewhere giving 12 plus counts followed by 12 minus counts [16:22:58] all at high rate [16:23:12] what causes it? [16:23:35] wrong voltage and phase on the reference to the resolver, making ATPCA and AMTPA total nonsense signals [16:24:05] in this case it's going back and forth between ATPCA saying it should count in one direction at high rate, and AMTPA saying it should count at high rate in the other [16:24:27] ATPCA and AMTPA should set up a meeting to correct the differences [16:24:32] hehehe [16:25:02] so we know from doing a bunch of attempts that the full 6.4kpps on both channels gives way more alarms than they actually had [16:25:40] and what the Grumman report describes is 13 degree excursions, with the reversals being at low rate [16:26:10] but the biggest excursions I've seen are these 12 counts, which is still like a fraction of a degree [16:26:34] and I have no explanation for how it could be at low rate for a reversal [16:27:18] but what's interesting and I didn't know is that the plus counts and minus counts are phased differently [16:27:43] if you look at that picture, when you go from + to -, the gap between pulses to the AGC is 50% wider [16:28:05] but if you go from - to +, the gap is only half as big -- which is 78 microseconds, or only 6 AGC memory cycle times [16:28:13] right [16:28:20] so I'm wondering if the reduced load was actually caused by dropping counts at high rate reversals [16:28:44] because if both flip-flops in a counter cell get set, the computer will only execute a single count instruction [16:29:14] and the divide instruction by itself takes more than 6 memory cycles, so it would for sure cause a dropped count on a reversal [16:29:48] I believe that about DV considering how complex it is in the Virtual AGC, hehe [16:31:27] so what you need is a real CDU to test all your theories [16:36:50] hahaha well [16:37:01] that would help me validate my model [16:37:11] to test, though, all I need to do is make a little FPGA that can output these waveforms [16:37:18] and fly a whole bunch more landings [16:38:48] but yeah, this is why I was asking about an inertial hold or something in SLEW [16:39:03] because I could believe the Grumman report if the antenna actually moved at all [16:39:08] that would make things go totally bonkers [16:39:23] but for a perfectly stationary antenna, it just gets stuck in little holes like this [16:40:28] hmmm [16:40:50] maybe it moved [16:41:09] have to look it up, but the CSM optics can drift during TVC [16:41:24] oh interesting [16:41:24] equally the RR might drift when the LGC is sending data to the X-pointers [16:41:32] oh man [16:41:36] very interesting [16:41:42] standard procedure in the CSM to leave the optics switch in zero during maneuvers [16:42:38] uhh [16:42:45] LGC to tapemeter, not X-pointer [16:43:13] no [16:43:14] haha [16:43:16] getting confused [16:43:35] it is the cross pointers [16:43:43] lgc_forward = 0.5571*(double)lem->scdu.GetAltOutput(); [16:43:44] yeah :D [16:43:46] definite prove :D [16:43:50] proof* [16:43:53] hehe [16:44:32] trying to find a source for the RR drifting [16:44:49] but that might just affect the LGC position for the RR [16:45:32] yeah that's what I was just about to ask [16:45:59] maybe the AGC/CDU drift, but that probably wouldn't affect the actual position outside of LGC [16:58:07] can't find anything [17:00:22] super weird [17:00:49] one difference is that in the RR the CDU signals are displayed if it's doing auto tracking [17:01:11] LGC only designates, all actual auto tracking is done by RR electronics [17:01:45] so the configuration for the RR to drift would be the switch in LGC position, but not actually locked on [17:03:45] uhh [17:03:54] one difference is that in the RR the CDU signals are ignored if it's doing auto tracking [17:03:59] that is what I wanted to say, sorry :D [17:08:10] testing right now if the RR can drift in NASSP [17:10:34] it sure doesw [17:10:40] in LGC mode and not locked on of course [17:14:52] huh [17:14:54] well that is interesting :D [17:15:42] I don't know if we are missing anything that prevent this [17:15:51] but I wouldn't know how [17:16:21] when displaying the inertial data the LGC needs to use the RR CDUs and needs to enable the RR CDU error counter [17:20:55] hmm [17:21:02] yeah [17:21:29] I do wonder how R29 works then though [17:21:39] what is it that is actually causing the drift? [17:22:03] the output to the RR is not disabled when the DID discrete is sent to the CDU [17:22:18] that only enables the alternative output, to the X-Pointers [17:22:57] oh shit okay [17:23:27] so I guess then we need to find out if the LGC signals to the RR get cut off when the switch isn't in LGC? [17:24:04] they should [17:24:37] if they do then there shouldn't be drift right? what are you thinking we might be missing? [17:25:48] well right now we are still at the point where we started, the RR shouldn't have moved in Slew [17:27:01] right :D [17:28:06] so how does R29 work [17:28:13] RR powered flight designate [17:28:16] used in P12 [17:28:29] it wants to move both the RR and show X-Pointer data [17:30:43] oh huh [17:31:03] man I really need to model the D/A portion of the CDU don't I [17:32:10] this is something I can test, again [17:32:29] just need to see if what the RR and X-Pointers are doing just after launch [17:36:50] okay yeah, confirmed in the systems handbook [17:37:04] the RR switch also disconnects the CDU designate commands if the switch is not in LGC [17:37:43] oh lol [17:37:56] FLAGWRD0 # ARE WE IN DESCENT TRAJECTORY? [17:38:03] BZF TASKOVER # NO [17:38:07] CAF BIT8 # YES. [17:38:13] WOR CHAN12 # SET DISPLAY INERTIAL DATA OUTBIT. [17:38:23] heh [17:38:26] Luminary099 doesn't show number on the X-Pointer in P12 [17:38:50] after R29 was removed it started doing that [17:38:57] that explains it, haha [17:41:24] cool [17:41:45] so then, RR antenna was definitely 100% totally stationary [17:45:54] what do the gyros in the RR do? [17:56:59] in auto tracking mode (so also when the LGC has given up control to the RR) the gyros compensate for LM attitude rates [17:57:09] for stable tracking [17:57:27] so it keeps tracking even during attitude maneuvers [17:57:47] small ones in reality, pretty large ones in NASSP, although I hadn't found a definite number for that [17:58:00] hmm, okay [19:53:34] okay but are we really sure it doesn't use them in SLEW? [19:54:02] hmm [19:54:20] The servo electronics, in conjunction with the antenna components and radar receiver, [19:54:21] form an inner and outer closed servo loop for each axis. The inner, or [19:54:22] stabilization loop, keeps the antenna boresight axis fixed in inertial space [19:54:22] unaffected by the LM body motions. The outer, or tracking loop, keeps [19:54:23] the antenna boresignt on the target in step with tracking error signals [19:54:23] from the receiver. In the designate mode (Radar Mode Switch 17S3 in [19:54:24] LGC position), this loop opens and the servo accepts the computer-designate data [19:54:48] yes [19:55:23] the LGC commands will then drive the RR [19:55:29] once it has locked on the LGC lets go [19:55:40] and the auto tracking happens, with gyro support [19:56:55] right, but when it says "this loop" does it mean both loops or just the outer tracking loop? [19:57:15] er, yeah [19:57:25] that wording doesn't preclude the inner stabilization loop from happening in SLEW [19:57:37] well, slew is for manually selecting some RR attitude [19:58:18] sure, but maybe it's for selecting an inertial attitude [19:58:24] maybe? [19:58:25] haha [19:59:17] I don't think it so, but I'll read a bit [20:00:23] the RR is in the way of the AOZ [20:00:25] AOT* [20:00:46] oh interesting [20:00:48] so when you want to do an alignment you move the RR to some specific angles [20:01:07] hmm [20:01:13] well usually with the help of the LGC [20:01:24] but just for convenience [20:04:12] no way, the RR is not holding inertial attitude in slew mode [20:04:27] but I haven't found definitive proof against it yet [20:04:57] hahaha [20:05:10] I believe you, but also would appreciate definitive proof :D [20:05:34] also oh shit, ND-1021043 has a section for RR moding tests, that gives the expected voltages of the error signals at the CDU test points [20:05:37] that is going to be super helpful [20:23:07] okay I'm not convinced [20:24:02] from the LM AOH: "The inner (stabilization) loop maintains the antenna boresight axis fixed in inertial space in the presence of vehicle motion, as sensed by the gyros. The outer (tracking) loop further maintains the antenna boresight on the target, using the tracking error signals from the receiver." [20:24:32] "In the designate mode, the tracking loop is open and LGC-designated antenna position data, or manual slew data, are accepted by the subassembly." [20:25:11] that sure makes it sound like the stabilization loop stays closed [20:34:16] would that also mean that the attitude is stabilized in LGC designate mode? [20:34:23] because that is definitely not correct [20:34:38] LGC alone decides on the RR attitude in LGC mode [20:34:49] without the auto tracking relay enabled [20:35:12] wouldn't that also mean* [20:35:17] hmm [20:35:19] yeah... [20:39:31] I mean, it could be that the RR doesn't normally move in Slew, but it could move a little bit if there is some kind of bias [20:46:16] that would probably be too small to really matter [20:48:35] so for your theory to work the RR needs to move as much as the LM rotates around? [20:50:21] probably yeah [20:50:36] tiny drift in the angles probably won't have much of an effect [20:50:50] the holes that the CDU channels can fall into are relatively deep [20:50:59] when did Buzz switch to slew? Before the 180° yaw maneuver? [20:51:09] I think so [20:51:12] uhh [20:51:42] 102:35:38 [20:53:01] yaw maneuver was at 102:36:46, looks like [20:56:16] that would be quite the maneuver for the RR as well [20:57:28] "Here, Neil puts the Rendezvous Radar mode switch in Slew" [20:57:35] I thought it was Buzz [20:57:45] but it would be a weird switch for the LMP to use [20:57:49] it's quite on the left side [20:58:56] heh [21:14:54] hmm [21:14:56] ERRORCOUNTER 3135 [21:15:02] I don't think this is possible [21:15:19] error counter has 9 bits, right? [21:15:37] so 511 max (octal 777) [21:16:19] hmmmm [21:16:39] well even less [21:16:56] 377 is max and 400 is min? [21:17:06] in octal [21:17:14] yes, 9 bits [21:17:18] yeah if it's signed [21:17:24] unless the sign is handled differently [21:18:34] right [21:20:16] actually I doubt that the CDU handles numbers like that [21:20:24] it's probably +777 and -777 [21:20:26] for max and min [21:20:49] ok [21:20:58] guess I have to limit it in the CDU class then [21:21:17] the RR CDU never went past +/-384 I believe [21:21:22] from the software side [21:22:27] ErrorCounter += delta & 077777; [21:22:32] can you tell me what this does? :D [21:23:17] hmmm [21:23:24] that limits delta to 77777 [21:23:45] which I think is correct in our code at least [21:23:57] delta comes from a "ChannelValue", which should be similar to an AGC word [21:24:07] if (ErrorCounter > 0777) [21:24:07] { [21:24:08] ErrorCounter = 0777; [21:24:08] } [21:24:14] guess I should put something like after it? [21:25:42] uhh maybe [21:25:54] let me actually implement the error counter before giving a firm answer on that :) [21:25:59] haha ok [21:31:12] I want to try to get a landing going tonight to test the current dropped count theory [21:31:26] depending on how that goes I'll start on the error counter tonight or tomorrow [21:31:34] it really shouldn't be too many additional gates at this point [21:31:49] sounds good [21:31:54] I already had to do a bunch of the EC&L module for the read counter logic [21:32:02] and I think I now get the old issue where the optics get driven back and forth by the CMC [21:32:09] cool [21:32:27] because of no internal feedback from read to error counter [21:34:12] bit 4 of the read counter does something to the error counter when it changes [21:35:21] because it has the same value [21:35:37] 40 arc seconds for OCDU trunnion [21:37:06] hmm [21:37:15] not bit 3? [21:37:40] oh no nevermind, I get how that works [21:38:36] the pulses to the AGC are handled by a signal from the read counter called _DEL0H [21:39:37] and that effectively pulses when there's a carry out from it [21:39:57] which means that the AGC only sees changes in bit 2 [21:40:08] i.e. the read counter has one extra bit of precision [21:40:24] the read counter also produces a signal called _DEL2H, which I bet has exactly the same effect on the error counter [21:40:30] but for bit 4, as you say [21:41:22] yeah [21:41:37] well it's going to happen when bit 3 is already 1 and should be incremented [21:41:50] is that why you first thought bit 3? [21:41:51] yep [21:42:05] I was thinking about the signal name when I asked [21:42:10] _DEL0H and _DEL2H [21:42:20] ah [21:42:26] before remembering that it was effectively the bit with a higher number that it was signaling a change in [21:42:57] ok made a few CDU modifications that I am quite sure won't mess up the RR CDU [21:43:06] all that is left is that read to error counter signal [21:43:56] I bet there are some annoying cases, like where the read counter goes from 359° to 0 or bove [21:43:59] or the other way around [22:00:08] night! [15:08:45] hey [15:09:40] hey Alex [15:11:45] well the OCDU error counter works somewhat better than yesterday, but not really :D [15:11:57] I will need Mike's help for sure [15:12:20] and this isn't just for making it more realistic but doesn't change behavior [15:12:32] We could not properly use P24 in Artemis before [15:12:47] that will work in the future [15:13:27] right [15:15:15] using the CDU implementation it now somewhat drives the optics in the right drection [15:15:22] in the general area of the desired star [15:15:27] but it's still very erratic [15:19:56] interesting progress though [15:20:56] when I tried it before I got nearly this far, but no stable optics drive at all [15:26:19] in the mail from UHCL, was your PDF request mentioned at all? [15:27:22] and regarding all of my RTCC stuff, it's basically done, I'll write some chapters for the RTCC MFD manual, do some fixes and then it's back to the main branch [15:33:34] no mention of the pdf yet unfortunately [15:34:41] manual writing, sounds fun :D [15:54:46] the server with all the PDFs must be infected with Corona [16:16:26] morning! [16:17:02] https://twitter.com/WordenAlfred/status/1240305414572519424 [16:17:08] hey Mike [16:17:21] :( [16:20:12] I got my test setup resurrected last night, updated the AGC FPGA to detect dropped counts, and made an FPGA that spits out the +12/-12 pulse trains [16:20:30] I haven't tried a landing yet but I don't have particularly high hopes that this is the right answer [16:21:07] I loaded up Aurora and did some self-tests and only observed 3 or so dropped counts each time it went through the multi-second extensive divide tests [16:22:46] hmm [16:23:13] but, still going to try it this evening and see what happens :D [16:23:16] I added some logic to our CDU class to count down the error counter by 1 for every 4 increments to the AGC counter [16:23:30] that makes the optics drive better [16:23:33] but not good [16:24:13] hmmm [16:24:36] the problem could still be at any stage [16:24:44] CDU, optics [16:25:03] I think I did the conversion right for error counter to optics drive signal [16:25:12] are you sure it shouldn't be every 8? [16:25:13] which I believe is a drive speed [16:25:29] every 8 increments to the AGC counter, not the read counter [16:25:35] 4* [16:26:01] should that still be 8? [16:26:39] AGC has one less bit [16:26:48] hmm [16:27:01] no, nevermind, just sleepy morning brain doing bad morning math [16:27:48] could still be something bad in that logic [16:29:20] https://i.imgur.com/DRIqY2J.png [16:32:03] what am I looking for? [16:36:44] just confirming that _DEL2H counts with every 4 counts to the AGC [16:39:15] ah yes [16:42:17] oh wait a second [16:43:23] I might have just found something [16:45:49] hmm okay _DEL2H may be problematic [16:45:56] and may have connections that are not shown on the schematic [16:45:57] great [16:51:28] what kind of connections? [16:51:54] like, it might actually replace _DEL0H for read counter control in the optics trunnion case [17:37:40] indy91, I noticed that the LOI total TV is always a bit higher then the DVLOI1 on the LOI planning page. Is this normal? [17:37:57] I think so [17:38:03] that will be the difference for the finite burn [17:38:14] for example LOI plane solution for Apollo 11m LOIDV1 is 2912, but on the MPT it shows 2925 fps [17:38:16] just below 10 ft/s? [17:38:19] ah [17:38:22] yeah [17:38:36] in the new powered iteration I had 3.9 m/s [17:38:40] 12.8 ft/s [17:38:56] so yeah, I think that is normal [17:39:00] fixed burn loss [17:39:05] fixed attitude* [17:39:09] right [17:39:39] to gain this 13 ft/s they spent years of their time implementing LOI targeting that optimizes DV using lambert aimpoint targeting [17:40:08] until the requirement was established for all maneuver to be fixed attitude [17:40:19] so that they are compatible with the SCS [17:41:18] interesting text in the Apollo Experience Report about this stuff [17:41:40] RTE as well, spent a lot of time on targeting that wasn't used in the end [17:44:01] LOI DVZ is only 11 fps for Apollo 11 [17:44:46] real pad was -68.6 [17:47:45] that will be quite sensitive to how close your trajectory is to the targeted one [17:47:50] node and all [17:50:00] right [17:51:08] so in my testing, LOI-1 is 4-5 minutes late for Apollo 11. But as before this I seem to be able to adjust it by tweaking the azimuth [17:54:40] of course the LOI targeting with the correct azimuth, but it doesnt seem to like that haha [17:55:01] well it works, but the DV's seem high [17:55:05] -881 DVZ [17:55:50] and I meant tweaking the azimuth only in the TLMCC constants [18:09:08] indy91, do we have the July 21st Apollo 11 presettings? [18:09:30] I believe that one has a hybrid trajectory [18:12:55] yes and true [18:13:10] I have a scenario for it [18:13:21] which needs some checking still I believe [18:13:59] https://i.imgur.com/YHuYJe7.png [18:14:29] oh nice [18:14:43] I think I can build SFP's for it and the 18th [18:15:06] with the SCOT Volume III? [18:15:10] using 69-FM-100 [18:15:21] and maybe that too [18:15:29] oh lol [18:15:37] that is SCOT vol 3 [18:15:44] so yeah [18:15:46] yeah, haha [18:16:06] for once I knew it by that name and the not the XX-FM-XX number :D [18:16:17] haha [18:16:40] Id like to then maybe fly one [18:16:47] probably the 21st launch [18:16:52] July 18 one is already in the repo [18:17:04] but I probably can get the July 21 one ready today [18:17:14] don't think there was anything left to do [18:17:34] ah sure [18:17:40] if its not too much trouble [18:18:52] no problem [18:18:56] where does that one even land [18:19:05] 41.9°W [18:19:27] what is interesting me is the hybrid/non fixed LOI GMT. The only other full presettings we have is Apollo 14 which is also hybrid but fixed LOI GMT [18:19:41] right [18:20:06] only other hybrid full pressetings* [18:20:43] Apollo 13 has interesting launch vehicle targeting for that [18:21:01] some launch days are variable GMT, some fixed [18:21:20] fixed GMT is equal to changing free return perilune through the launch window [18:21:40] Fra Mauro, April 11 launch, 210-60NM [18:21:50] April 12, 60 (free return) [18:22:04] Hyginus, April 9, 300NM fixed [18:22:28] and Apollo 11, July 21 has a fixed perilune height then I guess? [18:23:22] answering my own question, yes [18:23:28] LVOT says 800NM [18:28:25] hmm is the LVOTs on the Virtual AGC site? I dont seem to have it in my collection [18:29:01] it's on the archived NTRS [18:29:27] https://web.archive.org/web/20100527070036/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19690072999_1969072999.pdf [18:30:13] ah thanks [18:36:25] these different launch dates might make a good case for making all the ARCore contants loaded from a text file like what was recently done for the systems config [18:36:47] yeah [18:37:06] the MCC already can load some parameters from the scenario as well [18:37:17] I think I set up to try and make the July 18 launch compatible with it [18:37:36] but never tested it so far [18:37:41] right [18:38:45] does the SFP values get saved in the scenario? [18:39:26] block 2 of the SFP does [18:39:47] the one you can generate from a TLMCC mode 2-5 [18:39:58] which includes the updated node [18:40:11] that's why that table definitely needed to be saved [18:40:22] yeah [18:42:14] not really sure how to handle this [18:42:34] even with a text file, right now the mission file is loaded based on the mission number [18:43:04] I guess you could manually add or remove a line from the Apollo 11 mission file [18:43:31] easily done, that's how I switched back and forth between Terminus and Luminary for Apollo 17 [18:43:39] right [18:44:00] the mission file could have a line to load another text file which has the "initial program load" for the RTCC [18:44:57] that's how the real RTCC did "saving" and "loading" [18:45:43] IPL from a restart tape and every once in a while a "checkpoint" [18:45:56] from which they could recover if the computer crashed [18:47:10] I might implement something like a checkpoint, which wouldn't be saved in the scenario but elsewhere and only by manual request [18:47:14] on the config page maybe [18:47:29] but would then have a lot more parameters saved than currently [18:49:27] hmm [18:49:41] or maybe something entirely without the mission file? [18:49:58] just a button in the RTCC MFD to load a file with lots of numbers [18:51:55] yeah [18:52:20] then we would not always have to have the MFD open [18:54:24] yes. On the other hand you have to manually save [18:55:46] " where does that one even land [18:55:47] 41.9°W" [18:55:55] where did you find this value? [18:55:59] flight plan [18:56:04] ah [18:56:19] speaking of flight plans, haha [18:56:25] guess what UHCL has [18:56:49] APOLLO 11 ALTERNATE LAUNCH DAY ( 7/21/69 ) flight plan [18:57:45] maybe for the next, post-Corona requestz [19:00:21] OH [19:00:35] I was just sitting here for a bit trying to figure out what you were doing with AS-202 [19:00:43] but you meant the virus, not the agc program :P [19:01:12] and I was just thinking "that's also an AGC version isn't it" [19:01:18] hehehe [19:01:34] both should be sent to space as much as possible [19:01:47] also ignore what I said earlier, there's not weird wiring related to _DEL2H. I just missed the spot where it goes into the EC&L module [19:01:48] indeed [19:01:50] heh [19:02:06] I just email Francois that now would be a perfect time to finish dumping Corona from those modules :P [19:02:29] er, should [19:03:45] I could spend some months getting Corona to work [19:04:02] that sounds wrong [19:04:39] hehe [19:05:25] one of the questions I would have with the Block I software is: will it be as inaccurate during reentry in NASSP as the real missions? [19:05:45] oh yeah that would be interesting [19:06:01] not even sure what caused it [19:06:06] degraded state vector [19:06:10] or bad reentry guidance [19:16:19] ah [19:16:28] learned something new right away reading the error counter documentation [19:16:54] The nine stages, designated 2**0 through 2**8, provide an apparent capability of accumulating 2**9, or 512 pulses, but the counter is logically mechanized to saturate at 384 pulses. [19:17:15] so you would have to clamp at 0o600, not 0o777 [19:23:55] yep [19:23:57] knew that [19:24:18] so it won't even hold more than 384? [19:24:27] not just an output restriction [19:24:52] as in, the counter is actually at 512, but won't output more than 384? [19:25:55] nope, there is a hardware limit inside the CDU that error counter cannot count higher than 384 [19:26:00] ok [19:26:17] I first had it the other way yesterday, but was quite sure it actually only holds 384 so already changed that [19:26:29] nice [19:26:59] otherwise... yeah, decrementing the error counter with each _DEL2H pulse looks correct [19:27:02] from this documentation [19:27:52] with that it drives in the direction of the desired star, but still very erratic and not accurate, so definitely not the complete answer [19:28:11] the remaining issues could all be in our optics code of course [19:28:16] hmmm [19:28:32] dShaft += 0.01326*RAD*4.0*simdt*(double)sat->scdu.GetErrorCounter(); [19:28:32] dTrunion += 0.01326*RAD*simdt*(double)sat->scdu.GetErrorCounter(); [19:28:37] this is what I have right now [19:28:56] mainly based on the Delco manual [19:29:00] is the 4.0 in there accounting for the different scale factors of the shaft and trunnion? [19:29:17] yeah [19:29:44] 384 bits max [19:29:48] 26 mV/bit [19:29:57] 0.51°/s/Vrms [19:30:28] 26/1000*0.51 is the 0.01326 [19:30:53] but, if that is actually supposed to be the commanded rate, not quite sure [19:33:41] The optics error counter can receive pulse inputs from the CMC or the third stage of the read counter during OSS positioning of the optics. Each pulse sent to the error counter is equivalent to 158 arc seconds or 0.0439453 degree (nominal) for the shaft, or 19.8 arc seconds for the trunnion. The largest possible error angle the optics error counters can contain is 16.875 degrees for the shaft and 2.2 degrees for the trunnion. The contents [19:33:41] of the error counter represent only the absolute value of the error angle. [19:34:13] the 800 NM free-return height you found in the LVOT, did that come with EMP coordinates? [19:35:32] AlexB_88, no, but the SCOT might have those [19:35:45] thewonderidiot, "absolute value of the error angle" oh really [19:36:27] yep [19:36:29] so the way we had the optics drive implemented before is to directly apply the error output from the AGC to the optics angles, and also directly changed the AGC input counter [19:36:48] so no stage between AGC and optics [19:37:12] hmm [19:39:10] looking at the systems handbook, the output from the CDUs seems to be related to optics zero [19:39:19] a relay switches between the two [19:39:45] and if you really simplify the optics zero logic you get: optics rate = 2*angle [19:39:59] so maybe I have to appliy another 2.0 factor and everything works :D [19:40:07] I doubt it, but I will test it [19:41:49] hm [19:42:01] I don't think the CDU itself has any consideration for rate really [19:42:12] wow [19:42:15] a lot better actually [19:43:31] huh [19:43:33] interesting [19:43:42] ok it went through 0 and that broke it [19:43:48] but I knew that could happen [19:44:38] our read counter is still a double [19:44:44] not int or so [19:44:55] ah weird, heh [19:45:12] so when it goes from 1° to 359° it counts all the way [19:45:18] 358° difference [19:45:27] error counter didn't like that [19:45:47] I guess the real CDU just overflows? [19:45:49] or underflows rather [19:45:56] uhhh [19:46:06] the real CDU cannot count through zero on the read counter [19:46:08] er [19:46:11] error counter [19:46:34] I meant read counter [19:46:43] read counter it just wraps right back around to 0 [19:46:50] or goes from 0 to max [19:47:19] it didn't like that in combination with the increment of the error counter every 4 counts [19:47:34] hold on [19:47:56] it counted, in my example, 358°/4 worth of angle to the error counter when it went through 0 [19:48:00] hmm wait [19:48:06] it had that issue in trunnion only [19:48:48] indy91, the circumlunar pericynthion seems to be listed as selenographic polar coordinates (IE LONS 1.7341+02) in the SCOT [19:49:03] is there a formula for converting to EMP? [19:49:05] I thought there were some EMP angles as well [19:50:26] counting through zero: https://i.imgur.com/Hs3XdEA.png [19:51:48] yeah [19:52:23] just doesn't work when you don't have a proper read counter, haha [19:52:42] you could fix that :D [19:52:47] so I guess +173.41 E is the EMP longitude [19:53:43] thewonderidiot, I probably have to, yes [19:53:52] which page are you looking at, Alex? [19:55:13] page 113 of the SCOT vol 3 [19:55:26] ah those [19:56:00] look on PDF page 85 [19:56:11] that is July 21, 90° azimuth, 1st opportunity [19:56:16] Circumlunar pericynthion [19:56:53] DEMP and RAMP [19:57:34] DEMP is [19:57:35] earth-moon plane latitude of the intersection of the lunar approach hyperbola with the lunar parking orbit plane [19:57:50] so the node [20:00:14] right [20:02:52] hmm I think Im blind, I cant find DEMP or RAMP listed on that page [20:04:13] oh page 84 [20:04:15] sorry :D [20:04:42] ah [20:06:13] found it thanks [20:06:16] I guess the 90 azimuth for the mid launch window values? [20:08:32] the launch window on July 21 started at 94.6775° [20:08:45] the SCOT seems to have values for 72 to 108 though [20:09:23] yeah [20:22:33] fixed some bugs, successful P52 using the CDU class! [20:22:57] but the drive speed is definitely not right, still [20:23:19] nice! [20:23:49] drive speed is going to be entirely determined by the optics right? [20:23:51] so this is the CDU implementation we have been waiting for I guess [20:24:01] might be able to find that in the optics section... [20:25:02] the CDU implementation that we have been using for the RR CDUs already [20:25:20] but there is this weird feedback from the read counter to the error counter, which caused me trouble before [20:26:10] and yeah, the output from the CDU is the 26mV/bit [20:26:19] after that it's not the CDU's job anymore [20:27:38] hmm [20:29:09] AlexB_88, July 21 scenario needs more work than I thought [20:29:29] padloads? [20:31:32] yeah [20:31:45] I think I mainly had added the LVDC presettings [20:33:49] if its stuff other than presettings that need work, I can probably figure it out [20:34:32] it's fine, just need to check everything and do the few changes [20:34:47] ok [20:35:12] so July 21st launch is probably not 14h09 then [20:35:32] if it opens with -94.6775 launch azimuth [20:36:30] flight plan has 1209 EDT [20:36:33] so 16:09 [20:36:50] I like EDT [20:36:57] it's 4 hours away from GMT [20:37:05] and scenario starts 4 hours before launch [20:37:14] so I don't have to convert [20:38:57] hmm I see 1409 EDT in the flight plan [20:38:59] page 32 [20:39:05] pdf 32 [20:40:00] ah, the reformatted on says 1209, and the original 1409 [20:40:17] that must be Change 1 [20:40:57] but which one is right [20:41:28] well everything else I see says 1409 [20:41:32] LVOT,SCOT [20:42:33] I really shouldn't be using the reformatted one [20:42:37] there are a few errors [20:43:49] hmm [20:44:14] I actually think 1209 is correct [20:44:19] looking at the SCOT [20:44:31] for the ~95 launch azimuth [20:44:39] two hours into the daily launch window [20:45:12] ah haha [20:45:21] I got revision 1 from UHCL once [20:45:23] and it says [20:45:32] ON TABLE l-3 FIRST COLUMN CHANGE "1409 EDT" TO "1209 EDT" [20:45:42] ah [20:46:25] now I have to relearn how to use the ephemeris page in the RTCC MFD [20:51:22] so the PC1 GMT in the SFP should be set to the GET + 16:09 [20:52:54] yep [20:56:42] ok done [20:56:44] now the RLS [20:57:56] if I can't find a radius for that site I'll just put a delta glider at the coordinates :D [20:58:14] hahaha [20:59:13] dumb me, the flight plan has it [20:59:36] well [20:59:39] not exactly [20:59:41] but close enough [21:01:28] are any of the pre-flight RLS estimates exact? :D [21:02:10] rarely [21:09:10] what TLAND are you using? [21:10:47] the SCOT seems to be based on 10 revs between LOI-2 and DOI [21:10:59] so I just the landing site pass time and added two hours [21:11:03] used* [21:12:43] ok [21:14:51] CMC and LGC padload done [21:15:09] 103.7665472 [21:15:10] hrs [21:15:12] is the TLAND I used [21:16:58] wow [21:17:08] did I really not even implement the LVDC presettings yet [21:17:15] why did I even have a July 21 scenario then [21:18:26] that will take a while [21:18:31] I'll finish it tomorrow [21:22:20] lat 1.67805556 long -41.89916667 [21:22:25] is that what you used? [21:22:53] table 1-3 and 1=4 seem to differ on that [21:23:01] 1-4* [21:23:05] of the flight plan [21:23:28] yes [21:23:41] 1-4 is landmark tracking data [21:23:57] which seems to include a few landmarks close to the landing site [21:24:02] -1.25 NM [21:24:11] but the landmarks will be craters and the landing site is hopefully not a crater [21:24:15] yeah, I used -1.25 [21:26:59] alright, SFP and constants are done [21:27:35] by temporary changes to the Apollo 11 values? [21:28:16] yeah I just commented the July 16th ones and added July 21st under [21:28:25] just temporarily [21:28:40] ok [21:28:51] I wont PR that dont worry :D [21:28:56] haha [21:29:03] scenario will be done tomorrow [21:29:11] no rush [21:29:38] thanks for looking at it [21:29:52] yeah if I am rushing I am going to get the terrible mixture of angles in radians, degrees and pirads wrong :D [21:30:10] haha [21:30:25] good night! [21:30:30] cya [14:23:31] hey [14:30:58] hey Alex [14:37:51] the scenario is done [14:37:52] just got your update, thanks for the scenario! [14:38:04] no problem [14:39:00] I will test the constants/SFP for it today, and will do ones for July 18th [14:41:26] sure [15:04:49] still not having more luck with the CSM optics [15:05:08] it's always overshooting the target and even when it has acquired the star, it doesn't stay still [15:05:29] it's ok, definitely much better than I ever got it before, but I must still be missing something [15:23:17] weird [15:41:53] the LVDC presettings would be valid from 72 to 108 [15:42:05] not sure the launch window is cut short [15:42:23] definitely not for performance reasons, starting at 95° wouldn't make sense for that [15:43:28] hmm [15:44:31] yeah, not performance [15:46:10] so technically, you could still launch at 72 with these presettings? [15:46:15] yep [15:46:33] another reason could be the countdown recycle capability [15:46:45] if you tried launching on the 16th and the 18th, maybe you need more time [15:46:48] but 2 hours... [15:46:52] doesn't seem significant [15:48:28] yeah [15:48:44] about to launch, July 21st [15:48:59] going to fly it up to post TLI [15:52:26] on July 21 the launch azimuth changes very quickly in the first 2 hours of the launch window [15:58:36] hmm [15:58:50] there was a weird 10 second pause at staging [15:59:06] I mean the SII engines didnt start up for 10 seconds [16:00:40] that's very strange [16:00:53] can you send me the LV log? [16:01:10] like staging happened normally, but the SII engines just took very long to ignite [16:01:12] sure [16:01:43] Ill just finish insertion and Ill send you it [16:01:54] thanks [16:03:52] any time acceleration during launch? [16:04:11] SII staging was normal [16:04:20] only 10x up to T-5min after that none [16:04:28] and it was outside view only [16:04:58] ok [16:05:48] I should fix that some time [16:06:03] staging and engine starts are a busy time for the switch selector [16:06:14] up to 10 commands per second [16:06:24] and right now it can only do one command per timestep [16:06:41] so with time acceleration it can happen that it doesn't issue the commands fast enough [16:10:26] lol, the fix for that might be as easy as changing an "if" to a "while" [16:10:27] https://www.dropbox.com/s/0bku9rssmceu4vd/lvlog_A11_Jul21st.txt?dl=0 [16:10:34] thanks! [16:11:23] [TB3+1.402995] Switch Selector command issued: Stage 2 Channel 33 [16:11:31] that's the S-II engine start command [16:11:35] normal time for that [16:11:39] so that at least worked [16:12:37] I think the TB3 events are all normal [16:12:44] good acceleration by TB3+5 seconds [16:12:48] so TB3 must have started late [16:13:38] no sensed acceleration all through TB2 it looks like [16:13:43] did all engines go out at once? [16:14:41] didnt noticed anything abnormal there [16:15:15] I can give you the T-60s scenario if you want to test [16:15:48] I'll test it on my own at first, it might happen on any scenario [16:15:54] could be caused by my recent EDS work [16:16:00] ok [16:22:46] TB2 started late [16:22:54] and TB2 has a minimum run time [16:23:16] the LVDC for some reason didn't get the signal that the inner engine cut off until all engine cut off [16:23:39] odd [16:23:46] and when that happened it started TB2, ran through TB2 for some time coasting [16:23:49] and then TB3 started [16:23:49] TLI is on the table, looks good [16:24:04] not too many typos then :D [16:24:25] do you have a guidance reference failure? [16:25:26] ooooooh [16:25:30] I know what it is [16:25:35] indeed an EDS bug [16:25:41] if (!ThrustOK[4]) return true; [16:25:53] this is the logic for the inner engine cutoff [16:26:09] but recently I made it so that each engine has 3 redundant sensors [16:26:33] so ThrustOK[4] is not the single engine 5 sensor anymore [16:26:40] it's now 15 sensors [16:27:22] ThrustOK[4] is now the 2nd sensor of engine 2 [16:28:13] no guidance reference failure [16:28:26] the guidance seemd to have worked normally up until now [16:28:58] yeah, the LVDC didn't get the memo that the inner engine had cutoff [16:29:07] I dont think the zero-thrust period was long enough to really cause to much issues [16:29:08] I'll fix [16:29:50] nice [16:35:14] I think the logic in the LVDC might even be wrong [16:35:29] it doesn't look at the actual state of the engine, just sets a flagword [16:35:32] flag* [16:35:33] maybe [16:40:23] oh daytime TLI, nice [16:41:27] oh interesting [16:41:54] if that isn't a typo in the presettings... [16:42:47] TB6 is at about 9500 seconds [16:43:09] 2:38h [16:43:12] as per LVOT [16:43:26] plus minus a few minutes [16:43:46] yep [16:43:51] good, haha [16:48:38] morning! [16:49:40] hey [16:50:09] very good TLI [16:50:13] what's up? [16:50:21] right on the VI and DVC -6.4 remaining [16:50:24] still not getting great results with the optics [16:50:37] but my Apollo 11 July 21 launch scenario seems to work good [16:50:52] nice [16:51:21] I flew a couple of landings last night and the +12/-12 pattern with dropped counts is definitely not the answer [16:51:37] my DSKY didn't update for the entirety of P64 outside of restarts [16:51:53] and I got something like 12+ alarms [16:52:14] but now I'm starting to suspect that my models of the fine system might be wrong [16:53:11] hmm [16:53:24] at least you have a convenient tool to generate CDU data :D [16:53:35] yeah [16:53:53] will need to do actual circuit modeling I think to really nail this down [16:56:08] the optics are driving fine, but are always overshooting the target [16:56:34] the output from the CMC is essentially the angle difference it wants [16:56:38] would it still be helpful for me to integrate the error counter? [16:56:39] right [16:57:25] and with the read to error counter feedback that should decrement it by the right amount that it can't really overshoot [16:57:44] always seems like the CMC is too eager to add onto the error counter, even if it is almost at the target [16:57:46] yeah [16:57:56] hmmm [16:57:59] but I'll have to analyse that a bit more [16:58:04] if it actually adds too much [16:58:23] integrate the error counter in your CDU you mean? [16:58:27] yeah [16:58:34] well yeah, you understanding that better probably helps me as well [16:58:45] okay, cool, I'll start on that tonight [17:01:58] indy91, 1st mode 5 calculation looks good [17:02:06] oh nice [17:02:07] MCC-2 DV 50 fps [17:02:14] a hybrid transfer [17:02:16] yeah, seems good for 800NM [17:02:19] pericynthion [17:02:28] yeah [17:02:58] the SCOT vol 3 had quite a lot of info for building the SFP [17:03:09] nice [17:05:06] the angle unit issue is completely our fault btw [17:05:13] the LVDC is consistently using pirads [17:05:20] 1 pirad = 180° [17:05:30] but we have a mixture of degrees and radian [17:05:41] some is my fault, some was there before :D [17:17:12] indy91, does the LOI processor need to know the "no. of revs in 2nd lunar orbit" for missions that have an LOI-2? [17:17:39] what does it say above those inputs? [17:18:11] oh [17:18:12] LOI [17:18:14] hmm [17:18:17] yes [17:18:39] it still needs to know the landing time [17:18:48] I set it to 10 for this mission [17:18:59] but it should be 0 in the LDPP [17:19:28] shouldn't it be 11? [17:19:38] I added 2 hours to the landing time [17:19:49] as the SCOT was 2 hours early, for any launch day [17:20:38] from the Apollo 10 flight experience they figured that another rev would be helpful [17:21:15] and in that case the LOI and LDP processors talk about different things with their revs [17:21:28] in the LOI-1/LOI-2 case [17:21:57] LOI is always second LOI maneuver to landing [17:22:11] LDPP is always DOI to landing [17:22:27] so not really a contradiction [17:22:39] yes 11 [17:24:18] could the coplanr LOI solution be used? [17:24:27] coplanar* [17:24:46] if you don't want to fly over the landing site [17:25:06] hmm no thanks [17:25:21] I suggest the plane solutions [17:25:34] yeah thats what Ive been using [17:25:49] I just saw that the coplanar had a similar total DV [17:26:13] what's the Theta for the coplanar? [17:30:25] 2.37 [17:31:07] so probably not a lot of DVY [17:31:16] for the plane solutions [17:31:33] so coplanar won't have much less DV than plane [17:34:49] yeah [17:35:23] well the SFP/midcourse constants work quite well [17:35:37] added all maneuvers until DOI [17:35:47] landing is 10 minutes early [17:35:54] but LOI is 10 early too [17:36:04] when is the MCC? [17:36:09] I think the times are based on MCC-1 [17:36:23] MCC-1 being the hybrid transfer [17:36:23] yeah [17:36:33] I actually did an MCC-2 in my test [17:36:33] you can do it later, but it will be a few minutes different [17:36:39] but Ill try MCC-1 [17:37:08] right, because it says the MCC is at 9 hrs GET [17:37:12] Ill try that [17:37:48] btw those online monitor message are very helpful [17:37:58] the landing times? [17:38:26] well, everything [17:38:39] every input it gives you a confirmation [17:38:55] right [17:38:55] oh and the LOI time is much better with MCC-1 [17:38:58] every MED etc. [17:39:38] sounds like the July 21 launch is a feasible mission :D [17:41:03] landing time is 2 mins late [17:41:09] with MCC-1 [17:41:34] and I did not specify any node time restrictions in the TLMCC processor [17:41:40] so yeah, quite good [17:41:42] very nice [17:42:34] Ill probably fly the whole thing sometime in the coming weeks [17:44:25] I wonder about the landing site [17:44:34] I don't think any actual landing was that west [17:45:37] yeah [17:45:42] probably not super interesting, main constraint is that it is flat [17:56:10] not too far away from where Surveyor 1 landed [18:07:06] for a free-return MCC-1 it would be 11 fps [18:08:18] the post TLI pericynthion closest approach height is 1357.3 NM [18:08:35] and post MCC-1 (FR) would be 789 NM [18:08:48] 800NM being nominal [18:08:51] so a bit off [18:08:53] but not too much [18:08:56] yeah [18:09:19] I used mode 9 [18:10:37] right [18:13:07] on to the July 18th SFP I guess [18:13:29] the very first reaction of the Apollo 13 FIDO after the explosion was to calculate a Mode 8 flyby [18:13:46] mode 8 because he wanted to specifiy the pericynthion height [18:14:05] didn't listen any further, but as soon as he heard there was any kind of trouble he was ont it [18:14:08] onto* [18:14:20] interesting [18:14:37] and RETRO first talked with the assistant flight director about what abort solutions they had on board [18:24:28] was there any more LOI/DOI talk leading up to the explosion? [18:25:49] haven't listened to more yet [18:37:12] do you want me to PR the alternate Apollo 11 launch dates in ARCore.cpp (commented out)? [18:37:58] while we wait for a better solution to handle multiple launch dates for a single mission [18:38:13] you can do that, sure, then we have the numbers [18:39:56] ok [18:40:17] when I've tested July 18th Ill do that [18:44:35] that scenario was already done I believe [18:44:40] or else I wouldn't have commited it [18:46:32] right [18:47:07] it does have presettings [18:48:25] yep [18:48:30] and padloads [19:29:11] I noticed the Apollo 11 July 16th SFP's dpsi_loi & dpsi_tei match the SCOT but the signs are reversed [19:31:32] yeah I never know what is right for the signs, lol [19:32:28] July 18th SFP ready for testing [19:32:35] so in doubt, don't trust my numbers [19:32:55] you can generate the SFP block 2 and look at the sign there [19:33:06] haha no worries [19:33:10] yeah thats what I did [19:38:30] the coordinate system of the dpsi is EMP [19:38:34] oh is the fix for the SII ignition delay ready? [19:38:45] yeah [19:38:47] I am about to test July 18th [19:38:52] I tested it [19:38:55] I'll push it then [19:41:56] done [19:43:07] thanks [19:44:45] the No Auto Abort light might also have been on for longer than usual with that bug [19:44:59] and Liftoff light, after switching off auto abort [20:09:08] indy91, I had another though while doing landing tests yesterday [20:09:26] how similar is the trajectory in that scenario to the actual Apollo 11 landing trajectory? [20:09:41] and is it possible that different trajectories might give different computational loads? [20:13:34] it lands at the targeted spot [20:13:49] and I don't think the computation load would be any different [20:13:58] during the ignition algorithm maybe [20:14:10] but not during the descent itself [20:14:30] hmm, okay [20:15:01] the only thing in the descent guidance that is really variable is the time-to-go calculation [20:15:10] runs a quick iteration [20:15:39] but, that won't make the difference [20:16:04] I mean, the actual Apollo 11 mission didn't fly a different trajectory really as far as the LGC is concerned [20:16:11] the LGC thought it flew a perfectly normal trajectory [20:16:14] the SV was just off [20:16:27] right [20:16:52] hmm, in the LR routine [20:16:59] no, not even there I think [20:17:42] oh the other thing I need to do is get downrupts going at the right speed [20:18:19] I think in the hardware AGC I'm never triggering those [20:18:55] righ [20:18:56] t [20:19:44] indy91, so I just remembered, my pyro's might of not been armed on my launch this morning. I wonder if that might of contributed to the issue [20:20:00] no [20:20:11] ok [20:20:19] it was just that the LVDC didn't get the memo that the S-IC inner engine had cut off [20:20:20] didnt think so but thought Id ask [20:20:27] right [20:20:42] pyros are really just explosive devices in the CSM [20:20:52] the other SECS switches and CBs are another story [20:21:02] but you probably wouldn't even have lifted off then :D [20:21:13] I knew that EDS switch can be important [20:21:35] I am running a very improvised checklist on my tests :D [20:21:42] hmmmm [20:22:26] ok, the ground systems do get an "EDS unsafe" signal [20:22:31] not a checklist actually, but a flow [20:22:42] right [20:22:44] but that is mainly the EDS CBs [20:24:18] yeah, the rest of the SECS doesn't matter, it won't stop the launch for that [20:24:26] the automatic systems at least [20:24:40] I'm sure someone would object for the pyro switches not being armed :D [20:27:25] at least its better then what I used to do on quick tests like this...launch a completely dead CSM haha [20:27:39] ouch [20:36:33] staging went well [20:38:27] do random failures still happen without touching the fail multiplier in the PAMFD, or do you have to set it before anything will happen? [21:10:05] tested both TLI opportunities on the MPT, with MCC-2 afterwards mode 3 solutions look good [21:23:23] nice [21:23:24] uhh [21:24:04] I think random failures only happens if you generate them in the PAMFD [21:27:35] right [21:27:42] that makes sense [21:28:04] I was scared of getting an unwanted failure that would ruin my test :D [21:28:43] well even before failures only happened if you enabled them in the Orbiter launchpad or if you added something to the scenario [21:31:06] the thing is, I always forget to disable it in the Orbiter Launchpad lol [21:31:31] ah [21:31:31] and I believe random failures used to be on by default [21:32:04] that option might generate failures again in the future [21:32:17] but for now, when I moved the code to the PAMFD, it does not [21:34:29] night! [15:32:14] hey [15:38:50] hey Alex [15:44:23] any luck with the CDU/optics issue? [15:50:05] I'm making the CDU read counter into a 16 bit integer right now [15:50:50] probably required for any step from just above 0° to just below 360° [15:52:13] already have some questions for Mike, haha [16:40:37] seems to work good already, the new read counter [16:40:46] back to the error counter then [16:41:09] and this change will require a RR CDU Zero in old scenarios, but that doesn't seem like a big deal [16:41:12] morning! [16:41:28] hey [16:41:50] what's up? [16:41:56] questions for you [16:42:01] shoot [16:42:19] read counter [16:42:25] read counter is 0, becomes 1 [16:42:31] nothing happens to the AGC counter, correct? [16:42:35] correct [16:42:43] when 1 becomes 2, then the AGC gets a pulse [16:42:47] right [16:42:54] read counter is 0, and is decremented [16:42:56] by 1 [16:42:58] what happens? [16:43:11] uhh, let me check [16:43:50] both the 2⁰ and the 2¹ bit were 0 and become 1 I would imagine [16:43:56] in the read counter [16:44:09] so the AGC counter already gets a minus pulse? [16:44:46] and the definition of the 2⁰ pulse is that it is 1 and becomes 0? [16:45:11] or the 2¹ bit? [16:46:16] https://i.imgur.com/7T2x2Nx.png [16:46:20] counting down through zero [16:46:40] AT*PGH are the pulses to the AGC [16:47:27] looks like all things are generated when it goes below 0 [16:48:50] I think that answers the question, when it goes up from 0 it won't pulse something to the AGC until the second pulse [16:48:57] but when it goes down it's already the first pulse [16:49:00] yep [16:49:02] first change of the read counter [16:49:34] I think I successfully changed the read counter then [16:49:39] from double to uint16_t [16:49:45] nice! [16:50:00] I considered bitset, but didn't know how to handle the overflow as nicely as uint16_t [16:50:33] yeah uint16_t is definitely the right choice [16:50:41] I probably should try and make it a bit more efficient though [16:51:12] I save a temporary variable on every read counter increment [16:51:22] and then compare the bits for the two overflow signals [16:51:43] any ideas? Maybe a modulo? [16:52:04] do you do the increment one by one? [16:52:08] yep [16:52:28] hmm [16:52:30] I have a double precision value for the new value [16:52:38] convert that to uint16_t [16:52:51] some checks for up or down counting [16:53:24] and then increment or decrement bit by bit for the read counter [16:53:38] I think you can get away with just looking at the current value [16:53:39] and every bit a temporary variables is saved, which is used for the comparison [16:54:22] how? [16:55:22] hmm [16:56:38] I mean it works [16:57:17] mmm nevermind you do need to know last and current [16:58:19] because 557 -> 560 creates a _DEL2H pulse to the error counter, as does 560 -> 557 [16:59:07] or does it work what I have right now? :D [16:59:15] haha [16:59:17] if I compare previous and currentl value [16:59:39] I should check if bit 2^1 has changed [17:00:17] I think I had it right and then made it worse [17:01:15] should I check for a change or for a change from 0 to 1? [17:02:04] your example, 557 and 560 [17:02:22] I guess it depends on which bit, haha [17:02:26] heh yeah [17:02:32] hmm [17:02:42] if I check bit 2^0, then it should check if 1 becomes 0 [17:02:54] right [17:03:01] but that doesn't extend to bit 2^2 [17:03:02] but I can also check bit 2^1, basically any change is right there [17:03:17] for that one you're also looking just for a change in that bit [17:03:31] so in C that would be [17:04:08] if ((previous ^ current) & (1 << 1)) [17:04:17] or (1 << 3) for _DEL2H [17:04:19] yeah, I already have code for that [17:04:24] bad code, but it works [17:04:29] can still improve [17:04:38] mostly had issues with the actual logic [17:05:31] so I'll check for any kind of change in bit 2^1 and 2^3 [17:05:39] that should be right [17:06:28] yep [17:08:21] thanks for the help, I think I can get that correct now! [17:08:26] awesome :D [17:08:36] for the error counter, I got all of the NOR logic implemented yesterday [17:08:56] but I need a D/A model and some sort of feedback on the shaft angle for it to do anything meaningful in simulation, heh [17:09:17] yes, the feedback, haha [17:09:19] so learning how D/A works is this evening's project [17:09:35] basically been my project the last few days [17:12:15] reading a bit on ND-1021043 about it [17:12:17] in* [17:13:32] ND-1021043's description is generally good but very dense [17:13:47] I usually have to read sections multiple times to start to follow :P [17:22:36] haha [18:30:07] indy91, in the RTE processor, I am testing a flyby abort using the DPS. If I select the LDD, does it assume the standard thrust profile, or is there somewhere else I can adjust the DPS thrust profile? [18:38:27] LDD? [18:40:22] LM,DPS,Docked [18:40:55] right [18:41:01] I forgot I had already implemented that, lol [18:42:34] checking [18:44:47] I'm not seeing a way how they could have changed that [18:45:03] there is a general RTCC system parameter for the default DPS thrust [18:45:09] I mean doesnt matter I was just curious [18:45:41] right [18:45:54] on the relevant MEDs for the RTE there isn't that option [18:46:03] the option you have on most of the "transfer to MPT" MEDs [18:46:35] so in the real RTCC they probably would have to edit the default parameters for it [18:47:10] which they could do [18:47:47] I don't think I have heard any RTE maneuver being done on the FIDO loop yet [18:47:58] I guess it's mostly TEI and the TEC MCCs [18:48:05] which were actually being executed [18:48:12] oooh [18:48:13] haha [18:48:20] dumb me [18:48:30] I just have to listen to more of the Apollo 13 FIDO loop [18:48:38] more than one DPS burn coming up [18:49:40] I bet that will become relevant [18:49:51] RETRO loop actually [18:55:44] so the total thrust can be changed [18:55:55] not sure about thrust factor specifically or even time to throttle up [18:56:19] from the IBM RTCC documents I know though that those numbers are in the array of numbers being transferred for the burn simulation [19:27:27] auto optics work as before the read counter change [19:27:54] hmm [19:27:59] overshoots the target by some [19:28:04] in both trunnion and shaft [19:28:15] it basically circles around the star, slowly moving in [19:28:20] heh [19:28:22] interesting [19:28:33] where did you get the slew rates from? [19:28:35] pretty much the same behavior with any conversion factor [19:28:53] from error counter to slew rate [19:28:59] Delco manual [19:29:07] hmm [19:29:17] when I take 3 different pages from it and calculate the rate I get 3 different results [19:29:27] ok maybe 2 [19:29:35] hah [19:29:37] that sounds about right [19:29:50] but I think it's just the wrong approach [19:30:03] it can't be a simple conversion to slew rate [19:30:56] I wonder if we can find the answer in procurement specs [19:31:38] the thing is, it worked before by directly applying the output to the error counter to the actual optics angle [19:31:44] with the right conversion factor [19:32:07] why does that not give good results with the read to error counter feedback [19:32:37] hmm [19:35:58] so, there are certain modes in the CDU where the feedback path from the read counter to the error counter is inhibited [19:36:35] The inhibit read counter signal OINHRC is produced during either of the following conditions: a) OSS coarse align and thrust vector control disable is present and OSSEEC is not present orb) OSSZ is present. OINHRC is applied to the read counter rate select logic in the error angle counter and logic module where it prevents the generation of read counter incrementing pulses. [19:36:35] yes [19:36:52] CA signal in the Systems Handbooks [19:37:02] for ICDU that is directly the IMU coarse align output from the AGC [19:37:29] for the OCDUs it is error counter enabled plus TVC disabled [19:37:45] right [19:37:59] RR CDUs don't have that logic I believe [19:38:14] never any feedback from read to error counter [19:38:16] I think [19:38:26] hmm [19:38:47] man it would be great if Don's ND-1021042 wasn't missing these pages [19:45:22] the way the optics drive works it pretty much should be a direct conversion to a slew rate [19:47:10] I may have found something [19:47:35] ah no [19:47:48] just a typo in a debug string :D [19:50:00] heh [19:50:03] also lol [19:50:11] I found the procurement spec for the optics assembly and am reading it [19:50:20] and this page is talking all about tests to perform for the star tracker [19:50:37] this is the first rev :P [19:51:48] uhm [19:51:51] dumb question [19:51:57] what the AGC outputs to the error counter [19:52:06] is that increments or total desired error counter content? [19:54:31] uhhhh [19:54:34] not sure what you mean [19:55:02] whatever you write into the CDUD registers is counted out to the error counter, one pulse at a time [19:55:22] the number in the AGC's register decrements, and a pulse is generated, which increments the error counter in the CDU [19:55:40] at 3200 pulses per second [19:56:42] right, we (and the pre-pulses Virtual AGC) do that a bit hacky [19:56:49] and by CDUD I mean CDUTCMD and CDUSCMD [19:56:53] of course [19:57:04] I tried something [19:57:28] the content of the AGC output overwrites the error counter instead of being an increment to it [19:57:32] and it works like perfectly [19:57:57] how were you doing it when it wasn't working? [20:00:06] ErrorCounter = delta & 077777; [20:00:07] instead of [20:00:10] ErrorCounter += delta & 077777; [20:00:20] mmm [20:00:36] but you're limiting that to 384 after you do the addition? [20:00:58] yeah, directly the next lines are [20:00:59] if (ErrorCounter > 0600) [20:00:59] { [20:01:00] ErrorCounter = 0600; [20:01:01] } [20:01:42] without it being an increment that could be changed of course [20:01:58] hmmmm [20:02:01] delta & 077777 is just supposed to limit delta [20:02:03] weird [20:03:20] I couldn't prove it to you (yet), but it almost seemed like the AGC was commanding higher increments than needed to get to the desired angle [20:03:32] but with it being the total error counter content it works great [20:05:27] so if that's the case then there must be a zeroing of the error counter commanded or something [20:07:11] which would mean, occasionally taking away the error counter enable signal [20:07:12] in that case it could be increments [20:07:18] it really should be increments [20:07:32] it has to be, the AGC and CDU can only speak in increments [20:07:44] there's no way for it to directly transfer a number across [20:08:14] yeah [20:09:26] error counter is zeroed when the enable signal goes away [20:10:15] and timing wise that is whenever the AGC wants it [20:12:37] yep [20:15:19] so I don't think the AGS is disabling/enabling the error counter all the time [20:20:51] AGC* [20:29:19] hmmmmm [20:29:25] ok I can prove it to you now [20:29:32] I just had a thought [20:29:37] the AGC definitely puts too much on the error counter [20:30:04] the AGC of course has no way of knowing what is on the error counter [20:31:57] the max shaft error counter value for example is 16.285° [20:32:12] 16.875 [20:32:28] the shaft was maybe 20° still away from the target [20:32:36] error counter had a value of maybe 10° left [20:33:06] bad example [20:33:39] forgot how much the AGC sent at once [20:33:54] but it definitely added to the error counter enough so that it would overshoot [20:34:54] hmm [20:35:16] nevermind [20:36:28] so the AGC only sends... what, 164 pulses at a time to the optics? [20:36:46] once every 0.96 seconds? [20:36:48] yeah I think it was 164 [20:36:57] that's not consistent between CMC software [20:37:05] I'm looking at Comanche 55 right now [20:37:11] Artemis does it twice as often and half as much I believe [20:37:17] ah interesting [20:37:28] but, that is faster than the optics move? [20:37:50] er, no, hm [20:37:53] MAXPLS1 DEC -82 B-14 # WAS -164 [20:37:58] in Artemis code [20:38:00] yeah [20:38:17] well it only takes two cycles for the error counter to max out [20:38:25] then it is counting down again due to the feedback [20:38:28] and then back to full [20:38:52] when it's near the target the error counter still has enough counts on it to make it to the target [20:38:55] but my point is, the error counter definitely won't have reached zero by the time the AGC sends more pulses? [20:39:11] hmm [20:39:23] that's a function of optics speed right? [20:39:26] it would have move awfully fast for that [20:39:37] gotcha [20:39:44] but maybe [20:40:30] let me check how often it does it [20:40:49] the thing is, the speed will already decrease, due to error counter counting down [20:40:59] it's not going to be constant speed [20:41:18] not with this direction translation from error counter to rate [20:41:22] direct* [20:41:30] which might not be right [20:41:41] hmm [20:42:34] from the procurement spec: "With a variable AC, 800 cps, input voltage applied to the Motor-Generator control windings, the voltage shall be increased until the SXT shaft or trunnion starts to rotate. The input voltage shall not exceed 5.3 VAC. [20:42:56] The input voltage shall then be decreased to the lowest level required to maintain rotation. The input voltage shall not exceed 4.2VAC" [20:43:12] so, it may not necessarily be linear, if it takes more voltage to get it moving than to keep it moving [20:43:30] every 0.5 seconds it sends the 164 pulses [20:43:56] wait really? that's not what the comments say [20:43:57] hmm [20:43:59] Apollo 15 Delco manual has 83 pulses per 0.24 seconds [20:44:10] so about the same [20:45:22] it not being linear could be interesting [20:48:35] "integrating servo loop" [20:51:45] that sounds suspicious [20:53:16] ah [20:53:17] ASSEMBLY TEST PROCEDURE FOR THE APOLLO G&N SYSTEM OPTICAL SUBSYSTEM, BLOCK II [20:54:06] http://virtualagc.github.io/virtualagc/AgcDrawingIndexBox465.html [20:54:11] drawing 2015500 [20:54:14] maybe helpful? [20:56:03] I'll look through it [20:59:32] oh shit [21:00:03] 2015567 is also really good, wow [21:01:12] man I need to stitch these [21:01:15] these are great [21:05:42] yes [21:06:00] but I don't think they are helping me much :( [21:08:23] booo [21:09:16] it looks so great when it's not an increment to the error counter [21:11:39] let's see how it looks in Artemis [21:13:17] uhh [21:13:48] ah, forgot to rebuild [21:19:04] updating it twice as often makes it more stable [21:19:34] I wouldn't call it great, but it's better in Artemis [21:26:38] so if the drive is proportional to the error counter value, and you just copy the error counter value directly across [21:26:46] wouldn't that make artemis drive slower? [21:27:57] that is with the pulses from the AGC being increments, if you mean that [21:28:17] ah [21:28:24] you are right [21:28:38] what's the PCR on that, haha [21:31:53] the GSOP about rate aided optics (P24): [21:32:12] "In this subroutine, shaft and trunnion rates are supplied to the optics instead of shaft and trunnion angles" [21:32:48] oh [21:33:01] that just means that read counter to error counter feedback is disabled [21:33:18] by enabling TVC [21:34:42] maybe I should try P24 now, to see how it works [21:36:21] that would probably work better than anything else right now, haha [21:36:28] heheh [21:57:32] night! [15:14:30] hey [15:14:39] hey Alex [15:14:47] still no luck with the auto optics... [15:15:46] bummer [15:18:26] the CMC always outputs the optics angles change it wants in full [15:18:56] previously that was directly applied to the angles itself, that's why the optics was moving in intervals [15:19:19] and if the angle the CMC wants is achieved immediately then it all would work fine [15:27:13] yeah I was reading along with your discussion yesterday with Mike [15:28:29] I must still be missing something [15:32:06] I wished I could make that change to the error counter that the CMC input is the total error counter content and not an increment to it [15:32:11] but I know that would be wrong [15:32:23] and it would be bad any other CDU mode [15:45:36] hmm [15:45:49] I wonder if the issue is actually in Virtual AGC code [15:45:59] changed by NASSP or not [15:46:05] but there is special code [16:02:41] hmm interesting [16:02:54] I don't know though [16:03:34] I don't think that should cause these issues [16:03:47] I mean, the auto optics do reliable find the star [16:03:59] it just overshoots quite a bit [16:08:17] what am I missing... [16:17:55] morning! [16:18:29] maybe some other special case code elsewhere in the code? Im sure you've probably looked for that already [16:18:35] hey Mike [16:19:30] hey [16:20:48] what's up? [16:21:02] not finding the auto optics issue... [16:21:32] hmm [16:22:22] the CMC always outputs the absolute angle change it wants [16:22:35] that's why it works perfectly if the error counter gets that absolute value [16:22:45] together with the read to error counter feedback [16:23:24] and you can't make the optics that quick that the complete previous command has already been achieved in full [16:24:55] which rope are you doing most of your testing with? [16:25:01] Apollo 11 [16:25:05] so Comanche 55 [16:25:14] our previous solution directly applied the CMC output to the optics position [16:25:16] so infinite speed [16:25:47] because of that, when the CMC is outputting new commands, the optics already were at the commanded position [16:25:56] then it works [16:26:00] right [16:26:08] could it be something in Virtual AGC code? [16:26:18] our version of it? [16:26:25] hmm [16:26:27] maybe [16:26:46] ICDU and OCDU handling is definitely quite different there [16:27:10] would it be helpful for me to try to set this up with the FPGA AGC to see how the hardware behaved? [16:28:02] I don't know [16:28:06] haha [16:28:07] probably not [16:28:22] I mena the code in your agc_engine.c looks fairly innocent [16:28:25] *mean [16:28:31] the only difference to the real behavior is that the CMC pulses the commands out in a quite short amount of time [16:28:32] just moving the numbers to an output channel [16:28:35] yeah [16:28:42] it just does it all in one go [16:28:56] yeah it would take 120ms to pulse 384 counts out in reality [16:29:52] the 2^2 signal is disabled during that time [16:29:58] but for us it is instantly, so no need [16:30:11] it is? it doesn't appear to be in my simulation [16:30:50] the ND-Many Numbers explains that the CMC pulses have precedent [16:31:52] so if they happen at the same time, only CMC pulses to the error counter get in [16:32:17] precedent yes, but they're phased [16:32:25] https://i.imgur.com/vJtooaa.png [16:32:43] ah [16:32:56] well, it doesn't matter for us right now [16:33:03] also, one minor thing I have to improve is the sign of the error counter [16:33:33] in our CDU there is the theoretical case that 2^2 counts the error counter below 0 [16:33:58] but it can't really happen as there is near instant feedback, error counter -> optics drive -> read counter [16:34:04] still, needs to be handled properly [16:34:09] won't be cause our current issue [16:36:35] also, the error counter saturation detection does some things I haven't fully understood yet [16:36:49] does it inhibit something in the read counter? [16:38:10] I don't think so [16:38:16] it just keeps the error counter from going above 384 [16:39:03] ok [16:41:00] I think what would help me is you simulating the error counter fully [16:41:18] at least we could eliminate some possible issues then [16:41:30] tha'ts what you see in that simulation picture :) [16:42:03] oh [16:42:04] haha [16:42:08] https://i.imgur.com/rtmCDwb.png [16:42:19] I have it wired up in IMU mode, but [16:42:40] 384 pulses moved my shaft by 16.875 degrees, and the read counter moved to match it [16:42:49] which I believe is correct [16:43:03] yes [16:43:08] is that using AGC software? [16:43:17] or did you put in the 384 yourself [16:43:33] I pulsed in the 384 manual, at 3200 pulses per second [16:43:40] ok [16:43:43] and then? [16:44:07] and then what? haha [16:44:19] error counter -> shaft angle [16:44:28] how did you implement that [16:44:46] I put a really really simple DAC in the D/A module [16:45:09] and just made my shaft move if the value was above a certain level [16:45:22] interesting [16:45:25] so only one speed? [16:45:40] yeah [16:46:27] mmm [16:46:44] I feel like it would really help to know exactly how quickly the optics actually moved [16:47:15] Delco manual has some suggestions for that [16:47:46] what happens for us is this. The shaft is away from the target by a large amount. So CMC ramps the error up to 384. [16:48:13] with my current optics speed it goes down to about 300 when the next pulses from the CMC are coming in [16:48:38] but the behavior is pretty much the same at any speed, at least any linear increase of speed with the error counter [16:49:16] at 20° error the counter is 300 again and the CMC puts it to 384 again [16:49:51] but then when it is e.g. only 8° the CMC only needs to add 164 or so [16:50:01] but that puts it at 384 yet again, from 300 [16:50:12] so full speed past the target [16:50:23] it overshoots a bunch of times back and forth [16:50:26] and finally settles [16:51:13] right [16:51:17] hmmmm [16:51:30] and that happens because the CMC pushes the total angle change it wants onto the error counter [16:51:32] definitely [16:52:32] well, that is an annoying thing for it to do, heh [16:52:37] sure is [16:52:41] how slow did you make the one speed D/A? [16:53:19] uhhhh, I just fiddled with it until it kinda worked [16:53:21] what you set up as a test is not really taking into account the annoying things the CMC does [16:53:33] pushing more counts every 0.5 seconds [16:54:10] basically the same as I had when the CMC to error counter is an absolute value, not increment [16:54:14] works awesome [16:54:18] thanks to the feedback [16:55:12] yeah [16:55:21] if it's a linear relationship between error and optics speed then the speed doesn't really matter [16:55:31] if I make it reaaaallly slow it will still overshoot [16:55:40] due to the remaining counts in the error counter [16:58:07] I'll test that [16:58:31] the counter probably has near 384 until it overshoots [17:01:05] I really want to blame this on the CMC :P [17:05:33] yep [17:05:42] at 1% of "normal" speed [17:05:54] 2^2 is really slow of course as well [17:05:58] CMC still sends increments [17:06:03] small ones, but positive [17:06:15] hmmmmmmmmm [17:06:19] overshooting the star at full error counter [17:06:34] and does not start going down until it is past it [17:06:49] so, here's a dumb question [17:06:50] because then the CMC actually sends negative increments [17:06:58] how sure are you this isn't correct behavior? [17:07:05] I don't [17:07:22] but it just seems wrong, [17:07:39] why would it keep on sending increments like that [17:07:56] the CMC output is the angle change it wants at that time, without keeping track of what it sent to the error counter [17:07:58] yeah I don't know [17:08:05] yeah [17:08:23] is there something nulling the error counter that we missed [17:09:09] something in the coarse align mode [17:09:16] because that is active all this time [17:09:31] hmm [17:10:00] or the error counter output [17:10:16] the output is a voltage proportional to current error counter content, right? [17:10:27] yes [17:11:34] can you connect your AGC and CDU simulations, I send you a erasable memory state where it is already driving the optics and you see what happens? [17:12:17] oh boy uhh [17:12:23] maybe [17:12:25] we can try [17:13:46] maybe something is coming from the CMC that is getting lost in our version [17:14:25] CDUTCMD and CDUSCMD [17:14:38] those are getting zeroed with pulses being sent out, right? [17:15:30] yes, each pulse out decrements CDUnCMD by one [17:16:27] and if it takes 120ms for the pulses to go out, and the CMC is generating new pulses once every 0.48 seconds, then it will have been zeroed each time it goes back to send more [17:16:49] uh, one problem with the connecting simulations idea [17:17:02] the AGC sim is very big and very slow [17:17:11] I don't know if I've ever been able to simulate more than a second on it [17:17:57] was just an idea, haha, I'd just like to see the actual behavior of the CMC in connection with your CDU [17:18:43] yeah [17:18:51] it just might have to go to FPGA land for that to happen [17:19:02] which I don't know how to do for the CDU quite yet [17:24:43] still, send me the scenario and I'll poke at it on the AGC at least [17:24:58] and see what I can do in terms of CDU FPGA-ification [17:29:30] ok [17:29:55] it will be in P52, just when it tries to start driving the optics [17:30:25] do you want before or after the PRO for that? :D [17:31:11] uhh, well, don't forget that me loading a scenario generally involves a restart, due to internal state that I can't load [17:31:26] so, before the PRO, and we'll see how mad it is about the restart [17:31:33] ok [17:32:43] I'm already seeing input channels and flagwords being messed up [17:33:07] heheh [17:33:33] you can try yourself by doing a V69 right before the PRO [17:35:07] right [17:35:11] it drives, but 120 alarm [17:36:08] could be a problem [17:39:18] nah [17:39:25] it drives and to the right direction [17:39:50] cool [17:41:27] sweet, thanks [17:41:36] now I need to remember how to make this into something I can load :D [17:42:01] and I needed to remember how to make these [17:42:13] hehehe [17:42:24] or rather, if I needed to do anything additionally [17:42:34] it's just a button in the Project Apollo MFD [17:43:12] don't forget to null the erasable memory [17:43:23] or was that only an issue with the real AGC? :D [17:43:41] haha, only on the real one [17:44:55] I would suspect you are going to see the 162 pulses or whatever it was every 0.5 seconds [17:45:03] without a response from a connected CDU [17:46:49] I would suspect you are right [17:50:04] hmmm [17:50:14] and I need to build a new AGC FPGA that actually sends these pulses out [17:50:26] haha [17:53:32] hmmmmm [17:54:21] also what input channels am I going to need? [17:56:41] channel 33 [17:57:03] bit 4 to 1 [17:57:34] bit 5 to 0 [17:58:00] that might already be it [17:58:18] and I just noticed something [17:58:25] not related to the current issue though I think [17:58:30] channel 12 bit 11 [17:58:35] Disengage optics DAC [17:58:46] Artemis uses that [17:58:55] oh that will zero that error counter [17:59:15] the _EEC signals (enable error counter) are tied directly to DAC enable for the optics channels [17:59:30] and if that goes away the error counter is zeroed [18:00:09] okay, loaded up your core file onto my FPGA and have been greeted by P52, flashing V01 N70, with 00001 in register 1 [18:00:39] that is star number 1 [18:00:42] now PRO [18:00:54] that starts the driving [18:01:01] and I get a flashing V51? [18:01:06] if the bits are set correct in then shows shaft and trunnion in R1 and R2 [18:01:14] if not you get a flashing V51 :D [18:01:16] haha okay so I have bit problems [18:01:21] boo [18:01:29] what else could it be [18:01:39] the bit numbers I mentioned were starting with 1 [18:01:48] 1 to 15, not 0 to 14 [18:02:27] oh I haven't done that yet [18:02:33] changing input channels is not so easy lol [18:02:57] yeah, you immediately went to manual optics [18:03:15] you basically had the optics mode switch in manual instead of CMC [18:03:30] let's see, how did I do the channel simulation [18:08:11] is there an equivalent for the DAC disengage for ICDU or RR CDU? [18:08:54] uhh [18:09:03] I don't see anything [18:09:16] can you do a V01N10E 33E for me to get your full channel 33? [18:10:44] sure [18:11:04] I would have guessed you needed all 1s, except bit 5 [18:11:53] oh okay that works haha [18:12:02] channel 33 is 77757 [18:13:44] okay that did it [18:13:47] it's showing me angles now [18:14:16] soooo pulse outputs from AGC [18:14:17] that's the angles it wants [18:15:21] are you sure about channel 12 bit 11 zeroing the error counter? I don't think that is even going to the CDUs... [18:19:56] I'm just seeing it going to the optics itself, not letting the CMC commands through anymore [18:20:13] ah maybe not [18:20:51] I need to look up what exactly the connections are [18:21:46] according to GSOP section 2 Colossus doesn't even use it [18:22:13] yeah nevermind then, that was wrong [18:22:36] and Artemis only to fix one issue where TVC is active and the CDU would still drive the optics by the same amount [18:29:57] still waiting on synthesis for the fpga... [18:31:27] ouch [18:31:45] maybe you need a supercomputer [18:31:48] an IBM 360 should do [18:39:19] oookay, programming FPGA... [18:41:45] okay there it goes [18:41:59] so should I be looking at + or - counts? [18:43:08] uhh [18:43:10] let me check [18:45:14] plus in both trunnion and shaft [18:46:01] cool [18:47:51] well, I'm seeing 3.2kHz pulses that last for 50ms, once every 480ms [18:48:06] that sounds right [18:49:25] yeah, would estimate approximately 164 pulses [18:49:31] each time [18:50:10] which is correct [18:50:27] yep [18:50:37] and then it wold start driving [18:51:02] and the error counter gets decremented from the read counter [18:51:41] hmmmm [18:51:45] dumb idea, hold on [18:52:00] any interesting activity on channel 12? [18:54:31] I was about to say that's not easy for me to check, and then I remembered I have this entire monitor panel [18:54:36] haha [18:55:30] what are your expected contents of channel 12? [18:56:53] uhh [18:57:01] it doesn't appear to be writing to channel 12 [18:57:21] if I'm using the monitor correctly [18:58:04] so for fun, I looped the output shaft output pulses from the AGC directly to the input pulse pin [18:58:15] so I could watch it at least do something [19:00:01] and it does indeed start slowing down how many pulses it's sending [19:00:05] and stops [19:00:07] so that's cool [19:00:08] hmm [19:01:01] yes, it never writes to channel 12 while doing this [19:01:14] it only sets it to 00042 when it wants to start [19:07:11] https://photos.app.goo.gl/dx7yzk1mqwqa2JTn9 [19:07:29] those are the output pulses I get if I feed them directly back into the input counter [19:14:58] channel 12 has the OCDU error counter enable discrete [19:15:08] other than that there indeed shouldn't happen much [19:16:15] 42 is ICDU and OCDU error counters being enabled [19:17:26] that video looks very nominal [19:18:20] pretty much how we had it before, CMC output directly changes the sextant angle/read counter [19:18:44] right [19:24:09] "By sending an average pulse rate [19:24:10] low enough to prevent saturation the CMC does not have to monitor gimbal movement [19:24:10] to determine when pulses should be stopped." [19:24:15] thanks ND-1021043 [19:25:23] hahaha [19:27:55] hmm [19:28:08] what if I really make the optics driver that fast [19:28:11] drive* [19:28:50] I guess it just has to out-do the CMC pulses [19:28:58] so more than 16.875°/s or so [19:29:49] hmmmm [19:29:59] wouldn't that just be slightly faster than before... [19:31:32] could it be that I just made it too slow all this time... [19:32:22] yeah I think if you make it fast enough to not saturate it will be fine [19:34:42] the CMC will still add more to the error counter than it should though [19:34:58] will it? [19:35:32] I feel like that will work itself out towards the end [19:37:35] no, that would only work if the error counter has been completely nulled by the time the next burst from the CMC is coming in [19:37:40] it still overshoots [19:37:51] a bit better I would say, without saturating [19:37:58] it reaches 340 counts max in my current test [19:42:15] the overshooting is also very weakly damped [19:42:36] it takes about 10x overshooting until it has settled [19:44:34] it does get better when I make the shaft drive even faster [19:44:53] I wish I had some better numbers for how it should drive in auto optics [19:45:48] yeah I feel like that is going to be the key [19:45:51] at this point [19:46:24] yeah [19:55:58] "Servo motor-tachometer at 5952 speed with respect to trunnion prism." [19:56:20] "Servo motor-tachometer at 2976 speed with respect to the shaft-axis line-of-sight plane" [19:56:25] is that the same speed? [19:56:26] hmm [19:56:56] manual drive is quoted as 696.8 and 348.9 speed, respectively [20:00:48] oh how about this one [20:01:31] "The CDU shall exhibit an average torquing rate of 1.83 +- 0.45 degrees per second for the trunnion rate command and 7.32 +- 1.83 degrees per second for the shaft rate command." [20:02:24] interesting [20:03:49] definitely slower than the CMC pulses though [20:04:06] hmm [20:05:08] so the optics can't outrun the CDUs [20:05:57] from the Delco manual I had about 5°/s trunnion and 20.0°/s shaft rate, maximum [20:07:25] what page in the delco manual for that? [20:08:31] PDF pages 508, 511-513 [20:08:45] Apollo 15 [20:09:09] HW-49,52-54 [20:15:20] hmm yeah [20:15:25] that is pretty clear [20:25:32] https://photos.app.goo.gl/iMLQmhKGqpZLg1Kw8 [20:25:45] https://photos.app.goo.gl/YnmVH8E6XQNbWirw8 [20:25:54] slightly different in the apollo 12 version [20:28:17] same as HW-49 and 52 [20:28:21] except for the input [20:28:33] they changed it to send pulses twice as often at some point [20:29:03] yeah [21:26:17] night! [11:02:03] Hey indy [11:02:12] I managed to get the Mtimer MFD working [11:02:18] for both CSM and LM [11:03:04] hey [11:03:06] nice! [11:03:16] I installed VS community and it worked in the CSM but not the LM, in the LM it would just be showing GET of 0:0:0 [11:04:06] added all the dependencies and rebuilt, voila. Work in both CSM and LM [11:05:23] good work [11:05:47] luck [11:05:54] my first time touching VS [11:06:04] googled my way through [11:06:34] I started doing Orbiter stuff in Lua with the Lua MFD that comes with Orbiter, just because I couldn't really figure out VS [11:06:47] I could do C++, but VS has a steep learning curve initially [11:07:12] I've never touched any sort of computer programming except the time in college [11:07:34] even that was just basic C [11:07:53] and I don't remember a damn thing [11:09:51] the word lua means nothing to me other than it makes software work [11:11:05] haha [11:11:34] well Orbiter supports lua scripts [11:11:55] it has by default a Space Shuttle ascent autopilot [11:13:41] https://www.orbithangar.com/showAddon.php?id=740ba254-970f-4b6b-9fea-861d83d14df7 [11:13:49] this is one of the first things I did [11:16:14] so I guess you can post your MFD in the thread you created for that in the NASSP subforum? [11:30:18] would the MFD work for all though? [11:31:02] or does everyone need to build the thing up according to their folder structure? [11:31:09] good question [11:31:36] remember, I didn't get yours to work until I installed VS19 [11:31:50] even then it worked only partially [11:31:58] how about you send me what you got, and I try to make it work for me [11:32:12] if it doesn't I might know what to change to make it work for everyone [11:32:18] and then I can put in on the forum [11:32:21] do I send just the .dll or the entire sdk [11:32:41] the VS files only [11:32:57] I'll build the dll myself [11:33:12] the dll will probably work for everyone [11:33:46] if you added stuff with your personal folder structure to the VS files then other people might have trouble building though [11:34:03] but that can be changed to work for everyone [11:34:27] as long as the folder with the VS files is in Orbitersdk\samples [11:35:48] I've basically just used brute force and used my personal file location, e:\nassp.. [11:35:55] so I don't think it's gonna work for all [11:36:58] that can be fixed, I can do that [11:38:51] thanks for your help indy [11:39:03] apologize for being so needy [11:39:25] this mfd probably isnt your highest priority right now [11:39:58] oh you did the majority of the work it looks like, haha [11:40:09] the rest I know how to do, changing VS project files [11:40:58] hmm [11:40:58] https://gofile.io/?c=LC7huV [11:41:02] you said VS 2019 [11:41:07] that might be a problem [11:41:15] yes, the free one [11:41:17] NASSP is using VS 2017, that is what I have installed [11:41:20] VS community I think it's called [11:41:28] yeah [11:41:35] was the same for 2017 [11:42:13] nice file size [11:42:20] sorry [11:42:24] haha [11:42:29] I think VS creates a bunch of debugging files [11:42:30] I don't know what's needed and whats not [11:42:37] won't have to be included in the release luckily [11:42:43] I just packaged the whole thing [11:42:46] yeah [11:42:50] no problem [11:43:16] was just funny to see an MFD with lierally one single job to be that large :D [11:43:23] haha [11:43:26] true [11:43:35] oh yes [11:43:40] I just remembered [11:43:41] ok, how do I do this... [11:43:43] I did make a change [11:44:08] afxres.h [11:44:13] I changed it to windows.h [11:44:22] I hope it doesn't cause a problem [11:45:04] looking at it right now [11:45:14] the initial build said it was missing and I couldnt find afxres anywhere [11:45:31] I googled and it said it was fine to change it to windows.h [11:50:02] should be ok [11:50:24] trying to make the additional include folders work right now [12:05:29] ok, got it to build [12:05:42] what the Orbiter sample projects use are folder macros [12:06:04] $(OrbiterDir) as your Orbiter folder for example [12:06:15] and there is one central place where you change that to your own folder [12:06:23] and then everything magically starts working [12:06:54] that simple huh? [12:07:04] I added every single folder individually [12:07:12] yeah I know :D [12:07:33] let's see if this actually works now... [12:07:41] and then I'll fix release build mode as well [12:08:56] works in the CSM [12:08:57] what's the difference between debug and release? [12:09:19] and in the LM [12:09:27] wonderful [12:09:53] for such a tiny MFD not much, but if you run it in debug mode and an error happens it sends you to VS and you can debug it step by step [12:10:00] release mode is more efficiently build [12:10:08] smaller dll file and better performance I guess [12:11:04] not that I would be able to debug anything [12:11:12] I was just winging it [12:12:37] and release mode fixed [12:12:38] I think [12:12:51] I have no idea what exactly I did differently, just that it works and I'm never touching it again in case it breaks [12:13:15] haha [12:13:26] I would like you to test my dll file though [12:13:32] if it works for you as well [12:13:38] sure [12:13:42] I have a backup [12:13:44] you can back up your own in the mean time if you want [12:13:46] good [12:14:19] just curious [12:14:38] https://drive.google.com/open?id=15wJQPDSOnuAhuiprOG7qFh-zIVnurI0C [12:14:39] are the files in orbitersdk even needed? [12:14:47] since it's already compiled into a dll [12:14:53] Orbiter only needs the dll [12:15:41] it's good [12:16:06] yours works perfectly [12:16:43] so the one I compiled would only work for me, since I've built it using my own file structure and not a macro [12:17:08] is that right? [12:17:48] I'm not sure really [12:18:07] I'm about 60% sure it would work for everyone [12:18:39] in any case, I'll assemble a release package put it on the forum and say you did all the work :D [12:19:50] nah, I did essentially nothing [12:20:09] I didnt make the dll, I only adapted it to work for me [12:20:59] it works, that's the important thing [12:21:18] yes, that's true [12:21:29] but I have my doubts [12:21:49] because the one you modified did not work until I installed VS19 [12:21:58] hmm [12:21:59] not the redistribuables [12:22:04] VS19 the program [12:22:16] that's what confuses me [12:22:25] yeah could be an issue [12:22:41] my files are going to be VS2017 by the way, that's all I have [12:22:49] the dll doesn't care much though [12:23:08] I would think, you might only need the redistributable [12:23:15] exactly [12:23:19] although the including of the windows.h might be an issue there [12:23:34] is that so? [12:23:45] because it's Windows and VS version specific [12:23:48] although, haha [12:23:52] I can safely delete that line [12:23:55] and it still builds [12:24:07] I dare not delete anything [12:24:16] because I don't know what anything does [12:25:27] anyway, I do hope it works for everyone [12:25:33] yeah [12:25:35] it's really a useful tool [12:25:40] I'll release it without the Windows.h thing [12:26:12] you're the expert, I have no idea what windows.h even does [12:26:23] or afxres [12:26:31] or why it's interchangable [12:27:35] windows.h probably includes afxres or so [12:27:42] not really sure [12:27:54] 290MB total folder size, with all unnecessary files removed it is 52KB [12:28:11] endless amounts of build debugging data if something goes wrong [12:29:17] haha [12:29:32] most of the 290mb is in the .vs hidden folder [12:29:47] probably some temp files [12:29:53] yeah [12:30:46] hmm [12:30:58] the MFD is for Orbiter 2016 now I guess [12:31:02] the dll file definitely is [12:31:06] Orbiter Beta even [12:31:24] although the VS files are general enough, if you build it yourself it would work for Orbiter 2010 and NASSP 7 as well [12:32:39] the new one is exclusively for NASSP8? [12:33:11] the dll probably is yes [12:33:25] because it is build with includes to the saturn.h etc. [12:33:28] and Orbitersdk [12:33:39] thats true [12:33:58] it will work in the Orbiter Beta, quite likely in Orbiter 2016 but a bit less likely in Orbiter 2010 [12:34:24] at least I fly exclusively NASSP8 now [12:34:29] so I'm good [12:34:47] looking back [12:34:57] NASSP 7 was so long ago [12:34:59] ok posted the files [12:35:13] February 2017 was the release of NASSP 7 I think [12:35:29] we are kind of waiting for the next stable Orbiter release to make a push for a NASSP 8 release [12:35:54] yeah 2 years passed so quick [12:36:00] make that 3 [12:36:04] and I remember way back during the beta [12:36:08] right [12:36:12] derp [12:36:18] back during beta [12:36:25] we had to use IMFD for everything [12:36:28] how far we've come [12:37:40] then came LVDC++ [12:37:44] and MCC [12:37:52] absolute gamechangers [12:38:02] RTCC MFD as well [12:38:18] RTCC MFD is getting some big updates yet again [12:38:49] that's why there haven't been many updates lately [12:39:47] what else could you be adding I wonder [12:41:21] it's less adding something new, but bringing something that already existed to a new level [12:41:42] mainly the midcourse correction and LOI targeting is now very close to what they really used in the RTCC [12:41:45] including the displays [12:42:24] https://i.imgur.com/THJBg90.png [12:42:37] this is a screenshot from stock footage of a documentary about mission control [12:42:47] LOI targeting display, during an Apollo 14 sim, October 1970 [12:43:00] https://i.imgur.com/gEmw7um.png [12:43:07] and this is how it looks in the RTCC MFD now [12:43:58] so it computes all possibilities and presents it to you in table format? [12:45:23] yeah, several options [12:45:43] the pre Apollo 14 LOI targeting had even more LOI solutions it calculated every time [12:46:29] the main thing I have left to do is write the manual for the new MCC and LOI targeting [12:47:34] yeah I was just about to mention [12:47:43] I think a manual is definitely needed [12:48:08] yep [12:48:09] quite a few terms I don't understand [12:48:35] quite a few terms I needed some time to understand [12:49:20] in the end you will probably use the same solution every time, at least for pre Apollo 13 missions [12:49:25] solution 7 [12:49:50] you look at the display, select the solution you like and on the next page you generate the TIG and DV vectors from it [12:50:07] fairly straight forward... once you know what you are looking at [12:51:55] yeah, I think that would need some getting used to [12:52:10] intersection, coplanar, min theta [12:52:19] I dont understand [12:52:40] the previous one was much easier [12:52:53] for sure [12:53:08] the previous one only had what are the Plane solutions on this display [12:53:23] inserting into the desired orbital plane to fly over the landing site later on [12:54:09] coplanar is also simple, the post LOI orbit is coplanar with the pre LOI orbit. So a completely in-plane burn, at perilune. You won't fly over the landing site with that one [12:54:32] lowest DV to get into any kind of lunar orbit basically [12:55:25] kind of like an landing abort situation? [12:55:45] maybe the LM had some issue [12:55:50] yeah [12:55:55] CSM could still do SIM bay experiments [12:56:00] or the Saturn had an issue and the midcourse correction was giant [12:56:09] and you don't have the DV left for a normal mission [12:56:15] yeah exactly, some alternate mission [12:56:33] that makes sense [12:56:38] intersection solutions are relevant for the later missions where you don't do a LOI-2 circularization burn, but are doing DOI already, with the CSM, in place of LOI-2 [12:57:24] that adds some geometrical issues, because you want to be at perilune at PDI [12:58:16] so it calculates a post LOI perilune altitude (instead of the specificied usually 60NM) that makes the geometry work [12:59:01] quite difficult topic [12:59:45] Min Theta is using an input maximum DV, and it tries to achieve the orbital plane as best as it can, within the DV constraint [13:00:01] let's say the coplanar solution is 2500 ft/s, plane solutions 3000 ft/s [13:00:19] if you tell it it can use 10000 ft/s then the min theta solution is the same as the plane solution [13:00:33] if you tell it it can use 0 ft/s then the min theta solution is the same as coplanar [13:00:56] but if you give it something between 2500 and 3000 it will try to fly over the landing site as much as it can with the DV [13:01:53] find out more in the RTCC MFD manual, updated version coming soon... [13:04:06] looking forward to it! [13:04:31] to won't become easier to use, but more options and most importantly, realistic options [13:04:35] it* [13:05:28] I suspect many users won't even realise it's there [13:05:45] I think a lot of them are flying MCC [13:06:12] yeah, that's the idea [13:06:41] RTCC MFD is mainly for still unsupported and custom missions [13:07:05] if you want to play FIDO as well as astronaut [13:07:48] yup [13:08:18] can't wait for the day where we aren't constrained to land at the apollo sites [13:08:24] that's why I have no issue with making the RTCC MFD even more complicated :D [13:08:28] literally land wherever we want [13:08:48] I mean, you can kind of do that [13:08:53] but it's very difficult [13:09:17] what the RTCC MFD does not have is a targeting tool for TLI that calculates launch windows etc. [13:09:51] because it's handled by LVDC? [13:10:14] because I haven't found a good source for how that was calculated and it's quite challenging [13:11:10] what AlexB_88 has done once is select a landing site on the far side of the Moon [13:11:22] one where he was flying over anyway in the normal mission he was using [13:11:43] you have to change the landing site vector in the CMC and LGC, change some numbers in the RTCC MFD etc [13:11:46] difficult but doable [13:11:55] and then he could land there [13:12:24] what we also have is targeting parameters for planned, but unflown launch days [13:12:40] and we can generate CMC and LGC padloads for that without too much trouble [13:12:59] there are LVDC parameters for Apollo 11 for launches on July 15, 16, 18 and 21 [13:14:17] but these we can not generate on our own yet, we have to find the documentation [13:14:22] that sound way too complicated for me haha [13:14:58] I think of myself as an 'astronaut' [13:15:04] just need to know enough to fly [13:15:40] yeah, and we like to provide the option to do just that, flying [13:15:47] I have no idea what math goes into selecting a launch window and all that [13:15:59] with a bit of work the MCC might be adaptable enough to also support the July 18 and 21 launch days [13:16:18] we have scenarios for those, but you ned to use the RTCC MFD [13:16:39] right now at least [13:17:44] back in a bit [13:41:36] hey [13:43:58] hello [13:56:30] hey Alex [13:57:10] I've tested SPS TVC and RR LGC mode, works good with the updated CDU class [13:57:58] and I've added a flag in the CDU.h file [13:58:00] #define OCDU_CA_ERROR_INCREMENT false [13:58:29] if that is false then it uses the probably wrong logic, but it doesn't overshoot the star with auto optics [13:58:40] if that is true then it works "right", but overshoots [13:58:56] I want to test a P24, but then I can push it, if you want to try it [13:59:08] ah interesting [13:59:10] sure [13:59:44] finally P24 will be working, that's the main reason I was doing this, and I am testing it last lol [14:00:23] and that flag only affects the optics CDU and only when it's driving the auto optics, so no effect on SPS TVC or any other CDU type [14:01:48] right [14:01:50] what does P24 do again> [14:01:57] ?* [14:02:06] you have the optics in manual [14:02:12] it's like P22 basically [14:02:26] but you have the optics in manual and the CMC drives the optics anyway [14:02:34] and you can adjust it with the manual optics controls [14:02:44] I think that makes landmark tracking a lot easier [14:03:04] ah I see [14:03:13] it's meant for the low lunar orbit, the 60x8, as the optics rates you need to do manually are even higher than before [14:03:31] it's pretty much tracking the landmark on its own and you adjust it a bit [14:03:37] I think that's how it works at least [14:05:37] I know some of the checklists used to have issues with the old way of doing the CDU (or lack of CDU) [14:06:02] I guess those are all fixed? [14:07:41] what do you mean specifically? [14:09:32] V40 N20E ZERO CDU [14:09:45] that's the ICDU [14:09:56] the CDU class is not used for the ICDUs yet [14:10:01] that's a whole upcoming project [14:10:09] ah ok [14:10:16] the CDU class was implemented for the RR CDU [14:10:21] then I tried OCDUs but had no luck [14:10:30] fast forward a few months, now I had more luck with the OCDUs [14:10:47] but essentially the CDU class should now be ready for the ICDUs as well [14:12:53] will just need a bunch of changes to the IMU class [14:13:25] but V40 N20E does work even now, the only issue is that the FDAI will twitch once [14:13:40] it has been like that for quite a while [14:13:47] right [14:13:49] before, doing V40 N20 was bad [14:14:07] I think it moved the IMU angles to 0/0/0 or so [14:30:12] ok, testing a P24 and then I'll push the update [14:31:19] will be weird, optics driving in manual mode [14:42:29] well it works [14:42:38] and it does help, but it feels quite different [14:42:47] have to get used to it [14:43:29] there will probably be some changes to the optics reticle and general behavior [14:43:35] I think I have an idea why P23 doesn't work good [14:44:14] in the ND-many numbers document there are some illustrations [14:44:25] and the reticle should actually rotate when the shaft angle is changing [14:44:28] a bit like the AOT [14:46:46] https://www.ibiblio.org/apollo/Documents/HSI-208435-001.pdf [14:46:56] check PDF pages 127 to 130 [14:53:17] oh interesting [15:02:01] pretty mind blowing to be honest, I think there are a few things we need to change based on this [15:11:24] I have pushed the update btw [15:15:21] ok ill give it a test [15:16:13] hmm still says March 20th last commit [15:23:42] oh right [15:23:50] I pushed it but didn't bother checking if it worked [15:24:01] hadn't merged your PR with the July 18 and 21 numbers [15:24:34] done [15:25:07] great [15:25:56] I think Ill launch Apollo 11 today and fly the whole thing [15:26:01] July 21st [15:30:22] nice [15:30:31] have fun with the overshooting optics [15:30:39] but you can try it both ways of course [15:30:43] with the flag in CDU.h [15:34:02] nice [15:34:08] its much smoother [15:34:34] yeah, overshoots a bit but nothing major in my opinion [15:50:20] ok [16:28:34] morning! [16:30:01] hey Mike [16:30:44] what's up? [16:31:00] made the optics release ready [16:31:12] and added an optional flag to switch between the two behaviors [16:32:52] nice [16:33:20] I was looking through GN&C test procedures last night for slew rate tests [16:33:23] SPS TVC and RR CDU work as before [16:33:37] found plenty that give numbers for manual mode [16:34:26] but only found one computer mode slew rate test, for colossus, that involved using an EMP at launch base and the procedure had you check numbers on a DSKY display instead of calculating a rate [16:34:27] yeah, plenty of sources for thos enumbers [16:34:51] I mean, I can try the EMP [16:35:00] I don't think we have the EMP lol [16:35:18] pretty sure it was loaded from some K-START tape or other [16:35:40] oh, ok [16:40:26] "Shaft Slew Rate Test. Start tape reader. In approximately 25 seconds VERB 23 NOUN 26 shall flash. Read and record CRT DSKY Row 1 and 2 displays. The recorded value shall be between 00018.88000 and 00011.32000." [16:41:36] part of the semi-automatic mode test [16:41:59] the first bit of that is "Verify the appropriate K-START tape for CM Semi-Automatic Mode Test is on the K-START tape reader." [16:42:32] hmm [16:42:43] would this have been a new addition to the semi-automatic mode test from Sundial? [16:45:44] semi automatic self tests? [16:47:56] hmmmm maybe this code is in Sundial [16:49:41] let's look at the Sundial code then [16:49:43] oh wait :D [16:52:51] well, easier thing would be to just use it to run the test :D [16:53:14] In the optics rate test, the trunnion is first commanded to -19. 775 degrees to keep it from moving and the shaft is commanded to 180 degrees. The time at which the shaft CDU counter indicates 10 degrees and 160 degrees is obtained. The shaft CDU rate is calculated by dividing the difference in CDU readings by the elapsed time between the two angles. [16:53:41] if we can up with the procedure, sure [16:54:10] we for sure have procedures for running a Sundial semi-automatic mode test [16:54:18] it's just going to take some digging [16:58:29] https://archive.org/stream/apertureCardBox475Part1NARASW_images#page/n840/mode/1up [16:58:48] so the pages there are sideways but I'm pretty sure that applies to Sundial [16:59:55] I can try it later, thanks! [17:02:48] yes I just tried the first bit in standalone virtualagc and Sundial definitely behaves as according to that procedure [17:06:14] rotating it 90° doesn't properly work [17:07:04] and I guess I have to go through the full procedure to get to the optics rate tests [17:09:59] yeah [17:10:02] although [17:10:04] the table at the very end [17:10:30] says that the units for the DSKY display are deg/sec [17:11:24] with 00018.00000 max and 00014.00000 min for the shaft and 00009.00000 max and 00007.00000 min for the trunnion [17:15:39] interesting numbers [17:15:58] I guess it depends what number it puts on the error counter [17:17:26] those numbers would be about 308 out of 384 each [17:17:48] I will see [17:18:13] all tests should be fun to watch, so it's ok to go through many of them :D [17:21:41] :D [17:49:55] indy91, Im really going to test you Apollo 11 July 21st scenario/presettings... 1 hour late launch [17:50:01] ontop of the already late launch :D [17:50:29] 100.5 launch azimuth [18:00:20] fun [18:05:55] another interesting fact about this launch window is re-entry will be in daylight [18:10:08] lots of daylight for this mission then [18:10:13] TLI as you said [18:13:52] yeah [18:16:03] halfway to the auto optics test [18:19:29] nice! [18:20:04] similar tests with the IMU/ICDU right now [18:20:11] CDU rates [18:22:06] then ICDU coarse and fine fail tests [18:22:41] not sure I will get the ISS Warning light as the test suggests [18:23:13] yeah, didn't happen. Probably not simulated right [18:23:43] don't forget to save yourself some scenarios in case you want to go back to specific tests :P [18:23:50] yeah [18:23:57] will do at the next step [18:25:28] it shows channel 30, I guess that's where the CDU errors are [18:25:35] that we don't generate right now [18:27:42] not correctly at least [18:27:51] only power off generate the ICDU failure [18:28:05] yeah I haven't simulated those yet either [18:28:11] those come from the analog Mode module [18:30:22] test complete [18:30:35] I think it calculated an average rate [18:30:48] +00007 +31232 for shaft [18:31:02] I guess this is 7.31232°/s, looked it this was about the average [18:31:13] and 1.82597°/s for trunnion [18:31:38] so too slow I guess [18:31:53] yeah that looks much too slow [18:32:46] factor 2 too slow for shaft, 4 for trunnion [18:33:55] hmm [18:34:39] is that CDU rate though? [18:34:46] trunnion has a factor 4 there [18:35:11] SetReadCounter(SextTrunion * 4.0); [18:35:37] so maybe trunnion is just right? [18:35:42] shaft 2x too slow [18:37:07] ah wait, there is the sheet with the expected values [18:38:12] nah [18:38:21] what you said were the values [18:38:33] so I have to make the shaft 2x fast, trunnion 4x [18:38:53] which is weird, that makes the shaft and trunnion have the same speed [18:39:48] heh, interesting [18:48:27] hmmmmmmmmm [18:48:34] nearly the same result [18:48:42] which can only mean one thing [18:49:26] optics rate is not a simple linear relationship to the error counter value [18:49:57] uh oh [18:54:03] oh [18:54:13] Delco manual does have CMC rate numbers [18:54:22] 3.8°/s for trunnion, 15.1°/s for shaft [18:54:29] but what that is referring to exactly is unclear [18:54:32] average, max [18:54:59] indy91, do you have the proper LVLH angles for CSM sep attitude? I have them written in my notes but want to confirm P 48.59 Y -130.89 R 139.11 [18:56:07] well, that was Apollo 12 [18:56:25] that was 30° yaw, plus or minus, right? [18:57:40] it's also launch day dependent [18:58:23] it's -40° yaw for July 21 [18:58:25] LVDC_XLunarAttitude 3.141589512 2.094395207 -0.6981317008 [18:58:36] right looks like -40 [18:58:53] I'll run that little script I made [18:59:11] ok [18:59:32] should have made it clearer to myself which order is right :D [18:59:40] haha [19:01:58] -120.79 yaw, 41.561 pitch, -131.93° roll [19:02:57] awesome thanks [19:04:43] and that is set to inertial,P1,LVLH in the MPT if I remember [19:06:36] yep, 0 DV maneuver [19:08:17] and I think I said before, the FIDO had some nice checklist for this I bet and I'll create something like that [19:08:38] where values like that are listed [19:11:07] I already have my own rough "RTCC checklist" but it needs some updates with the latest stuff [19:15:40] thewonderidiot, "In the optics rate test, the trunnion is first commanded to -19.775" etc, where did you get that from? [19:16:24] ND-1021043 has a description of all of the Sundial tests towards the end, as does ND-1021042 for Aurora [19:16:36] https://www.ibiblio.org/apollo/Documents/HSI-208435-004.pdf [19:16:38] pdf page 48 [19:18:08] yeah, found it [19:51:28] ok, while I do now some at least some objective numbers for how fast the optics rate should be, I have the feeling that any kind of delay or integrator that makes the rate more steady will make the overshooting problem even worse [19:56:00] :/ [19:56:03] damn [20:05:51] you have the Apollo 12 Delco manual, right? [20:11:11] yep [20:11:19] I have all of them except for 10 [20:12:23] I'd like to have a high quality version of the page with "optics motor drive amplifier" [20:12:44] HW-57 in the Apollo 15 manual [20:13:28] do you care from which book? [20:13:34] nah [20:14:41] lol well let's see here [20:14:51] the quality of that page is not so great in the first one I grabbed, 16 [20:15:30] 11 doesn't seem to have it, at least I didn't find it [20:15:40] 15 and 16 were not good quality enough [20:16:24] let me see how the scans line up with what I am seeing printed [20:18:01] yeah the Apollo 16 one looks pretty accurate to how it's printed in the book [20:18:06] let me look through some more [20:20:23] yeah, looks just as bad in 12 and Skylab 1/2 [20:20:44] https://photos.app.goo.gl/dpksD3hiJ3P9yjLX7 [20:21:05] but if you're interested in the circuit, we have the original schematic and possibly test procedures for it [20:21:50] that's a bit better, thanks! [20:21:59] yeah I know [20:22:10] but that will probably confuse me more than it will help :D [20:23:37] well, considering this page appears to just be a low-resolution image of the actual schematic, maybe not :) [20:23:37] https://archive.org/stream/apertureCardBox462NARASW_images#page/n1425/mode/1up [20:24:37] ah [20:24:48] yeah I mostly wanted to be able to read the text and numbers there [20:25:31] test procedures for that module start here: https://archive.org/stream/apertureCardBox461NARASW_images/apertureCardBox461NARASW#page/n44/mode/1up [20:26:05] in revision order, mixed in with the assembly drawings [20:27:01] all goes way deeper than I ever intent to implement or even test unfortunately [20:27:29] it has a big requirements section talking about the gain in various cases [20:27:35] not sure if that's what you were after [20:28:38] not sure what I am after at this point :D [20:29:15] hahaha [20:31:33] oh btw, the Sundial test uses 80 pulses every 0.5 seconds [20:31:57] oh interesting [20:32:20] and I guess that is supposed to achieve 14-18°/s [20:32:30] maybe the 15.1°/s mentioned in the Delco manual [20:33:38] if I make the optics drive faster (linear) then the 2^2 pulses just happen faster, so it has no influence on the real speed as the counter never saturates [20:34:06] so I'm sure I can abandon the linear function [20:35:03] hmmm [20:35:40] what is the max rate the read counter can count? [20:35:52] is it ever possible that the shaft moves faster than the read counter? [20:36:21] or would that just make things even worse [20:36:25] yeah [20:36:33] the shaft angle knowledge in the CMC would lag behind [20:36:39] right [20:36:42] and the CMC would command even larger increments [20:36:59] very not good [20:38:31] I'm surprised I have found no document that has a simulation of the behavior [20:38:36] nothing from MSC or MIT [20:47:14] that is weird [21:33:10] night! [10:41:51] .tell thewonderidiot The semi automatic mode test goes up to revision M, I was using revision A. In revision M the shaft and trunnion rates I got were exactly in the middle of the expected range of values. [14:53:15] hey [14:54:54] hey Alex [14:55:09] at least a bit of good news, I was using an outdated revision of the optics rate test procedure [14:55:21] maybe a hardware, probably a different Sundial version though [14:55:33] in Revision M the drive rates I had implemented were spot on [14:55:46] so at least that part is right [14:56:22] hardware change* [14:57:14] nice [15:02:38] about to launch Apollo 11 [15:03:54] great [15:04:12] I still don't believe that the optics is behaving right with the overshooting of the target though :D [15:05:15] right [15:05:39] hopefully something we'll figure out soon [15:10:35] I still have 1 or 2 leads in the CDU [16:20:31] one thing I need to test is if saving and loading of the CDUs works for every angle [16:20:58] the read counter is a bit of a strange data format, might not be compatible with the normal saving/loading functions for integers [16:44:28] morning! [16:44:54] oh really? damn, sorry [16:45:26] I thought I looked at one of the later ones and the test procedure was going on about using tapes instead of the DSKY, which made me think it had been changed to use Colossus + EMPs instead [16:45:42] but maybe I looked at the wrong thing [17:14:16] it's funny [17:14:35] the order of the revisions is A, B... M and after M it's the original version [17:14:53] so if you looked at the first and last pages you will have the seen the same numbers [17:15:10] yeah, the original revisions are "-" and I think a dash is sorted after all of the letters alphabetically with how they did it [17:15:38] great system, lol [17:15:49] but at least it's alphabetical [17:15:53] heh yeah [17:16:28] so is M definitely still Sundial? [17:16:52] uhh [17:16:54] not sure [17:17:03] I just looked at the highest revision [17:18:13] I like the results better [17:18:42] revision M has 5.49° to 9.15° as the allowed shaft rate [17:18:59] and I had 7.31232°/s when I did the test [17:19:12] 1.38°/s to 2.28°/s trunnion rate [17:19:16] right but if that's with Colossus+EMP it could be totally different software to get those numbers, haha [17:19:22] I had 1.82587°/s [17:19:32] that is very nicely right in the middle though [17:19:36] yeah [17:19:52] so the earlier revisions must either have a different hardware or a different Sundial or so [17:20:16] yeah, I could definitely see the earlier one being Sundial A even [17:20:18] we've got E [17:21:30] oh wow, revision M is from 1970 [17:22:04] and starts with putting the CMC into uplink and sending up a bunch of stuff [17:22:09] I'm not so sure that's still Sundial [17:22:35] right [17:22:38] but maybe it is [17:22:58] man it would be convenient if all of these pages weren't sideways, or the internet archive's rotate feature still worked [17:23:03] and revision L has the higher numbers... [17:23:17] uhh [17:23:18] no [17:23:23] looked at the ICDU [17:23:59] but that is also EMP [17:24:33] hmm got a CTD while calculating SIVB sep angles [17:25:33] revision H seems to be sundial [17:25:38] and has the numbers I like [17:25:43] ah, cool :) [17:25:44] AlexB_88, debuggable? [17:26:05] let me try and reproduce [17:26:24] then ill run it through VS debugger [17:26:37] revision K is the first with an uplink thing [17:27:38] so basically it happened when I pushed the button on the DMT to view the 0 DV SIVB maneuver angles [17:28:00] hmm, ok [17:28:38] revision C is the first one with the nice optics rate [17:29:49] DMT CTD is more easily fixable than if it had happened during the transfer to the MPT.. [17:30:41] for the 0 DV maneuver I had the ATT set to "inertial" or should it still be "PGNS External DV"? [17:32:53] inertial is better [17:33:07] if anything a 0 DV PGNS maneuver might cause issues, haha [17:33:39] hmm did the same thing again but no CTD [17:33:58] fun stuff eh? :D [17:34:33] it would have been nice to happen again so I can debug [17:34:34] probably some unsafe code that can't deal with the 0 [17:34:57] I do have a weird dipslay on the DMT now though, whowing the 0DV maneuver [17:34:57] when is rev C from? [17:35:19] 11-15-66 [17:35:37] oh nice, that's super early [17:35:48] next question, what was the release history of Sundial... [17:36:35] https://www.dropbox.com/s/yanajifnsbzlys1/Screenshot%202020-03-23%2011.35.34.png?dl=0 [17:37:00] ouch [17:37:10] looks like something doesn't get zeroed by default [17:37:54] anyways my angles are there 359,88,320 [17:37:58] that does look good [17:39:23] looks like the Sundial drawing was updated for C/D on 6/28/66 [17:39:42] but what about E... [17:43:12] AlexB_88, I think it's the longitude of the ascending node [17:43:17] directly below the HP [17:43:24] that calculation should fail and thus display 0 [17:43:28] but it doesn't [17:44:06] and the CTD was possibly caused by it trying to display that and it going beyond the display [17:44:18] that's the kind of CTD that doesn't happen every time [17:44:21] unreliable [17:44:24] right [17:49:11] yeah, there should be a check on the eccentricity of the orbit [17:49:24] and if it's above 0.85 then it won't even try to calculate that angle [17:49:30] which is definitely the case for you [17:53:36] ok time for TLI+90 pad, TLI+4 P37 Pad [18:02:26] Al Worden passed away, he was 88. [18:02:27] http://aero-news.net/index.cfm?do=main.textpost&id=0d171654-c2e2-4568-bca4-c09d87fe5a3a [18:11:49] RIP [18:12:58] indy91, hmm doing the TLI+90, RTE earth-centered, I have a good solution, but M74 transfer to MPT does not seem to actually put it one the MPT [18:13:28] looking at the online monitor, it says M74,CSM,,RTEP; MED M74 OK [18:13:40] but doesnt actually go on the MPT [18:20:32] hey Suzuran [18:22:12] Suzuran, don't think we switched over to using my repo of NASSP only. I had merged an update that needed some more testing. So I was using indy91/NASSP for the latest NASSP work. Should be getting merged back into dseagrav/Orbiter2016 in the next few days though. [18:22:52] It's fine. [18:23:04] I intended to tell you guys to clone the repo anyway [18:23:15] I may have been exposed to CV [18:23:29] They can't test me unless I start showing symptoms [18:24:07] boo :( [18:24:09] you better stay healthy [18:24:36] I don't think there will be any issues, I've been AWOL for ages and nothing has broken, but just in case... [18:24:57] I intend to; I'm bunkered down at home now, but that's where the problem was [18:25:18] My brother lives in the same trailer park as two known cases and they ate at the restaurant he works at [18:25:26] and he was here 2 days before that info was made public [18:26:19] tx office has a record open so we can jump right on it if something comes up, but the stats for major organ transplant recipients vs. CV are so far extremely bad [18:26:47] I've been isolating a bit myself. On Wednesday I'll start taking care of my grandmother for a while, she is coming from rehab after an operation. [18:27:09] There's only been a handful of cases that have "concluded" in the USA so far, but of them a little less than 20% survival rate was achieved. Graft survival so far is 0%. [18:27:54] (meaning in no case so far were they able to save the transplanted organ) [18:28:27] but as of Friday there were only 12 cases total so all of that is just barely a starting point [18:28:32] I'll burn that bridge when I get there [18:28:45] step 1, don't be infected [18:29:07] That's the shit part, if you fail step 1, you don't know for ~2 weeks [18:29:46] They found a guy in Cali yesterday who tested positive 2 months after exposure and was completely asymptomatic [18:29:59] This thing is all over the place [18:30:32] it sure is [18:30:57] we almost had it contained here in Germany, but then people returned home from skiing in the alps and celebrated Carnival... [18:31:15] At least you're doing better than Italy. [18:31:32] USA seems to be on the way to number 1 [18:31:37] as it likes to do [18:31:58] Maybe as far as numbers but we can distribute them [18:32:19] If conditions in the US get like they are in Italy, I don't even want to think about the counts... [18:32:35] Some of their guys are still posting a few places and it's seriously bad stuff, like "cannot unread" bad. [18:32:44] countries like India could have it even worse [18:33:03] poulation density, worse health care [18:33:09] hopefully not [18:33:14] Yeah, but things are already bad there so they don't have a frame of reference for it [18:33:45] Italy is so bad they are no longer even assessing patients over 65. They have no resources. All they can do is put them somewhere until they arrest and then call someone to dispose of the body. [18:34:02] Their healthcare capacity is completely spent. [18:34:21] They don't even have oxygen anymore [18:34:29] Everything has been used up, including staff [18:34:40] I heard China is trying to help [18:34:55] The posts read like one of those "end of days" ebooks all the prepper types go nuts for [18:36:05] well it's not going to be the end of days, mortality isn't that bad [18:36:18] just a lot of cases at once [18:37:02] That's the issue, they have so many cases and so little resources that people are dying of just regular everyday stuff [18:37:23] yeah that's the danger [18:38:00] the virus in the movie Contagion "only" had a 25-30% mortality rate [18:38:07] and that was some real end of days stuff [18:38:24] otherwise pretty similar to what happens right now [18:40:10] AlexB_88, and you had the right config for TLI+90? [18:40:29] CSM alone I guess [18:40:42] yeah [18:40:43] maybe it rejected it for something config related [18:40:55] ah [18:41:14] maybe I need to add the config change in the MPT? [18:41:18] after TLI [18:41:32] well you probably need to make it CSM+LM [18:42:05] you specify a config for the RTE, that should take of it, if that is already working [18:42:12] take care* [18:42:20] it might not [18:42:47] I set it to CSU CSM SPS undocked [18:43:40] so you mean that it should not matter what config the MPT is using? [18:43:41] probably rejected due to config, I'll also add the messages for PMMXFR, the MPT maneuver transfer module [18:43:52] ok [18:44:09] RTE is a treated like a direct input maneuver [18:44:39] so if I add a config change maneuver (CSM only), then I guess it should work [18:44:42] so what it could be is that the RTE takes care of the config change, if necessary [18:44:55] but that is not implemented yet probably [18:45:03] and then the transfer got rejected [18:45:17] I don't think that you should have to add an undocking maneuver [18:45:27] can't remember that from the Apollo 11 FIDO audio [18:45:39] right [18:45:44] the RTE itself would be the undocking maneuver [18:45:55] and the RTE processor needs to set that up during the transfer to the MPT [18:47:48] but the workaround for now could be an undocking maneuver of course [18:48:05] right [18:49:39] whats the best way to do the undocking maneuver? In direct input? [18:50:05] I guess a 0 DV maneuver again [18:50:47] that would work [18:52:31] are you still pre TLI? [18:53:06] yes [18:53:13] ok [18:53:33] it worked [18:57:24] luckily this is quite well documented in the IBM documents [18:57:30] so I should be able to get it right [19:01:11] the maneuver transfer function is a bit of a mess. Which means I did something right, the real function is much worse. [19:01:18] whats "S or C" again in M58? [19:01:54] C is Computer, S is System Parameter [19:01:57] Computed* [19:02:19] if you want to specify specific trim gimbal angles (system parameter) [19:02:26] or let it calculate it (computed) [19:02:33] ah so C in most cases [19:02:34] C is default I think and usually what you want [19:05:39] the updated RTCC MFD manual will definitely get the MED list from the RTCC document [19:06:10] that document is 69-FS-2 [19:07:01] thewonderidiot will be familiar with the XX-FS-X documents [19:07:17] uh, am I? [19:07:20] what are those? [19:07:22] all the "Programmed Guidance Equations for Luminary/Colossus" are also in that category [19:07:29] oh jeez okay [19:07:31] yeah lol [19:07:33] 69-FS-4, Luminary 1B for example [19:07:50] they don't get many releases per year, haha [19:08:04] not the 200-300 of the Mission Planning and Analysis Divsion [19:08:07] so that was more than just Norton? :P [19:08:36] must be :D [19:08:58] James C. Stokes, Jr., Chief, Flight Software Branch [19:09:04] so at least one more person worked there :P [19:11:32] hehehe [19:12:05] so I guess there is no official way to get RTGO,VIO,GET 0.05G times yet for TLC aborts [19:12:24] at least with using multiple maneuvers on the MPT [19:13:39] I have TLI,undocking,TLI+90 on the MPT, but I dont think the Entry pad likes that [19:14:21] however the RTE page itself gives the LAT/LONG,GET RRT [19:14:35] and I found a useable RTGO on the splashdown page [19:15:58] brb [19:23:40] keyboard died [19:24:21] Government just banned all events until the 1st of June. Groups of more than 3 persons will be fined (€400,-) if they are within 1.5 metres of each other. Stores need to limit the amount of people that can enter. [19:24:49] You can put me into an artificial coma until this is all over. [19:24:58] haha [19:26:35] Can't see either of my grandparents for their birthday, can't host my own birthday nor my parents. Can't go to college. Amateur Radio exam I had scheduled is cancelled, I was supposed to get college credits for those. [19:27:08] oof [19:27:19] All scouts activities have been cancelled, can't go sailing in may, can't camp with the cubs, yearly events cancelled. [19:27:52] at least NASSP can't be cancelled [19:27:59] I guess [19:28:32] keyboard lives [19:28:37] USB died [19:28:47] My brother has high school exams this year. Those will most likely be cancelled. Who knows when he'll take them, considering they're an entrace requirement for higer education. [19:46:20] indy91, bummer [19:46:33] I guess it will join your old monitor :D [19:49:46] USB device in the PC might be dead, but I have more than one. Definitely won't remove it from the PC, way too much effort :D [19:51:31] haha [19:51:32] Thymo, same here, they haven't been cancelled yet, but it would be in a month. And my brother is in university, probably will need a semester longer than planned due to exams being cancelled [19:51:35] about to do TLI [19:52:12] AlexB_88, so Entry PAD isn't MPT compatible yet [19:52:16] I got the TLI+90 pad all filled out mostly without looking at the pad section [19:52:21] right [19:52:32] only value I couldnt really get was 0.05G VI [19:53:01] I tried the checkout monitor at 0.05G time, but it gave me "Error 4" [19:53:43] then the space digitals, but it would not display any data on column 3 [19:54:07] those were all pre-TLI, with TLI+undocking maneuver+Abort on the MPT [19:55:27] space digitals column 3 should work with the right inputs, if it's not broken in some way, which it probably is [19:55:43] and there is code to make the Entry PAD MPT compatible, but there must be something wrong with it [20:00:16] oh wow [20:00:36] I was trying to find what would be displayed on the Return-to-Earth Digitals display [20:00:39] and I found this [20:00:42] hi. just dropping in to ask some questions on the command module IRU. i had an incident a few minutes ago where i switched to the cm only to find it out of rcs propellants and the iru in gimbal lock having lost its attitude refference. after some save editing i've managed to refill the rcs but i hav no idea to realign the iru [20:00:46] https://twitter.com/poppy_northcutt/status/1210053922137821186 [20:00:52] hey x170doom! [20:01:12] you mean the IMU? [20:01:18] yes [20:01:26] P51 then P52 [20:01:59] did that, seems to be way off from the gdc which was still in good alignment [20:02:30] well, the new IMU alignment might not have the same reference anymore as before [20:02:51] Did you get any uplinks since the last alingment. Might have gotten a new REFSMMAT. [20:03:13] no. other than a reffsmat update that i created using the rtccmfd [20:03:14] as long as the AGC can still point your sextant at the stars your alignment is "good", it might just not be the alignment you had before [20:04:25] which mission are you flying? [20:04:48] apollo 11. i just managed landing with the lm [20:04:54] nice! [20:05:18] so that alignment would be a landing site alignment then [20:05:19] Damn. I need to do that someday. [20:05:35] AlexB_88, did you see the link I posted? That's a hardcopy of a MCC display, for an Apollo 8 TEI [20:06:21] is there any way to determine what refference the GDC is alligned to [20:07:10] not really. The GDC has its own kind of gimbal lock though [20:07:25] so it might have lost some accuracy (or a lot) when you went into IMU gimbal lock [20:07:42] I'd uplink a new landing site REFSMMAT (desired REFSMMAT) and align your IMU to that [20:08:02] might even be that it then has nearly the same alignment as the GDC [20:08:15] Do we actually simulate GDC gimbal lock? How many gimbals does it have, four? [20:08:26] how would i do that via rtccmfd, i basically managed the last one by accident [20:08:28] no gimbals at all [20:08:36] Oh right. Duhg [20:08:40] just analog, integrated rates [20:08:41] s/hg/h [20:08:45] I knew that [20:09:02] I worked on that a while ago, there is a secant amplifier that probably would get saturated in some way [20:09:11] so I implemented somewhat of a gimbal lock for it [20:09:24] x170doom, alternatively, P52 option 4 [20:09:39] that needs a time input, time of landing or lunar ascent, depends on the mission phase [20:09:46] also gives you a LS REFSMMAT [20:10:18] I also spun the CSM to deathly rates and the IMU was fine, something to fix if we get to those edge cases [20:10:21] but with the RTCC MFD you go to Utilities, REFSMMAT [20:10:22] indy91, interesting [20:10:28] cycle through the options until it says Landing Site [20:10:33] click calculate (CLC) [20:10:59] and then a fairly recent change is that all the uplinks are in a separate category in the MFD [20:11:04] And IMU tumbling is something I started working on in the background a while ago: https://www.youtube.com/watch?v=I9eE-tw1e-A [20:11:04] if you are using the latest verions [20:11:10] versions* [20:11:29] ah, i don't think i am. let me check [20:11:32] Thymo, looks like a rolling reentry [20:11:49] x170doom, well if you are not then the uplink is on the REFSMMAT page itself [20:11:55] even easier in some way [20:12:08] I wanna do one of those some time. Withough the CMC [20:13:41] I think the roll resistance of the CM needs some tweaking [20:13:58] rolling reentry is with 20°/s, but it slows down too quickly [20:14:10] once you hit the atmosphere [20:14:24] okay so i went rtccmfd>uplinks>refsmat. i hav the options for csm desired or just csm refsmatt [20:14:39] sorry cmc not csm [20:15:12] ah ok, so a more recent version [20:15:23] where I had already seperated the all the uplinks [20:15:35] you want CMC Desired REFSMMAT [20:15:45] the difference is, the desired REFSMMAT gets used in the next P52 [20:16:07] while the other option will replace your current REFSMMAT. That is very bad in most cases [20:16:17] only really done during LM activation for the LGC [20:16:40] so on that page you probably need to hit the CLC button again and then uplink the REFSMMAT [20:16:49] ah i see. ill try it now, then i assume p52 [20:16:49] when that was successful run a P52 option 1 [20:16:53] yep [20:19:28] AlexB_88, in the IBM RTCC document there is a list of all the values calculated in that MCC display [20:20:19] but I don't think the 0.05G time is on there, hmm... [20:20:39] maybe they just added 28 seconds to the EI time [20:20:44] isn't it always 28 seconds... [20:20:50] I was thinking the checkout monitor could show it [20:20:58] I was really looking for the VI [20:21:08] oh for the EMS [20:21:23] yeah [20:21:34] VIO [20:21:40] on the P30 pad [20:21:49] that was the only value I couldnt get [20:21:55] for the TLI+90 [20:21:58] need to listen more to the RETRO loop I think if it's not on here [20:22:12] or maybe it's on the other display, Abort Scan Table [20:23:00] nope [20:24:09] but I think there are some more displays, which might show the output from a reentry simulation [20:25:07] yeah, the RTCC document says to check two displays [20:25:11] that RTE Digitals one [20:25:31] and "DEORBIT X V/LAMB PARAMETR" whatever that is [20:27:28] the "RTCC Requirements: Reentry Phase" definitely simulates the EMS [20:32:03] did Apollo 11 use an average monthly launch window time for the PTC REFSMMAT? We have one for Apollo 12+ [20:32:52] it didn't [20:33:12] I have vaguely heard it mentioned in the MOCR audio, but it was a MED REFSMMAT [20:33:17] so calculated before the mission [20:33:30] the MCC has it hardcoded [20:33:35] ah [20:34:06] well, it probably wont be valid for July 21st launch [20:34:08] when I properly implement the several REFSMMAT types you can have at the same time we can maybe make that the default MED REFSMMAT [20:35:59] I think for this mission Ill use the TEI time [20:38:31] that seems to have done the trick, thanks again. now i just have to work out the lm surface opperations [20:48:41] AlexB_88, I added some more error displays for the transfer of maneuvers to the MPT. And I'll research if a RTE maneuver is automatically made an undocking maneuver if the config is e.g. CSM [20:49:15] error messages on the online monitor I mean [20:49:28] and it won't say it was ok if it didn't do the transfer [20:50:54] ok sounds good [20:55:47] damn, CTD at hatch openning [20:59:29] hello NaN my old friend [21:00:42] no NaN's in my save during LM pressurization [21:01:37] hmm, what else could i be [21:01:39] it [21:01:46] any clue during the CTD? Which module failed? [21:03:51] ughh, did the exact same thing the 2nd time, no CTD [21:04:15] it happened right when I clicked to open the fwd hatch the 1st time [21:05:31] classic [21:09:08] and my latest post-pressurization scenario has no NaN's either [21:09:38] I thats a good thing I guess [21:10:28] will be hard to debug it though [21:10:49] my track record in this mission so far, finding super-rare issues that happen 1/100 times haha [21:18:15] pretty much :D [21:34:34] night! [15:14:49] hey [15:23:16] hey Alex [15:23:30] writing on the RTCC MFD manual [15:23:58] I'll be gone for a bunch of days, probably a good time to keep on working on that [15:29:05] nice [15:29:57] any idea yet what was causing yor hatch opening CTD? [15:30:27] wasn't able to reproduce it unfortunately [15:30:39] I really have no idea what might have caused it [15:32:48] don't think there was a recent change to anything related [15:33:02] sometimes things are buggy until you do a full rebuild [15:33:22] right [15:33:37] I did a clean rebuild just before the mission [15:37:03] https://i.imgur.com/w02dptk.png [15:37:09] example from the manual [15:37:17] every MED that is implemented will get such a page [15:37:26] it's closely derived from the IBM documents [15:40:01] very nice [15:43:52] got a question for you [15:45:34] sure [15:46:00] say they did MCC-1 but skip MCC-2, would they still calculate MCC-2 with the TLMCC, just for the sake of updating SFP 2? [15:46:26] since MCC-3/4 are option only I believe [15:46:32] option 1 only* [15:47:04] I'm sure they would calculate MCC-2 the normal way, but not update the SFP [15:47:39] they would use nodal targets for MCC-3 and 4 of the actually executed MCC-1 or 2 [15:47:55] ah ok [15:48:10] that makes sense [15:48:14] they could even calculate MCC-2 with option 1 [15:48:30] they probably would do that provided MCC-1 was fairly nominal [15:48:51] right [15:49:06] you have multiple columns to play with, so, why not both [15:54:58] if you wondered what this means in the U20 MED [15:54:59] https://en.wikipedia.org/wiki/EBCDIC [15:55:32] basically means: a character string. I just copied it from the real MED format, might stil change that, not really relevant for the RTCC MFD [16:43:27] morning! [16:46:19] hey [16:46:37] what's up? [16:47:01] writing RTCC MFD manual [16:49:48] oh nice [16:57:42] I stitched together the first sheet of 2015566 last night: https://photos.app.goo.gl/gW8wruMppmFBXLHC8 [16:57:52] the 2-axis mechanization for the IMU and RR CDU stuff [16:58:03] it was very large and took a while lol [17:00:52] ah, very nice [17:00:55] format 10:1 [17:02:13] just the right amount of details for my purposes [17:02:38] although I am pretty much done with the OCDUs now. I won't figure out why it behaves a bit strange. [17:02:59] yeah, we'd need to model the motor drive amplifier and its feedback I think to understand [17:03:05] I'm pretty sure the CDU itself is correct [17:04:01] I'm not fully convinced of that but I wouldn't know what is wrong [17:10:47] I guess at this point it would have to be something in our Virtual AGC code or so [17:11:05] not too different to the standalone Virtual AGC [17:11:28] ours doesn't send out pulses when the AGC command counters is 77777 [17:11:35] standalone only doesn't do it at 0 [17:15:25] I mean, you were seeing the same behavior in NASSP that I was seeing on my FPGA right? [17:16:26] not really [17:16:49] on my side the Virtual AGC kept pushing the angle difference to the CDU error counter [17:17:00] the total [17:17:05] right [17:17:09] and the error counter wasn't 0 yet [17:17:14] which is what makes it overshoot [17:17:19] yes [17:17:28] what you were seeing basically only happens if the AGC is just sending pulses once [17:18:04] oh, you mean when I looped back? [17:18:13] that was because I made it extremely slow [17:18:57] since 1 AGC count is less than 1 error count, but I just counted the error counts directly as AGC counts [17:19:56] ehhh not even that, I just did something not realistic at all with the loopback [17:20:07] it's not really comparable either way, you would have to connect the AGC to get the same software behavior [17:20:11] but from the AGC point of view it was doing the same thing [17:20:25] it was commanding the absolute angle once every 0.48 seconds [17:20:46] yes [17:21:07] as an increment to what was already on the error counter [17:21:24] ....right [17:21:38] so even if I had the optics horribly wrong, the error counter was near 384 when it was at the target [17:21:42] what I'm getting at is, why are you suspecting the AGC? it at least appears to be behaving as expected [17:22:27] because it's so obvious that the optics overshoot if the number that is already on the error counter is not taken into account [17:22:39] and that's what the AGC seems to do [17:22:44] right [17:22:45] software or emulator [17:22:59] because that's how the CMC software is written [17:23:24] I think so yeah, going through the code right now [17:23:44] any chance the AGC command counters (053 and 054) aren't actually nulled every time? [17:24:22] nah, they count out at 3200 pulses per second [17:25:49] in contrast the RR CDU [17:25:58] doesn't use the CA mode with the 2^2 pulses [17:26:09] software keeps track of error counter content [17:26:14] just as the CMC does in TVC mode [17:26:25] drive rate is proportional to error counter [17:26:27] works perfectly [17:26:47] I guess the only thing that compares would be ICDU coarse align [17:26:57] might have to use the CDU class for that soon [17:27:36] and I am not doing the 2^2 pulses wrong [17:27:53] https://archive.org/stream/e24562dimages#page/n205/mode/2up [17:28:09] I implemented a flag to switch between increments and total content for the error counter coming from the AGC [17:28:27] it perfectly finds the star, drive rate goes to 0 exactly on the star [17:32:17] "make sure that commanded number of pulses is not greater than maximum" [17:32:22] 1650 [17:32:26] pulses [17:34:37] what is that for [17:35:06] uhhh [17:35:15] oh [17:35:16] hhaha [17:35:19] zooooom in [17:35:23] that's 165D [17:35:24] D [17:35:27] oh yes [17:35:28] okay [17:35:29] lol [17:35:31] and that's the usual number [17:35:34] yep [17:37:34] not keeping track of anything [17:38:08] nope, it definitely isn't [17:38:18] and not reading the value of the input counter either [17:38:27] other than to do the absolute angle calc [17:38:47] and some sign magic [17:39:06] to not drive the shaft into its stops [17:39:45] but that's also what ND-1021043 said, the 2^2 pulses are supposed to allow the software to be this simple [17:42:16] hmm [17:42:38] changing the factor for the optics speed doesn't actually change the average optics speed [17:42:59] because it slows down with the feedback from read to error counter [17:43:14] so I basically could use any speed [17:43:28] any if it goes really really fast it would behave like before [17:43:31] moving in steps [17:44:27] how fast would it move if you made it so that the error counter would just get to 0 every 480ms? [17:45:39] I can calculate that :D [17:46:53] not that that matters too much, previously it moved instantly [17:46:58] by the amount the AGC wanted [18:25:04] indy91, so the recent CDU changes, does that affect SPS TVC as well? [18:25:18] yes and no [18:25:26] it uses the new CDU implementation [18:25:37] the behavior should be exactly as before [18:25:54] we were able to get rid of a bunch of messy code though [18:26:25] for the TVC we had to store error counter enabled and two error counter values separately from the optics [18:26:45] I had that in the thrust vector servo lately [18:26:55] move it from somewhere else, SPS code maybe [18:26:58] but now it's all gone [18:27:09] well MCC-1 complete, so 1st test of it went well [18:27:37] yeah I had tested a LOI with it [18:28:04] TVC mode doesn't use the features of the CDU that is causing me the headaches [18:28:35] it's only relevant in ICDU and OCDU coarse align mode [18:29:03] right [18:29:38] I guess if the CMC software was doing bad things like commanding a large gimbal angle change then previously that could be very large angles [18:29:46] now it's limited to the max of the error counters [18:30:11] that's still something like 8°, nothing you would ever see in a real situation [18:30:57] 9.1104° [18:31:15] that's the theoretical maximum the TVC could be deflected from a CMC command [18:33:30] I wanted to make a note about my MCC-1 [18:33:38] pre-MCC-1, LOI-1 DV was 2812 fps (MCC-1+LOI-1 on the MPT) [18:34:01] also 2812 LOI DV indicated on the midcourse tradeoff column 1 [18:34:21] but after MCC-1, I re-did the LOI calculation by itself and LOI DV is ~15 fps higher [18:34:50] so I then calculated MCC-4, then LOI-1 after it, and DV was back to 2812 for LOI-1 [18:35:40] so I guess this is just because doing such an early MCC increases the chances of needing a later MCC [18:36:34] the MCC-4 will have fixed your node from actual to what was planned [18:36:53] how large is the MCC_4? [18:36:57] 1 fps [18:37:18] what's the theta of the coplanar solutions? [18:37:25] maybe you have a very sensitive node [18:37:44] actually, that is something the Min Theta solutions might be useful for [18:38:18] theta of coplanar is 1.61 [18:38:20] or the two numbers on the left side in the middle which are currently always 0 [18:38:23] thats with MCC-3 [18:38:25] so fairly small [18:38:25] MCC-4* [18:39:01] so what I would assume is that a small change of the approach azimuth changes the LOI TIG and DV by quite a bit [18:39:11] well seconds and a few ft/s [18:39:21] even if you change it by less than 1° [18:40:09] in the Apollo 14 of the LOI targeting it doesn't actually calculate LOI solutions using approach azimuths that are slightly different from the input [18:40:36] but you can give it a min and max azimuth [18:40:52] hmm, so your saying to tweaking the approach azimuth to try and avoid the need for another MCC [18:40:59] and what that is calculating, I think, is the true anomaly at LOI, which would be those two numbers in the middle, on the left of the LOI display [18:41:22] that tells you how much you could make the LOI closer to pericynthion by a certain amount of approach azimuth change [18:41:40] yeah [18:41:54] maybe try changing that by 0.1 or 0.5° and look what happens [18:42:05] I need to fix the calculation for those two numbers there [18:42:16] I couldn't get that to work yet [18:42:22] but I think this is exactly what they are for [18:42:55] https://i.imgur.com/THJBg90.png [18:43:06] AZ_MN F_ND [18:43:14] true anomaly of the node with azimuth min [18:43:31] one (or both?) of those numbers would then be closer to 0 [18:43:42] yes it works [18:43:52] and you could get a feeling how much a change of the azimuth is gaining you [18:44:24] there are a lot of calculations for those two numbers in the LOI targeting [18:44:40] it does a whole backwards integration from the landing site with a biased azimuth [18:45:15] definitely will take a look now that we have found a case where they would be useful [18:47:35] maybe thats why in some of our LOI targetting tests, LOI DVZ is a bit high? Because they would have tweaked the approach azimuth... [18:49:08] I changed it by 0.4 and it cut the DVZ from over 400 down to 200 fps [18:50:09] well, I guess Apollo 13+ have more of a need to stay on the desired approach azimuth [18:51:48] especially missions using the terrain model [18:53:11] but also don't forget that a 200 ft/s change in DVZ is basically nothing in total DV [18:55:31] it does change a lot with a sensitive node though, when the LOI plane change is small [18:55:41] well it reverted the extra 15 fps [18:57:51] ah [18:58:13] ok, final decision for the optics [18:58:20] I make it 5x or 10x faster than now [18:58:33] 10x makes it not overshoot at all [18:58:48] because it has done all the angle change the AGC wanted 0.48 seconds before [18:58:54] might not be the same with Artemis though [18:59:10] and I have to see if it freaks out in time acceleration with that [19:00:26] and in P24 [19:26:49] indy91, about min theta modes, I had to go back in the logs to read the description you gave me a few weeks ago [19:27:04] I think I have a better grasp of it now [19:27:29] great. Although it probably doesn't apply to your situation with the high DVZ [19:27:51] not really sure what a useful case for it is [19:28:00] " which would be those two numbers in the middle, on the left of the LOI display" is that AZMIN FND/AZMX FND? [19:28:08] yeah [19:28:18] are those what I can play with? [19:28:27] yes, if the calculation was working [19:29:12] there is lengthly calculations in the LOI targeting for it, but there must be some issue in the equations because the result is nonsense [19:29:17] so it's not displaying anything for it yet [19:29:29] I'll try to fix it some time [19:32:09] is that related to AMN/AMX on the LOI Computation [19:32:40] they seem to always default to 1 degree + and - from the desired azimuth [19:34:31] that's what I did to those parameters yeah [19:34:44] the Apollo 11 FIDO usually used +/- 1° from nominal [19:34:56] and yes, those numbers would be calculated with the min and max azimuth on the calculation page [19:35:55] and that's the plane solutions [19:36:18] right [19:36:31] yeah, had to check in the equations [19:37:00] so for the min theta, I find I can used the limit DV parameters to get a lower LOI DV [19:37:07] true anomaly of the node using those min and max azimuths [19:37:08] well obviously [19:37:17] right [19:37:23] but I guess thats what sacrifices a bit of theta [19:37:56] yeah, it tries to find the TIG that is the closest to the desired orbital plane with the allowed DV [19:38:04] so it minimizes the theta, hence the name [19:41:40] if you allow a huge DV it doesn't have to minimize anything and the solution should be the same as the plane solution [19:41:59] if the allowed dV is smaller even than the coplanar DV then it also can't minimize anything and the solution is the same as coplanar [19:42:00] ah, so what I think I can do, is min theta and enter DVMAX as the value in the SCOT [19:42:22] and that gives me an LOI of 2810 fps, with a theta pf 0.08 [19:42:29] hmm [19:42:42] careful with that, that doesn't just change the approach azimuth [19:42:51] it will also give you a crossrange [19:43:05] probably an acceptable one, but still [19:43:39] not really predictable how much it changes the approach azimuth and how much the cross range, but it will be both [19:43:39] ah, so it doesnt take into account the orbits from LOI to landing? [19:44:02] well it still tries to use the desired orbital plane [19:44:07] which was backwards integrated [19:44:23] but that plane is just defined by a normal vector to that plane [19:44:56] so the better way, is to still use plane solution, and just manually tweak the LLS azimuth I guess [19:44:58] and the min theta calculation tries to achieve an orbital plane with the minimum angle between the desired and the actual plane [19:45:30] tweaking the azimuth gives you 0NM cross range (in the optimal case) and an approach azimuth that is off [19:45:40] min theta solution will give you both [19:45:53] cross range and approach azimuth that is not the desired anymore [19:46:12] hmm not good [19:46:30] that's why I am still not really sure what that mode is really useful for [19:47:28] AZMN FND and AZMX FND is what you would be looking at to see if changing the approach azimuth a little bit will gain you something [19:48:33] so I guess min theta ties to "lets meet halfway" type of thing between the desired (desired approach azimuth and 0 crossrange) [19:48:56] halfway between coplanar and plane I would say [19:49:06] right [19:50:02] I found changing my approach azimuth by 0.4 and plane solution 5 gives a quite good LOI [19:50:08] if AZMN/AZMX FND is e.g. 359°/1° and the FND/H of the plane solution is something like 10° or 350° then that's a strong hint that you will get a smaller DV by changing the approach azimuth [19:50:09] plane 7* [19:50:28] yeah, that doesn't seem so bad [19:52:18] have to look at the mission rules of some of the missions that rely on a terrain model [19:52:40] that should say how much you are allowed to change the approach azimuth [19:52:52] ah yeah [19:53:19] haha [19:53:44] if the azimuth is off by +/- 10° then you have to do a plane change maneuver [19:53:53] I hope that is not the only mission rule for that [19:54:38] quite high [19:54:59] I think it's misleading [19:55:04] I looked at Apollo 15 [19:55:10] it had a scheduled DOI trim maneuver [19:55:30] and that is supposed to return approach azimuth and crossrange to nominal [19:55:41] have to look at another mission [19:57:17] Apollo 14 says +/- 2° [19:57:28] 16 and 17 also have 10°, but they all have potential DOI trims [19:57:38] so 2° is probably the more reasonable number [19:57:45] 0.4° < 2° [19:57:54] so you violate no mission rule :D [19:58:43] hey, if I can avoid a useless MCC... :D [19:58:51] and 0.5° out-of-plane [19:58:59] I think that is the 8NM crossrange rule [20:01:14] if 0.5° is only 8NM then your 0.08° from the min theta solution would probably have been fine [20:01:48] because the 0.08° will already include both the crossrange and approach azimuth difference [20:02:41] right [20:03:17] I think they would have prioritized for a 0 crossrange solution in reality [20:03:46] yeah [20:05:55] do you have any ideas on how to fix the AZMN FND and AZMX FND? [20:06:36] some, yeah [20:06:42] should be doable [20:17:23] I've enabled the display at least [20:18:33] and I implemented one fix [20:18:34] ... [20:18:46] the numbers look actually good already haha [20:19:30] although the intersection solution didn't calculate right for Apollo 11 [20:19:59] did you have that happen before? [20:20:03] the TIG is a negative number [20:20:16] I know I fixed some of the cases where that can happen, guess I didn't fix all [20:20:40] yes it happens [20:20:49] I was thinking it was normal [20:21:32] the RTCC Requirements document doesn't really go into detail, but it probably should be all 0 for those cases [20:32:49] I think that's an interesting bug with the intersection solution [20:32:53] not even a LOI targeting bug [20:34:44] and it does seem like I just had to fix one tiny thing and those true anomalies for min and max azimuths are now calculating correctly [20:37:40] sometimes you just have to stop working on something, not look at it for a while and once you look at it again you suddenly find an elusive bug [20:48:28] yeah haha [20:49:09] I find even after a good nights sleep, something you couldn't see in plain sight the night before suddenly becomes clear [20:53:55] keep getting "Error 4" at the bottom right of the checkout monitor [20:55:43] hmm [20:55:49] its GET 35:00:00, I put the flyby maneuver on the MPT, and using the checkout monitor to figure out my VIO "U02,CSM,GET,146:04:08,,,; MED U02 OK [20:56:04] but I get Error 4 [20:56:10] Input time is outside of ephemeris range [20:56:16] ah [20:56:37] are you pre TLI? [20:57:07] no, GET 35:00:00 [20:57:16] flyby pad calculation [20:57:17] you don't need to use the three ,,, by the way [20:57:54] U02,CSM,GET,146:04:08; works [20:58:00] space digitals column 3 works [20:58:07] ok [20:58:16] hmm, but why does it throw the error [20:58:27] it should generate 10 days worth of ephemeris [20:58:49] but it gives VEI, but I need VIO (0.05G) [20:59:10] oh [20:59:15] ephemeris ends at EI [20:59:37] so your time might be slightly beyond that [20:59:52] aha [21:00:00] that's what the threshold parameter is for [21:00:08] you can give it a threshold time that is earlier [21:00:20] and then it will propagate a state vector to your desired time [21:00:25] instead of interpolating the ephemeris [21:00:27] that should do it [21:00:47] U02,CSM,GET,146:04:08,140:00:00; [21:00:49] for example [21:01:23] actually, my bad, its 146:05:04 the 0.05G time [21:01:35] it takes the first state vector before 140h from the ephemeris and propagates it to your desired time [21:01:38] do that [21:01:42] I substracted the 28 secs from RTT instead of adding by accident [21:02:05] still, the ephemeris interpolation so close to the end of the ephemeris won't be super accurate [21:02:10] so use a threshold time [21:02:11] right [21:02:16] trying it now [21:03:30] I do think it would just give the error number on that display and you would have to look up what the code means [21:03:37] will be in the RTCC MFD manual [21:04:28] hmm [21:04:36] I get a chime when I add the 140:00:00 [21:05:02] oh [21:05:03] I wonder [21:05:11] input string length [21:05:55] yes probably [21:06:06] I had it limited to 30 for that button which is probably bad [21:06:10] character limit [21:06:18] try using 0 instead of 00 [21:06:24] hmm, maybe if I try height parameter [21:06:25] 140:0:0 for example [21:06:32] and I'll fix the chime [21:06:46] height is probably a good option [21:07:08] ALT is nautical miles I think [21:07:09] that is a fixed value right [21:07:21] pretty much, for lunar return at least [21:07:29] slightly below 300k [21:07:32] feet [21:07:45] that would take care of both VIO and GET 0.05G [21:08:06] 294084.3 ft is padloaded [21:08:12] thanks [21:08:24] 48.4 NM is what you need [21:09:04] it's actually 48.40005, I wonder if the 48.4 NM is the actual value and anything in meter or feet is derived from that [21:09:34] so input would be [21:09:44] hmm [21:09:48] U02,CSM,ALT,48.4,140:0:0; [21:10:05] it worked but [21:10:09] that should be below 30 characters [21:10:14] GET is 146:04:36 [21:10:23] which is RRT [21:10:35] and V is RRT velocity [21:11:18] did it just stop propagating at RRT, and not continue to 48.4 NM? [21:11:20] is that not what you want? [21:11:48] Im trying to fill the VIO and GET 0.05G of the flyby maneuver pad [21:12:06] I don't think it would stop [21:12:25] if anything it could find the time at that altitude when you are going upwards again [21:12:53] so the GET it came up with was the same as EI? [21:12:57] ye [21:12:58] yes [21:13:06] what threshold time did you use? [21:13:20] U02,CSM,ALT,48.4,140:00:00; [21:13:23] ok [21:13:36] checkout monitor has an altitude display [21:13:42] what does it show there? [21:14:11] HS? [21:14:50] yeah [21:15:01] that would be height above a Spherical Earth [21:15:10] while HO would be height above oblate Earth [21:15:15] HS is 48.4 [21:15:17] should be the same of course for us [21:15:24] then it found the right time [21:15:31] try EI altitude [21:15:35] bet that is earlier [21:15:45] but its weird because everything else tells me that time is RRT [21:15:51] 65.83NM [21:16:02] strange [21:16:15] like the RTE moon centered result tells me 146:04:36 GET RRT [21:17:04] 146:04:07 [21:17:16] uhh [21:17:18] RRT is EI [21:17:42] ok so that must mean, that the RTE moon-centered result says RRT, but it means 0.05G [21:17:45] yeah [21:18:03] I'll check what it shows there [21:18:45] so yeah, 65.83 NM gives a time of 146:04:07 [21:19:03] variable G->P37GET400K [21:19:21] oh lol [21:19:30] after the RTE is calculated [21:19:37] P37GET400K = res.GET05G; [21:19:41] who did this!!! [21:20:00] haha [21:20:06] hmm [21:20:19] I did this consistently though [21:20:46] hahaha [21:20:47] I think I meant that for the Maneuver PAD [21:21:04] so it should be the 0.05g time it shows on the RTE and deorbit pages [21:22:21] it's the entry interface time on the P37 Block Data [21:22:27] I guess that is where the confusion comes from [21:23:55] I guess the time was correct, just the wrong label [21:24:21] yeah, I'm adding variables for both [21:24:29] and fix the display [21:24:39] ok [21:24:45] it will be 0.05g times except on the P37 block data page [21:25:35] also, remember when I was asking about calculating the TLI+90 0.05G data from before TLI? Probably just needed a threshold time there too I guess? [21:26:43] could be [21:26:48] not sure about the Entry PAD though [21:26:52] why that didn't work [21:29:27] it doesnt work even with MPT inactive [21:29:52] I did my flyby solution, but most Entry pad values were bad [21:30:28] ouch [21:31:01] I think what is broken is the changes I did for the MPT anyway [21:31:17] where it selects which state vector to give to the Entry PAD calculation [21:31:44] also, I believe that that calculate needs some landing coordinates that were calculated before [21:31:46] maybe you should add a vector time selection for the pad pages? [21:31:58] that calculation* [21:32:42] maybe, I'll look at it [21:32:48] my flyby is 221 fps btw [21:33:12] can't be, Apollo 11 is free return [21:33:14] oh wait... [21:33:28] yep, not July 21st [21:33:35] only 16th and 18th' [21:33:59] we jumped so many topics, I had just uploaded this [21:34:01] https://i.imgur.com/tTAuSRx.png [21:34:09] that's the Checkout Monitor error codes [21:34:13] a bunch are implemented [21:35:24] ah, good to have [21:48:37] night! [14:49:04] hey [14:50:32] hey Alex [14:50:44] trying to get a few fixes done before I have to leave [14:56:06] RTE displays should be fixed now regarding the 0.05g and EI times [14:56:21] and the LOI display now shows those true anomalies on the left [14:57:00] I have some questions about the the Apollo 11 PDI Abort > 10 minutes and T2 T3 aborts [14:57:02] nice [14:58:31] the PDI > 10 min has a phasing TIG, do you remember how in the MCC that was calculated? [14:59:51] you mean our MCC or by the real FIDO [15:00:23] real FIDO preferably of course [15:00:28] haha right [15:00:44] didnt know if you had gotten that far yet :D [15:02:40] I did [15:03:09] from crew wakeup on landing day to about 110h GET [15:03:18] I already listened to [15:04:38] isn't that at apolune after insertion? [15:06:08] https://archive.org/details/69FM175Images/mode/2up [15:06:46] ah thanks [15:06:52] I didnt have that doc [15:07:30] page 30 I guess [15:07:49] I had requested it from Ron and he got it halfway done [15:07:56] a few months later he finished the rest [15:08:25] "The phasing maneuver for an abort at any time in this region is performed at 67 minutes after PDI" [15:10:35] looks like our MCC does it that way as well [15:12:20] I guess the DKI can be used for this [hasing [15:12:25] phasing* [15:14:59] I take a lot of notes when listening to the FIDO loop, but this was early on, so I wasn't doing that all the time yet [15:16:26] I guess that is just a phasing TIG, so they must have had a way to determine the DV of it onboard [15:17:10] yeah I think so [15:17:23] pretty sure we have that [15:18:33] we have the LM Rendezvous Procedures [15:19:10] yeah I have that open right now [15:19:22] cant seem to find any special charts for the phasing though [15:19:42] Apollo 11 Crew Charts [15:20:20] ah [15:20:24] I have that one too [15:20:34] let me check [15:20:43] yep [15:20:43] PDF page 49 [15:21:00] I think you run a P32 and get a DH that is not 15 [15:21:06] and use that in the chart [15:21:28] they probably ran this in the DKI as well though [15:21:33] well maybe [15:21:55] it was a busy time and they did not go through the full process of putting maneuvers on the MPT for every single abort [15:22:05] there was enough of that already [15:22:36] so if the PAD only has a Phasing TIG then they might not have run the calculation for it [15:22:41] can't remember [15:23:22] it would be the DKI of course [15:25:06] I guess its a fixed 67 minutes after PDI though [15:25:10] yep [15:26:06] the maneuver GETs in some documents have already been made finite burns [15:26:15] PDI is 102:35:19 [15:26:20] Phasing is 103:42:14 [15:26:40] impulse phasing TIG probably 103:42:19 [15:31:29] T3 abort must be a regular coelliptic profile [15:32:10] yeah [15:32:18] not sure about the insertion parameters though [15:34:23] it says right on the T3 abort pad, +5535.6, +32.0 [15:34:53] T2 has +5515.2 +19.6 [15:42:11] ah [15:42:20] so pretty nominal [15:42:22] for T3 [15:45:44] yeah [15:46:19] I dont know if there is a good way to calculate the T2 pad properly yet [15:46:57] T2 time is fixed? [15:47:02] PDI + 21:24 [15:47:04] I dont think the normal liftoff targeting would work with it, since it needs a phasing [15:47:13] right [15:47:40] you can just use that time and the insertion parameters, run the ascent targeting and put that on the MPT [15:47:50] without a launch time calculation [15:47:55] ah yes [15:48:01] and then use the DKI [15:48:04] that's how they did it I think [15:48:06] yeah [15:48:08] hmm [15:48:25] phasing is fixed 10 ft/s for that [15:48:46] definitely remember that from the FIDO audio [15:49:40] I think the TIG of that is 50 minutes after insertion [15:50:01] yes [15:50:03] they ran a checkout monitor for the insertion maneuver [15:50:08] burnout vector [15:50:09] the document says that [15:50:12] got the time from that [15:50:16] added 50 minutes [15:50:21] direct input maneuver [15:50:44] at that time and 10 ft/s DVX for External DV [15:51:02] they had that all on the MPT [15:51:07] and then the ran the SPQ [15:51:54] SP could comes from spherical, but I wonder if that acronym is a bit of a joke, as it's so close to "SPQR" [15:56:18] "without a launch time calculation" what did you mean by that? [15:56:57] well normally to calculate the launch time [15:57:00] you* [15:57:07] but for T2 it's basically fixed [15:57:16] so it doesn't matter what rendezvous profile follows the ascent [15:57:18] right [15:58:27] the rendezvous calculations don't start until you have the phasing maneuver on the MPT [15:58:52] but I cant seem to specify a specific liftoff time in the liftoff prcessor page, so do you mean, make the calculation in the Liftoff Processor, then in the Lunar Ascent Processor manually adjust LTO to the desired time? [15:59:17] I don't think you need any calculation in the liftoff processor page [15:59:21] what for [15:59:30] that's to determine the liftoff time [15:59:42] but that is fixed at T2 [16:00:21] so just enter the data on the ascent processor page [16:00:26] TIG and insertion velocity [16:01:05] ah ok [16:02:45] I think that's how they did it [16:03:09] the T2 might have been adjusted slightly by some calculation done by one of the support room people [16:03:43] will the ascent processor know to start from the landing site, and not the current trajectory stored in the LM MPT? [16:03:48] or they had some chart for it, as it would be possible that you don't get DH = 15 [16:03:54] since this is all done before DOI of course [16:04:24] yes [16:04:31] ok [16:04:32] it always starts at the best estimate of the landing site [16:05:00] it takes a CSM state vector from the MPT [16:06:01] and it does take the ascent stage mass from the MPT as well [16:06:11] at the liftoff time [16:07:48] ouch [16:08:43] https://www.dropbox.com/s/22feeukq7jdza6z/Screenshot%202020-03-25%2010.08.28.png?dl=0 [16:09:32] nice perilune [16:10:06] I wonder if I somehow didnt set up the MPT's right [16:10:29] have you initialized both MPTs? [16:10:37] yeah [16:10:56] and only the ascent maneuver on the MPT? [16:11:24] if you are before DOI the initial state vector of the LM MPT is a coasting one [16:11:37] you might want to put a PDI on the MPT before adding an ascent [16:11:45] and DOI I guess [16:11:55] ah [16:12:03] there probably should have been a check on the initial condition for the ascent [16:13:00] now I understand your question [16:13:22] the ascent processor will work fine in MPT mode even if you aren't landed in the MPT [16:13:43] but when you move the ascent to the MPT it starts with the initial, pre-DOI state vector and integrates through coasting and maneuvers [16:13:52] so for that then you will need DOI and PDI on the MPT [16:20:06] makes sense [16:20:16] im having a little trouble getting DOI on it [16:20:27] giving all 0's when I transfer to the MPT [16:21:01] LM MPT set up with initial configuration LM? [16:21:32] -15 seconds to throttle up? [16:22:43] yeah [16:22:50] https://www.dropbox.com/s/ntw3v5kbxuqu2v2/Screenshot%202020-03-25%2010.22.39.png?dl=0 [16:23:38] 0.4 instead of 0.925 throttle [16:24:30] but that isn't the issue [16:24:43] right [16:25:04] how did you initialize the MPT? [16:25:18] the same way as always [16:25:19] LM MPT [16:25:22] and what inputs for the LDPP [16:26:27] I just set it to the LM MPT, and VTI and LM Maneuver Sequence DOI [16:26:52] LDP display looked normal? [16:27:06] VTI and threshold times are all the same 102:00:00 which is in the future [16:27:09] yeah [16:27:53] isn't that a bit late? [16:27:59] ah [16:28:03] not for your scenario [16:28:48] actually, it is [16:29:08] delete the maneuver and try initializing the LM MPT again I guess [16:29:26] anything on the online monitor? Probably not... [16:30:40] tried that already [16:30:56] this is PDI-2 actually [16:30:56] well I can't get it to NOT work haha [16:30:59] oh [16:31:17] all I could do is use your scenario and do the same inputs [16:31:24] I am practicing with the Apollo 11 pre-DOI scenario [16:31:30] ah [16:31:40] I thought it was your July 21 launch one [16:31:43] but truing to get the DOI on it was too late, so I opted for the next REV [16:31:46] ok then I should be able to replicate [16:32:17] well I am practicing some abort pad creation with nominal mission 1st [16:33:04] ok [16:33:15] DOI at about 103:42 [16:33:42] good DOI on the MPT [16:34:48] hmm [16:34:56] mine was showing at 102:17 [16:35:02] somethings up haha [16:35:12] I have an idea [16:35:20] is your RTCC MFD using July 21 parameters? [16:35:23] like the landing iste [16:35:25] site [16:35:36] ohhhh [16:35:38] haha [16:35:43] of course [16:36:00] someone ran a July 21 sim and didn't clean up the RTCC [16:36:08] yep [16:37:24] wouldn't have happened if the MFD could already load those parameters correctly :D [16:37:46] yeah [16:40:13] ok DOI on the MPT [16:40:27] and PDI [16:41:43] and ascent [16:42:02] morning! [16:42:48] hey [16:44:11] what's up? [16:44:38] telling Alex that Apollo 11 can't land in the Ocean of Storms [16:45:24] lol [16:46:21] so phasing now also on the MPT [16:46:23] well it can if you launch on July 21 [16:46:33] but Alex didn't use that scenario of his .D [16:46:34] :D [16:47:22] ok next is something our coelliptic rendezvous processor can't do yet, optimize the CSI TIG [16:47:40] so I don't know, be creative [16:47:50] ill try :D [16:47:51] find the next apolune after phasing if CSI happened there [16:48:01] 1st I have to figure out the new SPQ format [16:48:23] it's closer to the MED for it, but not quite there yet [16:48:30] I guess in init I set DH to 15, E=26.6 [16:48:39] and then the desired TPI time [16:48:44] yeah [16:49:52] and TPI times are probably best generated in bulk [16:50:36] whenever there was a state vector update from tracking RETRO (helping out FIDO) generated 10 or so new TPI times using the sunrise/sunset display [16:50:58] so I got it from the CSM [16:51:06] and then they had a long list that would be valid for a while [16:51:11] took a picture of the whole display haha [16:51:20] so minus 23m [16:51:24] haha, that's one way to do a hard copy! [16:51:42] but you probably have no pneumatic tube system installed that is sending the printout to you [16:52:38] hmm fixed DH or fixed TPI time? [16:59:10] TPI time [16:59:14] ok [16:59:23] and then I play with CSI TIG to find the DH [17:00:12] uhh wait a moment [17:00:19] T2 abort has two CSIs? [17:01:18] I think the first one is a height adjustment maneuver [17:03:28] oh [17:03:34] so this does need the DKI [17:05:18] need to check the FIDO audio [17:09:34] at 98:19h the FIDO runs the "T2 Tape", which is probably the rendezvous MED inputs saved on tape [17:10:07] which usually means he is not saying the inputs out loud [17:10:21] have to go to an earlier time [17:12:13] https://apolloinrealtime.org/11/?t=098:23:11&ch=20 [17:12:22] this is the phasing maneuver direct MPT input [17:12:36] for T2 [17:15:01] and then SPQ, but the inputs from an earlier time [17:15:40] so its is the SPQ [17:16:23] yeah, they definitely ran that [17:16:43] I mean [17:16:47] the checklist has P32 for CSI1 [17:16:58] so with the right inputs you do the same as onboard [17:18:14] and then SPQ again for CSI2 with other inputs [17:18:37] ah probably fixed DH [17:18:42] for CSI1 [17:18:49] and then fixed TPI for CSI2 maybe [17:19:21] https://apolloinrealtime.org/11/?t=098:02:19&ch=20 [17:19:24] ah that gives me good DV [17:19:25] DOI calculation [17:19:29] for CSI1 [17:19:33] nice [17:19:33] +21.3 [17:19:39] pretty close yes [17:21:52] https://apolloinrealtime.org/11/?t=098:05:49&ch=20 [17:21:55] DOI transfer to MPT [17:32:19] they ran the SPQ for T2, but only once, to get the CSI1 TIG and DV maybe [17:32:30] at 98:32h the FIDO is already deleting the T2 maneuvers [17:32:34] from the MPT [17:33:18] at 98:34h he starts working on T3 [17:33:26] back an hour I go... [17:34:54] right, dont need more [17:35:11] so is CSI1 a fixed time as well? [17:38:36] not sure, could be CSI at apolune [17:39:23] so when I choose fixed DH, TIG is 107:45:00 and TPI is in the past [17:39:28] 104:00:36 [17:39:32] doesnt seem right [17:39:48] thats CSI2 btw [17:39:48] hmm [17:39:58] CSI1 is already on the MPT [17:40:08] CSI2 would be fixed TPI time I think [17:40:25] and that gives a good TPI time but over 100 fps CSI2 [17:40:45] fixed DH gives 40 fps CSI2, which is nominl [17:40:46] hmm [17:40:50] nominal* [17:40:58] is it? [17:41:04] I have -6.3 ft/s [17:41:14] no [17:41:16] wrong abort [17:41:19] 40 is right [17:41:54] what was your CSI1 TIG [17:41:58] the DV's look right but the TPI time is over 3 hours in the past, thats weird [17:42:06] 106:47:50 [17:42:10] 20.9 fps [17:42:44] what's the DH with fixed TPI time [17:43:01] -40 NM [17:43:22] strange [17:44:12] like you already coasted past the CSM and need to go backwards [17:44:32] yeah [17:44:38] and what fixed TPI time did you use? [17:44:46] 109:17:27 [17:44:53] also very nominal [17:45:34] and the CSI1 on the MPT looks ok? [17:45:43] could it be the chaser/target threshold GET's? [17:45:47] yes [17:46:26] well the threshold for CSI2 needs to be after CSI1, at least for the LM [17:46:41] chaser [17:46:43] I always set them to after the last burn, but before the next [17:47:30] can you show me your MPT and CSI1 DMT? [17:47:48] and maybe even your CSI2 inputs [17:48:26] https://www.dropbox.com/s/bvu4zzqy4ur0mrg/Screenshot%202020-03-25%2011.48.09.png?dl=0 [17:49:07] https://www.dropbox.com/s/cmjenny5dpczq2d/Screenshot%202020-03-25%2011.48.57.png?dl=0 [17:49:13] https://www.dropbox.com/s/0xp2vbacki26hzb/Screenshot%202020-03-25%2011.49.01.png?dl=0 [17:49:15] hmm [17:50:05] I don't know if that is a RTCC MFD bug, but you have 6° phase and 16.33 phase dot at CSI1 [17:50:14] whatever unit that is haha [17:50:48] but wouldn't that mean that you are already going away from the CSM [17:51:03] which is weird with the CSI1 calculation being so nominal [17:52:41] right [17:53:27] what does it say for your phase for the phasing maneuver [17:54:41] if that is minus then you are already in front of the CSM by CSI1 time [17:54:42] phase -23.34 [17:54:49] ok [17:54:52] phase dot 20.748 [17:54:53] so why [17:55:23] why are you already past the CSM by CSI1... [17:56:01] hmm, I used the right inputs for the ascent [17:56:06] PDI+21:24 [17:56:55] yeah, everything looks good [18:00:08] I am in an earlier scenario this time [18:00:19] still docked with the CSM [18:00:35] CSM orbit doesn't change much [18:00:43] right [18:00:45] the sep maneuver does not affect the orbital period of the CSM [18:02:25] PHASE DOT is degrees per orbit [18:04:11] you should have about -49° phase at phasing [18:05:37] super strange [18:10:24] yeah [18:13:23] I mean at least I can make the T2 pad now [18:14:33] TIG: PDI+21:24, Phasing: insertion+50mins, CSI1: Phasing+2h48mins [18:16:58] just as a sanity check, your CSM orbit in the MPT is 60x60? [18:17:09] checkout monitor or FIDO orbit digitals [18:17:50] yes I checked that already [18:18:10] 60x59.4 [18:29:11] ok, have to go now. Not sure when I will be back, at the latest in a week or so [18:29:32] cya! [16:47:17] morning! [16:49:10] hey [16:49:57] oh hello [16:50:00] thewonderidiot, I took the Apollo 11 FIDO audio for the lunar ascent with me while I am gone from home [16:50:25] 16 hour file, seems to start at 20 minutes before lunar liftoff [16:50:37] the first name I hear being mentioned is George Silver [16:50:37] nice, find anything interesting in it? [16:50:42] hah really? [16:50:59] it's of course about the computer overloading [16:51:26] awesome, I will have to give that a listen :D [16:51:38] slew is bad they say [16:51:49] if the RR is powered or not [16:52:01] so better put the RR in LGC mode and RR circuit breakers open [16:52:31] I hear it on the FIDO loop because GUIDANCE must be talking about it [16:52:58] oh wait, they actually did that? [16:52:59] FIDO, RETRO, GUIDO is the trio you can usually hear talking on all their three audio loops [16:53:06] oh yes [16:53:13] it's even in the lunar surface checklist [16:53:18] the flown one [16:53:21] handwritten change [16:53:23] oh wow, I thought they did it wrong on ascent [16:53:24] by Buzz [16:53:36] well, RR circuit breaker does absolutely nothing [16:53:42] in this instance [16:53:52] yeah, that's pretty much what they are saying [16:53:59] switch in LGC mode is the important one [16:54:36] they have the problem very much identified [16:54:42] duty cycle increase in slew mode [16:54:52] not necessairly the exact cause of the problem [16:54:56] but they know [16:55:19] if they follow the checklist then they would have the RR powered and it would have tried locking onto the CSM already during ascent [16:56:31] what was their reasoning for having the breaker out? [16:57:15] not much more than that the problem is coming somewhere from the RR side so best have it off, I think [16:57:21] gotcha [16:57:34] not critical to already lock on during ascent [16:58:10] that was never done in later missions anyway [16:58:17] and the LGC routine for that got deleted [16:58:37] works quite nicely though [17:00:47] you can see the handwritten changes in the Apollo 11 lunar surface checklist on the ALSJ website [17:02:42] I'll be back later [18:32:47] .indy91, I think AEA loading is broken, When I activate the AGS, the whole sim slowed to a very low framerate. I checked the default Apollo 11 scenarios in lunar orbit and the issue does not happen "FLIGHT PROGRAM 6" is already in those scenarios [18:32:52] damn [18:33:05] .tell indy91, I think AEA loading is broken, When I activate the AGS, the whole sim slowed to a very low framerate. I checked the default Apollo 11 scenarios in lunar orbit and the issue does not happen "FLIGHT PROGRAM 6" is already in those scenarios [18:33:09] haha [18:34:11] .tell indy91, I checked the default Apollo 11 pre CSM/SIVB separation scenario, separate the CSM, activate the LM and AGS the issue does happen though [18:39:49] .tell indy91, now that was the bad news, but dont worry, I have some good news as well :D [18:51:32] . [18:52:19] probably caused by the update that makes it use the mission file [18:52:41] should be easy to fix [18:52:43] yeah thats what Im thinking [18:53:43] let me guess, good news is for your T2 abort [18:53:49] or UHCL [18:54:13] nope, but you may run off to work on SSU once I give you it haha [18:54:50] but yes, I got the docs from UHCL [18:54:52] first I have some AGS to fix it seems [18:55:07] great [18:55:36] I'll not run off I promise. In fact I will neither work on NASSP or SSU in the next few days :D [18:56:05] but I would love to see those documents... [18:56:13] oh but once you see how juicy this 302 page doc looks :D [18:56:25] uploading to dropbox now [18:56:34] yeah I bet [18:56:40] I was excited to find out it even exists [18:58:14] thanks! [18:58:20] no problem [18:58:38] hopefully that Apollo 14 doc has some good info too [18:58:39] there goes half of my remaining Internet volume [18:59:32] ouch [19:00:18] I should of warned you it was 80 MB in all [19:02:23] no problem [19:02:36] the FIDO document is a little bit helpful, but not very detailed [19:02:50] the Apollo 13 one, which was a different kind of document I believe, was better [19:03:03] more rationale on how things were targeted [19:04:44] right [19:05:59] the rendezvous document looks fun [19:11:09] "CSM MCC2 was planned so that LOI would achieve the nominal GMT of arrival at longitude 180 on rev 2" [19:11:45] yeah [19:11:47] just re-affirms what we already knew of course [19:11:50] that is even in the flight plan [19:12:07] but I guess the orbit digitals should be useable for this? [19:12:21] you can specify a longitude and rev [19:13:47] I'm not entirely sure it will generate the table of rev crossing times so early in the mission [19:17:03] im testing it now with my post_TLI Apollo 14 scenario [19:17:27] at the same time I can test the AZMN AZMX FND [19:17:58] 1st interation shows AZMN 354.5 AXMX 354.0 [19:18:28] and what is your FND/H? [19:18:32] for the plane solutions [19:18:57] 354.2 [19:18:59] if the calculation works right then that would be in the middle of those two numbers [19:19:02] ah perfect [19:19:33] so, what this will tell you is that using the minimum azimuth value will probably get you a smaller DV [19:19:38] as it's closer to 0/360° [19:19:50] although for Apollo 14 that doesn't make much of a difference [19:19:58] quite large plane change during LOI [19:19:59] so 354.0 [19:20:35] 354.5 is the closest to 360° out of the 3 numbers [19:21:57] and LOI being closer to pericynthion (0/360° true anomaly) will usually be the lowest DV [19:25:49] but I am very happy that the calculation of those two numbers works now, with a very minor fix [19:26:54] oh and the intersection solution that sometimes has a negative TIG [19:27:06] that is actually a bug in the calculation for the display [19:27:17] all numbers associated with those maneuvers are set to 0 [19:27:25] and then it converts 0h GMT to GET [19:27:36] and the result is that negative number [19:28:01] so it will show the negative of the liftoff time there I guess [19:28:05] easy fix [19:34:38] oh the checkout monitor can be used for the time check on 180 L' [19:35:07] yeah, but by manually checking different times only, right? [19:36:44] yeah [19:36:51] a bit of a hassle [19:38:43] but it can be done [19:38:46] oh [19:39:04] if you have a time at which you want the longitude crossing to happen [19:39:34] you can probably just check the longitude at that time and then with a simple empirical calculation get the time difference you need [19:41:30] you travel about 3°/minute in lunar orbit [19:42:18] so if the longitude at the desired time is wrong by 3° you need to adjust the time limit in the MCC processor by 1 minute [19:44:17] in that doc it says longitude 180 [19:45:59] but at 84:45:12 I have LONC +62.69 [19:46:05] seems way off [19:48:11] "start of REV 2" [19:51:42] aha [19:51:45] MCT not MCI [19:52:02] now I have -178.049 at 84:45:12 [19:52:49] basically less then a minute difference [19:58:50] yeah [19:59:18] 3°/minute is that the post-LOI ellipse though? [19:59:46] it's a rough estimate for a 60x60 orbit [19:59:51] right [19:59:57] for 60x8 it will be more [20:00:10] well we need 170x60 [20:00:26] then it's a bit less [20:00:44] well [20:00:51] dont think the checkout monitor has the orbital period [20:00:52] not at perilune though [20:01:09] I would work with 3°/min [20:01:16] if you wanted to do an adjustment [20:01:18] ok [20:01:43] an exact longitude check is more cumbersome [20:07:43] works quite well [20:09:17] after finding tweaking the MCC to have LOI give the nominal REV 2 GET, LDPP indicates a TD time within 45 secons [20:09:33] after tweaking* [20:10:00] nice [20:10:16] what about the issue where DOI happens at a time quite different from normal [20:12:44] didn't you have some cases where LOI happens at a nominal time but DOI didn't? [20:14:54] yes [20:15:14] Apollo 14 flight plan DOI: 86:56:57 [20:15:34] the one I just calculated: 86:50:13 [20:16:54] but heres the thing [20:17:00] must be those perturbed orbits we don't get in Orbiter [20:17:12] real Apollo 14 DOI pad TIG: 86:50:55 [20:17:52] huh [20:18:21] I like it [20:18:24] of course they had a delay, but after LOI, the trajectory should be the same as the SCOT I think [20:18:37] atleast on Apollo 14+ [20:19:45] maybe there were errors in preflight estimates? [20:19:56] could be [20:20:13] are we sure we have the final version of the flight plan? [20:20:34] hmm maybe not [20:21:04] the only thing I find weird is the ~500 fps LOI DVZ component [20:21:14] real pad was half of taht [20:21:18] that* [20:21:46] but it seems to give the correct post-LOI ellipse [20:21:48] does that make the total LOI DV much larger than planned? [20:21:57] its exactly as planned [20:22:03] interesting [20:22:14] 2985 fps [20:22:30] well 3 fps less [20:22:33] and that's with a lot of LOI rotation I guess [20:22:41] 1.94 [20:23:09] then I'm not too worried about the DVZ [20:23:32] right [20:23:44] after this mission Ill fly Apollo 14 [20:23:53] test all that out for real [20:24:07] not just simulate it with the MPT :D [20:24:59] almost as much work just simulating it with the MPT :D [20:25:27] right [20:25:51] listening to the Apollo 11 FIDO audio for lunar ascent [20:26:04] first two things he does, CSI calculation with PGNS and then with the AGS state vector [20:26:23] using "same as onboard", I guess that means CSI TIG etc. [20:26:37] as it was given to the crew [20:28:10] and then a third run using the MSFN state vector [20:43:10] ok, first examination of that Shuttle onboard rendezvous document [20:43:23] it's Skylab on steroids [20:43:38] but it is not all the capabilities that existed before and after at mission control [20:46:24] it wouldn't have been able to handle the kind of rendezvous profile the Shuttle actually flew most of the time [20:47:59] right [20:48:12] document is from 1976, reference profile is two coelliptic orbits after each other [20:48:48] but I do think that I can take bits and pieces from it and use it in my MFDs [20:51:11] makes sense [20:51:29] also very good compared to the predecessor document of this, it has numbers for iteration tolerances [20:52:09] about the AEA issues I was having, I think maybe it is only wrongly initialized when the LM is created by the SIVB [20:52:51] hmm [20:53:00] maybe it's not loading the mission file properly [20:54:10] but if I delete the whole AEA section in a post LM creation scenario then it works fine [20:55:30] I'll take a look when I get back home, I'm sure it's fairly easy to find [20:55:40] ok [20:56:14] in the mean time, I think I fixed my scenario by deleting the AEA then only putting the padloads back as MEM's [20:57:10] but I want to be sure its loading the right AEA version, because if theres mission file loading issues, then it might give me FP8, the default [20:57:42] but if the mission file loading issue is only at LM creation from the SIVB, and not scenario loading then I guess it should be fine [20:58:32] hmm, how to tell FP6 and FP8 apart... [20:58:34] I wonder if theres an easy way in-sim to check AEA version [20:59:20] can you readout memory addresses of fixed memory maybe [21:00:45] those start at address 1000 [21:00:50] might be difficult... [21:01:12] or no [21:01:19] I forgot how the AEA software works [21:02:01] there is a checksum routine [21:03:54] do a AEA self test and check address 153 [21:04:10] but I don't know they expected value :D [21:05:08] check the AGS manual, probably tells you more about this than I currently can [21:05:17] right [21:15:23] night! [16:46:01] morning! [17:03:23] hey Mike [17:06:33] what's up? [17:08:46] landing Eagle at Ocean of Storms [17:09:06] hehehehe [17:09:11] the Apollo 11 July 21st landing site [17:10:04] oh I didn't know that was the official landing site for a backup date, that's cool [17:10:21] yeah [17:10:37] we have a full LVOT for it and July 18th launch [17:10:54] nice :D [17:11:04] July 18th had a different landing site as well [17:11:11] might try that one some time [19:16:25] good evening [19:17:37] AlexB_88, LEM::SetupPayload in LEM.cpp. Replace the line with agc.SetMissionInfo with CreateMissionSpecificSystems [19:17:51] I think that might fix the AGS issue [19:17:54] hey Niklas [19:17:56] thanks [19:18:17] SetupPayload is only called from the S-IVB when the LM gets created [19:18:43] and CreateMissionSpecificSystems or so is calling both the AGC and AGS function to set the software version [19:19:18] I think that's what I had overlook [19:19:54] ed [19:22:48] Ill test that today [19:23:16] Had a good landing with Apollo 11 [19:24:20] AGS seem to be ok, it had a weird issue where the altitude tape meter is at 77000 feet the whole way down, but H dot looked good [19:25:07] ah, weird [19:25:20] hmm [19:25:36] I don't think I had adjusted the AGS padload for any of the other launch days [19:25:45] so e.g. landing site radius could be wrong [19:26:50] I had updated 231 [19:27:16] ok [19:31:06] continued a bit with the Apollo 11 FIDO loop for the lunar ascent [19:31:15] a few more CSI calculations, some CDH [19:31:21] a DKI run for a non executed CSI case [19:31:50] and a little bit of confusion about the sign of the DVY for the CSI [19:32:42] "1.0 instead of -1.0, is that right? They must have changed the procedures" "Or you just didn't understand the procedures" [19:33:34] haha [19:35:08] pretty hectic until LOS, then suddenly FIDO tells his team they did a good job and then the flight director talked to all his flight controllers about what to do after AOS [19:35:23] so more relaxed [19:38:18] all in all the FIDO audio is probably not super interesting after lunar liftoff [19:38:36] a lot of events happen behind the Moon and are onboard calculated anyway [19:40:26] also, how do you get a go from a flight controller who is not at his console? [19:40:50] you ask the person sitting on the console next to him to press the button that makes the light go green on the FD console [19:48:15] I must say it was pretty hectic for me too last night, trying to get all those pad's done on time :D [19:48:53] yeah, definitely a busy time before landing [19:49:02] DOI, PDI, early abort, late abort and no-PDI+12 all before undocking [19:49:19] they are doing a lot of preparation, but they do want to use a fairly recent state vector for the calculations [19:49:27] so it's all done quite late [19:49:32] yeah [19:50:10] I think right now I am going to test one of the abort pad's I created [19:50:26] I wouldn't trust the T2 one too much :D [19:50:38] haha [19:50:41] unless you solved your phasing issue [19:50:47] thats the one I was eyeing lol [19:51:29] you'll get back to the CSM, in some way [19:52:05] I guess the test is you do phasing and then if your initial CSI calculation gives you DH of 15 then something went right [19:53:28] is that so, even with two CSIs? [19:53:42] and both having non zero DV in the rendezvous procedures [19:53:58] right [19:54:13] its a profile I dont think I've flown before [19:54:47] I have only flown the late PDI abort that also requires a phasing type of maneuver [19:56:44] oh, I did found one interesting thing in the Apollo 14 FIDO report [19:56:58] about the powered descent abort constants programs (PDAP) [19:57:03] program* [19:57:17] they had some run failures of it [19:57:53] caused by the ascent integrator not doing insertion super accuratly but the iteration needing it to be more accurate [19:58:03] well I know exactly what this is talking about [19:58:07] I had the same issue at first [19:58:30] implementing RTCC Requirements documents for both ascent integrator and the PDAP [19:58:59] just funny seeing them having the same bugs as I got, implementing their requirements [20:00:24] interesting [20:00:55] btw on my DOI calculation, the DMT for some reason would not give me AGS DV data [20:01:07] I was using the LM MPT for the DOI [20:01:31] also the FDAI angles did not make snse [20:01:34] sense* [20:01:51] weird [20:02:07] and for some reason, no PDI+12 calculation DMT display was fine [20:02:24] it should calculate AGS DV for all LM PGNS maneuvers [20:02:41] have to try and replicate that some time [20:07:09] I tested some TEI pad's with the latest updates (0.05G time display) [20:08:03] for some reason though, my check on 0.05 G with the checkout monitor does not produce the same data as displayed by the RTM [20:08:46] off by a minute or so [20:18:08] also, when I add the TEI to the CSM MPT, and check column 3 of space digitals, things look a bit odd: GEI -4.8 HVP 41.3 [20:23:01] hmm [20:24:58] so when I add an MCC (corridor control) in the MPT, now the space digitals are fine. Maybe something in the function that turns the impulsive TEI to non-impulsive through thrust selection that goes astray? This seems like just an issue that TEI is slightly inaccurate [20:29:04] I mean maybe this is normal behavior, post-TEI state vector on the MPT would have to be very accurate to get the correct EI data on the other displays...maybe in the real missions they would add an TEC MCC on the MPT for generation of the EI numbers on the TEI pad [20:40:54] well I think we have noticed before that TEIs arent as good as they used to [20:42:01] so there is probably a bug [20:47:01] yeah, I remember Apollo 12 MCC-5 being on the order of 2 fps, when I used to be able to skip that one [20:47:23] I had some up to 5 ft/s [20:47:36] well, maybe not MCC-5 [20:47:50] or yes, probably MCC-5 [20:50:55] I guess it would affect all moon-centered RTE calculations [20:51:37] hmm I think my flyby pad/pc+2 was ok though [20:51:42] let me check again [20:53:10] they could be less affected, especially if they are lower DV [21:10:39] night! [19:09:21] good evening [19:12:26] hey Niklas [19:14:31] afternoon! [19:22:13] I am updating my "RTCC MFD inputs reference guide" document right now [19:22:46] sounds like a useful document [19:24:12] Ill make it available once its finished [19:24:58] its definitely not a manual, just a document with the less-obvious/mission specific parameters [19:25:14] right [19:26:50] I think eventually I'll create (next to the manual) some mission specific FIDO procedures using the the MPT and all [19:26:57] not just FIDO I guess [19:28:17] and nothing too interesting to be gained from the Apollo 11 FIDO audio for the lunar orbit rendezvous anymore [19:28:33] so I'll continue with Apollo 13 instead [19:30:12] still need to listen to a few hours before Apollo 11 lunar liftoff though [19:31:52] here is a preview: [19:31:52] https://www.dropbox.com/s/wref04wmp4ltsjk/Screenshot%202020-03-28%2013.31.38.png?dl=0 [19:33:43] very nice [19:39:02] a bit les messy then my old notes :D [19:39:06] less* [19:40:48] haha I bet [20:01:22] I have a copy of the SA-506 Flight Manual now, if there's anything that would be helpful in it [20:01:41] I didn't see any scans online when I was looking last night, but maybe I missed them [20:01:54] I think we have one [20:02:10] from the other NASA online document thing [20:02:18] forgot what it is called [20:02:20] oh NTIS? [20:02:24] cool [20:02:25] I think so yeah [20:03:23] don't have my PDF collection available right now, but I think I found it there [20:03:36] yep, you're right [20:17:32] we have a good number of Saturn flight manuals by now [20:22:38] loud phone ringing on the Apollo 13 FIDO loop, my poor ears [20:29:35] cya!