Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Tesla Wall Connector load sharing protocol

This site may earn commission on affiliate links.
Gah, my post editing time ran out just before I fixed this:
FB E2 is a Master message that doesn't trigger a response from the slave, so they aren't completely following any obvious convention. It may be worth starting from 00 00 and going all the way to FF FF to look for undocumented messages. Special values C0 and DB should be skipped.
 
Today I took my 14-50 outlet and converted it to two load sharing HPWCs. First I verified that I had #6 wire to the 14-50 outlet. I upgraded the breaker from 50 Amps to 60 to allow 48 amp changing shared for two cars. A little conduit work and Voila!

BE642B55-4CBD-40E8-94E3-E81A94F798AF.jpeg
 
WARNING: I don't recommend trying the 00 00 to FF FF undocumented message test I described in my last post because it may have put my TWC into a weird, non-operational state.

Does anyone know how to do a factory reset - like more than just holding reset or power cycling it?

I got all the way to FF FF and discovered at least 10 undocumented messages the TWC responds to. Unfortunately, most return all zero data whether or not the car is charging. Others have static data or values that randomly change. Nothing shows increasing or decreasing values while charging which might contain a battery state. Nothing has a static value close to 120 or 240V.

FC 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 caused by TWC to hard lock to the point I couldn't reset it with the reset button. I had to power cycle it. Sometime within the next 20 minutes (perhaps immediately - I didn't notice), the TWCs ID had changed from 032E to EB30. This change has proven to be permanent. I froze it again with the FC 19 message and it hard locked again but the ID remained EB30. Freaky.

During my original test, I noticed FB 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 was returning an interesting result: c0 fd 1a 45 56 57 54 53 38 30 48 4c ff 00 ae c0

Over the next couple hours, I tried sending the message I'd discovered with the car unplugged, plugged not charging, and charging at 5A. Each time, I got the same c0 fd 1a 45 56 57 54 53 38 30 48 4c ff 00 ae c0 response to this message. Then, when I repeated this message twice with the car charging at 5A, I got a different response: c0 fd 1a 00 00 00 00 00 00 00 00 00 00 00 1a c0

The car stopped charging and 30 seconds later the TWC started sending messages as if it were in Master mode instead of Slave mode. I found that it seemed to be in a reboot loop where the LEDs at the front of the TWC light in this sequence:

All off
3rd green from bottom + middle orange (6th up from bottom)
All off
1st + 2nd green from bottom + middle orange
All off
1st + 2nd + 4th green from bottom + middle orange
All off
Top and bottom green (this normally indicates Master mode)
All off
All green for about a minute. Usually all LEDs only turn green when you hold the reset button for 5+ seconds.
All off, then the sequence repeats from the top.

Can anyone confirm if this is the normal sequence of lights when it boots or when reset is held? I remember it used to do something like this but never watched it closely.

Each time the lights do their cycle, the TWC sends Master linkready1 and linkready2 messages, each time with a different "sign" which is what it would do if you manually reset/rebooted the TWC.

I've tried different things all day to get it out of this mode and I've run out of ideas.

Since this seemed to happen as the result of a message I'd already sent a few times, I'm dubious that the message I sent directly caused this state, though it's possible I sent it during a time that it collided with another message and the TWC
saw the message that got the TWC into this state as a different message than what I'd sent each time before. It's possible that I introduced corruption in the firmware or NVRAM log or something with all the test messages I sent earlier. Maybe it really is just a hardware failure that happened to occur while I was messing with it. I really don't know. But I wanted to recommend others don't follow in my footsteps here as I may not be able to recover from this state.

Things I've tried:
Hold reset button till it restarts.
Power off for 20 seconds, then on again.
Power off. Hold reset before powering on. Held about a minute and gave up.
Power off. Hold reset and charger handle button before powering. Held a minute and gave up. Not surprisingly, this opened my car's charge port.
Power off and change rotary switch to 1, then 0, then F, then E, then 8. No difference in behavior.
Power off, dip switch 2 down. No difference.
Re-send all messages from FB00 to FFFF. The FC19 message that previously crashed it hard no longer crashes it. It responds to a lot of the messages in similar ways to how it used to respond in slave mode.
Hold reset for various lengths of time and tap it up to 30 times in a row.
Let TWC run overnight and hope it exits this weird mode (it did not).

