Meadville Space Center

Project Apollo - NASSP => Programming => Topic started by: bluespace88 on April 13, 2008, 12:01:34 PM



Title: Auto vAGC State Vector Update
Post by: bluespace88 on April 13, 2008, 12:01:34 PM
Hello

I just joined the dev team, and this will be my first time doing programming with Orbiter.  Pretty much continuing the work schneci did (from scratch) before he left, unless he miraculously reappears.  As requested by Tschachim, it will be in PAMFD.  And as such, I'll probably be asking for some help here and there.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 13, 2008, 12:23:36 PM
Welcome aboard.  I'll happily help where I can, though no one knows their way around PAMFD like Tschachim.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 14, 2008, 02:16:50 AM
thanks.  Right now, I'm just trying to understand the procedure used to get the emem values.  And thanks for the tip, I'll be sure to ask Tschachim about integrating it into PAMFD.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 14, 2008, 08:09:03 AM
ok, I got the algorithm going using the data from the excel sheet and a few shortcuts.  I'm going to need some help getting a screen up on PAMFD and actually getting the state vectors from Orbiter for the calculations. 


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 14, 2008, 09:19:35 AM
I'm going to need some help getting a screen up on PAMFD...

For me it's fine if you add that to the GNC screen, this screen doesn't do much except displaying some values to compare with P11 anyway.

...and actually getting the state vectors from Orbiter for the calculations.

That would be something like:

VECTOR3 vel, pos;
OBJHANDLE planet = saturn->GetGravityRef();
saturn->GetRelativeVel(planet, vel);
saturn->GetRelativePos(planet, pos);


Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 14, 2008, 10:06:33 AM
thanks.  I'll see if I can get the numbers on the screen before tackling the AGC.


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on April 14, 2008, 10:08:38 AM
Is the intent to go through the uplink or write it directly?


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 14, 2008, 10:13:19 AM
Through the uplink, via the existing TCP/IP interface would be the preferred solution.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 14, 2008, 10:15:56 AM
I'll keep that in mind.  Just one question.  Which variable stores the launch mjd date, if there is one?

EDIT:  Nevermind, found it.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 14, 2008, 10:45:01 AM
By the way, I forgot to mention that there's a CVS module called telemetryClient, which contains dseagrav's telemetry client, written in managed C++/WinForms, including an exe file (GroundStation.exe). It doesn't calculate anything, but you can test the downlink/uplink telemetry including state vector etc. and so see how it works: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg9828#msg9828

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 14, 2008, 10:57:45 AM
ok, I'll check it out.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 14, 2008, 03:24:25 PM
ok, finally got the pad values into Orbiter and calculated.  I'm going to look at the telemetry stuff to see how it would uplink to the AGC.

Also need to get it working under the moon's soi.  The code's there....I just don't know how to check which soi you're in.


Title: Re: Auto vAGC State Vector Update
Post by: Admiral on April 15, 2008, 03:53:15 AM
From what I can tell on IMFD, there is a time when you are outside Eath SOI and outside Moon SOI - just in Sun SOI.  I could be wrong. but may be worth checking or considering.  Others can advise if am I am inadvertently introducing a red herring.



The Admiral


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 15, 2008, 05:55:41 AM
you're not.  There is a time that you are in the sun's SOI.


Title: Re: Auto vAGC State Vector Update
Post by: Admiral on April 15, 2008, 06:54:01 AM
Thanks for the info.  Do you know if we have a way of calculating state vectors while in sun soi?

The Admiral


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 15, 2008, 07:20:07 AM
don't think so.  The excel sheet certainly didn't have that.  You'd probably have to wait till you're in either SOI.  Either way, you won't be doing an MCC until you're actually in the Earth's or Moon's SOI, so you wouldn't need to update the state vectors when you're in between them.

Anyway, I need some pointers for the TCP/IP stuff, as I never used them before, and not sure how to use them within VC++ 6, as the telemetry stuff is for VC2005.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 15, 2008, 08:27:35 AM
...I just don't know how to check which soi you're in.

From an Orbiter or Virtual AGC point of view? For Orbiter see Orbiter API Reference, page 81ff.

Anyway, I need some pointers for the TCP/IP stuff, as I never used them before, and not sure how to use them within VC++ 6, as the telemetry stuff is for VC2005.

Something like this: http://www.codeproject.com/KB/IP/winsockintro02.aspx ?

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 15, 2008, 10:51:14 AM
Thanks for the link.

I know about that function, but I don't know what it returns at all.

EDIT: Ok, just found the relevant function for that.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 16, 2008, 03:36:32 PM
Just a question.  I got the TCP connection working and have had V71E inputted in and working.  How would you check to see if the agc isn't still processing data so the next values can be inputted and entered.  I have tried recv() and that caused Orbiter to freeze.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 16, 2008, 06:59:51 PM
I think you can just send all the data.  All it is, after all, is a series of keystrokes.  There is technically no limit to how fast you can enter keys (except maybe the size of the key buffer).


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 16, 2008, 08:01:23 PM
well, I did try that and it gave me a 1202 alarm.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 16, 2008, 10:05:07 PM
huh.... as far as I know, the old telemetry MFD just sent it.

I'll dig through the telemetry client to see how it does it, because it has an upload structure, and it does work.


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on April 16, 2008, 10:05:49 PM
Really... A 1202?!?

Actually I thought about it and it makes sense. The AGC does not have a key buffer. Every time a keystroke, or in this case a uplink strole is processed it throws an interrupt and the stoke is processed. If you throw too many at once it hits the ceiling of the number of processes the AGC can handle at one time and it shots a 1202 alarm.

