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.
I worked on the camera interface a bit, but I haven't been able to get the display to show the cam input at all yet. I've ordered another camera to try some more with. For for details, it appears that the camera is controlled by an FPGA in the CID unit that sits between the display and the main processor. Then it overlays the camera feed as directed directly to the display output. The video from the rear cam never goes through the OS of the CID. This would explain why Tesla can't utilize the rear camera video for anything related to driver assistance/autopilot. It will also make this particular goal of my project more difficult since there isn't any code or anything I can look at and disassemble to make things easier.

Im just catching up on this after the holidays - so much awesome stuff happened in the meantime - and nice to see another player on board.
Need another one, just pitch me a PM.

On the other side. Thought Id share how the rear view camera is connected, in case you dont have the schematics.
 

Attachments

  • Skjermbilde 2016-01-14 kl. 14.46.45.png
    Skjermbilde 2016-01-14 kl. 14.46.45.png
    81.8 KB · Views: 289
FYI: Lithium Ion (and in fact most all) battery chemistry has a non-linear discharge curve. It's hard to accurately discern capacity from voltage, which is why Tesla (and most everyone else) uses coulomb counting to more accurately determine SoC.
He-he... yeah, I know that. I was trying to give a super simplistic answer why the 0.05V mattered. But you are of course right.
 
Would be interesting to read DCDC_outputPower/Current and see whether the draw in "sleep" mode is more than just the CID. (This could of course be done with an external clamp...)

Definitely an interesting point. Does passive cooling of the pack activate at all while the car is sleeping? Probably hard to tell until temps start to rise.

Although, in sleep mode the DCDC is not engaged at all. It would have to be determined off of 12 V draw.
 
Hmm... yeah, did all of that. I even tried parking, enabling max power, drive, brake, accel, etc... no dice. Just "both pedals pressed." I'll try it again tomorrow.

I did make a CAN log of the car self-parking with summon...

Brake pedal must be pressed HARD. Then try to tap the accelerator to the bottom and back up, like a bass drum pedal. Sometimes takes me more than one try. Range mode off?

- - - Updated - - -

My guess is T/C


Yeah, it's my guess that TC actually activates long before the dash icon shows. Finding a CAN message for that would be awesome.
 
FYI: Lithium Ion (and in fact most all) battery chemistry has a non-linear discharge curve. It's hard to accurately discern capacity from voltage, which is why Tesla (and most everyone else) uses coulomb counting to more accurately determine SoC.

So... Do you know the voltage that is mapped to 0%? Or perhaps have a data point somewhere in the 0-20% range.
 
I'd be interested in knowing what exactly these variables are influencing/reporting, and if there's any method to change them:

Code:
[COLOR=#333333]BMS_maxRegenPower
[/COLOR][COLOR=#333333]DI_regenPowerMax
[/COLOR]

100KW regen, anyone?
 
I've got 7.1 and can confirm (as others have) that launch is still there. Was it an ambient temp issue?

Hmm... that could be it. Whats the temperature limit? Was 25F out at the time. Battery was 32C/90F though.

You meant speed_in_mph*10

Hehe, oops. :) Yeah, it's given in increments of 0.1 MPH in that field. I found another that is 0.05 MPH though. hehe.

What do you think BMS_socUI is?

It's the percent state of charge shown on the UI.

Im just catching up on this after the holidays - so much awesome stuff happened in the meantime - and nice to see another player on board.
Need another one, just pitch me a PM.

On the other side. Thought Id share how the rear view camera is connected, in case you dont have the schematics.

Yeah, I have them... however I'm waiting on my camera part still.

I'd be interested in knowing what exactly these variables are influencing/reporting, and if there's any method to change them:

Code:
[COLOR=#333333]BMS_maxRegenPower
[/COLOR][COLOR=#333333]DI_regenPowerMax
[/COLOR]

100KW regen, anyone?

I've actually seen these about that high. Snippet from the parser I'm making.......... and plan to GPL... shh. ;)

Code:
--- BMS_maxRegenPower:     98.47 kW
--- BMS_packPower:   78.365 kW
--- DI_regenLight:       1
--- DI_regenPowerMax: 96 kW

This was right after a 0 to 1:eek::eek: run, and was while using the friction brakes too. The friction brakes don't seem to have any real effect on regen, except when using them heavily they can lower the amount of regen you can get, obviously, as a physics thing not a software thing.

I've only focused on reading data. I haven't focused on controlling anything.
 
So... Do you know the voltage that is mapped to 0%? Or perhaps have a data point somewhere in the 0-20% range.

I've never taken my car that low (yet). I know when it goes to 0% shown, there's actually around 7-10% SOC in "reserve" as reported by the BMS. I think at 5% real SOC (display well into 0%) 12v support stops. Car will still move at very low power, and at some point undetermined (probably around 3%) drive stops and BMS goes into hibernation. (anti-bricking) If I have the pleasure of witnessing this again, I'll be sure to note the voltages.

- - - Updated - - -

I'd be interested in knowing what exactly these variables are influencing/reporting, and if there's any method to change them:

Code:
[COLOR=#333333]BMS_maxRegenPower
[/COLOR][COLOR=#333333]DI_regenPowerMax
[/COLOR]

100KW regen, anyone?
The BMS decides what is a maximum safe regen limit and informs the DI. The DI then will not exceed this limit. These are not alterable. This is to limit charge power into the pack when it's at high SOC, cold, etc.

I believe there is a CAN frame sent out by the gateway that controls regen level as a single byte. The CID via the VAPI tells the gateway which mode the user has chosen (normal or low regen) and then when in drive mode this frame is sent to the DI with one one 2 byte values sent. It should in theory be possible to intercept this frame and alter it such that we could have adjustable regen from 0 to 255. Of course the regen power limit stipulated by the BMS will still apply, but the DI will do it's best to deliver up to that limit.

I do not believe the VAPI allows for variable regen outside of the 2 levels, (but I may be wrong) so it's not a simple code hack.