Today I took my 14-50 outlet and converted it to two load sharing HPWCs. First I verified that I had #6 wire to the 14-50 outlet. I upgraded the breaker from 50 Amps to 60 to allow 48 amp changing shared for two cars. A little conduit work and Voila!

Looks nice. Are you using TWCManager or just showing off two TWCs installed on one circuit?
 
  • Like
Reactions: robertvg
WARNING: I don't recommend trying the 00 00 to FF FF undocumented message test I described in my last post because it may have put my TWC into a weird, non-operational state.

Does anyone know how to do a factory reset - like more than just holding reset or power cycling it?

I got all the way to FF FF and discovered at least 10 undocumented messages the TWC responds to. Unfortunately, most return all zero data whether or not the car is charging. Others have static data or values that randomly change. Nothing shows increasing or decreasing values while charging which might contain a battery state. Nothing has a static value close to 120 or 240V.

FC 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 caused by TWC to hard lock to the point I couldn't reset it with the reset button. I had to power cycle it. Sometime within the next 20 minutes (perhaps immediately - I didn't notice), the TWCs ID had changed from 032E to EB30. This change has proven to be permanent. I froze it again with the FC 19 message and it hard locked again but the ID remained EB30. Freaky.

During my original test, I noticed FB 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 was returning an interesting result: c0 fd 1a 45 56 57 54 53 38 30 48 4c ff 00 ae c0

Over the next couple hours, I tried sending the message I'd discovered with the car unplugged, plugged not charging, and charging at 5A. Each time, I got the same c0 fd 1a 45 56 57 54 53 38 30 48 4c ff 00 ae c0 response to this message. Then, when I repeated this message twice with the car charging at 5A, I got a different response: c0 fd 1a 00 00 00 00 00 00 00 00 00 00 00 1a c0

The car stopped charging and 30 seconds later the TWC started sending messages as if it were in Master mode instead of Slave mode. I found that it seemed to be in a reboot loop where the LEDs at the front of the TWC light in this sequence:

All off
3rd green from bottom + middle orange (6th up from bottom)
All off
1st + 2nd green from bottom + middle orange
All off
1st + 2nd + 4th green from bottom + middle orange
All off
Top and bottom green (this normally indicates Master mode)
All off
All green for about a minute. Usually all LEDs only turn green when you hold the reset button for 5+ seconds.
All off, then the sequence repeats from the top.

Can anyone confirm if this is the normal sequence of lights when it boots or when reset is held? I remember it used to do something like this but never watched it closely.

Each time the lights do their cycle, the TWC sends Master linkready1 and linkready2 messages, each time with a different "sign" which is what it would do if you manually reset/rebooted the TWC.

I've tried different things all day to get it out of this mode and I've run out of ideas.

Since this seemed to happen as the result of a message I'd already sent a few times, I'm dubious that the message I sent directly caused this state, though it's possible I sent it during a time that it collided with another message and the TWC
saw the message that got the TWC into this state as a different message than what I'd sent each time before. It's possible that I introduced corruption in the firmware or NVRAM log or something with all the test messages I sent earlier. Maybe it really is just a hardware failure that happened to occur while I was messing with it. I really don't know. But I wanted to recommend others don't follow in my footsteps here as I may not be able to recover from this state.

Things I've tried:
Hold reset button till it restarts.
Power off for 20 seconds, then on again.
Power off. Hold reset before powering on. Held about a minute and gave up.
Power off. Hold reset and charger handle button before powering. Held a minute and gave up. Not surprisingly, this opened my car's charge port.
Power off and change rotary switch to 1, then 0, then F, then E, then 8. No difference in behavior.
Power off, dip switch 2 down. No difference.
Re-send all messages from FB00 to FFFF. The FC19 message that previously crashed it hard no longer crashes it. It responds to a lot of the messages in similar ways to how it used to respond in slave mode.
Hold reset for various lengths of time and tap it up to 30 times in a row.
Let TWC run overnight and hope it exits this weird mode (it did not).



