Meadville Space Center

Project Apollo - NASSP => Programming => Topic started by: Tschachim on March 14, 2007, 12:05:30 PM



Title: EMS progress/status report
Post by: Tschachim on March 14, 2007, 12:05:30 PM
Hi developers, mainly Chode :),

I'm going to begin with the EMS (http://nassp.sf.net/wiki/EMS), but only the dV modes for the SCS dV mode of the SPS, no entry stuff. Basically I would like to ask if anyone already started with the EMS, because then we should coordinate our work a little bit. If not I'd just go ahead with the stuff I need for the SPS and the entry part of the EMS can be integrated later.

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: NoName on March 19, 2007, 01:33:02 AM
Phantastic news. You're doing great work on the project Tschachim! And it gets greater and greater...  :D

I think that at the moment nobody seems to work on the EMS stuff (at least news and progress of the EMS slowed down or even freezed).



Title: Re: EMS progress/status report
Post by: Tschachim on April 29, 2007, 11:23:50 AM
The EMS dV stuff is finished for now, the currently working functions are explained here: http://nassp.sf.net/wiki/Entry_Monitoring_System

There's no panel screenshot with labels yet, I hope Moonwalker is going to add a bitmap of the ΔV/EMS SET rocker switch with it's five positions and we're going to get a entry scroll together with the entry functions (and VHF ranging functions) sooner or later. The EMS has a basic "status handling system" which hopefully can be extended easily to handle the entry functions, too.

Entry guys, it's your turn again!  :wink:

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Christophe on April 29, 2007, 01:50:22 PM
Wonderfull Tschachim! :ThumbsUp432:
I have a lot of work now to update the checklist. :wink:
With the EMS stuff we now can perform transposition and docking with no need anymore of the attitude MFD. Things are becoming more and more like in real.
Thanks a lot!
And thanks for the wiki too. Very helpfull.


Title: Re: EMS progress/status report
Post by: Tschachim on April 29, 2007, 02:21:28 PM
With the EMS stuff we now can perform transposition and docking with no need anymore of the attitude MFD.

Well, you still need it for the SIVB (unfortunately...)

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Christophe on April 29, 2007, 02:45:41 PM
With the EMS stuff we now can perform transposition and docking with no need anymore of the attitude MFD.

Well, you still need it for the SIVB (unfortunately...)

Cheers
Tschachim

You mean for the sep attitude? I agree. But If I understand well with the EMS you can monitor the +X delta V and so your relative motion with the SIVB, once separated; at least while considering the SIVB steady.


Title: Re: EMS progress/status report
Post by: Tschachim on April 29, 2007, 02:53:21 PM
Yeah, that should work, but I didn't test it during transposition and docking, so some test results would be very interesting!  :)

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Christophe on April 29, 2007, 03:17:05 PM
I'll do all of that this month with new checks.  :ThumbsUp432:


Title: Re: EMS progress/status report
Post by: movieman on May 31, 2007, 11:03:40 AM
Reading the EMS documentation, it always displays velocity in feet per second. Should we use meters per second in non-Virtual AGC mode, for consistency with the AGC?

That said, theoretically the C++ AGC can use feet per second for inputs and displays, but only some parts of the code actually support it properly.


Title: Re: EMS progress/status report
Post by: Tschachim on May 31, 2007, 11:13:39 AM
Reading the EMS documentation, it always displays velocity in feet per second. Should we use meters per second in non-Virtual AGC mode, for consistency with the AGC?

Yes, sounds reasonable for me.

That said, theoretically the C++ AGC can use feet per second for inputs and displays, but only some parts of the code actually support it properly.

Yes, until someone does some cleanup there (too much work for me currently)...  :wink:
Additionally we could add metric/imperial units radiobuttons to the configurator, then the user can decide by himself what he wants to see in case of the Simple AGC.

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: movieman on May 31, 2007, 11:28:33 AM
Sounds like a good idea: I think that currently the flag is in the AGC configuration, but it can easily be made vessel-wide.


Title: Re: EMS progress/status report
Post by: Vincent Majerowicz on August 21, 2007, 05:41:40 PM
Hi, guys!!

