YAPiP - recreating pEEf's approach

GBS cells are rated at 2C continuous. The 100A is the sustained rate at >60mph. Most of my driving will be around town. If the batteries do puke then I'll have learned something

BTW, Every GBS we've tested so far has had a larger than nominal capacity. Also, I'd rather keep a simple pack topology rather than parallel up a bunch of smaller cells. I'm lazy...

Here's a couple of diagrams (based on that document that lopez referenced). Figure 1 shows the original setup and Figure 2 shows how it will look when I'm done.

View attachment BeforeAndAfter.pdf

 

I'm replacing the battery ECU not the hybrid ECU. The former is a relatively simple device with just a few message of interest wherea the latter is the heart of the system and very complex. (BTW, I made the exact same mistake when talking to pEEf)

The development board, is just that - a board for prototyping with. It won't make for an ultra reiabe system. However the Atmel chips are auotmotive grade and are top quality.

You make a good point about reliability - however, I think the real issue is "failure mode" not "reliability". One could argue that this approach should be more reliable than the contactor method because it's less intrusive and there are less parts - hence less failure points. However if it fails there is a chance that the failure would be worse than a contactor design (although one would have to do FMEA on a specific design to know for sure). To be "picky" you wouldn't be "dead in the water" as in "stranded". You should be able to limp home on ICE power only.

Using the stock setup with a large LiFePO4 pack would be a non-starter. All Toyota's algorithms are based on the specific NiMH pack that they install.

However, it will actually be easier to put this system back to stock than a contactor system. Siply unplug the new bECU and plug in the old one. Unplug the new large pack and plug in the old NiMH pack (OK - you'd either have to keep that pack conditioned or source another pack.)

Obviously all of the above is just my opinion. It would be interesting to hear from the designer of a contacor systems - the trouble is most of those folks are commercial enterprises. So, they're likely even more biased than I am ;-)

 

Step zero is complete - sitting in my driveway is an '05 Prius. I'm just back from driving out to VA, trading in the Focus and driving back in the Prius. Ah, the things we do for "love" ;-)

I got a high mileage car with a dying pack. 200K miles but she still drives really smoothly and rattle free. The MFD is showing the "issue with the hybrid system" icon - but seeing as the motors work (and hence the inverter) and that the battery level yo-yo's up and down I'm guessing it's just the signs of a dying pack (no capacity left). On the drive home it actually got to the stage where MG2 just gives up and shuts down. Cycling the power (and being a bit more gentle on the pack) gets things going again.

