Meadville Space Center
Welcome, Guest. Please login or register.
October 29, 2020, 08:47:59 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  Virtual AGS Development
« previous next »
Pages: [1] 2 Print
Author Topic: Virtual AGS Development  (Read 2541 times)
indy91
Hero Member
*****
Posts: 1316


View Profile
« 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.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #1 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.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #2 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.  ROTFL
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #3 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.
Logged
macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #4 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?
Logged

abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #5 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
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #6 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.
Logged
macieksoft
Full Member
***
Posts: 80

RSO we are go we wanna blow!


View Profile
« Reply #7 on: August 14, 2017, 05:06:04 AM »

Does anyone have save prior to PDI with everything ready to go including AGC and AGS?
Logged

rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #8 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

* Apollo 11 MCC - PDI -3m.scn (220.29 KB - downloaded 81 times.)
« Last Edit: August 14, 2017, 08:56:44 AM by rcflyinghokie » Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #9 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

Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #10 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.
« Last Edit: August 19, 2017, 04:22:03 AM by indy91 » Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #11 on: August 19, 2017, 10:26:16 AM »

Ya that' scenario is within the last couple days, that fix works thanks for the help
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #12 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!
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #13 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?
Logged
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #14 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.
Logged
Pages: [1] 2 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!