My version of Li-ion modules for Toyota/Prius NiMH

I have copied and pasted the posts from the other thread into this thread so that everything is together.

 

Seems like high energy density like lithium-ion equals more safety issues not less? Maybe you're saying its a more reliable high energy density for this application? But in terms of a fire that destroys the car I always thought the higher the energy density the greater the risk?

 

So we're yo get one?? I'll run the shiet out of it.

 

This is a false equivalency. NiMH's end of charge behavior is drastically different from lithium. Specifically, NiMH cells can 'perpetually' turn excess charge energy into heat, whereas lithium cells cannot.

We aren't criticizing you, we're advising you that safety issues exist with your product as described (which I will do in more detail below).

Many LiFePO4 ('LFP') cells can handle more than 2C.

While I agree NexPower's V1 through V2.x cells were undersized for traction batteries, they could probably still handle at least 20C.
I certainly agree with you that NexPower used their LFP cells beyond the manufacturer's specified C rating.

Right, which is why NexPower created a 2xBlade (i.e. the width of two OEM blades). This allows a 5S LFP 2xBlade to approximate two 6S NiMH blades.

The bigger issue with LFP is its REALLY flat midband voltage curve (e.g. from 30% to 70% SoC). This makes it difficult to estimate Voc->SoC.

I agree LFP cells don't tolerate overvoltage very well.
But this is also true for ALL lithium chemistries (including LFP, LCO, NMC, LTO, LiS, etc).
In fact, of the commercialized lithium chemistries, LFP tolerates overcharging 'the best' (but still not well).

The short answer here is that all lithium chemistries are damaged by overvoltage. That's why a per-cell BMS is absolutely critical for safety in lithium systems.

I don't think NexPower exceeded the LFP cell's rated charge/discharge by 5x.
In my estimate, they were more like 1.5x. Your point still stands, though.

If your only design goal is 'cheap', then I suppose little effort was spent on 'safe'?
A lithium pack without a BMS is not going to age well.
I recently worked with another company who defended their lithium product's lack of BMS by saying "it will last at least until the warranty expires"... their warranty period was just one year. Yikes!

Which specific cell make and model are you using? Or what specific chemistry is it? Note that your answer is irrelevant because ALL lithium cells require a BMS when sold as products to consumers. However, knowing your cell chemistry will at least let me advise you on exactly how dangerous what you're doing is.

OK, but what happens when a cell fails and the OEM BMS doesn't catch it until the cell goes into thermal runaway? This is the exact issue I harped on for months with NexPower's lack of BMS.

IIRC, Toyotas can easily pull 150 amps.
In my reverse engineering, I note that the OEM current sensor in a Gen3 Prius can measure up to 205 amps of assist. Seems odd that Toyota would go through the additional engineering effort to measure 205 amps if they only ever pull 100 amps (as you claim).
I am not a Toyota person, so I leave the actual current values to those who know in this community.

This is only the case when the cells are new, and even then it's not guaranteed. That's why you need a per-cell BMS with supervisory control.

While a well-made battery doesn't require high current balancing, per-cell balancing is absolutely required to handle cell aging/heating/etc. Typically you only need C/100 passive balancing on a well made pack.

I don't understand your statement. Please elaborate.

It would also make your product safe (if properly implemented).

You haven't convinced me that your lithium pack is safe without a BMS.
A properly designed BMS is required for safety on all lithium batteries sold to consumers.

No, this isn't the case. "Testing for months" isn't long enough. Think about your customers ten years from now. What's going to happen when those cells degrade at different rates for a decade? The OEM NiMH BMS will only alert the driver when a 1.2 volt delta is measured. Please watch this video I made last month for a better explanation, including example scenarios the NiMH BMS won't catch:

Please post the datasheet so I can explain how you are misinterpreting what they're saying.
NMC lithium cells will absolutely go into thermal runaway if you overcharge them.

Please send me your cell and I will record a video of it going into thermal runaway. I have all the test equipment to do this safely.

Sorry science infuriates you...
...as I said at the onset, we are trying to educate you as to why your product is unsafe as described.

 

It's for EU not for the so called "new world." And I'd love to see proof that EU certified this product for sale. I mean why not a link to buy if OP isn't lying about EU certification?

 

Well at least if it catches on fire it's in the back of the car and I'm way in the front all these electrics burning the batteries go the length of floor pan. Open the windows pull over get out take fone and video

 

@Vencedor, any thoughts/response to the concerns I outlined on Friday? Maybe you don't work weekends?

 

"Regarding the danger of not having a balance, a well-made battery doesn't need any kind of balancing"



I'm buying a bunch of Apple MBPro batteries and hook them up in series and get rid of my GREAT
Newer Technolgy Sodium ION battery and use the older lithium Apple batteries!!!

It will be cheaper, lighter, and smaller!

 

Right behind the driver, with the back seat materials to add to the resulting cabin fire. Not a good scenario.

 