I wanted to ask you, how is the EMS coming along? Is entry scrolls implemented? :Excited432:


Title: Re: EMS progress/status report
Post by: Tschachim on August 21, 2007, 06:22:40 PM
No, enjoy the dV modes meanwhile: http://nassp.sf.net/wiki/EMS  :)

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Swatch on November 24, 2007, 09:51:07 PM
Ok, I'm coming along nicely on the EMS, (still can't display the scroll, but I'll figure it out) but I have a question to the developers and anyone who might want to help me with some research. 
To developers.... Have you run across any documentation on the actual determination of when Entry Interface (.05G light) conditions have been met?
To others.... could you help me find a detailed description of these conditions.  The following is the excerpt from the Apollo Operations Handbook, but its not very detailed.
Quote
The altitude at which this indicator is illuminated is a function of the entry angle (velocity vector with respect to the local horizontal), the magnitude of the velocity vector, geographic location and heading, and atmospheric conditions.  Bias comparator circuits and timers are used to initiate this indicator

As you can see, I know qualitatively what is needed, but not quantitatively.  I've been having problems finding more specific information on this.  Any help would be great. 


Title: Re: EMS progress/status report
Post by: Apassi on November 24, 2007, 11:47:27 PM
Have you seen already these documents: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720013191_1972013191.pdf
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072963_1974072963.pdf
May be you have, but just in case.  :ThumbsUp432:


Title: Re: EMS progress/status report
Post by: Swatch on November 25, 2007, 12:41:12 AM
thank you apassi, I had seen the Apollo 11 postflight, but not the other one.

One of the things I'm a bit confused on is whether there's a direct link between the EMS and the CMC/PNGCS.  Sometimes it seems that P61/P63 calculates when the .05G requirement has been met, others it seems that .05G trips and signals the computer to change from P61 to P63.   Anyone have an insight on this?   If this link is as close as it seems, then I'll probably need to know more on what re-entry capability we have on both vAGC and AGC++.


Title: Re: EMS progress/status report
Post by: Swatch on November 25, 2007, 04:03:22 AM
Alright...my weekend draws to a close here, so I have to commit what I have and hunker down for finals coming up over the next two weeks.  The EMS has been given some new functionality, although it isn't very useful yet.  The scroll will slew at the correct rates if you have the function rotary on Vo Set, or TEST 1 or TEST5.   Either when I have time around studying or once finals are over (Dec 7th for sure), I'll return to this and start working on getting us a line drawn on the scroll.  I'll also start working on the EMS Tests, which I think I have enough documentation for.

Tschachim, could you check to see if my VS broke anything?  I didn't use it to edit the resource.rc file, but I'm not sure if it automatically did or not.

movieman, thanks for your help.

Anyone else... got any ideas on how to draw the trace as the scroll is moving?

Hope everyone enjoys the pretty EMS Scrolling function....I like it.

PS.  If you try to scroll backwards and it stops after a while....it's not broken, that's authentic motion.


Title: Re: EMS progress/status report
Post by: Tschachim on November 25, 2007, 01:39:44 PM
To developers.... Have you run across any documentation on the actual determination of when Entry Interface (.05G light) conditions have been met?

Look at the "EMS Functional Block Diagram", pdf page 64 here: http://history.nasa.gov/afj/aoh/aoh-v1-2-03-scs.pdf. It looks like the EMS is just using it's own accelerometer (xacc in EMS::TimeStep), but there seem to be more details like a manual 0.05g initiation...

Tschachim, could you check to see if my VS broke anything?  I didn't use it to edit the resource.rc file, but I'm not sure if it automatically did or not.

Looks fine for me!  :)

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Swatch on November 26, 2007, 10:04:06 PM
Alright, you'll all find something quite fun in your CVS.  I just committed a working EMS scroll.

I'll post how to use it later.   This implementation may be buggy, so bear with me, and I'll need some people who are willing to fly some re-entrys.


Title: Re: EMS progress/status report
Post by: movieman on November 26, 2007, 11:48:13 PM
Looks good, though there's a one-pixel thick black line at the top of the EMS scroll window on my system.


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 12:38:25 AM
Status of the EMS...

