Tesla Motor Spinning

[EV_Builder]

Wanted to let everyone know that i made the Tesla Small drive unit spinning on the bench with its original parts in it.

I also recieved my OpenInverter board so atleast i'm prepared for the worst

My idea is to use the original tesla board and have the openinverter board when i'm done with the Tesla solution

[joromy]

Very interesting!!
More info pictures/video, please.

[johu]

Yes, more info
Did you reflash the processor or run the original Tesla firmware?

[Jack Bauer]

Ahhh, the sekret Tesla can messages again. I'll jump in as the op seems to have keyboard laryngitis. Back in the pre immobiliser days all we needed was 7 little can messages to make a large rear du run :

108 - two counters
202 - fixed values
212
21C
228 - mode command
232 - battery power limits
358

But then the media got all excited about "car hacking" and for extra clicks "Tesla Hacking" and so enter the immobiliser. A 256 bit challenge response between the drive unit and the mcu (center display). No response to the challenge = no spin spin for you dastardly car hacker!
So what to do? Option one : if you happened to have access t othe car the drive unit was from you were all set. Just grab a can log, answer the challenge and all is good in the world. Option two : Downgrade the firmware in the driveunit to a pre immobiliser version. This was usually accomplished via the can bootloader as the Musko had locked out the jtag port on the drive unit mcu. Of course it could be unlocked via the can bootloader.

That's about where I lost interest and designed the replacement boards. I got a LOT of pushback at the time. "It'll never be as good as Tesla" was the usual lament. As time went on I was offered details on all this sekret sauce but to be honest it holds little interest as it won't help people get into Tesla swaps cheaply. Even this year I was told how to run the M3 du via can. But guess what? I can make THIS du run via can but not YOUR one. Hence the modboard. Jon Volk recently replaced his DU due to a gear explosion. Oh no! what version is the mcu firmware? oh no now we have to reflash it......nah. Just swap the logic board and go driving.

[EV_Builder]

Mhhh do i taste a bit of bitterness??
Sadly the small drive unit was not that easy. Also i dont had a car (model S) or car logs (from a recent model S D). I just bought the drive unit from the junk yard.
Now on my route to victory i indeed stumbled across the IMMO problem. I solved that part, in the end, by buying the BCM of the same vehicle on that same junk yard. But! The original key was nowhere to be found... Weeks passed by until i discovered what was going on.
Then i discovered tinkering around with the BCM that it had a leak/design feature Now i had my key for the drive unit!

The small drive unit needs way more then 7 messages if you want to eliminate all errors and not having logs from a Model S D was quite challenging. Sadly the hacking world is not that opensource .

But wy? Wy did i all do this?
Well now i'm doubting that too hahaha

In Holland there are two ways to get a car on the road. You import it from an EU country (licensed) or you pass inspections.
The inspections demand EMC certificates for the car or for each component. The complete vehicle needs to pass (there are laboratoria todo that) or you need R10 certified parts.
BUT: Going the R10 way will only work on older cars now a day's the rest of the car also has non R10 parts. So you add some R10 parts but the new combination isn't certified by itself. So for older cars no problems, newer cars you still need todo the laboratoria test. So be carefull with buying EMC certified parts it isn't a passing guarantee more a 'less' problem during said laboratoria test.

During the process of the hacking i thought i better buy the openinverterboard, being disconnected from the scene i feared it would walk away (its stock) and wanted to save me one.

