Gen 2 Charger V5 Software Development Thread

Topics concerning the Tesla front and rear drive unit drop-in board
tom91
Posts: 1275
Joined: Fri Mar 01, 2019 9:15 pm
Location: Bristol
Has thanked: 97 times
Been thanked: 204 times

Re: Gen 2 Charger V5 Software Development Thread

Post by tom91 »

Missing messages: 0x44C and 0x368

Wonder if it is due to trying to push alot of canbus at once, so might want to have a cyclic message system. I have now started doing that in various projects.

Instead of all messages at 100ms interval, for 5 messages run it a 20ms interval but send one message at a time and just cycle through it.

Good start would be with a delay in front of the two missing messages.
Founder Volt Influx https://www.voltinflux.com/
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Just to be thorough, here is a CAN capture with 115VAC directly connected to the charger without an EVSE.
Attachments
No EVSE CAN capture.xlsx
(104.9 KiB) Downloaded 154 times
Formerly 92 E30 BMW Cabrio with Tesla power
tom91
Posts: 1275
Joined: Fri Mar 01, 2019 9:15 pm
Location: Bristol
Has thanked: 97 times
Been thanked: 204 times

Re: Gen 2 Charger V5 Software Development Thread

Post by tom91 »

Did that show any change on the debug?

Still the 0x368 message missing, which is most likely the culprit.

My suggestion would be, have two sets of messages and alternating between them for each callback for timer 3.
Also then just half the timer 3 trigger to bring message frequency back to the right frequency.
Founder Volt Influx https://www.voltinflux.com/
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

No change in debug mode since the message is still missing.
Formerly 92 E30 BMW Cabrio with Tesla power
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Thanks to some back and forth with Tom, we’ve got it working on the EVSE.

Will post code and a compiled file later
Attachments
D3D98ABC-E602-49B0-89AC-10475E21DE28.jpeg
Formerly 92 E30 BMW Cabrio with Tesla power
User avatar
Kevin Sharpe
Posts: 1345
Joined: Fri Dec 14, 2018 9:24 pm
Location: Ireland and US
Been thanked: 4 times

Re: Gen 2 Charger V5 Software Development Thread

Post by Kevin Sharpe »

jon volk wrote: Sat Apr 25, 2020 6:31 pm Thanks to some back and forth with Tom, we’ve got it working on the EVSE.
Congratulations, that's great news :)
This is a personal post and I disclaim all responsibility for any loss or damage which any person may suffer from reliance on the information and material in this post or any opinion, conclusion or recommendation in the information and material.
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Attached is the main file with the revised code. Attachements wont let me upload a .bin or .elf.
Attachments
main.c
(44.16 KiB) Downloaded 123 times
Formerly 92 E30 BMW Cabrio with Tesla power
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Still have some work to do. Current isn’t quite what I’d call stable, but it looks like a nice end of charge taper. At least I can plug it in and charge. I am going to jumper the usart1 and programming pins to empty external pins for ease of flashing/monitor. I also noticed all the WiFi gauge values were 900, so that’s on the to do list.
Attachments
903B7655-1755-4C40-A58A-19416CD34137.jpeg
Formerly 92 E30 BMW Cabrio with Tesla power
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Gen 2 Charger V5 Software Development Thread

Post by Jack Bauer »

Can you detail the changes made?
I'm going to need a hacksaw
tom91
Posts: 1275
Joined: Fri Mar 01, 2019 9:15 pm
Location: Bristol
Has thanked: 97 times
Been thanked: 204 times

Re: Gen 2 Charger V5 Software Development Thread

Post by tom91 »

Jack Bauer wrote: Sun Apr 26, 2020 7:39 am Can you detail the changes made?
John implemented this:
tom91 wrote: Sat Apr 25, 2020 5:35 pm Still the 0x368 message missing, which is most likely the culprit.

My suggestion would be, have two sets of messages and alternating between them for each callback for timer 3.
Also then just half the timer 3 trigger to bring message frequency back to the right frequency.
So turns out requesting more then 3 messages to be sent in one hit (sequentially in code) causes messages to not be sent. So this is why you need a cyclic counter that just sequences through message sets every time the timer 3 callback is triggered.
Founder Volt Influx https://www.voltinflux.com/
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Gen 2 Charger V5 Software Development Thread

Post by Jack Bauer »

Ah ok very good. I seem to remember the stm32 can module has an auto retransmit setting. I might see if that makes a difference. Anyway, Thanks guys much appreciated:)
I'm going to need a hacksaw
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Yup. In the end there weren't too many changes thus far.

To get the ADC to read, I moved the val to a global variable up in the EVSE setup and moved the function code out of an if statement. I also divided the ADC value by 4 to align it with the existing plug state parameters.


Code: Select all

