openinverter forum

Well I went to test again, having added a relay to power up the VCU when the plug is inserted. I tested said relay by placing a wire between pins 1 and 7 in the CHAdeMO receptacle (ground and proximity, as it's active low) -- it behaved as desired, powering up the VCU.

Then I went to charge at the local EVGo station. And lo and behold, the relay wouldn't click and thus wouldn't power up my VCU.
Has anyone else encountered this? It seems to be a failure in the proximity signal from the station.
I'd try on the other station here but the chargers there won't accept payment, seems like the credit card reader is shot.

Anyways, I'll add an override and go test again.

-Isaac

EDIT I'll test tomorrow, it's dark and the trunk keeps closing on my head. Not great conditions for HV testing.

I went to test versions 0.6 and 0.7 more fully today.
The results:
-0.6 is known good, it charges properly and terminates when it ought to.
-0.7 worked the same way after a couple of edits (apparently Serial and SerialUSB behave differently, even when one is aliased to the other.)

Both versions follow the amp limit of the station; my local chargers are 115A and the VCU followed that, holding itself to 115A.

Now here's where the weirdness starts.

I set my "V" to 380 since the pack was at ~375.

When the voltage hit 380, I expected a rampdown. But no! It continued til about 385, when the rampdown ran properly and terminated charging slowly.

After adding a bit of debugging code, I figured out what is going on.
The VCU ramps current based on the station voltage, not the voltage reported by the ISA.
And for some reason the station reports LOWER voltage than the car! That makes about zero sense since the voltage drop ought to operate in the other way anyways.

I'd love some input on this issue -- has anyone else seen something like this?
I can fix it fairly easily by changing the ramping algorithm's input parameters -- just forcing it to follow the ISA voltage rather than the station's reported voltage. And the ISA is most likely reading accurately, I'll grab BMS data as well to corroborate it.

-Isaac

Found me a new issue!

When these EVGo stations begin to overheat (which is fairly quickly apparently) they begin to ramp down the available current. At quite a high rate. (as in between 2 messages it went from 114 to 98 and shut off).
I believe the software is not yet able to ramp down quickly enough.

So I'm just going to add something in the EVSE status reception routine which, if it detects a downward change in the available current, will force a similar downward change in the requested current. Of course I will test this thoroughly, as it's rather important, especially on hot days.

Otherwise, it seems like the v0.10 (oof) software is nicely functional. If anyone wants it I can upload it, I'll also figure out some git and upload it there.

-Isaac

larsrengersen wrote: ↑Mon Nov 09, 2020 10:21 pm Update: wrote earlier that the non 3-channel version might be an option but it is not so 3-channel it is (thanks Damien for your input).

Lars, can you provide a bit more info on this? Given the dearth of availability on these precious little units, my shop was also wanting to get in on the reseller game to help stabilize the supply, and we were getting hung up on the U0 vs U3 configuration.

Considering the U0 was an error.
You need current and voltage from the IVT.
So you need at least one voltage measurement.
However as Damien wrote, U3 is most flexible because then you can also track midpack if you want.
So as far as I’m concerned, U3 it is (that’s the one I stock and sell).

On mobile, unable to review the schematic.

So I ask, is there a termination resistor on the board I would just remove if I use the isa can1 shunt( can1 is already terminated) ?

There is a resistor and a solder jumper. I'm not sure whether it comes soldered from Damien/JLC.
SJ1 is the jumper, R69 is the resistor.

The CAN1 terminated versions of the IVTs only have one CAN port, as well, since there is no pass-through. I will probably end up using the CAN1 on my car since it'll be mounted at the battery and it will be easy to make that one end of the bus.

Folks, as it seems the SAM3 due processor is the latest victim of the global semiconductor shortage I'm going to move the chademo controller to the STM32F103 and use the openinverter template for software. I don't suppose anyone would be interested in assisting with the software side of this?

Silly question would it be worth thinking about using something like a teensy?

As although not the cheapest it is supposed by Arduino (teensy duino add on) and flexcan is supported by colin80.
I was hoping to do this with my teensey 3.6 setup but way off in future as I have a car a pile of bits (all critical components) and am moving house so am far off be actually being able to test yet.

But if there is interest in filling the teensy direction I can help in anyway I can (note I'm a mech eng not elec eng, I do have programming experience but not to the depths of someone who does it for a living as I gently use VBA, Fortran, matlab or python for work stuff every few years or so)

The only problem I have with Teensy is its a board not an IC to the best of my understanding. I'm not going down the road of piggybacking boards. Appreciate the offer:)

Schematic for stm32 version. Farirly simple from a hardware point of view. Pin compatible with the sam3 version. Now to go rip off Johannes stm32car....again ....

Sounds like a plan. I can't do the same for STM32 that I did for the SAM3X, don't know bare C well at all.
Good luck!

stm32car already has chademo but with a leaf BMS for current/voltage values. I might be being naive, but wouldn't it be fairly simple to replace that with the IVT shunt?

Good point! That should be trivial. Mostly a matter of taking out the extra things. If one wants to use the code as is then it's even fairly easy to translate the CAN messages externally.

In that case I'll try flashing stm32car onto a STM32 Nucleo I've got around and see what can be done on the chademo side. Might be a couple weeks before I get to it.

Thanks guys. I have 2 cars in need of chademo here myself so I'll have a crack at it also. Need to keep those programming skills razor sharp:) As always free hardware to those willing to help with firmware.

Did you make a start? I've taken stm32-template, added the chademo library from stm32-car and started on an ISA shunt if that's of any use.

https://github.com/jamiejones85/stm32-chademo

I've found a flow diagram to follow https://www.evcreate.nl/chademo-fast-charging-in-diy/

Not started as yet. Thanks for the help

I don't mind helping out on the coding side, but you'll have to do the testing. My car isn't yet mobile and I'll not be using an ISA shunt as I picked up a Telsa shunt cheap.

I'm thinking out load here...

Since we have quite a few single boards designed around stm32 such as stm32-car, leaf Lexus, chademo (hopefully), would it make sense to create a universal board around the stm32f107 as it has 2xcans, 3xspi (extra can), 2xi2c 80 pins etc... Would it make sense to make a universal board that would cover everything and have add on boards for contactor control etc?

Or if not using the stm32f1 at least try to unify around the stm32-car, to expand it to support the ISA (and other current sensors) add more bms' (slaves) e.g BMW phev, VW phev, add chargets etc

Collaboratively we could probably make this a much easier task I know that this means for many of us myself included moving away from Arduino IDE to code locks/vscode to use the core stm32 and the vertical learning curve involved !

Sorry if this is not exactly the right place for it

Yes things are quite similar. If you get too universal you end up with an Olimex STM32-H103
I think the Zombieverter VCU project is currently the best development in terms of being universal.

Boards have arrived. Now time for some software...

Check my repo above, not tested it beyond sticking it on a bluepill but I don't think it's a million miles off. Still want to move some of the ISA shunt values to OI values for viewing in the web interface. Happy to make any other changes it might require.

Yep thanks tried that out yesterday. I think something is broken in libopeninv or the bootloader as I can't get it to even flash an led. Same with other projects. Johannes is investigating.