Meadville Space Center
Welcome, Guest. Please login or register.
September 24, 2020, 11:05:01 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Planning (Moderators: movieman, Swatch, lassombra)
| | | |-+  Steps before Apollo 7
« previous next »
Pages: 1 ... 7 8 [9] 10 Print
Author Topic: Steps before Apollo 7  (Read 41665 times)
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« 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!  Excited!
« Last Edit: October 31, 2016, 10:40:30 AM by Thymo » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« 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


View Profile
« 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


View Profile
« 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


View Profile
« 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


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


View Profile
« Reply #126 on: November 01, 2016, 06:43:10 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


View Profile
« 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


View Profile
« 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


View Profile
« 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


View Profile
« 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


View Profile
« 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


View Profile
« 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


View Profile
« 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


View Profile
« Reply #134 on: November 03, 2016, 06:46:17 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 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!