Simp BMS

[Ctwidle]

Thanks Tom, will the new version be subject to the same parts issue or does it use different components?

[tom91]

Thanks Tom, will the new version be subject to the same parts issue or does it use different components?

It has a different micro controller which also has a reduced availability but I have a large stock built up already.

[RGr]

(Tesla) Shunt requires isolated comms, and people have had it working. However this is not compatible with the SimpBMS.
Also be careful the OE Tesla Contactors are none economised thus need a diode and be setup as per SimpBMS usermanual.

Hello,
thinking on integrating Tesla shunt with simpBMS.
Tom, what do you mean by "Shunt requires isolated comms"? SPI isolation + isolated dc/dc converter to power the shunt? (btw is the VCC 5V?)
Or other option probably possible is to separate/isolate the whole simpBMS at CAN bus, but then you also need separate/isolated 12V power for all slave BMUs as well.

[tom91]

Hello,
thinking on integrating Tesla shunt with simpBMS.
Tom, what do you mean by "Shunt requires isolated comms"? SPI isolation + isolated dc/dc converter to power the shunt? (btw is the VCC 5V?)
Or other option probably possible is to separate/isolate the whole simpBMS at CAN bus, but then you also need separate/isolated 12V power for all slave BMUs as well.

As in anything connected to the shunt is referenced to its negative battery connection. So you need to isolate anything coming from the shunt. So yes VCC, 5V I believe and SPI comms.

https://github.com/Tom-evnut/Tesla-Current-Shunt

Since it is SPI this wont directly work on the standard SimpBMS hardware so you would need to create your own variant to deal with this.

[7yatna]

Karim, Thank you for pointing this out a coding error slipped in. I was calling for the wrong canbus message structure in this version. rxBuf instead of inMsg.buf

Will check and update all versions where required.

Hi Tom,

Sorry to keep taunting you with code errors.

I think i found another slip in the code. The IVT-S current sensor still not working.

Sorry it took me a while to verify the fix, im now fully buttoning up the car, i was away for a while since july, (out of the country, New Job, LIfe )

so i did flash the new Update that meant for fixing the can messages structure, still no dice from the can sensor, it reads ZERO.

before i dug into the code today, i verified that the sensor is spitting out the correct values, i hoked up the sensor alone to DUE can and indeed all the current values are coming out correctly, SO HW is OK.

I through lunch today at work i followed the code to understand how the current is calculated.

here is your fix where the can message is stored into CANmilliamps
then we jump into getCurrent(); function.

in this function CANmilliamps isnt used at all,

looking at previous and history revision, CANmilliamps should be shifted to RawCur then averaging and all the magic happen then the code proceed to caurrentact which the value is being reported everywhere.

so i think there is a step missing between the CANmiiliamp value and Currentact value.

i tried to make the code like historcally it was by adding

RawCur = CANmilliamps;

right after it gets is from the can value,

the reported current work but it was in the 1000 multiples so i reverted back and now im stuck.

appreciate your help. i try to resolve the coding before bugging you and hopefully reporting back with success but im out of ideas on this one.

i did actually find another issue and fixed it, plus added a balancing indicator in the screen.

i will post those updates when i finalize the work here.

thanks, Karim

[tom91]

RawCur = CANmilliamps;

Thank you for responding to this.

I have added this and cleaned the code some more, one thing to note the current sensor is running as "stock" I have not coded any of it.

Code: Select all

          CANmilliamps = (long)((inMsg.buf[2] << 24) | (inMsg.buf[3] << 16) | (inMsg.buf[4] << 8) | (inMsg.buf[5]));
          RawCur = CANmilliamps;

I have verified this now with a IVT-s shunt I recently aquired.

[7yatna]

Thank you for responding to this.

I have added this and cleaned the code some more, one thing to note the current sensor is running as "stock" I have not coded any of it.

Code: Select all

          CANmilliamps = (long)((inMsg.buf[2] << 24) | (inMsg.buf[3] << 16) | (inMsg.buf[4] << 8) | (inMsg.buf[5]));
          RawCur = CANmilliamps;

I have verified this now with a IVT-s shunt I recently aquired.

Hi Tom,

thanks for your support as usual and very fast replies,

