A customer has had a fairly serious problem with stirring the cryogenic tanks with a circuit fault present. To reproduce:
If a wiring fault exists, the issue may be replicated. Be aware that this may be hazardous to the tester attempting it.
i think this issue should be closed because we can't reproduce it
Does it happens only with translunar coast (sol-3-a), or any moon coasting? It may be a problem with the moon. Just trying to narrow down the issue.
Have you tried turning it off and on again?
This is fixed in Apollo 14.
This is a hardware problem. I suggest a wontfix and close.
http://history.nasa.gov/SP-4029/Apollo_13a_Summary.htm
In other words: "What was that gauge reading before you hit the switch?"
@adampats Hey, don't tell me how to fly the CM, all right? They brought me in here to do a job, they asked me to stir the tanks, and I stirred the tanks!
As a temporary solution, you could try gently rolling the CM/LAM to agitate the O2. You may need to do it on the X and Y axis to get optimal agitation.
@SilverWingedSeraph could you provide a screen shot of the error I should expect to see during repro?
Let's work the problem people.
@chrislgarry It looks a little something like this:


Which version of Apollo are you running? I suggest upgrading to Apollo 12
Not specifically for this issue, but maybe we should consider trimming down. I'm pretty sure we can automate this, eliminating both meatbags and O2 tanks from the final implementation.
Have you tried migrating your project to jQuery?
Many bug fixes were addressed in Apollo 18 mission software, until the bugs infected the astronauts.
It works for me
So, I think it might be a hardware issue. Have you tried taking the tanks out and putting them back in again? Maybe that will fix it.
@atpage Savage
We're going to need a label for good first bug, agreed?
@stkrzysiak It's got to be a hardware tag if what @atpage said is true.
@Wazzaps
Have you tried migrating your project to jQuery?
we have tried converting to node. heres a mockup.
Which exactly Universe do you use when face this bug?
Just had this issue happen to me, I took a screenshot.

Did you try uninstalling the drivers then reinstalling them?
Looks like there could be an ID10T error, along with some memory leaks.
Well, can I just update the firmware to fix this issue? Or do I have to take my Apollo to local NASA-spacecraft dealer?
Really frustrating!
This software has reached end of life and is no longer receiving security updates. NASA strongly recommends that you migrate to a supported version. Unfortunately no such version exists at this time.
Ok I'm in a real pickle here, after you experience this issue apparently you can't simply reboot to fix it. Does anyone have a good workaround? Also my CO2 is getting pretty high, please answer quickly this is a production issue for me.
It's not a bug, it's a feature.
Well, I run the unit tests and it says 0 errors...
Did you try SCE to AUX?
Who is the project manager? This change request is getting out of hand. I request a formal review. Let's bring back Waterfall. This is nonsensical that we have to argue whether this is a feature or a bug.
This repo really adds to the legitimacy of Stanley Kubrick's short fictional film "Lunar Landing", starring Neil Armstrong and Buzz Aldrin.
Nice work guys.
This issue made my day. :smiley: You guys are amazing.

