The ZombieVerter VCU Project

[Bryson]

PWM fuel, temp, and tach-ammeter would be most excellent!

[Jack Bauer]

Ok we have pwm channels accounted for. good call on the digi pot. Any part recomendations?

[JaniK]

Maybe some outputs to trigger a led for status of the VCU?
Like for some classic car where dashboard consist of speedo only.

Like for now just extra LED drivers #1-4 and map them later?

[chuuux]

Maybe some outputs to trigger a led for status of the VCU?

Good idea. It looks like some feedback about curent mode. For example, start, precharge, forward, reverse.
And maybe one output for beeper for some warnings (temperature, connections failure, etc)

[Bryson]

That reminds me - a fourth+ PWM for a speed signal might be useful. You could simulate any OEM differential/transmission based hall sensor this way.

Extra pins would be great to map to even more PWM capable general outputs. Agreed on the state feedback above. As an example, I’ve got my precharge contactor feedback triggering my ignition light in the dash, sort of like how an alternator light behaves during engine startup, a general 12v/ground output (mine is ground switched). It comes on during startup and turns off when precharge is complete.

Other things like AC compressor control, heater PWM control, and water pumps could all use these. Basically lots of PWMs would be useful to me

[chuuux]

Sorry if this sounds naive.
Is it possible to add the outputs to control the second inverter, as charging, or for the 4WD purpose?

[EV_Builder]

Ok, i would like more PWM outputs too, and i miss PWM capable inputs (properly we should make sure it works with a 100Hz signal atleast).

The 2nd gen Volt charger and DC/DC converter uses these if i'm correct.

I think that the final what comes out of the pin header is a question of which jumps we solder.
(in my head i see the header trace running and at its side i see some copper spots to bridge it.)
(This way you can easily give it 4 choices.) (see picture).

It gives flexibility for the different kind of IO each EV needs.

Last but not least it would perhaps be a good idea to have a free construction zone.
(any room left?) prepared as a PDIP prepared zone...

(It gives us the flexibility to mount a relais or something we forget / less common / vehicle specific. Having the obvious 5VDC / 12VDC and GND is offcourse nice...)

This is the idea how i thought we could make the choice for the pins on the header.
I think its a pretty dense way of giveing flexibility.
Also haveing the pad populated gives us the option to always wire a small line to our 'construction' zone to manipulate the signal comeing from the external before feeding it back into the MCU.

header_trace_idea.png (2.71 KiB) Viewed 3698 times

I would say flexibility is the main goal, but i think we are already on that route and are filling in the blanks.

Choices?

Dig. Inputs for Dig. Outputs
Analog Outputs for PWM outputs
Digital outputs for PWM outputs
Relais outputs for Digital outputs
Analog Inputs for PWM capable inputs

[Jack Bauer]

That all sounds good. Just remember that my goals with this project are two fold : 1)Make it as much plug and play for an end user as possible 2)Design in as much hardware flexibility as possible while keeping 1 in mind.

So The default setting of both hardware and software will respect 1 while allowing for 2 for more advanced users. Make sense?

[Jack Bauer]

Any recomendations for a digital pot IC for fuel gauge drive?

[johu]

I always drive them with plain or RC filtered PWM. But of course that can only simulate resistance to GND. Wouldn't be surprised if there are gauges around that don't work like that?
BTW will one of the digital outputs be strong enough to run the vacuum pump directly? And have freewheeling.

Re PWM inputs, I think there are 8 timers on the F107 100 pin, they can all do input capture on 4 channels to arbitrary frequencies. Though it seems duty cycle measurement occupies 2 channels (one for on-time, one for total period).

[Bryson]

My fuel gauge is driven the same way, filtered PWM via SimpBMS. Being a 50 year old car, it’s expecting a solid resistance and the PWM works great. You might just duplicate what Tom has done there.

[Jack Bauer]

Yeah BMW fuel gauges don't like filtered pwm to ground Ok, I'll go find a digi pot on JLC...

[EV_Builder]

That all sounds good. Just remember that my goals with this project are two fold : 1)Make it as much plug and play for an end user as possible 2)Design in as much hardware flexibility as possible while keeping 1 in mind.

So The default setting of both hardware and software will respect 1 while allowing for 2 for more advanced users. Make sense?

I think you are spot on!

What about this for in practice:

You can make one connection (the default) permanent, this full fills nr 1. requirement.
The skilled user can brake/cut it (between the dots) and choose another setting nr 2.
(as long as you draw (print, etch) the copperlanes its not an issue);
This saves also allot of soldering etc. and creates a default setting and leaves the option for skilled users adaptations etc.

