Tesla Model 3 Charge Port Controller Standalone Development

[tom91]

I need to put in a PR for the SimpBMS Chevy code as Tom added the Coda stuff a little _too_ quickly and had some copy paste errors. Happens to the best of us though.

Wait so the there is an issue with my the canbus messaging for the Coda charger or just the Coda charger selection? I put it in on the request of someone and even believe it has been tested and verified to work.

Great progress on this charge port, if feels like a huge snowball rolling down a hill collecting more and more side projects.

[mdrobnak]

Wait so the there is an issue with my the canbus messaging for the Coda charger or just the Coda charger selection? I put it in on the request of someone and even believe it has been tested and verified to work.

Selection was fixed previously. This is some minor issues that unfortunately affect my testing as I'm trying to use the minimum of 200V. See PR: https://github.com/tomdebree/AmperaBattery/pull/4

Great progress on this charge port, if feels like a huge snowball rolling down a hill collecting more and more side projects.

Thanks! Yes, once this is at least going, I'll swing back to the ISA integration, and then test full EVSE to charger integration

-Matt

[mdrobnak]

Good news so far today is that I've gotten the charger outputting voltage. I initially wasn't getting the right output, but I set the input current too low Annoyingly CAN Low was white, which is pretty much opposite from standard.. (de facto standard, but still...)

I now get 200V with a 1A current limit, looking good so far. I'll test the CHAdeMO out after I eat some dinner. Stay tuned!

-Matt

[mdrobnak]

YES, YES YES!!


We have working CHAdeMO!!!

[Isaac96]

Gorgeous!!!!
So you have more or less complete CHAdeMO functionality. Now we get to ask for CCS, right?

[mdrobnak]

Gorgeous!!!!

I know, right?

So you have more or less complete CHAdeMO functionality. Now we get to ask for CCS, right?

We'll go with "yes".

The details about how much current to ask for and voltage I need to work out, but now that I know it works, I can figure out what's going on at this point.

Once I have a better idea of what's needed there, I can try and apply that to CCS and see where that gets us. It will likely be quite similar.

So, yes, CCS will come. But for a somewhat-quick-and-dirty go, it works.

-Matt

[Jack Bauer]

Congratulations Matt. These are some major developments:)

[Bryson]

Excellent work!

[mdrobnak]

So, I've found current control.

Here's a fun bit - the CHAdeMO adapter _ignores_ anything above 125 Amps.

I'm having a heck of a time figuring out how to set the voltage, however.

That's all for now. Tomorrow I hope to find voltage.

-Matt

[larsrengersen]

Here's a fun bit - the CHAdeMO adapter _ignores_ anything above 125 Amps.
-Matt

Congrats! Great job.
What CHAdeMO Protocol is set?
0.9, 1.0 and 1.1 are 125A max
1.2 is 400A (but often you need different hardware/car socket)
See my blogpost on Introducing DC fast charging

[mdrobnak]

Here's a fun bit - the CHAdeMO adapter _ignores_ anything above 125 Amps.
-Matt

Congrats! Great job.
What CHAdeMO Protocol is set?
0.9, 1.0 and 1.1 are 125A max
1.2 is 400A (but often you need different hardware/car socket)
See my blogpost on Introducing DC fast charging

0.9 is what the adapter uses.

Interestingly, Fast Charge Limits CAN _does_ show 255A when I set it to that, but it looks like the adapter refuses to send a value greater than 125.
I've only seen standard 50kW (technically 62.5kW @ 500V) ever.

Didn't figure out voltage control yet. Definitely a little stumped.

-Matt

[johu]

0.9, 1.0 and 1.1 are 125A max

Hmm, I've seen 135A on a 60 kW charger. I've implemented 0.9 in Touran.

[mdrobnak]

Odd. From here:
https://assets.vector.com/cms/content/e ... eMO_DC.pdf

That's where I got the 125A number from, and seems to bear out in the Tesla implementation as well. Also note they don't claim to support more than 50kW anyway through the adapter.

In other news, I'm starting to go back and comment all the data and / or break out into variables. A few things as a result:
1. Getting closer to sending more realistic data
2. Redacted code will be available after I update the script to redact it.

-Matt

[collin80]

Odd. From here:
https://assets.vector.com/cms/content/e ... eMO_DC.pdf

chademo_2.PNG

That's where I got the 125A number from, and seems to bear out in the Tesla implementation as well. Also note they don't claim to support more than 50kW anyway through the adapter.
-Matt

It's not so odd when you consider how most engineers figure that standards are just vague suggestions. It would not surprise me in the least to find that some implementations went ahead and supported more than 125A just because they could. The number, after all, could be interpreted as an unsigned 8 bit integer so up to 255A could technically be requested. Sure, you're not supposed to do this but, once again, standards are just suggestions.

[mdrobnak]

It's not so odd when you consider how most engineers figure that standards are just vague suggestions.

This is definitely the quote of the day.