If you outline your BMS strategy before designing it, I'll let you know if your plan is unsafe. Unfortunately, I'd need to look at the finished product to determine whether it's safe... but I can certainly tell you beforehand if something is unsafe. My goal here is to prevent you from wasting your time designing something you think is safe, but isn't.

 

That's great to hear... Would love to support that! If we had an affordable open-source BMS with an app that would allow us to read/write code there would be almost no limits to what kind of aftermarket battery packs we could use. Of course I bet Toyota has lots of authentication pitfalls buried in their source code that are going to light up the dash board in warning lights in confounding ways... Honda is way friendlier to hacks and spoofs than Toyota is.

 

Yes, that makes sense at first... But if you're successful there could be some really interesting additional opportunities at a later date.

 

Without communicating with the car, how do you intend to tell the OEM Toyota computer to stop charging/discharging a too full/empty pack?
Relying on your customer to stay in the safe operating area is a recipe for disaster.

My LiBSU PCB will be mechanically identical to the existing BSU, but won't contain an onboard BMS. Instead, it will have multiple open source serial protocols with reference open source hardware/firmware designs, thus allowing anyone to bring their own battery and/or BMS. I will probably also sell an open source plug-and-play BMS for DIY crew, which will essentially be page2 in my existing LiBCM schematic (albeit with serialized isoSPI, rather than my existing single parallel isoSPI bus).

My goal with LiBSU is to allow 3rd party lithium battery companies to use my LiBSU product to make their products safe. In a parallel universe, even NexPower would use LiBSU... but I'm not sure Jack would ever get onboard. One of the latest BMS-less lithium blade products I recently found has an external 0.1" header with per-cell voltage taps... which makes it compatible with LiBSU.

I don't intend to design an app for LiBSU, but it will have a USB serial interface for data logging, etc. I already have this feature on my LiBCM project; LiBSU's implementation will be nearly identical. Team Jack may laugh that I use Arduino, but I find that laughable because their offering is a blank sheet of paper. It's like the kid who didn't do his homework laughing at my bad handwriting. I don't mind using crayons when the alternative is throwing caution to the wind.

Toyota doesn't encrypt or authenticate anything I've looked at, which (probably) includes every NiMH vehicle they've designed including and after the Gen3 Prius. The earlier BSU CAN-based serial streams also don't appear encrypted/authenticated, but I haven't researched them as much (yet).

However, you are correct that Toyota's serial stream is more complicated than Honda's. This is because Honda's BCM (same as Toyota's BSU) abstracts the data from the 'main' hybrid computer, whereas Toyota's BSU simply measures and relays tons of data to the main hybrid computer.

For example, Honda's BCM only report's the overall pack state (e.g. "wants charge", "doesn't want charge", "wants assist", etc); whereas Toyota's BSU relays every single blade voltage, temperature sensor, etc, to the main computer, which must then process all that data itself (e.g. to calculate blade ESR, pack SoC, etc). Honda's implementation gives its BMS agency to decide what the pack wants, whereas Toyota's implementation is similar to a micromanaging overlord that wants every single detail.

Fortunately, I've deciphered the entire RS485 protocol used on Gen3+ Toyota hybrids. My implementation only uses ~400 lines of code to generate the QTY384 byte serial data stream. I've actually spent the past couple weeks working on my LiBSU product for Toyota. I even bought a Prius last week ...meh... I prefer the Honda Insight, but obviously I need a Toyota mule to test the firmware.

For my prototype, I've already installed my existing 10.4 kWh Honda Insight battery into the Toyota's spare tire well. With a custom tray, I suspect you could fit these QTY5 2.07 kWh modules in the same volume and location as the existing NiMH pack (i.e. not in the spare tire well). We've come a long way since Hymotion's design 15+ years ago.

Assuming I finish up my firmware MVP over the next few days (crosses fingers), I intend to show off the prototype sometime next week in a video titled "Mudder Doesn't Even Own a Prius". Ideally the firmware will work the first time I test it in the car, but that's probably not going to happen... we'll see. Stay tuned.

 

Thanks for clarifying your research... I need more time to process this info above tomorrow...

But for starters, why have Honda mods been so successful at the race track for decades, with even first hacked Jpeg posted on a Honda car screen around about 2001being celebrated in the NYtimes and piggy back chips controlling engine ECU have been available for Honda near just as long so you can have a laptop running your ECU mods when racing/testing at the track?

Meanwhile Toyota mods like these seem to be near non-existent? Do you have any links that can help us better understand why its not as easy with Toyota? Seems like true to your self-described "Honda-Boy" view of the world you've haven't logged many hours trying to modify and spoof Toyota signals to prevent warning lights and hybrid system shut down?

And granted, I've spent less than single digit hours on developing these skills but I'd love to help everyone better understand why Honda is way more popular than Toyota when is comes to ECU hacking, mods and spoofs?