Slow down the rate that each stroke is sent so it gives time for the AGC to process them.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 16, 2008, 10:09:12 PM
thats what I'm looking at.  It does fine when you're just inputting the numbers, and the error only crops up after enter is sent and the agc has to process the data.  Ideally, I would like to see if the agc is idling rather than having a set time to wait in case of some unforseenable errors.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 16, 2008, 11:20:52 PM
How would one create something like a thread in C++?  The problem I'm having is that Orbiter is freezing each time I have a delay added.  I realized it's because the function is run from one of the Orbiter MFD functions, which is the button press, and if there's a substantial delay, Orbiter freezes.  Sorry for all these questions, but this is the first time I'm programming in C++.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 17, 2008, 01:04:01 AM
do a search on google for fork and join.

All I know is that they are the "objects" that represent a concurrent execution in ansi C++


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 17, 2008, 04:59:14 AM
thats what I'm looking at.  It does fine when you're just inputting the numbers, and the error only crops up after enter is sent and the agc has to process the data.  Ideally, I would like to see if the agc is idling rather than having a set time to wait in case of some unforseenable errors.

I don't know what TelemetryMFD does, but it looks like that GroundStation.exe looks at the downlink telemetry, the DSKY output and some CMC stuff is included in downlink telemetry, but I didn't check the details...

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 17, 2008, 02:32:49 PM
yeah, I'm trying to come up with a short simple parse algorithm that can parse JUST the cmc important data.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 08:44:26 AM
well, for now, I managed to get it working by having a 1 second delay between inputs, which is working quite well atm.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 10:02:06 AM
Quick question.  How can you check to see if both the UPTLM CM switch is set to ACCEPT and UP TLM DATA set to up?


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 18, 2008, 12:24:43 PM
By looking at them? :roll: :wink: Sorry, I don't get the question.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra 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.


Title: Re: Auto vAGC State Vector Update
Post by: dseagrav 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.



Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 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.


Title: Re: Auto vAGC State Vector Update
Post by: movieman 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.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 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.


Title: Re: Auto vAGC State Vector Update
Post by: movieman 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.



Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 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.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra 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.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 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.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra 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?


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 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  :|

and what do you mean by the logic being multi-instanced?


Title: Re: Auto vAGC State Vector Update
Post by: lassombra 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...)


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 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.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra 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.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 03:25:08 PM
yep, I can upload it.  Just haven't done much with the display though, as the only time I worked on it was when I wanted to cross check the emem values with the the excel values, so it's kinda rough.  The only other information it tells you is the SOI and if you're connected to the TCP connection or not (which was mainly for debugging).

It's under the GNC screen.  Make sure your switches are set to the proper position, and if you're not in the right SOI, change the reference planet to the right one, and press the SV button or Shift-S (any better key suggestions?).

Just give me a few minutes.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 18, 2008, 03:29:35 PM
nah, Shift+S is fine.

Looking good, this is something I've been wanting to do for a long time, but I can't seem to get my head around the math, so it's really good that someone who can is also able to put it into the MFD :)


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 03:41:10 PM
Sorry it's taking so long.  Have to do a CVS checkout, since I haven't done one for the developer's side yet.

yeah, took a while to get through the math part.  I wanted to understand what it meant before coding it in. 


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 18, 2008, 04:04:44 PM
Ah... yeah, the checkout can be lengthy...

Anyways, whenever is cool.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 04:28:39 PM
commited :)


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 18, 2008, 04:35:30 PM
cool, I'll poke around and see if I can comprehend the math in computer form...

And, I'm going to be trying it out...  Next thing you know we'll be having vAGC flights to the moon as the "quickstart" mode :)


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 04:48:57 PM
kinda need to go 10000x time acceleration first  :D

Still need to get in a vessel implementation for other vessels, and also make a nice display for it with reminders to go pooh and flip the right switches on.


Title: Re: Auto vAGC State Vector Update
Post by: movieman on April 18, 2008, 04:56:48 PM
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.

OK, I didn't realise that, I thought it was just poking values into the input channels.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 05:05:08 PM
yep.  It's opening a TCP port and sending all the data through that port to the AGC.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 05:27:09 PM
Forgot to add, you need to add WS2_32.LIB to your list of libraries  :awwcrap4253:


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 18, 2008, 05:38:55 PM
huh... should be in the PAMFD already...  We use it to manage sockets in that MFD from the perspective of CM's telemetry.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 18, 2008, 05:51:20 PM
hmm, really?  I had to re-add it for mine when compiling under VC6. 

EDIT:  Forgot to add the dsp to the CVS.  Committed now.


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 19, 2008, 12:41:43 AM
my bad, it's not in the MFD, it's in the configurator.  I'll add those to the VC2008 files.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 19, 2008, 01:10:26 AM
thanks.  I'll see what I can do with the VC2005 ones.


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on April 20, 2008, 11:49:20 AM
Where can I find the tool in CVS?


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 20, 2008, 02:53:36 PM
it's in the Project Apollo MFD.  You'll have to rebuild modules to get it.


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on April 20, 2008, 05:38:09 PM
it's in the Project Apollo MFD.  You'll have to rebuild modules to get it.

Thanks!

BTW...should the Ground Station telemetry client be working? I'm getting a "LOCKOUT/FRAM" error when connecting to localhost!

Pete


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 21, 2008, 01:34:43 PM
The ground station was never finished, though I got it to connect for me.

