Meadville Space Center
Welcome, Guest. Please login or register.
January 25, 2021, 03:14:24 PM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
25068 Posts in 2094 Topics by 2266 Members
Latest Member: Apollo Next
* Home Help Search Login Register
  Show Posts
Pages: [1] 2 3 ... 72
1  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 25, 2011, 02:28:46 AM
May be you can try to change E and CENTANG while in P34 to see if the AGC find a solution.

By now, the essential limitation with RDV spreadsheet is computing the whole sequence and displaying only the nominal delta V's for each burns. It means it assumes that each burn is perfectly done which, of course, it's nearly impossible to do.
So, in real time while running the simulation, dispersions grow up step by step until the relative position of the 2 vessel is wrong and the predicted TPI may be unfeasible.
Moreover, since the perturbation is not taken into account, the dispersion grows up more rapidly.
For example, with the default RDV State Vector, the target's computed orbital period is 5371 sec. It does match the orbit MFD at time of SV update simply because it's the period of the osculating orbit at this time. While working on the perturbation in J2, I’ve found that the mean apsidal period is around 5369 sec. In phasing and rendezvous practice, the period is an essential parameter such as the 2 sec difference in period makes the RDV solution too far from the actual one.

Currently I’m working on RDV 2.0 version which includes 2 important improvements:

First, the nonspherical gravity field perturbation is incorporated in the calculations (in J2 only, I neglected the other harmonic coefficients) so the whole geometry should be accurate enough.

Second; I plan to add something like two modes ability for the RDV to work:
 - A “plan mode” the user uses to build the sequence just like he does in the current version.
 - A “fly mode” the user switches to when the sequence has been built and while running the sim. In this mode the user would be allowed to update the SV between each burn and the spreadsheet would compute the next step burn data according to the new SV.

I got a lot of work in real life so I probably won’t be able to release this new version within at least 2 or 3 weeks. 

Meanwhile, you may try to disable the orbiter’s nonspherical gravity field to see if things go better.
An alternate is to disregard the RDV delta V’s and to use IMFD to find the burn solution to match the predicted orbit computed by the spreadsheet.
An other Idea: IMFD is able to find solution for offset target intercept. May be this would work using the spreadsheet range as the IMFD offset value?
 
2  Project Apollo - NASSP / Sounds / Re: Apollo 8 Air to Ground on: August 25, 2011, 01:43:15 AM
As far as the audio play reference is concerned, AFAIK, the only reference in orbitersound is with the timeline. Alain Capt managed to do something like you're asking for in AMSO and it's really amazing but it's a special code. Unfortunately We don't have such a feature in Project Apollo. 

We do have something like this in the LM, see Orbiter\Sound\ProjectApollo\Apollo11, especially sound.cvs in there. But I don't know if it's still working...

Cheers
Tschachim


Oops! So sorry I've forgotten that.
3  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 22, 2011, 10:50:49 AM
Does it work now?
4  Project Apollo - NASSP / Sounds / Re: Apollo 8 Air to Ground on: August 21, 2011, 03:49:31 AM
I've been working on getting some audio for Apollo 8 from the Honeysuckle creek audio. As of now, I have Launch through TLI and the 2 hours leading up to LOI done in 8-bit audio, and I'll post the work in progress shortly. Is there a way to have audio play in reference to something other then GET, like time from lunar periapsis?

Good!  Thumbs Up There's not a lot of Apollo 8 audio on the website I know.

As far as the audio play reference is concerned, AFAIK, the only reference in orbitersound is with the timeline. Alain Capt managed to do something like you're asking for in AMSO and it's really amazing but it's a special code. Unfortunately We don't have such a feature in Project Apollo. 
5  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 17, 2011, 07:29:22 AM
By the way P32/33 were not really required for the missions prior to Apollo 10.
If you look at the apollo7 phasing and rendezvous sequece, the NCC2 which I assume to be a sort of non planned CSI has not the same constraints than a true CSI: to be done at an apside point, horizontal burn etc. Moreover the ground had enough time to compute and uplink the burn data since the state vectors were stable and pefectly known.
Same for Apollo 9 and I dont speak about Apollo 8 which was a single ship mission.

