Gen 2 Charger V5 Software Development Thread

[Kevin Sharpe]

Yes. Still no luck with this bug. Have confirmed no hardware problems.

What connector are you using at the car end for test? AFAIK most J1772 car plugs do not implement the cable current sense resistor.

[tom91]

All type 2 cables should shave a resistor to identify them. The software, atleast when i wrote the base, takes the cable limit into account.

So it does the EVSE pwm limit first then checks if the cable limit is lower and adjusts if needed.

[Jack Bauer]

Yeah this is a bug in the new STM32F103 firmware that doesnt seem to read the adc value correctly. Not related to the evse or cables used.

[Kevin Sharpe]

All type 2 cables should shave a resistor to identify them.

They do, at the EVSE end (which then modifies the Pilot PWM accordingly)... the resistor at the vehicle end is a later addition to the standard. I suspect millions of cables exist without the resistor at the vehicle end (certainly we made many thousands without this resistor).

How does the software know whether it's a "Type 2" connector with a resistor and a "Type 1" ("J1772") connector without a resistor? What does it do if no resistor is installed?

[tom91]

All type 2 cables should shave a resistor to identify them.

They do, at the EVSE end (which then modifies the Pilot PWM accordingly)... the resistor at the vehicle end is a later addition to the standard. I suspect millions of cables exist without the resistor at the vehicle end (certainly we made many thousands without this resistor).

How does the software know whether it's a "Type 2" connector with a resistor and a "Type 1" ("J1772") connector without a resistor? What does it do if no resistor is installed?

Software does not allow a cable without a resistor at the vehicle inlet. It needs to detect a cable plugged in on the proximity line to allow it to start the evaluation if it can allow charging.

You configure the Socket Type....

[Kevin Sharpe]

Software does not allow a cable without a resistor at the vehicle inlet. It needs to detect a cable plugged in on the proximity line to allow it to start the evaluation if it can allow charging.

Sorry, I was unclear, in all scenarios you have resistor(s) on the proximity pin at the car end of the cable.

You configure the Socket Type....

What if the proximity resistor in the handle at the car end of the cable conforms to the J1772 'standard' (150R + 330R) rather than the IEC 61851 standard (100R, 220R, 680R or 1500R)?

[tom91]

What if the proximity resistor in the handle at the car end of the cable conforms to the J1772 'standard' (150R + 330R) rather than the IEC 61851 standard (100R, 220R, 680R or 1500R)?

The Type 1 J1772 standard does not support cable rating, so there is no cable rating applied if the Charger is configured to Type 1.

The software detects the plug, using the resistor in the plug, with Type 2 it then also checks cable current limit, with Type 1 it can detect switch pushed or not and stop charging if the switch is pressed.

[Kevin Sharpe]

The software detects the plug, using the resistor in the plug, with Type 2 it then also checks cable current limit, with Type 1 it can detect switch pushed or not and stop charging if the switch is pressed.

Ok, I see the logic... I guess the question is how many "Type 2" cables exist in the wild without the RC resistor at the car end

Adaptors at the car end also need some thought... thankfully this is all open source so I can modify the behaviour if I wish

[tom91]

Ok, I see the logic... I guess the question is how many "Type 2" cables exist in the wild without the RC resistor at the car end

Adaptors at the car end also need some thought... thankfully this is all open source so I can modify the behaviour if I wish

Yes that is the power of open source, you can a lot more easy adapt it to whatever situation you find yourself in.

There will always be some EVSE/installation that does not exactly follow the rules so you will always find new quirks/bugs.

[Kevin Sharpe]

Yeah this is a bug in the new STM32F103 firmware that doesnt seem to read the adc value correctly.

Seen this App Note?

STM32 ADC modes and their applications

en.CD00258017.pdf

(236.26 KiB) Downloaded 355 times

[jon volk]

Have a Gen 2 charger coming on Friday and also picked up a couple blue pills to mess around with the ADC on the bench. Had a few stumbles getting accustomed to the IDE and code after messing with Arduino based stuff, but now have the charger software running on one of the blue pills. Ill see if I can make any headway.

[Jack Bauer]

Thanks Jon. Very much appreciate the support.

[jon volk]

I just got the ADC reading on the blue pill. Just need to change scaling values(possibly. they don't seem to align but I need to do more testing) in the evseread function. Should be have it wrapped up for testing tomorrow.

[jon volk]

Not up to speed with how github works, but give this a try.

[Jack Bauer]

Will give it a shot. Thanks Jon.

[jon volk]

Started messing with the actual charger. WIth the code I posted above, I can get the connection state to change on the bluepill test with varying the input voltage. When running the above code on the logic board. It seems stuck at unconnected reading back a value of 996-998 regardless of connection. I need to dig in a little further.

[Jack Bauer]

Is the voltage on the pin of the stm32 actually changing?

[jon volk]

That’s what I need to verify, as well as my measured voltage at the connector. Garage was cold and ran out of time yesterday.

[jon volk]

Progress made. It turns out my prox input put wasnt fully seated in the molex connector. Once my oversight was fixed, we now have the J1772 connection state properly working.

Ive now run into another issue. My evse will click the AC voltage on as shown in the debug screen, but it will not command any current. There is also a toggling going on with the AC cur limit values. Need to look into that further. Any ideas there?

Video in action.

[jon volk]

Screen grab of the latest plug in.

[Jack Bauer]

You the man Jon:) I had not gotten any further then the prox detect problem but I see there your cable limit is 0 that is why its not drawing any current. It's not setup to calc the cable limit from the new values from the adc I would guess.

[tom91]

Screen grab of the latest plug in.

That looks good to me the current request is what is shown in the debug. so it should be asking for 4444mA ac current into the phases.

What is your configuration?

[jon volk]

Heres the settings I have in there. It appears the AC is being requested, but the EVSE is not supplying the requested voltage. If i look at the EVSE app, it shows as connected, but not supplying any current.

[tom91]

Heres the settings I have in there.

Be good to do debugging on the pilot signal output values.

Like add at line 1284:

Code: Select all

  
  else
  {
    accurlim = (micros() - pilottimer) * 100 / duration * 600; //Calculate the duty cycle then multiply by 600 to get mA current limit
    printf( \r\n);
    printf("Pilot curlim: ");
    printf(accurlim);     
  }

This will be a pain to see as it will be a lot of data due to the 1000hz pwm. But should indicate if there is an issue interpreting it.

Also a can capture of the charger coms would be usefull just to check what is being sent and to make sure you are not just having a quick on the module side.

[jon volk]

Added jumper wires to get an external CAN connection. Here is a snip while plugged in.