She's also "cosmetically challenged" - but structurally sound. I'm thinking I'm going to do a vehicle wrap when I'm done. That will hide the exterior blemishes. Not quite sure what to do about the interior :-(

There are also some other issues. However, I paid well beow market rate and the less I spend on the car the more I have for the conversion components...

Oh, and the AVR dev board came in today as well. Hopefully I can get some sort of CAN equivalent of "Hello World" up and running this weekend...

 

Hi cgates,

Your math seems about right to me. Personally I'd use 250 wh/mile. Although top speed around town is lower there is more stop start and accels are where you see peak draw. Also, I'd choose 72 not 70 as that will match me and pEEf. I don't know whether it's best to do 72SP2 or P272S (i.e. either connect two 72 series strings together or connect 72 blocks of paralleled cells together). I've not seen a discussion on that - but I suspect that the latter (72 blocks) is better as that's what I've more commonly seen.

Your BOM looks about right (see mine earlier in this thread). You'll probably need a little more like 750 for the charger - unless you have something in mind?

The one thing I haven't sourced or priced yet is upgraded springs for the rear shocks. This shouldn't be strictly necessary (because driver + pack is still within rated carrying capacity) but is recommended.

Check out the PDF I posted for a break down of the modules and what my new architecture will look like. Also look at the document that lopez linked too (which is where I got the diagram).

As far as commitment goes - I'm doing this entirely as an open-source for-fun-not-profit project. No commitments from me as to whether it will work or not and certainly no commitment for any particular deliverable. I have a lot on my plate with the day job - but I love this stuff and I've been wanting to do it for while and I now have everything I need. If you want to follow along that's great - but if you need me to finish first before you can complete your project then I strongly suggest you wait until I have something fully working. At any point along the way there's a chance I'll have to put it on hold due to other commitments.

 

Ah. Sorry I misunderstood. Yep I agree with you 100% . Reader beware!

 

Hmm I'd never thought of it quite like that. That might very well make for the ultimate EV. Very cool.

Yet another reason for YAPiP... so I better get the darn thing working...

 

Project Status update: I have the toolchain set up and I can compile apps. I've managed to set the CAN baudrate to 500kbps and I can get my standalone dev board talking to a PC controlled dev board. However, I can't get my dev board talking to the OBD2 connector on the Prius. I'm making some progress - things will go quicker when I get this basic communication working.

Meanwhile I hooked up a scantool and can confirm that the traction battery pack is bad. IT's throwing two DTCs - one for excessive voltage difference between modules and another reporting that module #13 is bad.

I am planning on completely removing the NiMH pack - I want thist to be as electrically / mechanically simple as possible. Swap out the NiMH pack and bECU and swap in a LiFePO4 pack and new bECU. It's not really a question of which is "best" - it's that this is the goal I've set myself.

Onwards and upwards...

 

Hmmm - not sure I like this new board. I just edited the above post but didn't provide an edit reason and it seems to have eaten all my changes... Oh well here goes again (in a separate post this time...)

Some clarifications:

The two DTC's being thrown are:

Code:

P0a80 - The difference in voltage between 2 of the blocks in the battery pack is too high 
P3023 - block 13 is bad

To clarify the design a bit more.

• I'm using a dev board (development board) with two separate CAN ports.
• The dev board will entirely replace the existing battery ECU (bECU). To do this it will be responsible for transmitting the existing PIDs that report battery status. It will be connected via the existing connector on the main CAN bus. It will keep track of battery status (amp draw, pack voltage, state of charge, temperature).
• I will also unplug the engine ECU (eECU) from the MAIN can bus and plug it into the second port of the dev board. This will mean that the eECU is now on it's own SECONDARY can bus. The dev board will act as a bridge between the MAIN bus and the SECONDARY bus.
• For normal operation it will simply pass through all traffic between the two buses unmolested.
• For EV only mode it will intercept messages where the hybrid ECU (hECU) is requesting engine power on the MAIN bus and replace them on the SECONDARY bus with requests to spin the engine but with no power. The engine speeds required will be related to the requirements to keep the MGs within operating range. In EV only mode it will also intercept messages requesting engine warmup. EV mode is what pEEf implemented.
• For PHEV mode (i.e. a mode that works more like a Chevy Volt) algorithms will blend EV only mode and normal operation. The decision between EV and normal mode will mostly involve engine load and throttle position. I may well implement a simple look-up based approach to achieve this (i.e. a calibration map for those familiar with such terminology). I believe this is what pEEf was intending to do but either he didn't get around to it or he didn't post much about it.
• The difference between "normal" and "PHEV" is that the PHEV algorithms will take more advantage of electrical energy because it knows it has a bigger pack and it knows that we can safely achieve higher electric only speeds.
• In PHEV mode one tricky thing will be what to do with engine warmup requests - because one doesn't want to demand power from a cold engine. Alternative approaches:
  • "manual warmup": Warmup is commanded by the driver. Pros: Suitable for an initial "development system" - I think this is what pEEf implemented. Cons: but it runs the risk of abusing the engine. Usage Scenario: when the driver knows he's about to exceed range or acceleration he presses a button to tell the engine to warmup.
  • "fixed warmup": Warmup follows standard Prius behavior as soon as PHEV mode is selected - and only allow selecting PHEV at the start of the journey. Pros: Toyota has already solved the issue of how best to handle warmup in this situation. Cons: not as flexible as I'd like it to be. Usage Scenario: When the driver starts the car he chooses between EV only knowing his journey doesn't involve freeways and is within EV only range or PHEV if he expects freeway driving or longer range.
  • "intelligent warmup". I've no detailed ideas yet on how to implement this scheme - but basically the system needs to be predictive and warmup the engine before demanding power from the engine. A lot of this intelligence will have to be based on what performance is possible in EV only mode. In the following I'll use speed as a proxy for load (but it needs to be load based not speed based). If I were to determine that EV only gives adequate throttle response in all cases below 60mph then I could inhibit warmup until I see a speed of 50mph. However, a more sophisticated system might also take into account actual acceleration and/or commanded acceleration. Pros: If it works then it makes PHEV the dominant mode - "set it and forget it". EV only mode would still have use for drivers who know exactly when they want to use electric only. Cons: If I don't get the algorithms right then I'll abuse the engine.

Action plan:
1) Get CAN communication between dev board and Prius working
2) Use dev board as a CAN message logger to build up my knowledge of the messages first hand. I also want to build up more knowledge about ICE, MG1 & MG2 interaction.
3) Implement a bECU replacement working with existing pack
4) Replace pack with a pluggable 9kWh LiFePO4 pack and update bECU code to handle larger pack
5) Separate eECU onto separate bus but with all traffic a straight pass through
6) Implement EV only mode
7) Implement PHEV mode with manual or fixed warmup
8) Implement "Intelligent warmup"
9) Rejoice.

Progress:
Started work on step one on 5/26. Currently have dev board connecting to a known good CAN system at 500kbps. However, it's not yet communicating with Prius.

Next Step:
Hook up the known good CAN source to the Prius OBD2 connector. This will confirm connection parameters and isolate the problem in the dev board (either hardware or more likely the software)

So, I've a long ways to go yet. But that's fine - I'm more interested in the learning and doing than the using (otherwise I'd purchase an Enginer or PIS kit -- or I'd buy pEEf's car).

In the meantime - does anyone know how the standard Prius handles warmup? Does anyone know how Volt handles warmup?

Thanks.