Looks nice. Are you using TWCManager or just showing off two TWCs installed on one circuit?

I am using the load sharing protocol between the two units, and have no issues.
 
@CDragon Interested in the state of your TWC ? Did you manage to reset the firmware and get it to work again ?
Besides that: very interesting to read that you got it to send 10 undocumented messages.
Chargers could potentially control so more if it would know the battery size, SoC and planned time of departure...

No, it's still broken. Monday morning, I sent an email to [email protected] which is the email shown under the cover of the TWC but I have not gotten a reply. If anyone knows a better address to contact, please PM me.

I'm trying not to spend too much more time trying to fix it until Tesla replies saying if they are willing to help or not, but I'm still trying a few things. I'm still not sure if the messages I sent caused this state or if it's a hardware problem. I can see evidence for both theories, but I think it's most likely I have it in a test or debug mode because it still responds in logical, repeatable ways. Hardware problems usually manifest as more random behavior, or trigger an error light that won't go away. Why they would even offer an RS-485 command to get it in such a mode and why it would not exit the mode on power off still baffles me. You'd think they would limit debug mode entry to using the JTAG connector and you'd think it would be password protected or something. It's also possible the commands triggered a buffer overflow or something that changed NVRAM in some way they didn't anticipate to get into this mode. That would explain why I can't get out of it.

Someone offered to donate me a TWC with newer firmware to experiment with even before I broke mine so I'll probably end up using that. Then I may take mine to a service center and have them look at it. Of course, I can't really risk sending undocumented commands to the newer TWC unless I find a reasonable way to get the old one out of this state without bringing it to a service center.
 
Last edited:
  • Like
Reactions: robertvg
Well it is not uncommon for software to start behaving unexpectedly and unpredictable with unintended use or when receiving unanticipated ‘commands’. You might not have found actual programmed rs-485 commands but maybe just something that it is not programmed to handle.
Hope you manage to get it working again.
 
Did anybody else see this?

11:25:10: Send master linkready1
Tx@11:25:10: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
11:25:10: Send master linkready1
Tx@11:25:10: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
11:25:10: Send master linkready1
Tx@11:25:10: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
11:25:10: Send master linkready1
Tx@11:25:10: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
11:25:10: Send master linkready1
Tx@11:25:10: c0 fc e1 77 77 77 00 00 00 00 00 00 00 00 46 c0 fe
11:25:10: Send master linkready2
Tx@11:25:10: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
11:25:10: Send master linkready2
Tx@11:25:10: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
11:25:10: Send master linkready2
Tx@11:25:10: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
11:25:10: Send master linkready2
Tx@11:25:10: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
11:25:10: Send master linkready2
Tx@11:25:10: c0 fb e2 77 77 77 00 00 00 00 00 00 00 00 47 c0 fe
Rx@11:25:16: c0 fd e2 82 04 83 0c 80 00 00 00 00 00 00 00 00 77 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 82 04 83 0c 80 00 00 00 00 00 00 00 00 77 c0
Rx@11:25:16: c0 fd e2 82 04 83 0c 80 00 00 00 00 00 00 00 00 77 c0
ERROR: Ignoring message of unexpected length 18: c0 fd e2 82 04 83 0c 80 00 00 00 00 00 00 00 00 77 c0
Rx@11:25:17: c0 fd e2 82 04 83 0c 80 00 00 00 00 00 00 00 00 77 c0

That's all it is doing right now. I tried to cycle the TWC a few times, it goes to a solid green LED on top, but that's it.

I have to leave again so I will only be able to SSH to my Pi remotely and debug it a bit further, but any ideas and what this might be?
 
I tried to cycle the TWC a few times, it goes to a solid green LED on top, but that's it.

I have to leave again so I will only be able to SSH to my Pi remotely and debug it a bit further, but any ideas and what this might be?

