It's a PAIN to install and get running, but DAMN is it worth it!
A similar technique to the distcc + cygwin install can be used to allow a distcc host to provide a GCC version other than its system GCC version. For example, my setup: 1.7 GHz P4-M (Gentoo box, always is the controlling node) 1.1 GHz Athlon (RedHat 7.3, sys GCC is 2.96, but I have a 3.3 tree in another location that won't interfere with the 2.96 tree) WinXP box with an Athlon XP 1?00+
The XP box has 256M RAM, the other two 512M. Works great.
An actual nuclear explosion - No on that count either.
Chernobyl was a steam explosion, followed by days of slow combustion of radioactive material. (i.e. once the lid blew off the reactor, which wouldn't have been THAT bad, the superheated graphite came in contact with air and began burning instantly - THAT was what spread the majority of the radiation.)
If the same thing had happened in a U.S. civilian power reactor, the steam explosion would have been contained within the reactor containment building and there would have been no graphite to combust. (Such a steam explosion in a U.S. civilian reactor would have been even harder to create than the one the idiots running Chernobyl created, due to reactor design differences. Using a graphite moderator is unsafe for a multitude of reasons, the final reason being that it burns readily.)
I believe nuclear warheads have so many safety features designed in to prevent detonation that you could shoot it with a gun/drop it off a cliff/set off an explosion next to it, and it wouldn't detonate.
Making a warhead detonate with full yield requires a very precise conventional explosion to compress the nuclear material. Unless a warhead is intentionally detonated, the chances of it exploding with full yield are slim to non. (At worst you'll have a "dirty bomb" rather than a nuclear explosion.)
I'm lucky - Most Cornell engineering students got a tour of the Ward Lab reactor facility their freshman year as part of a required engineering seminar. The view down into the pool was breathtaking.
The reactor was shut down permanently my senior year.
Trust me... I live in an area where car/deer collisions are frequent. We used to use the whistles, but 8-10 years ago we stopped replacing them when the adhesive wore out and they fell off our cars.
Death toll estimates I've seen elsewhere are WAY higher.
If you look at her site, 3500 would almost be entirely accounted for only by the people who refused to leave the dead zone. (3500 stayed, 400 still alive.)
I've seen death toll estimates in the hundreds of thousands (long-term, that is.)
In addition, you need to know the precise location of your GPS antenna. This can be tough. The necessary accuracy for your reference position usually require a receiver more expensive than one capable of providing the pseudoranges from which differential corrections can be calculated.
(These days, it's possible to get a receiver capable of providing pseudoranges relatively cheaply, although sometimes in an undocumented fashion, for example obtaining pseudoranges from Garmin receivers via gar2rnx. Surveying your antenna location to within millimeters is a different story... Cheap receivers cycle-slip often enough that obtaining a millimeter-accuracy solution can be very difficult.)
Galileo was shaping up to become a reality around May of 2000. (i.e. the Europeans were getting REAL serious about putting up their own positioning system.)
Guess when SA was turned off? Guess how fast Galileo turned into a dead project after SA was turned off?
Nowadays, even if SA is turned back on, it probably won't mean much. DGPS has become far more common than just the USCG stations. (For example, WAAS/EGNOS/whatever the Japanese call their system, all three are identical with different names, which are a form of DGPS.)
Differential GPS sends corrections for errors in the pseudoranges for each satellite (and in some cases, sends improved ephemerides for predicting the sat's orbit).
It can be mathematically shown that "Poor man's DGPS", i.e. "This is the lat/long the GPS says I'm at, this is my real lat/long" does not work, and may even degrade accuracy.
The good news is it's getting easier and easier to create a DGPS source. In the past, it was impossible to get raw pseudorange data from economical receivers. But nowadays, many sub-$200 OEM units are capable of it, as are some handhelds.
These are "cheap" receivers that I know of that allow for raw pseudorange and carrier phase logging:
Garmin 12-channel (Undocumented and unsupported, but it can be done. I've done it myself. Do a search for gar2rnx).
Rockwell Jupiter (Best example is the Delorme Earthmate, which Delorme advertises as being able to provide raw pseudorange/carrier data if you buy their software, GPS PostPro) u-blox modules, I believe.
I believe the "GPS-2" referred to above is proposals I've heard to put the C/A (coarse acquisition) code on the second GPS frequency (L2) in addition to L1.
Currently only military receivers and special receivers that use extra processing tricks (aforementioned $20k Trimbles, NoVaTels, etc.) are capable of using the current L2 transmissions.
The advantage of a dual-frequency receiver is that ionospheric delay (a significant contributor to GPS error now that SA is turned off) is a linear function of frequency. Measure the difference in arrival between the pseudocodes on two different frequencies, and you can figure out the absolute ionospheric delay at a given frequency.
The end result is increased accuracy without the need for differential corrections. (Right now, L1-only receivers must rely on DGPS to eliminate errors from ionospheric delay. A dual-frequency receiver can eliminate those errors without external information.)
I went caching in the desert (where in most cases a clear view of the entire sky results in very high GPS accuracy - I've seen my GPS be accurate to within 5 feet on some caches...), and there were cases where I would literally be standing on top of the cache and not see it.
One of the best was a cache at the top of a canyon. The first time I went there, I thought my GPS was just being inaccurate and the cache was at the bottom. That would've been too easy.
You could park 100 feet from the cache, but you had to hike.4 miles up the canyon and then.4 miles back along the rim to reach it. Once you got to it, it was a buried can sitting under a rock.
There are lots of rocks - Even close-up, this one was almost indistinguishable from any other.
East Coast geocachers are usually not so evil, probably due to the fact that those caches are in the woods and they know that their GPS units and those of the cache finders won't be as accurate. I know of one cache that can only be found at certain times due to the fact that it's in a gorge and over half the time you can't receive signals from enough satellites for even a 2-D fix down there.
"1. RTFA: I quote the relevant portion: "The scheme, the authors claimed, could double data throughput for a given transmitting power or, alternatively, achieve a specified communications data rate with half the transmitting energy" "
In this case, the article is wrong. Articles can have errors, you know.
You can have either of the two benefits mentioned above, but not both.
Shannon's theorem C = B * log(1+SNR) is the theoretical maximum.
The practical maximum for a given coding scheme can be thought of as C = B * log(1 + SNR * somefactor)
Which translates (approximately) to C = B * (log(1+SNR) + log(somefactor)) for relatively large SNR. (Given that SNRs for most comm. systems are in excess of 10-20 dB, i.e. a factor of 10-100, this is a safe assumption)
With old coding schemes, the practical limit was around 3.5 dB below Shannon's limit. Thus C = B * (log(1 + SNR) -.35)
(since dBs are 10*log() instead of log())
Turbo codes bring us to within 0.5 dB or so of the theoretical max.
Thus C = B * (log(1 + SNR) - 0.05)
Thus turbo codes will require 3 dB less (half as much) power (half the SNR) to achieve a given ratio of C to B.
Assuming power (and hence SNR) constant, turbo codes will NOT double the ratio of C to B, unless the SNR is very low. At high SNRs, they will make very little difference at all if power (SNR) is kept constant.
Note that the above equations are very quick and dirty approximations, but they illustrate the effects of the log() in Shannon's Theorem, both in the theoretical sense and in practical applications. i.e. doubling power (Turbo codes essentially double your "effective" power) does NOT double channel capacity.
This is why AT&T shot themselves in the foot by rolling out 2G/2.5G GSM when 3G was on the horizon - They rolled out an entire new network, when they knew that 2-3 yeards down the line, they would have to roll out YET ANOTHER network because UMTS and oldschool GSM use entirely different modulation techniques and band allocations.
Meanwhile CDMA2000 (2.5G/3G) and cdmaOne (2G) are entirely forwards and backwards compatible. cdmaOne phones will work with CDMA2000 towers (just without the CDMA2000 functionality), with no impact on the towers' ability to service actual CDMA2000 phones, and a CDMA2000 phone will work just fine with a cdmaOne tower.
End result, network providers who are smart and choose CDMA can upgrade their network piece by piece as needed, and not have to force customers to upgrade phones, plus people with CDMA2000 phones will have (at least) voice and low-speed data service in areas that only have cdmaOne coverage, whereas a user with a UMTS phone will be SOL trying to communicate with any of their provider's older towers.
My advice - if service quality and coverage mean anything to you, Verizon is the only choice. VZW has never ceased to amaze me with some of the places I've been able to get a digital signal. (miles and miles away from the nearest AT&T, Cingular, T-Mobile, or Sprint coverage.)
It's been a known fact for a while that most of the major distros have been looking for an alternative to XFree86 thanks to the license change.
I'm predicting that it'll be a matter of weeks before Gentoo, Debian, etc. follow suit. It was a matter of time before someone made this plunge, Fedora just happened to be the first.
There really aren't many other choices. The fd.org experimental server isn't ready for primetime Sticking with old versions of XFree isn't a long-term option. X.org seems to be the most mature branch with a decent license, and it sounds like a lot of former XFree developers have already jumped ship and are working on the X.org tree.
I'm expecting that the majority of distros will very quickly follow Fedora.
I know for a fact that Debian, Gentoo, and a few others are specifically NOT touching XFree86 4.4 (i.e. post-license-change), and are looking for alternatives.
X.org sounds like it is currently the most mature alternative, and will likely have the marketshare XFree86 does within months, unless David Dawes pulls his head out of his ass and stops shooting himself in the foot. He doesn't seem to realize that his license change is going to make XFree86 a defunct project VERY quickly.
Take a trip to the Mojave. Or Anza-Borrego Desert State Park three hours south.
There's a hell of a lot more than cacti to do serious damage to an ORV. The lack of vegetation means that rainstorms almost always bring flash floods, which means that there are some insane erosion patterns, plus large boulders scattered randomly about.
Even if they had Red Team's expertise and electronics, chances are their Acura MDX (a luxury SUV, inherently NOT a good off-road vehicle) would not have made it as far as Red Team's HMMMV or SciAutonics' dune buggy. Hell, even with a human driver, an MDX would probably not have been able to finish the race.
Also, even with a human driver, even some of the best offroad vehicles are prone to mechanical failure in the wrong terrain. (Trust me, the deserts of California and Nevada meet the classifcation of the "wrong terrain" in many cases.) For example, the Moab Easter Jeep Safari rates some of their trails as "25% of vehicles suffer catastrophic failure" - This is with heavily modified offroad vehicles driven by experienced drivers. The terrain can simply be Just Plain Nasty.
There are plenty of offroad trails (Like the Rubicon) where the average speed is probably 5 MPH... And there are sections of such trails where it probably will take 30 minutes to travel a few hundred feet.
Knowing when to drive fast and when to drive slow can be a tough decision, even for a human. Very often bad terrain can appear far less dangerous for the vehicle than it really is. (Actually, this is one case where an AUV probably has an advantage, a good LIDAR system will do far better than a human eye in detecting such terrain.)
Do a Google search for "Moab Jeep Safari" (Might be Easter Jeep Safari).
The EJS uses a trail rating from Class 1 to Class 5 (at least used to, it may have changed.)
FYI, Moab, UT is pretty much in the desert.
Class 1 is basically a paved road
Class 5 is defined as "25% of vehicles suffer catastrophic failure". That is AFTER excluding "stock" vehicles - which the trail ratings reccommend staying on class 3.5 and below trails.
I fully agree, as someone who is on vacation in the desert (Borrego Springs State Park in California, about 3 hours south of Barstow where the race began), desert offroading is NOT easy. Even on the 4x4 "roads", there are sections that are challenging for a human driver with a stock vehicle. Leave the "roads" (often nothing more than a dried stream bed) and even the most heavily modified ORVs will have trouble on much of the terrain.
For example, a course that an '89 Mitsubishi Montero or an older (pre-SUV-fad) Toyota Land Cruiser, or Red Team's Hummer (not the H2 Fake Hummer) would have no trouble with would most likely be impassable for an Acura MDX. (oops... Sorry PVHS, BAD vehicle choice...)
SciAutonics probably had one of the best base vehicles that I have seen pictures of so far - Their vehicle was even better suited to off-road travel than Red Team's Hummer, and it looked like it was a jacked-up dune buggy. (i.e. a common and standard design.)
FYI, this applies not to compression of data, but to error correction. It's assumed with turbo codes that there is no redundancy in the information being encoded. (In reality there may be, but that's a completely different problem.)
i.e. a communications system is always optimized to maximize performance with a bitstream that is assumed to be non-redundant.
Turbo codes are a method for error correction, not compression. In fact, they do the exact opposite of compression - they ADD redundant data.
As to a limit - Turbo codes have performance within 0.5 dB of SNR of Shannon's limit for a given channel. Can't do much better. (Although it may be possible to come up with a coding scheme that is less computationally intensive/has less latency)
Actually, "turbo" in turbocharger derives from the fact that a turbocharger uses an exhaust-driven turbine to provide power to the compressor.
As explained earlier, turbo codes were named because they use a positive feedback loop to improve their performance, just like a turbocharger, even though in the strictest sense of using the word "turbo", it is inappropriate since "turbo" implies the use of a turbine somewhere.
If you read the article (Not sure if that's possible to do without paying $$$ unless you're an IEEE member, in which case you have it in dead-tree format and can access it for free online), the reason they were called "turbo" codes was because one of the creators of turbo codes was apparently a big automotive racing fan.
Part of the turbo coding system involves a feedback loop between two seperate decoders at the receiver. The feedback from each decoder helps the other decoder make a better decision about the data.
Similarly, a turbocharger relies on feedback to operate. Exhaust pressure spins the turbo, which is used to compress intake air to the engine, increasing the amount of fuel that can be burned. More fuel/air being burned in the cylinders means more exhaust gases being pushed out, which results in a positive feedback loop that increases power until something is done to interrupt the loop. (Usually a wastegate that dumps the exhaust gas in a path that bypasses the turbine once the pressure reaches a certain threshold.)
Thus while the naming of "turbo" codes isn't completely appropriate (no turbine...), it is far more appropriate than the old inappropriate association of the word "turbo" with anything fast.
Great amounts of precision are needed, but the fact is that the feature size is so small that what seem to be miniscule variations in the manufacturing process have HUGE effects on the operation of a chip.
Do you realize that many fabs consider 60% yield to be incredibly good? i.e. 40% of the chips on a wafer MAY NOT WORK AT ALL.
The machinery used is extremely precise, but the wafers are also EXTREMELY sensitive to errors. On tiny speck of dust can ruin a chip - And there's only so much dust even the best filtration technologies can remove, for example.
Slashdot Mirror
It's a PAIN to install and get running, but DAMN is it worth it!
A similar technique to the distcc + cygwin install can be used to allow a distcc host to provide a GCC version other than its system GCC version. For example, my setup:
1.7 GHz P4-M (Gentoo box, always is the controlling node)
1.1 GHz Athlon (RedHat 7.3, sys GCC is 2.96, but I have a 3.3 tree in another location that won't interfere with the 2.96 tree)
WinXP box with an Athlon XP 1?00+
The XP box has 256M RAM, the other two 512M. Works great.
Contained - hell no.
An actual nuclear explosion - No on that count either.
Chernobyl was a steam explosion, followed by days of slow combustion of radioactive material. (i.e. once the lid blew off the reactor, which wouldn't have been THAT bad, the superheated graphite came in contact with air and began burning instantly - THAT was what spread the majority of the radiation.)
If the same thing had happened in a U.S. civilian power reactor, the steam explosion would have been contained within the reactor containment building and there would have been no graphite to combust. (Such a steam explosion in a U.S. civilian reactor would have been even harder to create than the one the idiots running Chernobyl created, due to reactor design differences. Using a graphite moderator is unsafe for a multitude of reasons, the final reason being that it burns readily.)
I believe nuclear warheads have so many safety features designed in to prevent detonation that you could shoot it with a gun/drop it off a cliff/set off an explosion next to it, and it wouldn't detonate.
Making a warhead detonate with full yield requires a very precise conventional explosion to compress the nuclear material. Unless a warhead is intentionally detonated, the chances of it exploding with full yield are slim to non. (At worst you'll have a "dirty bomb" rather than a nuclear explosion.)
They don't.
I'm lucky - Most Cornell engineering students got a tour of the Ward Lab reactor facility their freshman year as part of a required engineering seminar. The view down into the pool was breathtaking.
The reactor was shut down permanently my senior year.
Those things do NOT work.
Trust me... I live in an area where car/deer collisions are frequent. We used to use the whistles, but 8-10 years ago we stopped replacing them when the adhesive wore out and they fell off our cars.
Death toll estimates I've seen elsewhere are WAY higher.
If you look at her site, 3500 would almost be entirely accounted for only by the people who refused to leave the dead zone. (3500 stayed, 400 still alive.)
I've seen death toll estimates in the hundreds of thousands (long-term, that is.)
In addition, you need to know the precise location of your GPS antenna. This can be tough. The necessary accuracy for your reference position usually require a receiver more expensive than one capable of providing the pseudoranges from which differential corrections can be calculated.
(These days, it's possible to get a receiver capable of providing pseudoranges relatively cheaply, although sometimes in an undocumented fashion, for example obtaining pseudoranges from Garmin receivers via gar2rnx. Surveying your antenna location to within millimeters is a different story... Cheap receivers cycle-slip often enough that obtaining a millimeter-accuracy solution can be very difficult.)
Galileo was shaping up to become a reality around May of 2000. (i.e. the Europeans were getting REAL serious about putting up their own positioning system.)
Guess when SA was turned off? Guess how fast Galileo turned into a dead project after SA was turned off?
Nowadays, even if SA is turned back on, it probably won't mean much. DGPS has become far more common than just the USCG stations. (For example, WAAS/EGNOS/whatever the Japanese call their system, all three are identical with different names, which are a form of DGPS.)
Differential GPS sends corrections for errors in the pseudoranges for each satellite (and in some cases, sends improved ephemerides for predicting the sat's orbit).
It can be mathematically shown that "Poor man's DGPS", i.e. "This is the lat/long the GPS says I'm at, this is my real lat/long" does not work, and may even degrade accuracy.
The good news is it's getting easier and easier to create a DGPS source. In the past, it was impossible to get raw pseudorange data from economical receivers. But nowadays, many sub-$200 OEM units are capable of it, as are some handhelds.
These are "cheap" receivers that I know of that allow for raw pseudorange and carrier phase logging:
Garmin 12-channel (Undocumented and unsupported, but it can be done. I've done it myself. Do a search for gar2rnx).
Rockwell Jupiter (Best example is the Delorme Earthmate, which Delorme advertises as being able to provide raw pseudorange/carrier data if you buy their software, GPS PostPro)
u-blox modules, I believe.
I believe the "GPS-2" referred to above is proposals I've heard to put the C/A (coarse acquisition) code on the second GPS frequency (L2) in addition to L1.
Currently only military receivers and special receivers that use extra processing tricks (aforementioned $20k Trimbles, NoVaTels, etc.) are capable of using the current L2 transmissions.
The advantage of a dual-frequency receiver is that ionospheric delay (a significant contributor to GPS error now that SA is turned off) is a linear function of frequency. Measure the difference in arrival between the pseudocodes on two different frequencies, and you can figure out the absolute ionospheric delay at a given frequency.
The end result is increased accuracy without the need for differential corrections. (Right now, L1-only receivers must rely on DGPS to eliminate errors from ionospheric delay. A dual-frequency receiver can eliminate those errors without external information.)
I went caching in the desert (where in most cases a clear view of the entire sky results in very high GPS accuracy - I've seen my GPS be accurate to within 5 feet on some caches...), and there were cases where I would literally be standing on top of the cache and not see it.
.4 miles up the canyon and then .4 miles back along the rim to reach it. Once you got to it, it was a buried can sitting under a rock.
One of the best was a cache at the top of a canyon. The first time I went there, I thought my GPS was just being inaccurate and the cache was at the bottom. That would've been too easy.
You could park 100 feet from the cache, but you had to hike
There are lots of rocks - Even close-up, this one was almost indistinguishable from any other.
East Coast geocachers are usually not so evil, probably due to the fact that those caches are in the woods and they know that their GPS units and those of the cache finders won't be as accurate. I know of one cache that can only be found at certain times due to the fact that it's in a gorge and over half the time you can't receive signals from enough satellites for even a 2-D fix down there.
"1. RTFA: I quote the relevant portion: "The scheme, the authors claimed, could double data throughput for a given transmitting power or, alternatively, achieve a specified communications data rate with half the transmitting energy" "
.35)
In this case, the article is wrong. Articles can have errors, you know.
You can have either of the two benefits mentioned above, but not both.
Shannon's theorem C = B * log(1+SNR) is the theoretical maximum.
The practical maximum for a given coding scheme can be thought of as
C = B * log(1 + SNR * somefactor)
Which translates (approximately) to C = B * (log(1+SNR) + log(somefactor)) for relatively large SNR. (Given that SNRs for most comm. systems are in excess of 10-20 dB, i.e. a factor of 10-100, this is a safe assumption)
With old coding schemes, the practical limit was around 3.5 dB below Shannon's limit. Thus
C = B * (log(1 + SNR) -
(since dBs are 10*log() instead of log())
Turbo codes bring us to within 0.5 dB or so of the theoretical max.
Thus C = B * (log(1 + SNR) - 0.05)
Thus turbo codes will require 3 dB less (half as much) power (half the SNR) to achieve a given ratio of C to B.
Assuming power (and hence SNR) constant, turbo codes will NOT double the ratio of C to B, unless the SNR is very low. At high SNRs, they will make very little difference at all if power (SNR) is kept constant.
Note that the above equations are very quick and dirty approximations, but they illustrate the effects of the log() in Shannon's Theorem, both in the theoretical sense and in practical applications. i.e. doubling power (Turbo codes essentially double your "effective" power) does NOT double channel capacity.
3G GSM is UMTS, which is a form of CDMA.
This is why AT&T shot themselves in the foot by rolling out 2G/2.5G GSM when 3G was on the horizon - They rolled out an entire new network, when they knew that 2-3 yeards down the line, they would have to roll out YET ANOTHER network because UMTS and oldschool GSM use entirely different modulation techniques and band allocations.
Meanwhile CDMA2000 (2.5G/3G) and cdmaOne (2G) are entirely forwards and backwards compatible. cdmaOne phones will work with CDMA2000 towers (just without the CDMA2000 functionality), with no impact on the towers' ability to service actual CDMA2000 phones, and a CDMA2000 phone will work just fine with a cdmaOne tower.
End result, network providers who are smart and choose CDMA can upgrade their network piece by piece as needed, and not have to force customers to upgrade phones, plus people with CDMA2000 phones will have (at least) voice and low-speed data service in areas that only have cdmaOne coverage, whereas a user with a UMTS phone will be SOL trying to communicate with any of their provider's older towers.
My advice - if service quality and coverage mean anything to you, Verizon is the only choice. VZW has never ceased to amaze me with some of the places I've been able to get a digital signal. (miles and miles away from the nearest AT&T, Cingular, T-Mobile, or Sprint coverage.)
It's been a known fact for a while that most of the major distros have been looking for an alternative to XFree86 thanks to the license change.
I'm predicting that it'll be a matter of weeks before Gentoo, Debian, etc. follow suit. It was a matter of time before someone made this plunge, Fedora just happened to be the first.
There really aren't many other choices.
The fd.org experimental server isn't ready for primetime
Sticking with old versions of XFree isn't a long-term option.
X.org seems to be the most mature branch with a decent license, and it sounds like a lot of former XFree developers have already jumped ship and are working on the X.org tree.
I'm expecting that the majority of distros will very quickly follow Fedora.
I know for a fact that Debian, Gentoo, and a few others are specifically NOT touching XFree86 4.4 (i.e. post-license-change), and are looking for alternatives.
X.org sounds like it is currently the most mature alternative, and will likely have the marketshare XFree86 does within months, unless David Dawes pulls his head out of his ass and stops shooting himself in the foot. He doesn't seem to realize that his license change is going to make XFree86 a defunct project VERY quickly.
Take a trip to the Mojave. Or Anza-Borrego Desert State Park three hours south.
There's a hell of a lot more than cacti to do serious damage to an ORV. The lack of vegetation means that rainstorms almost always bring flash floods, which means that there are some insane erosion patterns, plus large boulders scattered randomly about.
Even if they had Red Team's expertise and electronics, chances are their Acura MDX (a luxury SUV, inherently NOT a good off-road vehicle) would not have made it as far as Red Team's HMMMV or SciAutonics' dune buggy. Hell, even with a human driver, an MDX would probably not have been able to finish the race.
Also, even with a human driver, even some of the best offroad vehicles are prone to mechanical failure in the wrong terrain. (Trust me, the deserts of California and Nevada meet the classifcation of the "wrong terrain" in many cases.) For example, the Moab Easter Jeep Safari rates some of their trails as "25% of vehicles suffer catastrophic failure" - This is with heavily modified offroad vehicles driven by experienced drivers. The terrain can simply be Just Plain Nasty.
There are plenty of offroad trails (Like the Rubicon) where the average speed is probably 5 MPH... And there are sections of such trails where it probably will take 30 minutes to travel a few hundred feet.
Knowing when to drive fast and when to drive slow can be a tough decision, even for a human. Very often bad terrain can appear far less dangerous for the vehicle than it really is. (Actually, this is one case where an AUV probably has an advantage, a good LIDAR system will do far better than a human eye in detecting such terrain.)
Do a Google search for "Moab Jeep Safari" (Might be Easter Jeep Safari).
The EJS uses a trail rating from Class 1 to Class 5 (at least used to, it may have changed.)
FYI, Moab, UT is pretty much in the desert.
Class 1 is basically a paved road
Class 5 is defined as "25% of vehicles suffer catastrophic failure". That is AFTER excluding "stock" vehicles - which the trail ratings reccommend staying on class 3.5 and below trails.
I fully agree, as someone who is on vacation in the desert (Borrego Springs State Park in California, about 3 hours south of Barstow where the race began), desert offroading is NOT easy. Even on the 4x4 "roads", there are sections that are challenging for a human driver with a stock vehicle. Leave the "roads" (often nothing more than a dried stream bed) and even the most heavily modified ORVs will have trouble on much of the terrain.
SUVs vary greatly these days.
For example, a course that an '89 Mitsubishi Montero or an older (pre-SUV-fad) Toyota Land Cruiser, or Red Team's Hummer (not the H2 Fake Hummer) would have no trouble with would most likely be impassable for an Acura MDX. (oops... Sorry PVHS, BAD vehicle choice...)
SciAutonics probably had one of the best base vehicles that I have seen pictures of so far - Their vehicle was even better suited to off-road travel than Red Team's Hummer, and it looked like it was a jacked-up dune buggy. (i.e. a common and standard design.)
FYI, this applies not to compression of data, but to error correction. It's assumed with turbo codes that there is no redundancy in the information being encoded. (In reality there may be, but that's a completely different problem.)
i.e. a communications system is always optimized to maximize performance with a bitstream that is assumed to be non-redundant.
Turbo codes are a method for error correction, not compression. In fact, they do the exact opposite of compression - they ADD redundant data.
As to a limit - Turbo codes have performance within 0.5 dB of SNR of Shannon's limit for a given channel. Can't do much better. (Although it may be possible to come up with a coding scheme that is less computationally intensive/has less latency)
Doubling power does not double available channel capacity.
Note the log(1 + SNR) in Shannon's theorem...
Actually, "turbo" in turbocharger derives from the fact that a turbocharger uses an exhaust-driven turbine to provide power to the compressor.
As explained earlier, turbo codes were named because they use a positive feedback loop to improve their performance, just like a turbocharger, even though in the strictest sense of using the word "turbo", it is inappropriate since "turbo" implies the use of a turbine somewhere.
If you read the article (Not sure if that's possible to do without paying $$$ unless you're an IEEE member, in which case you have it in dead-tree format and can access it for free online), the reason they were called "turbo" codes was because one of the creators of turbo codes was apparently a big automotive racing fan.
Part of the turbo coding system involves a feedback loop between two seperate decoders at the receiver. The feedback from each decoder helps the other decoder make a better decision about the data.
Similarly, a turbocharger relies on feedback to operate. Exhaust pressure spins the turbo, which is used to compress intake air to the engine, increasing the amount of fuel that can be burned. More fuel/air being burned in the cylinders means more exhaust gases being pushed out, which results in a positive feedback loop that increases power until something is done to interrupt the loop. (Usually a wastegate that dumps the exhaust gas in a path that bypasses the turbine once the pressure reaches a certain threshold.)
Thus while the naming of "turbo" codes isn't completely appropriate (no turbine...), it is far more appropriate than the old inappropriate association of the word "turbo" with anything fast.
Great amounts of precision are needed, but the fact is that the feature size is so small that what seem to be miniscule variations in the manufacturing process have HUGE effects on the operation of a chip.
Do you realize that many fabs consider 60% yield to be incredibly good? i.e. 40% of the chips on a wafer MAY NOT WORK AT ALL.
The machinery used is extremely precise, but the wafers are also EXTREMELY sensitive to errors. On tiny speck of dust can ruin a chip - And there's only so much dust even the best filtration technologies can remove, for example.