Meadville Space Center
Welcome, Guest. Please login or register.
September 23, 2020, 06:34:55 PM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  LM status...
« previous next »
Pages: 1 ... 63 64 [65] 66 67 Print
Author Topic: LM status...  (Read 159500 times)
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #960 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.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #961 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?
Logged
lotisully86
Full Member
***
Posts: 37


View Profile
« Reply #962 on: June 06, 2017, 08:17:41 PM »

Have tried both. Lm slot, spider target vessel
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #963 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?
« Last Edit: June 06, 2017, 09:31:40 PM by rcflyinghokie » Logged
lotisully86
Full Member
***
Posts: 37


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


View Profile
« Reply #965 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.
Logged
lotisully86
Full Member
***
Posts: 37


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


View Profile
« Reply #967 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.
Logged
lotisully86
Full Member
***
Posts: 37


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

* (Current state) 0001 0002 0002 0001 0002.scn (169.11 KB - downloaded 58 times.)
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #969 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?
« Last Edit: June 07, 2017, 10:06:43 AM by rcflyinghokie » Logged
lotisully86
Full Member
***
Posts: 37


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

Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #971 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.
Logged
lotisully86
Full Member
***
Posts: 37


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


View Profile
« Reply #973 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.
« Last Edit: June 08, 2017, 04:56:33 AM by indy91 » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #974 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?
Logged
Pages: 1 ... 63 64 [65] 66 67 Print 
« previous next »
Jump to:  

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