I was expecting this based on Fuzzylogic's experience. His newer EU firmware TWCs use two extra bytes of data in all their messages to support the FD EB message containing voltage on all three phases. The fix is to have TWCManager send and accept two extra bytes in its messages. I was going to work on that around when my TWC entered the Twilight Zone.

Fuzzylogic also found that he couldn't tell the car to stop charging using the message I've been using with the older firmware TWCs. I suggested some things to try but haven't heard back. So watch out for that.
 
Last edited:
Aha, ok! But that means I have a proper 'connection' with my EU TWC. Just wanted to be sure I'm not having a bad RS485 connection or buggy adapter.

I'm testing with a EU TWC 32A 3-phase 7,5m cable which I got about 6 weeks ago.
 
Yep, that's a linkready message from a EU TWC. I'm seeing the same length.
Still haven't been able to stop charging, other then using the app on my phone.

There is a ugly way of stopping the charge, and that is to stop responding to messages from the slave, after 30-40 seconds it will timeout, and stop charging.
You can also immediately stop charging by sending the error code 02 01, but then the TWC needs to be reset by holding the reset button.

Btw i found the reference to the serial protocol (and escaping of 0xC0 and 0xDB) they are using:
Serial Line Internet Protocol - Wikipedia
 
  • Informative
Reactions: Ulmo
There is a ugly way of stopping the charge, and that is to stop responding to messages from the slave, after 30-40 seconds it will timeout, and stop charging.

Btw i found the reference to the serial protocol (and escaping of 0xC0 and 0xDB) they are using:
Serial Line Internet Protocol - Wikipedia

Really interesting they're using the SLIP protocol. It now makes sense why they didn't double C0 to represent an actual C0, but I still want to understand why DB is escape and DD ends the escape. Why do they call DD "transposed escape"? I don't see any bits or bytes swapped around between DB and DD.

Anyway, did you try my suggestion of having two fake (or real) slave TWCs controlled by a single real master set to 6A? When the slaves both report they need power, Master must choose to turn one of them off because you've found they can't be set below 6A. It can't supply 3A to each, so it must supply 6A to one and none to the other. Whatever messages it sends to the one that gets no power should be how you can instruct a slave to stop charging.
 
  • Informative
  • Like
Reactions: Ulmo and robertvg
Yes i tried that, but that too does not work.

I had one real TWC set to Master at 6A, the other TWC as Slave.
First i powered up the Master, all OK. But as soon as i power up the Slave, the Master will blink an error code.
It will not accept a slave on the same bus, when the current is set lower then 13A (so 10, 8 or 6A)
 
  • Informative
Reactions: Ulmo and spottyq
No luck getting my original TWC working. I realized that the fd 1a 45 56 57 54 53 38 30 48 4c ff 00 response to FC1A it used to return when it was working actually represents ascii characters "EVWTS80HL". This almost matches identifiers printed on the circuit boards in the TWC such as EVWTS80HT-7 and must represent a model number of the firmware board or of the entire unit. The fact FC1A now returns all zeros makes me suspect I may have corrupted the area containing data like the model number. I have no idea how I did that, although one possibility is the car was trying to update the firmware and the messages I was sending interrupted it before it finished (it was plugged in and charging when it got in the bad state).

Another possibility is the FC19 message which I've found normally crashes the TWC, but very occasionally it returns FD 19 01 00 00 00 00 00 00 00 00 00 00. If it didn't crash, the next time you send FB19 (with any eleven-data-byte value), the eleven data bytes you last sent with FC19 are returned, even after power cycling. In other words, FC19 can write to NVRAM in some way if the TWC doesn't crash. My stock TWC returned FD 19 41 31 36 47 30 30 30 31 38 31 34 which may represent "A16G0001814" in ascii (serial number? Place/date of manufacture? Firmware version?) but at some point days before the bad state, I unknowingly overwrote that so FB19 returned all zeros. Conceivably, the fact it was all zero broke the next firmware update and got it into the bad state.

I suspect that the inability to read a valid model number and possibly other important data is what has it stuck in a reboot loop.

