YAPiP - recreating pEEf's approach

OK, I have my dev board talking to the ODB2 port - woot! Now, it's "just software"...

 

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...

 

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!

 

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).

Next steps:
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!

 

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...)

 

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:

EITHER:
-
Atmel Store / Atmel AVRISP mkII In-System Programmer

OR:
-
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...

 

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.

 

Correct.

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

 

Status Update:

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.