And onto updates, just added the ability to update the state vectors of other vehicles, ie the Apollo 7 SIVB stage, by allowing you to select the source.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 21, 2008, 02:08:43 PM
Right now, the display has the vessel and planet on bottom left, a connection display, and it reminds you to go to pooh and flip the two uplink switches on panels 2 and 3.
(http://i66.photobucket.com/albums/h251/BlueDragon8144/More%20stuff/mfd.jpg)

Any suggestions on what should be displayed?


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on April 21, 2008, 11:36:50 PM
I think the best things to display would be the update code and state vectors in the AGC frame for eventual comparison with the down linked values. Which is the way that it was done.


Title: Re: Auto vAGC State Vector Update
Post by: dseagrav on April 22, 2008, 04:35:31 PM
Right now, the display has the vessel and planet on bottom left, a connection display, and it reminds you to go to pooh and flip the two uplink switches on panels 2 and 3.

You don't have to be in P00 for telemetry to be sent. Different active programs generate different telemetry.
The client program knows (knew) how to tell which list was what.
Edit: You don't have to be in P00 to send keystrokes either. You can send V37E00E if the crew doesn't. You can read the DSKY image in the downlink data to see if you need to or not.

It worked last time I messed with it, and I don't think anyone ever touched it after I committed it, so unless someone broke the connection between the vAGC and the TCP port, it should be working.

Note that you will be out of lock for a few seconds on initial connection as the telemetry client and AGC reach sync.
Edit: When low bitrate is selected this can take awhile. The list has to cycle through and the client has to identify the start and type of the list.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 22, 2008, 06:01:01 PM
well, it's generally better to go pooh first anyway.  I haven't tried it at LBR though.  How would you read the DSKY image anyway?


Title: Re: Auto vAGC State Vector Update
Post by: dseagrav on April 22, 2008, 06:11:14 PM
It's encoded in the downlink list. The telemetry client will display it for you. It's in the uplink operations screen. If you want to read it yourself the format is described in the NASA documentation. The downlink datastream follows the orignal NASA format exactly with the possible exception of parity bits. (I don't set or check them, but the ones the AGC generates are passed intact. Computing and checking parity is not cheap in software.)


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 23, 2008, 05:22:33 AM
Hi BlueDragon8144,

I unfortunately didn't have the time to test the new functions, but it looks like you're doing a great job!  :ThumbsUp432:

Skimming through the code it looks like you threw out the old "P11 GNC" screen completely. No problem, looks like I didn't think much about it :wink:, but I still would like to have that screen as an optional GNC display (or as a new screen). If it's no problem for you, I'd be happy if you can do that, otherwise I can do that by myself later, no problem, too...

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 23, 2008, 09:32:32 AM
I can have it as that screen normally till you wish to do the state vector, so I can do it, no problem.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 23, 2008, 11:58:18 AM
actually, I'll just make a new screen.  The main menu has plenty of unused buttons, so I'm going to take one and make that Telemetry, and put the state vector stuff in there and leave room for any other telemetry programs.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 23, 2008, 12:32:11 PM
any complaints about this?
(http://i66.photobucket.com/albums/h251/BlueDragon8144/More%20stuff/mfd-1.png)
each screen occurs each time you press the SV button.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on April 23, 2008, 12:47:27 PM
actually, I'll just make a new screen.  The main menu has plenty of unused buttons, so I'm going to take one and make that Telemetry, and put the state vector stuff in there and leave room for any other telemetry programs.

Great!

The screenshots are looking great, too! You might want to denote that there are 2 uplink telemetry switches and also to switch to high bit rate

V37E 00E
UPTLM CM (MDC 2, LEB 122) - ACCEPT (up)
UP TLM (MDC 3) - DATA (up)
PCM BIT RATE (MDC 3) - HIGH (up)

Cheers
Tschachim



Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 23, 2008, 01:10:00 PM
thanks.  Forgot about the bit rate.  I'll commit after making the changes.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on April 23, 2008, 01:52:34 PM
committed


Title: Re: Auto vAGC State Vector Update
Post by: lassombra on April 24, 2008, 03:52:50 AM
Comments by Bertog split into separate thread.

Split topic moved to:

Support & Bugs.

http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1692.0


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on April 24, 2008, 10:33:24 AM
Right now, the display has the vessel and planet on bottom left, a connection display, and it reminds you to go to pooh and flip the two uplink switches on panels 2 and 3.

You don't have to be in P00 for telemetry to be sent. Different active programs generate different telemetry.
The client program knows (knew) how to tell which list was what.
Edit: You don't have to be in P00 to send keystrokes either. You can send V37E00E if the crew doesn't. You can read the DSKY image in the downlink data to see if you need to or not.

It worked last time I messed with it, and I don't think anyone ever touched it after I committed it, so unless someone broke the connection between the vAGC and the TCP port, it should be working.

Note that you will be out of lock for a few seconds on initial connection as the telemetry client and AGC reach sync.
Edit: When low bitrate is selected this can take awhile. The list has to cycle through and the client has to identify the start and type of the list.



Yes, tried it some more and the CMC data works great! Just wasn't waiting long enough.

Peter


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on May 02, 2008, 12:48:09 PM
Hi BlueDragon8144,

I had the chance to try the state vector update today. At first I had problems transferring the data to the CMC correctly. It turned out that there was a "small but effective" bug in the handling of the UP TLM CMD switch resetting the uplink command unintentionally. I fixed that and additionally introduced a check that the telemetry waits reading the socket receive buffer until the last uplink interrupt is processed in the Virtual AGC. Now the data transfer seems to work fine, changes are committed (no changes in the MFD, your stuff is fine  :)).

But I'm not sure if the uploaded state vector is correct. I must admit that I'm no state vector expert, I never did a manual state vector update nor used the old TelemetryMFD, also I didn't check or verified the transmitted data, but I did the following: Rather shortly after orbit insertion I asked the VAGC for ApA/PeA (Verb 82) and got 155.2 / 122.2 nmi, the PAMFD GNC screen was showing 155.3 / 124.6 mni, so the values are quite fine as usual. After the state vector update (a few seconds later, PAMFD was showing still the same) V82 displayed 169.4 / 131.6, after the next update (again only a few seconds later) I got 142.8 /107.1 nmi

I don't know if this is the expected result, I for my part didn't expect that, but again I'm no state vector expert...

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on May 02, 2008, 01:14:16 PM

I don't know if this is the expected result, I for my part didn't expect that, but again I'm no state vector expert...

Cheers
Tschachim

I thought that the auto SV upload stuff was sending the new statevector over with an MET of 0 rather than the correct time? Or is that something else...


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on May 02, 2008, 03:10:56 PM
Something else. BlueDragon8144 did a new SV upload, now integrated in PAMFD, see the first post of this thread.

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on May 02, 2008, 04:10:11 PM
I don't know if this is the expected result, I for my part didn't expect that, but again I'm no state vector expert...

Its on my list of things to do. To verify that the MFD uploads an accurate state vector. Its impossible to tell with V82. Maybe this weekend.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on May 02, 2008, 04:26:58 PM
Its impossible to tell with V82.

Propably you explained it already, but may I ask why V82 can be off?

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on May 02, 2008, 06:28:23 PM
Hi BlueDragon8144,

I had the chance to try the state vector update today. At first I had problems transferring the data to the CMC correctly. It turned out that there was a "small but effective" bug in the handling of the UP TLM CMD switch resetting the uplink command unintentionally. I fixed that and additionally introduced a check that the telemetry waits reading the socket receive buffer until the last uplink interrupt is processed in the Virtual AGC. Now the data transfer seems to work fine, changes are committed (no changes in the MFD, your stuff is fine  :)).

But I'm not sure if the uploaded state vector is correct. I must admit that I'm no state vector expert, I never did a manual state vector update nor used the old TelemetryMFD, also I didn't check or verified the transmitted data, but I did the following: Rather shortly after orbit insertion I asked the VAGC for ApA/PeA (Verb 82) and got 155.2 / 122.2 nmi, the PAMFD GNC screen was showing 155.3 / 124.6 mni, so the values are quite fine as usual. After the state vector update (a few seconds later, PAMFD was showing still the same) V82 displayed 169.4 / 131.6, after the next update (again only a few seconds later) I got 142.8 /107.1 nmi

I don't know if this is the expected result, I for my part didn't expect that, but again I'm no state vector expert...

Cheers
Tschachim
Thanks for checking it out.  Been a bit busy with finals, so sorry if I'm not on much.

I'm betting the v82 problem would be the same manual way of updating using the excel sheet.  While I was developing it, I had it pop out values on every mfd refresh rate, and checked them against the manual update, and they were pretty much spot on, except for every other emem value starting from 1503, which was off by a few units.  I haven't done anything else with the calculations since then.

The most probably reason for this, as I found out with the constant emem value update, was that these values changed rapidly, greater than 100 units every second, and I'm betting that this is the reason why v82 isn't that accurate.  I'm not sure how it's done in real life, but both the Ground Station and Telemetry MFD used the same method, and I know that the Ground Station would probably have the same problems, especially when you have to give it values from the excel sheet.


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on May 03, 2008, 12:07:27 AM
I have yet not been able to explain V82 differences with orbiter. It is something I have not really dove into yet, and I suspect it is the way the AGC computes it, creating some error.

In another note I cannot seem to get it to build with VS2005. I get:
Code:
------ Build started: Project: ProjectApolloMFD, Configuration: Release Win32 ------
Linking...
   Creating library .\Release/ProjectApolloMFD.lib and object .\Release/ProjectApolloMFD.exp
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _send@16 referenced in function "void __cdecl send_agc_key(char)" (?send_agc_key@@YAXD@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _connect@12 referenced in function "void __cdecl UplinkStateVector(double)" (?UplinkStateVector@@YAXN@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _htons@4 referenced in function "void __cdecl UplinkStateVector(double)" (?UplinkStateVector@@YAXN@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _inet_addr@4 referenced in function "void __cdecl UplinkStateVector(double)" (?UplinkStateVector@@YAXN@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _closesocket@4 referenced in function "void __cdecl UplinkStateVector(double)" (?UplinkStateVector@@YAXN@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _WSAGetLastError@0 referenced in function "void __cdecl UplinkStateVector(double)" (?UplinkStateVector@@YAXN@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _socket@12 referenced in function "void __cdecl UplinkStateVector(double)" (?UplinkStateVector@@YAXN@Z)
ProjectApolloMFD.obj : error LNK2019: unresolved external symbol _WSAStartup@8 referenced in function "void __cdecl ProjectApolloMFDopcDLLInit(struct HINSTANCE__ *)" (?ProjectApolloMFDopcDLLInit@@YAXPAUHINSTANCE__@@@Z)
../../../../../Modules/Plugin/ProjectApolloMFD.dll : fatal error LNK1120: 8 unresolved externals
Build log was saved at "file://c:\Program Files\NASSP 060601\Orbitersdk\samples\ProjectApollo\VC2005\ProjectApolloMFD\Release\BuildLog.htm"
ProjectApolloMFD - 9 error(s), 0 warning(s)
:awwcrap4253:


EDIT: Nevermind I read the other thread


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on May 03, 2008, 02:25:16 AM
yeah, someone needs to update the vc2005 and vc2008 solutions to include the WS2_32.lib file as a dependency.


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on May 03, 2008, 07:06:16 AM
For state vector updates...do we take the positions in Earth and Equatorial Fixed references? (as opposed to Ecliptic and Eq Rotating)?

Pete



Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on May 03, 2008, 12:24:34 PM
it's whatever was default when you open scn editor.


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on May 03, 2008, 03:45:57 PM
it's whatever was default when you open scn editor.

Earth, Ecliptic and Cartesian....confusing myself because the EOCA calc uses Earth, Equatorial Fixed, Cartesian.

Thanks!


Title: Re: Auto vAGC State Vector Update
Post by: movieman on May 25, 2008, 01:06:40 PM
BTW, Fabrizio Bernardini sent me and Ron Burkey an email updating the work he had done on the Virtual AGC state vector; Ron was going to stick it on his site, but I'm not sure whether it's there yet... if anyone wants a copy, let me know and I'll forward the email.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on May 25, 2008, 01:09:32 PM
Certainly interesting, I'd be glad to have a copy...


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on May 25, 2008, 03:44:03 PM
I would like a copy as well.  Definitely interesting.


Title: Re: Auto vAGC State Vector Update
Post by: movieman on May 25, 2008, 11:43:18 PM
You'll probably have to send your email address in a PM as I can't find a way to find it on the forum :).


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on May 27, 2008, 09:34:13 AM
I wonder if there's a way to actually calculate the state vectors at a future time like it was done in that, because the current way doesn't exactly give accurate readings, though it's probably more accurate then doing by hand. 

Updating via realtime doesn't help either.


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on May 29, 2008, 12:41:55 AM
I wonder if there's a way to actually calculate the state vectors at a future time like it was done in that, because the current way doesn't exactly give accurate readings, though it's probably more accurate then doing by hand. 

Updating via realtime doesn't help either.

Could  you elaborate on this a little. Why would it help to calculate State vectors at a future time?


Title: Re: Auto vAGC State Vector Update
Post by: pattersoncr on June 23, 2008, 04:54:08 PM
How difficult would it be to add functionality to update the LM state vector?
Perhaps it would require a list of vessel in the scenario (like when you hit F3) to tell the MFD what vessel to use to base the update on.  Or perhaps that will be obvious enough for a given scenario (SIVB for Apollo VII, LM for Apollo IX and later) and specified in the .scn file.
The reason I ask is because I'd like to start tinkering around with some of the rendezvous programs in the Apollo VII mission, i.e. P20 as well as P17, P34, etc and I'm too lazy to keep updating the LM SV for the SIVB manually.

Thanks,
Chuck


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on June 23, 2008, 05:07:22 PM
If I'm understanding you correctly, you can change the source vessel to the LEM/SIVB on the bottom left so you can update the vectors for the LEM/SIVB.  You can also change the reference for the moon's or earth's soi.
(http://i66.photobucket.com/albums/h251/BlueDragon8144/More%20stuff/mfd.jpg)



Title: Re: Auto vAGC State Vector Update
Post by: pattersoncr on June 24, 2008, 04:45:05 PM
That's exactly what I was looking for BlueDragon.  I didn't realize the functionality was already there.
Beautiful!

Chuck


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on June 24, 2008, 09:20:43 PM
No problem.  I still need to see if there's a better way to get more accurate state vectors, because the current ones aren't all that accurate.  Just haven't had time to get around to experimenting because of summer work at the lab  :awwcrap4253:


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on June 30, 2008, 08:37:42 AM
Ok, just tried a different approach.  I was thinking that maybe the values get uploaded to the agc after the last value is inputted, which in this case, is about 17-18 seconds after the state vector was calculated.  So I thought, what if I set the clock to 17-18 seconds before the actual time, and then calculate the state vector, so once the last value is inputted, it'll be the same time as when the actual state vector was calculated.  This test was done by setting the clock back 18 seconds.  I don't know if the extra second taken when going to pooh matters, but the results are much more accurate than before.

AGC      Actual
101.8x95.9   107.8x97.3
108.5x91.7   107.7x97.1


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on June 30, 2008, 09:47:30 AM
Sorry for the dump question, but I thought the state vector are combined location/velocity/time data and not just location/velocity for the time the upload happens, so the actual upload time shouldn't matter?


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on June 30, 2008, 11:17:38 AM
the values actually aren't static, the way they're being done now.  They change quite rapidly within a second.  I could probably show how fast later to give you an idea of how fast they change.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on June 30, 2008, 12:24:19 PM
That's not what I meant, but perhaps I'm too wrong to be understandable:  :wink:

I was thinking that the data you're sending is like "the spacecraft was at location x and velocity y at GET z", you calculate and store these data in one time step, so they are consistent. Of course it takes a couple of seconds to upload that, but you upload not only x and y, but also z, so x and y isn't w.r.t. the actual upload time, but z. Or to put it differently, you could calculate the data now and send them in a couple of hours, which would mean you send an old state vector and the AGC needs to propagate, but you are not sending a wrong one.

But I may be completely wrong here...  :sorry345:


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on June 30, 2008, 01:36:55 PM
yeah, I thought so too, but the way it is being done now isn't giving reliable data, and I really have no idea why.  All the data is taking from that very same instant, which is the x, y, z positions and velocities, as well as the time.  I could have been completely wrong earlier about how it is done though.  Need some more time to play around with it.


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on August 02, 2008, 07:42:53 AM
That's not what I meant, but perhaps I'm too wrong to be understandable:  :wink:

I was thinking that the data you're sending is like "the spacecraft was at location x and velocity y at GET z", you calculate and store these data in one time step, so they are consistent. Of course it takes a couple of seconds to upload that, but you upload not only x and y, but also z, so x and y isn't w.r.t. the actual upload time, but z. Or to put it differently, you could calculate the data now and send them in a couple of hours, which would mean you send an old state vector and the AGC needs to propagate, but you are not sending a wrong one.

But I may be completely wrong here...  :sorry345:

Correct....you can in theory send any state vector you like..but the AGC can't cope with having to propagate a very old SV. (well it can but it will just be tied up for a long time doing so). The entire reason SVs were uploaded was because the STN could determine the spacecrafts position to a very high degree of accuracy. Any uplinked state vector would have been at best several minutes old (at worst prehaps longer).

Pete


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 02, 2008, 03:08:27 PM
Correct....you can in theory send any state vector you like..but the AGC can't cope with having to propagate a very old SV.

Sure, it was just meant as an illustration, the actual SV we're uploading is only a couple of seconds old.

Quote from: kneecaps
Current Work: Getting us a complete AOH Volume II

By the way, any updates?  :)

BlueDragon8144, I took a look at your code and I saw that you're using some hardcoded constants for coordination transformations in void ProjectApolloMFD::GetStateVector (void), for example 23.45. These constants are slightly off, this one should read 23.43929... I don't know of this makes a big difference, but I suggest to not use constants in the code, but the OrbiterAPI-calls for that (oapiGetPlanetObliquityMatrix or something like this).

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on August 05, 2008, 05:05:00 PM
hmm....i'll look into that and let you know.  Just need to get orbiter on my new machine up and running.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on August 05, 2008, 06:58:09 PM
results still vary, about +/- 10nm

Actual
100.0x99.6   

V82
109.9x95.3
108.4x91.9
104.7x92.8
98.1x94.9
97.7x89.8


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 06, 2008, 08:58:44 AM
Thanks for looking at that, did you already commit the change to CVS? I suppose you did the V82's quite shortly in series, so the actual (osculating) orbit didn't change? I still have no clue why this happens...  :gloomy3353:

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on August 06, 2008, 06:08:15 PM
just commited it.  I'm going to see how it turns out if i used the old manual state vector updates.

Can someone see how accurate the manual state vector is using the spreadsheet?  I would do it, but I currently don't have office installed.


Title: Re: Auto vAGC State Vector Update
Post by: Christophe on August 06, 2008, 07:20:34 PM
results still vary, about +/- 10nm

Actual
100.0x99.6   

V82
109.9x95.3
108.4x91.9
104.7x92.8
98.1x94.9
97.7x89.8

When you say "Actual". What do you mean exactly?
Is it the parameters from orbit MFD?


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on August 06, 2008, 07:28:07 PM
it's from the gnc page of projectapolloMFD, which is just the values from the orbit MFD in US units i think.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 07, 2008, 08:36:27 AM
Yes, the MFD uses the OrbiterAPI calls GetApDist/GetPeDist, which should be pretty much the same as OrbitMFD shows.

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: Christophe on August 07, 2008, 04:06:23 PM
Yes, the MFD uses the OrbiterAPI calls GetApDist/GetPeDist, which should be pretty much the same as OrbitMFD shows.

Cheers
Tschachim

So in this case the difference seems to be normal: Orbit MFD displays only the osculating orbit at a specific time.
Try to put the state vectors into EOCA (if you know how to use it) and you should get about the same orbit as shown via vAGC.

However, you get this:
results still vary, about +/- 10nm

Actual
100.0x99.6   

V82
109.9x95.3
108.4x91.9
104.7x92.8
98.1x94.9
97.7x89.8

And I don't understand why the parameters vary time after time.


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on August 07, 2008, 09:09:24 PM
we're not sure why it does that either.  It varied each time i did a state vector update. I'm betting it's the calculations, since I did compare values between the auto state vector and manual state vector to make sure they matched up when I was developing the code, but I want to make sure just in case.  My office 2003 cd's back down at college, so I have no way of doing the manual state vector without help.


Title: Re: Auto vAGC State Vector Update
Post by: kneecaps on August 19, 2008, 06:58:43 AM

Quote from: kneecaps
Current Work: Getting us a complete AOH Volume II

By the way, any updates?  :)


Yes, I have it here PDFd ready to go (80mb though). I'm just awaiting permission from the kind fellow who provided the source scans. We are going to release it shortly via a website that's in the process of being setup.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 19, 2008, 08:26:00 AM
Yes, I have it here PDFd ready to go (80mb though). I'm just awaiting permission from the kind fellow who provided the source scans. We are going to release it shortly via a website that's in the process of being setup.

Great news, can't wait!  :ThumbsUp432:


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 21, 2008, 08:02:34 AM
Hi BlueDragon8144, Irnenginer & Co,

Two of the Virtual AGC guys, Fabrizio Bernardini and Christian Bucher, were messing around with state vector updates, too, not in relation with Orbiter but more on a "theoretical basis", see attached file. At a first glance, it doesn't seem to contain anything new for us, but I might be wrong and perhaps it's interesting anyway.

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: Christophe on August 28, 2008, 03:40:08 PM
Well,
In my mind there are no hundreds ways to compute SV.
I think that either the maths in spreadsheet or auto SV update MFD are right.

I rather think that the problem is coming from the used datas:

1/ Don't try to compare orbit parameters from vAGC with orbit MFD or others datas coming from orbit MFD. If there is only one way to compute SV, there are plenty of ways to consider the orbit parameters while in a perturbated gravity field: osculating orbit, mean orbit and so on... and the vAGC doesn't use the same than orbit MFD at all!

2/ Orbiter and thus NASSP uses only one earth radius. In NASSP the radius value is the one at the KSC latitude. I think ther is a common mistake for many people:
The earth radius is used in two sorts of computations:
 a) The J2 perturbation effect
 b) The vessel height by making the difference between the radius from center of the earth to the vessel position and the reference earth radius.

What does the vAGC?
- In a), it uses the equatorial earth radius (6 378 165.00 meters)
- and in b) it uses the KSC earth radius (6 373 338.00 meters). You see that the 2 values are not the same.
What does orbiter?
Since I suspect it knows only one radius, the one which is set in the earth config file, it should use the KSC earth radius (6 373 338.00 meters) for both a) and b).
That probably explains why the sim does not follow the same perturbated orbit that the vAGC expect.
Since the J2 has not the same effect, the error should grow with time, and that's exactly what you've noticed.