void evseread(){
/*{
 uint16_t val=0;

  if(HAL_ADC_PollForConversion(&hadc1, 5)){
	  val=HAL_ADC_GetValue(&hadc1);
  }*/

  HAL_ADC_PollForConversion(&hadc1, 5);
  val = (HAL_ADC_GetValue(&hadc1)/4);
The above fixed the connection state. Then we were missing two CAN messages. On Tom's suggestion, broke the CAN messages into 2 sets of 3 alternating transmissions.

Code: Select all

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
	if(htim->Instance == TIM3){
		if (mescycle > 1){
			mescycle = 0;}

		if (mescycle == 0 ){

		Charger_msgs1();
		Backfeed();

	}
		else  {
			Charger_msgs2();

		}

		mescycle ++;
	}

Grouped the CAN messages by breaking it into two separate functions.

Code: Select all

void Charger_msgs1(void){

	  /////////////////////This msg addresses all modules/////////////////////////////////////////////////
	  myTxMessage.StdId = 0x045c;            // Set our transmission address ID
	  myTxMessage.DLC = 8;            // Data payload 8 bytes

	  CanTxData[0] = (uint8_t)((parameters.voltSet)&0xFF);  //Voltage setpoint
	  CanTxData[1] = (uint8_t)((parameters.voltSet)>>8);//Voltage setpoint
	  CanTxData[2] = 0x14;
	  if (bChargerEnabled)
	  {
	    CanTxData[3] = 0x2e;
	  }
	  else {CanTxData[3] = 0x0e;}
	  CanTxData[4] = 0x00;
	  CanTxData[5] = 0x00;
	  CanTxData[6] = 0x90;
	  CanTxData[7] = 0x8c;
	  HAL_CAN_AddTxMessage(&hcan, &myTxMessage, CanTxData, &TxMailbox);
	  //////////////////////////////////////////////////////////////////////////////////////////////////////

	  //////////////////////////////////////Phase 1 command message////////////////////////////////////////
	  myTxMessage.StdId = 0x042c;            // Set our transmission address ID
	  myTxMessage.DLC = 8;            // Data payload 8 bytes

	  CanTxData[0] = 0x42;
	  CanTxData[2] = (uint8_t)(modulelimcur&0xFF); //AC Current setpoint
	  CanTxData[3] = (uint8_t)(modulelimcur>>8); //AC Current setpoint
	  if (bChargerEnabled)
	  {
	    CanTxData[1] = 0xBB;
	    CanTxData[4] = 0xFE; //FE dont clear faults. FF do clear faults.
	  }
	  else
	  {
	    CanTxData[1] = (uint8_t)(((uint16_t)(ACvoltIN / 1.2))&0xFF);
	    CanTxData[4] = 0x64;
	  }
	  CanTxData[5] = 0x00;
	  CanTxData[6] = 0x00;
	  CanTxData[7] = 0x00;
	  HAL_CAN_AddTxMessage(&hcan, &myTxMessage, CanTxData, &TxMailbox);


}
void Charger_msgs2(void){


	  //////////////////////////////Phase 2 command message/////////////////////////////////////////////*/

	  myTxMessage.StdId = 0x43c;        //phase 2 and 3 are copies of phase 1 so no need to set them up again
	  HAL_CAN_AddTxMessage(&hcan, &myTxMessage, CanTxData, &TxMailbox);
	  ///////////////////////////////Phase 3 command message/////////////////////////////////////////////

	  myTxMessage.StdId = 0x44c;
	  HAL_CAN_AddTxMessage(&hcan, &myTxMessage, CanTxData, &TxMailbox);

	  ///////////Static Frame every 100ms///////////////////////////////////////////////////////////////////

	  myTxMessage.StdId = 0x368;            // Set our transmission address ID

	  CanTxData[0] = 0x03;
	  CanTxData[1] = 0x49;
	  CanTxData[2] = 0x29;
	  CanTxData[3] = 0x11;
	  CanTxData[4] = 0x00;
	  CanTxData[5] = 0x0c;
	  CanTxData[6] = 0x40;
	  CanTxData[7] = 0xff;
	  HAL_CAN_AddTxMessage(&hcan, &myTxMessage, CanTxData, &TxMailbox);

}
Tom mentioned shortening the Timer 3 interval, but I have yet to do that.

On the debug screen, the AC limit seems to be constantly changing.
Formerly 92 E30 BMW Cabrio with Tesla power
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

It seems the pilot signal may need work. Generally everything seems to be working but both my evse and charger will get clicky spasms on occasion. It seems the evse will shut of briefly, then modules start clicking off/on, then evse clicks on....repeat 2 or 3 times, then were good for a while.

I dont fully understand (nor looked in depth yet) at the pilot signal requirements vs. what is being read.
Formerly 92 E30 BMW Cabrio with Tesla power
User avatar
Kevin Sharpe
Posts: 1345
Joined: Fri Dec 14, 2018 9:24 pm
Location: Ireland and US
Been thanked: 4 times

Re: Gen 2 Charger V5 Software Development Thread

Post by Kevin Sharpe »

jon volk wrote: Wed Apr 29, 2020 7:49 pm I dont fully understand (nor looked in depth yet) at the pilot signal requirements vs. what is being read.
I had a very quick look at the hardware/software and we may have an outstanding issue with the pilot State B (Ready) to State C (Charge) transition control circuit. This line is commented out in V2, V4, and V5 software;

//digitalWrite(EVSE_ACTIVATE, HIGH);//pull pilot low to indicate ready - NOT WORKING freezes PWM reading

I know some EVSE actively check the pilot signal and may get upset if they don't get the correct levels. I also note on V5 that R11 (1K5) in parallel with R12 (2K7) is a 964R load as opposed to the 882R required by the standard. I'll check the tolerances in the latest documents when I get a moment.
This is a personal post and I disclaim all responsibility for any loss or damage which any person may suffer from reliance on the information and material in this post or any opinion, conclusion or recommendation in the information and material.
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

So in an effort to bypass any pilot read, I swapped the following code in based on the high value read from my EVSE to give a steady state input to the controller. I am still getting intermittent performance from the charger. It will not give a steady output over time and it seems to only be operating on two phases of DC output despite all 3 LEDs being on and AC registering on each input. I attached a serial log but did not have a chance to try and get a CAN log as well.

Code: Select all

 else
  {
    //accurlim = (micros() - pilottimer) * 100 / duration * 600; //Calculate the duty cycle then multiply by 600 to get mA current limit
    accurlim = 52400;
  }
Attachments
Serial log.xlsx
(17.84 KiB) Downloaded 139 times
Formerly 92 E30 BMW Cabrio with Tesla power
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

I upped the static accurlim value to the max of 65535 and get a current reading at the evse of 32amps. Module 2 in the monitor still shows 0 DC output current.
Formerly 92 E30 BMW Cabrio with Tesla power
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Just sort of thinking out loud. In looking at my serial log, is it possible the DC current is must a comm error? The module current request in the log is 8733. When all 3 modules show AC current of 8.7 amps, the EVSE will read approx 24 amps of current so it would seem all 3 modules are consuming power. I am still unsure what is causing them to turn on/off now that the pilotcalc is set to a static value.

*edit* I did just remember I never halved the timer for the CAN messages after splitting them. Perhaps the modules are timing out?
Formerly 92 E30 BMW Cabrio with Tesla power
tom91
Posts: 1275
Joined: Fri Mar 01, 2019 9:15 pm
Location: Bristol
Has thanked: 97 times
Been thanked: 204 times

Re: Gen 2 Charger V5 Software Development Thread

Post by tom91 »

jon volk wrote: Thu May 14, 2020 3:32 pm Just sort of thinking out loud. In looking at my serial log, is it possible the DC current is must a comm error? The module current request in the log is 8733. When all 3 modules show AC current of 8.7 amps, the EVSE will read approx 24 amps of current so it would seem all 3 modules are consuming power. I am still unsure what is causing them to turn on/off now that the pilotcalc is set to a static value.

*edit* I did just remember I never halved the timer for the CAN messages after splitting them. Perhaps the modules are timing out?
Yes that could be it, I would say no harm in halving it and testing.

Any luck trying to get a propper reading out from the Pilot duty cycle?
Founder Volt Influx https://www.voltinflux.com/
User avatar
Kevin Sharpe
Posts: 1345
Joined: Fri Dec 14, 2018 9:24 pm
Location: Ireland and US
Been thanked: 4 times

Re: Gen 2 Charger V5 Software Development Thread

Post by Kevin Sharpe »

Kevin Sharpe wrote: Wed Apr 29, 2020 9:02 pm I know some EVSE actively check the pilot signal and may get upset if they don't get the correct levels. I also note on V5 that R11 (1K5) in parallel with R12 (2K7) is a 964R load as opposed to the 882R required by the standard. I'll check the tolerances in the latest documents when I get a moment.
I've checked the IEC61851-1 standard (see attached extract) and can confirm the resistors are defined as 2K74 and 1K3 with a +/- 3% tolerance.

Looking at the OpenEVSE source code (here) it can tolerate a pilot signal with a 250-600mV deviation from nominal (see attached source code snippet),

When I get access to the workshop I'll measure the pilot signal levels and confirm operation of Q1.
Charger_Gen2_V5_Pilot.png
OPEN EVSE Pilot Voltage.png
IEC61851-1{ed2.0}b_33-38.pdf
(1.53 MiB) Downloaded 121 times
This is a personal post and I disclaim all responsibility for any loss or damage which any person may suffer from reliance on the information and material in this post or any opinion, conclusion or recommendation in the information and material.
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

It looks like the modules were indeed timing out. I halved the CAN timing instance and it seems to be rolling at a pretty steady 32A of AC current. I have to assume my "0" module 2 signal is some sort of error since the AC request current and actual consumption at the EVSE all aligns. Im guessing there can be some scaling done as the pilotcalc value is at the max but we are still falling short of 10kw it seems.

Due to the STM32 stuff being a little more in depth than a simple .ino file ill work on getting a github account going for ease of sharing.
Attachments
Serial log CAN timing halved.xlsx
(18.15 KiB) Downloaded 108 times
Formerly 92 E30 BMW Cabrio with Tesla power
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Looks like the calculations are preventing full power with autoenablecharger.

Correct me if Im off on this...

With 65535 being the highest value for unint16, this means the highest modulelimcur can reach is 32.7A.

For testing purposes until I figure out the pilotcalc, would there be any harm in changing the formula to multiply by a factor of 2 instead of 1.5? This in theory should give 43.6A, unless Im missing something.
Formerly 92 E30 BMW Cabrio with Tesla power
bulletbug
Posts: 94
Joined: Thu Sep 26, 2019 5:12 pm
Location: West Jordan, Utah USA

Re: Gen 2 Charger V5 Software Development Thread

Post by bulletbug »

jon volk wrote: Thu May 14, 2020 8:46 pm It looks like the modules were indeed timing out. I halved the CAN timing instance and it seems to be rolling at a pretty steady 32A of AC current. I have to assume my "0" module 2 signal is some sort of error since the AC request current and actual consumption at the EVSE all aligns. Im guessing there can be some scaling done as the pilotcalc value is at the max but we are still falling short of 10kw it seems.

Due to the STM32 stuff being a little more in depth than a simple .ino file ill work on getting a github account going for ease of sharing.
I'm working with a Gen 2 v4 board and I'm wondering if the CAN message timing you mention exists in the v4 software as well. I'm not able to get my charger to go above a 4 or 5 amps total DC output while at the same time my serial monitor view shows the dc amperage being output is .02 amps per module.

Can you confirm if I'm on the right track to making a similar change in my version of the Gen2V4 Board software?

It sounds like you're saying that the power module's can connection side is timing out because we're not sending instructions often enough. True?

If that's correct do I make a change in the switch (state) section of the code (around line 363 in the v4 .ino file) from 90000 to 45000?

case 2:
digitalWrite(DIG_OUT_1, HIGH);//HV ON
Timer3.attachInterrupt(Charger_msgs).start(90000); // start sending charger power module CAN messages
switch (parameters.enabledChargers)

Thank you.
David
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Gen 2 Charger V5 Software Development Thread

Post by jon volk »

Yes, it does appear that in this case they needed the messages to be sent more often. The previous versions seem to be working as they should, but perhaps there are units out there with different Tesla firmware that faster receipt of messages. It cant hurt to try reducing the time interval.
Formerly 92 E30 BMW Cabrio with Tesla power
bulletbug
Posts: 94
Joined: Thu Sep 26, 2019 5:12 pm
Location: West Jordan, Utah USA

Re: Gen 2 Charger V5 Software Development Thread

Post by bulletbug »

jon volk wrote: Sat May 23, 2020 11:59 pm Yes, it does appear that in this case they needed the messages to be sent more often. The previous versions seem to be working as they should, but perhaps there are units out there with different Tesla firmware that faster receipt of messages. It cant hurt to try reducing the time interval.
Thank you. I moved it down to 45000 but saw no changes in behavior. I think I've got one of the odd gen 2 chargers with something different going on. I may try going further with dropping that timing instance to see if anything changes. I'm stepping through the v4 code, basically line by line to find out in order to make comments in the code regarding function.

I'm working on understanding the state switch. Case 0 - Everything is shut off. Case 1 - Each of the modules that have been requested to function via the Parameters variable set by the user, are active but not enabled/charging. Case 2 - Each of the modules are now enabled and being issued current and voltage instructions through the outframe processing.

Am i understanding this correctly?

Another question - Is the dccur variable that's read through the CAN frame.data an indication of DC current being pushed into the battery bank from the charger?
Bryson
Posts: 179
Joined: Sat Jan 25, 2020 6:22 am
Location: California
Has thanked: 1 time
Been thanked: 4 times

Re: Gen 2 Charger V5 Software Development Thread

Post by Bryson »

bulletbug wrote: Sun May 24, 2020 12:32 am I think I've got one of the odd gen 2 chargers with something different going on.
What rev is your charger, for the record?
‘70 jag XJ6, GS450h drivetrain, 102s Tesla pack
Post Reply