Visual Interface:
    Threshold Indicator (.05G)- Working.
    Roll Stability Indicator- Non-Functional, There are no bitmaps for this, and the inner indicator needs to rotate, so I'm not sure the best way to pull this off.
    Corridor Verification Indicators- Code is there, but I haven't found the bitmaps yet, so its not visually there.
    Delta V/Range-To-Go Indicator- Working...great bit of code here by tschachim.
    Scroll Assembly- Scroll is working, along with plotting using GDI.
    SPS Thrust-On Indicator- Working.  once again, thanks tschachim.
    Switches- All working, to uncover the Ground Test, right click.

Functionality:
    Accerometer-  Seems to be working just fine, although I'd appreciate it if someone could explain to me why it needs all the calculations it has.  I might just be missing something though.
    Threshold Comparator Circuit-  Refuses to be kind to me.  I also did a shotty job of programming this first time around, so I'm going to try it from scratch.  I'm debating how much accuracy to put into it.  I can take the very easy, straightforward route which should produce mostly accurate functionality, but not necessarly historically perfect.  Unknown how much this will affect usability.
    Corridor Verification Circuit-  Pretty straightforward, but need to get Threshold Comparator working first.
    Scribe Drive Circuit-  Working.  Need someone to test and compare actual reentrys.
    RSI- Not working, see above.
    EMS Tests- In progress, but more interested in getting actual function correct first.

