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.
That all said I am definitely not a software guy, so any help to improve functionality is much appreciated. If you want to PM me your git email/username then I can add you as a contributor.

My git user name is also zdre. I spend a good amount of time optimizing software performance at work, so am sure I can contribute some improvements.
I using a low-power netbook to log the data, and it seems to be missing many frames. It took me about 5 10,000-frame attempts to actually capture Battery Odometer frame. It seemed that the netbook was not pulling them off CANtact fast enough. I am trying to enhance logging performance to log as much as possible on low-end hardware (maybe even connecting CANtact to a Raspberry Pi) This would require the serial communication to happen on a separate thread from any parsing and file output.

How many frames are you able to capture per second when idle? I am yet to try a capture using a higher-spec laptop.
 
Last edited:
Here are some of my numbers when fully charged:
Nominal Energy Pack Full: 56.6 kWh
Nominal Energy Remaining: 39.2 kWh
Expected Energy Remaining: 40.8 kWh
Ideal Energy Remaining: 39.2 kWh
Energy (Bricking?) Buffer: 1.4 kWh
Pack Voltage: 336.50
Battery Odometer: 34172
SoC UI: 69%

I am not sure what the difference between Expected and Ideal energy remaining.
 
Here are some of my numbers when fully charged:
Nominal Energy Pack Full: 56.6 kWh
Nominal Energy Remaining: 39.2 kWh
Expected Energy Remaining: 40.8 kWh
Ideal Energy Remaining: 39.2 kWh
Energy (Bricking?) Buffer: 1.4 kWh
Pack Voltage: 336.50
Battery Odometer: 34172
SoC UI: 69%

I am not sure what the difference between Expected and Ideal energy remaining.

This is interesting... As what voltage are your cells when you are at 100% SoC? I'm curious how Tesla limited the usable capacity of your battery.
 
This is interesting... As what voltage are your cells when you are at 100% SoC? I'm curious how Tesla limited the usable capacity of your battery.

Pack Voltage: 336.50

336.50 / 84 = 4.00V... which seems a bit high for 69% SoC... was this while still charging?

- - - Updated - - -

How many frames are you able to capture per second when idle? I am yet to try a capture using a higher-spec laptop.

The power train bus is easily a few thousand frames per second. It's likely not the laptop but the CAN logger that isn't catching them all.
 
This is interesting... As what voltage are your cells when you are at 100% SoC? I'm curious how Tesla limited the usable capacity of your battery.
They limited the capacity by only allowing it to charge to ~69%... so I cannot charge any more

336.50 / 84 = 4.00V... which seems a bit high for 69% SoC... was this while still charging?
The power train bus is easily a few thousand frames per second. It's likely not the laptop but the CAN logger that isn't catching them all.

I was plugged in and had heat on at that time, so charger was probably applying voltage to the pack. Will look what pack voltage is when just completed charging and not plugged in.
Theoretically, the CANtact adapter is supposed to be internally buffering the frames on the chip, so it should not be losing frames unless you can't pull them fast enough through USB... but I really do not know what is actually going on.
 
They limited the capacity by only allowing it to charge to ~69%... so I cannot charge any more

I was plugged in and had heat on at that time, so charger was probably applying voltage to the pack. Will look what pack voltage is when just completed charging and not plugged in.
Theoretically, the CANtact adapter is supposed to be internally buffering the frames on the chip, so it should not be losing frames unless you can't pull them fast enough through USB... but I really do not know what is actually going on.

Just to add something, the ID I'm using for voltage is 102, based on one of my colleagues decodes he thought the pattern was (B3*256) + (B2/100), according to sheet from wk057 B1/0 is the total pack voltage, and B2/3 is pack current, based on wk's research and privileged access I'm more likely to believe his interpretation, I'll update the script accordingly.
 
I'll try it out tonight. Removing the sides of the console is pretty easy : you just pull them on each side. I just hope I don't have to unscrew the console's center part (4 screws) to access the connector.

One thing for sure, I retested this morning and with the console installed, there is now way the cubby can be pulled down enough to get to the connector.
Mistery solved.

I removed the console (10min job) and there was nothing behind...

a33da0bdafe1cc03a3ec35f6a798ecb8.jpg


Then I saw the 4pin ethernet connector on the right.. Followed the harness and bam, voila:

8793b4bbb0ecb40cc3615500c160ccc6.jpg


Simply pull out the right trim from the center bump and you're good to go, the connector's right there!
 
Wow, this means your pack will never top balance. Scary!

Service Center will do a full charge at the yearly service if requested... But many people never actually charge to 100% even though they can.

- - - Updated - - -

336.50 / 84 = 4.00V... which seems a bit high for 69% SoC... was this while still charging?
The voltage while not charging showed 326V
EDIT: not sure this is right any more.
 
Last edited:
336.50 / 84 = 4.00V... which seems a bit high for 69% SoC... was this while still charging?

- - - Updated - - -



The power train bus is easily a few thousand frames per second. It's likely not the laptop but the CAN logger that isn't catching them all.

The power train bus has about 2200 frames per second as far as I remember. That's somewhere in the neighborhood of 40% bus utilization.

The CANTact firmware doesn't use interrupt driven reception but does seem to use the hardware FIFO. I believe that should be at least 3 deep but I don't know. It also pretty tightly monitors for new frames so it shouldn't be missing any. Though, a three deep buffer means that you can't store four frames or more in between loops in the main firmware.

