Meadville Space Center

Project Apollo - NASSP => Programming => Topic started by: dseagrav on April 07, 2006, 06:49:31 AM



Title: LM status...
Post by: dseagrav on April 07, 2006, 06:49:31 AM
I have electricty and parts of RCS but nothing that fires yet. I'm still putting pieces of it together. Ideally I should have something that at least has descent power and usable RCS before the weekend's out.

Does the PanelSDK as it exists now actually use up batteries, or is their output constant?

Also, I noticed that DC busses wired to NULL still get 28 volts of DC from somewhere. Is that deliberate or did I screw something up?


Title: LM status...
Post by: movieman on April 07, 2006, 07:52:23 AM
Yeah, batteries slowly run down over time and their voltage depends on the current draw.

The DC bus thing may be a bug or an old hack put in to provide power before we'd wired up the fuel cells. It probably just needs to check whether anything is connected and return 0V if it's not.


Title: LM status...
Post by: dseagrav on April 09, 2006, 11:07:28 PM
Got further, but not as far as I wanted. I have a semi-working ECA and figured out how to deal with the high/low taps on the batteries without resorting to phantom batteries or other silliness. I'm missing the descent deadface relays and the CM power connection, and all of the monitoring stuff. I got RCS to fire but I screwed the axes up and didn't accomplish anything useful. So there's progress, but not as fast as I wanted. I'm starting to get a better handle on how the LM works though, which should help things along some.

For the EPS, I will need someone to make me images of a talkback indicator that shows barberpole, grey, and grey with the letters "LO". See page 340 (PG 2.5.3.4.1) of the LM AOH Volume 1 (15-June-1970 version). This is for showing the status of batteries.


Title: LM status...
Post by: dseagrav on April 12, 2006, 01:27:45 AM
I'm making a commit at this point but it's still really incomplete, the LM is not airworthy. The RCS currently has four times more thrusters than it actually should, only half of the EPS is present, and some. I just want to have a "checkpoint" of sorts. Consider the entire LM checked out editing for the moment.


Title: LM status...
Post by: Tschachim on April 13, 2006, 08:57:54 AM
Hi dseagrav,

Thanks for beginning with that!  :)  :)
Currently the LM doesn't build for me, it looks like a file is missing or some changes are not committed:
Quote
lempanel.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: void __thiscall LEMValveSwitch::Init(int,int,int,int,void *,class SwitchRow &,class sat5_lmpkd *,int,class IndicatorSwitch *)" (?Init@LEMValveSwitch@@QAEXHHHHPAXAAVSwitchRow@@P
AVsat5_lmpkd@@HPAVIndicatorSwitch@@@Z)
lempanel.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: void __thiscall LEMBatterySwitch::Init(int,int,int,int,void *,class SwitchRow &,class sat5_lmpkd *,class LEM_ECA *,int)" (?Init@LEMBatterySwitch@@QAEXHHHHPAXAAVSwitchRow@@PAVsa
t5_lmpkd@@PAVLEM_ECA@@H@Z)
Saturn5LM_parked.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: virtual bool __thiscall LEMBatterySwitch::SwitchTo(int)" (?SwitchTo@LEMBatterySwitch@@UAE_NH@Z)
Saturn5LM_parked.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: virtual bool __thiscall LEMBatterySwitch::CheckMouseClick(int,int,int)" (?CheckMouseClick@LEMBatterySwitch@@UAE_NHHH@Z)
Saturn5LM_parked.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: virtual bool __thiscall LEMValveSwitch::SwitchTo(int)" (?SwitchTo@LEMValveSwitch@@UAE_NH@Z)
Saturn5LM_parked.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: virtual bool __thiscall LEMValveSwitch::CheckMouseClick(int,int,int)" (?CheckMouseClick@LEMValveSwitch@@UAE_NHHH@Z)
Saturn5LM_parked.obj : error LNK2001: Nichtaufgeloestes externes Symbol "public: __thiscall LEMValveTalkback::LEMValveTalkback(void)" (??0LEMValveTalkback@@QAE@XZ)

... and a very small point: To fly a complete mission it is necessary to deploy the landing gear. I don't know how this was done in reality, with the last panel you had to toggle a single "landing gear switch". Perhaps you could take a look at that...

Cheers
Tschachim


Title: LM status...
Post by: dseagrav on April 13, 2006, 10:27:02 AM
I added a file "lemswitches.cpp" and associated lemswitches.h

Make sure you add it to your VS6 project. I'm certain I added it to the commit (but let me know if it's not there)

As of late last night I got the RCSes in the proper order, but in doing so I broke Orbiter's control of them. Orbiter wants the thrusters in groups according to axis, but it's difficult to do that with the LM thrusters because they get reused. So instead of that I'm going to complete enough of the GNC subsystem to get the ACA to work, then bind the keypad keys to ACA axes. (I want to do this with the CM later as well) The keymap stays the same between Orbiter and the ACA, so nobody should notice unless they start asking. The Orbiter prograde/retrograde/etc. autopilot is worthless with the LM anyway because of the engine being in the hover axis. The only thing I can see anyone actually using would be killrot, and the GNC should do that.  The only problem with this is once the appropriate channels work to allow RCS firing from the LGC, someone has to edit the LGC++ to fire thrusters from channels rather than whatever its doing now, which would need to happen anyway to allow for processing of direct/normal fire coil usage. It could use a DAP, too.

(Is it bad if I do things like this that create more work for the AGC++ maintainer? Who is that, anyway? I'm not trying to be hostile toward it, I just want to get as close to correct as I can get.)


Title: LM status...
Post by: movieman on April 13, 2006, 10:38:37 AM
LazyD handles the LEM autopilot. I think he fires the RCS himself anyway, but probably by using the Orbiter controls and not manually setting the output bits from the AGC.


Title: LM status...
Post by: Tschachim on April 13, 2006, 10:49:17 AM
Hi dseagrav,
Quote from: dseagrav
I added a file "lemswitches.cpp" and associated lemswitches.h.Make sure you add it to your VS6 project. I'm certain I added it to the commit (but let me know if it's not there)

Thanks, that does the trick, project file is committed!

Quote
Is it bad if I do things like this that create more work for the AGC++ maintainer? Who is that, anyway? I'm not trying to be hostile toward it, I just want to get as close to correct as I can get.

Well, the guy you're looking for is LazyD, a forum member, too, so I suggest to contact him because of this. If he cannot fix it, I fear you should do the necessary changes in the AGC++, just because you are the only one who is able to do this. :wink: Otherwise we would loose one of the best features in NASSP (in my opinion), which would be not very cool...

EDIT: Sorry movieman, you are too fast for me (once again :wink:)...

Cheers
Tschachim


Title: LM status...
Post by: movieman on April 13, 2006, 10:55:51 AM
To be honest, updating the RCS code shouldn't be terribly difficult, since the LEM RCS thrusters can easily be mapped to the roll/pitch/yaw axes. It's more time-consuming than complex, and we need to get it right so as not to screw up the autopilot.

Really we should do this anyway at some point, so we have the C++ AGC and Virtual AGC controlling the LEM with the same output channels. Adding generic RCSPitch(), RCSRoll() etc functions that fire the right thrusters would probably be the best solution.


Title: LM status...
Post by: dseagrav on April 13, 2006, 04:30:13 PM
Quote from: movieman
It's more time-consuming than complex, and we need to get it right so as not to screw up the autopilot.


Do you mean the Orbiter autopilot or the LGC/LGC++?


Title: LM status...
Post by: movieman on April 13, 2006, 05:43:20 PM
The C++ AGC autopilot.


Title: LM status...
Post by: dseagrav on April 13, 2006, 05:48:21 PM
Quote from: movieman
The C++ AGC autopilot.
Oh, OK. I don't plan to break it beyond repair. It'll just need to be changed so that it uses IO channels to fire the RCS, like it does for the CM right now.


Title: LM status...
Post by: Tschachim on April 14, 2006, 04:48:23 AM
Quote from: dseagrav
It'll just need to be changed so that it uses IO channels to fire the RCS

Can you do this?

Cheers
Tschachim


Title: LM status...
Post by: dseagrav on April 14, 2006, 07:42:24 AM
Probably.


Title: LM status...
Post by: Tschachim on April 14, 2006, 09:58:02 AM
That would be really great, thanks a lot!  :)
I apologize if I'm too annoying because of that point, but despite the fact it's perhaps easy to fix someone needs to do it and I really like the descent and ascent AGC++ autopilots and don't want to "lose" these features...

Cheers
Tschachim


Title: LM status...
Post by: dseagrav on April 14, 2006, 10:39:36 AM
It's OK. I just don't want to promise I can fix it because I haven't even looked at it, so I have no idea if it's too confusing for me or whatever. Except for the CM SCS I've never dealt with any sort of working autopilot before. None of mine ever worked properly.


Title: LM status...
Post by: LazyD on April 14, 2006, 06:19:45 PM
Hi dseagrav,

Currently, the AGC++ for anything I wrote for the Apollo CSM or LM controls attitude independently of anything dependent on the VAGC.  It basicly feels up the RCS torques and vessel PMI, and uses Orbiter API to control RCS thrust.  If the vessel RCS changes, it should be able to deal with it.

Currently, it's difficult for me to test the old AGC++ stuff I wrote last year.  Due to scenario format changes and who knows what else, none of my stuff seems to work any more.  I have gladly watched the progress of the CSM VAGC and figured the LM would soon be running Luminary, which is very cool, IMHO.  I'm happy to cooperate, but I think this project has moved beyond what I am able to do.

If you can bring the LM to life using the VAGC, I think that's fantastic!

D.


Title: LM status...
Post by: movieman on April 14, 2006, 07:03:38 PM
Quote
Currently, it's difficult for me to test the old AGC++ stuff I wrote last year. Due to scenario format changes and who knows what else, none of my stuff seems to work any more.


Hopefully these changes will pretty much fix the scenario format and allow us to get the LEM up and running with the control panel again before long.


Title: LM status...
Post by: dseagrav on April 17, 2006, 12:59:34 AM
LazyD, as nifty as running Luminary is, it still locks up on scenario loads semi-randomly and doesn't work above 10x time acceleration. We still need the AGC++ for awhile until those problems are solved. There's also a philosophical divide between the AGC++ and the AGC - The AGC++ is cheat-able and easier to manipulate for newbies, it uses "proper metric measurements instead of the ugly American measurements", and so on; It will take us quite awhile to get the AGC working reliably enough for the Average Joe, and even then it can never be made user-friendly; Only the AGC++ can do that.

Once I get the systems mess worked out the LM will be back to business as usual, and you can hack away. It's just being a pain in the butt in the meantime.

Speaking of, here's the latest scoop - I got the IMU alive and talking to the LGC, and I can start the LGC DAP and get it to fire jets. The RHC works and fires jets in the proper axes.  HOWEVER, someone installed the IMU sideways, or possibly backwards and sideways, so the computer gets very confused when it tries to navigate. I have to sort that out and get one of the FDAI alive, and then I should be able to call this working enough to let some other people share the fun.

Additional quirks that I haven't investigated yet include Luminary being very confused about something; It randomly falls over and dies, and requires a restart every so often. I think being "on" during the launch may have confused it. Most notably, even in P00, using V48 will mess up something such that V49 gets a OPR ERR lamp afterwards and requires a fresh-start to continue. Hopefully this is related to the IMU being wrong and will go away.

I don't plan to try fixing Luminary except as required to get the IMU, FDAI and RCS hardover working, so as to keep people who don't want to use vAGC from waiting on vAGC work.


Title: LM status...
Post by: movieman on April 17, 2006, 06:25:59 AM
Are you loading a sensible state vector?

If you go to the Virtual AGC site, other people seem to have Luminary running, so clearly it's possible to get it to work. We must have either screwed something up when wiring it into Orbiter or not loaded enough data to make it happy.


Title: LM status...
Post by: Tschachim on April 17, 2006, 01:11:54 PM
Quote from: dseagrav
HOWEVER, someone installed the IMU sideways, or possibly backwards and sideways, so the computer gets very confused when it tries to navigate. I have to sort that out.

The IMU assumes the CSM Orbiter and Apollo coordinates systems when calculating attitudes and probably this is wrong for the LM, so it looks like you should make the IMU configurable for both CSM and LM coordinates.

Cheers
Tschachim


Title: LM status...
Post by: Christophe on April 20, 2006, 05:03:44 PM
hi dseagrav, Movieman or everybody else
I've found this while surfing:
http://klabs.org/mapld04/papers/p/p202_portillo_p.pdf
Don't know if there is something useable for you


Title: LM status...
Post by: dseagrav on April 20, 2006, 05:25:44 PM
I found that earlier last week ^_^


Title: LM status...
Post by: Swatch on April 23, 2006, 11:36:19 PM
Quite a while ago, Moonwalker suggested I look into getting the vertical acceleration/velocity and, namely, the X-Pointer instruments working in the LEM...I did some more looking at it and I was having trouble determineing the best way it could be implemented in Orbiter.   (like Optics...I have ideas, but I'm working out the kinks)  I was wondering what the IMU was capable of...
What all values can I get out of it? (velocities? positions? accelerations? relative to what axis? etc...)


Title: LM status...
Post by: Swatch on April 24, 2006, 03:59:26 PM
I figured everything out....but I'm still interested in what the IMU is capable of for curiousity sake.

I got the X-Ptrs working on the Main Panel, and they've been commited....I hope that didn't mess with anything you're doing dseagrav.  Now I'm going to get to work on the Range Altitude, the T/W, and the Range Rate/Alt Rate meters


Title: LM status...
Post by: dseagrav on April 24, 2006, 04:19:10 PM
IMU provides attitude and velocity-change in three axes, and that's it. I don't think anything is connected to it other than the LGC and FDAI. The velocity data is definetely only available to the LGC because of how it works - via an integrating accelerometer the computer periodically resets. The AGS uses a different system entirely.

Oh, and if you want to do the voltmeters and such on the right panel, that would be grand.


Title: LM status...
Post by: dseagrav on April 25, 2006, 03:19:55 AM
I committed what I have - The IMU is alive and works, but the computer is still unhappy about something. Most likely it has a bizarre state vector. We need to come up with a way to do an alignment for the LM, or otherwise fake it. For the crazy types, The RHC works, but the computer generates way too high rate commands and ends up bell-ringing out of control (or just plain tumbling). I didn't bother wiring the translation controller until the LGC situation is sorted out and it can orient itself.

Someone else can look at the LGC while I finish out the descent ECS. It generates high rates for any maneuver and ends up tumbling pretty quickly.

Also, the IMU doesn't save state right now. I'll fix this unless someone beats me to it.


Title: LM Simulator
Post by: shotto on May 05, 2006, 03:39:59 AM
First I like to introduce myself.
Last year I did some hacking  :wink:  to create that TCL/TK based LM Simulator distributed with Ron Burkey's yaagc package http://www.ibiblio.org/apollo/index.html

Right now I'm stuck with the development because the DAP does not work correctly, even after providing the whole set of Apollo 13 launch pad values for the Luminary code base.
The DAP behavior is more or less an oscillation with increasing amplitude around the target attitude values. Because of your working CSM DAP, I would assume that yaagc is fine but probably an initialization value is missing.
As a pre condition IMU is aligned, the V48 initialization has been performed and even the V49 crew defined maneuver routine works with the above mentioned behavior.

It would be great if you can give me some hints why the DAP does not lock on the target attitude values even by simulating the correct moment of inertia.

Thanks in advance.


Title: LM status...
Post by: Tschachim on May 05, 2006, 05:32:00 AM
Hi Stephan,

nice to see you here at Meadville!  :)
I hope dseagrav can help you, he already did a lot of great stuff in the CSM.

Cheers
Tschachim


Title: LM status...
Post by: movieman on May 05, 2006, 06:24:59 AM
Quote
For the crazy types, The RHC works, but the computer generates way too high rate commands and ends up bell-ringing out of control (or just plain tumbling).


Are you sure the LEM RCS has the correct thrust? The CSM RCS was way overpowered before, so the LEM may be too.


Title: LM status...
Post by: dseagrav on May 07, 2006, 09:05:30 PM
Quote from: movieman
Are you sure the LEM RCS has the correct thrust? The CSM RCS was way overpowered before, so the LEM may be too.

Yes - I rechecked the ISP values. I assumed the CG was set wrong, but it's doing the exact thing that shotto is describing so it may be a LGC bug or something we're missing.
I have a lot of catching-up to do as apparently a new Orbiter version is out and I have to convert, reconcile my outstanding commits (or throw them away) and figure out where exactly I was because I forgot. It'll take me a little while to get back up to speed.


Title: LM status...
Post by: Swatch on May 07, 2006, 11:03:48 PM
I'm just working in 2005 until I get my current commits working and then once my current projects are done, I'll switch over.   So far, I'm pretty sure that everything is porting relatively nicely.  I'm sure that it'd be easier to finish what you start first.


Title: LM status...
Post by: shotto on May 08, 2006, 01:02:31 AM
Like dseagrav, I also checked things like thruster power or the rotational model which is in the case of the LM Simulator based on the calculation of the Moment of Inertia by using the same hyperbola equation as used by the AGC state estimator.

My current suspicion where the problem could be located is focused on the EDRUPT command. This is used once within the Luminary DAP routine but never used within Colossus. Furthermore, I've read in some older posts that there are problems with EDRUPT.

Does anybody know more about it?


Title: LEM panel progress
Post by: Vincent Majerowicz on May 26, 2006, 06:01:08 PM
Hi!,

I wanted to ask you, how is the LEM instrument panels coming along since the CVS is online again? :D


Title: LM status...
Post by: dseagrav on May 27, 2006, 11:34:22 PM
Quote from: shotto
Like dseagrav, I also checked things like thruster power or the rotational model which is in the case of the LM Simulator based on the calculation of the Moment of Inertia by using the same hyperbola equation as used by the AGC state estimator.


Question, did you perform a platform alignment before starting DAP? Maybe it's trying to compensate for gravity or something like that...


Title: LM status...
Post by: shotto on June 08, 2006, 12:07:26 AM
Quote from: dseagrav
Quote from: shotto

Question, did you perform a platform alignment before starting DAP? Maybe it's trying to compensate for gravity or something like that...


I did the whole procedure.
Nevertheless, by tracing the DAP routine of the Luminary code I found out that EDRUPT is called during each DAP cycle. That command does not exists in the Colossus code and appears merely one time in Luminary. After discussing this with Ron Burkey we found out that this is very likely the root cause for the problem. Unfortunately, there isn't much documentation around EDRUPT available. Probably for the reason that it has been implemented just on the demand of one LGC programmer.


Title: LM status...
Post by: dseagrav on June 08, 2006, 09:34:05 AM
Oh, so that's where the EDRUPT happens. I thought it was in one of the main loops, not DAP.

Well, the computer is deterministic, and EDRUPT has to be doing something, otherwise Ed would not have insisted on its presence. All other instructions are (mostly) known, so it stands to reason that if the EDRUPT is ignored, whatever isn't happening is what the EDRUPT is supposed to be doing. Therefore, make EDRUPT a no-op, observe what results, and then fix up EDRUPT so it does whatever is needed to make the DAP work.

Supposedly it works in the latest Virtual AGC, and I think we have the latest one. From the description it really does look like it's giving data to some external device; Maybe it's giving data to the AGS? I'll look through the LM diagrams and see if anything is wired to the LGC like that.

I don't suppose the Ed Smally is still alive and can be located?

Alternately, what is in location 0 when EDRUPT happens?


Title: LM status...
Post by: dseagrav on June 11, 2006, 04:28:47 AM
New commit, added descent ECA #2, made ECA low-voltage tap usage work, connected the LMP and CDR DC busses to the ECAs directly, and enabled the switches.


Title: Re: LM status...
Post by: mikaelanderlund on July 12, 2006, 04:01:19 AM
Any status report?

Mikael


Title: Re: LM status...
Post by: dseagrav on July 12, 2006, 08:10:32 AM
Unfortunately no - I lost my weekend to some family drama (sigh...) and I'm behind again. But I'm starting to get a good mental picture of how the LM fits together.

It might seem strange when you remember how fast I was able to get through working on the CM, but you have to remember I had basically done two years of research on how the CM worked. ^_^ The LM is a lot different.


Title: Re: LM status...
Post by: mikaelanderlund on July 12, 2006, 08:31:22 AM
Well, as we say in Sweden, better late than never  :D.

Mikael


Title: Re: LM status...
Post by: Tschachim on July 23, 2006, 11:13:40 AM
Hi dseagrav,

I don't know if it's too early for LM bug reports, but I did some tests of the LM landing autopilot (AGC++ P63) using the "Quickstart/Apollo 14/Apollo 14 - LM before powered descent" scenario.

At first I fueled all tanks by using Orbiter's scenario editor since the LM now has 2 RCS tanks. Then I powered up the LM using the 4 descent power high voltage switches on panel 14. After that's the bat feed tie, LGC and IMU circuit brakers on the left panel are popping out, I closed them again. The are popping out, too, if I save and load after power up.

I activated the RCS by switching the MAIN SOV SYS A and B switches to open. The corresponing talkbacks were already grey before but otherwise it's not working. Manual attitude control using Orbiter control seems to be fine after that.

Then I started P63, no errors, initial attitude seems to be fine (at least the DPS is directed against flight direction), the DPS burn starts normally. After that's the AGC++ begins to control the attitude, but wrongly with horrible results, I'm crashing into the moon at about the time the LM should begin to roll "face-up".

I think the electic problems are small bugs because of the work in progress, but I have no clue why the landing autopilot is not working, did you change the LM axes or something like this?

Cheers
Tschachim


Title: Re: LM status...
Post by: dseagrav on July 23, 2006, 02:32:13 PM
No, but we did change Orbiter versions...

Edit: Actually, wait, yes I did, I moved the RCS thrusters to where they should be instead of the "phantom" locations they originally had, just like I did with the CSM. That shouldn't change the axes, but would affect the moment...


Title: Re: LM status...
Post by: dseagrav on July 24, 2006, 01:56:06 AM
New LM commit.

* The AC busses, inverters, and associated breakers now exist.
* New battery config to more closely match voltage discharge curve. Calibrated against voltage and amperage at 25 amps single-battery load but the discharge RATE has not been verified yet. Should at least meet real spec, probably exceeds it. Won't know for sure until we fly with a flight power load.
* Popping CB bug fixed
* ECAs and inverters save and load state with scenario changes



Title: Re: LM status...
Post by: Tschachim on July 24, 2006, 05:01:01 AM
Cool, thanks :) , I'll try again!

Cheers
Tschachim


Title: Re: LM status...
Post by: NoName on July 24, 2006, 09:36:00 AM
Phantastic, dseagrav :)

Quote
The AC busses, inverters, and associated breakers now exist.

Does it mean that the circuit breaker switches are working again so I can continue to implement the still missing breakers on the side panels?


Title: Re: LM status...
Post by: dseagrav on July 24, 2006, 10:28:03 AM
Go nuts. Let me know what you want to do and I'll stay out of your way.


Title: Re: LM status...
Post by: Tschachim on July 24, 2006, 12:19:52 PM
Hi dseagrav,

thanks for looking at the FDAI power usage, but it's still wrong:

AC power of 3.3W was fine according to the AC power distribution matrix in the Systems Handbook (Danger Will Robinson :wink: : All current ratings are DC equivalent there!)

As you pointed out the DC power was way too high, I was reading the DC power distribution matrix wrongly :ashamed45523:. But according to the Apollo 15 G&C checklist, page 44 both FDAIs use 58W alltogether, so the DC power of one FDAI is 25.7W.

Do you want to change it (and agree with that... :)) or should I do?

Cheers
Tschachim


Title: Re: LM status...
Post by: BigDAS on July 24, 2006, 01:00:34 PM
Does this mean we can now land the LM with the SDKY Program 63?


Title: Re: LM status...
Post by: dseagrav on July 24, 2006, 02:00:16 PM
Tschachim: That sounds more sane. I didn't look up the DC usage because I was in a hurry to get out of Moonwalker's way, I just thought they might be backwards and reversed them. If you have an actual number by all means use that. I can make the change when I get home or you can do it if you can do it faster.

BigDAS: Probably not - You can try if you want though. At last report it loses control of the LM and crashes. Please report what you get. Don't forget to turn the electricity on! Both high-voltage taps will probably work for you.

Assuming it doesn't step on anyone's toes, the next bits of code will be the ascent/descent seperation of systems and the DC bus paralleling breakers, and maybe the DC meters if I can figure out how it works. That should give us a full EPS to build on. I figured everyone would be busy with the CSM and I'd have more time to work with! ^_^



Title: Re: LM status...
Post by: Tschachim on July 24, 2006, 02:25:43 PM
FDAI fix is committed!

... and I don't plan to do anything in the LM, except perhaps having a close look at the landing autopilot, but I fear we'll need LazyD to fix that...

Cheers
Tschachim


Title: Re: LM status...
Post by: dseagrav on July 24, 2006, 02:43:30 PM
I dunno, maybe I can have a whack at it if nobody else will. It shouldn't be too hard - as far as the code goes I guess it's basically like a more different SCS.


Title: Re: LM status...
Post by: BigDAS on July 24, 2006, 04:24:03 PM
The Apollo 14 base approach seems a bit more conginsant than the Apollo 11 PDI scenario. P63 held the retrograde attitude fine up Main Engine powerup, but it gained altitude and put the landing marker well behind the Fra Mauro base tick. At around 10 kliks from base, it began to go wild and crashed the LM.



Title: Re: LM status...
Post by: Tschachim on July 25, 2006, 08:36:21 AM
I think I know what's the problem is with the landing autopilot, but it looks like I don't know how to fix it:

At the beginning of P63 the LEMcomputer::Prog63 function orients the LM to the initial attitude by using the ApolloGuidance::OrientAxis function. This function does a lot of calculations and in the last line it sets the RCS thrust with the SetAttitudeRotLevel function. If you replace

Code:
OurVessel->SetAttitudeRotLevel(Level);

with

Code:
OurVessel->SetAttitudeRotLevel(Level);

VECTOR3 th;
OurVessel->GetAttitudeRotLevel(th);
sprintf(oapiDebugString(),"Level %f %f %f AttitudeRotLevel %f %f %f", Level.x, Level.y, Level.z, th.x, th.y, th.z);

and start P63 you'll notice that th.x is always 0 despite the fact that Level.x isn't 0, so basically the LM ignores pitch thruster settings (but not roll and yaw). Funny thing is that I can control pitch with the Orbiter controls and I have no clue why the pitch thruster level is ignored by the LM or set to 0 at another place.

I think I miss something completely obvious, but I don't find it...  :? :? :?

Cheers
Tschachim


Title: Re: LM status...
Post by: movieman on July 25, 2006, 09:02:40 AM
Shouldn't all that code be replaced with writes to the I/O channels like the Virtual AGC? If it's trying to fire the RCS at partial thrust they might need to be changed to pulsed thrust instead.


Title: Re: LM status...
Post by: dseagrav on July 25, 2006, 09:38:27 AM
I bet that's what's going on - The IO channel data is overwriting the values set by the AGC++.

Since the vAGC doesn't work you can just disable the IO channel code and I can fix it properly later when the actual thrust control chain exists.


Title: Re: LM status...
Post by: Tschachim on July 25, 2006, 12:07:08 PM
I figured it out, it's a nasty problem:

All pitch thrusters are also roll and yaw thrusters, so the roll and yaw thrust levels overwrite the pitch level. The roll and yaw thrusters are "decoupled" so they don't have that problem. Concluding SetAttitudeRotLevel is not working for the LM, the OrientAxis and ComAttitude functions need to be changed.

As you already mentioned obviously the best solution is to control the thrusters directly via the I/O channels, so it looks like we have to wait with lunar landings until that thrust control chain exist. Dseagrav, it's your turn again! :)

Ah, and I think both OrientAxis and ComAttitude are also used by the CSM AGC++ (LOI for instance) so it looks like OrientAxis and ComAttitude both should call a new virtual function of ApolloGuidance with different implementations in CSMComputer and LEMComputer...

Cheers
Tschachim



Title: Re: LM status...
Post by: dseagrav on July 25, 2006, 03:58:54 PM
Geh. Well, at least with the EPS done there is other things other people can do so I'm not such a bottleneck this time.


Title: Re: LM status...
Post by: BigDAS on July 25, 2006, 04:43:19 PM
Well, in the meantime, I'll practice my Manual Landings for emergency situations.


Title: Re: LM status...
Post by: Tschachim on July 26, 2006, 11:06:35 AM
Antares has landed!  :Excited432:

No, I didn't fix it correctly, no I/O channels, no pulsed thrusters, just a dirty hack: I add up the commanded thrust levels for each thruster manually to avoid the problem described above.

Hey dseagrav, don't worry, for me you aren't a bottleneck, these things just need a lot of time to do them correctly. Since the LM is landing again (and perhaps also ascending and doing rendezvous) you aren't "under such pressure" anymore. :)

Good thing is that we now can try the new Meshland version finally...

Cheers
Tschachim


Title: Re: LM status...
Post by: BigDAS on July 26, 2006, 11:32:01 AM
Hey, great work, T. Gonna try it out right now.


Title: Re: LM status...
Post by: Christophe on July 26, 2006, 12:04:14 PM
congratulations Tschachim!

Do you plan to be renamed as "Al Shepard" or "Ed Mitchell" ? :wink:


Title: Re: LM status...
Post by: Tschachim on July 26, 2006, 02:11:24 PM
Thanks for your kind words, Big Al, of course!  :cool7777:

Sorry dseagrav, one more dirty hack (but that's the last one): Since the RCS state isn't saved currently I enabled it (i.e. the Main SOVs) by default.

I also updated the "Apollo 14 - LM before powered descent" and "Apollo 14 - LM final approach" scenarios in the "Project Apollo - NASSP\Quickstart Missions\Apollo 14" folder.
...and yes, I'll make new beta modules soon... :wink:

Cheers
Tschachim


Title: Re: LM status...
Post by: BigDAS on July 26, 2006, 03:18:31 PM
I tried it and it seemed to go wild as before. I guess you haven't updated yet, although I did the LM Autoland coming down in the last one. Guess I'll wait for it.


Title: Re: LM status...
Post by: Tschachim on July 26, 2006, 03:28:42 PM
Yes, you need to compile the modules by yourself (using the free MS Visual C++ 2005 Express Edition for example) or wait for new beta modules.

Cheers
Tschachim


Title: Re: LM status...
Post by: BigDAS on July 26, 2006, 06:25:39 PM
Eccch, now I gotta learn C++. Oh well, it's about time I got into programming.


Title: Re: LM status...
Post by: Tschachim on July 27, 2006, 07:48:00 AM
No need to learn C++, you "just" need to install the compiler and configure a couple of options, Orbiterfan and MaxQ already built the modules successfully. I didn't write instructions for that (hopefully I'll do sometimes...), but if you want to give it a try I suggest to read this topic (you'd need to read the complete topic really precisely :wink:): http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=555.0

Cheers
Tschachim


Title: Re: LM status...
Post by: dseagrav on July 27, 2006, 10:13:20 AM
Well, I have webspace and so on, I suppose rather than confuse everyone with the compiler I could try to do a "daily build" kinda thing but people would have to understand that it would track live CVS and be very, very unuspported. I'll see if I can get a machine set up for it.


Title: Re: LM status...
Post by: BigDAS on July 27, 2006, 12:33:56 PM
I have Microsoft Visual C++ 2005 Express Edition installed. How would I configure that to build the modules?


Title: Re: LM status...
Post by: Swatch on July 27, 2006, 02:00:41 PM
crap...now that the LEM is goin again, guess I have to get started on it's new mesh sometime soon..... :cool7777:


Title: Re: LM status...
Post by: dseagrav on July 27, 2006, 03:03:45 PM
Well, I wouldn't quite say it's "going" again - It just sorta works. I'd much rather the CSM be finished before the LM anyway. It's kinda pointless to have a lot of work in on the LM when there's no CSM to get it to the moon. If I just wanted to play with an LM over and over again, I'd be happy with just Eagle Lander. ^_^



Title: Re: LM status...
Post by: Tschachim on July 27, 2006, 04:43:17 PM
Me, too. Because of this I'm working on the SPS again... :)


Title: Re: LM status...
Post by: movieman on July 27, 2006, 05:41:09 PM
Probably a good idea to post this in this thread too :) :

I've added a CSM->LEM power connector, but haven't really been able to test it much more than ensuring it doesn't crash on docking. Someone else will have to connect up the ends to the CSM and LEM power systems so the CSM can feed power to the LEM through it.

We probably need another one going the other way for the Apollo 13 mission, but I'm not sure how the wiring works.


Title: Re: LM status...
Post by: NoName on July 27, 2006, 05:42:51 PM
Quote
Me, too. Because of this I'm working on the SPS again...

With the SPS & RCS working (gauges, pressurization), the EMS working, the CSM would almost be finished for a first release of Project Apollo :wink:




  


Title: Re: LM status...
Post by: BigDAS on July 27, 2006, 06:18:16 PM
Okay, spent the last two hours reading threads, downloading and installing the MS SDK R2, reading instructions, updating files, and built the default Windows Test Application with C++, and I'm ready to rock and roll.
Now, as I understand it, it have to:
2. Edit the OrbiterAPI.h file.
3. Open ProjectApollo2005.sln and build.

Here goes...

Damn! Getting a Out of Date error for ASTP - Debug Win32


Title: Re: LM status...
Post by: BigDAS on July 27, 2006, 06:22:41 PM
Well, I wouldn't quite say it's "going" again - It just sorta works. I'd much rather the CSM be finished before the LM anyway. It's kinda pointless to have a lot of work in on the LM when there's no CSM to get it to the moon. If I just wanted to play with an LM over and over again, I'd be happy with just Eagle Lander. ^_^



I'd suggest sticking with the Lander. Inversely, there's no point in travelling thousands of kilometers only to become another crater in the Moon.
I've made several successful manual landings by overriding the DSKY, but it's nice to have automodes working.


Title: Re: LM status...
Post by: BigDAS on July 27, 2006, 08:53:58 PM
Decided to build the LEM.DLL by itself. Got a few debug errors, but it built okay. Seems to be corrupted, according to the post-launchpad debug message. Tried the Apollo 14 Historic mission Before Powered Descent scenario. Program 63 seemed to work this time, although I got some strange readings with the V06N16 phase. N63 read correctly.
All panel sounds okay except the Circuit Breaker clicks were missing, and the Panel 1 "8-Ball" was inactive (Off). Otherwise, the LM performed a perfect  automatic landing on Fra Mauro.
You might be interested to know that P63 also works with the Apollo 11 descent scenarios, and should work with all of the missions.




Title: Re: LM status...
Post by: Tschachim on July 28, 2006, 03:56:01 AM
Well, sounds great, but I don't understand what you mean with "Seems to be corrupted, according to the post-launchpad debug message."?

You also want to build the modules in release configuration, not debug:

"At the top, immediately under the menu bar, change the Configuration from Debug to Release and then choose Rebuild solution in the Build menu."

Cheers
Tschachim


Title: Re: LM status...
Post by: BigDAS on July 28, 2006, 05:33:42 AM
Well, sounds great, but I don't understand what you mean with "Seems to be corrupted, according to the post-launchpad debug message."?

You also want to build the modules in release configuration, not debug:

"At the top, immediately under the menu bar, change the Configuration from Debug to Release and then choose Rebuild solution in the Build menu."

Cheers
Tschachim

Thanks. I'll do that.
The error box pops up after exiting the scenario and comes from the C++ Debug Library. Error in LEM.dll, Runtime Check Failure #2 - Stack around the variable 'str' was corrupted.


Title: Re: LM status...
Post by: movieman on July 28, 2006, 05:38:12 AM
Yeah, I got that too. Also, I tried the scenario you mentioned and my LEM flew off into deep space... it fired the decent engine pointed towards the moon rather than along the orbit.


Title: Re: LM status...
Post by: Tschachim on July 28, 2006, 07:10:38 AM
The error box pops up after exiting the scenario and comes from the C++ Debug Library. Error in LEM.dll, Runtime Check Failure #2 - Stack around the variable 'str' was corrupted.

Thanks a lot for pointing that out, bugs like this can be very nasty!  :ThumbsUp432:
Fixed it.

Cheers
Tschachim


Title: Re: LM status...
Post by: BigDAS on July 28, 2006, 07:32:42 AM
Yeah, I got that too. Also, I tried the scenario you mentioned and my LEM flew off into deep space... it fired the decent engine pointed towards the moon rather than along the orbit.

Odd, it worked perfectly for me. I started P63 around 1.5K from the base. The LM kept it's 'Feet First' profile retrograde with no diversions. Did you activate all the nessessay functions? I find I somethimes have to reset the power switches then toggle them back on, and push in the Bus Tie breakers that pop out.


Title: Re: LM status...
Post by: Chris97b on July 29, 2006, 08:23:24 PM
Worked perfectly for me, Started P63 as soon as the scenario loaded, it turned retrograde and fired right around the periapsis/perilune. It flew down beautifully and made a perfect landing right in the middle of Fra Mauro; completely hands off :)


Title: Re: LM status...
Post by: BigDAS on July 31, 2006, 07:59:17 AM
How do I power on the CDR FDAI? Is this a panel switch operation or do I have to activate it in the SDK?


Title: Re: LM status...
Post by: dseagrav on July 31, 2006, 09:13:21 AM
LMP electrical panel: Switch on at least one CDR descent battery. You probably need both. High-voltage taps is OK. Switch on either inverter. This should power the FDAI. You may have to wait for the IMU to spin up, I don't remember if it becomes active immediately or not. If it doesn't work, check the breakers on the CDR side. The CDR FDAI requires the CDR DC bus and AC Bus (A?) to operate.

The LMP FDAI is not implemented. Also there is no rate data until the RGA is completed. I'm going to try to do the LM SCS and DC bus crosslinks in one commit.


Title: Re: LM status...
Post by: BigDAS on July 31, 2006, 11:14:06 AM
Thanks!


Title: Re: LM status...
Post by: NoName on August 08, 2006, 08:41:31 PM
The COAS on the LEM left hand side window now works. 


Title: Re: LM status...
Post by: BigDAS on August 08, 2006, 08:43:07 PM
Excellent!!! :ThumbsUp432:


Title: Re: LM status...
Post by: x15 on August 12, 2006, 05:11:12 AM
Hello folks,

I have been inactive for some time on the project, but I have some news for you

I have been working lately on the LM Digital Autopilot, and I found an issue in the virtual AGC implementation.

It seems to explain the overactivity we have had with the RCS thrusters on the LM.

David, are you still struggling with this problem ?

Is yes, I can suggest the following :

I cannot commit the change myself (my developer login doesn't work anymore, I am getting an
authenticate failure)


But i tested it with the anonymous login and i was able to stabilize myself with the attitude hold mode
and doing some Verb 49 manoeuvres in the Auto stab Mode.

The patch is quite simple (I am still discussing with Ron Burkey about it), you only have to remove the #ifdef ALLOW_BSUB directive in the agc_engine.c


I would be interested if someone else tests this (and specially if it is working too for Stephan Hotto's LM simulator)


Cheers

x15


Title: Re: LM status...
Post by: dseagrav on August 12, 2006, 07:22:54 AM
Sourceforge had some security issues and invalidated everyone's passwords some time ago. Visit the main page to correct this.


Title: Re: LM status...
Post by: x15 on August 12, 2006, 10:52:50 AM
thank you dseagrav

my login is working again

I just committed the patch in agc_engine.c


x15


Title: Re: LM status...
Post by: dseagrav on August 13, 2006, 01:30:56 AM
This is Yet Another Checkpoint Commit for the LM. It makes the ATCA exist but most of the logic doesn't. Someone needs to add lmscs.cpp and lmscs.h to the VS6/VS2005 projects for me.

The GC mode switch works (The PGNS/AGS mode switch by the FDAI) - It properly toggles the AGC bit and inhibits AGC thrust commands if the AGS is enabled (which just enables and disables the Orbiter autopilot - see below). This causes the actual thruster writes for vAGC mode to go through the ATCA, but all it does now is pass them unmodified.

It also has an inhibit for AGC++ mode where it will no longer whack the AGC++ thruster commands by overwriting them with the channel data. Later when someone fixes the AGC++ to use pulses and IO channels this will not be required. (I tried but it didn't work right so I undid it. I might try again later.) As a side effect of this, when in vAGC mode and the GC mode is PGNS, the Orbiter autopilot no longer works. This is just fine now that the LGC DAP works.

Next commit will have more of this and some parts of the Explosive Devices subsystem. (Yes, the landing gear deployment is one of them.)

Before too long I'm going to need someone to make a LM pad load for me, so I can tow a vAGC LM to the moon and try it there. I know the AP13 pad load exists, but does it have good ephemeris numbers and such?


Title: Re: LM status...
Post by: Swatch on August 13, 2006, 12:17:48 PM
Somebody call an engineer!  We need PAD!

Irengineer:  Did somebody call? 

 :cool7777:


Title: Re: LM status...
Post by: movieman on August 13, 2006, 12:33:36 PM
The Apollo 13 PAD data is in the scenario, but it seems to be incompatible with the version of the software that we have.


Title: Re: LM status...
Post by: dseagrav on August 14, 2006, 01:10:55 AM
I need an engineer, and now I need an artist! ^_^
On the LM left panel, Panel 8, Explosive Devices section, the two items under the "STAGE SEQ RELAYS" caption labelled "SYS A" and "SYS B" are supposed to be two lights, 2DS1 and 2DS2 respectively. These lights should illuminate yellow. They are currently depicted as circuit breakers. I need someone to edit the panel bitmap to make them lamps, then give me a bitmap of said lamp illuminated yellow if one doesn't already exist.



Title: Re: LM status...
Post by: BigDAS on August 14, 2006, 10:12:53 AM
Okay, leave them in BMP format?


Title: Re: LM status...
Post by: Swatch on August 14, 2006, 10:21:52 AM
I'd almost suggest leaving this for Moonwalker he has the source bitmaps, so his won't suffer any degridation from re-encoding to bmp.


Title: Re: LM status...
Post by: movieman on August 14, 2006, 10:37:31 AM
I think you're confusing me with Moonwalker again :).


Title: Re: LM status...
Post by: Swatch on August 14, 2006, 10:43:26 AM
I don't know what you're talking about..... :Duh!39835:

<_<    >_>   <_<

 :wink:

Actually if you noticed (prior to me correcting it for clarity sake), I capitalized it  (Movieman vs. movieman).   And yes....I do that constantly.


Title: Re: LM status...
Post by: NoName on August 14, 2006, 06:19:46 PM
Quote
On the LM left panel, Panel 8, Explosive Devices section, the two items under the "STAGE SEQ RELAYS" caption labelled "SYS A" and "SYS B" are supposed to be two lights, 2DS1 and 2DS2 respectively.

Not a problem. I'll change that within the next few days ;)

At the moment I'm going to do antoher and a final major change of the bitmaps. I'm using the new high detail images we have. I know that stuff should be posted in the modeling area but I would like to show you what I'm talking about:

(http://www.german-spaceflight.com/panel_project/Preview/Preview 1.bmp)

(http://www.german-spaceflight.com/panel_project/Preview/Preview 2.bmp)

I think using real switches, rotaries and some panel parts would be great :)

What do you think?


Title: Re: LM status...
Post by: NoName on August 14, 2006, 06:38:44 PM
Just as a reference...

(http://swatch.homeip.net/capsule/1000217.JPG)


Title: Re: LM status...
Post by: dseagrav on August 18, 2006, 12:45:18 AM
This is Yet Another LM Checkpoint Commit. This makes the initial parts of the EDS exist, and allows you to deploy the landing gear. The other switches flip but none of them are connected to anything (yet). To deploy the gear, make sure the ED CBs are pushed in on the CDR and LMP sides, arm Master Arm, and flip LDG GEAR DEPLOY to FIRE. The TB should go grey. If it doesn't, you have an open CB somewhere or forgot to turn the power on. You can turn everything back to SAFE one the gear is deployed.

This commit also causes talkbacks to barberpole if they are wired to a power source and the power source loses voltage.
Talkbacks not wired to anything should function as before.



Title: Re: LM status...
Post by: BigDAS on August 18, 2006, 06:29:21 AM
Good work! Now we can run a complete mission!


Title: Re: LM status...
Post by: dseagrav on August 18, 2006, 06:46:31 AM
No you can't - You can't stage.


Title: Re: LM status...
Post by: BigDAS on August 18, 2006, 04:11:34 PM
No you can't - You can't stage.


Blast! Oh well, back to little CM I go and wait.
 :Duh!39835:


Title: Re: LM status...
Post by: dseagrav on August 20, 2006, 03:34:41 AM
Another LM Checkpoint Commit. This one removes references to the "Ascent RCS" (more below) and fixes the bug that causes the IMU and LGC to restart on scenario load, and as an extra bonus the EDS can now cause (really incomplete and incorrect) staging. Even after staging the descent EPS still exists and still powers the ship, because the ascent EPS doesn't exist yet. I'll take care of that later. Anyway, those switches talking about ascent fuel for RCS aren't what people thought before - The LM RCS has just one fuel supply that is used whether or not the descent stage is present. Those switches actually allow APS fuel to power the RCS as a means to conserve RCS fuel.


Title: Re: LM status...
Post by: dseagrav on August 20, 2006, 10:08:58 PM
Another "another" commit... This one adds the DC voltmeters and associated switching. It wasn't obvious what the meter was supposed to show when connected to "AC BUS", so I made it show AC bus A voltage minus 85. That is, if the inverter is operating properly the needle should stand straight up. Also, the ED batteries don't exist, and their voltage is faked.



Title: Re: LM status...
Post by: Christophe on August 21, 2006, 12:06:14 PM
Thanks dseagrav for all your efforts! :ThumbsUp432:

I can't wait to test your new LM!
Unfortunately I don't have much time for that at the moment but as soon as I finish the CSM preocedures I'll begin the work on the LM. With the Irnenginer padload spreadsheet I expect to build the Apollo 9 scenario to test the LM in flight :)

Keep up your work!


Title: Re: LM status...
Post by: NoName on September 22, 2006, 09:31:04 PM
Final Graphics update also completed for the LEM!

All the new stuff is up and running. Just have a look and enjoy the spirit of Apollo ;)

Important: The stage seq relay lights of panel 8 are availabe for coding now. Just look for "lem_seq_light.bmp".

I'll do the corresponding ORDEAL panel for the LEM too. And I'll add the hatch just below the main panel soon. It could be used to open the hatch (nice view to the lunar surface) and start the lunar EVA.


Title: Re: LM status...
Post by: thermocalc on September 22, 2006, 11:09:28 PM
dear Moonwalker,
I want to thank you so much to have decided to implement all the panels, internal views and so on, the realism will be extremly of high level.
congratulation again for all your efforts to finish all the new panels in very short time.
Take care! :ThumbsUp432:


Title: Re: LM status...
Post by: FordPrefect on September 23, 2006, 01:12:35 AM
Sounds fantastic Moonwalker!  :Excited432: I really hope I will have internet access from home again soon, so I can update throught CVS again to see all the gorgeous new stuff implemented!


Title: Re: LM status...
Post by: Christophe on September 23, 2006, 08:30:46 AM
Thanks again Moonwalker.
Now I got a lot of work to write the corresponding checklist with the new panels.  :wink:
But I like to do it... :yes77:


Title: Re: LM status...
Post by: Christophe on December 01, 2006, 04:56:32 AM
Hi fans.
Just wanted to know, what's the current LM status at present time?
What's working and what doesn't ?
For my information only; if someone could post a brief report.
I'm thinking about starting to work on the LM procedures, maybe for an Apollo 9 mission, since the CSM works not too bad in earth orbit.
Thanks a lot.


Title: Re: LM status...
Post by: dseagrav on December 01, 2006, 10:16:16 AM
It needs lots of attention yet; Only about half of the electrical system works, the LGC works and can fire thrusters, and that's about it. The last thing I touched was partial support for staging. That's about when I went off on my optics adventure. I plan to get back into the LM "Real Soon Now".

Today we're snowed in, so I can probably hack at it some.


Title: Re: LM status...
Post by: Swatch on December 01, 2006, 12:32:26 PM
Keep in mind, if we want a release by Xmas, we probably should avoid jumping into the LM too much and getting bogged down.  :twocents22:

~Swatch


Title: Re: LM status...
Post by: Christophe on December 02, 2006, 10:53:18 AM
Thanks for your reply.
Quote from: dseagrav
The last thing I touched was partial support for staging

Should I uderstand there's a way to separate ascent/descent stage by now? For example like an abort?
I tried yesterday (very quickly I admitt) and I did'nt found the way. I was wondering if that was my fault or if that didn't work.

 
Quote from: dseagrav
plan to get back into the LM "Real Soon Now".

What a great news! Keep up your effort, you did an awesome work dseagrav.

Quote from: Swatch
Keep in mind, if we want a release by Xmas, we probably should avoid jumping into the LM too much and getting bogged down

You're perfectly right Swatch. Don't worry. I don't want to go too far or too fast.
Just, as you know I'm unfortunately not a programmer at all and as far as I'm concerned, my only little contribution is the writing of the checklist, which are almost complete for the CSM. It left only the rendez vous programs while the CSM is active vehicle and of course the different updates according to the new optics stuff. And perhaps write some articles in the Wiki.
On the other hand, the LM is very complex and I know nothing at all on it. So I would like to take some advance and to start to study it to be able to put some docs as soon as it is acceptable for use in the sim.


Title: Re: LM status...
Post by: Christophe on December 06, 2006, 06:40:34 PM
Hi!
Could someone explain a little the TJT parameter in joystick.ini ?
Unable to get it working.


Title: Re: LM status...
Post by: dseagrav on December 06, 2006, 07:20:07 PM
When the LM is more complete, the axis selected will act as the Throttle/Jets lever. It doesn't do anything right now.


Title: Re: LM status...
Post by: Christophe on December 07, 2006, 02:23:53 AM
When the LM is more complete, the axis selected will act as the Throttle/Jets lever. It doesn't do anything right now.


Yes I know the throttle/jets lever but I understand that it's not working yet. Am I right?


Title: Re: LM status...
Post by: dseagrav on December 07, 2006, 08:55:37 AM
Right, it doesn't work yet.


Title: Re: LM status...
Post by: Christophe on December 07, 2006, 09:31:25 AM
Experience some trouble to start the DPS, too, either manually or via P40 (apollo 13 padloads); Does it really work?


Title: Re: LM status...
Post by: dseagrav on December 07, 2006, 11:59:31 AM
No, DPS won't fire. The LM is really early. Most of it doesn't work as expected.


Title: Re: LM status...
Post by: Cale on December 20, 2006, 12:35:37 AM
Hi there,

Have tried to do several different lunar landing and liftoff/rendezvous missions, in both Standard and Quickstart format.  All the landing scenarios worked (after changing the vessel names for the SIV-B in the scenario file), but have had issues with 2 of the attempted liftoff/rendezvous scenario, except Apollo 16 (which I haven't tried yet).

1.  On Apollo 11  liftoff scenario, P33 (the CSI burn) doesn't fire the RCS thrusters, thus screwing up the rest of the rendezvous..P34 doesn't work etc.  I've followed the checklists properly, and have even enabled the 2 TTCA switches on Panel 3 to "Enable", with no change in result.

2.  On Apollo 17 liftoff scenario, everything goes swimmingly until rendezvous, when the LM just cruises on by the CSM without braking :Duh!39835:
Again, enabling the TTCA switches didn't change anything.

I'm using the latest beta mods, and last did my CVS update on Sunday (Dec. 17).

Any help would be appreciated...thanks!

Cale


Title: Re: LM status...
Post by: dseagrav on December 20, 2006, 12:40:14 AM
The LM is not guaranteed to be working right now. We're focusing on getting the CSM able to do Apollo 7 and 8 first.
No point in spending time on the LM if the CSM can't get it to the moon to begin with.


Title: Re: LM status...
Post by: Cale on December 20, 2006, 12:57:24 AM
Well, at least it's not something I screwed up! :D



Title: Re: LM status...
Post by: Christophe on December 20, 2006, 06:28:12 AM
The LM is not guaranteed to be working right now. We're focusing on getting the CSM able to do Apollo 7 and 8 first.
No point in spending time on the LM if the CSM can't get it to the moon to begin with.


But in this case we absolutely need the CMPAD to tell the vAGC where the moon is, we need a code for the IU TLI, we need a way to compute landing site refsmmat, we need VHF ranging implement... there's a chance that the LM would never be released!


Title: Re: LM status...
Post by: dseagrav on December 20, 2006, 10:41:34 AM
But we need some of those for the LM too! The LM also has to know where the moon is and the range to the CM. When we figure out how to do it with the CM, we can copy/paste it over to the LM.



Title: Re: LM status...
Post by: Christophe on December 21, 2006, 10:08:26 AM
Not exactly. The LM knows where the CSM is accurately with the help of the RDV radar.
At least the LM should allow to start the DPS/APS manually and with working RCS.
I read a lot about the RCS, it's very tricky because it needs the LGC to work. As far as I tested, some features work, some other doesn't, and apparently randomly.


Title: Re: LM status...
Post by: dseagrav on December 21, 2006, 05:18:05 PM
The RDV radar only works when you get within range of the CM - You still have to be able to get within range by inertial calculation, and it still has to be able to compute the position of the moon to land on it. The LM uses the LGC a *LOT* more than the CM uses the CMC. The LGC++ is going to have to be made a lot smarter to cope (which is a lot of work), or some pretty severe cheating will need to be done (which breaks the vAGC), or something. vAGC is going to be a big advantage in the LM, if it weren't for the simulation-rate limitations it entails...

If you're that desperate for a LM, I can go back to it when I get the telemetry client finalized (Almost done with that, I have all lists working except the P22 orbital-navigation list) and do some looking for the CM RCS stuff that chode needs.



Title: Re: LM status...
Post by: Christophe on December 22, 2006, 11:24:17 AM
If you're that desperate for a LM, I can go back to it when I get the telemetry client finalized (Almost done with that, I have all lists working except the P22 orbital-navigation list) and do some looking for the CM RCS stuff that chode needs.

Ok Thanks dseagrav. But I didn't want to put you under pressure  :)
You 've already done a very great work for the project. Thanks for that.


Title: Re: LM status...
Post by: mikaelanderlund on April 30, 2007, 12:57:51 PM
Hi dev team,

 Any news about the LM :Excited432:?

Mikael


Title: Re: LM status...
Post by: Tschachim on April 30, 2007, 02:29:38 PM
Yes, kinda...

With yesterday's beta modules (20070429) I'm quite sure that you can land on the moon in Standard and Quickstart Mode (not Virtual AGC mode), the problem to arm the descent engine is fixed, but it isn't documented yet, so it's very hard to find out how to do, especially how to activate the LM. If I have some time left I'll take a look at it and post some info...

Cheers
Tschachim


Title: Re: LM status...
Post by: mikaelanderlund on May 01, 2007, 12:55:49 AM
Great news!!! Does this mean that we have a functional AGC++ in the LM like the one we have in the NASSP 6.4?

Mikael


Title: Re: LM status...
Post by: movieman on May 01, 2007, 05:38:43 AM
Well, the Apollo 14 lunar landing scenario certainly works with the AGC.


Title: Re: LM status...
Post by: Christophe on May 01, 2007, 01:52:53 PM
And what about flying the LM manually. Is there any way to use the RCS at least like any standard orbiter vessel?


Title: Re: LM status...
Post by: mikaelanderlund on July 06, 2007, 11:07:31 AM
Dear dev team,

Any news or progress about LM panel? Maybe a status report and future plans?

Mikael


Title: Re: LM status...
Post by: dseagrav on July 06, 2007, 02:38:19 PM
I don't think I'll get back to it any time soon - I'm still busy with the LV. For plans, I want to get the LV and ground control working enough to put the CSM on an automatic translunar trajectory before I go back to the LM. Once that happens, I plan to go back and finish the work I started on the LM. I have no specific timetable.


Title: Re: LM status...
Post by: mikaelanderlund on July 06, 2007, 03:49:02 PM
Hi dseagrav,

thanks for your info! Take your time and thanks for a great sim :ThumbsUp432:

Mikael


Title: Re: LM status...
Post by: ryan on June 27, 2008, 05:36:04 AM
Is the LM work still open, or what?


Title: Re: LM status...
Post by: Zachstar on June 27, 2008, 05:40:42 AM
Is the LM work still open, or what?

Do you know what is currently going on in the sim? I suggest you check out the last few weeks worth of messages and find out.


Title: Re: LM status...
Post by: ryan on June 27, 2008, 05:45:09 AM
I have actually, and it seems were really doing stuff with the CM, to be honest the outside of the LM looks 2003 version of orbiter. More info on the LM will be great to see every now and then. :)


Title: Re: LM status...
Post by: Tschachim on June 27, 2008, 05:47:16 AM
...to be honest the outside of the LM looks 2003 version of orbiter. More info on the LM will be great to see every now and then. :)

http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1480.msg15767#msg15767


Title: Re: LM status...
Post by: ryan on June 27, 2008, 05:49:11 AM
Sorry :Duh!39835: need to open me eyes.


Title: Re: LM status...
Post by: Zachstar on June 27, 2008, 05:49:41 AM
Sorry :Duh!39835: need to open me eyes.

I agree


Title: Re: LM status...
Post by: NoName on October 10, 2008, 04:43:58 PM
I have some thoughts concerning the planned 2D Lunar Module - LPD window and the future of our 2D Lunar Module windows on the whole...

While FordPrefect is doing such a great work on a new ascent stage, and since this is going to include a VC too, I think that there is no reason anymore to include a 2D LPD window. Further, I also think we should remove all 2D window graphics of the Lunar Module in the long run. Which means the right and left window used for landing and the upper rendezvous window. I really think we should create a nice selectable eye-point environment within the future VC of the LM.

And in context to this, we also could remove the 2D side hatch of the CM and almost fully animate the VC hatch and connect it to the systems (as well as using 3D eye-points for all the VC windows of the CM too including an animated COAS for the left hand rndz window). In other words: I think 2D views are out meanwhile.

It's only some ideas. In my point of view we should work more with eye-points within VC's in the future and keep working on 2D panels only while removing the 2D windows.

What do you all think about that?


Title: Re: LM status...
Post by: FordPrefect on October 17, 2008, 05:53:39 PM
Hey Moonwalker!

First, I think your 2D panels are a truly awesome, and I would not be happy to see them vanish from NASSP. I agree with you though, a switch to use more 3D cockpits in the long run is the way to go. If we would do so, your gorgeous bitmaps should be used as textures in the VC's, and that is what you are thinking of as well, I assume. We've also talked about this briefly in my LM ascent stage thread, I think.

My only question about that step, or concern is: Which of both variants affects performance less, the current 2D panel structure or a full 3D VC? I'm asking this thinking of all NASSP users with low end machines...of which btw I have no clue how many we have.

Now that summer is over and my brief escapade with Celestia and FS9 is over, I'm going to update you folks soon on the LM ascent stage progress. Sorry for my absence here in the last months.  :oops:


Title: Re: LM status...
Post by: Christophe on October 19, 2008, 06:57:12 AM
Hi Fordperfect!
Glad to see you back! :)


Title: Re: LM status...
Post by: Tschachim on February 26, 2009, 01:36:15 PM
From Graham2001:

Found something on the NTRS discussing the programming of NOUN69, it seems that the programming was changed between Apollo 14 & 15.
See: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072774_1979072774.pdf [11 MB]

Thanks Graham!  :)


Title: Re: LM status...
Post by: NoName on February 26, 2009, 09:14:26 PM
Well, you'll note that the LM instrument panels will make some progress within the following weeks, graphically at first.

This is what I think the panels finally are going to be in the near future:

http://www.nasa-virtual.com/project_apollo/instrument_panels/lm_panel_management.jpg

I'm not quite sure if I'll add the whole suit compressor box to the right hand side of the right panels or just the controls. In any case, we'll have almost all controls available.

Tschachim: I fear the panels should have a width of at least 1680 pixels, right? The LM main panel currently has a width of 1485 pixels. I think I have to extend it. And we also need wide screen versions of all window views once again, right? :)


Do not hesitate to request something / make any advices...


Title: Re: LM status...
Post by: Apassi on February 26, 2009, 11:22:50 PM
Hi Everyone!
I`m not developer myself and I´ve been watching the development this project silently many years.

It seem that LM development has started.
Some day we have to land on the moon and get back out there.

LM seems to be very complicated machine. There is lots of Pdf.s about it.  But..
Have you developers seen this already?
http://history.nasa.gov/alsj/LMA790-3-LM-2.1.pdf
(Pg.64).  Different star tracking method. 

Nice to see you have keep going on these many years  :cool7777:

Apassi




Title: Re: LM status...
Post by: Tschachim on February 27, 2009, 07:22:21 AM
Tschachim: I fear the panels should have a width of at least 1680 pixels, right? The LM main panel currently has a width of 1485 pixels. I think I have to extend it. And we also need wide screen versions of all window views once again, right? :)

No, we need wide screen versions only if

- the panel is more narrow then 1680 px (per "convention", but my currently used screen is 1920 px wide...) and the aspect ratio is more narrow then 16:10 to avoid that you can see outside to the left and right of the panel. There's no such panel in the CSM at the moment, because all panels with this aspect ratio are at least 1680 px wide.

- the panel should not scroll in any resolution / aspect ratio, because a fixed position is necessary for the panel to work properly. This is the case for the left and right rendezvous panels (COAS position) and the sextant and telescope panels (crosshair position) in the CSM. In the LM I assume this is necessary for the LPD window, the rendezvous window, the AOS window and the left and right window if there's a COAS.

Cheers
Tschachim   


Title: Re: LM status...
Post by: Graham2001 on March 02, 2009, 09:38:31 AM
From Graham2001:

Found something on the NTRS discussing the programming of NOUN69, it seems that the programming was changed between Apollo 14 & 15.
See: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072774_1979072774.pdf [11 MB]

Thanks Graham!  :)

Thanks for sending it to the right people. I've finished looking at it myself, only pages 1-21 of the PDF deal with the modifications to NOUN 69. The rest of the file is an unrelated document dealing with early space station proposals, still an interesting read though.


Title: Re: LM status...
Post by: Graham2001 on April 17, 2009, 11:32:29 AM
Courtesy of the NASA Technical Reports Server. Two documents dealing with LMs 7-10 dating from about 1970.

1. Lunar module 7, 8, and 9 elementary functional diagrams (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710070891_1971070891.pdf)(25.8mb)

2. Lunar module 10 and sub elementary functional diagrams (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710070889_1971070889.pdf)(21.8mb)


Title: Re: LM status...
Post by: NoName on May 14, 2009, 02:25:53 PM
While I'm going to completely finish the 2D instrument panels hopefully still this week, I would like to let you all know that I decided not to support 2D window views for the LM anymore. For the Crew Module the 2D windows were almost indispensable due to the close arrangement to the instrument panels (and because of functionality of the side hatch). But for the LM we don't really need 2D windows (except the LPD window view) once we'll have a VC available. So temporarily the old 2D windows will still be available but not updated anymore.

My primary future focus will be on the EVA's and on the Lunar Module. Especially to create first person views for both, a LM VC and the EVA suits (and really, we also need "jumping" astronauts and oxygen use as well). I'll post the corresponding stuff and questions/help requests in the related topics once the time has come...

PS: And thanks for the documents Graham2001.


Title: Re: LM status...
Post by: dseagrav on August 08, 2009, 07:42:15 PM
I noticed something interesting while working on the EPS again -- If more than one source draws from a circuit breaker, it doesn't sum the load properly.
Can anyone think of anything this would break?


Title: Re: LM status...
Post by: NoName on August 08, 2009, 08:11:31 PM
I could not even wire up the circuit breakers at all the way it is done for the command module. But I haven't got enough programming skills to find the solution/cause.

Anyway, I have to tell a news which is about to abandon my intention not to support 2D window views anymore. That is because I'm going to get a new TFT display. I have to because my old one is going to pack up (it requires almost 45 minutes to get a signal after it has been switched on, so I do not turn it off anymore until I get a new one). The new TFT will be widescreen. Plus the fact that there is obviously no interest within the community of doing AMSO- like 3D interior stuff for the LM (well actually no VC stuff at all), made me thinking about 2D windows once again. Today I picked up my final work on the LM panels, since the CM panels can be assumed to be complete on the whole. This LM work will include new widescreen window views, all of it :)


Title: Re: LM status...
Post by: dseagrav on August 09, 2009, 09:30:08 PM
I committed the rest of the EPS. The entire EPS should work as expected.
This includes the bus cross-tie load balancing act, which was a real pain in the ass.
The only exception is the XLUNAR bus and the CSM feed, I have to figure out how to do that.

Anyone working on any new system should wire their system to the appropriate breaker and set up power loading.
Let me know if there are any issues.



Title: Re: LM status...
Post by: Swatch on August 09, 2009, 09:45:58 PM
I wouldn't say there is NO interest in doing a VC for the LEM.   :cool7777:

I'm just going to get the CM VC working first and then start on my LEM VC.  I of course need your wonderful 2D panels, like before!   CMVC first, then LEM VC.


Title: Re: LM status...
Post by: NoName on August 10, 2009, 11:59:18 AM
Great news guys :)

And what should I say about your LEM VC intentions swatch... I've always dreamed about such a thing for NASSP (at least since AMSO :P). Once the LEM panels are complete, which is going to happen quite soon, I'll send you them for the future LEM VC...

PS: Today I managed to make my TFT work again. I just have to "blow-dry" the location of the power supply for some 2-3 minutes. It seems that a condenser is not working properly, but I sadly have no voltmeter to figure out which one. But anyway, to blow-dry the TFT on rather than to switch it on, is an acceptable compromise until I get my new TFT :D Funny but it works. Once it runs, it does this without any problems. It just should not be switched off for too long so that the power supply cools down...


Title: Re: LM status...
Post by: Swatch on August 10, 2009, 07:07:39 PM
Ironically, getting numerical dimensions of the LM is much easier than the CM.  I'm finding out that the CM VC I built isn't compatable with our current CM.  I need to figure that out.  I built the CM-VC with dimensions more in mind, so I need to see if I got it right or if I need to tweak the VC.  If the VC is right, then I'm going to rebuild the CM meshes.  I've always questioned it a bit... always seemed too tall.  Hopefully I'll figure this out quickly.  The biggest problem is there simply isn't a good source of dimensioned drawings for the CM Interior.  I do need to get the numbers for the exterior though.   Anybody got a set of David Weeks drawings?  :P


Title: Re: LM status...
Post by: dseagrav on August 15, 2009, 10:16:22 PM
I made a new commit, it adds more EPS stuff, but I have a few outstanding issues left.
The CSM to LM umbilical works now.

Edit: I don't have the issue I thought I had. The real ship had the issue too, so it's realistic.
This set of changes will make all scenarios which have a LM in them obsolete and they probably won't work anymore without editing of the scenario.

The "problem" is, the device that takes power from batteries and puts it on the DC busses (The ECA) is itself operated by power from said busses.
The switches on the panel that turn on and off the battery feeds are connected to the Relay Junction Box. The RJB is connected to the individual ECAs and provides the actual power that changes the positions of the relays and contacts inside the ECA. That means if you somehow lose power on both DC busses while not connected to the CSM, *AND* your current ECA configuration does not provide power to at least one bus, you have no means of restoring power to the LM since you have no power with which to alter the position of the ECA contacts! The easiest ways to accomplish that are to deadface the descent stage without ascent power turned on (since you need power to restore the deadface relays) or to simply turn off all power sources. The LM can never be truly "cold and dark" and still be restarted later under its own power EXCEPT by pulling of circuit breakers.

You can also screw yourself over by turning on the CSM power feed (which disables descent stage power) and then undocking the LM without resetting the descent stage power feed. If you do this the descent stage power will still be disabled.

The side effect of issue #1 there is that any LM scenario created where the LM ECAs are saved in the all-off position, or any LM scenario having only an ascent stage, you will not be able to turn on LM power.
In the first case you can get around this by deleting the ECAs from your scenario, which will revert them to their pre-docking setup (Batteries 1 and 4 low-voltage taps on).
In the second case you have to edit the scenario to turn on the ascent power by changing the ECA 3A and 4A channel inputs to 1.


Title: Re: LM status...
Post by: dseagrav on August 23, 2009, 09:26:53 PM
I made a checkpoint commit, it adds a bunch of skeleton systems with heaters to use up power during the translunar cruise.
Work continues.


Title: Re: LM status...
Post by: dseagrav on August 23, 2009, 10:46:54 PM
Hey Moonwalker, you still have the PSD file or whatever that the panel bitmaps are generated from, right? I'm going to need ECS controls before long here, and there's more controls than what you have on the panel.
(In fact, there's enough of them we might want to make another panel that's further right, to reflect the idea that the LMP had to turn around to operate it)

Other things that would be nice to have is the hatches and LM tunnel. Then I can do the tunnel filling and crew movement stuff.


Title: Re: LM status...
Post by: NoName on August 24, 2009, 05:26:02 AM
I'm already going to do a complete new panel. I will cut the right hand side panel (the latest one already is cut but not yet committed), and add the ECS controls on a new panel right next to it.

Not up to date but you can see what I'm going to add right next to the right side panel:

http://www.nasa-virtual.com/project_apollo/instrument_panels/lm_panel_management.jpg

Hatches will follow as well. But it'll take some time...

What do you mean by "tunnel filling"?


Title: Re: LM status...
Post by: dseagrav on August 24, 2009, 05:56:16 AM
I'm already going to do a complete new panel. I will cut the right hand side panel (the latest one already is cut but not yet committed), and add the ECS controls on a new panel right next to it.
That works.
Quote
What do you mean by "tunnel filling"?
From what I understand so far, the LM was launched with the CABIN REPRESS cb in. But I don't know how exactly the ECS valves were set. The overhead hatch vent valve may or may not have been open.
So I don't know how much air, if any, was in the LM. At docking time, the LM/CM tunnel is definitely at a vacuum. So the crew has to over-pressurize the CM and allow that overpressure to bleed into the tunnel to fill it. After that, if the LM was launched with the overhead vent valve closed, they would open it from the outside to allow the LM cabin and tunnel pressures to equalize. If the valve was open air would just bleed in. Once all three pressures were equal, the hatches could be removed and crew transferred.

At the moment evidence indicates the valve was open and the LM was at a vacuum.



Title: Re: LM status...
Post by: NoName on August 24, 2009, 06:01:05 AM
Ah, okay. You mean the pressurization :)

I also only know about the tunnel pressurization . But at the moment I'm reading the complete Apollo Command Module News Reference. I think if the LM was pressurized or not can be found somewhere in it...


Title: Re: LM status...
Post by: dseagrav on August 24, 2009, 06:06:54 AM
We may have to find and ask an astronaut.

Another thing I'm having problems finding is power consumption of individual subsystems. For example, lighting.
Edit: And the ASA. Nothing on how much heater it uses when it's off. I can't even find decent diagrams of it.


Title: Re: LM status...
Post by: NoName on August 24, 2009, 06:14:00 AM
Try the Apollo Lunar Module News Reference:

http://www.cs.indiana.edu/sudoc/image_30000061709352/30000061709352/pdf/techdata.htm


Title: Re: LM status...
Post by: NoName on August 25, 2009, 03:22:45 PM
dseagrav:

is there a certain timeline in which you need my latest/final instrument panel graphics for your coding work?

My intention is to finish the complete LM stuff until end of September. If you need certain things before, let me know. Maybe I can hurry up...


Title: Re: LM status...
Post by: dseagrav on August 25, 2009, 03:43:50 PM
My intention is to finish the complete LM stuff until end of September. If you need certain things before, let me know. Maybe I can hurry up...
As far as I know right now the ECS is the only thing I don't have that's going to get used soon, so if you can give me the new ECS panel first that would work. You don't have to bother editing out the partial one that's there until you get that panel ready to run, I can just ignore it.

It's not a HUGE rush, so you don't have to cause any problems for yourself. retro just found a passage proving the LM was in fact pressurized at launch time, so that mystery is now solved.

Edit: I found another thing we don't have, just FYI: There's a switch on the AOT guard that switches the RR gyro override. It's not obvious so I thought I would point it out.


Title: Re: LM status...
Post by: dseagrav on September 01, 2009, 01:32:23 AM
I made another checkpoint commit. Someone may have to regenerate the non-VS2008 project files, because I made the LM load the large fonts thumbwheel bitmap. I found another something we don't have, we need a 25x77 border bitmap for the said knobs.

Work continues.


Title: Re: LM status...
Post by: NoName on September 01, 2009, 10:00:26 AM
I think you used the thumbwheel_large_fonts.bmp? Because somebody some time ago made a second one: thumbwheel_large_fonts_inv.bmp. I could not figure out yet whether those thumb wheels within the LM were white or dark grey. As long as we don't know, I personally tend to use the darker one. In case we need it in white indeed, I will update the bitmap. So we can move the thumbwheel_large_fonts_inv.bmp to the obsolete bitmaps anyway.

By the way, I'm right now finishing the updates of the currently existing panel bitmaps, including an update of the new phantastic AOT panel by swatch. I'll post a preview either today ot tomorrow. It looks great and the progress is way faster than I expected. Only three things remain to be done until all the NASSP 2D panels will be finally complete after years of work: the two hatches and the ECS box. My plan is to commit the complete new set in one go, which will be I think within the next two weeks ;)


Title: Re: LM status...
Post by: dseagrav on September 01, 2009, 10:26:47 AM
I think you used the thumbwheel_large_fonts.bmp? Because somebody some time ago made a second one: thumbwheel_large_fonts_inv.bmp.
Yeah, because that matched what was in the panel. I guess I can see if I can find pictures.
If it turns out to be wrong it should be easy to switch the bitmap.
Quote
By the way, I'm right now finishing the updates of the currently existing panel bitmaps, including an update of the new phantastic AOT panel by swatch. I'll post a preview either today ot tomorrow. It looks great and the progress is way faster than I expected. Only three things remain to be done until all the NASSP 2D panels will be finally complete after years of work: the two hatches and the ECS box. My plan is to commit the complete new set in one go, which will be I think within the next two weeks ;)
Awesomesauce. I should have all of the switches that we have flippable by then. FYI I am deliberately not putting CBs in until I have something wired to the wire to them, to make it easier to keep track of what I have and haven't done.

Oh, I also need you to kill the pointers in all of the currently-unused gauges that have them (FDAI rate indicators, T/W gauge) so I can replace those. I will need strips and a pointer image for the altitude/rate indicator too. (and you'll have to blank out the existing strips with that magic pink color so I can blit the strip underneath the pointer)



Title: Re: LM status...
Post by: NoName on September 01, 2009, 11:26:08 AM
Oh, I also need you to kill the pointers in all of the currently-unused gauges that have them (FDAI rate indicators, T/W gauge) so I can replace those. I will need strips and a pointer image for the altitude/rate indicator too. (and you'll have to blank out the existing strips with that magic pink color so I can blit the strip underneath the pointer)

You don't need pink color on the background bitmap I think. You can place the strips above the background panel and place a gauge bitmap above the strip, which is filled with pink colour. Just like we did with crew modules gauges and FDAI's. The only things that need to be removed is those needles.


Title: Re: LM status...
Post by: dseagrav on September 01, 2009, 01:52:56 PM
You don't need pink color on the background bitmap I think. You can place the strips above the background panel and place a gauge bitmap above the strip, which is filled with pink colour. Just like we did with crew modules gauges and FDAI's. The only things that need to be removed is those needles.
That works too ^^;;~

Edit: Found a picture of LM panel 8: http://www.spaceaholic.com/lm_panel8_front.jpg (http://www.spaceaholic.com/lm_panel8_front.jpg)


Title: Re: LM status...
Post by: NoName on September 02, 2009, 10:36:34 AM
Nice find :ThumbsUp432:

This will finally add the right thumb wheels to our LM panels.


Title: Re: LM status...
Post by: dseagrav on September 06, 2009, 12:05:09 PM
I found another missing item today, I need a bitmap that has the lit-up versions of the CWEA lights.


Title: Re: LM status...
Post by: NoName on September 06, 2009, 05:28:17 PM
I found another missing item today, I need a bitmap that has the lit-up versions of the CWEA lights.

Well, I did not yet find the colour code which shows which lights are red and which lights are yellow. I'll look for it...


Title: Re: LM status...
Post by: dseagrav on September 06, 2009, 06:31:07 PM
Well, I did not yet find the colour code which shows which lights are red and which lights are yellow. I'll look for it...
Oh, I didn't think of that. I'll see if I have anything.

EDIT: Got it! Colors as follows:

All of the lights on the CDR side are RED

On the SE side, the LEFT side lights (ASC HI REG thru PRE AMPS) are YELLOW
The color of the ED RELAYS and S-BD RCVR lights are not noted, so I assume that means WHITE.
The rest are all YELLOW.

Source: LM 10 and Subsequent Diagrams, page 313-321







Title: Re: LM status...
Post by: NoName on September 07, 2009, 06:55:12 PM
Oh, I didn't think of that. I'll see if I have anything.

EDIT: Got it! Colors as follows:

All of the lights on the CDR side are RED

On the SE side, the LEFT side lights (ASC HI REG thru PRE AMPS) are YELLOW
The color of the ED RELAYS and S-BD RCVR lights are not noted, so I assume that means WHITE.
The rest are all YELLOW.

Source: LM 10 and Subsequent Diagrams, page 313-321

That's great. I think it was one of the last vague items. Now everything of the 2D LM panels should be complete within the next few weeks.


Title: Re: LM status...
Post by: dseagrav on September 09, 2009, 09:16:19 PM
I committed a LM checkpoint commit. This one adds files, so someone will have to update the VS2005 and VS6 build files.
I added lm_telecom.cpp/h and lm_ags.cpp/h



Title: Re: LM status...
Post by: NoName on September 10, 2009, 08:30:53 AM
By the way, dseagrav, do you have a source that exactly tells/shows how the scales for the RANGE ALT and RANGE RATE gauges right next to the left FDAI have to look like? Especially the numbers (range of numbers) from top to bottom?

I'm just right now finishing the final version of the main panel including all its bitmaps required for programming. The entire currently existing LM panels that I have updated to their final versions are close to commitment by the way. I think I can manage it still this week... ;) So you and barry can concentrate on implementing all the current stuff while I'm doing the two hatches and ECS bitmaps.


Title: Re: LM status...
Post by: dseagrav on September 10, 2009, 09:43:54 AM
EDIT: Found it.
Altitude range is 0 to 60,500 feet.
Altitude Rate range is +/- 700 fps
Range range is 0 to 400 nm.
Range Rate range is +/- 700 fps.
Source: AOH LM Vol 2 page 261
I am having problems locating information on the Range tape, which is at the end of the Altitude tape.

Images of the range scale show it calibrated in thousands of feet, with a tickmark every hundred feet. It looks like 4,000 feet will fit in the range window.
http://www.mkjassociates.com/cgi-bin/ilgvulot.pl?site=1&sale=49&lot=144 for a picture.

Edit 1: The LR maxumum altitude is 40,000 feet.
Edit 2: The AGS maximum altitude is 37,680 feet.
Edit 3: The AGS maximum altitude rate is 6143 fps.


Title: Re: LM status...
Post by: NoName on September 10, 2009, 02:59:51 PM
Thanks a lot so far.


Title: Re: LM status...
Post by: Tschachim on September 10, 2009, 05:32:31 PM
... so someone will have to update the VS2005 and VS6 build files.

Done!  :)


Title: Re: LM status...
Post by: NoName on September 11, 2009, 08:42:17 PM
At the moment I'm totally lost on that rate/range indicator scales. So far I did the 60,500 feet alt scale and the +/- 700 fps rate scale. But now I'm confused because of the LR and AGS scales/data. I could not find any information that tells me how many scales I have to draw and how they look like particular. I guess I have too many documents and the files may be named different so that I can not find the proper documents :?

I'll continue with all the other remaining stuff firstly.


Title: Re: LM status...
Post by: dseagrav on September 11, 2009, 08:46:16 PM
I put out some requests for more information, we'll see if anything comes back. Go ahead and move on for now. I'll post if I get anything.


Title: Re: LM status...
Post by: NoName on September 11, 2009, 09:26:12 PM
I put out some requests for more information, we'll see if anything comes back. Go ahead and move on for now. I'll post if I get anything.

Okay :)

Thanks.


Title: AGS DEDA Keys
Post by: barry on September 13, 2009, 08:56:19 AM
I have almost finished a stage commit that implements the AGS DEDA UI (the AGS computer keyboard on the Right LM Panel).

The documentation (and yaAGS's code) seems to suggest that the HOLD Light is not a light - rather it is a key (like Enter). Am I missing some later documentation where this was changed?

This would require a new bitmap for the Right Panel, and a new ags_keys bitmap as well.


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 10:56:20 AM
It is a key, confirmed by looking at the diagrams.
Edit: New checkpoint commit.


Title: Re: LM status...
Post by: NoName on September 13, 2009, 11:30:16 AM
Yes, it seems to be a button. I'm right now working on, it at full speed...

http://www.ibiblio.org/apollo/yaDEDAscreenshot.jpg



Title: Re: LM status...
Post by: NoName on September 13, 2009, 12:04:53 PM
By the way: which color does the OPR ERR light have?


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 12:19:50 PM
White.


Title: Re: LM status...
Post by: NoName on September 13, 2009, 02:16:26 PM
Thanks.

And, well, I need one more day I think. My intention was to commit the LM stuff tonight, but I still have to review and change things here and there until everything is finished.


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 02:52:48 PM
It's OK. We have plenty of time. There is no such thing as SLSSP. ^_^


Title: Re: LM status...
Post by: NoName on September 13, 2009, 03:55:33 PM
It's OK. We have plenty of time. There is no such thing as SLSSP. ^_^

What's SLSSP? :)


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 03:59:01 PM
Soviet Lunar Space Simulation Project ^_^


Title: Re: LM status...
Post by: NoName on September 13, 2009, 04:21:30 PM
Soviet Lunar Space Simulation Project ^_^

Ah, okay :D


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 05:17:43 PM
OK, I got details on the range/altitude tape.

There is one tape for both altitude and range. The tape is 10 feet long. The highest number on the altitude tape is 400 nautical miles. It's likely graduated the same way the whole length, numbered in feet up to 60,500 and then nautical miles after that (that is to say, distances under 10 nm read correctly in feet without affecting the number of "steps").
If you know the height of the viewing window you can determine the validity of this mathematically.

The tapes have a digital signal on the back with a gray-code word of position data at each step. A read head picks out the current position on the tape and steps motors as necessary to match that to the desired position.


Title: Re: LM status...
Post by: Swatch on September 13, 2009, 05:36:54 PM
It's possible this will be better to implement in a similar way to how I implemented the AOT reticle.  This would involve rendering the numbers and tic marks in real-time as opposed to manipulating a bitmap.   Depends on how many pixels a 10 ft long tape will take.  I'd love to do something similar with the EMS Scroll in the CM, but the guidance curves on that scroll make it near impossible.


Title: Re: LM status...
Post by: barry on September 13, 2009, 07:25:26 PM
Stage commit for AGS. The DEDA keyboard and Display are now working. See yaAGC's site in the AGS section for the syntax of legal entries.

The CB on Panel 12 Stab/Cont/AEA must be activated and powered for the DEDA to function. I only committed the VC2005 LEM.vcproj. Can someone update it for VC2008. Added the ags_lights.bmp and ags_keys.bmp to the Bitmaps included (not sure if required as the LEMResources.rc pull them in..)


Title: Re: LM status...
Post by: NoName on September 13, 2009, 08:06:51 PM
It's possible this will be better to implement in a similar way to how I implemented the AOT reticle.  This would involve rendering the numbers and tic marks in real-time as opposed to manipulating a bitmap.

I agree.

Depends on how many pixels a 10 ft long tape will take.

I already did the 60.500 feet tape. But it's nothing. Extending that bitmap so that it displays up to 400 nm is totally crazy: 44 x 97.200 pixels :shock:

Those engineers at Grumman were crazy :D Why couldn't they develope a digital display for that... ;)


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 08:13:46 PM
It is a digital display. It has a processor and such inside to do the arithmetic for moving the tapes.


Title: Re: LM status...
Post by: NoName on September 13, 2009, 08:16:06 PM
Well, but 97.200 pixels does not fit to a 10 feet tape. It's about 92 wide screen displays one above the other. I'm totally confused on that damns indicator from the beginning to be honest. I don't understand the graduation above 60.500 feet :gloomy3353:


Title: Re: LM status...
Post by: NoName on September 13, 2009, 08:18:12 PM
It is a digital display. It has a processor and such inside to do the arithmetic for moving the tapes.

I actually meant the displayed data. Digitally displayed just like the mission clock for example ;)

I'm wondering why they used a tape...


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 08:22:37 PM
I don't understand the graduation above 60.500 feet
I'm not certain of it either. All I know for sure is that the length of the tape is 10 feet. If I knew the height of the instrument I could determine the graduation by dividing it out.


Title: Re: LM status...
Post by: NoName on September 13, 2009, 08:24:41 PM
But actually, 10 feet, that's just 3 meters, well in reality. Our panels are not true to scale. I guess it's about as half as big as the real ones. So the scales might be about only 1,5 meters or so. But I'm not a coder. You guys decide...


Title: Re: LM status...
Post by: dseagrav on September 13, 2009, 10:13:26 PM
Stage commit for AGS. The DEDA keyboard and Display are now working. See yaAGC's site in the AGS section for the syntax of legal entries.

The line endings in lmresource.h got eaten so I fixed it.


Title: Re: LM status...
Post by: NoName on September 14, 2009, 07:08:44 PM
Here you get a preview of what I'm going to commit probably this evening:

http://www.nasa-virtual.com/project_apollo/instrument_panels/lm_panel_management.jpg

It will be labeled soon. All panels are wide screen, except the LPD window (for now).

Work in progress:

A2 - Overhead Hatch
A3 - Forward Hatch
B2 - ECS controls / Water Control Module

I thought it would be also nice to get a new COAS...

(http://onfinite.com/libraries/1520721/7d7.jpg)


Title: Re: LM status...
Post by: Swatch on September 14, 2009, 07:52:28 PM
Looks great... but do you think you could make the displays in the background of the AOT dark?  In otherwords, make it look like the AOT and its controls are brightly lit, while the rest falls into the background.  If you want to REALLY make it cool, add a soft focus on the stuff that's in the background and it will give you a better feel of looking in the telescope.  (if you don't quite understand what I mean, send me the .psp file... I should be able to show you with it)

(yes I know this is purely cosmetic... but I'm picky... :)  )


Title: Re: LM status...
Post by: NoName on September 14, 2009, 08:04:46 PM
Well, I already tried to let it look darker but it doesn't look that much good. I think I give it try to let the AOT and its controls look brightly lit. We'll see. I'll post the results...

By soft focus you probably mean to blurry the background? That's already done but not quite visible on the small preview.


Title: Re: LM status...
Post by: Coussini on September 15, 2009, 08:11:12 AM
Check this page

http://www.space1.com/Artifacts/Lunar_Module_Artifacts/Optical_Sight__COAS_/optical_sight__coas_.html

Check the purple color of the Lens here (probably a filter incorporate in this lens):



Title: Re: LM status...
Post by: NoName on September 15, 2009, 12:12:39 PM
Thanks Coussini. Those images helped to finish the COAS finally :ThumbsUp432:

(http://onfinite.com/libraries/1520866/e72.jpg)


Swatch, do you think the AOT panel looks better this way?

(http://onfinite.com/libraries/1520867/ae5.jpg)





Title: Re: LM status...
Post by: retro on September 15, 2009, 01:32:27 PM
wow awesome !!


Title: Re: LM status...
Post by: Coussini on September 15, 2009, 01:32:36 PM
You're welcome  :ThumbsUp432:

Great result.... Thanks


Title: Re: LM status...
Post by: Swatch on September 15, 2009, 06:33:10 PM
yes, much better   :ThumbsUp432:


Title: Re: LM status...
Post by: vrouleau on September 16, 2009, 01:27:01 PM
The branch does compile for me under VC2008 since changes to LEMresource.rc. It is now including

#include "afxres.h"

instead of

#include "winresrc.h"


Should the VC2008 project file include new system paths?


Title: Re: LM status...
Post by: dseagrav on September 16, 2009, 03:10:32 PM
It should do whatever it did before it was regenerated.
barry let VS regenerate it and VS deliberately breaks compatibility with older versions so you have to upgrade all of your developers at the same time.
It needs to work in VS6 and newer.

Edit:
Contrary to what MS wants you to believe, VS will NEVER "do the right thing" if you let it regenerate projects or resource files or whatever - It will always kick you in the teeth in such a way that maximizes MS profits. Files will always get written in newer (incompatible) formats. This serves to force all developers of a given company to upgrade all at the same time (meaning you must buy many copies of VS all at the same time instead of spreading them out over a period of time) and also to prevent or hamstring people who use other products that read VS files.

If you want something done right, do it yourself.


Title: Re: LM status...
Post by: Tschachim on September 16, 2009, 03:43:05 PM
Should be fixed.


Title: Re: LM status...
Post by: vrouleau on September 16, 2009, 04:30:17 PM
I see now that ProjectApolloMFD now has the code to update time& state vector in the LEM vAGC.  I would like to try to power up the LEM and do some orbital manouvers.
Ddeagrav, are electrical system complete enough to power up the LEM, RCS ans DPS? If so, can I use the Apollo 15 LM activation checklist (a15lmact.pdf) to try to power up? I would like ( if I may...) to start updating "Apollo 11 Flightplan Basic.xls" and creating a new "Apollo 11 Flightplan vAGC.xls" with those procedures. Tschachim, would it be fine to document the flight plan referencing LTMFD instead of IMFD?


Title: Re: LM status...
Post by: Tschachim on September 16, 2009, 04:42:34 PM
Tschachim, would it be fine to document the flight plan referencing LTMFD instead of IMFD?

Yes.  :)


Title: Re: LM status...
Post by: dseagrav on September 16, 2009, 04:46:08 PM
I see now that ProjectApolloMFD now has the code to update time& state vector in the LEM vAGC.  I would like to try to power up the LEM and do some orbital manouvers.
Ddeagrav, are electrical system complete enough to power up the LEM, RCS ans DPS? If so, can I use the Apollo 15 LM activation checklist (a15lmact.pdf) to try to power up? I would like ( if I may...) to start updating "Apollo 11 Flightplan Basic.xls" and creating a new "Apollo 11 Flightplan vAGC.xls" with those procedures. Tschachim, would it be fine to document the flight plan referencing LTMFD instead of IMFD?
The MFD stuff is absolutely untested. All it does is send keystrokes.
I haven't checked that the SV and time uploaded are actually correct or going to the right addresses. The IMFD parts of it are absolutely non-functional.

There is no interface to DPS or APS because those systems are not implemented at all.
There is an incomplete interface to the RCS but it doesn't orient properly - it continually bounces off the deadbands. The RCS values are correct, so that means the LM mass properties (inertia, CoG) are likely wrong. This will cause untold problems if you light the DPS, so the RCS must be solved first.

I'm still working on the LEM telemetry client.

FYI I am working from the Apollo 12 checklists. Apollo 15 used a newer, different model of LM that we aren't simulating yet.

I am not interested in landing a barebones LM on the moon and do not suggest that we do that. We already missed the anniversary so there is no point in rushing. I am going through the checklist one subsystem at a time and doing things in order so that I can do the checklist as originally published. This includes passing all of the checkout tests. We shouldn't fall prey to "Go Fever" unless we want an Apollo 1 of our own.


Title: Re: LM status...
Post by: Swatch on September 16, 2009, 05:07:30 PM
Yea... sad we missed the aniversary... but there's always the 50th.... :)


Title: Re: LM status...
Post by: vrouleau on September 16, 2009, 06:43:42 PM
My intention wasn't to rush down to surface. I see now that the LEM is far from that. I would like to contribute by testing code and updating procedures. So, for now, I can at least update the flight plan for A11 up to LOI with vAGC ( TLI,MCC, barbecue rolls, etc).

I did notice the RCS behavior ~4 weeks ago. It was firing thrusters left&right trying to keep the attitude.


Title: Re: LM status...
Post by: NoName on September 18, 2009, 05:50:43 PM
Well, by watching new photos of the Lunar Module instrument panels (from spaceaholic.com and other sources) I had to realize that the colours of our mission timer and digital propulsion displays do not match the real displays. The same case happened to the screws of the Lunar Module instrument panels. We want the maximum possible realism, don't we? ;)

So I did some "last minute" changes which in fact turned out to become "last hours" changes. But it's done finally and looks quite nice I think. While I'm going to put any new LM panel graphics into our project right now finally (as far as possible at my side), enjoy the preview of the final version...

(http://onfinite.com/libraries/1521859/382.jpg)

(http://onfinite.com/libraries/1521860/24f.jpg)


http://www.nasa-virtual.com/project_apollo/instrument_panels/lm_panel_management.jpg


PS: By looking at the new DEDA, you may notice the real Apollo buttons that I used. So you can guess that I'll also update all the DSKY buttons (potentially its numbers too) and the mission timer colour of the CM instrument panel as it also does not fit to the real one I noticed (and by the way, I got a very nice and clear shot of the EMS display... ;)).


Title: Re: LM status...
Post by: Tschachim on September 18, 2009, 06:16:58 PM
...and by the way, I got a very nice and clear shot of the EMS display... ;).

Could you post it? I was just looking for one with details of the G scribe.

The new panels are looking great!  :)


Title: Re: LM status...
Post by: NoName on September 18, 2009, 06:23:36 PM
...and by the way, I got a very nice and clear shot of the EMS display... ;).

Could you post it? I was just looking for one with details of the G scribe.

(http://farm4.static.flickr.com/3440/3261867442_e6ec1e67b8.jpg)

The new panels are looking great!  :)

Thanks :)


Title: Re: LM status...
Post by: Coussini on September 18, 2009, 06:34:00 PM
Great job.... very exciting !


Title: Re: LM status...
Post by: Tschachim on September 18, 2009, 06:38:17 PM
 :ThumbsUp432:


Title: Re: LM status...
Post by: NoName on September 19, 2009, 09:55:08 AM
I'm having problems changing the stage switch on panel 8 to a guarded stage switch.

Does "GuardedToggleSwitch" not work for the Lunar Module?


Title: Re: LM status...
Post by: barry on September 19, 2009, 12:49:54 PM
I was also wondering about the Rate of Descent 3-way toggle. Is it on one of the other panels? I think that is also supposed to be on Panel 8. This is the switch that allows the tell the LGC to increase or decrease the descent rate by 1 fps.


Title: Re: LM status...
Post by: dseagrav on September 19, 2009, 01:33:01 PM
I'm having problems changing the stage switch on panel 8 to a guarded stage switch.
I have no idea actually, I can't think of anything else that uses it.
What problem are you having?


Title: Re: LM status...
Post by: NoName on September 19, 2009, 02:46:39 PM
I'm having problems changing the stage switch on panel 8 to a guarded stage switch.
I have no idea actually, I can't think of anything else that uses it.
What problem are you having?

I get error messages during compiling whenever I use GuardedToggleSwitch instead of ToggleSwitch for the staging switch on panel 8. But I'm not a coder actually (I'm just a kind of panel editor). So I might miss something. But I did it the same way we do for CSM panels. So my impression is that the GuardedToggleSwitch does not work for the Lunar Module for some reason.

So, I guess that I put in all the new bitmaps, correct its positions wherever required, and leave the two guarded switches out so that you professional guys can have a look ;) It's just two guarded switches for the LM as far as I know: it's the staging switch on panel 8 and the abort button on panel 1. I've already done all required bitmaps. So you'll just have to look how to make it work.


Title: Re: LM status...
Post by: dseagrav on September 19, 2009, 02:50:36 PM
Can you post the error message for me?
I looked and GuardedToggleSwitch is supposed to be declared in toggleswitch.h which should be visible to the LM...


Title: Re: LM status...
Post by: NoName on September 21, 2009, 02:49:03 PM
Done.

All new LEM panels are now available and working well, so far. I sadly did not manage to set up the guarded stage switch on panel 8 and the new guarded abort button on panel 1. I use the German version of VC6 so posting the error messages would take some time, or is there a chance to change the language? But anyway, I would like to give that job to our advanced coders. The bitmaps are available of course: "LMAbortButton.bmp" and the new "lem_stage_switch.bmp". Areas have been defined. The stage switch basically is set up but disabled so you can look for errors. The new abort button has to be set up (but I have changed the corresponding area already). The right abort button is guarded as far as I know (it obviously can be lifted up). Just look at the bitmap. Also, a new "lem_small_button.bmp" is available for those small round buttons.

The parts of the main panel on the left and right window views also do work now, simultaneously with the same switches on the full main panel. But I don't know if I chosed the correct way to do so.

I did not change the arrangement of the panels the way we see it on the diagram below. So anybody may want to do that...

I noticed that the X-Pointer gauge is going to work. There are bitmaps for the needles availabke for some time already: "vel_accel_indicator_needles.bmp". They are curved just like the X-Pointer gauge was curved. Just wanted to mention that. Maybe you would like to use them dseagrav?

Ordeal: there is a LEM ordeal available now: "lem_ordeal.bmp". I think we should add it to the left panel as a pop-up panel. What do you think?

PS: the "thumbwheel_large_fonts_inv.bmp" is obsolete now ;)


Swatch:

I did one more update of the AOT panel. I think it looks quite nice now. Also have a look for the "lem_aot_mark_knob.bmp" and "lem_aot_reject_knob.bmp". You can make the AOT computer control work now. By the way, I've added a sound to the shaft knob, but it's the wrong one for now (it's actually a button sound). I don't know how to correctly add the thumbwheel sound...


So, have fun with the new panels anyway. I hope you all like it.

http://www.nasa-virtual.com/project_apollo/instrument_panels/lm_panel_management.jpg



Title: Re: LM status...
Post by: retro on September 21, 2009, 03:37:16 PM
I would luv to see the panels but i dont know how to compile
the  modules  :gloomy3353:
retro


Title: Re: LM status...
Post by: dseagrav on September 21, 2009, 04:02:41 PM
Grand, I'll update when I get home and see what happens.


Title: Re: LM status...
Post by: NoName on September 21, 2009, 04:31:29 PM
I knew that I forgot something to mention:

barry, you need to update the keypad of the DEDA (positions of the buttons). The new bitmaps are available.

I would luv to see the panels but i dont know how to compile
the  modules  :gloomy3353:

I think there'll be another beta module update not too long in the future ;)


Title: Re: LM status...
Post by: barry on September 22, 2009, 06:44:10 AM
Quote
barry, you need to update the keypad of the DEDA (positions of the buttons). The new bitmaps are available.

Checkpoint commit: Updated DEDA to support new buttons and digits


Title: Re: LM status...
Post by: NoName on September 22, 2009, 06:59:18 AM
Quote
barry, you need to update the keypad of the DEDA (positions of the buttons). The new bitmaps are available.

Checkpoint commit: Updated DEDA to support new buttons and digits

Great.

By the way, I forgot to mention that I've noticed something that is unrealistic: When the DEDA is unpowered, you don't see the buttons pressed in when you push them. You don't also see them pressed in when the OPR ERR light is illuminated while you bush the buttons.


Title: Re: LM status...
Post by: barry on September 22, 2009, 07:37:16 AM
Quote
By the way, I forgot to mention that I've noticed something that is unrealistic: When the DEDA is unpowered, you don't see the buttons pressed in when you push them. You don't also see them pressed in when the OPR ERR light is illuminated while you bush the buttons.

Commit: DEDA buttons animate even if unpowered or Error Light lit.


Title: Re: LM status...
Post by: NoName on September 22, 2009, 08:33:18 AM
Quote
By the way, I forgot to mention that I've noticed something that is unrealistic: When the DEDA is unpowered, you don't see the buttons pressed in when you push them. You don't also see them pressed in when the OPR ERR light is illuminated while you bush the buttons.

Commit: DEDA buttons animate even if unpowered or Error Light lit.

Wow. That was quick :)


Title: Re: LM status...
Post by: barry on September 22, 2009, 03:41:50 PM
You caught me when I was working actively working on it.

BTW The DSKY and the DEDA now have two different button animations. Do you think it is worth re-laying out the DSKY keys the same way you did for the DEDA? Hopefully it would not involve any code tweaks if the button sizes and spacing are the same...

Right now, I am staring at the AEA engine code, and the FP6 flight program for the AGS. I am anticipating a reasonable sized learning curve before the code gets working properly. I am hoping that it will function properly with just the DEDA IO channels working, then the telemetry (used to download from the AGC), and then the ASA (both of which will require a properly aligned and functioning LGC for validation).

I am out searching for a joystick as I write this...


Title: Re: LM status...
Post by: NoName on September 24, 2009, 07:31:16 AM
Do you think it is worth re-laying out the DSKY keys the same way you did for the DEDA?

That's my intention. The DSKY's, the COAS and the mission timers of the CSM panels will get one more update.

Hopefully it would not involve any code tweaks if the button sizes and spacing are the same...

It might involve slight code tweaks...

I'll also have to look for and learn the button positioning method of the DEDA, since I've noticed that the animations do not match their intended positions on the pixel exactly, which I think they should. I'm perfectionist on that. My eyes catch any button/switch/gauge etc. which has not been positioned on the pixel exactly :wink: As long as I know how to correct it, I do it. I already did it for the entire Apollo panels. But the DEDA keys is the only exception at the moment.


Title: Re: LM status...
Post by: dseagrav on October 17, 2009, 09:41:10 AM
Final word on the altitude/range tape: It's calibrated in feet up to 120,000 and then turns to NM up to 400.


Title: LGC Software
Post by: pattersoncr on October 20, 2009, 08:47:22 PM
With work proceeding on the LM, I've started to dig thru LM checklists to compile the required Word Checklists (see the Word Documentation thread for my planned approach).  I have several questions:
I know that the LM software evolved significantly over the course of the Apollo program specifically the landing programs (P60's).  Do we know what software version we will be simulating?  What mission was this version flown on?  Do we plan to simulate more than one version?  I've so far only found one good detailed document covering LCG operations, the A12 LM C&G Dictionary (available from ALSJ).  Does anyone know of any other sources?


Title: Re: LM status...
Post by: dseagrav on October 20, 2009, 10:40:07 PM
Luminary 099.
Apollo 11.
Yes.
No.


Title: Re: LM status...
Post by: NoName on November 11, 2009, 05:36:15 AM
Any news on the LEM progress? :)

Today in two weeks my exam will be finished and hopefully passed. I'll be back then finally...



Title: Re: LM status...
Post by: dseagrav on November 11, 2009, 08:45:43 AM
I'm still here - I've been doing lots of reading, and I'm getting a good understanding of how it was put together and how the landing was actually done. So far I've determined we're going to need quite a bit more assistance from "mission control" than the CM needs. I'm also going to have to find someone who understands all that inertia tensor and so on type stuff and have them go over the LM physical properties and make sure they match reality.
I'll be posting more stuff before too long.



Title: Re: LM status...
Post by: NoName on November 13, 2009, 02:16:43 AM
Okay. I'll pickup my work on the remaining parts of the panel end of next week I think. So the LEM panels should be complete still this years.


Title: Re: LM status...
Post by: Swatch on November 15, 2009, 11:02:44 PM
Do we have the horizontal/vertical movement indicator working yet?  (The X-PNTR)

(http://history.nasa.gov/alsj/xpoint.jpg)


Title: Re: LM status...
Post by: dseagrav on November 16, 2009, 05:28:01 AM
No, the radar doesn't work yet, so the x-pointer has no input. There is (was?) something that drew the lines on the screen, I think, so it just needs input.
I haven't looked at it, I was working on the RCS and LGC.


Title: Re: LM status...
Post by: Graham2001 on December 05, 2009, 06:55:38 PM
Luminary 099.
Apollo 11.
Yes.
No.


I've found some documentation dealing with proposed changes to the LM descent guidance programming that might be worth a look at.

Called Delta (Δ) Guidance the changes were supposed to increase landing accuracy and reduce fuel consumption. Much of the supporting documentation is also online at the NTRS.

See: The use of delta guidance for improved trajectory control and fuel cost during LM descent (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072465_1979072465.pdf).

Also possibly of interest is a 1971 paper on the LM guidance equations from MIT, Delta (Δ) Guidance is discussed as 'Implicit Guidance'.

See: Apollo, Guidance Navigation and Control: Apollo Lunar Descent Guidance (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19760073526_1976073526.pdf)

Edit: Here are the remaining documents I found on Delta (Δ) Guidance.

1. Guidance laws for controlling off-nominal LM powered descent trajectories back to the nominal. Project Apollo (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700026559_1970026559.pdf), the original proposal, also discusses the initial testing of the concept.

2. Δ-RLS updates during the breaking phase of LM descent using Explicit and Delta Guidance (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072388_1979072388.pdf)

3. Δ-V cost of updating the landing site during the LM descent braking phase (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790073030_1979073030.pdf)

4. The effect of vehicle performance of thrust and Isp variations due to delta guidance thrust modulations (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072983_1979072983.pdf)


Title: Re: LM status...
Post by: NoName on January 24, 2010, 09:19:54 AM
Any 'secret' news/progress on the Lunar Module systems? :)


Title: Re: LM status...
Post by: dseagrav on January 28, 2010, 04:34:11 PM
Nope, sorry.
Been working lately.


Title: Re: LM status...
Post by: NoName on January 29, 2010, 10:56:28 AM
Okay.


Title: Re: LM status...
Post by: dseagrav on February 18, 2010, 08:04:00 PM
I put the pad load for Apollo 11 in the LM; If you delete all of the LGC EMEM lines from your scenario, you will get a clean pad load.
This is apparently the real as-flown pad load, so everything should work properly as far as the program is concerned.

RCS still bounces badly, something in the CG or mass must be screwed up.

Did we get anywhere with the ECS stuff?


Title: Re: LM status...
Post by: vrouleau on February 18, 2010, 09:27:00 PM
I was wondering, had there been similar problems when vAGC was introduced in the CSM? Mass of the LM should be ok. When I did the CSM+LM LOI, the CSM vAGC managed the burn right on. And the CSM vAGC is able be manage the stability of the couple using the CSM RCS thrusters. Could it be the LEM RCS are too powerfull? When I played with the LEM last August, It was wobbling but it did manage to keep attitude. It seemed the thrusters were over-correcting. So I guess my question is: had the CSM RCS thrusters been tweaked when vAGC introduced in the CSM? Who worked on the RCS then?


Title: Re: LM status...
Post by: Tschachim on February 19, 2010, 05:36:54 AM
So I guess my question is: had the CSM RCS thrusters been tweaked when vAGC introduced in the CSM? Who worked on the RCS then?

I have worked on the RCs and AFAIR thrust was too big at first and is fixed now, but that didn't cause much trouble. I've no clue about the LM though...


Title: Re: LM status...
Post by: dseagrav on February 19, 2010, 09:51:38 AM
I was wondering, had there been similar problems when vAGC was introduced in the CSM? [...] had the CSM RCS thrusters been tweaked when vAGC introduced in the CSM? Who worked on the RCS then?

Yes, there were issues. I messed with the CM RCS at one point. The jets had been arranged around the center of mass instead of where they were actually located and I think they had extra power. We fixed that by moving them to where they were supposed to be. I think I have the LM jets where they are supposed to be, and I think the thrust is correct - I even tried lowering the output and modeling the thrust curve with no effect, the LM still bounced around inside the deadband, so I think the CG or mass is the issue. I can't imagine it did this in real life.


Title: Re: LM status...
Post by: vrouleau on February 19, 2010, 02:09:11 PM
Could it also be PIPA pulsing to much making vAGC thing its rotating faster then it actually is? But then, it is the same code as the CSM.


Title: Re: LM status...
Post by: dseagrav on February 19, 2010, 03:18:45 PM
Could it also be PIPA pulsing to much making vAGC thing its rotating faster then it actually is? But then, it is the same code as the CSM.
Not likely, because when I request DAP maneuver to aim a given direction, it points the right direction and the right amount.


Title: Re: LM status...
Post by: dseagrav on May 10, 2010, 01:50:48 AM
I added the CWEA lights bitmap to the LM and started putting that together. I have VS2008, and I don't know if this breaks the project files for the other VS versions, can someone please check on that and adjust them if needed?


Title: Re: LM status...
Post by: vrouleau on May 10, 2010, 08:11:44 AM
Fixed the VC2010 to match your commit. VC2005 needs to be fixed now.

P.S. I also changed LEMResources.rc, it has a hardcoded path in your C: drive.


Title: Re: LM status...
Post by: dseagrav on May 10, 2010, 10:31:16 AM
Figures. I really dislike VS's handling of this sort of thing.


Title: Re: LM status...
Post by: dseagrav on May 22, 2010, 07:28:49 PM
Moonwalker, next time you're in the LM mood, I need a bitmap for a lit-up "component caution" light (The little button-looking thing scattered around the panel, for example near the "CO2" and "H2O SEP" notes under the quantity monitor rotary) and a lit version of the little "power failure" warning lights over certain gauges on panels 1 and 2 (the little square thingy above the ECS pressure, quantity, glycol gauges, etc)

I also still need a sound file for the LM Master Alarm and a panel and such for the ECS controls.


Title: Re: LM status...
Post by: NoName on June 09, 2010, 04:19:15 AM
Moonwalker, next time you're in the LM mood, I need a bitmap for a lit-up "component caution" light (The little button-looking thing scattered around the panel, for example near the "CO2" and "H2O SEP" notes under the quantity monitor rotary) and a lit version of the little "power failure" warning lights over certain gauges on panels 1 and 2 (the little square thingy above the ECS pressure, quantity, glycol gauges, etc)

Sorry that I answer late. You mean those button-looking things and the red little things above the gauges were actually small lights? I obviously misunderstood their functionality :ROTFL3453: Are they supposed to illuminate in red colour? And the button-looking lights in yellow (like usual for caution lights)?

I also still need a sound file for the LM Master Alarm and a panel and such for the ECS controls.

Does the Master Alarm inside the LM sound different than inside the CM? If no, I think we could use the same sound file. I don't yet have an idea how the Master Alarm inside the LM sounded like...

The ECS panel is on my list ;)


Title: Re: LM status...
Post by: dseagrav on June 09, 2010, 08:32:58 AM
Sorry that I answer late. You mean those button-looking things and the red little things above the gauges were actually small lights? I obviously misunderstood their functionality :ROTFL3453: Are they supposed to illuminate in red colour? And the button-looking lights in yellow (like usual for caution lights)?
The power failure indicators are red. The color of the component caution lamps was not noted.
Quote
Does the Master Alarm inside the LM sound different than inside the CM? If no, I think we could use the same sound file. I don't yet have an idea how the Master Alarm inside the LM sounded like...
LM master alarm is a 3KHz tone, but I couldn't find any mention of it being interrupted at an interval.


Title: Re: LM status...
Post by: NoName on June 17, 2010, 01:34:41 AM
I'll do the bitmaps as soon as I have some time.

As for the master alarm sound: I sadly have no experiences to do such sounds from scratch. But maybe you have an advice how to do such a sound in case the only thing I have is an info about the frequency? Which specific software is required for that? The only thing I have at the moment is "Audacity".


Title: Re: LM status...
Post by: dseagrav on June 17, 2010, 08:57:40 AM
Oh, I'm sorry, I thought you made the CM tone, so I was going to leave it to you.
I honestly don't know for certain, I'd have to go digging around for it.


Title: Re: LM status...
Post by: NoName on June 19, 2010, 11:00:39 AM
Oh, I'm sorry, I thought you made the CM tone, so I was going to leave it to you.

I've just made the previous/old one. I simply recorded it from the Apollo 13 movie years ago. But I did not consider my own motto: don't rely on movies as sources ;)


Title: Re: LM status...
Post by: Kjellander on July 01, 2010, 05:06:17 AM
I'll do the bitmaps as soon as I have some time.

As for the master alarm sound: I sadly have no experiences to do such sounds from scratch. But maybe you have an advice how to do such a sound in case the only thing I have is an info about the frequency? Which specific software is required for that? The only thing I have at the moment is "Audacity".

Audacity works fine for generating tones. Track/Add New/{Audio Track or Stereo Track}, then  Generate/Tone with the frequency 3000 and volume between 0.0 and 1.0. Remember that 1.0 is very loud at 0 dB, and each halving is -6 dB so 0.5 is -6 dB, 0.25 is -12 dB, 0.125 is -18 dB and so forth, and I recommend one of the latter two. After this you have to remember that just turning on a tone on full volume will produce nasty pops, so select the first 0.02 seconds and do Effect/Fade In and the last 0.02 seconds and Effect/Fade Out. Then klick ">>|" to get to the end and Generate/Silence. To listen to it just Shift-click on Play to listen to it loop. 1 s tone, 1 s silence is probably a good starting point.

When done, just export the track to Wav.



Title: Re: LM status...
Post by: dseagrav on August 14, 2010, 02:46:06 PM
Did someone make a change that invalidates CSM scenarios? I just updated hoping it would allow 2010 to exit cleanly instead of hanging, and now my test scenario (which worked previously) loads with a CSM master alarm (FC bus disconnected, cycling the FC bus switches resets it) and both DSKYs dead. There is no CWS light for the CMC, and no alarm. The CMC is still running. Resetting the computer CBs generates master alarm while the CBs are out but doesn't bring back the DSKYs.

Oh, and exiting on 2010 still hangs.

Edit: The CMC itself is alive, only the DSKYs are dead.



Title: Re: LM status...
Post by: vrouleau on August 14, 2010, 07:49:57 PM
Fyi, my CSM/lm Apollo 11 scenario ( from 2009...) were not working for me either under 2010. I was in the process of re-flying the stack post tli to get in a LM in a testing state...


Title: Re: LM status...
Post by: Tschachim on August 16, 2010, 04:35:19 AM
...and now my test scenario (which worked previously) loads with a CSM master alarm (FC bus disconnected, cycling the FC bus switches resets it) and both DSKYs dead.

Sorry for that, I haven't posted about all my changes yet. The DSKY problem is due to this change I suppose: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=848.msg19954#msg19954, the FC bus disconnect is because of a change in the scenario format because of this - meanwhile fixed - bug: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=673.msg19506#msg19506

Cheers
Tschachim


Title: Re: LM status...
Post by: vrouleau on September 15, 2010, 07:01:57 AM
Hi dseagrav,

I was reading "Apollo Guidance Computer - Architecture & Operation" (see http://www.apolloguidancecomputer.com) and I stumbled on something on page 51. It is mentioned that for the CSM one pulse count of a PIPA represents 5.85cm/sec. But for the LM it represents 1 cm/sec. In IMU.cpp:

...
         pulses = RemainingPIPA.X + (accel.x * deltaTime / 0.0585);
...
         pulses = RemainingPIPA.Y + (accel.y * deltaTime / 0.0585);
...
         pulses = RemainingPIPA.Z + (accel.z * deltaTime / 0.0585);


PIPA representation is always 5.85cm/sec regardless on CSM or LM simulation step. The 0.0585 needs to be 0.01 for a LM IMU. This could be a cause for the LM wobbling on AGC control. I would like do implement those changes and test stability of the LM attitude control. I now have re-ran the Apollo 11 scenario up to just before transpostion & docking. What is the current status of the LM electrical system and power-up procedure. Will I be able to power-up? Updated power-procedures? I see that you have done some changes last summer regarding RCS and updated the luminary99.bin. I was able to do that a year ago but have not done it since then.


Title: Re: LM status...
Post by: dseagrav on September 16, 2010, 12:10:04 AM
Yeah, you can power up. The AC bus is mandatory now and the DSKY dimmer is connected to the numeric lighting controls, so check that out if you have no DSKY.


Title: Re: LM status...
Post by: NoName on September 16, 2010, 10:52:45 AM
dseagrav,

I'm in the LM mood :) Just to avoid confusions, I'll post your required changes below to let you check if this is what you want to see:


The power failure warning lights?

(http://onfinite.com/libraries/1621632/be5.jpg)


The component caution lights?

(http://onfinite.com/libraries/1621631/f32.jpg)

I'm not sure if those lights were red or maybe white (or yellow?). But since the unlit lights look quite dark, I guess those lights were red:

http://www.ibiblio.org/apollo/Documents/LM-Panel-Sept1968.jpg


Title: Re: LM status...
Post by: dseagrav on September 16, 2010, 03:17:27 PM
The power failure warning lights are supposed to be red, but I am red/green colorblind (deficient) and I can't see the difference between the on and off states. Do you think you can darken the color used for the off state without sacrificing anything?

As for the component caution lights, I haven't found any mention of colors yet. When I get home I can do more digging.


Title: Re: LM status...
Post by: NoName on September 17, 2010, 08:40:57 AM
The power failure warning lights are supposed to be red, but I am red/green colorblind (deficient) and I can't see the difference between the on and off states.

Oh, I didn't remember in case I ever read about it ago. However, it's interesting. Because the difference between the on and off state is quite significant (just to let you know: the ECS PRESS light is illuminted). Now I can imagine what color blindness really means.

Do you think you can darken the color used for the off state without sacrificing anything?

Of course. Anything is possible ;)

Does this make a difference?

(http://onfinite.com/libraries/1621813/133.jpg)

As for the component caution lights, I haven't found any mention of colors yet. When I get home I can do more digging.

That would be great.


Title: Re: LM status...
Post by: Puma on September 17, 2010, 03:17:45 PM
For better details watch this video I recorded :
http://www.youtube.com/watch?v=ocQ-gQSHnAU

it was taken from the interactive apollo 11 landing site at nasa`s site:
http://www.nasa.gov/externalflash/apollo11_landing/


Title: Re: LM status...
Post by: NoName on September 17, 2010, 03:34:41 PM
For better details watch this video I recorded :
http://www.youtube.com/watch?v=ocQ-gQSHnAU

it was taken from the interactive apollo 11 landing site at nasa`s site:
http://www.nasa.gov/externalflash/apollo11_landing/

I have that LM interior as a quicktime file already. But thanks anyway. Currently I'm working on the LM ECS/suit compressor controls, actually the last 2D instrument panel for NASSP (beside the 2D hatches for the LM) :)

I'm using these images as a reference:

http://www.hq.nasa.gov/alsj/FOB_lm_ecs.jpg

http://www.ehartwell.com/LM/pullo/CB_ECS2.JPG

http://www.ehartwell.com/LM/pullo/CB_ECS1.jpg


Title: Re: LM status...
Post by: Drako20 on October 14, 2010, 11:30:52 AM
Hi there!

First of all: many, many thanks to all developers for all this work and all the time you invest in this very special project! I'm more than grateful that I can simulate these important historical missions! I would love to do Apollo 9 and 10. So I would like an update on the last status of the LM.


Title: Re: LM status...
Post by: dseagrav on October 14, 2010, 11:38:02 AM
Moonwalker's working on panel images, after which I'm going to wire the panels in. vrouleau said he wanted to change the IMU to correct my oversight (PIPA counting is different from the CM) and I don't know what his status is.


Title: Re: LM status...
Post by: vrouleau on October 14, 2010, 12:14:42 PM
FYI. I commited the PIPA 1cm/s change for the LM last week.


Title: Re: LM status...
Post by: dseagrav on October 14, 2010, 12:43:53 PM
I'll pull it down when I get home and see how it does.


Title: Re: LM status...
Post by: dseagrav on October 15, 2010, 09:40:27 AM
Replying to cause notifications for people following the thread...

I tested vrouleau's PIPA correction and it seems to work fine. This means as soon as Moonwalker gets the ECS panels I can move forward in the activation checklist.
There are some PAMFD items we will need:
0) I forgot - Before LOI, ground uplinked the Landing Site REFSMMAT to the CMC, and the CMC used it for LOI. We need to be able to compute this.
1) For syncing clocks while docked, a display of CSM GET and TEPHEM, available from the LM.
2) For coarse alignment while docked, a display of CSM gimbal angles, available from the LM.
3) For IMU fine alignment while docked, ground calculated gyro torquing angles for fine alignment and voiced them to the LM. Need to calculate these.
4) Shortly before undocking, the ground calculated and uplinked the Landing Site REFSMMAT, LM & CSM State Vectors, LM & CM Clock Sync, PIPA Biases, and LGC Abort Constant.
5) After undocking, ground calculated and uplinked the DOI and Descent targets.
6) We will also need information for filling out the LM DOI pad and LM PDI pad. (And some abort pads, but we can ignore those.)

Edit: We need CSM GET, not mission time. (Both would be nice...)
Edit 2: I forgot about item 0.


Title: Re: LM status...
Post by: vrouleau on October 19, 2010, 03:12:41 PM
I have been scratching my head for a while now on the Landing Site REFSMMAT. So we have 3 problems:
1) Translating Orbiter orientation info into the REFSMMAT coordinate data ( ... or do we have that?)
2) Calculating the Orbiter landing site orientation in function of time...
3) ... and estimating the landing time. So that would be something lite : now +  orbit count remaining/orbit rate until PDI + estimate time to land from powered descent. Would we like the PAMFD to ask "in how many complete orbits will you initiate landing"

If nobody else is looking into this, I could dig more?


Title: Re: LM status...
Post by: dseagrav on October 19, 2010, 03:41:51 PM
The easiest answer to #3 is to simply get it from the user, in terms of mission time. They would just provide the time from the relevant flight plan.
Edit: The AGC coordinate system is defined in GSOP 5.1.4.


Title: Re: LM status...
Post by: vrouleau on October 20, 2010, 10:55:05 AM
For now, I've given up to try to calculate LS RESFMMAT. I'll use the scenario editor, Put the CSM headup and the belly oriented towards landing fly path, do a P51 and read the RESFMMAT from memory dump. I can do that at Apollo 11 land time and launch time. Anybody see something worng with that way of getting it?

Then, there is the uplink. The flightplans always refer to the LS RESFMMAT. Put nowhere do I see in Lumimary99 a memory location for LS REFSMMAT, nor any description on uploading it in http://www.ibiblio.org/apollo/NARA-SW/R-577-sec2-rev2.pdf, not in pattersoncr's G&C Checklist. I can't see how to 'P27' a LS REFSMMAT or set it in the LM PADLoad.



Title: Re: LM status...
Post by: dseagrav on October 20, 2010, 11:48:17 AM
Well, you'd want to read the gimbal angles, not the REFSMMAT.
As I understand it, the computer only knows one REFSMMAT, and to change them, you uplink a new one that replaces the old one.
Edit: To do some elimination of things, make it work with the CMC first, if you get everything right, then the CMC attitudes in the AP11 flight plan should match up.


Title: Re: LM status...
Post by: vrouleau on October 20, 2010, 02:26:18 PM
In P27 V71 there is
option 2   "CMC DESIRED REFSMMAT UPDATE"
option 3   "CMC REFSMMAT UPDATE"

I have not found documentation that describes the difference.

Shouldn't the gimbal angles be 0,0,0. Isn't the point of the LS RESFMMAT to have the FDAI angles to 0,0,0  upon touchdown. I would have figure put the CMC on the landing site, do a P51 to nullify the IMU gimbals there. Then get the resulting RESFMMAT from meme location 1732. That would be the data used in PAMFD when executing P27 V71 option 2 or 3 for Apollo 11 for example?


Title: Re: LM status...
Post by: dseagrav on October 20, 2010, 04:01:11 PM
Unless you have the REFSMMAT beforehand, they won't be zero.
The idea is to come up with a matrix that transforms the un-REFSMMAT'd gimbal angles to 0,0,0 at the right place and time.
So you'd "land" the CSM, do an align without the REFSMMAT, read the angles off, and use those angles to make a REFSMMAT that cancels them.


Title: Re: LM status...
Post by: vrouleau on October 20, 2010, 04:56:37 PM
... Ok I've tried but the problem is that is CSM "lands" on Moon belly down. I cannot "land" with the scenario editor with the CM up and SPS down so that the IMU X axis be pointed up as the LM on the surface...
Edit: Added scenario


Title: Re: LM status...
Post by: dseagrav on October 20, 2010, 05:36:49 PM
Well, that sucks. I guess we'll just have to figure out how to do it the hard way, then.


Title: Re: LM status...
Post by: eddievhfan1984 on October 21, 2010, 04:59:17 AM
Well, how is the Earth REFSMMAT determined, at launch?


Title: Re: LM status...
Post by: vrouleau on October 21, 2010, 06:22:18 AM
At CMC 'boot', it uses gravity to know where is 'down' and knows how the Saturn V sits on on launchpad and knows know it will launch at azimuth 'x' .

BTW, I've been re-read the flightplan. We still need a LS REFSMATT for the CSM to be align to prior the LM G&N powerup. That one is not the same as the LM LS REFSMATT?

1) upload CSM LS REFSMATT to ' CMC DESIRED RESFMATT'
2) P52 align to 'preferred' REFSMATT (which is the one just uploaded)
3) power LM G&N
4) upload LM LS REFSMATT to 'LM REFSMATT'
5) Transfer gimbal angles from CSM to LM . Coarse align.

Question is: What is the orientation of the CSM LS RESFMATT.  CM facing velocity vector heads down at the moon?


Title: Re: LM status...
Post by: dseagrav on October 21, 2010, 09:58:01 AM
Got it. For the CSM, the IMU X axis (roll) is parallel to the landing site vertical, pointing up. The Z axis (yaw) is in the direction of flight.


Title: Re: LM status...
Post by: vrouleau on October 21, 2010, 10:06:42 AM
Ok comfirmed then, they are the same: LM LS REFSMMAT = CSM LS REFSMMAT and the gimbal angle translation when copied into the LM is just for LM orientation difference when docked.

I wounder if I could just hack the CSM temporaly so that it 'lands' on the SPS and not the bottom of the SM. Do the alignement LS at land/lauch time for each mission to build up the LS REFSMATT database to hardcode in PAMFD.


Title: Re: LM status...
Post by: Tschachim on October 21, 2010, 10:22:33 AM
I wounder if I could just hack the CSM temporaly so that it 'lands' on the SPS and not the bottom of the SM.

Look for Saturn::SetCSMStage() in saturnmesh.cpp and add something like this after SetCOG_elev(3.5);:

SetTouchdownPoints(_V(0, -10, -3.5), _V(-10, 10, -3.5), _V(10, 10, -3.5));

You'll need to change the "3.5" to a proper COG elev, also you might need to change the signs of the other values for proper orientation.


Title: Re: LM status...
Post by: vrouleau on October 21, 2010, 10:24:31 AM
Wow, thanks. That was quick.  :ThumbsUp432:


Title: Re: LM status...
Post by: dseagrav on October 22, 2010, 02:11:20 PM
This may not be as hard as we are thinking.
When in the lunar SOI, the center of the coordinate system is the center of the moon.

GSOP 5.1.4.1 says:
The Basic Reference Coordinate System is an orthogonal inertial coordinate system whose origin is located at either the moon or the earth center of mass. The orientation of this coordinate system is defined by the line of intersection of the mean earth equatorial plane and the mean orbit of the earth (the ecliptic) at the beginning of the Besselian year which starts January 0.525, 1969. The X-axis is along this intersection with the positive sense in the direction of the ascending node of the ecliptic on the equator (the equinox), the Z-axis is along the mean earth north pole, and the Y-axis completes the right-handed triad.

So first we have to figure out where the lunar north pole was pointing on the conditions described above, then from that figure out which way the landing site points.
That would give us our REFSMMAT.


Title: Re: LM status...
Post by: eddievhfan1984 on October 22, 2010, 02:24:48 PM
Awesome. Can we also replicate the same "telemetry station" on Earth on the Moon to make those uplinks easier? Or does the Earth station handle lunar REFSMMATs as well?


Title: Re: LM status...
Post by: vrouleau on October 22, 2010, 02:32:36 PM
That would give us our REFSMMAT.

When do we tell the CMC that the BRCS is moon centered? In the LM software, it would be always assumed the BRCS in moon centered?

The LAND LS RESFMMAT is uploaded to the CMC before land and LIFT-OF LS REFSMMAT before lift-off? I have not seem where we tell the CMC that take RESFMMAT is moon centered? And I still don't know out to make the actual 9x9 matrix out of the orientation vector sitting on the ground. That is why I figured easier to do the alignment on the ground to (0,0,0)  and see the resulting REFSMMAT in  memory.


Title: Re: LM status...
Post by: dseagrav on October 22, 2010, 03:01:15 PM
GSOP 5.1.4.1 again: (rSPH is the radius of the lunar SOI)
This coordinate system is shifted from earth-centered to moon-centered when the estimated vehicle position from the moon first falls below a specified value (rSPH) and is likewise shifted from moon-centered to earth-centered when the estimated vehicle position from the moon first exceeds (rSPH). This procedure is described in Section 5.2.2.6 and Fig. 2.2-3. All navigation stars and lunar-solar ephemerides are referenced to this coordinate system. All vehicle state vectors are referenced to this system.


Title: Re: LM status...
Post by: vrouleau on November 01, 2010, 12:37:29 PM
Ok. So Have a scenario with the CSM oriented properly on Jul 20th at 20:17 on the landing site. From there I raised my altitude with the scenario editor to keep my orientation fixed and see more stars. But the problem is that I can't get P51 to do a proper alignment. The angle errors are off scale. I've also tries in earth orbit, I can't do a P51 anymore since run on orbiter2010 (Some changes where done in the EMEM data in the scenario)....

As anybody been able to run P51 since we migrated to orbiter2010?


Title: Re: LM status...
Post by: Tschachim on November 01, 2010, 02:28:38 PM
As anybody been able to run P51 since we migrated to orbiter2010?

I fear even worse, was anyone able to run P51 at all the last years?
http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2425.msg19830#msg19830 ?  :?


Title: Re: LM status...
Post by: dseagrav on November 01, 2010, 03:22:20 PM
I can test it when I get home.


Title: Re: LM status...
Post by: vrouleau on November 01, 2010, 04:31:29 PM
BTH, Were is my scenario file with the CSM oriented ready for P51


Title: Re: LM status...
Post by: dseagrav on November 01, 2010, 06:22:20 PM
I checked my scenario, and I can track stars fine. Something must be wrong with your procedure and/or scenario.


Title: Re: LM status...
Post by: Tschachim on November 02, 2010, 07:03:56 AM
I also did a couple of P51s (P52 is fine) with Apollo 7 in Earth orbit, some were working fine (star angle diff between 0° and 0.02°) while some "failed" (star angle diff about 60°). It seems to depend on the chosen stars, perhaps they mustn't be too far away from each other (similar to the "P03 boundaries" here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1751.0), I'll do more tests...


Title: Re: LM status...
Post by: vrouleau on November 02, 2010, 07:14:51 AM
Could you provide your Apollo 7 scenario and the star pair that was fine? I'll validate the way I do it with your scenario, then validate again with my Apollo 11 scenario.


Title: Re: LM status...
Post by: dseagrav on November 02, 2010, 07:50:01 AM
It seems to depend on the chosen stars, perhaps they mustn't be too far away from each other

Have you tried reading the source code used for the automatic star sighting assistance?
If there is such a requirement it would probably be covered there somewhere.
(Also, does any pair given to you by the auto star assistance ever fail?)


Title: Re: LM status...
Post by: Tschachim on November 02, 2010, 09:01:15 AM
Could you provide your Apollo 7 scenario and the star pair that was fine? I'll validate the way I do it with your scenario, then validate again with my Apollo 11 scenario.

Scenario is attached, star 45 and 02 should work fine.

Have you tried reading the source code used for the automatic star sighting assistance?
...
(Also, does any pair given to you by the auto star assistance ever fail?)

No and no.  :) 
I'll try to take a look at the Colossus code...


Title: Re: LM status...
Post by: Tschachim on November 02, 2010, 09:09:36 AM
Found something, Colossus 249 P51-P53.s line 689ff in the description of the PICAPAR routine:

A PAIR OF STARS HAVE GOOD SEPARATION IF THE ANGLE BETWEEN THEM IS LESS THAN 66 DEGREES AND MORE THAN 40 DEGREES.


Title: Re: LM status...
Post by: vrouleau on November 02, 2010, 09:15:16 AM
Yes, I when I did the P51, I choose the most distant... P51 should do a F 05 09 if the user picks  <40 >66 stars... Thanks, I'll try tonight.


Title: Re: LM status...
Post by: dseagrav on November 02, 2010, 11:19:32 AM
I THINK I FOUND THE ORIGINAL REFSMMAT LIST.
Wait while i confirm it.


Title: Re: LM status...
Post by: FordPrefect on November 02, 2010, 11:26:29 AM
I THINK I FOUND THE ORIGINAL REFSMMAT LIST.
Wait while i confirm it.


Oh boy, that sound too good to be true.


Title: Re: LM status...
Post by: Rex on November 02, 2010, 12:24:39 PM
another thing that would be nice to have is the T&D procedures and checklist, at least in pdf so people can practice it with A-9 i know its not LM specific but it is a key element
rex


Title: Re: LM status...
Post by: vrouleau on November 02, 2010, 01:04:25 PM
Check :
Doc\Project Apollo - NASSP\Word Checklists\Launch Checklist.doc

Starting page 4-1. The T&D procedures are pretty much up to date except for nulling the rate using the scenario editor. Its not need as the SIVB now is in attitude hold post TLI.


Title: Re: LM status...
Post by: dseagrav on November 02, 2010, 04:15:07 PM
It's not behaving the way I expect it to. What's the procedure supposed to be for putting a new REFSMMAT into effect?
I want to confirm I'm not doing it wrong.


Title: Re: LM status...
Post by: dseagrav on November 02, 2010, 07:19:55 PM
Reply to trigger notifications: I think I got it!

TO LOAD:
#                 V71E            CONTIGUOUS BLOCK UPDATE VERB
#                    24E          NUMBER OF COMPONENTS FOR REFSMMAT UPDATE
#                  1736E          ECADR OF `REFSMMAT'
#                 XXXXXEXXXXXE    ROW 1 COLUMN 1                                  2(-1)
#                 XXXXXEXXXXXE    ROW 1 COLUMN 2                                  2(-1)
#                 XXXXXEXXXXXE    ROW 1 COLUMN 3                                  2(-1)
#                 XXXXXEXXXXXE    ROW 2 COLUMN 1                                  2(-1)
#                 XXXXXEXXXXXE    ROW 2 COLUMN 2                                  2(-1)
#                 XXXXXEXXXXXE    ROW 2 COLUMN 3                                  2(-1)
#                 XXXXXEXXXXXE    ROW 3 COLUMN 1                                  2(-1)
#                 XXXXXEXXXXXE    ROW 3 COLUMN 2                                  2(-1)
#                 XXXXXEXXXXXE    ROW 3 COLUMN 3                                  2(-1)
#                 V33E            VERB 33 TO SIGNAL THAT REFSMMAT IS READY TO BE STORED

LANDING SITE REFSMMAT, APOLLO 11:

30754 13576
22346 10225
07617 06256
00075 11753
63333 73173
35332 30623
24013 21025
51046 41272
66100 43717

Someone else test and confirm?
If it's right, I'll translate and post the other REFSMMATs.


Title: Re: LM status...
Post by: vrouleau on November 02, 2010, 08:29:45 PM
Let me enter those into my .scn file with the CSM pointing up and p51 into 'current' resfmmat. I should get 0,0,0 gimbals. I'll get back to you...


Title: Re: LM status...
Post by: dseagrav on November 03, 2010, 09:49:22 AM
Is anyone flying Apollo 8?


Title: Re: LM status...
Post by: vrouleau on November 03, 2010, 10:47:23 PM
I manage to do P51&P52 with the CSM over the landing in in the proper orientation. I appended the scenario file. I 'landed' the CSM with the upright hack This is what I get as in REFSMMAT in EMEM 1735 to 1756:

  EMEM1735 14417
  EMEM1736 31562
  EMEM1737 11111
  EMEM1740 14164
  EMEM1741 3727
  EMEM1742 27344
  EMEM1743 77640
  EMEM1744 53206
  EMEM1745 71722
  EMEM1746 53530
  EMEM1747 16626
  EMEM1750 36644
  EMEM1751 11744
  EMEM1752 33312
  EMEM1753 64274
  EMEM1754 40123
  EMEM1755 73254
  EMEM1756 77567

So it's not what you get dseagrav. ( starting offset is 1735, isn't it?)
I'm also prototyping changes to the PAMDF to allow upload of : landing refsmmat & desired refsmmat, lift-off refsmmat &desired refsmmat. Tell me what you think...


Title: Re: LM status...
Post by: dseagrav on November 04, 2010, 12:33:26 AM
That's because when you do that, the stored "REFSMMAT" is the attitude prior to align.
Read the flowchart.

If you uplink the REFSMMAT I provided, then P52 option 2 (and wait forever while it torques around...) when you overfly the landing site, 0,0,0 should be straight up.


Title: Re: LM status...
Post by: vrouleau on November 04, 2010, 10:19:44 PM
FYI, I have commited changes to the PAMFD to uplink REFSMMAT data. This is the extent of the testing I have done.
- Using a my scenario with the CSM above landing site. Current REFSMMAT still at original launch REFSMMAT. P52 aligned
- Open PAMFD -> TELE ->LS to uplink LS Desired REFSMMAT to CMC.
- Did P52 Option 1 "Prefered"
- Alignment is now correct with gimbal at 0,0,0.
- Have appended the resulting scenario

The PAMFD detects if you are in CSM ( LS Desired REFSMMAT), in LM ( LS REFSMMAT at powerup) or in LM on surface ( LiftOff REFSMMAT).

The PAMFD usability for REFSMMAT update is consistent with SV update.




Title: Re: LM status...
Post by: dseagrav on November 04, 2010, 10:53:33 PM
Here are the other REFSMMATs for Apollo 8 (possibly flown) and Apollo 11 (apparently flown):
Please test these and report results.
There are more of them, I'm figuring out which ones are what mission.
There aren't any for Apollo 7.

Code:
OCTAL VALUE                    CONTENTS                                # NAME
                                                                        # APOLLO 8 - PRE-LAUNCH
 17726 24673                    2DEC     +.49747632                     #
 45503 63314                    2DEC     -.82399864                     #
 10533 05077                    2DEC     +.27118897                     #
 66175 44767                    2DEC     -.30486110                     #
 61243 75714                    2DEC     -.45874424                     #
 45225 53444                    2DEC     -.83463369                     #
 31772 05041                    2DEC     +.81214345                     #
 12510 10311                    2DEC     +.33253554                     #
 60521 46047                    2DEC     -.47941956                     #
                                                                        # APOLLO 8 - LOI-2
 53172 56270                    2DEC     -.64877632                     #
 52660 47331                    2DEC     -.66111865                     #
 63741 71137                    2DEC     -.37684405                     #
 02343 17216                    2DEC     +.07638412                     #
 56330 60634                    2DEC     -.54928435                     #
 32501 27403                    2DEC     +.83213712                     #
 47613 42566                    2DEC     -.75713590                     #
 20265 24166                    2DEC     +.51108595                     #
 15012 00532                    2DEC     +.40686164                     #
                                                                        # APOLLO 8 - ENTRY
 54366 76213                    2DEC     -.60992761                     #
 53040 46070                    2DEC     -.65428522                     #
 61542 66306                    2DEC     -.44710085                     #
 00347 02104                    2DEC     +.01410319                     #
 21607 17322                    2DEC     +.55514414                     #
 45306 57755                    2DEC     -.83163459                     #
 31265 21761                    2DEC     +.79233164                     #
 57442 43670                    2DEC     -.51354244                     #
 65353 63107                    2DEC     -.32937023                     #
                                                                        # APOLLO 11 - LAUNCH PAD
 43770 41515                    2DEC     -.87548513                     #
 14630 03566                    2DEC     +.39990946                     #
 10534 32031                    2DEC     +.27128992                     #
 77607 52511                    2DEC     -.00736495                     #
 21467 33577                    2DEC     +.55028486                     #
 45220 50473                    2DEC     -.83494450                     #
 60423 55654                    2DEC     -.48318894                     #
 50426 73476                    2DEC     -.73297954                     #
 60532 77744                    2DEC     -.47882090                     #
                                                                        # APOLLO 11 - PTC
 33554 36563                    2DEC     +.86602540                     #
 61244 46567                    2DEC     -.45872739                     #
 71504 74475                    2DEC     -.19892002                     #
 57777 77777                    2DEC     -.50000000                     #
 46446 50515                    2DEC     -.79453916                     #
 64763 44101                    2DEC     -.34453558                     #
 00000 00000                    2DEC     +.00000000                     #
 14566 06605                    2DEC     +.39784004                     #
 42510 55351                    2DEC     -.91745480                     #
                                                                        # APOLLO 11 - LANDING SITE
 30754 13576                    2DEC     +.78005170                     #
 22346 10225                    2DEC     +.57655390                     #
 07617 06256                    2DEC     +.24311512                     #
 00075 11753                    2DEC     +.00374214                     #
 63333 73173                    2DEC     -.39283134                     #
 35332 30623                    2DEC     +.91960294                     #
 24013 21025                    2DEC     +.62570389                     #
 51046 41272                    2DEC     -.71642806                     #
 66100 43717                    2DEC     -.30858630                     #
                                                                        # APOLLO 11 - PLANE CHANGE
 00071 13531                    2DEC     +.00350127                     #
 63326 72432                    2DEC     -.39313783                     #
 35330 24462                    2DEC     +.91947288                     #
 53461 72134                    2DEC     -.63758434                     #
 51234 42672                    2DEC     -.70922305                     #
 66277 56763                    2DEC     -.30081372                     #
 30515 31073                    2DEC     +.77037261                     #
 55214 50634                    2DEC     -.58518828                     #
 67714 60657                    2DEC     -.25314170                     #
                                                                        # APOLLO 11 - LIFT OFF
 24240 37075                    2DEC     +.63482498                     #
 26635 25037                    2DEC     +.71274769                     #
 11427 17440                    2DEC     +.29830849                     #
 00141 24553                    2DEC     +.00595991                     #
 63400 63524                    2DEC     -.39058749                     #
 35352 07365                    2DEC     +.92054649                     #
 30562 32141                    2DEC     +.77263296                     #
 55266 61463                    2DEC     -.58260803                     #
 67733 75142                    2DEC     -.25220262                     #
                                                                        # APOLLO 11 - ENTRY
 77672 71717                    2DEC     -.00422305                     #
 30560 31113                    2DEC     +.77250890                     #
 24243 25453                    2DEC     +.63498990                     #
 75522 42447                    2DEC     -.07311520                     #
 24204 00271                    2DEC     +.63305733                     #
 47255 70346                    2DEC     -.77064428                     #
 40053 77742                    2DEC     -.99731456                     #
 76321 77447                    2DEC     -.04968342                     #
 01561 22461                    2DEC     +.05380744                     #


Title: Re: LM status...
Post by: vrouleau on November 05, 2010, 06:13:33 AM
I will test the Apollo 11 PTC, Apollo 11 Landing Site and Apollo 11 List Off values and report back.

I don't have the setup to test The Apollo8 Entry, LOI of pre-launch. Isn't pre-launch calculated by P03?


Title: Re: LM status...
Post by: dseagrav on November 05, 2010, 08:02:16 AM
Yeah, I think it was just provided for reference. The others I found so far are for Apollo 10 and 12.


Title: Re: LM status...
Post by: vrouleau on November 07, 2010, 10:12:06 PM
I've tried your the REFSMMAT you provided, but I never get all balls on the alignment. I get
 F 06 05
+00415
which is not good. The FDAI is not bad, but not centered.
See attacements:
1 - CSM on landing site facing landing forward speed direction
2 - All balls after P52 'preferred' aligment from REFSMATT I uploaded taken from RESFMATT EMEM data in orbiter. This one is good.
3 - FDAI + DSKY after P52 at step F 06 05 after P52 'preferred' alignment from REFSMMATT you provided
4- same at step F 50 25.


Title: Re: LM status...
Post by: eddievhfan1984 on November 07, 2010, 10:48:00 PM
I just realized, are we doing this in reference to the actual landing point, or the one listed in the flight plan?


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 12:00:28 AM
vrouleau: The "preferred" alignment expects that a maneuver target be uploaded and causes the alignment result be biased for this target. I don't think that's the correct option in our case, since we don't have the maneuver target data and aren't doing a maneuver. I used the "Nominal" option (option 2). I did the align in lunar orbit, then tested that 0,0,0 was close to straight up when passing over the landing point. You might try that as well, to make sure that there isn't something screwing up the alignment if you do it while landed.
eddievhfan1984: This should be for the planned landing point, not the actual landing point.


Title: Re: LM status...
Post by: vrouleau on November 08, 2010, 08:15:53 AM
Note that I had added the upload feature in the PAMFD to uplink "preferered" REFSMMAT last week. You can update your CVS. So that is why I did the P51 with 'preferred' option as the CSM does prior to LM power-up as per the flightplan


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 09:29:15 AM
I did the P51 with 'preferred'
Did you mean P51 or P52? You should be doing P52.


Title: Re: LM status...
Post by: vrouleau on November 08, 2010, 09:30:25 AM
Sorry, yes I mean P52.


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 10:07:26 AM
Wait, what do you mean by uploading a "preferred" REFSMMAT? There's only one REFSMMAT.
The preferred target attitude is just a set of attitude. Hang on, I'll go look at the P52 source code.
You should be putting the REFSMMAT at 1736 for Comanche 55 or 1734 for Luminary 99.
 


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 10:28:23 AM
I think I figured out what's going on.

If you pick any option other than option 3 (PRESENT REFSMMAT), P52 does a coarse alignment to a new starting point before starting the alignment procedure.
When using option 1, the values in three erasable locations (XSMD, YSMD, ZSMD) are used as the starting point gimbal angles.
This means that if whatever is in XSMD,YSMD,and ZSMD are supposed to be close to your current attitude in the new REFSMMAT, as computed by the ground.
If they aren't, you'll get an increased angle error, since the starting point and ending point don't match up.
This must have been part of the uplinked data.

You can see what the coarse align target is by reading the data presented in flashing noun 22 just before the coarse alignment.
I'll hunt down the addresses for these so we can figure out what to do with it.


Title: Re: LM status...
Post by: vrouleau on November 08, 2010, 10:29:27 AM
You can also find in the source code that ground wants to uplink a change of REFSMMAT to the AGC then use memory location 306 (XSMD). This is the temporary location where the 'preferred' REFSMMAT is located and used during P52 option 1. See also the G&C word documents page 3.12 .During the P52 option 1, the gyro are torqued, then the REFSMMAT is copied to 1735 by the agc software. That is what I did when I did my original P52. The CSM was aligned to launch REFSMMAT. I did the upload to 'desired' REFSMMAT to memory location 306. I did a P52 option 1, it torqued the gyros and the AGC then copied the REFSMMAT to 1735 and then I was gimbaled 0,0,0 at the landing site.


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 10:43:24 AM
You're right, a REFSMMAT does go there. I thought it was a set of DPs.
I have no idea where the error is coming from then. I guess my numbers must be garbage.


Title: Re: LM status...
Post by: vrouleau on November 08, 2010, 10:54:03 AM
You mentioned  "1736 for Comanche 55". I read 1735  ( also from the G&N documents page 3-12)

003861,002240: E3,1735                        REFSMMAT          ERASE    +17D                                  #  I(18D)PRM
003862,002241:
003863,002242:                                                                                                 #  Page 87
003864,002243:                                                                                                 #  AVERAGEG INTEGRATOR STORAGE.           (8D)

how did you get them? for example,  should  30754 be at 1735 or 1736 for you?:
                                                                        # APOLLO 11 - LANDING SITE
 30754 13576                    2DEC     +.78005170                     #
 22346 10225                    2DEC     +.57655390                     #
 07617 06256                    2DEC     +.24311512                     #
 00075 11753                    2DEC     +.00374214                     #
 63333 73173                    2DEC     -.39283134                     #
 35332 30623                    2DEC     +.91960294                     #
 24013 21025                    2DEC     +.62570389                     #
 51046 41272                    2DEC     -.71642806                     #
 66100 43717                    2DEC     -.30858630                     #

To me, the biggest problem with that REFSMMAT is the star angles are totally off after a P52.


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 11:11:08 AM
I don't have any word documents for anything, all my stuff is PDFs.

I just read the generated value for REFSMMAT out of the listing.
See http://www.ibiblio.org/apollo/listings/Comanche055/P51-P53.agc.html - All the references to REFSMMAT go to 1736.

As for how I got the numbers, I found a set of documents with titles like "Operational spacecraft attitude sequence for Apollo 11"
See http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072577_1974072577.pdf
Table 3 on page 64 has the matrices.
There's a few documents like this.
Then I used YUL to translate the floating-point numbers into the double word float form the AGC wants.


Title: Re: LM status...
Post by: vrouleau on November 08, 2010, 11:45:33 AM
Sometimes its 1736, others its 1735 ( in P51-P53.agc.html ) depending on the instruction:

033888,001217: 14,3044           75160        FINEONLY          AXC,1    AXC,2                                 
033889,001218: 14,3045           02671                                   XSM                                   
033890,001219: 14,3046           01735                                   REFSMMAT

034568,001897: 13,2326           53521        COM52             MXV      UNIT                                 
034569,001898: 13,2327           01736                                   REFSMMAT 

Thanks for the link "9740072577_1974072577.pdf". Good stuff.


Title: Re: LM status...
Post by: dseagrav on November 08, 2010, 11:52:40 AM
It must be 1735 then. I wonder why it worked when I did it then? I'll have to mess with it more when I get home.


Title: Re: LM status...
Post by: dseagrav on November 09, 2010, 01:15:36 AM
OK, I did this multiple times to make sure I was doing it right. We are getting different results; One or the other of us must have a broken scenario, or something else is wrong.
For reference, you are correct, REFSMMAT is 1735.

I uplinked my proposed LS REFSMMAT to location 306 and did P52 option 1.
The sighting assistance proposed two stars, but didn't properly target them. Most of the error was in pitch in both cases.
I switched to manual and both cases and marked the stars it wanted. After this, I ended up all balls and got an attitude correction.
The resulting attitude is very close to straight up when passing the landing site.

I am attaching my scenario PRIOR TO REFSMMAT UPLOAD, so you can try it and see if you are getting the same results.



Title: Re: LM status...
Post by: meik84 on November 09, 2010, 05:43:30 PM
Quote
The sighting assistance proposed two stars, but didn't properly target them. Most of the error was in pitch in both cases.
I switched to manual and both cases and marked the stars it wanted. After this, I ended up all balls and got an attitude correction.
The resulting attitude is very close to straight up when passing the landing site.
I guess that's the same issue we're experiencing with P51: the coordinate system of orbiter does not coincide with the one of the AGC. I played around a little with AZO,AYO and AXO in AP7 and was able to fix it -for one point of time in the mission (star angle difference <00001), half an orbit later I was worse of (star angle difference far beyond good and evil). :(  I guess I understand how the AGC CS looks like (GSOP 5.1.4 gives a good idea of that) -but how does orbiters' earth (or moon, resp.) behave in relation to it? :?


Title: Re: LM status...
Post by: dseagrav on November 09, 2010, 05:51:53 PM
I never checked to see if it was drifting off once aligned; I'll test that when I get home.
I was under the impression that once it was aligned, it tended to stay aligned. (Minus normal drift of course)


Title: Re: LM status...
Post by: Tschachim on November 10, 2010, 11:26:11 AM
I guess that's the same issue we're experiencing with P51: the coordinate system of orbiter does not coincide with the one of the AGC. I played around a little with AZO,AYO and AXO in AP7 and was able to fix it...

Just in case you guys don't know, but the Apollo 7 pad load is (thanks to Jarmo) almost perfect with respect to time, coordinate systems, ephemeris, moon and sun position etc. AZO,AYO and AXO are the Earth's precession vector and must be 0 as our Earth has no precession. The only issue is that Orbiter's Earth (unlike its gravity field) is spherical (non-spherical planets are requested already), so latitude and altitude (in P21 for instance) isn't perfect.

The problem with P51 is either that the angular difference between the 2 stars is greater that 66° (see above) or the trunnion angle (as I figured out by testing) of either star is greater than 60°.

But only the Apollo 7 VAGC scenario (and I mean to remember the Apollo 8 scenario, including the Moon's SOI where the AGC is switching to a Moon centered coordinate system) are fine. I don't know which scenario you guys are using here, Apollo 11 is most probably NOT fine...

PS: Just in case it IS Apollo 11, we should try to do a correct Apollo 11 scenario, which should be possible, parts of the pad load can be generated with LTMFD, again thanks to Jarmo. Having said that, it might be a good idea to talk with Jarmo about this stuff here in case we don't get it working by ourselves...  :)

Cheers
Tschachim

EDIT: typos, PS


Title: Re: LM status...
Post by: dseagrav on November 20, 2010, 09:43:38 AM
(words words words)
I found another something on the panel for you to fix while you're at it.
On panel 16, the ECS CB labelled "LGC PUMP" should be labelled "LCG PUMP".


Title: Re: LM status...
Post by: vrouleau on July 07, 2011, 07:22:36 AM
I did a checkpoint commit on the LEM Rendez-vous radar. Can somebody test compiling in VS2005 and VS2008, I have modified the project files by hand since I only have VS2010.


Work in progress:

 - added persistence to the trunnion/shaft position
 - added calculation for range/range rate and CSM direction calculation
 - the slew panel joystick can now move the trunnion/shaft
 - input trunnion/shaft position to AGC. AGC can output drive the position of trunnion/shaft.

I am missing power consumption data. I only connected the DC power source to it but I know it electronics also need AC power.

I did not have any AGC pulse rate data for the RR so I took the same ones as the CSM optics. Since the CSM optics position uses the same AGC registers as the LM RR positon ( 035,036 ), I assumed the pulse rate was the same. Does anybody know where these values come from in CSMcomputer.h ?:

#define OCDU_SHAFT_STEP 0.000191747598876953125
#define OCDU_TRUNNION_STEP 0.00004793689959716796875

I would like to know what are the real values for the RR.

I was also looking a full LM GNC checklist. I was doing a V63 to initialize the RR as per LM activation checklist but I get a

F 50 25
R1 201

and I could not find any documentation that explains what the AGC ask for on the 201

P.S. The LM DAP works much better for me now. I've put the LM in attitude hold mode and it keeps the proper attitude now ( alone AND connected with an ildle CSM !). It doesn't wobble as before.


Title: Re: LM status...
Post by: meik84 on July 07, 2011, 08:24:21 AM
Quote
F 50 25
R1 201
Well:
V50: Please perfom
N25: the following checklist item:
201: 'switch rendezvous radar switch to automatic'

Don't anybody say that computers can't speak... :wink:


Title: Re: LM status...
Post by: vrouleau on July 07, 2011, 08:50:32 AM
Thanks, make sense, but can you provide the link to where you found what '201' means. I will probably stumble on other cases like this.


Title: Re: LM status...
Post by: meik84 on July 07, 2011, 09:26:10 AM
Well, I don't know which version of Luminary we use, but a great bunch of docs regarding it can be found here ->http://www.ibiblio.org/apollo/Luminary.html (http://www.ibiblio.org/apollo/Luminary.html). Note especially the GSOP for Apollo 13 and the Delco manual for Apollo 15 -those should fit (with minor deviations) the other versions, too.
Oh, and just to state it clear: 'automatic' has to be read as 'LGC'. 'Auto track' won't give the LGC the 'data good' discrete, I guess.


Title: Re: LM status...
Post by: vrouleau on July 07, 2011, 09:53:04 AM
Thanks. Found it in R-567-sec4-rev7-intro.pdf section 4.4.5. I need to turn on Channel 33 bit 5 for 'LGC' control and Channel 33 bit 2 when the data is good.


Title: Re: LM status...
Post by: Tschachim on July 07, 2011, 11:48:22 AM
Can somebody test compiling in VS2005 and VS2008, I have modified the project files by hand since I only have VS2010.

VS2005 compiles fine for me, thanks for working on the LM!  :)


Title: Re: LM status...
Post by: vrouleau on July 07, 2011, 01:21:25 PM
Its been so quiet for the past year, figure I needed to get back to it. Its summer time, I've got more time to work on it with the kids out of school ;). I need to touch the AGC to generate Radar interupt, and I was meaning on doing a cleanup to remove the AGC_SOCKET_ENABLED conditional define. Many thing already don't work with the remote virtual AGC ( namely, memory persistency) and will not implement/test new stuff on the remote AGC. How do you feel about removing this feature from the sim? This help cleanup the code, if this is not used anyways. I'm throwing this out to start debating it...


Title: Re: LM status...
Post by: vrouleau on July 08, 2011, 08:20:33 AM
I need to do the NO TRACK light graphics and I can't find detailed images of the rendez-vous panel. Is  Moonwalker around?


Title: Re: LM status...
Post by: Tschachim on July 08, 2011, 10:51:54 AM
How do you feel about removing this feature from the sim?

Go ahead, as you said it isn't used anymore anyway.


Title: Re: LM status...
Post by: meik84 on July 08, 2011, 11:47:03 AM
Quote
I need to do the NO TRACK light graphics and I can't find detailed images of the rendez-vous panel. Is  Moonwalker around?
According to this here-> www.ibiblio.org/apollo/OperatingHandbookLighting.pdf (http://www.ibiblio.org/apollo/OperatingHandbookLighting.pdf), component caution lights (to which I count the NO TRACK light) light up in 'aviation yellow', if you wanted to know that...


Title: Re: LM status...
Post by: vrouleau on July 08, 2011, 11:51:02 AM
Thanks. I add a new bmp to overlay on the NO TRACK light myself. I also need to the the RNDZ CAUTION cw light to yellow. Gez, your quick those non-text PDF....


Title: Re: LM status...
Post by: meik84 on July 08, 2011, 02:25:21 PM
Quote
Gez, your quick those non-text PDF....
As long as you don't come along with a 1202 prog alarm during descent... :wink:
Anyhow, how far do you want to go with this RR? I was a little bit surprised when I read that section of the LM handbook: the shaft and trunnion angles of the RR can be displayed on the FDAI error needles! :shock:


Title: Re: LM status...
Post by: irnenginer on July 08, 2011, 02:28:58 PM
Its been so quiet for the past year, figure I needed to get back to it. Its summer time, I've got more time to work on it with the kids out of school ;). I need to touch the AGC to generate Radar interupt, and I was meaning on doing a cleanup to remove the AGC_SOCKET_ENABLED conditional define. Many thing already don't work with the remote virtual AGC ( namely, memory persistency) and will not implement/test new stuff on the remote AGC. How do you feel about removing this feature from the sim? This help cleanup the code, if this is not used anyways. I'm throwing this out to start debating it...

I know, I have been away. I do want to give a quick 2 cents on keeping AGC_SOCKET_ENABLED, maybe. Mainly as a long term functionality. There has been some work done to create a hardware AGC Block 2 using a PLD. I could see that at some point it might be cool to be able to implement Project Apollo with that hardware acting for the AGC.
There may be better ways of implementing that the way it currently is so dumping it now may not be a problem. Just wanted to throw it out there.


Title: Re: LM status...
Post by: vrouleau on July 08, 2011, 02:40:14 PM
Well, I want to do it all, (XPointer ang velocity, FDAI error needles, etc.). No point in starting something if you don't finish it..

Maybe we done have enough info to simulate the RR test mode switch positions...

For the AGC on socket. The way its implemented now is wrong as a conditional define instead of a configuration option and the interface would must probably change anyways. The current interface doesn't handle interrupts properly. So we would have to revisit the interface completly anyways. Now, my biggest problem is trying the read the code blocking used or not used code. Someplaces its #ifndef AGC_SOCKET_DEFINE, someother places its #ifdef AGC_SOCKET_DEFINE. I really feel it should be redone. ...and the code in source control the get the history...


Title: Re: LM status...
Post by: vrouleau on July 10, 2011, 08:54:49 PM
Checkpoint commit:

- Removed AGC_SOCKET_ENABLED flag.

- Checkpoint commit on the LEM RR. If the RR as been slewed to track the CSM , the auto mode will continue tracking it.

I have added a new yellow NO TRACK light (lem_notrack.bmp) , but I am no very artistically talented, so MoonWalker can improve it .

I am at the point were if  I do a V63E, after the AGC print the first V16 N72 to print the shaft/trunnion angle, I get a 1210 program alarm (TWO PROGRAMS USING DEVICE AT THE SAME TIME).  I've checked Luminary code, at it looks like IMU doing I/O stuff at the same time as the RR. I need to investigate, but I think I need to properly align the IMU before doing RR stuff. I'll work on completing the AOT mark/reject buttons so we can align the LEM IMU.



Title: Re: LM status...
Post by: meik84 on July 11, 2011, 05:34:25 AM
Quote
I need to investigate, but I think I need to properly align the IMU before doing RR stuff. I'll work on completing the AOT mark/reject buttons so we can align the LEM IMU.
Good question. Maybe it is only neccessary to bring the IMU out of the coarse align mode by V42. Not that I intend to keep you from working on the AOT, though. :wink:


Title: Re: LM status...
Post by: vrouleau on July 14, 2011, 06:02:17 PM
Committed the AOT marking. Press q for X, press y for Y and press e for reject.

I've been scratching my head in the past few days on that 1210 program alarm.
- I've done the IMU coarse align, V55 dt adjust,
-I'm still trying to understand the LM P52 from the activation checklist, so that's not done.

If I do V63E for RR self test or V40N72 to print the shaft/trunnion angle, I get a 1210 alarm generated by R04.
I there an AGC software/Luminary expert that can help me debug the AGC code?


Title: Re: LM status...
Post by: meik84 on July 15, 2011, 12:07:28 AM
Quote
-I'm still trying to understand the LM P52 from the activation checklist, so that's not done.
In how far? On first sight, P52 of the LGC seems very similar to the CMC one. Is your IMU still in coarse align mode (NO ATT lt on)? If yes, P52 won't work. This could also be the cause for your V63 problem. From my rudimentary understanding of the IMU mode switching logic, any access to any CDU except IMU fine align and coarse align is blocked when the IMU is in coarse align. Have you tried to bring the IMU out of coarse align mode by V42?


Title: Re: LM status...
Post by: vrouleau on July 15, 2011, 07:23:00 AM
- I did N41 N20E to coarse align with the calculated gimbal angles from the CSM. "NO ATT" light was ON
- I did N40 N20E Is per checklist. "NO ATT" turned OFF.
- I did the V25 N07E to set the REFSMFLG
- I did V37E 51E PRO, then V37E 00E

At that point, I think I am coarse aligned. So you are saying that is not enough, my IMU must be in "fine align" for the V63E to use the Radar CDU.

http://history.nasa.gov/ap15fj/lmact/2-19.gif (http://history.nasa.gov/ap15fj/lmact/2-19.gif)

So I need to do a P52.

So step by step from the checklist:

V37E 52E
F04 06
R2 0003
PRO

That is fine since I have uploaded the LS REFSMMAT using the PAMFD both CSM and LM and the the CSM was fine aligned to that REFSMMAT.


F 50 25
R1 00015
V32E

?Why do a V32E here

F 01 70
R1 00ADE
PRO

where A = AOT positon
          DE = star code

? How do I pick the star? Isn't the P52 align on the LEM done with the LM rotating and mark stars as the cross the Y or X AOT axes?

F 06 79 CUR/Spir (0.01)
PRO

What does that mean? I am lost from that point on...

BTW, I'm updating the PAMFD statevector code to upload both SV to each vehicule. So when focus is on the CSM, it will upload its SV and the "other vehicule" SV for the LM if it exists (Apollo 9 and above). If the focus if on the LM, it will upload it's SV and the "other vehicule" SV for the CSM. I didn't think we needed a separate button to trigger each SV.


Title: Re: LM status...
Post by: dseagrav on July 15, 2011, 07:45:10 AM
If I do V63E for RR self test or V40N72 to print the shaft/trunnion angle, I get a 1210 alarm generated by R04.
I there an AGC software/Luminary expert that can help me debug the AGC code?

From looking at the code, I got this:
Make sure DAP is off (KALCMANU running will get you a 1210)
Other than that, if there is ANY IMU driving going on you will get a 1210 as well. Anything that uses R77 or R04 can trigger it.

Ordinarily the very first IMU coarse alignment was computed on the spacecraft, based on the CM IMU, and was driven directly.
After that, the ground computed a set of corrections based on the CM IMU and uplinked them, fine driving the LM IMU to achieve their corrections.
They could have done this to avoid some kind of gotcha in trying to do an alignment from nothing. This is just speculation on my part.

When I get home, I can try to resync to CVS and see if I can get through the activation checklists where I left off. When I last stopped trying, Orbiter was totally unusable in standard mode (Less than 7 FPS in lunar orbit with the CSM and LM, and CPU usage locked at 100%) and using the new DirectX graphics client I would get random crashes inside Orbiter itself when switching panels. There were other anomalies as well, instruments not drawing on the screen and parts of bitmaps being missing.



Title: Re: LM status...
Post by: vrouleau on July 15, 2011, 07:52:57 AM
Did you have the modules compiled in Debug mode? I note that if I am in debug mode, if I run for more then 5 minutes, the debug log files starts slowing down my orbiter to a crawl. So I took the habit of cleaning up *.log files prior to running in re-run with modules compiled 'Debug'. We need a new mechanism to toggle those traces in independant from the Debug/Release compile option.

I found more detailed P52 instruction in the A15Delco.pdf pages LM-67-LM69 with better explains the alignment mode. I'll read that and try my P52 again.


Title: Re: LM status...
Post by: dseagrav on July 15, 2011, 07:55:55 AM
So when focus is on the CSM, it will upload its SV and the "other vehicule" SV for the LM if it exists (Apollo 9 and above). If the focus if on the LM, it will upload it's SV and the "other vehicule" SV for the CSM. I didn't think we needed a separate button to trigger each SV.

Actually, can you make the "other vehicle" updating a separate option?
The "Other Vehicle" slot is operated on sometimes (See P76, etc) or used for other things, and it would be nice to be able to update one without clobbering the other.

Did you have the modules compiled in Debug mode? I note that if I am in debug mode, if I run for more then 5 minutes, the debug log files starts slowing down my orbiter to a crawl.

No, this was in release mode.

Edit: Wasn't that clever? ^_^

Edit 2: Oh, and before I waste a bunch of time, you are running Luminary 99, right?


Title: Re: LM status...
Post by: vrouleau on July 15, 2011, 08:16:46 AM
Ok, I will add a new "OSV" button instead to trigger the "other vehicule" SV upload.

Update: Yes I was using Luminary99


Title: Re: LM status...
Post by: meik84 on July 15, 2011, 12:30:12 PM
Quote
So you are saying that is not enough, my IMU must be in "fine align" for the V63E to use the Radar CDU.
I said it has to be out of coarse align mode (NO ATT lt off aka 'IMU released'). Have you tried to to do the RR check after V40N20E, ignoring anything (P51,P52) after that?
Quote
F 01 70
R1 00ADE
PRO

where A = AOT positon
          DE = star code

? How do I pick the star? Isn't the P52 align on the LEM done with the LM rotating and mark stars as the cross the Y or X AOT axes?
There are 2 ways of realigning the IMU: one is to maneuver the LM to bring a star near the middle of the reticle and mark with X and Y. Do this twice and you can realign the IMU. This is called 'in-flight sighting'. The other way is to use the spiral and the cursor of the AOT: mark on a star with the cursor, mark on it with the spiral. Do this with another star and you can also align the IMU. This is called 'cursor/spiral sighting' or 'lunar surface sighting' as it is the only way to align the IMU on the surface (maneuvering the landed LM is somewhat complicated :wink:). By keying V32E in the step before you selected the cursor/spiral routine, if you had keyed PRO you would have gotten the in-flight routine. See LM AOH Vol 2 on how this routines (and P52 overall) works.


Title: Re: LM status...
Post by: dseagrav on July 15, 2011, 06:24:39 PM
Before I forget about it, your NO TRACK lamp is on even when there's no power.
Edit: Even on a clean install, with only base Orbiter and NASSP, using the latest D3D9Client, I immediately start having the problems I had before; On the right LM panel, the EPS meters are transparent.

Edit 2: But it doesn't seem to randomly crash anymore, so that's something.
Anyway, after going through the whole (applicable) parts of the startup to the RR test, I see your 1210 alarm.

Edit 3: I did another startup to RR test, this time doing a fine align on the gimbal angles I got by running the LM coarse align worksheet.
I still get the 1210 alarm. I did everything in NASA's procedure, even the DAP startup and test (Well, as far as I could) so it's not a procedural error, it's a bug somewhere.

Edit 4: I split the power source (AC and DC side) and rewired it.
I'm looking for your bug still. If I step on your toes or if you find it first, let me know.


Title: Re: LM status...
Post by: abr35 on August 09, 2011, 09:25:41 AM
From reading previous forum posts it looks like there are developers, but not enough people to test the systems out. I'm unfamiliar with the CVS, so how can I help test the LM while it's still a work in progress? Also what are the other show stoppers in LM development besides test flying?


Title: Re: LM status...
Post by: NoName on August 11, 2011, 05:08:59 AM
I'm not familiar with the LM development. But I guess there is still a huge amount of work do be done. I really hate it not being able to program, because I would help a lot.

However, I think we have to ask dseagrav about the LM status. He seems to be the LM guy :D

As for my graphics work on it: there are still a few graphics which have to be done. But it doesn't really prevent the already existing stuff to be developed :wink:


Title: Re: LM status...
Post by: Tschachim on August 11, 2011, 05:25:14 AM
I'm unfamiliar with the CVS, so how can I help test the LM while it's still a work in progress?

Look here for CVS: http://nassp.sourceforge.net/wiki/Installation

With anonymous access, you can't commit anything (i.e. don't have write access to the repository), but you still get the latest stuff. Then you need a compiler to build the modules by yourself. You'll need Microsoft Visual Studio 2010 Express Edition for that, some slightly outdated articles are here:

http://nassp.sourceforge.net/wiki/VC2005Express
http://www.orbiterwiki.org/wiki/Free_Compiler_Setup

Cheers
Tschachim


Title: Re: LM status...
Post by: dseagrav on August 16, 2011, 10:22:21 AM
Sorry for my inattention. I'm still picking at the LGC trying to find out what this radar issue is. I'm certain the code is running right, so there's got to be something wrong with the interface; I'm pulling all the docs together to try to see what I can find. Maybe it's expecting a response from the other unit? I'm not sure yet.

I have a new desktop though, and I'm getting my environment set up now, so maybe I should be able to get back into the swing of things.

As for what's going on, the LM is still mostly incomplete and under development; There's not much to be tested. We're still in research mode.
What we really need is more systems operation data; Operating voltages and wattages, consumption rates, and things like that.
I'm also missing the telemetry assignments for the LM, and we'll want that later when we start trying to diagnose systems interactions.
(Come to think of it, did I ever put that together properly for the CM?)


Title: Re: LM status...
Post by: abr35 on August 17, 2011, 07:14:38 PM
OK, well being I can't program I guess I'll just have to get up to speed on the LEM's systems and see if I can help with document archeology. Just out of curiosity, how different internally were the earlier LMs (9-14) from the J series? ALSJ has the LM Operations handbook for Apollo 15, but since we are beginning from the beginning should I start elsewhere?


Title: Re: LM status...
Post by: dseagrav on August 18, 2011, 07:49:34 AM
There's not too many differences, just some irritating ones; The EPS and its panel changed, for one.
I can't remember all the differences off the top of my head.



Title: Re: LM status...
Post by: Apathy Man on November 08, 2011, 09:22:35 AM
[Previous post killed by moderator]


Title: Re: LM status...
Post by: dseagrav on November 08, 2011, 03:05:26 PM
OK, I fixed this by killing your post.
Try posting it somewhere else and putting a link to it here.


Title: Re: LM status...
Post by: Apathy Man on November 08, 2011, 05:38:42 PM
Weird, but no problem. Here it is.

http://www.mediafire.com/i/?7xwkw88w26951ew (http://www.mediafire.com/i/?7xwkw88w26951ew)


Title: Re: LM status...
Post by: dseagrav on November 08, 2011, 05:55:12 PM
Those are circuit breaker amperages. That's usage LIMITS, not rates.
Usage rates are usually expressed in watts, or sometimes in terms of amperage at a voltage over a period of time.


Title: Re: LM status...
Post by: Apathy Man on November 08, 2011, 10:28:18 PM
Ahh, I see.

Well in that case, I did some more sifting and came up with more.

http://www.hq.nasa.gov/alsj/LMSysHandbk.pdf (http://www.hq.nasa.gov/alsj/LMSysHandbk.pdf)
For earlier LM's, not sure how much it will help with this one...

http://www.hq.nasa.gov/alsj/LM10HandbookVol1.pdf (http://www.hq.nasa.gov/alsj/LM10HandbookVol1.pdf)
This one has a wealth of information about each of the LM's systems. Alot to go through, but each subsystem's electrical information is detailed.

http://www.hq.nasa.gov/alsj/LMNewsRef-Boothman.html (http://www.hq.nasa.gov/alsj/LMNewsRef-Boothman.html)
And finally, I found a lot of info on each subsytem on the above link, including alot of wattage info. I'll put what I was able to construct below. I'm sure there is probably more than this in the above documents that I haven't gotten around to looking into thoroughly yet.

Also note, the above document has a ton of ECS data as well.

GNC
---
LGC: 70W, 28V DC
AGS: 12.5W (standby) 96.0W (operate), 3-5V DC
Rate Gyro Assembly: 1.8W
Descent engine control assembly: 7.9W (max), 115V AC, 28V DC
Gimbal Drive Actuator: 35W, 115V AC
Landing Radar: 125W (nominal), 147W (max), 25-31.5V DC, 3.5-6.5 amps
Landing Radar Heater: 63W
Altimeter Antenna: 100mw
Velocity Sensor Antenna: 200mw
Transponder: 75W
Transponder Heater: 20W (max)

ECS
---
Suit Circuit Fans: 28V DC
Cabin Fan: 62W (average), 210W (peak), 28V DC
Coolant Pumps (3): 28V DC

Propulsion
---
MPS: 115V AC, 28V DC
RCS: 115V AC, 28V DC
RCS Heaters: 17.5W (per heater) @ 24V, 28V DC

EPS
---
AC Inverter Input Voltage: 24-32V DC
AC Inverter Output: 115 Vrms
AC Inv Normal Load Range: 0-350 Volt-Amperes
AC Inv Maximum overload at constant voltage: 525 Volt-Amperes for 10 minutes
DC Bus Voltage Limits: 26.5-32.5V DC
DC Bus Nominal Voltage: 28V DC
DC Bus Transient Voltage: 50V above or below nominal supply voltage
Desc Batteries: 5
Desc Battery Capacity (each battery): 415 ampere-hours (25 amps @ 28V DC for 16 hours)
Desc Battery Nominal Voltage: 30.0V DC
Desc Battery Minimum Voltage: 28.0V DC
Desc Battery Maximum Voltage: 32.5V DC
Asc Batteries: 2
Asc Battery Capacity (each battery): 296 ampere-hours (50 amps @ 28V DC for 5.9 hours)
Asc Battery Nominal Voltage: 30.0V DC
Asc Battery Minimum Voltage: 27.5V DC
Asc Battery Maximum Voltage: 32.5V DC

Communications
--------------
S-band Transceiver: 36W
S-band Power Amps: 72W
VHF A transmitter: 30W
VHF A receiver: 1.2W
VHF B transmitter: 31.7W
VHF B receiver: 1.2W
Signal Processing Assembly: 12.7W
Digital Uplink Assembly: 12.5W
Ranging Tone transfer assembly: 5W
TV Camera: 7.5W

Instrumentation
---------------
Sig. Cond. Electronics Assembly: 28V DC
Sig. Cond. Electronics Assembly 1: 16.04W
Sig. Cond. Electronics Assembly 2: 14.23W
Pulse-code-modulation and timing assembly: 11W, 28V DC
C&WS Assembly: 13W, 28V DC

Not sure if you'll find it helpful. Maybe you've already seen them, just figured I'd toss it out. However, just using the above, we can pretty much tell where at least 26.89 amps (@ 28V DC) are going. I'll see what else I can add.


Title: Re: LM status...
Post by: Apathy Man on November 13, 2011, 12:32:45 AM
I went to the central library in my city this past week looking for what I could find on Apollo, but more specifically the LM. Aside from taking out a few books, I came across a large R&D reference report on the Lunar Module. One of the pages detailed typical current through the circuit breakers. I copied down the rates and put them together in the attached Word document.

Unfortunately, the document was not specific on which of these rates is momentary (either from switching relays, valves, or commands) but some are pretty obvious. I’m sure it can be figured from reading the online documentation which of these are.

*For the inverters, typical draw rate from the busses under a 300 volt-ampere load varied between 700 and 775 watts.

Edit: I computed the amps values based on the wattage of the given bus.


Title: Re: LM status...
Post by: dseagrav on March 13, 2012, 11:16:33 PM
By taking the program apart I finally figured out what the alarm 1210 was.
I can fake out radar data and have it displayed on the DSKY now.



Title: Re: LM status...
Post by: meik84 on March 14, 2012, 05:22:43 PM
Just to satisfy my curiosity :wink:: what was it?


Title: Re: LM status...
Post by: vrouleau on March 14, 2012, 05:25:34 PM
Yes, what was it?? I' m about to commit changes to the PAMFD to allow to upload the other vehicule state vector. So its a new 'OSV' in the TELE page. It will work either in the CSM or the LM. The changes were hanging there on my drive for a year...


Title: Re: LM status...
Post by: dseagrav on March 14, 2012, 06:38:41 PM
I'm still working on it; I've only figured out the RR half, the LR still doesn't work. The hard part was figuring out that you get alarm 1210 NOT just when there's a conflict for the CDU, but ALSO when the IO operation fails. To read the RR, the LGC will put a channel number on the bottom three bits of channel 13, then light the Radar Activity bit. This causes the range unit to send back the data via the pulse train, after which it generates EXACTLY ONE radar interrupt. If you interrupt twice, you'll get a 510. The LGC will then change its requested channel number but it WON'T drop the Radar Activity bit! When it does that, the pulse train starts again and you generate EXACTLY ONE radar interrupt. The actual send sequence seems to be caused by having a new channel and activity bit pair.

This works for the RR, but when I try the same stuff for the LR, I get a 1210 again. I think it's looking for another bit to set. The LGC uses the same routine to do all radar IO, so it's hard for me to pick out exactly what it expects without being able to read the LGC state in real time.


Title: Re: LM status...
Post by: vrouleau on March 14, 2012, 07:26:55 PM
WOW !! awesome Sherlock. I spent so much time look at the agc source code to understand why but could find it. I did the commit for the PAMFD  other SV upload.

I still need to improve the RR to set the porper operation angle based on RR operation mode. For e rolling tape, I firged I could do a simple Bitmap that can be offset with a scale and 000 digits representing thousand feet range and that just use superimpose single digits on it reprensing tousand unit, 10 thousand and 100 thousands units.
.


Title: Re: LM status...
Post by: barry on March 14, 2012, 08:13:59 PM
Slightly off-topic, but if you are working on the RR - perhaps you can also emulate the hardware interrupt bug that caused the "1201"s and "1202"s that actually happened during Apollo 11.

see: http://www.doneyles.com/LM/Tales.html (http://www.doneyles.com/LM/Tales.html)

Look around for the following:
Quote
The CDU interface counters in the LGC were incremented or decremented by means of external commands that were processed inside the computer as increment or decrement operations with names like PINC and MINC. Like the LGC's programmable operations, these took time, in this case one memory cycle of 11.7 microseconds, each. Moving at their maximum rate, the RR CDU counters consumed approximately 15% of the available computation time. At the time, conservatively, we assumed the time drain (called TLOSS) was about 13%, which was consistent with the behavior that was observed.

As I understand it, the RR CDU hardware chewed up too much real-time, and caused the system to recursively handle events, which ate up the free VACs..


Title: Re: LM status...
Post by: dseagrav on March 14, 2012, 08:50:54 PM
The problem with that is that the exact loading is not strictly deterministic - Even if I faked up the time loss, it would be really difficult to get the alarms at the exact time it happened.
Maybe after everything works properly we can look into simulating faults, but I'm not interested in it right now.

Edit: Solved the LR issue, it was a typo on my part that caused it to intermittently fail.
The LR works exactly the same way the RR does.
I mapped out the radar range unit channels, here's the list:

Code:
ABC WHAT
000 unused/not observed
100 LR VELOCITY X
010 RR RANGE RATE
110 LR VELOCITY Z
001 RR RANGE
101 LR VELOCITY Y
011 unused/not observed
111 LR RANGE


Title: Re: LM status...
Post by: dseagrav on March 18, 2012, 08:16:18 PM
There are some inconsistencies in driving activity that I am investigating; Antenna drive commands don't seem to work as expected.
I'm picking it apart and will post more when I figure it out.

Edit: Whatever happened to the LM ECS bitmaps that were being worked on?


Title: Re: LM status...
Post by: NoName on March 19, 2012, 09:22:14 PM
Whatever happened to the LM ECS bitmaps that were being worked on?

I am drawing the Water Control Module right now. Looks nice so far. I expect to complete my work on the LM panel graphics this week.

I'll post a preview soon...


Title: Re: LM status...
Post by: vrouleau on March 20, 2012, 06:15:13 AM
I had the moving Tapemeter for the radar range implemented.  Does anybody know what the portion below 0 feet looked like on the tape? Was it just black. Tried to find images on the internet...


Title: Re: LM status...
Post by: dseagrav on March 20, 2012, 11:05:11 AM
Looks like it's just black. See http://www.hq.nasa.gov/office/pao/History/alsj/a11/AS11-36-5389HR.jpg


Title: Re: LM status...
Post by: NoName on March 20, 2012, 11:15:45 AM
The tapemeter already exists. It's just not yet committed :P

I could commit it. But I don't know if the bitmap is correct. It goes from -700 fps to +700 fps and from 0 up to 60,000 feet. Is this correct?


Title: Re: LM status...
Post by: dseagrav on March 20, 2012, 11:18:08 AM
No, it's supposed to turn to nautical miles at 120,000 feet and go out to 400 nautical miles.


Title: Re: LM status...
Post by: NoName on March 20, 2012, 11:20:04 AM
No, it's supposed to turn to nautical miles at 120,000 feet and go out to 400 nautical miles.
I'm at work so I don't have all my notes.


Ah yes. It was just too long ago we were talking about. I didn't have time during the last month. But I am fully back.

I'll finish it. "Only" another 60k feet and then up to 400 nm :ROTFL3453:


Title: Re: LM status...
Post by: vrouleau on March 20, 2012, 12:09:13 PM
Ok, I stop working on it then.


Title: Re: LM status...
Post by: retro on March 20, 2012, 01:27:40 PM
yes those figures are correct
0 to 120,000 then changes to NM to 400


Title: Re: LM status...
Post by: NoName on March 20, 2012, 01:41:12 PM
Ok, I stop working on it then.

Do you need the bitmap urgently? I could put it on top of my list and commit it before I commit all the other new LM bitmaps.


Title: Re: LM status...
Post by: NoName on March 20, 2012, 01:41:35 PM
yes those figures are correct
0 to 120,000 then changes to NM to 400

Thanks.


Title: Re: LM status...
Post by: vrouleau on March 20, 2012, 01:49:41 PM
Ok, I stop working on it then.

Do you need the bitmap urgently? I could put it on top of my list and commit it before I commit all the other new LM bitmaps.
Well no, as I was about ready to commit myself the range tape meter. I had done the tapemeter (in feet only , I did not implement the transittion to NM) and the digits to print out the range in ,000 increments.  Can you confirm that you worked on a fully moving tapemeter that responds to RR radar values? or just the bitmaps? I've got the whole thing working but did not commit. I you just worked on the bitmap, then I'll keep the display logic code.


Title: Re: LM status...
Post by: NoName on March 20, 2012, 02:20:48 PM
Ok, I stop working on it then.

Do you need the bitmap urgently? I could put it on top of my list and commit it before I commit all the other new LM bitmaps.
Well no, as I was about ready to commit myself the range tape meter. I had done the tapemeter (in feet only , I did not implement the transittion to NM) and the digits to print out the range in ,000 increments.  Can you confirm that you worked on a fully moving tapemeter that responds to RR radar values? or just the bitmaps? I've got the whole thing working but did not commit. I you just worked on the bitmap, then I'll keep the display logic code.

I'm only working on the bitmaps. I'm a very bad coder :sorry345: So I'm glad there is you and all the other coders here :ThumbsUp432:

The bitmap currently contains, or more specifically will contain everything: the black tape from 0 to 120k feet and up to 400 nm on the left, as well as the white +/- 700 fps tape on the right. It's going to be a very long/high bitmap. Just tell me in case it should look different.


Title: Re: LM status...
Post by: vrouleau on March 20, 2012, 02:44:02 PM
Ca n you send me your bitmaps. If you did manage do to the large range, I'll see if I can you it instead of printing every digits individually.


Title: Re: LM status...
Post by: NoName on March 20, 2012, 02:50:24 PM
Ca n you send me your bitmaps. If you did manage do to the large range, I'll see if I can you it instead of printing every digits individually.


Of course. But I still have to add the nautical miles. Shouldn't take too long. I'll commit it soon...


Title: Re: LM status...
Post by: NoName on March 20, 2012, 06:39:57 PM
Does anybody know the limit of the fps scale? And isn't it two different tapes? Currently both scales are in one bitmap.


Title: Re: LM status...
Post by: NoName on March 20, 2012, 07:01:53 PM
So now I am at the 120k feet mark. The bitmap is 84x8040 pixel at the moment. The next number would be 121k but due to the transition to NM I guess the next number is 20 NM right? If the look of the scale does not change, now each small mark means one NM more, i.e. 10 NM more each tenth mark. So the bitmap doesn't become too big I think. In terms of mega byte it's just about 2 currently, uncompressed (24 bit). Anyway, it's going to become the longest bitmap for a gauge I have ever seen so far :ROTFL3453:


Title: Re: LM status...
Post by: NoName on March 20, 2012, 07:34:35 PM
So there we are. The ALT scale measures 44x6370 pixel = from 0 to 120k feet and then from 20 NM up to 400 NM.

The ALT RATE scale measures 44x5610 pixel = from -700 to +700 FPS.

Just let me know if the ALT RATE scale (-700 to +700 FPS) is correct, and if the two scales should be in one bitmap or two separate different bitmaps.


Title: Re: LM status...
Post by: vrouleau on March 20, 2012, 07:59:13 PM
I'm test then out tomorrow in the code. I'll let you know it orbiter handles it. If not, I' ll revert to my current method.
for the rate, it is better to keep it one bitmap

Update: Did you commit? I did an update and did not get anything.


Title: Re: LM status...
Post by: NoName on March 21, 2012, 12:07:54 PM
Sorry for the delay.

I'm having trouble checking out the latest CVS files. CVS aborts every few minutes. I'll let you know as soon as it works and when I committed the new bitmap.


Title: Re: LM status...
Post by: NoName on March 21, 2012, 02:56:02 PM
I still can't checkout, i.e. get all the latest project files. CVS crashes here and there with different messages. Even when I delete the folder and try it again with a clean checkout.


Title: Re: LM status...
Post by: NoName on March 21, 2012, 04:39:11 PM
Finally it worked. But now one of my RAMs obviously died. But that's a different matter...

So, the new bitmap is available now ("lm_range_rate_indicator_scales").

Remember to put the "lem_range_rate_indicator" bitmap on top, if you haven't done so already.

Hope it will work.


Title: Re: LM status...
Post by: vrouleau on March 23, 2012, 09:34:01 PM
I did a commit on the radar tape logic. The range tape and rate tape now moves based on RR data only. The "ALT/RNG MON" switch must be in UP position. I added persistency on tape position to add smooth scrolling on large changes, that I will add later later.

I believe there is an error in the range bitmap. 120000 feet = 20NM, so the scale should go to 30 NM from 120,000 , not 20NM. I can fix that.


Title: Re: LM status...
Post by: NoName on March 23, 2012, 11:24:29 PM
I did a commit on the radar tape logic. The range tape and rate tape now moves based on RR data only. The "ALT/RNG MON" switch must be in UP position. I added persistency on tape position to add smooth scrolling on large changes, that I will add later later.

Great news. I will check it out this weekend.

I believe there is an error in the range bitmap. 120000 feet = 20NM, so the scale should go to 30 NM from 120,000 , not 20NM. I can fix that.

Ah, yes. If it starts at 120,000 feet than the first line means 21 NM, the second one 22 NM and so on, which means that the first mark should be 30 NM.

I can fix it also if you want. I have to change it anyway since I keep all the original files up to date in different folders. Uncompressed, compressed, and all the templates. If not compressed, NASSP would have 400mb of panel graphics by the way.


Title: Re: LM status...
Post by: vrouleau on March 24, 2012, 05:28:37 AM
Ok fix it. Once you commit, it will change an offset in the code. I will correct it them


Title: Re: LM status...
Post by: dseagrav on March 24, 2012, 12:57:45 PM
When you guys are done fixing that let me know so I can finish debugging the positioner.


Title: Re: LM status...
Post by: retro on March 24, 2012, 09:44:03 PM
Found out the max rates on the range alt tape fps is + -700 fps.
that's vertical vel max Display.confirmed! lol


Title: Re: LM status...
Post by: NoName on March 25, 2012, 12:10:20 PM
I'll try to hurry up. I'm in the final stages of designing the ECS panel. Looks nice so far. I just have to add eye candy stuff here and there. Preview follows very soon...

PS: and thanks retro, for the tape info.


Title: Re: LM status...
Post by: NoName on March 27, 2012, 04:22:39 PM
So here is the preview of the latest ECS graphics...

First, the reference:

(http://onfinite.com/libraries/1735178/31c.jpg)

The new right hand side panel:

(http://onfinite.com/libraries/1735176/f65.jpg)

The new panel which is supposed to be next to the right hand side panel:

(http://onfinite.com/libraries/1735177/315.jpg)

It's still a work in progress. Takes more time than I thought (as usual). Especially the rotaries, suit gas inverter, liquid garment cooling/cabin recirculation assembly graphics and other details have to be finished.

I hope you like it.

Another reference:

http://www.apolloproject.com/diagrams/ad017.gif


Title: Re: LM status...
Post by: retro on March 27, 2012, 07:40:17 PM
Like it,Na- Love  it !


Title: Re: LM status...
Post by: NoName on March 28, 2012, 08:08:52 PM
The right hand side panel now is finished. The new panel next to it still needs to be finished (not too much work though). Next and final step: extending all LM panels to 1920 x 1440 pixels. Then we should have all Lunar Module controls and switches available. At least optically. Still lots of coding required I guess.

@ dseagrav

if you don't mind I commit the new ECS graphics when all other LM panels are finished as well (i.e. extended to 1920 x 1440 pixels). But let me know if you need the new ECS panels now. In this case I'll commit them as soon as they are complete.

Like it,Na- Love  it !

Thanks :)


Title: Re: LM status...
Post by: dseagrav on March 29, 2012, 12:39:50 PM
Well, I'm still waiting for the range rate commit, so I can wait for yours too.
I'll be out of town next weekend anyway.


Title: Re: LM status...
Post by: NoName on April 01, 2012, 07:18:55 PM
I did commit the changed range rate scale.


Title: Re: LM status...
Post by: NoName on April 01, 2012, 07:29:49 PM
Please let me know in case something on the bitmaps has to be changed; or send me a private message, describing required changes or changes someone has done. I have to do the changes on the original bitmaps as well, to keep everything up to date.

I noticed that there are changes on the main panel. It's only the range rate gauge I guess, i.e. the removed scale in the background. There is also black pixels on the upper left hand corner now (originated during changing the range rate gauge I think). Not a big issue. It just went into my eyes :D But since I'll commit completely revised panel bitmaps soon (due to the 1920 pixel wide screen issue) it does not matter in this case.


Title: Re: LM status...
Post by: vrouleau on April 01, 2012, 09:00:58 PM
I recompiled with it and everything is ok. You moved downed the NM instead of raising the FT, so the offsets was still good in the code.

dseagrav, I'm not touching the code it for now, so you can go ahead with your work.  Any change you can commit your fixes on the RR self test, I'd like to play with it.

Are/will you work on the Mark X/Y handling of the AOT? I could look into it, but I dont what to step on the stuff you are doing.


Title: Re: LM status...
Post by: FordPrefect on April 02, 2012, 07:18:43 PM
Very nice work on the new 2D panels, Moonwalker!  :ThumbsUp432:


Title: Re: LM status...
Post by: NoName on April 02, 2012, 07:37:06 PM
Very nice work on the new 2D panels, Moonwalker!  :ThumbsUp432:

Thanks :)

They will be finished soon.


Title: Re: LM status...
Post by: macieksoft on June 08, 2014, 02:31:43 PM
Is RCS system in LEM working? How to activate them to extinguish RCS A REG and RCS B REG lights?
What means LM LGC ERROR:RESET?
And how to turn on AGC and DSKY? It looks like not working.

I am using broken Apollo 11 VAGC scenario.


Title: Re: LM status...
Post by: eddievhfan1984 on June 08, 2014, 02:57:46 PM
Yeah, the LM still has a lot of development left to do. IDK if the RCS is actually working on that vehicle, or even the computer.


Title: Re: LM status...
Post by: vrouleau on July 29, 2014, 01:20:35 PM

Hi desagrav. Hope things are getting better for you. If possible, can you commit or provide the changes that you did to avoid the 1210 alarm. I'd like to get back on this.

I'm still working on it; I've only figured out the RR half, the LR still doesn't work. The hard part was figuring out that you get alarm 1210 NOT just when there's a conflict for the CDU, but ALSO when the IO operation fails. To read the RR, the LGC will put a channel number on the bottom three bits of channel 13, then light the Radar Activity bit. This causes the range unit to send back the data via the pulse train, after which it generates EXACTLY ONE radar interrupt. If you interrupt twice, you'll get a 510. The LGC will then change its requested channel number but it WON'T drop the Radar Activity bit! When it does that, the pulse train starts again and you generate EXACTLY ONE radar interrupt. The actual send sequence seems to be caused by having a new channel and activity bit pair.

This works for the RR, but when I try the same stuff for the LR, I get a 1210 again. I think it's looking for another bit to set. The LGC uses the same routine to do all radar IO, so it's hard for me to pick out exactly what it expects without being able to read the LGC state in real time.


Title: Re: LM status...
Post by: dseagrav on August 30, 2014, 07:27:54 AM
I'll have to look at the state of my copy. I don't remember what I was doing.

The RCS should work at least under LGC control, I was using it to test.


Title: Re: LM status...
Post by: pattersoncr on June 16, 2015, 10:19:31 AM
Does anyone know if the latest updates to the LM are reflected in the most recently posted set of modules (20120715)?
If not can someone build me an updated set of modules??


Title: Re: LM status...
Post by: dseagrav on July 06, 2015, 12:55:59 AM
To make it easier to follow the LM startup checklist I added a button to PAMFD that gives you the CM's TEPHEM, the CM gimbal angles, and the numbers to use for the LM coarse align as described in the A12 LM activation checklist.

If this breaks anything, let me know.


Title: Re: LM status...
Post by: indy91 on July 06, 2015, 05:21:40 AM
Ah, that's very useful. Is there still the need for the ground calculated fine align angles from pages ACT-36/37 with this update? I am pretty familiar with the IMU alignment subroutines, let me know if I can help with that.


Title: Re: LM status...
Post by: vrouleau on July 06, 2015, 07:53:58 AM
Glad to see you back desgrav, I did not checkout your commit, but did you push the fix for the Range Radar problem during the activation checklist in the AGC?


Title: Re: LM status...
Post by: dseagrav on July 06, 2015, 12:18:11 PM
Is there still the need for the ground calculated fine align angles from pages ACT-36/37 with this update?

I don't know. If there's some gain in accuracy to be had by recalculating the angles maybe, but if the coarse align set is good enough to get you through the first alignment then it might not be worth the hassle.

did you push the fix for the Range Radar problem during the activation checklist in the AGC?

No, not yet. My old copy of PA is unusable, I have to fix everything by hand.


Title: Re: LM status...
Post by: dseagrav on July 13, 2015, 07:14:50 AM
New post to generate reply notifications.

New commit completes LR and RR computer interfaces.
Neither radar actually does real work, but the LGC can talk to them now.

Edit: RR test mode is in now.
Edit: LR test mode in also.


Title: Re: LM status...
Post by: indy91 on July 14, 2015, 06:06:38 AM
Just wanted to share my list of notes about some (probably known) issues I had running through the Activation Checklist a few times:

-When building the newest commit I get a compiler error C4335 "Mac file format detected." This is not really an issue, VS can easily change the inconsistent line endings.
-Orbiter crashes every time when exiting the simulation, but only with the LM present and using the D3D9 client. Not really an issue either, because quicksaving works fine.
-However, every time I load a quicksave the LGC has the "No Att" and "Restart" light on. So quicksaving doesn't really help once the LGC is activated.
-Random crashes when changing between panels. Not very common, but without quicksaving I basically have to start from the beginning.

So if chance lets me get to the RR self test I will report about that, too.


Title: Re: LM status...
Post by: vrouleau on July 14, 2015, 07:33:24 AM
Same thing here for the file format. Now when I open the file, It asks me to convert to Windows CR LF. Compiling strait from the cvs update fails.

In my case, in SVN OrbiterSim2015, I do not get a crash exiting. I did not test mush else.

BTH I tried to push yesterday and I get a 'no write access' to CVS, I tried to PM taschim but he has not been posting for a while. I've got the VS2015 project files that I whould like to commit as well as the OrbiterSoundSDK4.0 changes I wanted to commit for a year now !


Title: Re: LM status...
Post by: dseagrav on July 14, 2015, 09:11:09 AM
Since I am using a unix system for CVS, it appears that when cvs updates the changelog, the lines generated have the incorrect line endings.

I cannot afford to pay $150 for CVSNT and I am opposed to the idea of rewarding them for their behavior. Additionally I refuse to pollute the changelog with advertisements. I will check to see if cvs can be configured to use MSDOS line endings. If I cannot, and the effect cannot be tolerated or mitigated, I have no choice but to discontinue contributions.

The system anomalies in save/load are known (at least to me) issues. The LM is absolutely not warranted or implied to be spaceworthy. Most of the LM is outright missing, and even more of what is there does not have save/load functions.


Title: Re: LM status...
Post by: vrouleau on July 14, 2015, 10:27:31 AM
You can work with SmartCVS of TurtoiseCVS also. Both allow configuration for line endings


Title: Re: LM status...
Post by: dseagrav on July 14, 2015, 12:36:42 PM
SmartCVS and TortoiseCVS are just frontends to CVSNT, which is solely available from March Hare. They have made the decision that they no longer want to support the free versions of CVSNT, so the non-commercial versions of CVSNT now force advertisements for March Hare's commercial product(s) into your commit messages. There are no remaining alternatives to CVSNT on Windows, and the only versions of CVSNT that do not have the advertisement have a remotely-exploitable security vulnerability and/or only work under Windows XP.

That said, I think I have a workaround for the line endings - I'll test it later.


Title: Re: LM status...
Post by: dseagrav on July 14, 2015, 08:36:55 PM
New update, new post.

This rearranges some things in initialization to cause them to be more like the CSM, and introduces a few timesteps of delay into startup to allow busses to settle before clocking systems. This is probably not the -correct- solution, I think something is wrong with the LM's use of panelsdk. I'll dig for more later. Anyway, the LGC should survive a scenario load now. I tested for the minimum delay and found it to be 4 timesteps.

The random crash when switching panels seems to have disappeared for me. Does anyone else still have it? If so, does it produce usable crash files and/or backtrace?

I also tried a means of not screwing up the line endings; It didn't work.




Title: Re: LM status...
Post by: indy91 on July 15, 2015, 09:19:56 AM
Thank you for fixing the initialization stuff so quickly, comes in pretty handy. I did get one crash when changing to another panel. Orbiter.log said something about the D3D9 client, but I didn't save it. CTDs don't happen as frequently now though, which is great.


Title: Re: LM status...
Post by: dseagrav on July 15, 2015, 09:58:04 AM
Orbiter.log said something about the D3D9 client, but I didn't save it.

Next time you get one of these, please post it on pastebin and post the resulting link here so I can see it.
If it's something the LM is doing it might be a hint.

Sidenote, whatever happened to moonwalker?


Title: Re: LM status...
Post by: dseagrav on July 15, 2015, 11:53:14 AM
BTH I tried to push yesterday and I get a 'no write access' to CVS, I tried to PM taschim but he has not been posting for a while. I've got the VS2015 project files that I whould like to commit as well as the OrbiterSoundSDK4.0 changes I wanted to commit for a year now !

Apparently I have CVS administrator access, so I should be able to help. My first question is are your login credentials for sourceforge still valid? They had a security breach a while back and invalidated everyone's credentials. Log in on the website, make sure your passwords and/or ssh keys are still good, and let me know. After that, is your PA installation based on a checkout from the public anonymous CVS? If so, you can't commit from it, you have to re-checkout over ssh using your developer credentials. If your passwords are good and your source tree is checked out using your developer credentials then something else is wrong.


Title: Re: LM status...
Post by: vrouleau on July 15, 2015, 01:59:26 PM

Got it, I was checkout in :pserver:, not :ext:. I did the commit. You now need to install OrbiterSound 4.0, OrbiterSound3.5 is not available from Dan's page, I updated all VC project files for all versions

What where you working on? After testing the power-up, I wanted to test transferring the gimbal angles from the CSM to the LM, then implement the X-Y buttons to do the alignement using the LM optics.


Title: Re: LM status...
Post by: dseagrav on July 15, 2015, 02:12:06 PM

Got it, I was checkout in :pserver:, not :ext:. I did the commit. You now need to install OrbiterSound 4.0, OrbiterSound3.5 is not available from Dan's page, I updated all VC project files for all versions

What where you working on? After testing the power-up, I wanted to test transferring the gimbal angles from the CSM to the LM, then implement the X-Y buttons to do the alignement using the LM optics.

Awesome. Can I just drop orbitersound 4 over the top of 3.5 or do I have to rebuild my orbiter directory?

Right now I'm changing around stuff in lempanel and friends, I found places where lempanel overwrites textures when it shouldn't that might be related to the mysterious panel-switching crashes.


Title: Re: LM status...
Post by: vrouleau on July 15, 2015, 02:31:36 PM
I don't know about dropping in 4.0. In my case, I've always re-installed, so i cannot say.


Title: Re: LM status...
Post by: dseagrav on July 15, 2015, 03:18:57 PM
When you install 4.0 it asks to remove 3.5, which worked fine.

I pushed another commit, this time cleaning up all the uses of hardcoded surface offsets in lempanel. I found one, srf[19], that was used without being initialized anywhere I could find.
I commented all of those out, with seemingly no change - If anyone figures out what no longer works, let me know and I will fix it.
There were other places where a hardcoded offset was overwritten by another texture later; If there's any new crashes, or textures showing up where they shouldn't be, let me know.
(This does not apply to the missing guard over the ED Stage Fire switch)

Ideally this decreases or eliminates the random crash when switching panels; Anyone who gets one of those crashes should gather as much information as possible about it and pastebin it so I can see it.

Sidenote to vrouleau: Your commit added double spacing in LEM.h and lemsystems.cpp. That's probably my fault so I fixed it.


Title: Re: LM status...
Post by: eddievhfan1984 on July 16, 2015, 12:37:57 AM
I already posted about this. Most of the functions are overwritable, but SoundOptionOnOff now takes a VesselID parameter, and I'd just comment it out ATM, until a workaround is discovered...


Title: Re: LM status...
Post by: indy91 on July 17, 2016, 04:13:55 PM
Orbiter.log said something about the D3D9 client, but I didn't save it.

Next time you get one of these, please post it on pastebin and post the resulting link here so I can see it.
If it's something the LM is doing it might be a hint.

One year later and I get the error again while trying the LM. I get the following message when Orbiter crashes:

Code:
Microsoft Visual C++ Runtime Library

Assertion failed!

Program: D:\ProjectApollo\modules\server\orbiter.exe
Files: .\D3D9Surface.cpp
Line: 735

Expression: false

and the relevant lines of the D3D9ClientLog.html are:
Code:
(76560: 15671.12s 302567547307us)(0x1B00)[ERROR] CreateRenderTarget Failed in ConvertToRenderTarget(0x232A3AF8) W=830, H=1661, usage=0x0, Format=0x16
(76561: 15671.12s 302567551391us)(0x1B00)Surface name is clbkCreateSurface Handle=0x232A3AF8
(76562: 15671.12s 302567551410us)(0x1B00)ActiveFlags( )


Title: Re: LM status...
Post by: indy91 on August 21, 2016, 08:32:09 AM
I have done a few changes to the LM:

-The Throttle Control and Engine Gimbal switches now set a bit in an AGC input channel
-The panel 1 event timer can now be used
-The DPS now has proper gimbal actuators in pitch and roll and gets its commands from the AGC. I have added a debug string, so that you can see what it is doing.
-The gimbal caution light will be on, if the gimbals are in a hard stop (happens during V48)
-The DPS has provisions for auto ignition, but that isn't working yet
-I had to comment out a few lines of code, which were out-of-date and prevented the new gimbal actuators to work. I also commented out the handling for an incorrectly read input channel bit, which wanted to start the old abort programs. It doesn't really do anything with the Virtual AGC active, but it changes the displayed program to P70 or P71.

To show off what has been changed, I have two scenarios for you. Landing and launch. When you load one of the scenarios, first go to both panels 11 and 16 once, because not all LM systems are correctly loaded otherwise.

In the P63 scenario first roll to 0° on the FDAI. Then start P63 with V37E 63E. It will run the ignition algorithm, which can take a little bit. When it has converged, it will display F 06 61. You can access the TIG with N33E. When you proceed on F 06 61, it will give you a F 50 25 and ask you to fine align the IMU. Because this has already been done press ENTR. Next the AGC wants to maneuver to the ignition attitude. Set the PGNS mode control switch to Auto and let the AGC do its thing. Once it is in attitude, you maybe want to press 5 on the numkey to get the attitude rates to zero. Right now the AGC is not too good at attitude holding. When you ENTR on the F 50 18, the AGC will check if various switches are in position. If you get a F 50 25 with the number 500, then you need to press the three landing and rendezvous radar circuit breakers on panel 11. You can then PRO and if the AGC finds the radars running, it will let you through to the next display. There you might get a F 50 25 again with the number 203. Now it checks for a few guidance switches. You might need to cycle the throttle control switch to manual and back to auto. If it lets you PRO on the 203, then the AGC will be busy for a while again. If it shows you a F 06 62, then it is ready for ignition. The rest basically works like P40. PRO at T-5 seconds and manually throttle up to 10% and at 26 seconds into the burn to 100%. The AGC should now controll the DPS gimbal actuators.

Program 12 description coming later...


Title: Re: LM status...
Post by: eddievhfan1984 on August 21, 2016, 10:23:36 AM
Thanks for the upload, although when I tried it (after doing the necessary recompiling), I got a P00DOO without the program alarm lighting—the computer was so insistent I change modes, it didn't even let me look at the alarm registers. And I really wanna fix the throttle command pointers so I know what my throttle is without having to F8 to check it...


Title: Re: LM status...
Post by: indy91 on August 21, 2016, 10:34:11 AM
Thanks for the upload, although when I tried it (after doing the necessary recompiling), I got a P00DOO without the program alarm lighting—the computer was so insistent I change modes, it didn't even let me look at the alarm registers. And I really wanna fix the throttle command pointers so I know what my throttle is without having to F8 to check it...

I get the strange error sometimes, too. Just switch the PGNS Mode Control switch to off, then you can look at the alarm, which probably also will be a 1103. The Guidance Control switch really doesn't want to be touched, sometimes that is the cause of the problem. And other switches aren't correctly setting their bit at scenario start, probably because I changed the switches to AGC IO switches after I saved that scenario and the input/output channels are saved in the scenario. Just try the scenario again and it might work.

I'll look into the throttle pointers.


Title: Re: LM status...
Post by: eddievhfan1984 on August 21, 2016, 11:08:20 AM
Did multiple tries, but still getting the same problem. Also, the LGC C/W light is lit, but I guess you already knew about that...


Title: Re: LM status...
Post by: indy91 on August 21, 2016, 11:15:03 AM
Did multiple tries, but still getting the same problem. Also, the LGC C/W light is lit, but I guess you already knew about that...

You did the looking at all panels trick, right? The LGC alarm will go away, when the radar circuit breakers are in. Here the exact steps I take at the beginning of the scenario:

-Look at panel 11
-Look at panel 16
-Roll to 0°
press keypad 5 to null attitude rates
-V37E 63E
-wait for ignition algorithm to finish
-PRO when looking at the countdown, ENTR on the 00014. Then on the 50 18 I switch PGNS mode control to auto. Then PRO and it will work without the alarm.


Title: Re: LM status...
Post by: eddievhfan1984 on August 21, 2016, 06:32:46 PM
Yep, I checked the panels first, and even enabled some of the breakers necessary for a fire-in-the-hole abort (though since neither ABORT or ABORT STAGE work ATM...). Enabled the radar breakers, but the light remains.


Title: Re: LM status...
Post by: rcflyinghokie on August 21, 2016, 07:24:48 PM
Yep, I checked the panels first, and even enabled some of the breakers necessary for a fire-in-the-hole abort (though since neither ABORT or ABORT STAGE work ATM...). Enabled the radar breakers, but the light remains.

I just ran through it, my LGC light cleared with no problem.

EDIT: Unless you mean the PROG light?  Because I just tried it again and I too am having a PROG light and F 37 whenever I switch PGNS to AUTO.  Its weird I ran through it the first time with no such error, now every time I have that problem.


Title: Re: LM status...
Post by: eddievhfan1984 on August 21, 2016, 08:35:31 PM
Yeah, it cleared now. But I think something is screwy with the Luminary code or something... When P63 called P00DOO, I couldn't even select P00 at all. I even tried calling P70 to get me back in to orbit, but it still stayed on F 37, no matter what I did.

EDIT: Tried manually selecting P70 before the point P63 normally goes kaput, but it does the same thing: looping in F 37, and not accepting any requests to go P00. And the X-axis maneuver override isn't working, either. >.<


Title: Re: LM status...
Post by: indy91 on August 22, 2016, 06:01:33 AM
Lots of things aren't currently working. The "F 37" problem is somehow caused by the PGNS mode control switch, as I said above. So just switch it to off, then you can do inputs on the DSKY again.

But I think something is screwy with the Luminary code or something...

Actually, there was a bug in Virtual AGC (https://github.com/rburkey2005/virtualagc/issues/30), but by simply asking about it they were already able to fix it.  :ROTFL3453: I'll commit that fix, but it probably has not much further use than fixing attitude holding for pitch angles greater than 180°. I'm not sure about these 1103 alarms. I never had them on previous LM activation attempts, so it's possible that it is somehow caused by the new Apollo 11 LM Padload or I did something wrong in the LM activation procedure. More likely is that some input/output stuff is causing the LGC to panic, so some problem on the NASSP side. I wish I could read the alarm data. If you use V05 N08, then it gives you additional information about the program alarm. Maybe we could track it down that way.


Title: Re: LM status...
Post by: eddievhfan1984 on August 22, 2016, 08:10:46 AM
Well, I even tried disabling PGNS auto to take control of the vehicle, and even switched the throttle control to manual, but still can't get back to idling. I'll try the new build though, in any case.


Title: Re: LM status...
Post by: indy91 on August 22, 2016, 08:11:56 AM
A few more LM changes.

-The engine thrust indicator now shows the current thrust. Should probably be connected to the appropiate circuit breaker.
-The state of left FDAI is now saved and loaded.
-The Virtual AGC issue I mentioned above is now fixed.

I already have a pretty good idea how to fix the panel loading thing, but I'll have to look into it a little bit more.

Well, I even tried disabling PGNS auto to take control of the vehicle, and even switched the throttle control to manual, but still can't get back to idling. I'll try the new build though, in any case.

It is always the PGNS mode control switch that causes that problem for me. Set to off I have no problem switching to another program anymore.


Title: Re: LM status...
Post by: eddievhfan1984 on August 22, 2016, 09:27:35 AM
Worked this time, although the P63 freeze now calls alarm 1210—that two programs are trying to use the DSKY at the same time. This may be related to how I was trying to use V57 to get a look at slant range to the landing target.


Title: Re: LM status...
Post by: indy91 on August 22, 2016, 09:53:30 AM
Worked this time, although the P63 freeze now calls alarm 1210—that two programs are trying to use the DSKY at the same time. This may be related to how I was trying to use V57 to get a look at slant range to the landing target. So I don't know, maybe it wants to run an abort program or there even is some interference with the old LM autopilot?! Very much possible.

Yeah, I get the 1210 sometimes, too. Even without trying the V57. The landing radar isn't functional yet though, it has all the LGC interaction and the test mode, but no way to get altitude and velocities yet.

I have done some more work:

-I commited my attempt to fix the panel loading issue on scenario start. This could very well break something, so watch out for any new issues.
-The LGC can now command APS and DPS ignition and shutdown! All that was wrong was a missing spare bit in the relevant output channel. I haven't disabled the normal Orbiter manual throttle control of the hover thrustgroup yet. So you can still throttle the APS and DPS as you want. But the LGC now shuts down the engines, when the signal is there, and it commands the APS to full thrust and the DPS to 10% thrust. For the P63 testing you will have to manually throttle to full thrust at 26 seconds. But P12 now works without the need to do any throttling.

This seems like a good time to explain the P12 scenario. There is not much to do. Just set the master arm switch to on, also the stage fire switch (the abort stage switch is not functional right now), set the engine arm switch to ASC and off you go!


Title: Re: LM status...
Post by: eddievhfan1984 on August 23, 2016, 12:16:10 PM
Haven't tried the auto ignition yet (got to recompile), but a new report: I tried triggering P70 2:30 into the burn. The computer began adjusting pitch for the abort and I got the 06 62 display back, but then it locked up like last time. But at least I know P70 is not likely an issue itself.


Title: Re: LM status...
Post by: indy91 on August 23, 2016, 01:38:07 PM
Haven't tried the auto ignition yet (got to recompile), but a new report: I tried triggering P70 2:30 into the burn. The computer began adjusting pitch for the abort and I got the 06 62 display back, but then it locked up like last time. But at least I know P70 is not likely an issue itself.

Same results here. Looks like the same problem as in P63, but of course P70 might have issues on its own. Luckily we have the Apollo 11 LM pad load, or else we might have never been able to work out the abort constants for it. The abort calculations were different from Apollo 12 on and we only have the GSOP for the later LGC versions. The LM pad load is very new though and I might have done something wrong with the LGC activation, so I'm going to check if all the relevant numbers are still in the erasable memory in the P63 testing scenario. At least the numbers for the ignition algorithm seem to be alright.

Other than that, I have done a bunch more work on the DPS and APS. Mostly DPS. Just a few things to test then it is ready to commit, here is what it will be:

-Complete simulation of the Descent Engine Control Assembly (DECA). Only thing missing is LGC throttle commands, haven't figured out how they work. Also AGS engine start commands, because we don't have a proper AGS yet.
-Manual engine start and stop button. These are only keys right now because our LM panel doesn't have these buttons. They are "+" on the numpad for engine start and "-" on the numpad for engine stop. Pressing engine stop resets the engine start button. After having stopped the engine this way, you have to reset the engine stop button by pressing it again.
-Realistic TTCA throttle commands. I have removed the hover thrust group, so there is no more standard Orbiter engine control for the DPS and APS. No DECA power, no DPS control. The thrust lever doesn't directly command linear thrust. The lever has 66° of movement. At the minimum position it commands 10% thrust. That is the minimum the DPS can do. At the 51° position of the lever it commands 50.6% engine thrust. That's the first linear segment. If I understand it correctly, there is a soft stop in that position. If you move it further the TTCA commands 92.5% thrust in the full deflection position. So a lot of precision possible in the first 50% percent of thrust and then quickly through the undesireable thrust regions to full thrust. The throttle lever is controlled with numpad "0" and numpad ",", so just like Orbiter hover engines. I haven't connected the throttle lever to any jostick controls yet, so if joysticks currently even work correctly with the LM, then the throttle control won't work yet. There seems to be an interesting mode of the TTCA, where the DPS thrust can be controlled with the TTCA hand controller as upwards translational thrust. I doubt it was used much...
-What should also work is the Descent Engine Command Override switch. It is mostly used during PDI and it keeps the engine running, even if the DECA loses power. But there are no more gimbal commands or throttle commands coming through to the DPS, so you have to fix the DECA power or abort.

As I said, some more testing on my part and then you all can try the realistic engine on/off and throttle operations.

EDIT: There were indeed a few typos in the LM padload, two of them would have made us problems in P64. It doesn't fix the P63 problems though. Another strange thing is that we get 401 errors when the PITCH angle is close to 90° and 270°. How does that make any sense?

Also, there is a conversion in the IMU so that the angles display for the LM have roll and yaw exchanged. If you roll to 90° with the LM, then you get gimbal lock, but the FDAI displays that you have rotated around the other axis. I wonder which one is wrong though. How is the IMU mounted in the LM? Or is the only difference to the CSM that the definition of roll and yaw are changed? Then the FDAI would agree about gimbal lock, but roll and yaw are not intuitive anymore. So I'm not sure which one is wrong. And this might be connected to the 401 alarms.


Title: Re: LM status...
Post by: eddievhfan1984 on August 23, 2016, 03:42:11 PM
Well, I would think for commonality, the IMU is mounted the same way on both vehicles relative to the AGC mountings, but yeah, the roll and yaw gimbals are exchanged. It still seems intuitive to me, because the IMU during landing is set up to yield 0,0,0 at the designated landing spot at nominal landing time, right? So a yaw heads-up would risk gimbal lock, but on the back (or front) during PDI, yawing should pose no issues, looking like a roll in that orientation.


Title: Re: LM status...
Post by: indy91 on August 23, 2016, 04:03:44 PM
Well, I would think for commonality, the IMU is mounted the same way on both vehicles relative to the AGC mountings, but yeah, the roll and yaw gimbals are exchanged. It still seems intuitive to me, because the IMU during landing is set up to yield 0,0,0 at the designated landing spot at nominal landing time, right? So a yaw heads-up would risk gimbal lock, but on the back (or front) during PDI, yawing should pose no issues, looking like a roll in that orientation.

The Apollo 11 descent/ascent procedures first has pitching up to 105° and then yaw for 180° to heads down for the initial part of the powered descent. After that maneuver the pitch angle is 285°. So whatever is wrong, it is not what I initially thought.

The problem with how the IMU in the LM currently works is that you can freely move through the red area of the FDAI without gimbal lock. Gimbal lock happens when you roll to 90°, so when the engine is out-of-plane. But on the FDAI that seems like a save attitude.


Title: Re: LM status...
Post by: eddievhfan1984 on August 23, 2016, 04:06:27 PM
Exactly, because even though +X is aligned with the DPS and APS thrust direction, it's now the yaw axis, not the roll axis. So the FDAI drives have to be swapped, at least.

EDIT: I also did some mods to the LM panel source code, so that the proper-looking FDAI shows up, and I also enabled the right-side FDAI as well.


Title: Re: LM status...
Post by: eddievhfan1984 on August 24, 2016, 03:00:10 AM
BRAINSTORM: I think I may know why the LGC is locking up during descent. We don't model the landing radar as of yet, but is the "data good" signal still enabled?

And I'm digging through the assembly code, trying to find the I/O channels for DPS throttling. I know it's a 3.2kHz pulse train on either the increase or decrease bits (depending on the program), and I feel like I could find it soon.

Also, does anybody know how to troubleshoot a pushbutton that works (does its function) without animating properly?


Title: Re: LM status...
Post by: indy91 on August 24, 2016, 04:09:53 AM
Well, I'm stupid. I had a major msconception about the TTCA. I thought the lever on the right is the throttle. That is just the switch to allow the x-axis of the hand controller a wider movement. With the switch set to JETS the TTCA works pretty much like the THC in the CM. With the switch set to THROTTLE the x-axis of the handle gets a much wider range of movement, from about 10° up and down in JETS mode to all in all 66°. So the lever changes the behavior of the handle whose x-axis is the actual throttle. With manual control you can then control the throttle and sideways and forwards/backwards translational trusters at the same time, if you want. But I guess nobody really has a THC/TTCA style controller and with a normal joystick it's probably pretty awkward to try and use the x-axis as the throttle. So I'll change a few things, but I have the throttle mapped to the first slider of both the rotational and the translational joystick that are connected. I don't think we have the TTCA switch either, but should I try to map the throttle to the up/down translational axis (numpad 2 and 8 ) when in THROTTLE mode? Or should I leave it like the normal hover controls? I guess the average user has 0-1 joysticks, so it should be possible to fully control the LM with just the keyboard and we should also map useful functions (like the ROD switch) to the one joystick, if connected. And with two joysticks attached... I guess only give the TTCA the throttle and the additional switches?

Exactly, because even though +X is aligned with the DPS and APS thrust direction, it's now the yaw axis, not the roll axis. So the FDAI drives have to be swapped, at least.

EDIT: I also did some mods to the LM panel source code, so that the proper-looking FDAI shows up, and I also enabled the right-side FDAI as well.

Great! Do a pull request on github or attach your changes to the next post, so I can incorporate them.

BRAINSTORM: I think I may know why the LGC is locking up during descent. We don't model the landing radar as of yet, but is the "data good" signal still enabled?

And I'm digging through the assembly code, trying to find the I/O channels for DPS throttling. I know it's a 3.2kHz pulse train on either the increase or decrease bits (depending on the program), and I feel like I could find it soon.

Also, does anybody know how to troubleshoot a pushbutton that works (does its function) without animating properly?

Data good shouldn't be on. The landing radar has all the LGC interaction and test mode, but during the landing it should always have altitude and velocity "data bad". I can check if there is going something wrong. Pretty sure the problem also occured, when you pull the LR circuit breaker. But some bit on the I/O channel would still be wrong.

Yeah, from the GSOP section 6 (simulator data) we can find the conversion between the pulses (each is about 2.7 pounds of thrust) and throttle signal. But I'm not sure it is done via the normal I/O channels, there only is a thrust activity bit, but I think it at least has to be two bits (DPS Throttle Up, DPS Throttle Down) to work properly.

Which pushbutton is a problem? Master Alarm?

EDIT: Found the thrust pulses register. Its erasable memory address is 055. Now to find out how to work with it...


Title: Re: LM status...
Post by: indy91 on August 24, 2016, 06:36:20 AM
I have commited the LM update. It's a pretty complete simulation of the Descent Engine Control Assembly. I have already explained it a few posts above. With regards to the throttle issue, I have for now decided on this configuration:

-If you have a joystick as the ACA connected, then slider 0 of it (usually the throttle lever) will be the the TTCA throttle control. This is of course cheaty, but I guess it is a fairly normal configuration to have only one joystick, used as ACA/RHC. Right? If you think the throttle should only be controlled with the numpad in this configuration, let me know.
-If you have a joystick as the TTCA connected, the slider 0 is the JETS/THROTTLE switch/lever of the TTCA. In the forward/up position it is in THROTTLE, in the back/down position it is in JETS. In the first case the x-axis of the joystick can be used as the throttle control.
-If two joysticks are connected as ACA/RHC and TTCA/THC then I don't know what currently happens. I can't test that.
-If no joystick is connected, then the numpad hover controls are used for throttle control.

EDIT: The LR currently doesn't save its state, so maybe there is indeed something that causes the LGC to freak out.


Title: Re: LM status...
Post by: eddievhfan1984 on August 24, 2016, 11:43:56 AM
Actually, it's the ABORT/ABORT STAGE switches. The switches activate like they're supposed to, but I can't get the button animation to work properly, even after programming in the right offsets. I'm also trying to get the FDAI pointers to animate properly as well.

I'll try a pull, in any case.

As for the DECA, that's what's so confusing—according to the systems docs from 1970, there's two bit lanes for the thrust commands, but the assembly code only indicates one I/O channel for driving the thrust command display, and the thrusting commands are written to erasable memory, implying some kind of DMA to the DECA. And maybe since we know what the memory word is, it can be monitored for where the pulses are via debug line?

EDIT: I may have to send you the changes; I can't seem to create a branch or fork, and any attempt to clone or checkout via the Git GUI leads to complaints of "file-level merge".


Title: Re: LM status...
Post by: indy91 on August 24, 2016, 12:06:17 PM
Actually, it's the ABORT/ABORT STAGE switches. The switches activate like they're supposed to, but I can't get the button animation to work properly, even after programming in the right offsets. I'm also trying to get the FDAI pointers to animate properly as well.

Yeah, I think I tried the same thing as you. The "register" function was commented out and if you let it register again, then it paints a Frankstein's monster version of the Abort buttons over the panel. My guess is that previously the abort buttons weren't on the big main panel itself, but instead were a separate bitmap. And now the coordinates for the new abort buttons are incorrect.

Quote
I'll try a pull, in any case.

Careful, in the most recent update I have also done some changes to the lempanel.cpp. I have never done a pull request myself (never worked with github before NASSP), but it seems like a good way to help with projects. If it is too much effort or too complicated, just post the relevant lines of code here. I don't mind either way.

Quote
As for the DECA, that's what's so confusing—according to the systems docs from 1970, there's two bit lanes for the thrust commands, but the assembly code only indicates one I/O channel for driving the thrust command display, and the thrusting commands are written to erasable memory, implying some kind of DMA to the DECA. And maybe since we know what the memory word is, it can be monitored for where the pulses are via debug line?

Yeah, I don't know what those two "increase thottle" and "decrease throttle" lines are supposed ot be. The AGC has a "Thrust activity" bit in the output channel and  the THRUST register. I have written the THRUST register in a debug line, it certainly is the right one. A negative number in the register is probably thrust decrease and a positive number thrust increase. Without a thrusting maneuver the register says "67777" which might be maximum throttle decrease?! At 26 seconds into P63 it commands "10000", so it does want to throttle up at the correct time. "10000" probably means maximum increase. When you manually throttle up then it has slightly different commands, but even at full thrust it wants to increase thrust. Which should be realistic. The actual DECA has a counter that converts the signal from the LGC into voltage which is added to the manual signal.

The commanded thrust display is simply the added manual and automatic thrust commands.


Title: Re: LM status...
Post by: eddievhfan1984 on August 24, 2016, 03:14:42 PM
Yeah, I iterated until the buttons line up now. They just won't show the button-depressed or guard-up bitmaps when I click them. The rate pointers are difficult since they're differently shaped from the CSM pointers, so I have to add in an extra flag to control rendering...


Title: Re: LM status...
Post by: eddievhfan1984 on August 24, 2016, 04:57:58 PM
Here's my copy of the LM and systems source code folders. They have my changes so far...


Title: Re: LM status...
Post by: eddievhfan1984 on August 25, 2016, 01:21:40 AM
I went ahead and also forked the repository, but now I'm VERY sure that the P63 lockup has to do with the landing radar. According to the LM documentation, the LM starts awaiting landing radar information (in raw Doppler frequency format, mind) after 50,000 feet; it's only that due to the landing radar limitations, good data is not usually available until 30,000 feet. I kept a close eye on the DSKY during the recent test I did (other times, I had been eyeing the event timer or the FDAI), and noticed that in one of the 2-second guidance cycles after crossing 50,000 feet, the DSKY blanked, which is synonymous with starting the radar processing routine, and then the 06 62 came back briefly, only for the ALT light to come on, followed by the P00D00. This indicates to me that it's expecting landing radar data (even if it's bad), and not getting it, it confuses the software, causing the 1103.


Title: Re: LM status...
Post by: dseagrav on August 25, 2016, 02:33:21 AM
Did I ever commit the changes to the LR that made it able to pass the LR self-test?


Title: Re: LM status...
Post by: eddievhfan1984 on August 25, 2016, 02:38:28 AM
I don't think so. The tapemeters don't drive.


Title: Re: LM status...
Post by: indy91 on August 25, 2016, 04:31:34 AM
Did I ever commit the changes to the LR that made it able to pass the LR self-test?

The landing radar has range and velocity data during the self test, but that's about it. Also a small change to the radar tape is required, because it currently only displays rendezvous radar data.

Here's my copy of the LM and systems source code folders. They have my changes so far...

I'm sorry, but it's exceedingly difficult to merge those changes. Your version was a few commits behind and there are a few things I don't understand. First, the changes to the FDAI class are probably good. They are required to make it work for the LM. Although maybe the rate scale stuff shouldn't even be in the FDAI class itself, but in the supplying functions. What is this extremely large "LEMResources.aps" file? Why is there a "lmresources." and a "lmresources.h" file and the former is being used in "LEMResources.rc"? Also, why was the left FDAI moved 1 pixel? And for me the changes don't really work, it has not-functional error needles.

I went ahead and also forked the repository, but now I'm VERY sure that the P63 lockup has to do with the landing radar.

But why do we get the same alarm with the same alarm data (V05 N08) even without trying P63 and without having the LR on? Sometimes all you have to do is put the PGNS Mode Control switch to Auto and you get the 1103. The alarm data always reads R1: 2032 R2: 36106. I don't really know how to read this, but if 36016 is an address in the fixed memory, then it leads to P70/P71 and specifically the beginning of the routine "GOABORT". Maybe something is still trying to trigger an abort. 36016 is also just after it calls INITCDUW, which could indicate that is has to do with the 401 alarms and the wrong gimbal lock area.

EDIT: I've commited the things I have been working on so far. It's the GASTA, LR and RR save/load and a few other minor things, including my attempt to make the right FDAI work. It was just registering the FDAI and fixing one of the coordinates. Eddie, maybe it is a good idea if you use this new commit for your FDAI changes. I'm not going to change anything about the panel until that stuff is ready. It was just a nightmare to manage your changes with the changes I had already done, sorry.


Title: Re: LM status...
Post by: jalexb88 on August 25, 2016, 09:46:33 AM
Is the LR/RR close to functional? Is it now just a matter of feeding it the orbiter altitude/velocity? Great to see the LEM finalllly getting some attention.
Also, my LEM FDAI is not rotating in the proper direction but you think you guys have discussed and fixed it.


Title: Re: LM status...
Post by: indy91 on August 25, 2016, 10:07:24 AM
Is the LR/RR close to functional? Is it now just a matter of feeding it the orbiter altitude/velocity?

The LGC interaction seems to be mostly there, the actual measurements of altitude/velocity and range/range rate aren't currently done. It seems the RR was previously able to find the CSM, not sure if it is just a matter of including that portion of the code again. Altitude should be no problem. For the LR velocities I'll have to look up what the LR measures.

Quote
Great to see the LEM finalllly getting some attention.

It started with me being annoyed that the LM currently uses Luminary099, but still had the Luminary131 padload. So I copied the padload from the Apollo 11 padload document, made a few smaller changes and wanted to find out how far I could take the LM. And the answer was almost 4 minutes into PDI.  :ROTFL3453:

Quote
Also, my LEM FDAI is not rotating in the proper direction but you think you guys have discussed and fixed it.

What exactly do you mean not rotating properly? I don't even know anymore about this IMU/FDAI stuff, all I know is that they don't agree about gimbal lock. The FDAI has gimbal lock at 90° yaw, the IMU at 90° roll. At this point I'm mostly confused what exactly is wrong.


Title: Re: LM status...
Post by: vrouleau on August 25, 2016, 10:22:54 AM
I had done some work on the RR ( range calculation, slewing manually and auto track). Nothing for LR. I don't think is just a matter of calculating the range. There must be a function that zero's back the trunion when in landing mode and the LM is facing down. I probably tilts also as the LM tilts to land to keep the radar on the ground. I didn't read up on that .


Title: Re: LM status...
Post by: eddievhfan1984 on August 25, 2016, 11:03:47 AM
Well, Visual Studio was doing a weird thing. I had to add bitmaps to the LEMResources.rc to get the right images for the FDAI, and when I compiled the RC file, it created a C++ header without a file extension (like a Linux text file). Then I had to rename it to get the header included for the LL panel compilation and a whole lot of other complicated stuff I don't get...

I did the pixel shifts to manually line up the FDAI roll bezels on top of the panel as best I could. According to my compilation, the error needles work when in LR/computer error monitor mode. I did also enable both of the FDAIs. I mean,all I really changed was the LEMpanel.cpp and .h, the LEMresources.rc (which can be recompiled) and the FDAI.cpp and .h. Otherwise, you can ignore everything else in the zipped folders.

As for the V05N08, the R1 is supposed to be the address of the offending instruction, R2 being BBCON (not sure what that is yet). Maybe the instruction at the breakpoint?


Title: Re: LM status...
Post by: indy91 on August 25, 2016, 12:40:06 PM
Yeah, I only copied over the files that had a change date from yesterday. But it was still enough to cause a headache with changes I had commited after you started working on the FDAI and abort buttons (so I had to redo all my changes to those files) and it was a few changes too much for to simply commit it. And it didn't even really work for me. The error needs were simply a cross in the middle, like on the lem_FDAIRoll bitmap. But now I think I know what changes you have done, so I'll slowly incorporate them and look why it didn't properly work for me.

And yes, it would be great if we could track down the LGC problem with the alarm data.


Title: Re: LM status...
Post by: eddievhfan1984 on August 25, 2016, 12:52:02 PM
Right, I had the same problem. One of the complications was that if you tried to draw in a texture larger than the file you were referencing from, it wouldn't render at all.

EDIT: I looked through the definitions. Based on what I can tell for 05 08 displays, R1 is actually the lower word of the address. R2 is BBCON—stands for Both Bank Constant, since it encodes both the fixed memory bank and erasable memory bank the instruction is currently using. For R1=02032 and R2=36006 (are you sure it was 36106? According to definition, bits 4-10 should be 0), this means common fixed bank 15d/17o (reading bits 11-15), erasable bank 6 (bits 1-5), address 02032o. Hope that helps...

EDIT2: I FOUND IT. Based on the information provided by 05 08, the point at which the error is called is in the "Q and R axis RCS autopilot" assembly code, suggesting that it's associated with our current IMU issues. I also have the results from another test flight, but I will wait for a response first.


Title: Re: LM status...
Post by: indy91 on August 25, 2016, 07:31:33 PM
I tried my old Apollo 10 scenario that still had the old LM padload and the 1103 happens there, too. So it's not an issue with the new Apollo 11 padload.

Also, I wanted to try a docked maneuver with the LM and when I reached 90° pitch (I think) the FDAI went black and gimbal lock occured. Although the DSKY didn't have the light on, that sometimes seems to be the case in the LM. Pressing RSET once usually helps. And I also just tried to cause the 1003 again, I am sure the alarm data says 36106, not 36006.

EDIT2: I FOUND IT. Based on the information provided by 05 08, the point at which the error is called is in the "Q and R axis RCS autopilot" assembly code, suggesting that it's associated with our current IMU issues. I also have the results from another test flight, but I will wait for a response first.

All seems to point to it. That would also explain the random errors once you put the PGNS mode control switch AUTO. Something is up with the DAP, causing 1103's and the 401's (commanded MGA >85°) when it really shouldn't. It probably has to do with the IMU, The IMU class has some specific differences for the LEM, but when I changed it so that CSM and LM IMU are identical, then the yaw angle on the FDAI was interchanged with the roll angle. I'll search for the issue tomorrow.


Title: Re: LM status...
Post by: eddievhfan1984 on August 25, 2016, 08:21:36 PM
Well, that's just it. The IMU adjustment sets it up so that the vehicle's roll must be constrained to avoid gimbal lock. That might also explain the red warning band on the FDAI bezel, inside the error needle indicators. In which case, the LM FDAI shouldn't have a gimbal lock mark on the +90 and -90 yaw points.

As to the follow-up report... I watched over the AGC closely again during PDI, and took note of the errors I got this time. They included the 1103, but also a 405 (PICAPAR failure, how's that make sense?) and a 1520 (V37 locked out by COMP ACTY). In doing the P70 routine, I first disabled the automatic control mode, then pulled the LR breaker to make sure it wouldn't interfere. After the return of the 06 62 display, I manually turned towards the guessed abort vector, then re-enabled automatic attitude control. Seemed to work for a while, then I got another program alarm, 401. Shortly after that, the computer P00D00'd again. I disabled automatic control, then tried using the - key to shutdown the engine. Caused an immediate CTD.


Title: Re: LM status...
Post by: rcflyinghokie on August 25, 2016, 08:39:31 PM
How far is the P63 working?  I have run it quite a few times and at ignition my LM is totally upside down with respect to the moon and thus crashes in no time.  I am trying to figure out what I am doing wrong here.


Title: Re: LM status...
Post by: eddievhfan1984 on August 25, 2016, 08:45:09 PM
How far is the P63 working?  I have run it quite a few times and at ignition my LM is totally upside down with respect to the moon and thus crashes in no time.  I am trying to figure out what I am doing wrong here.

Are you running from indy's test scenario, or are you working from scratch?

Also, as well, indy, I incorporated the FDAI mods into your recent release. Just pull from my branch, and your FDAI should be working fine now.


Title: Re: LM status...
Post by: indy91 on August 26, 2016, 06:29:43 AM
Well, that's just it. The IMU adjustment sets it up so that the vehicle's roll must be constrained to avoid gimbal lock. That might also explain the red warning band on the FDAI bezel, inside the error needle indicators. In which case, the LM FDAI shouldn't have a gimbal lock mark on the +90 and -90 yaw points.

Ahh, of course. Also, something I was confused about, is that the LM FDAI angles are not identical to the IMU angles. Just try a V49 with e.g. 180°, 105° and 0° for the V06 N22. These are the IMU angles, OG, IG and MG. When you proceed to V50 N18 then the angles are roll, pitch and yaw, and they are not identical to the IMU angles. The GSOP has the IMU to FDAI transformation, but they don't immediately seem to work. Must be some different definition of arcsine/arccos in the AGC and normally used or so. Also, I think for the FDAI this transformation is done by the GASTA, that's why it is a separate system in the LM. It's a little bit more complicated than switching the coordinates of the IMU angles, that's why the FDAI sometimes has a strange behavior with a high yaw angle. When I work out the actual transformation, the FDAI should always get the correct information.

Quote
As to the follow-up report... I watched over the AGC closely again during PDI, and took note of the errors I got this time. They included the 1103, but also a 405 (PICAPAR failure, how's that make sense?) and a 1520 (V37 locked out by COMP ACTY).

These alarms are already there when you start the scenario. I guess they were from previous P52 etc. I probably didn't press RSET, because the PROG light wasn't on for some reason.

Quote
In doing the P70 routine, I first disabled the automatic control mode, then pulled the LR breaker to make sure it wouldn't interfere. After the return of the 06 62 display, I manually turned towards the guessed abort vector, then re-enabled automatic attitude control. Seemed to work for a while, then I got another program alarm, 401. Shortly after that, the computer P00D00'd again. I disabled automatic control, then tried using the - key to shutdown the engine. Caused an immediate CTD.

Weird, must be a very rare bug of the new engine start/engine stop "buttons". I didn't think engine stop could cause a CTD. I'll try to replicated with an LGC commanded engine start and then I'll test a few things. Did you also maybe change the ENG ARM switch before the engine stop?

Also, as well, indy, I incorporated the FDAI mods into your recent release. Just pull from my branch, and your FDAI should be working fine now.

Dammit, your diff shows that every single line of the files you worked on has been changed. Maybe a line ending problem? Did you follow the instructions in the git thread? I really can't commit these, if we can't reconstruct what has been changed...


Title: Re: LM status...
Post by: rcflyinghokie on August 26, 2016, 06:43:05 AM
Are you running from indy's test scenario, or are you working from scratch?

I have been running from the test.

EDIT:  I did not see a newer one posted after the time he posted the 12 and 63 together, I just loaded that one to try.

EDIT 2: Yep the older test file was the problem, thanks!


Title: Re: LM status...
Post by: indy91 on August 26, 2016, 07:46:29 AM
EDIT 2: Yep the older test file was the problem, thanks!

Ah yeah, that scenario was only capable of testing the P63 ignition routine. It didn't have a good alignment. On the half orbit down to perilune I fixed that and that's where the second scenario is from. Now you too can enjoy the 1103, 401 and 1210 alarms.

So it seems there isn't anything wrong with our IMU after all. I have changed the IMU function GetTotalAttitude() to send out the unconverted gimbal angles and let the GASTA do the job of converting them properly to FDAI angles. It now can smoothly yaw through 90°/270° without problems. Only at exactly 90° the pitch and roll angles become undefined.

What needs to be added is a special FDAI for the LM, without the gimbal lock area at 90° and 270° yaw. Has anyone seen a picture that confirms that the LM didn't have these areas? In that case the LM FDAIs probably look almost exactly like the original Shuttle FDAIs. Our bitmaps and texture don't have the red warning band for roll, right? I guess that needs to be added, too.


Title: Re: LM status...
Post by: rcflyinghokie on August 26, 2016, 09:32:07 AM
What needs to be added is a special FDAI for the LM, without the gimbal lock area at 90° and 270° yaw. Has anyone seen a picture that confirms that the LM didn't have these areas? In that case the LM FDAIs probably look almost exactly like the original Shuttle FDAIs. Our bitmaps and texture don't have the red warning band for roll, right? I guess that needs to be added, too.

I am hunting for a picture or documentation about the painted red area on the LM FDAI now, but yeah theoretically since the MG is Roll, that should have a gimbal lock warning zone.

EDIT:  I cannot find anything to confirm that the actual did not have the warning zone on the ball but it would make sense, just the red bands on the housing itself.  I am still looking but I think it is a safe bet to remove that zone from the LM FDAI if possible.

EDIT 2:  If we cannot reveal anything I think that would be the best course.  However I am going to DC in a few weeks I will stop by the NASM and check out the LM simulator panel there perhaps I can get the answer there?


Title: Re: LM status...
Post by: eddievhfan1984 on August 26, 2016, 10:25:45 AM
When I installed Git, I did tell it to leave the line endings alone. Maybe because your branch uses a different Windows locale, it assumes everything has been changed? Maybe it's because in order to preserve my edits during the older ZIP-based updates I used, I ZIPed the files I had modified, then copied them back after getting the new commit.

We do have an FDAI roll housing with those guard bands indicated; I added them to the panel in my fork.


Title: Re: LM status...
Post by: dseagrav on August 26, 2016, 12:49:23 PM
For some reason the last few posts in this thread got messed up, so I deleted them.


Title: Re: LM status...
Post by: eddievhfan1984 on August 26, 2016, 10:37:37 PM
I pushed my changes to the LM-panel_mods branch. You're OK to compare and push it to the origin branch at your leisure...

EDIT: Also, this link seems to confirm that with the exception of the roll gimbal lock marks, the LM FDAI nad no markings for yaw gimbal lock: http://www.collectspace.com/ubb/Forum29/HTML/001395.html (http://www.collectspace.com/ubb/Forum29/HTML/001395.html) It's a Shuttle FDAI, but the post says that it had its roots in the LM simulators, which would seem to lend some credence.

EDIT2: I went back over the alarm data, and I made a mistake. The error is actually located in the T6RUPT handler, which handles the timing of RCS pulses for the DAP. Here's the offending bit of code:

Key: Absolute (total) line no., subroutine line no.: fixed memory bank,address|*E*rasable bank,address|raw machine code|location label|instruction|operand(s)

Code:
059792,000077:    5753                                             BLOCK    02                                    
059793,000078:                                                                                                 #  Page 1404
059794,000079: 17,2027                                            BANK     17                                    
059795,000080: 17,2000                                            SETLOC   DAPS2                                
059796,000081: 17,2000                                            BANK                                          
059797,000082: 17,2027  E6,1466                               EBANK=   T6NEXT                                
059798,000083: 17,2027                                             COUNT*   $$/DAPT6                              
059799,000084:
059800,000085: 17,2027           10031        T6JOBCHK    CCS     TIME6                                 #  CHECK TIME6 FOR WAITING T6RUPT:
059801,000086: 17,2030           00002                          TC       Q                                     #  NONE: CLOCK COUNTING DOWN.
059802,000087: 17,2031           05705                          TC       CCSHOLE                              
059803,000088: 17,2032           02032                          TC       T6JOBCHK   +3                          

In short, this monitors the TIME6 erasable, which indicates when it's time to handle another T6 interrupt for the DAP. For whatever reason, this erasable location somehow becomes +0 (which should never happen, according to the software listing), which causes control to be transferred to the CCSHOLE routine, which triggers the 1103 alarm and the ABORT. Do we do anything weird with that memory location?


Title: Re: LM status...
Post by: indy91 on August 27, 2016, 05:58:14 AM
I pushed my changes to the LM-panel_mods branch. You're OK to compare and push it to the origin branch at your leisure...

Where is it? I don't see it in your NASSP fork. Maybe you have only commited it but not pushed to Github? I have only seen this pull request (https://github.com/dseagrav/NASSP/pull/22), with 26,000 lines changed.  :ROTFL3453:

Quote
EDIT: Also, this link seems to confirm that with the exception of the roll gimbal lock marks, the LM FDAI nad no markings for yaw gimbal lock: http://www.collectspace.com/ubb/Forum29/HTML/001395.html (http://www.collectspace.com/ubb/Forum29/HTML/001395.html) It's a Shuttle FDAI, but the post says that it had its roots in the LM simulators, which would seem to lend some credence.

I trust Eagle Lander 3D on this, too. The LM FDAI had no red yaw gimbal lock areas.  :ThumbsUp432:

Quote
EDIT2: I went back over the alarm data, and I made a mistake. The error is actually located in the T6RUPT handler, which handles the timing of RCS pulses for the DAP. Here's the offending bit of code:

Key: Absolute (total) line no., subroutine line no.: fixed memory bank,address|*E*rasable bank,address|raw machine code|location label|instruction|operand(s)

Code:
059792,000077:    5753                                             BLOCK    02                                    
059793,000078:                                                                                                 #  Page 1404
059794,000079: 17,2027                                            BANK     17                                    
059795,000080: 17,2000                                            SETLOC   DAPS2                                
059796,000081: 17,2000                                            BANK                                          
059797,000082: 17,2027  E6,1466                               EBANK=   T6NEXT                                
059798,000083: 17,2027                                             COUNT*   $$/DAPT6                              
059799,000084:
059800,000085: 17,2027           10031        T6JOBCHK    CCS     TIME6                                 #  CHECK TIME6 FOR WAITING T6RUPT:
059801,000086: 17,2030           00002                          TC       Q                                     #  NONE: CLOCK COUNTING DOWN.
059802,000087: 17,2031           05705                          TC       CCSHOLE                              
059803,000088: 17,2032           02032                          TC       T6JOBCHK   +3                          

In short, this monitors the TIME6 erasable, which indicates when it's time to handle another T6 interrupt for the DAP. For whatever reason, this erasable location somehow becomes +0 (which should never happen, according to the software listing), which causes control to be transferred to the CCSHOLE routine, which triggers the 1103 alarm and the ABORT. Do we do anything weird with that memory location?

Impressive detective work you are doing there. I didn't immediately find something setting the T6RUPT bit on the input channel 13, but maybe something is causing an issue there...

EDIT: If I monitor input channel 13 then it says 04000 in the P63 scenario. If I change it to 40000 and cause the 1103 error, then it is 04000 again. So yes, something seems to be going on in that input channel.


Title: Re: LM status...
Post by: indy91 on August 27, 2016, 10:34:27 AM
I managed to fly a proper P71 abort. When the 1103 alarm 4 minutes into PDI happens, I pressed abort stage (In the current build the buttons still don't work), I never changed the PGNS Mode Control Switch and then manually selected P71. It brought me in a 14x113NM orbit, which I think is what it is supposed to do. I don't know much about the abort constants in Luminary099 and there is no GSOP for it, so all we can do is use the constants provided with the padload document. All I know is they depend on the time since PDI. Anyway, I guess if you uplink good state vectors for LM and CSM you should be able to fly aborts soon. If you want some nice procedures with the CSM (http://hdl.handle.net/2060/19700025402), the abort case of "<60 No PDI1 + 12 (CSM active)" is pretty crazy. In that case the LM is completely inactive after the DOI burn and can't even do a phasing maneuver or does one with less than 60 ft/s. This procedures has 3(!) CSI burns and takes almost 7 hours after the abort. Our CSM should be able to do all of that (maybe not so much spotting the LM in the sextant at 400NM distance without cheating), so have fun.  :ROTFL3453:


Title: Re: LM status...
Post by: eddievhfan1984 on August 27, 2016, 12:37:22 PM
Yeah, I did a commit to master instead of the fork I made, but I can't push, since it 403s me out for not having push permissions. I edited the files themselves rather than doing a full file replace like I did last time. I haven't enabled the ABORT/ABORT STAGE switches in my commit, though—the buttons in our Bitmaps are too small, like it was from the earlier NASSP release. It would be nice if someone could create new buttons from the main panel bitmap; I don't quite have the editing skills for that.


Title: Re: LM status...
Post by: indy91 on August 27, 2016, 02:10:40 PM
Yeah, I did a commit to master instead of the fork I made, but I can't push, since it 403s me out for not having push permissions. I edited the files themselves rather than doing a full file replace like I did last time. I haven't enabled the ABORT/ABORT STAGE switches in my commit, though—the buttons in our Bitmaps are too small, like it was from the earlier NASSP release. It would be nice if someone could create new buttons from the main panel bitmap; I don't quite have the editing skills for that.

You couldn't push to your fork or dseagrav/NASSP? For the latter dseagrav would have to add you as a contributor. Again, either just push your changes to your fork and then try a pull request or let me try to handle your now updated files. It just was a little too much to incorporate the changes from files that were a few commits behind and it had a few changes that were not really in a state to be commited to the master branch, like the strange "lmresource." file.

Also, I have some very good news. I now know why Orbiter is crashing when you exit a scenario with the LM and I also know how to fix it. It has to do with the PanelSDK. All hydraulic and electrical systems in the CSM are predefined in the SaturnSystems.cfg before they are initiated in the code. The LM also has such a file "LEMSystems.cfg", but only the batteries are in that file right now. While you can manually define these systems in the code, the part of the PanelSDK that keeps track of all systems has no pointers to them. Saving and loading works, but when you exit a scenario all thermal, hydraulic and electrical systems get destroyed, the PanelSDK tries to delete the elements with NULL pointers, and a crash happens. Luckily we don't have the LM ECS yet, so there are only a few systems that have to be added to the config. Looks like a few heaters and antennas (which are radiating heat).

EDIT: I'm merging your stuff manually, Eddie. Only the FDAI stuff at first. It was just too many changes that I didn't all understand couldn't handle all at once. Especially if github is freaking out and thinks 26,000 lines have been changed.

EDIT2: Now tell me what I all forgot.


Title: Re: LM status...
Post by: eddievhfan1984 on August 27, 2016, 09:25:48 PM
OK, I just checked out the master branch, but no changes appear to have been made to the FDAI...

EDIT: NVM, I did a merge to master, seems to have worked.


Title: Re: LM status...
Post by: indy91 on August 28, 2016, 04:30:38 AM
OK, I just checked out the master branch, but no changes appear to have been made to the FDAI...

EDIT: NVM, I did a merge to master, seems to have worked.

I have moved a few boilers and radiators to the LEMSystems.cfg and now Orbiter doesn't crash anymore on scenario exit! It wasn't quite straight forward, the parameters one has to use in the config for the system definition are a little bit different from the parameters used in the constructor of the system's class. Hopefully I have done it all correct and it also should load the saved systems from a scenario, because I gave the systems the same names as they had before.

Also, I just tried a few things with the new FDAI. The error needles are quite different from the CSM. Are they behaving as expected? Right now they can only get a signal from the RR though.

I added back the thruster group hover. I thought that would directly map the thruster to the standard Orbiter keys for hover (Numpad 0 and ,) and enable thrusting whenever a propellant resource is connected, but that doesn't seem to be the case. The SPS is also defined as a thruster group and works fine without letting the user manually use it. The thruster groups are used in a few RTCC calculations for the LEM (mostly REFSMMAT, more to come soon!) so it is useful to have it. Let me know if there are cases where you can throtle up the DPS when you shouldn't be able to. It doesn't look like it breaks anything though.


Title: Re: LM status...
Post by: rcflyinghokie on August 28, 2016, 04:42:13 AM
No CTD!  Thats awesome!!  Nice work :)

Has there been any more research as to why the LGC likes to go to F37 with a PROG light half the time during the auto maneuver on the P63?  Same procedure, but sometimes as soon as it fires RCS to maneuver I get the F37 and other times no issues.  I feel like I am violating the definition if insanity, trying the same experiment AND getting different results.


Title: Re: LM status...
Post by: indy91 on August 28, 2016, 04:59:40 AM
Has there been any more research as to why the LGC likes to go to F37 with a PROG light half the time during the auto maneuver on the P63?  Same procedure, but sometimes as soon as it fires RCS to maneuver I get the F37 and other times no issues.  I feel like I am violating the definition if insanity, trying the same experiment AND getting different results.

All I have researched is that the input channel 13 in the LM has a different behavior than the CMC. It has something to do with TIME6, T6RUPT and the LGC internal timing of RCS firings. Something is going on there. But at this point I have no idea if something is going wrong in NASSP or the Virtual AGC. The old AGC++ used the same input/ouput channels as the Virtual AGC, so there was still some legacy code. You might have seen a P70 or P71 on scenario start until a few days ago. There was a function searching for an abort signal not knowing that the input channel bits for ascent and descent aborts are inverted in the actual AGC. But the old AGC is disabled in Virtual AGC scenarios, so all it did was put a P70 or P71 display on the DSKY. So something like this could still be going on somewhere, old code interfering with Virtual AGC operation. I also tried this LGC Simulator (http://www.cems.uwe.ac.uk/~jtwebb/agc/agc_simulator.htm) to look for similar behavior, but it crashes once it wants RCS control. Reproducing the problem with the standalone Virtual AGC is probably very difficult, because you would have to change all the input channels manually so it thinks it is in control. Once we are a little bit more convinced it is not a NASSP problem (I still think it is), then we could ask Ron Burkey about it. Just few days ago I implemented a fix they found for a DAP problem (https://github.com/dseagrav/NASSP/commit/2a326a674f7e2ba37bb46b62be0d6f3b53d7af36). The LGC wasn't able to hold attitude at pitch>180°. So the Virtual AGC is not completely bug free.

EDIT: Eddie, you have also changed one of the FDAI error needles in the CSM. Was that intentional?


Title: Re: LM status...
Post by: eddievhfan1984 on August 28, 2016, 11:40:23 AM
No, the CSM error needle change wasn't intentional. Might've transposed a few bits of code I didn't mean to. And I set up the LM FDAIs to get their error signals from the ATCA class, although they tend to behave oddly when flight control is taken off auto, since they stop updating...


Title: Re: LM status...
Post by: indy91 on August 28, 2016, 02:35:43 PM
No, the CSM error needle change wasn't intentional. Might've transposed a few bits of code I didn't mean to.

Ok, I'll change it back.

Quote
And I set up the LM FDAIs to get their error signals from the ATCA class, although they tend to behave oddly when flight control is taken off auto, since they stop updating...

The CSMcomputer compared to the LEMcomputer has a little bit of extra code to set the error needles to zero, if the error counter isn't on. That should do it.

Also, I wanted to implemented the ORDEAL for the LM, but the bitmap is simply invisible. Only the switches show up. Eddie, you have just worked with that stuff, any idea why it wouldn't show up? It doesn't seem to call clbkPanelRedrawEvent() for the ORDEAL case, but I have used oapiRegisterPanelArea() correctly, I thought. Actually, I almost copied the code one to one from the CSM. Any ideas?


Title: Re: LM status...
Post by: eddievhfan1984 on August 28, 2016, 03:05:48 PM
Did you register a space for the ORDEAL? I didn't see a line of code regarding that in the lempanel.cpp.


Title: Re: LM status...
Post by: indy91 on August 28, 2016, 04:01:30 PM
Well, I haven't added anything for the ORDEAL yet in the latest commits. I've used oapiRegisterPanelArea(), if you meant that with registering. I want to put it in the top left-hand corner of the main panel. In the actual LM the ORDEAL was loacted next to panel 8 (https://www.hq.nasa.gov/alsj/a12/LM6-co17.jpg), but that's not very useful for changing the pitch on the FDAI. If I as a test put the ORDEAL over the left window, then a transparent rectangle is appearing over the window. So something is there, but not the ORDEAL panel. It's not a problem with the bitmap, I've tried replacing the CSM ORDEAL with it, works without problem. As I said, the "AID_ORDEALSWITCHES" or so is simply not called IN clbkPanelRedrawEvent(), despite the panel area being registered. So it never is drawing the bitmap. Is there an additional step that I am overlooking? Or is it some kind of layer problem? You had changed a few numbers in the lmresources.h, that I don't quite understand. Maybe it has something to do with that?


Title: Re: LM status...
Post by: rcflyinghokie on August 28, 2016, 05:56:04 PM
All I have researched is that the input channel 13 in the LM has a different behavior than the CMC. It has something to do with TIME6, T6RUPT and the LGC internal timing of RCS firings. Something is going on there. But at this point I have no idea if something is going wrong in NASSP or the Virtual AGC. The old AGC++ used the same input/ouput channels as the Virtual AGC, so there was still some legacy code. You might have seen a P70 or P71 on scenario start until a few days ago. There was a function searching for an abort signal not knowing that the input channel bits for ascent and descent aborts are inverted in the actual AGC. But the old AGC is disabled in Virtual AGC scenarios, so all it did was put a P70 or P71 display on the DSKY. So something like this could still be going on somewhere, old code interfering with Virtual AGC operation. I also tried this LGC Simulator (http://www.cems.uwe.ac.uk/~jtwebb/agc/agc_simulator.htm) to look for similar behavior, but it crashes once it wants RCS control. Reproducing the problem with the standalone Virtual AGC is probably very difficult, because you would have to change all the input channels manually so it thinks it is in control. Once we are a little bit more convinced it is not a NASSP problem (I still think it is), then we could ask Ron Burkey about it. Just few days ago I implemented a fix they found for a DAP problem (https://github.com/dseagrav/NASSP/commit/2a326a674f7e2ba37bb46b62be0d6f3b53d7af36). The LGC wasn't able to hold attitude at pitch>180°. So the Virtual AGC is not completely bug free.

After some experimentation, I have noticed I do not get that error if I manually maneuver to the auto maneuver attitude first before enabling PGNS AUTO and hitting proceed.  I don't know if this tid bit helps in isolating the error but just something I have noticed.


Title: Re: LM status...
Post by: eddievhfan1984 on August 28, 2016, 06:38:46 PM
All I did was add some entries for the FDAI-related stuff. The resource file generated referencing numbers for them, but it shouldn't have overwritten anything, or there'd have been a hash collision out the wazoo.


Title: Re: LM status...
Post by: indy91 on August 29, 2016, 07:56:17 AM
Well, I'm not having much success with what I am trying. I just am not experienced enough with the Orbiter SDK to find the issue with LM ORDEAL. I'll gladly leave this for someone else to try. I also tried to implement the Virtual AGS and I think I have it running, but all the IO stuff is way too difficult for me, and without interaction with the DEDA there is not much to do with it. So I leave that for someone with more expertise in this low-level coding, too. I guess I will try to solve the 1103 alarm issue, but I don't really know where to start either. This part of the AGC engine code:

Quote
     // I'm not sure if TIME6 is supposed to count when the T6 RUPT
      // is disabled or not.  For the sake of argument, I'll assume
      // that it is.  Nor am I sure how many bits this counter has.
      // I'll assume 14.  Nor if it's out of phase with SCALER1.
      // Nor ... well, you get the idea.

suggest that there actually could be something not 100% correct with the Virtual AGC.

That leaves making the RTCC MFD work for the LM and/or working on Apollo 7 and 8 topics again.  :|


Title: Re: LM status...
Post by: rcflyinghokie on August 29, 2016, 10:14:31 AM
That leaves making the RTCC MFD work for the LM and/or working on Apollo 7 and 8 topics again.  :|

Could always play with that V40 in the IMU setting the gimbal angles and not just the CDU to zero, see if we can resolve that conundrum ;)  Also maybe the maneuver to SEP ATT on Apollo 9 before TD&E?  Just spit balling :)


Title: Re: LM status...
Post by: indy91 on August 29, 2016, 11:41:39 AM
I'm not going to run out of things to do for NASSP for the next few probably years, it's just that the RTCC MFD and work for a Apollo 7+8 release are at the top of my agenda.

I'm still not 100% sure what the correct change to the IMU for the V40 issue is. ICDU zero appears a few time in the code there. Sep attitude for Apollo 9 is of course easy, just copying the code for the Saturn 1B LVDC and some kind of logic that chooses between moving to separation attitude in timebase 5 vs. 7.


Title: Re: LM status...
Post by: eddievhfan1984 on August 29, 2016, 11:57:54 AM
Well, I'm not having much success with what I am trying. I just am not experienced enough with the Orbiter SDK to find the issue with LM ORDEAL. I'll gladly leave this for someone else to try. I also tried to implement the Virtual AGS and I think I have it running, but all the IO stuff is way too difficult for me, and without interaction with the DEDA there is not much to do with it. So I leave that for someone with more expertise in this low-level coding, too. I guess I will try to solve the 1103 alarm issue, but I don't really know where to start either. This part of the AGC engine code:

Quote
     // I'm not sure if TIME6 is supposed to count when the T6 RUPT
      // is disabled or not.  For the sake of argument, I'll assume
      // that it is.  Nor am I sure how many bits this counter has.
      // I'll assume 14.  Nor if it's out of phase with SCALER1.
      // Nor ... well, you get the idea.

suggest that there actually could be something not 100% correct with the Virtual AGC.

That leaves making the RTCC MFD work for the LM and/or working on Apollo 7 and 8 topics again.  :|

That's definitely an issue. I can confirm that TIME6 *does* control the handling of T6RUPT, that it has a 15-bit counter like all the other low-level erasables, and its counter is incremented with a DINC counter interrupt @ 1.6kHz. However, there is a mistake in the Virtual AGC software listings—TIME6 should NEVER be negative or positive-zero (only positive or negative-zero); that's what's triggering all these 1103 alarms. Plus, since these are all tied into the master clock, I don't see why the other scalars and TIME6 wouldn't be in-phase.


Title: Re: LM status...
Post by: indy91 on August 29, 2016, 01:01:16 PM
I'm not quite sure I understand. Do you think there is an issue with the actual LGC code or in the AGC engine? Or do you just mean the comments in the listings? Here the complete handling of T6RUPT in agc_engine.c:

Code:
     // I'm not sure if TIME6 is supposed to count when the T6 RUPT
      // is disabled or not.  For the sake of argument, I'll assume
      // that it is.  Nor am I sure how many bits this counter has.
      // I'll assume 14.  Nor if it's out of phase with SCALER1.
      // Nor ... well, you get the idea.
      State->ExtraDelay++;
      if (CounterDINC (State, 0, &c (RegTIME6)))
 if (040000 & State->InputChannel[013]) {
 State->InterruptRequests[1] = 1;
 }

I guess all this does (apart from diminshing TIME6) is set T6RUPT, if TIME6 is... positive I guess? It looks like CounterDINC returns 1, if the diminshed value is still positive. You seem to understand this better than me, is there something wrong in  the code snippet above or CounterDINC?


Title: Re: LM status...
Post by: eddievhfan1984 on August 29, 2016, 04:15:36 PM
Well, you said decrement. TIME6 can only increment, and when it overflows into negative zero is when T6RUPT is called on the next DINC, resetting to 1 after the interrupt is processed. Decrementing to zero is what causes the CCS instruction to call the 1103 alarm, since it's not behaving properly.

EDIT: I also looked at the Virtual AGC debug log from one of my recent runs, and there's quite a bit of writing all balls to TIME6. That should not happen under *any* circumstance.


Title: Re: LM status...
Post by: indy91 on August 29, 2016, 04:29:21 PM
Well my short question is: do you know exactly what is wrong, or can find it out, and do you think you can fix it?

One of the earlier entries in the changelog is:

Quote
08/28/05 RSB   Oops!  Had been using PINC sequences on
            TIME6 rather than DINC sequences.

So currently RegTIME6 is changed with DINC. DINC is "diminish increment", whatever that means, lol, I guess it doesn't mean decrement. If you are sure it's a problem in the agc_engine.c, then you might want to open an issues here: https://github.com/rburkey2005/virtualagc/issues There is also a lot of commented lines of code with TIME6 in the agc_engine.c, almost looks like an earlier attempt to fix something...


Title: Re: LM status...
Post by: eddievhfan1984 on August 29, 2016, 04:37:58 PM
Well my short question is: do you know exactly what is wrong, or can find it out, and do you think you can fix it?

One of the earlier entries in the changelog is:

Quote
08/28/05 RSB   Oops!  Had been using PINC sequences on
            TIME6 rather than DINC sequences.

So currently RegTIME6 is changed with DINC. DINC is "diminish increment", whatever that means, lol, I guess it doesn't mean decrement. If you are sure it's a problem in the agc_engine.c, then you might want to open an issues here: https://github.com/rburkey2005/virtualagc/issues There is also a lot of commented lines of code with TIME6 in the agc_engine.c, almost looks like an earlier attempt to fix something...

I'm sure that's it. DINC only increments by +1 when the counter is negative—another 1103 alarm condition. It HAS to reset to 1 after reaching negative zero and the T6RUPT processing occurs. I'll open an issue, see what comes of that.


Title: Re: LM status...
Post by: indy91 on August 29, 2016, 04:42:46 PM
Good thing that we are in the position to test this stuff so easily. Same thing with the other DAP issue (https://github.com/rburkey2005/virtualagc/issues/30). Someone found the problem (very low level issue with an instruction), I punched the changes in our agc_engine.c, did a quick Verb 49 aaaand fix is verified as working.  :ROTFL3453: So I guess once the problem is found, the 1103s will be gone immediately. And in the case of TIME6 we also don't have to worry about any ramifications for the CSM, TIME6 is not used there iirc.


Title: Re: LM status...
Post by: eddievhfan1984 on August 29, 2016, 05:21:20 PM
Actually, the CSM does use TIME6, but not in the same way the LM does. There's no CCS hole triggering it, and if it did happen during an AVERAGE G routine, the P00DOO would become a BAILOUT. The LM doesn't have that function.

EDIT: My issue got a response. Apparently, I was mistaken in some cases (it *does* use DINC), but I was on the trail of the problem: the adder logic in the AGC causes 1+(-1)=-0, whereas in the current vAGC, the same addition results in +0, triggering the CCSHOLE routine and the abort. That would explain the regular writing of 00000 to TIME6 when it should've been 77777. The respondent said they'd look into it a make the changes within a few days.


Title: Re: LM status...
Post by: indy91 on August 31, 2016, 09:54:13 AM
Little video I made showing the working P12: https://www.youtube.com/watch?v=bT7JGyOae6U

Still getting 401 alarms close to 90° and 270° pitch. Strange.


Title: Re: LM status...
Post by: dseagrav on August 31, 2016, 12:35:44 PM
For your attitude hunting I'd suspect incorrect CG before RCS issues. I burned a bunch of time on the RCS and I think it's as it should be.


Title: Re: LM status...
Post by: indy91 on August 31, 2016, 12:52:22 PM
I had a look at the RCS implementation. As did the comments in the RCS code, I wondered whether 60 fps is high enough to resolve the thrust pattern sufficiently. The only actual problem with the code is that it didn't seem to have the delay between thruster off signal and the thrust ramping down, but that is a minor detail that doesn't have much influence on the behavior. Didn't think about CoG issues for the ascent stage, but that's probably the problem then. That would indeed explain the behavior, because in general the DAP knows the jet acceleration fairly well. The principal moments of inertia are even a little bit high for the ascent stage. CoG is also a problem with LGC controlled docked DPS burns. The thrust force attack point is currently fixed 3.3 meters from the CoG of the unstaged LM and in reality this distance was only 3 to 7 feet, depending on weight. So it almost spins out of control during docked burns because of excessive moments caused by the gimballing. For both ascent and descent stage this behavior won't become much better until the variable CoG, you have been talking about a while ago, has been implemented.


Title: Re: LM status...
Post by: dseagrav on August 31, 2016, 01:26:26 PM
I have an idea of how to go about doing it that doesn't suck, I'm just not sure what physical parameters to use. When I get a chance I'll set things up but someone is going to have to fill in the blanks. Does it need to update just CG or PMI as well?


Title: Re: LM status...
Post by: indy91 on August 31, 2016, 02:03:06 PM
PMI would be good, too. Empty and full tanks are a decent difference for both CSM and LM. A while back I changed the CSM to have the PMI with about half full tanks. I did some preliminary analysis here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2863.msg23194#msg23194 and here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.525. There is a mass properties document for all configurations so I could certainly fill your variable CoG function with these parameters for CoG and PMI. The GSOP about the DAP also has some nice diagrams with the parameters (weight dependant jet accelerations and moment arm for the SPS/DPS gimbals) it assumes for conrolling the spacecraft. For the CoG we of course need an absolute reference point. The coordinate system for both CSM and LM have this point somewhere below the spacecraft and all CoG data is relative to the origin of this coordinate system.


Title: Re: LM status...
Post by: eddievhfan1984 on September 01, 2016, 04:43:35 AM
https://github.com/rburkey2005/virtualagc/pull/47 (https://github.com/rburkey2005/virtualagc/pull/47)

They're implemented the change we requested in vAGC. However, I also see that dseagrav made a crapton of mods to our current vAGC files to make them compatible with Orbiter. As a result, I would rather he (or something more familiar with his modifications) incorporate the update, rather than me trying it pseudo-blindly.


Title: Re: LM status...
Post by: indy91 on September 01, 2016, 04:49:24 AM
https://github.com/rburkey2005/virtualagc/pull/47 (https://github.com/rburkey2005/virtualagc/pull/47)

They're implemented the change we requested in vAGC. However, I also see that dseagrav made a crapton of mods to our current vAGC files to make them compatible with Orbiter. As a result, I would rather he (or something more familiar with his modifications) incorporate the update, rather than me trying it pseudo-blindly.

I've manually implemented these changes and the 1103 alarms are gone. I think I got it right, but there is some new strange behavior though. The LGC warning light is going on and off during the descent, even without any program alarm. Did that ever happen before? Eddie, can you check that before I commit the agc engine changes?

There are really only two ways the LGC would send such a signal: an LGC malfunction signal or an oscillator problem. The second one could only happen if the LGC has no sufficient power, but that really shouldn't be the case. The LGC malfunction signal is on for: restart, counter fail, voltage fail and scaler double alarm. At the same time when the 1103 alarm happened before, now a 1210 alarms occurs and the DSKY blanks sometimes. I even got a 1201 alarm once. But the LGC does progress further than 4 minutes now without P00DOO. One problem is that the Sea of Tranquility is very low, so the current landing site vector is 3 kilometers below the surface of our round Orbiter moon. I have a scenario with the new vector attached to this post and I will fix it in the launch scenario, too. Unfortunately we don't have the good kind of program alarms that still does proper guidance. The LGC does progress to P64 (yay!), but it still sends you crashing into the moon. It also never commands a throttle down (auto throttle is not implemented yet, but I put the thrust register of the LGC in the debug string) so that would be the point when the astroanuts would abort. I also think that the DPS thrust is not high enough. It should be 10,500 lbf (=46706N) maximum rated thrust and during the descent only 92.5% of that is used. So lots of little problems, but at least the 1103 alarms and the P00DOOs are gone, too, I think.


Title: Re: LM status...
Post by: eddievhfan1984 on September 01, 2016, 04:55:36 AM
Do you have a branch I can pull?


Title: Re: LM status...
Post by: indy91 on September 01, 2016, 05:03:03 AM
I only changed that one file, so an extra branch is too much effort.  :ROTFL3453: Here is the file, it didn't like the .c extension, so it's a zip.


Title: Re: LM status...
Post by: eddievhfan1984 on September 01, 2016, 05:41:02 AM
Yeah, I get the 1210s, but I also get 520—RADARUPT sooner than expected. The LR shouldn't even be generating data, so IDK why it's throwing that. I couldn't progress too far because the LM refused to point correctly after P64, probably because the RADARUPTs bogged it down...


Title: Re: LM status...
Post by: indy91 on September 01, 2016, 06:46:15 AM
I guess some work on the LR would be the next step for the now working late P63. I really don't know what is causing these 1210s though. I increased the maximum thrust of the DPS and it still doesn't command a throttle down until one minute too late. Maybe the thrust is still not high enough or the ignition routine computes ignition for too late. Or maybe our LM is too heavy at ignition. But despite the new program alarms it seems to control the spaceacraft all throughout the descent and there is no problem with the abort programs or random 1103 alarms. Shortly after P64 begins it crashed into the surface for me. There seems to be an inconsistency between P63 and P64, when P64 starts it commands full thrust again because it is about to crash. But P63 doesn't seem to be bothered by the trajectory. Could be the late throttle down that's screwing up the trajectory, or maybe there is something wrong with the braking phase targets (position, velocity, acceleration, downrange jerk). The targets in the Apollo 13 LM Padload document are quite different for P63...


Title: Re: LM status...
Post by: indy91 on September 01, 2016, 09:56:23 AM
I have confirmed that the 1210 alarms happened before the AGC engine change, so I don't really see any new issues caused by it. I have commited that fix and also increased the DPS thrust to 10,500 lbf. That way the 92.5% thrust used during the powered descent is more realistic. Actually, it seem the 1210 alarms are happening earlier this way, weird. Eddie, maybe have a look at the alarm data and find us the next AGC issue?  :ROTFL3453:


Title: Re: LM status...
Post by: eddievhfan1984 on September 01, 2016, 06:55:28 PM
Did another test: I got a 511 as well (LR in pos. 2 or transferring), and got a shot of the debug data from the 05 08 display: fixed bank 33o, address 02537o, erasable bank 7. It shows it might have something to do with the RR designation routine R29, but I can't find instruction 2537 in the assembly listings so far...


Title: Re: LM status...
Post by: indy91 on September 02, 2016, 05:55:25 AM
I finally tried to implement the auto throttle commands from the LGC, but with not much success. I tried to learn from other cases where the numbers from a register are used to drive something, like auto optics and the LM radars. These are the things I know:

-The THRUST register has the address 055 in the erasable memory
-The maximum value seems to be (in octal) 10000, the minimum value 67777
-According to the GSOP section 2 the scaling is lbs/(2.817*2^14)
-During the descent every 2 seconds a new command is generated

But my problems are with the bitwise operation that seems to be used to convert the register value to a negative or positive integer. I think I know how the scaling works, but I have not been able to convert a 67777 or any negative number to a thrust change command. So if anyone could help we with everything between:

Code:
val = lem->agc.GetErasable(0, 055);

and

Code:
lgcAutoThrust += thrustchange;

that would be great. Also, I wonder how the timing works. Should the register be read every timestep or should the thrust command be applied during the 2 second period? The commands for the optics and RR and LR seems to somehow hacked into the AGC engine, so they are not calculated with "simdt" and every timestep...


Title: Re: LM status...
Post by: eddievhfan1984 on September 03, 2016, 01:03:02 AM
Kind of along similar lines—I tried doing a V16 N92 display during PDI (same as the nominal PDI display with the auto throttle setting in R1), but the computer keeps claiming OPR ERR, like I typed in a nonexistent noun. Do you have a line on that, indy?


Title: Re: LM status...
Post by: indy91 on September 03, 2016, 05:30:55 AM
It is a nonexistent noun, at least in Luminary099. So they didn't have this manual throttling capability on Apollo 11. They had a completely manual landing program P67 though which was deleted for later flights. P66 had then some manual modes instead. Luminary131, our other LGC version, does have the noun 92.


Title: Re: LM status...
Post by: eddievhfan1984 on September 03, 2016, 04:40:50 PM
Ohh, that makes sense. *derp*


Title: Re: LM status...
Post by: indy91 on September 05, 2016, 11:45:38 AM
At least the 520 alarms shouldn't be occuring anymore now. The 1103 fix did cause that nonsensical values  (usually a lot of 1s) were written to output channel 13 and therefore it tried to get range data from the landing radar long before it should do that. Now all I get is the 1210 alarms.


Title: Re: LM status...
Post by: thewonderidiot on September 05, 2016, 11:48:17 AM
I finally tried to implement the auto throttle commands from the LGC, but with not much success. I tried to learn from other cases where the numbers from a register are used to drive something, like auto optics and the LM radars. These are the things I know:

-The THRUST register has the address 055 in the erasable memory
-The maximum value seems to be (in octal) 10000, the minimum value 67777
-According to the GSOP section 2 the scaling is lbs/(2.817*2^14)
-During the descent every 2 seconds a new command is generated

But my problems are with the bitwise operation that seems to be used to convert the register value to a negative or positive integer. I think I know how the scaling works, but I have not been able to convert a 67777 or any negative number to a thrust change command. So if anyone could help we with everything between:

Code:
val = lem->agc.GetErasable(0, 055);

and

Code:
lgcAutoThrust += thrustchange;

that would be great. Also, I wonder how the timing works. Should the register be read every timestep or should the thrust command be applied during the 2 second period? The commands for the optics and RR and LR seems to somehow hacked into the AGC engine, so they are not calculated with "simdt" and every timestep...

If you're still working on this, THRUST is also handled with DINC. It's counted out to the DECA at 3.2kHz whenever bit 4 of channel 14 is set. That bit is automatically cleared when a ZOUT is generated by the DINC. On top of that, according to Don Eyles (http://www.doneyles.com/LM/Tales.html), there's a 0.075s response lag in the DECA for throttle changes to take effect.

I'm not sure what the strategy is for dealing with throttle commands that are outside the -6400..6400 range, since the counter won't have had time to count them out by the next 2s writing of THRUST. It doesn't look like THROTTLE_CONTROL_ROUTINES reads THRUST back in or makes internal use of PSEUDO55. Are you sure the min and max are that large?


Title: Re: LM status...
Post by: indy91 on September 05, 2016, 12:15:24 PM
I'm not sure what the strategy is for dealing with throttle commands that are outside the -6400..6400 range, since the counter won't have had time to count them out by the next 2s writing of THRUST. It doesn't look like THROTTLE_CONTROL_ROUTINES reads THRUST back in or makes internal use of PSEUDO55. Are you sure the min and max are that large?

THRUST (EMEM0055) is 67777 at all times when no thrusting is commanded and 26 seconds into PDI, until throttle up. Then it is 10000 until throttle down later in P63. Very rarely it seems to have some value above 10000, 16023 or something like that. But if full thrust is commanded then it is 10000.

EDIT: Here the alarm data for the 1210 alarms:

V05 N08

R1: 3722
R2: 70000

The instruction (R2) is SQUARE and the address seems to indicate that the alarm is triggered in the general stalling routine. Maybe it doesn't have an allowable state and then MODABORT is called which is causing the 1210. No idea what kind of "stall" is happening though.


Title: Re: LM status...
Post by: thewonderidiot on September 05, 2016, 02:45:19 PM
THRUST (EMEM0055) is 67777 at all times when no thrusting is commanded and 26 seconds into PDI, until throttle up. Then it is 10000 until throttle down later in P63. Very rarely it seems to have some value above 10000, 16023 or something like that. But if full thrust is commanded then it is 10000.

Ah, the +-10000 is probably just to peg it open or closed. I think pulses beyond the limits are just discarded. It looks like the lbf/count from THRUST is something like 2.7 (which I pulled from this document (https://www.hq.nasa.gov/alsj/LM08_Guidance-Navigation-Control_ppGN1-48.pdf)) or 2.868 which is what I get calculating it myself from this GSOP section 6 (http://www.ibiblio.org/apollo/NARA-SW/R-567-sec6.pdf).
(0.224809 lbf/N) * (3645 N/V) * (0.0035 V/bit) = 2.868... so I'm not sure what I'm missing for this to not match the 2.7.

Anwyays, that means that it only takes a bit more than a second to fully open or fully close the throttle from any state, so the 2 second window isn't an issue. I'm not sure where the lbs/(2.817*2^14) comes into this, although the 2.817 ignoring the 2^14 isn't far off from these numbers.

EDIT: Here the alarm data for the 1210 alarms:

V05 N08

R1: 3722
R2: 70000

The instruction (R2) is SQUARE and the address seems to indicate that the alarm is triggered in the general stalling routine. Maybe it doesn't have an allowable state and then MODABORT is called which is causing the 1210. No idea what kind of "stall" is happening though.
Interesting, I wonder if there's a way to interrogate which device stalled.

e: Looks like 2.817 is also used by the software. SCALEFAC, defined in CONTROLLED_CONSTANTS.agc, is +7.97959872 E-2 "BITPERF" (bit/N), which is roughly 2.817lbf/bit. So it looks like for the throttle control, you can just take the value out of EMEM055 when it's written (it doesn't look like VirtualAGC currently properly handles it as a counter), convert it to a signed integer, multiply it that by 2.817, and add that to the throttle position, clamping to the fully closed and fully open positions if the result goes past them. Would it be useful to add DINCing to this counter in yaAGC? How are other output counters like this currently handled in NASSP?


Title: Re: LM status...
Post by: kneecaps on September 05, 2016, 03:58:52 PM

Ah, the +-10000 is probably just to peg it open or closed. I think pulses beyond the limits are just discarded. It looks like the lbf/count from THRUST is something like 2.7 (which I pulled from this document (https://www.hq.nasa.gov/alsj/LM08_Guidance-Navigation-Control_ppGN1-48.pdf)) or 2.868 which is what I get calculating it myself from this GSOP section 6 (http://www.ibiblio.org/apollo/NARA-SW/R-567-sec6.pdf).
(0.224809 lbf/N) * (3645 N/V) * (0.0035 V/bit) = 2.868... so I'm not sure what I'm missing for this to not match the 2.7.


The first document appears to be a general spec document, the characteristics of each DPS engine were determined prior to flight and the numbers provided specifically for each flight. So in summary, don't expect your accurate value to match the generic one from the doc.


Title: Re: LM status...
Post by: thewonderidiot on September 05, 2016, 04:05:27 PM
The first document appears to be a general spec document, the characteristics of each DPS engine were determined prior to flight and the numbers provided specifically for each flight. So in summary, don't expect your accurate value to match the generic one from the doc.

Fair enough, although our two examples of Luminary both use the same scale factor constant for bit/N.  :)


Title: Re: LM status...
Post by: kneecaps on September 05, 2016, 06:03:28 PM
The first document appears to be a general spec document, the characteristics of each DPS engine were determined prior to flight and the numbers provided specifically for each flight. So in summary, don't expect your accurate value to match the generic one from the doc.

Fair enough, although our two examples of Luminary both use the same scale factor constant for bit/N.  :)

That is interesting.....I will dive a bit more into this part of the code. Luminary specifics I'm sadly a little weak on.


Title: Re: LM status...
Post by: eddievhfan1984 on September 05, 2016, 08:07:24 PM
I'm not sure what the strategy is for dealing with throttle commands that are outside the -6400..6400 range, since the counter won't have had time to count them out by the next 2s writing of THRUST. It doesn't look like THROTTLE_CONTROL_ROUTINES reads THRUST back in or makes internal use of PSEUDO55. Are you sure the min and max are that large?

THRUST (EMEM0055) is 67777 at all times when no thrusting is commanded and 26 seconds into PDI, until throttle up. Then it is 10000 until throttle down later in P63. Very rarely it seems to have some value above 10000, 16023 or something like that. But if full thrust is commanded then it is 10000.

EDIT: Here the alarm data for the 1210 alarms:

V05 N08

R1: 3722
R2: 70000

The instruction (R2) is SQUARE and the address seems to indicate that the alarm is triggered in the general stalling routine. Maybe it doesn't have an allowable state and then MODABORT is called which is causing the 1210. No idea what kind of "stall" is happening though.

Actually kinda read that wrong—R1 is the address, and R2 is the contents of the memory bank registers. Bits 1-3 indicate the erasable bank selected (dependent on routine), bits 4-10 are normally zero (bit 7 is one when super-bank 1 is used), and 11-15 is the fixed bank. This puts the instruction at address 3722 in fixed bank 34.

Code:
038811,001525:                                                                                                  #  LRHJOB IS SET BY LRHTASK WHEN LEM IS BELOW 25000 FT.  THIS JOB
038812,001526:                                                                                                  #  INITIALIZES THE LR READ ROUTINE FOR AN ALT MEASUREMENT AND GOES TO
038813,001527:                                                                                                  #  SLEEP WHILE THE SAMPLING IS DONE -- ABOUT 95 MS.  WITH A GOODEND RETURN
038814,001528:                                                                                                  #  THE ALT DATA IS STORED IN HMEAS AND BIT7 OF LRSTAT IS SET.
038815,001529:
038816,001530: 34,3716                                           BANK     34                                    
038817,001531: 34,2000                                           SETLOC   R12STUFF                              
038818,001532: 34,2000                                           BANK                                          
038819,001533:
038820,001534: 34,3716                                           COUNT*   $$/SERV                              
038821,001535:
038822,001536: 34,3716           04616        LRHJOB             TC       BANKCALL                              #  INITIATE LR ALT MEASUREMENT
038823,001537: 34,3717           53073                           CADR     LRALT                                
038824,001538: 34,3720           04616                           TC       BANKCALL                              #  LRHJOB TO SLEEP ABOUT 95MS
038825,001539: 34,3721           17714                           CADR     RADSTALL                              
038826,001540: 34,3722           13745                           TCF      HBAD                                  
038827,001541: 34,3723           11674                           CCS      STILBADH                              #  IS DATA GOOD JUST PRESENT?
038828,001542: 34,3724           13755                           TCF      HSTILBAD                              #  JUST GOOD -- MUST WAIT 4 SECONDS.

And here's the subroutine HBAD called from that address:

Code:
038851,001565: 34,3745           30101        HBAD               CA       FLAGWRD5                              
038852,001566: 34,3746           74742                           MASK     RNGSCBIT                              #  IS BAD RETURN DUE TO SCALE CHANGE?
038853,001567: 34,3747           00006                           EXTEND                                        
038854,001568: 34,3750           13754                           BZF      HSTILBAD   -1                         #  NO  RESET HSTILBAD
038855,001569: 34,3751           05516                           TC       DOWNFLAG                              #  YES  RESET SCALE CHANGE BIT AND IGNORE
038856,001570: 34,3752           00120                           ADRES    RNGSCFLG                              
038857,001571: 34,3753           05155                           TC       ENDOFJOB                              

This still pinpoints the 1210 alarms as being caused by a collision between the landing guidance program at-large and the landing radar polling routines. It also would explain the screwy behavior I've been getting with my landing attempts—around 25,000 feet, I get a ton of DSKY blanks and 1210s faster than once per second, and it seems like DAP control gets really slow and sloppy, which might also explain why the guidance doesn't converge properly to generate a sensible LPD angle in P64 (mine is pegged at 80 degrees, 0 seconds LPD time available).


Title: Re: LM status...
Post by: thewonderidiot on September 05, 2016, 09:06:24 PM
So, I took a closer look at timer timing. VirtualAGC currently increments TIME1, TIME3, and TIME5 all at the same time, however my hardware sim has TIME5 offset by 5ms. Think that might have something to do with it?
(TIME3 and TIME4 are supposed to be phased by 5ms too, but I'm only showing a 2.5ms offset right now. Must have something wired incorrectly somewhere, since the documentation suggests this should be 5ms too. It shouldn't impact what I see for the TIME3/TIME5 offset).


e: Does anybody know of any original source other than E-2052 that specifies phase offsets between the various timers? I'm starting to convince myself, looking at the schematics, that T4 should be offset from T3 by 7.5ms instead of 5ms...

e2: E-2065 lays out a RUPTCHK routine in the self-test code:

"The only non - programmable instruction that  is  checked  is  PINC, which  is
checked in the RUPTCHK subroutine. The fact that TIME3 interrupts  2  1/2  mil -
liseconds after TIME4 assures the proper functioning of all the pulses in this  in -
struction."

So that means E-2052, VirtualAGC, and "The Apollo Guidance Computer: Architecture and Operation" are all wrong about the relative phasing of TIME3 and TIME4 -- lovely! That makes two timers that are being incremented with the wrong relative phasing -- TIME4 and TIME5. Possibly the cause of contention issues?


Title: Re: LM status...
Post by: eddievhfan1984 on September 06, 2016, 01:34:54 AM
Do either of those timers have direct control over LR and/or RR pulses?

And a formal welcome to the project, thewonderidiot. Thanks for helping out with the DINC and the 1103 issues.


Title: Re: LM status...
Post by: indy91 on September 06, 2016, 04:22:44 AM
So it looks like for the throttle control, you can just take the value out of EMEM055 when it's written (it doesn't look like VirtualAGC currently properly handles it as a counter), convert it to a signed integer, multiply it that by 2.817, and add that to the throttle position, clamping to the fully closed and fully open positions if the result goes past them. Would it be useful to add DINCing to this counter in yaAGC? How are other output counters like this currently handled in NASSP?

Other output counters are handled with fictitious output channels, but I think that's how it is done in yaAGC, too. The SPS gimbal control/auto optics and the FDAI error needles are done that way. Maybe the THRUST counter could also be implemented like that?

Actually kinda read that wrong

Ah, thanks, I guess I didn't know how to read the alarm data after all.

Quote
This still pinpoints the 1210 alarms as being caused by a collision between the landing guidance program at-large and the landing radar polling routines. It also would explain the screwy behavior I've been getting with my landing attempts—around 25,000 feet, I get a ton of DSKY blanks and 1210s faster than once per second, and it seems like DAP control gets really slow and sloppy, which might also explain why the guidance doesn't converge properly to generate a sensible LPD angle in P64 (mine is pegged at 80 degrees, 0 seconds LPD time available).

Same behavior here and I think Average G is also handicapped by the 1210 alarms. Before the LM crashes on the moon the displayed altitude is much lower than the actual altitude. Even without a working landing radar, the alignment and state vector at ignition shouldn't be so bad that it is a few thousand feet off in altitude.

EDIT: I don't know what it is, but I'm having major problems converting the thrust command 067777 to something useful. 067777 should be the negative equivalent of 010000, right? 010000 is 4096 in decimal, so 67777 should be -4096. But I have no idea how to get from 067777 to -4096 to then convert these pulses to a thrust change command. I am so much more useful for any GNC and orbital mechanics problems...

EDIT2: Well, right as I wrote this I have solved it. The bitwise operation is to ensure the inversion happens with the single precision 15-bit values and not a full integer. Anyway, expect a LGC auto throttle update soon, maybe.


Title: Re: LM status...
Post by: indy91 on September 06, 2016, 07:08:31 AM
Actually, there is something quite wrong with the P63 test scenario. I didn't perform a LGC clock update, so the clock is a few seconds(!) off. You can easily fix that with the clock update of the PAMFD. It works so much better! Sorry about that. I think this fixes most issues I had with trying P40 maneuvers. They were always off a bit.

The clock update doesn't change anything about the 1210 alarms, but the guidance is much better. Throttle down is still a minute late (probably our DPS is still weaker than the Apollo 11 DPS) but P64 is now starting at a much more reasonable position and the LGC almost goes into P65 auto landing, but the altitude is maybe a 100-200 meters off and so the LM crashes into the surface in late P64. So landing in P67 should work now. P66 needs the descent rate switch, which I can implement as keyboard and/or joystick commands. Of course the velocity rate will be off without the landing radar, maybe it's not so bad though. Note that for P64 you need a joystick currently, the LPD commands don't work with the numpad yet. I'll try my first reasonable P64 now.

EDIT: I have commited my LGC auto thrust attempt. It's implemented basically like the SPS gimbal and auto optics commands. I hope that is right. For the scaling I have chosen 2.817/10500. 10500 lbs is the nominal thrust of the DPS and the thrust settings is scaled form 0 to 1. It works very well, every 2 seconds a new command is generated and the initial throttle down in P63 seems to hit its target thrust pretty well. Attached are two scenarios. Both have updated clock and state vectors, so that should work better now. The second scenario has the actual Apollo 11 landing site as a target instead of the targeted LS. That should guid you right to the Tranquility Base mesh that comes with NASSP.

I have tried the descent two more times, P64 seems to start with more reasonable numbers now. 99+ seconds in P64 and usually 60° LPD. I'm not sure the LPD is doing anything yet, the commands I am giving with the joystick don't seem to do all that much. Not sure though. Also, when I set the PGNS mode control switch to ATT HOLD, then P66 isn't starting. That's all I should have to do, right? Maybe related to the program alarms. If I switch to manual throttle then P67 is starting just fine though.

EDIT: Switching from P64->P67->P66 works. Now I have to implement the ROD switch I guess...


Title: Re: LM status...
Post by: eddievhfan1984 on September 06, 2016, 04:35:21 PM
Yeah, those issues might also tie in with the lack of X-axis override during P63. It might also be because I use keypad steering (I have a joystick, but it has no yaw axis, and that causes a TON of problems), and the code may just be reading nothing but hardover, and the AUTO/ATT HOLD logic only changes references when using PROP RATE rotation commands...


Title: Re: LM status...
Post by: thewonderidiot on September 06, 2016, 08:43:16 PM
Do either of those timers have direct control over LR and/or RR pulses?

And a formal welcome to the project, thewonderidiot. Thanks for helping out with the DINC and the 1103 issues.

Thanks!  :)

I'm not sure, honestly... it does look like TIME4 at least checks some things about the RR. I'm going to go ahead and make the changes to VirtualAGC anyways, since the incorrect TIME3/TIME4 phasing will make us fail the RUPTCHK test when we get the chance to run the real self-test code. It's probably worth pulling those changes over into NASSP just to see what happens as a result, since the relative timings of a lot of things will change.

e: Pull request for the timer phasing is open: https://github.com/rburkey2005/virtualagc/pull/49
I still lack the means to test this stuff myself -- my next task is to get Orbiter installed and a clone of NASSP going.  :D


Title: Re: LM status...
Post by: indy91 on September 07, 2016, 04:41:47 AM
Yeah, those issues might also tie in with the lack of X-axis override during P63. It might also be because I use keypad steering (I have a joystick, but it has no yaw axis, and that causes a TON of problems), and the code may just be reading nothing but hardover, and the AUTO/ATT HOLD logic only changes references when using PROP RATE rotation commands...

Only with a connected joystick the relevant bits in the input channel are currently set. X-axis override works fine with a joystick, with the numdpad all you are doing is use the default Orbiter thruster groups. That's why during the RCS test of the LM activation nothing happens in the channels when you pitch up/down etc. I think I can implement it like the RHC and THC, where the numpad keys are equivalent to full deflection. But it's fairly complicated and if I work on that I might as well add switches and power to the ACA/TTCA logic, so this might take a while.

I'm not sure, honestly... it does look like TIME4 at least checks some things about the RR. I'm going to go ahead and make the changes to VirtualAGC anyways, since the incorrect TIME3/TIME4 phasing will make us fail the RUPTCHK test when we get the chance to run the real self-test code. It's probably worth pulling those changes over into NASSP just to see what happens as a result, since the relative timings of a lot of things will change.

Over at github I wrote:

"Doesn't seem to break anything, doesn't seem to fix anything. Still the 1210 alarm when the LGC is first looking for landing radar data (I guess) and the DSKY blanks about once per guidance cycle. Late in P63 the frequency of the DSKY blanks increases. Then in early P64 it first doesn't have new program alarms (probably while the LGC waits for the LR to move to position 2) and then enough program alarms and DSKY blanks that you barely get to see the registers. This happens in all landing programs, P64-P67."

One thing I wonder though, why does the velocity light never light up on the DSKY? Shouldn't it light up at the same time as the altitude light? The LR does not accidentaly send a "velocity good" signal, so much I know...

I still lack the means to test this stuff myself -- my next task is to get Orbiter installed and a clone of NASSP going.  :D

It's best if you follow these instructions: http://nassp.sourceforge.net/wiki/Installation I strongly recommend the D3D9 Client. And instead of the linked modules pack or git snapshot just build it yourself with Visual Studio 2015 or use the latest Beta Master release: https://github.com/dseagrav/NASSP/releases


Title: Re: LM status...
Post by: lotisully86 on September 07, 2016, 06:51:37 AM

Over at github I wrote:

"Doesn't seem to break anything, doesn't seem to fix anything. Still the 1210 alarm when the LGC is first looking for landing radar data (I guess) and the DSKY blanks about once per guidance cycle. Late in P63 the frequency of the DSKY blanks increases. Then in early P64 it first doesn't have new program alarms (probably while the LGC waits for the LR to move to position 2) and then enough program alarms and DSKY blanks that you barely get to see the registers. This happens in all landing programs, P64-P67."

One thing I wonder though, why does the velocity light never light up on the DSKY? Shouldn't it light up at the same time as the altitude light? The LR does not accidentaly send a "velocity good" signal, so much I know...
[/quote]

Aside from the LR cbs and LR ant switch, what other components of the landing radar are actually working? Moving the LR ant switch to position 2 stops the extra frequent DSKY blanks. I've found you can run P63 with the switch in either auto or 1 position, the very frequent blanks will occur at the same time, and manually switching to 2 slows the blanks back down.


Title: Re: LM status...
Post by: indy91 on September 07, 2016, 07:13:22 AM
Actually, I get no program alarms in P64-P67 at all with the LR switch in the 2 position! So it might be that the problem is almost exclusively our landing radar. I was pretty sure that it was mostly complete except for actually generating useful range and velocity information. But it seems like that is not the case...


Title: Re: LM status...
Post by: eddievhfan1984 on September 07, 2016, 08:11:14 AM
I guess it just means that it's not properly coded to change radar positions when the right I/O channel bit is set, but that should be an easy fix...


Title: Re: LM status...
Post by: indy91 on September 07, 2016, 09:04:43 AM
Weird, the second time I have manually controlled the LR position the program alarms are happening again. So maybe it just was a fluke that they didn't happen once. I haven't actually checked if the LR is automatically moved to position 2, so I'll try that next time.

But guidance is overall working pretty good, if I manually take over and land P68 has coordinates pretty close to the targeted point. Altitude is only off by about 0.05 NM (~100 m) which I would say is a reasonable error. A little bit of landing radar action will fix that.


Title: Re: LM status...
Post by: dseagrav on September 07, 2016, 12:42:44 PM
I guess it just means that it's not properly coded to change radar positions when the right I/O channel bit is set, but that should be an easy fix...

I don't remember if I did that or not.


Title: Re: LM status...
Post by: indy91 on September 07, 2016, 01:01:17 PM
I've just tried it, the LR is automatically moved to position 2 when P64 starts.

The increased DSKY blanking starts when first velocity data is requested, the ruptSent variable is 1 then and a RADARUPT is generated. Should that already be happening without the LRDataGood and LRVelocityDataGood bits set? The range data, which is 0 or for some reason 24 sometimes, is then already set into the RegRNRAD register. But without being told to incorporate it, the LGC shouldn't have too much problem with that...


Title: Re: LM status...
Post by: eddievhfan1984 on September 07, 2016, 02:53:54 PM
Well, the I/O channel that the LR data good bits use is inverted sensing—a 0 would indicate data good instead of data bad. Is that taken into account in the code?


Title: Re: LM status...
Post by: thewonderidiot on September 07, 2016, 10:12:47 PM
Another thing to try -- it looks like the hardware resets bit 4 of channel 13 (the radar activity bit) as soon as RADARUPT is triggered. The GenerateRADARUPT (https://github.com/dseagrav/NASSP/blob/master/Orbitersdk/samples/ProjectApollo/src_sys/yaAGC/agc_engine.c#L460) function isn't currently doing that. It looks like Luminary might be reading that back in, although I can't see where things would go wrong if it unexpectedly stays set.


Title: Re: LM status...
Post by: indy91 on September 08, 2016, 05:17:33 AM
Another thing to try -- it looks like the hardware resets bit 4 of channel 13 (the radar activity bit) as soon as RADARUPT is triggered. The GenerateRADARUPT (https://github.com/dseagrav/NASSP/blob/master/Orbitersdk/samples/ProjectApollo/src_sys/yaAGC/agc_engine.c#L460) function isn't currently doing that. It looks like Luminary might be reading that back in, although I can't see where things would go wrong if it unexpectedly stays set.

We have a winner! I noticed this before, but I wasn't sure if the radar activity bit is reset by the hardware.

But this did the trick. The LR probably generated nonstop RADARUPTs when it read range data, which caused the problems, and even more when it read velocity data. During my first attempt I had no 1210 alarms until late in P63, when the LGC was starting to read velocity data and then all throughout P64. Should the bit be reset before the RADARUPT maybe? Something is going on with velocity data, shouldn't the velocity light on the DSKY be on at some point?

I guess the rendezvous radar also needs to reset the bit. I'll try a few things and keep you updated.

EDIT: I'm not having luck with the "fast" 1210 alarms. What you can actually do to trick the computer is set the the LR to the exact opposite position it wants. So to 2 in late P63 and to 1 in P64. That way the LGC never wants to process data and you can use the DSKY. Just the program alarm indicating the incorrect LR setting. When I pull the LR circuit breaker the alarms are still happening, even in early P63. If the LR has no power, how can it reset the RadarActivity bit? But there shouldn't be any RADARUPTs happening without LR power. Maybe it's the RR's fault somehow...

I have a scenario here with a biased landing site vector. It's 170 meters above the surface, which is the approximate error from alignment inaccuracies etc. in the P63 scenario. With that bias it has a pretty good idea where the surface is, even without LR data. So you can actually try complete automatic landings with program 65! It's working pretty well, there is surface relative speed of only 4m/s and a +/-30 meters altitude uncertainty at touchdown. But that's good enough to not crash. When landed, set the ACA out of detent (without joystick the PGNS mode control switch to off) or else there is a lot of thruster firings. Do an engine stop ("-" button on the numpad) at contact and the Virtual AGC has completed a sucessful landing on the moon!


Title: Re: LM status...
Post by: thewonderidiot on September 08, 2016, 10:30:43 AM
Awesome! Yeah the bit is reset when the request for a RADARUPT is generated by any source, before the computer actually services it.

Also, starting to understand the radar interface circuitry more, it looks like RADARUPTs are generated internally after a sequence of a bunch of pulses is sent to the target radar, rather than on any action from the radars themselves. So they definitely shouldn't be happening if the AGC isn't actively trying to use the radars. But it might still expect the interrupt even if the radars are off. I'll have to see if I can get the rupt to fire in my hardware sim -- I had been thinking I'd need to spoof a radar interface for that to happen but now I'm not so sure.

Of course, take that with a grain of salt until I actually get it to work.  :wink:


Title: Re: LM status...
Post by: thewonderidiot on September 08, 2016, 11:33:57 AM
Yeah, RADARUPT happens without anything attached to the radar input or output pins whatsoever.
(http://i.imgur.com/eyANWRJ.png)

It's slower than I expected too -- it takes a whole 10 milliseconds for it to start counting (the first ADVCNT pulse), and the rupt itself doesn't happen until nearly 110ms after I wrote to CH13 bit 4 (which is ACTV/ in the trace). The timing could of course be off if I have a wiring error somewhere, but yeah -- pulling breakers on the radars shouldn't interrupt the flow of RADARUPTs, just the validity of their data.


Title: Re: LM status...
Post by: indy91 on September 08, 2016, 11:59:41 AM
Awesome! Yeah the bit is reset when the request for a RADARUPT is generated by any source, before the computer actually services it.

Playing around with this doesn't change anything, the "fast" 1210 alarms are still happening.

Quote
Also, starting to understand the radar interface circuitry more, it looks like RADARUPTs are generated internally after a sequence of a bunch of pulses is sent to the target radar, rather than on any action from the radars themselves. So they definitely shouldn't be happening if the AGC isn't actively trying to use the radars. But it might still expect the interrupt even if the radars are off.

The RadarActivity bit is already set and LR data is read before the LR indicates that the data is good. So the AGC is actively trying to use the radar before the LR say anything else than "The LR is in position 1, so I am working".

So if I understand this correctly, the RADARUPT stuff should rather be in agc_engine.c than in the LR code? The bit reset, too?

Yeah, RADARUPT happens without anything attached to the radar input or output pins whatsoever.

It's slower than I expected too -- it takes a whole 10 milliseconds for it to start counting (the first ADVCNT pulse), and the rupt itself doesn't happen until nearly 110ms after I wrote to CH13 bit 4 (which is ACTV/ in the trace). The timing could of course be off if I have a wiring error somewhere, but yeah -- pulling breakers on the radars shouldn't interrupt the flow of RADARUPTs, just the validity of their data.

I don't think RADARUPT is happening in our AGC without the LR or RR actively requesting it. So pulling the LR circuit breaker will stop the LM simulation from reaching the part of the code where RADARUPT is requested and the RadarActivity bit is reset. How do you think it should be handled and what could still be causing the 1210 alarms late in P63 and in P64?


Title: Re: LM status...
Post by: thewonderidiot on September 08, 2016, 12:45:00 PM
Yeah, the bit reset should definitely be in agc_engine.c. If CH13b4 has anything to do with the 1210s, then yeah -- the RADARUPTs are needed to clear it. Can the code be changed such that RADARUPTs are generated regardless of the breaker state? I.e., is there any bit of radar code that gets called if the breaker is out, or is it cut off entirely?

Also. Is it possible that the "fast" alarms have a different V05N08 display than the slow ones?


Title: Re: LM status...
Post by: indy91 on September 08, 2016, 01:33:54 PM
Yeah, the bit reset should definitely be in agc_engine.c. If CH13b4 has anything to do with the 1210s, then yeah -- the RADARUPTs are needed to clear it. Can the code be changed such that RADARUPTs are generated regardless of the breaker state? I.e., is there any bit of radar code that gets called if the breaker is out, or is it cut off entirely?

There is always an electrical "off" state for the simulated systems. In the case of the LR that is mostly a few Channel 33 bits which are all set to 1 (which is "off", because inverted). I don't think the powered off LR should send out a 0 to the RadarActivity bit though, that would just interfere with the RR. Do you want me to try and generate nonstop RADARUPTs with the inactivate LR? I have the feeling how and when CH13b4 is reset is different for reading the range or velocity data and because it should be independent from the LR timestep something goes still wrong. But if the bit is reset and the LGC just wants range from the LR, then the 1210 alarms have definitively stopped.
Quote
Also. Is it possible that the "fast" alarms have a different V05N08 display than the slow ones?

Ah, great idea, that would have been nice. But no, unfortunately the same noun 8.


Title: Re: LM status...
Post by: indy91 on September 08, 2016, 02:44:48 PM
I think I have solved it! There was some code in the LR range/rate processing that didn't let the same type of data (range, velocity X/Y/Z) be processed twice in a row. Maybe it already got stuck when it first read range data or so. Let me do code cleanup and try it a second time before we celebrate though, it still might be a fluke.

In the case the 1210s are solved, I already have the next topic for you. There are also 401 alarms happening during the descent, but also the ascent. They don't seem to do any harm to guidance or the DSKY, so they are not as important as the 1210 alarms. here the alarm data for the 401:

V05 N08

R1: 3757
R2: 60066

EDIT: No fluke! So there will be a nice commit on your way soon. When the fast 1210 alarms started before, now the velocity light goes on. I think that is the expected behaviour. There are no program alarms other than the 401 all throughout the landing. I did a bunch of other changes to the lemsystems.cpp already, so I'll first have to sort those out before I can commit the changes. Maybe I'll commit the other changes at the same time.

EDIT2: I'll dump all the LM changes I have at once. There probably is a better solution, but I was too lazy to make a branch for each of the changes. So here it is:

-The LR and RR set the RadarActivity bit to 0 whenever something was requested from them. This fixes the slow 1210 alarms.
-The LR and RR don't have the logic aynmore that prevent repeated requests for the same type of data. This should fix the fast 1210 alarms.
-I have added the geometry for the RR to track the CSM. This is not tested a lot, but if you start P20 and the LGC already has a decent idea where the CSM then lockon will occur and range/range rate data will be generated and also displayed on the meter. I have not checked if the LGC can steer the RR correctly or if incorporating the data into the state vector works.
-ACA and TTCA. This has been changed a lot, so please test and report problems. For now I had to disable the normal thruster groups. So the RCS can only be controlled by the LGC or with direct hardover commands, which I have added as well. The Numpad should be able to control the RCS via the LGC now, too. It should work like the RHC in the CSM, where also hardover commands (full deflection) are done with the numpad. If you want finer control, use a joystick. You can use the joystick as a

ACA: If you have a throttle lever, I have cheated so that the ACA has throttle control.
TTCA: The lever is now the jets/throttle switch and throttle commands are the x-axis/pitch-axis. Doesn't work too well, but who has a proper THC/TTCA anyway?!

I hope all this at once doesn't break anything. At least the lunar landing should work now. No big deal.  :cool7777:

P.S. In the P63 scenario the LGC minimum impulse (V76E) mode is activated, which currently doesn't work very well. Thruster commands are too short and have no delay. So if you want to test the ACA controls with the LGC, please engage proportional mode (V77E). You can also deactivate the direct RCS mode with the CDR ACA/4 Jet switch. That way you can use the numpad and not command hardover all the time.


Title: Re: LM status...
Post by: dseagrav on September 08, 2016, 03:40:16 PM
I think I have solved it! There was some code in the LR range/rate processing that didn't let the same type of data (range, velocity X/Y/Z) be processed twice in a row.

IIRC that was a workaround for something the radar test did. Have you tried the radar test after your change, does it still work?


Title: Re: LM status...
Post by: indy91 on September 08, 2016, 03:49:02 PM
IIRC that was a workaround for something the radar test did. Have you tried the radar test after your change, does it still work?

Seems like it? I just tried it and didn't notice anything being different. If, what the radar did, had to do with the LGC interaction (or even the same program alarm as during the actual descent?) then setting the RadarActivity bit to 0 should have fixed it, without requiring the workaround.


Title: Re: LM status...
Post by: thewonderidiot on September 08, 2016, 08:32:22 PM
Fantastic! Congrats on the landing!! :D I'll get on the 401s. I got a build of NASSP going last night, and am currently struggling my way through learning all the controls.  :)


Title: Re: LM status...
Post by: eddievhfan1984 on September 08, 2016, 09:59:17 PM
Yeah, the 0508 display just points to the alarm handler subroutine in this case. When do the 401s pop up, during certain maneuvers? Because during landing/ascent, I could see roll commands being used to correct for off-plane adjustments and LPD re-designation, but what kind of maneuver during those events would call for ±70° of roll?


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 02:35:38 AM
It will take a few ascents/descents to try your attempt at fixing the 401 alarm @thewonderidiot. Sometimes the alarms happen 3-4 times during the descent, sometimes not at all. It also depends on the attitude you start in. During the ascent they happen almost every time though.

The next two topics I want to work on for the LM are P63 throttle down and LR range data. Throttle down still happens a minute too late, so I guess our DPS thrust is still low or the pad loaded position for the ignition algorithm is not correct. I have a few differing sources about the max thrust of the DPS, but I'll test a few things there. The late throttle down is probably not so good for P64, with the earlier throttle down the trajectory should be closer to the reference.

For the LR, I want to work out the geometry in three steps. First a 2D approximation of the LR angle, just to test a few things. When yaw and roll are 0 this should be pretty decent. Especially the actual landing should improve a lot just by this simple version. Then I'll work out the whole LR geometry in 3D. The GSOP should have most of the transformations the LGC does to get altitude from LR range. And after that I'll add the velocity data. This seems like a pretty complicated task, but give me some time, I think I can work it out.


Title: Re: LM status...
Post by: eddievhfan1984 on September 09, 2016, 03:28:49 AM
It will take a few ascents/descents to try your attempt at fixing the 401 alarm @thewonderidiot. Sometimes the alarms happen 3-4 times during the descent, sometimes not at all. It also depends on the attitude you start in. During the ascent they happen almost every time though.

The next two topics I want to work on for the LM are P63 throttle down and LR range data. Throttle down still happens a minute too late, so I guess our DPS thrust is still low or the pad loaded position for the ignition algorithm is not correct. I have a few differing sources about the max thrust of the DPS, but I'll test a few things there. The late throttle down is probably not so good for P64, with the earlier throttle down the trajectory should be closer to the reference.

For the LR, I want to work out the geometry in three steps. First a 2D approximation of the LR angle, just to test a few things. When yaw and roll are 0 this should be pretty decent. Especially the actual landing should improve a lot just by this simple version. Then I'll work out the whole LR geometry in 3D. The GSOP should have most of the transformations the LGC does to get altitude from LR range. And after that I'll add the velocity data. This seems like a pretty complicated task, but give me some time, I think I can work it out.

The LM systems handbook has that data: http://www.ibiblio.org/apollo/Documents/LMA790-3-LM10-ApolloOperationsHandbookLunarModuleLM10AndSubsequent-Volume1-SubsystemsData.pdf (http://www.ibiblio.org/apollo/Documents/LMA790-3-LM10-ApolloOperationsHandbookLunarModuleLM10AndSubsequent-Volume1-SubsystemsData.pdf), Figure 2.2-12. Is your intent to use the Orbiter API to get the velocities and altitudes in LVLH and make the necessary trig adjustments for the LGC I/O?


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 03:54:17 AM
The LM systems handbook has that data: http://www.ibiblio.org/apollo/Documents/LMA790-3-LM10-ApolloOperationsHandbookLunarModuleLM10AndSubsequent-Volume1-SubsystemsData.pdf (http://www.ibiblio.org/apollo/Documents/LMA790-3-LM10-ApolloOperationsHandbookLunarModuleLM10AndSubsequent-Volume1-SubsystemsData.pdf), Figure 2.2-12. Is your intent to use the Orbiter API to get the velocities and altitudes in LVLH and make the necessary trig adjustments for the LGC I/O?

Pretty much. Using the state vector + moon radius would probably be better to also take the curvature of the moon into account, but thinking about the future, we need to use altitude for Orbiter 2016. Orbiter 2016 has an altitude function that calculations the local altitude, but only where the vessel is, not where the LR is pointing. Doesn't make a difference in our Luminary versions though, only in the Apollo 15+ version which we don't have.

I have done two more descent tests, one ascent test and one late P71 abort and no 401 so far with the new AGC engine changes. No program alarm at all actually. So it looks like that was the correct change. I want to do 1-2 more ascents before I am really sure though.

If I use the highest estimate for the 92.5% thrust setting I could find (9870 lbs: http://history.nasa.gov/SP-4029/Apollo_18-13_Launch_Vehicle-Spacecraft_Key_Facts.htm) then throtte down still happens as late as 6:57 since PDI. Our mass is good, the specific impulse should be dependant on the thrust setting, which it currently isn't, but that shouldn't be the problem. So, not sure why throttle down is happening late. Of course the timing is critical, ignition a few seconds earlier can change the throttle down time a lot.


Title: Re: LM status...
Post by: eddievhfan1984 on September 09, 2016, 04:37:45 AM
Well, my understanding was that because of digital control, the DECA could command full thrust directly. The difference with the TTCA is that it uses analog voltages to transmit thrust commands and has to tolerate a 5% wiggle room as a result. So I think you could compromise by only allowing 92.5 in manual throttle through the TTCA control code block (maybe throw in some pseudorandom noise for extra effect), and use the full rated thrust value as is.


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 05:15:53 AM
Quote LM AOH: "The total thrust commanded (automatic and/or manual) cannot exceed 92.5%". So it can't really be that, right?

I have commited three changes:

-The AGC engine change indeed fixed the 401 alarms. Even after 3 ascents and 2 descents they are not happening anymore.
-I forgot about the ACA counters when I implemented the numpad control for the LGC. Now the counters are not overflowing anymore, when a negative value is commanded with the numpad.
-I had removed the Orbiter thruster groups so they don't interfere with LGC RCS control, but because of that there were no RCS sounds anymore. The CSM has a specific function for that, the LM now has that, too.


Title: Re: LM status...
Post by: eddievhfan1984 on September 09, 2016, 05:32:08 AM
Well, there goes that theory. I guess we could still do the pseudorandom thing with the actual engine output, if we wanted to.


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 12:08:37 PM
Well, there goes that theory. I guess we could still do the pseudorandom thing with the actual engine output, if we wanted to.

Well, there is a document that says 97% thrust should be used for Apollo 11, but I'm not sure that isn't just a displayed value...

I've commited the first attempt at landing radar range calculation. I have also tried to fix a few compiler warnings, hopefully I chose the correct data types everywhere. As I said above, this is a simplified version of the LR that will only work with roll and yaw being zero. So flying heads down during the first part of the descent can be done, but don't incorporate altitude data. I have set the maximum range as 50,000 feet. This should lead to good data at about 40,000 feet altitude. What is missing for the complete 3D version is 2-3 rotation matrizes. Challenging because of left-handed vs. right-handed coordinates, but certainly possible. I'll try to implement that in the next few days.

Usually I have used the Apollo 12 G&N Checklist, but there is difference for the LR data incorporation. The checklist says first a V57E which leads to the V16 N68 display and then PRO to accept the data. What you actually have to do with the Apollo 11 LGC is first the V16 N68, then the DH check and V57E directly incorporates the data.

The LR data being processed leads to two new program alarms in P64. One is a 1201, the other is a 1202. Guidance doesn't seem to be affected. I have the feeling I have heard that before...  should we even try to find the issue causing the alarms (probably something with the LR again) or do we just leave them in as "effect"?  :ROTFL3453:


Title: Re: LM status...
Post by: jalexb88 on September 09, 2016, 01:07:13 PM
Just had a very successful lunar landing!  My last attempts before the LR update would not sequence from P64 to P65 and would crash on the moon unless I used P66 or P67. Now with the LR update, using the unbiased P63 test scenario, she goes from P64 to P65 very smoothly and lands very smoothly with a good control on rate of descent! Nice catch on the differing procedures between 11 and 12. I've been waiting for this for a while... thanks Indy!!  

The LR still does not drive my tape meter very well, but I guess its in the works. BTW I think we should definitely not "fix" those alarms  :ROTFL3453:


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 01:24:41 PM
Speaking about procedures, there is still some trouble with P64 and P66. In P64 I always get a 99 or a 0 for the LPD time. And the LM never reacts to any LPD commands. Has that worked for anyone? You just have to press PRO to start the LPD, right? Maybe this is a padload problem and something with the P64 targets is wrong or so. Or maybe still a result of the late throttle down?

And P66 has the expected throttle oscillations that nearly caused a disaster for Apollo 11 and 12.There currently is no delay for throttle commands at all, not in the DECA and not in the DPS itself. I bet once we introduce these time lags the oscillations will be much better. Unfortunately we don't have a LGC version where it is fixed as comparison. That was only done after Apollo 13. P66 is of course the program of choice to land, but there is still much to do to implement like the cross pointer, for situational awareness. Right now I just enjoy every time how good P65 can land without any inputs.

The tape meter still needs work, yeah. I don't even know what information it gets when the Mode Control switch is the in the landing radar position. The radar shouldn't have any altitude information, so it's either range (nearly identical to altitude close to landing) or the LGC directly sends the LR data to the meter.

The alarms might become bad once the LGC also has to process velocity information. So it might still be useful to look into their cause. I very much doubt it's the RR though.


Title: Re: LM status...
Post by: thewonderidiot on September 09, 2016, 01:39:29 PM
Yeah, these are probably happening for the same reason as Apollo 11, even if it's not the same root cause... input from some device(s) coming in too quickly. How fast is radar data being fed in? The sum total of all radar requests shouldn't exceed 9 Hz or so.


Title: Re: LM status...
Post by: jalexb88 on September 09, 2016, 01:47:17 PM
I haven't had much success with the LPD, either and P66 is pretty erratic for me as well. Should I still used the biased scenario? I was thinking that with the LR working, the unbiased one would now be fine. I tried doing a run with the RR breakers pulled, to see if we get the 1201,1202 and yes that is affirm. I think you are right its not the RR.

I will do more runs to test and I've given the RR a try to track the CSM and had some success with it, Ill see how far I can get through a rendezvous...


Title: Re: LM status...
Post by: thewonderidiot on September 09, 2016, 01:48:54 PM
Unfortunately we don't have a LGC version where it is fixed as comparison. That was only done after Apollo 13.

As far as I know, this was just a constant change. The constant is THROTLAG in CONTROLLED_CONSTANTS.agc. For our two versions of Luminary, it has Don Eyles's setting of 0.2. Don's site doesn't say what the value was changed to, but we'll probably get pretty close just by changing that constant to 0.075, until we get a real Apollo 14+ Luminary listing.  :)


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 02:01:40 PM
Yeah, these are probably happening for the same reason as Apollo 11, even if it's not the same root cause... input from some device(s) coming in too quickly. How fast is radar data being fed in? The sum total of all radar requests shouldn't exceed 9 Hz or so.

No idea, range data is of course generated each timestep (60FPS) but the registers are filled and the RADARUPTs generated whenever the LGC requests it.

As far as I know, this was just a constant change. The constant is THROTLAG in CONTROLLED_CONSTANTS.agc. For our two versions of Luminary, it has Don Eyles's setting of 0.2. Don's site doesn't say what the value was changed to, but we'll probably get pretty close just by changing that constant to 0.075, until we get a real Apollo 14+ Luminary listing.  :)

Apollo 11 didn't crash by using P66, so we won't crash by using P66. Changing a fixed constant in the AGC is not an option. Then we might as well use the much simple AGC C++ that was created for NASSP a long time ago. We always  make our simulation more realistic to be able to work with the Virtual AGC, not the other way around. ;)


Title: Re: LM status...
Post by: thewonderidiot on September 09, 2016, 02:17:21 PM
Oh, of course, that's not what I was trying to get at. I was just saying we could try that to observe the behavior change if we wanted to.

Also, I wonder whether the AGC is getting ahead of itself if the radar data comes in faster than the ~100ms it took in the real thing. It might see an instantaneous RADARUPT and then immediately try to schedule another reading.


Title: Re: LM status...
Post by: indy91 on September 09, 2016, 02:22:42 PM
Oh, yes, nice idea. But I think there are a few other more important things to work on. When I start working on throttle delay for P66 and become frustrated because it still doesn't work, then I will certainly at least test a smaller lag constant just to see what happens.  :)

For the 1201/1202 alarms, I guess it would be helpful again to get the alarm data? Maybe I'll delay that until the LR generates velocity data, maybe we find something that works for the range data, but later the alarms are still happening.


Title: Re: LM status...
Post by: thewonderidiot on September 09, 2016, 02:25:20 PM
Yeah, get the alarm data and try to measure RADARUPT frequency, if you wouldn't mind. Thanks!

Though I fear the alarm data will just point us to the alarm call in EXECUTIVE.


Title: Re: LM status...
Post by: jalexb88 on September 09, 2016, 03:50:08 PM
Hmm... I'm getting a random orbiter CTD with the latest commit that happens only sometimes and when it does its near the beginning of the scenario. Anyone else experience this?




Title: Re: LM status...
Post by: eddievhfan1984 on September 09, 2016, 04:29:16 PM
My understanding of the tapemeters is that it is driven based on PRF signals from either the LGC interface electronics or the LR interface. (Presumably the faster the pulse frequency, the lower the altitude/altitude rate, or something like that). Do we really want to model the pulse waves directly, though?


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 03:44:46 AM
Yeah, get the alarm data and try to measure RADARUPT frequency, if you wouldn't mind. Thanks!

Though I fear the alarm data will just point us to the alarm call in EXECUTIVE.

Yeah, that's what I thought, too, just pointing at the EXECUTIVE and not being very conclusive about what is stealing cycles. Here the alarm data for the 1202:

R1:2654
R2:20000

I'll try to measure the RADARUPTs, but I also want to look into the LPD problems. the time-to-go in P64 seems to be counting down correctly, but the time remaining for LPD is somehow screwy. Maybe there is a connection to the program alarms.

Hmm... I'm getting a random orbiter CTD with the latest commit that happens only sometimes and when it does its near the beginning of the scenario. Anyone else experience this?

Sometimes with the LM the frame rate is terrible for me, when I have just loaded a scenario. Didn't cause a CTD for me, but all I could do is reload.

My understanding of the tapemeters is that it is driven based on PRF signals from either the LGC interface electronics or the LR interface. (Presumably the faster the pulse frequency, the lower the altitude/altitude rate, or something like that). Do we really want to model the pulse waves directly, though?

If it is coming from the LR interface then it has to be LR Range and the measured vertical velocity. We don't need to model pulses from the LR, I think, but with the LGC and AGS we ar enot so lucky. There is a register for the tapemeter and a few output bits that control it. Not sure about the scaling though.

EDIT: The AOH confirms it. The Altitude meter displays LR slant range.


Title: Re: LM status...
Post by: eddievhfan1984 on September 10, 2016, 04:40:42 AM
That 0508 data points towards the display servicer routines.

Code:
057957,000841: 10,2646           30160                           CA       PLAYTEM4                              #  IS THIS A FLASHING R DISPLAY
057958,000842: 10,2647           74750                           MASK     BIT4                                 
057959,000843: 10,2650           10000                           CCS      A                                     
057960,000844: 10,2651           12657                           TCF      VACDSP                                #  YES, MAKE DSPLAY JOB A VAC
057961,000845: 10,2652           30063                           CA       NEWPRIO                               #  NO, MAKE DSPLAY JOB A NOVAC
057962,000846: 10,2653           05072                           TC       NOVAC                                 
057963,000847: 10,2654  E7,1471                                  EBANK=   WHOCARES                             
057964,000848: 10,2654           02546 20067                     2CADR    MAKEPLAY

Not too sure about the source of this one...


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 05:13:15 AM
Classic AGC behavior, the displays have low priority. When I try to display the alarm code and data it takes a while until the display comes up. Interestingly enough the program alarm also happens when I haven't done a V57. So just the presence of a "Data Good" signal is already enough to cause the problem. The LGC requests data from the LR too often maybe? Could very well still be a LR problem...


Title: Re: LM status...
Post by: rcflyinghokie on September 10, 2016, 08:33:43 AM
Speaking about procedures, there is still some trouble with P64 and P66. In P64 I always get a 99 or a 0 for the LPD time. And the LM never reacts to any LPD commands. Has that worked for anyone? You just have to press PRO to start the LPD, right? Maybe this is a padload problem and something with the P64 targets is wrong or so. Or maybe still a result of the late throttle down?

I get the same reaction for the P64 LPD so it's not just you.

The alarms might become bad once the LGC also has to process velocity information. So it might still be useful to look into their cause. I very much doubt it's the RR though.

The 1201 and 1202 are executive overflows right?  And on the A11 mission they were caused by the RR and LR simultaneously feeding information to the LGC?  I would say the only way to leave them in for "effect" should be if we keep the procedural error of having both sets of data feeding into the LGC as in A11 and let it occur organically.


Title: Re: LM status...
Post by: eddievhfan1984 on September 10, 2016, 08:40:51 AM
I just did a test myself. No 1201/1202, although I did have the same issue of no transfer to P65 due to LPD time not being recorded properly...

The A11 alarms occurred more because the the lack of matched AC power phase made the LGC think the RR was in continuous motion, rather than fixed position. I don't think it's that big of a deal though—is our plan to allow the user to overfly West Crater like in the real mission, or send it directly to the IRL landing site?

Also, in regards to the ROD switch, I had a thought—during IMU programs, it's mentioned that the ROD switches can be used in lieu of the AOT mark buttons in case of a malfunction/jam. Is it possible it works both ways?


Title: Re: LM status...
Post by: rcflyinghokie on September 10, 2016, 09:01:05 AM
I just did a test myself. No 1201/1202, although I did have the same issue of no transfer to P65 due to LPD time not being recorded properly...
Yeah I am not transferring to P65 either, it wants to stay in P64 for me :(

The A11 alarms occurred more because the the lack of matched AC power phase made the LGC think the RR was in continuous motion, rather than fixed position. I don't think it's that big of a deal though—is our plan to allow the user to overfly West Crater like in the real mission, or send it directly to the IRL landing site?
Ahh ok, I know there was a lot of controversy on that topic I didn't know if there was an "accepted" answer as to the final verdict.  And that's hard to decide.  I would err on the side of caution and say lets get it nailed down to the landing site.

And for the cause of landing long, didn't the undocking impart an unaccounted for dV to the spacecraft?  If so would we use that as the cause of landing long or would we actually program the computer to land incorrectly, opens up a lot of "what if's"


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 09:07:58 AM
I just did a test myself. No 1201/1202, although I did have the same issue of no transfer to P65 due to LPD time not being recorded properly...

Yeah I am not transferring to P65 either, it wants to stay in P64 for me :(

No transfer to P65? I didn't have that one before. Without the LR I sometimes crashed before the LGC reached P65, but now with at least the simplified LR range calculation (and before with a biased landing site vector) it always automatically goes into P65 at the end of P64. That can take a while though, the LM is very low and slow when that happens. I did have problems with getting into P66, but more about that below.

Quote
The A11 alarms occurred more because the the lack of matched AC power phase made the LGC think the RR was in continuous motion, rather than fixed position. I don't think it's that big of a deal though—is our plan to allow the user to overfly West Crater like in the real mission, or send it directly to the IRL landing site?

Good question. The actual landing site has some textures, so in all my recent attempts I tried to land on that. We won't be able to use that for Orbiter 2016 though. The planned landing site was of course in the padload document. So I'd say let's use the actual landing site for Orbiter 2010 and the planned landing site for Orbiter 2016.

Also, in regards to the ROD switch, I had a thought—during IMU programs, it's mentioned that the ROD switches can be used in lieu of the AOT mark buttons in case of a malfunction/jam. Is it possible it works both ways?

I don't think so. But the commit two days ago actually included the ROD switches. I forgot about that. They are the same as in the old LM autopilot. "-" for "increase descent rate" and "=" for "decrease descent rate". I had problems before getting into P66, but what you have to do is the PGNS mode control switch to ATT HOLD and then on the first ROD command it switches to P66. P66 is fairly unstable, but it gets better with low pitch angles. I've just managed to manually land (not crash) the LM with P66. Without LR velocity information it's difficult to judge your vertical speed though. When all the visual aids are functional (cross pointer, altitude meter etc.) on the LPD panel then it should be much easier to land manually.

And for the cause of landing long, didn't the undocking impart an unaccounted for dV to the spacecraft?  If so would we use that as the cause of landing long or would we actually program the computer to land incorrectly, opens up a lot of "what if's"

Using the landing site vector for the actual landing site is the easiest way.


Title: Re: LM status...
Post by: jalexb88 on September 10, 2016, 09:11:22 AM
I only had the no sequencing from P64 to P65 before the LR update... Are you guys setting the LR up properly? Breakers in and at around 40000 ft you have to do V16N68 and V57 to start incorporating.


Title: Re: LM status...
Post by: rcflyinghokie on September 10, 2016, 09:13:17 AM
I had the no sequencing from P64 to P65 before the LR update... Are you guys setting the LR up properly? Breakers in and at around 40000 ft you have to do V16N68 and V57 to start incorporating. Then it should go to P65.

Yeah I did that, it took P64 all the way into the surface.  I am trying again now to see if I may have made a mistake.

Also, procedural question, are we using 2 or 4 jet for att/trans switch during PDI?

EDIT:  Just tried again, still stayed in P64 until it crashed.  40k ft V16N68, V57.  P64 comes up and PRO, and no switch to P65 automatically.  Also I have a VEL light from about 30k ft to the crash.


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 09:17:32 AM
Yeah I did that, it took P64 all the way into the surface.  I am trying again now to see if I may have made a mistake.

As jalexb88 said, waiting for the ALT light to go out, then a V16 N68. Check that R3 (altitude difference between LR and LGC) is fairly low, it should be about -300 feet. And then incorporate with V57. This should send you back to V06N63 and you should be good. You can look at noun 68 again to see the DH converge.

Quote
Also, procedural question, are we using 2 or 4 jet for att/trans switch during PDI?

The switch is for the AGS only. For the LGC you have to set it with verb 48.


Title: Re: LM status...
Post by: rcflyinghokie on September 10, 2016, 09:37:24 AM
As jalexb88 said, waiting for the ALT light to go out, then a V16 N68. Check that R3 (altitude difference between LR and LGC) is fairly low, it should be about -300 feet. And then incorporate with V57. This should send you back to V06N63 and you should be good. You can look at noun 68 again to see the DH converge.

Same issue, P64 all the way to the surface, and the VEL light remains on.

EDIT:  Apparently I am using an older P63 .scn, I am going to try it with the latest one posted that I missed.


Title: Re: LM status...
Post by: eddievhfan1984 on September 10, 2016, 09:43:04 AM
I did the same procedures myself. Convergence was fine, but the darned thing wouldn't change over from LPD mode automatically. In any case, is there an Orbiter API function to get velocities in LVLH, or is it state-vector only?


Title: Re: LM status...
Post by: rcflyinghokie on September 10, 2016, 09:52:05 AM
I did the same procedures myself. Convergence was fine, but the darned thing wouldn't change over from LPD mode automatically. In any case, is there an Orbiter API function to get velocities in LVLH, or is it state-vector only?

The changeover from LPD is my issue as well.  Stays on that screen in P64 until it hits the surface.


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 10:47:06 AM
I did the same procedures myself. Convergence was fine, but the darned thing wouldn't change over from LPD mode automatically.

I have to ask a few stupid questions then: Are you using the release from yesterday? Have you only started the LR Range incorporation once in an heads up attitude? Is the PGNS mode control switch in Auto and Auto Thrust enabled?

If the answer to every question is yes then I am out of ideas. For me it doesn't matter if I have pressed PRO in P64 or not, it switches to P65 if I don't do anything to go to P66 or P57. What altitude does the DSKY display just before touchdown? If it is far away from 0 then for some reason the LGC still doesn't know the altitude.

Quote
In any case, is there an Orbiter API function to get velocities in LVLH, or is it state-vector only?

GetShipAirspeedVector() is the answer. It's even in local ship coordinates, so that makes things easier. The landing radar in both positions is angled about 6° from the the centerline to the right (I think, or left). That also applies to the range, but even more for velocities. I'll work on the realistic range and velocity data soon.

EDIT: I've added a X-Pointer class. The cross pointers were actually drawn before, but they didn't have the proper scaling to do anything without the old LM autopilot. I haven't changed anything about how they are drawn or their functionality, just connected them to the correct CBs and switch, make them draw power etc. All that is currently working is displaying RR rates. You can try a few different scalings with the slew rate and x-pointer scale switches.


Title: Re: LM status...
Post by: eddievhfan1984 on September 10, 2016, 11:20:52 AM
At touchdown, the altitude from the DSKY is about 200 feet...


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 01:26:56 PM
At touchdown, the altitude from the DSKY is about 200 feet...

That's too high. The only differences I can see between my copy and the latest release is a slightly different scenario without bias (we don't need that anymore) and that I have increased the DPS thrust for testing. I'll try if it is different without the higher thrust, but it really shouldn't be.

But before you try it again, I almost have the complete range geometry ready. There is just one sign difference that confuses me. If I have that ready just try it with that and a new scenario.

EDIT: I have commited the complete LR range geometry. When you stay in the initial attitude of the test scenario then the initial DH is+340 feet instead of -300 feet. I don't really like that, but there is still the assumption that the Moon is flat in the rnage calculation, so maybe that is the problem. Even the LGC calculates the altitude from the slant range with a spherical Moon, so I will find these equations in the GSOP and use them in the future. Attached is the scenario I have been using. In theory it should land you right in the center of the Tranquility Base texture.


Title: Re: LM status...
Post by: jalexb88 on September 10, 2016, 03:57:03 PM
I have tried an abort with P70/71, followed by attempting a rendezvous. As per the Apollo 11 flight plan, V93 to reinitialize the w-matrix, V80 for LM SV updating. I start P20 which orients to tracking attitude. The RR then locks on but its a bit inconsistent. I have to move the rotary to slew and then manually adjust it to get a lock-on. It then gets good range data and it stays locked on for the most part, but it loses it sometimes and I have to manually slew it back. In P20 It does incorporate the marks, but the noun 49 delta R/V are too high to proceed on. I then noticed that the LGC only slightly moves the RR trunnion/shaft when I initially started P20, but then they stop moving, other than me slewing them back to a lock-on. Is the RR supposed to be constantly adjusting the trunnion/shaft angle while in P20 with the selector in LGC mode?

Also I'm not getting those random CTDs anymore  :? And Indy, you were talking about sometimes loading a scenario with low fps, for me every scenario load has low fps, but I can fix it simply by hitting a key on the DSKY, say the reset button. Weird.


Title: Re: LM status...
Post by: indy91 on September 10, 2016, 04:37:34 PM
Oh, of course, that's not what I was trying to get at. I was just saying we could try that to observe the behavior change if we wanted to.

Also, I wonder whether the AGC is getting ahead of itself if the radar data comes in faster than the ~100ms it took in the real thing. It might see an instantaneous RADARUPT and then immediately try to schedule another reading.

I tried to implement an artificial delay between setting the RadarActivity bit and the LR response (filling the register, RadarActivity bit zero and RADARUPT), but that didn't help. Maybe I should set it higher than 0.1s? Also, if I put the code that zeros the RadarActivity bit in the "LR unpowered" section of the code, then the 1210 alarms don't happen anymore with a pulled circuit breaker. Resetting the RadarActivity bit shouldn't really be in the in the LR code at all, I guess. Maybe the 1210 and the 1201/1202 alarms are both caused by this? If the bit isn't reset at all, then the 1210 alarms happen. If the bit is reset too fast or too often then the executive overflow occurs.

I have also started preliminary work on LR velocity data, but there a bunch of side effects and it needs more time. Among them even worse executive overflow.

I have tried an abort with P70/71, followed by attempting a rendezvous. As per the Apollo 11 flight plan, V93 to reinitialize the w-matrix, V80 for LM SV updating. I start P20 which orients to tracking attitude. The RR then locks on but its a bit inconsistent. I have to move the rotary to slew and then manually adjust it to get a lock-on. It then gets good range data and it stays locked on for the most part, but it loses it sometimes and I have to manually slew it back. In P20 It does incorporate the marks, but the noun 49 delta R/V are too high to proceed on. I then noticed that the LGC only slightly moves the RR trunnion/shaft when I initially started P20, but then they stop moving, other than me slewing them back to a lock-on. Is the RR supposed to be constantly adjusting the trunnion/shaft angle while in P20 with the selector in LGC mode?

Pretty much my experience, too. I couldn't really test the geometry for the RR, because the LGC never tracked the CSM. And range and range rate maybe need to be biased or something else is happening there. So RR assisted rendezvous are not really feasible yet.

Quote
Also I'm not getting those random CTDs anymore  :? And Indy, you were talking about sometimes loading a scenario with low fps, for me every scenario load has low fps, but I can fix it simply by hitting a key on the DSKY, say the reset button. Weird.

I think it has to do with the LM panel, but I didn't know about the DSKY fix.  :ROTFL3453: A while back I changed some things about loading the panel on scenario start. Maybe something bad happened there, although I have the feeling I got the random low fps even before that. I haven't had it in a while, but there were also random crashes because of incompatibility with the D3D9 Client. So maybe something like that is still the case. No idea really.


Title: Re: LM status...
Post by: eddievhfan1984 on September 10, 2016, 05:12:51 PM
I have tried an abort with P70/71, followed by attempting a rendezvous. As per the Apollo 11 flight plan, V93 to reinitialize the w-matrix, V80 for LM SV updating.

Updating the LM state vector? I thought it was supposed to be updating the CSM SV during rendezvous...


Title: Re: LM status...
Post by: thewonderidiot on September 10, 2016, 05:43:01 PM
I tried to implement an artificial delay between setting the RadarActivity bit and the LR response (filling the register, RadarActivity bit zero and RADARUPT), but that didn't help. Maybe I should set it higher than 0.1s? Also, if I put the code that zeros the RadarActivity bit in the "LR unpowered" section of the code, then the 1210 alarms don't happen anymore with a pulled circuit breaker. Resetting the RadarActivity bit shouldn't really be in the in the LR code at all, I guess. Maybe the 1210 and the 1201/1202 alarms are both caused by this? If the bit isn't reset at all, then the 1210 alarms happen. If the bit is reset too fast or too often then the executive overflow occurs.
And the RR isn't generating any RADARUPTs either right now? That 10Hz limit applies to both of them combined. Yeah, ideally the bit would be reset 100-110ms after the radar activity bit is set, regardless of which radar is being addressed, and regardless of whether or not they're on. You could possibly try increasing the delay to 0.11s, which appears to be close to the worst case, but I wouldn't push it any further than that.

I'm going to start looking at that old VirtualAGC issue that claims most instructions take an MCT longer than they should. It's an easy change if it's right, and I'd be curious to hear if the 1201s and 1202s go away entirely if you make the change suggested on the issue. That would account for a LOT of incorrectly wasted CPU time.

e: Actually on further thought, you're just sticking the radar readings directly into RNRAD, right? In reality, there will be CPU time stolen from SHINCing and SHANCing bits into that counter. So assuming we've got the RADARUPT load approximately correct, we should be dedicating slightly less CPU time to the radars than the real thing would have.


Title: Re: LM status...
Post by: jalexb88 on September 10, 2016, 06:22:57 PM
Updating the LM state vector? I thought it was supposed to be updating the CSM SV during rendezvous...

In the Apollo 11 flight plan it says to use V80, which according to the A12 checklist (and in-sim test) is LM SV update. I have tried it using the CSM SV update V81, but it still gives me wildly inaccurate SV incorporations.

Here is my scenario for testing, right after the CDH burn (P33), ~40 minutes to TPI. I used just LM+CSM RTCC MFD SV updates up until here. P20 is running with the RR locked on the CSM and V80 will start incorporation.

EDIT: Well, I did the full rendezvous by using only RTCC MFD state vector updates for both vehicles before each maneuver. The LGC did a very good job with P32,33,34,35 even without the RR updates! I was able to manually slew the RR  to keep a lock on for most of the time so I used it for monitoring the range and closure rate. I ended up on a very accurate course after the last P35. only slight RCS translation activity to keep the CSM steady in my line of sight.  The RR seems to give accurate range and range rate as far as the tape meter is concerned.


Title: Re: LM status...
Post by: rcflyinghokie on September 10, 2016, 07:31:25 PM

I have to ask a few stupid questions then: Are you using the release from yesterday? Have you only started the LR Range incorporation once in an heads up attitude? Is the PGNS mode control switch in Auto and Auto Thrust enabled?

If the answer to every question is yes then I am out of ideas. For me it doesn't matter if I have pressed PRO in P64 or not, it switches to P65 if I don't do anything to go to P66 or P57. What altitude does the DSKY display just before touchdown? If it is far away from 0 then for some reason the LGC still doesn't know the altitude.

Using the newest build and scn file I still am getting the same issues, and also I still have a VEL light on all the way to the surface.  I really have no idea what I am doing wrong :(


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 03:39:22 AM
Updating the LM state vector? I thought it was supposed to be updating the CSM SV during rendezvous...

The best practice is probably updating the less accurate state vector. And the LM has just done DOI, PDI and a few minutes in Average G, while the CSM has only done the separation maneuver. So the LM state vector will be worse than the CSM state vector.

In the Apollo 11 flight plan it says to use V80, which according to the A12 checklist (and in-sim test) is LM SV update. I have tried it using the CSM SV update V81, but it still gives me wildly inaccurate SV incorporations.

Here is my scenario for testing, right after the CDH burn (P33), ~40 minutes to TPI. I used just LM+CSM RTCC MFD SV updates up until here. P20 is running with the RR locked on the CSM and V80 will start incorporation.

EDIT: Well, I did the full rendezvous by using only RTCC MFD state vector updates for both vehicles before each maneuver. The LGC did a very good job with P32,33,34,35 even without the RR updates! I was able to manually slew the RR  to keep a lock on for most of the time so I used it for monitoring the range and closure rate. I ended up on a very accurate course after the last P35. only slight RCS translation activity to keep the CSM steady in my line of sight.  The RR seems to give accurate range and range rate as far as the tape meter is concerned.

That's great to hear. I haven't tried a full rendezvous with the LM, but since I updated the clock in the P63 test scenario everything has become very accurate. I also still have a LM update for the RTCC MFD in the pipeline, so that you can calculate maneuvers and uplink them, calculate the LM Maneuver PAD and downlink the REFSMMAT to the MFD. P30 target updates are currently not working with the LM. Different memory address. This update only needs a little bit more testing. And after that DOI targeting would be really nice. The calculations for that are actually already in the MFD, but there is no dedicated MFD page for it yet.

Using the newest build and scn file I still am getting the same issues, and also I still have a VEL light on all the way to the surface.  I really have no idea what I am doing wrong :(

The velocity light should be on, there are no velocity data being processed yet. But even then, the worst thing that happens for me sometimes is that the LM is hovering at the end of P64, because its velocity data is inaccurate. But it still goes into P65 every time...

Can you maybe post a scenario at around PDI+6 minutes? I think that is a good time to find any procedural errors. Also you should have done the V57 at that time.


Title: Re: LM status...
Post by: jalexb88 on September 11, 2016, 09:22:03 AM
That's great to hear. I haven't tried a full rendezvous with the LM, but since I updated the clock in the P63 test scenario everything has become very accurate. I also still have a LM update for the RTCC MFD in the pipeline, so that you can calculate maneuvers and uplink them, calculate the LM Maneuver PAD and downlink the REFSMMAT to the MFD. P30 target updates are currently not working with the LM. Different memory address. This update only needs a little bit more testing. And after that DOI targeting would be really nice. The calculations for that are actually already in the MFD, but there is no dedicated MFD page for it yet.

It will be great once we get the RR working but I guess we have to get the landing right first.  :cool7777: Any luck with the LPD? I tried last night but no joy. I think the LPD display is working, the number on the DSKY does correlate somewhat to the window markings, but weird time value. You were talking about the velocity component of the LR that is still in the works, is that why I have the VEL light on the DSKY? Maybe also what is missing for the LPD to function properly?  Looking forward the the MFD updates!


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 09:41:33 AM
The Velocity light is on when the LGC is looking for velocity data (should start at 24,000 feet or so) but the Landing Radar hasn't send a "VelocityDataGood" signal. I've been already testing the velocity data, it did a beautiful touchdown at -3 ft/s and no lateral and horizontal velocity at all on the first try, but the behavior at higher altitudes is a little bit erratic. When the velocities get incorporated then the 1201/1202 alarms get even worse, especially at the end of P63 they are now happening, too. LPD seems unchanged, the time remaining in LPD always shows 99 and then directly goes to 0. When it is 0 no landing point changes can be calculated anymore. I also had something strange happen with a P66 test, maybe the ROD switch got stuck or so. It just went straight up until it reach 200+ ft/s upwards. :ROTFL3453: Could be a problem with the LR velocities, so more testing is required.


Title: Re: LM status...
Post by: jalexb88 on September 11, 2016, 09:52:21 AM
The Velocity light is on when the LGC is looking for velocity data (should start at 24,000 feet or so) but the Landing Radar hasn't send a "VelocityDataGood" signal. I've been already testing the velocity data, it did a beautiful touchdown at -3 ft/s and no lateral and horizontal velocity at all on the first try, but the behavior at higher altitudes is a little bit erratic. When the velocities get incorporated then the 1201/1202 alarms get even worse, especially at the end of P63 they are now happening, too. LPD seems unchanged, the time remaining in LPD always shows 99 and then directly goes to 0. When it is 0 no landing point changes can be calculated anymore. I also had something strange happen with a P66 test, maybe the ROD switch got stuck or so. It just went straight up until it reach 200+ ft/s upwards. :ROTFL3453: Could be a problem with the LR velocities, so more testing is required.

Have you tried a run with the RR off? Ive had that P66 issue multiple times, the LGC randomly orders the DPS full throttle for short bursts and up you go!


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 10:09:08 AM
The velocity light should be on, there are no velocity data being processed yet. But even then, the worst thing that happens for me sometimes is that the LM is hovering at the end of P64, because its velocity data is inaccurate. But it still goes into P65 every time...

Can you maybe post a scenario at around PDI+6 minutes? I think that is a good time to find any procedural errors. Also you should have done the V57 at that time.

Here is my PDI+6 minutes.

EDIT:  Just realized I forgot the DES ENG CMD OVRD off :P


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 10:45:43 AM
Yes, with that scenario the LM is crashing when in P64. What scenario is that? It's trying to land at the targeted landing site, I think all my recent scenario were targeted for the actual landing site. The DH never seems to become 0, it was -40 when the LM crashed. What was the DH when the LR started getting range data? It should be around -250 ft. Also the LGC clock is off by almost 2 seconds, which is a little bit worrying. Is that difference between LGC clock and PAMFD already there before PDI? Maybe something bad happens with the clock during PDI.

Another thing I hadn't considered before, the LR range should really be calculated at the bottom of the LM where the LR actually is and not a few meters above at the center of gravity of the LM. That will be changed and certainly help.


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 11:23:43 AM
Yes, with that scenario the LM is crashing when in P64. What scenario is that?

The latest .scn file that was posted in this thread. (The one posted and paired with the (actual LS) version)

It's trying to land at the targeted landing site, I think all my recent scenario were targeted for the actual landing site. The DH never seems to become 0, it was -40 when the LM crashed. What was the DH when the LR started getting range data? It should be around -250 ft.

About -217 ft

Also the LGC clock is off by almost 2 seconds, which is a little bit worrying. Is that difference between LGC clock and PAMFD already there before PDI? Maybe something bad happens with the clock during PDI.

I just started the same scn again and the clocks actually are 1-2 seconds off upon loading.


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 11:35:53 AM
Really this scenario?: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=491.msg24290#msg24290 Then you must have renamed it before the quicksave...

When I load that scenario the clock is perfect on time. 1 second already make a state vector error of 1650 m (velocity of the LM), so in that case the landing site might be that much off, too. There are also some weird things going on and I now think that the 1201/1202 alarms have actual bad effects. If I deactivate the JoystickTimestep function so that no ACA and TTCA signals are changed then the scenario you posted actually works and goes into P65, just above the surface. Still 1202 alarms, but much better. So it's not just displays and the whole LPD function might be handicapped because of it, too. Not sure what the priority of the LPD is in the AGC, but maybe it is not much more than the displays...


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 12:14:10 PM
Really this scenario?: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=491.msg24290#msg24290 Then you must have renamed it before the quicksave...

When I load that scenario the clock is perfect on time. 1 second already make a state vector error of 1650 m (velocity of the LM), so in that case the landing site might be that much off, too. There are also some weird things going on and I now think that the 1201/1202 alarms have actual bad effects. If I deactivate the JoystickTimestep function so that no ACA and TTCA signals are changed then the scenario you posted actually works and goes into P65, just above the surface. Still 1202 alarms, but much better. So it's not just displays and the whole LPD function might be handicapped because of it, too. Not sure what the priority of the LPD is in the AGC, but maybe it is not much more than the displays...

Actually no not that one.  http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=491.msg24218#msg24218

Let me run through that one

EDIT:  Yet again P64 to the surface :(  I am clueless as to why it will not work for me.  About -350 dH in the N68 and still P64 to the surface, though much softer this time.  Also running a N36 shows the LCG 2 seconds behind the PAMFD clock and they agreed before starting P63.

I am going to try a clock and SV update prior to P63 and see what happens.


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 12:53:09 PM
Where are you landing/crashing? This scenario should get you very close to the Tranquility Base texture.


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 12:54:49 PM
Where are you landing/crashing? This scenario should get you very close to the Tranquility Base texture.

Visualizing as you approach it, I am to the left and just beyond the texture.

EDIT:  And ran through again, updated SV and clock prior to PDI and still same results.


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 01:20:47 PM
Visualizing as you approach it, I am to the left and just beyond the texture.

Yes, that's where it is getting me without velocity updates, too. Just outside of the texture, maybe a hundred meters to it. Close enough so that an actual LPD would get you right to the center of it. So that is at least consistent between our attempts. Are you getting 60 fps? Maybe it's somehow related to that.

Your scenario there indeed crashes, too. Looks very much like a clock problem. If that is the case then without velocity data the range data could be not enough. The state vector could be so degraded that the altitude rate is so bad that knowledge about the altitude is not enough. There are still some issues with it, but I'll commit the LR velocity updates. That won't fix this weird clock issue (which I think now might be your problem) but the LM should be able to deal better with it.

Quote
EDIT:  And ran through again, updated SV and clock prior to PDI and still same results.

How accurate is the clock at landing? Also, your LGC state vector itself should probably be good. Just the clock seems to be the issue.


Title: Re: LM status...
Post by: jalexb88 on September 11, 2016, 01:23:21 PM
Hmm just tried the landing again and all is good on my side, transits to P65 and smooth landing. Sounds like an issue I had before the latest rendition of the LR. rcflyinghokie, are you sure that you've recompiled/downloaded the latest modules?


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 01:26:12 PM
Hmm just tried the landing again and all is good on my side, transits to P65 and smooth landing. Sounds like an issue I had before the latest rendition of the LR. rcflyinghokie, are you sure that you've recompiled/downloaded the latest modules?

You seem to be the only other person who also had success with auto landings. Have you build the latest updates yourself or downloaded it? I doubt it's possible, but at this point...

Also @rcflyinghokie: The LR velocity update is on the way, so better use those.  :ThumbsUp432: With the correct switch settings the LR information will be displayed on the tape meter and X-Pointer.


Title: Re: LM status...
Post by: jalexb88 on September 11, 2016, 01:34:35 PM
I just transfer the updates directly into my VS2015 and then rebuild the modules.


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 02:08:35 PM
Hmm just tried the landing again and all is good on my side, transits to P65 and smooth landing. Sounds like an issue I had before the latest rendition of the LR. rcflyinghokie, are you sure that you've recompiled/downloaded the latest modules?

Currently using Build 215.  I see 216 was uploaded 45 mins ago though.

Also @rcflyinghokie: The LR velocity update is on the way, so better use those.  :ThumbsUp432: With the correct switch settings the LR information will be displayed on the tape meter and X-Pointer.

Awesome!  I think for completion I am going to completely clear out my NASSP folder and just apply the current build see if anything is causing problems.

EDIT:  May seem silly, but gotta check, prior to P63, I am supposed to have R and Y at 0 correct? 


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 02:24:59 PM
I just transfer the updates directly into my VS2015 and then rebuild the modules.

I actually do not know how to do that :(  I would love to learn!

EDIT:  And to add, complete fresh "install" of NASSP and its now landing on the right side of the texture same exact thing, P64 to the ground.


Title: Re: LM status...
Post by: indy91 on September 11, 2016, 03:43:15 PM
EDIT:  May seem silly, but gotta check, prior to P63, I am supposed to have R and Y at 0 correct?  

Apollo 11 started heads down (so 180° yaw) to do a ground track check. That's where Armstrong already noticed they are a little bit long. They then yawed to 0° at 4 minutes from PDI. The LGC would enforce this attitude a few minutes later anyway. The LR can now deal with it, heads down the LR will point up and not measure range. So just like on the real Apollo 11 mission, once you have yawed to 0° the LR should get altitude data pretty fast.

I actually do not know how to do that :(  I would love to learn!

Then you need to get the NASSP repository with git. Here is the tutorial dseagrav wrote: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0 You can get Visual Studio 2015 Community for free.

Quote
EDIT:  And to add, complete fresh "install" of NASSP and its now landing on the right side of the texture same exact thing, P64 to the ground.

Yep, with the velocity data it usually leads to to the right, too. But the altitude doesn't seem to work out for you...

Unrelated to this all, @thewonderidiot might have found the fixes of all fixes. So potentially say goodbye to the 1201 and 1202 alarms.


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 05:16:43 PM
Then you need to get the NASSP repository with git. Here is the tutorial dseagrav wrote: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0 You can get Visual Studio 2015 Community for free.

I have that set up, now after fetching the master how do I rebuild the modules as jalex stated?  I remember some of this from the SVN back in the day but its been years.

EDIT:  I think I figured it out, memory served me well :)


Title: Re: LM status...
Post by: rcflyinghokie on September 11, 2016, 06:06:54 PM
I am coming down to almost a solid hover now but still wont switch to P65.  Also when I get LR (ALT light out) it is usually around -400 and increasing, could this be a reason my altitude is screwy and no P65?

EDIT:  Well I just ran it again, no changes to my procedure, and I got a P65 and a landing :)


Title: Re: LM status...
Post by: eddievhfan1984 on September 12, 2016, 04:28:23 AM
I am coming down to almost a solid hover now but still wont switch to P65.  Also when I get LR (ALT light out) it is usually around -400 and increasing, could this be a reason my altitude is screwy and no P65?

EDIT:  Well I just ran it again, no changes to my procedure, and I got a P65 and a landing :)

Did you incorporate LR updates with V71E? Because if you did and the delta-H is still increasing, then guidance is not properly converging, and we got another issue on our hands...


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 05:39:25 AM
V57 not V71. Guidance seems to always converge very well for me.

I've taken a first look at the LPD issue. When the displays switches from 99 to 00 there is still 130 seconds left in P64. You should be able to use LPD until 30 seconds left in P64. I have checked the padloaded value for this, TCGFAPPR, about 4 times now. Here is the routine calculating the display for TR:

(http://i.imgur.com/YDb4cYv.png)

TTT_CGPF is the aforementioned padload, TTT is the negative time-to-go in the current phase and DDT_REDES is the "time interval to assure at least one computation of guidance coordinates after the last site redesignation."

The equations above are just for the DSKY, but I have the feeling something is messing up with one of them. I'll looking into the actual LPD guidance equations.


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 06:24:54 AM
I never commited a L-Register overflow commit to Virtual AGC from a few weeks ago. Now during LPD it at least seems to do the countdown, but I still haven't had success with actual landing point redesignation. maybe it's looking for a specific count from the ACA counter, so I'll try with a joystick. It's possible that it doesn't like full deflection, which commands RCS hardover.

I also still slightly relucantly commited the corrected cycle count for multi-MCT instructions. This gives the AGC a lot more cycles and the 1201 and 1202 alarms are gone. This will have major consequences for about every complex operation of the AGC. Potentially rendezvous calculations are much faster now.


Title: Re: LM status...
Post by: rcflyinghokie on September 12, 2016, 06:41:26 AM

Did you incorporate LR updates with V71E? Because if you did and the delta-H is still increasing, then guidance is not properly converging, and we got another issue on our hands...

Yes I used the V57 to incorporate landing data.  It is starting high for me but it converges nicely during the rest of the P63/64.  To be clear though my landings are now working.


Title: Re: LM status...
Post by: thewonderidiot on September 12, 2016, 11:07:32 AM
I never commited a L-Register overflow commit to Virtual AGC from a few weeks ago. Now during LPD it at least seems to do the countdown, but I still haven't had success with actual landing point redesignation. maybe it's looking for a specific count from the ACA counter, so I'll try with a joystick. It's possible that it doesn't like full deflection, which commands RCS hardover.

Awesome! I really wasn't expecting that one to have any pragmatic effect. For the LPD, are you currently generating RUPT10? I can't find the code for it.


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 11:19:52 AM
Yes, that sounds like something that could be missing. But I wonder why it isn't necessary for normal ACA operations and why I can't find any mention of HANDRUPT for the CM either...


Title: Re: LM status...
Post by: thewonderidiot on September 12, 2016, 11:34:53 AM
I don't think the CM uses that interrupt at all. In the LM, it's just used for the redesignator, and it's ISR exits right away if P64 isn't running.


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 11:39:12 AM
The AOH says a HANDRUPT (or RUPT10) is initated whenever the ACA is moved out of detent. That's probably going to make the LPD work. Or it will generate too many interrupts... but we will see.


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 12:01:21 PM
Just as I expected. LPD is working now, but if I hold the ACA out of detent then I get a 1203 alarm. Probably because a HANDRUPT is generated each Timestep. So it should be either generate a HANDRUPT as fast as ACA data can be read (max. 30 times a second?) or just once when ever the ACA is moved out of detent. But all in all it's working pretty good!


Title: Re: LM status...
Post by: thewonderidiot on September 12, 2016, 12:07:46 PM
Cool! I can see where the rupt is generated (top right of A17-1) but there's a lot of gates and latches separating it from the count pulses that I don't understand yet. I'll dig into them when I get home tonight.


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 01:11:46 PM
When a RUPT10 is only initiated if the ACA is moved out of detent and not continuosly out of detent, then the 1203 alarm isn't happening but the LPD command is still processed. I have commited that version now, until you maybe come up with a more realistic/intelligent solution. But LPD works now! Everyone have fun with your precision auto landings. Realistic throttling of the DPS so that there are no oscillations in P66 is already on my to-do list. But first I want the X-Pointers and the altitude meters to get LGC signals. Just have to find out what is trigger bit 6 in input channel 30...

There is one strange thing, sometimes when in P65 the LM just stops descending and starts going up. It looks like the DPS is not getting any throttle commands anymore. Maybe something is unreliable there.


Title: Re: LM status...
Post by: eddievhfan1984 on September 12, 2016, 03:36:00 PM
Yeah, I tried to do manual switching to P66, but it did a weird thing where it switched to a high upward vertical speed and wouldn't respond to ROD commands.

And I'm also wondering about the RR. It doesn't seem to actively track what it locks onto, and P20 isn't worth crap for me. :P I was wondering if it was because the LGC may derive initial pointing commands, then use the AUTO TRACK circuitry to keep the antenna pointed at the CSM transponder, not bothering with angle tracking itself...


Title: Re: LM status...
Post by: indy91 on September 12, 2016, 03:51:16 PM
Yeah, I'll have to look into it. There is an input channel bit that I don't quite understand, it's possible that the DECA or something else should send a signal to the LGC that it is thrusting. Or something like hat.

For the RR, the trunnion and shaft registers actually share a location with the velocities for the X-Pointers (like the auto optics and TVC share registers in the CSM) and I have not seen a single signal come through. So maybe there is something wrong with these commands in general. If I get the LGC X-Pointer commands to work then I might find a problem with the RR CDUs, too.


Title: Re: LM status...
Post by: thewonderidiot on September 12, 2016, 09:07:30 PM
Alright, so what's going on with RUPT10: there's three different possible sources of it, enabled under software control. They are:

Trap 31-A (enabled by resetting CH13 bit 12) : Causes a RUPT10 when any of CH31 bits 1-6 are set.
Trap 31-B (enabled by resetting CH13 bit 13) : Causes a RUPT10 when any of CH31 bits 7-12 are set.
Trap 32 (enabled by resetting CH13 bit 14) : Causes a RUPT10 when any of CH32 bits 1-10 are set.

Looks like the LPD is on 31-A, and that's the only one that I can obviously see is being used. So your "once on moving out of detent" sounds like it should work fine.


Title: Re: LM status...
Post by: jalexb88 on September 12, 2016, 10:55:19 PM
Here's an old doc I found from a very early post on this thread (c. 2006) on ACA input processing. You guys may of already had it but thought I'd share anyway as it has some stuff on LPD and ROD.

http://klabs.org/mapld04/papers/p/p202_portillo_p.pdf


Title: Re: LM status...
Post by: rcflyinghokie on September 13, 2016, 07:19:13 AM
Just wanted to thank everyone putting up with me not being able to get that P65.  I can now get it every time consistently.  A few things I have noticed, not sure if they are bugs or intentional, but...

1) The P68 landing confirmation and the PAMFD and orbiter position disagree consistently with each landing (LGC reading 0.69/23.43 and PAMFD .71/23.33 on my last attempt.)
2) If I recall, ideally the FDAI should read 000 at the landing site, I land consistently with 10 degrees left yaw.
3) The computer always brings me down (viewed from approach) to the right and long from the tranquility base texture.
4) Lunar contact light comes on when the pads hit and not the probes.

Just a few things I have noticed.  Also, it may not be a bad idea to add indicators for the engine start/stop pushbuttons and what position they are in.  Especially for a P12, I have no idea if I am in stop or start or need to reset etc.  Thanks again for everyone helping me finally get that P65!


Title: Re: LM status...
Post by: indy91 on September 13, 2016, 07:52:10 AM
1) The P68 landing confirmation and the PAMFD and orbiter position disagree consistently with each landing (LGC reading 0.69/23.43 and PAMFD .71/23.33 on my last attempt.)

Not good. Then the strange clock problem is still there. 0.1° in longitude is about 3km, I get max. 0.02° difference in both longitude and latitude. That is only a few hundred meters and it is very possible that the P63 scenario doesn't have a great alignment. But it does have a fresh state vector.

Quote
2) If I recall, ideally the FDAI should read 000 at the landing site, I land consistently with 10 degrees left yaw.

Apollo 11 landed with 13° yaw, not sure about other missions. If I do fairly aggressive LPD commands then I get up to 20°. No problem, the ascent stage will deal with that before pitchover.

Quote
3) The computer always brings me down (viewed from approach) to the right and long from the tranquility base texture.

If I don't give any LPD commands then it usually lands slightly to the right and just outside of the texture. With LPD commands I can land exactly in the center. So this is caused by the same clock problem you had.

Quote
4) Lunar contact light comes on when the pads hit and not the probes.

Yep, the contact light is currently just the standard Orbiter ground contact function. It should be altitude or even attitude dependant.

Quote
Also, it may not be a bad idea to add indicators for the engine start/stop pushbuttons and what position they are in.  Especially for a P12, I have no idea if I am in stop or start or need to reset etc.

The easiest way would be a text message displayed a few seconds after one of the two buttons is pressed. But ideally we would need something on the panel.


Title: Re: LM status...
Post by: rcflyinghokie on September 13, 2016, 10:40:25 AM
Not good. Then the strange clock problem is still there. 0.1° in longitude is about 3km, I get max. 0.02° difference in both longitude and latitude. That is only a few hundred meters and it is very possible that the P63 scenario doesn't have a great alignment. But it does have a fresh state vector.

I even tried it updating my clock and SV prior to calling P63 with the same results.  Could this be an issue on my end?

EDIT: Side note, what thrust are we using in the LM.  9870lbs?  And isn't this 94% of 10500 not 92.5%?


Title: Re: LM status...
Post by: indy91 on September 13, 2016, 12:16:16 PM
Are you getting steady 60 FPS? Maybe it is a problem at scenario loading? But it seems the clock is getting worse over time for you...

The currently used thrust is 10500lbs as 100%.


Title: Re: LM status...
Post by: rcflyinghokie on September 13, 2016, 12:44:02 PM
Are you getting steady 60 FPS? Maybe it is a problem at scenario loading? But it seems the clock is getting worse over time for you...

The currently used thrust is 10500lbs as 100%.

My framerate is very smooth, how can I bring up my FPS in orbiter?

And during P63 throttle up are we using 92.5% or 94%.  I am just confused because I remember seeing 92.5% often.


Title: Re: LM status...
Post by: rcflyinghokie on September 13, 2016, 01:25:37 PM
Also if it helps, here is my scn post landing with the P68 running.


Title: Re: LM status...
Post by: indy91 on September 14, 2016, 04:21:24 AM
The clock is almost 3 seconds off in that scenario. With that difference it is no wonder the LGC can't convert state vector to lat+long and doesn't land at the planned landing site. It's so strange that you seem to be the only one this happening for.

My framerate is very smooth, how can I bring up my FPS in orbiter?

Press F in Orbiter to show resolution and frame rate.

I just brought this up because I noticed when I tested the LVDC with my crappy netbook (about 30 fps during the launch) that the transients during stage separation are much worse, which degrades the LVDC state vector. Orbiter freezes for a split second, which the accelerometers don't seem to like. I thought maybe something like that could be going on. It doesn't seem to be only a problem with scenario loading, because as you say, you have updated the clock and then after the landing the clock is again off. I really have no clue why the LGC clock would do that just for you. Are you now building NASSP yourself with Visual Studio? What I thought was that the github builds are somehow bad, but I really have no idea.


Title: Re: LM status...
Post by: rcflyinghokie on September 14, 2016, 06:54:30 AM
I just brought this up because I noticed when I tested the LVDC with my crappy netbook (about 30 fps during the launch) that the transients during stage separation are much worse, which degrades the LVDC state vector. Orbiter freezes for a split second, which the accelerometers don't seem to like. I thought maybe something like that could be going on. It doesn't seem to be only a problem with scenario loading, because as you say, you have updated the clock and then after the landing the clock is again off. I really have no clue why the LGC clock would do that just for you. Are you now building NASSP yourself with Visual Studio? What I thought was that the github builds are somehow bad, but I really have no idea.

I am running orbiter on a pretty fast machine (i5 3570K OC to 4.2GHz, 16 GB RAM, GTX 970 GPU, running Windows 10 x64)  and I am now building with VS yes.  Maybe I have a bad scn file to start?  Here is my copy.

EDIT:  When I load this scn I get about 17FPS for the first 30 seconds or so then I am sitting around 175-200.  I am going to try two things for debugging here:  I am going to run the scn start to finish with no updates to SV or clock, then I am going to do an LGC clock update and run it again and post the landing quicksaves.


Title: Re: LM status...
Post by: indy91 on September 14, 2016, 09:10:10 AM
So your PC is about as powerful as mine, even a little bit better.

I get the low fps on startup sometimes, usually it goes away, sometimes I have to reload. About your fps, maybe the Virtual AGC (or the multithreading for time acceleration) can't handle the variable frame rate. Have you tried it with vertical sync on, so not diasbled vertical sync. on the Video tab of the Orbiter Launchpad?


Title: Re: LM status...
Post by: eddievhfan1984 on September 14, 2016, 09:38:53 AM
I sometimes get the same thing myself, but usually after switching to external view and back again, it moves on up to full framerate (I use VSync), and I can get 20x with multithreaded vAGC (30x on good days).


Title: Re: LM status...
Post by: rcflyinghokie on September 14, 2016, 09:45:55 AM
So your PC is about as powerful as mine, even a little bit better.

I get the low fps on startup sometimes, usually it goes away, sometimes I have to reload. About your fps, maybe the Virtual AGC (or the multithreading for time acceleration) can't handle the variable frame rate. Have you tried it with vertical sync on, so not diasbled vertical sync. on the Video tab of the Orbiter Launchpad?

I only get the low frame rate for a little bit then it vanishes completely, even during time acceleration up to about 30x.  I will mess with the Vsync though and see.

Also as I said, here are my two scn files one with clock and SV updates the other with no updates.  Looks like they landed in the same area with the same discrepancy :(  Take a look and see what you can find.


Title: Re: LM status...
Post by: rcflyinghokie on September 14, 2016, 10:51:09 AM
I sometimes get the same thing myself, but usually after switching to external view and back again, it moves on up to full framerate (I use VSync), and I can get 20x with multithreaded vAGC (30x on good days).

This is what I do as well,. I do have my d3d9 settings maxed out but still see 200 fps in the lm.  Are you guys getting more fps than this?


Title: Re: LM status...
Post by: indy91 on September 14, 2016, 12:07:24 PM
With VSync I get always 60 fps, without it depends on the panel I am looking at. Sometimes 100 fps, outside view 1000 fps. But that doesn't really matter anyway, my monitor only can display 60 fps. So I pretty much always use VSync for everything. I actually tried a descent without VSync. I still was able to land where I wanted to, but I had the feeling the LM wanting to go a little bit longer than I wanted and when I reloaded that landed scenario then the clock was a little bit off. Maybe 1.5 seconds. Not sure if that isn't happening with VSync, too. Have you tried it with the steady 60fps (or whatever your monitor allows) yet?


Title: Re: LM status...
Post by: rcflyinghokie on September 14, 2016, 01:42:04 PM
With VSync I get always 60 fps, without it depends on the panel I am looking at. Sometimes 100 fps, outside view 1000 fps. But that doesn't really matter anyway, my monitor only can display 60 fps. So I pretty much always use VSync for everything. I actually tried a descent without VSync. I still was able to land where I wanted to, but I had the feeling the LM wanting to go a little bit longer than I wanted and when I reloaded that landed scenario then the clock was a little bit off. Maybe 1.5 seconds. Not sure if that isn't happening with VSync, too. Have you tried it with the steady 60fps (or whatever your monitor allows) yet?

I think I get either 50 or 60 I can't remember from my monitor.  I will try with the vsync when I get home and see if it changes anything.  The two scn files I posted I did not check the availability or clock but once again the landings were off from the actual position that tells me that whatever is happening occurs during p63 with the clock, we will see if the frames or orbiter settings are the culprit.

EDIT:  Lands in the texture now, but the P68 is still off it seems, I have posted the scn
EDIT 2:  Did another with clock and SV updates prior to P63 and still the site is off, any other ideas? (posted another scn)  It looks like the clock is fine when I land, but the LAT LON are still incorrect in a P68.  Even if I do a SV update on the surface its still incorrect.


Title: Re: LM status...
Post by: indy91 on September 15, 2016, 02:47:19 AM
That's so much better! Did you give any LPD commands? In fact, that's pretty much exactly the coordinates I am always getting, too. Remember, 0.02° is only 600 meters on the Moon. And I really think most of that difference comes from a not-so-perfect alignment, which in Average G can cause these differences. After they solved the landing accuracy problem with Apollo 12 the biggest issue for accuracy until the end of the Apollo program was the AOT and the IMU alignment. It just isn't as accurate as the sextant in the CM. They even thought about upgrading the AOT, but that never happened. So, the few kilometers difference in P68 you were getting before were worrisome, but 0.02° is ok. Especially for Apollo 11. So it seems the steady frame rate is pretty healthy for the Virtual AGC.


Title: Re: LM status...
Post by: rcflyinghokie on September 15, 2016, 06:50:02 AM
That's so much better! Did you give any LPD commands? In fact, that's pretty much exactly the coordinates I am always getting, too. Remember, 0.02° is only 600 meters on the Moon. And I really think most of that difference comes from a not-so-perfect alignment, which in Average G can cause these differences. After they solved the landing accuracy problem with Apollo 12 the biggest issue for accuracy until the end of the Apollo program was the AOT and the IMU alignment. It just isn't as accurate as the sextant in the CM. They even thought about upgrading the AOT, but that never happened. So, the few kilometers difference in P68 you were getting before were worrisome, but 0.02° is ok. Especially for Apollo 11. So it seems the steady frame rate is pretty healthy for the Virtual AGC.

This was an organic autoland, let P65 do it's job.  I do want to play with the ROD and LPD commands, how do we use these with orbiter?

And yeah it looks like that framerate did the trick, might not be a bad idea to suggest for new users to change it during initial setup :)


Title: Re: LM status...
Post by: indy91 on September 15, 2016, 07:15:47 AM
The LPD commands are simply roll and pitch with the ACA. If you don't have a joystick I would recommend disabling hardover commands with the left ACA/4 Jet switch. That way you don't generate RCS commands when you just want to do LPD commands. The ROD switch is implemented as it was before for the old LEM autopilot. "-" for "increase descent rate" and "=" for "decrease descent rate". But P66 isn't really working too good yet.


Title: Re: LM status...
Post by: vrouleau on September 15, 2016, 07:34:38 AM
I'd like to start testing landing. I am looking for DOI procedure. It's not documented in "G&C Checklist.doc". Is the procedure in the non-VirtualAGC "Apollo 11 Flightplan Basic.xls" (P17 & P18) for DOI still applicable? Or should I read from original DOI procedure? Links? I remember testing LM activation using the real Apollo 15 documents 2 years ago. Was there any LM AGC aligment done post undocking and pre-p63 with the AOT or did they rely only on gimbal torquing during LM powerup?

Could someone provide me with a .scn post-undock and pre-P63 that resulted in successful landing for me to try it out please. I'like to test it


Title: Re: LM status...
Post by: indy91 on September 15, 2016, 07:44:11 AM
I'd like to start testing landing. I am looking for DOI procedure. It's not documented in "G&C Checklist.doc". Is the procedure in the non-VirtualAGC "Apollo 11 Flightplan Basic.xls" (P17 & P18) for DOI still applicable? Or should I read from original DOI procedure? Links? I remember testing LM activation using the real Apollo 15 documents 2 years ago.

I have a DOI calculation function in the RTCC MFD, but the LM update for the MFD hasn't been released yet. I can have that ready today.

Quote
Was there any LM AGC aligment done post undocking and pre-p63 with the AOT or did they rely only on gimbal torquing during LM powerup?

They did one on Apollo 11 P52 aligment not long before DOI. Later missions spent a revolution longer undocked from the CSM, not sure if they did another P52 there.

Quote
Could someone provide me with a .scn post-undock and pre-P63 that resulted in successful landing for me to try it out please. I'like to test it

Here the P63 test scenario I have been using and my scenario just after undocking. A bunch of things have been changed in the LM after that undocking scenario was created, but it should be ok.


Title: Re: LM status...
Post by: rcflyinghokie on September 15, 2016, 07:44:47 AM
The LPD commands are simply roll and pitch with the ACA. If you don't have a joystick I would recommend disabling hardover commands with the left ACA/4 Jet switch. That way you don't generate RCS commands when you just want to do LPD commands. The ROD switch is implemented as it was before for the old LEM autopilot. "-" for "increase descent rate" and "=" for "decrease descent rate". But P66 isn't really working too good yet.

I do have a joystick, but I have it disabled because the rudder axis sensitivity deadband was so extreme in orbiter that i would bump the base and it would fire, with no sensitivity adjustment I could find in orbiter I just reverted to numpad.  Is there any way to adjust the deadband, in orbiter?  (Logitech extreme 3d pro)  If not I will give the numpad a try.


Title: Re: LM status...
Post by: rcflyinghokie on September 15, 2016, 07:46:20 AM
I have a DOI calculation function in the RTCC MFD, but the LM update for the MFD hasn't been released yet. I can have that ready today.

Speaking of, the RTCC cannot calculate a SV for the LM right now it seems.  I know its redundant with the PAMFD still working but just for sake of completion.


Title: Re: LM status...
Post by: jalexb88 on September 15, 2016, 07:59:07 AM
Speaking of, the RTCC cannot calculate a SV for the LM right now it seems.  I know its redundant with the PAMFD still working but just for sake of completion.

Hmm...my LM SV updates with RTCC MFD is working fine. Are you selecting "Eagle" and LM slot?


Title: Re: LM status...
Post by: rcflyinghokie on September 15, 2016, 08:40:33 AM
Hmm...my LM SV updates with RTCC MFD is working fine. Are you selecting "Eagle" and LM slot?

I am, and nothing calculates, all zeros

EDIT: formatting and I am a moron :)  I didn't select Eagle :P
EDIT 2:  And are the slots from the RTCC transposed for the LM?  In other words, if I select LM slot is it putting it in my primary SV slot in the LM, where in the CSM it would put it in the secondary slot?


Title: Re: LM status...
Post by: jalexb88 on September 15, 2016, 09:50:25 AM
I am, and nothing calculates, all zeros

EDIT: formatting and I am a moron :)  I didn't select Eagle :P
EDIT 2:  And are the slots from the RTCC transposed for the LM?  In other words, if I select LM slot is it putting it in my primary SV slot in the LM, where in the CSM it would put it in the secondary slot?

Ive felt that way before... :ROTFL3453:   In the CSM the primary is CSM, secondary LM.  In the LM its the other way around, primary LM and secondary CSM. 


Title: Re: LM status...
Post by: indy91 on September 15, 2016, 09:54:52 AM
EDIT 2:  And are the slots from the RTCC transposed for the LM?  In other words, if I select LM slot is it putting it in my primary SV slot in the LM, where in the CSM it would put it in the secondary slot?

This had confused me quite a bit, too. But it works like this: The slots in the erasable memory are the same as in the CMC, but for extended verbs such as V82 you use option 1 to get the parameters for yourself (LM). So the option LM on the RTCC MFD uplinks to the LM slot. For the astronauts it doesn't make a difference in CMC or LGC, the same option for an extended verb etc. wil be the information about YOUR vehicle.

Ive felt that way before... :ROTFL3453:   In the CSM the primary is CSM, secondary LM.  In the LM its the other way around, primary LM and secondary CSM.  

Yes, but in the erasable memory the CSM and LM state vectors have the same order as in the CMC.


Title: Re: LM status...
Post by: rcflyinghokie on September 15, 2016, 10:04:07 AM
This had confused me quite a bit, too. But it works like this: The slots in the erasable memory are the same as in the CMC, but for extended verbs such as V82 you use option 1 to get the parameters for yourself (LM). So the option LM on the RTCC MFD uplinks to the LM slot. For the astronauts it doesn't make a difference in CMC or LGC, the same option for an extended verb etc. wil be the information about YOUR vehicle.

Brilliant in its simplicity :) 

And by the way the LPD worked nicely for me even with the numpad, still wants to land to the right but I have it much more centered in the texture now :)  Now will the RTCC be calculating necessary orbits for the CSM and P12 times for lunar liftoff and rendezvous?


Title: Re: LM status...
Post by: indy91 on September 15, 2016, 10:08:25 AM
And by the way the LPD worked nicely for me even with the numpad, still wants to land to the right but I have it much more centered in the texture now :)

It wants to go a little bit right for me, too. No problem in LPD.

Quote
Now will the RTCC be calculating necessary orbits for the CSM and P12 times for lunar liftoff and rendezvous?

Oh, yes. In fact I have done these calculations for another addon already: http://www.orbithangar.com/searchid.php?ID=5899 That plugin is written in lua, but I also have a C++ version of it that never made it to release state. So I will be able to reuse quite a bit of code for lunar liftoff times.



Title: Re: LM status...
Post by: eddievhfan1984 on September 15, 2016, 10:38:48 AM
Just tried the new build, very good. I'm working with the LPD now, but I feel like it puts the LS too long from the texture—when the normal 47° approach angle is set up, it's always too far away, and it seems I can't redesignate it down quickly enough. Also, there's a behavior in P66 that isn't correctly modeled, IMO. When you set the PGNS mode switch back to AUTO, it should control attitude to null surface velocities. It's hard for me to monitor everything simultaneously with our current panels, and by the time I've got a handle (somewhat) on descent rate, I find that I'm going backwards because the LGC held the inertial attitude for the LPD mode the whole time, even in AUTO.


Title: Re: LM status...
Post by: indy91 on September 15, 2016, 10:54:47 AM
Luminary099 doesn't have the surface velocity nulling capability in P66. After Apollo 11 P67 (fully manual landing program) was deleted and they added a few manual and automatic capabilities to P66.  Situational awareness in P66 is challenging and I find it also difficult to tell which descent rate I currently have. That should get better once the DPS has throttle lag.

I also usually get the long targeted landing site and then have to do a steep descent. I guess the best technique is to do a few LPD commands very early in P64 which will make the LM pitch up even more at first. But once the LM is on track again it should be easier to land in the middle of the texture. The targets for P63 and P64 are steeper for Apollo 11 than Apollo 13 according to the both padloads. It will be interesting to see how much different the landing is with these different targets and Luminary131.


Title: Re: LM status...
Post by: vrouleau on September 15, 2016, 10:02:42 PM
For the range, have you tested with

      //Altitude
      alt = lem->GetAltitude(ALTMODE_GROUND) - dh;

instead of

      //Altitude
      alt = lem->GetAltitude() - dh;

To get the altitude from the ground for the current mesh to get a more precise location


Title: Re: LM status...
Post by: indy91 on September 16, 2016, 03:51:35 AM
Yeah, I have already tried that for the Orbiter 2016 version. Are we allowed to commit to that branch now, dseagrav? :)

EDIT: I have found the main source of the landing inaccuracy. I have blindly followed the Apollo 12 LM Activation, which has this line:

V21N01E, 1462E, 576E

EMEM1462 is NBDZ, a gyro bias drift which we really don't want because our IMU is basically perfect. Not sure why that line is in the Activation Checklist, usually this parameter in padloded. And the Apollo 14 Activation Checklist doesn't have it. So please remove the line EME1462 576 from the LM part of the scenario. The parameter shifts the alignment for about 1°(!) every few minutes.

Also, if you have an older scenario (e.g. the undocking scenario) then there are still some typos in the padload, which I have corrected in this commit: https://github.com/dseagrav/NASSP/commit/0e3e3fc5cd305f03ec7d3aba13c71231ddecdbdc The undocking scenario has a terrible alignment by the way. I think I'll add the V42 fine alignment to the PAMFD page. Then you basically don't need to do a P52 anymore.


Title: Re: LM status...
Post by: dseagrav on September 16, 2016, 08:13:14 AM
Yeah, I have already tried that for the Orbiter 2016 version. Are we allowed to commit to that branch now, dseagrav? :)
Yes, I posted in the 2016 thread that it's been updated and all should be well.

When a push happens and appveyor does its thing, it has to download a little file from my server that has the relevant Orbiter SDK (and OrbiterSound SDK) for that branch in order to build it. I had to make a new version of that which had the 2016 SDK instead of the 2015 beta stuff.



Title: Re: LM status...
Post by: indy91 on September 16, 2016, 08:40:14 AM
Then I'll push my RTCC MFD updates, the Landing Radar for Orbiter 2016 and a Moon config that doesn't make it all black.

There is something strange going on with the IMUs. Something seems to be always drifting, even if I remove the gyro bias drift from the LM erasable memory. If I continuosly compare the CSM and LM IMU then I never get them to agree.


Title: Re: LM status...
Post by: dseagrav on September 16, 2016, 09:35:08 AM
I pushed a change to the LM that adds a means of updating CG/PMI/etc as a result of fuel usage. It's in LEM.cpp, look for the tag DS20160916. Someone else who understands all this needs to fill out the relevant computation of new CG/PMI/etc and put it where indicated.


Title: Re: LM status...
Post by: indy91 on September 16, 2016, 09:47:21 AM
Great stuff! There are two good sources for the required data. First the "CSM/LM Spacecraft Operational Data Book, Volume III: Mass Properties", which has data for specific missons and all the vessels (e.g. CSM-106). Or we directly use the numbers from "GSOP section 3: Digital Autopilot" so that the PMI and CoG of our simulated LM are exactly the numbers that the LGC DAP assumes. If we use the numbers from the Operational Data Book then we could even create config files for different parameters for each misison.

EDIT: Ok, for the PMIs I can easily come up with the parameters for total weight, both for the unstaged and staged vessel. The CoG is a little bit more tricky. I guess we should modify all the thruster definitions etc. to be valid for a specific weight, maybe all tanks full. And from that specific weight we can then shift the CoG.


Title: Re: LM status...
Post by: jalexb88 on September 16, 2016, 12:41:49 PM
I tried the landing in orbiter 2016, worked quite well and what an incredible view with the new elevation data! I decided to do the P63 ignition up to the landing in sync with this YouTube video: https://www.youtube.com/watch?v=RONIax0_1ec and it was pretty amazing to see "boot hill" go by my orbiter window at the exact same time as on the video.

I did notice that something is off about our DPS. I did the exact same ignition time in sim and the video, and as discussed before the real throttle down was 1 minute earlier than in the sim. What is weird though is that despite this, if I try and follow what they did in the real world and land at the same time they did, I have MORE fuel then in the video ie. when they had their 60 second callout for fuel remaining, I was still at 10%! If I throttled down later I should have less, no!? I'm thinking maybe if we established that our mass and thrust are ok, then maybe its the fuel flow rate that is too low, with the resulting heavier weight down the line we need more time at high thrust before LGC is happy with throttling down, and would explain why we still have 10 % fuel at the time of the "60 seconds" call which would be about ~2-3 percent.


Title: Re: LM status...
Post by: indy91 on September 16, 2016, 12:51:03 PM
I did notice that something is off about our DPS. I did the exact same ignition time in sim and the video, and as discussed before the real throttle down was 1 minute earlier than in the sim. What is weird though is that despite this, if I try and follow what they did in the real world and land at the same time they did, I have MORE fuel then in the video ie. when they had their 60 second callout for fuel remaining, I was still at 10%! If I throttled down later I should have less, no!? I'm thinking maybe if we established that our mass and thrust are ok, then maybe its the fuel flow rate that is too low, with the resulting heavier weight down the line we need more time at high thrust before LGC is happy with throttling down, and would explain why we still have 10 % fuel at the time of the "60 seconds" call which would be about ~2-3 percent.

Two things will cause this:

-I didn't perform the DOI with the LM, so it still has 100% fuel in my PDI scenario. I did this before I was even able to performs a P40 DPS maneuver with the LM, all I really wanted to do was try the P63 Ignition Algorithm.
-Variable ISP of the DPS. The 92.5% throttle setting is the most fuel efficient, at 10% it looses a few seconds of specific impulse. I think our DPS is currently to efficient all around. I know the exact numbers for the ISP, so I can easily add that.


Title: Re: LM status...
Post by: rcflyinghokie on September 16, 2016, 06:34:02 PM
Speaking of DOI, the post undocking scn throws a alarm code saying the alignment is not good when I try the p40.  Wasn't it already aligned using the docked align?


Title: Re: LM status...
Post by: eddievhfan1984 on September 16, 2016, 06:47:14 PM
Which alarm code?


Title: Re: LM status...
Post by: rcflyinghokie on September 16, 2016, 06:49:16 PM
Which alarm code?

Not at my computer at the moment but I think 220?  I got a program alarm and looked up the code in the gn checklist(also not with me right now)


Title: Re: LM status...
Post by: eddievhfan1984 on September 16, 2016, 08:24:20 PM
Well, if it's a 220, either your REFSMMAT was badly uplinked or the REFSMMAT flag wasn't set after you did the docked alignment.


Title: Re: LM status...
Post by: eddievhfan1984 on September 16, 2016, 08:47:23 PM
So I just pulled off my first ever landing in P67, right inside the mesh. I couldn't get P65 to cut in, and P66 ROD is still awkward as hell. PGNS longitude was within .04° of actual longitude, and latitude was right on.

However, I tried doing a P71 for T1/T2 no-stays, and I guess I waited a few minutes before I selected P68, since when the burn started, PGNS thought I was underneath the Moon and descending (negative H and H-dot), although my 06 60 display before the abort showed PGNS thinking I was above the Moon and climbing, due to holding accelerometer readings after touchdown. What do you guys think?

I'd upload an image or two, but the forum doesn't seem to be liking PNGs right about now...


Title: Re: LM status...
Post by: rcflyinghokie on September 16, 2016, 09:06:13 PM
Well, if it's a 220, either your REFSMMAT was badly uplinked or the REFSMMAT flag wasn't set after you did the docked alignment.

Well I know that :P  My point was I thought the scn that was posted has already done that.  I was just clarifying if it had been done in that scn or if I have to do it again.

EDIT: I will try to set the REFSMMAT flag after the undocking and see what happens, the thing is we dont have P51/52 capability with the AOT yet do we?


Title: Re: LM status...
Post by: eddievhfan1984 on September 16, 2016, 09:23:36 PM
Well, at least in theory for the zero-g P51 and P52, we should. Because in free-flight, the preferred method for alignment with the AOT is to get a star in view, then perform an RCS burst to get it to trace a line just offset from the crosshair. You mark the X when it crosses the vertical datum line, then mark the Y when it crosses the vertical. Using the spiral and cone is intended for ground alignment, IIRC.


Title: Re: LM status...
Post by: indy91 on September 17, 2016, 01:57:34 AM
P51 and P52 are working fine in the LM. You are not moving the reticle in orbit, but the whole LM instead. I've also tried P57 on the moon already, but it's not working too great yet. Probably just procedural problems on my part.

And the problems you are having with the undocking scenario are completely my fault I guess. I had some problems with the alignment. I first didn't want to do the V40, because I didn't understand its behavior (I still don't, really). And I also think I did some mistakes with the REFSMMAT and the flags. I really only was able to fix the alignment after "DOI", which I performed with the scenario editor.  :ROTFL3453: I can post a scenario at the beginning of the LM activation, if you want, that's probably more useful.

The problems with the late P71 could indeed be the several minutes in Average G on the ground. It still reads velocity data from the LR and landed these numbers could throw the state vector off quite a bit. Not sure what the correct altitudes are when altitude and velocitiy data from the LR are not good anymore. Certainly before the landing.

One other thing. @dseagrav and @vrouleau, if you and anyone else want to take over development for Orbiter 2016 and the LM again, that would be great. I would like to focus on the RTCC MFD and Apollo 7+8 again. For the MFD I want to finish making it compatible with the LM, for Apollo 7 I still need to finish the Checklist MFD file. If I have time and nothing to do for CSM or RTCC MFD anymore, then I'll work on the LM again. I still plan to help with the PMI/CoG stuff of course.


Title: Re: LM status...
Post by: rcflyinghokie on September 17, 2016, 07:41:05 AM
P51 and P52 are working fine in the LM. You are not moving the reticle in orbit, but the whole LM instead. I've also tried P57 on the moon already, but it's not working too great yet. Probably just procedural problems on my part.
I honestly hadn't tried them to be honest!  I need to work on my procedure then :)

And the problems you are having with the undocking scenario are completely my fault I guess. I had some problems with the alignment. I first didn't want to do the V40, because I didn't understand its behavior (I still don't, really). And I also think I did some mistakes with the REFSMMAT and the flags. I really only was able to fix the alignment after "DOI", which I performed with the scenario editor.  :ROTFL3453: I can post a scenario at the beginning of the LM activation, if you want, that's probably more useful.
Yeah that V40 stuff is something we might need to come back to, I know I was getting into it in another thread.  And for the pre activation scenario, if you have one ready I won't say no!


Title: Re: LM status...
Post by: indy91 on September 17, 2016, 08:00:49 AM
Here my Apollo 11 scenario at 95h GET, an hour before LM ingress.


Title: Re: LM status...
Post by: jalexb88 on September 17, 2016, 08:07:03 PM
Here's an edited texture for the LEM's FDAI ball, without the red gimbal lock zone. There is only one file for both the CSM & LM FDAI ball so back up the original "FDAI_Ball.dds" in "C:\Orbiter 2016\Textures\ProjectApollo" as you have to put it back to regain the CSM FDAI texture. For testing that's fine but we will need to put provisions for both in the code.


Title: Re: LM status...
Post by: eddievhfan1984 on September 17, 2016, 08:12:20 PM
You can just rename it FDAI_Ball_LM.dds (or something like that), add it to the resource files for the LEM module, then edit LMResource.rc to create a new constant definition for it. That's how I added the FDAI bezels, arrows, and needles for the LM.


Title: Re: LM status...
Post by: rcflyinghokie on September 18, 2016, 08:49:50 PM
Well, at least in theory for the zero-g P51 and P52, we should. Because in free-flight, the preferred method for alignment with the AOT is to get a star in view, then perform an RCS burst to get it to trace a line just offset from the crosshair. You mark the X when it crosses the vertical datum line, then mark the Y when it crosses the vertical. Using the spiral and cone is intended for ground alignment, IIRC.

Does the Q button work for both marking X and Y?


Title: Re: LM status...
Post by: jalexb88 on September 18, 2016, 09:49:21 PM
I believe its Q for X and Y for Y, E for reject.


Title: Re: LM status...
Post by: rcflyinghokie on September 19, 2016, 07:26:05 AM
I believe its Q for X and Y for Y, E for reject.

That did it, finally getting good alignments for the LM :)  I do miss the sextant/telescope though!


Title: Re: LM status...
Post by: eddievhfan1984 on September 19, 2016, 02:02:35 PM
In addition, when doing alignments, you should set your FOV to 72°, since the AOT has a FOV of 60°, and we have all that extra stuff on screen...


Title: Re: LM status...
Post by: rcflyinghokie on September 19, 2016, 04:27:28 PM
In addition, when doing alignments, you should set your FOV to 72°, since the AOT has a FOV of 60°, and we have all that extra stuff on screen...

I will try that.  I am using 60 I believe now and getting about 00007 on the star angle. 


Title: Re: LM status...
Post by: rcflyinghokie on September 20, 2016, 07:14:59 PM
So now I am trying the DOI in the LM after activation and a P52, but after doing a upload of the burn data and a P30, my P40 V to be gained is always very small, 2.9fps in my latest trial.  I also see that in the P30, after inputting my values the V to be gained is also very small after calculating.  Also at -35s, the dsky does not blank.  Any ideas?  I have posted my scn.


Title: Re: LM status...
Post by: jalexb88 on September 20, 2016, 07:52:10 PM
Just tried your scenario, and I had the same result. Did you do a SV update during LEM activation? I then did it in your scenario (Eagle in LM slot, then a Colombia in CSM slot) and a clock update and then it displayed the correct velocities in  P30,P40.


Title: Re: LM status...
Post by: rcflyinghokie on September 20, 2016, 08:41:31 PM
Just tried your scenario, and I had the same result. Did you do a SV update during LEM activation? I then did it in your scenario (Eagle in LM slot, then a Colombia in CSM slot) and a clock update and then it displayed the correct velocities in  P30,P40.

I did do a SV update.  I did not do a Columbia in the CSM slot though.  I also did one during activation and another post undocking with a clock update because I noticed I was a second off.  I also am using PAMFD for the SV with it saying Eagle Moon This on the bottom assuming that puts it in the correct slot.  

EDIT: That did the trick for me. I tried it with just a PAMFD SV and it still yielded the incorrect values.  Then I tried it again with just the RTCC MFD SV of just the LM.  However it seems I need the LM and CSM state vectors for some reason to give me good values.  Would having the CSM SV in the CSM slot really be necessary for my P30?


Title: Re: LM status...
Post by: jalexb88 on September 20, 2016, 08:50:43 PM
I retired your scenario, using PAMFD SV updates. Do a V82 orbit parameter and you see the data is way off. Now do an RTCC MFD SV update and the V82 parameters are now fine and P30, P40 works as it should. Since Indy updated the "NASSP universe" I think he did some changes to the moon config files and padload data that now only the RTCC MFD SV updating takes into account. The PAMFD SV updating is now unusable, but RTCC is now the way to go for all MFD updates.

However it seems I need the LM and CSM state vectors for some reason to give me good values.  Would having the CSM SV in the CSM slot really be necessary for my P30?

You should only need to do a RTCC MFD "eagle" updated to the "LM" slot


Title: Re: LM status...
Post by: indy91 on September 21, 2016, 02:45:42 AM
The NASSP universe changes affect the PAMFD only a little bit. PAMFD is using the fixed NBY1968/1969 epoch for state vectors, so it's only really usable for Apollo 9 and earlier. The difference is not too significant though for the epoch the Apollo 11 AGC uses. One year worth of Earth precession. The epoch thing is a little bit difficult to fix in the PAMFD, because we don't even use the same epoch for CSM and LM in the same mission sometimes! Currently this only affects Apollo 9. This mission uses Colossus249 (NBY1968/1969) and Luminary099 (NBY1969/1970), with the lack of an earlier LGC version.

Also note that the "this" and "other" logic of the PAMFD doesn't really work for the LM. The "this" slot is always the CSM and the "other" slot is always the LM. So maybe you only uplinked a state vector to the CSM slot by accident? I guess the reason for using "this" and "other" was that the primary mission, Apollo 7, uses the LM slot for the S-IVB. But in the grand scheme of things it should probably be changed in the PAMFD.


Title: Re: LM status...
Post by: rcflyinghokie on September 21, 2016, 06:53:44 AM
The NASSP universe changes affect the PAMFD only a little bit. PAMFD is using the fixed NBY1968/1969 epoch for state vectors, so it's only really usable for Apollo 9 and earlier. The difference is not too significant though for the epoch the Apollo 11 AGC uses. One year worth of Earth precession. The epoch thing is a little bit difficult to fix in the PAMFD, because we don't even use the same epoch for CSM and LM in the same mission sometimes! Currently this only affects Apollo 9. This mission uses Colossus249 (NBY1968/1969) and Luminary099 (NBY1969/1970), with the lack of an earlier LGC version.

Also note that the "this" and "other" logic of the PAMFD doesn't really work for the LM. The "this" slot is always the CSM and the "other" slot is always the LM. So maybe you only uplinked a state vector to the CSM slot by accident? I guess the reason for using "this" and "other" was that the primary mission, Apollo 7, uses the LM slot for the S-IVB. But in the grand scheme of things it should probably be changed in the PAMFD.

Thanks guys that explains it.  I was using PAMFD because I already had it open for the clock, but now I see the errors in my ways :P

EDIT:  On that note, in the RTCC, When using the Maneuver PAD page, on the vehicle select, it only gives the option of LM/CSM, which to me would seem docked vehicles.  Will this change parameters of the PAD or is this not changeable by default?


Title: Re: LM status...
Post by: indy91 on September 21, 2016, 09:13:01 AM
It used to be an option to change the configuration on the Maneuver PAD page, but now you can only change this on the configuration page.  The MFD can detect what vehicle it is and if there is another vehicle docked. But it doesn't detect docking and undocking maneuvers. So when you were previously docked it will still read LM/CSM docked, which you have to change.


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 09:13:14 AM
In addition, when doing alignments, you should set your FOV to 72°, since the AOT has a FOV of 60°, and we have all that extra stuff on screen...

This can go for anyone, what kind of angles were considered good for the AOT?  I am averaging about 00007-00010 with a 72 FOV.


Title: Re: LM status...
Post by: indy91 on September 22, 2016, 09:25:16 AM
How many marks are you doing? The AGC can save up to 5 marks, that usually helps with the accuracy. I haven't tried P52s with the AOT too often, but I have been getting 0.03° and lower.


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 09:25:52 AM
How many marks are you doing? The AGC can save up to 5 marks, that usually helps with the accuracy. I haven't tried P52s with the AOT too often, but I have been getting 0.03° and lower.

I actually just realized this and am getting all balls now :)


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 10:06:34 AM
And now another issue, I am running my P63 after a DOI burn and getting a TIG of +59 59.  I have posted a scn file.  What am I missing?  A bad DOI maybe?

EDIT:  Looks like it may have been.  My ground track misses tranquility base :(


Title: Re: LM status...
Post by: indy91 on September 22, 2016, 10:38:27 AM
The trajectory looks pretty good actually. Were you looking at Fra Mauro? There isn't much that could make you completely miss the landing site, DOI doesn't have an out-of-plane component.

Anyway, the scenario still had a few typos that I corrected after I flew the mission up until PDI. But the most relevant change is that TLAND has still the value from the padload document, so it calculated the PDI for two hours earlier. I am a little bit confused, the Apollo 11 launch scenario update I did a few weeks ago already has the correct TLAND, I guess I changed that before my commit but after I flew the mission. Here the scenario with all the parameters fixed, I hope.


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 10:57:13 AM
The trajectory looks pretty good actually. Were you looking at Fra Mauro? There isn't much that could make you completely miss the landing site, DOI doesn't have an out-of-plane component.

Anyway, the scenario still had a few typos that I corrected after I flew the mission up until PDI. But the most relevant change is that TLAND has still the value from the padload document, so it calculated the PDI for two hours earlier. I am a little bit confused, the Apollo 11 launch scenario update I did a few weeks ago already has the correct TLAND, I guess I changed that before my commit but after I flew the mission. Here the scenario with all the parameters fixed, I hope.

Ah maybe I was looking at Fra Mauro in the map view.  I will fire it up again and see what happens.  Also, if it helps, I was flying the activation scn you posted.

EDIT:  Another thing, I know we mentioned this before, but perhaps a status text on the engine stop PB position?  I have done these a few times not knowing if I am in stop or reset only to find out at ignition :P

EDIT 2:  Also, what is the LM DAP load supposed to be for PDI?  I cannot seem to find it.  Also what gimbal angles should A11 be using?  I am using the ones from the A12 activation.


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 05:54:02 PM
So now during PDI I get an 05 09 of 522 and LR stays at 99999.  Same scn as you gave me Indy.


Title: Re: LM status...
Post by: eddievhfan1984 on September 22, 2016, 06:08:28 PM
According to the documentation, a 522 code means that the LR changed position (is in the wrong place). Which would suggest a failure to trigger the switch to position 2 (you'd get a 523 if the position change command were sent, but the radar failed to move). Try a manual switch to position 2, and see if that helps.

EDIT: also regarding the DAP for P63, it's not too important, as the P63 routines include configuring the DAP. for example, according to the assembly listing/logic flow diagram, the computer sets up for a 1° deadband during P63, then changes to a 0.3° deadband for P64 onwards.

Maybe something to think about for a future release is implementing some of the cue cards/quick-reference cards on the panel bitmap to help with these sorts of things. LOL


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 06:15:18 PM
According to the documentation, a 522 code means that the LR changed position (is in the wrong place). Which would suggest a failure to trigger the switch to position 2 (you'd get a 523 if the position change command were sent, but the radar failed to move). Try a manual switch to position 2, and see if that helps.

Yeah I read the error code from the docs.  I cannot even get radar to pick up any data at all, not even an ALT light.  Also I am noticing in this scn that even with a SV update, my computer thinks I am a lot higher than I actually am.  Looks to be about 10k feet.


Title: Re: LM status...
Post by: eddievhfan1984 on September 22, 2016, 06:23:30 PM
That is pretty odd. Even if communication from the LR to the computer is screwed up, the tapemeters should still be able to drive...


Title: Re: LM status...
Post by: indy91 on September 22, 2016, 06:23:58 PM
Maybe the LR isn't in position 1 at PDI? Have you done the self test? The Apollo 12 G&N checklist has a verb 59 during it, while in the Apollo 11 AGC it is verb 60. In doubt, just manually place the position switch to 1.

The altitude is calculated from the landing site radius and the scenario still has the actual landing site vector for Tranquility Base, which is about 10k feet below the average Moon radius.

I'll add a simple debug string for the engine start/stop switches.


Title: Re: LM status...
Post by: rcflyinghokie on September 22, 2016, 06:39:39 PM
That is pretty odd. Even if communication from the LR to the computer is screwed up, the tapemeters should still be able to drive...

Tape meters drive just fine and there is a big difference between PGNS and LR.  Also after updating a SV, I still have different altitudes in my V82 than I should.  They are close but off by about 10k feet as well.

Maybe the LR isn't in position 1 at PDI? Have you done the self test? The Apollo 12 G&N checklist has a verb 59 during it, while in the Apollo 11 AGC it is verb 60. In doubt, just manually place the position switch to 1.

The altitude is calculated from the landing site radius and the scenario still has the actual landing site vector for Tranquility Base, which is about 10k feet below the average Moon radius.

I'll add a simple debug string for the engine start/stop switches.

I have not done the self test, however I did try switching manually to position one and had no change in results.  I think the issue is stemming honestly from the large altitude discrepancy to begin with even with a SV update.  Take a look at the file you sent back to me and run a V82 and compare with the actual values.

And thank you for the switch position string :)

EDIT: To clarify, after a SV update my V82 orbit parameters differ from the PAMFD GNC parameters by almost 2 miles (last iteration 60.6x8.0 vs 62.3x9.7) the latter being the LGC.  These should match even before PDI right?


Title: Re: LM status...
Post by: indy91 on September 23, 2016, 04:36:20 AM
The altitude in V82 is measured from the landing site radius, not the mean Moon radius. And the scenario you are using has the landing site vector from the padload document. Tranquility Base is about 1.7NM lower than the mean Moon radius, which Orbiter 2010 is using. That's why V82 and PAMFD disagree about altitude.

I have tried the scenario and I also got the 522 alarm. I don't see anything that would cause the position change, maybe something doesn't quite work out because the LR sends a data good signal before the LGC even asks for it. That also happens because of the landing site vector difference and if that causes the alarm it is probably a LR bug. Maybe try what happens if you copy over the RLS vector (EMEM2022-2027) from the P63 test scenario?


Title: Re: LM status...
Post by: rcflyinghokie on September 23, 2016, 06:50:05 AM
The altitude in V82 is measured from the landing site radius, not the mean Moon radius. And the scenario you are using has the landing site vector from the padload document. Tranquility Base is about 1.7NM lower than the mean Moon radius, which Orbiter 2010 is using. That's why V82 and PAMFD disagree about altitude.

Ah I thought they were separate entities to be honest.  Just goes to show I have a lot to learn!  

I have tried the scenario and I also got the 522 alarm. I don't see anything that would cause the position change, maybe something doesn't quite work out because the LR sends a data good signal before the LGC even asks for it. That also happens because of the landing site vector difference and if that causes the alarm it is probably a LR bug. Maybe try what happens if you copy over the RLS vector (EMEM2022-2027) from the P63 test scenario?

I will try that and see if anything changes..  Now how do I do that :P

EDIT:  I think I found it in the G&N checklist, its the V1 N1 to view and V21 N01 to modify?

EDIT2: Got it, now to try a P63...

EDIT3: Same issue with the LR :(


Title: Re: LM status...
Post by: rcflyinghokie on September 23, 2016, 12:54:50 PM
A separate issue, I often get at the bottom of my screen "TELECOM: bind() failed: 10048" and it doesn't go away.  It also blocks your new string for the engine start/stop.  Any ideas what this stems from?


Title: Re: LM status...
Post by: dseagrav on September 23, 2016, 01:00:57 PM
Usually means the previous Orbiter instance did not exit.


Title: Re: LM status...
Post by: rcflyinghokie on September 23, 2016, 01:04:45 PM
Usually means the previous Orbiter instance did not exit.

Interesting, thank you I will check my task manager whenever I see that :)

Maybe the LR isn't in position 1 at PDI? Have you done the self test? The Apollo 12 G&N checklist has a verb 59 during it, while in the Apollo 11 AGC it is verb 60. In doubt, just manually place the position switch to 1.

Just tried a self test, on steps 11 and 12 I am getting the same 522 error anytime the LR switch is not in position 2.

Also went back into the same scn before your fixes and am getting the same issues with the LR, but I go into the old P63 scn and no issues with the LR whatsoever.

EDIT:  After doing some experimentation, it is a problem with the EMEM in the scn file.  I have not narrowed it down but when I copied the EMEM from the P63 scn into the other one you fixed the error goes away.  Now I just do not know how to start narrowing down the problem.  I have ruled out a few addresses; 2022-2027, 3420-3421, 2522-2536, 2400-2401.  Any thoughts about where to look next?


Title: Re: LM status...
Post by: indy91 on September 25, 2016, 08:45:53 AM
Here my obligatory video showcasing the new feature of landing on the Moon: https://www.youtube.com/watch?v=sHaS6sYJsMg

EDIT:  After doing some experimentation, it is a problem with the EMEM in the scn file.  I have not narrowed it down but when I copied the EMEM from the P63 scn into the other one you fixed the error goes away.  Now I just do not know how to start narrowing down the problem.  I have ruled out a few addresses; 2022-2027, 3420-3421, 2522-2536, 2400-2401.  Any thoughts about where to look next?

Have you copied over only the EMEMs or also the I/O channel stuff? If it's only the EMEMs, then it will be easier to track down for me. I don't have as much time right now and I want to finally get another RTCC MFD update finished. After that I'll look into the problem in more detail. I'm sure it has to be a procedural error during the activation or later, but certainly one that will be a valuable lesson for flying the Apollo 11 LGC in the LM.


Title: Re: LM status...
Post by: rcflyinghokie on September 25, 2016, 09:12:00 AM
Have you copied over only the EMEMs or also the I/O channel stuff? If it's only the EMEMs, then it will be easier to track down for me. I don't have as much time right now and I want to finally get another RTCC MFD update finished. After that I'll look into the problem in more detail. I'm sure it has to be a procedural error during the activation or later, but certainly one that will be a valuable lesson for flying the Apollo 11 LGC in the LM.

I only copied the EMEMs, left all of the I/O channels alone, then I started going through the pad loads to see what EMEM addresses could have dealt with the landing as I mentioned.  Is there a list of the definitions of the EMEM locations other than pad load documents?

EDIT:  Through trial and error I have it narrowed between EMEM 0313 and 0377 if this helps


Title: Re: LM status...
Post by: indy91 on September 25, 2016, 10:33:49 AM
Here is the erasable memory for Luminary099: http://www.ibiblio.org/apollo/listings/Luminary099/ERASABLE_ASSIGNMENTS.agc.html

If it is in the range of EMEMs you mentioned, then there is nothing that immediately stands out for me. Mostly downlink stuff.


Title: Re: LM status...
Post by: rcflyinghokie on September 25, 2016, 10:40:01 AM
Here is the erasable memory for Luminary099: http://www.ibiblio.org/apollo/listings/Luminary099/ERASABLE_ASSIGNMENTS.agc.html

If it is in the range of EMEMs you mentioned, then there is nothing that immediately stands out for me. Mostly downlink stuff.

That's what I was using and nothing stood out to me either.  And yeah I just double checked if I explicitly copy EMEM 0313-0377 from the p63 test scn to my scn, I do not get the 522 error in the test or the landing.  I noticed that the p63 scn has a lot more emem addresses used in that range than my scn as well.

P63:

  EMEM0313 77777
  EMEM0321 3513
  EMEM0322 42500
  EMEM0323 77710
  EMEM0324 77777
  EMEM0325 77777
  EMEM0326 77777
  EMEM0327 77777
  EMEM0330 77777
  EMEM0331 77777
  EMEM0333 4000
  EMEM0334 2214
  EMEM0335 3515
  EMEM0336 6762
  EMEM0337 32231
  EMEM0340 77715
  EMEM0341 214
  EMEM0342 77752
  EMEM0343 65416
  EMEM0344 74051
  EMEM0345 53340
  EMEM0346 1001
  EMEM0347 26273
  EMEM0350 343
  EMEM0351 32703
  EMEM0352 4213
  EMEM0353 23006
  EMEM0366 30000
  EMEM0370 5202
  EMEM0371 11343
  EMEM0373 11470
  EMEM0374 10146
  EMEM0375 1520
  EMEM0376 405
  EMEM0377 41203

Mine:
  EMEM0313 77777
  EMEM0320 1
  EMEM0321 60
  EMEM0322 62132
  EMEM0323 77753
  EMEM0324 77777
  EMEM0325 77777
  EMEM0326 77777
  EMEM0327 77777
  EMEM0330 77777
  EMEM0331 77777
  EMEM0333 10000
  EMEM0334 2172
  EMEM0335 3707
  EMEM0336 77776
  EMEM0337 77776
  EMEM0366 30000
  EMEM0370 4054
  EMEM0371 11343
  EMEM0373 45313
  EMEM0374 10146


Title: Re: LM status...
Post by: rcflyinghokie on September 25, 2016, 07:39:49 PM
I have it down to EMEM 0375 and 0376, if I add those two my 05 09 code goes away.


Title: Re: LM status...
Post by: eddievhfan1984 on September 25, 2016, 09:02:59 PM
Yeah, those are just previously called alarms, 0375-0377. I can't imagine what adding in the previously called alarms would do in regards to the radar, though...


Title: Re: LM status...
Post by: rcflyinghokie on September 26, 2016, 07:06:27 AM
Yeah, those are just previously called alarms, 0375-0377. I can't imagine what adding in the previously called alarms would do in regards to the radar, though...

Neither can I, which is why I am confused :(  However if I run the LR test again I get the same 522 error.  But I go back and replace 0313-0377 I do not get the error at all.  However I did notice when I do this, and run the V63 the first time with the DES radar selected, I get all of the test values.  Then when I V34 and force the radar into hover with a V 60, I get good data again in the V63, but when I switch it to DES, I get no program alarm but the values for the test all go to zero (except the LR position register which cycles to 1) and then when I switch back to hover they come back.

And running the P63 scn again I do not have that issue, tells me there is something else up.


Title: Re: LM status...
Post by: rcflyinghokie on September 28, 2016, 07:28:52 AM
Not sure if they are related but ever since the latest build I get a CTD in the LM within a minute or two of loading into it regardless of scn file.  Same debug error each time "Unhandled exception at 0x004704F7 in orbiter.exe: 0xC0000005: Access violation reading location 0x00000010."


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 08:26:35 AM
Not sure if they are related but ever since the latest build I get a CTD in the LM within a minute or two of loading into it regardless of scn file.  Same debug error each time "Unhandled exception at 0x004704F7 in orbiter.exe: 0xC0000005: Access violation reading location 0x00000010."


I haven't had any crashes caused by the LM for a long time. Maybe the build is bad? No idea really...

@jalexb88, a while back you uploaded some LM panel changes. Has anyone discovered any problems with it? If not, then I am finally going to commit them.


Title: Re: LM status...
Post by: lotisully86 on October 01, 2016, 08:57:34 AM
 :ThumbsUp432:
 
This also reminds me... For docking tunnel index, are we always accounting for this angle as zero or n/a? I have assumed so, although I haven't seen this brought up before so I figure I might as well.


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 10:15:27 AM
The docking orientations in Orbiter are fixed, so the docking tunnel index should always be zero. However, looking at the code and past experiences, I think there is something quite wrong here with our CSM and LM. The docking port of the LM is offset 45°, not 60°. The docking target on the LM still works, because it is also offset 45° and the left rendezvous window of the CSM has the corresponding camera offset.

Am I thinking this wrong somehow? If not, then we really need to change this, or else the docked IMU alignments don't work, or at least not with the 60° correction. That's why I (and probably everyone else) had problems with it and why my V42 torquing angles calculation didn't really work. If we change this, then the LM mesh has to be changed, the camera offset for the rendezvous window has to be changed and of course the docking port offset of the LM, but that should be easy.


Title: Re: LM status...
Post by: rcflyinghokie on October 01, 2016, 10:22:47 AM
The docking orientations in Orbiter are fixed, so the docking tunnel index should always be zero. However, looking at the code and past experiences, I think there is something quite wrong here with our CSM and LM. The docking port of the LM is offset 45°, not 60°. The docking target on the LM still works, because it is also offset 45° and the left rendezvous window of the CSM has the corresponding camera offset.

Am I thinking this wrong somehow? If not, then we really need to change this, or else the docked IMU alignments don't work, or at least not with the 60° correction. That's why I (and probably everyone else) had problems with it and why my V42 torquing angles calculation didn't really work. If we change this, then the LM mesh has to be changed, the camera offset for the rendezvous window has to be changed and of course the docking port offset of the LM, but that should be easy.

Because of the CM camera offsets would say using the converted docking angles in a TP&D (60 degrees included) look correct even if the spacecraft is only 45 degrees of roll?  I ask because I usually run a TP&D and use the calculated docking angles in a V49 and I am usually aligned very well if memory serves.  It has been a little since I did a TP&D I will run one to be sure momentarily.


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 10:34:41 AM
Because of the CM camera offsets would say using the converted docking angles in a TP&D (60 degrees included) look correct even if the spacecraft is only 45 degrees of roll?  I ask because I usually run a TP&D and use the calculated docking angles in a V49 and I am usually aligned very well if memory serves.  It has been a little since I did a TP&D I will run one to be sure momentarily.

If you align yourself with the docking target then you should have no problem, but if you use the V49 angles all the way until docking, then you will suddenly be rotated by 15° once docked. Aligning yourself with the translational thrusters to the docking target will still works very well, but you should be 15° off in roll.

EDIT: It's not exactly a new problem: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=904.0 I would say until this can be fixed, we just have to use 45° for our docked IMU alignments. And TD&E.

We are in desperate need for modelers anyway. Our LM mesh looks very out-of-date and at one point we might want a 3D panel.


Title: Re: LM status...
Post by: rcflyinghokie on October 01, 2016, 11:29:33 AM

If you align yourself with the docking target then you should have no problem, but if you use the V49 angles all the way until docking, then you will suddenly be rotated by 15° once docked. Aligning yourself with the translational thrusters to the docking target will still works very well, but you should be 15° off in roll.

EDIT: It's not exactly a new problem: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=904.0 I would say until this can be fixed, we just have to use 45° for our docked IMU alignments. And TD&E.

Yep looks to be a 15 degree offset using the V49 until hard dock


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 11:50:55 AM
I guess what I could do is change the docking orientations of the LM (including still in the SLA) and the viewing point of the rendezvous window. The last one is a little bit tricky, because the COAS is not exactly in the center of the screen. But it can be done. Without changing the mesh there would always be the 15° offset while docking, but at least it wouldn't cause us problems with the alignment.


Title: Re: LM status...
Post by: rcflyinghokie on October 01, 2016, 12:07:39 PM
I guess what I could do is change the docking orientations of the LM (including still in the SLA) and the viewing point of the rendezvous window. The last one is a little bit tricky, because the COAS is not exactly in the center of the screen. But it can be done. Without changing the mesh there would always be the 15° offset while docking, but at least it wouldn't cause us problems with the alignment.

Until we get someone back or someone new that knows meshes this sounds like a viable answer.

Also on a previous subject, I still have not found the issue for the LR in my LM.  In your P63 test, did you use the apollo 12 activation procedure to the letter (except the V21N01 1462E 576E)?


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 12:42:01 PM
I commited the docking orientation change. Not sure what this does to the already docked CSM/LM in old scenarios. If both have running IMUs, then certainly one of them will be wrong now. @rcflyinghokie, you were just doing TD&E tests, can you try the change? If I didn't get the offset for the rendezvous window perfect, then I can certainly tweak it a little bit more. I have a 16:10 monitor, not sure how it looks on other resolutions and aspect ratios.

Also on a previous subject, I still have not found the issue for the LR in my LM.  In your P63 test, did you use the apollo 12 activation procedure to the letter (except the V21N01 1462E 576E)?

I certainly did not follow the checklist to the letter. Lots of systems weren't implemented yet and I did not know as much about the LM and the activation as I do now. The 15° offset of my alignment will also not have helped. I'll take a look at the LR problem again, when I have commited the LM panel changes.


Title: Re: LM status...
Post by: jalexb88 on October 01, 2016, 12:49:06 PM
@jalexb88, a while back you uploaded some LM panel changes. Has anyone discovered any problems with it? If not, then I am finally going to commit them.

I think they are ready, although I was wondering how they are on 16:10 monitors and I think that's your case? Are the 16:9 panels displaying ok on that? Also if you wouldn't mind including the CSM panels which also have been updated to 16:9.

Edit: we will also at some point have to ask moonwalker about those LM ECS panels...


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 12:59:37 PM
I think they are ready, although I was wondering how they are on 16:10 monitors and I think that's your case? Are the 16:9 panels displaying ok on that?

No real problems there, you can still see the DSKY on the LPD panel and everything else. Without 16:9 and 1080p you just have to be careful to not move the view, or else the LPD markings are useless.

Quote
Also if you wouldn't mind including the CSM panels which also have been updated to 16:9.

I wanted to ask you, why don't they need any changes to the saturnpanel.cpp? Have you only added panel area on the right hand side? I just hadn't checked every single switch to see if anything doesn't work...

Quote
Edit: we will also at some point have to ask moonwalker about those LM ECS panels...

Should we really have to rely on people joining the development again? I think if we have anyone here who can create the panels, then we should go ahead and do that.


Title: Re: LM status...
Post by: rcflyinghokie on October 01, 2016, 01:05:50 PM
I commited the docking orientation change. Not sure what this does to the already docked CSM/LM in old scenarios. If both have running IMUs, then certainly one of them will be wrong now. @rcflyinghokie, you were just doing TD&E tests, can you try the change? If I didn't get the offset for the rendezvous window perfect, then I can certainly tweak it a little bit more. I have a 16:10 monitor, not sure how it looks on other resolutions and aspect ratios.

Just tried it, still have the same visible offset of about 15 degrees was apparent as I showed in my image.  Also, upon contact, both vehicles go into insane spin rates now.

EDIT: attachment


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 01:09:14 PM
Just tried it, still have the same visible offset of about 15 degrees was apparent as I showed in my image.  Also, upon contact, both vehicles go into insane spin rates now.

The offset should still be there, at least until the mesh is changed. What shouldn't happen anymore is suddenly being rotated 15° upon docking when using the V49 angles. The spin rate sounds bad, maybe I overlooked something. Do you have a scenario for me?


Title: Re: LM status...
Post by: rcflyinghokie on October 01, 2016, 01:10:35 PM
The offset should still be there, at least until the mesh is changed. What shouldn't happen anymore is suddenly being rotated 15° upon docking when using the V49 angles. The spin rate sounds bad, maybe I overlooked something. Do you have a scenario for me?

Yep sorry forgot to attach.  Right before soft dock.


Title: Re: LM status...
Post by: jalexb88 on October 01, 2016, 01:23:57 PM
No real problems there, you can still see the DSKY on the LPD panel and everything else. Without 16:9 and 1080p you just have to be careful to not move the view, or else the LPD markings are useless.

I can see about creating a 16:10 version of the LPD panel so that the view stays "locked".

Quote
I wanted to ask you, why don't they need any changes to the saturnpanel.cpp? Have you only added panel area on the right hand side? I just hadn't checked every single switch to see if anything doesn't work...

That's correct, I only added to the right side of the panels to fill the gap, no change was required to staurnpanel.cpp. No switch should be affected by this.

Quote
Should we really have to rely on people joining the development again? I think if we have anyone here who can create the panels, then we should go ahead and do that.

I agree, but I think moonwalker was on the verge of releasing some ECS panels at some point, so we may not have to far to look.


Title: Re: LM status...
Post by: indy91 on October 01, 2016, 01:31:58 PM
I just did a dumb mistake with the S-IVB docking orientation, the coordinate system of the S-IVB is not identical with the LM. Fix is on the way. The Docking MFD should now show a good docking alignment with the V49 angles.

I can see about creating a 16:10 version of the LPD panel so that the view stays "locked".

There is something in the Project Apollo Configurator that automatically detecs the aspects ratios 4:3, 16:9 and 16:10. This is already used for the left rendezvous panel, so that the COAS is always in the correct place. Not sure how much that helps with separate bitmaps for the panel. 16:9 is the most used format, so I would be ok if we only use that in NASSP.

Quote
That's correct, I only added to the right side of the panels to fill the gap, no change was required to staurnpanel.cpp. No switch should be affected by this.

Then I can simply commit it.

Quote
I agree, but I think moonwalker was on the verge of releasing some ECS panels at some point, so we may not have to far to look.

Good point. Work on the LM is only distraction right now anyway ;)


Title: Re: LM status...
Post by: rcflyinghokie on October 17, 2016, 02:00:44 PM
I know the focus is getting 7 and 8 working for a release, but just to save a bunch of work later, I have begun LM checklist MFD excel files.  I currently am importing the switches in the LM so we do not have to go searching later for names in the sdk files and then filing out a preliminary activation checklist based on A12's checklist pdf.  Since it takes a bit to get these into excel from scratch, I wanted to make sure nobody else is doing it and basically doubling the work :P

EDIT:  A few things I noticed, not huge but still can be fixed:
1) Glycol is spelled Clycol in the code :P
2)There is a repeat switch name for 2 different switches on both the CDR audio and LMP audio, CDRAudICSSwitch is used for both the ICS switch and VOX switch in the code, same with LMPAudICSSwitch.  The Mode switch will need to be defined as something else I believe for this to work.

   CDRAudICSSwitch.Register(PSH,"CDRAudICSSwitch",THREEPOSSWITCH_CENTER);
   CDRAudVOXSwitch.Register(PSH,"CDRAudICSSwitch",THREEPOSSWITCH_CENTER);


Title: Re: LM status...
Post by: dseagrav on October 17, 2016, 10:47:11 PM
Unless someone objects to it for some strange reason go ahead and correct/fix the spelling in the code. There was another error in the name somewhere that I made a mental note to fix and now I forget what it was; Something involving the use of a CSM acronym in the LM. I want to say it was on the LMP side of things.


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 08:58:03 AM
Unless someone objects to it for some strange reason go ahead and correct/fix the spelling in the code. There was another error in the name somewhere that I made a mental note to fix and now I forget what it was; Something involving the use of a CSM acronym in the LM. I want to say it was on the LMP side of things.

Is the mistake you are trying to remember a panel switch name or incorrect name in code?

And I have made the changes I am going to try using Indy's git instructions to add them to the repository.


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 11:24:18 AM
And I have made the changes I am going to try using Indy's git instructions to add them to the repository.

Yes, that would allow me to figure out how to merge pull requests.  :ROTFL3453:

I'm sure you have already figured that out, but checklist files for the LM are loaded with the LEMCHECK option in the launch scenario (see: http://nassp.sourceforge.net/wiki/Scenario_File_Options#Checklist_Information). And hopefully the LM gets this information, when it is created upon S-IVB/LM separation. I doubt it has been tested much. A generic activation checklist for our LM with Luminary099 would be very helpful, we don't have that documentation for Apollo 11.


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 11:30:07 AM
Yes, that would allow me to figure out how to merge pull requests.  :ROTFL3453:

I'm sure you have already figured that out, but checklist files for the LM are loaded with the LEMCHECK option in the launch scenario (see: http://nassp.sourceforge.net/wiki/Scenario_File_Options#Checklist_Information). And hopefully the LM gets this information, when it is created upon S-IVB/LM separation. I doubt it has been tested much. A generic activation checklist for our LM with Luminary099 would be very helpful, we don't have that documentation for Apollo 11.

Well I just made my first push!  I think it worked, give the pull a try if you wish!

I haven't tried putting the checklist in the scn file just yet, it was a workout naming each of the switches and breakers in excel for the initial activation, but now we (should) have a repository of switches and names to use once I push them up.  I am going to play with that LM checklist and see if it reads it up before I push it.


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 11:41:38 AM
You didn't actually create a pull request for the changes, so I did that for you. See the discussion there.


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 11:44:58 AM
You didn't actually create a pull request for the changes, so I did that for you. See the discussion there.

Ah no I did not yet, I am still learning all of this git stuff, I think I thought all I had to do was a push :P  Which discussion are you referring to? 


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 11:48:49 AM
No problem, the actual pull request is not the most complicated part, so I haven't prevented any learning.  :ROTFL3453:

The discussion is here: https://github.com/dseagrav/NASSP/pull/24 and as expected the build failed, because the LEM.h needs a change, too.

EDIT: And interestingly enough, BuildBot tried to build your changes, although they haven't even been merged into the master branch yet.


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 11:50:47 AM
No problem, the actual pull request is not the most complicated part, so I haven't prevented any learning.  :ROTFL3453:

The discussion is here: https://github.com/dseagrav/NASSP/pull/24 and as expected the build failed, because the LEM.h needs a change, too.

EDIT: And interestingly enough, BuildBot tried to build your changes, although they haven't even been merged into the master branch yet.

Ah perfect.  I just fixed that file as well.  Now before I run these in the future, can I use VS to find that error?


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 11:57:59 AM
Ah perfect.  I just fixed that file as well.  Now before I run these in the future, can I use VS to find that error?

It shouldn't have been able to build the NASSP solution, if you did the changes in Visual Studio. It's easy to find any problems that way, so it's always a good idea to try building the solution as a test if the change are good. Did you not change it in VS? Because then it would have given you a "GlycolRotary is not defined" message the second you did this change.


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 12:03:44 PM
It shouldn't have been able to build the NASSP solution, if you did the changes in Visual Studio. It's easy to find any problems that way, so it's always a good idea to try building the solution as a test if the change are good. Did you not change it in VS? Because then it would have given you a "GlycolRotary is not defined" message the second you did this change.

I did change them in VS, but I pulled up the individual files.  I would have to open up the main solution file and change within for these to show up? Never mind I got it :)

Also I am working with your instructions to create a pull request, I added that LEM.h file and compared across forks but I see no create new pull button anywhere.


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 12:21:48 PM
The button should be here: https://github.com/dseagrav/NASSP/pulls I have changed the link now in my explanation in the git thread. No need to create an extra pull request of course, unless you have another change (e.g. the LEM checklist file).


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 12:26:06 PM
The button should be here: https://github.com/dseagrav/NASSP/pulls I have changed the link now in my explanation in the git thread. No need to create an extra pull request of course, unless you have another change (e.g. the LEM checklist file).

Ah gotcha.  And I will have that change next!  Glad to see my last one FINALLY worked.


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 12:32:18 PM
dseagrav, if it is possible and you get the chance, then maybe the auto builds should be deactivated for pull requests. Instead of only checking if it can be build, it actually does a complete build, although it doesn't actually create a release at least.


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 04:02:38 PM
I'm sure you have already figured that out, but checklist files for the LM are loaded with the LEMCHECK option in the launch scenario (see: http://nassp.sourceforge.net/wiki/Scenario_File_Options#Checklist_Information). And hopefully the LM gets this information, when it is created upon S-IVB/LM separation. I doubt it has been tested much. A generic activation checklist for our LM with Luminary099 would be very helpful, we don't have that documentation for Apollo 11.

I have been trying to get this to work but every time I get a CTD when accessing it from the LM.

I am placing   LEMCHECK  Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls into the scn file is this correct?


Title: Re: LM status...
Post by: indy91 on October 18, 2016, 05:14:05 PM
LEMCHECK is just for the launch scenario, or rather until the LM is separated from the S-IVB. Only then is the LEMCHECK string actually being used to create a new checklist controller. What you can try is using the format in which checklist state is saved, but completely blank. So at the end of the LM in the scenario file, try this:

Code:
<checklist>
  FILE Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls
</checklist>


Title: Re: LM status...
Post by: rcflyinghokie on October 18, 2016, 05:55:05 PM
LEMCHECK is just for the launch scenario, or rather until the LM is separated from the S-IVB. Only then is the LEMCHECK string actually being used to create a new checklist controller. What you can try is using the format in which checklist state is saved, but completely blank. So at the end of the LM in the scenario file, try this:

Code:
<checklist>
  FILE Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls
</checklist>

Even though the wiki says this "Additionally there are two items to define in the launch vehicle before the scenario starts. These are NOT defined between <checklist> and </checklist>"  for those?


Title: Re: LM status...
Post by: indy91 on October 19, 2016, 05:14:50 AM
Any information between <checklist> and </checklist> are for the checklist controller itself. So that is loaded in the launch scenario for the CSM. The LEMCHECK parameter is not a checklist parameter, it's a Saturn parameter and saved/loaded in the Saturn until the LM is created. When the LM exists, the checklist controller for the LM is created and only then there will be <checklist> and </checklist> in the LM. So it seems what should work for an already existing LM, is using the same syntax as is used in the launch scenario for the CSM. With FILE instead of LEMCHECK of course.


Title: Re: LM status...
Post by: rcflyinghokie on October 19, 2016, 07:21:21 AM
Any information between <checklist> and </checklist> are for the checklist controller itself. So that is loaded in the launch scenario for the CSM. The LEMCHECK parameter is not a checklist parameter, it's a Saturn parameter and saved/loaded in the Saturn until the LM is created. When the LM exists, the checklist controller for the LM is created and only then there will be <checklist> and </checklist> in the LM. So it seems what should work for an already existing LM, is using the same syntax as is used in the launch scenario for the CSM. With FILE instead of LEMCHECK of course.

Makes perfect sense.  Now before the LM is created, ie beginning a scenario from launch, how can I tell it to load the LM checklist file for the LM?

EDIT:  Also I still get a CTD whenever I click any checklist buttons in the LM.


Title: Re: LM status...
Post by: indy91 on October 19, 2016, 10:48:46 AM
Makes perfect sense.  Now before the LM is created, ie beginning a scenario from launch, how can I tell it to load the LM checklist file for the LM?

For the launch scenario or the Saturn before the LM is created (at LM/S-IVB sep)

Code:
LEMCHECK  Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls

has to be used. When the LM already exists, then it is

Code:
<checklist>
  FILE Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls
</checklist>

in the section of the scenario for the LM of course.

Quote
EDIT:  Also I still get a CTD whenever I click any checklist buttons in the LM.

Maybe you can post your draft for the checklist, so I can try and find if there is a problem in the checklist controller code? It probably was never really used with the LM before, so maybe there is an issue.


Title: Re: LM status...
Post by: rcflyinghokie on October 19, 2016, 11:00:55 AM
Oh ok I think i just misinterpreted.  So my original theory of placing LEMCHECK Doc\Project Apollo - NASSP\Checklists\CSM Default Checklists.xls in the scn file before launch was correct.  That's what I was trying to figure out.

I have been running this a few times (takes a while because I have to start the scn file and then get to orbit and dock etc) but each time the checklist doesn't show in checklist MFD and I get the CTD.  I have posted the excel file I am playing with as well as the scn file I am using with my modifications.


Title: Re: LM status...
Post by: indy91 on October 19, 2016, 11:12:09 AM
Well, I took a random Apollo 11 scenario with the LM already existing and placed the "Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls" string at the appropiate place and I see the checklist, without CTD. Note that even in the LM without a checklist the checklist part of the save in the scenario already exists, with only a few items. The space behind "FILE" was blank without a file. Of course there might be a problem still with giving the string defined with LEMCHECK in the launch scenario to the LM, but Checklist itself is loaded and doesn't cause a CTD.


Title: Re: LM status...
Post by: rcflyinghokie on October 19, 2016, 11:20:07 AM
I did the same thing with my A9 scn and it worked as well.  However I notice when I use LEMCHECK with the file name in it like I previously posted, it doesn't call that file in the new checklist section.

Code:
 <checklist>
  FILE
  COMPLETE 1
  FLASHING 0
  LASTITEMTIME -1000000000.000000
  AUTOEXECUTESLOWDELAY 4.000000
  WAITFORCOMPLETION 0
  </checklist>

This is all it creates.  Which is probably why I am getting a CTD because there is no FILE defined.


Title: Re: LM status...
Post by: indy91 on October 19, 2016, 11:31:41 AM
It looks to me like the S-IVB doesn't properly receive the checklist settings and doesn't send them to the newly created LEM. I'll try to figure out how to fix that.


Title: Re: LM status...
Post by: rcflyinghokie on October 19, 2016, 11:37:24 AM
It looks to me like the S-IVB doesn't properly receive the checklist settings and doesn't send them to the newly created LEM. I'll try to figure out how to fix that.

Sounds good, thanks.  In the mean time I will load this checklist and see if I can get an activation checklist completed and tested.


Title: Re: LM status...
Post by: indy91 on October 19, 2016, 02:39:11 PM
It was a little bit more tricky than I hoped, but now the LEMCHECK parameter should be given to the LM/S-IVB stack and then after that to the LM, at which point the Checklist Controller is created for the LM. Saving and loading should also work. Not much of this was working before, even the saving of the LEMCHECK parameter in the Saturn class was a little bit broken. I've tested it with a TD&E, before that the Saturn is always the part of the rocket that is attached to the CSM, so there shouldn't be any problem between prelaunch and until CSM/LV Separation.


Title: Re: LM status...
Post by: rcflyinghokie on October 19, 2016, 05:50:12 PM
It was a little bit more tricky than I hoped, but now the LEMCHECK parameter should be given to the LM/S-IVB stack and then after that to the LM, at which point the Checklist Controller is created for the LM. Saving and loading should also work. Not much of this was working before, even the saving of the LEMCHECK parameter in the Saturn class was a little bit broken. I've tested it with a TD&E, before that the Saturn is always the part of the rocket that is attached to the CSM, so there shouldn't be any problem between prelaunch and until CSM/LV Separation.

Is/should the LEMCHECKAUTO working?  Because the checklist comes up fine but I have zero auto execution.


Title: Re: LM status...
Post by: indy91 on October 19, 2016, 06:17:56 PM
Are you sure it even recognizes the switches yet? Because I have not seen the flashing borders, if I enable that option, and the Checklist MFD also doesn't react if I cycle the required switch/circuit breaker. Might have been that your Checklist MFD didn't have the correct names yet. But if it isn't that, then I'll check the transfer of the LEMCHECKAUTO parameter again. In the other case something in the LM needs fixing.


Title: Re: LM status...
Post by: rcflyinghokie on October 19, 2016, 06:27:36 PM
The switch names should be correct, they match the switch names in the LM files as well as the scn file after the LM is generated.  But no I am not sure it recognizes them, and I do not have flashing indicators either.

EDIT:  I also noticed in the scn file, the checklist generation is a little different than the CSM.

Code:
  <group>
  INDEX 0
  CALLED 1
  </group>

These are in the csm checklist section

Code:
  <item>
  INDEX 0
  STATUS 1
  DSKYINDEX 0
  </item>

And these are in the LM section.  I am not well versed as I said, but I would think there is something wrong with the LM section, also, the CSM makes only about 20 something indexes, where the LM makes hundreds in the scn file.


Title: Re: LM status...
Post by: indy91 on October 20, 2016, 06:50:44 AM
I think there are a bunch of variables that are only saved, if they are non zero. That would apply to STATUS. The indexes are so many for the LEM, because the currently loaded checklist (LM Activation) is so long. Whatever CSM checklist is loaded in your scenario is shorter.

But I have found the actual reason why it didn't work. The LM Checklist Controller simply didn't do any timesteps yet. So I have added that function at the end of clbkPostStep. The Timestep function needs the SaturnEvents struct as a parameter, so what I have done is given the LM a DummyEvents variable, which should have minus infinity for all Saturn events. I don't think it's possible to synchronize events between CSM and LM, so the two possible solutions in the long term is either giving the LM "LMEvents" that work the same way as the SaturnEvents, or add the few events relevant to the LM to the SaturnEvents struct. The second option is certainly easier, a lot of Checklist Controller methods are using the SaturnEvents as a parameter.


Title: Re: LM status...
Post by: rcflyinghokie on October 20, 2016, 06:58:25 AM
But I have found the actual reason why it didn't work. The LM Checklist Controller simply didn't do any timesteps yet. So I have added that function at the end of clbkPostStep. The Timestep function needs the SaturnEvents struct as a parameter, so what I have done is given the LM a DummyEvents variable, which should have minus infinity for all Saturn events. I don't think it's possible to synchronize events between CSM and LM, so the two possible solutions in the long term is either giving the LM "LMEvents" that work the same way as the SaturnEvents, or add the few events relevant to the LM to the SaturnEvents struct. The second option is certainly easier, a lot of Checklist Controller methods are using the SaturnEvents as a parameter.

I agree that the second method is the best option.  I cannot imagine we would do any more than double the current number of events in the extreme situation.  I have also begun to think about these events, perhaps undocking, PDI, landing, liftoff, and docking to start could be appropriate event functions.  Other than aborts I wouldn't know what else to add until I dive deeper into this.

Also for the length of my current checklist, it was just a test and initial activation (which everything should already be set).  Now since we do not do any comm checks, would it even be necessary to do the IVT comm powerup and powerdown?  Or should I create those for the sake of accuracy?


Title: Re: LM status...
Post by: indy91 on October 20, 2016, 07:04:00 AM
I agree that the second method is the best option.  I cannot imagine we would do any more than double the current number of events in the extreme situation.  I have also begun to think about these events, perhaps undocking, PDI, landing, liftoff, and docking to start could be appropriate event functions.  Other than aborts I wouldn't know what else to add until I dive deeper into this.

Yeah, docking and touchdown events are what are probably most relevant.

Quote
Now since we do not do any comm checks, would it even be necessary to do the IVT comm powerup and powerdown?  Or should I create those for the sake of accuracy?

Yeah, I would add it. Who knows, maybe one day the comm checks are functional in some way. That's why I would always try to create the checklist that would apply to the real spacecraft. That logic probably breaks down with the AGS at the moment, but most other functional and non-functional switches/CBs etc. should be added to the activation checklist.


Title: Re: LM status...
Post by: rcflyinghokie on October 20, 2016, 11:03:41 AM
So now I realize it finds the switches but it actually doesn't change the position of them.  If it is in the correct position it automatically moves to the next, however if the switch is in the incorrect position, it just freezes until the user changes the switch.


Title: Re: LM status...
Post by: indy91 on October 20, 2016, 11:34:09 AM
Well, clearly the auto execution function isn't working. I think I know what is going on there. The autoexecute variable isn't actually saved. In the CSM that's not necessary, it is loaded from the config file each time, which can be changed with the ProjectApolloConfigurator in the Orbiter Launchpad. So the LEM forgets about the setting and uses the default. Auto execution does work in the LM in general though. Something that is also not loaded from the config is the slow auto execution, so it sets all switches at once. What do you prefer? Deleting the LEMCHECKAUTO parameter entirely and loading everything from the config? That way you can't have a separate auto execution setting for the LM. If everything is loaded from the config, then it will work like in the CSM.


Title: Re: LM status...
Post by: rcflyinghokie on October 20, 2016, 02:34:00 PM
Well, clearly the auto execution function isn't working. I think I know what is going on there. The autoexecute variable isn't actually saved. In the CSM that's not necessary, it is loaded from the config file each time, which can be changed with the ProjectApolloConfigurator in the Orbiter Launchpad. So the LEM forgets about the setting and uses the default. Auto execution does work in the LM in general though. Something that is also not loaded from the config is the slow auto execution, so it sets all switches at once. What do you prefer? Deleting the LEMCHECKAUTO parameter entirely and loading everything from the config? That way you can't have a separate auto execution setting for the LM. If everything is loaded from the config, then it will work like in the CSM.

Initially I wanted things to be like the CSM, minimize settings and such.  But then I got to thinking, if you jump into the LM and its on AUTO from the CSM, it could start throwing switches you do not want, so perhaps a separate auto for each spacecraft would be prudent if that makes sense.


Title: Re: LM status...
Post by: indy91 on October 20, 2016, 03:02:41 PM
I wouldn't consider the automatic checklist execution the default mode, most people will use that maybe for their 10th time going through the prelaunch procedure. But usually the Checklist MFD is used simply as an aid to find switches, that's what it is useful for the most.

Anyway, I think I'll not modify the configurator right now. There is already a separate config file for the LM, but it is always identical to the CSM. Instead I will simply save the CHECKLISTAUTODISABLED and VAGCCHECKLISTAUTOENABLED parameters in the LM.


Title: Re: LM status...
Post by: rcflyinghokie on October 20, 2016, 09:39:23 PM
I wouldn't consider the automatic checklist execution the default mode, most people will use that maybe for their 10th time going through the prelaunch procedure. But usually the Checklist MFD is used simply as an aid to find switches, that's what it is useful for the most.

Oh I would hope not.  I was just considering the fact that sometimes I get lazy and leave a checklist to complete while still in auto, I was thinking if I switch to the LM while its maybe between checklists in the CM it would inadvertently automatically start a checklist in the LM that I am not ready to begin.


Title: Re: LM status...
Post by: indy91 on October 21, 2016, 04:37:06 AM
You are right and I have done that before, too, when I opened an older scenario and it suddenly executed the startup checklist. That's what Jim Lovell did during Apollo 8, right?  :ROTFL3453:

The checklist auto execution parameter for the LM is now saved and loaded. In the future, this might be handled with the configurator. Then the whole sequence of giving the LEMCHECKAUTO aparameter to the LM can be removed, too. The ChecklistAutoSlow parameter is now loaded from the config file for the LM, too. I never really use the option to automatically set all switches immediately.


Title: Re: LM status...
Post by: rcflyinghokie on October 21, 2016, 07:03:36 AM
The checklist auto execution parameter for the LM is now saved and loaded. In the future, this might be handled with the configurator. Then the whole sequence of giving the LEMCHECKAUTO aparameter to the LM can be removed, too. The ChecklistAutoSlow parameter is now loaded from the config file for the LM, too. I never really use the option to automatically set all switches immediately.

So will this fix work on open LM scenerios?


Title: Re: LM status...
Post by: indy91 on October 21, 2016, 10:49:17 AM
Not quite sure which parameter you mean. The slow execution parameter is loaded from the config file. If an old scenario with the LM is loaded that doesn't have any value for the automatic execution parameter saved, then it uses "false" by default, so no automatic execution.


Title: Re: LM status...
Post by: rcflyinghokie on October 21, 2016, 03:39:36 PM
Not quite sure which parameter you mean. The slow execution parameter is loaded from the config file. If an old scenario with the LM is loaded that doesn't have any value for the automatic execution parameter saved, then it uses "false" by default, so no automatic execution.

That is exactly the answer I was looking for.  I haven't been able to try it yet but I plan on verifying all of the switches work and then basically duplicating the A12 activation and lm guidance checklists in a similar fashion as our csm default checklist.


Title: Re: LM status...
Post by: rcflyinghokie on October 22, 2016, 08:53:34 AM
So with these new changes, what all needs to be in the scn file to make sure this works?  Right now I have these two lines but I am not sure about the second.
Code:
 
LEMCHECK Doc\Project Apollo - NASSP\Checklists\LM Default Checklists.xls
 
LEMCHECKAUTO 1


Title: Re: LM status...
Post by: indy91 on October 22, 2016, 09:02:05 AM
These parameters should work for the launch scenario or any scenario before the LM is created. Then the LM checklist will be saved with the parameter FILE as part of the checklist controller. I have simply copied over the load function for the config file, so in the LM itself it is not saved as LEMCHECKAUTO but as VAGCCHECKLISTAUTOENABLED.


Title: Re: LM status...
Post by: rcflyinghokie on October 22, 2016, 09:13:01 AM
These parameters should work for the launch scenario or any scenario before the LM is created. Then the LM checklist will be saved with the parameter FILE as part of the checklist controller. I have simply copied over the load function for the config file, so in the LM itself it is not saved as LEMCHECKAUTO but as VAGCCHECKLISTAUTOENABLED.

So I should keep both of the lines I mentioned in the launch scenario correct?  I am just making sure I am not adding unnecessary lines or not including appropriate ones :P


Title: Re: LM status...
Post by: indy91 on October 22, 2016, 09:21:53 AM
Well, at least the LEMCHECK parameter should be in the launch scenarios for Apollo 9+. LEMCHECKAUTO isn't really necessary, right? Once the default LM checklist for lunar missions is ready, I'll add it to the launch scenarios in the repository. Apollo 9 might be fairly non-standard, I think, so the default checklist would not apply.


Title: Re: LM status...
Post by: rcflyinghokie on October 22, 2016, 10:17:26 AM
Well, at least the LEMCHECK parameter should be in the launch scenarios for Apollo 9+. LEMCHECKAUTO isn't really necessary, right?

Thats what I was asking, from what you said it doesnt appear to be anymore so i was just verifying.  I am running a new A9 right now to make sure it works without LEMCHECKAUTO.


Title: Re: LM status...
Post by: indy91 on October 22, 2016, 10:26:57 AM
All parameters in the scenario have some sort of default value. If the parameter isn't specified, then that default value will be used. So without LEMCHECKAUTO it will use the default, which is no auto execution. It's just giving that parameter to the LM that wasn't working yet until yesterday. So no reason to test a launch scenario with LEMCHECK, but without LEMCHECKAUTO. LEMCHECKAUTO should probably only be set to true, if we want to automate the LM. That should rather be specified in the configurator anyway.


Title: Re: LM status...
Post by: rcflyinghokie on October 22, 2016, 10:31:45 AM
All parameters in the scenario have some sort of default value. If the parameter isn't specified, then that default value will be used. So without LEMCHECKAUTO it will use the default, which is no auto execution. It's just giving that parameter to the LM that wasn't working yet until yesterday. So no reason to test a launch scenario with LEMCHECK, but without LEMCHECKAUTO. LEMCHECKAUTO should probably only be set to true, if we want to automate the LM. That should rather be specified in the configurator anyway.

Ok I think I am understanding now.  I just wanted to make sure when I get to the LM part the autoexecution is working for this test of the switches.


Title: Re: LM status...
Post by: indy91 on October 22, 2016, 10:35:06 AM
To test that put

Code:
LEMCHECKAUTO 1

in the launch scenario and if it does the auto execution hours later after TD&E is done, then we know it is working. Of course don't forget LEMCHECK itself.


Title: Re: LM status...
Post by: rcflyinghokie on October 22, 2016, 11:41:53 AM
Looks like all of the switches other than ordeal ones work with the checklist :)  Now I just need to make the checklists and test them.  Are the DSKY commands for the LM going to be the same as the CSM in regards to the checklist file?


Title: Re: LM status...
Post by: rcflyinghokie on October 23, 2016, 10:44:59 AM
So I have made a few default switch changes to the LEM files to match the initialization checklist.  I also have discovered all of my switches work however many do not flash when they come up even though they react to the position set forth by the checklist.  How would I fix this?


Title: Re: LM status...
Post by: indy91 on October 23, 2016, 11:02:02 AM
Looks like all of the switches other than ordeal ones work with the checklist :)  Now I just need to make the checklists and test them.  Are the DSKY commands for the LM going to be the same as the CSM in regards to the checklist file?

DSKY should work. DEDA shouldn't be too much of a problem to implement either.

So I have made a few default switch changes to the LEM files to match the initialization checklist.  I also have discovered all of my switches work however many do not flash when they come up even though they react to the position set forth by the checklist.  How would I fix this?

Do you have an example switch for that? I'm sure that there is simply no flashing border defined for these switches.


Title: Re: LM status...
Post by: rcflyinghokie on October 23, 2016, 02:10:48 PM
Do you have an example switch for that? I'm sure that there is simply no flashing border defined for these switches.

That would make sense as the switches do change based on the setting.  I don't have the switch name handy I am not home, but one I recall is the ED master arm switch.

EDIT:  I attached my checklist file, look under LM Activation, everything highlighted yellow does not flash.


Title: Re: LM status...
Post by: indy91 on October 24, 2016, 06:12:40 AM
Looks like one of the border types (34x39) didn't have its bitmap loaded, so it's just two lines of code that need to be added. This will fix it for quite a few switches. A few of the audio switches also don't have flashing borders defined yet. Either because the correct border size for them hasn't been chosen yet, or because a border with the correct size doesn't exist yet as a bitmap.


Title: Re: LM status...
Post by: rcflyinghokie on October 24, 2016, 12:39:48 PM
I need a little bit of input for a few checklist items on the LM:

1)  Since we do not have any gyro bias, am I to omit V21N01 1462E from the LM checklists?
2)  The coarse align of the LM still gets screwed up by our V40 N20.  I am thinking I will just use a V42 with zeros in R1-R3 to enable fine align for the checklist in the mean time until this is fixed, any objections?
3)  Many switches/panels still do not exist, should I just place them in the checklist as text for now until switches are implemented (like suit gas diverter or cabin repress valve etc)
4)  Other than the gyro bias and of course the V40, are there any "gotcha's" in the A12 checklist that would be Apollo 12 specific and therefore not needed or need to be changed for other LM missions?


Title: Re: LM status...
Post by: indy91 on October 24, 2016, 01:32:36 PM
1)  Since we do not have any gyro bias, am I to omit V21N01 1462E from the LM checklists?

Yeah, we don't need that in the checklist. It's a strange item, the number loaded as NBDZ in the checklist is the same as metioned in the mission report for the "flight load". The checklist page with NBDZ was changed on Nevember 5th, 9 days before the flight. So maybe a wrong number was loaded in the erasable memory before launch. 9 days is plenty of time to change it though, the pad load is only valid for the daily launch window. Unlikely but possible is a bug in the Luminary version flown on Apollo 12, that somehow loads a false number in NBDZ during AGC activation.

Quote
2)  The coarse align of the LM still gets screwed up by our V40 N20.  I am thinking I will just use a V42 with zeros in R1-R3 to enable fine align for the checklist in the mean time until this is fixed, any objections?

Didn't have time yet to work on this again. I still plan to fix it, but you can use V42 for now.

Quote
3)  Many switches/panels still do not exist, should I just place them in the checklist as text for now until switches are implemented (like suit gas diverter or cabin repress valve etc)

Yes, adding the text for it already is a good idea.

Quote
4)  Other than the gyro bias and of course the V40, are there any "gotcha's" in the A12 checklist that would be Apollo 12 specific and therefore not needed or need to be changed for other LM missions?

On page ACT-38 the padloaded gimbal trim angles have to be 6° and 6°. 6° is along the centerline, which it should be until variable CoG is implemented. The gimbal trim procedure is already functional. Weights are of course also going to be slightly different. Most of the differences will be after undocking, so the Apollo 12 activation checklist is mostly ok.


Title: Re: LM status...
Post by: lotisully86 on October 24, 2016, 03:45:54 PM
In coarse aligning the icdu, this may have already been mentioned but what about using V40 without the N20? I'm fairly certain this is in the apollo 15 cmc gnc procedures, and if I recall correctly this will not zero the fdai angles. Will confirm that later on, but that would solve the issue at hand would it not?

Edit-my apologies this was already mentioned  :Duh!39835:


Title: Re: LM status...
Post by: rcflyinghokie on October 24, 2016, 04:05:40 PM
In coarse aligning the icdu, this may have already been mentioned but what about using V40 without the N20? I'm fairly certain this is in the apollo 15 cmc gnc procedures, and if I recall correctly this will not zero the fdai angles. Will confirm that later on, but that would solve the issue at hand would it not?

A good idea, I have tried it but the LGC we are using right now does not support that particular verb without a noun attached.


Title: Re: LM status...
Post by: rcflyinghokie on October 24, 2016, 04:07:06 PM
I remember we had an issue with spring release switches and doing the checklist MFD with the CSM, now I am having the same problem in the LM where they do not register the temporary position.  How did you all fix that before?

EDIT:  One other thing before I forget, how do I get the LGC Docked Data in the PAMFD for Apollo 9?

EDIT 2:  And another thing, the DSKY commands do not work for the LM like they do in the CSM.


Title: Re: LM status...
Post by: indy91 on October 25, 2016, 06:15:17 AM
I remember we had an issue with spring release switches and doing the checklist MFD with the CSM, now I am having the same problem in the LM where they do not register the temporary position.  How did you all fix that before?

The problem with springloaded switches is when they are set by the checklist controller, then they spring back to the their default position before a complete panel timestep was run. So the systems have then never recognized it ever left the default position. The solution is to introduce an artificial delay (usually 1 second) before the switch can reset itself. This delay is then only the case when used by the checklist controller.

This probably is the case for all springloaded switches, so I'll begin adding the delays to these switches in the LM.

Quote
EDIT:  One other thing before I forget, how do I get the LGC Docked Data in the PAMFD for Apollo 9?

Looks like the PAMFD doesn't recognize all CSM names yet, e.g. it knows about "Gumdrop" but it doesn't recognize "AS-504", which is the default name for the CSM for Apollo 9.

Quote
EDIT 2:  And another thing, the DSKY commands do not work for the LM like they do in the CSM.

Yeah, looks like the DSKY in the LM is still implemented in an "old" way. I'll see what I can do about that.


Title: Re: LM status...
Post by: rcflyinghokie on October 25, 2016, 09:10:16 AM
Awesome thanks, I wish I had a little more knowledge to hunt for these issues myself.  I am almost up to undocking on the activation checklist, then I am going to make the sub checklists using the LM gnc checklists.  The only checklist I am omitting right now is the AGS because I do not know what commands to use for the DEDA yet.


Title: Re: LM status...
Post by: indy91 on October 25, 2016, 09:20:33 AM
Ok, I have pushed the update:

-PAMFD should now recognize vessels called AS-504, AS-505 and AS-506 (Apollo 9-11). So the docked alignment angles should work now for Apollo 9.
-I added the time delay to a bunch of springloaded switches in the LM. I don't want to add it to all of them, because it isn't necessary for e.g. the RR slew switch. But I probably have forgotten some switches that should have the delay anyway.
-I have updated the DSKY buttons to how it works in the CSM. I haven't tried it with the Checklist MFD though. I also had to slightly move the panel area for the DSKY keys, so if it somehow looks wrong now, please let me know. Both the automatic execution and the flashing border for the DSKY keys should now work.


Title: Re: LM status...
Post by: rcflyinghokie on October 25, 2016, 09:38:46 AM
-I have updated the DSKY buttons to how it works in the CSM. I haven't tried it with the Checklist MFD though. I also had to slightly move the panel area for the DSKY keys, so if it somehow looks wrong now, please let me know. Both the automatic execution and the flashing border for the DSKY keys should now work.

The DSKY looks just fine I couldn't discern a change in appearance.  And a trivial matter but for completion, the DSKY keys do work but they do not flash.


Title: Re: LM status...
Post by: indy91 on October 25, 2016, 09:47:06 AM
The bitmap for the 38x38 DSKY key border wasn't in the resource file. Hopefully it should work now.


Title: Re: LM status...
Post by: rcflyinghokie on October 25, 2016, 10:04:10 AM
The bitmap for the 38x38 DSKY key border wasn't in the resource file. Hopefully it should work now.

I'll give it a spin shortly.

I did want to see if you could clarify a switch for me, the TTCA (CDR) and (LMP) switches.  Are they implemented in the LM?  And where are they supposed to be?

EDIT:  I found this line which seems to be what I am looking for, but how do we use this in the LM?

Code:
int ttca_mode;                        // TTCA Throttle/Jets Mode
#define TTCA_MODE_THROTTLE 0
#define TTCA_MODE_JETS 1
int ttca_throttle_pos;                // TTCA THROTTLE-mode position
double ttca_throttle_pos_dig;  // TTCA THROTTLE-mode position mapped to 0-1
int ttca_throttle_vel;
double ttca_thrustcmd;
int js_current;


Title: Re: LM status...
Post by: indy91 on October 25, 2016, 10:52:05 AM
All it does is disable TTCA commands. That is implemented, but only for the CDR switches. So currently the assumption is that the user is controlling the CDR ACA and TTCA. Although now that I have looked at the AOH again, I am not entirely sure if this also disables throttle commands. These maybe should still be enabled even wth the TTCA switch set to disabled.


Title: Re: LM status...
Post by: rcflyinghokie on October 25, 2016, 10:56:53 AM
All it does is disable TTCA commands. That is implemented, but only for the CDR switches. So currently the assumption is that the user is controlling the CDR ACA and TTCA. Although now that I have looked at the AOH again, I am not entirely sure if this also disables throttle commands. These maybe should still be enabled even wth the TTCA switch set to disabled.

This may shed some light on it's function https://www.hq.nasa.gov/alsj/lm_ttca_en.jpg  Its also described here: https://www.ibiblio.org/apollo/Documents/LMA790-3-LM-2.1.pdf

I think we should leave it on jets and use the separate throttle controller I think that is how it is programmed?

Also I am not talking about the TTCA Enable Switch just to clarify :)


Title: Re: LM status...
Post by: indy91 on October 25, 2016, 11:09:42 AM
Oh you mean the lever on the TTCA itself. Yes, I have implemented that, although I can't really recommend using a joystick for the TTCA. In JETS mode the TTCA basically works like a THC in the CM. In THROTTLE mode it works exactly like in the picture, with the X-axis as the throttle. If you use a joystick, then its throttle lever is implemented as the Throttle/Jets select lever. As you can imagine the throttle is difficult to control with a normal joystick. That's why there are three cheaty options for controlling the throttle. If no joystick is connected, the normal controls for a hover engine can be used, both in rotation and translation mode. And in my personally recommended configuration with a joystick as a the ACA, the throttle lever there can also be used.

So the switch you are talking about is only used if a joystick is selected as the TTCA in the configurator.


Title: Re: LM status...
Post by: rcflyinghokie on October 25, 2016, 11:18:57 AM
Oh you mean the lever on the TTCA itself. Yes, I have implemented that, although I can't really recommend using a joystick for the TTCA. In JETS mode the TTCA basically works like a THC in the CM. In THROTTLE mode it works exactly like in the picture, with the X-axis as the throttle. If you use a joystick, then its throttle lever is implemented as the Throttle/Jets select lever. As you can imagine the throttle is difficult to control with a normal joystick. That's why there are three cheaty options for controlling the throttle. If no joystick is connected, the normal controls for a hover engine can be used, both in rotation and translation mode. And in my personally recommended configuration with a joystick as a the ACA, the throttle lever there can also be used.

So the switch you are talking about is only used if a joystick is selected as the TTCA in the configurator.

Got it, so in my checklist I am just going to leave the TTCA - JETS for completion, but not have it actually do anything since we have a workaround as it is.


Title: Re: LM status...
Post by: rcflyinghokie on October 25, 2016, 11:53:54 AM
So the delay that was added in those spring loaded switches places them in the temporary position now but doesn't return them to center.  For example, SYS A QUAD 1 - ENABLE flips it into position 2 and instead of returning it stays there unless the user clicks it manually after the fact.  Also the battery switches do not have the delay and they do need them.


Title: Re: LM status...
Post by: indy91 on October 26, 2016, 06:39:52 AM
I have added the delay for the battery switches and solved the problem with springloaded switches not resetting. The LM MainPanel timestep function wasn't used yet. I first thought this might cause every switch being processed twice or something like that, but it seems the timestep function itself mostly does houskeeping for the checklist controller, e.g. it keeps track when a time delay is over and a switch is supposed to be reset. But I might have missed something, so if there is any unexpected behavior now, please let me know.


Title: Re: LM status...
Post by: rcflyinghokie on October 26, 2016, 07:10:28 AM
I have added the delay for the battery switches and solved the problem with springloaded switches not resetting. The LM MainPanel timestep function wasn't used yet. I first thought this might cause every switch being processed twice or something like that, but it seems the timestep function itself mostly does houskeeping for the checklist controller, e.g. it keeps track when a time delay is over and a switch is supposed to be reset. But I might have missed something, so if there is any unexpected behavior now, please let me know.

So the battery switches physically move but they aren't changing the tb indicators when switched by the auto checklist, the physical switch is moving but its result is not registered if that makes sense.  And upon review that seems to be the case with all of the spring loaded switches in the LM.


Title: Re: LM status...
Post by: indy91 on October 26, 2016, 07:43:20 AM
As I said before the checklist controller uses a backdoor, a different function to set the switches. Turns out the function to set a switch manually sometimes contains some additional code in the LM, e.g. for the RCS Main SOV switches it additionally checks the status of the valves and sets the TB indicator to the correct state, if it was changed. So that will be rather annoying to fix. A slow process of moving these additional functions to the appropiate subsystems, so that setting a switch really is just setting a switch.

EDIT: Actually, it might not be so bad. A bunch of LM switch use "CheckMouseClick", which the Checklist MFD doesn't like. But it is probably possible to move things to "SwitchTo", which is actually useful for the checklist controller.


Title: Re: LM status...
Post by: rcflyinghokie on October 26, 2016, 07:49:13 AM
As I said before the checklist controller uses a backdoor, a different function to set the switches. Turns out the function to set a switch manually sometimes contains some additional code in the LM, e.g. for the RCS Main SOV switches it additionally checks the status of the valves and sets the TB indicator to the correct state, if it was changed. So that will be rather annoying to fix. A slow process of moving these additional functions to the appropiate subsystems, so that setting a switch really is just setting a switch.

No problem, the LM needs a lot of work as it is so that will come in time.  Just wish I was savvy enough to fix that :)

EDIT:  You probably already know this, but the registering of the switch isn't just the spring loaded ones.  The INV switch for example doesn't turn on the inverter when the checklist controller flips the switch but it works when you do it by hand.


Title: Re: LM status...
Post by: indy91 on October 26, 2016, 11:44:30 AM
As mentioned in my EDIT above, I have now changed the function used to set a few LM specific switches from "CheckMouseClick" to "SwitchTo". This was changed for CSM specific switches at some point, too, so I feel comfortable changing this.

@rcflyinghokie, if you want to test it for me, the switches that should now work both automatically with the checklist controller and manually are the 12 battery switches, the Deadface switch, the Inverter switch, the 2 RCS Main SOV switches and the 4 Mission Timer switches. Please also check if they are not only set optically, but actually are functional as intended.


Title: Re: LM status...
Post by: rcflyinghokie on October 26, 2016, 12:18:01 PM
@rcflyinghokie, if you want to test it for me, the switches that should now work both automatically with the checklist controller and manually are the 12 battery switches, the Deadface switch, the Inverter switch, the 2 RCS Main SOV switches and the 4 Mission Timer switches. Please also check if they are not only set optically, but actually are functional as intended.

Looks like the battery switches are functioning properly, there is a debug line on the bottom saying "newstate #", however the DES BAT connect/deadface switch and inverter switches now do not function even clicking them by hand.  The Main SOV valves appear to be working and moving the TB indicators, but I have not tested their function completely.

EDIT:  Have not tested all timer switches yet, need to add them to the checklist first, will report back.


Title: Re: LM status...
Post by: indy91 on October 26, 2016, 12:41:10 PM
Debug line has been removed, inverter and deadface switches should now work again. Note that the deadface switch only works, when the ASC ECA CONT circuit breaker is in.


Title: Re: LM status...
Post by: rcflyinghokie on October 26, 2016, 01:03:27 PM
Debug line has been removed, inverter and deadface switches should now work again. Note that the deadface switch only works, when the ASC ECA CONT circuit breaker is in.

Ah yes I did forget that.

And for the event and mission timer switches, they are still not working properly.


Title: Re: LM status...
Post by: indy91 on October 26, 2016, 01:19:04 PM
And for the event and mission timer switches, they are still not working properly.

That's a little bit unspecific. What is not working? Manually setting them? Automatically setting them? The time delay for the springloaded switches? Because manually they are all working fine for me and I haven't changed anything about the event timers. I have pushed a small change to the Mission Timer, which doesn't change the functionality. I also pushed the time delay for the Mission Time control switch, which I had forgotten.

What is still missing is the dummy switch to set the event timer to any desired value in the checklist file. The Mission Timer probably doesn't need that function, it needs to be set to the right time by hand.


Title: Re: LM status...
Post by: rcflyinghokie on October 26, 2016, 01:29:09 PM
That's a little bit unspecific. What is not working? Manually setting them? Automatically setting them? The time delay for the springloaded switches? Because manually they are all working fine for me and I haven't changed anything about the event timers. I have pushed a small change to the Mission Timer, which doesn't change the functionality. I also pushed the time delay for the Mission Time control switch, which I had forgotten.

You are right I apologize, it was a quick message I had something going on.  They are not responding to the auto checklist.

To be specific, EventTimerCtlSwitch and EventTimerStartSwitch work, EventTimerMinuteSwitch and EventTimerSecondSwitch work manually but they do not move with the auto checklist.  For the mission timer, none of the switches respond to the auto checklist.





Title: Re: LM status...
Post by: indy91 on October 26, 2016, 01:54:57 PM
I haven't even added the time delay to the minute/second switches in the CSM. What do you need them for? If you want to set a specific mission or event time, then I can add dummy switches. That's easier than something like 9x the seconds switch to up.

If you wanted to test them because I told you to, then it's all my fault.  :yes77: I never intended to make the springloaded hour/minute/seconds switches functional with the auto execution.


Title: Re: LM status...
Post by: rcflyinghokie on October 26, 2016, 02:37:49 PM
If you wanted to test them because I told you to, then it's all my fault.  :yes77: I never intended to make the springloaded hour/minute/seconds switches functional with the auto execution.

That's why I was going to test them :P  They weren't even in my checklist.  Yeah they should be manually controlled.  Now the event timer if we could set it up like the CSM where we can automatically set timers would be nice ;)


Title: Re: LM status...
Post by: dseagrav on October 28, 2016, 06:32:29 AM
How many of you have uncommitted LM work for the master branch, and how much of it is there? We're close to where we can start closing out master and making our V7 release. At the same time this happens I will change the Orbiter2015 branch to V8 beta, and new development work should move there.



Title: Re: LM status...
Post by: indy91 on October 28, 2016, 06:41:46 AM
I have nothing specifically for the LM. I still have unfinished IMU changes though. Still haven't figured out the correct way to implement the ICDU Zero (Verb 40) that doesn't coarse align the IMU. I would gladly give this task to someone else though. A proper implementation requires some good knowledge of data types, so that the error and read counters in the CDU and the CDU registers in the AGC are properly done. I don't feel qualified for this task, it's not really my cup of tea. I will open an issue on Github for it though. It's not a problem for any normal procedure in the CSM, so I'll set it as required for the next release.

EDIT: Here it is: https://github.com/dseagrav/NASSP/issues/28


Title: Re: LM status...
Post by: rcflyinghokie on October 28, 2016, 08:04:39 AM
The only uncommitted project I have is a checklist for Apollo 9 and the LM Checklist, both are still very much under construction.


Title: Re: LM status...
Post by: abr35 on December 20, 2016, 10:57:15 PM
I was testing out some of the improvements made to the LEM back in the fall and I noticed that the vLGC and Orbiter have very different ideas about the size of the moon. When calculating DOI, P30 gives me a PeA of about 11.2nm when in actuality it is closer to 8.4nm. When running P63 the Eagle routinely ploughs into the surface at about -01 15 TGO on Noun 68. I've moved the DOI target around and get consistent results: crashing into the surface short of the landing site usually right after yaw around. My alt/alt rate tape will often give me a 20,000ft difference from what any orbiter MFDs give me, even with a fresh state vector. Is there anyway to change the LGC's understanding of where the surface is located? I know the LEM is very much on the back burner with the upcoming release so any help is appreciated.


Title: Re: LM status...
Post by: indy91 on December 21, 2016, 07:21:01 AM
I was testing out some of the improvements made to the LEM back in the fall and I noticed that the vLGC and Orbiter have very different ideas about the size of the moon. When calculating DOI, P30 gives me a PeA of about 11.2nm when in actuality it is closer to 8.4nm. When running P63 the Eagle routinely ploughs into the surface at about -01 15 TGO on Noun 68. I've moved the DOI target around and get consistent results: crashing into the surface short of the landing site usually right after yaw around. My alt/alt rate tape will often give me a 20,000ft difference from what any orbiter MFDs give me, even with a fresh state vector. Is there anyway to change the LGC's understanding of where the surface is located? I know the LEM is very much on the back burner with the upcoming release so any help is appreciated.

Looks like I never changed the Apollo 11 landing site vector in the launch scenario. The landing site is the Sea of Tranquility, which is a very low region as compared to the mean radius of the moon. The mean radius of the Moon is what we use for the spherical Orbiter 2010 Moon. And the launch scenario still has the actual landing site vector from the Apollo 11 LGC padload document. The LGC then calculates its altitude as compared to the landing site vector, which explains the altitude difference between Surface MFD and the LGC.

But even then, did you not activate the landing radar? It's already functional and should help with the difference. I think I once tried a scenario with the actual landing site vector and the landing radar saved me.

If you want to change your scenario shortly before PDI, use these EMEMs for a landing site vector with the correct radius:

EMEM2022 302
EMEM2023 25000
EMEM2024 124
EMEM2025 13650
EMEM2026 2
EMEM2027 21356

But change this in the LM, not accidentally in the CSM.  :ROTFL3453:
 


Title: Re: LM status...
Post by: abr35 on December 21, 2016, 09:27:15 AM
Landing radar cb was in. Got a program alarm. I think the radar was trying to feed data or change to the hover position before the lgc expected it? It would begin at 40k which the lgc would consider 60k. Got a recurring landing radar antenna changed alarm, even when in pos 1.  My h-dot was low, but it should not have been. Did V57 (maybe too late?) but didn't save me from making new craters haha. Ill give the new emems a try later this week. What fov should the AOT screen be set for? I've had to realign the imu with the coas.


Title: Re: LM status...
Post by: rcflyinghokie on December 21, 2016, 09:54:19 AM
What was the alarm?  I know when I was working the LM last mine kept failing the LR test and would not work properly (threw program alarms not in commanded position) during PDI unless I loaded Indy's PDI file, even with the proper EMEM's


Title: Re: LM status...
Post by: abr35 on December 21, 2016, 12:51:04 PM
What was the alarm?  I know when I was working the LM last mine kept failing the LR test and would not work properly (threw program alarms not in commanded position) during PDI unless I loaded Indy's PDI file, even with the proper EMEM's

Same as yours: 522 alarm.


Title: Re: LM status...
Post by: eddievhfan1984 on December 21, 2016, 06:04:00 PM
522 just means the LR is in the wrong position (i.e., if this in P63, it should be in position 1/DES, but the computer thinks it's in position 2/HOVER). Try flipping the LR switch from AUTO to DES then back to AUTO. That might clear the issue and allow LR updating.

Just read the post further down. So if the LR is in manual DES during P63 and you're still getting the program alarm, that might mean some flag is getting locked in for some reason...


Title: Re: LM status...
Post by: rcflyinghokie on December 21, 2016, 09:42:33 PM
522 just means the LR is in the wrong position (i.e., if this in P63, it should be in position 1/DES, but the computer thinks it's in position 2/HOVER). Try flipping the LR switch from AUTO to DES then back to AUTO. That might clear the issue and allow LR updating.

Just read the post further down. So if the LR is in manual DES during P63 and you're still getting the program alarm, that might mean some flag is getting locked in for some reason...

Yeah I think there is a lot in this thread of me explaining the issues with this, I never was able to get it resolved.  I also had the same problem in the LR test in the Apollo 9 scn when I started writing Checklist MFD files for the LM.


Title: Re: LM status...
Post by: eddievhfan1984 on December 21, 2016, 10:01:26 PM
So, was it a chain of 522s right down the 05 09 display, or did you only get the one after the RADARUPT routine started (DSKY blank on crossing 50-60k)?


Title: Re: LM status...
Post by: rcflyinghokie on December 21, 2016, 11:41:58 PM
So, was it a chain of 522s right down the 05 09 display, or did you only get the one after the RADARUPT routine started (DSKY blank on crossing 50-60k)?

I had the chain both in the PDI and in the LR test if I recall, I will try it again tomorrow and get a better answer for you.


Title: Re: LM status...
Post by: indy91 on December 22, 2016, 07:13:28 AM
At this point it seems more plausible to me that there is something wrong with our Landing Radar. Probably some changes I made for it to work at all, "fixing" the RADARUPT problems we had. The only functional scenario we have is the one I created BEFORE a lot of the changes that made the lunar landing possible. So maybe something is just different in that scenario, because it is older, and that's why it works.

I'll probably tackle this issue again early next year.


Title: Re: LM status...
Post by: abr35 on December 22, 2016, 12:53:10 PM
Yes it was a chain of 522s. I'm gonna compare the scenario files and see if I can fix it. Maybe it isn't the AGC but something "mechanical"? My PDI file has no LEM_LR_START section. When does that get written into the scenario file?

Edit: Disregard it was there. Copying EMEM0375 and 0376 from the PDI scenario removed the alarm issue. I'm still crashing into the surface: now a few moments after pitchover. Through P64 the PGNS and LR agree closely. After pitchover, the PGNS and LR can agree by as much as 10,000 feet.


Title: Re: LM status...
Post by: eddievhfan1984 on December 22, 2016, 02:45:03 PM
Yeah, EMEM0375 and 0376 are just the alarm storage flags—resetting after the detected errors doesn't do anything?


Title: Re: LM status...
Post by: indy91 on December 22, 2016, 03:08:18 PM
@abr35? Did you use the current Apollo 11 scenario for your Apollo 11 mission or some scenario posted in this forum? Also, was it the LVDC++ scenario or the other scenario in the "Virtual AGC" folder that I have now deleted? Because I think I remember that the non-LVDC++ scenario never got the update where I fixed a few typos of mine, including one important padload for P64.

Can you post your scenario before PDI here? I want to have a look at it


Title: Re: LM status...
Post by: abr35 on December 22, 2016, 03:56:18 PM
This scenario is based on either the Post Undocking scenario in this thread. I changed EMEM2023 from 25000 all the way up to 37000. It's still not high enough but it gives me ample time to accept the radar and land safely. Delta-H still doesn't seem entirely accurate but if I accept the radar data at yaw around or higate everything works out fine now. Still get the 522 but radar and altitude velocity lights work and P65 lands safely. Managed to land manually too but the auto throttle tends to fire up in P66 at contact and the LEM does a "touch and go." Scenario attached. DOI is a tad off, had trouble with the RTCC MFD as I described earlier. About 1.5-2km too high and a small cross range error. AGC adjusts just fine.

Internet keeps crashing. Been having trouble lately. Ill try and upload later.


Title: Re: LM status...
Post by: indy91 on December 22, 2016, 04:28:28 PM
Actually, I think the Post Undocking scenario I posted still has the padload issues. Here is a version of it where I (hopefully) have fixed all the issues, including the P64 issue. Among other issues the TENDAPPR variable was missing from the scenario. This variable should be set to 12 seconds, which is the guidance time (time until the targeted point is reached) when P64 is supposed to switch to the next program. If it is 0 then the LM will fly all the way to the targeted point and it would do some pretty extreme steering towards the end.

I will also fix your pre PDI scenario when you have posted it and then we'll see if that helps with anything.

EDIT: Also I would suggest doing a clock update with PAMFD, because iirc the clock is way off.


Title: Re: LM status...
Post by: abr35 on December 24, 2016, 09:19:53 PM
I managed to land with the updated post undocking scenario. There is no 522 alarm and the LR passed the self-test successfully. I typed up a very rough landing procedure from undocking to touchdown based on the Apollo 11 flight plan and LM11 AOH (with not yet functional procedures bracketed) and I will try to get it up on the wiki after doing some clean up and proofreading after the holiday. The only issue I noticed was that occasionally an auto maneuver would be targeted the wrong way (+/- 180 deg yaw), so my RR test and sun check failed the first time, but I did get successful results more often than not.

Took a few tries to even post that message so still can't get the scenario up yet  :ROTFL3453:.


Title: Re: LM status...
Post by: indy91 on December 25, 2016, 07:37:16 AM
I managed to land with the updated post undocking scenario. There is no 522 alarm and the LR passed the self-test successfully.

This is about as much as you can currently expect to achieve.

Quote
I typed up a very rough landing procedure from undocking to touchdown based on the Apollo 11 flight plan and LM11 AOH (with not yet functional procedures bracketed) and I will try to get it up on the wiki after doing some clean up and proofreading after the holiday.

There is a document detailing this timeframe: http://hdl.handle.net/2060/19700025215 I'm sure this will also help with your procedures.

Quote
The only issue I noticed was that occasionally an auto maneuver would be targeted the wrong way (+/- 180 deg yaw), so my RR test and sun check failed the first time, but I did get successful results more often than not.

A V49 auto maneuver did that? Be aware that the input for the LGC is not FDAI angles (Noun 18: roll, pitch, yaw) but ICDU angles (Noun 22: Yaw, Pitch, Roll). The LGC then does the conversion to FDAI angles. That can be slightly confusing.


Title: Re: LM status...
Post by: rcflyinghokie on December 25, 2016, 09:23:01 AM
Do you know what changes would have fixed the LR from all the 522's I was getting before on a new scn?


Title: Re: LM status...
Post by: indy91 on December 25, 2016, 11:22:38 AM
None of the changes I made to the Post Undocking scenario have something to do with the LR. My theory that an old scenario, created before the implemention of some systems, works better doesn't seem to be the case now that @abr35 had a good landing. So no idea really, it's either a user error (or rather a procedure we haven't fully understood yet) or something about our implemention of the LR is inconsistent.


Title: Re: LM status...
Post by: rcflyinghokie on December 26, 2016, 10:28:06 AM
None of the changes I made to the Post Undocking scenario have something to do with the LR. My theory that an old scenario, created before the implemention of some systems, works better doesn't seem to be the case now that @abr35 had a good landing. So no idea really, it's either a user error (or rather a procedure we haven't fully understood yet) or something about our implemention of the LR is inconsistent.

I am away for the holidays right now but when I get back I am going to bring back my A9 work and see if I can get some more testing of those checklists complete.  I know I was having the same issues on 9 as I was on the A11 scns we played with during the landing experiments, I will compile a list and some scn files to look at.


Title: Re: LM status...
Post by: abr35 on December 26, 2016, 06:37:27 PM
Second time through while proofreading the procedure I did a RR test after my LR test. Ran into the 522 alarm at PDI. Backed out and tried again with a LR test before PDI. Got an ALT lt as opposed to a 522. Everything went smoothly after that. I wonder if V63 Option 2 sets some flag involving the antenna position?

I can only acquire Columbia and get RR data to the LGC by using the docking HUD to boresight the CSM.  P20 goes through an endless search pattern even with the CSM right on the +Z axis. So I'm going to omit those parts for now. Unless the RR should be more functional then that?


Title: Re: LM status...
Post by: indy91 on December 26, 2016, 07:14:39 PM
Second time through while proofreading the procedure I did a RR test after my LR test. Ran into the 522 alarm at PDI. Backed out and tried again with a LR test before PDI. Got an ALT lt as opposed to a 522. Everything went smoothly after that. I wonder if V63 Option 2 sets some flag involving the antenna position?

What checklist are you using? I think I have mentioned it a few times in this thread, careful with the Apollo 12 checklist concerning the LR. Verb 59 doesn't exist in Luminary 099 (Apollo 11) but it is Verb 60 instead. I doubt it, but maybe that is causing the problem? The Apollo 11 Descent/Ascent document I linked above has the correct procedure in section 2.3 page 9. Looks basically identical, just with the Verb 60 instead. I'll have a look at the implementation of the LR position switch again, looks a little bit too simple to me...

EDIT: Can you attach scenarios again? I could use one with the LR problem...

Quote
I can only acquire Columbia and get RR data to the LGC by using the docking HUD to boresight the CSM.  P20 goes through an endless search pattern even with the CSM right on the +Z axis. So I'm going to omit those parts for now. Unless the RR should be more functional then that?

@dseagrav worked on the initial framework and there is an older implemention of the range and direction calculations that I replaced, because it wasn't used anymore. I haven't spent too much time on the RR before I abandoned it for more urgent issues, so there still might be a problem with the RR geometry. @jalexb88 has tried the LM active rendezvous some more, but I don't think he had much success with the RR.


Title: Re: LM status...
Post by: abr35 on December 26, 2016, 08:30:58 PM
The document you posted was extremely helpful! All I could find were up to then was the LM timeline books which were very sparse when it came to powered descent. I used what you posted for everything but the LR test. The radar test contained in the LM descent summary did not remove the alarm. The one from the LM11 AOH did and I'll include it here. Shouldn't work, it's from Apollo 16 and uses different software, but it worked for me. And worked every time. Scenario is attached. It's the one I originally tried to send with the old pad load but it still takes the alarm away. Maybe you could tell me what I'm doing right because I don't have the foggiest idea! Both the 11 and 16 procedures include the same steps, but in a different order. LM-11 only omits the V60.

Activation
TEMP MON – LAND RDR
LDG RDR cb – close

Self-Test
RATE/ERR MON – LDG RDR/CMPTR
MODE SEL – LDG RDR
RNG ALT MON – ALT/ALT rt
X PNTR SCAL – HI MULT
RDR TEST – LDG
ALT – 7700 to 8100 ft
ALT RATE – 478 to -482 ft
XPNTR – off scale upper right

V63E
F 04 12 – V22E 2E
F 16 66
R1 = 08276 to 08296 +/- 2 ft

LDG RDR ANT – AUTO
R2 = 00001
LDG RDR ANT – DES
R2 = 00001
LDG RDR ANT – HOVER (wait 10s, poss alarm)
R2 =00002
LDG RDR ANT – DES (wait 10s, poss alarm)
R2 = 00001
LDG RDR ANT – AUTO
R2 = 00001
PRO

F 16 67
R1 = -0493 to -0497
R2 = +01860 to +01864
R3 = +01329 to +01333
PRO

RDR TEST sw – OFF
ALT/VEL lts – ON
V34E
RSET
ALT/VEL lts – OFF

LDG RDR cb – open

Edit: Pressing PRO at Noun 67 to complete the routine seems to make the difference. Didn't even put the test switch to landing and still got away with it. As long as I did a V63 Option 2 and hit PRO when I got to N67, I had no alarm.


Title: Re: LM status...
Post by: indy91 on December 27, 2016, 08:14:24 AM
Edit: Pressing PRO at Noun 67 to complete the routine seems to make the difference. Didn't even put the test switch to landing and still got away with it. As long as I did a V63 Option 2 and hit PRO when I got to N67, I had no alarm.

The Apollo 11 document also has the PRO on Noun 67 before V34E. I have the feeling that the RADMODES flagword could be incorrectly set if you V34E early out of Verb 63. The Apollo 12 LGC version is the next that has become available, so I can compare the source code and I will also check the flagword after the two LR Self Test procedures.


Title: Re: LM status...
Post by: rcflyinghokie on December 27, 2016, 08:21:19 AM
Are we using Luminary or Sundance in the Apollo 9 scn as of right now?

EDIT:  Let me rephrase, are we planning on using Sundance for 9 at some point or should everything be written in terms of Luminary as far as procedures right now?


Title: Re: LM status...
Post by: indy91 on December 27, 2016, 08:47:29 AM
Are we using Luminary or Sundance in the Apollo 9 scn as of right now?

EDIT:  Let me rephrase, are we planning on using Sundance for 9 at some point or should everything be written in terms of Luminary as far as procedures right now?

Sundance is not one of the LGC versions that is on the list of versions becoming available through Don Eyles, so we are going to use Luminary 069 (almost Apollo 10) for Apollo 9 and 10. I have already started initial work on the padload worksheets for all the new LGC versions and there don't seems to be too many differences between Luminary 069 and 099, most of them concern the descent programs.


Title: Re: LM status...
Post by: abr35 on December 28, 2016, 02:41:21 PM
I have the procedure put together. A user on the forum who I believe has passed on (jc121018), put together some basic flight plans when the CSM was in early development. I aimed to do the same sort of thing for the LEM so that people can fly it and bug test it without having to dig through all of the historical documents. A temporary guide that will be replaced when the time comes. Right now it's a chm to be opened as a help file in Orbiter. Is that good enough, or would a checklist xml be more suitable?


Title: Re: LM status...
Post by: indy91 on December 28, 2016, 03:53:29 PM
In the long run we will probably want two types of checklists. For those who want to have all the procedures printed out, we provide Word Checklists or historical documents, whenever we have them and apply to NASSP spacecraft. For Apollo 7 and 8 we have also created very extensive files for the Checklist MFD. These are the best way for new users and testing. I'm not sure, if we really want a third way to show checklists. There still exist very outdated chm files with checklist. I'm not sure if we really have a purpose for them between the Checklist MFD and Word checklists. In any case you should coordinate your efforts with rcflyinghokie, who has already started with the Checklist MFD file for Apollo 9.


Title: Re: LM status...
Post by: abr35 on December 28, 2016, 04:21:42 PM
In the long run we will probably want two types of checklists. For those who want to have all the procedures printed out, we provide Word Checklists or historical documents, whenever we have them and apply to NASSP spacecraft. For Apollo 7 and 8 we have also created very extensive files for the Checklist MFD. These are the best way for new users and testing. I'm not sure, if we really want a third way to show checklists. There still exist very outdated chm files with checklist. I'm not sure if we really have a purpose for them between the Checklist MFD and Word checklists. In any case you should coordinate your efforts with rcflyinghokie, who has already started with the Checklist MFD file for Apollo 9.

Sounds good! I'll just hang onto it for when/if it becomes useful to what rcflyinghokie is up to. If nothing else I learned my way around the LEM for when we get there :ROTFL3453:


Title: Re: LM status...
Post by: rcflyinghokie on December 30, 2016, 11:41:10 AM
Sounds good! I'll just hang onto it for when/if it becomes useful to what rcflyinghokie is up to. If nothing else I learned my way around the LEM for when we get there :ROTFL3453:

If you have them in PDFs or something I'd love a copy to compare to what I have so far.  I've pretty much been using the Apollo 9 flight plan and Apollo 12 checklists to create mine.


Title: Re: LM status...
Post by: abr35 on December 30, 2016, 03:46:29 PM
If you have them in PDFs or something I'd love a copy to compare to what I have so far.  I've pretty much been using the Apollo 9 flight plan and Apollo 12 checklists to create mine.

Sure! It assumes the LEM is powered and the IMU is coarse aligned to a known orientation. I've had an issue with the IMU causing a CTD if there is no known orientation. So starting the IMU for the first time, gimbal lock, and changing orientation, all cause Orbiter to crash. I started work with a scenario that has the IMU on. The procedure for EPS, LR, and RR are from the LM11 AOH and the rest is from the descent document Indy91 posted, with some adjustments made for Orbiter. If you need any help with Apollo 9 I'd be happy to dig around, or test things out, or anything else you need.


Title: Re: LM status...
Post by: rcflyinghokie on December 30, 2016, 04:29:53 PM
Sounds great!  I am out on vacation right now so I do not have my orbiter stuff with me but when I return I will give you my checklist mfd excel files if you wish to play with them.  I have been able to go through everything up to the first LM burns, though I do have the DPS and APS burn checklists on there too.  My issue with 9 was the rendezvous back with the CSM, thats where I stopped in favor of getting 7 and 8 ready.

But as I said I will attach what I have and if you want to play with them on Apollo 9 any input would be greatly appreciated!


Title: Re: LM status...
Post by: indy91 on December 31, 2016, 07:49:47 AM
I have been able to go through everything up to the first LM burns, though I do have the DPS and APS burn checklists on there too.  

This is where your problems will start. Docked DPS burns with full propellant are close to spinning out of control, because the center of gravity of the LM is far away from where the LGC expects it to be. You might have noticed this during the descent, too. At PDI the LM requires a lot of RCS to stay stable. Once most of the propellant is gone the CoG of the actual LM is closer to where the NASSP LM currently has its CoG So in P64 and later the LM can mostly "balance" on the gimballing DPS alone. I'll probably analyse this in more detail at some point, but the only really good solution, as has been planned for a while, is introducing a variable CoG for both descent configuration and ascent configuration.


Title: Re: LM status...
Post by: rcflyinghokie on January 06, 2017, 08:37:07 AM
@abr35 I posted my very alpha LM startup checklists here, they are geared towards A9 but if you want to play with them you are more than welcome to :)


Title: Re: LM status...
Post by: rcflyinghokie on April 01, 2017, 09:37:05 AM
I am having an issue getting the LM checklists to automatically execute.  I found the line VAGCCHECKLISTAUTOENABLED and it was set to zero under the LM.  This parameter is set by the extras tab in orbiter for the CM, but there is nothing to make it automatic for the LM save for changing the line by hand.  Is there a way to get the checklists to automatically execute without having to go change the VAGCCHECKLISTAUTOENABLED 0 to a 1 after the LM spawns?


Title: Re: LM status...
Post by: rcflyinghokie on April 02, 2017, 10:44:18 AM
The Apollo 11 document also has the PRO on Noun 67 before V34E. I have the feeling that the RADMODES flagword could be incorrectly set if you V34E early out of Verb 63. The Apollo 12 LGC version is the next that has become available, so I can compare the source code and I will also check the flagword after the two LR Self Test procedures.

I know it has been a while, but is there any new information on this?  I am at the LR tests on Apollo 9 and am back again facing these 522 errors.

Also, the LGC in Apollo 9 no longer has ALT and VEL lights, is this accurate?


Title: Re: LM status...
Post by: indy91 on April 02, 2017, 11:20:44 AM
I am having an issue getting the LM checklists to automatically execute.  I found the line VAGCCHECKLISTAUTOENABLED and it was set to zero under the LM.  This parameter is set by the extras tab in orbiter for the CM, but there is nothing to make it automatic for the LM save for changing the line by hand.  Is there a way to get the checklists to automatically execute without having to go change the VAGCCHECKLISTAUTOENABLED 0 to a 1 after the LM spawns?

Should be possible, I'll look into it.

The Apollo 11 document also has the PRO on Noun 67 before V34E. I have the feeling that the RADMODES flagword could be incorrectly set if you V34E early out of Verb 63. The Apollo 12 LGC version is the next that has become available, so I can compare the source code and I will also check the flagword after the two LR Self Test procedures.

I know it has been a while, but is there any new information on this?  I am at the LR tests on Apollo 9 and am back again facing these 522 errors.

Weird. Jalexb88 has been flying a few missions (at least Apollo 11 and 12) and I have been flying Apollo 15 from launch to at least the lunar landing, without getting this issue. I wonder if it is a AGC version dependant problem or a procedural one. I just remember looking at the scenario you posted and I never got rid of this alarm. But I never got it in my own scenarios. Maybe Alex and I just didn't thoroughly go through the LR checks in our missions and it's a bug in our LR implementation that happens during the tests.

Quote
Also, the LGC in Apollo 9 no longer has ALT and VEL lights, is this accurate?

Yep, Apollo 11 was the first mission with those lights. I first noticed that when I saw this Apollo 10 video: https://www.youtube.com/watch?v=tajGQrE9w8Q The lights should now be correct for all the manned missions. In the CM it always stays the same and in the LM the ALT and VEL lights were added for Apollo 11 and the NO DAP and PRIO DISP lights were added for Apollo 15.


Title: Re: LM status...
Post by: rcflyinghokie on April 02, 2017, 12:03:09 PM
Weird. Jalexb88 has been flying a few missions (at least Apollo 11 and 12) and I have been flying Apollo 15 from launch to at least the lunar landing, without getting this issue. I wonder if it is a AGC version dependant problem or a procedural one. I just remember looking at the scenario you posted and I never got rid of this alarm. But I never got it in my own scenarios. Maybe Alex and I just didn't thoroughly go through the LR checks in our missions and it's a bug in our LR implementation that happens during the tests.

I am following the Apollo 12 LM Activation Checklist at the moment.  I get PROG alarms when I switch the LR switch.  However, when I followed the procedure @abr35 posted (I think from Apollo 16?) and it works without that V60 added, I still get PROG alarms but the LR changes the R2 from 00001 to 00002 and back.


Title: Re: LM status...
Post by: abr35 on April 02, 2017, 12:57:11 PM
Weird. Jalexb88 has been flying a few missions (at least Apollo 11 and 12) and I have been flying Apollo 15 from launch to at least the lunar landing, without getting this issue. I wonder if it is a AGC version dependant problem or a procedural one. I just remember looking at the scenario you posted and I never got rid of this alarm. But I never got it in my own scenarios. Maybe Alex and I just didn't thoroughly go through the LR checks in our missions and it's a bug in our LR implementation that happens during the tests.

I am following the Apollo 12 LM Activation Checklist at the moment.  I get PROG alarms when I switch the LR switch.  However, when I followed the procedure @abr35 posted (I think from Apollo 16?) and it works without that V60 added, I still get PROG alarms but the LR changes the R2 from 00001 to 00002 and back.

As far as I can tell the 522 alarm during the LR checkout is okay. Both the Apollo 16 LEM handbook and the Apollo 11 landing document indy91 posted a few pages back say to expect it during checkout. It was during Powered Descent that I believe it was an issue.


Title: Re: LM status...
Post by: rcflyinghokie on April 02, 2017, 10:41:49 PM
As far as I can tell the 522 alarm during the LR checkout is okay. Both the Apollo 16 LEM handbook and the Apollo 11 landing document indy91 posted a few pages back say to expect it during checkout. It was during Powered Descent that I believe it was an issue.

Right, however when I keep the V60 like in the apollo 12 activation checklist, it wont even drive the LR, the number stays 00000 in R2 with the 522 error.  And yeah, I did have it on landing but I haven't tried a landing scenario in a long while, i am just trying to figure out the "correct" procedure for Apollo 9 given that we are using a different LGC version than LM-3 had on board and of course a different one from Apollo 11 or 12 or 16 etc.

EDIT: Using the Apollo 12 procedure and the V 60 seems to yield correct results for me now that I reexamine it, I had an extra PRO before the V34 as Indy mentioned in a previous post, and I think that makes the routine work properly per the checklist.  The only thing I am wondering is if the PROG alarm is supposed to clear after pressing reset (the checklist says there will be a 522 code, and press reset) however the code remains.

Here is my current procedure:

V37E 00E
cb PGNS: LDR RDR - close
X-POINTER SCALE (CDR) - HI MULT
X-POINTER SCALE (LMP) - HI MULT
TEMP MON - LDG RDR
 50°-70°
RATE/ERR MON (CDR) - LDG RADAR/CMPTR
RNG/ALT MON - ALT/ALT RATE
LDG ANT - DES
MODE SEL - LDG RADAR
RADAR TEST - LDG RDR
TEST MONITOR - ALT XMTR
 2.1-5.0
TEST MONITOR - VEL XMTR
 2.1-5.0
 ALT/ALT RT MON +7900 to +8100 ft/-478 to -482 fps
X-Pointer - Up, Rt

V63E
 F 04 12
 R1 00004 Specify Radar
 R2 00001 (Rndz Radar)
V22E
00002E (Ldg Radar)
PRO

 F 16 66 SLANT RANGE, ANT POSITION (ft)
 R1 +08277 to +08297
 R2 +00001
PRO

 F 16 67 VX,VY,VZ
 R1 -00494 (+-2)
 R2 +01861 (+-2)
 R3 +01331 (+-2)
V34E

LDG ANT - AUTO
V60E

V63E
 F 04 12
 R1 00004 Specify Radar
 R2 00001 (Rndz Radar)
V22E
00002E (Ldg Radar)
PRO

 F 16 66 SLANT RANGE, ANT POSITION (ft)
 R1 +08277 to +08297
 R2 +00002
PRO

LDG ANT - DES (10 sec)
 F 16 66 SLANT RANGE, ANT POSITION (ft)
 R2 +00001 (PROG Lt-On, V05N09E, 00522 RSET)

LDG ANT - AUTO
 F 16 66 SLANT RANGE, ANT POSITION (ft)
 R2 +00001
V34E

RADAR TEST - OFF
cb PGNS: LDR RDR - open


Title: Re: LM status...
Post by: indy91 on April 03, 2017, 10:15:43 AM
EDIT: Using the Apollo 12 procedure and the V 60 seems to yield correct results for me now that I reexamine it, I had an extra PRO before the V34 as Indy mentioned in a previous post, and I think that makes the routine work properly per the checklist.  The only thing I am wondering is if the PROG alarm is supposed to clear after pressing reset (the checklist says there will be a 522 code, and press reset) however the code remains.

The program alarm persisting after pressing reset is how I remember it from Apollo 11. Not sure if that is a bug in our LR. The alarm goes away once the self test is done.


Title: Re: LM status...
Post by: rcflyinghokie on April 03, 2017, 10:41:03 AM
The program alarm persisting after pressing reset is how I remember it from Apollo 11. Not sure if that is a bug in our LR. The alarm goes away once the self test is done.

Right, so I am just going to assume it's normal for the test.  Now is the self test testing the positioning of the LR using the switch and the computer?  Or is it testing what data the computer receives from the LR itself?  Or both perhaps?


Title: Re: LM status...
Post by: indy91 on April 05, 2017, 09:00:31 AM
I am having an issue getting the LM checklists to automatically execute.  I found the line VAGCCHECKLISTAUTOENABLED and it was set to zero under the LM.  This parameter is set by the extras tab in orbiter for the CM, but there is nothing to make it automatic for the LM save for changing the line by hand.  Is there a way to get the checklists to automatically execute without having to go change the VAGCCHECKLISTAUTOENABLED 0 to a 1 after the LM spawns?

Actually, we talked about this a few months ago and then I added exactly this feature. You just have to add

Quote
LEMCHECKAUTO 1

In the launch scenario below the LEMCHECK parameter and it should work.


Title: Re: LM status...
Post by: rcflyinghokie on April 05, 2017, 11:15:15 AM

Actually, we talked about this a few months ago and then I added exactly this feature. You just have to add

Quote
LEMCHECKAUTO 1

In the launch scenario below the LEMCHECK parameter and it should work.

Oh my you are right!  I recalled this but I didnt think to look back for the code and thought it was just me misremembering :P  I will change the launch scn for this.

Also, is there any status or progress on AGS implementation?  I cannot even find the key commands for the DEDA to use in the checklist excel file.


Title: Re: LM status...
Post by: indy91 on April 05, 2017, 11:50:40 AM
Also, is there any status or progress on AGS implementation?  I cannot even find the key commands for the DEDA to use in the checklist excel file.

Ah, I really would like to start working on the AGS! I'm really excited to work on the AGS padloads, the Abort Sensor Assembly systems etc. The first step is to make the Virtual AGS run in NASSP and get the I/O between AEA and DEDA to work. And that's where I have failed so far and I don't think I am really able to succeed. The IO is more complicated than between AGC and DSKY and that kind of stuff is not really my strength when it comes to programming. So dsegrav or someone else has to do the initial work. I can probably take over after those initial steps. But right now the AGS is not running at all yet.


Title: Re: LM status...
Post by: rcflyinghokie on April 06, 2017, 11:09:27 AM
I have finished the Docked DPS burn checklists (untested) and am hitting the LM Powerdown.  I cannot however find any good resources for the powerdown sequence in Apollo 9.   I am just going to pretty much take my activation checklists and run them in reverse unless someone knows of documents out there that can show how this was done?


Title: Re: LM status...
Post by: indy91 on April 06, 2017, 11:24:45 AM
I have finished the Docked DPS burn checklists (untested) and am hitting the LM Powerdown.  I cannot however find any good resources for the powerdown sequence in Apollo 9.   I am just going to pretty much take my activation checklists and run them in reverse unless someone knows of documents out there that can show how this was done?

Best one I can find is the Apollo 14 LM Contingency Checklist (https://www.hq.nasa.gov/alsj/a14/a14LMCntngncyChklst.pdf) which has a section called "Unstaged Power Down". The Apollo 9 flight plan mentions an "Initial Power Down" and a "Final Deactivation". The Apollo 14 checklist has sections with those names, so it might be fairly close to what they did during Apollo 9.


Title: Re: LM status...
Post by: rcflyinghokie on April 06, 2017, 11:27:49 AM
Best one I can find is the Apollo 14 LM Contingency Checklist (https://www.hq.nasa.gov/alsj/a14/a14LMCntngncyChklst.pdf) which has a section called "Unstaged Power Down". The Apollo 9 flight plan mentions an "Initial Power Down" and a "Final Deactivation". The Apollo 14 checklist has sections with those names, so it might be fairly close to what they did during Apollo 9.

I will check this out, considering the titles are identical I think this is what I need, thanks!


Title: Re: LM status...
Post by: rcflyinghokie on April 09, 2017, 11:01:51 AM
I am running into some issues with the LR Spur test (R77) during a P40.  I get a 1210 alarm when I key V78 (2 routines using device at same time).  According to the flight plan the V78 is enabled after P40 but it seems the two are in conflict.  Any thoughts?


Title: Re: LM status...
Post by: indy91 on April 09, 2017, 11:39:29 AM
I am running into some issues with the LR Spur test (R77) during a P40.  I get a 1210 alarm when I key V78 (2 routines using device at same time).  According to the flight plan the V78 is enabled after P40 but it seems the two are in conflict.  Any thoughts?

I don't think R77 is in conflict with P40. The AOH says about the test: "Routine may be called only when no other program or routine is using either radar, or TRACKFLG is set". So maybe the LR self test is still running for some reason? Maybe try a V37E 00E before you enter. But I am not really sure why you get the alarm. I doubt it's a problem because of LGC version difference though.


Title: Re: LM status...
Post by: rcflyinghokie on April 09, 2017, 11:43:17 AM
I don't think R77 is in conflict with P40. The AOH says about the test: "Routine may be called only when no other program or routine is using either radar, or TRACKFLG is set". So maybe the LR self test is still running for some reason? Maybe try a V37E 00E before you enter. But I am not really sure why you get the alarm. I doubt it's a problem because of LGC version difference though.

Tried a P00, tried starting and V34'ing the self test and still get it.  Here is a .scn  Looks like the TRACKFLG is not set (showing a digit of 4)  How do I set this?  Or better question, what would cause it to be unset?


Title: Re: LM status...
Post by: indy91 on April 09, 2017, 12:10:52 PM
In your scenario, the LR circuit breaker is out. If I push it in then I don't get the 1210 alarm in P40. A powered up and checked out Landing Radar is a prerequisite for the LR Spurious Test.


Title: Re: LM status...
Post by: rcflyinghokie on April 09, 2017, 12:36:24 PM
In your scenario, the LR circuit breaker is out. If I push it in then I don't get the 1210 alarm in P40. A powered up and checked out Landing Radar is a prerequisite for the LR Spurious Test.

Wow, I wonder why it is back out.  I think the LR self test has it pulled back out, I will fix my checklists.  Thanks for catching my blindness ;)


Title: Re: LM status...
Post by: rcflyinghokie on April 15, 2017, 10:02:44 AM
Question regarding the LM DAP.  I notice when i put some registers in and hit enter they change back to another digit.  For example, the Apollo 9 RDV procedures call for a R1 A digit of 0, however when I press enter, a 1 replaces the zero.    Another place I notice it is the D digit will not let me put a 2, it replaces it with a 0 upon keying enter, it will allow me to place a 1 in this position though.  Could this be a result of using a different LGC software than what was aboard Apollo 9?


Title: Re: LM status...
Post by: rcflyinghokie on April 16, 2017, 08:31:11 AM
Another thing I noticed is the current Luminary version installed for Apollo 9 does not have the extended verb 84 to update target delta V as noted in the checklists.  Would it have the same result to call a V06 N84, enter the dV, then call a V06 N33 to enter the time of burn, then call a V81 to update CSM state vector?  Of course just doing a LGC P27 SV update after the SM RCS sep burn would accomplish the same thing but I am trying to keep things as accurate as possible.

EDIT: I also see that this version has a P76 target dV, would this work in place of the V84?

EDIT 2:  Looks like by trying it I answered my own question, until we have a different program for Apollo 9, the P76 will be used in the checklist.


Title: Re: LM status...
Post by: rcflyinghokie on April 18, 2017, 09:20:54 AM
May be another version thing but I am trying to make sense of the RR Checkout in the Apollo 9 LM RDV procedures.  It tells me to run a V63 then a V41N72, however this brings up an opr err.  Additionally a few steps later, I am supposed to call a V62 which in this version is not an extended verb.  Any guidance in this part would be appreciated!


Title: Re: LM status...
Post by: indy91 on April 18, 2017, 02:32:45 PM
EDIT 2:  Looks like by trying it I answered my own question, until we have a different program for Apollo 9, the P76 will be used in the checklist.

Yep, Apollo 9 didn't even have Luminary yet, just like Apollo 7 didn't have Colossus yet.

May be another version thing but I am trying to make sense of the RR Checkout in the Apollo 9 LM RDV procedures.  It tells me to run a V63 then a V41N72, however this brings up an opr err.  Additionally a few steps later, I am supposed to call a V62 which in this version is not an extended verb.  Any guidance in this part would be appreciated!

I don't really have an answer for the Verb 63 procedure. After all, you are the first one to try the Apollo 9 rendezvous with Luminary 069! But we have some Apollo 10 documentation that might be helpful:

Mission F, LM descent/phasing summary document: http://hdl.handle.net/2060/19700026546
LM Rendezvous Procedures - F Mission: http://hdl.handle.net/2060/19700025408

Regarding Verb 62, it seems to display RR trunnion and shaft angles (Noun 72) and RR range and range rate (Noun 78). Noun 72 can be accessed with a Verb 85 and Noun 78 can simply be accessed by a V16 N78. Verb 62 is something different in Luminary and there doesn't seem to be a direct equivalent for the Sundance Verb 72.


Title: Re: LM status...
Post by: rcflyinghokie on April 19, 2017, 07:31:11 AM
I don't really have an answer for the Verb 63 procedure. After all, you are the first one to try the Apollo 9 rendezvous with Luminary 069! But we have some Apollo 10 documentation that might be helpful:

I believe both utilize the V63 as the test program so it is strange why this would be called up and then a designate used, unless it was required to actually designate the RR in Sundance.  It also says "PGNS mode 2 err needles" after the V63 which also is unclear to me.  It just seems out of place.  When I get a chance I will experiment with it and see how it works. 

Another weird thing I am seeing is when the RR breakers are engaged, the FDAI roll error needle oscillates left and right rapidly, any idea what is causing this as I am certain it is a glitch/bug.


Title: Re: LM status...
Post by: indy91 on April 19, 2017, 07:48:54 AM
I believe both utilize the V63 as the test program so it is strange why this would be called up and then a designate used, unless it was required to actually designate the RR in Sundance.  It also says "PGNS mode 2 err needles" after the V63 which also is unclear to me.  It just seems out of place.  When I get a chance I will experiment with it and see how it works. 

Ah, I think in Sundance V62 and V63 are simply interchanged. In Luminary Verb 62 is displaying the total attitude error, sometimes referred to as mode II attitude error display. And V62 in Sundance is simply the V63 for the radar self tests, which we are already familiar with.

Quote
Another weird thing I am seeing is when the RR breakers are engaged, the FDAI roll error needle oscillates left and right rapidly, any idea what is causing this as I am certain it is a glitch/bug.

Yeah, right now the roll error needle has an undefined value when the RR angles are displayed on the FDAI. That should probably be set to 0. Easy fix.


Title: Re: LM status...
Post by: rcflyinghokie on April 21, 2017, 11:17:33 AM
I am trying to figure out the COAS calibration of the P52, but it seems the A12 instructions have different values for detents.  It looks like "5" is what I am using but where am I looking for the COAS diagram to input the az and el angles?  Also I know the line of sigh is probably screwy with the LM COAS.  Another question, for the simulation can we assume perfect calibration from the start?


Title: Re: LM status...
Post by: indy91 on April 21, 2017, 11:56:02 AM
I have added the LM Ordeal and it should be fully functional. It is located between the two CWS displays and works just like the ORDEAL in the CSM, so you can toggle it being displayed or not. The actual location of the ORDEAL in the LM is somewhere left of panel 8. But to be displayed there the ORDEAL should be made part of that panel bitmap (lem_left_panel.bmp I guess). Here is a few closeout pictures for the location:

https://www.hq.nasa.gov/alsj/a12/LM6-co17.jpg
https://www.hq.nasa.gov/alsj/a15/lm10-co35.jpg
https://www.hq.nasa.gov/alsj/a16/LM11-co26.jpg

So someone with bitmap editing skills has to add the ORDEAL to that panel.
I am trying to figure out the COAS calibration of the P52, but it seems the A12 instructions have different values for detents.  It looks like "5" is what I am using but where am I looking for the COAS diagram to input the az and el angles?  Also I know the line of sigh is probably screwy with the LM COAS.  Another question, for the simulation can we assume perfect calibration from the start?

Where did you find the procedure and what do you mean with "5"? What COAS diagram? And I am not sure about the COAS line-of-sight. I very much doubt it's usable for an alignment, because it is so much off center. We'll have to find a solution for that eventually. 3D Panel probably :D


Title: Re: LM status...
Post by: abr35 on April 21, 2017, 12:32:52 PM
I am trying to figure out the COAS calibration of the P52, but it seems the A12 instructions have different values for detents.  It looks like "5" is what I am using but where am I looking for the COAS diagram to input the az and el angles?  Also I know the line of sigh is probably screwy with the LM COAS.  Another question, for the simulation can we assume perfect calibration from the start?

I believe the value placed in R1 for the AOT detent. Did you use the A12 G&N dictionary? It's on page 39 (P52 step 7) https://history.nasa.gov/afj/ap12fj/pdf/a12_lm_g&n.pdf

It lists the COAS as the 7 detent and the azimuth/elevation are both +00000 for the forward COAS. The COAS on the CDR window of our panel is useless there. The 0 degrees LPD mark on the landing panel is what I use as an alternative for now, as I imagine a million other things are going to get priority in the LM. I never tried the overhead COAS but I imagine the yellow tick mark at 0 on the rendezvous window should work.


Title: Re: LM status...
Post by: rcflyinghokie on April 22, 2017, 09:05:33 AM
Where did you find the procedure and what do you mean with "5"? What COAS diagram? And I am not sure about the COAS line-of-sight. I very much doubt it's usable for an alignment, because it is so much off center. We'll have to find a solution for that eventually. 3D Panel probably :D

Forgive me for not being clear, wrote this in a hurry before work while the question was still burning in my mind...

The LM RDV procedure for Apollo 9 has steps for a coas calibration after the first P52.  Basically it says to use "5" as the selection code in the star selection "00CDE" where C is the AOT position and DE is the star code.  I know that the line of sight for the COAS is a long way off, but I am just trying to figure out if Sundance uses different numbers for these detent than the Apollo 12 lm g&n manual. 

The Apollo 12 manual says "0" in the C position brings up a coas calibration, and such brings up a F 06 87 for Azimuth and Elevation angles.  The LM RDV document says to use a "C" value of 5 which in the A12 document corrosponds with the CL AOT detent and thus should not bring up a F 06 87 (I think).  Is there any way to look at the code and see which numbers correspond to which detents/coas calibration selection for a p52?


Title: Re: LM status...
Post by: indy91 on April 22, 2017, 09:31:47 AM
Forgive me for not being clear, wrote this in a hurry before work while the question was still burning in my mind...

The LM RDV procedure for Apollo 9 has steps for a coas calibration after the first P52.  Basically it says to use "5" as the selection code in the star selection "00CDE" where C is the AOT position and DE is the star code.  I know that the line of sight for the COAS is a long way off, but I am just trying to figure out if Sundance uses different numbers for these detent than the Apollo 12 lm g&n manual. 

The Apollo 12 manual says "0" in the C position brings up a coas calibration, and such brings up a F 06 87 for Azimuth and Elevation angles.  The LM RDV document says to use a "C" value of 5 which in the A12 document corrosponds with the CL AOT detent and thus should not bring up a F 06 87 (I think).  Is there any way to look at the code and see which numbers correspond to which detents/coas calibration selection for a p52?

The Apollo 10 documents are probably the best to find the right procedures for Luminary069. What i can tell you is that according to the Luminary changelog in the GSOP a few alignment related features were added for Apollo 11 and were probably not available in earlier versions. Relevant changes for Apollo 11 were:

"Pad load AOT Back Detent AZ(imuth) and EL(evation) Angles"
"Add COAS Calibration Option to R52"

So I am not sure if the three back detents were even available for alignments before Apollo 11. Nominally they are only used on the lunar surface anyway. If they aren't available in Luminary069, then that could have an influence on the selection codes in P52. For changes from Sundance to Luminary the GSOP changelog is not very useful, the GSOP is only for Luminary and Luminary started development long before Apollo 9 flew.

And looking at the Luminary069 code, the options 0 and 7 that are mentioned in comments on the Apollo 11 (Luminary099) code do not appear in Luminary069.


Title: Re: LM status...
Post by: rcflyinghokie on April 22, 2017, 11:12:33 AM
The Apollo 10 documents are probably the best to find the right procedures for Luminary069. What i can tell you is that according to the Luminary changelog in the GSOP a few alignment related features were added for Apollo 11 and were probably not available in earlier versions. Relevant changes for Apollo 11 were:

"Pad load AOT Back Detent AZ(imuth) and EL(evation) Angles"
"Add COAS Calibration Option to R52"

So I am not sure if the three back detents were even available for alignments before Apollo 11. Nominally they are only used on the lunar surface anyway. If they aren't available in Luminary069, then that could have an influence on the selection codes in P52. For changes from Sundance to Luminary the GSOP changelog is not very useful, the GSOP is only for Luminary and Luminary started development long before Apollo 9 flew.

And looking at the Luminary069 code, the options 0 and 7 that are mentioned in comments on the Apollo 11 (Luminary099) code do not appear in Luminary069.

Yeah playing with the LGC it looks like 1 2 and 3 are L F and R, 4 and 5 bring up the AZ and EL making me believe that they are the COAS for FD and OVHD.  Options 7 and 0 seem to have no effect so my guess is it was a crude COAS calibration technique before they actually added a "COAS Calibration" as option 0


Title: Re: LM status...
Post by: rcflyinghokie on May 06, 2017, 09:44:19 AM
I have been trying the rendezvous with the LM and have a few questions about the P20.  I will preface in saying I know the RR needs a lot of work in the LM but I am just trying to see what I can and cannot do with it right now.

1) When I first call the P20, all it gives me is a blank DKSY, no 50 18 requesting a maneuver.  After a little bit of time I get the 503 designate fail and cannot get it to do much.  Is there a reason it doesnt give me FDAI angles to maneuver to?  I have tried this close to LOS with the CSM and far from LOS.

2)  If I call a P20 and manually aim the LM RR to the CSM for a lock, the DSKY just stays in the blank state instead of bringing up a 06 05 to proceed, am I missing something?

3)  If I call a P20 and manually aim the LM RR to the CSM for a lock and then call a P34, sometimes it will begin the marking sequence, and sometimes it will not.  I feel like I am violating the definition of insanity trying the same experiment and getting different results.

4)  If I lose lock while pointing the LM to the CSM, the LGC moves the RR pitch error needle all the way to the top, and I either have to slew it back or maneuver to get another lock.  Is there a reason it moves it to the stop and doesn't just search for it?


Title: Re: LM status...
Post by: indy91 on May 06, 2017, 10:17:44 AM
I am not an expert on the LGC Program 20 yet, but I can tell you at least a few things.

-P20 won't give you a maneuver request if you are already in the right attitude, i.e. less than 10° off. So maybe that happened to you.
-P20 in the LM does a whole bunch of things automatically that are hard to follow. I think it will try to point the RR in the right direction, start a marking sequence and incorporate without much user input.
-The marking sequences with the RR in the LM and the VHF Ranging System in the CSM don't really work like sextant marks. You can actually do sextant marks at the same time as VHF ranging. RR and VHF Ranging are both happening in the background usually and don't require much DSKY interaction.

There is not much we can properly test until the RR can hold the antenna inertially fixed on its own. Once that is implemented we can fix any remaining issues with the RR/LGC interaction. There are a few sections in our RR code that seem to not be fully implemented yet, but I don't really understand what still needs to be done there.


Title: Re: LM status...
Post by: rcflyinghokie on May 06, 2017, 10:24:54 AM
P20 won't give you a maneuver request if you are already in the right attitude, i.e. less than 10° off. So maybe that happened to you.

Yeah I remember reading that, which is why I tried it from different attitudes all of which never bring up a 50 18.  I just wish i could figure out how I got the marks to work for the P34, because I cannot seem to get it to do that again.  I will be playing with it a lot more.  I also have discovered, in the mean time, if you bring up the Orbiter dock HUD, and have your RR needles centered, if you place the +Z axis chevron on the box of the CSM, you can pretty easily maintain RR lock manually.


Title: Re: LM status...
Post by: eddievhfan1984 on May 07, 2017, 11:12:52 PM
TBH, I thought the original idea was that the LGC would do the initial pointing, and then one would switch the radar to AUTO TRACK and it would handle the tracking of the CSM, passing R, R-dot, and the radar angles to the LGC upon interrogation.


Title: Re: LM status...
Post by: indy91 on May 08, 2017, 04:47:16 AM
TBH, I thought the original idea was that the LGC would do the initial pointing, and then one would switch the radar to AUTO TRACK and it would handle the tracking of the CSM, passing R, R-dot, and the radar angles to the LGC upon interrogation.

The RR can switch to Auto Track mode internally, if the LGC sends the RendezvousRadarEnable signal (output channel 12, bit 14). The LGC does that when it has driven the RR to within 0.5° of the targeted direction. You could probably manually switch to Auto Track at that time and nothing would change. The separate Auto Track setting is mostly for use with the AGS, I guess.


Title: Re: LM status...
Post by: rcflyinghokie on May 08, 2017, 08:22:27 AM
TBH, I thought the original idea was that the LGC would do the initial pointing, and then one would switch the radar to AUTO TRACK and it would handle the tracking of the CSM, passing R, R-dot, and the radar angles to the LGC upon interrogation.

Also, programs such as P20/P25 require the RR in LGC mode else it will throw error codes if you lock on and switch to Auto Track.


Title: Re: LM status...
Post by: rcflyinghokie on May 08, 2017, 09:04:25 AM
There is not much we can properly test until the RR can hold the antenna inertially fixed on its own. Once that is implemented we can fix any remaining issues with the RR/LGC interaction. There are a few sections in our RR code that seem to not be fully implemented yet, but I don't really understand what still needs to be done there.

Yeah I noticed that when looking at the code, a lot of sections commented out too.  Another thing I noticed other than what I have mentioned is that when you run a V41N72 coarse align RR, it doesn't drive properly either.  Say I use R1 +00000 and R2 -07700 and run a V16N72, the angles should be at 00000 and 28300 but they hang at 00000 and 35578.  This could be a root problem for why the LGC doesn't drive the RR properly to a target even when it is right smack in LOS


Title: Re: LM status...
Post by: rcflyinghokie on May 11, 2017, 10:18:52 AM
So I figured out my issues with the P34 marking with P20 running in the background.  For some reason my IMU was not aligned properly after my latest quicksave, so after running a P51/52 opt 3 the marking sequence starts properly and the LGC doesn't drive the RR to weird angles.  I still have to manually hold the lock (using the docking HUD helps a lot) but the marking for the P34 is currently working.

My issue now (and its probably a function of my phasing burn even though the parameters matched that of the flight plan) is that I am throwing 611 errors for the elevation of +02750 and a TPI TIG of 95h0m0s.

EDIT:  So I just got a few 601 alarms running the P34.  According to the Apollo 12 g/n, this is a lunar orbit perigee <35kft.  Is it possible that Luminary 069 thinks the LM is in orbit around the moon?  In which case the rendezvous calculations by the P34 etc could be affected and not calculate properly.


Title: Re: LM status...
Post by: indy91 on May 11, 2017, 10:45:29 AM
My issue now (and its probably a function of my phasing burn even though the parameters matched that of the flight plan) is that I am throwing 611 errors for the elevation of +02750 and a TPI TIG of 95h0m0s.

EDIT:  So I just got a few 601 alarms running the P34.  According to the Apollo 12 g/n, this is a lunar orbit perigee <35kft.  Is it possible that Luminary 069 thinks the LM is in orbit around the moon?  In which case the rendezvous calculations by the P34 etc could be affected and not calculate properly.

jalexb88 had those alarms, too, when he tried the Apollo 9 rendezvous with Luminary099. I can only imagine that you are not on a good trajectory relative to the CSM, the AGC still tries to achieve the TPI time you gave it and that is only possible with a low perigee. According to the guidance equations the minimum periapsis altitude is 35kft for lunar orbit and 85NM for Earth orbit. I am 99% confident that Luminary069 doesn't have any issues specific to Earth orbit.

How did you calculate the the rendezvous burns before you started with the onboard targeting? So the phasing and insertion maneuvers!? There are probably some helpful tools missing that will be added to the RTCC MFD at some point, but for the most part it should already be able to calculate burns that follow the flight plan closely. Here a post where I described how I flew the Apollo 9 rendezvous profile a while ago: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2854.msg22711#msg22711


Title: Re: LM status...
Post by: rcflyinghokie on May 11, 2017, 10:53:18 AM
jalexb88 had those alarms, too, when he tried the Apollo 9 rendezvous with Luminary099. I can only imagine that you are not on a good trajectory relative to the CSM, the AGC still tries to achieve the TPI time you gave it and that is only possible with a low perigee. According to the guidance equations the minimum periapsis altitude is 35kft for lunar orbit and 85NM for Earth orbit. I am 99% confident that Luminary069 doesn't have any issues specific to Earth orbit.

Well that is good to know, just thought I would ask since this software was not used on 9 :)

How did you calculate the the rendezvous burns before you started with the onboard targeting? So the phasing and insertion maneuvers!? There are probably some helpful tools missing that will be added to the RTCC MFD at some point, but for the most part it should already be able to calculate burns that follow the flight plan closely. Here a post where I described how I flew the Apollo 9 rendezvous profile a while ago: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2854.msg22711#msg22711

I used the parameters in the Apollo 9 flight plan, apogee perigee TIG and adjusted the inclination to achieve the dV's prescribed in the flight plan.  I know this was rough but I was hoping it would put me in the ballpark :P  I see now I should have used the Lambert calculation to achieve the appropriate offset is that correct?  If so I will load that quicksave and recalculate.

And I have only completed the phasing burn using that, I was hoping to get good numbers using onboard programs to get the insertion and forward numbers.

If you don't mind taking a look at my scn, and telling me how far off I am?   :oops:


Title: Re: LM status...
Post by: indy91 on May 11, 2017, 11:16:28 AM
I didn't properly read your post, you have issues in P34 calculating TPI0 and not in P32.

In any case, your orbit is indeed off. It's very important to have the same orbital period as the CSM while in the football shaped orbit, or else your relative position to the CSM will be off. And that seems to be the case. It's especially important because you let P34 find the TPI time based on elevation angle. And that elevation angle will only occur close to the planned time, if your relative profile is as planned.

In some cases using the flight plan or mission report values for apogee and perigee are good enough as an estimate, for most of the Apollo 7 SPS maneuvers that usually works. But not for the Apollo 9 phasing and insertion burns. I'll probably add something to the RTCC MFD that calculates an equiperiod orbit as a target vessel, but with a DH input, so that the football shape is the resulting relative orbit. That input would be be 10NM in the case of Apollo 9, because the insertion burn will bring the LM on a coelliptic orbit with a DH of 10NM. In an advanced step that DH would be varied to achieve desired lighting conditions for TPI. But that can be added later.


Title: Re: LM status...
Post by: rcflyinghokie on May 11, 2017, 11:19:38 AM
In any case, your orbit is indeed off. It's very important to have the same orbital period as the CSM while in the football shaped orbit, or else your relative position to the CSM will be off. And that seems to be the case. It's especially important because you let P34 find the TPI time based on elevation angle. And that elevation angle will only occur close to the planned time, if your relative profile is as planned.

I figured I was, I am using the lambert guidance now and the dV values are very close to the flight plan as you had in your attempt, so I will press on from here!

EDIT:  Forgot to mention, something else I noticed is in the AOT you can actually adjust the camera point with the arrow keys similar to scrolling around a panel.  I think this needs to be addressed because it moves the X axis of the AOT up and down within the FOV and can potentially mess up alignments.


Title: Re: LM status...
Post by: indy91 on May 11, 2017, 11:56:36 AM
EDIT:  Forgot to mention, something else I noticed is in the AOT you can actually adjust the camera point with the arrow keys similar to scrolling around a panel.  I think this needs to be addressed because it moves the X axis of the AOT up and down within the FOV and can potentially mess up alignments.

It works with the CSM optics because there are separate bitmaps for 4:3, 16:9 and 16:10 screens and there is some code that decides which bitmap to use. And the size of these bitmaps is smaller than the usual resolution with these aspect ratios, so they always fit in the actual size of the screen. The CSM rendezvous window also has that feature. I guess it would be useful to have it for the AOT as well.


Title: Re: LM status...
Post by: rcflyinghokie on May 12, 2017, 06:48:05 AM
Just wanted to report that, after a proper phasing burn this time, Luminary 069 P34 with the RR manually locked (boresighted really) to the CSM yields a proper marking sequence and reasonable TPI TIG and dV values for the prescribed elevation angle.  After graduation this weekend I'll fly the whole rendezvous and create a PR with the checklist.

I think I am going to make a call group for the makeshift method until the RR is working and then of course the actual checklist.

EDIT:. Now that the abort and stage buttons work, would someone explain to me why for AGS burns the abort stage button is pressed?  I don't understand the system very well and know it sets a bit in the computer but how does it play into an ags burn?


Title: Re: LM status...
Post by: indy91 on May 12, 2017, 07:54:31 AM
I think I am going to make a call group for the makeshift method until the RR is working and then of course the actual checklist.

In any case, if possible create more checklist groups and not put too many checklist item in overly long checklists. The Checklist MFD saves the state of every single checklist item of the active checklist, so e.g. the rendezvous scenario you posted above has 14,000 lines, 9000 of which are from the Checklist MFD. That seems quite excessive and if we can avoid that through splitting the checklists up some more, that would be great.

Quote
EDIT:. Now that the abort and stage buttons work, would someone explain to me why for AGS burns the abort stage button is pressed?  I don't understand the system very well and know it sets a bit in the computer but how does it play into an ags burn?

Hmm, not sure. Did you find that in the Apollo 9 LM Rendezvous Procedures? Pressing abort stage does arm the ascent stage engine, so maybe it was used for that.


Also, I have now added the Direct mode for the LM RCS. If you switch the Attitude Control switches to DIR, then the secondary RCS coils will now be enrgized. It kind of works like Accel Cmd in the CSM. You can enable it for each axis, it will override any other LGC or AGS commands and will fire 2 jets. The ACA will issue direct mode commands if moved 2.5° from detent. As a reminder, hardover mode (which is already implemented and works like Direct RCS in the CSM) commands on 4 jets and requires full ACA deflection. Hardover mode is enabled with the ACA/4 Jet switch, Direct Mode just needs the Attitude Control switch to DIR. Direct Mode might be the best manual control mode for people without joystick. Using Numpad always commands full deflection, so either you got the highest rate the LGC let's you do or you had to use hardover mode. Direct Mode is kind of an AGS control mode, but just like Accel Cmd in the CSM, it works with the Guidance Control switch set to PGNS or AGS.


Title: Re: LM status...
Post by: rcflyinghokie on May 12, 2017, 11:18:10 AM
In any case, if possible create more checklist groups and not put too many checklist item in overly long checklists. The Checklist MFD saves the state of every single checklist item of the active checklist, so e.g. the rendezvous scenario you posted above has 14,000 lines, 9000 of which are from the Checklist MFD. That seems quite excessive and if we can avoid that through splitting the checklists up some more, that would be great.

Oh thats certainly going to happen, I have it all in the Flightplan section until I test it then I will break it up into sections specific to the rendezvous (Phasing CSH CDH etc etc) and determine appropriate call groups from there.  I will try from now on to consolidate before making my next and future PR's  :ThumbsUp432:

Hmm, not sure. Did you find that in the Apollo 9 LM Rendezvous Procedures? Pressing abort stage does arm the ascent stage engine, so maybe it was used for that.

I did in fact.  And it was for an AGS controlled DPS burn.  

For the phasing burn, "Abort-Depress (ENG ON)" is used in conjunction with bypassing the PGNS ENG ON with an ENTER press for the AGS controlled burn.  After the burn "Abort-Reset" is performed right before Eng Arm - Off.  Also in the AGS burn checklists from the Apollo 12 g&n document, Abort(Stage) is pressed prior to an AGS controlled burn, then released after engine cut off.

Also, I have now added the Direct mode for the LM RCS. If you switch the Attitude Control switches to DIR, then the secondary RCS coils will now be enrgized. It kind of works like Accel Cmd in the CSM. You can enable it for each axis, it will override any other LGC or AGS commands and will fire 2 jets. The ACA will issue direct mode commands if moved 2.5° from detent. As a reminder, hardover mode (which is already implemented and works like Direct RCS in the CSM) commands on 4 jets and requires full ACA deflection. Hardover mode is enabled with the ACA/4 Jet switch, Direct Mode just needs the Attitude Control switch to DIR. Direct Mode might be the best manual control mode for people without joystick. Using Numpad always commands full deflection, so either you got the highest rate the LGC let's you do or you had to use hardover mode. Direct Mode is kind of an AGS control mode, but just like Accel Cmd in the CSM, it works with the Guidance Control switch set to PGNS or AGS.

This reminds me, is the PGNS ATT HOLD properly implemented or implemented at all yet?  I know the AGS side wouldn't be yet but I thought I remembered it (PGNS ATT HOLD) holding attitude when messing with Apollo 11, but on my current runs of Apollo 9, it seems to have zero effect.


Title: Re: LM status...
Post by: indy91 on May 12, 2017, 11:59:13 AM
I did in fact.  And it was for an AGS controlled DPS burn.  

For the phasing burn, "Abort-Depress (ENG ON)" is used in conjunction with bypassing the PGNS ENG ON with an ENTER press for the AGS controlled burn.  After the burn "Abort-Reset" is performed right before Eng Arm - Off.  Also in the AGS burn checklists from the Apollo 12 g&n document, Abort(Stage) is pressed prior to an AGS controlled burn, then released after engine cut off.

Pressing abort arms the DPS, pressing abort stage arms the APS. Having the abort (stage) button pressed seems to be the nominal procedure for an AGS controlled burn. Not sure why. Maybe as a backup for the ENG ARM switch. I'll look into giving the Abort and Abort Stage buttons these capabilities. Right now that will probably not work.

EDIT: From the Apollo 10 LM Descent/Phasing Procedures:

"ABORT PUSH BUTTON sw

...
The AGS will not issue automatic engine ON/OFF commands unless this switch is depressed.
..."

Quote
This reminds me, is the PGNS ATT HOLD properly implemented or implemented at all yet?  I know the AGS side wouldn't be yet but I thought I remembered it (PGNS ATT HOLD) holding attitude when messing with Apollo 11, but on my current runs of Apollo 9, it seems to have zero effect.

Yes, PGNS ATT HOLD has always worked fine for me. And it still works in my scenarios for other missions. So I can only assume that it has to be something with Luminary069. The V48 configuration looks right in the Apollo 9 scenario, but maybe it's different in that Luminary version. Maybe some of the Apollo 10 documentation knows something?

EDIT: Also, I am not sure PGNS Minimum Impulse mode is properly working yet.


Title: Re: LM status...
Post by: rcflyinghokie on May 14, 2017, 12:02:50 PM
The abort buttons seem to be depressed now when I start a scenario.  It looks like the "on" or depressed position is a 0 in the command and "off" or reset is a 1.  Logically shouldn't this be the other way (0 being reset, 1 being set)? 

Also, the abort stage button stages the LM when it is pressed.  I imagine this isn't the case considering the abort stage button is depressed prior to an AGS burn in the Apollo 9 RDV procedures. 

Additionally, the staging sound effect that is played when the button is pressed plays whenever it is pressed even if staging has already been performed, should this be edited to only play upon staging, and not upon depressing the button?


Title: Re: LM status...
Post by: indy91 on May 14, 2017, 12:30:40 PM
The abort buttons seem to be depressed now when I start a scenario.  It looks like the "on" or depressed position is a 0 in the command and "off" or reset is a 1.  Logically shouldn't this be the other way (0 being reset, 1 being set)? 

Also, the abort stage button stages the LM when it is pressed.  I imagine this isn't the case considering the abort stage button is depressed prior to an AGS burn in the Apollo 9 RDV procedures. 

This is a problem with the bitmap for both abort buttons and/or the way our toggle switches work. If you look at the bitmap for e.g. normal toggle switches then you see the "up" position on the left side and the "down" position on the right side of the bitmap. The abort buttons both have the "depressed" state on the right side of the bitmap. So the only way to easily implement this without changing the bitmap or totally rewrite our toggle switch implementation was to logically invert the button settings. The disadvantage is that in all old scenarios with the LM the button will appear depressed. Just press them once and they are in their normal state. I have also changed the default position for the abort buttons, so in new scenarios where the LM gets created this won't be an issue.

Quote
Additionally, the staging sound effect that is played when the button is pressed plays whenever it is pressed even if staging has already been performed, should this be edited to only play upon staging, and not upon depressing the button?

Yes, this will be fixed once the whole staging is simulated more realistically. So that sound would only be played once when the pyros are fired for staging. I have a development branch for the Explosive Devices Subsystem and once I have a basic implementation ready then that stagin sound and a whole bunch of other stuff (like properly arming the engines with the abort buttons) will be fixed.


Title: Re: LM status...
Post by: rcflyinghokie on May 15, 2017, 09:48:14 AM
In any case, if possible create more checklist groups and not put too many checklist item in overly long checklists.

This has been started and a PR made.  There has been massive consolidation especially in the LM :)



Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 09:03:28 AM
Question with the insertion phase of rendezvous.  I have used the lambert guidance in the rtcc mfd to compute and complete the phasing burn and have been running a P34.  I have been getting good values throughout.  Now for the question:  am I to be using the computed values from P34 for the insertion?  Or am I to use the values from the RDV procedures (about a 40 minute difference in TIG)?


Title: Re: LM status...
Post by: indy91 on May 16, 2017, 09:11:25 AM
Question with the insertion phase of rendezvous.  I have used the lambert guidance in the rtcc mfd to compute and complete the phasing burn and have been running a P34.  I have been getting good values throughout.  Now for the question:  am I to be using the computed values from P34 for the insertion?  Or am I to use the values from the RDV procedures (about a 40 minute difference in TIG)?

The TPI0 calculated with P34? Look at figure 2-1 in the Rendezvous Procedures again. TPI0 and Insertion are not the same maneuver. You are only calculating the TPI0 to test if P34 works and in the case you don't get a go from MCC-H to execute the full rendezvous profile. You are spending 1.25 loops in the football shaped relative orbit. After 3/4 orbits you could execute the TPI0 maneuver, if you wanted to go back to the CSM already. The Insertion maneuver is executed half a revolution later than that. TPI0 is at 10NM below the CSM, Insertion at 10NM above.

The Insertion maneuver can not really be calculated onboard. You have to use the Coelliptic/NSR/CDH page of the RTCC MFD for that, to get into a 10NM coelliptic orbit above the CSM orbit. You can try the Fixed TIG option and see if the DH is close to 10NM. If not, then use the option that calculates the TIG at 10NM DH for you.


Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 09:20:13 AM
The TPI0 calculated with P34? Look at figure 2-1 in the Rendezvous Procedures again. TPI0 and Insertion are not the same maneuver. You are only calculating the TPI0 to test if P34 works and in the case you don't get a go from MCC-H to execute the full rendezvous profile. You are spending 1.25 loops in the football shaped relative orbit. After 3/4 orbits you could execute the TPI0 maneuver, if you wanted to go back to the CSM already. The Insertion maneuver is executed half a revolution later than that. TPI0 is at 10NM below the CSM, Insertion at 10NM above.

The Insertion maneuver can not really be calculated onboard. You have to use the Coelliptic/NSR/CDH page of the RTCC MFD for that, to get into a 10NM coelliptic orbit above the CSM orbit. You can try the Fixed TIG option and see if the DH is close to 10NM. If not, then use the option that calculates the TIG at 10NM DH for you.

Ok thats what I thought!  I think I was just confusing myself, honestly shocked everything was working and not throwing 611 errors left and right or RR designate fail errors.  I see exactly what you are talking about this is the mini football to test the P34 and RR tracking. 

I will give the Coelliptic page a shot and play with it.  But I will say, things are going pretty smooth.  I do have another question regarding the W-Matrix.  I am setting the W-Matrix to "1 MR" and recalculating the TPI, what is the purpose of this?  And are the values in the checklist (address 2002 and 1014 in R1 and R2) still good for Luminary 069?


Title: Re: LM status...
Post by: indy91 on May 16, 2017, 10:10:22 AM
Ok thats what I thought!  I think I was just confusing myself, honestly shocked everything was working and not throwing 611 errors left and right or RR designate fail errors.  I see exactly what you are talking about this is the mini football to test the P34 and RR tracking.  

The mini football is actually the half orbit between the separation burn and the phasing burn. After the phasing burn you are in the big football. You spent 1.25 orbits in this big football. After 3/4 orbits you have reached the point where TPI0 would be executed, which is not nominally done. After the insertion burn you are phasing away from the CSM in a coelliptic orbit. After the CDH burn you are once again in a coelliptic orbit, phasing towards the CSM. And the nominal TPI maneuver then happens at the exact same relative position as the TPI0 maneuver.

Quote
I will give the Coelliptic page a shot and play with it.  But I will say, things are going pretty smooth.  I do have another question regarding the W-Matrix.  I am setting the W-Matrix to "1 MR" and recalculating the TPI, what is the purpose of this?  And are the values in the checklist (address 2002 and 1014 in R1 and R2) still good for Luminary 069?

Yes, 1 MR is 1 milli radian and I can confirm the scaling is the same as in Luminary069 and the addresses are, too. Those are the W-Matrix initialization parameters for the RR shaft and trunnion.


Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 10:20:03 AM
The mini football is actually the half orbit between the separation burn and the phasing burn. After the phasing burn you are in the big football. You spent 1.25 orbits in this big football. After 3/4 orbits you have reached the point where TPI0 would be executed, which is not nominally done. After the insertion burn you are phasing away from the CSM in a coelliptic orbit. After the CDH burn you are once again in a coelliptic orbit, phasing towards the CSM. And the nominal TPI maneuver then happens at the exact same relative position as the TPI0 maneuver.

Ah ok,  I think I am visualizing this better.  Thank you for the clarification!  Now I will bug you with an RTCC issue, I cannot get the Coelliptic page to calculate anything.  I have tried both fixed and find geti and nothing seems to even be reacting.  I have the latest build and will attach a scn file.

Also I am creating a PR for my checklists through the insertion burn (untested from the point in my scn forward)


Title: Re: LM status...
Post by: indy91 on May 16, 2017, 10:36:49 AM
When I load the scenario it says "Spider" is set as the target vessel. You have to use "AS-504", because the CSM is your target. Then it calculates good solutions. At the nominal time for the insertion maneuver it is at -10.9NM Delta H (positive numbers mean you are below the target, negative numbers you are above). When you let it find the TIG then there are obviously two solutions: once when you cross the 10NM DH upwards and once downwards. One will be a few minutes earlier and one a few minutes later than the nominal TIG. You can play around with the initial guess for the TIG to get it to find either of those two 10NM crossings. I would probably choose the earlier TIG, but I don't think it's really important. The actual phasing burn would be done with a modified DH to get the TPI time to the nominal value, but that's not possible with the RTCC MFD yet.


Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 10:42:32 AM
When I load the scenario it says "Spider" is set as the target vessel. You have to use "AS-504", because the CSM is your target. Then it calculates good solutions. At the nominal time for the insertion maneuver it is at -10.9NM Delta H (positive numbers mean you are below the target, negative numbers you are above). When you let it find the TIG then there are obviously two solutions: once when you cross the 10NM DH upwards and once downwards. One will be a few minutes earlier and one a few minutes later than the nominal TIG. You can play around with the initial guess for the TIG to get it to find either of those two 10NM crossings. I would probably choose the earlier TIG, but I don't think it's really important. The actual phasing burn would be done with a modified DH to get the TPI time to the nominal value, but that's not possible with the RTCC MFD yet.

Yeah I tried switching the target after it failed the first time and still got no response, however if I switch the target before entering a GETI then it works, thanks again!  And it's also good to know that my phasing burn was calculated and performed correctly (once again thanks to your trusty RTCC MFD  :ThumbsUp432:)  Time to press on!

EDIT:  Just curious as to why I used the LM as a target for a Lambert calculation and the CSM as a target for the Coelliptic?


Title: Re: LM status...
Post by: indy91 on May 16, 2017, 10:52:00 AM
Yeah I tried switching the target after it failed the first time and still got no response, however if I switch the target before entering a GETI then it works, thanks again!  And it's also good to know that my phasing burn was calculated and performed correctly (once again thanks to your trusty RTCC MFD  :ThumbsUp432:)  Time to press on!

EDIT:  Just curious as to why I used the LM as a target for a Lambert calculation and the CSM as a target for the Coelliptic?

You should have used the CSM as the target there, too. Did you get that from my rendezvous attempt and the description in the other thread? Because that was done as a CSM active rendezvous before the LM was properly working. So there I used the CSM for all the rendezvous maneuvers and the LM as the target.


Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 11:06:14 AM
You should have used the CSM as the target there, too. Did you get that from my rendezvous attempt and the description in the other thread? Because that was done as a CSM active rendezvous before the LM was properly working. So there I used the CSM for all the rendezvous maneuvers and the LM as the target.

I believe I used the LM because I saw Falcon there in your procedure so yes.  However it appears my phasing burn was still correct?


Title: Re: LM status...
Post by: indy91 on May 16, 2017, 11:19:44 AM
I believe I used the LM because I saw Falcon there in your procedure so yes.  However it appears my phasing burn was still correct?

Not optimal probably, but still fairly good. Before the phasing burn you were only in a slightly different orbit than the CSM, that's why the calculation worked even though you calculated an offset to your own vehicle and not the CSM. If you had used the CSM as the target then the shape of the football orbit would be even better  I think.


Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 11:30:30 AM
Not optimal probably, but still fairly good. Before the phasing burn you were only in a slightly different orbit than the CSM, that's why the calculation worked even though you calculated an offset to your own vehicle and not the CSM. If you had used the CSM as the target then the shape of the football orbit would be even better  I think.

Well I think I might go back and try it out, maybe getting closer to that -10NM mark at the prescribed TIG.  Thanks again for setting me straight!


Title: Re: LM status...
Post by: rcflyinghokie on May 16, 2017, 09:57:46 PM
Not optimal probably, but still fairly good. Before the phasing burn you were only in a slightly different orbit than the CSM, that's why the calculation worked even though you calculated an offset to your own vehicle and not the CSM. If you had used the CSM as the target then the shape of the football orbit would be even better  I think.

I would still be using a -47.5 as the offset versus a +47.5 using the CSM as a target correct?


Title: Re: LM status...
Post by: indy91 on May 17, 2017, 03:50:26 AM
Yeah, just the roles of CSM and LM are reversed in comparison to my Apollo 9 rendezvous profile attempt. You still want to be 47.5NM behind your target and not in front of it, so -47.5 is correct.


Title: Re: LM status...
Post by: rcflyinghokie on May 17, 2017, 08:57:09 AM
Question regarding the Luminary 069 DAP:  The procedures ask for a DAP load of "02002"  However when I input this the LGC adds a 1 into the A position.  The G&N information I have from Apollo 12 doesn't even have a value of "0" possible for the A position.  I know in the CSM it was to turn off the DAP, is it possible that Luminary 069 used this as well?

EDIT:  On a side note, the P32 worked wonderfully and I didn't even have to manually adjust the iterations for the apsidal crossing, another check in the box for a Luminary 069 rendezvous  :ThumbsUp432:


Title: Re: LM status...
Post by: indy91 on May 17, 2017, 11:13:02 AM
Question regarding the Luminary 069 DAP:  The procedures ask for a DAP load of "02002"  However when I input this the LGC adds a 1 into the A position.  The G&N information I have from Apollo 12 doesn't even have a value of "0" possible for the A position.  I know in the CSM it was to turn off the DAP, is it possible that Luminary 069 used this as well?

Yeah, the AOH Volume 2 also has no 0 setting there. Weird. Maybe it is because of different switch settings in CSM and LM. "CMC Mode - Free" in the CSM allows you to control the spacecraft with the RHC, under CMC control. However, in the LM the Mode Control switch setting isn't called "free" but "off" and completely disables the LGC control of the LM. So that already accomplishes what "02002" would do. But no idea why the checklist says to use a 0 then. It might have still been a valid setting in Sundance, but not in Luminary anymore.


Title: Re: LM status...
Post by: rcflyinghokie on May 17, 2017, 05:28:32 PM
Yeah, the AOH Volume 2 also has no 0 setting there. Weird. Maybe it is because of different switch settings in CSM and LM. "CMC Mode - Free" in the CSM allows you to control the spacecraft with the RHC, under CMC control. However, in the LM the Mode Control switch setting isn't called "free" but "off" and completely disables the LGC control of the LM. So that already accomplishes what "02002" would do. But no idea why the checklist says to use a 0 then. It might have still been a valid setting in Sundance, but not in Luminary anymore.

What's also interesting is there is no DAP load change prior to staging, I did not see if there was one before the P42 but the P41 burn after staging would have kept this load which seems weird.  Maybe it was used in place of a 1 on Sundance?


Title: Re: LM status...
Post by: indy91 on May 18, 2017, 03:44:06 AM
What's also interesting is there is no DAP load change prior to staging, I did not see if there was one before the P42 but the P41 burn after staging would have kept this load which seems weird.  Maybe it was used in place of a 1 on Sundance?

Do you mean changing from descent stage configuration to ascent stage configuration? That is done automatically in the LGC, under some circumstances. According to the AOH that is done by:

-Program 42 at TIG- 30 seconds
-Selection of Program 71 (Ascent Stage Abort)
-Selection of Program 68 (Landing Confirmation)

EDIT: Looking at the LM Rendezvous Procedures document again. The configration 02002 seems to be fairly common. Unfortunately we don't have any checklists or cue cards for Apollo 9 and also not many information about Sundance. So at the moment I don't know what the first 0 does.


Title: Re: LM status...
Post by: rcflyinghokie on May 18, 2017, 07:44:19 AM
EDIT: Looking at the LM Rendezvous Procedures document again. The configration 02002 seems to be fairly common. Unfortunately we don't have any checklists or cue cards for Apollo 9 and also not many information about Sundance. So at the moment I don't know what the first 0 does.

Yeah even the onboard transcript doesn't help, though they do read off "02002" so it's no typo.  When I put a 0 into that position and proceed it just changes it to a 1.  This is also curious because I am supposed to use a PGNS auto maneuver for the P41 after sep, so I do not think the 0 turns off the DAP like in the CM, and perhaps it was the ascent stage configuration using a 0 instead of a 1?

EDIT:  On another note, I cannot tell if they vented the DPS before staging, the only thing I can find is to perform the pre stage checks which I found in the AOH.

EDIT 2:  Well I am happy to report that staging, RCS CSI, and APS CDH maneuvers calculated on board with RR updates to the SV have all been successful and very close to the flight plan parameters.  This is of course no guarantee that the final rendezvous will be successful, but so far Luminary 069 is performing quite well!


Title: Re: LM status...
Post by: indy91 on May 18, 2017, 12:32:43 PM
The JSC History Collection at UHCL (https://www.jsc.nasa.gov/history/history_collection/uhcl.htm) has a few Sundance Guidance System Operations Plan (GSOP) documents which will tell us everything we want about Verb 48. They are very accommodating with scanning documents, that they don't have available as PDFs yet. I already requested a whoooole bunch of Spacecraft Operational Trajectory documents, so maybe you can request those documents @rcflyinghokie instead of me?

Just search for the documents here: http://historycollection.jsc.nasa.gov/default.htm by using title search with: Guidance System Operations Plan Sundance. They seem to have section 4, 5 and 6. Section 4 will have detailed descriptions of Verb 48. Just send an email to the archivist, Lauren Meyers, and request the documents with their name, location and ID. You will then probably get the scanned documents via Dropbox. You can then tell me the link per PM, or so, Ron Burkey from the Virtual AGC project will also want to host these documents on the Virtual AGC website, as he has done in the past with all AGC related documents.


Title: Re: LM status...
Post by: rcflyinghokie on May 18, 2017, 05:18:19 PM
The JSC History Collection at UHCL (https://www.jsc.nasa.gov/history/history_collection/uhcl.htm) has a few Sundance Guidance System Operations Plan (GSOP) documents which will tell us everything we want about Verb 48. They are very accommodating with scanning documents, that they don't have available as PDFs yet. I already requested a whoooole bunch of Spacecraft Operational Trajectory documents, so maybe you can request those documents @rcflyinghokie instead of me?

Just search for the documents here: http://historycollection.jsc.nasa.gov/default.htm by using title search with: Guidance System Operations Plan Sundance. They seem to have section 4, 5 and 6. Section 4 will have detailed descriptions of Verb 48. Just send an email to the archivist, Lauren Meyers, and request the documents with their name, location and ID. You will then probably get the scanned documents via Dropbox. You can then tell me the link per PM, or so, Ron Burkey from the Virtual AGC project will also want to host these documents on the Virtual AGC website, as he has done in the past with all AGC related documents.

Sure I have no problem doing that!  I will let you guys know when I get the documents and share the wealth  :wink:

EDIT:  Lauren Meyers has gotten back to me the Sundance documents have not been scanned but she will share them when they have been  :ThumbsUp432:


Title: Re: LM status...
Post by: rcflyinghokie on May 20, 2017, 01:45:25 PM
So I am going back to run my RDV again and I am wondering where you got the Phasing T2 time that you used in your attempt with Apollo 9?  I see on the diagram where the phasing burn puts the LM about 46 nm behind the CSM but I do not see what time this is supposed to be.  The reason I ask is, well first of course I need it for the maneuver, but second I am trying to make sure I fully understand how to use these charts.


Title: Re: LM status...
Post by: indy91 on May 20, 2017, 04:21:29 PM
So I am going back to run my RDV again and I am wondering where you got the Phasing T2 time that you used in your attempt with Apollo 9?  I see on the diagram where the phasing burn puts the LM about 46 nm behind the CSM but I do not see what time this is supposed to be.  The reason I ask is, well first of course I need it for the maneuver, but second I am trying to make sure I fully understand how to use these charts.

I can't remember how I came up with that number. I think I already did some calculations that will be done by the proper "football targeting" one day. There is half an orbit from phasing to the T2 point, so I probably used the orbital period of the CSM from the Orbit MFD and divided by 2. That's one of the essential properties of the football shaped relative orbit, it has the same orbital period as your target.


Title: Re: LM status...
Post by: rcflyinghokie on May 22, 2017, 02:53:04 PM
I have the files for Sundance.  Looks like the A digit in the DAP was literally CSM docked or undocked.  There was no ascent stage/descent stage setting.


Title: Re: LM status...
Post by: rcflyinghokie on May 22, 2017, 05:39:08 PM
I can also report that I have successfully completed a LM active rendezvous with Luminary 069.  The burns were a bit sloppy as a result from my initial phasing and insertion burn calculations but the CSI/CDH/TPI all got me back to the CSM and braking phase was successful.  I will say that without the RR holding a lock it is very challenging to use the tapemeters for the braking gates! 

I will be going back through it again from undocking to see if my initial burns perturbed enough to give numbers that were different from the flight plan, but regardless after insertion, all maneuvers were calculated and performed with the LGC  :)


Title: Re: LM status...
Post by: indy91 on May 23, 2017, 03:38:19 AM
Thanks for getting us the documents! I guess the Sundance DAP simply used the weight as the parameter to achieve good control over the ascent stage. Luminary just does it in a more elaborate way, with a separate DAP configuration for the ascent stage.

jalexb88 requested two LM Systems Handbook and I am currently using that to finish up some work on the Explosive Devices Subsystem and the APS control logic. That is related, because the firing command for the APS is what causes staging. So pressing Abort Stage doesn't immediately cause stage separation. It just arms the Ascent engine and a firing command is coming from LGC or AGS. So during a nominal lunar liftoff the staging pyros are firing at T-0 and not when the Abort Stage button was pressed. The Stage Fire switch also can initiate staging, of course. The LM-1 Systems Handbook is already available, I might wait for the LM-8 one to be scanned before I push my ED/APS control logic update, just to cross check a few things and make sure it's not a LM-1 specific configuration.


Title: Re: LM status...
Post by: rcflyinghokie on May 23, 2017, 03:20:24 PM
For the Apollo 9 SM RCS SEP burn, what is the best way without an MCC update to burn 5fps radially down?  Wouldn't that be burning towards the center of the earth?  I tried a P30 with dVZ -5fps and it faces me in the opposite direction.  Maybe I do not understand the reference frame for the burn vectors as well as I thought!


Title: Re: LM status...
Post by: indy91 on May 23, 2017, 03:23:30 PM
For the Apollo 9 SM RCS SEP burn, what is the best way without an MCC update to burn 5fps radially down?  Wouldn't that be burning towards the center of the earth?  I tried a P30 with dVZ -5fps and it faces me in the opposite direction.  Maybe I do not understand the reference frame for the burn vectors as well as I thought!

Downwards is positive along the Z-axis. So the best way is to use the manual TIG/DV input on the Maneuver PAD page of the RTCC MFD, with the DV input "0 0 5" for 5 ft/s downwards.


Title: Re: LM status...
Post by: rcflyinghokie on May 23, 2017, 03:40:52 PM
Downwards is positive along the Z-axis. So the best way is to use the manual TIG/DV input on the Maneuver PAD page of the RTCC MFD, with the DV input "0 0 5" for 5 ft/s downwards.

Perfect thanks!  I am just trying to polish up these maneuvers so I can have a cleaner rendezvous :)

EDIT:  And a little cleaner it was this time.  Less time flipping from checklist to checklist and more time playing hurry up and wait.  I still get some weird TPI numbers, nothing as unusual this time (my first go I actually lit my APS again because of a 60fps burn) but still another successful rendezvous.  I did a LM active docking as well this time, and the orientation change is tricky at first to get used to when maneuvering for a dock, but still everything worked.  I am going to stop there checklist-wise for now and am going back to the very beginning now that I can launch with Orbiter 2016, and see if I can make these first SPS burns cleaner using the Maneuver PAD manual inserts instead of orbit adjustment page, and of course debug the checklist thus far.


Title: Re: LM status...
Post by: rcflyinghokie on May 26, 2017, 09:25:44 AM
So I have noticed now whenever I load a quicksave in the LM, the event timer is counting up if it was running, even if it was counting down before.  I don't know if this was a problem before or after the power transient fixes but if someone wouldn't mind taking a look at it?  I imagine it would be a simple fix.


Title: Re: LM status...
Post by: indy91 on May 26, 2017, 10:55:00 AM
So I have noticed now whenever I load a quicksave in the LM, the event timer is counting up if it was running, even if it was counting down before.  I don't know if this was a problem before or after the power transient fixes but if someone wouldn't mind taking a look at it?  I imagine it would be a simple fix.

The proper mission and event timer saving/loading functions weren't used yet in the LM, so only the time and the state (running or not running) were saved before, not if it was counting up or down. That can't really be fixed in old scenarios, but I will add the correct saving and loading in the LM.

Also, this: https://github.com/dseagrav/NASSP/pull/92#issuecomment-304244421


Title: Re: LM status...
Post by: rcflyinghokie on May 26, 2017, 04:30:28 PM
Also, this: https://github.com/dseagrav/NASSP/pull/92#issuecomment-304244421

Regarding this, now I am getting a "merge conflict" and also when I fetch, I am seeing origin as an option instead of just upstreams.

Auto-merging Doc/Project Apollo - NASSP/Checklists/Apollo 9 LM Checklists.xls
CONFLICT (content): Merge conflict in Doc/Project Apollo - NASSP/Checklists/Apollo 9 LM Checklists.xls
Auto-merging Doc/Project Apollo - NASSP/Checklists/Apollo 7 Checklists.xls
CONFLICT (content): Merge conflict in Doc/Project Apollo - NASSP/Checklists/Apollo 7 Checklists.xls
Automatic merge failed; fix conflicts and then commit the result.
warning: Cannot merge binary files: Doc/Project Apollo - NASSP/Checklists/Apollo 9 LM Checklists.xls (HEAD vs. a6d66491af6611122e1ce8013fa296083d9eef2a)
warning: Cannot merge binary files: Doc/Project Apollo - NASSP/Checklists/Apollo 7 Checklists.xls (HEAD vs. a6d66491af6611122e1ce8013fa296083d9eef2a)

EDIT: I just reinitialized and set up my git and the problem was fixed.  No clues as to what happened, but all is well now.  The PR with the changes to all checklists has been made as well.



Title: Re: LM status...
Post by: rcflyinghokie on June 03, 2017, 11:40:12 AM
@Indy91 I see you pushed some LM logic fixes, just wondering what this actually is doing to the LM?  And should I expect any differences when I make my burns?


Title: Re: LM status...
Post by: indy91 on June 03, 2017, 11:57:59 AM
A few days ago I (kind of) accidentally pushed the big APS/DPS control logic update, during the process of renaming the Orbiter2015 branch. It wasn't 100% ready, so I knew about a few smaller issues. This fix today specifically fixes the case if the LGC sends neither Engine On or Engine Off signals. Sunburst120 is kind of lazy about that, it only sends an EngineOff signal during the burn programs (P4X), before and after the burn itself. The result was, in combination with the bugs, that setting the Engine Arm switch to ASC alone could cause the engine to start. So it would start without an actual engine on signal. The DPS had a similar bug, but instead of the engine staying on it would cycle on and off. Both of these issues should now be fixed. I think Luminary always sends an Engine Off signal whenever the engine isn't running, so these issues would never occur.

In any case, with these fixes the engine on/off logic should be pretty realistic now. The difference to before the big update is that some special cases work or work better now, like the Descent Engine Command Override switch and the Abort Stage button arming the ascent engine, even if the Engine Arm switch is still set to Descent. The wiring of the control logic is mostly based on the LM-1 Systems Handbook right now. An LM-8 Systems Handbook is currently being scanned and I will change the wiring to how it worked in LM-8. LM-1 didn't have a few circuit breakers of the later LMs.


Title: Re: LM status...
Post by: rcflyinghokie on June 06, 2017, 10:17:40 AM
I don't know if any recent changes did this, but I just started the second LM powerup (I did the first LM powerup before the last few builds) and now closing the LGC breaker turns off the DKSY.  I have attached my recent checklist and the scn file where it is powered up again.


Title: Re: LM status...
Post by: lotisully86 on June 06, 2017, 02:50:29 PM
Also have encountered this, the LGC warning lights work I believe but the numerical lights go blank once the breaker is closed. Also the standby light is not lit even tho the LGC hasn't been brought out of standby.

Somewhat related, after uplinking the LM state vector before the first dps burn, the comp activity stays lit and I can not get to P00 without a V96. Is this behavior expected?


Title: Re: LM status...
Post by: indy91 on June 06, 2017, 03:05:26 PM
Also have encountered this, the LGC warning lights work I believe but the numerical lights go blank once the breaker is closed. Also the standby light is not lit even tho the LGC hasn't been brought out of standby.

The DSKY being on before it should have power and the DSKY being off with the circuit breaker closed are actually two unrelated issues. The AGC can command the DSKY to be off in standby mode, but this signal and the actual standby mode currently become desynced if you completely cut the power. Thymo is working on fixing that.

Quote
Somewhat related, after uplinking the LM state vector before the first dps burn, the comp activity stays lit and I can not get to P00 without a V96. Is this behavior expected?

First DPS burn? With which LGC version?


Title: Re: LM status...
Post by: lotisully86 on June 06, 2017, 03:58:10 PM
When uplinking the state vector and target load for the first dps burn yes. If just the target load is uploaded, it does not cause this behavior. I believe it is luminary 069? I started from the Apollo 9 MCC launch scenario using the latest modules, so I'm just assuming 069 is the default setting


Title: Re: LM status...
Post by: Thymo on June 06, 2017, 04:12:36 PM
The desync also appeared in the CSM. It has now been fixed for both of them.

The DSKY in the LM is now wired to its proper breaker that fixes the inconsistent breaker state.


Title: Re: LM status...
Post by: rcflyinghokie on June 06, 2017, 06:34:03 PM
When uplinking the state vector and target load for the first dps burn yes. If just the target load is uploaded, it does not cause this behavior. I believe it is luminary 069? I started from the Apollo 9 MCC launch scenario using the latest modules, so I'm just assuming 069 is the default setting

Are you using the RTCC MFD or PAMFD?


Title: Re: LM status...
Post by: lotisully86 on June 06, 2017, 08:17:41 PM
Have tried both. Lm slot, spider target vessel


Title: Re: LM status...
Post by: rcflyinghokie on June 06, 2017, 09:22:39 PM
Yeah its using Luminary 069.  I have run through that phase 3 times now without having that problem.  Mind posting a scn file?

EDIT: You said you have the latest modules, but do you have the latest build?


Title: Re: LM status...
Post by: lotisully86 on June 07, 2017, 02:20:50 AM
Will post a .scn in a bit, headed home from work now. I fetched and compiled the modules, will give it a whirl with the latest build


Title: Re: LM status...
Post by: indy91 on June 07, 2017, 02:29:29 AM
Are you sure you have a healthy CSM state vector as well? Uplinking an LM state vector can trigger a state vector integration, which always propagates both CSM and LM state vectors. And if one of the state vectors is bad in some way, the integration can fail. So, try to uplink a state vector to the CSM slot as well.


Title: Re: LM status...
Post by: lotisully86 on June 07, 2017, 02:59:39 AM
Are you sure you have a healthy CSM state vector as well? Uplinking an LM state vector can trigger a state vector integration, which always propagates both CSM and LM state vectors. And if one of the state vectors is bad in some way, the integration can fail. So, try to uplink a state vector to the CSM slot as well.

will try this as well, i only uplinked the lm state vector, thats what the apollo 9 flightplan and checklist calls for. should the uplink be followed by V66? or should the csm state vector be uplinked


Title: Re: LM status...
Post by: indy91 on June 07, 2017, 03:31:32 AM
Actually, as part of the padload the largest possible number is loaded for the CSM and LM state vector times. That should inhibit the initial P00 state vector integration. So even if no valid CSM state vector is loaded at all, there shouldn't be this problem. Maybe your scenario will help with solving the issue.


Title: Re: LM status...
Post by: lotisully86 on June 07, 2017, 04:27:24 AM
sorry heres the scenerio, just before mcc uplink at 48:10:00. using the latest build, uplinking both lm and csm state vectors solved the problem, if just the lm s.v is uploaded the problem persists


Title: Re: LM status...
Post by: rcflyinghokie on June 07, 2017, 09:40:47 AM
sorry heres the scenerio, just before mcc uplink at 48:10:00. using the latest build, uplinking both lm and csm state vectors solved the problem, if just the lm s.v is uploaded the problem persists

Interesting I am having the same issue.  I have not had this problem on any of my 9 flights.

EDIT:  Loaded it again and performed just a SV update for the LM with no lingering light, I cannot get the problem to duplicate itself anymore it seems.  Every time I load it now and do the same thing, I have no issues, only the first time I loaded your scn.  I have tried 12 times now and only the first time did I duplicate your problem.  Maybe you can quicksave when you have the light stuck and post it?


Title: Re: LM status...
Post by: lotisully86 on June 07, 2017, 12:01:51 PM

Interesting I am having the same issue.  I have not had this problem on any of my 9 flights.

EDIT:  Loaded it again and performed just a SV update for the LM with no lingering light, I cannot get the problem to duplicate itself anymore it seems.  Every time I load it now and do the same thing, I have no issues, only the first time I loaded your scn.  I have tried 12 times now and only the first time did I duplicate your problem.  Maybe you can quicksave when you have the light stuck and post it?

heres a .scn with the comp lite lit after uplink


Title: Re: LM status...
Post by: rcflyinghokie on June 07, 2017, 06:30:38 PM
If you V96 and uplink another does it come back for you?  Because it cleared for me.


Title: Re: LM status...
Post by: lotisully86 on June 08, 2017, 02:28:02 AM
If you V96 and uplink another does it come back for you?  Because it cleared for me.

uplinking just the lm state vector again, no it does not clear. however uplinking just the cm state vector clears the light


Title: Re: LM status...
Post by: indy91 on June 08, 2017, 04:19:25 AM
One thing I learned from the Apollo 8 CMP Checklist is that when the coasting integration routine is running in the AGC, it always stores the GET of the currently integrated state vector in Noun 38. Looking at N38 in your scenario with the continuous computer activity light, the AGC seems to want to integrate the state vector far into the future. I can only imagine that the padloaded state vector time is responsible for that. I think it would continue to propagate the state vector until the GET reaches about a month, that's the maximum state vector time the AGC can deal with. But I am still not sure why the AGC does this. Maybe it's a AGC version thing and Sundance can deal with just one state vector having been uplinked, while Luminary needs both and in a specific order? No idea really...

EDIT: Of course with Luminary069 being 2 revisions short of the flown Apollo 10 version, there could be some bugs that were fixed in Luminary 069 Rev. 2. That is unlikely however, we have a fairly good idea about the two revisions that were done to Luminary069 before it was released to be manufactured. But there always could be some anomaly fixes that didn't warrent its own revision number.


Title: Re: LM status...
Post by: rcflyinghokie on June 08, 2017, 06:48:03 PM
One thing I learned from the Apollo 8 CMP Checklist is that when the coasting integration routine is running in the AGC, it always stores the GET of the currently integrated state vector in Noun 38. Looking at N38 in your scenario with the continuous computer activity light, the AGC seems to want to integrate the state vector far into the future. I can only imagine that the padloaded state vector time is responsible for that. I think it would continue to propagate the state vector until the GET reaches about a month, that's the maximum state vector time the AGC can deal with. But I am still not sure why the AGC does this. Maybe it's a AGC version thing and Sundance can deal with just one state vector having been uplinked, while Luminary needs both and in a specific order? No idea really...

EDIT: Of course with Luminary069 being 2 revisions short of the flown Apollo 10 version, there could be some bugs that were fixed in Luminary 069 Rev. 2. That is unlikely however, we have a fairly good idea about the two revisions that were done to Luminary069 before it was released to be manufactured. But there always could be some anomaly fixes that didn't warrent its own revision number.

Well to be safe, should I just add a V66 after this uplink?


Title: Re: LM status...
Post by: indy91 on June 09, 2017, 03:22:18 PM
Well to be safe, should I just add a V66 after this uplink?

That will work I guess.

For the longest time the LGC had a clock drift issues. Usually a few seconds after a few hours of coasting. I have pushed a potential fix. The LGC cycles now work the same way as the CMC cycles. Hopefully that fixes the issue.


Title: Re: LM status...
Post by: rcflyinghokie on June 11, 2017, 05:22:40 PM
I may have found an issue with the LM ED system.  If the stage switch is moved to fire at all, it is "armed".  In other words I can flip the switch to fire with the master arm off, safe and guard it, and then as soon as the master arm switch is flipped it will fire the stage.  Shouldnt it only fire if actually in the fire position with the master arm on?


Title: Re: LM status...
Post by: eddievhfan1984 on June 11, 2017, 06:26:48 PM
Are you saying that you expect the staging switches to be disabled even after master arm is on until they are reset to SAFE, then FIRE? Because I wouldn't expect that. In the CSM, if you enabled the sequential logic and pyro arms with any of the pyro firing switches held ON, they'd fire the moment PYRO ARM was enabled.


Title: Re: LM status...
Post by: rcflyinghokie on June 11, 2017, 06:59:39 PM
No no the switch was safe and guarded when master arm was flipped on.  And the stage fired.  Playing with it I found if I flipped it to fire and returned it to safe with master arm off, then later flipped master arm it would fire, even though the stage fired switch was safe.


Title: Re: LM status...
Post by: eddievhfan1984 on June 11, 2017, 10:18:51 PM
OH, master arm logic is just jammed. OK. Easy fix.


Title: Re: LM status...
Post by: indy91 on June 12, 2017, 04:51:35 AM
This is not a bug. The Staging relay (K2) is a latching relay. It is set by the Stage Fire switch, when it has power from its ED circuit breaker (systems A and B), and it is also set by the engine electronics when the ascent engine is firing. It can be only be reset by the Stage Relay Reset switch. So this operation doesn't need the Master Arm switch to be on. The Master Arm switch switches power on from the ED Batteries to the explosive devices. So for the staging pyros to actually fire, the Master Arm switch is needed, in addition to the Staging relay being set of course. This can in theory be done in two steps: Stage Fire to fire and then to safe and then later the staging is actually done with the Master Arm switch. There is nothing that would prevent this from happening as two separate events.

However, something that isn't implemented yet is that you would get a Master Alarm, if you energize the Staging relay without actually firing the staging pyros. Because it wouldn't be the proper procedure to do this. I'll work on the logic for this alarm soon.


Title: Re: LM status...
Post by: rcflyinghokie on June 12, 2017, 09:05:34 PM
Here are the stats on the LM Ascent Battery usage, seems like they drain too quickly to me but I don't know.
(https://www.dropbox.com/s/7k71avi3hdb6fyn/LM%20ASC%20Bat%20Draw.jpg?dl=0)


Title: Re: LM status...
Post by: indy91 on June 22, 2017, 06:14:48 AM
The update I have been working on for a while now has been released! It includes:

-Implemented CDU class. The Coupling Data Units for the Rendezvous Radar shaft and trunnion angles are functional, including read counter, error counter and alternative output for the X-Pointer.
-Overhaul of the Rendezvous Radar, with corrected RR antenna direction vector, LGC is able to drive the RR and a few display changes.

With these changes the interaction between LGC and RR should be mostly functional. I have successfully moved the RR to the AOT alignment attitude, in P20 to the direction of the CSM and in P22 (Lunar Surface Navigation) to the direction where the CSM comes over the horizon.

What hasn't been implemented yet is the RR Auto Tracking. The auto tracking is used with the RR switch to Auto Track and also in LGC mode whenever the LGC sends the Auto Track Enabled bit. So proper tracking for rendezvous and lunar surface navigation will still not properly work. But I will work on that next.

The CDU implemention will be expanded to be used by IMUs and CMC optics in the future. For now it only gets used as the two RR CDUs. Once it is implemented for the IMU, then the ICDU Zero (V40 N20) can be used without the alignment being changed.


Title: Re: LM status...
Post by: indy91 on June 23, 2017, 08:06:14 AM
The Rendezvous Radar now has the Auto Tracking capability!

It gets used with the RR switch set to Auto Track, or in the LGC position when the LGC sends a signal to the RR that it should take over control. A signal strength is now calculated, which gets displayed on the signal strength meter with the Temp/Monitor rotary set to AGC. Shaft and Trunnion error of the auto tracking also gets displayed on that meter. Currently the signal strength doesn't go down with range, I couldn't figure out a good calculation for this. Maybe someone who knows more about antennas and radars than me can try to figure that out some day.

I have tested the auto tracking with P20 and P22. In P22 the RR can't take advantage of the gyros, which help the RR to hold inertial attitude. These gyros haven't been implemented yet anyway. The auto tracking is just about fast enough to hold lock on the CSM during P22. I also tested a full rendezvous with P20 and the only times I lost lock was due to LM attitude maneuvers. This is where the gyros will help as well. There were no other major issues during the rendezvous, the RR perfectly updated the state vector. So the LM is now fully capable of rendezvous operations!


Title: Re: LM status...
Post by: lotisully86 on June 23, 2017, 11:13:06 AM
did the recent changes maybe break something on the csm imu or fdai's? Showing zero motion on either fdai corresponding to the imu..


Title: Re: LM status...
Post by: indy91 on June 23, 2017, 11:41:51 AM
did the recent changes maybe break something on the csm imu or fdai's? Showing zero motion on either fdai corresponding to the imu..

No, that seems to work fine for me. Do you have a scenario where that happens? Or if it happens in every scenario, maybe try rebuilding the Visual Studio solution, if you are using Visual Studio.


Title: Re: LM status...
Post by: abr35 on June 23, 2017, 12:19:26 PM
Nice work on the auto tracking! :ThumbsUp432: Going to try and give a landing mission a whirl from launch to splashdown before too long. And I did not experience the issue with the CSM FDAIs


Title: Re: LM status...
Post by: lotisully86 on June 23, 2017, 12:46:15 PM
rebuilt solution, problem remains. lm has same problem as well. heres my scn, havent tried any other ones yet

EDIT: scn is Apollo 9 90:15:00 approx, just before p52 opt1

also agc is throwing 211 and 217 alarms on the P52


Title: Re: LM status...
Post by: indy91 on June 23, 2017, 01:05:58 PM
It's a bug I introduced when I implemented the RR CDUs. No commands from the AGC are currently coming through to the IMU. Easy fix, I think.

EDIT: Should be fixed now. I have not been able to make your scenario work again though. Older scenarios should work properly though. If that is not the case, please tell. Sorry for the inconvenience.


Title: Re: LM status...
Post by: lotisully86 on June 23, 2017, 02:13:19 PM
Been meaning to ask this for a while, is anybody else using a two stick set up for the lm? I'm not getting any throttle commands with either joystick as the ttca when in throttle mode, actually am getting rcs commands when in throttle, although if I use the slider on the Aca the thrust indicator will show a quick slight movement b4 reverting back to 20%. In my lm launchpad config file there is a TJT but has no assigned value I'm guessing it might be that, just seeing if anyone has had the same issue


Title: Re: LM status...
Post by: indy91 on June 23, 2017, 02:58:51 PM
Been meaning to ask this for a while, is anybody else using a two stick set up for the lm? I'm not getting any throttle commands with either joystick as the ttca when in throttle mode, actually am getting rcs commands when in throttle, although if I use the slider on the Aca the thrust indicator will show a quick slight movement b4 reverting back to 20%. In my lm launchpad config file there is a TJT but has no assigned value I'm guessing it might be that, just seeing if anyone has had the same issue

So you are using two sticks? I haven't tried that yet. I implemented some of the LM joystick functionality (mostly throttle for the DPS), but without being able to test the two stick setup I didn't focus too much on making that work. I will take a look though. Is it properly working in the CSM for you with two joysticks? Then it might just be a case of copying some of the code over to the LM.


Title: Re: LM status...
Post by: lotisully86 on June 23, 2017, 03:45:22 PM
Works fine with the csm. I'm using a sidewinder precision 2 and thrustmaster hotas 4. So with the thrustmaster z axis is the throttle lever and the rz axis is the rotator,  there is a slider but it's a rocker button. The sidewinder is pretty standard with the z axis as the rotator and slider as the throttle. Both work fine in any config in the csm. In the lm I think the main problem is with the TJT and that it's not switching from jets to throttle, because I'm only getting rcs commands no matter if the throttle is forward(jets) or back(throttle) . If I turn the left ttca switch off I'm able to use the Aca joystick slider as to give thrust commands, only problem is nassp reads the thrustmaster slider (that's the rocker) as the throttle and not the actual throttle itself (the z axis). So 2 joystick setup with thrustmaster as aca and left ttca switched off I can use give throttle commands with tha aca rocker but they will return back to about 40% once I release the rocker button. Sidewinder as the aca and left ttca off I can give throttle commands normally with the slider. In either config with the ttca switch up the throttle just sticks at 10%.

Hope that all makes sense   :beathead:


Title: Re: LM status...
Post by: indy91 on June 24, 2017, 09:48:14 AM
Works fine with the csm. I'm using a sidewinder precision 2 and thrustmaster hotas 4. So with the thrustmaster z axis is the throttle lever and the rz axis is the rotator,  there is a slider but it's a rocker button. The sidewinder is pretty standard with the z axis as the rotator and slider as the throttle. Both work fine in any config in the csm. In the lm I think the main problem is with the TJT and that it's not switching from jets to throttle, because I'm only getting rcs commands no matter if the throttle is forward(jets) or back(throttle) . If I turn the left ttca switch off I'm able to use the Aca joystick slider as to give thrust commands, only problem is nassp reads the thrustmaster slider (that's the rocker) as the throttle and not the actual throttle itself (the z axis). So 2 joystick setup with thrustmaster as aca and left ttca switched off I can use give throttle commands with tha aca rocker but they will return back to about 40% once I release the rocker button. Sidewinder as the aca and left ttca off I can give throttle commands normally with the slider. In either config with the ttca switch up the throttle just sticks at 10%.

Hope that all makes sense   :beathead:

I did a few fixes for the joysticks in the LM. I connected my Xbox 360 controller as the ACA and my proper joystick as the TTCA and both seem to properly work now. Please let me know how it works for you now.


Title: Re: LM status...
Post by: lotisully86 on June 24, 2017, 09:57:35 AM
I'm away until next weekend, will try it out first thing when I get back.


Title: Re: LM status...
Post by: lotisully86 on July 01, 2017, 11:35:48 PM
Just following up did a quick test and can comfirm the ttca seems to be behaving correctly with two sticks now. Thanks!

EDIT:just a heads up, I think the slider positions are inverted, i.e.  Forward is jets and back is throttle.


Title: Re: LM status...
Post by: abr35 on July 04, 2017, 09:26:59 AM
Really puzzled by this one: perhaps I initialized the LGC wrong? Or maybe a broken pad load? I followed the LM Activation checklist for Apollo 12, omitting 1 step that seemed to involve setting a PIPA bias.  However every fresh state vector I get turns to garbage. My P30 for DOI has an HA and HP of -9372. TEPHEM is set and matches the command module. IMU is aligned and can point the AOT at a requested star. LGC clock is updated. I'm also getting a program alarm 21204 in P40 and P52 after which both program terminate. Any ideas?


Title: Re: LM status...
Post by: indy91 on July 04, 2017, 11:09:14 AM
Really puzzled by this one: perhaps I initialized the LGC wrong? Or maybe a broken pad load? I followed the LM Activation checklist for Apollo 12, omitting 1 step that seemed to involve setting a PIPA bias.  However every fresh state vector I get turns to garbage. My P30 for DOI has an HA and HP of -9372. TEPHEM is set and matches the command module. IMU is aligned and can point the AOT at a requested star. LGC clock is updated. I'm also getting a program alarm 21204 in P40 and P52 after which both program terminate. Any ideas?

I've tested your scenario a bit. It appears you have two LM batteries that are almost completely drained. The result is also some warning lights, DC BUS, and when you apply a heavy load like during RCS firings, then you even get a PRE AMPS light. So the issue could be intermittent power failures in the LGC. When I try your scenario I can sucessfully uplink state vectors with the RTCC MFD and go through P30. I get no program alarms in P40, but the RCS stopped working due to lack of power.

I believe your LM spent the entire translunar coast period powering it's own running systems, which isn't much, only stuff like standby heaters etc, but still enough to drain two of the batteries quite a bit. And now you get really low voltages on your DC Buses. This probably wasn't even a user error, you might have followed the checklist after TLI by the book. Maybe the checklist told you to start powering the LM from the CSM before the LM was separated from the S-IVB? That could be an issue, because technically the LM doesn't exist in Orbiter yet before it gets separated from the S-IVB.

You can try to fix this by searching for "DSC_BATTERY_A" in your scenario and give it 100% juice again, which is the value 44820000.0. Do this for both batteries A and D, those are the ones drained below 20% or so.

Independently from this I think we have some general power issues in the LM. Something draws too much power in general. You can barely fly a nominal mission with the LM without running into trouble with the batteries.


Title: Re: LM status...
Post by: abr35 on July 04, 2017, 11:41:59 AM
Really puzzled by this one: perhaps I initialized the LGC wrong? Or maybe a broken pad load? I followed the LM Activation checklist for Apollo 12, omitting 1 step that seemed to involve setting a PIPA bias.  However every fresh state vector I get turns to garbage. My P30 for DOI has an HA and HP of -9372. TEPHEM is set and matches the command module. IMU is aligned and can point the AOT at a requested star. LGC clock is updated. I'm also getting a program alarm 21204 in P40 and P52 after which both program terminate. Any ideas?

I've tested your scenario a bit. It appears you have two LM batteries that are almost completely drained. The result is also some warning lights, DC BUS, and when you apply a heavy load like during RCS firings, then you even get a PRE AMPS light. So the issue could be intermittent power failures in the LGC. When I try your scenario I can sucessfully uplink state vectors with the RTCC MFD and go through P30. I get no program alarms in P40, but the RCS stopped working due to lack of power.

I believe your LM spent the entire translunar coast period powering it's own running systems, which isn't much, only stuff like standby heaters etc, but still enough to drain two of the batteries quite a bit. And now you get really low voltages on your DC Buses. This probably wasn't even a user error, you might have followed the checklist after TLI by the book. Maybe the checklist told you to start powering the LM from the CSM before the LM was separated from the S-IVB? That could be an issue, because technically the LM doesn't exist in Orbiter yet before it gets separated from the S-IVB.

You can try to fix this by searching for "DSC_BATTERY_A" in your scenario and give it 100% juice again, which is the value 44820000.0. Do this for both batteries A and D, those are the ones drained below 20% or so.

Independently from this I think we have some general power issues in the LM. Something draws too much power in general. You can barely fly a nominal mission with the LM without running into trouble with the batteries.

Well that did it! Thanks, perhaps it was restarting mid uplink? There must be a step omitted from the word checklists as I distinctly remember seeing "LM PWR - OFF/rset" after ejection and thinking it was a bit odd to have the breakers in but not power the LEM. So I guess I dutifully let the batteries power Intrepid the whole way out  :ROTFL3453:


Title: Re: LM status...
Post by: indy91 on January 05, 2018, 11:16:18 AM
This rearranges some things in initialization to cause them to be more like the CSM, and introduces a few timesteps of delay into startup to allow busses to settle before clocking systems. This is probably not the -correct- solution, I think something is wrong with the LM's use of panelsdk. I'll dig for more later. Anyway, the LGC should survive a scenario load now. I tested for the minimum delay and found it to be 4 timesteps.

I don't expect you to remember this issue, dseagrav, but I finally found what was wrong with it. The LEM_BusFeed class has a UpdateFlow function that needs to be called at least once by the electrical system to update its voltage. And these systems were added to the electrical system (AddElectrical function) in the order that was not identical to the propagation of the voltage from the batteries to the CDR and LMP buses. Actually, it was in the exactly wrong order (Bus Feed E first, Bus Feed B last). Changing the order of these AddElectrical calls to how the batteries, DC buses, bus feeds and circuit breakers are actually chained together results in DC and AC voltage being available on timestep 1. Hopefully this doesn't have any side effects.