Apollo 14: RTCC LM S.V. and CSM S.V. Update Procedure

[Wedge313]

Are you entering P00 via V37E00E and waiting for the SV integration to complete before running a V47/414+10000?

Yes, after the uplinks are complete I do V37E00E and wait for the COMP ACTY to go out before proceeding.

 

[rcflyinghokie]

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 5 minutes here.

EDIT: Video link

EDIT 2: Was doing some testing, you actually do not have to go to P00 and wait after the uplink to get a good PGNS downlink to the AGS, so that in itself saves a few minutes of time, but it is a good practice imo.

 

[Wedge313]

Great video! Everything you do looks familiar to me through the SV uplinks. I have not been using the RTCC to calculate the K factor. But mine is different, it's 100:00:00.16. Also, every time I hit the KFA button a slightly different K factor shows up, but it's always a small number.

I watched the video a few times, and followed along on my computer. I believe I'm copying all the steps your video shows. I'm incorporating the new K factor when I begin V47. But again after completing the process my V83 looks ok but my DEDA readouts are out to lunch.

I'll go through it a few more times. Also I haven't tried hitting my laptop with a hammer yet, that might help.

 

[rcflyinghokie]

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 different save then that fine but if its from the one you sent me its a concern.

What kind of framerates in orbiter are you seeing during this?

 

[Wedge313]

Thanks for the saved scenario, but I'm embarrassed to say I forget how to convert the .txt file to a .scn

EDIT: Disregard. Figured it out. Your save opened OK, my V83 values and DEDA 317R, 440R, and 277R values agree with each other with your .scn.

Now working with your scenario, here's a question: Let's close V83, clear the DEDA. Without updating anything, no SV uplinks, if I try to do an AGS Init again (V47, 414+1), what should happen? My V83 looks the same, but the DEDA 317R is -00001, 440R is +00000, and 277R is +33190. Also these values seemed fixed, they don't change. It looks as if the AGS thinks the CSM and LM are occupying the same space?

From this point I uplinked the LM SV (current time) and CSM SV (108:33:29). Waited for it to integrate. When I start V47 I used the AGS k factor of 100:00:00.61, although every time I hit the KFA button it gives me a slightly different value, 00.69, 00.65, 00.67, 00.62 etc but I stuck with 00.61. After the initialization is complete now my V83 again looks good but the AGS is still -00001, +00000, 227R +03446 but now while 317R and 440R are fixed the 277R value is changing, although the V83 value (+21261) and 277R value (+07204) are not close.

Could I have messed up something in the RTCC that prevents my PNGS and AGS to communicate correctly? I'm digging around and one display I'm questioning is the Liftoff Time Update (DIS 25, see attachment) Does this look correct?

Also, my frame rates sit around 11-13 fps.

 

[rcflyinghokie]

Also, my frame rates sit around 11-13 fps.

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?

 

[Wedge313]

May I ask what you are running orbiter/NASSP on specification wise?

Eureka! I think that was the problem.

I'm using an old Dell laptop that performance-wise leaves me yearning for my Commodore 64. It's a Dell 5555 with an AMD A4-7210 processor with integrated AMD Radeon R3 graphics. It's the only PC platform I still own, so the only computer I have that can run Orbiter/NASSP. I've complained in the past on this forum about it's poor performance, I'm just too lazy/cheap to invest in a better system, since the only thing I use it for is Orbiter/NASSP. To compensate for the poor performance I've used combinations of slower time acceleration (0.5x) or different views to improve the frame rate (staring at the CSM Panel 1 my frame rate is 9.8-10.5 at 1x. If I switch to an external view the frame rate will jump as high as 79-82). There are a few NASSP maneuvers (like re-entry) where I have to do this or the spacecraft becomes unstable.

But I hadn't associated the computer performance with my AGS issue until you asked the question.

So I went back to one of my saves (right after the landing radar checkout) and re-did the LM and CSM S.V. uplinks, began V47 with an updated K factor, DEDA 414+1E, then immediately after hitting PRO on the DSKY I jumped out to an external view (frame rate around 80) and waited a few minutes. When I popped back into the LM the initialization had completed.

And when I ran V83 and compared it to the AGS 317R, 440R and 277R values, they all looked good! 440R was within 0.2 fps of the V83 range rate.

Just to make sure this "solved" the issue I did it two more times, and they both worked. I think you figured it out.

Now I'm wondering if this has been the reason I've struggled with the AGS on all my previous flights too?

 

[indy91]

Ah yeah, it's a double unfortunate situation. With the AGS, when I first got the PGNS to AGS downlink working I had to implement a hack that buffers three "packages" of PGNS data for the AGS to process. Otherwise this wouldn't even work at 1.0x time acceleration at 60fps. But I guess with good framerates at 10x it already doesn't work anymore and with pretty bad framerates that you get it stops working at some point even at 1.0x. All as a result of certain timing requirements of PGNS to AGS communication that doesn't work if the length of one simulation step is too long, with PGNS and AGS computer cycles being simulated separately.

And with the panel, it's been frustrating ever since we switched to Orbiter 2016, that had a big performance impact on NASSP. I've looked a lot into improving the performance of the 2D panel, but it's a lot of work for very little gain. I have a branch on Github where I was working on reducing the number of bitmap redraws per timestep, as currently we even redraw e.g. every switch on every timestep, even if it doesn't get moved. Frame rate is quite random for me, at best the update improves it from 50 to 60 on average for me. If I find the motivation again I'll work some more on the branch

 

[Wedge313]

I'm not a computer guy (in case you haven't gleaned that) but if I understand what's going on in NASSP, you guys have taken the actual code that the CMC and LGC used, modeled the actual RTCC, and somehow figured a way to run it all on Windows. Then added all the systems simulations (which boggles me). And put together all the graphics and textures etc. and then come up with a way to incorporate it onto the Orbiter platform. Which I'm sure way over simplifies what's actually going on.

But I'm continuously amazed with NASSP. If my bottom-feeder laptop can run the simulation (with an occasional hiccup) at all, then the whole program must be constructed pretty well. If I had even an average computer this issue would never have cropped up.

It's been great using NASSP.

 

[rcflyinghokie]

I'm not a computer guy (in case you haven't gleaned that) but if I understand what's going on in NASSP, you guys have taken the actual code that the CMC and LGC used, modeled the actual RTCC, and somehow figured a way to run it all on Windows. Then added all the systems simulations (which boggles me). And put together all the graphics and textures etc. and then come up with a way to incorporate it onto the Orbiter platform. Which I'm sure way over simplifies what's actually going on.

But I'm continuously amazed with NASSP. If my bottom-feeder laptop can run the simulation (with an occasional hiccup) at all, then the whole program must be constructed pretty well. If I had even an average computer this issue would never have cropped up.

It's been great using NASSP.

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 AGS things and aborts, unusual contingency burns like DPS for TEI things of that nature all a blast and a challenge.