Meadville Space Center

Project Apollo - NASSP => Project Apollo - NASSP Development => Topic started by: indy91 on July 26, 2017, 09:59:16 AM



Title: Virtual AGS Development
Post by: indy91 on July 26, 2017, 09:59:16 AM
The first step for running the AGS emulator is now done. When set to operate the AEA is doing computer cycles. Also implemented are a few basic input/output functions. Single input and output bits can be send back and forth. So if the software would command the engine on/off, then that would already work.

The first real step for using the AGS of course has to be getting the DEDA interaction with the AEA working. We already have a DEDA that can display numbers, show an operator error and so on. As opposed to the DSKY, the DEDA has a certain amount of intelligence. Setting or resetting the operator error light is determined in the DEDA itself and not in the AEA software, as it works in the AGC/DSKY. The standalone AGS emulator uses TCP/IP for communicating between AEA and DEDA. Unfortunately this means that we can't simply copy over the yaDEDA code and use it as the basis for our NASSP DEDA. I have attempted to get the DEDA /AEA communication working, with not much success so far. I will probably consult with the Virtual AGC/AGS developers and maybe they can help a bit. If someone else here is interested in attempting to get the DEDA and AEA to communicate, I would gladly give this task to someone else.

For now at least this initial commit only makes the AEA do the right amount of computer cycles per timestep and a few functions have been added to process some of the AEA output data.


Title: Re: Virtual AGS Development
Post by: indy91 on August 02, 2017, 08:56:44 AM
Another AGS update.

-The ASA is now sending out proper attitude pulses to the AEA. These are not terribly accurate yet, but at least for a short term the AEA now has good attitude data.
-The ASA state is saved and loaded.
-The AEA attitude and attitude error data sent to the FDAI have been fixed.
-AEA saving and loading has been fixed.
-The ATCA gets the AEA attitude error information, which get processed and used in the ATCA signal flow. This enables full AGS control of the Lunar Module. When the AEA is set to operate it immediately enters an attitude hold mode. So the AGS can now command atittude hold and the LM will always return to the initial attitude. Which is pretty impressive to watch. Not much else can be done with AGS attitude control though. You can move to another attitude with ACA commands and the AGS will control the LM returning to 0/0/0 attitude. That's it.


Title: Re: Virtual AGS Development
Post by: indy91 on August 04, 2017, 08:56:49 AM
The DEDA and AEA can now talk to each other!!!

This really opens the window for all the work that needs to be done to make the Virtual AGS operational in NASSP. As of now both reading data out of the AEA and entering data into the AEA are fully working.

I had to do a few modifications to the Virtual AGS for that. Or rather, I had to revert a few changes that were done to get AEA and DEDA to communicate in the standalone Virtual AGS. There yaAEA and yaDEDA are two separate program running concurrently and are communicating via TCP/IP. And to make that possible with the timing constraints of the AEA emulator a bunch of tricksery was done in the handling of input/ouput packages.

In NASSP these workarounds are not necessary. Our DEDA can react instantly to any request from the AEA. So I changed the Virtual AGS code back to the normal AEA/DEDA communcation, did a whole bunch of changes to our DEDA and now it all works! The real work on the AEA now begins.  :ROTFL3453:


Title: Re: Virtual AGS Development
Post by: indy91 on August 07, 2017, 05:20:19 AM
There have been a few more updates:

-The ASA accelerometers are implemented.
-Accuracy of ASA acceleration and attitude data has been improved. There doesn't seem much of a drift now.
-The RTCC MFD now has the ability to calculate AGS state vectors. You can find this as a third subpage on the State Vector page. Right now a manual state vector update is the only way to update the AGS state vectors. The automatic way to do this is using Verb 47 on the AGC. This puts the CSM and LM state vectors on a special downlink from the AGC, which gets intercepted by the AEA. This is not working yet in NASSP and seems fairly tricky to get to work.
-Fixed a bug concerning engine on/off signals from the AEA to the APS and DPS.
-The tape meter and cross pointer should now be able to display data from the AEA. Only the tapemeter is tested, the AEA doesn't seem to always send out data for the cross pointer.

