ggalfi
Well-known member
Hi all,
I've managed to simulate the Apollo 11 landing and events (prog alarms, etc.) fairly close to the original, real-life timeline. You can see the result in this video:
[ame="https://www.youtube.com/watch?v=QRBi-39jPyc"]https://www.youtube.com/watch?v=QRBi-39jPyc[/ame]
The next step in this story is to make my developments available for the community. The novelties you can see on this video could be grouped into three more-or-less independent sets:
And here is an appetizer (or maybe a de-appetizer) on what I changed to improve the accuracy of the simulation:
I've tested my version with many scenarios both involving CSM and LM (launch, reentry, SPS burns, P52, lunar ascent and landing) but haven't seen any problem with that.
The only significant disadvantage of the current version is the lack of multithreaded AGC capability. As the AGC is now more tightly integrated with the peripherals(IMU, Radars, Optics), these at least partially should be incorporated into the AGC's thread. I don't know how many people are relying on this feature, actually I've never used this multihtread option, so this is again something open for discussion.
I've managed to simulate the Apollo 11 landing and events (prog alarms, etc.) fairly close to the original, real-life timeline. You can see the result in this video:
[ame="https://www.youtube.com/watch?v=QRBi-39jPyc"]https://www.youtube.com/watch?v=QRBi-39jPyc[/ame]
The next step in this story is to make my developments available for the community. The novelties you can see on this video could be grouped into three more-or-less independent sets:
- High resolution texture and elevation maps for Tranquility Base (Apollo 11 landing site) based on LROC NAC imagery. Publication of this one is the simplest: a bunch of texture files, so could be zipped together and uploaded to some addon site. Another option to make it a part of NASSP (as it is historically strongly connected to Project Apollo). So the only question here is where should I upload it? I am open for any suggestion.
- To be able to see the elevation map in their full beauty I had to tweak the D3D9Client in a way that it uses floats instead of integers when doing elevation calculations. It is not related directly to my NASSP developments and even with the normal D3D9Client one will see improvement with the textures above, however it'd be needed if you want to see the same finely detailed terrain around Tranquility Base as on this video. After I finished with the publication of my NASSP developments I'll turn my attention on how to make my D3D9Client hack public. As I've done this circa in Nov 2019 and not looked after since, it could be even possible that the D3D9Client guys have already solved this issue.
- So the largest part of the development was the improvement which made the simulation more accurate. I've touched a lot of source files of NASSP and - as I began this development in January - I out of sync with the main (Orbiter2016) branch since then. I'm not sure how to proceed from here: either I can upload my changes to my own github page based on the 2020 Jan status of main branch and it could be merged with the current main version; or I can try to sew in my changes into the current version and that version could be merged into the current main branch. Sorry, I am not a git expert so maybe I'm using inaccurate terminology. Again I am open for any idea here.
And here is an appetizer (or maybe a de-appetizer) on what I changed to improve the accuracy of the simulation:
- CDU implementation based on the schematics and other detailed documentation. I haven't simulated every logical gate or transistor in the CDU (though the schematics are available), I rather focused on the parts which were involved in the 1201/1202 errors. I've also taken care of the correct nominal behaviour in the different modes (not only the usual A-D conversion, but the support for coarse aligning and the D-A output of CDUs like error needles, TVC in CSM and the velocity indicator in LM).
- As the coarse aligning now done through CDUs I reworked that in the IMU implementation. I haven't touched fine alignment as it is done outside of the CDUs.
- I've also changed the RR and CSM optics behaviour when under AGC control just to fit into this AGC-CDU-peripheral architecture. For optics I've used the mathematical models described in Apollo 15 Delco documentation.
- The PIPAs even in normal condition are giving significant load on the AGC through involuntary counter increments-decrements. So I've implemented that one and additionally I simulated the PIPA as a physical (pendulous) system. One positive side-effect of the new implementation, that the AGC is more accurately keeps up the state vector when DeltaV is small, e.g. when trimming after burns.
- Another significant load on AGC is the DPS thurst control: when LGC want to make it work in FTP (pedal-to-metal) mode, it continuously bombarding it with control pulses with ~2000pps and that comes with the same number of involuntary counter decrements as well.
- I also implemented the serial data transfer of LR and RR. It turned out that it doesn't make too much load on LGC (8pps during PDI), the now proper timing of radar interrupts makes the simulation one step closer to the real hardware.
- To make all the above to work I have to deeply rework the interface handling of the AGC emulator itself (agc_engince.c and agc_engince.h). I've added counter request logic according to the schematics and I've also implemented a simple scaler (the timer module of the real AGC) to let the computer beat the drum for the devices (CDU, PIPA, radars).
- Changed the DPS thrust function: there are inconsistencies in different documents (simulator data; actual scanned simulation outputs; Luminary source code; etc.) up to a few percent on the maximum thrust and erosion caused thrust increment. I tried to come up with a value as an "average" of the available data and also to fit the throttle down time to the historical value. Additionally I've improved the DPS dynamics with the famous 0.08 seconds lag as the overloaded computer caused heavy oscillations without that.
I've tested my version with many scenarios both involving CSM and LM (launch, reentry, SPS burns, P52, lunar ascent and landing) but haven't seen any problem with that.
The only significant disadvantage of the current version is the lack of multithreaded AGC capability. As the AGC is now more tightly integrated with the peripherals(IMU, Radars, Optics), these at least partially should be incorporated into the AGC's thread. I don't know how many people are relying on this feature, actually I've never used this multihtread option, so this is again something open for discussion.