I will try this update and hopefully get it going, I`m not following the point of a stock current sensor?

I'm using a current sensor( Stock and animalized as the IVT-S initialize code on open inverter wiki)

pretty sure we are set now,

thanks again and i will report back.

Karim

[7yatna]

Hi tom,

Unfortunately the current garbage values still exist.

I added the couple of lines to my code and the problem still presisted,

then i decided to flash the hex file you uploaded yesterday to make sure it isnt my code and issue still there.

check the pictures i took from the debug.

that's the current sensor reporting on canbus, the current is really zero no flow going through it.

and this is the current debug and shows way big or garbage data.

i think RawCur and getcurrent functions are the trouble here,

will look at the code and hopefully i can catch the issue.

best,
Karim

[tom91]

check the pictures i took from the debug.

The standard broadcasting is defined the user manual for the shunt. so you need to see 0x521 for current.
I bench tested it, so the problem is on your end.

So if you do not see 0x521 on the canbus it wont work.

[7yatna]

The standard broadcasting is defined the user manual for the shunt. so you need to see 0x521 for current.
I bench tested it, so the problem is on your end.

image.png

So if you do not see 0x521 on the canbus it wont work.

Hi tom,

Yes i agree and that's the very first thing i verified since last July when the problem started, and of course this week when the problem persist.

so if you see my attached picture sorry i didn't highlight the 0x521 but it is in the middle to lower end line but here it is highlighted in this one

the current sensor is reporting 0x521 all the way to 0x528 and is working fine. as well if i disconnect the current sensor from the network the garbage values stops.

meaning the 0x521 id is contributing to the issue.

i agree the problem might be on my end, but the current sensor and can network and 0x521 is out of the picture.


sorry to pick your brain on that. i will debug code and see where the problem might be.

Karim

[tom91]

Garbage probably due to you having set the byte value in reverse so its little endian as byte 2 contains something.

The standard message is Big Endian.

[7yatna]

Garbage probably due to you having set the byte value in reverse so its little endian as byte 2 contains something.

The standard message is Big Endian.

that what i actually was thinking. little vs big, i didn't intentionally do so but i will figure a way to reverse it

so after all it is my current sensor being a square ??

haha sorry tom. will spend sometime reversing that then report back. need now to figure it out.

[7yatna]

that what i actually was thinking. little vs big, i didn't intentionally do so but i will figure a way to reverse it

so after all it is my current sensor being a square ??

haha sorry tom. will spend sometime reversing that then report back. need now to figure it out.

Hiya Tom,

so here how i initialized that IVT-S Sensor,

I followed this wiki here on openinverter,

https://openinverter.org/wiki/Isabellen ... te_Heusler

and i got the correct Values as expected,

unless the libraries got updated and somehow the fix meant for addressing the little endian problem associated with arduino.

my senbsor is now configures as little endian ? if so is there away to tweak the in.msg buffer to get the correct information from the sensor without reinitializing,

have no idea how to reinitialize the sensor if this sketch is broken.

im trying this format hopefully it will work.

Code: Select all

CANmilliamps = inMsg.buf[0] + (inMsg.buf[1] << 8) + (inMsg.buf[2] << 16) + (inMsg.buf[3] << 24);

instead of

Code: Select all

CANmilliamps = inMsg.buf[5] + (inMsg.buf[4] << 8) + (inMsg.buf[3] << 16) + (inMsg.buf[2] << 24);

thanks again tom, im very excited as this is the very final stages of getting the car driving.

[tom91]

so here how i initialized that IVT-S Sensor,

im trying this format hopefully it will work.

Please insert the (long)(.....) back as it keeps it formatted right and you do not get errors with the signed value.

I must say I never initialised it I just ran it as it came. Have done so on all ones I used so far.

[7yatna]

Please insert the (long)(.....) back as it keeps it formatted right and you do not get errors with the signed value.

I must say I never initialised it I just ran it as it came. Have done so on all ones I used so far.

Ok, Yes i`m aware of the long type.

that was me being writing and copying quickly.

ok at least we know it is an little, vs Big endian problem.

will take turns at it and see how it turns out.

thanks tom.

[Layer8]

Hi and thank you for the great work!

Would it somehow be feasible to use SimpBMS with a BMW i3 battery in HV config as it comes and emulate e.g. a BYD battery towards some HV battery capable hybrid pv inverter? I could think of either using the second CAN board or maybe even modbus tcp...
I read through the i3 code and I feel it should be doable but maybe something similar is already planned?
Thank you!

[tom91]

emulate e.g. a BYD battery towards some HV battery capable hybrid pv inverter? I could think of either using the second CAN board or maybe even modbus tcp..

I can do this if someone provides the fully required canbus data to emulate a byd battery.

[Layer8]

