Most of the time, water injection is used in turbocharged/supercharged engines. It is used in place of an aftercooler (usually incorrectly called an intercooler) or to augment a smaller one. Compressing air in a supercharger/turbo heats it, injecting water cools it back down. Air at the same pressure but a lower temperature is more dense = more air fits into the cylinder. Also, since the intake air is cooler, the temperature after compression in the cylinder is lower, so detonation is less likely.
It may be possible in some normally aspirated engines to get a benefit from water injection. Over on the allpar.com forums, one guy was experimenting with it on his Dodge Shadow and getting good results. If it had been anyone else I wouldn't have believed him, but this guy was pretty thorough. Note that he saw no benefit from water injection until he advanced his timing - Essentially water injection was raising the effective octane rating of his fuel, allowing him to advance timing. It would also have allowed for a higher compression ratio without detonation. It could potentially be used as a replacement for lead in older cars that prefer leaded gasoline (Such cars had higher compression ratios, since leaded is less likely to preignite), but I don't know about that.
This might not have been of any benefit on an "optimum" engine like 90% of those on the market today. (Thanks to computer simulations, most engines in newer cars are close to the limits of what can be done in a normally aspirated car without major sacrifices in emissions/driving flexibility/efficiency.) It happened that the 2.2/2.5 Chrysler engines had rather suboptimal intake systems and it didn't take much to improve that model of engine. (Matt also had a ram air intake system that was a major benefit for 2.2/2.5 users but of almost no benefit to most 3.0L V6 users because that engine was a bit more recent and had a better stock intake system to begin with.)
90% of turbocharger systems on the market use an aftercooler. (Usually called an intercooler, but in most situations this isn't actually the correct term - Intercoolers are used in systems with multiple compressor stages, usually fixed generators.)
When gas is pressurized, it heats up. The aftercooler allows this heat to be exchanged to the ambient air, resulting in gas which is close to the same pressure. (Slightly less due to frictional losses in the aftercooler) But since it's cooler, it's more dense than if it were the same pressure (or even slightly higher pressure) at a warmer temperature.
This allows the engine to fit more air into the cylinders without the risk of detonation.
All of that heat given up in the intercooler is mere waste...
A lot could be done for efficiency of cars if someone could figure out a way to use gasoline in a combustion cycle similar to diesel engines. Diesels don't have problems with preignition/detonation, in fact they RELY on the phenomenon that causes it (compression heats the air) in order to ignite the air/fuel mixture. Rather than mixing the air/fuel and then compressing it (and having a risk of the heating from compression alone causing the mix to ignite), diesels compress the gas heavily and THEN inject fuel, which instantly burns because the gases are so hot. (This is why diesels are usually more efficient - They run much higher compression ratios than gasoline engines can.)
There's no difference between handheld civilian units and other civilian units. They all use the same signals, with the exception of survey-grade equipment which is not affected by SA to begin with. (That and civilian equipment which is receiving some form of DGPS correction data, whether through the Coast Guard's VLF transmitters in the US, WAAS from geostationary non-military satellites, or any other DGPS source such as dgpsip)
100 meters is more than good enough for automotive navigation if you're paying attention to the road, so who cares about SA?
I've driven in New England without GPS assistance. There were a few times it might've been nice ("How many miles am I from Quincy Market now?"), but it's nothing 100 meters of error would've caused a problem with.
In short: If you're paying attention primarily to the road and your surroundings, 100 meters error won't hurt you at all.
Some Garmin receivers already support WAAS, which is a DGPS variant that uses data from geostationary satellites.
Kinda of hard to knock those out...
Also, terrestrial DGPS is not likely to be targeted by a missle for use in the USA.
DGPS isn't too expensive - Almost any civilian GPS receiver can apply the corrections if they are supplied, and receivers for the Coast Guard broadcasts are only $150-200 I believe. (And have been homebrewed for less.) If you have some form of wireless internet connection, do a search for dgps-ip - Essentially RTCM correction data that can be obtained by connecting to a port on a dgpsip server.
Do you realize how long it takes from the initial design stages to general use for a commercial jetliner? A helluva lot longer than three years. Hell, I don't think a jetliner could even get FAA certification in three years from the first prototypes being built.
In short: AIRPLANES HAVE BACKUPS. GPS is currently considered to be the least reliable nav source, precisely because the military can kill the system or enable SA any time they want to. Pilots are required to be able to navigate without GPS and using their eyes only. If you can't navigate based on visual info alone, you don't get your license. Similarly, you don't get your IFR certification unless you can use all of the standard instrumentation that was in use long before GPS became common.
Also, most likely almost any aeronautical GPS will support some form of DGPS, which makes SA semi-irrelevant. As soon as SA turns on, it will be a matter of seconds before updated DGPS info starts coming through. (This is assuming that SA isn't turned on gradually. It most likely will be, in which case users of DGPS in one form or another won't notice a thing.) Locally, the Coast Guard broadcasts DGPS at VLF frequencies in localized areas, and modern Garmins support WAAS, which is a DGPS variant that uses non-military geostationary satellites to broadcast the corrections.
Admittedly, there IS some military data on the civilian frequency, but it's more than possible for the military to get a decent fix if the frequency that carries civilian data is jammed.
The P code is broadcast on two frequencies. This allows the receiver to measure and correct for ionospheric delay, but also allows the military to gain a fix even if one frequency is jammed, at a precision slightly better than that of the unjammed civilian code but worse than normal for military use.
Also, I've read that military receivers are much harder to jam. Most likely the P code is transmitted at higher power, and also military receivers can use a phased-array antenna and some DSP power to reject noise sources not in the direction of a satellite.
People like you shouldn't be driving. The GPS is merely a navigational aid. It doesn't and never should replace KEEPING YOUR EYES ON THE GODDAMNED ROAD. You shouldn't need a GPS to tell you that you're on Foo Avenue - You should be looking at Foo Avenue and double checking that you're on Foo Avenue using these really cool devices called street signs.
that the US turned off SA in the first place to neuter the Galileo project by reducing its perceived need.
Well, the second time the US turned SA off was for that reason.
This article is really amusing because of the fact that the government actually turned SA OFF for the last Gulf War, as there was a shortage of military GPS receivers and soldiers were ordering civilian units mail-order.
The amount of microwave radiation emitting from these things is insignificant.
For one, only the CPU core is running in the GHz range. This is a very small area, and doesn't make a good antenna.
For another, almost all of those high-frequency paths are terminated. As a result all of the power goes into some sort of load (Often the gate of the next transistor), and gets converted to heat and not radiated as RF. You can confirm this by measuring the power input of a CPU and its heat output - Almost all of that power is being turned into heat, so where could RF be coming from? Let's not forget that the heatsink (or heat pipe evaporator) and other parts of the machine make good RF shields.
People make way too big of a deal of RF exposure. Trust me, if it were as dangerous as the "cell phones cause cancer" crowd made it out to be, most of my coworkers would be dead or extremely sick. But they're still healthy even after quite a number of them have been working on RF power amplifiers for 10-20 years. We're regularly exposed to far more RF than a cell phone is likely to emit in our development labs without any problems at all.
BTW, it's more than possible to run modern laptops on your lap if you know what you're doing. In the case of Dell Inspirons, do a search for FanGUI. The BIOS fan speed settings for the Dells are quite agressive as far as maximizing battery life/minimizing noise. (i.e. the CPU has to heat up to around 60 degrees C or more for the fans both to be turned on at their "high" setting.) FanGUI (And a similar tool for Linux) takes over and manages the fan speeds, sacrificing a little battery for much lower temperatures. With FanGUI, I can run full-speed on AC with the unit in my lap without a problem.
BTW, Sandia's way behind. Dell has been using heatpipes for close to two years (Maybe longer. The I8000 has heatpipes, so does the 8200).
And yes, they're wicked heatpipes. Non-wicked pipes don't work when the heat source is above the heatsink, but my Dell works fine when tilted backwards.
Finally found the URL for the one utility I've used (Although haven't yet gotten my postprocessing code to work with it - The RINEX file is different enough from the ones recorded in CU's ECE 415 lab that the preprocessor chokes on it.)
http://artico.lma.fi.upm.es/numerico/miembros/an to nio/async/
While it's hard/impossible to obtain a receiver that can directly use the P code, it IS possible for a civilian receiver to use the encrypted P code for additional accuracy without decrypting it.
The civilian C/A codes are only broadcast on one frequency. Both the C/A and P codes are pseudorandom bit sequences designed to have a very high peak in their self-correlation function. (Effectively turning the CW transmitters on the satellites into high-power pulse transmitters as far as SNR requirements at the receiver.) The encrypted P code has a much lower peak in its self-correlation function, but it STILL has a peak.
The C/A code is only broadcast on one frequency, while the P code is broadcast on two frequencies. Why? Because one of the leading sources of error in GPS reception when SA is turned off is the fact that the ionosphere delays the signal. Fortunately, the ionospheric delay is a linear function of the frequency. (I.e. a signal at 1.7 GHz is delayed 1.7/1.2 times as much as a signal at 1.2 GHz). So, a military receiver can measure the delay between the two frequencies, and from that calculate the ionospheric delay.
Now go back to the fact that even the encrypted code has a peak in its self-correlation function. A high-end civilian (usually surveying) receiver can receive the encrypted P-codes and correlate them (since they happen to be identical). Since the self-correlation peak of the encrypted code is much lower, the signal strength must be higher than that for unencrypted codes and the process is SLOW, but it can be done. Receivers capable of this cost $$$$$$. (For example, in the GPS lab at Cornell University, they have only 1-2 dual-frequency receivers, while they have plenty of single-frequency receivers on ISA cards to allow for advanced postprocessing of data.)
As far as SA - Even when SA is on, it's possible to get millimeter accuracy from a civilian receiver, using the same techniques needed to get millimeter accuracy from a civilian receiver with SA off. The most important thing is a "reference receiver" nearby - One whose location is precisely known. This receiver can measure all of the errors generated by the satellites, which can be used later to postprocess the data from a remote receiver and correct it.
In addition to clock dithering, SA puts errors in the satellite ephemerides (The description of their orbits). It's possible to download precise (even better than non-SA) ephemerides from various standards organizations for post processing.
Want to try post-processing yourself? Until recently, the answer was "tough luck" with the exception of expensive receivers and the Delorme Earthmate. Only the Earthmate allowed the user to capture raw pseudorange data (The data needed to obtain a navigation fix) for later processing. Fortunately, some people found out that it was possible to obtain pseudorange data from 12-channel Garmin civilian receivers by using some undocumented commands. See http://mywebpages.comcast.net/dmilbert/softs/g12ri n.htm and http://www.nottingham.ac.uk/iessg/gringo/
On one hand, we should've gotten rid of Saddam the first time around. I agree that he needs to go and something needs to be done about him (and should've been done long ago).
On the other hand, I don't think that it should be done at the cost of pissing off the entire fucking planet in the process, while ignoring the fact that our economy is in a hole, and the uncertainty about Iraq (Both in general paranoia and in oil prices) is killing what's left of our economy.
Screw Iraq. Bomb Florida, this is all their fault.
This already exists to some degree - Modern 3D cards have internal pixel pipelines of 16+ bits/color. The latest (GeForceFX and I think also the Radeon) have moved to internal floating-point representation, doesn't get much more accurate than double-precision FP. Even single-precision is insane compared to 8 bits/color.
Also, at the output stage, not much more than 8 bits/color is needed. At input, more than 8 bits/color would be useful for correcting exposure errors.
But for interim processing, many more bits are needed. Cumulative roundoff errors are evil, evil, EVIL. This is why most people consider a 24-bit DSP to be an absolute minimum for processing 16-bit audio. 16-bit is below the noise floor for almost all audio equipment to begin with, but if the processing path stays at 16 bits the truncation errors get compounded to the point where you've lost a few bits of resolution by the time you get to the output.
If anything, as other people posted, digital is closer to the "real thing".
One person mentioned that Fuji Velvia is great for landscapes but murders skin tones. This is because the sensitivity curve of a digital can be easily optimized, while it's very difficult to tweak the sensitivity and linearity of films based on chemical reactions.
As to rounding to the nearest bit - There's a lower limit in both electronic and film recording of the precision that a light level can be recorded which is distinguishable from noise. This is called the "noise floor" - Use enough bits, and then all the bit roundoffs will be well below the noise floor of even film media. (Which does indeed have a noise floor, just as digitals do. The nice thing about digitals is that with improved electronics and sensors, the noise floor of the sensor is dropping while film is staying the same. One of the things "pro" digitals are known for is having far less noise than lower-end digitals, and those improvements are constantly moving down to the consumer level.)
And for those that WANT the nonlinearities/quirks of film - All a camera manufacturer has to do is model the nonlinearities of major film types and then they can easily be emulated, just like guitar amps that use modeling techniques to emulate older units.
The biggest advantage to digital is by far the fact that it costs $0 per shot. (Well, maybe a few fractions of a penny for the electricity in the battery...)
So you can dynamically adjust your exposure settings as you shoot. It looks underexposed? Force an overexposure. No more need for an ultra-expensive spot meter.
In an optimal situation, low-speed film will blow away the best digitals. But digital shines in situations with unforgiving lighting, because you can see your results instantly and adjust. And once you get to the ISO 400 region, film quickly starts losing its resolution advantage. While it will take a 11+ MP camera to beat film rated in the ISO 50-100 range, it takes far less to beat ISO 400 film. 800 film? In many cases even a 3 MP digital will begin to win here.
Looks like I was wrong about STK500 prices - They're apparently down to $79 from DigiKey... Very tempted to finally order one, have been planning on doing so for a long time.
America's Choice 300 minute plan is $35/mo, $45/mo only gets you 400 minutes. (Although there's something about 100 bonus minutes...)
Still only 500 and not 700. Those plans are REALLY expensive per minute compared to Sprint, T-Mobile, etc., but those minutes are worth every penny due to Verizon's superior service and coverage.
Atmel (http://www.atmel.com/) AVR series >>>>> Microchip PIC
http://www.digikey.com/ is an excellent source for AVRs. AT90S8515s are around $8 each and a good "Beginner's" uC (Lots of memory, lots of features), from there you can go to smaller uCs such as the AT90S1200 (No RAM, just flash memory for program, some EEPROM, and the CPU registers. Don't worry, it's not x86, there are PLENTY of registers.:) or the ATTiny series.
For those who are willing to try commercial compilers, Codevision is excellent. The professor for Cornell's microcontrollers class loves the compiler (and most students of the class including myself wind up swearing by it by the time they finish with EE 476). Prof. Land has had 1-day turnarounds between bug reports and bug fixes.
http://instruct1.cit.cornell.edu/courses/ee476/ is the webpage for the course and has LOTS of AVR resources as well as some good example code. Sadly, my lab partner and I never got around to tidying up our final project summary for posting on the class website, we also had a POV display, albeit single-color. (Dot-matrix scrolling sign plus a PS/2-to-RS232 converter.)
Also good to have a resistor between the uC pin and the base.
Can't remember NPN or PNP... I really need to brush up on the basics, been spending too much time with upconversion/downconversion of RF and high-speed ADCs...:)
In this case, the transistor sinks rather than sources current. (In many situations, sinking current is easier than sourcing it - This is inherent in most logic/uC output circuits, almost all TTL logic, CMOS logic, and most uCs can sink much more than they can source.
Most of the time, water injection is used in turbocharged/supercharged engines. It is used in place of an aftercooler (usually incorrectly called an intercooler) or to augment a smaller one. Compressing air in a supercharger/turbo heats it, injecting water cools it back down. Air at the same pressure but a lower temperature is more dense = more air fits into the cylinder. Also, since the intake air is cooler, the temperature after compression in the cylinder is lower, so detonation is less likely.
It may be possible in some normally aspirated engines to get a benefit from water injection. Over on the allpar.com forums, one guy was experimenting with it on his Dodge Shadow and getting good results. If it had been anyone else I wouldn't have believed him, but this guy was pretty thorough. Note that he saw no benefit from water injection until he advanced his timing - Essentially water injection was raising the effective octane rating of his fuel, allowing him to advance timing. It would also have allowed for a higher compression ratio without detonation. It could potentially be used as a replacement for lead in older cars that prefer leaded gasoline (Such cars had higher compression ratios, since leaded is less likely to preignite), but I don't know about that.
This might not have been of any benefit on an "optimum" engine like 90% of those on the market today. (Thanks to computer simulations, most engines in newer cars are close to the limits of what can be done in a normally aspirated car without major sacrifices in emissions/driving flexibility/efficiency.) It happened that the 2.2/2.5 Chrysler engines had rather suboptimal intake systems and it didn't take much to improve that model of engine. (Matt also had a ram air intake system that was a major benefit for 2.2/2.5 users but of almost no benefit to most 3.0L V6 users because that engine was a bit more recent and had a better stock intake system to begin with.)
90% of turbocharger systems on the market use an aftercooler. (Usually called an intercooler, but in most situations this isn't actually the correct term - Intercoolers are used in systems with multiple compressor stages, usually fixed generators.)
When gas is pressurized, it heats up. The aftercooler allows this heat to be exchanged to the ambient air, resulting in gas which is close to the same pressure. (Slightly less due to frictional losses in the aftercooler) But since it's cooler, it's more dense than if it were the same pressure (or even slightly higher pressure) at a warmer temperature.
This allows the engine to fit more air into the cylinders without the risk of detonation.
All of that heat given up in the intercooler is mere waste...
A lot could be done for efficiency of cars if someone could figure out a way to use gasoline in a combustion cycle similar to diesel engines. Diesels don't have problems with preignition/detonation, in fact they RELY on the phenomenon that causes it (compression heats the air) in order to ignite the air/fuel mixture. Rather than mixing the air/fuel and then compressing it (and having a risk of the heating from compression alone causing the mix to ignite), diesels compress the gas heavily and THEN inject fuel, which instantly burns because the gases are so hot. (This is why diesels are usually more efficient - They run much higher compression ratios than gasoline engines can.)
Either way, it requires some sort of reference position in order to measure the error.
There's no difference between handheld civilian units and other civilian units. They all use the same signals, with the exception of survey-grade equipment which is not affected by SA to begin with. (That and civilian equipment which is receiving some form of DGPS correction data, whether through the Coast Guard's VLF transmitters in the US, WAAS from geostationary non-military satellites, or any other DGPS source such as dgpsip)
100 meters is more than good enough for automotive navigation if you're paying attention to the road, so who cares about SA?
I've driven in New England without GPS assistance. There were a few times it might've been nice ("How many miles am I from Quincy Market now?"), but it's nothing 100 meters of error would've caused a problem with.
In short: If you're paying attention primarily to the road and your surroundings, 100 meters error won't hurt you at all.
Sounds like fun!
Some Garmin receivers already support WAAS, which is a DGPS variant that uses data from geostationary satellites.
Kinda of hard to knock those out...
Also, terrestrial DGPS is not likely to be targeted by a missle for use in the USA.
DGPS isn't too expensive - Almost any civilian GPS receiver can apply the corrections if they are supplied, and receivers for the Coast Guard broadcasts are only $150-200 I believe. (And have been homebrewed for less.) If you have some form of wireless internet connection, do a search for dgps-ip - Essentially RTCM correction data that can be obtained by connecting to a port on a dgpsip server.
SA was turned off less than three years ago.
Do you realize how long it takes from the initial design stages to general use for a commercial jetliner? A helluva lot longer than three years. Hell, I don't think a jetliner could even get FAA certification in three years from the first prototypes being built.
In short: AIRPLANES HAVE BACKUPS. GPS is currently considered to be the least reliable nav source, precisely because the military can kill the system or enable SA any time they want to. Pilots are required to be able to navigate without GPS and using their eyes only. If you can't navigate based on visual info alone, you don't get your license. Similarly, you don't get your IFR certification unless you can use all of the standard instrumentation that was in use long before GPS became common.
Also, most likely almost any aeronautical GPS will support some form of DGPS, which makes SA semi-irrelevant. As soon as SA turns on, it will be a matter of seconds before updated DGPS info starts coming through. (This is assuming that SA isn't turned on gradually. It most likely will be, in which case users of DGPS in one form or another won't notice a thing.) Locally, the Coast Guard broadcasts DGPS at VLF frequencies in localized areas, and modern Garmins support WAAS, which is a DGPS variant that uses non-military geostationary satellites to broadcast the corrections.
Admittedly, there IS some military data on the civilian frequency, but it's more than possible for the military to get a decent fix if the frequency that carries civilian data is jammed.
The P code is broadcast on two frequencies. This allows the receiver to measure and correct for ionospheric delay, but also allows the military to gain a fix even if one frequency is jammed, at a precision slightly better than that of the unjammed civilian code but worse than normal for military use.
Also, I've read that military receivers are much harder to jam. Most likely the P code is transmitted at higher power, and also military receivers can use a phased-array antenna and some DSP power to reject noise sources not in the direction of a satellite.
People like you shouldn't be driving. The GPS is merely a navigational aid. It doesn't and never should replace KEEPING YOUR EYES ON THE GODDAMNED ROAD. You shouldn't need a GPS to tell you that you're on Foo Avenue - You should be looking at Foo Avenue and double checking that you're on Foo Avenue using these really cool devices called street signs.
that the US turned off SA in the first place to neuter the Galileo project by reducing its perceived need.
Well, the second time the US turned SA off was for that reason.
This article is really amusing because of the fact that the government actually turned SA OFF for the last Gulf War, as there was a shortage of military GPS receivers and soldiers were ordering civilian units mail-order.
The amount of microwave radiation emitting from these things is insignificant.
For one, only the CPU core is running in the GHz range. This is a very small area, and doesn't make a good antenna.
For another, almost all of those high-frequency paths are terminated. As a result all of the power goes into some sort of load (Often the gate of the next transistor), and gets converted to heat and not radiated as RF. You can confirm this by measuring the power input of a CPU and its heat output - Almost all of that power is being turned into heat, so where could RF be coming from? Let's not forget that the heatsink (or heat pipe evaporator) and other parts of the machine make good RF shields.
People make way too big of a deal of RF exposure. Trust me, if it were as dangerous as the "cell phones cause cancer" crowd made it out to be, most of my coworkers would be dead or extremely sick. But they're still healthy even after quite a number of them have been working on RF power amplifiers for 10-20 years. We're regularly exposed to far more RF than a cell phone is likely to emit in our development labs without any problems at all.
BTW, it's more than possible to run modern laptops on your lap if you know what you're doing. In the case of Dell Inspirons, do a search for FanGUI. The BIOS fan speed settings for the Dells are quite agressive as far as maximizing battery life/minimizing noise. (i.e. the CPU has to heat up to around 60 degrees C or more for the fans both to be turned on at their "high" setting.) FanGUI (And a similar tool for Linux) takes over and manages the fan speeds, sacrificing a little battery for much lower temperatures. With FanGUI, I can run full-speed on AC with the unit in my lap without a problem.
That's what I use for my Dell Inspiron 8200.
BTW, Sandia's way behind. Dell has been using heatpipes for close to two years (Maybe longer. The I8000 has heatpipes, so does the 8200).
And yes, they're wicked heatpipes. Non-wicked pipes don't work when the heat source is above the heatsink, but my Dell works fine when tilted backwards.
Finally found the URL for the one utility I've used (Although haven't yet gotten my postprocessing code to work with it - The RINEX file is different enough from the ones recorded in CU's ECE 415 lab that the preprocessor chokes on it.)
n to nio/async/
http://artico.lma.fi.upm.es/numerico/miembros/a
While it's hard/impossible to obtain a receiver that can directly use the P code, it IS possible for a civilian receiver to use the encrypted P code for additional accuracy without decrypting it.
i n.htm and http://www.nottingham.ac.uk/iessg/gringo/
The civilian C/A codes are only broadcast on one frequency. Both the C/A and P codes are pseudorandom bit sequences designed to have a very high peak in their self-correlation function. (Effectively turning the CW transmitters on the satellites into high-power pulse transmitters as far as SNR requirements at the receiver.) The encrypted P code has a much lower peak in its self-correlation function, but it STILL has a peak.
The C/A code is only broadcast on one frequency, while the P code is broadcast on two frequencies. Why? Because one of the leading sources of error in GPS reception when SA is turned off is the fact that the ionosphere delays the signal. Fortunately, the ionospheric delay is a linear function of the frequency. (I.e. a signal at 1.7 GHz is delayed 1.7/1.2 times as much as a signal at 1.2 GHz). So, a military receiver can measure the delay between the two frequencies, and from that calculate the ionospheric delay.
Now go back to the fact that even the encrypted code has a peak in its self-correlation function. A high-end civilian (usually surveying) receiver can receive the encrypted P-codes and correlate them (since they happen to be identical). Since the self-correlation peak of the encrypted code is much lower, the signal strength must be higher than that for unencrypted codes and the process is SLOW, but it can be done. Receivers capable of this cost $$$$$$. (For example, in the GPS lab at Cornell University, they have only 1-2 dual-frequency receivers, while they have plenty of single-frequency receivers on ISA cards to allow for advanced postprocessing of data.)
As far as SA - Even when SA is on, it's possible to get millimeter accuracy from a civilian receiver, using the same techniques needed to get millimeter accuracy from a civilian receiver with SA off. The most important thing is a "reference receiver" nearby - One whose location is precisely known. This receiver can measure all of the errors generated by the satellites, which can be used later to postprocess the data from a remote receiver and correct it.
In addition to clock dithering, SA puts errors in the satellite ephemerides (The description of their orbits). It's possible to download precise (even better than non-SA) ephemerides from various standards organizations for post processing.
Want to try post-processing yourself? Until recently, the answer was "tough luck" with the exception of expensive receivers and the Delorme Earthmate. Only the Earthmate allowed the user to capture raw pseudorange data (The data needed to obtain a navigation fix) for later processing. Fortunately, some people found out that it was possible to obtain pseudorange data from 12-channel Garmin civilian receivers by using some undocumented commands. See http://mywebpages.comcast.net/dmilbert/softs/g12r
On one hand, we should've gotten rid of Saddam the first time around. I agree that he needs to go and something needs to be done about him (and should've been done long ago).
On the other hand, I don't think that it should be done at the cost of pissing off the entire fucking planet in the process, while ignoring the fact that our economy is in a hole, and the uncertainty about Iraq (Both in general paranoia and in oil prices) is killing what's left of our economy.
Screw Iraq. Bomb Florida, this is all their fault.
This already exists to some degree - Modern 3D cards have internal pixel pipelines of 16+ bits/color. The latest (GeForceFX and I think also the Radeon) have moved to internal floating-point representation, doesn't get much more accurate than double-precision FP. Even single-precision is insane compared to 8 bits/color.
Also, at the output stage, not much more than 8 bits/color is needed. At input, more than 8 bits/color would be useful for correcting exposure errors.
But for interim processing, many more bits are needed. Cumulative roundoff errors are evil, evil, EVIL. This is why most people consider a 24-bit DSP to be an absolute minimum for processing 16-bit audio. 16-bit is below the noise floor for almost all audio equipment to begin with, but if the processing path stays at 16 bits the truncation errors get compounded to the point where you've lost a few bits of resolution by the time you get to the output.
If anything, as other people posted, digital is closer to the "real thing".
One person mentioned that Fuji Velvia is great for landscapes but murders skin tones. This is because the sensitivity curve of a digital can be easily optimized, while it's very difficult to tweak the sensitivity and linearity of films based on chemical reactions.
As to rounding to the nearest bit - There's a lower limit in both electronic and film recording of the precision that a light level can be recorded which is distinguishable from noise. This is called the "noise floor" - Use enough bits, and then all the bit roundoffs will be well below the noise floor of even film media. (Which does indeed have a noise floor, just as digitals do. The nice thing about digitals is that with improved electronics and sensors, the noise floor of the sensor is dropping while film is staying the same. One of the things "pro" digitals are known for is having far less noise than lower-end digitals, and those improvements are constantly moving down to the consumer level.)
And for those that WANT the nonlinearities/quirks of film - All a camera manufacturer has to do is model the nonlinearities of major film types and then they can easily be emulated, just like guitar amps that use modeling techniques to emulate older units.
I was comparing to 35mm here.
Medium format, OTOH, isn't going away for a long time. Large format will live even longer.
The biggest advantage to digital is by far the fact that it costs $0 per shot. (Well, maybe a few fractions of a penny for the electricity in the battery...)
So you can dynamically adjust your exposure settings as you shoot. It looks underexposed? Force an overexposure. No more need for an ultra-expensive spot meter.
In an optimal situation, low-speed film will blow away the best digitals. But digital shines in situations with unforgiving lighting, because you can see your results instantly and adjust. And once you get to the ISO 400 region, film quickly starts losing its resolution advantage. While it will take a 11+ MP camera to beat film rated in the ISO 50-100 range, it takes far less to beat ISO 400 film. 800 film? In many cases even a 3 MP digital will begin to win here.
Looks like I was wrong about STK500 prices - They're apparently down to $79 from DigiKey... Very tempted to finally order one, have been planning on doing so for a long time.
America's Choice 300 minute plan is $35/mo, $45/mo only gets you 400 minutes. (Although there's something about 100 bonus minutes...)
Still only 500 and not 700. Those plans are REALLY expensive per minute compared to Sprint, T-Mobile, etc., but those minutes are worth every penny due to Verizon's superior service and coverage.
Atmel (http://www.atmel.com/) AVR series >>>>> Microchip PIC
:) or the ATTiny series.
http://www.digikey.com/ is an excellent source for AVRs. AT90S8515s are around $8 each and a good "Beginner's" uC (Lots of memory, lots of features), from there you can go to smaller uCs such as the AT90S1200 (No RAM, just flash memory for program, some EEPROM, and the CPU registers. Don't worry, it's not x86, there are PLENTY of registers.
For those who are willing to try commercial compilers, Codevision is excellent. The professor for Cornell's microcontrollers class loves the compiler (and most students of the class including myself wind up swearing by it by the time they finish with EE 476). Prof. Land has had 1-day turnarounds between bug reports and bug fixes.
http://instruct1.cit.cornell.edu/courses/ee476/ is the webpage for the course and has LOTS of AVR resources as well as some good example code. Sadly, my lab partner and I never got around to tidying up our final project summary for posting on the class website, we also had a POV display, albeit single-color. (Dot-matrix scrolling sign plus a PS/2-to-RS232 converter.)
Power connected to LED via resistor.
:)
Transistor between LED and ground.
Also good to have a resistor between the uC pin and the base.
Can't remember NPN or PNP... I really need to brush up on the basics, been spending too much time with upconversion/downconversion of RF and high-speed ADCs...
In this case, the transistor sinks rather than sources current. (In many situations, sinking current is easier than sourcing it - This is inherent in most logic/uC output circuits, almost all TTL logic, CMOS logic, and most uCs can sink much more than they can source.