With all these updates you can already use a lot of the AGS functions now. I even managed to fly a fairly successful orbital insertion from the landing site into orbit!! Control of the ascent stage was pretty bad though. I suspect there to be some problems in the ATCA though and not something with the AEA. The manual state vectors seem to be very healthy, but mysteriously some AEA addresses show wrong numbers. In my Apollo 17 test using Flight Program 8 the range to the CSM always showed 0, range rate also showed a value that didn't make sense. I will have to check the scaling factors and such. For the most part we actually don't need to figure out an AGS padload, because the Flight Program binaries already come with a lot of the erasable memory of the AEA filled with the correct numbers. But maybe there are one or two missing that are spacecraft specific.


Title: Re: Virtual AGS Development
Post by: macieksoft on August 08, 2017, 01:11:23 PM
So is the AGS working out of the box (has NASSP embedded VAGS?) or does it needs external VAGS application running and NASSP acts only as input/output?

Has anyone some LM saves with AGS working?

Is there any LM guidance and control manual that describes AGS?


Title: Re: Virtual AGS Development
Post by: abr35 on August 08, 2017, 01:25:45 PM
So is the AGS working out of the box (has NASSP embedded VAGS?) or does it needs external VAGS application running and NASSP acts only as input/output?

Has anyone some LM saves with AGS working?

Is there any LM guidance and control manual that describes AGS?

I've been able to use the AGS without any background applications and it saves under AEA in the scenario file. I've been using this to help me learn it:

https://www.hq.nasa.gov/alsj/LM_AGS_FP6_OperatingManual.pdf


Title: Re: Virtual AGS Development
Post by: indy91 on August 08, 2017, 01:41:50 PM
So is the AGS working out of the box (has NASSP embedded VAGS?) or does it needs external VAGS application running and NASSP acts only as input/output?

It's the same way as with the Virtual AGC. It's an emulator of the Abort Electronics Assembly, written by the same people who developed the emulator of the AGC. The emulator can run two versions of the AGS software, both of which are actually flown Apollo software. Flight Program 6, which was flown on Apollo 11 (and maybe one or two more missions) and Flight Program 8, likely for Apollo 15-17. The emulator runs in NASSP in the background, just like the Virtual AGC.

Quote
Has anyone some LM saves with AGS working?

The software binaries (the files that the AEA emulator runs) actually come preconfigured. For the AGC we have to figure out a lot of preflight numbers and load them into the computer as part of the launch scenarios. But with the AEA that isn't necessary. So if you had any older scenarios from before AGS activation then you can start from there with the AGS specific checklists. No need to modify old scenarios.

Remember though that we only just started experimenting with the AGS in NASSP. It can be a long time until it is as functional as the AGC in NASSP.


Title: Re: Virtual AGS Development
Post by: macieksoft on August 14, 2017, 05:06:04 AM
Does anyone have save prior to PDI with everything ready to go including AGC and AGS?


Title: Re: Virtual AGS Development
Post by: rcflyinghokie on August 14, 2017, 08:34:04 AM
Does anyone have save prior to PDI with everything ready to go including AGC and AGS?

Here is one PDI-3m.  AGS is aligned with SV is loaded and everything is ready for the burn.

EDIT:  Just realized this was my save for the PDI demo I am making for new users to play with.  Its all the same but the only difference is the LM is face up when for 11 it should have been face down, so don't yaw 180 degrees


Title: Re: Virtual AGS Development
Post by: lotisully86 on August 18, 2017, 08:25:12 PM
going thru lm activation for apollo 11 and im getting ctd during ags activation, specifically when moving the ags switch from standby to operate


Title: Re: Virtual AGS Development
Post by: indy91 on August 19, 2017, 04:07:11 AM
Something in the AEA section of your scenario is messed up. It has the line "FLIGHTPROGRAM 0". That means it doesn't properly load one of the AEA flight programs we have (6 and 8 ). But if I change this to 6 (which is the flight program Apollo 11 used) the simulation still comes to a stillstand, which I guess is the same behavior you are getting.