Yeah, if we can't solve it, let's think abouta workaround. I believe we should start by collecting all the tools we have.
The Tape with Duct software, Socks proxy and some in-hose tools could help.
Have you tried not breathing? Then having no O2 would make no difference!
Client insists that breathing is a MVP feature. I don't really agree given the development costs but whatever it's their disaster.
Pretty sure this only happens on later versions of the software.
@Xenopoloza Unreasonable. Let them implement that on their own fork.
Your customer's config is wrong.
It works perfectly well in our system. Tell them to freshly install it on a newly installed Ubuntu 14.04 and it should work.
We could probably replace the O2 cryogenic tanks with lightweight containers. Would you consider a PR?
Does this issue result in a crash? Perhaps you forgot to re-register the dll.
Try putting something else in the tanks, then turning it off and back on again.
Compile with -favoid-ions-side-effect.
If you're having this issue, you probably have a more immediate need.
I'd advise calling Houston operational support team as soon as you can once again attempt a transmission.
Why prevent in software that which can be mitigated in hardware? Fix the darn board FFS!
jQuery has a function for this.
Awesome thread!
Seems to be working fine in Ops. Has someone contacted the project manager? I feel there are too many hands on deck and it could be taking time away from Juno.
Documenting as a known issue. Workaround: carry more plants.
As a temporary fix I would suggest moving to the LM to reduce impact on users.
There are no reports of this issue on previous versions. Can someone volunteer to bisect? It should only take a few dozen launches.
You should not use outdated tech. I suggest you migrate your project to SpaceX Dragon. Yes I know it is still in beta, but it is a more modern way to do things.
Works on my machine. Must be an ops problem.
This is by design.
I use this to warm my tea while working on cryogenics. Please don't remove this as I depend on it for warmth. Perhaps a workaround can be established?
This would never have happened on FreeBSD.
Clearly the solution needed is MongoDB. It's web-scale.
Haha, you people are so amusing. Amusingly stupid.
Try running it in a modern browser.
It's an Easter egg. Has anybody tried to run it as Apollo 666?
I think it's solved on last internet explorer, it's bug free.
"not my fault, it was working as expected on my development environment"
I'm looking forward to testing the PR 😉
Dr. Thomas Jeffrey Hanks, from the Nasa, found this bug on '95. according to his official report , he fixed it using @wanted0 's solution. this is a hardware problem, guys, we need to focus.
How to setup a test environment? Please, advice.
I tried setting up automated testing on my fork, but runs are flaky. About 6% fail catastrophically. I'm running out of astronauts.
How to patch KDE2 for FreeBSD?
If you will try a newer version, better avoid 13th, even if your suppliers have bought already some of these.
Try to format Apollo 11 and reinstall everything. That should fix problems generally.
I'm sorry, Dave, I'm afraid I can't do that.
Just don't push the red button and everything will be fine.
Have you considered upgrading the code to TypeScript. It can help catch bugs like these at compile time :rose:
I'm recommend migrate to Fortran. It's wonderful language for engineers. Who use assembly? It' disappeared before eras, like tuberculosis.
Does it happen on Tuesdays ? May be related to https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28
Really, folks? This again? It's an edge case! Hasn't been replicated even once in 47 years.
Even though it WAS an edge case, Houston still found a simple (but not easy) hardware solution.
That's why we paid those folks so much for support! They're Out-of-This-World good at what they do! And we still have them on retainer for future human missions, even though they're just keeping the lights on with robot missions right now.
Their solution to this is _thoroughly_ documented (and Open Source!) (Certain dramatizations are _not_ OS and subject to MPAA harassment.)
No need to get your knickers in a tizzy over this issue, folks -- Mark this bug as closed; I feel confident saying we'll never see it again.
I'll try to look back at it later for edition but for now it is time to listen to some music https://youtu.be/Rr8ljRgcJNM
THX :zap:
i mean <3 represent a life in twitter and if you don't react on facebook or whatever you'll probably do the same error
i mean by :/ here in this issue reaction wtf?
then we can verify by reactions yes with reactJS for example a new issue commented in real time to make some emotional reactions to the users of the system for example
but the most important thing here is that nothing morse has happenned to the pilots
@sump -----> Do it !!!!! emojis are push buttons
for example ask how many buttons we have on the board ? and code them with something else
Are you sure you have the correct permissions? I've run into this in our testing environment and turned out I wasn't stirring the tanks because I didn't have permission.
On IRC, some guy had the same problem and he solved it by using another moon to coast to. So maybe the issue is moon related. AFAIK there aren't any known issues coasting to Phoebe, so I suggest to set for Phoebe and wait if the issue persists.
Lets file a PIL.
There's a simple fix that everyone has overlooked.
Just open a window 🙄
Maybe you're just holding it wrong!
now we'll going to have 1 billion reactions on facebook to command the ship
:-1: is codded by !land every body should now that on the ship its self
wish you a nice continuation :100:
k @dah it should works fine
Guys I found this command on stack overflow
rm -rf
It fixed the issue, haven't heard a beep from the guys at production site since then. 👍
It worked locally...
Apollo 13 is still the best selling bug fix Movie i've seen so far.
What is the current status? We need to update end users...
As a workaround on repro step #3 I suggest a cabin venting by opening the main porthole and or front hatch.
Happened to me - here's a screencast of the occurrence https://www.youtube.com/watch?v=kAmsi05P9Uw
Mmmh...
It's reading a quadruple failure ... That can't happen.
It's got to be instrumentation.
+1
We must fix this issue before the mission-to-mars milestone!
Toughen up guys. We put that training glitch in there for a reason. Keeps you on your toes! Keeps the mission control team on their toes! That's all for now
This is a cross-shuttle compatibility issue. On Спутник we're stirring the shit out of those tanks.
Whatever you do don't try reverting to Apollo Alpha. It uses pure O2 in the cabin and can lead to immediate, and catastrophic, failure.
Should be closed, issue already fixed in hardware, the test is thus not needed if pre-lauch manual tests done correctly.
In the instance mentioned, technician used wrong voltage to test tank heater circuit, thus melting insulation of wiring. Thus leaving bare wires.
The issue of spark discharge when heater and stirer active then would occur only with a part filled tank.
Thus this issue is User Induced and required only user training and proper retesting of production units and flight spares.
For added safety, voltage trip and insulation to heaters added to later units.
Isn't obviou that you need a "sudo chmod -R 777 ." ????
Some trainee's fault.
Alright, we need to get this on the right task board so the engineers can prioritize this sprint. How many story points do you think this task needs?
Tried to begin with step 1, and ran npm install csm.
The CSM package no longer builds, though;
the launch-pad dependency was unpublished from npm.
Just replicating this issue. Can confi—