I think that PWM inputs could even do with just sampleing with quick timers?
We just need to make sure one can jump input filters perhaps?

[EV_Builder]

Sorry if this sounds naive.
Is it possible to add the outputs to control the second inverter, as charging, or for the 4WD purpose?

I think that a second inverter always will be like a slave inverter to the master.
I'm planning of building an class for it as soon as i'm into that stage.

For display purposes i think we should use something on the canbus.
I bet that there are allot of options which we could use to make nice HMI's.

Something with grafana perhaps.?
would that run on Android? That would give us directly a OpenEVHMI.

[jon volk]

If one were to have selectable circuit paths, I’d think a small dip switch array is a bit more elegant than cutting traces. However I think it becomes a slippery slope since you’ll never cover 100% use cases with one piece of hardware.

[Dilbert]

Yeah BMW fuel gauges don't like filtered pwm to ground Ok, I'll go find a digi pot on JLC...

I was looking for what range the digi pot needed, 500ohms is fine for the fuel, we would need around 5k for the temp senders.

I typically use the microchip parts. I wonder do we need to spec a different resistance range for each

[EV_Builder]

I know that perhaps i will be lynched for this, but i still feel i need to bring this up.

Reason i suggest is that i just learned that the DUE CPU has more MIPS then our F10x, so i thought lets check..

Why don't we go with the : STM32F4series? 3 CAN ports native and a bunch of other stuff and most importantly more crunch power.
DAC's build in too...

I also found the STM32F2 series at JLCPCB 100pins and its way cheaper then our STM32F1xx cpu and way faster...
I know that for generating a inverter application its not needed, but when we start going on the VCU perhaps its not that bad idea at all...


https://www.st.com/resource/en/applicat ... ronics.pdf

https://www.st.com/resource/en/applicat ... ronics.pdf

If you check the documents it doesn't look that much work...

[jon volk]

Why don't we go with the : STM32F4series?

To quote Johannes from another thread…

libopencm3 doesn't seem fully fleshed out for the F4. There seem to be fundamental differences. So I'd say this project is F1 only.

[mackoffgrid]

Why don't we go with the : STM32F4series?

With the chip shortages I've been forced into the F4 (and L4) series.

[Jack Bauer]

I have no issue at all with an F4 device. The problem is (as always for me) the software. At least with the F1 I can get enough of a grip to do the basics while leaning on Johannes and his work. It's essential for me to have that as I do want to be able to do my own mods and modules and at least be able to follow that which are done by others. If we go F4 I'm guessing I'd loose that?

[mackoffgrid]

I have no issue at all with an F4 device. The problem is (as always for me) the software. At least with the F1 I can get enough of a grip to do the basics while leaning on Johannes and his work. It's essential for me to have that as I do want to be able to do my own mods and modules and at least be able to follow that which are done by others. If we go F4 I'm guessing I'd loose that?

I haven't been able to keep up to date with this thread so forgive me if I've missed something. I don't see that big of a change in code going to F4 with your core code remaining the same.

But saying this I am just starting this process myself. Having been forced by stock shortages to change processors several times - I have just ordered ( from USA suppliers) stocks of stm32L452R and stm32F446R purely for my own consumption - everything else has gone. I'd recommend thinking about securing stocks. It's a PITA and now I've got to place these chips myself

[mackoffgrid]

Yeah BMW fuel gauges don't like filtered pwm to ground Ok, I'll go find a digi pot on JLC...

A buffered digi-pot is okay but perhaps the problem with filtered pwm is that it's not filtered enough or the pwm is not running at a high enough frequency (for the given Rs and Cs).

I made myself a CAN driven board specifically to drive my instrument cluster. From memory I use a pwm freq of about 4kHz to drive my fuel and temp senders.
https://github.com/mackelec/SolarUte/tr ... s/CANio-18

[Jack Bauer]

Thanks mackoffgrid. Given no one seems to want to get into the details of whats involved in an mcu change then we'll be staying with the f107. As stated this will be 100% opensource so those who don't like what I do can modify it to their own needs.

[Jack Bauer]

Enclosure kit arrived and looks great. Looks like the board mounts to the 4 corners via m3 screws. I'll go ahead and order a few more from the seller to have available when boards arrive. I may end up migrating all the projects to this enclosure and connector as the ME-MX stuff is getting very hard to source and expensive.

[johu]

Just designing the VCU of a Volvo project and found there are two cases when I want it to switch on
1. Driving
2. Charging

Since I don't want to switch on all the "Driving" stuff when charging (and vice versa), it'll need to have two decoupled supply inputs. Would that be interesting here as well?