YAPiP - recreating pEEf's approach

It looks like they're a distributor for Peak - so they do have all the dual channel stuff: PCAN Adapters | Grid Connect

If you're not using your CAN device now then yes, it would be a great addition to the arsenal. I'm kind of guessing your latest project vehicle doesn't have CAN .... (at least not yet)

This looks like the most cost effective option: CAN PC104 - PCAN-PC104 Adapter with 1 or 2 Channels | Grid Connect

Combined with something like this: Welcome To NEUTRONEXPRESS.COM

But then I'd spend a bunch of time getting all that to work together. I'll stick with the Atmel for now...

 

Yay! I have the SD Card working (just a simple test routine at the moment). I'll start writing some logging code next. Then some analysis code for the files produced.

I'll be hosting this on GitHub - so you'll be able to see the code then...

 

Thanks for the springs info. Most of the time I'll be solo-driving (now don't hate me - I also ride an electric super scooter for most of the summer and fall) or with my wife and kid (neither are big). I'll start off with no extra springs but probably end up adding them.

 

Yup & I appreciate it. I'll see how things go.

 

Status Update:
1) I've officially named her Pippy.
2) Battery pack is repaired and back on the road.

Details:
OK, I have Pippy back on the road. Changing the battery module wasn't too bad - and I doubt I did it in the most efficient manner (I took apart more than I needed to - but it was all a good learning experience). The biggest jigsaw puzzle was figuring out the ducting seeing as I hadn't labeled anything when I tore into her (typical me!).

However, once all back together she just sat there and said "Problem" on the MFD but didn't produce any fault codes...

Hmm. I tracked it down pretty quickly to the SMR not engaging (i.e. 220V on the battery side, 0V on the car side). Well this first one had me checking the service disconnect and trying to probe the connector to see if the "reed switch"(*) was closing. Futzed around with this for a while. Eventually I took it off the service disconnect assembly so that I could take a better look on the bench (it's awkward to get to on the car). Turns out what I thought was a switch within the socket is actually a set of extra contacts that are only engaged when the safety connect switch handle is slid down. Duh! I'd been closing the handle but forgetting that it then also slides down. That problem was solved.

* BTW, I'm sure I've seen that extra interconnect called a "reed switch". That's not what I think of as a reed switch (nor does google: reed switch - Google Search). That's what slowed me down because I thought the little white box at the end of the wire was the switch. It's not, it's an interconnect. Oh well.

Next I got two fault codes and no READY indicator (and hey, that felt like progress!). One which I forget the number of indicated a bad current sensor - but that cleared up itself and was probably due to the second one: AA4. I got to dig into the Prius service manual at this point. AA4 says SMR3 is stuck open or closed (depending on the sub info on that DTC - but my reader wasn't showing me sub-info). Wiggled the wires (always a good first test!) - still no go. Took out the relay hooked it up to a 12V battery on the bench - clunked close, clunked open. All looking good. Re-install SMR3.

Ta da! READY and no more MIL. I've been on a couple of drives yet and Pippy is now acting more like what I expect she's supposed to (remember that before she had a bad battery module and the SOC would yo-yo - well that meant pretty much zero battery only operation).

Having a normal baseline will make ongoing experiments much easier to interpret. I still plan on taking a friend's Prius for a drive and collecting data so that I can compare the operation of his car with mine.

Next up - time to log some CAN data and create some tools to analyze the log files.

 

OK - I've successfully started gathering timestamped data. At the moment it just logs the first 10,000 records (microsecond resolution timestamp + message id + message data).

10,000 records takes just over 13 seconds and results in 52 unique IDs. Ultimately I'll log all the data from each run of the car - if I have my math right I can store around 24 hours of data on a 1GB SD card.

Also, with the same math caveat, I think the bus is only being utilized at about 16% capacity (the bus baud rate is 500kbps and we're seeing around 81kbps of data).

That all seems plausible. So, now it's on with analyzing / understanding the data. And for that I'll create a couple of things:

1) A database of known IDs (from kinetic's excellent document: Decoding CAN messages 0x348 & 0x3C8 as described by pEEF | PriusChat). The database will map the ID to a description and to the necessary routines to decode the data payload.

2) Some visualization tools. Three views spring to mind: (a) a timeline to look at interactions between messages & (b) graphing appropriate time varying signals (RPM, volts, amps etc. etc.) & (c) something to help visualize shifting bit patterns in "flag fields".

That should keep me busy for a while...

Progress is progressing.

 

BIG DATA...

Well, not really, but that's a cool buzzword in the tech industry these days.

I have my logger working so that it captures every CAN message during a drive. Which means big files. So, now I'm working out how to make my analysis ideas work.

I'm getting there...

 

OK, as I dig into analysis of the data I think there are 7 PIDs of interest for this project.

These first two will be used when implementing a bECU that handles the larger pack

• 3CB - reports CCL, CCD, Delta SOC, SOC, Min & Max battery temps
• 3CD - reports battery DTCs & voltage

These next three will be used when implementing "ICE control" to allow high speed EV operation and to provide control over warmup operation. These are the 3 PIDs ** that pEEf refers to:

• 38 - originates from the hECU & contains control flags and torque and power info
• 348 - originates from the hECU & contains control flags and an engine speed request
• 3C8 - originates from the eECU & contains control flags indicating warmup request

These last two PIDs report information of interest to use in the algorithms above:

• 39 - engine temp
• 3B - current & voltage

Sorry if this post doesn't wow you with my amazing progress. I'm using these posts to record what I consider important pieces of information and also to document clarifications as I go. Of course, if someone sees something that is wrong or wrongheaded then please let me know!

It's progress. Of a sort.

** Note: I'll continue to research these 3 PIDs- but I'm not going to implement anything until I have the large pack handling completed. That means not only the software for the bECU but also the purchase and installation of a large pack. And that might take a while... (what with me being just a tad over-committed...)

 

That's not a bad idea. In fact it's a very good idea. And I never follow good advice...

Actually, I have a fair amount of experience with batteries, BMS's and chargers. I'm going to go with GBS 40Ah cells. I'm not too worried about smoking the batteries. I'm more worried about the control algorithms hurting the ICE, MGs or inverter...

Plus I should be able to get the GBS's at the wholesale price

Attached is my first attempt at a proposed layout.

The cells are 208mm tall. The connections are recessed and covered by a plastic cover so I don't have to add any height for cables. My rough and ready measurements of the Prius trunk space shows that I have about 150mm to 180mm of depth. So, I'll end up raising the floor of the trunk by about 3 cm. I can live with that.

The charger has a CAN interface which I'll use in conjunction with the BMS outputs to control the charging profile.

I imagine two battery boxes - one of which will be on gas-struts so it can hinge upwards to allow access to the spare tire. Or, I might recess some cells in the tire well and put the spare tire on top of them. We'll see...

But I will have to save up my pennies for a while for that pack.

 

WAIT UP!

If I have my math right the pouch cells result in a pack with about half the volume of the GBS cells. Yes, I did take into account that they're 20Ah pouches. 44 liters for the raw pouches vs. 84 liters for the "fully packaged" GBS cells. Even if I add 10% volume with packaging then it's still about a 40% space saving. I'd no idea the pouch cells were quite so compact. However, higher density also probably means they run hotter.

Dang, now I'll have to think about pouches again...