From Apollo 10, they had to perform a rendezvous as it was expected to be in a lunar landing mission with the constraints of the far side overflying. During the far side coast from LOS to AOS ground didn't receive any telemetry and crew had to do it by himself.
Thing are even worse when a rendezvous occur after lunar liftoff due to uncertainty about the real position, launch and insertion dispersion and lack of time to update the state vector.
6  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 16, 2011, 04:58:16 PM
Yes, this means that the Apollo 9 CMC (and the version we use for Apollo 7/8) was not able to 'rescue' a stranded LM completely by itself(!). Obviously this didn't bother NASA. Maybe it was enough to have the AGS as 'first line' backup and the ground solution as second in earth orbit.

You’re right. I checked. Artemis got P32/P33 but colossus didn’t.
For rescue, the procedure was to use the burn data computed by the LM and transmitted to CSM. The CSM then used it with sign inversion for a rendezvous “from above” and, amazingly that worked!
One interested thing would be trying that with RDV. It is capable of rendezvous from above too.

One thing with the burntabs: I've played around a little bit and one interesting thing is that your timing is bad someway. When I do my phasing burn 14 min earlier, I can use the dV's from the tab to get the desired orbit. But at the desired time, I need significantly more dV for that.

I suspect non spherical gravity field to be responsible of that.
I was planned to be at work for 2 days but that was cancelled so I spent most of the afternoon trying to figure out how to include the perturbation in RDV.
The problem is to do that in an acceptable way which saves the user from a wait for long and boring iterations. 
7  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 16, 2011, 02:51:05 PM
I think we may be going about this wrong. AFAIK, the only burns that needed to be manually computed were insertion/NCC1, CSI/NCC2, and CDH/NSR. All that really needs doing is placing the spacecraft into such a position (while remain authentic to the flight path as best as possible) to allow the AGC to take over for TPI onwards. So I'm wondering, is there a way to do the burns with post-phasing state vectors and just take it from pre-NCC1 to CDH?

I think that the CSI and CDH were manually computed (I guess you mean by the ground) because the AGC version of Apollo 7 was  sundisk instead of the colossus we use in vAGC/projectApollo. And I believe sundisk was not able of P32/33 (not sure of the exact program number...) to compute CSI CDH.
Normally, our AGC should do that...

After all, RDV spredsheet only must compute the CSI/CDH/TPI by itself in order to offer a proper phasing solution to establish the proper geometry. If the solution is valid, from CSI point we don't need it anymore and its CSI/CDH/TPI solutions are for information only or at least as a backup.
8  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 16, 2011, 11:57:31 AM
Thanks Christophe for the new excel!  Thumbs Up

No problem, it's my pleasure.

But another point: I don't know if the insertion orbit in Apollo 7 is really correct because I never found data about neither the longitude of the ascending node nor the argument of periapsis of the insertion orbit (or any orbit later in the mission), so if someone knows a reference... Happy

That's the problem. There's a terribly lack of information about that kind of data.
The only way to get the answer is to compute from some reports doc which give the velocity components at insertion. Knowing the Pe and Ap at insertion, the vertical velocity (Vz) should give the excentric anomaly and then the true anomaly. Then, knowing the position at insertion the longitude of periapsis should be calculated to.
In the same way, knowing the exact Inc at insertion (this could be found in mission reports or "Apollo by the numbers" pdf) and angle of path the LAN can be defined.

But I don't know if such a computing would be very accurate, taking into account all the perturbations, dispersion etc.
9  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 15, 2011, 07:51:02 AM
New version!

In the 1.2 I've added a new 'BURNPADS' TAB.
There are display of the burn data to be entered into IMFD.

I updated the doc too.

Hi! Meik84, hope this will be better for you. Wink

I'm away for the next 2 days because I have to go to work  Gloomy

Sure I'll probably even more busy when I'm back at home!

EDIT:
Oops!
I realised IMFD displays metric units only.
I modified the 1.21 version to override the user setting made in rendezvous tab: the values are now always metric in burnpads.

Rest is unchanged.
10  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 15, 2011, 07:43:55 AM
NP with the help. Hell, I should start contributing code myself, but I've yet to learn Visual Studio as it is. Tongue

So welcome! A new programmer is always something cool.
I don't know visual basic neither C++. It's a shame.

