No, I don't like the DC-DC, too much hardware, not enough energy. That is sweet! But I'm targeting 8-10kwh, which means I'll need 40Ah, I'm thinking I'll split the 4-pack into two 40ah each. That means I now only need to add 43-40ah cells, where I would have needed ~60 before. Now onto the fun stuff, how do I build a battery management and PHEV filtering pass-through ECU?
I use notepad++ Use Notepad++ As HEX Editor with Plugin Download (Free WinHEX Alternative) « My Digital Life
You can buy the battery packs from Enginer Enginer | Prius Plugin PHEV Conversion Kit with Lithium-Ion | Hybrid for US900 each for LHS or RHS battery pack, 32 cells in each LHS or RHS battery pack works out to US28.15 for each cell. Then reconfigure the cells. Build your own battery box to fill I would use existing reconfigured battery pack boxes (16S2P) 51.2v x 4 and just add your own built battery box housing 6S2P 19.2v. All five battery boxes would connect in series via Anderson connectors. It would not look so bad. The RFE cells have a lower nominal voltage of 3.2v compared to 3.3v for the A123 cells so your fifth battery box should be 8S2P. This would give you an overall voltage of 230.2Vdc. I think that a lot of Enginer users would be very interested in doing your conversion and would like to see pictures. I would go as far as starting a new thread on the Enginer forum - How to turn your low performance Enginer kit into a real PHEV kit. I think that Jack would be spitting chips. May do this myself one day when my Converters are beyond repair.
Nice thinking, a matched set is a good idea. Casing might be bulky and I need to insulate. But it is nice. I'll thinki about it. It's a good price.
On the hardware side, what about two CAN modules, one making the decisions and controlling what engine messages flow on to the second proxy? PIC18F2682-I/SP - Microchip- PIC18F2682ISP- datasheet It has three 10-bit ADCs to measure the current, temperature and voltage. From this we can make a SoC decision and we can process other messages like throttle position. Are there any actual projects for this?
I have an update, but this thread seems to be dying... I might re-post to a new thread. I've done a ton of research and the most complete, simple dual-CAN capable package is the duinomite-mega. $40! It's based on a powerful PIC32 controller with two CAN ports, one is ready to rock on the board, the second is driven with a simple CAN transceiver shield (needs a MCP2551, cap + resistor). The break-out CON4 P0 & P1 are the C2TX and C2RX respectively. It also happens to have a VGA driver and USB for keyboard; you can program right on the device! ?!? What could possibly go wrong !?! As for the logic... I re-read the old messages and I think I have it pretty well figured out. I'm ready to place my order and start the project. I've attached a high-level logical diagram for the design.
Once your program decides to start the ICE you need to simulate 0348 warm up request (if ICE temperature is <45degC) which was previously blocked. If you do start your project please start a new thread like jhd2550 who has his own thread for his project. A PHEV board with a VGA output would be handy so you could see the difference between the original 0348 message and the modified whilst driving. A touch screen would be good. A 800ah battery pack is a bit big. You can adjust your throttle limit according to AH remaining in your battery pack.
I was just looking at the Duinomite Mega manual http://www.olimex.com/dev/DUINO/DUINOMITE/DuinoMite-UM-1-03.pdf , It has a high level language program I could use MM Basic but it does not presently support CAN. Not sure if it could keep up the CAN traffic speed of 500Mbs.
They've added support for CAN to the basic language http://www.olimex.com/dev/DUINO/DUINOMITE/MMBasic_CAN_commands.pdf
During my drive to work with the ICE enabled (data file attached) I have recorded 1609 spurts of canbus messages for 0348. Just looking at the flag bytes for 0348 (x1609 - total number of occurrances ) 04, 60......(x819) most common when ICE is running with acceleration 04, 62........(x104) second most common when ICE is running without acceleration. (ICE idling request) 04, 70........(x18) heavy acceleration or heavy foot on the gas pedal. 0C, 60........(x41) Regenerative braking (ICE HV battery charge request) 04, 21........(x36) transition to EV/Stealth mode just before 00,21 or/and 00,01 00, 21........(x28) EV/Stealth just before 00,01 (no ICE request) 00, 01........(x545) EV/Stealth mode (No ICE request) 00, 42.........(x4) transition from EV/Stealth mode to ICE run 04, 40.......(x8) transition from EV/Stealth mode to ICE run 04, 42.......(x7) transition from EV/Stealth mode to ICE run I have found the following EV/stealth mode to ICE run transitions: 00, 01 > 00, 42 > 04, 60 00, 01 > 04, 42 > 04, 60 00, 01 > 00, 42 > 0C, 60 > 04, 60 00, 01 > 04, 40 > 04, 60 00, 01 > 04, 60 00, 01 > 0c, 60 00, 01 > 04, 70 I have found the following ICE run to EV/Stealth mode transitions: 04, 60 > 04, 21 > 00, 21 > 00, 01 04, 62 > 04, 21 > 00, 21 > 00, 01 04, 60 > 04, 21 > 00, 01 Using Hexworkshop program it was easy to colour map each individual 0348 flag and count function for each flag variation. By colour mapping it was easy to see the transitions. So far I have found Hexworkshop is the best program for this application. I have attached a zipped file of the Canbus serial data. Also attached is a file of the color mapping for the 0348 can bus flag variations. It automatically colour maps each flag type for 0348 when you load the file into Hexworkshop.
That's great data! Not dinging that in any way, but I'm planning to directly pass all Hybrid ECU messages once I'm out of electricity, does it matter? ie, the H-ECU does the talking.
We won't really know until somebody actually does this project. It could be a race between you and JHD to find out for sure. Or you could ask pEEF via PM.
I have been observing the x03c8 Canbus message. The second data byte varies between 34(hex) and 28(hex). It correlates with the ICE temperature x0039. The value decreases as the ICE temperature rises. X03c8...x0039...DegC 28.......44.......68degC 29.......43.......67degC 2a.......43.......67degC 2b.......42......,66degC 2c.......42.......66degC 2d.......42.......66degC 2e.......41.......65degC 2f........41......65degC 30.......41.......65degC 31.......40.......64degC 32.......40.......64degC 33.......3F.......63degC 34.......3F.......63degC After the initial ICE warm up stage I noticed that my ECT spoofer caused the value of 34 to jump directly to 28. Then I switched off my ECT spoofer and it did not got go back to 34 unless the ICE started. Once the ICE started it jumped from 28 to 34. It seems that a value of 28 allows stealth mode. Just looking at the 03c8 flag bytes (x1610 total) 00, 28.......... (x832) Most common 00, 34.......... (x408) 04, 34.......... (x48) 04, 28.......... (x7) 06, 34.......... (x143) 00, 29.......... (x46) 00, 2A.......... (x65) 00, 2B.......... (x14) 00, 2C.......... (x13) 00, 2d.......... (x12) 00, 2e.......... (x8) 00, 2f.......... (x4) 00, 30......... (x3) 00, 31......... (x0) 00, 32......... (x3) 00, 33......... (x4)
The value of 28 hex (x03c8) is not the ICE temperature (x0039). It is inverted. It correlates to a ICE temperature of 68degC or higher. If you can spoof the ICE temperature to 68degC Or higher by using a ECT spoofer then you can get Stealth after the initial warmup. As usual you can fall out of Stealth for other reasons such as pressing too hard on the gas pedal. This is what a ECT spoofer does at this thread A Prius ECT Spoofer MCU Controlled | PriusChat
I've been on vacation in the UK - visiting the folks. I'm back now! Wow - that does seem like a great find. Tell me more about the tool chain... Spoken like a true tinkerer! (before they've passed through the valley of death) Is "PHEV ECU" your ECU? And is "PHEV ECU" a replacement for the "Battery ECU"? I'm assuming yes to both of those. I don't think option 2 will work. You'll end up "doubling up" your messages to the ECU - it will receive both the Hybrid ECU and the PHEV ECU messages. I think you need to split the bus. Also, I'm not sure option 2 is "much" simpler than option 1. Your logic is essentially the same in both cases and passing traffic from one bus to another should be relatively straightforward (another one of those optimistic comments that will come back to haunt us! ). The wiring is simpler though... Am I missing something? Do you have reason to believe that option 2 won't just confuse the Engine ECU with conflicting messages? BTW - this is a great post and a great summary. I'll stick with my dev board for now. But when I get it working I might redo it over with the board you suggest. That VGA output would be great for driving a secondary display - although I hope to look into hacking the existing MFD to display extra info (like BMS+ does). If I can't hack the MFD successfully then I might look at creating an MFD replacement. (That's another "tinkerer" issue I have - as well as simplifying the task at hand I get distracted by future ideas as well!) p.s. I plan on doing my conversion in two steps: (1) a "standard" PHEV conversion - just replacing the battery pack and not enabling high-speed (2) a "high speed" conversion. However, you already have step (1) installed, right?
That's 500kbps - 500 kilo bits per second. Not mega bits. However, I've no idea about MMBasic - is it compiled or interpreted? If interpreted then it's a question of the efficiency of the interpreter - not necessarily an issue but something to be aware of. Is there an MMBasic forum to post questions on?
Not a race but a collaboration - pushing two ideas forward at the same time. If you do PM and hear back from pEEf be sure to share! (I've stopped bugging him now).
This is great! Thank you very much. I'll download Hexworkshop - a data visualization tool is definitely what I need and I might incorporate that idea into my own stuff. One of the things I did on vacation was work on graphing the CAN data that I've acquired.
