Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Let the hacking begin... (Model S parts on the bench)

This site may earn commission on affiliate links.
@smac

I recently acquired a leaf light at a good price from eBay, so far I'm impressed with the build quality and reliability, I have only used busmaster for logging but I'm working with Kvaser to see if I can use the python wrappers for their existing C library. That might be a good option for those of you who either have one or where getting one would be economical.

C (C++/C# with PInvoke) I can work with :)

Finding the workshop space and dedicated time to make up hardware is slightly more challenging for me right now, the joys of re-modelling a house that even Tom Hanks and Shelley Long would find a walk in the park :)
 
IXXAT is a German company and is one of the principal suppliers of CAN tools to the OEM automotive industry. I've been using their CAN to USB adaptors for over ten years. They are also the tools most likely used in the field for things like Zero Motorcycle firmware updates and the like so I've often found other uses besides development logging. Perhaps someone familiar with SavvyCAN can chime in on compatibility.

Currently there is only support for the EVTVDue or CANDue boards. But, I plan on supporting socketcan on linux. IXXAT almost certainly has socketcan compatible drivers. That doesn't help OSX or Windows users. I had thought to maybe support Kvaser tools on WIndows. I've got a kvaser leaf light (very nice!). I don't have any IXXAT hardware but maybe support for it could be added some day. The easiest approach in the interim is to capture with something else that supports IXXAT like maybe BusMaster or something.
 
WK057,
What is the (default SavvyCAN) log format that you are using, please?

For compactness, I use a 12 byte fixed size binary record
for two time stamp bytes, 2 bytes for the CAN MsgID and
data length, and 8 bytes of data (padded with 0xFF if necessary).

It defaults to CRTD format. Mark from OVMS created that format for his tools. I then used it to help everyone be on the same page. But, now SavvyCAN supports all kinds of formats and I probably should really default it to the native GVRET format now.

Here is a sample line from CRTD:
1320745424.002 R11 402 FA 01 C3 A0 96 00 07 01

It's: timestamp, format (receive 11 bit, 29 bit, transmit, etc), the ID, then the data bytes.

Here is a same line of GVRET native:69401973,000005FC,false,Rx,1,8,00,40,03,01,00,00,00,01

Timestamp, ID, extended?, direction (Rx, Tx - from point of view of the capturing device) which bus, data length, data bytes (in hex)

Most people probably have GVRET files without the direction flag. It works fine that way too. It figures out the version based on the header line. This format is a straight CSV file.

But, heck, I'll add your CAN-DO format. Why not? My goal is support basically every format anyone could be using.

Do you have a description file of the MsgIDs and data fields for
all of your parcer's recognized variables?

My CAN-Do creates/uses a Recipe file where each record describes
a data variable, from 1 bit to 2 bytes, with possible scaling and offset.

Is there someone who is going to be create a repository
for the data field definitions,, log files, file formats, etc?

Well, I plan to add all of the public findings into a DBC file. DBC files aren't particularly easy to read with human eyes but they are an industry standard and several tools either read them or have converters. For instance, BusMaster can't use DBC files directly but it can turn them into DBF files and use those. So, a DBC file is a pretty standard way to store data like this. So, I think it's a decent enough way but it is not very human readable so that can be problematic.

As for a repository of log file formats and such, that's a potentially good idea. I have a lot of canbus capture formats figured out for SavvyCAN so I could explain many different formats. I suppose the question to ask is "what sort of things do people want explained?" Sometimes it can be tough to know what you should explain and what people either don't care about or already know. If someone starts a wiki or something then it would be helpful if people could request things that need explanation or description.

I will look at your capture format and your recipe files and see how easy it'd be for me to add support.
 
@garygid

Alright, I wrote all the code to support your file format (CANDO) but I have a couple of questions:

1. All files seem to start with a frame that has the third and forth byte set to FF. That would ordinarily be illegal. What is that frame for?

2. It seems like your timestamp and ID are stored in reverse endian order? Timestamp seems to be stored little endian while ID is stored big endian. Am I correct in thinking that?