I've tried about 20 times to send FC 19 41 31 36 47 30 30 30 31 38 31 34 to return it to the stock setting, but so far it always crashes even when I try to perfectly replicate the lead up to some of the times it did not crash. FB19 is currently returning FD 19 76 00 00 00 E5 3F E6 3F FF 00 00 which doesn't look like ascii, nor does it look like anything I would have sent with an FC19 message, so I don't understand that, nor do my logs show when it changed to that value. I did try leaving it plugged into the car overnight to see if the car would fix it, so it's possible the car changed the value.

I've now installed a newer U.S. TWC and am finding the same behavior Fuzzylogic encountered in the latest EU model. The messages are two bytes longer, it won't let me set it below 6A, and it won't stop charging when set to 0A.

I talked to someone I trust who thinks these changes aren't actually firmware but hardware differences because the car periodically updates a plugged-in TWC to the latest firmware version it can support. I can't verify but it's interesting.

I'll update again if I can figure out a better solution to stop charging than simply stopping message sending.
 
Last edited:
I've got TWCManager updated to work with my newer TWC using what I've dubbed "Protocol 2" (vs the older "Protocol 1"). I've actually gotten a hold of two recently-manufactured TWCs and had one acting as Master, one as slave, and TWCManager acting as a second fake slave. I had TWCManager mimic as much of the behavior as I could identify in the real slave's responses but I'm afraid I see absolutely no evidence that any of the real TWCs are getting battery state information or trying to time the two slave TWCs to finish charging their cars at the same time. The only extra information passed in Protocol 2 is the voltage of each slave and the total kWh that slave has delivered to cars in its lifetime. That total kWh is in whole killowatts, no fractions, so it seems impossible for that to be used to do any realtime load balancing.

Master does not compel slave TWCs to allocate less power to a car even when that car is within minutes of hitting its target SoC. I've tried 50% target and 80% target. So the people that have reported two cars managing to hit target charge at the same moment thanks to load balancing just doesn't seem possible. TWCs aren't sending any data that could be used to do that. When a car finishes charging, Master does allocate all power to the other slave, and that doubling of available power in a two-car system could potentially make the other car finish quickly and make it seem like they were timed to finish near the same time. Also, cars naturally slow their rate of charge as they near 100% SoC which may help two cars sync reaching that state. Where I live, charging to 100% makes things difficult (basically I have to grind my brakes down a 4000 foot elevation change) so I don't like to do it.

The only thing I'm unable to try is plugging a car into real master and slave at the same time. I think it's highly unlikely it would load balance a real master with a slave based on car SoC if it won't load balance two slaves based on SoC, but that's an avenue that hasn't been explored.

I have small hope that an undocumented message might return SoC in Protocol 2 but am also quite nervous about performing experiments that could result in another dead TWC. I plan to wait until I've pursued every other line of experimentation involving two TWCs before I try undocumented messages such that if I kill another TWC I will still have one working one. There is also some tiny chance that an undoc message could stop a TWC from charging without showing an error light.

I've found the same weird status state code use that Fuzzylogic found, ie 05 to start charging at an absolute limit, 09 to change the absolute limit, 06 to permanently increase limit by 2A, 07 to temporarily decrease it by 2A, etc. If a Master needs to raise a slave to a higher amperage because another car has finished, it seems to use 06 repeatedly to gradually increase it to the target. Even once a slave has reached target amps, master seem to periodically send an 07 code to temporarily decrease amps for no apparent reason. After 40 seconds in 07 state, slaves change their own status to 0A and raise themselves by 2A. I've not seen a Master send 0A itself. I see no obvious reason for using this system but I've set up the fake slave to mimic it. One possible theory is a Master wants to periodically make sure the slave is responding as expected to commands and that the slave is able to control the power drawn by its car. Kind of a periodic diagnostic test.