-Matt

[mdrobnak]

So, I somehow managed to mess with the LED blink pattern, and now my 2019 ECU blinks like my 2018 ECU. I made a dumb mistake and had it powered on while I unplugged the inlet connector, leaving the door / led and power connected.... No idea how I did that one lol.

So.. SWCAN is wired up for sniffing. Except..I can't do it in Linux. Nothing supports 33.3k, and frankly, it needs to be in silent mode due to the pilot -> SWCAN switch. So, off to Windows we go..and I logged some interesting data. Some things I am *not* transmitting on the HV bus are being generated and put on the SWCAN bus. I probably need to fix that data to make the right things happen.

I'll go over that more tomorrow.

-Matt

[Jack Bauer]

Keep up the good work Matt:)

[mdrobnak]

Keep up the good work Matt:)

Thanks. If all goes well I should have more for you to test second week of January. Things need cleaning up. I at least did put in the state transitions like with the CHAdeMO EVSE. In terms of a hack / refine phase, we're definitely in the hack state.

So some clarifications... This connector is the one I unplugged and left the power on with:

The green wire is ground, and the white with purple is pilot. This connects to CAN Low (Ground), and CAN High (Pilot).

This then results in:

And my table still looks reasonable:

I did get it to work in Linux using my ValueCAN3. The key is the drivers basically just use the hardware config and can't modify it on the fly. So I booted into Windows, set CAN 1 to 500k and normal mode, and set CAN 2 to 33.3k and silent mode. Now I can capture in SavvyCAN and analyze in Vehicle Spy.

I did not get far with figuring out what causes the Fast Charge limits to be calculated as they are, but I did figure some things out. I think there's about 30 signals, and I figured out about 13 of them, including all the CHAdeMO ones. The others are harder. There's three multiplexed ones that I have no idea what's going on with them.

Not sure how much I'll do tomorrow, I'll probably do some stuff in the morning but the afternoon is busy.

-Matt

[mdrobnak]

I know I've been quiet, but I'm really battling figuring out some of this data.

So far what I have for the CHAdeMO current request vs what I have listed as a 'BMS current limit' seem to be two completely different items. I'm also unable to get the voltage to change at the moment. So I'm a bit stuck. However I'm trying to attack this from a few different sides and I think I'll see some more progress soon.

[Jack Bauer]

I have faith in you Matt:)

[mdrobnak]

Thanks, Damien.

There is an ID on the vehicle bus side (?!?!) that shows BMS limits. I've tried sending that on the CP side, no go. So I tried sending that data on basically every ID I am not sending, no immediately visible changes, however I will look at the SWCAN data tomorrow and see if anything changed as a result of my experiment.

In other news, people are getting their CCS adapter from SETEC...and..it works at Electrify America, but otherwise the success rate seems low for most people. In other words, not great.

-Matt

[mdrobnak]

Well that was a bust.

Found the ID which generates some alerts, and found that 0x604 is repeated as-is from CP CAN to SW CAN. But does not produce a useful change that I can see.

Maybe I need to figure out how to wire up a way to spy on the SWCAN on my car and capture an actual CHAdeMO session.

-Matt

[mdrobnak]

Unfortunately nothing majorly new to report here at the moment with respect to functionality.

Some code cleanup in progress - a 3rd party has put together a driver for the bxCAN peripheral - https://github.com/stm32-rs/bxcan
So I'm attempting to get that working, which hopefully will get us the ability to use interrupts for receive rather than a crazy 1ms or 0.5ms loop

After that there has finally been some movement on the RTC driver for the STM32F4 Pull Request, and it apparently needs some fixes, and some testing - I never tested "day of week" and...that probably is somewhat broken.

I've git stashed away the work in progress stuff, so after I switch over this driver I'll probably update the redacted repo. Sorry for the delay on that.

There's been some other breaking changes on the HAL that I need to update some code to get going, but not ready for that quite yet.

-Matt

[mdrobnak]

I was able to re-work the code to use the bxcan driver, however something is definitely not right at the moment. It panics after queueing the first frame to be sent. Nothing shows up on the wire. Yay. But the code structure changes are ready to go. A downside is that the error handling code I added in is...useless again. LOL. Once I get it working I'll talk with the maintainers about their thoughts for future changes.

Next items, no timeline:
* CAN driver update
* RTC driver fix for STM32F4
* Breaking changes HAL update

-Matt

[mdrobnak]

Some good news, I have verified the bxcan driver works in a testing scenario. Test parameters were an 8 MHz clock, with a single ID, 8 bytes long, sending as fast as possible. With a debug build I was seeing about 2000 frames a second. With fully-optimized release build -- 4000!

The downside is that the example code uses a non-blocking method to send, which doesn't quite work with RTIC. However, a nice RTIC example was provided with using a queue and interrupt based send and receive.

Sooo even more code to write, but it's going to be even more efficient when done with this change.

-Matt