That's it for the binary frame log format. I have questions about what all of the fields in your recipe file mean. Can you go through one by one and explain it to me (and everyone)?

I wasn't really a fan of binary file formats for storage as it makes things more difficult for people reading the files manually. But, I can see some upsides. Loading and saving to your format is probably 4x faster than loading and saving with the CSV style files. So, that's pretty handy for really big files.
 
They don't seem to have any kernel modules at all, so they just have what is compiled in for USB stuff, which appears to just be mass storage. Just about everything else is ignored, with a few benign exceptions.



Certainly! If you were able to get CAN3 logs from your car doing random things like driving/charging/etc I could use that to verify my findings are compatible. I've already found some differences between my P85D and my wife's P85, so the more data the better!



I have the audio files, although I'm not sure sharing them would be legal since they're Tesla's audio files. :-\

Which means you can replace the audio in your car. You should use homer's "d'oh!" for AP off, and HAL "I'm sorry Dave, I'm afraid I can't do that" for the AP can't be enabled sound. What to use for AP on....
 
Which means you can replace the audio in your car. You should use homer's "d'oh!" for AP off, and HAL "I'm sorry Dave, I'm afraid I can't do that" for the AP can't be enabled sound. What to use for AP on....

How about "V[SUB]1[/SUB], V[SUB]2[/SUB], Rotate" :biggrin:

For those not in the know, these are aircraft takeoff terms.

V[SUB]1 [/SUB] is the speed beyond which the takeoff can no longer be safely aborted
V[SUB]2[/SUB]
is the speed at which the aircraft may safely become airborne with one engine inoperative

Rotate is said as a recommendation to the pilot-in-command to pull back on the yoke or stick so as to place the aircraft at the proper angle of attack to safely climb.


 
How about "V[SUB]1[/SUB], V[SUB]2[/SUB], Rotate" :biggrin:

For those not in the know, these are aircraft takeoff terms.

V[SUB]1 [/SUB] is the speed beyond which the takeoff can no longer be safely aborted
V[SUB]2[/SUB]
is the speed at which the aircraft may safely become airborne with one engine inoperative

Rotate is said as a recommendation to the pilot-in-command to pull back on the yoke or stick so as to place the aircraft at the proper angle of attack to safely climb.



Vr (i.e., rotate) generally takes place prior to V2, so,
"V2, Vr, V2".
 
Links for CAN-Do use and file formats:

---------
Log File formats:
SOC-Meter CAN-Message and CAN-Do Log file formats - My Nissan Leaf Forum

---------
Recipe File Format:
As used in CAN-Do (6th post)
CAN-Do: User Manual - My Nissan Leaf Forum

a CSV file (all file values are decimal) with columns titled ...
[not really meant to be easily human readable]

"Var Name v105", (a text name for this recipe item)
[the v105 in the title is a version number for this file/format]

First data byte used to create extracted value:
"Byte A#", (data byte number, 1 through 8, 0 means ignored)
"Mask A", (entered as 2 hex chars, AND this with the data byte to mask off bits)
"Shift A", (> 0 is shift these 8 bits left, < 0 is shift right to combine with B)

Second data byte, if not ignored, 16 bits ORed to A after shifting:
"Byte B#","Mask B","Shift B", (like A)

"Plot Min","Plot Max", (The min and max values to be plotted.)

"2's Comp Ck", (if checked, the value is a typical signed value)

"Scale Fact", (if non-zero, after the Zero-Offset below, multiply by this value)

"Raw Zero", (this data value is considered Zero, before scaling)

"Reserved", (I do not remember the intended usage, if any)
[perhaps future, for making 3 and 4-byte values]

Message Filter, if not ignored (when C# = 0):
"Byte C#","Mask C", (like A)
"Equals C", (message ignored unless C masked equals this value)

"Msg ID" (the CAN Message ID)

---------
Getting CAN-Do installed:
GaryG's CAN-Do Program Page
and
CAN-Do: a CAN-message Analysis Tool - My Nissan Leaf Forum

---------
AVR-CAN for CAN bus Reading:
Gary SOC-Meter / GID-Meter Page
and
AVR-CAN hardware for CAN-data Capture - My Nissan Leaf Forum

- - - Updated - - -
---------
QC to LEAF charging, CAN message conversation.
QC Message Data Decoding - My Nissan Leaf Forum

This data is basically what occurs between the Tesla Chademo Adapter
and the Chademo charger, which we could see with our "QC sniffer".
 
Last edited:
Not to drag this thread too much more off-topic, but I don't even understand how that claim isn't illegal, the EPA has a clearly defined "gas savings" number, it's printed on the window sticker, and it's HALF of the number Tesla claims on their pricing page!

I believe they are assuming some free supercharger charging. Maybe they also include running an extension cord to neighbors outdoor outlet at night as well.
 
SavvyCAN works pretty well, too, and their default format is what I've been using for my parser. SavvyCAN tends to crash occasionally while capturing on my laptop for some reason, though... not sure what's up with that.

lolachampcar is working on an inexpensive solution to logging, also, if you're not in a rush.

@lolachampcar: do you already have a clear idea of what will be the difference in capability between your device and the SavvyCAN?
I have taken a look at the SavvyCAN but the shipping cost is $190.79 which is, like, Ludicrous...
 
Not to drag this thread too much more off-topic, but I don't even understand how that claim isn't illegal, the EPA has a clearly defined "gas savings" number, it's printed on the window sticker, and it's HALF of the number Tesla claims on their pricing page!

It's gas savings compared to some other ICE you're not feeding and driving. Not gas savings the MS provides.
 
jpet,

My goal here is to support this (relatively narrow) community's efforts to gather meaningful data. I've got the boards laying about and I'm actually having fun re-engaging my brain on the project. I think the battery health part is functional as is but will likely need some feedback from others on what form the burst performance logger will take. I then need to re-test my update functionality to make sure code can be updated in the field. Lastly, I've got ten cables on order which will need to arrive.

The question becomes what to do at that point. I believe the correct approach is to loan units to people with specific needs. I have no desire to sell them nor do I want to start doing batches of boards again (like I did for the key fob). Most were happy with the key fob but some of the feedback I got from a few people had me scratching my head and wondering what I did to deserve it. Forum members wanted one, I built it and shipped it at cost and simply asked to be paid for the bits once it arrived and people found that it met their needs or wants. Believe it or not, some did not pay and others gave me grief when they could not figure out how to pull the battery isolation paper out (required by the post office to ship the darn things) and yet others complained and then could not be bothered to send it back. I learned that no good deed goes un-punished :)

Let me get the rest of the coding and testing done, I'll post sample files of the output for the two different logging functions and we can go from there. Hope the above makes sense.
 
The question becomes what to do at that point. I believe the correct approach is to loan units to people with specific needs. I have no desire to sell them nor do I want to start doing batches of boards again (like I did for the key fob).

Ok, I understand. What I can contribute is testing data from Europe. I'm only 1 hour away from the autobahn where I can do some testing at full throttle.
I love playing around with this stuff and learning about all possible details of the car so I'd like to buy a CAN bus logger that allows me to get a maximum of data to do so.
I'm sure I would be able to help some folks in Belgium and the Netherlands that have questions on their battery health and things like that.

From what I understand, right now the SavvyCAN is probably the easiest option but I need to find a way to get it shipped at a reasonable cost. The list price of $295 is fine but adding $190.79 for shipping + probably an additional European import tax + VAT on top looks a bit much in comparison with the list price.

Respect for the work you and others are doing to offer all of this to the community for rep points only!
 
The question becomes what to do at that point. I believe the correct approach is to loan units to people with specific needs. I have no desire to sell them nor do I want to start doing batches of boards again (like I did for the key fob). Most were happy with the key fob but some of the feedback I got from a few people had me scratching my head and wondering what I did to deserve it.

As one that was very happy, thank you for your work.

Could you publish the board design so others could obtain the parts and build it themselves? I'd be happy to do that to build one (and would have fun doing it).