Did you also get the battery from that vehicle for your other project or are you still waiting to hear back from Tesla on that? I imagine if you negotiated that large salvage battery purchase, you could possibly have got these goodies thrown in for not too much more to allow for the fun you are now having.
I didn't pick up the battery from this salvage since it was already sold. As for the deal with the 90 pack swap with Tesla and keeping my 85 pack... I'm not getting my hopes up. Probably will hunt for a pack for my project once I get closer to the point of actually needing one to install.
I don't know how much you followed artsci's thread on the front camera switch, so it's possible you know all this, but just in case you don't, I thought I'd share...
My understanding (and since artsci is following this thread, he can correct whatever I get wrong or can just fill in the gaps) is that when they were working on the original front camera switch they couldn't get the display to work with anything other than the same rear camera Tesla was using. So the switch wound up being designed to use the rear camera on the front of the car, as that was the only video signal they were able to get to display on the 17" screen.
I'm just pointing this out, in case you knew nothing about all that, in which case what you're thinking may be the easiest part may prove not to be so easy after all.
Yeah, I don't know the details. It just looks like a low voltage differential data link. Since I'm not messing with my actual car to get details I'll have to wait until I get a Tesla rear cam to mess with.
So, I guess speed is stored as just one byte?
That's amazing stuff you're doing. Care to summarize what you sent to the console to make it drive that fast and use that much energy? Are those two things related or independent?
Yep, speed is sent as one byte. There are a couple of bytes for the analog speed readout (which I can send to be in a different position than speed), a couple of bytes for the position of the cruise setting, and a flag for cruise enabled. That's all one CAN packet, ID 0x0256 on CAN bus 3.
The power meter is a little more annoying. I figured out the signal for it... but haven't nailed down the encoding of it. Was tweaking bytes to get some results and was just scratching my head.
Turns out this packet on a P85D is different than the packet this bench setup expects. The P85D sends an 8 byte packet, where a CAN log I have from another vehicle that someone sent me a while back shows it as a 6 byte packet. Not enough data yet to really figure out exactly how to finely manipulate the power meter.
In case anyone else wants to take a crack at it... here is that packet logged from a P85D:
http://skie.net/uploads/powermetercan.txt
Starts sitting still, slowly up to ~20 MPH, then full throttle to 60 MPH (power ramp starts around packet 715 or so), then full regen to ~40 MPH, then some normal driving and finally stopping again. I don't have a P85D that I'll play CAN packets to, so, can't really test the results. But I know for sure that this is the only packet needed to move the power meter on my bench setup. Good luck. Maybe I'm just sleepy, but I couldn't figure out exactly what the values worked out to be. Definitely the first 4 bytes turn into the power meter read out. It's definitely not quite right on the bench IC, since full power from the P85D log ends up at ~60kW on the bench display. I'll have to log from a non-D one of these days.
if you could find a way to splice into the line inputs everyone with an iPod or non-Bluetooth device would love to get that hack. Perhaps a switchbox that intercepts the radio line and switches to an aux input when you want to listen to your iPod then you could flip the switch and go back to the radio
Probably pretty doable, but probably not really worth it given the bluetooth audio stuff, IMO.
