Nissan Leaf CAN Bus Man in the Middle

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
I wrote a man in the middle for the leaf battery communication. It uses
can4python and Kayak's kcd format to describe the signals. It probably
only works on Linux. Source code is here
https://carrott.org/git/leaf-can-utils.git

It decodes all the messages received on one interface (from the battery)
into signals, lets me change their values, and then re-encodes them back
into the can bus format, recalculates the new checksum when necessary
and sends them out the other interface (to the car).

Yesterday I spent some time testing it on a Gen 1 leaf at
https://bluecars.nz

We cut the can bus wires inside the battery box, just after they go
through the water proof connector to the outside and connected about 1
metre of thin figure 8 wire to each side of the cut. This let us access
the bus on the car and the bus on the battery while the battery was
plugged in under the car. It's possible to get enough slack in the
internal battery loom to feed the connector all the way through the
machined hole and make room for some extra wires to pass through.

With the two pairs connected together, the car behaved normally, going
into ready and spinning the wheels.

The BMS module terminates the bus so we connected a termination resistor
to the car side of the cut and used termination on the CAN interface
talking to the battery. We plugged the other end of the man in the
middle to the OBD2 port and didn't use termination.

The MitM just worked.

The car is very tolerant of errors on the CAN bus. You can stop the
battery messages and it goes into turtle mode and all the battery info
disappears off the instrument cluster. When you re-start the battery
messages it goes back to normal mode and the battery info reappears.
Start-up is quite critical, if you don't let the battery send it's start
up messages the car doesn't go into ready mode. The car never shut down
or went into a permanent turtle mode while I was messing with data on
the bus -- it always went back to normal mode if I restored the
unmodified messages flow from the BMS. I modified the data in nearly
every field to see what would happen.

The car will go into ready and turn the wheels even when it cannot send
messages to the battery. This means the startup sequence doesn't involve
a car to battery handshake, even if the car is expecting some startup
messages from the battery within a time window. The "check engine" light
comes on and it does record some DTCs:
* P3180 (EVC-249) VCM detects an error signal that is received from LBC
via CAN communication for 0.02 seconds or more.
* P3183 (EVC-250) After a lapse of 0.3 seconds from M/C RELAY ON, the
following state remains for 2.8 seconds or more: LBC's calculation
result to the VCM-set example question is incorrect.

My MitM only works in one direction (from the battery to the car) and it
turns out my CAN bus setup wouldn't let two programs play together, so
when I started a CAN repeater (candump -b) to copy data from the car to
the battery I got corrupted frames and no buffer space errors. I'm going
to make the MitM work in both directions to resolve this.

If you play a different car's battery messages into this car, it does
not go into ready. I didn't spend much time on this and I didn't write
code to start the BMS messages at the right time, I just started playing
the recording of a running BMS and switched the car on. One experiment
that I should have tried was to start the car with it's real battery and
then switch to messages recorded from a different car. There are some
new DTCs when you try to start a the car while playing messages recorded
from another car including

* P3102 Li-ion Battery ID Registration must be performed if the Li-ion
battery controller or VCM is replaced.

The next experiment is to swap in a BMS module from another car.

I figured out some more of the BMS protocol by messing with the data and
seeing how the car reacted.

The Fuel Gauge display on the instrument cluster is powered by the GIDs
signal (the first 10 bits of 0x5BC), not the state of charge signal
(first 10 bits of 0x55B). I guess it knows how many GIDS is "full"
because the battery will have fewer gids and still read full as it ages.

0x5BC bits 36-39 (ie the high nibble of the 5th byte) somehow effects
the Fuel Gauge, lower numbers mean more bars, all other things being the
same. Maybe this is used to calculate how many GIDs each bar is worth? I
haven't explored this.

The battery capacity gauge (the bars outside the fuel gauge) is
controlled by a muxed field, when 0x5BC bits 32-35 (ie the low nibble of
the 5th byte) is 0x3, 0x5BC bits 16-19 (ie the low nibble of the 3rd
byte) contains the capacity bars. I haven't yet used the mux field
support in the kcd format to express this -- can4python doesn't support
it so I had to hand code it. The cluster does not remember the capacity
-- changing this value directly manipulates the number of bars
displayed, the value on the can bus is literally the number of bars (0x0
-> no bars, 0xC -> 12 bars).

Ed Blackmond earlier reported that his car shows the original capacity
not the new capacity after he replaced the cells while keeping the
original BMS module. What data do you see on this field?

