[15:57:47] NASSP Logging has been started by n7275 [15:57:49] hey [16:15:41] hey Matt [16:17:11] "The way orbiter calculates its first timestep actually results in a rather substantial initial offset" [16:17:17] what do you mean with that? [16:29:40] I might need to amend my wording there to be more specific. [16:32:57] I'm not entirely sure how Orbiter deals with first timesteps. in fixed timesteps mode, if you start paused, the simulation starts at the end of the first timestep [16:33:44] hmm I see [16:34:04] all I really know is that with variable timesteps the first step is always 0.01 seconds [16:34:08] but it works normally [16:40:53] with fixed, it's the length of the fixed step. [16:41:30] so I'm my case 5 seconds [16:50:45] it's hard to say what a "good enough" drift rate would look like, but 200m per day probably isn't it [17:05:26] it's very strange to me that disabling nonspherical gravity, then manually setting the state vector, would result in a 300km shift in position. it doesn't even look like that actually happens, which is the odd part [17:07:21] manually setting how [17:08:46] if scenario editor, could it be a delay in pressing apply [17:08:53] if the simulation is not paused [17:13:52] yes, with the scenerio editor, the simulation was paused, then I started the recording and unpaused [17:22:10] and all with fixed length steps? Can't say I have much experience with it [17:26:09] and RK8 [17:31:46] my goal was agreement within 5 meters after a day. that might be a bit ambitious. [17:32:16] I mean, for that a lot of other things need to work out [17:32:25] Moon rotating for example [17:32:41] maybe my "screwed up" version causes problems [17:33:01] ah, but maybe you aren't even using the NASSP universe [17:33:09] nope [17:33:18] and what MJD? [17:33:23] near 2000? [17:33:33] April of 2001 [17:33:52] 52006.76972 [17:34:12] close enough haha [17:37:27] coincidentally about a month before the first release of Orbiter [17:41:31] if it was a velocity error it would need to be around 2.5mm/sec [17:43:04] and it's not the radius of the Moon or the standard gravitational parameter? [17:43:29] Did you check or change it to be in agreement with GMAT [17:43:47] oh wait [17:44:15] that could be it [17:45:49] I manually set the 0,0 coefficients to 0 rather than 1 so Orbiter is doing all of the point mass stuff [17:47:06] I had tried that before way back when I was working out coordinate system stuff. it obviously doesn't fix those, so here I am thinking "I've already tried that" [17:48:25] thank you [17:49:20] standard gravitational parameter is like the main gravity thing, it's so obvious that you wouldn't even think it could be that :D [17:50:01] they differ a bit from what's in the moon config [17:50:43] it's like 6th decimal place and on, but then again...so is my position error [17:51:43] it's just a mass of course. I checked in Orbiter code at some point, it does uses the Orbiter API variable GGRAV to calculate the mu [17:53:27] if you were doing this in Earth orbit, Orbiter uses the same radius for the actual radius of the body in Orbiter and for gravity calculations [17:53:45] I bet over longer periods of time using the wrong radius also gives errors for us [17:58:27] morning! [17:58:46] hey Mike [18:00:03] what's up? [18:00:58] fun with gravity [18:36:26] :D [21:37:58] night! [13:38:42] good morning [13:44:52] hello [14:02:04] all this GMAT stuff is making me want to try some mission planning with it [14:02:45] good luck :D [14:23:53] At some point they added the capability to the Shuttle computer to calculate a rotation-nutation-precession matrix on its own [14:23:59] I'm looking at that function right now [14:24:36] Based on the default Earth config and my understanding of the B1950/M50 coordinate system I am getting a 0.3° error in longitude [14:24:53] it is that whole UTC, timing, leap seconds whatever thing again [14:25:05] timing and coordinate systems in Orbiter are going to be the end of me... [14:26:05] In latitude I can see the nutation but otherwise it cycles around zero difference over the years [14:26:41] in longitude it's quite off and getting worse with time [14:29:56] they're going to be the end of me too apparently [14:33:20] it works pretty good with the NASSP config actually [14:33:31] but it's a bit of circular logic [14:34:01] my understanding of the coordinate system could be wrong. And the config was adjusted based on the cordinate system [14:34:13] although to be fair, it works out for quite small errors with the AGC [14:35:22] a few hundred meters errors at worst with the NASSP config [14:36:28] the RNP matrix calculation of the Shuttle I mean [14:40:36] and will mostly be nutation [14:41:05] Does that mean the Earth config is wrong or my understanding of the coordinate system is wrong. Will I ever know? :D [14:41:32] same coordinate system as Skylark and same type as all the rest of the AGCs. So kind of important to know... [17:31:13] I should try building Orbiter against one of Martin's prereleases. [17:31:31] s/Orbiter/NASSP [17:31:52] that makes more sense now haha [17:32:36] afaik sound is the only big thing in the way of us doing that [17:51:09] morning! [18:01:39] hey Mike. how's it going? [18:02:03] good! what about you? [18:03:50] good, and very happy that it's Friday [18:08:07] hahaha very much same [18:08:19] I am very ready to have a down weekend [18:12:22] hey [18:12:48] yo [18:15:49] trying to get a bit more Apollo 7 in [18:16:07] did the phasing burn getting away from the S-IVB with the same DV as actual mission, 5.7 ft/s [18:16:18] the drag-less solution is 1.8 [18:17:06] I still need to figure out beter criteria for the 2nd phasing burn [18:17:30] they only did that because the S-IVB had an unscheduled vent, dropping its orbit enough that it would have actually overtaken the CSM :D [18:17:46] haha [18:19:36] without that the 5.7 ft/s is really the worst, worst case [18:19:52] of S-IVB having lots of drag [18:24:00] my expectation is that usually we will have to do a second phasing with about the same DV as the actual mission [18:24:04] but opposite direction [19:08:13] ah, we might finish our set of Aurora 88 modules next week [20:17:27] nice! [20:35:22] perfect [21:23:32] yep, should be Tuesday or Wednesday [21:30:31] what I hadn't really considered is the difference the SLA panels are making for the drag [21:31:23] ohhhhh yeah that has to be a huge factor on 7 [21:31:39] in this RTCC system parameters document for Apollo 7 they have an area of 365 sq ft for the S-IVB while it is still connected to the CSM [21:32:07] it's an early document and they even say "for information only", but they up it to 1000 for the S-IVB alone [21:32:23] and then, presumably for the time the S-IVB has lost power/control up to 1400 [21:32:51] our model isn't detailed enough to really send it tumbling [21:33:13] and for me it doesn't run out of fuel until it looses power [21:33:21] so it will continue being in the least draggy attitude [21:33:31] but the SLA panels is something I need to take into account for sure [21:35:23] I can't just increase the area because then the model doesn't make sense anymore with 90° pitched [22:05:27] night! [14:18:55] hey [14:23:35] hey Matt [14:50:33] what's up? [14:52:33] gave the S-IVB a new drag model [14:52:48] static const double CD_free[nlift] = { 2.9251, 3.3497, 6.1147, 11.08, 6.1684, 3.1275 }; //free flow (no panels) [14:52:51] static const double CD_free_hinged[nlift] = { 8.0141, 8.0141, 8.0141, 13.744, 8.0141, 8.0141 }; //free flow (panels hinged) [14:52:52] and then [14:52:57] if (sivb->ArePanelsHinged()) [14:53:00] { [14:53:03] *cd = CD_free_hinged[i] + (CD_free_hinged[i + 1] - CD_free_hinged[i]) * f; [14:53:08] } [14:53:10] else [14:53:11] { [14:53:12] *cd = CD_free[i] + (CD_free[i + 1] - CD_free[i]) * f; [14:53:13] } [14:56:01] oh very cool [14:57:22] you're making me want to fly 7 again :) [14:59:05] if you can wait then there will be the right amount of drag and phasing burn DV :D [15:04:22] first phasing burn is -5.7 ft/s [15:04:43] yesterday, with the S-IVB not having enough drag, the second one was +6.8 [15:05:41] but now I hopefully get a smaller second one with the drag from the SLA panels taken into account [15:05:59] there probably doesn't need to be a second one at all [15:06:14] further away from the S-IVB is acceptable [15:06:23] getting too close to it before NCC-1 is not [15:12:52] I can wait. [16:16:00] +3.5 ft/s for the second phasing [17:47:52] morning! [17:53:48] hey Mike [17:55:34] another bank of Sunrise fully disassembled :D [17:55:48] now into the second pinball bank which has most of the verbs and nouns [17:55:58] ah that's fun [17:59:10] easy to disassemble but lots of unknown names? [17:59:26] or did I describe the difficult part of a disassemble :D [18:02:00] hahaha these banks haven't been toooo bad [18:02:09] sometimes it just takes a bit to figure out what I'm looking at [18:02:23] pinball got pretty heavily refactored [18:03:06] luckily there's only been a few instances where I've struggled with names haha [18:07:19] so pinball needed just two attempts early on and then it was in its final form, quite impressive [18:21:33] well maybe [18:21:39] now I'm very curious how Eclipse and Sunrise differed [18:26:56] ah Eclipse [18:27:24] that's really getting into the Pre-Cambrian [18:31:06] it's pretty much the only step further back we can go haha [18:36:53] also, kind of fun -- a lot of things that I've found are different so far are called out as differences between Series 0 and Series 50/100 in the comments [18:36:56] # OPDEGOUT USED TO TEST BIT 13 OF WASOPSET (1 = 90 DEG RANGE, 0 = 180). [18:36:58] # SINCE THAT BIT IS ALWAYS 1 IN BLOCK 50 - 100, DON;T TEST IT NOW [18:39:34] Poor software guys had to keep up with hardware changes [18:39:44] remember the LM stage input bit... [18:40:01] hahaha yes [18:40:05] Where LM-1 had it inverted from LM-3 and later [18:40:12] that was a fun little discovery [18:40:15] and LM-2 having a fun time doing its own, strange thing [19:04:21] oh boy just as I was saying pinball wasn't so bad, this chunk is completely different [19:05:37] ohhhhhh got it, this is a very early form of MIXNOUN [16:09:36] hey [16:27:57] hey Matt [16:58:09] morning! [17:18:54] hello hello [17:28:30] hey Mike [18:12:45] I need to motivate myself to write documentation. Always the hardest part. [18:21:56] oh yeah that is very hard [16:10:55] hey [16:11:01] hey Nik [16:11:22] I'm in a mood to delete things [16:12:11] RTCC is on the chopping block [16:16:03] oh? [16:16:45] just a lot of code that is really outdated and couldn't be deleted because of dependencies, some function for the MCC still needing it etc. [16:17:38] ahh cool. [16:18:49] speaking of deleteing things. there is still some IMFD stuff in some places. do we need to keep that/even have the ability to interface with it? [16:18:56] not really [16:19:39] something was difficult with deleting the remaining parts of that, but I can't really remember what [17:42:10] morning! [17:57:03] hey [17:57:16] what's up? [17:57:19] still having fun with Sunrise? :D [17:57:26] deleting RTCC things [17:57:35] and then running into trouble deleting RTCC things [17:57:38] hahahaha [17:57:45] sounds like fun :P [17:58:31] and yeah, I'm having a great time with Sunrise. lots of weird little differences and not too many completely unexplainable mysteries [17:58:49] I only have 4.5 banks left to go though, so I'm starting to get to the scary stuff [17:59:53] what is the scary part? [18:03:33] system test, prelaunch alignment, and orbital integration [18:03:49] the more mission-y type things that are heavy on interpretive code [18:04:12] luckily we have AGCIS issues for system test and prelaunch alignment [18:04:23] ah nice, I'll have to look at that orbital integration code some time :D [18:04:29] but orbital integration is very scary and we have no documentation haha [18:07:17] shouldn't it be implemented like in R-467? [18:08:25] although, that looks even more theoretical than the later GSOPs [18:09:00] can it really be that different from Solarium? [18:10:17] lol yeah R-467 is highly theoretical and turning that into names of routines is going to be very hard for me :P [18:10:46] it seems decently different from Solarium, at least from the little bit of poking at it I've done [18:11:22] I did find the KEPLER routine so that's at least an entry point [18:27:29] also the fact that one of the program sections in Solarium is called "ORBITAL INTEGRATION FOR 501" makes me a bit afraid of what they changed [18:34:33] yeah, that part seems to be somewhat of an interface with the orbital integration [18:35:04] very familiar function names, converting back and forth with stable member coordinates for maneuvers [18:35:45] yeah so presumably Sunrise is going to have some sort of equivalent for interfacing with progress control [18:44:35] does Sunrise even have the Average G integrator? [18:44:42] that could be the main differences there [18:45:08] I don't think it does [18:45:09] Solarium starts using orbital integration after "TLI", having used Average G all the time since liftoff [18:45:20] right [18:45:30] and will then have to do the conversions, which is that "ORBITAL INTEGRATION FOR 501" probably [18:45:38] yeah that makes sense [18:46:31] I remember state vector uplinks in Earth orbit (average G still running) being quite different from later uplinks (for orbital integration) [18:46:42] hmmm I think you're right and a lot of the actual orbital integration code is almost identical to solarium [18:47:25] and hopefully identifying all of the chunks that are unchanged will give me enough variable names to make sense of the Sunrise-only bits [18:50:32] maybe I'll mess with this bank tonight and report back with questions tomorrow haha [18:53:23] sounds good [18:56:40] I'm suuuuuper curious if the prelaunch alignment bank is going to bear any resemblance to Sundial E [18:56:50] because whatever Sundial has is very different from the other ropes we have [20:02:15] and we should get the full Aurora 88 tomorrow, which will be another interesting comparison :D [20:18:55] oh that's why Comanche 67 has to wait until next month, you are already overloaded with software to disassemble [20:19:13] hahaha [20:19:21] well it's a little convenient that way [20:19:32] every month a new present [20:19:34] but I promise you if I had the choice I would be on a flight to retrieve Comanche 67 right now :P [20:20:12] yeah, I wasn't serious haha [20:21:08] I'm hoping to get an actual date for that nailed down this week or so [21:55:10] night! [17:32:15] hello [17:39:16] good evening [17:43:32] hey Nik [17:43:48] morning! [17:45:49] indy91, orbital integration is better than I had initially feared but worse than I was hoping based on my initial findings lol [17:46:08] how do you feel about learning the Block I interpreter? :P [17:46:17] so not the "mature" Solarium version [17:46:25] yeah [17:46:29] sure [17:47:18] haha excellent [17:47:32] gimme another couple of days to finish the rough disassembly of the bank [17:49:57] unfortunately whoever was in charge of this program section was very good about cleaning up after themselves, from what I've seen [17:50:19] in a lot of places Solarium has still had the erasables from Sunrise, even if they're not referenced anymore [17:50:27] or comments that didn't get removed [17:50:43] but orbital integration looks pretty clean, like they took care of updating everything / deleting unused things [17:52:46] ah nice [17:53:29] not nice, it's less hints for us haha [17:53:38] Orbital integration was probably one of the first orbit things they really worked on getting it to good state [17:53:51] yeah that makes sense [17:54:18] How early did they come up with the interpreter? [17:54:50] one of the things that surprised me was that the values for J2REQSQ, 2J3RE/J2, and J4REQ/J3 are all different, even though the math referencing them is seemingly the same [17:54:52] oh very early [17:55:00] they had it running on at least the Mod 3C [17:55:03] if not the 1B [17:55:07] they probably had orbital integration and such things in mind with the interpreter [17:55:44] any complicated math thing that doesn't have to be fast in real time [17:56:04] oh here [17:56:07] Very different values for J2 etc? [17:56:16] Can't be a scaling thing? [17:56:27] Or a test setup for the Moon :D [17:56:49] "The most ambitious of these programs was a set of interpretive subroutines by means of which programs could be written in pseudo-instructions more powerful than the basic four Mod 1A instructions." [17:56:58] it could be a scaling thing potentially? [17:57:05] they're not dramatically different [17:57:53] Solarium has: [17:57:56] J2REQSQ 2DEC .335914874 [17:57:58] 2J3RE/J2 2DEC -.003309146 [17:57:58] J4REQ/J3 2DEC .60932709 [17:58:39] if I did my math right, Sunrise has: [17:59:00] J2REQSQ 2DEC .33587616 [17:59:01] 2J3RE/J2 2DEC -.00330903 [17:59:01] J4REQ/J3 2DEC .71761542 [17:59:49] the first two are quite close, the last one is pretty different [18:01:33] yeah, well, that's not very different over all [18:01:57] the knowledge of the Earth gravity field was still improving, maybe the J4 was just a bit outdated [18:03:20] that makes sense :) [18:09:24] notices the discussion topic has turned to gravity models [18:09:39] hahahaha [18:25:13] I'm pretty sure the AGC model would give you some hilariously wrong results if you ever flew one in a polar orbit [18:26:36] Earth or Moon? [18:27:51] both, I'm assuming [18:29:06] I need to reread that Boeing paper [19:39:26] speaking of orbit propagation, how accurately do the RTCC and AGC keep up with state vectors, at least within the context of NASSP as it is currently? [20:30:21] hmm, difficult to quantify. I haven't often tried a direct comparison with Orbiter [20:30:41] one time I did it when Ryan had Apollo 9 trouble, which is when I found how random the CSM drag was [20:31:10] I believe he calculated a deorbit burn with the RTCC MFD 24 hours before it happened and then later when the MCC calculated it the solution was very different [20:31:27] I kind of questioned everything there [20:32:04] but I did then set the drag of the CSM to 0 and compared predicted trajectory to actual [20:32:16] and I believe this was very accurate, 100 meters over 24 hours or something [20:32:43] the AGC will be slightly less accurate because it uses a larger integration step size [20:33:25] I did initially use the AGC orbital integration in the RTCC and first set the step size to 0.1 compared to the AGC, but this was over the top and slow [20:33:31] so I settled on 0.3 [20:33:55] with the lunar orbit however I haven't done such a comparison and I always wondered how much the Earth and Sun are pulling [20:34:32] But, since our LOI processor uses an integrated solution to fly over the landing sites the crossrange at PDI is sometimes all the way down to 0.0 from up to 2 miles, so [20:34:37] can't be that bad :D [20:35:31] okay [20:37:11] I'm pretty sure that the big difference I'm seeing between Orbiter and Gmail is related to a difference between propagators, RK8 vs RKF89 [20:37:23] GMAT rather haha [20:38:53] yeah, I've had that in MATLAB a few times where setting some precision variable a bit smaller suddenly gave the expected results :D [20:40:11] the difference between spherical error and nonspherical error is on average probably about 10m per day. [20:40:42] can probably live with that [20:44:24] unless Martin wants to impliment propagators with error control...that somehow are friendly to a realtime simulator... [21:04:36] indy91, anything specific I should check with the PCM timestep fix? [21:05:19] not really, it's quite simple [21:07:34] not very elegant solution, but still the easiest one without adding something that gets done often per timestep [21:07:42] I guess I wrote that all in the PR description [21:15:13] that's what I assumed. I'll pull it and build and test for good measure and then approve. [21:27:38] to really test it you need to be in debug mode [21:27:49] TLC scenario, LM exists but not powered [21:28:02] and then in the LGC timestep, unpowered, where I added the code [21:28:19] it should make sure that a normal amount of telemetry cycles are done on the first timestep [21:28:47] of course technically there should be no telemetry at all [21:29:00] but the PCM doesn't check on power yet [21:37:59] night! [15:49:59] hey! [15:50:17] hey Matt [15:53:51] merged that PR [16:17:20] nice [16:17:33] did you see the launch this morning? [16:17:49] yep [16:18:20] cant believe that thing is finally flying :D [16:18:23] took long enough [16:48:51] i thought it was going to be like JWST again. [16:49:17] they certainly put some miles on the crawler [17:28:59] morning! [17:33:53] hey [17:34:58] what's up? [17:36:47] GLS from the forum found some bugs in my Shuttle FDO MFD, so I am trying to get rid of those [17:36:51] how is Aurora? [17:36:55] any trouble reading it [17:36:59] no trouble at all [17:37:13] it was all 2003972 modules so problems would have been surprising [17:37:40] this Aurora 88 module is surprisingly different from Aurora 85 [17:38:01] 3 major revisions then? :D [17:38:03] I was expecting just a few small patches, but it's like 270 words different, 215 of which are completely new [17:38:11] in what sort of sections [17:39:00] not entirely sure yet :D [17:39:09] haha ok [17:39:16] let me see if Ron's disassembler can pick up enough to figure that out [17:43:59] hmmm [17:44:20] lots of changes in the radar routines [17:45:16] no doubt starting the mess that doesn't get much better until Luminary 100 :D [17:45:33] hehehe [17:46:37] oh whoa, they may have changed some extended verbs here [17:46:59] the extended verb table has three changes in it [17:47:40] and looots of new stuff at the end of the extended verbs bank [17:47:41] wouldn't it be fun if Aurora could move the landing radar [17:47:43] not quite sure what [17:47:52] even more fun if we had an animation for that in NASSP... [17:48:03] haha [17:48:53] ah well [17:48:57] some changes in fresh start and T4RUPT [17:49:03] Aurora 12 and Sunburst 13 also can do that [17:49:11] 37* [17:49:55] IMU mode switching stuff [17:50:36] and maybe some AOTMARK things? [17:50:40] they changed a lot here [17:51:04] do you already know the verb numbers that changed? [17:51:30] uhhhh one sec, I can probably calculate it [17:52:51] both 85 and 88 are before the DAP Aurora? [17:53:22] yeah [17:53:39] DAP aurora resembles approximately Sunburst 15 or so [17:53:48] from my current estimates [17:53:56] also sorry only two extended verbs changed [17:54:04] 60 and 61 -- prepare for and recover from standby [17:55:48] well I mean, the entries in the table only changed for those two [17:55:56] I think more verbs changed, just in their implementations [17:56:11] maybe they needed a bunch of manual steps for that before they added those verbs [17:56:35] could be yeah [18:01:09] that doesn't start P05 and P06 in any version we have, or does it [18:01:40] Sunspot has V60/V61 but also P05/P06 [18:01:48] need to find some procedures for that... [18:06:57] hahaha [18:07:18] Sunspot sounds like a weird rope :D [18:09:04] interesting list of verbs [18:09:15] "Calculate time of arrival at longitude" [18:09:38] Artemis added that (back) with P29 [18:19:14] oh fun [18:22:09] so I was pretty distracted last night but I did make some more progress on orbital integration in sunrise, and was able to tentatively name a few more things [18:22:32] I might be able to finish my first draft on the bank tonight [18:23:59] dazzled by sunrises and auroras, careful with your eyes [18:24:05] hehehe [21:38:23] night! [15:57:31] hey Nik [16:09:23] hey [16:57:03] morning! [16:57:59] hey Mike [17:00:11] I actually have an on-topic question today. [17:01:08] the fpga/AGC interface into Orbiter. how does that work exactly? [17:01:55] oh boy [17:01:58] what part of it? [17:06:08] what is actually being communicated between the simulation and the hardware. is copying the hardware state into yaAGC or is it just IO and similar stuff being communicated? [17:06:44] I'm mostly just curious. and I know very little about it [17:08:07] yaAGC is totally disabled/bypassed [17:10:01] the monitor lets you either inject values into erasable via the debug-only STORE instruction, or swap out erasable entirely (so when the computer tries to access erasable, the monitor inhibits the memory cycle and supplies its own data through the test connector instead) [17:10:36] so I capture the counter changes NASSP tries to write into yaAGC memory and forward them out to the monitor [17:11:58] I also capture any channel changes and forward those as well. those are tricky to get into the hardware because the channel bits are part of the hardware. the monitor watches for channels 30-33 to be accessed and minorly "corrupts" them by changing the instructions to reference channels 70-73 on the fly, such that when the computer tries to hit the channel no real channel data gets overlaid on the NASSP data [17:12:24] for outputs I just have the monitor report output channels every frame or so [17:14:15] interrupts are also really hard, for e.g. the DSKY [17:14:54] I don't do the channel nonsense for that because we can put a pullup resistor on the AGC's main connector to keep the keycode bits 0 [17:15:14] but it's impossible to directly generate an interrupt through the test connector [17:16:19] luckily the RESUME instruction to leave an interrupt is a special case of INDEX, which is capable of modifying instructions [17:17:14]