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 :)
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.
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)
Wait for COMP ACTY lt to extinguish
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?
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.