Search results

We honestly haven't figured out what this one is! We have many theories but have yet to pinpoint it. You can safely skip for now of course. This is totally normal behavior from the AGS from my experience with liftoff. There will be slight divergence especially since you are on the surface and...

Good to hear! I need to investigate that a bit more. And its not that "450" didnt converge, but it pulls a DVX value from your TPI targeting if I am not mistaken, so if 371 was +60000 then that got transferred to to your dV values as well. Also I was reading the FP6 manual again, I am assuming...

Ah I see what you are saying. That is interesting as it has you load them there but says not to in the FP6 manual. It could be an order of operations thing or loading CSM or MCC values since you are computing a burn update. In any case that shouldn't impact what you were doing. The root of your...

Happy you are enjoying it! There are endless possibilities as you are sort of seeing (being able to fly a mission using just the actual flight plans etc) I do encourage you to try other missions as well. 16 is fun if you simulate the aborted PDI and subsequent time recomputations :) Also doing...

Check DEDA 371, if its the same as your 450 value then you have not converged on a valid solution. (FP6 manual 25-5) Also, you shouldn't be using/modifying 450-452 for any of the rendezvous burns targeted in AGS, those are only for inputting external values such as those generated by the PGNS...

I think this explains all of the issues you are having. This low framerate is likely causing the issues with the downlink as well as that difference in k-factor . May I ask what you are running orbiter/NASSP on specification wise?

Hmm you should be getting a k factor of like 100:00:00.62 =/- 0.01s. Assuming you are starting from he same save I was, that difference concerns me. Unless you are getting it from a different save. The k factor depends on slight human error in entering DEDA time. So if that number is from a...

Here is your last save after I update the SV's. See if you get the same results with 317 and 440 as you did before. Also I am uploading a video of how I got to this state from your posted save, maybe you can identify something you missed? I will post the link and it should be viewable in about...

Yeah continuously replacing files wont remove any rendered old or obsolete, but a clean install will remedy that. Those look totally normal. Are you entering P00 via V37E00E and waiting for the SV integration to complete before running a V47/414+10000?

Do you use git to install NASSP or do you download the build? The reason I ask is if you "paste" in new builds, old/obsolete files arent removed and could potentially cause problems. I cant think of anything that would cause your AEA issues but its worth a shot to think about.

I dont think it would break any old saves. I dont think it would, but you can of course try. I really am at a loss as to why your AEA is getting bad SVs

Hmm if you are using that save and doing exactly what I laid out there, then perhaps the problem is elsewhere. I get consistently good results on your save and the procedure I posted. It's almost like you aren't getting a good downlink to your AGS for some reason. Which version of NASSP are you...

From that save try the following: Uplink time tagged CSM SV Uplink present time LM SV (make sure the uplink page says present GET) V37E00E Wait for COMP ACTY lt to extinguish V47E DEDA 414+10000E 414R PRO Then once you get it uplinked and you have the F 50 16, PRO to clear the DSKY and then...

Just fired up this save and did time tagged CSM and present LM state vectors. N38 looked normal watching the time integration. Also my V83 matched my AGS once again after an AGS update. Are you doing a V47 immediately after the uplink or letting it go to P00 and finish integrating first? (I...

Nah you are correct to timestamp the CSM SV (display 21) with PDI -10m. I did the same and there is a delay on P00/V83 etc which is completely normal. DEDA outputs should be close but might not be spot on at that time.

I just did the uplinks, I can enter P00 right away and the V83 seems normal to me. Also my DEDA output addresses are all correct. All I did was a display 21 with Kitty Hawk as target at present GET and display 20 with Antares as target at present GET. Are you getting the issue with time...

I know the AGS works just fine for insertion, I will jump into that scn and check its configuration and such and compare to a fresh powerup and report back here.

Looks like they added this to the procedures for 14 based on results of unbalanced mixture ratios from previous SPS firing. 8-12 seemed to have a less than desirable mixture ratio at the end of the mission. For 15-17, the valves were actually redesigned to inherently correct for this, so like...

Ah good! Make sure you perform a descent update in the LM as well (this is also in the flight plan) to make sure your LGC knows this time is different than preplanned.

That landing time directs the TIG. And the landing time is computed when you computed DOI, so it's possible you burned DOI incorrectly or subsequently recalculated it using incorrect values changing the landing time. Feel free to post a scenario file here or jump in discord, we will see about...