Meadville Space Center Forum Index Meadville Space Center
Know the future through the past
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Virtual AGC
Goto page Previous  1, 2, 3, 4 ... 16, 17, 18  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Meadville Space Center Forum Index -> Programming
View previous topic :: View next topic  
Author Message
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Fri Aug 19, 2005 2:53 pm    Post subject: Reply with quote

Quote:
Movieman, if you really want to have that in, we should perhaps do a scenario file flag for that?


If we don't, then we need some way of guaranteeing to limit time acceleration to 100x or 10x (not sure how fast the average PC can run the Virtual AGC code).

Otherwise we'll be totally hosed if someone turns the time acceleration up too high and is suddenly trying to simulate 100,000,000 clocks per timestep.
Back to top
View user's profile Send private message
Tschachim



Joined: 26 Nov 2004
Posts: 1272

PostPosted: Fri Aug 19, 2005 3:00 pm    Post subject: Reply with quote

Limiting time acceleration is a very good idea in my opinion, it's limited to 10x during launch anyway. I can run it with 10x without problems (but it's less accurate then), 100x is not possible.
I believe the AGC is slower cycled during standby, perhaps this gaves us the possibility of higher time accelerations during coasting, but nobody figured out standby in the Virtual AGC as far as I know, it's only an idea for the future...

Cheers
Tschachim
Back to top
View user's profile Send private message Send e-mail Visit poster's website
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Fri Aug 19, 2005 3:03 pm    Post subject: Reply with quote

There is some documentation on standby mode: AFAIR the AGC wakes up once a second and updates the clock.

That's the other option if we limit the cycle count: we can just poke the clock counter values directly into erasable memory to keep it in sync with Orbiter.
Back to top
View user's profile Send private message
Tschachim



Joined: 26 Nov 2004
Posts: 1272

PostPosted: Fri Aug 19, 2005 3:16 pm    Post subject: Reply with quote

movieman wrote:
we can just poke the clock counter values directly into erasable memory to keep it in sync with Orbiter.

... but then we have to poke the results of the average g calculations (for example) into erasable memory, too... Wink
Back to top
View user's profile Send private message Send e-mail Visit poster's website
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Tue Aug 23, 2005 12:07 am    Post subject: Reply with quote

Turns out we're not calling any functions in agc_utilities.c, and we have to comment out all the socket code in there on every update, so I've removed the file from the build.
Back to top
View user's profile Send private message
x15



Joined: 12 Jul 2005
Posts: 63

PostPosted: Tue Aug 23, 2005 8:14 am    Post subject: Reply with quote

Movieman

Actually I am using those functions because I added the possibility (Conditionnally #defined) to run with the original external yaAGC and using sockets.

Not that I don't like your AGC integration (it is great Very Happy ) but
sockets are very convenient for debugging purpose (that's how I traced the EDRUPT problem) because yaGAC is now an integrated source level debugger


So, if you're OK I'd like you to reinstate agc_utilities in the project

I think you had compilation problems because Ron is using Winsock2.h include file in the yaAGC.h and this is not correct
he should use winsock.h (which is compatible with all versions)


I'll tell him to change that and of course you've got to add the WSOCK32.lib library to the link list

I've got all this sorted out and my planning is to commit all this by next monday (i'm on vacation this week)

BTW, I am activating the LEM computer step by step and saw that initialization of certain channel bits are done in the apolloguidance class(such as the AGCwarning bit channel 33).

As some bits are computer dependant (CSM or LEM), those should be located in the CSMComputer or LemComputer class init, am I right ?


Thanks

x15
LazyLunarModuleDevtTeam's apprentice member
Back to top
View user's profile Send private message
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Tue Aug 23, 2005 10:27 am    Post subject: Reply with quote

Sure, if you can get it to work. I just don't want to have to keep editing lots of files every time we update to a new version.
Back to top
View user's profile Send private message
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Tue Aug 23, 2005 2:48 pm    Post subject: Reply with quote

BTW, I think we should change the erasable memory state saving in the scenario files to use octal addresses rather than decimal addresses, just so it's easier to preload data into the erasable memory before launch, as the addresses will match those in the AGC documentation.

That will obviously invalidate old scenario files which have saved state in them. I guess in the short term I can increase the version number by one and read it as decimal if the scenario is from an old version.
Back to top
View user's profile Send private message
LazyD



Joined: 10 May 2005
Posts: 406

PostPosted: Thu Aug 25, 2005 7:36 pm    Post subject: Reply with quote

movieman - what is the status of the EMEM's now? I notice that they are saved in a different format, and the information I used to get from them all comes up zeros (LandingLatitude, LandingLongitude and ApolloNo). The code in LEMcomputer that saves and restores these seems not to have changed - should it have?

D.
Back to top
View user's profile Send private message Send e-mail
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Thu Aug 25, 2005 8:10 pm    Post subject: Reply with quote

They're in octal now. We have erasable memory load data for at least one LEM, so it will be a lot easier to enter if they're octal in the scenario rather than decimal...
Back to top
View user's profile Send private message
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Thu Aug 25, 2005 8:17 pm    Post subject: Reply with quote

Incidentally, it wouldn't be hard to put in a conditional compilation option to dump them out in decimal if you have to: there should just be a few %o in apolloguidance.cpp which would need to be changed to %d.
Back to top
View user's profile Send private message
LazyD



Joined: 10 May 2005
Posts: 406

PostPosted: Thu Aug 25, 2005 9:33 pm    Post subject: Reply with quote

OK - it looks like the EMEM address AND the contents are octal now. I'll try and convert my latitude and longitude to octal. Also I was using EMEM (octal) 113 and 114 for a lat/long extension to get more precision - they seem to be getting saved with the same value as in EMEM0111 now.

If I need to use different EMEM addresses for compatibility with yaAGC, this is a good time to change, since old landing scenarios are broken anyway. I just need four locations for lat & lon, and one for landing site altitude.

D.
Back to top
View user's profile Send private message Send e-mail
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Thu Aug 25, 2005 9:39 pm    Post subject: Reply with quote

Maybe the best solution would be to use decimal for the C++ AGC and octal for the Virtual AGC? Or would that be too confusing Smile ?
Back to top
View user's profile Send private message
LazyD



Joined: 10 May 2005
Posts: 406

PostPosted: Thu Aug 25, 2005 11:51 pm    Post subject: Reply with quote

I think it would be confusing - easier for me to convert to octal. After all, we are trying to ACT like the AGC did.

In my opinion, the C++ stuff should try to act as real as possible, whenever we learn what real was. I'm happy to change my code, anyway.

D.
Back to top
View user's profile Send private message Send e-mail
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Thu Aug 25, 2005 11:54 pm    Post subject: Reply with quote

Actually, I need to play with the Virtual AGC at some point and figure out how the erasable memory editing functionality worked so we can duplicate it. That was the original idea between implementing it that way, so you could manually change internal program state from the DSKY.
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Meadville Space Center Forum Index -> Programming All times are GMT
Goto page Previous  1, 2, 3, 4 ... 16, 17, 18  Next
Page 3 of 18

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group