Meadville Space Center
Welcome,
Guest
. Please
login
or
register
.
January 25, 2021, 09:40:44 PM
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
Search:
Advanced search
AMSO 1.18 released!
http://www.acsoft.ch/AMSO/amso.html
25068
Posts in
2094
Topics by
2266
Members
Latest Member:
Apollo Next
Meadville Space Center
Project Apollo - NASSP
Project Apollo - NASSP Development
Planning
(Moderators:
movieman
,
Swatch
,
lassombra
)
Steps before Apollo 7
« previous
next »
Pages:
1
...
7
8
[
9
]
10
Author
Topic: Steps before Apollo 7 (Read 42737 times)
Thymo
Full Member
Posts: 113
Re: Steps before Apollo 7
«
Reply #120 on:
October 31, 2016, 08:37:12 AM »
Ok. With everything working again. There are still some open issues on GitHub.
https://github.com/dseagrav/NASSP/milestone/1
Mostly are almost finished I think. If they are they can be closed. Otherwise they need to be fixed and we'll be really close to an actual release!
«
Last Edit: October 31, 2016, 10:40:30 AM by Thymo
»
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #121 on:
October 31, 2016, 10:00:44 AM »
The MCC major maneuver assistance can probably be closed. Although there was something jalexb88 mentioned a while ago about MCC7 during Apollo 8, I'm not sure if I ever fixed that.
The optics bug only really happens in P23 and can be rather annoying. Haven't been able to find out more than what I wrote in the issue comment.
For "MCC state save/load support" only the PADs aren't saved I think. I looked into that a little bit, but wasn't sure how to save a string with multiple lines. In my attempt it always cut off most of the PAD string.
For documentation I really would like a short user manual that is supplied with NASSP. Although I can imagine it can be mostly arranged from wiki articles.
Logged
dseagrav
Project Admin
Hero Member
Posts: 1118
Re: Steps before Apollo 7
«
Reply #122 on:
October 31, 2016, 10:05:19 AM »
For PAD saving/loading you'd either have to save just the numeric values that make up the PAD (possibly as separate values, like how AGC memory is managed) or recalculate it at load. I'm not sure which is more of a pain.
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #123 on:
October 31, 2016, 10:12:19 AM »
I mean, the intention is that the PADs are written down on the appropiate form, so if you close Orbiter before you have done that, then it's really the users own fault. For MCC updates with uplinks there already is the option to repeat the calculation+uplink, for the case an uplink has failed. It could be implement for the more general case that you simply want to have the PAD calculated again. Which is of course already possible through the debug menu.
The method with saving the values could work, although it indeed will be a painful process to do that for every value of every PAD.
«
Last Edit: October 31, 2016, 10:15:20 AM by indy91
»
Logged
dseagrav
Project Admin
Hero Member
Posts: 1118
Re: Steps before Apollo 7
«
Reply #124 on:
October 31, 2016, 10:20:50 AM »
Another option is to break the PAD into pieces and save/load them that way.
Logged
rcflyinghokie
Hero Member
Posts: 580
Re: Steps before Apollo 7
«
Reply #125 on:
October 31, 2016, 05:13:17 PM »
Maybe a little out of left field but what about an option in say an MFD to recalculate the PAD to re-display it instead of the debug menu?
Logged
dseagrav
Project Admin
Hero Member
Posts: 1118
Re: Steps before Apollo 7
«
Reply #126 on:
November 01, 2016, 06:43:10 AM »
Quote from: indy91 on October 31, 2016, 10:00:44 AM
The optics bug only really happens in P23 and can be rather annoying. Haven't been able to find out more than what I wrote in the issue comment.
When this bug is hit, does it hang there forever inside the loop or actually crash/exit?
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #127 on:
November 01, 2016, 07:36:04 AM »
My description in the issue comment was not quite correct. It does not actually cause a CTD; that's why I was able to pause the simulation in debug mode to have a look at the state of the simulation in Visual Studio. The issue happens if you manually move the shaft (maybe trunnion, too) close to 0°. It must be some kind of rare case when the sign of the angle is changing and this line of code:
Code:
while (fabs(fabs(OpticsShaft) - fabs(ShaftMoved)) >= OCDU_SHAFT_STEP) {
can't deal with it. Which is why it is stuck in the loop and the variable ShaftMoved reaches the very wrong value of 391501.66411046032 and increasing.
Also, I will save the PADs line by line. I've already learned something about the "stringstream" class thanks to that. Just need to figure out loading the PAD from the scenario.
Logged
dseagrav
Project Admin
Hero Member
Posts: 1118
Re: Steps before Apollo 7
«
Reply #128 on:
November 01, 2016, 09:17:24 AM »
Yeah, this is called "floating-point uncertainty". The computer's internal representation of floating-point numbers is an approximation, and sometimes operations on them can have unexpected results.
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #129 on:
November 01, 2016, 09:51:12 AM »
Floating point precision was not one of the causes I suspected. Any ideas how to fix it?
I have implemented the PAD and uplink string save/loading now. I had to save all the values instead of the long string line by line, because the displayed PAD isn't stored as a string in the padForm variable. Each time a new display is requested the display string is newly assembled. So I had to implement the saving/loading individually for each type of PAD. I expect some bugs, so please help test the new saving/loading.
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #130 on:
November 02, 2016, 06:03:32 AM »
I have attempted to cleanup all of the remaining compiler warnings. @dseagrav or anyone else, data types are not my specialty, so maybe someone could have a look at these changes and confirm they are ok.
Logged
dseagrav
Project Admin
Hero Member
Posts: 1118
Re: Steps before Apollo 7
«
Reply #131 on:
November 02, 2016, 07:48:38 AM »
So what exactly is the optics resolved mode supposed to do? I was under the impression it was supposed to translate OHC commands such that up/down/left/right moved the LOS up/down/left/right from the viewer's point of view, whereas direct mode just drives shaft and trunnion as-is. When I select resolved mode I get results that make no sense.
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #132 on:
November 02, 2016, 09:28:56 AM »
I'm pretty sure it is working as intended. My sources were AOH, Systems Handbook and a document about the development of the CSM Optics Subsystem that had the actual equations for the matrix transformation of the shaft and trunnion commands. I can't findthat document in my collection right now, I am still searching.
The AOH says: "The matrix transformation makes the image motion correspond directly to the hand controller motion. This is up, down, right, and left motions of the hand controller command; the target image moves up, down, right and left respectively, in the field of view. In other words, the image motion is in the X-Y spacecraft coordinate system."
It is useful for landmark tracking, because you can command up and down and the sextant will move up and down in your direction of flight. Equally left and right commands move the optics out-of-plane when looking at the Earth/Moon.
EDIT: Here is the document:
https://archive.org/details/nasa_techdoc_19700015844
Start reading at page 3-18.
«
Last Edit: November 02, 2016, 10:00:03 AM by indy91
»
Logged
dseagrav
Project Admin
Hero Member
Posts: 1118
Re: Steps before Apollo 7
«
Reply #133 on:
November 03, 2016, 03:49:22 AM »
Sidenote: I just noticed something. The FDAI is a motor-driven ball instrument, not a gyro instrument. When power is removed, shouldn't it simply freeze in place?
Logged
indy91
Hero Member
Posts: 1316
Re: Steps before Apollo 7
«
Reply #134 on:
November 03, 2016, 06:46:17 AM »
Quote from: dseagrav on November 03, 2016, 03:49:22 AM
Sidenote: I just noticed something. The FDAI is a motor-driven ball instrument, not a gyro instrument. When power is removed, shouldn't it simply freeze in place?
Isn't that exactly what it is doing? If you set the FDAI/GPI Power switch to OFF, then both FDAI don't move anymore, but they aren't set to 0. If you open the two SCS System circuit breakers the same thing happens. In which case does the FDAI return to 0?
Logged
Pages:
1
...
7
8
[
9
]
10
« previous
next »
Jump to:
Please select a destination:
-----------------------------
Meadville Space Center
-----------------------------
=> NEW MEMBER REGISTRATION
=> Site News
=> Project News
=> Orbiter
=> Off Topic
=> Rob Conley's Blog
-----------------------------
Project Apollo - NASSP
-----------------------------
=> Project Apollo - NASSP News & Discussion
===> News & Announcements
===> Support & Bugs
=> Project Apollo - NASSP Development
===> Planning
===> Programming
===> Modeling
===> Sounds
-----------------------------
Project Mercury
-----------------------------
=> Discussion & Help
=> Development
===> Planning
===> Programming
=> Mercury Mission Control
-----------------------------
Project Gemini
-----------------------------
=> Discussion & Help
=> Development
===> Programming
===> Modelling
===> Sounds
===> Planning
-----------------------------
Orbiter Mars Direct
-----------------------------
=> Planning
===> General News
=> Development
===> Programming
===> Modelling
===> Sounds
-----------------------------
General Projects
-----------------------------
=> The After Columbia Project
===> Sprint
===> Greenstar
===> Cyanstar
===> Bluestar
===> Mars Challenger
-----------------------------
Sol 2018
-----------------------------
=> Planning
Loading...