The indicated temperature on the instrument cluster is controlled by
another muxed field, when 0x5C0 is 0x40, the indicated temperature is
controlled by the 3rd byte of 0x5C0. This mux has 3 values, on this car
all 3 are similar in the 3rd byte, but only the when the mux is 0x40
does the 3rd byte control the temperature in the instrument cluster.

Many thanks to Carl at https://bluecars.nz/ for letting me torture his car.

_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
Great info, thanks!

The next time I use a Leaf pack on an EV I want to be able to just plug
it in "unmodified" and make use of the existing BMS and CAN interface,
it's good to know that people are making good progress on the "auto"
side of this.

Jay

On 03/12/2017 06:07 AM, Tom Parker via EV wrote:

> I wrote a man in the middle for the leaf battery communication. It uses
> can4python and Kayak's kcd format to describe the signals. It probably
> only works on Linux. Source code is here
> https://carrott.org/git/leaf-can-utils.git
>
> It decodes all the messages received on one interface (from the battery)
> into signals, lets me change their values, and then re-encodes them back
> into the can bus format, recalculates the new checksum when necessary
> and sends them out the other interface (to the car).
>
> Yesterday I spent some time testing it on a Gen 1 leaf at
> https://bluecars.nz
>
> We cut the can bus wires inside the battery box, just after they go
> through the water proof connector to the outside and connected about 1
> metre of thin figure 8 wire to each side of the cut. This let us access
> the bus on the car and the bus on the battery while the battery was
> plugged in under the car. It's possible to get enough slack in the
> internal battery loom to feed the connector all the way through the
> machined hole and make room for some extra wires to pass through.
>
> With the two pairs connected together, the car behaved normally, going
> into ready and spinning the wheels.
>
> The BMS module terminates the bus so we connected a termination resistor
> to the car side of the cut and used termination on the CAN interface
> talking to the battery. We plugged the other end of the man in the
> middle to the OBD2 port and didn't use termination.
>
> The MitM just worked.
>
> The car is very tolerant of errors on the CAN bus. You can stop the
> battery messages and it goes into turtle mode and all the battery info
> disappears off the instrument cluster. When you re-start the battery
> messages it goes back to normal mode and the battery info reappears.
> Start-up is quite critical, if you don't let the battery send it's start
> up messages the car doesn't go into ready mode. The car never shut down
> or went into a permanent turtle mode while I was messing with data on
> the bus -- it always went back to normal mode if I restored the
> unmodified messages flow from the BMS. I modified the data in nearly
> every field to see what would happen.
>
> The car will go into ready and turn the wheels even when it cannot send
> messages to the battery. This means the startup sequence doesn't involve
> a car to battery handshake, even if the car is expecting some startup
> messages from the battery within a time window. The "check engine" light
> comes on and it does record some DTCs:
> * P3180 (EVC-249) VCM detects an error signal that is received from LBC
> via CAN communication for 0.02 seconds or more.
> * P3183 (EVC-250) After a lapse of 0.3 seconds from M/C RELAY ON, the
> following state remains for 2.8 seconds or more: LBC's calculation
> result to the VCM-set example question is incorrect.
>
> My MitM only works in one direction (from the battery to the car) and it
> turns out my CAN bus setup wouldn't let two programs play together, so
> when I started a CAN repeater (candump -b) to copy data from the car to
> the battery I got corrupted frames and no buffer space errors. I'm going
> to make the MitM work in both directions to resolve this.
>
> If you play a different car's battery messages into this car, it does
> not go into ready. I didn't spend much time on this and I didn't write
> code to start the BMS messages at the right time, I just started playing
> the recording of a running BMS and switched the car on. One experiment
> that I should have tried was to start the car with it's real battery and
> then switch to messages recorded from a different car. There are some
> new DTCs when you try to start a the car while playing messages recorded
> from another car including
>
> * P3102 Li-ion Battery ID Registration must be performed if the Li-ion
> battery controller or VCM is replaced.
>
> The next experiment is to swap in a BMS module from another car.
>
> I figured out some more of the BMS protocol by messing with the data and
> seeing how the car reacted.
>
> The Fuel Gauge display on the instrument cluster is powered by the GIDs
> signal (the first 10 bits of 0x5BC), not the state of charge signal
> (first 10 bits of 0x55B). I guess it knows how many GIDS is "full"
> because the battery will have fewer gids and still read full as it ages.
>
> 0x5BC bits 36-39 (ie the high nibble of the 5th byte) somehow effects
> the Fuel Gauge, lower numbers mean more bars, all other things being the
> same. Maybe this is used to calculate how many GIDs each bar is worth? I
> haven't explored this.
>
> The battery capacity gauge (the bars outside the fuel gauge) is
> controlled by a muxed field, when 0x5BC bits 32-35 (ie the low nibble of
> the 5th byte) is 0x3, 0x5BC bits 16-19 (ie the low nibble of the 3rd
> byte) contains the capacity bars. I haven't yet used the mux field
> support in the kcd format to express this -- can4python doesn't support
> it so I had to hand code it. The cluster does not remember the capacity
> -- changing this value directly manipulates the number of bars
> displayed, the value on the can bus is literally the number of bars (0x0
> -> no bars, 0xC -> 12 bars).
>
> Ed Blackmond earlier reported that his car shows the original capacity
> not the new capacity after he replaced the cells while keeping the
> original BMS module. What data do you see on this field?
>
> The indicated temperature on the instrument cluster is controlled by
> another muxed field, when 0x5C0 is 0x40, the indicated temperature is
> controlled by the 3rd byte of 0x5C0. This mux has 3 values, on this car
> all 3 are similar in the 3rd byte, but only the when the mux is 0x40
> does the 3rd byte control the temperature in the instrument cluster.
>
> Many thanks to Carl at https://bluecars.nz/ for letting me torture his car.
>
> _______________________________________________
> UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
> http://lists.evdl.org/listinfo.cgi/ev-evdl.org
> Read EVAngel's EV News at http://evdl.org/evln/
> Please discuss EV drag racing at NEDRA
> (http://groups.yahoo.com/group/NEDRA)
>
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
On 13/03/17 04:39, Jay Summet via EV wrote:
> The next time I use a Leaf pack on an EV I want to be able to just
> plug it in "unmodified" and make use of the existing BMS and CAN
> interface, it's good to know that people are making good progress on
> the "auto" side of this.

The BMS is already understood mostly enough to use in a conversion.
While it evidently logs an error when the car is missing, it's quite
happy to tell you the battery current, voltage, remaining capacity and
cell voltage levels. There are some more signals that would be a good
idea to follow but I don't know if anyone has identified them:

* High voltage discharge permit signal
* System main relay ON permit signal
* Insulation resistance signal
* Li-ion battery dischargeable power signal

_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
In reply to this post by Electric Vehicle Discussion List mailing list
It sounds like the BMS is well understood enough to do something that I've thought about: building a module to combine the outputs of two (or more) packs or to use the 30kWh pack in a car built with the 24kWh pack.

Bill
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
Outstanding work Tom.
Not many folks have the ability (or patience) to tackle this job, but
a lot of us will use this. Makes the Leaf battery module so much more
useful as a functional unit.

A bit like "LeafSpy", but for the serious EV hacker. :-)

