[Tomdb]

Cool, as always we got to keep in mind that tesla ignore bytes

My excel formula
=BITAND(BITLSHIFT(D3,8)+D2,511)

So you have 234V mains. But then again 511V makes sense, three phase power.

 

[CKidder]

ID 0x207 0x1A 0xE6 0x00

so 00E6 = 230v

Max value 1FF = 511v

I agree, that looks nicer and smoother than the previous guess of the first two bytes being a 16 bit integer in big endian. Attached is a PDF graphing both on top of each other. You can see that they match *very* closely but that the new 9 bit version is smoother. I also graphed byte 0 as it tracks the mains voltage pretty much exactly but with a small value. It doesn't appear to be current as it is constant when voltage is constant.

So, what does byte 0 encode anyway? Inquiring minds want to know!

Edit: Byte 0 is essentially the mains voltage / 9. Still no idea why it's there.

 

[jackbauer]

Thanks Colin. Graph is very good. You can even see where I paused the variac on the way up and down. I got stuck working on the TM4 earlier in the year until I stopped thinking of CAN frames as bytes and more an array of bits then things made a lot more sense.

Not sure about byte 0. Perhaps something to do with the pfc booster? When I get a log from a charging car I hope this will make more sense.

 

[jackbauer]

One of my great failures in life has been not getting Savvycan to run on linux. So i'm stuck with windoze. Did a 4 hour round trip last night to log a charge session. Guess what this morning? Bill decides to take a crap on my laptop. No more log files

Did find one interesting thing which I noted. Seems messages 0x042c , 0x043c and 0x044c carry the charge current request in bytes 2 and 3 relevant to each power module. Was very easy to see on the live graphs. Anyway , more logging to be done.

 

[CKidder]

One of my great failures in life has been not getting Savvycan to run on linux. So i'm stuck with windoze. Did a 4 hour round trip last night to log a charge session. Guess what this morning? Bill decides to take a crap on my laptop. No more log files

Well, previously it was kind of a pain to compile SavvyCAN as it had external dependencies that you had to compile first and then place in the proper place. Now it just requires QT. I think it's easier to compile everywhere now and I know a lot of people do compile it themselves on linux. There are just so many LINUX variations that it's hard to come up with one executable that runs everywhere. I've thought about statically compiling the executable so that it has less dynamic library links that could mess up. At any rate, if you have GCC and QT 5.9 installed in LINUX you should now be able to easily compile it yourself.

It sucks that you lost your log files. I've thought about maybe adding a feature to do streaming logging so that it directly logs to file, flushing maybe every couple of seconds so that the most you'd lose during a crash is the last few seconds of log. There's no technical reason why this feature couldn't be added.

 

[jackbauer]

Ok so got a new CAN log during a charge.

Message 0x42c 42 c4 1f 4a fe 00 00 00

Guess so far :

Byte 2 and 3 I think have the charge current command. Measured 12.6A into the pack.

 

[CKidder]

Ok so got a new CAN log during a charge.

Message 0x42c 42 c4 1f 4a fe 00 00 00

Guess so far :

Byte 2 and 3 I think have the charge current command. Measured 12.6A into the pack.

Well, without the log I'm just shooting in the dark but what about bytes 3 and 4 in little endian? That gives you a value of 0xFE4A which is -438. If all three modules are providing a third of the output current each then you'd expect right around 4.2 amps each. So, -438 could be the current in hundredths of an amp or -4.38A for that module.

It makes sense to me anyway. Maybe it's right, maybe it's wrong.

 

[Tomdb]

One remark would be, why would a charger use a signed command?
Not like this charger is setup to do bidirectional.


Mind sharing the log with a short description of when you started the log and any values you recorded.

 

[CKidder]

One remark would be, why would a charger use a signed command?
Not like this charger is setup to do bidirectional.

You might think so but I've seen them do it. Probably to keep the values in sync with the rest of the vehicle. Usually positive current is discharge and negative current is charge. So, keeping the chargers in negative range makes them work the same way as everything else when it comes to current reporting.

 

[jackbauer]

Ok have a new log up on the github. Didn't want to upload a raw log as it's a friends car and I don't want him getting in trouble with Elon! This one is the 4 command messages from the charger logic board to the power modules :
Logic_msgs_chg_start.csv

Events:
start capture
press ‘open charge port’ button
get out of the car
insert plug
Charging initalises
Charging commences
stop capture


Oh and SavvyCAN now compiles and runs on Linux

 

[jackbauer]

Guess why we had the weird mains voltage /9 byte? Because I didn't ground the charger case during the test. Ground the charger case and they track. The damn thing is looking for an earth leak!!! It must have an earth leak detector built in!

 

[Tomdb]

You played the capture back to one of the modules?

Going through the captures, bytes 1 (D2) and 4 (D5) are identical in all messages except 0x45C.

Messages 0x43C and 0x44C are identical

Attached the bytes from 0x42C

 

[Kevin Sharpe]

Ground the charger case and they track. The damn thing is looking for an earth leak!!! It must have an earth leak detector built in!

I guess that explains the heavy duty earth strap and is also something we need to look out for on the HVJB

 

[kennybobby]

That big strap connects to chassis? So how/where is chassis connected to earth ground? Does anyone have access to a Tesla to measure continuity between chassis and the ground terminal of the charge port?

During examination of Panasonic EVSE units i found that there is a deliberate leakage path from the mains line to the earth ground line that is used to detect a valid ground exists. It also has a ground-fault current detection circuit that uses a deliberate by-pass path to prove that the GFCD is working properly.

