Meadville Space Center
Welcome, Guest. Please login or register.
October 25, 2020, 06:13:48 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
  Show Posts
Pages: 1 2 3 [4]
46  Project Apollo - NASSP / Programming / Re: LM status... 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.  Happy
47  Project Apollo - NASSP / Programming / Re: LM status... 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) or 2.868 which is what I get calculating it myself from this GSOP section 6.
(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?
48  Project Apollo - NASSP / Programming / Re: LM status... 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:

val = lem->agc.GetErasable(0, 055);


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, 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?
Pages: 1 2 3 [4]
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!