SSU V1.25 Release

[SiameseCat]

The RMS attachment is currently created first, so if we added the foot restraint attach at the same time, we'd mess up the other attachment indexes. The other option is to have two separate functions in the RMS class; one would create the EE attachment and the other would create the foot restraint attachment.

 

[Urwumpe]

The RMS attachment is currently created first, so if we added the foot restraint attach at the same time, we'd mess up the other attachment indexes. The other option is to have two separate functions in the RMS class; one would create the EE attachment and the other would create the foot restraint attachment.

How many payloads do we already have? I think adding one is still possible, but I am ready to take complaints.

 

[Donamy]

I think one or the other would be fine.

 

[SiameseCat]

I think SSU currently creates a total of 20 attachments. Once we get the mission definition files working, it should be possible to adjust the number of PLBD attachments created based on the mission file.

 

[Urwumpe]

I think SSU currently creates a total of 20 attachments. Once we get the mission definition files working, it should be possible to adjust the number of PLBD attachments created based on the mission file.

Not the number, only the z-position. The number will stay constant, as well as the general orientations. This makes coding as well as scenario definition easier.

 

[Donamy]

STS-88 used a tunnel adapter, between the forward bulkhead and the airlock. Is there a way to do this with SSU ?

 

[Urwumpe]

STS-88 used a tunnel adapter, between the forward bulkhead and the airlock. Is there a way to do this with SSU ?

No... not yet. We would need some modifications to the ODS to realize such a system.

 

[Donamy]

Maybe that could be looked at while the STS-88 payloads are finnished.

 

[Urwumpe]

Maybe that could be looked at while the STS-88 payloads are finnished.

Yes. I also abuse Poscik's real time mission with SSU for getting some feedback on possible bugs. For example our GNC202 software has a problem with off plane burns it seems.

 

[DaveS]

Yes. I also abuse Poscik's real time mission with SSU for getting some feedback on possible bugs. For example our GNC202 software has a problem with off plane burns it seems.

I guess you tried to do the SIMPLEX burn?

 

[Urwumpe]

I guess you tried to do the SIMPLEX burn?

SIMPLEX?

Was a simple PEG7 input.

 

[DaveS]

SIMPLEX?

http://www.nasa.gov/mission_pages/station/science/experiments/SIMPLEX.html

Was done on this mission as well.

---------- Post added at 07:01 AM ---------- Previous post was at 04:49 AM ----------

Seems like our MET/GMT displays are not working properly.

I have tried setting up a good STS-119 pre-de-orbit burn scenario with accurate MET and GMT time data. But I cannot get the MET/GMT displays to display the proper times.

According to my calculations setting the MET parameter to 1088821 in the scenario should yield an MET of 012/14:27:01. My scenario starts at a GMT of 087:14:10:45 which is March 28 2009 14:10:45 GMT.

But the GMT displays is off by exactly one day and the MET shows 001/04:09:23!

Very, very off! I have checked in the scenario for troubleshooting.

 

[Poscik]

I guess you tried to do the SIMPLEX burn?

Daves:
When you set vY value to +10 for example, and you push ITEM27, attitude is wrong. Now I have to use LVLH to maintain correct. Calculated data in GNC202 for pitch, yaw and roll looking good, but...

 

[Urwumpe]

According to my calculations setting the MET parameter to 1088821 in the scenario should yield an MET of 012/14:27:01. My scenario starts at a GMT of 087:14:10:45 which is March 28 2009 14:10:45 GMT.

But the GMT displays is off by exactly one day and the MET shows 001/04:09:23!

Very, very off! I have checked in the scenario for troubleshooting.

Can confirm the first...I implemented an alternative function to calculate GMT and compared both results. The old code is exactly one day more than the alternative. I also found the reason: 1970 is no leap year.

Not sure on the MET display, will research this.

 

[DaveS]

Can confirm the first...I implemented an alternative function to calculate GMT and compared both results. The old code is exactly one day more than the alternative. I also found the reason: 1970 is no leap year.

Not sure on the MET display, will research this.

OK, thanks for the confirmation that the GMT is off. Found the reason why the MET was off: I was modifying the wrong parameter. It seems like the parameter MET is no longer used. Instead the parameters MTU_MET* is the ones used now.

 

[Urwumpe]

It seems like the parameter MET is no longer used. Instead the parameters MTU_MET* is the ones used now.

Yes, but possible that the GPC displays use the MET parameter.

 

[DaveS]

Yes, but possible that the GPC displays use the MET parameter.

In this case, that should be a priority fix.

 

[Urwumpe]

In this case, that should be a priority fix.

Well, actually, we just lack the MTU SOP in the GPC code. :lol:

 

[SiameseCat]

The GPC displays currently use the MET parameter. I'm currently working on the MM 202 bug; I should be able to check a fix in sometime today.

 

[Urwumpe]

GMT calculation is fixed and the slower alternative function disabled... it is not like we need to optimize for speed there, but the other code is better.