[20:52:04] NASSP Logging has been started by indy91 [20:52:06] night! [11:52:42] hey [11:56:03] morning [12:14:16] got the question in the discord, what are the advantages of using a pulse torque over a coarse align for a P52 option 1? In NASSP I cannot see any but IRL? [12:36:50] I think it's a question of accuracy. but not sure if that applies to us, or to the degree it would irl [12:39:01] yeah thats what I was thinking as well [12:39:23] question is though, wouldnt the fine align torquing make up for errors? [12:56:44] Yes during a coarse align the platform is moved to the new orientation. Fine align torques the platform while still keeping track of forces on the craft. You do fine align by a certain amount of degrees determined by start sightings, it doesn't automagically make up for errors in the platform. [13:02:36] I thought that was the purpose of the fine align/P52 in general, to fix the errors? [13:53:02] Well yes. You know the error in the platform by doing star sightings and then you apply that error as an input for torquing the IMU. So you always do a fine align in P52 but not always a coarse align, you only do that if you switch to a different REFSMMAT IIRC [14:06:25] well you can pulse torque a different alignment as well thats my confusion here haha [14:07:37] In NASSP yes. But can you in real life? There might be another reason besides it being slow. [14:08:32] Yes pulse torquing is an option on I think Apollo 11 and later? [14:08:52] For a P52 option 1 you can choose to coarse align or pulse torque to the new orientation [14:09:22] TIL [14:09:54] I haven't really used the later ropes much. Most of my experience it with Colossus237 and 249 [14:11:00] yeah that's the root of my question haha, you can choose either option and in NASSP I think there is no benefit over either, but I am curious what IRL benefits are there [16:05:49] hey [16:07:30] good afternoon [16:20:02] hey Alex [17:17:10] hey [17:17:16] morning! [17:23:52] what's up? [17:25:27] not a whole lot -- mostly been figuring out how I want to do electronics for my dsky [17:25:28] you? [17:26:10] did a bit of Apollo 7 flying. Pretty sure I started P34 with a good state vector, but the TPI time is a bit off. [17:26:17] Maybe my sextant marks were bad [17:28:25] the method that the RTCC MFD uses to get the state vectors from the AGC also doesn't seem right. I think it gets the wrong ones. [17:29:21] it has a time tag of before I did P20 [17:29:36] that can't be the same state vector then as used in the rendezvous calculation [17:29:40] with sextant updates [17:30:41] I'm getting the state vectors at E3,1554 and E3,1626 [17:33:21] I could use RN, VN, PIPTIME instead [17:33:26] "PERM STATE VECTORS FOR BOOST AND DOWNLINK -WHOLE MISSION-" [17:34:29] yeah that sounds reasonable heh [17:35:13] surely P20 saves the permanent state vector when you exit it... [17:40:52] hmm now I remember why I used these state vectors [17:41:05] their addresses are the same for all Colossus and Luminary versions [17:41:18] but RN and R-OTHER aren't [17:50:15] right [17:54:34] so it's been delayed for a couple of years at this point.... but Don and I are making arrangements for me to finally visit again for another scanning trip in the next month or so :D [17:57:20] oh great :D [17:57:53] I was looking at the three pages from the Apollo 7 Final Flight Plan yesterday [17:58:15] it's still the same as back when you made the photos of that. Would be awesome to have that, but not super high priority [17:58:32] yeah. I'll have to talk to Don about his policy for removal of staples [17:58:42] if I can't pull the staples, then chances of getting the whole thing are low [17:58:51] but if I can, then I can run it through the autofeed scanner very quickly [18:00:29] right [18:04:13] I'll start making a list of definitely-scan things [18:06:14] ah thanks. I remember that spreadsheet. [18:06:36] it will be nice to just be able to scan things this time and not have to create the index haha [18:08:29] I'm really excited to finally get the Norton document for Luminary 1D, to confirm some things that were ambiguous for that reconstruction [18:08:45] that will certainly help [18:09:11] for a while I didn't think I was going to be able to finish it without it [18:09:26] but now I mostly want to know things like, what the DOWNLIST variables were actually named, and things like that [18:10:30] I'm going to do my best to leave no PCR, LNY, etc. unscanned [18:10:36] same applies to Sundance with our P10/P11 variables haha [18:10:39] heh yeah [18:10:48] I remember I really wanted to have a mission techniques document that UHCL didn't have, seems like Don has a bunch of them. [18:11:14] "Large folder of Mission Techniques memos" [18:11:15] "Limits of Gimbal Rates" Do we have that one already? I don't think NASSP has any limits right now [18:11:44] hmmmm [18:11:53] there's a chance I took a picture of it [18:11:54] what kind of gimbals is that talking about [18:12:07] My guess would be IMU [18:12:08] it's right next to stabilization loops, so possibly IMU [18:12:26] Would be great if it also lists the limits of the GDC but I guess it won't [18:14:13] yeah my number for the yaw angle where the GDC has some sort of gimbal lock effect is very much an estimate [18:14:27] I think the best we have is drift rate estimates at some yaw angles [18:15:24] "Effect of short duration bus transients on LGC v-fail detector" Might also be interesting. I'm always up for improving power transient behavior in NASSP. [18:16:31] I think I might have already gotten that one [18:16:47] last time I was visiting was right before we started the AGC restoration [18:17:02] so I was in hardcore "gather as much relevant information about powering up an AGC as possible" mode [18:17:35] Cool. Shoot it my way if you run into it. [18:17:54] Thymo[vacation]: http://www.ibiblio.org/apollo/Documents/stg_memo_1429.pdf [18:18:10] ty! [18:21:05] I've always been confused what this is supposed to tell me [18:21:06] E3,1735 E3,1642 T-OTHER [18:21:10] which address is it??? [18:21:20] yeah Yul is weird [18:21:21] er [18:21:23] not Yul [18:21:25] YaYUL [18:21:26] EMEM1735 72347 [18:21:27] EMEM1736 47554 [18:21:32] that would be a negative value [18:21:37] which is not so great for a GET [18:22:09] yeah ignore the left number [18:22:12] the right one is correct [18:22:18] ok, but then [18:22:18] E3,1721 R-OTHER [18:22:23] the number is on the left only [18:22:33] then you use the left number :D [18:23:03] I guess it would be most accurate to say "use the rightmost number" out of however many there are [18:23:12] hmm, guess that means T-OTHER is not in the same place as R-OTHER and V-OTHER then [18:23:30] slightly annoying [18:23:36] yeah [18:23:44] they'll be in consistent locations in the downlist [18:24:03] which doesn't really help you with how you access things... but that's why their actual memory location doesn't matter as much [18:24:42] true. Maybe if what n7275 is working on can be fed into the RTCC MFD [18:25:00] one thing you could do that would always work but would be annoying would be to write something to process the downlist format yourself, and figure out where it wants to read those things from [18:25:40] assuming something related to downlists is stored in a consistent place... [18:28:38] sounds complicated [18:29:02] for e.g. uplink addresses I added RTCC system parameters, because it would have that [18:29:20] downlink processing would happen more like the telemetry client [18:29:47] and I'm mostly trying to see what caused the wrong TPI time. CSM state vector is pretty good. [18:30:14] if I could trigger P00 to do orbital integration then I could get the state vectors like I did before [18:32:45] hmm, both state vectors are better than 1000 ft accurate [18:34:05] which is almost too good to be true, there was a SPS maneuver for the CSM and S-IVB sextant marks since the last uplink haha [18:37:19] hmm maybe it's accurate actually [18:37:41] actual mission had TPI time of 29:20:30 on the first recycle, 29:12:26 [18:37:45] on the second [18:37:50] 8 minute difference [18:38:03] I have 6 minutes difference to the RTCC time [18:38:08] so maybe it's going to converge [18:40:09] yeah I was probably expecting too much for Earth orbit [18:43:41] oh hi [18:45:11] telemetry processing won't be too hard I think [18:46:22] it will basically work like the telemetry client, but rather that printing values to a form label, it will be to a data array class [18:47:03] RTCCmfd could then read from the arrays [18:48:05] that sounds good yeah [18:48:11] I want to do this in a seperate thread though, so making sure it synchronizes, and does reads and writes at the right time will be the hard part [18:48:37] will be a lot of work to have the right processing for each mission [18:49:49] I will make the array as generic as possible, and then load scaling and offsets from a config file [18:50:42] yeah I think that's how I got started with that, too, before I abandoned it [18:51:10] in the telemetry client [18:51:12] the LM one [18:51:35] what I actually ended up doing was a lot more derived from the CSM telemetry client and now how the RTCC does it [18:52:41] indy91, I see TLCC_TLMIN and TLCC_TLMAX is now loaded from the scenario [18:53:01] should we add those to the pre-launch scenarios? [18:53:31] we might finially have a reason to impliment DES too [18:53:40] dse [19:06:47] AlexB_88, we could yeah, for missions that use modes 4 or 5, so Apollo 12 and later [19:07:16] one problem though. I'm not sure that the burn solutions are consistently trending toward one end of the limit [19:07:37] what we usually do is 10 minute limits [19:07:47] and it usually runs into one of the limits [19:07:54] right [19:08:08] but if your TLI is a bit different, does it always trend toward the same limit? [19:08:33] and if not the preloaded values aren't very useful as the LOI TIG will still be 10 minute off, at the wrong limit [19:08:37] good question [19:09:04] so no guarantee that those values being preloaded is actually really helpful [19:09:21] n7275, isn't the DSE in digital form quite large? [19:10:17] haven't done the math though. It's probably a lot of megabytes, right? [19:33:55] ah now I get it. I was looking at the wrong thing. The S-IVB state vector had a very small position error after the sextant marks, but a 3 ft/s velocity error. That caused the difference [19:34:16] not too unusual an hour away from TPI I would say [19:35:16] a neat thing you can do with the MPT and the vector panel summary. Downlink telemetry vectors. Promote them up through evaluation and usable vector table. Do the trajectory update with those vectors. And now you are doing all RTCC calculations with the downlinked state vectors. [19:35:41] and it got me the same TPI TIG [19:35:45] as the CMC [19:48:05] indy91, yeah dse would be several MB [19:48:59] don't really want to save 2 of those in the scn [19:49:26] nope haha [19:50:34] "why do my quicksave freeze orbiter for 90 seconds..." [19:51:24] I'll need to think about how best to do that [19:56:17] yeah, 1.44MB [21:02:09] night! [21:33:25] I'm off to Italy. See you guys in two weeks. :D [21:33:49] see ya, have a good trip! [21:44:56] have fun! [14:26:34] hey Ryan [16:17:51] afternoon [16:19:23] yo [16:24:06] I think I may need to trim back some of my branches. I'm starting to a accumulate quite a lot [16:28:38] I have the opposite problem, I should have more of them haha [16:42:22] I have one started for the rtcc telemetry. didn't get very far code wise, but i do have some whiteboard diagrams I'm my office I'm working from now. [16:49:09] because I tend to push directly instead of making PRs I often start work on an update in the Orbiter2016 branch [16:49:43] more often than not a "small" updates is growing in size all the time and it becomes something that should be in a branch [16:55:48] I've finally done the Apollo 7 rendezvous btw. I don't like how random it is if a sextant marking sequence goes well or not [16:56:20] don't think drag is causing any difference in the last part of it. Just relevant for targeting the early burns, NCC1 etc. [16:57:04] if the RCS keeps the relative motion super steady then the marks are very accurate [16:57:48] but if the targeting is moving a lot then the convergence for the velocity vector is bad. Position accuracy is usually good. [16:57:54] target* [17:11:49] hmm, I still need to make some decisions for how much drag I want to compensate in the Apollo 7 MCC [17:15:49] morning! [17:18:21] hey Mike [17:18:31] what's up? [17:19:13] did the rest of the Apollo 7 rendezvous [17:19:34] drag isn't much of a factor in the last 1-2 hours [17:19:43] new sextant reticle is totally fine for the job [17:19:52] I am using resolved mode like 99% of the time now [17:21:18] now I need to decide how much S-IVB drag I should use in the RTCC for all the calculations [17:25:19] I can do accurate sextant marks. But if the target is moving a lot in the field of view I end up with fairly large velocity errors in N49. [17:25:55] Not sure what that means, because I am certainly marking directly on the target and the state vector reflects that. Small position error, but larger velocity error which of course accumulates over time. [17:26:47] how quickly are the measurement data saved when you mark? [17:26:58] probably difficult to tell... [17:27:45] I wonder if I should track the target with the sextant during marking, or if it only matters that I mark exactly on the target at the right time [17:40:52] some times during P51/52 I mark when the star "flies" through the crosshairs [17:41:34] never had an issue with accuracy, but that's only angular [17:42:19] yeah for P52 that works well [17:45:01] I'm not sure of tracking would help or not [17:46:28] it should save the same kind of data as for a P52 and that very quickly, so I wouldn't really expect it to help [17:46:39] surely it has saved the relevant numbers within milliseconds [17:51:04] hmmmm [17:52:31] nah, the interrupt is generated correctly. For a moment I thought the mark button only causes the input bit [18:06:34] very strange that it's only velocity [18:07:39] I think you can easily tell if the mark wasn't right on target, then you get a non-zero DR in N49 [18:08:13] but the DV becomes larger if the CSM is moving around too much while marking, at least it feels that way [18:17:11] how often does the agc update its orientation vectors? [18:19:02] doesn't get calculated until after the mark [18:19:11] when you mark it stores IMU angles, sextant angles and time [18:19:27] and after that it calculates an inertial vector to the target from that [18:40:31] I cant think why it should care that the csm is moving. how big is the error? [18:41:42] yeah it shouldn't matter as long as the rate isn't super fast and the data is saved quickyl [18:42:11] my first marking sequence left me with a 3 ft/s velocity error [18:42:30] because that was quite some time before TPI it has a 6 minute error in TPI time [18:43:01] and on my last sequence, the last two marks had 1.0 ft/s errors [18:43:08] pretty sure it was spot on before that [18:43:24] but that caused the TPI TIG to shift by 2 minutes [18:43:29] got me a 6 ft/s MCC-1 [18:43:41] still ok, although larger than the real mission and larger than I like [18:44:46] it seems that it's almost worth it to wait for a long time until attitude rates are low [18:44:54] even if you do fewer marks with that [19:32:53] that's quite a long time there, do you think you get through more than just he "must have" documents? [19:33:04] or is the must have list already/still quite long [19:47:00] yeah I'm anticipating the must have ones only taking a couple of days [19:47:17] but I'm also planning for there to be a lot of "research" time [19:47:50] e.g. reading through things like "Larson et al Phone Logs ~67-77" around key dates, searching for references to things link LNY-77 [19:48:09] right. Instead of a scan request I might just have a specific question in one specific document, or one page or so. [19:48:30] yeah, if you can make a list I can definitely tackle a lot of those [19:48:57] will certainly do. I don't expect I have that much really. Most of the mission techniques documents are at UHCL [20:45:43] also feel free to make a list of "things to research" that you think might have some shot of being mentioned in some of the notebooks or phone logs [20:45:58] like my LNY-77 stuff [21:07:40] hmm, right, I'll think about that [21:08:27] who caused the V49 operator error bug in Colossus 237 :D [21:10:04] hahahaha [21:10:35] I almost mentioned that -- but I don't think Russ Larson would have been involved in that in any way [21:10:39] although George Silver might have [21:10:49] I'll keep that in mind while looking through his stuff [21:12:05] it's such a weird, random, inconsequential bug in such a often used extended verb [21:13:09] hehehe [21:17:07] there has to be a story about that, although I doubt that we will ever hear it. And if it's just some AGC programmer being made fun of being responsible for this being in a flown rope. [21:17:34] lol [21:17:42] that seems very likely :D [21:26:33] night!