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.
If you do, please link to it here so those of us that are interested can follow along!

Will do after making some progress.

I'm not much help with the sensor values (thankfully I think others have given you solid leads), but I did have an idea on where to hide the speaker... There's a sort of "exhaust port" on each side behind the rear fender. It's where air escapes when you close a door/hatch. You could probably sneak a speaker wire through it and mount the speaker nearby. Routing the wiring to the back might be a pain though.

Thats what those things are for! pressure equalization... Also, I think that's a great idea.
 
  • Like
Reactions: jvonbokel
Nice thread!
Also built a bench setup. But I don't want to be at the setup all the time, when playing with it. Is there any way to keep it online forever at least some hours? Tried some API's, but nothing worked. Once it even passed away during scp^^
Last chance would be to install a remote controlled circuit breaker :D
 
  • Like
Reactions: apacheguy
Nice thread!
Also built a bench setup. But I don't want to be at the setup all the time, when playing with it. Is there any way to keep it online forever at least some hours? Tried some API's, but nothing worked. Once it even passed away during scp^^
Last chance would be to install a remote controlled circuit breaker :D

You want to prevent sleep? There are a few sleep variables you can mess with. One is called "never sleep" or something like that.
 
The other somewhat related one I'd like to find is a way to wake the IC and CID from the LAN
I can wake them up with the remote API, but I'd like to find a way to do so without going through the Tesla servers.

Seems like there should be some form of "wake on lan" or similar functionality on these things?
 
@marco2228
this is what I do to keep the bench setup awake (at a spare mcu shell):
sdv GUI_neverSleep true
sdv GUI_sleepAtNight false
sdv GUI_enableSleep false
while :; do sleep 120 ; sdv GUI_lastTouchTime `date +%s` ; done

The other somewhat related one I'd like to find is a way to wake the IC and CID from the LAN
I can wake them up with the remote API, but I'd like to find a way to do so without going through the Tesla servers.

Seems like there should be some form of "wake on lan" or similar functionality on these things?
on mine once it's asleep, the lan is down too, but if you trigger the brake GPIO, that should wake it up (I know, not LAN).
 
@marco2228
on mine once it's asleep, the lan is down too, but if you trigger the brake GPIO, that should wake it up (I know, not LAN).
So what is it that allows Tesla to wake it up?
The VPN would appear to be down, the LAN is down, do they send an SMS? what mechanism does Tesla use to wake the car?

Brake GPIO has 2 issues, one is that it wakes the car up too much, I only need it to wake to accept commands, I don't need (or want) the screens to come on.
I can't do it remotely, which is the whole point, if I'm in the car, I can manually wake it quite easily.

I don't so much need to stop it from ever sleeping, but I do want to find a way to wake it up without using Tesla's servers (it's the only function left that I need their server for unless you count updating the list of superchargers, and that's somewhat optional)
 
So what is it that allows Tesla to wake it up?
The VPN would appear to be down, the LAN is down, do they send an SMS? what mechanism does Tesla use to wake the car?
I did not really look too much into it, but I suspect parrot module might still be awake?
In that case it being a usb device (so does not depend on the lan being up) might wake the host (cid) whenever it feels like (it might also have a dedicated gpio for that purpose, like I said, did not reallly look too much into that).
Just see in the parrot firmware what does it do?
 
@marco2228
this is what I do to keep the bench setup awake (at a spare mcu shell):
sdv GUI_neverSleep true
sdv GUI_sleepAtNight false
sdv GUI_enableSleep false
while :; do sleep 120 ; sdv GUI_lastTouchTime `date +%s` ; done


on mine once it's asleep, the lan is down too, but if you trigger the brake GPIO, that should wake it up (I know, not LAN).

Thanks, that seems to work :)
 
I did not really look too much into it, but I suspect parrot module might still be awake?
In that case it being a usb device (so does not depend on the lan being up) might wake the host (cid) whenever it feels like (it might also have a dedicated gpio for that purpose, like I said, did not reallly look too much into that).
Just see in the parrot firmware what does it do?

Parrot module is definitely off during sleep. The remote wake up signal is SMS.
 
I am trying to rig up a jetsons type sound also (just for some fun every once in a while) and I have a can bus cable, but I am not sure that the Can hi and can lo pins are the same on the MX as on the MS. (I have an MX) This is the cable: Tesla Diagnostic Cable For MS/MX (Sept 2015 and up) - Bare Wire Version

I am using can 3 hi and can 3 lo for my rpm/voltage data and it is feeding into an EVSM device from here EVSM

Sine the EVSM needs pulses, I am using CANM8 CANNECT PULSE which converts the can into a pulse the the EVSM can see.

The issue is that I am not seeing the pulse on the pulse interface device, so I am speculating that I am on the wrong pin. Does anyone know what the Can Hi and Can lo pins are for the MX? thanks.
 
can2.jpg
this is the pinout I am using. Using 18 and 19
 
Last edited:
View attachment 225970 this is the pinout I am using. Using 18 and 19
I can assure you that the MX and MS Powertrain bus are on the same pins, Tesla's own schematics don't lie. I think the issue comes down to the devices you are using. I'm assuming you are aware that in order for the CANM8 to output a pulse it needs to decode the signal that encodes motor RPM or speed, how sure are you that they have the right CAN message and decoding of it. Their spec page lists the MS 2013- but not the MX. I'm guessing Tesla may have reshuffled some of the CAN id's when architecting the layout of the MX so it might be good to check with CANM8 to make sure, it also wouldn't hurt if you had some other device like the CANtact or CANdue to make sure you are getting valid messages off the bus. Remember the adage "Garbage in garbage out".
 
I can assure you that the MX and MS Powertrain bus are on the same pins, Tesla's own schematics don't lie. I think the issue comes down to the devices you are using. I'm assuming you are aware that in order for the CANM8 to output a pulse it needs to decode the signal that encodes motor RPM or speed, how sure are you that they have the right CAN message and decoding of it. Their spec page lists the MS 2013- but not the MX. I'm guessing Tesla may have reshuffled some of the CAN id's when architecting the layout of the MX so it might be good to check with CANM8 to make sure, it also wouldn't hurt if you had some other device like the CANtact or CANdue to make sure you are getting valid messages off the bus. Remember the adage "Garbage in garbage out".

I've confirmed the wiring is correct and I tried another device made by kufatec that doesn't need the canm8 to get the pulse signal, and it also does not work on the MX. I think you are dead on accurate that the devices I am trying that work on the S must not be reading the MX data correctly. Kufatec in Germany is super helpful and willing to reprogram their module with the data I provide (they don't have an Mx to test), so I should probably get an analyzer. Do you have one you suggest. Ps. I know just enough to be dangerous!