EMUS BMS <=> zombieverter

[allard]

I’m doing a conversion which has the SDU, Tesla batteries, Tesla gen2 OI charger and the EMUS BMS.

I’m thinking about adding the EMUS as an option to the BMS already supported by zombie. This would then make the EMUS replace the ISA shunt (it puts voltage and current on the CAN bus) and control the charger. I should be able to do the programming.

Any thoughts about this idea from the community? Are there things to keep in mind when doing this?

Thanks for thinking with me.

[tom91]

Why a Zombie verter?!

There is nothing there that it would be indirect control of.

Depending on how you are planning to use the Zombieverter various degrees are needed. ISA Shunt measures the voltage post contactors, the EMUS BMS does not. Thus you cannot miss out the ISA Shunt.

[johu]

I had a thought when discussing precharging with Zombie during a support call (because up to that point I didn't know how it worked)
Typically a BMS senses the voltage before the contactors. And then various peripherals like inverter and charger sense it behind the contactors.

What if the ISA shunt were classified a "BMS"? So delivers voltage before contactors.

Then you can do precharging by comparing voltage pre and post contactors. Just a suggestion.

I like the ISA shunt, it's almost comical how accurate it is. Comes at a price though

[J0hannes]

Tesla drive unit doesn't tell voltage it's getting?
Any reason, why this shouldn't be used for post -contactor voltage information?
I have done it this with my hackery with the Leaf stack and Leaf LBC, that's why I'm also asking why this shouldn't be done.

[johu]

Tesla drive unit doesn't tell voltage it's getting?

Oh yes, it does.

Any reason, why this shouldn't be used for post -contactor voltage information?

I'm just on my never ending simplification quest So when you have a BMS already that gives you battery voltage and current this could make the ISA shunt redundant in that case

[J0hannes]

I'm just on my never ending simplification quest So when you have a BMS already that gives you battery voltage and current this could make the ISA shunt redundant in that case

Ah, we're chasing the same point here!
I have omitted the ISA shunt for this reason

If I don't recall wrong, Leaf inverter sends precharge ready status in one of the CAN messages.
If I actually had coding skills, I'd modify the Zombie code so the precharge ready information could be taken from the Leaf inverter CAN message.

Maybe that'll come once I get my Rising sun moving...

[allard]

Simplification indeed, but some other reasons might be: maybe the SoC calculation of EMUS is more reliable, it can send individual cell temperatures and voltages to zombie (like simpBMS does), zombie can control the charging process together with the BMS thus making it more safe. Also in case of BMS detecting problems zombie can be informed and possibly act upon it.

[tom91]

Simplification indeed, but some other reasons might be: maybe the SoC calculation of EMUS is more reliable, it can send individual cell temperatures and voltages to zombie (like simpBMS does), zombie can control the charging process together with the BMS thus making it more safe. Also in case of BMS detecting problems zombie can be informed and possibly act upon it.

This is not implemented in the coding for the Zombie.

Ah, we're chasing the same point here!
I have omitted the ISA shunt for this reason

If I don't recall wrong, Leaf inverter sends precharge ready status in one of the CAN messages.
If I actually had coding skills, I'd modify the Zombie code so the precharge ready information could be taken from the Leaf inverter CAN message.

Maybe that'll come once I get my Rising sun moving...

Again none of this is in the Zombie code.

Oh yes, it does.
I'm just on my never ending simplification quest So when you have a BMS already that gives you battery voltage and current this could make the ISA shunt redundant in that case

Again not in the Zombie coding.

[J0hannes]

Again none of this is in the Zombie code.

On the other hand it is a good thing that you bring this up that none of this is implemented the official release of Zombieverter firmware.

Then again, what was asked in first post is opinion from the community and what I'm reading is that allard is taking up the task himself.
So maybe not necessary to wrestle the point any further that what is and what is not implemented in Zombieverter firmware?

I’m thinking about adding the EMUS as an option to the BMS already supported by zombie. This would then make the EMUS replace the ISA shunt (it puts voltage and current on the CAN bus) and control the charger. I should be able to do the programming.

Thanks for thinking with me.

Even though it may be totally obvious, my tip is that get familiarized with the different modules in Zombieverter code, variables and parameters, where they are used etc (EMUS docs too). My understanding how GitHub works is close to zero, but I believe that it will be a much simpler thing for Damien to merge the BMS addition to the main project if there aren't too many tweaks to be made manually.

The way I did things in my fork of the Zombieverter code to get my setup spinning motor and AC charging:
-Defined Leaf LBC (BMS) as shunt type
-When Leaf LBC is selected, Inverter power on always when contactors are pulled so inverter UDC can be used for precharge
-SOC calculation bypass in main when LBC used
-The implementation of the actual LBC features are still a work in process (i.e. charge/discharge limit)

[tom91]

none of this is implemented the official release of Zombieverter firmware

Then again, what was asked in first post is opinion from the community and what I'm reading is that allard is taking up the task himself.
So maybe not necessary to wrestle the point any further that what is and what is not implemented in Zombieverter firmware?

Yes you can make a derivative/branch of the Zombie code as you have done.

Damien will however not merge requests unless it can be fully verified by himself. The issue here is any change should not break anything else, which means alot of testing.

If you have the coding skills you change whatever you want, this is why its open source. The issue is once you have done this you are at the mercy of your own skills as its not possible for anyone to provide direct support.

We need to be careful not to list features that are "desires" or "opinions" that are not in the main branch as it will seed confusion and cause loads of hassle for Damien.

[J0hannes]

Damien will however not merge requests unless it can be fully verified by himself. The issue here is any change should not break anything else, which means alot of testing.

We need to be careful not to list features that are "desires" or "opinions" that are not in the main branch as it will seed confusion and cause loads of hassle for Damien.

Thanks for explaining this out as is is a really good point!

After I posted somewhere on this forum that I got Leaf LBC working in my fork, it didn't go unnoticed by me that there were questions in some threads which I somehow connected in my mind to my post.

At least I'll be more cautious in the future about what and how I post regarding my Zombie fork and the features I'm working on in my fork/branch.

[allard]

I understand the dilemma: on one hand you want an active community contributing to a project, on the other hand you want the project to be ultra stable, because mistakes might cause serious injuries.

Two things might be worth considering: 1. should not the whole project be covered with unit tests. And 2. It should in most cases be possible, if you fork from main, to rebase your changes based on changes to the original (let’s say Damien’s version). That will keep future (safety) changes being able to be incorporated in the fork.

[tom91]

Two things might be worth considering:
1. should not the whole project be covered with unit tests.
2. It should in most cases be possible, if you fork from main, to rebase your changes based on changes to the original (let’s say Damien’s version). That will keep future (safety) changes being able to be incorporated in the fork.

1. Yes this is very time consuming, this is why expanding on options/features/wishes needs alot of consideration.
2. Yes if you make changes it is your decision to maintain your own Fork, thus you are responsible for pulling any main branch changes into your own fork. Only certain changes will be considered merge-able into the main branch.

Key thing to remember Damien sells the hardware with main branch firmware that he has proven to work, this way when people have questions (yes there is the forum) they are things he himself has tested and verified.

[janosch]

1. should not the whole project be covered with unit tests.

In my VCU firmware stm32-taxi I followed a rigorous testing approach (Zombie wasn't ready yet when I started).
You will be able to see the code for that within this year I think. Some of that may be helpful for ZombieVerter.
I believe it is unrealistic to demand product-level unit test coverage from Damien (I know that is not what you did, just want to reiterate that point).
Therefore I may volunteer to sprinkle tests over the firmware that will help sanity check modifications in ZombieVerter if that is wanted by core contributors and likely to be a productive effort.