It worked on my machine
user error
Works on my sister's machine too.
Wait guys I found it. Running on Travis CI now. Should work soon.

@ramriot is right. Closing.
Ran into this bug, too. You can read the logs here: http://apollo13.spacelog.org/02:07:52:58/02:07:56:10/#log-line-201178
This is a classic XY issue, suggesting a fix ("Check continuity...") instead of describing the problem ("O2 tanks exploded during Apollo 13 mission").
Further, I believe that the suggested fix is incorrect, or at least insufficient. The Apollo 13 investigation indicated that a list of factors led to the fan wires in the O2 tanks having damaged insulation. However, unless the wires were already short-circuited before stirring, checking continuity first would not have detected the short. Indeed, the tank was stirred twice earlier in the mission without incident. The investigation suggested that operating the fans itself may have eventually moved the wires into contact with each other, which combined with the damaged insulation, finally allowed an electrical arc and the resulting explosion to occur.
The correct fix is to upgrade the thermostatic switches which protect the tank heaters from overheating to accommodate 65 V DC, so that the fan wiring isn't damaged in the first place. In addition, the tank acceptance procedure should be amended to require switch cycling under load.
I found a jQuery plugin to stir the tanks when a user hovers over the moon.
Clearing the cookies fixed it for me.
Got a call from Jeb.
He said _"Yeah, it exploded. And ?"_
Just install new wireless tanks.
It will definitely require a patch. Do you have a spare rover kicking around? One of my buddies reported using that to load the patch. His was a different platform, but I think the idea is the same:

Are you shure you used the right brand O2 and not a cheap refill ? You might have to clean the nozzles
I heard there was a solar flare today. Could be the issue?
Just use the Kerbal Space Program instead. It's got huge community support that will fix issues like this in days, not decades.
Unable to contact Huston, problem with AE-35 unit. Can we authorize EVA to check up on it?
The Soviet version does not have this problem. I suggest you reinstall the package on Astra Linux.
LMAO!!!
It works for me in node.js
Tried an apt-get upgrade? maybe it is a problem of dependencies of the system.
Found the problem: missing semicolon
INTEGRATION_INITIALIZATION.s#L290
It appears that a directive may have had this effect. +1 for moving to react or jquery rather than angular
This is how it could have been fixed