Bill D.

_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
In reply to this post by Electric Vehicle Discussion List mailing list
Thanks Tom, this gives us a lot of room to build.  We could even have
real time R or RShiny output to a display to do trends and
predictions.

sean

On Sun, Mar 12, 2017 at 6:07 AM, Tom Parker via EV <[hidden email]> wrote:

> I wrote a man in the middle for the leaf battery communication. It uses
> can4python and Kayak's kcd format to describe the signals. It probably only
> works on Linux. Source code is here
> https://carrott.org/git/leaf-can-utils.git
>
> It decodes all the messages received on one interface (from the battery)
> into signals, lets me change their values, and then re-encodes them back
> into the can bus format, recalculates the new checksum when necessary and
> sends them out the other interface (to the car).
>
> Yesterday I spent some time testing it on a Gen 1 leaf at
> https://bluecars.nz
>
> We cut the can bus wires inside the battery box, just after they go through
> the water proof connector to the outside and connected about 1 metre of thin
> figure 8 wire to each side of the cut. This let us access the bus on the car
> and the bus on the battery while the battery was plugged in under the car.
> It's possible to get enough slack in the internal battery loom to feed the
> connector all the way through the machined hole and make room for some extra
> wires to pass through.
>
> With the two pairs connected together, the car behaved normally, going into
> ready and spinning the wheels.
>
> The BMS module terminates the bus so we connected a termination resistor to
> the car side of the cut and used termination on the CAN interface talking to
> the battery. We plugged the other end of the man in the middle to the OBD2
> port and didn't use termination.
>
> The MitM just worked.
>
> The car is very tolerant of errors on the CAN bus. You can stop the battery
> messages and it goes into turtle mode and all the battery info disappears
> off the instrument cluster. When you re-start the battery messages it goes
> back to normal mode and the battery info reappears. Start-up is quite
> critical, if you don't let the battery send it's start up messages the car
> doesn't go into ready mode. The car never shut down or went into a permanent
> turtle mode while I was messing with data on the bus -- it always went back
> to normal mode if I restored the unmodified messages flow from the BMS. I
> modified the data in nearly every field to see what would happen.
>
> The car will go into ready and turn the wheels even when it cannot send
> messages to the battery. This means the startup sequence doesn't involve a
> car to battery handshake, even if the car is expecting some startup messages
> from the battery within a time window. The "check engine" light comes on and
> it does record some DTCs:
> * P3180 (EVC-249) VCM detects an error signal that is received from LBC via
> CAN communication for 0.02 seconds or more.
> * P3183 (EVC-250) After a lapse of 0.3 seconds from M/C RELAY ON, the
> following state remains for 2.8 seconds or more: LBC's calculation result to
> the VCM-set example question is incorrect.
>
> My MitM only works in one direction (from the battery to the car) and it
> turns out my CAN bus setup wouldn't let two programs play together, so when
> I started a CAN repeater (candump -b) to copy data from the car to the
> battery I got corrupted frames and no buffer space errors. I'm going to make
> the MitM work in both directions to resolve this.
>
> If you play a different car's battery messages into this car, it does not go
> into ready. I didn't spend much time on this and I didn't write code to
> start the BMS messages at the right time, I just started playing the
> recording of a running BMS and switched the car on. One experiment that I
> should have tried was to start the car with it's real battery and then
> switch to messages recorded from a different car. There are some new DTCs
> when you try to start a the car while playing messages recorded from another
> car including
>
> * P3102 Li-ion Battery ID Registration must be performed if the Li-ion
> battery controller or VCM is replaced.
>
> The next experiment is to swap in a BMS module from another car.
>
> I figured out some more of the BMS protocol by messing with the data and
> seeing how the car reacted.
>
> The Fuel Gauge display on the instrument cluster is powered by the GIDs
> signal (the first 10 bits of 0x5BC), not the state of charge signal (first
> 10 bits of 0x55B). I guess it knows how many GIDS is "full" because the
> battery will have fewer gids and still read full as it ages.
>
> 0x5BC bits 36-39 (ie the high nibble of the 5th byte) somehow effects the
> Fuel Gauge, lower numbers mean more bars, all other things being the same.
> Maybe this is used to calculate how many GIDs each bar is worth? I haven't
> explored this.
>
> The battery capacity gauge (the bars outside the fuel gauge) is controlled
> by a muxed field, when 0x5BC bits 32-35 (ie the low nibble of the 5th byte)
> is 0x3, 0x5BC bits 16-19 (ie the low nibble of the 3rd byte) contains the
> capacity bars. I haven't yet used the mux field support in the kcd format to
> express this -- can4python doesn't support it so I had to hand code it. The
> cluster does not remember the capacity -- changing this value directly
> manipulates the number of bars displayed, the value on the can bus is
> literally the number of bars (0x0 -> no bars, 0xC -> 12 bars).
>
> Ed Blackmond earlier reported that his car shows the original capacity not
> the new capacity after he replaced the cells while keeping the original BMS
> module. What data do you see on this field?
>
> The indicated temperature on the instrument cluster is controlled by another
> muxed field, when 0x5C0 is 0x40, the indicated temperature is controlled by
> the 3rd byte of 0x5C0. This mux has 3 values, on this car all 3 are similar
> in the 3rd byte, but only the when the mux is 0x40 does the 3rd byte control
> the temperature in the instrument cluster.
>
> Many thanks to Carl at https://bluecars.nz/ for letting me torture his car.
>
> _______________________________________________
> UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
> http://lists.evdl.org/listinfo.cgi/ev-evdl.org
> Read EVAngel's EV News at http://evdl.org/evln/
> Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)
>