To Use: (EMS Mode Switch should be in "Normal")
    Step 1: Calculate the Range to go and projected initial velocity at .05G.
    Step 2: Turn Function Rotary to RNG SET and use dVSetSwitch to set expected range to go.
    Step 3: Turn Function Rotary to Vo SET and use dVSetSwitch to slew the scroll to projected initial velocity.
    Step 4: Turn Function Rotary to ENTRY and wait for .05G to be tripped.
    Step 5: If .05 is not tripped (and it won't be til I figure out better logic for it), you can manually start scroll by flipping the EMS Mode switch to BACKUP.

Notes:
    Historical function dictates that the scroll can only be reversed 1 inch.  However, this isn't useful for checking and comparing the trace after entry, so I set it up to where if the GroundTest (GTA) switch is flipped after the CM has seperated from the SM, you can freely traverse the entire scroll.  I hope to figure out how to print out the surface to a bitmap, but that's not likely.
    Range to go appears not to work correctly.  I'll need to check if my units are correct.
    I did a very crappy reentry and the trace appeared to more or less act correctly.


If someone could post some good pre-set Apollo 7 entry scenarios for me, I'd appreciate it.  Eventually I plan on flying the Apollo 7 re-entry from orbit and checking the EMS myself, but I need to learn those AGC programs.


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 12:40:06 AM
Looks good, though there's a one-pixel thick black line at the top of the EMS scroll window on my system.

Are you sure that's not the trace you're seeing?


Title: Re: EMS progress/status report
Post by: movieman on November 27, 2007, 01:06:43 AM
Oh, could be.


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 01:11:47 AM
Haha, yea... the trace is working now, so there should be a small black line as you scroll and it should follow your G's vertically as you accelerate.


Title: Re: EMS progress/status report
Post by: NoName on November 27, 2007, 03:58:31 AM
Great work guys :ThumbsUp432:

Do you need bitmaps for the Roll Stability Indicator and Corridor Verification Indicators?


Title: Re: EMS progress/status report
Post by: Christophe on November 27, 2007, 05:11:57 AM
Thanks Swatch for the work you did on EMS.  :ThumbsUp432:
If someone could post some good pre-set Apollo 7 entry scenarios for me, I'd appreciate it.  Eventually I plan on flying the Apollo 7 re-entry from orbit and checking the EMS myself, but I need to learn those AGC programs.
I've putted a long time ago some training scnenario to practice reentry from earth orbit  into: "\Scenarios\Project Apollo - NASSP\Virtual AGC\Training" subfolder. The Earth Orbit Entry_03.scn start just after the deorbit burn and before the CM/SM separation, and the _04.scn a bit later, right after the CM/SM separation. but these scn are very old and I don't know wether they're still working with last modules.
I believe that jc121081 has done and put some Apollo 7 scn into the cvs. see this post:
http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1408.0
But I don't know wether there is some scn available for reentry;
Anyway the checklist for use of the P60's vAGC programs (reentry programs) is in the doc at:
\Doc\Project Apollo - NASSP\Check List\Entry checklist\Earth Orbit.
The full checklist requires the help of IMFD to compute deorbit burn since there is no other way to do for the moment. I'll include a deorbit mnvr into EOCA next but I'm currently working on phasing for the moment so it should take some time.
AFAIK the P60's where working last year and should work if meanwhile nothing has been broken.


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 10:59:29 AM
No problem Christophe....and now that I know where that scenario is....I want to say, that's EXACTLY what I needed.  _03 and _04 is perfect for me. The problem is that the thrusters aren't responding correctly.

~To movieman or Tschachim....  could you fix either one or both of those scenarios for me?  I know next to nothing about scenario writing.

Great work guys :ThumbsUp432:

Do you need bitmaps for the Roll Stability Indicator and Corridor Verification Indicators?

yes, we need them...but I'm not sure how we want to do the Roll Stablilty Indicator, since it rotates smoothly.  Let me think about that one, we might have to use GDI for that.  as far as the Corridor Verification Indicators though, they'd be great and they can just be added to the same bitmap that the SPSLight and .05G light are on.

EDIT:  BTW, found a bug.... you'll notice that if I go to exterior view, the trace stops drawing and has gaps whenever you're not in the main panel cockpit... I'm going to see if I can fix that.


Title: Re: EMS progress/status report
Post by: lassombra on November 27, 2007, 12:17:39 PM
Swatch, just in case you haven't figured this out yet... the only way to get that to work regardless of view would be to move the code that updates it from the panel to the main time-step callback.  I'm guessing you figured this out, but thought I'd throw in my 2 cents worth, btw, the scroll is very nice, so glad we have that now!  :)


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 01:36:49 PM
Yes, that was the conclusion that I came to as well, however it only fixes half the problem.  (I actually didn't know that this was two different problems until just now)  it will keep the trace now if you go to exterior, but the previous trace is completely wiped out if you change panels at any time.  So now I'm trying to figure out if there is any way around it.  I fear though that it is something in the way orbiter draws panels and that I have hit a wall.


Title: Re: EMS progress/status report
Post by: Tschachim on November 27, 2007, 01:45:28 PM
What about drawing the complete line each clbkPanelRedrawEvent since there are not that much points/LineTo's?

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: movieman on November 27, 2007, 02:06:02 PM
What about drawing the complete line each clbkPanelRedrawEvent since there are not that much points/LineTo's?

Might work, but LineTo is truly evil (requiring a call in and out of the kernel for every single line whereas on Win98 you just made one call with a list of lines). Sounds like we need to record the lines that need to be drawn and then figure out how much updating is required (e.g. track the last line that was actually drawn and panel changes).


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 02:15:52 PM
That would require me to keep track of the trace pts...which right now is not being done.  It can be done, but that will be a fairly large data structure (array) that needs to be flexable.  As it stands, it merely calls a LineTo() continuously each update and draws a new line from the last location to the new location.  It works well and efficiently since there is only one LineTo called each timestep, but it means it has no prior knowledge of the trace.  Keeping track of the trace and redrawing it from scratch is the failsafe solution, but I'm not sure how much of a performance hit we might take for such a data structure and its handling.  I'm very interested in opinions on this subject.


EDIT:  In reply to movieman...

There is an alternative to a bunch of LineTo's and I believe its called a PolyLine.  This should be more efficient, as it just sends an array to the kernel once.  I'd have to do some checking to see how to use it though as it is a bit more indepth.


Title: Re: EMS progress/status report
Post by: movieman on November 27, 2007, 02:53:07 PM
Strange, I didn't think that XP had Polyline, since I remember driver writers I knew complaining about that. If it works, then that's less of a problem.

I'd keep the array of trace points anyway, it might be interesting to use after a flight to display the re-entry trajectory. Assuming it's only one point per pixel across the EMS bitmap, that's only going to be a few kilobytes of data; obviously will need to save it in the scenario file and reload afterwards.


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 03:22:07 PM
well, I'm looking at some ways to do this.  PolyLine requires a pointer to an array of POINT datatypes.  So I'm trying to figure out an efficient way to store off that array.


Title: Re: EMS progress/status report
Post by: Swatch on November 27, 2007, 07:20:37 PM
Ok.... has anyone else experienced a complete computer lockup since I commited the EMS?  If so I apologize, but if not... then I've commited some computer crime in the stuff I've been working on since that commit.

I'm going to go ahead and start from that point over again, but if anyone else has had this problem... I'd love to know.  In the meantime...I'm gonna keep trying to fix this.


Title: Re: EMS progress/status report
Post by: Apassi on November 27, 2007, 09:40:25 PM
No lock ups here. 
Just want to know where to get right numbers for presettings of Rng Set and Vo set.
From the V16N64 perhaps ?
The EMS entry mode does not work yet because 0.05g treshold is not tripped. I have to use backup mode to scripe the entry line. As you mentioned before.





Title: Re: EMS progress/status report
Post by: NoName on November 27, 2007, 09:49:26 PM
No lock ups here too ;)


Title: Re: EMS progress/status report
Post by: irnenginer on November 28, 2007, 12:57:30 AM
Worked good for me. Just a couple thoughts (I know I always have some). I wonder if in Vo set Mode the needle is at the bottom so you can set it per the scale. A different color for the scribe might make it easier to see.


No lock ups here. 
Just want to know where to get right numbers for presettings of Rng Set and Vo set.
From the V16N64 perhaps ?
The EMS entry mode does not work yet because 0.05g treshold is not tripped. I have to use backup mode to scripe the entry line. As you mentioned before.

Comes from V06N63 in P61. At least thats what I used.
R1 is Range to Go
R2 is Vo



Title: Re: EMS progress/status report
Post by: Swatch on November 28, 2007, 01:52:51 AM
Worked good for me. Just a couple thoughts (I know I always have some). I wonder if in Vo set Mode the needle is at the bottom so you can set it per the scale.


I have heard tell of a hairline mark, but I  have yet to verify its existance.... to be honest, I haven't even figured out where the scribe actually is in that box.  I know that this is a problem and as a result, I'm going to try and figure out the historical way from photographs (if I can find any) and if that fails, I'll just improvise something thats at least usable.

Quote
A different color for the scribe might make it easier to see.

I can do this eventually, but right now I'm just using a default Black Pen, also I believe that it would look black on the S/C too.


Title: Re: EMS progress/status report
Post by: Swatch on November 28, 2007, 02:08:24 AM
Ok.... I present to you questionable, but possibly the first, evidence of where the scribe was in the EMS scroll...

(http://www.scienceandsociety.co.uk/pr/621604226/Science_&_Society_Picture_Library_10441062.jpg)

It appears that it drew it from all the way at the right....no lead time.  This actually holds somewhat true to the documentation I've been reading since it seems that it was callibrated to have a bit of a leadtime involved in it.


EDIT:  This one shows otherwise...if you look, you'll see it is about halfway across the scroll....

(http://historicspacecraft.com/Photos/Apollo_9_Control_Panel_Stewart_Bailey_02.jpg)

...but more importantly, there appears to be a scale written on the left hand side of the frame....that would be nice eh?


Title: Re: EMS progress/status report
Post by: Apassi on November 29, 2007, 02:53:15 PM
Hi Swatch

Quote

I have heard tell of a hairline mark, but I  have yet to verify its existance.... to be honest, I haven't even figured out where the scribe actually is in that box.  I know that this is a problem and as a result, I'm going to try and figure out the historical way from photographs (if I can find any) and if that fails, I'll just improvise something thats at least usable.

There is interesting document on Aiaa.org called: An Entry monitoring system for maneuverable vehicles, but I dont have free acces there.
If remembering right, somenone among the developers here have such one.

http://pdf.aiaa.org/GetFileGoogle.cfm?gID=43648&gTable=mtgpaper



Title: Re: EMS progress/status report
Post by: Swatch on November 29, 2007, 06:40:22 PM
Awesome Apassi.... without a doubt some of the best investigative work I've run across here.

It does answer my question (ironically, the way I set it up is pretty close, even though I was just guessing).

Also for anyone who is interested in seeing the article....

http://swatch.homeip.net/Orbiter/Apollo Documents/EntryMonitoringSystemforVehicles.pdf (http://swatch.homeip.net/Orbiter/Apollo Documents/EntryMonitoringSystemforVehicles.pdf)


Title: Re: EMS progress/status report
Post by: Christophe on November 29, 2007, 07:11:40 PM
Fabulous doc!
Thanks Apassi and Swatch.


Title: Re: EMS progress/status report
Post by: Swatch on December 05, 2007, 02:21:20 AM
Trace Disappearance Bug Fixed, Drawing Code rewritten using PolyLine, vertical line added for reference on EMS Scroll Window, and scroll Bitmap size reduced.

Commited, and ready for you all to checkout and try.

I did a test checking how accurate the velocity change is, and it's pretty good (not perfect, as this is an integration along one axis, not like Orbiter's calc which takes into account absolute velocity changes)  Its off of Orbiter's value by about 300 ft/s after the first 5000 ft/s or so  and by 4000 ft/s it's off by around 1000 ft/s, but it's doing its job pretty well.  I suspect that the real thing also was only an approximation of velocity, and that for something with as much leeway as reentry has (once when you start to reenter that is) it's not a life threatening discrepancy. Range is all outta whack, not really sure why yet, but I believe it to be due to a combination of integration and unit conversion errors.


Title: Re: EMS progress/status report
Post by: Tschachim on December 05, 2007, 07:05:23 AM
Thanks for all your efforts, there's a small bug though: You moved the "GSE correction" (the "// Handle different gravity and size of the Earth" block) to the Init function, which is too early, sat->IsVirtualAGC() returns false at that time even if you do use the Virtual AGC. Could you move it back to AccelerometerTimeStep()?

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Coussini on December 05, 2007, 07:24:35 AM
Thanks for all your efforts, there's a small bug though: You moved the "GSE correction" (the "// Handle different gravity and size of the Earth" block) to the Init function, which is too early, sat->IsVirtualAGC() returns false at that time even if you do use the Virtual AGC. Could you move it back to AccelerometerTimeStep()?

Cheers
Tschachim

I just want to know, if the wiki page http://nassp.sourceforge.net/wiki/Entry_Monitoring_System

is up to date according to this new ems version. Thanks swatch for your effort. GREAT  :ThumbsUp432:


Title: Re: EMS progress/status report
Post by: Swatch on December 05, 2007, 11:20:03 AM
yea, I can do that....   I didn't think we needed to be checking that each timestep, but I can move it back.

It's partially up to date, I've been working on it, but it's not complete yet Coussini.


Title: Re: EMS progress/status report
Post by: Swatch on December 05, 2007, 02:26:01 PM
Ok.... there's a surprise for anyone who wants to compile what I just committed.   Just look at the EMS and flip the GroundTest Switch Up. :cool7777:

I'll get around to doing the actual logic once finals are finished.  That will require a bit of digging into the PGNS.  But I think it at least looks good.  It's set to rotate at 1 degree/timestep


Title: Re: EMS progress/status report
Post by: Swatch on December 06, 2007, 12:52:34 AM
I am curious to know how the RSI looks when it rotates to everyone.   If nobody has a problem with how it looks, then all I'll have to do is implement the logic....but I may be able to do some tweaking on looks if anyone has a problem.  It's using GDI calls right now, and not a bitmap since it needed to rotate freely.


Title: Re: EMS progress/status report
Post by: Coussini on December 06, 2007, 08:19:10 AM
Thanks Swatch  :cool7777:


Title: Re: EMS progress/status report
Post by: Tschachim on December 06, 2007, 02:25:52 PM
I am curious to know how the RSI looks when it rotates to everyone.   If nobody has a problem with how it looks, then all I'll have to do is implement the logic....

Nice, it rotates fine for me. Ignoring the GDI problems for now, this is something we probably need for the ORDEAL ALT SET rotary, too, because of the necessary very fine altitude setting.

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Swatch on December 09, 2007, 02:50:34 PM
Need some help here....

Below is a screenshot from the AOH, Section 2.3, Page 15.

(http://swatch.homeip.net/Orbiter/EMSQuestion.jpg)

I was wondering where I might find the algorithms/calcs that are done in those boxes surrounded by the RED Box (Entry Stability Roll XFormation).  Any Suggestions?  I know that Tschachim and dseagrav have done almost all the work on the SCS, so figured they might have run across this,  or at least a good document.


Title: Re: EMS progress/status report
Post by: NoName on December 09, 2007, 09:30:27 PM
I am curious to know how the RSI looks when it rotates to everyone.   If nobody has a problem with how it looks, then all I'll have to do is implement the logic....

Nice, it rotates fine for me. Ignoring the GDI problems for now, this is something we probably need for the ORDEAL ALT SET rotary, too, because of the necessary very fine altitude setting.

That's a nice idea :ThumbsUp432: Otherwise it would require some work and a rather large bitmap for fine tuning. 

By the way, I think I'll add a much nicer bitmap for the ORDEAL ALT SET rotary... ;)


Title: Re: EMS progress/status report
Post by: Swatch on December 10, 2007, 10:39:41 AM
Ok, I think I found the stuff I needed on the Stability Roll transformation, but now I'm trying to figure out how they convert the rates coming out of the BMAGS to something the RSI can use.  Any suggestions helpful.

Also, the .05 G light is almost working I think.


Title: Re: EMS progress/status report
Post by: Swatch on December 13, 2007, 12:26:56 PM
well... .05G is working, as are the Corridor Verification lights, but I broke 2 or 3 other things in the process....so it is getting there.


Title: Re: EMS progress/status report
Post by: lassombra on December 13, 2007, 01:21:14 PM
Awesome work swatch.  The EMS has been the thing I most wanted for a while now, but I'm still getting used to the code as it is.  There is a lot of code there to comprehend...


Title: Re: EMS progress/status report
Post by: Swatch on December 21, 2007, 04:46:24 AM
Ok.... EMS is fully committed for the time being.  Everything is working with one slight exception (math error that I'm not going to worry about until I have some good test scenarios) in the RANGE calculation.

RSI- Tried the historically documented method, but never recieved accurate values from the GDC.... I ended up improvising to match what I interpreted its output to be.  Will determine if it needs further work as testing insues.

Test away my pretties!  ENJOY!

PS
I'm gonna take a break from the EMS for a while (except maybe cleaning up some of my code) and work on the CM-VC and planning the Checklist MFD.  So if anyone else wants to work on it...be my guest.


Title: Re: EMS progress/status report
Post by: Coussini on December 21, 2007, 07:49:11 AM
The Wiki is update to explaine that ?



Title: Re: EMS progress/status report
Post by: Tschachim on December 21, 2007, 11:09:44 AM
Thanks Swatch, I'll try to test it as soon as possible!  :ThumbsUp432:

Cheers
Tschachim


Title: Re: EMS progress/status report
Post by: Swatch on December 21, 2007, 12:14:31 PM
The Wiki is update to explaine that ?



Not Yet, but it will be...


Title: Re: EMS progress/status report
Post by: Swatch on December 08, 2009, 07:34:14 PM
Updating the old topic...

I set it up so that someone can output their scroll trace... more info on the wiki page.

The way to use this feature is to make sure the GTASwitch (on the EMS) is in the up and unguarded position when either A) the simulation is saved, or B) the simulation is exited.  It is possible that the EMS needs to be powered on as well.

A bitmap file will then be created in your Orbiter root directory (where the executable is) known as Scroll.bmp.

CAUTION:  This file will be overwritten every time you hit save in Orbiter or close Orbiter with the above criteria met.

NOTE:  Since the scribe line is not saved between instances of Orbiter, if you close orbiter and reopen, then close again, the written scribe trace will only contain data created from the moment the simulation was started.

If you have any questions or problems don't hesitate to say so.