Relavent xkcd.
I tested it with CodeIgniter and worked well locally. CodeIgniter will keep it warm but I would recommend to use it PHP >= 5.6 with OpCode option on.
You guys realize this spaceship launched in 1969, right? It's many years later now. I don't believe this software is still in use today.
@murac The issue is a joke. And the whole repo is more of historical interest.
@murac it's a joke.
It's not a joke, but the cake is a lie.
@murac The spaceship we are talking about launched April 13, 1970. We're joking about Apollo 13 not 11. Although the fact we have not been back since 1972 makes me unbelievably sad.
It worked here, have you checked your hardware? I'll attach a schematic to help you in the process.

Well, after reading all the great technical advice here in this thread, i'm reminded once again of that old adage - "sure it's rocket science, but we're all rocket scientists!"
Why are you even trying to stir the tanks? This doesn't sound like something you should do with the CM. Just switch your entire mission to a shuttle design, it's more modern and efficient.
Just wanted you all to know that I'm vegetarian...
@piranna another relavent xkcd.
@piranna another relavent xkcd.
Isn't there a relevant xkcd strip for _everything_? ;-)
Could Matt Damon fix this?
This is technically a fatal error. However, due to the heroic efforts of:
@Jim-Lovell
@John-Swigert
@Fred-Haise
and extensive technical support lead by @Gene-Kranz; A crash in production can apparently be avoided.
These are extraordinary people. We can't expect every user to be of this caliber. I suggest this issue be recategorized as mission critical. Even if it is a result of a hardware failure we should improve fault tolerance, and mitigate the impact. Failure is not an option.
Works for me. I guess that you forgot to turn off selinux ;)
Hi guys. I have a similar problem but it's not on a CSM it's a car and instead of the O2 tanks I have fuel tanks. Any help plz email me the solutio!
Works fine on our moon at this end of the galaxy!
Going to ask Chuck Norris for a hot fix, we will deliver it OTA.
Did you tried to reimplement it in delphi?
Ask the flight attendants or beam me up Scotty.
OMG, it is not wroted in PHP!!!
Downloading more RAM fixes this issue.
migrating to ruby and using gem 'apolo-tank-stirrer' fixed it for me. sending a PR shortly.
I tried porting it down to Haskell and it compiles. By the laws of Haskell it should work if it compiles. Verified the same by porting down to Rust too.
I just want it to work..anyone who has a docker image for this?
I think rewriting this to meteorjs will do the trick.
Try running it on the lunar cloud VMs.
Those old lady's forgot to deploy the commit that fixed the bug. I have asked them to re weave it
Have you tried Node.js?
I'd rather go for Eclipse luna with Java 8 from eclipse.org , but as it will be dark because of the eclipse we need additional lights.
BTW I have been in a private conference in 1998 where Jim Lovell talked about leadership. Impressive guy.
Successfully reproduced... I see what you mean, but I'm not sure it's actually a bug. Could this be the intended functionality?

I asked the PM, he said QA approved it, so....
This can easily be resolved with a jQuery plugin.
have you tried to turn it off and on again?
try by not using assembly
I recommend that future astronauts using this software watch this training video in case this happens again in production.
And congrats to @Jim-Lovell, @John-Swigert, @Fred-Haise, @Gene-Kranz, and the many others at NASA and their contractors who managed bring everyone home safely; it was an extraordinary accomplishment.
We should look at other software that NASA has written for solution ideas, such as in HASP for OS/360 on the IBM System/360 running at JSC.
Try deleting the user preference files and rebooting. Someone may have set the cryogenic tanks to 'shaken, not stirred'.
It's a UI problem. The button to stir the tank is too dominant, we should make it a bit smaller and disable it if it is not supposed to be clicked.
sir plz tell me exactly how to do this !!!!!!!!
Try migrating to jQuery 3.0
This is interesting! All the comments here... :D
WARNING: Don't migrate to jQuery 3.0 and try reproducing this issue.