Since it's more easy to change the vAGC than the orbiter code, may be we could try to change the mean equatorial earth radius into the vAGC memory?


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 29, 2008, 05:58:08 AM
In my point of view the problem is that if you do many SV updates within a short period of time (a couple of minutes), the Ap/Pe shown by V82 varies too much.

For example if I do no SV Update and observe V82 and OrbitMFD (or PAMFD), both values are different because of the reasons you pointed out, but within a couple of minutes both values vary only within a range of < +/- 1nmi.

If I do a couple of SV Updates in the same period of time, the values shown by V82 vary within a range of +/- 10 nmi each update as BlueDragon8144 already mentioned before, which is at least something I don't expect to happen.

As I'm mainly working on the ECS and didn't take a close look at that, I'm not sure why this happens and if this is an issue at all, at a first glance it looks like this is caused by the uploaded SV data, but perhaps BlueDragon8144 or irnenginer can enlight us here...  :)

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: Christophe on August 29, 2008, 07:52:33 AM
If I do a couple of SV Updates in the same period of time, the values shown by V82 vary within a range of +/- 10 nmi each update as BlueDragon8144 already mentioned before, which is at least something I don't expect to happen.

Does this issue occur only with auto SV update MFD or even with manual CMC update using the excel spreadsheet?

By reading the previous posts in this thread I suspect an error with the exact GET for update. All the SV digits must be picked up at exactly the same time. Only a few hundredth of sec delay may mess the AGC up.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 29, 2008, 08:15:44 AM
Does this issue occur only with auto SV update MFD or even with manual CMC update using the excel spreadsheet?