--
Sean Korb [hidden email] http://www.spkorb.org
'65 Suprang,'68 Cougar,'78 R100/7,'60 Metro,'59 A35,'71 Pantera #1382
"The more you drive, the less intelligent you get" --Miller
"Computers are useless.  They can only give you answers." -P. Picasso
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
In reply to this post by Electric Vehicle Discussion List mailing list
Hi Bill,
Maybe we should talk.
My understanding was that the BMS communication was already well enough
understood to allow an app like LeafSpy, but indeed we are finding new
bits and pieces here. Very interesting.

My daily driver has 2 Leaf packs including 2 BMS (LBC) which are both
wired to the cabin, currently terminating in a toggle switch and an
ELM327 so I can use LeafSpy to alternate between the two BMS'es to
monitor both packs which are 2 independent strings, wired in parallel to
the main contactors.

My plan is to adapt the "CANary" that some Leaf folks have used to
display the info from the Leaf's 2 CAN buses and instead, write a
program to inquire of both BMS'es via both CAN buses and display the
statuses of the two packs on the two LCD displays of the CANary.

One other wild idea is to take a WinTerm and boot it in DOS, since my
truck's Dolphin controller needs a DOS program to be configured, then
add a larger LCD monitor that I mount behind the seat, just visible
through the rear window above the truck bed and display consumption
(miles per kWh) and power, voltage, current and other geek things on to
draw attention to the fact that this is not just a regular S10 truck.
Since many LCD monitors run on 12V, just like the WinTerm, all I need is
the IGN wire to power it and display the WinTerm VGA output. All that is
needed is a small program receiving the Dolphin serial output and
decoding it, to generate the display info. That might also lead to
reverse engineering the current DOS program to program the controller,
which in turn will help to keep the controller accessible in future
decades as DOS computers are dying...
Luckily there are still some around and I found a rather recent laptop
that has a serial RS232 bus which I can boot in DOS. The WinTerm is much
more rugged than a laptop and is essentially a Windows computer without
drives so plugging in a memory stick and booting it in DOS is for now
the most rugged DOS computer I can think of - but requires external
keyboard and monitor, which I can turn into a feature...
Oh and a WinTerm can be had for almost nothing...

