I just love this bullet point:
* Maxwell Technologies Specified, Controlled, Tested and
Guaranteed
So, I suppose if you experience a nuclear detonation and the chip doesn't go off, you get your money back?!
The ¬NED pin goes low on detection of a nuclear detonation [pdf]
61–70 of 86 posts
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#62I've wondered about the following: The firmware controlling a nuke has to have, at some point, a bit or control register it sets that causes the explosion to go off: *pKaboom = true; or something like that. My question is: What is the line of code after that? *pKaboom = true; /*NOTREACHED*/ I suspect it's more complicated than that (there's an infinite loop of some kind that keeps retrying the command sequence). I al…
GCC has a noreturn pragma for this sort of thing. It lets you mark functions as never returning, which can in turn help the optimizer generate code leading up to that function's call sites.
[deleted]
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#63Hopefully the Built-In Test pin doesn't trigger a nuclear event.
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#64So, my mom is a former Maxwell employee who now does her own defense contracting, and makes this same type of part. As I understand it, when there is a nuclear event, it generates x-rays followed by the EMP. The goal is to have warheads in flight to be able to continue to their target, so the strategy is to employ an NED. When an event is detected, the warhead shuts down its electronics for the duration of the EMP, a…
Do you have mixed feelings about this? Your mom's part in WMD technology, I mean. And how does she feel about it? This is a serious question.
I genuinely wonder if people who work on this kind of stuff feel conflicted about it regularly, or don't think about it, or feel strongly that they are doing good.
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#65Earlier quoted context omitted.
No kidding. I believe NASA had something like 3 dual-redundant flight computers on the Voyager probes.
Just think how much redundancy you could get, cheaply, with the advances that have been made with Moore's Law over the years. Computers for space probes don't need to be that fancy. It's totally feasible to build processors that use error-correcting codes in their entire datapaths, have tri-modular redundancy for all their functional units, and then are arranged alongside several other identical processors for ridicu…
Redundancy in hardware is one problem. But then all those CPUs still run the same software.
After Ariane 5 crashed spectacularly due to a software error that affected the two on board computers and the ground control unit likewise (http://en.wikipedia.org/wiki/Ariane_5_Flight_501), there had been talk about having the same software be developed by multiple, independent teams, and then use the different versions for error correction. Sounds like a crazy idea and probably won't work, but I don't really know of a better solution either.
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#66I've wondered about the following: The firmware controlling a nuke has to have, at some point, a bit or control register it sets that causes the explosion to go off: *pKaboom = true; or something like that. My question is: What is the line of code after that? *pKaboom = true; /*NOTREACHED*/ I suspect it's more complicated than that (there's an infinite loop of some kind that keeps retrying the command sequence). I al…
[deleted]
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#67Earlier quoted context omitted.
Of course! When the !NED pin goes low, duck and cover like it's 1959. (Fun fact: in a fairly large portion of the blast radius of a nuclear bomb, the main danger for people indoors is falling debris and broken glass from the pressure waves. Duck and cover actually works.)
So hiding in a fridge might actually save you?
Given how close to ground zero in Hiroshima and Nagasaki people actually survived just by virtue of being slightly more shielded than people around them: Yes, it'd probably at least increase your odds.
And it's not like the Indy movies aren't full of situations where his odds of survival would've been ludicrously low.
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#68I just love this bullet point: * Maxwell Technologies Specified, Controlled, Tested and Guaranteed So, I suppose if you experience a nuclear detonation and the chip doesn't go off, you get your money back?!
I think you can physically model the ionizing radiation of a nuclear event, without actually detonating a weapon, just condoms are tested for elasticity by filling them with pressured air and water.
The detector may have been tested before the discontinuation of underground testing in the US in '92
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#69Guaranteed to operate in ionizing radiation of 10^12 rad/s. Yikes, that's like 10 billion sieverts/s. Since a dose of something like 10+ sieverts is fatal I'm guessing a human would be turned to a puddle of goo around that much radiation.
1e12 rad/s is 10e9 Gray/s. Sieverts measure something else, dose equivalence.
Interestingly, in this radiation field, every kilogram of mammalian tissue absorbs 10 GW. If this blasts lasts for more than a few nanoseconds, your puddle of goo would be a good guess.
Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]
#70So, my mom is a former Maxwell employee who now does her own defense contracting, and makes this same type of part. As I understand it, when there is a nuclear event, it generates x-rays followed by the EMP. The goal is to have warheads in flight to be able to continue to their target, so the strategy is to employ an NED. When an event is detected, the warhead shuts down its electronics for the duration of the EMP, a…
When an event is detected, the warhead shuts down its electronics for the duration of the EMP, and then powers back up.
I doubt this, since the EMP is moving at the speed of light, whereas the delay times inherent in most circuitry and the time required to power down most circuitry would be at least an order of magnitude (most likely more) larger.