News The code that took America to the moon was just published to GitHub

[GLS]

Two interesting reads related to this software:
http://www.doneyles.com/LM/Tales.html (from the author of the famous BURNBABY routine)
https://www.hq.nasa.gov/alsj/a14/a14AbortDiscrete.html

 

[Messierhunter]

Not sure if he is here. It's Hitman57 on the French Orbiter forum (http://orbiter.dansteph.com/forum) and Hitman458 on the Meadville Space Center forum.

I know he had to change some things in NASSP, because this isn't natively supported. Mostly he had to revert some changes about the Virtual AGC implementation. Maybe the relevant thread is helpful to you: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2889

Awesome, thanks. I still have a lot to learn about it, but I'd love to have a physical DSKY pad.

 

[indy91]

Two interesting reads related to this software:
http://www.doneyles.com/LM/Tales.html (from the author of the famous BURNBABY routine)
https://www.hq.nasa.gov/alsj/a14/a14AbortDiscrete.html

The first link has an interesting bug in Program 66 of the LM. It will be interesting to see if it will cause any problems in NASSP, when we finally begin working on that.

Something I haven't seen any article about is an issue with the Apollo 8 AGC. Not too long before the launch of Apollo 8 the decision was made to change the reentry profile slighty. Instead of nominally -6.26° flight path angle at entry interface -6.48° was then to be used. This decision came too late to change the AGC. With the core rope memory development of the AGC version for a specific flight had to be frozen early, months before launch.

Now, the AGC has a program called "Return to Earth Program", P37. In the case that communications are lost with the ground, this program can be used to calculate a midcourse correction for the return to Earth onboard, with the help of onboard navigation. Unfortunately this program indirectly imposes a "speed limit" for the reentry trajectory, which was based on the former maximum major axis of the return orbit. But with the steeper reentry profile, the program on a nominal trans-Earth trajectory now sometimes runs into this constraint and tries to slow the spacecraft down, even if the spacecraft is already on a perfect trajectory headed to the center of the entry corridor.

We stumbled upon this problem when we started using a Moon-To-Earth trajectory very close to the one used by Apollo 8. Instead of a close to 0 ft/s midcourse correction that should have been the result of the P37 iteration, the AGC wanted to burn 50 ft/s radially upwards. This will take the spacecraft far from the planned splashdown coordinates. At first we couldn't explain this problem.

Then we began reading the Apollo 8 transcripts and found that sometimes the astronauts and CAPCOM were talking about a "high speed procedure". I tracked down the fixed constant that caused the issue and slowly began to understand why it had an undesirable value. But I wasn't quite sure how they bypassed the fixed constant during the flight. I then contaced the editor of the Apollo Flight Journal, David Woods, who kindly provided me with a PDF of the Apollo 8 CMP Checklist.

So in the case of an emergency, if Program 37 had to be used in the "No-Comm" case, Jim Lovell would have to change a few variables in the erasable memory to overwrite the limiting constraint, while Program 37 is already running. We tried this procedure with the Virtual AGC in NASSP and it immediately calculated the desired trajectory! The CMP Checklist was changed rather last minute to incorporate this high speed procedure and the AGC really only barely ran into the constraint, on some high speed return trajectories.

This is really more an annoying problem than a dangerous one, but it was interesting to find such an issue with the AGC. By the way, it was of course fixed for Apollo 10.

 

[kuddel]

My personal (guess why) favourite Apollo hardware building project though is a DSKY, that directly connects with the Virtual AGC in NASSP

..done that
Started back in 2012 with the DSKY. Based on an arduino board that connects via USB to the PC running NASSP.
NASSP code needed only two changes to read / write channels 011 / 015 through USB.
It's kind of fun to "really" punch in all the verbs and nouns, but progress is very slow 'cause I have too many hobbies

The first two are from way back, when I did not yet found proper 'sign' 7-segment displays in green. You see it running NASSP :thumbup:
The other two are the current state (now with box! and sign-segment based on old GDR displays)

Sorry for the image quality, I am not that good at marketing

 

[Ravenous]

I love those DSKY pictures! Every office should have one!

There's a photo of a DSKY in an unusual place in Tomayko's book on digital fly-by-wire (early 70s). I'm sure it'll be online somewhere. Their old F-8 was first modified with an AGC (Neil Armstrong apparently knew of an unused one and recommended it to them.) There's a photo of the F-8 with the weapons bay open, and the big calculator keypad clearly visible in there! (Ground technicians would start up the appropriate program before flights started.)

Edit: here it is:

 

[Capt_hensley]

Ahhhh.. an Armchair Expert talks sense once again :thumbup:

I am an electronics technician, and Airframe Repair Specialist, so some knowledge was applied to the comment, but yes Armchair Expert, because I'm stuck in a wheel chair permanently.rly:

I'm glad everyone understands, it takes real expertise to design simulated hardware that can provide feedback for testing purposes, I used to do that sort of thing, Now I play with WARSIM

 

