Meadville Space Center
Welcome, Guest. Please login or register.
October 24, 2020, 09:28:09 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: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  EMS progress/status report
« previous next »
Pages: 1 2 [3] 4 5 Print
Author Topic: EMS progress/status report  (Read 22949 times)
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #30 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).
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #31 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.
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)
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #32 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.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #33 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.
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)
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #34 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.
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)
Apassi
Full Member
***
Posts: 65


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



« Last Edit: November 27, 2007, 09:46:53 PM by Apassi » Logged
NoName
Project Team Member
Hero Member
****
Posts: 795


View Profile
« Reply #36 on: November 27, 2007, 09:49:26 PM »

No lock ups here too Wink
Logged
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #37 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

Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #38 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.
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)
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #39 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...



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....



...but more importantly, there appears to be a scale written on the left hand side of the frame....that would be nice eh?
« Last Edit: November 28, 2007, 02:21:41 AM 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)
Apassi
Full Member
***
Posts: 65


View Profile
« Reply #40 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

Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #41 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
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)
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #42 on: November 29, 2007, 07:11:40 PM »

Fabulous doc!
Thanks Apassi and Swatch.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #43 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.
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)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #44 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
Logged

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