I can do this if someone provides the fully required canbus data to emulate a byd battery.

Hey Tom,
BYD was just a shoot into the blue - there might be easier-to-emulate batteries out there, which are widely supported by the inverters...
Maybe Pylontech would be easier? If I we find either, you would be willing to put it into the code?
Have a great weekend!

[tom91]

Maybe Pylontech would be easier? If I we find either, you would be willing to put it into the code?

Again any provided information can be implemented.

[Layer8]

Hi!
As it is very hard to buy teensy 3.2 boards, are there any plans to support more available ones, e.g. esp32 based?
Does the current code unter https://github.com/Tom-evnut/BMWI3BMS run on teensy 4.1 boards?
Thank you!!

[tom91]

No it does not feel free to port it over like others have.

I have created a new product using the Teensy 4.0, this is no longer open source.

[7yatna]

Please insert the (long)(.....) back as it keeps it formatted right and you do not get errors with the signed value.

I must say I never initialised it I just ran it as it came. Have done so on all ones I used so far.

Hi Tom,
wanted to report back that indeed it was a little endian vs Big endian issue. i confirmed it by looking at the script code i used to initialize the IVT-S Sensor it was reading back in little endian.

so after adjusting the SimpBMS to little endian, All is good and i have fully working system.

over the weekend i did the first full charge cycle on the pack. current is reporting Ok both ways, Balancing is active and with my little modified code it can report on the screen if it is balancing or not.

if you remember my pack is

3 Parallels BMW 530e Packs each has its own current sensor, SimpBMS, Contactor boxes and fuses.

the main SImpBMS is configured to read the main current sensor so it is reporting capacity and discharge as total

the other two packs are only reporting their own data.

it is working OK except one of my packs that uses analog sensor is not calibrating the offset correctly. so SOC current info based isnt accurate.

do you think it is good idea to make SOC as strictly voltage based ?

well thanks again for supporting my crazy idea for the longest time i will report back with some pictures.

[tom91]

do you think it is good idea to make SOC as strictly voltage based ?

Yes voltaged based SOC is the "cleanest" way of doing it, with analogue sensors. I have purposely not supported analogue sensors in my new products.

Best to do is tune it a bit when the vehicle drives, but does the "main" SimpBMS not use the IVT shunt and just do all the current tracking in and out for the full setup? Or have you wired it as 3 seperate packs?

How are they wired? 3 parallel strings or is it 3 packs that are put in series?

[7yatna]

Yes voltage based SOC is the "cleanest" way of doing it, with analogue sensors. I have purposely not supported analogue sensors in my new products.

Best to do is tune it a bit when the vehicle drives, but does the "main" SimpBMS not use the IVT shunt and just do all the current tracking in and out for the full setup? Or have you wired it as 3 separate packs?

How are they wired? 3 parallel strings or is it 3 packs that are put in series?

Exactly as you said,

the Main SImp BMS is using the IVT-s and tracking everything in and out. that main Simpbms has battery settings of 3 times the pack capacity so the current calculations reflect on total battery capacity.
the way it is setup:

3 Packs of 740e in parallel

each pack is 9.15kwh and 96 cells

one main Simp that iVT-S is connected to and tracking the current but only monitoring and balancing the 96 cells of that pack.

two other simps with analog sensors, and each simp is monitoring and balancing each of the other two packs.

in other words the secondary simps are only to monitor the cells, balance them, and close the contactors when they drive or charge. current sensors are irrelevant but it will be nice seeing something, they have their own screens too to show me info. these secondary have the battery settings as a single 9.15 pack.

the main one only is the one with settings of 3 time each pack and it has a screen on my dashboard to show me the current going in and out, percentage and things,

there will be only about a 1or 2 volt difference between the main packs from being un connected as a group. but i dont think this is an issue, as soon i close all the contactors ( about 7 different contactors) all the packs connects in parallels and right a way have the same voltage.

no crazy current rush seen so far, just something like a spike of 1-3 amps moving from high voltage to lower

will try to make a diagram for how they are connected.

thanks tom,

i will update the settings for voltage based SOC

[Ctwidle]

I just had an aborted attempt to buy a BMW pack from the UK but the seller didn’t realise the complexity of international freight for lithium and eventually the best he could come up with was a port to port shipment for an additional £2000.
Local sources of secondhand packs are at best sketchy and all I have been able to find readily available are 94Ah cells. From my reading SimpBMS (and its successor) seem to have been designed around reusing OEM BMS systems, can it be configured to handle a pack of 96s cells?