Now i need your advice on EMC who has EMC measured its car and found the openinverterboard passed?
What are the safety differences between the original board and the open inverter board? Is the HVIL still available on the big connector?
Is the pedal dual pot? (if i remember at the beginning it wasn't). Nice that its DUAL pot
Why does tesla use an FPGA i suspect, to fire the IGBTs and determine firing position of the IGBTS and we do that with software?

What would be the efficiency difference between the units?

[Jack Bauer]

Nope not bitter. Just tired of being a lone sharer in the Tesla world really. One of the reasons I stepped back from selling drive unit boards. Anyway, well done on getting it running and lots of people here have experience with emc testing so am sure they will jump in. Not yet needed in Ireland but I'm sure its on the way:)

[EV_Builder]

I wasn't serious Anyway i really admire your skills Damian i think you are one of a few.

We should disrupt the market with the sharing experience the only thing what can happen is that people start sharing too and then perhaps in the end it doesn't make sense to buy an openinverterboard? Anyway i truly think that what you do is amazing and big fun.
Our biggest challenge is to structure information such a way that people with less skills find there way quickly.

I also have thought about participating more in this community and propose changes.
One of the things i was thinking on was why not make a tesla compatible board? Swapping drive units should be easy. Especially for the repaired cars market i suspect that they would like open replacement boards.

Can you elaborate more on the FPGA side?

[johu]

We should disrupt the market with the sharing experience the only thing what can happen is that people start sharing too and then perhaps in the end it doesn't make sense to buy an openinverterboard?

I appreciate your concerns but the existing board shall not stand in your way to publish your findings in detail

One of the things i was thinking on was why not make a tesla compatible board? Swapping drive units should be easy. Especially for the repaired cars market i suspect that they would like open replacement boards.

Hmm, I reckon the boards in the openinverter shop are Tesla compatible, no?

[EV_Builder]

Hmm, I reckon the boards in the openinverter shop are Tesla compatible, no?

Yes, but not when used in a Tesla, software wise i mean.

So i figured that if we would add full canbus support and map it to your program we basically have a Tesla replacement part.
Offcourse we would have to deal with different versions and stuff but hey it basically means all Tesla's can be tuned by open inverter

Saying that it's allot of work and i don't have ways to test or even check all versions. For that we would need a rooted car etc..

Where does Tesla use the FPGA for?

[EV_Builder]

I appreciate your concerns but the existing board shall not stand in your way to publish your findings in detail

The thing is its like Damian says. Allot of CAN messages just hours of fidling. Wrestling with CRC checks. They used a couple of variants in there.
And then, in the end, you are able to send a GEAR change command. And then you hit the throttle and the motor runs/spins.
I think i have like 30 can messages in there right now.

I made a GUI program in C# connected to my PEAK USB CAN adapter. I used a Arduino DUE (i advice people to ditch the default IDE and at least go VS2017 with a plugin. Very nice! )Behind the GUI i use WireShark so the CAN packets in the end all end up there for filtering or checking the DUE program etc.

Later in the process i started using Savvy CAN because i found some DBC files. Which obviously helped.

While developing and searching for the answers i also added things to the GUI like CRC calculations to check a message.
I could play a log file. I could live build up a filter list (a missed feature in savvy can IMHO). And i could compose a message with 64 check boxes.
(to toggle settings) offcourse after i grabbed it live from the wire.

The findings are also that the messages change per firmware revision. Perhaps not allot but they do change. The paper from WK057 is quite old and incomplete. It is still like 70% useful though on (firmware 33506 / begin 2019).

[EV_Builder]

[JaniK]

So that's diy CAN controlled? Nice

[Jack Bauer]

In the large drive unit the fpga was used to decode the sigma delta current sensors and provide anti commutation on the pwm signals. I looked at doing this and in fact designed a version of both boards with an fpga onboard but really what was the point. You can do anti commutation with a few nand gates (Johannes would love that). I think they just used a cpld on the small unit if memory serves due to analog current sensors. More than likely they also included some logic to kill the igbt drive on a desat event.

The hvil loops are used on the sdu board (hence the ext hvil override jumper for testing) so if the hv connections come out it kill the pwm. Not used on the ldu board due to lack of pins on the 23 way connector but if you really wanted it then it could be designed back in. Both support single or dual throttle channels.

Early inverter failures using the openinverter boards were down to dropping the main contactor under load during an overcurrent. A large voltage spike resulted and blew one part of one side of a phase leg. Also some people wired a bms to the contactors that did the same with the same result. Now that that is understood no more failures.

[collin80]

While developing and searching for the answers i also added things to the GUI like CRC calculations to check a message.
I could play a log file. I could live build up a filter list (a missed feature in savvy can IMHO). And i could compose a message with 64 check boxes.
(to toggle settings) of course after i grabbed it live from the wire.

Ask and ye shall receive. But, I think it already exists. When we were first trying to figure out which messages were required for spinning the original LDU from a Model S we would play back logs from a car and selectively uncheck one message at a time until the LDU would no longer work. In this way we could quickly narrow down which messages were required. So, unless I'm not understanding what you wanted to do, it's already there. There's plenty of places where you can build up filter lists. You can even save and load them.

[EV_Builder]

No, i mean live making that filter list. So when you open the file it fills a list, but then you can check a checkbox and every CAN ID which it sees on the bus is then checked and added in that filter list for ya. It's the typical use case what you describe. It saves the work of going through log files and making lists of what the device spits out and what you are gonna inject. I never want to inject what already is there, that's easily solved.
And when i update the VCU it adapts the filter.

The other feature i missed is that from a message it would be nice being able to see the bit field and being able to toggle them. So you can like prepare the message bytes. Now i kept the DBC file manager open and or notepad++ with the raw file to lookup 'options' in the fields.

Another thing which i added was a array builder so if i had a log what worked i could filter it out to the 16 message cycle i needed and then i could build the array code for it. That code was then added to the arduino due project to test/save the new sample injection.

Being able to build structs and or constants from the DBC file would also be very cool. Then you could fast develop nice code with the known definition of the data .

Hope i spread some inspiration and shared some insights of how i did it / modded my tools etc..

[EV_Builder]

So that's diy CAN controlled? Nice

Yupsz i used a DUE with an double CAN shield.

[EV_Builder]

In the large drive unit the fpga was used to decode the sigma delta current sensors and provide anti commutation on the pwm signals. I looked at doing this and in fact designed a version of both boards with an fpga onboard but really what was the point. You can do anti commutation with a few nand gates (Johannes would love that). I think they just used a cpld on the small unit if memory serves due to analog current sensors. More than likely they also included some logic to kill the igbt drive on a desat event.

Well the truth is that they have allot of extra stuff going on in that DU then only controlling a motor.
Traction Control for example. The drive unit commands the brake system which wheel to brake for example.
It's also those same systems you need to beat (and keep beating) to get it running properly.

Also there is still the front drive unit. You need to solve the absence of that device also.

Would be interesting to do a load test comparison. It would learn us about efficiency.

[Boxster EV]

From my limited experience, most folk (and EV conversion specialists), don’t want the bells and whistles you describe, as the hardware is being fitted to vintage and more analogue vehicles. Perhaps in the future this will change but I doubt it.

There’s also the argument that complicating the method of
making the motor spin by requiring a modicum of CAN knowledge would be unwelcome. The present situation of dropping a low cost logic board straight in and you’re away is far more appealing. At least in my experience anyway.

Just my 2 cents.

[New Electric Ireland]

In my experience many people find open source solutions desirable. This is not always possible (for example when warranty or approvals are required) but I see no value in yet another closed source Tesla solution today

[Isaac96]

I'd love a Tesla controlled drive unit just for that efficiency and lack of tuning required. Also reliability would be much higher -- open source solutions unfortunately don't have as much R&D money behind them.
To each his own. Publishing things is better though

[EV_Builder]

Ok well for now i'm gonna try the opensource board. The Tesla software solution is a hard one to get perfect.
In fact there are parameters to be send to the drive units about drag coeff and mass of the vehicle etc. etc.
And if you don't have manual of what it does with the unit....

So i bit the bullet and started of on the opensource board. Let's wait and see

[ravikashi]

And then, in the end, you are able to send a GEAR change command. And then you hit the throttle and the motor runs/spins.
I think i have like 30 can messages in there right now.

Is it really just the GEAR change and throttle? They are both in the CAN message ID 0x118. I am lucky to have a Vector CANalyzer tool that allows me to send out this message using CAPL script. I tried this and unfortunately it did not work.

I made a GUI program in C# connected to my PEAK USB CAN adapter. I used a Arduino DUE (i advice people to ditch the default IDE and at least go VS2017 with a plugin. Very nice! )Behind the GUI i use WireShark so the CAN packets in the end all end up there for filtering or checking the DUE program etc.

Thats very cool!

Later in the process i started using Savvy CAN because i found some DBC files. Which obviously helped.

Can you please point me to these DBC files? I looked at https://skie.net/uploads/TeslaCAN/Tesla ... 0wk057.pdf

While developing and searching for the answers i also added things to the GUI like CRC calculations to check a message.
I could play a log file. I could live build up a filter list (a missed feature in savvy can IMHO). And i could compose a message with 64 check boxes.
(to toggle settings) offcourse after i grabbed it live from the wire.

Looks like you have developing a parallel to CANalyzer

The findings are also that the messages change per firmware revision. Perhaps not allot but they do change. The paper from WK057 is quite old and incomplete. It is still like 70% useful though on (firmware 33506 / begin 2019).

I looked at the WK057 work too. That's some extraordinary work. Although is currently not up to date.
I am looking to learn from you how to control the Tesla FDU/RDU. Please help! I know, I am about a year late since you were actively working on this.

[EV_Builder]

I advise to just buy the board when available, but the first step i would do and still do with each car i tackle is i make a dashboard / GUI in my case with C#.

So the canbus device sends the message to the gui and after that it sends it to wireshark (both places).
In my case i use the peak systems USB CAN device and that one allows sharing of the device between applications.
So if needed you can also start Peak view (which can easy inject stuff) and Savvy CAN all 3 at the same time.
Off course keep your VCU / Arduino DUE etc. ready for adding stuff that solves problems / works.

First thing i did was making the error pages. So it easy to spot if an error changes in the device.
I added also some log messages when error bit words changed so you can easily spot something toggling for example.
(you aren't looking like a hawk all the time to the correct fields...hahaha)

So first step is decode what it sends out while stationary, receiving nothing.

Second step is injecting stuff preferably known good values. Now some logic thinking and design feeling is needed. What would it need to see on the bus to grab/use for it self? Vehicle speed? Throttle? Gear? Torque request? etc..

[ravikashi]

I advise to just buy the board when available, but the first step i would do and still do with each car i tackle is i make a dashboard / GUI in my case with C#.

So the canbus device sends the message to the gui and after that it sends it to wireshark (both places).
In my case i use the peak systems USB CAN device and that one allows sharing of the device between applications.
So if needed you can also start Peak view (which can easy inject stuff) and Savvy CAN all 3 at the same time.
Off course keep your VCU / Arduino DUE etc. ready for adding stuff that solves problems / works.

First thing i did was making the error pages. So it easy to spot if an error changes in the device.
I added also some log messages when error bit words changed so you can easily spot something toggling for example.
(you aren't looking like a hawk all the time to the correct fields...hahaha)

So first step is decode what it sends out while stationary, receiving nothing.

Second step is injecting stuff preferably known good values. Now some logic thinking and design feeling is needed. What would it need to see on the bus to grab/use for it self? Vehicle speed? Throttle? Gear? Torque request? etc..

Thanks EV_Builder for the valuable suggestions.

1. Using the CAN DB, looks the FDU is interested in the MsgID 118 <- has all the good things it needs to drive the motor. Immo status, Acc Pedal Position, Brake Pedal Position, Drive blocked Status etc.
2. Using a 2 channel CANalyser, I was able to observe all the CAN messages sent out by the FDU. some of them are in the DBC files some of them are not. I am not sure if the unknown ones are not so critical.
3. I think the primary inputs to the FDU should be Vehicle / Wheel Speed and Accelerator Pedal position. <-- Not sure which message contains these information. May be Msg ID 0x108.