I only tested the Auto SV Update.


Title: Re: Auto vAGC State Vector Update
Post by: Christophe on August 29, 2008, 10:26:10 AM
Ok I'm too busy to check the SV update right now but I read again some post above on this thread. I'm pretty sure the issue is from the way the MFD takes the datas. The SV must be the one for a specific time. No matter the time it takes to upload it into the memory. Isn't it possible to pick up the datas just like the scn editor does, in a frozen instant?


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on August 29, 2008, 10:56:07 AM
Isn't it possible to pick up the datas just like the scn editor does, in a frozen instant?

This is what we're doing already, i.e. to pick up all the data including time in one time step, but a comparison with the Excel/Scn Editor version would be interesting as there might be small differences between the two ways.

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on September 09, 2008, 01:02:53 PM
As it looks like nobody is really working on this problem, I took a look the last days. I found 2 bugs in the latest version, the bigger one is that oapiGetPlanetObliquity gets the planet handle as argument (not the name) and the result is in rad, not deg. The smaller one was the use of abs() with the mission time instead of fabs(), which rounded the mission time to the next second. I fixed both bugs in CVS, testers please do a CVS update, the SV before these fixes was way off.

After that's I did more tests, now using P21 (geographic position) and P47 together with N62 to get inertial velocity, local vertical velocity and height. I also did tests with re-uploading the same SV several times within a couple of minutes to check for problems with the upload itself and consistancy within the AGC. As far as I can tell, it looks like the upload itself is working fine, also the AGC gives the same results with the same state vector, but the calculated state vector in the MFD seems to be off up to about 10km in position, the error varies each upload, I still have no clue why.