[Urwumpe]

I am an electronics technician, and Airframe Repair Specialist, so some knowledge was applied to the comment, but yes Armchair Expert, because I'm stuck in a wheel chair permanently.rly:

So you are clearly a wheelchair expert like Charles Xavier.

 

[Messierhunter]

..done that
Started back in 2012 with the DSKY. Based on an arduino board that connects via USB to the PC running NASSP.
NASSP code needed only two changes to read / write channels 011 / 015 through USB.
It's kind of fun to "really" punch in all the verbs and nouns, but progress is very slow 'cause I have too many hobbies

The first two are from way back, when I did not yet found proper 'sign' 7-segment displays in green. You see it running NASSP :thumbup:
The other two are the current state (now with box! and sign-segment based on old GDR displays)

Sorry for the image quality, I am not that good at marketing

That's awesome, and pretty much exactly what I'd like to make myself. Can you make or do you have a walkthrough of how you made it? And what exactly did you change in the NASSP source code to make it work? I'd love to build one for myself.

 

[Capt_hensley]

So you are clearly a wheelchair expert like Charles Xavier.

Minus that whole telepathy thing, but close...:lol:

 

[Col_Klonk]

I am an electronics technician, and Airframe Repair Specialist, so some knowledge was applied to the comment, but yes Armchair Expert, because I'm stuck in a wheel chair permanently.rly:

I'm glad everyone understands, it takes real expertise to design simulated hardware that can provide feedback for testing purposes, I used to do that sort of thing, Now I play with

Having a similar background in some respects, I recognised the sensible logic in your previous comment, and humuorously applied a phrase that some derogatorily directed to myself, not realising that you run on wheels :thumbup:
It was meant as a dig at those know-it-alls

 

[Capt_hensley]

Having a similar background in some respects, I recognised the sensible logic in your previous comment, and humuorously applied a phrase that some derogatorily directed to myself, not realising that you run on wheels :thumbup:
It was meant as a dig at those know-it-alls

Thanks... I can appreciate the humor in it. I do lots of self deprecating humor, it must be a right crowd thing along with lost non-verbal gestures and body language.

 

[GLS]

Not a lot of technical talk, but still a very interesting documentary about the AGC.

 

[kuddel]

That's awesome, and pretty much exactly what I'd like to make myself. Can you make or do you have a walkthrough of how you made it? And what exactly did you change in the NASSP source code to make it work? I'd love to build one for myself.

Thanks,
now I have to do what "I like the most" about my projects: Documenting it :lol:

Basic layout is as following:

• One Arduino (Diecimila) board, which I had lying around
• Four MAX7219 (Serially Interfaced, 8-Digit LED Display Drivers)
• 21 Seven segment displays + 3 "Sign" 7Segment displays
• Several LEDs for status lights and "static" lights (NOUN,VERB,PROG)
• One Keyboard controller IC salvaged from an old PS/2 Keyboard
• 19 Keys connected to the Keyboard encoding IC

A general "design rule" was, that the DSKY should *not* need any additional powers supply and can be powered over a standard USB (2.0) port. Currently it draws 375mA max. and about 200 mA avg. (changing the keyboard encoding hardware might reduce the consumptions a far bit lower. Without keboard IC powered it draws 96 mA less!).

All the 7-Segment displays were combined in blocks of 6 7-Segments controlled by one MAX7219 (thus needing four of them). Free outputs of the MAX7219 are used to drive the status lights.
All this is currently done on breadboard (see Attachment), so no PCB layout available, sorry

The four MAX7219s are daisy-chained and connected via the SPI bus to the Arduino.

The keyboard controller (PS/2 connector) is connected to the Arduino board, too.

On the software side the microcontroller code just waits for serial data from the PC-AGC (channel 010, 011 and 013) and encodes them. Those data is transferred via SPI to the MAX7219s.
The second task is to wait for keyboard interrupt and send the transformed message serialized to the PC(-AGC).

Some "special" code was added in some "spare nouns" to control the display intensity.

On the PC side (NASSP) all that is done is to tap the channels 010, 011 and 013 and send that data via a serial port (USB Serial port) and to listen for data on that serial port to be inserted into the keyboard routine.
Basically the same as on the microcontroller but in the opposite direction

I would really like to have more instructions available and I planned to make a PCB layout so that the soldering is much more easy, but I've not found the time for that, sorry.
One thing I started with was a PCB-Layout for one single Register (see 2nd attachment), but that has never seen the light of day now, so it could contain errors.

Last but not least I went to the local polytechnic university and let them mill the frontpanel for me. It's always nice when you have "connections" :lol:
(see 3rd attachment)

 

[amalahama]

Wow this is very sound! Does anybody know if NASA has plans to upload and make available Space Shuttle PASS software? It would be a revolution for SSU (if somebody find out how to program an AP-101 emulator first!)

Regards!