Separate names with a comma.
Discussion in 'Prius PHEV Plug-In Modifications' started by jdh2550, May 23, 2012.
OK, I have my dev board talking to the ODB2 port - woot! Now, it's "just software"...
Are you just using the OBDII port for analyzing data? Right. Can you intercept Canframes through the ObDII port. I did not think that is possible. The AVR board would have to be electrically connected between the HV ECU and the ECM to intercept the required Canbus frames.
For now I'm just using the OBD2 port for monitoring traffic at this point. All traffic is visible on that port (and on every port on a CAN bus). Later on is when I'll break the bus into two parts (putting the eECU on it's own bus and my new bECU+ will bridge between the existing bus and this new secondary bus.
Separating the bus will go something like this:
- unplug old bECU (located by the old pack)
- disconnect old bECU CAN wires from Junction Connector 1 (J/C1) - not sure if this is necessary, but it doesn't seem a good idea to have a long, unused flying lead remaining on the CAN bus
- disconnect ECM (Toyota calls it the ECM - I call it the eECU) CAN signals from J/C2. Connect bECU+ CAN port 1 to J/C2 in place of the ECM CAN signals.
- connect ECM to CAN port 2 on the bECU+
Rather than disconnecting individual pins from these connectors it might be better to plug the bECU+ in where the old bECU is - but then I'd need to run CAN signals from there to the ECM (for the secondary bus). I'll cross that bridge when I come to it (that's still a ways away yet).
Next up is to start writing monitoring software to help interpret those messages. I'll start off with a one port monitor on the OBD2 port. At some point I will also create a 2 port monitor to allow isolating each ECU from the bus this will help identify who is sending out particular messages (on the CAN bus there's no concept of sender and receiver - it's a "message oriented" protocol rather than an "address oriented one). I might not need to do a 2 port monitor (with pass through) because pEEf has already indicated the source and consumer. We'll see...
Onwards and upwards...
Looks like it's coming along well. I might be interested in some of those NiMH cells at some point.
Well, this prompted me to google "prius battery teardown" which got me to here: Prius battery exploration
I've seen "hobbit" mentioned a couple of times on these forums - and his site is sure to be a treasure trove. He has an interesting take on various PHEV systems about halfway through this write up.
Now lunch break is over and it's back to the salt mines for me!
I started a thread today to see if there is enough interest in a group buy of A123 20ah prismatic pouch cells.
Is there interest in a group buy of A123 20ah prismatic pouch cells? | PriusChat
I posted it in the Gen II Prius Modifications/Prius PHEV Plug-In Modifications section.
Progress on the CAN software. I've coded up a simple framework for a UI that supports a set of pages that you access by swiping left and right and I've implemented two pages (1) CAN status - shows message and error counts; (2) decoding message 3CD. There's a common header that shows total message count and total error count. Here's a pic of the 3CD page:
I started with a known message (per this page: Prius PHEV TechInfo - EAA-PHEV) - just so I could check my results. I don't think I'm decoding the Fault Code quite right (I think I have my bit mask wrong - if so, an easy fix).
1) Add pages for all the messages of interest.
2) Add data logging to the SD card (this dev board has everything *and* the kitchen sink!)
BTW - I wanted to use the capacitive buttons but couldn't get them working, whereas the touchscreen worked pretty much first time. Unfortunately, as you can see in the pictures, I have really icky fingers!
This the Atmel eval? I am impressed
That is so cool! A touch screen on the AVR PCB. I definitely would need to wear my reading glasses to read it. It looks like it is about 50mm x 50mm LCD screen judging by the two DB9 serial plugs above it.
Nah, I was sure it was bigger than that. So I measured it. Dang, your good! ~50 mm wide x ~40mm high.
Yup, it's time to dig out the glasses! ;-)
BTW, the "final solution" of the bECU+ probably won't use the touchscreen at all - it's just convenient for the development process.
For the final bECU+ unit I'm thinking that I'll layout a board (or have my brother do it? hint, hint) with just the components I need on it.* That way the dev kit will be available for future projects. The UI for the final solution will likely involve pre-existing Toyota buttons for input and graphical output on a smartphone or tablet. The communication between the bECU+ and the outside world will be, of course, CAN. I'll add my own unique messages to the bus (hey, that's what it's there for). To go from CAN to the phone or tablet I'll either use a bluetooth ODB2 dongle or I'll create a CAN to WiFi link. The advantage of getting a CAN/WiFi dongle working is that if I can make that device act as a webserver then *any* device that has wi-fi and a browser will be able to act as the GUI. On the flip side if I have a bluetooth connection it will basically be a serial stream and have to have software for each device that I want as a head unit.
I'm a big fan of using HTML/Javasacript for the GUI because (a) it opens up a wide range of devices & (b) it allows for easy customization of the GUI & (c) it enforces a good separation between software layers. Downside is (a) performance of the UI & (b) graphical capability of the UI (in other words native UIs always look slicker and perform better than web based ones).
But, that's getting WAY ahead of things. For now, I'm still watching CAN messages come in with my "poor imitation" of a scan tool! ;-)
* p.s. with careful design we could make a general purpose "CAN hacking tool" - I'm thinking of basically a different layout of the dev board with a few less devices and a more compact form factor. Imagine a smartphone sized device held in landscape mode. A DB-9 on each side (OK, it's fatter than a smartphone!) and the screen on the front. Standard software would be to use it as a scan tool. Advanced software would use it as a pass through device / sniffer. However, we'd also also expose the JTAG connector and provide software libraries so others could reprogram it. The careful design comes in with the ability to make a version with no screen (to reduce cost and increase robustness) by simply not populating some of the same board and having a different case. This "no-screen" version would be the bECU+ module.
SWAG** of $150 without screen and $200 with screen for a modest profit. Those prices are for a "hacker device" - no support and a minimal warranty that guarantees the device is not dead on arrival. To turn it into a more complete tool to attract a professional audience one would likely double or triple those costs. It would still be a very cool tool - and there's plenty of $1000+ CAN solutions out there today.
**SWAG = Silly wild nice person guess. So I could easily be off by 100% or more! However, there really ain't that many components required (there's an awful lot on that dev board that we don't use) - the main issue is the stuffing the boards. At a minimum that micro needs to be machine placed - perhaps a lot of the other stuff could be through-hole components? Also, if one wanted to get serious about it then you'd look at scaling down that processor to one that's "right sized" for the task.
What do you think? Would folks find something like a "CAN hacking tool" useful?
OK, now I have to come back down to earth - and back to working on the YAPiP! (This always happens - I start on a new project and my mind goes in several different directions as I think of the possibilities. Must focus on completion. Must focus on completion. Must focus on completion...)
Hold on. Just one project at a time. However it would be handy to have a device that connects into the OBDIi plug and would send a Canbus message to activate your AVR board so ECM spoofing can be activated/deactivated. My Canview V4 does this with my BMSplus or SoC spoofer.
How long did you have to wait to get Atmel then where did you get the custom obd cable hookup??I am really envious of that setup...
Both hardware parts are standard order:
- Atmel Store / Atmel AT32UC3C-EK
- Cable, J1962M to Open End, 3ft. w/ Strain Relief - OBD II Cables - Cables - OBD2Cables.com
(there are different length cables).
- I had a breadboard ready female DB-9 socket, and a breadboard. Then it was just a question of duct tape!
The software to make the dev board into a simple CAN monitor is my creation. Happy to share - but it's not packaged in an easy to distribute form as yet. So, if you were to order the above parts you can't do anything useful without adding software. But, if you do want to go ahead and play along then you'll also need an appropriate programmer:
- Atmel Store / Atmel AVRISP mkII In-System Programmer
- Atmel Store / Atmel AVR Dragon
The first one is just a programmer. The second one is a debugger as well - which is what I have (a debugger is useful if you're developing the software, but not required if you're just programming the chip with a hex file).
Finally, you'll also need a development environment to compile code and/or to program the chip. Atmel's AVR Studio 6 is a free download:
Atmel® Studio6 - Two Architectures, One Studio - Overview
Again, it's important to remember that if you buy all this stuff there's still work for you to do before getting it all hooked up and working...
Sounds like a good project. The compile code you mentioned, are you talking about assembly language? If so this requires a good knowledge of what is in the AVR board at the processor level. I did assembly language programming at TAFE a very long time ago. Can you provide us with updates of your latest code by uploading a zipped file of the code. I may buy one these AVR boards and try out your software programs. Thanks.
The source code is C. I'm using Atmel's ASF framework (which comes with the AVR. Studio.
Rather than post a zip file I'll create a repository for the source code. Either at github or using my own SVN server. That way I get to keep a backup and you'll always have access to the latest code.
OK. What ever you do please supply us with a short cut to the code when it is available. The highest level of programming I did was turbo pascal. Programming C was the next step up. Maybe I should start reading up on C. Your simple existing program for just looking at a CANbus message could be a good learning aid as a starting point. I will see. I have got a feeling it is all going to be way over my head.
So you need to instal the Gateway, that allows to separate the CAN in different CAN branches. Right Gateway permits to filter the CAN frames between two CAN branches and permits to change the CAN frame identifier from a branch to the other.
Will this do the trick?
This approach creates two "CAN branches" (actually I think two separate CAN buses is more correct). The second bus (which I'm calling the secondary bus) will just contain the ECM and the battery ECU+. The main bus contains everything it did before except the ECM and the original battery ECU (which is replaced by my battery ECU which I'm calling bECU+).
So, my bECU+ is acting as the Gateway that you describe. I prefer to use the term Bridge as this minimizes the confusion as there's a "Gateway ECU" - but that's acting as a bridge between the CAN bus and other vehicle networks.
The physical connections will take place at J/C2 which is in the passenger foot well. There are two of these connection points where all the CAN devices are electrically connected onto one bus (the other is J/C1 and is in the driver foot well). In other words the J/C1 and J/C2 tie all the CAN High wires together and all the CAN Low wires together.
At least I *think* that's how the physical connections work...
p.s. there's a before and after diagram attached to this post: YAPiP - recreating pEEf's approach | Page 2 | PriusChat
I'm having trouble getting the SD Card and FAT file system up and running on the dev board. This means I can't log data on the board itself. I'll keep trying for a couple more days - but if I don't get any luck then I might just stream the data out on the USB port and log on a separate computer. I really want the dev board to be a standalone system though...
In the meantime I decided to take the battery pack out of the Prius and see if I can find the problem. The disassembly and pack removal were very straight forward. The bugger is heavy but it's an OK one man job. I didn't bother taking the rear seats out as there's enough room to remove the front side bolts. 2 to 3 hours later and the pack is now sitting on my bench and it's cell 25 that is showing a low voltage.
I know all the caveats about replacing just one module - but seeing as I only want a couple of months more life out of this pack (hopefully!) I decided to just order a module off of ebay. I figured it was worth a $35 experiment anyway. Cell should turn up later this week.
So with the Prius out of action I won't be doing any in-vehicle experiments this week. That should give me time to get the dev board SD card situation figured out and also do some more research and thinking about the install.
I met Jack Chen briefly this weekend at the MI EAA show (owner of Enginer). I may well use a pack from him - I haven't decided yet.
I've been slammed with work so haven't made any progress on debugging the SD Card setup. But while surfing today I came across these guys: CAN interfaces : Product Listing: PEAK-System
A possible approach for prototyping would be to use one of their dual-channel devices plugged into a PC and that way I could work in a high level development environment which would result in quicker development. However, I'm not sure if I could rely on the timing in the same way as I can with the Atmel dev board.
I think I'll continue with the Atmel for now - but if it becomes too frustrating I may look at one of the Peak System devices.