But first I need to get around to assemble the two CANary hardware sets
that I ordered and verify everything works, then start programming...
In the mean time the two Leaf BMS'es keep the two packs nicely balanced
with just feeding them 12V continuously even without Leaf surrounding
them.

Cor van de Water
Chief Scientist
Proxim Wireless
 
office +1 408 383 7626                    Skype: cor_van_de_water
XoIP   +31 87 784 1130                    private: cvandewater.info

http://www.proxim.com

This email message (including any attachments) contains confidential and
proprietary information of Proxim Wireless Corporation.  If you received
this message in error, please delete it and notify the sender.  Any
unauthorized use, disclosure, distribution, or copying of any part of
this message is prohibited.


-----Original Message-----
From: EV [mailto:[hidden email]] On Behalf Of Bill Collins
via EV
Sent: Monday, March 13, 2017 10:38 AM
To: [hidden email]
Subject: Re: [EVDL] Nissan Leaf CAN Bus Man in the Middle

It sounds like the BMS is well understood enough to do something that
I've thought about: building a module to combine the outputs of two (or
more) packs or to use the 30kWh pack in a car built with the 24kWh pack.

Bill
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA
(http://groups.yahoo.com/group/NEDRA)

_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)

Reply | Threaded
Open this post in threaded view
|

Re: Nissan Leaf CAN Bus Man in the Middle

Electric Vehicle Discussion List mailing list
In reply to this post by Electric Vehicle Discussion List mailing list
On 14/03/17 07:07, Bill Dube via EV wrote:

> Outstanding work Tom.
> Not many folks have the ability (or patience) to tackle this job, but
> a lot of us will use this. Makes the Leaf battery module so much more
> useful as a functional unit.

To be clear my contribution so far is only

* writing a simple tool to explore how the system behaves when messages
are modified
* writing a configuration file for kayak and a wireshark dissector to
decode some of the can bus messages
* finding the car mostly works when the battery can send messages to it
and it cannot send messages to the battery
* discovering which signals the leaf instrument cluster is using for the
capacity, temperature and state of charge displays

The work to decipher enough of the Leaf BMS to use it outside the car
was done by others.
_______________________________________________
UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub
http://lists.evdl.org/listinfo.cgi/ev-evdl.org
Read EVAngel's EV News at http://evdl.org/evln/
Please discuss EV drag racing at NEDRA (http://groups.yahoo.com/group/NEDRA)