I've tried a lot of things to get a car to stop charging without resorting to the tactic found by Fuzzylogic of stopping all communication with the slave. These include:
  • Send heartbeat with state 00 repeatedly, incrementing state each 5 seconds till we eventually reach state FF and stop testing. This test skips state 02 which puts TWC in an error condition that requires reset.
  • Send amp values of 0000 (0.00A), 0001 (0.01A), FFFF (meaning -1.00A if interpreted as a signed value, or the max unsigned value of 65.535A), 8000 (-327.68A, the max negative value), 8001 (-327.67A), 1FA4 (81.00A), 7FFF (327.67A, the max signed positive value)
  • Send 000000FFFFFFFFFFFF or 090000FFFFFFFFFFFF. Slave sees this as invalid and responds as if we sent no heartbeat message at all.
The only real downside to stopping communication is the TWC blinks a red light 4 times for as long as you don't communicate with it. Other than that, the car stops charging, goes to sleep, turns off all its fans, and will resume charging 8+ hours later when the TWC is communicated with again.

One thing I'm still worried about is one time the car got into an error mode where it refused to take a charge until I re-plugged it. I think it probably had something to do with stopping communication with the slave, but I don't know what exact timing or circumstances triggered it. Due to this problem, I've not yet released updates to the TWCManager code at the git repository.

Also, my cheap JBTek RS-485 adapter has gone bad. This wasted a lot of time as I tried to figure out what the heck was going on. I thought I'd somehow fried another TWC for a little bit. Basically, JBTek seemed able to transmit but not receive, and it also caused the real master and slave TWCs to be unable to communicate. The moment I unplugged JBTek's USB cable from the pi to cut its power, Master and Slave started talking and the 4-blink error code went away. I'm now using one of the expensive FTDI RS-485 adapters. It's conceivable that a misty atmosphere left condensation on some exposed metal of a plug I use to connect the master and slave TWCs and that damaged the JBTek adapter. However, the RS-485 spec says the two wires are supposed to tolerate unlimited periods of being shorted together which allows RS-485 to be run underground where rain water may temporarily short the wires.
 
Last edited:
I discovered how to set values below 6A using protocol 2:

