Meadville Space Center
Welcome, Guest. Please login or register.
May 23, 2013, 03:17:37 PM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
20011 Posts in 1930 Topics by 2250 Members
Latest Member: mikegk
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  RDV SPREADSHEET
« previous next »
Pages: 1 [2] 3 4 Print
Author Topic: RDV SPREADSHEET  (Read 2655 times)
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #15 on: August 13, 2011, 01:49:40 PM »

Just to have a clear starting point.

Current debugged version is 1.17.

The whole zip folder is in the attach.

* RDV_1.17.zip (1831.81 KB - downloaded 30 times.)
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #16 on: August 13, 2011, 06:58:16 PM »

My version is 2010 Home and Student.

I forgot that this was an international project for a second. Duh! Well, I'll run mine and see what goes.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #17 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.
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #18 on: August 14, 2011, 05:14:27 AM »

I did end up with a crash, but I thought that's because I had iterative calculations enabled and when I saved to exit, it got stuck in an execution loop that nearly bricked my laptop. Big Red Switch time.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #19 on: August 14, 2011, 07:22:54 AM »

On which excel version dit it happen?
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #20 on: August 14, 2011, 11:18:56 AM »

Just for clarification: 'L.O.A. ang' is nothing else then the argument of periapsis aka 'small omega' aka 'AgP' in orbiter's terms, right? Confused
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #21 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?
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #22 on: August 14, 2011, 03:58:59 PM »

On which excel version dit it happen?

2010. Like I said, I had iterative calculations enabled.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #23 on: August 14, 2011, 04:27:23 PM »

Quote
Thus, if periapsis and apoapsis are inverted the angle doesn't change; otherwise it would vary 180°.
Isn't this some sort of inconsistence? There are two possible orbits then, or am I thinking wrong? Confused
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
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #24 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.
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #25 on: August 15, 2011, 07:11:11 AM »

NP with the help. Hell, I should start contributing code myself, but I've yet to learn Visual Studio as it is. Tongue

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.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #26 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
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #27 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.

* RDV_1.21.zip (1836.84 KB - downloaded 57 times.)
« Last Edit: August 15, 2011, 09:03:22 AM by Christophe » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #28 on: August 15, 2011, 06:02:00 PM »

There must be something wrong with your imperial/metric conversions. The data in the burn tabs change, depending on the switch and I get 7,81m/s dV for phasing in metric, but 6,05 fps in imperial. AFAIK the conversion factor is something around 3,3, so one of them must be wrong. Confused
Edit: Nonsense. Forgot that the sheet doesn't convert the parameters automatically. Bangs Head 2
« Last Edit: August 15, 2011, 06:50:04 PM by meik84 » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #29 on: August 16, 2011, 11:33:30 AM »

Thanks Christophe for the new excel!  Thumbs Up

Oh, and just for your info: the SIVB is doing some sort of maneuver shortly after sep. Maybe some of the booster guys (Tschachim?!) can tell more about that...

Well, I'm more the assistant booster guy... Wink

In Apollo 7 the S-IVB changes its attitude to "tail first" LVLH at T+3h17min, but this should not change its orbit very much. That's the only maneuver I know after separation. Atmospheric drag should be modelled by Orbiter 2010's new atmosphere, but I never checked / tried that.

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

Cheers
Tschachim
Logged

Pages: 1 [2] 3 4 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!