[Ovmsdev] Nissan Leaf

Tom Saxton tom at idleloop.com
Tue Feb 11 15:21:35 HKT 2014


That's correct, the ATMA command will spew messages that match your filter
(or all messages if you set the CAN filter mask to 000: ATCM 000) until you
type a character to interrupt it. I usually hit space or return.


On 2/10/14, 11:05 PM, "Avesh Chauhan" <aveshcool at gmail.com> wrote:

Dear Tom,

Thanks for so nicely explaining  your work. I tried almost similar steps
using wifi enabled ELM 327 chipset on my car ( not a electric car ). However
did not use the command Can Mask command you suggested . This is useful as
with ATMA command , OBD adapter is not able to provide all data so filtering
the data is awesome idea.So i believe it will continue to monitor particular
parameter unless interrupted ???

@ Dear Mark and all :

have you guys worked on ELM 329 chipset. I am not able to understand the
difference between ELM 327 and 329. Any help is appreciated .


On Tue, Feb 11, 2014 at 7:20 AM, Tom Saxton <tom at idleloop.com> wrote:
> I bought a tiny $12 ELM327 Bluetooth gizmo that's listed among the devices
> compatible with LeafSpy.
> http://www.amazon.com/gp/product/B008U1MOM8/
> I also bought the OBDII Y cable that Mark suggested which looks like a high
> quality cable and it works.
> http://www.amazon.com/gp/product/B00EEDOWU8/
> At first I had zero success getting CAN messages from the Leaf's CAR-CAN bus
> using the ELM327; I got either nothing or garbage data with errors and buffer
> overflow messages.
> This tutorial Mark suggested is inspiring, and illustrates a good general
> technique for figuring things out, but it has no information on how to get CAN
> data.
> http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/
> I was then led astray by reading the ELM32X data sheet and the Wikipedia page
> on how OBDII CAN messages work.
> http://elmelectronics.com/DSheets/ELM327DS.pdf
> http://en.wikipedia.org/wiki/OBD-II_PIDs
> The specifics of how the messages are formatted is completely wrong for the
> Leaf. The 11-bit CAN ID values are not used to identify ECUs, they are the
> message identifiers. Instead of looking at CAN IDs in the range 7E0 to 7EF,
> you have to look at all CAN IDs from 001 to 7FF.
> The next problem is that there is so much traffic on the Leaf's CAR-CAN bus,
> that a low-bandwidth unit like the cheap Bluetooth gizmos can't possibly keep
> up. I was able to determine that the output baud rate on the above gizmo is at
> most 38400 bps. To look at things, you need to filter to only get a subset of
> the constant stream of traffic on the CAR-CAN bus.
> The trick is to use the ATCM (CAN mask) and ATCF (CAN filter) commands to
> filter for a single message. For example, to view message 0x5C5 which includes
> the Leaf's odometer value, first set up the chip with these commands:
> ATH1
> ATL1
> ATS1
> Those commands in order: reset the chip to defaults, turn on message headers
> (which show the CAN ID), line endings between messages and spaces between
> bytes, and enables long messages. Then issue these commands:
> ATCF 5C5
> The first two commands set the ELM327 to filter for a single message ID, 5C5,
> the third starts dumping them. You'll get data that looks like this:
> 5C5 44 00 3C BA 00 0C 00 00
> 5C5 44 00 3C BA 00 0C 00 00
> 5C5 44 00 3C BA 00 0C 00 00
> ...
> Type any character to stop the spewing of messages. The first group of three
> hex digits, 5C5, is the message ID, followed by the message data, bytes 0
> through 7. According to the LEAF CAN message spreadsheet, skipping the first
> byte (44) and taking the next three (00 3C BA) yields the odometer. Sure
> enough, 003CBA is 15,546 in decimal, which is indeed our Leaf's odometer
> value.
> I also confirmed the Gid value documented in message 5B3 for several Gid
> values in the low 200's.
> To get an idea of what's happening on the CAR-CAN bus, I wrote a program that
> marches though all 2048 CAN ID values, listens for each message ID until
> either 20 messages have been collected or 2.01 seconds goes by with no
> messages, then moves on to the next ID. Using that program, I found 49
> messages that happen between twice and one hundred times per second when the
> car is parked and turned on in accessory mode. Together, they total up to over
> 1500 messages per second. So, you'd need an output baud rate around 500,000
> bps to monitor all messages, which is totally not happening with a $12 38400
> bps gizmo.
> I've attached a spreadsheet with the list of those messages. I have a text
> file with 20 sample messages of each type. I'm happy to share if anyone else
> wants to see it.
> See the spreadsheet of known LEAF CAN messages to see what's known about what
> they contain.
> https://docs.google.com/spreadsheet/ccc?key=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1ON
> 2xZSzlMUXc#gid=1
> Unfortunately, with the sealed plastic $12 gizmo, there's no way to look at
> the EV-CAN bus, so that will have to wait until I get a better device. I'm
> considering these three:
> Mark recommends: http://www.can232.com/?page_id=16 ($140 + cable + shipping)
> Roadster service techs use: http://gridconnect.com/can-usb.html ($255 + cable
> + shipping)
> Sparkfun: https://www.sparkfun.com/products/9555 ($74.85 with cable and
> shipping)
> For connecting to the CAN bus, OVMS uses the same pin mapping as the device
> Mark and Tesla use. Sparkfun uses a different pin mapping which agrees with
> what OBD2cables.com says is the "de facto standard pinout."
> Standards are so awesome, we have at least two!
> I was surprised to see obd2cables.com <http://obd2cables.com>  claiming a
> standard that's different from what I expected from Mark's and Tesla's
> preferred gizmos. Fortunately, it should be easy to make a DB9 adapter to
> convert between the two standards should the need arise.
>    Tom
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140210/78245da9/attachment.htm>

More information about the OvmsDev mailing list