I think just so long as iterative calculation is disabled (big disclaimer on that one!), there won't be a problem. Also, it never caused a problem for me until I tried to save--IIRC, when Excel saves, if iterative calculations are enabled, it will attempt to complete said calculations up to the max limit (I had mine set for 32,768. Go figure.) before closing. I think that is what sent my computer into an endless calculation loop before some Big Red Switch action was necessary.

Not sure understanding you very well about that trouble. However, the RDV default setting is 100 iterations only because it's enough and may avoid the problem you've experienced.
But I can't explain why your setting doesn't respect automatically the default !?!?  Shocked
11  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 15, 2011, 03:40:50 AM
On which excel version dit it happen?

2010. Like I said, I had iterative calculations enabled.

That’s what I was the most afraid of!
I included many “filters” into the spreadsheet in order to avoid the endless iterations due to some inconsistent values the loop may run into.
Although I tested it with many samples of SV, time settings and all and even the most absurd settings I could imagine, I could not be totally sure of it.
 
Could you post your file?
Ideally, if you can, please post 2 files: the first just before the entering of the crash value and a second after the crash.

Isn't this some sort of inconsistence? There are two possible orbits then, or am I thinking wrong? Confused

I know what you mean.
In fact, in my mind the purpose of this data was not to compute the burn but just information to help for the setting of the spreadsheet because it could be useful, in some case, to know if the chaser line of Apside is aligned with respect to the target line of apside.
So I arranged the math for the angle to be always less than 90° since it eliminates the problem of a possible apside inversion.

Example: Let’s say the tgt LOA angle is 32.8° and assuming that the LOA is equal to the AgP. Let’s say that for some reason you would like to compute a burn to make the resulting orbit aligned with the target. If the Pe and AP are on the same side than the targets, the chaser AgP must be 32.8° too. But if the resulting computed orbit has inverted the apside (chaser Pe superposed to target Ap, and chaser Ap superposed to target Pe), the resulting AgP is 212.8° instead, which could be confusing especially if the user is not familiar with the complementary angles. The LOA angle would still show 32.8°.

May be it would be better if I would change the “LOA angle” to “relative LOA angle” which would display the difference in the target LOA and chaser LOA directly.
 
Oh, and I turned the inside of IMFD to the outside and didn't find any program which would be capable of calculating a burn from the spreadsheet data. The deltaV-prog shows ApA and PeA, but lacks AgP. Sad

A second problem is as following:
Due to the nongravity field perturbation, LPe is a very unstable data. So it is almost impracticable as an IMFD setting. Although Pe/Ap heights are unstable too, those are a bit less sensitive.
I didn’t have enough time to test the spreadsheet into the simulation (I admit I should take that time) but my idea is that you can set IMFD with respect to the spreadsheet GET and Pe/Ap data. The respect of the GET should make the resulting mean LPe be quite right, no matter of the osculating LPe shown instantaneously.

As I said in a previous post, I prepare a new tab with the displays of the delta V’s components, in LVLH and/or velocity frame to be used in IMFD delta velocity program.

Anyway I’d like to thank you Meik84 and eddievhfan1984 for the time you spent in testing the spreadsheet and reporting these bugs.
12  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 14, 2011, 03:54:32 PM
Not exactly.
It's the angle between the line of apside and line of node. Thus, if periapsis and apoapsis are inverted the angle doesn't change; otherwise it would vary 180°.
Do you see what I mean?
13  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 14, 2011, 07:22:54 AM
On which excel version dit it happen?
14  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: RDV SPREADSHEET on: August 14, 2011, 02:23:01 AM
All that's remind me that I forgot to mention the excel setting options in the doc for the spreadsheet to work properly.
Normally, if you have no other excel file already open when you start RDV you should have nothing to do.
If you see that the spreadsheet crashes, it may be because the iteration option is disabled.
Trying to relaunch the RDV iteration loops once they have crashed is really a pain. You'd better exit without saving, close the other excel files and restart.
15  Meadville Space Center / Orbiter / Re: Orbiter doesn't work? on: August 14, 2011, 02:12:15 AM
There's probably a conflict somehere inside your orbiter folder.
Download it again from the orbiter site (or decompress again if you have it on your harddrive) and try to run it.
If it's free of trouble that proves there's an add-on conflict or something like this.
Then try to reinstall all the add-on step by step.

I experienced the same, one day and the conflict was with orbiter sound and my sound device. I ran out of that trouble by reinstalling the sound driver. 
Pages: [1] 2 3 ... 72
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!