To avoid duplicate work I would like to ask if someone else is looking at that problem right now, also it would be great if someone of the AGC experts around here can take a look at ProjectApolloMFD::GetStateVector() as I don't know if the calculations there are correct. If nobody else is going to look at that, I'll try harder to get this fixed...  :)

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on September 11, 2008, 11:09:16 AM
I managed to have a few minutes last night to take a look at this finally. The math in GetStateVector looks good but I will study it some more. C++ does a horrible job at math so it is a bit hard to figure out whats going on. The resultant state vector of an update also looks good, to be honest I think we are on the money.

I think I can explain why you see a 10km offset. There is still some inaccuracy in the AGC padloads that determine the translation between the "Basic Reference Coordinate System" (ie state vectors) and the "Earth Fixed Coordinate System" (ie surface coordinates).  There are 3 parameters for this AZO, -AYO, and AXO. There may also be some difference in the coordinate systems that orbiter uses vs that of the AGC. The total error is in the area of 10s of km.



Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on September 11, 2008, 12:10:09 PM
The math in GetStateVector() was taken straight from the excel sheet for manual state vector update, which is why I asked to see if the excel sheet got the same results to see if it was an error in my programming. 


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on September 12, 2008, 12:18:54 PM
Finally got around to doing some testing, so I did both manual and state updates using the same data, give or take a few milliseconds.  What I did was start up a Auto SV update, but pause at just as the data starts coming in, so as I can input the date and state vectors in to the cmc update excel sheet.  Then, I unpause, let it go, and enter in V82 to get the orbit parameters.  After that, I did the same thing using the excel sheet numbers.  Then I repeated it 5 more times.

                MFD               Auto             Manual
