Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ¬NED pin goes low on detection of a nuclear detonation [pdf]

maxwell.com

Post reply on HN
Print view View original

71–80 of 86 posts

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#71

Post by nraynaud »

idoh wrote: post #8

So, 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…

I've worked for a French military chopper (Tiger, NH-90) company, and they do the same, they short-circuit everything (even the batteries) so that the induced current doesn't grill semiconductors but flows freely through copper. They do that for a very short time, so the cinetic energy in the moving rotor keeps the helicopter airborne.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#72

Post by nraynaud »

kabdib wrote: post #24

I'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…

I guess there might be some code for mis-firing. Detonating this kind of stuff is tricky.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#73

Post by nraynaud »

kennywinker wrote: post #64
idoh wrote: post #8

So, 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.

my sister and mother where in WMD, my father was in Oil industry. My only sane options where either compete with them by going to High Speed Trading in African originated goods markets or give up and become a Hippie, I mostly took the later option and live 400km from them.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#74

Post by [deleted] »

Nitramp wrote: post #65
pjscott wrote: post #13

Earlier quoted context omitted.

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…

[deleted]

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#75

Post by mfenniak »

Nitramp wrote: post #65
pjscott wrote: post #13

Earlier quoted context omitted.

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…

The Space Shuttle had a design like this, with a separate backup flight control system that used independent hardware and software. http://en.wikipedia.org/wiki/Space_Shuttle#Flight_systems

I wonder though -- in this case, the backup software was never used. In my experience, redundant systems tend to fail more often the less frequently they're used... I wonder how they maintained testing the backup flight system to ensure that it the transition would operate correctly.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#76

Post by amatus »

kabdib wrote: post #24

I'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…

Some missiles run a proprietary operating system for which one has to buy a license per missile. I always found it funny that those instances of the OS were going to destroy themselves.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#77

Post by sophacles »

giardini wrote: post #70
idoh wrote: post #8

So, 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.

Why does the rate of propagation matter? I presume that during the course of the explosion there are several sequential phases. If phase x emits some non-EMP but detectable signal, say an X-Ray burst and phase y emits the EMP, both of which propagate at the same rate, then you have time(y) - time(x) to respond to detecting x before the EMP from y reaches you.

Explosions, like all other macro scale phenomena are not instantaneous, they just appear so until an appropriately small time step is applied.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#78

Post by huhtenberg »

nraynaud wrote: post #71
idoh wrote: post #8

So, 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…

I've worked for a French military chopper (Tiger, NH-90) company, and they do the same, they short-circuit everything (even the batteries) so that the induced current doesn't grill semiconductors but flows freely through copper. They do that for a very short time, so the cinetic energy in the moving rotor keeps the helicopter airborne.

I wonder what a test cycle for this system is like.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#79

Post by nobody31 »

samfoo wrote: post #32
kabdib wrote: post #30

Earlier quoted context omitted.

Think cruise missile. Some code looks at a map, looks at GPS, looks at altitude and velocity, and decides "Yup, this is the spot." It's probably a lot more prosaic than I imagine.

I'm fairly certain that ICBM's use inertial guidance with predefined/computed coordinates ( http://en.wikipedia.org/wiki/Inertial_guidance ). There's no software involved, its all physical. Detonation is (probably) trigged by a combination of altimeter, accelerometer and other telemetry systems.

ICBM's use inertial and (in the case of Trident) star mappers.

The reason they don't use GPS is that you would (hopefully) only start throwing ICBMs around if you are in "nucular combat toe to toe with the Rooskies" - and the way you know you are in a proper war is that all your GPS satellites have just been destroyed by the other side.

Re: The ¬NED pin goes low on detection of a nuclear detonation [pdf]

#80

Post by gnaffle »

Nitramp wrote: post #65
pjscott wrote: post #13

Earlier quoted context omitted.

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…

http://en.wikipedia.org/wiki/N-version_programming It's used in Airbus planes, for instance.

Of course, it's useless if the specification is wrong, and the assumption that the differing versions will fail in different ways seems to not hold water.

Post reply on HN