The Tesla EVSE might have similar checks but haven't examined one in person. Maybe those same checks are also done inside the Tesla chargers.

 

[Tomdb]

The ground pin in the charge socket connects to the chassis. Or atleast that is what the schematics say, plus this is required in the charging standards.

 

[jackbauer]

Put together a log with 0x042c: Phase 1 charger command, 0x207 and 0x227 which contain charger mains voltage, battery voltage and charge current for phase one.


Block1_start_charge_msgs.csv


Not had a chance yet to do a playback as will need to move operations to the shed and hook up to a 360v battery and some serious power.

 

[CKidder]

You played the capture back to one of the modules?

Going through the captures, bytes 1 (D2) and 4 (D5) are identical in all messages except 0x45C.

Messages 0x43C and 0x44C are identical

Attached the bytes from 0x42C

It's my guess that 0x42C controls the first module, 0x43C the second, and 0x44C the third. 0x45C is probably common to all three or something. If that guess is true then only the first module is getting activated so far. I'm not sure if that makes sense. 12.6A into a pack at 360v or so is 4.5kw which exceeds the rating of a single module. But, we don't know (or I don't know) the actual charge rate during this last log. It might not have been 12.6A. All I know is that you can see the charger ramp and then it stays constant but only in one message. As you said, the other two messages are the same but they don't seem to contain current requests in bytes 2-3 like the first message 0x42C does.

However, all three messages go through a pattern in bytes 0,1,4. It's always 0x42 in byte 0 for all three messages. Byte 1 starts out at 0x60 for all three. It then goes to 0xC4 for all three and at the same time. Byte 4 starts out as 0x64 for all three then transitions through 0x68 then 0x69 then 0x6D. The 0xC4 in byte 1 does not happen until byte 4 is 0x6D. We stay 0x6D for a bit then drop to 0x6C then go to 0xFC on all modules. Eventually 0x42C (first module???) goes to 0xFE in this byte. This seems to indicate that the module should be ready to start charging. About 8 seconds after the byte goes to 0xFE a charge ramp happens in bytes 2 and 3.

I'm attaching a graph that shows the charge ramp found in 0x42C bytes 2 and 3(little endian). Also in that graph is a mystery signal found in 0x45C bytes 0-1 which appears to be big endian and signed. It fairly closely matches the current ramp from 0x42C but it starts out hovering high and it goes negative for a little bit. I don't know what it means. Bytes 6-7 are similar to bytes 0-1 in 0x45C but they don't seem to quite make sense any way I try to graph them. Bytes 2-5 in 0x45C are fairly constant and I don't yet really have much of a guess at what they do.

But, to me it seems like the first three messages are commands and the fourth is a status feedback of some sort.

 

[jackbauer]

Sorry guys my mistake. Was 8.4A of charge current.

 

[Tomdb]

Damien, what charger did you plug into?

Wallbox, type 2? Single phase 16A or three phase? Looks like the charger is being mind full of 16A AC current limit.

Looks like in 0x227 bye 4 (D5) and byte 5 (D6) are the current feedback, looks like DC current in mA.

Multiplying this with the battery voltage in the same message, 0x227 byte 2 (D3) and byte 3 (D4) it would give you power, however this seems to nude 3.7 Kw. I do not know if this would be unreasonable.

However it looks like as collin points out, 0x42C byte 2 (D3) and byte 3 (D4) contains a current demand, scaled a factor of 2.

Will do some more digging to find some more info, however a bench test will easily allow you to sus out a if the findings are true.

As Damien mentioned, treat the bytes as a row of binary.

Maybe these are just lucky numbers but, 0x42C 0x42 0xC4, if i take 0x2c4 I get 708, but you can trim the binary. 0010 1100 0100 to 010 1100 010 which is 354V or just about 3.7V per cell. But then again I might just be trying to make the numbers work.

AC current in 207 byte 5 (D6) and then bit 0 and 1 from byte 6 (D7) to make a 10bit integer, curve matches the dc current exactly, however it has a strange factor of 0.035amp per bit.

 

[CKidder]

Damien, what charger did you plug into?

Wallbox, type 2? Single phase 16A or three phase? Looks like the charger is being mind full of 16A AC current limit.

Looks like in 0x227 bye 4 (D5) and byte 5 (D6) are the current feedback, looks like DC current in mA.

Multiplying this with the battery voltage in the same message, 0x227 byte 2 (D3) and byte 3 (D4) it would give you power, however this seems to nude 3.7 Kw. I do not know if this would be unreasonable.

However it looks like as collin points out, 0x42C byte 2 (D3) and byte 3 (D4) contains a current demand, scaled a factor of 2.

Yes, all that seems to check out. I've created a DBC file that allows one to graph and investigate the values and all of that looks good and proper.

As Damien mentioned, treat the bytes as a row of binary.

Maybe these are just lucky numbers but, 0x42C 0x42 0xC4, if i take 0x2c4 I get 708, but you can trim the binary. 0010 1100 0100 to 010 1100 010 which is 354V or just about 3.7V per cell. But then again I might just be trying to make the numbers work.

AC current in 207 byte 5 (D6) and then bit 0 and 1 from byte 6 (D7) to make a 10bit integer, curve matches the dc current exactly, however it has a strange factor of 0.035amp per bit.

I don't think that 0x42 0xC4 encodes the pack voltage. 354v doesn't match the voltage reported in 0x227 bytes 2 and 3. The way it progresses doesn't look right either. But, not every guess can turn out. History has shown all my wrong guesses - it's all part of the fun.

But, yeah, I think you might be correct about the AC Current in byte 5 and 6.

I'm attaching the DBC file. It should have all the best guesses so far.