Did you fly this scenario from TLI to the Moon very recently? I found two bugs, one of them is probably responsible for your issue. It causes no flight program being loaded upon creation of the LM, which happens at sep from the S-IVB. That is now fixed. In your scenario you were just before activating the AEA for the first time it seems. So what you can simply do then is delete every line in your scenario between and including AEA_START and AEA_END. So that whole AEA memory section and the other variables. That will cause the whole AEA in NASSP to initialize from scratch instead of using some probably wrong numbers in the scenario. If I do that with your scenario then the AEA starts up without issues.


Title: Re: Virtual AGS Development
Post by: lotisully86 on August 19, 2017, 10:26:16 AM
Ya that' scenario is within the last couple days, that fix works thanks for the help


Title: Re: Virtual AGS Development
Post by: rcflyinghokie on October 13, 2017, 09:33:29 AM
Thanks to thewonderidiot's sleuthing through code and indy91's implementation/hooking up the code, we now have a fully functioning AGS!  I have successfully run FP6 through its paces in lunar orbit and it has performed every prescribed routine with flying colors.  I have also completed a few full insertion-rendezvous with AGS alone doing the work and I must say it is impressive how close it reads to the PGNS.

The only feature we lack is an PGNCS/AGS downlink so you still have to manually enter SV information but other than that our AGS is very much up and running!


Title: Re: Virtual AGS Development
Post by: eddievhfan1984 on October 18, 2017, 05:25:12 PM
There's a dedicated parallel I/O line between the PGNCS and AGS, right? Or is it serial?


Title: Re: Virtual AGS Development
Post by: thewonderidiot on October 19, 2017, 04:15:19 PM
It's serial -- it's an identical copy of the downlink data line to the PCM. The PCM also sends the downlink start, downlink end, and downlink clock signals that drive the AGC's downlink circuitry to the AGS. The AEA is effectively a passive listener on the AGC's downlink channel; it detects when the AGC has special downlist selected and initializes itself based off of that telemetry.


Title: Re: Virtual AGS Development
Post by: eddievhfan1984 on October 19, 2017, 05:08:34 PM
So all it has to do is listen to the special data word that says "AGS update" and respond to the interrupt generated by that data word, right?


Title: Re: Virtual AGS Development
Post by: rcflyinghokie on October 21, 2017, 06:07:08 PM
Just wanted to share a few videos showcasing the AGS control of the LM :)

Lunar ascent under full AGS control: https://youtu.be/uI38vocs5zQ (https://youtu.be/uI38vocs5zQ)

Lunar APS abort just after P64: https://youtu.be/0q8e5vb-dBo (https://youtu.be/0q8e5vb-dBo)


Title: Re: Virtual AGS Development
Post by: thewonderidiot on October 22, 2017, 12:30:41 AM
So all it has to do is listen to the special data word that says "AGS update" and respond to the interrupt generated by that data word, right?

Yeah, pretty much. The AGS has an 18-bit input register that captures the first 18 bits of a 40-bit AGC downlink word. There's an additional discrete input for the Downlink End signal from the PCM, which sets a flip-flop. When the program detects that this input bit is set, it reads in the captured 18 bits. This read automatically clears the "end" flip-flop.

So in theory, all we need to do is read the downlink data out of the AGC, assemble the 18-bit word that the AGS is expecting and jam it into its input register, and then set a bit for it to know that it has data. I haven't looked, but aea_engine.c might need to be updated on the VirtualAGC side to automatically reset the end bit on input register read.


Title: Re: Virtual AGS Development
Post by: rcflyinghokie on October 22, 2017, 08:08:00 AM
Also FP8 has a separate downlink for RR updates using 18 bits so we need to be able to capture that downlink as well for FP8 missions.


Title: Re: Virtual AGS Development
Post by: indy91 on April 14, 2018, 11:35:58 AM
The last remaining big feature of the AGS has now been implemented, PGNS to AGS downlink. Previously AGS state vector updates had to be done all manually, typing the data into the DEDA. Now Verb 47 of the LGC can be used to send the LGC state vectors of CSM and LM to the AEA. Should be much more convenient.