Meadville Space Center
Welcome, Guest. Please login or register.
August 08, 2020, 01:39:27 AM

Login with username, password and session length
Search:     Advanced search
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)
| | | |-+  Auto vAGC State Vector Update
« previous next »
Pages: 1 2 [3] 4 5 ... 10 Print
Author Topic: Auto vAGC State Vector Update  (Read 33093 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #30 on: April 18, 2008, 12:24:43 PM »

By looking at them? Rolling Eyes Wink Sorry, I don't get the question.
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #31 on: April 18, 2008, 12:54:28 PM »

Well...

I think that mission control had to just trust the astronauts.  They'd say "Go to Pooh and accept" and the astronauts would push all the buttons and then say "Ok, go" and then mission control would send the data.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #32 on: April 18, 2008, 01:00:21 PM »

If you send a keystroke and don't see the expected result in the screen image sent in the downtelemetry, then the switches are wrong.

Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #33 on: April 18, 2008, 01:16:16 PM »

well, yeah, I know that.  I'd just like the mfd to remind the user to set those switches if they're in the wrong position.  If not, no biggie.  I'll just add a line reminding them to do so.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #34 on: April 18, 2008, 01:18:35 PM »

do a search on google for fork and join.

You don't want to fork off a new process for an MFD; just a new thread.

See, for example: http://msdn2.microsoft.com/en-us/library/ms682453(VS.85).aspx

However, that's overkill. You should probably send one (or a small number) of commands, and then wait until the next timestep to send some more; otherwise the AGC won't get any time to process the incoming data.
Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #35 on: April 18, 2008, 01:25:16 PM »

well I did it a different way from that.  I realized my problem was from running the commands based off a button press, which resulted in a lock up when it had to wait, so I moved all the input stuff to the update function of the mfd, and had the input be entered in 1 second intervals using the mission time as a base.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #36 on: April 18, 2008, 01:32:36 PM »

Probably doesn't need to be as slow as one per second; there must be some documentation somewhere on the interface and how fast they could send the real telemetry.

The important thing is to only send one per timestep since the AGC is currently clocked in the vessel's timestep() function so it can't process anything until then. Though I suppose we could add in some kind of buffer to write to that the AGC could be fed from during the timestep processing.

Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #37 on: April 18, 2008, 01:35:30 PM »

so how fast would the mfd update() function go in comparison with the vessel's timestep() function?

EDIT: Well, just tested that, and got a program alarm.
« Last Edit: April 18, 2008, 01:39:55 PM by BlueDragon8144 » Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #38 on: April 18, 2008, 01:57:52 PM »

I would suspect you could send all the numerical keystrokes in one pass, and then wait a second or so based on mission time then send the next keystrokes in another pass.

Also, you don't have to do all this in update (and probably shouldn't) instead, use opcTimestep.

The thing is, update runs in the graphics routines, and is not intended to have a lot of calculations beyond the ones for the basic display.

Also, the idea that it's just the cmc not getting time to respond is bogus, we're going through the tcp.  It provides a producer/consumer que.  When the cmc gets a timestep, it'll grab one(or maybe more) packet from the tcp interface.  The problem is in stacking up commands right behind one that takes some processing.  We need to give the cmc time to catch up.  I suspect that mission control didn't have this problem because they could only send the commands so fast.  However, we now have a much higher bandwidth connection, and can likely send the commands too quickly.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #39 on: April 18, 2008, 02:18:43 PM »

well, the way it's set up is
V71E, wait 1 second, 21E, wait 1 second, 1501E, wait 1 second.....V33E, close connection.

I'll see about opcTimestep, but that requires some tweaking of some stuff.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #40 on: April 18, 2008, 02:21:37 PM »

shouldn't require too much... except that it is a non-object method...

But... I don't think we need the logic to be multi-instance, just the screen, right?
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #41 on: April 18, 2008, 02:32:17 PM »

yeah, it wasn't much to move it over.  Still getting that program alarm though if I remove the 1 second delay  Undecided

and what do you mean by the logic being multi-instanced?
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #42 on: April 18, 2008, 02:44:12 PM »

Well, when Orbiter displays an MFD, it creates an object of that MFD (an instance).  There is no reason, in this case, for the logic to spread across multiple MFD's (the rest of Project Apollo MFD has a singular logic backend and only the display is OO...)
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #43 on: April 18, 2008, 02:57:18 PM »

oh, thats what you mean.  Yeah, it's following the same pattern as the rest of the MFD, which in this case would be the IMFD stuff, as I just moved the TCP stuff over to opcTimeStep().  The actual calculations are still linked to the button being depressed.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #44 on: April 18, 2008, 03:20:32 PM »

That's fine...

Just curious, do you have any ready for the cvs yet?  I'm really curious to look at what you've got.

Also, if you want to check the position of the uplink switches, you can use the mfdPanelConnector...

Read the code in the ChecklistMFD to see how that works.

*tries to figure out why he didn't think of that before.  He helped to write 2/3 of the code in that object...*

It will give you options for reading/writing the current state of switches.  Eventually, you'll even be able to command V 3 7 E 0 0 E through it... (I'm working on it, REALLY!)  So, you could provide a button that is like "prepare uplink" whenever the system is not 100% the way it should be.
« Last Edit: April 18, 2008, 03:23:08 PM by lassombra » Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Pages: 1 2 [3] 4 5 ... 10 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!