Test 1   153.7x124.5   155.8x128.6   156.6x127.2
Test 2   154.5x124.6   164.5x130.8   165.2x129.7
Test 3   155.5x124.5   168.3x125.1   168.2x124.2
Test 4   156.5x124.1   174.2x137.6   174.4x137.0
Test 5   157.4x123.7   149.2x117.0   149.5x116.4
Test 6    158.7x122.8   167.7x127.4   168.4x127.2

Just something I was looking for when i didn't have excel.  But it looks like the upload is fine.  It's just either the math or the agc portion thats causing the errors.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on September 12, 2008, 07:02:48 PM
Thanks for the replies, I think I found it, there seems to be a bug in the conversion of negative numbers to the octal values, I'll do more tests and will post later...

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on September 12, 2008, 08:38:04 PM
To clarify, when converting negative decimal numbers to octal for the agc, would you do this?

Code:
|-0.530688379*2^14| = 8695
8695 to binary = 0b 010 000 111 110 111
invert =         0b 101 111 000 001 000
bin to oct =     0o  5   7   0   1   0


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on September 13, 2008, 05:00:25 AM
Found the problem.  Wasn't an error in converting from decimal to octal.  The problem actually stemmed from the excel sheet.  I was using values from Fabrizio Bernardini and Christian Bucher's SV analysis and found numbers that just did not match up.  The high components were spot on, but it was the low components that had a problem, specifically low components of negative values, and I traced it to the fmod routine, and fiddled around to see if I could find the error, which I did find one.

