Meadville Space Center
Welcome, Guest. Please login or register.
July 11, 2020, 10:25:08 PM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
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)
| | | |-+  Things that need doing?
« previous next »
Pages: [1] 2 Print
Author Topic: Things that need doing?  (Read 8399 times)
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« on: December 01, 2008, 01:51:12 PM »

Does anyone have a list of things that need doing before we can have a proper release? I've been busy for the last couple of months but if there's something I can tackle I'll try to take a look soon.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #1 on: December 01, 2008, 03:37:49 PM »

The whole project is not currently progressing, to say the least... Worried
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #2 on: December 02, 2008, 06:28:48 AM »

Yes, it's rather slow lately. I'm still working on the ECS and EPS stuff, if Lassombra won't "reappear", I'm going to finish the Checklist MFD after that's probably.

Movieman, as you were working on the Saturns often, this is a rather big point desperately needed for an Apollo 7 release: The Saturn IB launch autopilot needs to be fixed to achieve the correct orbit in terms of inclination and LAN, and the S-IVB "on orbit autopilot" (basically there's almost no such thing right now) should control the venting and attitude (and everything else the real thing did I'm not aware of), so that the orbit at CSM/LV separation and after that's is by the numbers, too. Would that be interesting for you?

Cheers
Tschachim
« Last Edit: December 02, 2008, 06:51:05 AM by Tschachim » Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #3 on: December 03, 2008, 09:53:51 AM »

I can try, but I've never been much good with code that requires pointing things in the right direction Happy.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #4 on: December 03, 2008, 10:38:32 AM »

...I've never been much good with code that requires pointing things in the right direction Happy.

 Very Happy

Well, there are some issues with the Virtual AGC, mainly the TVC problem, explained here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1825.0, but irnenginer and BlueDragon8144 are already working on that. I'm going to do the remaining ECS and EPS stuff for release, there isn't much left so I don't think I need much help here. So in my point of view the Saturn IB and the S-IVB are really important, especially since we want to fly Apollo 7 by the numbers and the currently wrong orbits at insertion and even more at CSM/LV separation are a big showstopper, so it would be very cool if you can take a look at that...  Happy

Cheers
Tschachim
Logged

dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #5 on: December 03, 2008, 11:04:38 AM »

Just make sure not to break the SV, I'm already working at that.

IGM is actually getting closer to working, too. I'm getting valid burn times out of it, but garbage angles. Turns out I'm doing navigation wrong. After almost two years, there's light at the end of the tunnel ^_^

Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #6 on: December 03, 2008, 11:11:20 AM »

Just make sure not to break the SV, I'm already working at that.

The "LVDC++"? I was talking about fixing that in the "old" autopilot, but...

IGM is actually getting closer to working, too. I'm getting valid burn times out of it, but garbage angles. Turns out I'm doing navigation wrong. After almost two years, there's light at the end of the tunnel ^_^

... that are great news, if the LVDC++ is working fine and with the Saturn IB, too, it would be the better solution, of course.

Cheers
Tschachim
Logged

dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #7 on: December 03, 2008, 12:27:16 PM »

Right now I'm only concerned with the Saturn V and Apollo 8. The S1B used a different FCC and different LVDC software, so I am not sure how much of this will apply. My plan is to make Apollo 8 work, then dump everything verbatim into a S1B and see what breaks.

Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #8 on: December 03, 2008, 01:08:44 PM »

In that case I'll leave it as is Happy. I'll see if I can figure anything out about the SIVB autopilot in orbit.

I also still have some telemetry to finish off, I was sent to Europe for work for a while when I was in the middle of doing that.

Actually, one thing I was thinking of doing was investigating telemetry recording and playback; we should be able to just save the telemetry stream on a virutal 'tape recorder' but I'm not quite sure how that worked on a real Apollo.
« Last Edit: December 03, 2008, 01:12:26 PM by movieman » Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #9 on: December 03, 2008, 05:06:59 PM »

Well, don't wait for me to get this right, if you're going to work on the S1B, go ahead and do it. I'm not claiming I'll be finished with LVDC++ anytime soon. It would be nice, but I am expecting I will run into more problems after solving navigation. I don't want to hold up the Apollo 7 release. I just wanted to say I was still working on the SV and Apollo 8, and I didn't want to conflict.


Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #10 on: December 03, 2008, 10:50:23 PM »

So anyway, I tracked down some information on the data recorder in the CSM. As far as I can make out:

27000 inches of tape
playback 120 inches per second (3.75 minutes to downlink an entire tape)
ffwd/rewind 120 inches per second
high-speed is 15 inches per second (6400 bytes per second)
low-speed is 3.75 inches per second (200 bytes per second)

So that's pretty easy to simulate, though we'd need a modified telemetry client which could record the downlinked data and convert it into a useful format (e.g. save to a raw disk file or dump out in a suitable format for some graph-generation software). I was going to store the data in 1.5inch chunks since that comes to round numbers in both data rates (160 bytes for HBR and 80 bytes for LBR).

The downside is that potentially the tape can hold 11MB of data, so if we save non-zero sections of tape to the scenario file as hex we could end up with a 22MB scenario file when the tape is full Happy. There doesn't seem to be any way to erase it other than by overwriting. Of course if people don't turn the tape on then they won't have any data to save, so it only matters for people who actually use it.

I've no idea how big a scenario file Orbiter can cope with.
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #11 on: December 03, 2008, 11:18:53 PM »

Since we're probably going to be the only people using it, just make it write to a binary file outside of the scenario file. Put the filename in the scenario file, but not the data itself.
That would make it easier to manipulate outside of orbiter as well.

PS: If you wanted to be really sneaky you could mmap() the file from Orbiter and it wouldn't even cost you RAM. (Wait, does Windows have mmap?)
« Last Edit: December 03, 2008, 11:20:41 PM by dseagrav » Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #12 on: December 03, 2008, 11:32:51 PM »

I thought about that, but then when you delete the scenario file you still have the data file lying around; and if you load an old scenario you lose the recorded data that went with it.

I agree that it would be easier to process from outside Orbiter that way, but we should probably update the telemetry client to be able to record the telemetry into some useful spreadsheet-compatible format anyway; it could then handle recording the downlink of recorded telemetry too. That said, Open Office can only handle 64,000 rows, so we could hit that pretty fast even at 1 value per second.

I've no idea whether Windows uses mmap, actually; but it's compllicated anyway because of the different bits per inch values in the different recording modes; you can't just say 'one inch is 426.666 bytes', because sometimes it's not Happy. I presume that for the real system they'd have rewound the tape before switching between low and high bit-rates, but I'm not certain of that.
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #13 on: December 03, 2008, 11:37:53 PM »

No, you don't have to do that at all. The datastream has framing and sync data every frame, so the client can parse the datastream and determine how and where on the tape what was recorded.
Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #14 on: December 04, 2008, 12:16:19 AM »

Actually, I think you're right about saving it to a file: we could use a different file each time you save the scenario, so you could just delete old ones when you want to free up some disk space, effectively 'erasing' the tape. If you haven't recorded anything then no file would be written as the tape will be blank. That would be half the size and potentially we could use zlib or similar to compress it too.

We should probably split out the telemetry decoding from the client into a generic library so that any program can do it; then we could just read the recorded stream and dump it to a suitable file format for a spreadsheet. That's at most two hours long, so it could handle about eight samples a second in LBR and more in HBR.
Logged
Pages: [1] 2 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!