The USB interface is a bit strange. It is polled which most people probably don't expect. Essentially the host polls the connected devices to see if they want to do something. You can send a decent amount when it is your turn but you have to buffer until then. I think the default poll time is something like 10ms. At the data rate on the power train bus that could be something like 20-22 frames per USB transaction. A CAN frame is probably only like 30-40 bytes even in ascii output so you're looking at maybe 600 or so bytes. If the USB side is using a 512 byte buffer then this would be a problem. But, I think you can set a buffer size of like 4096 bytes or something for USB so presumably that hasn't happened.

That leaves the software side on the PC. Python isn't really known for speed but I would think that it would be able to handle the comparatively slow data rate of CAN. Even the text mode data stream that CANtact uses can't be that much. 2200 frames per second * 30 bytes per frame (just a guess) is a whole 66,000 bytes.

So, not sure why it would drop frames, doesn't seem like it should have trouble.

Of course, I know someone whose products can do 5000 frames per second with no drops at all. B)
 
With the Nissan LEAF, we investigated its 4 CAN buses, and found some useful data,
and others discovered how to Request Data (like the 96 cell voltages) and interpret
the results. They made an excellent Leaf Spy Android app, to run on a smartphone
and connect via bluetooth locally to a CAN-to-Bluetooth dongle attached to the LEAF's
Diagnostics connector.

This app was programmed for Android using B2A, and LeafSpy had a free LeafSpy Lite
to test out your dongle and phone (showing a vertical bar graph of the 96 cell voltages)
before buying the $10 LeafSpy app. Then, a LeafSpy Pro was created, offered for $15,
that would read the Diagnostic Trouble Codes, etc. Eventually there was even a twin app
that supports iOS phones.

Sense you have located some useful "hidden" data on the 4 Model S CAN buses, it might
be possible to get a copy of the LeafSpy B2A-based program, and modify it for use with the
Model S (and X). I will be speaking to the program owner soon about this.

Perhaps there us someone here who has the time, talent, and temperment for this
programming project to help out the MS and upcoming MX community?

If you are capable, or want to learn, and seriously interested, please send me
a Private Message with your contact information and I will email or call.
Work on TMS-Spy has started and the basic code to move the 0x6F2 Frame data and scale it into the cell voltage array is done. Plotting is the same as LeafSpy since Leaf also has 96 cells so once the array is loaded with Tesla data it will be displayed using the same code. Temperature display code will need to be changed to go from the 3 or 4 sensors the Leaf has to 32 on the Tesla but that is not a big deal. To keep things the same the cell voltage is stored as an integer millivolt value so resolution is kept to 0.001 volts.

Until I get a cable and access to a Tesla I will use emulation mode in the app which allows a set of stored frames to be feed into the code as if it came from the serial port.
 
Quick Q. for the SavvyCAN experts...

How is the time stamp defined?

The time stamp you see normally is microseconds since the capture hardware started. That gives you a *very* precise timestamp but it is somewhat cumbersome to work with. It tends to be easier to read if you go to File->Preferences->Display time in seconds. Then the next time you start the program (and thereafter) it'll display the timestamps in seconds which tends to be easier to read.
 
The time stamp you see normally is microseconds since the capture hardware started. That gives you a *very* precise timestamp but it is somewhat cumbersome to work with. It tends to be easier to read if you go to File->Preferences->Display time in seconds. Then the next time you start the program (and thereafter) it'll display the timestamps in seconds which tends to be easier to read.

Thanks for the confirmation. I had assumed it was in microseconds, but wanted to double check (in case it was an internal counter or similar, and the timings were coincidental.)

Microseconds works perfectly for my purposes (grabbing a straight text log from a run, then feeding it into some graphing stuff, where I can scale appropriately to 100's of a second), but handy to know.
 
Work on TMS-Spy has started and the basic code to move the 0x6F2 Frame data and scale it into the cell voltage array is done. Plotting is the same as LeafSpy since Leaf also has 96 cells so once the array is loaded with Tesla data it will be displayed using the same code. Temperature display code will need to be changed to go from the 3 or 4 sensors the Leaf has to 32 on the Tesla but that is not a big deal. To keep things the same the cell voltage is stored as an integer millivolt value so resolution is kept to 0.001 volts.

Until I get a cable and access to a Tesla I will use emulation mode in the app which allows a set of stored frames to be feed into the code as if it came from the serial port.

Nice to see you over here Jim! I'll be happy to give you access to my little fleet if you wanna come by. =)
 
The power train bus has about 2200 frames per second as far as I remember. That's somewhere in the neighborhood of 40% bus utilization.

Can someone explain why there is so much traffic? I mean why do we need to know motor rpm 100 times a second? Seems crazy. 10 Hz should be the maximum frequency sent out. Interpolation is arguably just as robust if finer scale is needed, but frankly I don't see the need. Most cars have bus rates that are much, much less than the Model S from what I gather.
 
Can someone explain why there is so much traffic? I mean why do we need to know motor rpm 100 times a second? Seems crazy. 10 Hz should be the maximum frequency sent out. Interpolation is arguably just as robust if finer scale is needed, but frankly I don't see the need. Most cars have bus rates that are much, much less than the Model S from what I gather.

Most cars don't have electric motors that can be manipulated "on the millisecond level", to use an Elon Musk term. :)
 
Here is the battery temperature graph. As I understand it there are thought to be pairs of sensors one on the inlet the other on the outlet coolant port. For that reason I have grouped the temperatures in pairs. The data is from sample CAN frames in the Tesla format. I would assume different pack sizes have a different number of sensors. How is this reflected on the CAN bus? Same number of frames but some have zero for data or less frames?

Screenshot_2016-02-11-22-08-56.png