The equation is not -fmod(value, 2^-14), but it is actually
-fmod(-value, 2^-14), or -fmod(abs(value), 2^-14)

That resulted on numbers that were spot on with the SV analysis, and once in orbiter, I did 5 tests, and the parameters matched with an error of +/-0.1km.

I've commited the changes, as well as the excel changes.


 


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on September 13, 2008, 07:27:22 PM
Yeah, that does the trick, works pretty well, for my part it's fine now!  :ThumbsUp432:  :ThumbsUp432:  :ThumbsUp432:

I got your changes of the excels with the CVS update, but not of the code, could you check that?

There are 3 parameters for this AZO, -AYO, and AXO.

While we are talking about that, AXO and AYO is Earth precision and nutation and as far as I know Orbiter doesn't simulate that, should we use 0 for both (I didn't try that yet)? Do we need new pad loads for the position of the Moon and the Sun in this case (Sun pad loads for Apollo 7 are still missing, it would be great if you can take a look at that if you have some time left  :) ) ?

Sorry to bothering you with all these questions, but I'd like to have a "baseline configuration" for that stuff for Apollo 7 rather soon as I hope we can begin with flight tests for the release soon (the Earth orbit at insertion and the S-IVB on orbit still needs fixing though).

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on September 13, 2008, 07:48:21 PM
Sorry, I guess it didn't go through for some reason. :awwcrap4253:
It's now up on CVS. 


Title: Re: Auto vAGC State Vector Update
Post by: irnenginer on September 14, 2008, 10:40:06 PM
While we are talking about that, AXO and AYO is Earth precision and nutation and as far as I know Orbiter doesn't simulate that, should we use 0 for both (I didn't try that yet)? Do we need new pad loads for the position of the Moon and the Sun in this case (Sun pad loads for Apollo 7 are still missing, it would be great if you can take a look at that if you have some time left  :) ) ?

Sorry to bothering you with all these questions, but I'd like to have a "baseline configuration" for that stuff for Apollo 7 rather soon as I hope we can begin with flight tests for the release soon (the Earth orbit at insertion and the S-IVB on orbit still needs fixing though).

I am not sure if they should be zero or not. while they may not be modeled in orbiter the reference will be different from 1968 so I would assume it will need something in here so it works out. These parameters only deal with earth tilt variation so it only impacts the accuracy of the translation between state vectors and earth referenced surface coordinates and vise versa. Operationally the only impact is using P21, P22 and at liftoff to determine the initial state vectors.  I will work on it.

I feel bad about the negative number thing. I saw that bug six months ago and had fixed it in a new spreadsheet version but had held onto it while I was looking into TVC DAP issues (which still exists) and then got sidetracked with some life stuff and summer. With summer falling behind us I think I can be more int the game and not leave you guys hanging. The spreadsheet also includes Sun Data for Apollo 7.  I will post a thread that will discuss all the remaining vAGC issues I am aware of.


Title: Re: Auto vAGC State Vector Update
Post by: Tschachim on September 15, 2008, 04:57:30 PM
It's now up on CVS. 

Thanks, the changes arrived well. I also committed two more cosmetical changes, the telemetry checklist in the MFD is now formatted like the Checklist MFD and I removed the mission specific "CMC Update" excels and added the Apollo 7 & 8 values to the generic one, with Apollo 7 as default values for easier maintenance, I hope this is fine for all.

irnenginer, don't feel bad too much, at least we guys learned more about the AGC.  :)

I did some tests with P21 and AXO=AYO=0, but I don't see any substancial improvements (always about +/- 0.1), so I think it's up to you. Also please don't worry too much about getting everything ready like TVC for example, every small improvement is important in my point of view, so I'd be happy if you commit what you have and we improve it step by step.

Cheers
Tschachim


Title: Re: Auto vAGC State Vector Update
Post by: bluespace88 on September 15, 2008, 06:09:01 PM
yeah, don't feel bad about it.  We did learn more about the AGC and the math behind it :)

the changes are fine with me.  It's better to have it all in one file rather than have multiple, especially if only the launch date changed.

Also, wondering, what else needs to be done before releasing 7.0?  I'd like to work on some more stuff.


Title: Re: Auto vAGC State Vector Update
Post by: Christophe on September 21, 2008, 12:00:48 PM
So congratulations BlueDragon8144 for having fixed that error!  :ThumbsUp432:

Great job! :wink: