Problem Glideslope2 De-Orbit Question

[davidweb]

Hello!

I'm trying to understand the GS2 / BaseSync relationship. I'm on Orbiter 2016 and I've tried this first with DGIV then switched to XR2 because I thought maybe the reason for the below issue was that DGIV wasn't technically compatible with 2016... but same issue.

If I undock from ISS, target Cape Canaveral using base sync I get to the right orbit # for reentry etc. When I slave BS to GS with Cape Canaveral RW 15 selected, for example... the "DeltaAZ", Range, info say "-nan(ind)"

Questions:
1) Is this because I am not at the 200km orbit that the default GS parameters of 0.73 degree angle and anticipation refer to? IE: Do those angles vary based on the orbit from which I am doing my de-orbit burn?

2) If so, is there a way without simple guess or trial/error to correct for different orbits? If I'm at a 380km orbit, how would I know or figure out what a better angle / anticipation angle would be?

Hope this makes sense. And thanks in advance for any help you might have!

-David

 

[turtle91]

....info say "-nan(ind)"

I have this issue, too.
This came up during the various GS(2)-updates, I have reported this allready.
The reason for this, seems to be, that GS-MFD is setting-up a default HAC-size of "0".
So, to solve this, just go to the HAC-setup, and increase the HAC-range to >0.
As soon, as you have a value >0, that MFD gives more sensefull data.

