[02:04:24] NASSP Logging has been started by thewonderidiot [02:04:28] Guenter! [14:52:09] n7275 love the youtube post :) [15:10:54] :) [15:15:59] I want to go back and film rendezvous from 10kft to docking. [15:21:39] hey guys [15:21:47] you should do it [15:21:55] Morning Niklas [15:22:22] You probably saw how I fell down the CSM external lighting rabbit hole last night :P Boy I learned a lot [15:22:39] yeah haha [15:24:27] I'm down the CM aerodynamics rabbit hole [15:25:03] the least realistic thing in NASSP right now is that the CM will stabilize itself in basically any attitude [15:26:16] at high Mach numbers there is a stable region near 0° angle of attack [15:27:01] trim AOA is at 160°. It only automatically stabilizes itself between 110 and 250° [15:27:38] is that orbiters doing or NASSP code at this point [15:28:11] well it's because we define a fixed center of pressure, which makes the aerodynamics works without having to define two airfoils right now [15:28:24] that center of pressure is realistic for the normal attitudes [15:28:37] I think I will have to set that to a all zeros vectors [15:28:54] and then adjust the moment coefficients accordingly [15:30:16] just like with the CSM, the way Orbiter has this implement works fine for aircraft [15:30:33] but a little different for the CM alone [15:30:34] but not so great for spacecraft, not even the CM. At least not at weird attitudes [15:31:27] it's a bit of an annoying workaround. For the CSM I basically calculate the moments around the body axis [15:31:41] then I have to convert them to lift and drag axis [15:31:47] and then Orbiter converts them back to body [15:33:07] but I think it can be done for the CM, too [15:35:46] haha yeah sounds like its annoying to bounce back and forth like that [15:45:25] I can see how the left-handed coördinate system would make that a pain to work on. [15:47:44] yeah. At least I have the conversions worked out now. Once I have identical graphs for the NAA simulator equations and the Orbiter calculations then I know I have the correct solution [16:14:55] hey [16:18:01] good morning [16:26:49] hey [16:28:05] morning! [16:40:44] AlexB_88 thanks for posting that, the reason I asked for a scn is because I gave him that data to input already so I am curious as to whats up [16:41:39] Hopefully its just a missing parameter like you said but that post tweak orbit concerns me haha [16:42:26] Also for 15, I think tweak is insertion +2 minutes (not that it matters much here) [16:42:36] yeah maybe the PHASE or DEL H entered wrong [16:42:50] ah right [16:43:11] I ran him through those numbers a little bit ago but again, its easy to miss things with RTCC the first time through (or the second, third for that matter) [16:44:50] Just hoping its user error not a bug somewhere [17:01:08] his CSM orbit seems to be very circular at least [17:02:31] Also after PC his crossrange was almost zero [17:03:00] If the inputs are correct, I think it might have to do with nulling the ascent residuals as that can be a pain [17:03:24] But still, the resulting orbit Pe troubling after those tweak dvs [17:03:30] high dvz [17:07:09] I never usually see tweak DV's above 10 ft/s or so [17:07:51] one thing I used to always screw up is the phase angle [17:08:03] -1.7 instead of 1.7 [17:08:15] yeah, because I used to have that wrong in the RTCC [17:08:27] but positive = chaser behind [17:08:28] its a bit counter-intuitive because you are 1.7 behind [17:08:39] right [17:09:49] Yeah mine are usually <10fps as well [17:10:35] it should be small, the ascent processor page properly simulates the ascent. As long as the liftoff time targeting uses the numbers from that processor it should be quite accurate [17:13:25] lots of debate on how to come up with the best values on the Apollo 11 FIDO loop [17:13:44] we have it easy, their ascent integrator was only used in the MPT and couldn't independently output these numbers [17:14:06] they had to let the RTACF people run some ascents to come up with tweaked numbers, accounting for updated weight etc. [17:15:03] but I'm sure by Apollo 15 they had cleaned up the process for this [17:15:13] as it's quite important for the short rendezvous profile to work right [17:25:51] I'm implementing that insertion state vector uplink thing [17:28:16] with MPT inactive you need to calculate the ascent while in the LM and then switch over to the CSM [17:28:25] for the uplink [17:29:05] the only thing missing for the ascent processor to work in the CSM in non-MPT mode is getting the LM mass for the integrator [17:52:24] oh the CMC really didn't like that state vector [17:52:44] SOI indicator was missing from the saved SV [17:53:04] didn't even stay in P00 [17:53:29] I guess it thought it was an Earth SOI state vector [17:53:37] so way inside the Earth with that position vector :D [17:54:17] the uplink page should really display Earth vs. Moon [18:04:07] I should also reset the surface flag :D [19:41:31] rcflyinghokie, I'll make it easy on myself and in the first version it just gives the insertion state vector itself to the CMC uplink page, not a specific time tag [19:41:42] the SV time is then also the insertion GET [19:41:46] which you can use [19:41:58] Or should I also let it display the time in GET on the ascent processor page? [20:42:35] that would be practical for ie. having the insertion GET quickly without going to the checkout monitor [20:43:36] I'll just let it display the GET of that state vector on the right side [20:43:46] the last number there is already the GMT of insertion [20:45:05] indy91, btw does the MCC scenarios use the latest and greatest with regards to the rendezvous calculations? I think you had updated them in the RTCC recently-ish...might be mistaken though [20:46:39] uhh [20:46:59] it might still use some old calculations [20:47:44] yeah, like the old Lambert targeting for the No PDI + 12 PAD [20:49:02] right, I vaguely remembered one of the programs being renewed based on RTCC documents...but maybe I am thinking of the LLT (for direct rendezvous) [20:50:53] well I changed the Lambert page to the Two Impulse Processor page a while back [20:51:01] that's when the MFD started using new calculations [20:51:09] but not the MCC yet in all places [20:52:03] right [20:52:42] Ill be flying ascent+rendezvous tonight or tomorrow [20:53:54] so far no issues to report with MCC...simulated ascent (1 REV after landing) numbers looked good [20:55:33] I even think I might simulate a PGNS failure before ascent...not sure yet though [20:56:37] now that we can rely on the manual RR markings in the AGS [20:57:35] that still is a challenging procedure :D [20:59:21] I guess we'll see how good that fix was or not [20:59:33] or maybe how bad I am at taking the marks :D [21:02:23] ah about that tweak burn calculation using the proper MOCR display [21:02:41] this is for coelliptic and from 1968, so a bit old [21:03:14] "The Mission Planning subsystem provides a rendezvous monitor (ARM) which updates the proposed rendezvous plan on a two-second cycle. The same type of insertion vector predictions and rendezvous computations are performed [21:03:15] after an abort in the Descent phase. Upon receipt of main engine cutoff (Thrust Off), the Hold phase calculations are initiated. PNGS and AGS vectors are averaged and displayed. Additional RCS thrust periods may follow main engine cutoff. Each time the thrusters are used, the ARM processor will be passed a new set of averaged vectors. " [21:04:21] I am fairly sure it will still be the same for the "Short ARM" [21:06:34] it kind of depends on mission phases and physical switches which our RTCC doesn't use yet, but it could maybe be actively doing the calculations when you have that MFD page up [21:07:08] what I wonder is, what calculations does it do that the RTCC can easily perform every 2 seconds [21:07:18] I doubt it's the normal RTCC rendezvous processors [21:11:04] well, I know there was a lunar version of it. I thought that was just doing a few modifications for lunar orbit, or maybe it is light-weight enough (or has a light-weight mode) that can run so quickly [21:42:24] indy91. crazy idea. our MCC missions run off a hard coded sequence. what do you think about making that run from script-defined sequence when we get to 9.0+ [21:43:09] probably doable. A bit like the Checklist MFD I guess [21:43:20] with different criteria to continue to the next step [21:43:36] mission time, time relative to the last state, or time relative to e.g. LOI [21:44:48] but the RTCC calculations are still very specific, that wouldn't give too much more flexibility [21:46:49] also, were you thinking of making the "Request Abort" option work for Apollo 10-11 as it does in 8? I guess its a bit more complex with the LM ops [21:47:28] by that I mean the MCC support to EI after Request Abort is done [21:48:38] probably, yeah [21:49:01] I was putting it off, any changes to the normal MCC makes that a lot more complex [21:49:14] I think the way it works for 8 is once its pressed, you burn the last issued abort pad [21:49:23] and then you get support to EI [21:51:15] I think that for Apollo 10/11 you always have enough data to get from lunar surface to post-TEI at any given time in lunar orbit ops correct? [21:52:04] yeah, at least you are supposed to. On the actual missions [21:52:34] so the Request Abort button could then just wait until it detects TEI has been done, then carry on from there [21:53:04] TEI or any TLC aborts [21:55:12] I guess it could also detect if your docked or not in lunar orbit [21:56:21] but yeah I guess with the LM ops it makes it much more complex :D [21:58:54] I think the MCC already tracks the last TEI computation [21:59:18] so if you request abort it could then go to a process where a while after TEI it starts doing TEC stuff [22:00:22] ah ok [22:00:57] so it basically already does what I said, from post TEI [22:01:25] yeah. So that part might be fairly simple [22:30:02] listening to the FIDO loop to eventually get to lunar ascent and (that little bit of) ascent rendezvous monitor usage [22:30:06] the FIDO is just like me [22:30:20] gives all the inputs for a launch window calculation [22:30:26] and then realizes he hasn't got a TPI time yet [22:39:08] haha [22:39:21] rendezvous expert writes memo. FIDO has graphs from memo in the MOCR. rendezvous expert can't find the memo. Rendezvous expert goes to MOCR to get the graphs and make himself a copy. [22:39:23] professionals [22:41:37] it's graphs for the anytime liftoff. I don't think I have successfully done a dwell maneuver yet. [22:42:00] one of those highly unlikely rescue cases [22:52:42] What would be the best way to recompute Apollo 8's lunar REFSMMAT once already in lunar orbit [22:54:24] And post LOI2 [23:00:35] LVLH REFSMMAT [23:01:04] time doesn't really matter, but could be LOI-2 TIG even after LOI-2 happened [23:03:05] btw does the MCC downlink the current REFSMMAT stored in CMC/LGC for every maneuver not associated with a REFSMMAT change? [23:05:28] mostly, yes [23:05:51] I've started to implement some cases where it checks on the REFSMMAT stored in the RTCC [23:06:01] the CUR (current) REFSMMAT [23:06:05] right [23:06:20] but of course that depends on the REFSMMAT not being changed in the AGC, so that can be problematic [23:06:56] but only really in cases where e.g. you are supposed to change the REFSMMAT with P52 option 1 but fail to do so [23:09:20] I think in reality they updated the RTCC REFSMMAT with a downlinked one whenever they changef the REFSMMAT in the AGC [23:09:36] but our MCC isn't really that flexible [23:14:09] night! [00:32:59] what causes "failed to create vertex buffer" in the orbiter log? [00:34:31] Also, AlexB_88 when you download the orbiter beta, does that come with texture files or do you have to port them from Orbiter stable [00:34:56] I recall having to copy textures over [00:55:32] yeah you have to either copy or link them from another installation [00:56:19] no idea about the first question though [00:57:25] I think that might need to be clarified in the install instructions especially people just getting the beta for the first time [00:57:45] I have had 2 now who didnt have the stable orbiter textures [00:58:29] well it does say it in step 2 [00:59:11] with a note that instead you may link them from existing installation [01:00:14] Right but it doesnt give you any direction if you do not have one [01:00:53] Either way I have had 2 people installing run into missing textures due to that so clarity might be necessary [01:01:52] just to confirm, you mean the planet texture right? [01:04:04] "Right but it doesnt give you any direction if you do not have one" I do not understand what you mean by that, have one what? [01:14:39] The texture folders you need to copy from the base install to the beta [01:14:55] if someone doesnt have the base install and only installs the beta, they dont have them [01:15:13] And if you do not have a orbiter 16 non beta install [01:15:33] Trying to troubleshoot the install in discord right now haha so thats where I am seeing some of this [01:16:55] right [01:18:43] but if you only have the beta, then following step 2 of the install guide, you should have the textures [01:19:02] unless there are other textures I am not thinking of [01:19:29] step 2 directs you to the download page for the earth/moon high res textures [01:20:54] are the high res textures optional [01:21:04] he skipped those [01:21:29] no [01:21:39] not if you are not linking from another installation [01:21:41] Ahhh thats why [01:22:07] he copied the textures this time from a regular orbiter install [01:22:11] still getting the errors [01:22:58] https://www.dropbox.com/s/r96oolznpkevgon/Orbiter.log?dl=0 [01:23:02] Have you ever seen those? [01:23:31] no [01:24:13] could not having the high res textures be a culprit? [01:27:03] not too sure, but he is using a separate beta installation with only NASSP in it right? [01:28:35] im thinking if he copied over the netire texture folder from stable, he might of over-written some Orbiter Beta textures [01:28:57] entire* [01:29:08] yes [01:29:22] maybe at this point its best to revert to the original texture folder from beta [01:29:26] he copied those first then put everything else on top of it [01:29:45] that was the state when he first got these [01:30:04] I think they could be the microtextures...since its the last thing loaded before errors...worth a shot [01:36:45] theres 152 seconds between the microtexture load and that error though [01:37:17] that looks like it crashed during the simulation not at load [01:42:23] it did it crashes a few minutes in [01:42:45] But I am just spitting into the wind at this poing [01:42:53] Based on this https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-261235 [01:42:55] rcflyinghokie, I feel like he is copied texture folder from stable, but this is not needed at all [01:43:03] seems like out of memory [01:43:19] you dont need anything from stable for NASSP [01:43:36] AlexB_88 yes he did but that was my first suggestion after this started happening [01:43:46] unless you want to link the textures, but as far as I understand, this is not he case for him [01:44:00] this happened with and without copying textures from stable [01:44:44] oh yeah. out of memory [01:45:08] very weird [01:47:24] trying to drop settings now [01:47:36] but I dont have much experience with AMD GPUs [01:48:59] my limited experience from using them circa 2009 was: weird and impossible to resolve errors [01:50:25] although the potato I have in my work computer runs Solidworks at 5670x1080 fine so... no idea [01:51:04] yeah I am baffled [01:51:08] All I have is the log haha [01:52:06] dropped a bunch of settings to default [01:52:10] see what happens [01:54:56] looks like it works [01:55:08] removed microtextures and dropped setting [01:56:24] video memory gremlins. gotta be. [01:59:15] haha yeah [01:59:31] At least it isnt NASSP related [01:59:39] Thanks Alex for helping! [01:59:55] I was just grasping at straws lol [02:14:39] no problem [02:23:39] the textures situation is indeed a mess as it is now with NASSP and the beta [14:38:31] hey Nik [14:46:04] hey [14:46:24] Thymo, have you completely disabled all direct pushes to the Orbiter2016 branch? [14:49:56] I wasn't really ok with that. It just makes small fixes and updates more annoying. [14:51:10] I don't want to create branches just for changing one number. [14:51:33] ah, I guess I can push to indy91/Orbiter2016, PR and merge myself [14:55:39] but I now have one bugfix with one number changed and a small RTCC MFD update. Two unrelated changes. Am I supposed to make separate PRs for these or what is the envisioned process. [14:56:50] If I put unrelated changes in one PR it's not any more organized than just commit directly. [14:57:11] I would agree with that [14:58:21] maybe 2 seperate PRs. I think this is why Thymo wanted to overhaul the autobuild process [15:00:43] If it's just very minor fixes its completely fine by me if you aggregate them. If you don't want to switch branches left and right you can also create your own personal "work" branch (in orbiternassp or your fork). Doing that the only change in your workflow would be to create a PR to merge it back into Orbiter2016. [15:02:25] The point of doing this is to ensure everything that gets released gets atleast a second pair of eyes (regardless of size), reduces the amount of trivial (borderline useless to users) updates that get published and indeed also allows tracking of what is being added as mentioned earlier. [15:03:27] the second pair of eyes makes sense, even if it's just a simple fix [15:04:27] "reduces the amount of trivial (borderline useless to users) updates that get published" I don't understand this part. Do you mean it reduces the number of builds being produced? How? [15:04:57] When I do the overhaul I intend to make some division in releases so people will have more insight in what they are running and also allowing us to have some expectations about peoples setup. When NASSP 8 is released it will go into the master branch as the defacto stable version (as is/was intended for 7). Then above that can be a beta/release candidate branch. That branch will be more ... [15:05:22] ... bleeding edge to get features out quicker to let people test while also guaranteeing some sort of stability. [15:07:00] Above all that is the main "develop" branch which is what we'll actively work on (through PRs). This is the most up to date one can get but it will also mean that if you have an issue with it you are expected to know what you are doing to get it fixed or make a useful bug report. The develop branch should only be used if you intend to write code for NASSP. [15:09:45] With these different builds it would for once make sense to call something "beta" as then it would only contain stuff that we are somewhat confident in has been tested to a certain extend but still aren't confident enough it should be marked "stable". [15:11:23] Matt's specific heat model would be an excellent example for this. We're pretty sure it works, but would like to give it some more time before releasing it to the masses. So you would ship it in the beta and hold it there for a while until you are confident it is working as intended. [15:15:27] So the idea is to have this development model after NASSP 8? [15:15:38] we need to rethink our strategy for NASSP 8 in general. I don't think martins is doing any more Orbiter releases, or is he? [15:15:48] But we can't rely on Open Orbiter yet [15:16:25] I wish he was at least publishing a last Orbiter freeware release. Then we could actually push for releasing NASSP 8 with an acceptable installation process [15:17:34] I think NASSP 8 would be a good switchover point, yes. [15:19:18] I honestly think Martin isn't really interested in maintaining Orbiter anymore. AFAIK Doug Beachy has administrative access to everything and would be the next person to go to. It might be a good idea to have a discussion with him about OpenOrbiter going forward and who's going to be the head of responsibility ther. [15:19:51] Right now its just a whole lot of wild discussion about things to add without a clear path laid out for the future. [15:20:09] yep [15:20:35] I hope we won't have to start using a branched off version of Open Orbiter [15:21:14] as appealing as that may sound with useful features for NASSP, it puts the burden on us to also maintain a version of the simulator itself [15:21:27] https://github.com/orbitersim [15:21:50] It looks like Martin isn't even in the Orbitersim organization anymore, likely meaning he no longer has push access to that repo [15:25:08] hmm [15:28:31] So there is definitely the possibility that he won't ever do anything with Orbiter again [15:28:40] but what about the website... [15:34:54] In the worst case you can make a new one. People tend to call the relicensed version OpenOrbiter anyway. So the "old" Orbiter is already one foot out the door. [15:36:33] maybe we should just accept that there might not be a proper last release of Orbiter and start thinking about release NASSP 8 for the last Orbiter Beta [15:36:44] and then start thinking about moving to Open Orbiter [15:36:56] if there is a last Orbiter release, all the better. [15:37:10] it's probably going to be compatible with the last Orbiter Beta [15:37:27] Stuff like this happens all the time. OpenOffice to LibreOffice, OpenSSL to LibreSSL, Ubuntu from Debian. Maybe now OpenOrbiter from Orbiter. [15:37:45] If Martin ever shows up and releases it on the current Orbiter site I assumu it would be compatible [15:38:27] I think he had some changes even in the version he put in Github [15:38:37] haven't tried building it though [15:38:55] even from Orbiter 2016 to Orbiter Beta there are some minimal API changes only [15:39:09] No one is being stopped from making a "release". In the end, all that means is someone compiling it, put it in a zip and upload it with the appropriate PR. There you go, new release. [15:40:32] ok, but is that possible right now and will it run with NASSP [15:42:11] Eh, probably? I haven't actually tested it myself. I was able to build Orbiter but haven't managed to get sound working. That's just an issue with my setup though as others can use it just fine. [15:46:26] hey [15:47:25] hey Alex [15:47:38] has anyone compiled a Open Orbiter release package yet? [15:48:22] I tried but haven't been able to get the D3D9client branch to build [15:55:49] Thymo, I'm fine with keeping the Orbiter2016 branch locked for direct pushes, although I would have preferred to knowing about that change. Maybe I misunderstood, but I thought we were just going to try and make an effort to make PRs and not prohibit any other way of merging things. I'm not really convinced by any of your other arguments, but having a second person look at every change makes sense. [15:57:58] and as an admin I guess I can still push an important fix really quick even if nobody else is around, right? I just need to review my own PR or force it to merge the PR or so. [16:05:16] indy91, my P32 PAD has a DVx of 162 ft/s [16:06:43] what are you flying again? [16:07:03] https://www.dropbox.com/s/1izbazs21f7zkl3/Apollo%2011%20MCC%20-%20Ascent%20PADs.scn?dl=0 [16:07:07] Apollo 11 MCC [16:07:28] that scenario is just before the Ascent PAD and P32 PAD [16:07:38] the Ascent PAD itself looks fine [16:08:14] You and I have the same permissions within the organization so in case of a catastrophic emergency it could be overridden. Are you referring to my proposed release model as the argument you're not conviced about? The point of that model is to separate the minor changes from the major changes so you can release more frequently instead of having NASSP X every couple years. [16:08:54] morning all [16:10:03] morning! [16:11:11] Loved the platform discussion I missed last night :) Always enjoy people asking those in depth questions [16:12:34] hey guys [16:16:01] AlexB_88, lol, I think that is one ft/s conversion too many [16:16:13] so just a display error [16:16:33] so should be a simple fix [16:17:17] ah [16:17:30] Thymo, the release model makes sense. I was only having a problem with disabling direct pushes. [16:17:54] Lately I have been doing more of the larger projects, but it used to be very often that I was fixing many small things in a day. [16:18:54] And I was the only one doing that sort of changes, so having to do PRs for every single one of them just adds to the workload with very little benefit [16:20:48] AlexB_88, confirmed. For the T2 CSI PAD I was doing this [16:20:49] calcParams.DVSTORE1 = _V(PZLRPT.data[1].DVCSI*0.3048, 0, 0); [16:20:59] for the actual ascent [16:21:00] calcParams.DVSTORE1 = _V(PZLRPT.data[1].DVCSI, 0, 0); [16:21:09] been a bug since June [16:21:15] my two cents -- I would agree with disabling direct pushes if this was a business or professional -- but since this is a hobby project for all of us I think added on more process will just make things take longer and be less fun [16:21:44] to be fair, this mostly affects me (and occasionally Thymo). Everyone else already had to do PRs [16:23:36] gotcha [16:26:07] oh great :D [16:26:16] didn't we already have the functional schematics [16:26:35] ah later revision [16:26:37] we had K [16:26:41] this is H? [16:27:14] and good thing that the first document says SL-1, I already started counting in my head to figure out which mission SA-513 was :D [16:27:26] hahaha [16:27:42] yeah, this is an earlier and less accurate version of the functional schematics [16:27:54] but it's still interesting for comparison :) [16:29:30] indeed [16:29:57] AlexB_88, in June I implemented the new LLWP for the MCC, that's when this bug started [16:30:25] it takes the CSI DV from the table storing the number for the rendezvous planning display [16:30:31] but there it's already converted to ft/s [16:30:49] and then the function calculating the CSI PAD also convert m/s to ft/s for display [16:30:55] random question (wrt a forum post) isnt there a few limitations on how to pick star pairs? as far as their angles and such? [16:31:26] Trying to figure out if he is getting bad angles from his pair selections or if its user error [16:32:55] indy91, so in the mean time I can make calcParams.DVSTORE1 identical to the T2 case? [16:33:11] I just did that but the DV is still 160... [16:33:29] oh right [16:33:40] this scenario is already past the LLWP calculation [16:34:14] MCC calculates the launch time earlier [16:34:19] not together with the ascent maneuver [16:34:29] so that number is already stored incorrectly in that scenario [16:34:44] ok [16:35:05] so its really just that number thats wrongly displayed, not anything deeper? [16:35:13] but yeah if you make it like the T3 case with the added *0.3048 it will store it correctly [16:35:14] If so I can ignore it I guess [16:35:15] DVSTORE1 [16:35:41] yeah, it's just a meters per second number converted to feet per second twice [16:35:46] it's not very elegant [16:36:10] gets calculated in m/s, stored for rendezvous planning display in ft/s [16:36:14] I know its normally around 50 ft/s so I;ll hust keep that in mind [16:36:20] just* [16:36:34] MCC takes number from table and has to convert it back to m/s [16:36:45] and then CSI PAD calculation convert is to ft/s for CSI PAD display... [16:37:02] If P32 onboard comes up with 162 ft/s then you'll here from me again :D [16:37:11] haha [16:37:25] 162*0.3048 = 49.5 ft/s [16:37:29] .4* [16:37:46] that's what it actually should say [16:38:29] right [16:38:37] the CSI PAD calculation does actually think it's 162 ft/s, but it doesn't make a difference for the other numbers it has I think [16:41:08] man I might have to revise the LM touchdown points [16:41:25] if I load this scenario it does weird things [16:41:31] the "drifting" it sometimes does seems to be worse [16:41:49] even weirder is, I get 4 red flags on the TCA [16:41:54] and clickspots are messed up? [16:42:00] oh I have ggalfi's landing site [16:42:02] have to switch VC positions [16:42:27] if you don't have it then it probably jumps to the default terrain [16:42:28] right the landing site would explain that it has to find a new position to settle [16:42:39] oh and the clcikspots is due to the Orbiter bug [16:42:50] ah true [16:43:24] rcflyinghokie, I don't think there is anything that prevents it from working. But you shouldn't choose two stars that are too close to each other, makes it less accurate [16:44:39] PICAPAR will select two stars that are at least 50° apart [16:45:44] Yeah thats what i recall remembering, I am thinking it has to be user error somewhere with his P51 [16:45:54] I tried all of his star pairs with good results [16:53:26] Now looking at the ORDEAL situation, I have a retrograde DAP orb rate procedure there, but looks like the spacecraft is prograde using the pad attitude [16:53:44] Trying to figure out if that is correct here [16:54:01] The last SPS burn and associated REFSMMAT was a retrograde burn [17:10:24] yeah that is weird, no idea how they solved that on the actual mission [17:12:57] unless they uplinked a REFSMMAT that rolled the attitude by 180° [17:13:14] but the flight plan definitely has no uplink [17:15:30] Yeah thats why I am going back and looking to see why I have a retrograde DAP orb rate there [17:15:52] I want to see, based on that REFSMMAT, where I am with respect to the SO65 time [17:16:11] aside from the orb rate, the ORDEAL doesn't work at all with a REFSMMAT like that [17:16:17] it rotates the wrong way [17:35:31] 9 didnt uplink a REFSMMAT for SPS 6 IIRC (at least not per the flight plan) they used an onboard P30 REFSMMAT [17:35:59] So based on the target load they used what the CMC spit out [17:37:26] and the flight plan also has the ORDEAL after that [17:37:32] which can't be correct [17:39:44] After what [17:41:32] after SPS-6 [17:42:46] Yeah I see that [17:43:26] where is the secret switch on the ORDEAL to make it rotate the FDAI in the other direction? :D [17:43:34] But even holding orb rate, using the SPS 6 REFSMMAT, the ORDEAL would continue to turn, correct? [17:44:09] Or is that what the retrograde DAP orbital rate is supposed to counteract [17:45:31] yeah that could be, not quite sure right now. But with the way the IMU is aligned you might have to do orb rate backwards [17:45:48] but you can't with the ORDEAL, so it just rotates in the wrong direction [17:45:55] That makes sense [17:46:00] it can only turn it one way [17:46:18] So while the DAP is holding the correct orbital rate, the ORDEAL would rotate away from it [17:47:13] yeah [17:47:31] I remember a long time ago when we didn't have a way to calculate the Apollo 8 LOI-2 REFSMMAT yet [17:47:46] we just did P30, P40, P52 option 1 [17:47:59] and then the ORDEAL is messed up [17:48:10] same issue, retrograde burn alignment [17:50:21] so thats probably what he is talking about with the ORDEAL not working "properly" in the forum post [17:51:11] yeah [17:51:27] which, when following the flight plan fully, would happen the same way [17:52:00] I had read transcript, mission report and debriefing etc. but didn't find anything about it [17:52:07] but there has to be something [17:52:56] Yeah I havent found anything yet [17:53:35] what GET is that again? [17:54:44] oh wait a moment [17:55:33] about 125h [17:55:36] post SPS 6 [17:55:47] hmm [17:56:11] I am doing the first SO65 post SPS6 [17:56:18] I am flying prograde heads down [17:56:31] based on the SO65 pad [17:57:55] 124:07:21 Scott: Okay. I guess we have some question about the platform alignment, too, since we have aligned retrograde. The uprate technique with the DAP works real well; it just looked like we were going the wrong way. [Pause.] [17:58:12] 124:07:35 Roosa: Roger. Copy. And GNC here has a lot of good words to say about that. Sounds like you are absolutely right. [Pause.] [17:58:19] 124:07:54 Roosa: Roger. It looks like we went V cross R instead of R cross V. [Pause.] [17:59:08] 124:08:53 Scott: Okay; thank you. You might also have the orbit rate angle, too, because we could monitor that on the ORB RATE ball. [Pause] [17:59:26]