What people sometimes forget about is that such a cycle can be theoretically 100% efficient: it's called the reversible adiabatic process -- completely reversible! As long as your gas storage system is well insulated and has low thermal masses, that is. You simply compress and heat up the gas and store it. Later on, you decompress and cool down.
Think of a gas sealed in a well-insulated, low thermal mass cylinder. You do some work to move the piston in, the gas heats up and compresses. You release the piston, the gas does the same work going out as it expands and cools down. If the system is perfectly isolated and there is no friction, you get exactly the work you put in.
This has the theoretical potential of being a rather nifty thing, but I don't know how the practical (engineering) side of things works out. It may be impractical, or may be not. Time will tell.
If it really works they could retire? LOL. They can buy the Playboy mansion, and all the other mansions of similar um, nature, and probably choose a small college town with lots of chicks and buy all that outright, too. Chicks, teachers, the dean's office, everything;)
Wait a minute. I have accidental death insurance. If there's a crash, I'd much rather be dead and have my family get mucho-$, than say be disabled and have them spend mucho-$ that I won't provide for them in such a case. Unintended consequences, and all that. IOW: if there's a crash where most people will be significantly injured, I'd much rather die, thankyouverymuch.
Specifically, some modern airframe buses use TTEthernet as the backbone. Physically it's about as "robust" as any Ethernet-based network -- IOW it's nothing special. The robustness comes from the protocols that run on top of the Ethernet medium.
If avionics systems get irritated, then they are operating at the wrong frequency
LOL, you're just silly. GPS operating frequencies are fixed. You can't change them. Almost every electronic gadget out there with a modern CPU will unintentionally radiate at GPS frequencies: I've seen first hand laptops that are especially bad at that. They are fully within FCC limits but still they cause a nearby GPS receiver to lose lock.
The requirement to accept interfering transmissions does not imply that correct operation must be maintained, only that things should not break (IIRC -- say the receiver blowing up).
You can well comply with all applicable FCC regulations and still emit enough to kill GPS receivers -- and that's whether you fall under the rules set for intentional radiators, or not.
Methinks that airborne commercial GPS receiver systems simply are too sensitive to stuff radiated onboard and below the horizon. They should use a phased array with steerable beams to track the satellites -- even in basic implementation this easily gives 30dB of gain -- and that seems more than far enough to maintain lock in presence of FCC-compliant radiators on board. Even multiple of them.
A bit of nitpicking: It wasn't IEEE that did the study -- at least nowhere in the article does it claim that IEEE commissioned the study. The authors merely published it in an IEEE journal.
But besides that: the article is -- as far as science is concerned -- a piece of crap. The only valid claim is that people leave their cellphones on, and perhaps even use them. That's it. They have not shown that there was interference in the GPS or legacy NAVAID bands. Even if they would have shown it, such measurements must be done at the input from the antenna(s) used by avionics, not by an antenna in a carryon.
The only other semi-valid argument they have stems from their analysis of historical incident data. What I don't like about it, though, is that they treat every airplane the same. Such an approach would need to be shown correct first: you'd need to do real measurements to show that airframe and antenna systems don't affect the path loss from the cabin to your receiver.
For now I think that you can't mix different airframes and receivers in one bag. For every airframe, there is some worst-case (here: lowest) path loss between a "small" radiator of (cellphone, laptop, PDA) and the GPS/NAVAID receiver inputs. I expect there to be a big spread (I'd think 20dB at least) between various airframes. By airframe I mean a unique combination of airframe and installed antenna systems.
I'd think that small planes would be in the worst shape. Assuming that shielding systems work correctly, the direct path between radiators in the cabin and the GPS/NAVAID receivers can be ignored. So what you really get is a bunch of windows that radiate outwards, and some of this gets diffracted/reflected back to the antennas elsewhere on the airframe. The loss on this path is IIRC called Minimum Interference Path Loss (MIPL).
A 747 will be a whole different ballgame I'd bet than, say, ERJ-145. The NASA report (google for SPH-N300 NASA) mentions that they saw problems specifically on a small plane.
It was a radio altimeter malfunction, not attributed to EMI directly, although it could be a design issue where EMI played a role. Due to location under the belly, I doubt that cabin-originating EMI could play a role. So, as far as I'm concerned, the crash-inducing-EMI-in-planes is bunk and scaremongering.
So, have many documented crashes are out there (with NTSB or similar national body reports available) where EMI effects were identified as a part of the failure cascade? IOW: citation please.
LOL, wrong frequency at the wrong time. What a load of BS. Interconnected digital avionics systems deal with networking upsets, and can usually restart the networking stack in a fraction of a second if it comes to that. If you do actually manage to get EMI anywhere near the digital guts of a control system (CPU, memory, etc), things have failed horribly anyway. You'd need an EMP from a nuclear blast for that. It's not exactly easy to lug a multi-hundred-kilowatt transmitter onboard a plane, and that's what you'd need to even begin getting anywhere close to real corruption in typical critical avionics systems. If all you do is corrupt external radio transmissions, nothing restarts because of that, save for -- maybe -- the GPS receiver's state machine.
If it's a stuck reading that's caused by an EMI-induced upset, then you have a serious flight software bug anyway. Flight software generally is not supposed to give stuck values when correct data is flowing in. Also do remember that EMI is mainly affecting cabling, so you're not likely to flip a bit on a flight computer without first pretty much obliterating the network transmission first. If the network is shot (due to interference, disconnection, etc), your instuments throw nice Xs across the values, so that you know that current data is not available. The N0 values received by the displays are also likely to go through some sort of a plausibility filter -- engines spool up and down slowly, whereas the N0 value is transmitted likely many times per second. Single outliers are likely to be removed and not affect the display. For this to even happen you need an unlikely scenario that the networking stack fails to detect data corruption. So your story is pretty much entirely fictional and implausible -- it is based on no understanding of how real systems work. I'd call it scare mongering, even.
If one can't explain to one's wife what has happened in this case, then perhaps one chose a wrong wife? And here I was thinking that adults in a loving relationship can talk about pretty much anything, and trust each other. Bah.
I stand by my statement that a user application shouldn't be able to crash an X11 server. And at least in the case of the crash above, that's the case: it's KDE that crashes, not X11 -- I agree with jadrian.
If just changing the NVidia driver version can prevent this crash from occurring, it almost points the finger at Xlib code. Some junk is perhaps returned from the screen (the X server), and Xlib corrupts some unrelated userland data (or its own data), and then promptly brings down the application.
There shouldn't be anything that a unprivileged userspace code like KDE should do to crash an X11 screen, whether local or remote. The buck stops at the GPU driver.
There's a difference between what amounts to a dumb D/A converter with a bunch of support logic for video timing, and a card that's a whole computer in and of itself. Realtime video rendering on par with a dumb graphics card can easily be done 100% in software these days, even on rather lowball hardware -- just look at what's possible with a single chip Parallax Propeller microcontroller. A slightly more powerful hardware would be the XMOS XS1 platform. Both of those platforms let you have 1024x768 VGA or HDMI output, defined completely in software.
As for the "standardised" registers on Matrox/S3/Tseng: you obviously have no idea what you're talking about. All those cards were emulating the legacy IBM register set, but this was only a looked-down-upon legacy compatibility mode for low-resolution modes -- maybe up to 16 color 800x600. All of the cards you listed had mutually incompatible register sets that you had to access for native operation at full resolution, and for access to blitter and other acceleration primitives. The best you could hope for was that the VESA BIOS didn't have bugs and that the flat framebuffer native video modes would work, but that was without you knowing anything about registers. You just made a mode switch call into the BIOS, and then inquired about where the framebuffer was; from thereon you were on your own.
The fast pace of progress in graphic cards pretty much makes it impossible to have any sort of a consortium-driven standard for access to hardware. Whatever would be publicly available would lag a generation or two behind shipping hardware. Making solid, interoperable standards is hard. If you want it done quickly, especially in parallel with hardware development, you need to hire a lot of extra, very experienced (not cheap) talent. Of course ATI and NVidia have their in-house spec/documentation teams, but they only have to worry about making something that will keep their own divisions in sync. It doesn't have to be understandable outside of their doors. Don't underestimate the information content of corporate culture: there's plenty of documents that I've seen that are next to useless simply because one would need to be "then and there" to get the context necessary for understanding.
The one fan can be driven from two turbines, but that's besides the point. If the fan of such a size decides to disintegrate, good luck containing the failure. You lose the empennage, adios.
Let's get some perspective. The US-Mexico land border is about 3200km long. $8 billion amounts to $2.5 million per metre of border. You don't need no stinking virtual border, at that price they could get something on the scale of a concrete dam, footed 10-20m below grade, running the whole length. At the purchase scale of billions, you can get some extremely price competitive sensing gear. The problem here is not that the technological solution is wrong; it's that Boeing is absolutely unfit to provide cost-effective, down-to-earth solutions to certain real-life problems where they face no competition. If they priced their jets according to the same pricing model, a 747 would be costing $2B. They are on cloud nine, but worse -- whoever signs the bills is mentally in even worse shape.
I've done some conservative back-of-the-envelope calculations, and assuming that land and easements are free, for just under $1B you could have some pretty nice tech deployed to cover entire US-Mexico border with state of the art SAR, NIR and VIS imaging, with delayed imagery available also online to the public (how's that for transparency, huh?). Another $1B would comfortably cover operations and maintenance for a decade. But the whole system has to be properly engineered, you can't have it running on grandstanding and buzzwords. The Boeing division responsible for that project has clearly shown a total ineptness to do anything much at all.
I don't think there's any case law internationally that a search engine is aiding and abetting anything. Although with recent legislative stupidity, who knows. A search engine is just that: a search engine. It's not their job not to find stuff. What you expect is like expecting a phone book not to list numbers of felons.
Slashdot Mirror
What people sometimes forget about is that such a cycle can be theoretically 100% efficient: it's called the reversible adiabatic process -- completely reversible! As long as your gas storage system is well insulated and has low thermal masses, that is. You simply compress and heat up the gas and store it. Later on, you decompress and cool down.
Think of a gas sealed in a well-insulated, low thermal mass cylinder. You do some work to move the piston in, the gas heats up and compresses. You release the piston, the gas does the same work going out as it expands and cools down. If the system is perfectly isolated and there is no friction, you get exactly the work you put in.
This has the theoretical potential of being a rather nifty thing, but I don't know how the practical (engineering) side of things works out. It may be impractical, or may be not. Time will tell.
If it really works they could retire? LOL. They can buy the Playboy mansion, and all the other mansions of similar um, nature, and probably choose a small college town with lots of chicks and buy all that outright, too. Chicks, teachers, the dean's office, everything ;)
Or sleeping, for that matter.
Wait a minute. I have accidental death insurance. If there's a crash, I'd much rather be dead and have my family get mucho-$, than say be disabled and have them spend mucho-$ that I won't provide for them in such a case. Unintended consequences, and all that. IOW: if there's a crash where most people will be significantly injured, I'd much rather die, thankyouverymuch.
That's some lame ass intercom system you were using. Perhaps 3rd party uncertified headsets or replacement parts?
Specifically, some modern airframe buses use TTEthernet as the backbone. Physically it's about as "robust" as any Ethernet-based network -- IOW it's nothing special. The robustness comes from the protocols that run on top of the Ethernet medium.
If avionics systems get irritated, then they are operating at the wrong frequency
LOL, you're just silly. GPS operating frequencies are fixed. You can't change them. Almost every electronic gadget out there with a modern CPU will unintentionally radiate at GPS frequencies: I've seen first hand laptops that are especially bad at that. They are fully within FCC limits but still they cause a nearby GPS receiver to lose lock.
The requirement to accept interfering transmissions does not imply that correct operation must be maintained, only that things should not break (IIRC -- say the receiver blowing up).
You can well comply with all applicable FCC regulations and still emit enough to kill GPS receivers -- and that's whether you fall under the rules set for intentional radiators, or not.
Methinks that airborne commercial GPS receiver systems simply are too sensitive to stuff radiated onboard and below the horizon. They should use a phased array with steerable beams to track the satellites -- even in basic implementation this easily gives 30dB of gain -- and that seems more than far enough to maintain lock in presence of FCC-compliant radiators on board. Even multiple of them.
A bit of nitpicking: It wasn't IEEE that did the study -- at least nowhere in the article does it claim that IEEE commissioned the study. The authors merely published it in an IEEE journal.
But besides that: the article is -- as far as science is concerned -- a piece of crap. The only valid claim is that people leave their cellphones on, and perhaps even use them. That's it. They have not shown that there was interference in the GPS or legacy NAVAID bands. Even if they would have shown it, such measurements must be done at the input from the antenna(s) used by avionics, not by an antenna in a carryon.
The only other semi-valid argument they have stems from their analysis of historical incident data. What I don't like about it, though, is that they treat every airplane the same. Such an approach would need to be shown correct first: you'd need to do real measurements to show that airframe and antenna systems don't affect the path loss from the cabin to your receiver.
For now I think that you can't mix different airframes and receivers in one bag. For every airframe, there is some worst-case (here: lowest) path loss between a "small" radiator of (cellphone, laptop, PDA) and the GPS/NAVAID receiver inputs. I expect there to be a big spread (I'd think 20dB at least) between various airframes. By airframe I mean a unique combination of airframe and installed antenna systems.
I'd think that small planes would be in the worst shape. Assuming that shielding systems work correctly, the direct path between radiators in the cabin and the GPS/NAVAID receivers can be ignored. So what you really get is a bunch of windows that radiate outwards, and some of this gets diffracted/reflected back to the antennas elsewhere on the airframe. The loss on this path is IIRC called Minimum Interference Path Loss (MIPL).
A 747 will be a whole different ballgame I'd bet than, say, ERJ-145. The NASA report (google for SPH-N300 NASA) mentions that they saw problems specifically on a small plane.
Yep, I agree. I've had a Ph.D. biology teacher in high school in Poland and those were some of the most positively memorable classes.
It was a radio altimeter malfunction, not attributed to EMI directly, although it could be a design issue where EMI played a role. Due to location under the belly, I doubt that cabin-originating EMI could play a role. So, as far as I'm concerned, the crash-inducing-EMI-in-planes is bunk and scaremongering.
So, have many documented crashes are out there (with NTSB or similar national body reports available) where EMI effects were identified as a part of the failure cascade? IOW: citation please.
LOL, wrong frequency at the wrong time. What a load of BS. Interconnected digital avionics systems deal with networking upsets, and can usually restart the networking stack in a fraction of a second if it comes to that. If you do actually manage to get EMI anywhere near the digital guts of a control system (CPU, memory, etc), things have failed horribly anyway. You'd need an EMP from a nuclear blast for that. It's not exactly easy to lug a multi-hundred-kilowatt transmitter onboard a plane, and that's what you'd need to even begin getting anywhere close to real corruption in typical critical avionics systems. If all you do is corrupt external radio transmissions, nothing restarts because of that, save for -- maybe -- the GPS receiver's state machine.
If it's a stuck reading that's caused by an EMI-induced upset, then you have a serious flight software bug anyway. Flight software generally is not supposed to give stuck values when correct data is flowing in. Also do remember that EMI is mainly affecting cabling, so you're not likely to flip a bit on a flight computer without first pretty much obliterating the network transmission first. If the network is shot (due to interference, disconnection, etc), your instuments throw nice Xs across the values, so that you know that current data is not available. The N0 values received by the displays are also likely to go through some sort of a plausibility filter -- engines spool up and down slowly, whereas the N0 value is transmitted likely many times per second. Single outliers are likely to be removed and not affect the display. For this to even happen you need an unlikely scenario that the networking stack fails to detect data corruption. So your story is pretty much entirely fictional and implausible -- it is based on no understanding of how real systems work. I'd call it scare mongering, even.
It's all up to you. Don't blame it on passage of time. You have to work at it. Get lazy, and sure, you'll "lose" the "glasses". Sigh.
Poor married soul indeed: what kind of a relationship he/she is in that they can't explain simple things like that...
Hate to burst your bubble: good luck claiming "identity fraud" on a dating site.
If one can't explain to one's wife what has happened in this case, then perhaps one chose a wrong wife? And here I was thinking that adults in a loving relationship can talk about pretty much anything, and trust each other. Bah.
I stand by my statement that a user application shouldn't be able to crash an X11 server. And at least in the case of the crash above, that's the case: it's KDE that crashes, not X11 -- I agree with jadrian.
If just changing the NVidia driver version can prevent this crash from occurring, it almost points the finger at Xlib code. Some junk is perhaps returned from the screen (the X server), and Xlib corrupts some unrelated userland data (or its own data), and then promptly brings down the application.
There shouldn't be anything that a unprivileged userspace code like KDE should do to crash an X11 screen, whether local or remote. The buck stops at the GPU driver.
There's a difference between what amounts to a dumb D/A converter with a bunch of support logic for video timing, and a card that's a whole computer in and of itself. Realtime video rendering on par with a dumb graphics card can easily be done 100% in software these days, even on rather lowball hardware -- just look at what's possible with a single chip Parallax Propeller microcontroller. A slightly more powerful hardware would be the XMOS XS1 platform. Both of those platforms let you have 1024x768 VGA or HDMI output, defined completely in software.
As for the "standardised" registers on Matrox/S3/Tseng: you obviously have no idea what you're talking about. All those cards were emulating the legacy IBM register set, but this was only a looked-down-upon legacy compatibility mode for low-resolution modes -- maybe up to 16 color 800x600. All of the cards you listed had mutually incompatible register sets that you had to access for native operation at full resolution, and for access to blitter and other acceleration primitives. The best you could hope for was that the VESA BIOS didn't have bugs and that the flat framebuffer native video modes would work, but that was without you knowing anything about registers. You just made a mode switch call into the BIOS, and then inquired about where the framebuffer was; from thereon you were on your own.
The fast pace of progress in graphic cards pretty much makes it impossible to have any sort of a consortium-driven standard for access to hardware. Whatever would be publicly available would lag a generation or two behind shipping hardware. Making solid, interoperable standards is hard. If you want it done quickly, especially in parallel with hardware development, you need to hire a lot of extra, very experienced (not cheap) talent. Of course ATI and NVidia have their in-house spec/documentation teams, but they only have to worry about making something that will keep their own divisions in sync. It doesn't have to be understandable outside of their doors. Don't underestimate the information content of corporate culture: there's plenty of documents that I've seen that are next to useless simply because one would need to be "then and there" to get the context necessary for understanding.
Fans methinks can be made to survive bird strikes. It's everything else downstream that doesn't like it.
The Lockheed design has a single fan. This doesn't imply a single engine (turbine) driving it.
The one fan can be driven from two turbines, but that's besides the point. If the fan of such a size decides to disintegrate, good luck containing the failure. You lose the empennage, adios.
Let's get some perspective. The US-Mexico land border is about 3200km long. $8 billion amounts to $2.5 million per metre of border. You don't need no stinking virtual border, at that price they could get something on the scale of a concrete dam, footed 10-20m below grade, running the whole length. At the purchase scale of billions, you can get some extremely price competitive sensing gear. The problem here is not that the technological solution is wrong; it's that Boeing is absolutely unfit to provide cost-effective, down-to-earth solutions to certain real-life problems where they face no competition. If they priced their jets according to the same pricing model, a 747 would be costing $2B. They are on cloud nine, but worse -- whoever signs the bills is mentally in even worse shape.
I've done some conservative back-of-the-envelope calculations, and assuming that land and easements are free, for just under $1B you could have some pretty nice tech deployed to cover entire US-Mexico border with state of the art SAR, NIR and VIS imaging, with delayed imagery available also online to the public (how's that for transparency, huh?). Another $1B would comfortably cover operations and maintenance for a decade. But the whole system has to be properly engineered, you can't have it running on grandstanding and buzzwords. The Boeing division responsible for that project has clearly shown a total ineptness to do anything much at all.
I don't think there's any case law internationally that a search engine is aiding and abetting anything. Although with recent legislative stupidity, who knows. A search engine is just that: a search engine. It's not their job not to find stuff. What you expect is like expecting a phone book not to list numbers of felons.