[Ovmsdev] Nissan Leaf

[Avesh Chauhan]

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 .

Regards,
Avesh



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:
>
> ATZ
> ATH1
> ATL1
> ATS1
> ATAL
>
> 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:
>
> ATCM 7FF
> ATCF 5C5
> ATMA
>
> 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=0An7gtcYL2Oy0dGRaSWl6VTV2eXBQMy1ON2xZSzlMUXc#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."
>
>
> http://www.obd2cables.com/products/cable-j1962m-right-angle-to-db9f-4-3-ft.html
>
> Standards are so awesome, we have at least two!
>
> I was surprised to see 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140211/7ba06f24/attachment.htm>