Re: [eaa-phev] HV battery ECU operation when car is off
Chris Ewert
> Hi Chris, can you elaborate at all on what you are using to monitor
> the phev pack batteries? Thats an interesting result, that some
> batteries are getting down as low as 8V. I was concerned that could be
> the case. I wouldn't be surprised if thats really taking its toll on
> the cycle life of the packs, particularly if they are not being
> balanced when charging. I still like the idea of using isolated 12v
> chargers to get a free balance while charging, but a battery monitor
> becomes pretty important as you really don't want to set off for a
> days EVing only to find that one of the twenty batteries didn't charge
> fully for one reason or another. I was originally just thinking about
> a simple uC with a voltage and temp sensor setup to talk to the EVIL
> bus on the CAN-View.
The "monitor" I'm using is a prototype of a BMS Andrew and I have been
working on for the FreeBMS project. It's 1 microcontroller per battery
communicating on an optically isolated bus (similar to EVIL, but
different.) Each BMS module (1 module per battery) has a small shunt
resistor as well, which is used to bring the batteries into balance at
the top end. It isn't perfected by any means, but it is functional - at
least enough to be logging data and rough balancing.
http://www.pluginproject.com/img/BMS_day.jpg
http://www.pluginproject.com/img/BMS_night.jpg
What I am discovering is that the batteries are reasonably well balanced
at the top end - not perfect, but close enough. The root problem seems
to the the differing "capacities" of the batteries. At pack "discharge"
(where the aggregate voltage of the pack pretty much matches the OEM
battery's voltage), the weak ones get pulled way down (I've actually
seen as low as < 5v under full acceleration in EV mode.) I even had a
particularly weak battery reversing polarity on me. So no wonder packs
are failing! What I'm seeing (and is to be expected) is that those
batteries that get pulled way down are then badly out of balance at the
top end in the next cycle, which I believe is causing the problem to
"spread" to other batteries since the aggregate voltage of the pack is
lower and the charger will then overcharge the remaining batteries.
(however, if the pack is cycled only half way for example they seem to
stay in balance much better.) All that makes perfect sense, but
presents a problem for keeping the pack in parallel with the OEM battery
at the low end. So what I think I'm going to do is setup the BMS like
Toyota did in the Prius to just be concerned about protecting the pack,
to publish a CCL, DCL, amp draw/charge and SOC and relay that
information along with a state of charge to the CAN control board, so
the CAN control board will stop using the PHEV pack when it would harm
the pack.
>
> Any hopes of in future being able to keep both the SOC spoofing board
> and the CAN-View on at the same time, and get the real (not spoofed)
> SOC to show up in CAN-View? Maybe it would be as simple as just
> rebroadcasting the real SOC onto one of the unused IDs Davide was
> proposing using for phev data a while back? If that ID is received,
> the CAN view would know that SOC spoofing must be in use and to
> disregard the oem SOC value.
I think there are 2 easy ways to do this - either CAN-View can just
differentiate between the high SOC and the lower SOC since both are
still on the CAN bus (the CAN control board algorithm never spoofs a
lower SOC - as a safety check to prevent accidental overcharging.)
Alternatively, and the more proper route would be to use Davide's
standard for reporting the real SOC and have CAN-View (and any other
viewers) monitor the new address. Ideally, it would also listen for the
SOC of the PHEV pack from a PHEV pack BMS. But either way, Norm would
have to release a software update for CAN-View in order to make CAN-View
compatible. Any 3rd party or open source CAN data viewer can also pull
the real and spoofed SOC - Andy just posted about the project he is
working on.
Chris