confirming @jaysoffian has a working fix.
Thank you for your report. However, the Colossus software was produced for the AGC, which was responsible for either the navigation of the Command Module or the Lunar Module. The problem you've reported can only occur in the Service Module and has nothing to do with AGC functionality.
Please report your bug in the Service Module project.
Actually, @MadDonArabian and his team were able to reliably reproduce the cause of the problem.
It's a hardware design defect due to miscommunication. A heating safety system on the the cryo assembly spec from North American originally expected 28v DC. NA asked the subcontractor to change to 65v DC, which the did, but failed to inform their subcontractors in turn. In ground operations, the tank got heated higher than its design limit and the safety system fried itself instead of shutting off when it got 65v pushed through it instead of 28v. The overheating cracked open Teflon insulation on wires inside the tank.
The error experienced by the user is due to the wires causing a short, igniting the Teflon, heating the LOX, and causing it to expand and build pressure, eventually causing the explosion. Wontfix is correct. As stated, @MadDonArabian's team reproduced the circumstances of the ground operations on a spare and got the same result. It's a hardware issue.
(See pp451 - 455 of Apollo by C Murray and C Bly Cox, ISBN 0976000806)
@paoloo - the schematic is for the wrong version. You posted 14. The bug is for 11.
My solution is to change the astronauts and and re-write in JavaScript
I can confirm upgrading the hardware to the latest NES Advantage joystick worked for me.

