50 kWh is a good, useful capacity for EVs in general. So it's probably not targeted specifically at the Tesla Roadster but for EVs in general. Should give about a 200 mile range depending on vehicle efficiencies. Given that most people commute less than about 40 miles per day, 200 miles of range is more than enough for most daily driving.
It's incorrect to say that capacitor storage will drastically increase the energy recovered from braking in an electric or hybrid vehicle compared to battery storage. The problem is that both the inverter (power transistor) electronics and motor have efficiency losses on the order of 5 to 7% each. Batteries do have additional losses when charging or discharging of about 15% in each direction, which a capacitor largely avoids, but there are still significant losses from the motor and power transistors. Remember those losses get applied twice, both then regenerating (decelerating the vehicle) and when using the energy to accelerate the vehicle again. There are also significant losses in the gears, tires, etc.
There ain't no such thing as a free lunch. If regenerative braking and acceleration in an EV or hybrid were 100% efficient, they would be perpetual motion machines.
That said, capacitors would allow and EV to make use of significantly more regenerative braking energy than a battery electric vehicle. But the overall improvement is going from about 50% efficiency to 70% or about a 20% range improvement. That is very significant, but it's not perpetual motion and can't be due to the other losses.
That also said, practical capacitors would be a major shift in how we use energy for transporation and in general.
Which is fine if you consider refilling your car's liquid nitrogen tank to be more convenient than charging batteries:
American Superconductor Corporation (NASDAQ:AMSC - News), a leading energy technologies company, announced today it has achieved commercial levels of electric current for the first time in long lengths of second generation (2G) high temperature superconductor (HTS) wire. This is the first time commercial levels of electrical current have been successfully achieved in long lengths (over 300 feet) by a low cost industrial process, making possible the emergence of this technology from the laboratory into the marketplace. HTS wires conduct large quantities of electricity with 100% efficiency when cooled with environmentally friendly liquid nitrogen, the coolant of choice for superconductor electric power transmission and distribution cables.
The problem is that LNG or Propane are still fossil fuels, and Hydrogen either comes from reformed natural gas (also a fossil fuel) or electrolyzed water. The energy cost of electrolyzing water is at least 3 times more as charging a battery. Finding ways to power cars without using fossil fuels or powering them more efficiently is very important. Even with remote power generation (using Nikola Tesla's AC power lines), the energy efficiency and CO2 reduction of battery electric vehicles is greater than the current best fossil-fueled hybrid by a wide margin.
Maybe batteries aren't very sexy, but they are used the cleanest, most efficient form of transporation available: electric vehicles. The cost of batteries for cars will come down if they get produced in volume. It's the same thing that's happened to cell phone and laptop batteries: capacities double and costs halve every few years. What's lacking for EV batteries is sufficient production volume of car-sized ones. In other words, the costs will reduce as volume ramps up. Battery powered cars have the potential to be less expensive than fossil-powered cars, given enough volume, since they are simpler, have fewer parts that wear out, don't have significant thermal stresses, etc. Batteries in hybrids and EVs are lasting 150,000 miles or more, and brushless motors and electronics basically never wear out.
Regarding hub motors, folks like Mitsubishi are using them experimentally on full size cars. Hub motors reduce transmission losses since the motor is directly in the wheel, but they also increase unsprung mass (since the motor is directly in the wheel the wheel becomes much heavier), which is usually detrimental to handling.
Regarding turbines in cars, no one has been able to deal with the large volume of exhaust produced or the noise yet. Nor are superconductors readily available.
Nikola Tesla came up with many cool inventions including his excellent turbine design, which BTW is appreciated and argably improved upon in the Discflo turbine:
However the point of Tesla Motors is not to make use of Tesla's pump or remote energy transmission technologies. It's to make use of his world-altering AC motor and create a practical, desirable, high-performance EV that can be produced today. The point as I see it is to jump-start the Electric Vehicle industry again and get more EVs out on the road, leading to less expensive, more-mundane ones eventually. In that regard Tesla Motors may turn out to be very significant.
AC motors and AC power transmission are two of Nikola's most significant contributions, and Tesla Motors *is* using both of them.
Also whoever said 200 cycles is probably wrong. Li-Ion typically lasts about 500 cycles, depending on the depth of discharge. With shallower discharge and charge they last longer. Calendar life of Li-Ion is about 5 years, not 1.
The point of this car is to get the ball rolling with an expensive, quick car. The costs will come down as battery production ramps up due to Plug-In Hybrids, etc. Then less expensive cars with cost-reduced battery packs can be built.
Economics says that it must be done in that order, unless some large car maker puts in enough money (i.e. $Billions) to drive down coasts immediately. None seem willing to do that, so the high-end-first approach makes sense.
Tesla is making a general case about EVs using theirs in particular. Even if the electricity source was 100% coal, any recent EV would put out less CO2 per mile than the cleanest hybrid. In California, where the car is sold initially, the power mix is as described in the paper. That is mostly hydro and natural gas. BTW they answer your exact issue in the paper:
"However, natural gas accounts for only 14.9% of U.S. electricity generation; the rest is a mix of coal, nuclear, and others. The average well-to-outlet efficiency of U.S. electric generation, including all the old, inefficient power plants, is about 41%. With this efficiency, our electric car has a well-to-wheel energy efficiency of 0.83 km/MJ, still the most efficient car on the road."
Aproximately half of the 60 Toyota RAV4 EV owners that I surveyed in 2003 charge their cars from photovoltaic (solar) energy. Their CO2 output is zero, after a few years of energy payback to recover the energy used to make the solar panels. Their operating costs are also near zero after the panels pay for themselves, which takes a few years. Call photovoltaic energy pixie dust if you like, but it does exist, people do use it, it is clean, and it does pay for itself in terms of energy and cost.
Regarding peer review, if anyone can find any errors in their calculations or references, then I'm sure they'd like to hear about it. Frankly the issues about total emissions, overall efficiency, etc., of various types of vehicles have already been studied extensively by scientists who specialize in it. Nothing in their paper is really controversial or new. Their references are the U.S. Department of Energy, EPA, General Motors, BP, ExxonMobil, Shell, Aragonne National Laboratory, etc.
May I recommend taking a few minutes to read the Telsa white paper? It neatly summarizes most of the relevant facts about energy production, efficiency of the motor, charger and battery system, CO2 emissions compared to a Prius, etc.
http://www.teslamotors.com/learn_more/white_papers .php
But I suppose that would take all the usual fun out of debating from ignorance.:-(
Yes there is an apparent SA bug that occasionally causes the SURBL lookups to FP. Strictly speaking that's almost certainly not the fault of SURBLs which are the data source in RBL form. If you are
using Windows, you may want to upgrade to the latest
version of ActiveState PERL, which apparently fixes
a possibly related Net::DNS buffer overflow bug. I don't have a reference for the PERL bug, but here's a SpamAssassin bug mentioning the fix.
Why use a scalpel when you can use a sledgehammer, eh? That's not our approach with SURBLs. We want to list only the spammer domains not the resolved IPs for some of the reasons already mentioned, such as virtual hosting on a shared server. We're not interested in *causing* collateral damage as that only makes SURBLs less useful in the larger picture. Ideally we'd like a tool that an ISP could "set and forget" blocking only spam and not ham (legitimate messages), for example at the MTA level.
That said, SpamAssassin 3.0 uses IPs of URIs in the command uridnsbl, which looks at URI domains, resolves their NS records, then checks those name server IPs against sbl.spamhaus.org. That turns out to be highly effective (about as effective as SURBLs), since so many spams mention domains served by the same spammer name servers. This is only useful because Spamhaus is very careful to add only purely spammer nameservers to sbl.
If you use both SURBLs with urirhssub and SBL with uridnsbl, you will have very powerful spam filtering that uses both domains and IP addresses (of name servers).
I should also add that we ask people to send us any false positives (e.g. innocent bystanders, legitimate URIs mentioned in legitimate messages or newsletters, etc.) to whitelist at surbl dot org .
We've created exclusion lists of all the whitehats we could think of, including google, ebay, etc., etc., etc. We call those exclustion lists "whitelists" but they are only used intenally to keep domains out of SURBLs. See:
http://www.surbl.org/faq.html#joe
In case it's not clear, ws.surbl.org uses different source data from sc.surbl.org. The former comes from Bill Stearns' sa-blacklist SpamAssassin rule set. The latter come from SpamCop URI reports aka "Spamvertised sites". Both target spam message body URIs; the SpamCop URI ones a bit moreso.
Both sc.surbl.org and ws.surbl.org SURBLs are intended to be used with message body scanning programs that can extact URI domains and compare them against name-type RBLs such as ours. Other uses of the lists such as in conventional RBL code won't work as well as the intended use. It needs to be stated clearly that our use of RBLs is pretty different from what they have been used for before. For example no name resolution of the message body domain is needed or desired.
Resolving the domains to IPs can be useful, and it's a technique
we're about to use to improve our performance. Our main
focus is going to stay on spam domain names, though I agree
with some of the reasons for using IPs too.
A thread on our discussion list archive
has an outline of our next engine with prior IPs used
to lower the domain inclusion thresholds.
One major reason to avoid name resolution on the incoming messages is to cut out the timeouts needed for the DNS queries to complete. We figure the domain name is nearly as useful to block on, modulo the improvement we expect to make mentioned in the thread.
Hi All,
First I wanted to let everyone know that the name of the SURBL list derived from Bill Stearns' sa-blacklist is changing from sa.surbl.org to ws.surbl.org . DNS for the old name will probably be up for another week or so before we switch it off. If anyone us using sa.surbl.org please update your rules or confs to use the new name: ws.surbl.org .
The original SURBL derived from SpamCop URI domains remains unchanged at: sc.surbl.org . (One advantage of using Bill's list as an SURBL instead of hard-coded SpamAssassin rules is that it frees up a lot of SA memory and pushes storage of the spam domain data to your local DNS cache.)
Differences between the two lists and more topics about our project are described on the SURBL site. If anyone has a question or comment about SURBL you can write to me directly at jeffc at surbl dot org, or much better ask the growing SURBL community on our discussion list. The separate announcement list is a good way to keep up with news about the project. Archives of the lists are available on the list site.
Folks who have tried SURBL have generally been pleased with the results, and we expect to improve the ~60% spam detection rate and lower the already low (<0.1%) false positive rate further in the next version of the data engine behind sc.surbl.org. As has been previously mentioned, Devin Carraway has written an MTA use of SURBL domain data to check message body URIs in his qpsmtpd plugin called uribl. This is the first MTA use for SURBL that I've heard of, though I don't necessarily claim to have heard of all uses of SURBL so far. Some other folks are thinking about implementing a sendmail milter for which will probably use sc.surbl.org since they are also a major ISP source of SpamCop's data.
Since I probably won't be posting here too often, I'd like to thank some of the people who have been quietly very supportive and responsible for the success of this effort so far including Eric Kolve, Justin Mason, Daniel Quinlan, Raymond Dijkxhoorn, Julian Haight, Kelsey Cummings and others who already know how greatly they have helped to make SURBL possible.
One thing we could use some help with now are more BIND-compatible secondary DNS servers and rsynced rbldnsd servers. Please see the SURBL site for details, and lend a hand if you can. DNS traffic may get kind of heavy when SA 3.0 comes out since it has SURBL support in URIDNSBL (URIBL), so we definitely need some help with name service.
Slashdot Mirror
50 kWh is a good, useful capacity for EVs in general. So it's probably not targeted specifically at the Tesla Roadster but for EVs in general. Should give about a 200 mile range depending on vehicle efficiencies. Given that most people commute less than about 40 miles per day, 200 miles of range is more than enough for most daily driving.
It's incorrect to say that capacitor storage will drastically increase the energy recovered from braking in an electric or hybrid vehicle compared to battery storage. The problem is that both the inverter (power transistor) electronics and motor have efficiency losses on the order of 5 to 7% each. Batteries do have additional losses when charging or discharging of about 15% in each direction, which a capacitor largely avoids, but there are still significant losses from the motor and power transistors. Remember those losses get applied twice, both then regenerating (decelerating the vehicle) and when using the energy to accelerate the vehicle again. There are also significant losses in the gears, tires, etc.
There ain't no such thing as a free lunch. If regenerative braking and acceleration in an EV or hybrid were 100% efficient, they would be perpetual motion machines.
That said, capacitors would allow and EV to make use of significantly more regenerative braking energy than a battery electric vehicle. But the overall improvement is going from about 50% efficiency to 70% or about a 20% range improvement. That is very significant, but it's not perpetual motion and can't be due to the other losses.
That also said, practical capacitors would be a major shift in how we use energy for transporation and in general.
Maybe batteries aren't very sexy, but they are used the cleanest, most efficient form of transporation available: electric vehicles. The cost of batteries for cars will come down if they get produced in volume. It's the same thing that's happened to cell phone and laptop batteries: capacities double and costs halve every few years. What's lacking for EV batteries is sufficient production volume of car-sized ones. In other words, the costs will reduce as volume ramps up. Battery powered cars have the potential to be less expensive than fossil-powered cars, given enough volume, since they are simpler, have fewer parts that wear out, don't have significant thermal stresses, etc. Batteries in hybrids and EVs are lasting 150,000 miles or more, and brushless motors and electronics basically never wear out.
Regarding hub motors, folks like Mitsubishi are using them experimentally on full size cars. Hub motors reduce transmission losses since the motor is directly in the wheel, but they also increase unsprung mass (since the motor is directly in the wheel the wheel becomes much heavier), which is usually detrimental to handling.
Regarding turbines in cars, no one has been able to deal with the large volume of exhaust produced or the noise yet. Nor are superconductors readily available.
http://www.animatedsoftware.com/pumpglos/teslapum. htm
http://www.animatedsoftware.com/pumpglos/discflo.h tm
However the point of Tesla Motors is not to make use of Tesla's pump or remote energy transmission technologies. It's to make use of his world-altering AC motor and create a practical, desirable, high-performance EV that can be produced today. The point as I see it is to jump-start the Electric Vehicle industry again and get more EVs out on the road, leading to less expensive, more-mundane ones eventually. In that regard Tesla Motors may turn out to be very significant.
AC motors and AC power transmission are two of Nikola's most significant contributions, and Tesla Motors *is* using both of them.
http://www.acpropulsion.com/Products/Range_extendi ng_trailers.htm
Tesla is using AC Propulsion's electronics and battery strategies.
Initially the trailer was used with Alan Cocconi's (the AC in ACP) converted electric Honda CRX.
The point of this car is to get the ball rolling with an expensive, quick car. The costs will come down as battery production ramps up due to Plug-In Hybrids, etc. Then less expensive cars with cost-reduced battery packs can be built.
Economics says that it must be done in that order, unless some large car maker puts in enough money (i.e. $Billions) to drive down coasts immediately. None seem willing to do that, so the high-end-first approach makes sense.
Aproximately half of the 60 Toyota RAV4 EV owners that I surveyed in 2003 charge their cars from photovoltaic (solar) energy. Their CO2 output is zero, after a few years of energy payback to recover the energy used to make the solar panels. Their operating costs are also near zero after the panels pay for themselves, which takes a few years. Call photovoltaic energy pixie dust if you like, but it does exist, people do use it, it is clean, and it does pay for itself in terms of energy and cost.
Regarding peer review, if anyone can find any errors in their calculations or references, then I'm sure they'd like to hear about it. Frankly the issues about total emissions, overall efficiency, etc., of various types of vehicles have already been studied extensively by scientists who specialize in it. Nothing in their paper is really controversial or new. Their references are the U.S. Department of Energy, EPA, General Motors, BP, ExxonMobil, Shell, Aragonne National Laboratory, etc.
May I recommend taking a few minutes to read the Telsa white paper? It neatly summarizes most of the relevant facts about energy production, efficiency of the motor, charger and battery system, CO2 emissions compared to a Prius, etc. http://www.teslamotors.com/learn_more/white_papers .php
But I suppose that would take all the usual fun out of debating from ignorance. :-(
Yes there is an apparent SA bug that occasionally causes the SURBL lookups to FP. Strictly speaking that's almost certainly not the fault of SURBLs which are the data source in RBL form. If you are using Windows, you may want to upgrade to the latest version of ActiveState PERL, which apparently fixes a possibly related Net::DNS buffer overflow bug. I don't have a reference for the PERL bug, but here's a SpamAssassin bug mentioning the fix.
Why use a scalpel when you can use a sledgehammer, eh? That's not our approach with SURBLs. We want to list only the spammer domains not the resolved IPs for some of the reasons already mentioned, such as virtual hosting on a shared server. We're not interested in *causing* collateral damage as that only makes SURBLs less useful in the larger picture. Ideally we'd like a tool that an ISP could "set and forget" blocking only spam and not ham (legitimate messages), for example at the MTA level. That said, SpamAssassin 3.0 uses IPs of URIs in the command uridnsbl, which looks at URI domains, resolves their NS records, then checks those name server IPs against sbl.spamhaus.org. That turns out to be highly effective (about as effective as SURBLs), since so many spams mention domains served by the same spammer name servers. This is only useful because Spamhaus is very careful to add only purely spammer nameservers to sbl. If you use both SURBLs with urirhssub and SBL with uridnsbl, you will have very powerful spam filtering that uses both domains and IP addresses (of name servers).
I should also add that we ask people to send us any false positives (e.g. innocent bystanders, legitimate URIs mentioned in legitimate messages or newsletters, etc.) to whitelist at surbl dot org .
We've created exclusion lists of all the whitehats we could think of, including google, ebay, etc., etc., etc. We call those exclustion lists "whitelists" but they are only used intenally to keep domains out of SURBLs. See: http://www.surbl.org/faq.html#joe
Both sc.surbl.org and ws.surbl.org SURBLs are intended to be used with message body scanning programs that can extact URI domains and compare them against name-type RBLs such as ours. Other uses of the lists such as in conventional RBL code won't work as well as the intended use. It needs to be stated clearly that our use of RBLs is pretty different from what they have been used for before. For example no name resolution of the message body domain is needed or desired.
A thread on our discussion list archive has an outline of our next engine with prior IPs used to lower the domain inclusion thresholds.
One major reason to avoid name resolution on the incoming messages is to cut out the timeouts needed for the DNS queries to complete. We figure the domain name is nearly as useful to block on, modulo the improvement we expect to make mentioned in the thread.
Differences between the two lists and more topics about our project are described on the SURBL site. If anyone has a question or comment about SURBL you can write to me directly at jeffc at surbl dot org, or much better ask the growing SURBL community on our discussion list. The separate announcement list is a good way to keep up with news about the project. Archives of the lists are available on the list site.
Folks who have tried SURBL have generally been pleased with the results, and we expect to improve the ~60% spam detection rate and lower the already low (<0.1%) false positive rate further in the next version of the data engine behind sc.surbl.org. As has been previously mentioned, Devin Carraway has written an MTA use of SURBL domain data to check message body URIs in his qpsmtpd plugin called uribl. This is the first MTA use for SURBL that I've heard of, though I don't necessarily claim to have heard of all uses of SURBL so far. Some other folks are thinking about implementing a sendmail milter for which will probably use sc.surbl.org since they are also a major ISP source of SpamCop's data.
Since I probably won't be posting here too often, I'd like to thank some of the people who have been quietly very supportive and responsible for the success of this effort so far including Eric Kolve, Justin Mason, Daniel Quinlan, Raymond Dijkxhoorn, Julian Haight, Kelsey Cummings and others who already know how greatly they have helped to make SURBL possible.
One thing we could use some help with now are more BIND-compatible secondary DNS servers and rsynced rbldnsd servers. Please see the SURBL site for details, and lend a hand if you can. DNS traffic may get kind of heavy when SA 3.0 comes out since it has SURBL support in URIDNSBL (URIBL), so we definitely need some help with name service.