[Tomdb]

Good to hear you are making progress.

I wonder if it faulting because it sees an unexpected battery voltage.

 

[CKidder]

I'd have to guess voltage irregularities as well. It's possible that the charger listens to BMS messages and faults if the reported voltage from the BMS isn't pretty close to the voltage it measures itself. I'd probably do a check like that if I were them.

It sounds promising though! If it gets that far then that's a good sign. Maybe post a snippet of log of the bus from a little bit before the fault to a little bit after. It must be setting some sort of fault flag and maybe we can figure out what that fault flag means.

 

[jackbauer]

It's alive!!!!!

 

[Tomdb]

Please do indulge us Damien

A youtube video coming? You capable of commanding a range of voltages and current already?

 

[Kevin Sharpe]

Please do indulge us Damien

A youtube video coming?

Patreon is the place to go for the latest news

 

[Tomdb]

Fully aware Kevin, and ofcourse im chipping in.

Just waiting on that notification email.

 

[Kevin Sharpe]

Fully aware Kevin, and ofcourse im chipping in.

Sure... more of a reminder to other readers of this thread that developers need to eat

 

[jackbauer]

The video :
https://www.youtube.com/watch?v=mOIgp3QFg78

So only very basic control at this point. Just turn on and ramp up until I chicken out. Lots more on the way

 

[Tomdb]

Do you have a spreadsheet showing the messages decoded so far?

Might be easy to whip up a arduino sketch to control the charger with a due.

The question ofcourse is how much of the can messages are really needed.

 

[jackbauer]

That's on the cards for tomorrow Tom. Need to beef up my wiring and add cooling so I can let it run at full power then figure out the necessary messages. I know 0x045c is needed and it has some weird crc byte going on.

 

[Tomdb]

Yes maybe built a setup on aboard, so you can use it as lab charger for any test pack or dc charging testing.

Did it with a chevy volt unit, very handy even as a heavy duty power supply.

 

[jackbauer]

Oh no. This is going in the Panzer

 

[jackbauer]

Ok so in order to run phase one of the charger it takes 3 CAN IDs :

0x0368
0x042C
0x045C

I have uploaded a file to the github ph1_frames.csv
When this is played back to the phase 1 module and mains applies at the right time the module will go through power up and ramp up to 8.5A DC and stay there until the capture ends. Details of the Savvycan settings in the picture attached.

0x045c seems to indicate when the mains must be applied. Work progresses....

 

[jackbauer]

0x045C seems to have a checksum of some type in bytes 0,6 and possibly 7. If I can figure this out it should be possible to write an arduino sketch to drive this puppy

 

[jackbauer]

Uploaded charger power_run_ph1.csv this is a capture of phase 1 starting up , ramping up to 8.5A DC 320VDC, 15.5A AC, 230v 50hz. Mains switched manually around message number 700 in ph_frames.csv

And of course the power goes out again just as I'm about to film
Maybe Elon bought the power company.....

 

[Kevin Sharpe]

And of course the power goes out again just as I'm about to film
Maybe Elon bought the power company.....

Maybe a Falcon 9 arriving overhead is a bit obvious

 

[CKidder]

0x045C seems to have a checksum of some type in bytes 0,6 and possibly 7. If I can figure this out it should be possible to write an arduino sketch to drive this puppy

Nope. None of those bytes present themselves as a likely CRC or security byte. A proper CRC would have a roughly even distribution of values and almost always is coupled to a counter byte or nibble so that the traffic continuously changes and the CRC/Security byte can then detect trouble easily and quickly. None of that is present. It appears to be three signals with byte 5 and 6 always being zero. The signals are fairly constant too, there just isn't a lot of variation here. Personally I'd try hard coding the data bytes to just one set of values and transmit it over and over. I'm thinking the actually interesting stuff is in the other IDs. I don't know what 0x45C is but I don't think it's that important.

Depending on which version of SavvyCAN you're using you could do lots of fun stuff to make the 0x45C message happen but always be static. If you have a recent enough version you could write a Javascript file that implements the suspected charging protocol directly and then edit it until it works. Or you can turn off transmission of 0x45C in the playback window and add it to the custom frames window triggered by your sending of one of the other messages. Or you could script just that part. Or you could use the fuzzing window but lock it to one ID (0x45C) and the bits you want set. Then fire that up at like 20ms and do your playback with just the other two. SavvyCAN has gotten really large and feature rich but unfortunately the jerk that wrote it never documented any of it. So if you have questions about how to do something just ask.

 

[jackbauer]

Thanks Colin. I'll have a play tomorrow if the power is back on.

 

[jackbauer]

Ok. New theory. One time today when I was doing a power run I forgot to install the fuse that bypasses my cooker element (approx 10R) on the hv dc side. The charger ramped up to 1.5A and hunted around that current value while holding the battery at exactly 370V until the capture ran out.

one of the last values of 0X045C is 0x57 0x90 0x15 0x2E 0x00 0x00 0x6A 0x8C

take bytes 0 and 1 in little endian so 0x9057 = 36951 x 0.01 = 369.51V

Could this be the voltage target ? Find out tomorrow. Same prat time, same prat channel

 

[Tomdb]

Gents my findings so far.

And nice one on finding that. Mind sharing that capture so i can check if my findings are true?

Just found that the last bytes of that message, 0x045C read 0x8C6A or 359.46 V if divided by 100, plus then overlaying with the capture with the knowledge for damien this looks very much like a Voltage feedback from the control board (maybe from the battery). See updated document with graphs.