https://www.youtube.com/watch?v=ixhwSg1ezSM
Perhaps you might need to put it back to channel 3 ?
Hi!
Thanks for contacting help desk.
My name is Luke and I am here to help you with your CRYOGENIC TANKS WITH A CIRCUIT FAULT PRESENT ISSUE.
Let's start with what version of CRYOGENIC TANKS WITH A CIRCUIT FAULT PRESENT ISSUE you are using. If version A14, press 1. If greater than A14, press 2.
Great, you selected A14, is that correct? If yes, press 1, if no, press 2.
OK, you have confirmed you are using A14.
Have you checked that the CRYOGENIC TANKS WITH A CIRCUIT FAULT PRESENT ISSUE are charged (green light) and are you using the new lightning charger cables? If not, you can purchase the new cables from our online store and have them shipped to you, just click here if you need them: http:www.wemakeyourlifeharder.com
Now, if after verifying that the CRYOGENIC TANKS WITH A CIRCUIT FAULT PRESENT ISSUE battery indicator is not green, follow these steps:
Please remain on the line for a short survey. This will help us improve our service to you in the future!
Anybody called Tom Hanks,Bill Paxton or Kevin Bacon? I've seen a training video, where they were able to fix that.
Your holding it wrong.
Same here
Yea, have you tried Docker?
Its not a bug. It is the limitation of the free version. Kindly upgrade to the premium version to enjoy
hazard free cyro tank stirring.
Just kidding. I know its a bug. But nobody clicks on my "Donate via paypal" button, so I ain't going to fix it.
There.. I said it.
Please find second source.
Cannot replicate on my test system. Please zip up all logs and a memory dump and upload it to the support ftp site. We will get back to you within 24 hours. Have a nice day.
It's a network problem. Closing ticket.
This is expected behaviour, In fact its a feature, not a bug.
I was able to fix this by going into the config files and deleting one called "System32".
Apollo is really tough to boot from then on, but it's a solid fix.
Login to NDS as admin and type "load landing.nlm"
Sprzedam Opla! :D
But seriously guys, that bug is clearly caused by the team not having daily agile stand-ups! Agile would do that the right way!
I like my O2 shaken not stirred. Do I have to log in a new issue?
Sounds like you have run into a firmware bug and need a sensor replaced.... we can arrange for a new one to be fitted next week that should fix this issue so if you can drop when in the area next we can take a look at it.
That's an issue that has been pointed out to us by other users as well.
To get this repaired, please send your unit to our service center. We will repair it/replace it depending on the problem with the pre-requisite being:
guys, with this attitude (see almost all comments above), we'll never reach the moon
I just noticed this bug only exists in the 5 bit version. Since we'll be upgrading to the 6 bit version real soon I suggest leaving closed as a WON'T FIX.
I am on Mars for a client assignment right now. So it will be a while before I look into the issue.
Also, I note that you are using a legacy setup that we no longer actively develop.
We will however maintain backward compatibility till 31st Dec 2016. This is part of our strategy to make a streamline move towards cost-effective SpaceX components.
We advice you to upgrade your infrastructure to reflect the same.
That said, we do have a patch for your problem but it wont be until the next release that you can see the fix.
However, if it is very critical for your project, then kindly send over your time signature (in Unix timestamp format) and the value of gravity at your test facility, and one of our engineers will travel back in time to examine and fix the issue.
Thanks.
Is this happening in sandbox, or a production environment? Engineering is saying the described behavior is impossible, it's got to be an instrumentation issue.
Leave it.
until they provide hardware too :)
Your call might be recorded for quality and training purposes
You forgot to import apollo_11.cms...
let me check it out
_Regards_,
_Dominic A. Imbuga *
Blogs: http://imbuga.blogspot.co.ke || imbugad.wordpress.com
*Fullstack Developer | Blogger_
_Github:Domminique_
_Twitter:@dominicimbuga_
_Skype:Dominic-imbuga__+254 715 180 530 | +254 734 983 442_
_" _Science and technology revolutionize our lives, but memory, tradition
and myth frame our response"
On Mon, Jul 18, 2016 at 9:48 PM, Victor Otieno [email protected]
wrote:
You forgot to import apollo_11.cms...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/chrislgarry/Apollo-11/issues/3#issuecomment-233421466,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGX1iZKhwYKY2mTiS8n9ezBpcATSgQ_4ks5qW8prgaJpZM4JHJnx
.
🚫 USER ERROR 🚫
I just solved the issue. Here's how, have a listen!
▶ 🔘──────── 00:21
I suggest assigning Stanley Kubrick to fix this issue.
Which version of Apollo are you running? I suggest upgrading from Apollo 11 to Apollo 12
@khash We cannot upgrade simply because by our 60's semver rules the V12 contains "breaking" changes.
This never would have happened when Steve Jobs was alive.
And that's why we should use docker, could have reproduced the issue easily.
works on my machine
You guys are trying to solve an issue which doesn't exist in future.
The Doctor has already solved it in past future.
In his words:
"People assume that time is a strict progression of cause to effect, but _actually_ from a non-linear, non-subjective viewpoint - it's more like a big ball of wibbly wobbly... time-y wimey... stuff."
So, let's stop being geeky and go back to humour, ehh?
Unless someone can point to the specific user story in the functional design document that proves this is not working as intended, this should be considered a billable change request. Please submit this to the internal review board for discussion at next month's meeting.
if we split the tank and stirrer into separate micro-services and implement some sort of ESB, then at least we can deal with faults in isolation. I highly recommend [flavour of the day] hosting service, in my experience they have been A1 and their 24hr support is awesome.
There is a plugin for jQuery that fixes it. Google4it.
And that's why we have not sent anyone to the moon for 47 years! Please use upcoming Android O which comes with blazing vibration support for stirring (android.os.Vibrator.vibrate())
I think it's time we re-write this node.js code in golang.
Why hasn't anybody submitted a PR to fix this issue yet?
This never would have happened when Steve Jobs was alive.
Who ?
This is just like that time you complained that the autopilot's "hold altitude" function caused a 200 foot per minute descent. No matter how hard I try, I have yet to successfully reproduce this problem on the ground!
Don't understand why this was tagged "Won't fix" and "Humour". Seems to me you don't appreciate the seriousness of this report.
@brianmay what do you expect? They are the same people that worked on the Apollo13 and we all know what happened...
... it worked on my moon ...
... it worked on my moon ...
that's no moon.....
Client decided to upgrade from legacy 60s tech stack alternatives like Soyuz and is now implementing https://github.com/r-spacex/SpaceX-API with at least one success case in production. Gotta say - it's about time.
It works on my machine
Most helpful comment
This is fixed in Apollo 14.