For your 2. question.....that's a good question. :thumbup:
I am always going down to a 200x200 km orbit, just to make the de-obit calculations happy (i.e. IMFD's base-aproach + orbit-insert (in AP30 mode)).
Maybe somebody has a better solution.

 

[davidweb]

I have this issue, too.
This came up during the various GS(2)-updates, I have reported this allready.
The reason for this, seems to be, that GS-MFD is setting-up a default HAC-size of "0".
So, to solve this, just go to the HAC-setup, and increase the HAC-range to >0.
As soon, as you have a value >0, that MFD gives more sensefull data.

For your 2. question.....that's a good question. :thumbup:
I am always going down to a 200x200 km orbit, just to make the de-obit calculations happy (i.e. IMFD's base-aproach + orbit-insert (in AP30 mode)).
Maybe somebody has a better solution.

Thank you thank you thank you! As for question two, I'm guessing I would have to create a new "glidepath" file as per the GS2 instructions. I just made it work using the default glidepath but from ISS altitude (around 375km). I set it up in BaseSync de-orbit to do 1.4% angle 60% anticipation instead of the default 0.73 & 75. I managed it, but needless to say, according to GS2, I was coming in high and fast the entire way.

It seemed to expect me to come in at the default angle on the VSit page so I ended up trying to match the default path once I got low enough to bleed off more speed (the consequence of course is that I ended up having a lot higher hull temps ... survivable but still...).

It would be WONDERFUL if it could calculate your post de-orbit burn trajectory and guide you per that, vs. guiding you per the .cfg file info. Perhaps I'm still missing something, though.

For now, I think I may end up using Aerobrake for anything other than 200km deorbits... but I *love* the interface of GS2.

 

[ADSWNJ]

GS2 author here. I am busy on other projects (hint: EML1), but I'll get to this in due course. Looks like you have it in hand though.

Have you tried hitting the SAV button to save a user glideslope? This will generate a file that you can then rename and add to your glideslope config file, for selection as your reference glideslope for the next time.

The XR vessels like to come in more shallow than the DG, so if you can get a good reference glisdeslope, I'd be happy to merge it into a future release.


BaseSync to GS2 ... part of a dream born on this forum a couple of years ago, to have MFD's be able to share data either as one-offs or in real time, just lie a real flight dec would be expected to do. My buddy Enjo was the driver behind this awesomeness (i.e. Module Messaging), and he and I worked on the Extended version.

Happy orbiting!

 

[boogabooga]

For now, I think I may end up using Aerobrake for anything other than 200km deorbits... but I *love* the interface of GS2.

That's what I do. GS2 is great for the HAC part, but Aerobrake IMHO still offers a more robust solution for most of re-entry.

 

[davidweb]

GS2 author here. I am busy on other projects (hint: EML1), but I'll get to this in due course. Looks like you have it in hand though.

Have you tried hitting the SAV button to save a user glideslope? This will generate a file that you can then rename and add to your glideslope config file, for selection as your reference glideslope for the next time.

The XR vessels like to come in more shallow than the DG, so if you can get a good reference glisdeslope, I'd be happy to merge it into a future release.


BaseSync to GS2 ... part of a dream born on this forum a couple of years ago, to have MFD's be able to share data either as one-offs or in real time, just lie a real flight dec would be expected to do. My buddy Enjo was the driver behind this awesomeness (i.e. Module Messaging), and he and I worked on the Extended version.

Happy orbiting!

Thank you very much for replying! I know we are all grateful for the time and effort you and folks like you put into making this simulation what it is!

I have no idea what EML1 stands for, but thanks in advance for that, too!

I think this is still an area of opportunity within Orbiter overall. I can plan a launch to rendezvous with ISS or set up a trajectory to overfly a base on Mars, from Cape Canaveral... but there is still no real way to predictably plan and execute a full atmospheric re-entry without a large degree of guess work and trial and error.

I can't even imagine the challenges of coding something like that... but it would be a great future-goal to have something that marries the variability of Aerobrake with the precision of Glideslope so that one can set up and execute a reliable, predictable, stable re-entry from any level orbit (or the moon... or Mars, etc).

Thanks Again for all you do for this community!
-David

 

[turtle91]

I have tested GS-MFD, if the 200 km orbit is somewhat hardcoded and might be a requirement for a "good" automated de-orbit-burn.
In short words...it's not hardcoded :thumbup:.

For testing I used the XR1, there is a default scenario, where the XR1 is docked to ISS.
So I used this scenario as a reference.

What I have done:

-undocked form ISS as soon as basesync came-up with a shortest passage to KSC
-reduced the crossrange via a short orbit+ burn
-used Davidweb's setting for a test (0.60 ANT and 1.4 ANG in basesync's DEO-screen)
-started GS-MFD and enabled ext. tracking (XTS-button at config-page)
-AOA set to 40 degrees with XR1 autopilot
-used Aerobrake-MFD to monitor the reentry

All was fine, there was a small atmosphere-skip of about max VS +18 m/s, but the reentry was fine.
-after landing I pressed the SAV button at GS-MFD
-then, I opened the new created GS-REF-file with notepad and removed all lines until I have set the AOA of 40, like this:
(removed all stuff until here)
6953.09 134.36 7575 -195.9 1.6 ; Time 17053 secs (Ext Track)
6878.44 132.39 7578 -195.0 40.2 ; Time 17063 secs (Ext Track)

-then I reloaded the XR1-ISS default scenario and only used GS-MFD and BaseSyncMFD
=
-undocked from ISS and done a small crossrange correction burn like before
-used GS-MFD's DEO-screen to prepare the automated deorbit-burn
-this time, even if I was still at about 370 km altitude, the deorbit-burn went fine (down to a PEA of about 17km...a bit harsh....but no problem thanks to the small atmosphere-skip).
-I used only GS-MFD as a reference until a sucessfull touchdown at KSC33 (HAC 12KM left-open)

I have attached the GS-file, it's not perfect, but it shows, that GS-MFD can handle >200 km altitude automated deorbit-burns.

 

[ADSWNJ]

Thank you very much for replying! I know we are all grateful for the time and effort you and folks like you put into making this simulation what it is!

I have no idea what EML1 stands for, but thanks in advance for that, too!

I think this is still an area of opportunity within Orbiter overall. I can plan a launch to rendezvous with ISS or set up a trajectory to overfly a base on Mars, from Cape Canaveral... but there is still no real way to predictably plan and execute a full atmospheric re-entry without a large degree of guess work and trial and error.

I can't even imagine the challenges of coding something like that... but it would be a great future-goal to have something that marries the variability of Aerobrake with the precision of Glideslope so that one can set up and execute a reliable, predictable, stable re-entry from any level orbit (or the moon... or Mars, etc).

Thanks Again for all you do for this community!
-David

EML1 = Earth Moon Lagrange 1. My current fascination with completing a thorough implementation of @Keithth G's algorithms described in this forum. Probably 500-600 hours of work so far on my side, and a few hundred for the guys helping with the testing and the mathematics as well.


I agree with you on the re-entry side. When I first looked at the original Glideslope 1, I was in awe at the technical complexity of the calculations of the glideslope, the HAC turn, and the line-up to landing. The source code was almost undocumented, and various pieces missing, so it was a bit of a Jurassic Park-style splicing in frog DNA to breath life back in it. I wanted to make each screen do something interesting, with colors, flashing tags, etc, and I like the digital displays. I've never really focused on the programming of the S-turns, the LNAV/VNAV modes, etc, and now the wind effects, but it's certainly something for a longer-term project.

Something my buddy David Courtney said to me ... about simplifying MFD's to do one job really well ... has stuck with me for a long time now. Having a method now to pass data in real time between MFD's makes this viable. Just wish more tool developers would jump in and take advantage.

For those wanting to start in this space, there's lots of things you can do here if you want! PM me.