Telling the car to charge at 640A or higher will make it charge at the value you tell it to minus 640A. So if you send a master heartbeat with data 09FA00000000000000 the car will draw zero amps (FA00 in the command is 64000 decimal which is 640.00A - 640A = 0A). 641A will charge at 1A, 642A at 2A, etc. Fractional values seem to get rounded down, so 640.99A charges at 0A and 641.99A charges at 1A. The max value you can send is FFFF which is 655.35A - 640A = 15A. This is all good evidence that the amp value is not signed (ie you can't specify negative amps).

Unfortunately, telling the car to charge at 0A does not stop it from charging in a clean way. Instead, the TWC keeps its relays open, its green lights keep streaming, and the car remains awake showing charging at 0A and ~250V. If you leave it in that state for too long (guessing 20 minutes?), the car stops accepting charge and enters an error state where it refuses to charge again until you re-plug the TWC. The car doesn't say there's any error, charge port remains blue, and clicking the 'Start charge' button in the car or in the phone app is simply ignored. This behavior seems exactly the same as with protocol 1 when you set amp values too low for too long.

Oddly, values 639.50 to 639.99 are also interpreted as 0A. I tried every single value in 0.01A increments hoping one would tell the TWC to stop charging, but none did. 639.49A and lower are interpreted as charge at max amps the car will take, which is 40A in my car's case.

I think it's highly unlikely, but there could be some special value below 639.49A that will tell the TWC to stop charging, but it will take a long time for me to test every value in 0.01A increments. I may start with 1A increments. I will need to wait till my car has non-full charge to test.
 
I verified your discovery on my EU TWC, and it works fine. Thanks!

I tried charging at 2A (3 phase) for more then 30 minutes, and no issues.
The charging efficiency is probably terrible, as it's only charging at 3km/h, but it's nice to be able to set the charge current to a lower value then 6A temporarily.

I'm now testing 1A, will also test 0A, and see how long it takes for it to stop with an error.
 
  • Like
Reactions: spottyq
Unfortunately, ceasing communication with the TWC has proven to cause my car to seemingly randomly stop charging. It happened once on a cloudy day where clouds caused charging to start and stop at random intervals. I tried some tests and haven't been able to identify what exactly causes the car to go into error mode and refuse to charge. I can leave it not-charging all night with no TWC communication and it will resume in the morning when I resume TWC comm, but if I stop and start TWC comm at various intervals, the car will eventually go into error state after a seemingly random number of TWC comm stops. It doesn't seem to matter how frequent the intervals are. I've seen it happen after 3 comm stops and after 6 with different spacing. It seems most likely that there is simply some smallish chance the car will go into error state every time you stop TWC comm and there is no clear way to avoid the problem.

Someone gave me a 'fake car' to plug into my second TWC. It sends a pilot signal so the TWC opens its relay and starts charging it, but the fake car sets the charging rate at 0A so doesn't draw any significant power. I used it to test all 09 state amp values from 639.5A to 655.36A in 0.01A increments with 5 seconds delay between each test value. I also got my security camera system to log an alarm if it saw motion stopped, meaning I could see if I ever got the TWC LEDs to stop streaming. Sadly, they never did.

I then tried testing 80A and up in 0.5A increments with 20 seconds of delay between each test value. At around 85A, the TWC goes into error mode that indicates invalid pilot signal. After some more testing it appears the fake car won't allow charging above around 85A. It's sending the TWC something invalid I guess because 85A+ isn't valid in the J1772 spec. The problem could also be in the JDapter stub being used to bridge the Tesla connector to the J1772 'fake car'.

So I returned to using my real car for these tests. I set the car UI to limit actual charging to 5A which gives me about 36 hours of testing time between 40RM and 150RM. I discovered that charging below 6A actually happens in cycles separated by 128A:
  • Charge at 0A: 127.5, 255.5, 383.5, 511.5, 639.5
  • Charge at 1A: 129.0, 257.0, 385.0, 513.0, 641.0
  • Charge at 2A: 131.0, 259.0, 387.0, 515.0, 643.0
  • Charge at 3A: 132.0, 260.0, 388.0, 516.0, 644.0
  • Charge at 4A: 133.0, 261.0, 389.0, 517.0, 645.0
  • Charge at 5A: 134.0, 262.0, 390.0, 518.0, 646.0
Each zero value begins at amp setting 127.5 + 128 * x

I'm not sure why charge at 2A begins two values higher than charge at 1A.

This whole ability to charge under 6A may actually be a bug. The TWC seems to support charging in 0.5A increments, so if you send it 4.0A to 4.49A, the car charges at around 4.10A. 4.5 to 4.9, car charges around 4.62A. 5.0 to 5.49A, car charges around 5.10A. Etc. These 0.5A increments could be represented by a single byte that can have values 0 to 255. 0 means charge at 0A, 1 means 0.5A, 2 means 1A, 3 means 1.5A, all the way to 255 which means 127.5A.
They might do the 'don't charge below 6A' check immediately using the two-byte value in the master heartbeat data that ranges from 0 to 65535. So a value of 500 means 5.00A which it sees is too low, raises it to 6A, and stores 6*2 = 12 in the byte that controls actual amps to be drawn. A value of 12800 means 128.00A which is above 6A so it isn't reduced. It tries to put a value of 128*2 = 256 in the byte that controls actual amps. 256 can't be represented by a single byte and the usual thing that happens when you assign such an 'overflow' value is it takes just the lowest 8 bits of the value and stores that in the byte. 256 in hex is 0x10000 and its lowest 8 bits are 0x0000, so it stores 0 in the byte and charges at 0A.

Anyway, if this is just a bug then I'm not likely to find any special amp value that stops the TWC from charging, but I'll continue testing just in case. So far, I've tested up to 241.91A in 0.01A increments. When I hit 127.5A the car dropped to 0A as expected, raised to 1A at 129.0A, but at 129.40A, exactly 19 minutes and 0 seconds later, the car decided it had been charging at too low an amp rate for too long and it went into error mode. I re-plugged it and resumed testing at 134.0A (interpreted as 5A). This does skip some test values but I'm not sure it's worth trying to get through every last one in there.

The only remaining hope is undocumented messages, or maaaybe states other than 09 (I plan to try state 05 and 08 at least).
 
Last edited: