Gen 3 inverter converter control software

[celeron55]

Do you have the current sensor ground properly soldered?

[Bigpie]

Not sure which pin that is, the other phase seems to be reporting correctly.

[celeron55]

Oh, actually there's no ground in the connector at all and there are no redundant power pins.

Swapping the sensor is a good idea. EDIT: Oh, you swapped it already...

[Bigpie]

Yep, at a bit of a loss now.

[celeron55]

The atmega328's RESET pin is next to the MG1_I2 (A5) pin and RESET is definitely at 5V all the time. Check if there's a short between those.

You could try disconnecting the current sensor and pulling A5 to ground via a resistor to see how strong the 5V is.

[Bigpie]

Already checked that. No short and A5 goes low with the current sensors disconnected.

[Bigpie]

Dead resistor in the voltage divider replaced and up and running.
Been playing with low voltages, it's working well so far, no dared connect up to mains again yet.

The interpretation of the CP signal is fluctuating but that could be my DIY signal generation. I'll have to look further.

Going to make some changes to the code next. It would be good to have output levels so the web interface can filter out, DEBUG, INFO etc. Also move some values to eeprom.

[bexander]

As a starting point I want to control the charger over CAN and not use the CP/PP.
I've started looking into the charger code and have some questions regarding CAN communication.
I made a short summary of the CAN messages from the charger code. Please let me know if something is incorrect.

Prius3ChargerBuckCANmsg.txt

(1.33 KiB) Downloaded 127 times

Regarding Id 0x320, how do I setup the inverter (STM32) to disable it self from this CAN message?

The charger expects Id 0x100 from BMS to tell that main contactor is closed. I'm letting the inverter (STM32) control the main contactor. How do I setup the inverter to send out this info?

Regarding Id 0x620. To set a AC input limit setting I first need to read Id 0x600 Byte 7 and send that as old value on 0x620 in order for the charger to accept a new value, correct?

[celeron55]

Regarding Id 0x320, how do I setup the inverter (STM32) to disable it self from this CAN message?

The protocol is just what I have in my car, it may or may not be universally usable.

For disabling the inverter using CAN, the code does two things: It starts sending 0x320 when the inverter should be disabled, and also sets byte 0 bit 0x08 in 0x600 that it always sends. I guess I'd configure it to be the din_emcystop input, but openinverter expects it to be inverted, i.e. not a disable signal but an enable signal. The 0x320 frame has lots of zero bytes so it could be configured for din_emcystop, but it's never sent when the inverter should be enabled, and I guess openinverter defaults to CAN inputs being 0 when they time out? So, good question.

Could just change the code to send an enable, not a disable bit, but then one will ask, what if I have two chargers and the inverter should be disabled when one of them is charging? This is what I designed the 0x320 frame for, as I actually have 3 chargers in my car and any of them can disable the inverter by just sending the exact same 0x320 frame, no customization needed.

The charger expects Id 0x100 from BMS to tell that main contactor is closed. I'm letting the inverter (STM32) control the main contactor. How do I setup the inverter to send out this info?

Getting the main contactor status from openinverter on CAN is something I'd like to be able to do later also. Also for that to be useful the inverter should be able to precharge and close the main contactor for charging purposes based on a CAN request. If I have to guess, johu's response will be "just add an arduino to do that for you", which is probably fair as these systems vary a lot based on people's preferences.

Regarding Id 0x620. To set a AC input limit setting I first need to read Id 0x600 Byte 7 and send that as old value on 0x620 in order for the charger to accept a new value, correct?

Yes, for safety I implemented the configuration messages of all CAN-enabled things in my conversion so that to change a value, you need to be able to read what the value currently is. It doesn't work for the start/stop messages though.

I'm thinking of extending the idea to everything though. If there was sort of a random nonce (as in cryptography) sent by each module that would change every few seconds, and you'd have to include it in your control message in order for the message to be accepted, it would rule out control messages that were delayed or modified by electrical issues or bugs in the code. Think of, say, if cruise control activation over CAN gets buffered somewhere and you get it 10 seconds later than you intended. It would scare the hell out of the driver. Of course alternatively you can just have a policy of not doing anything safety critical on CAN and hardwire the brake and the cruise button directly to the inverter, or you can just hope for the best which usually works too.

[bexander]

Thank you for that very extensive answer!

I think it is a good idea to use the BMS as a middle man between inverter and charger to get the results I want.
My plan for now is as follows:
At 12V power on, the BMS detects if AC is present and then sends "canio" start bit to start inverter and manage DC precharge and main DC contactor.
I can then read "opmode" and check for "Run" to confirm main DC contactor is closed.
Now send
0x100, Byte 0 = 0x05
0x101 data
0x102 Byte 2&3 = 0xFA (250, dec) (for 25A max DC current into battery)?
0x620 Byte 0 = 0x00, Byte 1&2 old value, Byte 3&4 = 0x10 (16, dec) (for 16A max AC phase current into charger)
followed by
0x620 Byte 0 = 0x01 to start charging

Is this reasonable or have I missed anything?
How often do I have to resend id 0x100 - 0x102 to avoid any timeouts?

[celeron55]

Those CAN frames look correct and it should work using those, however here's about the start/stop/restore commands as these are a bit weird:

• After being powered up the charger is in the WAITING_START_TRIGGER state. It will start charging once it sees the EVSE PP and CP signals, OR if you send the 0x620 0x00 AC current setting and have PP permanently grounded (in the case that you handle PP/CP elsewhere or don't use EVSE).
• The 0x620 0x01 start charge command: Only does something if the charger is in the DONE_CHARGING state. This command is not normally used. It's in that state only if you issued the stop charge command and there were no errors, or if the charger is just sitting there after the battery was fully charged, both of which generally mean you don't want to charge anymore.
• The 0x620 0x02 stop charge command: If the charger is doing something else than being in the FAILED state, it will stop charging and go into the DONE_CHARGING state as if charging had completed. If you want to pull the plug, issuing this command first is a good idea.
• The 0x620 0x03 restore initial state command: The "try again" command: If the charger is finished charging or failed charging, it will start over the entire process. If the charger is charging, this command does nothing. This is the command to issue when you have the car plugged in but for some reason no chargemathinging is going on.

If you use CANBUS_TIMEOUT_MS 2000 like I'm using, something like a 500ms interval is fine. Something that allows some lost messages here and there, as they can be lost due to various reasons.

(By the way, looks like the code is reading a pack voltage value from 0x100 and then using it for absolutely nothing. Quite confusing, I'll remove it next time when I'm working on it) (also, should add this to the README) (pull requests welcome on the repo)

[bexander]

Ok, great. Thank you!

[m.art.y]

Ok, great. Thank you!

Did you manage to get it working? Would you share how it went?

[bexander]

Ok, great. Thank you!

Did you manage to get it working? Would you share how it went?

Not tested yet. Will share when tested, which I hope will soon.

[Bigpie]

I've been doing a little more work on the web interface
Features

• Wireless Updating of ATMEGA firmware

• Updatable params stored in EEPROM

• Filterable debug output

https://github.com/jamiejones85/PriusCh ... bInterface
https://github.com/jamiejones85/prius3charger_buck

I can raise a pull request celeron55, if you want to review and merge the changes.

[Bigpie]

Looks like I'm getting a Golf GTE pack, voltage is 345 which is higher than single phase rectifies to, so to keep using this I either need to change to boosting with external rectifier or someone mentioned a voltage doubling rectifier?

[rstevens81]

There are a couple of ways to get it to work if you don't mind the noise of the eddy's running around your motor.
(This is basically my plan if I can ever get the damn 50 pin connector to work)
1. Fix pwm @0.7 boost using motor inductor as per oi boost charger
2. Try to drag down by increasing the duty to get the voltage on HV side to >360v, but less than say 380v
3. Voltage doubler love the simplicity but the cost of the capacitors might make it a bit pointless.

Ps love the project it pretty much sums up what many of us want to do .... An ev conversion on a human budget

[Bigpie]

Would it not be easier to use an external rectifier and current sensor and use mains on the LV side and boost up to charge?

[rstevens81]

The problem is the voltage range.... 2.7vx96=259 actually 3v is a better as fully discharged is 288v fully charged is 400v
AC mains 230v plus 10 minus 6 therefore 216 to 253 rectified 304 to 357.

If you are doing some power factor boosting....
It's what happens when your peak voltage is less than your battery voltage. Plus you need to allow for the variation in ac, it might be ok at home but could blow things up when you use the free charging at Asda/lidil etc or a friend's house.

If your just bridge rectified the mains into the DC cap then are boosting to a voltage lower than the rectified, I am unsure what would happen, would it just be pwm (basically like a DC motor controller) till the threshold where battery is greater than AC rectified voltage is reached?
I have never tried to drag down a boost converter to a voltage lower than input.

[NiHaoMike]

The problem is the voltage range.... 2.7vx96=259 actually 3v is a better as fully discharged is 288v fully charged is 400v
AC mains 230v plus 10 minus 6 therefore 216 to 253 rectified 304 to 357.

If you are doing some power factor boosting....
It's what happens when your peak voltage is less than your battery voltage. Plus you need to allow for the variation in ac, it might be ok at home but could blow things up when you use the free charging at Asda/lidil etc or a friend's house.

If your just bridge rectified the mains into the DC cap then are boosting to a voltage lower than the rectified, I am unsure what would happen, would it just be pwm (basically like a DC motor controller) till the threshold where battery is greater than AC rectified voltage is reached?
I have never tried to drag down a boost converter to a voltage lower than input.

Add a SCR (thyristor) to allow phase angle modulation to keep current under control when the output voltage is lower. The power factor will be poor so hopefully you're OK with slower charging until the voltage rises.

[Leo M]

Я немного поработал над веб-интерфейсом
Характеристики
Беспроводное обновление микропрограммного обеспечения ATMEGA
Обновляемые параметры, хранящиеся в EEPROM
Фильтруемый отладочный вывод
https://github.com/jamiejones85/PriusCh ... бинтерфейс
https://github.com/jamiejones85/prius3charger_buck

Fantastic job! I looked at the files and didn't quite understand how to install this interface . There is no file for arduino there is only an INI file...) could you please adjust the files for easy installation?thanks.

[Bigpie]

It's platformIO instead of arduino IDE. I would consider it experimental also.

[Leo M]

Deleted

[Leo M]

PlatformIO!!!! Super... Cool thing !! I started studying it - I really liked working in it....

[Bigpie]

I much prefer it to arduino IDE.
I have some unpushed changes, I'll push them tomorrow when I'm on laptop. There's a bug preventing setting of the bool parameters.