Meadville Space Center
Welcome, Guest. Please login or register.
August 08, 2020, 12:19:20 AM

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)
| | | |-+  AGC++ reentry help
« previous next »
Pages: 1 ... 3 4 [5] 6 Print
Author Topic: AGC++ reentry help  (Read 24622 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #60 on: January 17, 2007, 06:14:50 AM »

I'll take a look at making the metric/english flag work for the AGC display, and maybe then we can move on from there.

Yeah, looks like I'm a little bit too perfectionistic here. Wink When we have that config file/scenario flag we can make it available in the Launchpad Configurator (http://nassp.sourceforge.net/wiki/Launchpad_Configuration_Options) and use metric as default, I think that would be a good solution.

... and something important:
 As you can see here in the revision history we've lost versions 1.68 to 1.72 of CSMcomputer.cpp, so the VAGC is broken in the latest CVS version.

So my appeal to all developers: Please make sure that you do a CVS update of the files before you commit changes. Do not copy files around nor copy and paste the complete content of a file. Before you commit changes it's useful to do a "CVS Diff" (context menu) to check the your changes against the latest CVS version to avoid unintentional changes. In order to do that in a comfortable way I suggest to install WinMerge (http://winmerge.org/), which has a TortoiseCVS integration.

I already prepared a fixed version I'm going to commit together with the SPS TVC stuff the next days, I just need to do a couple of tests, then everything should be working again. Happy

Cheers
Tschachim
« Last Edit: January 17, 2007, 10:09:10 AM by Tschachim » Logged

chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #61 on: January 17, 2007, 11:56:26 AM »

About the scroll, to keep the size manageable, I would suggest having two scrolls, one for LEO entry and one for trans-lunar and only include the part that the astronaut would actually see during the mission (only one of the charts). This should be the test header stuff and one re-entry chart, plus part of the header for the next chart, since from the Apollo 7 scroll it looks like the pen runs off the chart into the beginning of the next one.

Regards
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #62 on: January 17, 2007, 12:14:16 PM »

On the other hand, the bitmap being long doesn't matter much when the bitmap is being scrolled, depending on how you scroll it. If you blt parts out, it doesn't matter how long it is, the unused parts will be swapped if they don't end up part of the current working page set. The unseen parts wouldn't (shouldn't) occupy video RAM. At the join point you would have to load both anyway.

Another idea, leaving it as one bitmap makes it possible to write a program or Photoshop filter or something that takes the scroll image and superimposes the trace from a post-landing scenario file, so we can read the scroll and see how well the entry went.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #63 on: January 17, 2007, 09:48:05 PM »

Ok, we'll go with 1 or 2 large bitmaps to be messed with later...

Different Sections:

Leader: Used by the manufacturer, not important really and probably next to impossible to find.  ~34 in.
Ground Test Patterns: Not found as of yet, but would probably be useful.  Anyone who can find one of these, or even reference to what was on them, it'd be a great resource.  5 of these at ~3 in. a piece.
VHF/dV Ranging Instructions:  Alternated with In-Flight Test blocks on Lunar trips. More information on the VHF Ranging test is needed.
In-Flight Test:  Header before each reentry proceadure/chart.  About 3 in. a piece, various # and location it seems. 
Entry-Instructions:  2 inch section before each reentry chart containing instructions.  More information on what exactly this means is welcome.
Entry-Chart:  Many types, Non-Exit Orbital Entry Pattern (NOE),Non-Exit Lunar Entry Pattern (NLE), and 3500NM Lunar Return Exit Pattern (LRE).  4 Charts per scroll, but typically only 1 or two of the individual types.  18 in. a piece.

Now, what would you guys prefer?

Realistic:
|--Gnd Test (3-5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--LRE Pattern--|

Simple:
|--Gnd Test--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--NLE Pattern--|--LRE Pattern--|

Seperate (2 scrolls):
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--LRE Pattern--|     (Lunar Reentry)
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|   (Earth Reentry)

Historic (2 scrolls):
|--Gnd Test (25)--|--FltTst/VHF-dV Rng(4)--|--Entry Inst.--|--NLE Pattern--|--Entry Inst.--|--LRE Pattern--|--Entry Inst.--|--NLE Pattern--|--Entry Inst.--|--LRE Pattern--|    (Lunar Reentry - partially verified for Apollo Cool
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|    (Earth Reentry-verified for Apollo 7)

Oh and a full-sized Apollo 7 scroll at 120 inches in length would be about 6,144px in length and 144-150 px in height.
« Last Edit: January 17, 2007, 09:50:43 PM by Swatch » Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #64 on: January 19, 2007, 12:12:56 AM »


Seperate (2 scrolls):
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--LRE Pattern--|     (Lunar Reentry)
|--Gnd Test (5)--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|   (Earth Reentry)


I would vote for this, except changed to:

Seperate (2 scrolls):
|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|--FltTst(2)--|--Entry Inst.--|--NLE Pattern--|     (Lunar Reentry)
|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|--FltTst(2)--|--Entry Inst.--|--NOE Pattern--|   (Earth Reentry)

The reasons being:

1) We don't know what the ground test patterns looked like, nor do we have any idea how they were used.

2) I have no idea what the purpose of the 3500 NM "exit" trace was, since no mission ever had a reentry range longer than 2000NM. Plus, if you look at one, the differences between it and the "no-exit" trace are very small.

Also, you only need part of the second entry trace, since the entire second chart would not be used in practice, it would be there only so the chart would continue to scroll if the EMS system were left running up to and beyond splashdown.

I like the idea of preserving a copy of the marked-up scroll in a file (.bmp?) so the user could look at it or print it out to see how they did.

Regards
« Last Edit: January 19, 2007, 12:20:52 AM by chode » Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #65 on: January 19, 2007, 12:52:49 AM »

If I remember correctly, the reason for the second, third and forth charts were so if the astronauts scanned past the start of the first, they would just go the next chart.  The EMS scroll could only move forward, it couldn't back up.
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #66 on: January 19, 2007, 01:09:47 AM »

Yes, that is most likely the reason why there are so many charts. But, we can go back, and make it look like we went forward if we want to simulate that, since the scroll just repeats itself.

Regards
Logged
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #67 on: January 19, 2007, 06:26:14 AM »

Do you have a scenario include in the BETA files that i can use to test your stuf.

Thanks.

I want to test it Wink


It's a good job chode  Thumbs Up
Logged

Have a nice day
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #68 on: January 19, 2007, 09:12:21 AM »

On page 3 of this thread, about half way down, there are two scenarios attached.

Regards
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #69 on: January 19, 2007, 09:11:08 PM »

I tweaked the SM RCS positions; They should be better.
Sorry it took so long, I had unexpected company staying over the last couple days, so I didn't get much time to work with.
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #70 on: January 20, 2007, 02:16:53 PM »

I think something got changed up in the directions of those jets, they don't work correctly now. I'll see if I can fix them.

Regards
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #71 on: January 20, 2007, 02:52:40 PM »

I just checked dseagrav's new SM RCS thruster modification and it works fine here (in fact I didn't realize the difference).
Chode, what problems do you have?
Logged

Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #72 on: January 20, 2007, 04:17:26 PM »

present for you all in the orbitersdk folder...
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #73 on: January 20, 2007, 07:01:16 PM »

It's the CM jets. The direction of one of the roll jets is not right, I'll try to fix it tonight.

Regards
Logged
chode
Project Team Member
Full Member
****
Posts: 153


View Profile
« Reply #74 on: January 20, 2007, 11:08:17 PM »

Somehow, the direction of one of the roll jets on the CM got changed, causing the problem I reported (sorry, I didn't specify that the problem was with the CM and not the SM). I've reset it to the correct direction. I also tweaked the position of the CM jets to coincide more with the mesh. I did not tamper with the SM RCS thrusters at all. I've committed the changes, and hopefully everything is working as it should now.

Regards
Logged
Pages: 1 ... 3 4 [5] 6 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!