Reach

yungwunn & others: leave him to his work and stop asking to buy something that doesn't even exist, its obnoxious. We all want a turnkey touchscreen solution, but AC and some of the other guys here are among the few who have the know-how, time, and patience to try to put it together. Not just that, but he's giving us invaluable schematics and progress updates so we can follow along, and others could pick up the work if necessary.

Ac is being very nice by posting all of this (its his IP afterall) so lets all respect that and keep this topic to exactly what the topic says: hacking the IE bus.

yungwunn911

your completely right. Sorry!

angrycamel

I just wanted to make sure that I am not misleading anyone, so here is some clarification....


The schematic I recently posted is a result of me referencing schematics from 2 peoples existing boards (with encouragment and permission from them). Its not like there is anything terribly unique out the board however (its the firmware that's unique) but I don't want everyone thinking that what I posted was completely mine to claim. It is already freely available on the Internet from Marcin and others, including Louis who I had mentioned helped answer a couple of questions via email. My schematic is merely what I need out of their boards and its my take on how to set it all up. I am already thinking of ways that a final board will be much different, but this should work for testing.

If you remember, back on 6-28-2007, TrashCan posted a link to http://www.softservice.com.pl/corolla/avc/ipod.php
This was a huge leap forward for my research on this project since its apparent that the guy that runs that site (Marcin) was quite a bit further along than I was, with similar goals. It was definitely interesting to read through his research and have the holes in mine filled in at such a fast rate. There was a lot of, "Oh, I see. Why didn't I think of that!". So we are all working from where he has left off basically. I (we) want to do a bit more with the IEBus than he has ever felt the need to try, so in that sense there may be some IP (intellectual property) for what we do from this forward, but its only because I first stood on the shoulders of giants. At the end of the day, I would like to have everything that has been learned through this project freely available to anyone who would like to attempt it on their own from this thread, or condensed on my website. That's what others before me have done, and this project is better off because of it. It's only right that I should do the same.

If we do end up getting something working (and that's a HUGE IF at this point because so much is unknown), I may build some circuits to sell on EBay or something for those who do not want to make their own. Maybe a kit wouldn't be a bad idea for those who do want to try it, but would like instructions and all of the parts in one box. Lets cross that bridge once we find the river.

So, now we are all on the same page. Let's all hope that the UPS guy shows up soon and we can all continue to learn some more!!

Reach

That was the point I was trying to say, not-so-eloquently. Thank you angrycamel.

angrycamel

I just got home from work and the digikey parts I ordered were waiting diligently on my front doorstep. I am tearing into all of it now to start putting together the breadboard.

Unfortunately, I haven't recieved the programmer from SparkFun yet. So no ATMega8 programming tonight

I will update with pictures when I have something together.

angrycamel

I just finished putting together the breadboard and testing out the MAX232. However this is as far as I can go at the moment, until I get the programmer for the Mega8 in the mail.

I did play around with a loopback test on the MAX232. Thats fun I guess...

...I sure hope that programmer gets here tomorrow!


Until then, here are some pics to hold you over:

xdvd

How do you plan on displaying the video? Can you get VGA input or RGBS atleast?

Or are you planning on running an RCA video into the rearview camera input?

angrycamel

I am still mulling that one over, to be honest. I made a mistake when I ordered the motherboard and bought a Jetway (VIA C7) 1.5Ghz (J7F4K1G5D). That motherboard does not have a RCA video out port on the back, like the M10000 that I have. I assumed that it did without checking, and now I am kinda stuck with it, unless I can sell it and get something else. I had planned to use the RCA out to go into Dom's video converter.

I got the other M10000 as a gift over a year ago and had never powered it on. When I finally did (a couple of months ago), a few of the capacitors burst right away (google showed that this was common due to some shitty manifacturer of caps over seas). I ordered replacement caps and soldered them in, then when I powered it on, other caps burst! Its been a pain in the ass, and its sounding like I will have to replace all of them on the mobo, then pray that nothing else was ruined when I powered the board without good caps.

It would be nice to get something that could convert VGA directly to RGBs.




I made some corrections to the board, see if that looks more like what you would expect (see page 4). Remember I am new to electronics, so I am at the mercy of what I can learn from the google. Thanks for the help

mihooper

Thanks for the honesty... I'll try to dig into this during the weekend. I have a bit of experience in the area (mikeh@carnetix.com).

angrycamel

FYI, the RS232 is working fine.

angrycamel

The programmer for the ATMega8 arrived this afternoon, so I have been getting familiar with the its's programming procedures and installing the IDE's this evening. I must say, this thing is really fun and easy to work with. I can't believe I am only just now getting into working with IC's! This stuff is cool. I feel like a kid in a candy store; like I can make anything do anything now. Well maybe not anything, but world domination is coming soon, so look out Bill Gates, I am learning how to program IC's!

Seriously though, I have the (IC -> MAX232 -> PC -> MAX232 -> IC) circuit all setup. Its pretty damn cool to see it working and without much of a learning curve either. Well, a background in the C programming language doesn't hurt.

I will continue working on the circuit tomorrow, actually putting it in the car to start building the (Acura specific) IEBus message table (I hope I make it that far tomorrow). I will have to run and grab a PCI video card in order to get a video out port to go into dom's unit, or else I wont be able to see anything!

Wish me luck!

Here is a shot of the board as it is now (I reorganized it, and took some stuff out for now):

angrycamel

I'm having issues with the serial connection on my ATMega8. I cannot get it working properly. Using a simple program to output some text to serial doesn't work. The problem is not the connection because I can see text coming back in a terminal but its just not the text that I have it programmed to send.

No matter what, I always get this:
I followed a tutorial to setup a echo program on the Mega8, so that it would reply saying, "You typed: " then the key I hit. Just to test full i/o com, but that is returning those characters for every letter that I hit as well. I have tried multiple cables and methods of connecting the seial cable to my breadboard, all with the same results. The simple RS232 loopback by jumping pins 11 and 12 works fine, so I can only assume that the problem is in the Mega8.

Has anyone ever experienced this type of an issue with the ATMega8? Do I have something connected incorrectly?

Mega8 -> MAX232 (Pins)
2 -> 12
3 -> 14

MAX232 - > Serial (Pins)
14 -> 2
13 -> 3
GND -> 5

Thanks in advance,
AC

angrycamel

Never mind that last post. I got it working. I had forgotten to set the fuse bits on the ATMega8, doh!

Anyways, thats been working for while now, but I just have been taking some time tonight, while the house is quiet, to plan out the firmware a little better. I want to utilize interrupts, so its going to be a complete rewrite of the firmware that Marcin wrote. But his and Louis' is the best reference I could ask for.

I will post when I have more.

2002TLSNavi

Shhh.... If you keep talking like this the next sound you hear is going to be the crashing sound as the average salary for electrical engineers plummets. Repeat after me: "This is the most difficult endeavor I have ever attempted. It is going to take years to learn all of the mystical black arts of electronics"

But seriously, I'm glad you are making some good progress. If you get stuck and need any help, you know where to find me. I haven't completely lost interest in this project, I just haven't had much free time lately.

Good Luck

angrycamel

Haha. There is no way this could be a career move for me. I enjoy software side of engineering too much. However, I spend a lot fo my time writting RPG/ILE these days. I have to use my hobbies to find ways to program in something other than that.

I appreciate the offer, and I will. I just got through with a ton of housework. So now that I have a freshly cleaned office with no more dust-bunnies and all cables are zip tied and tucked neatly away, I should finally be able to start testing in the car. I went and bought a video card this morning for the carpc, so I anxious to get started.

Keep in touch!

angrycamel

...then how much is this worth?


Pictures and data log files will come tomorrow.

Reach

I just wish I had any knowledge that could help you! Keep up the amazing effort.

ITL

very impressive, AC. Very impressive.

2002TLSNavi

great work man....

Osmodious

So let me ask this...at this point, you are capturing the data streams from the various controls on the dash through the bus? That is wicked. Now, using this interface, you will also be able to capture the information from the touchscreen as well? So, your ultimate goal is to be able to use the various controls on the computer itself (like the volume knob and, perhaps the channel changer to select songs or something)? Wow, the nav joystick could be used for moving the mouse pointer/cursor and...there are a lot of possibilities here!

This is far beyond what I was originally thinking could be done. I was just looking for touchscreen input...but if the rest of the dash interface could be utilized, the customization possibilities are endless!

I thought your project was cool and useful...it is way, way more than that.

yungwunn911

that video..is the most badass video on the web right now.

angrycamel

You got it!

However, just being able to see the packets is not enough. I gotta figure out a way to keep the real system from seeing it too, or else you will touch a button on your PC but will also be touching something on the navigation system. Or maybe a better example is, you hit the channel up button on the dash while viewing your PC then that also changes the channel on your stock system. Just some things that I am trying to work out, along with generalizing the code base so that it not specific to a make or model vehicle.

Oh, and thanks to everyone else for the kind words! Great inspiration. Below are some of the pictures that I said I would post. I am going to wait on the data file until I finish putting together the final database. (It may take me a while to tie all packets with actual name-able events)

Osmodious

"I gotta figure out a way to keep the real system from seeing it too, or else you will touch a button on your PC but will also be touching something on the navigation system."

Good point, hadn't thought of that.

This is probably going to sound exceptionally stupid, but couldn't you do something as simple as cutting off the throughput from getting to the nav while the carputer interface is engaged? I don't know if that would also intercept signals to the other dash controls, but it's a start (actually, I can't imagine that EVERYthing is routed through the nav system in the trunk...especially considering many TSX's don't HAVE the nav unit). Still, for use of just the touchscreen, cutting off the signal from the nav unit while in carputer mode would suffice.

My guess is that something would have to be connected IN the dash area, which leads to a whole new world of complexity, I think. Then again, there's probably a way to control everything on the bus from one location...finding out the code(s) necessary to do this would be next to impossible. Wouldn't it be nice if one of the Honda engineers who worked on this system lurked on these boards an anonymously posted the info we need?

Anyway, back in the real world...I will stop my prattling, since I have nothing constructive to add. Wish I could help but I'm not a programmer or engineer, and if I had the proper equipment to make any attempts I'd probably manage to meltdown the whole car. Still, I would love to be a 'beta tester' when the time arrives (and can certainly help defray some costs for you as such). I'm actually pretty good at that, as my endless ability to break stuff comes in handy for such a task! For now, I'll just continue to cheerlead with everyone else...

2002TLSNavi

Unfortunately it is not that easy. The IEBus packets need to be ACKed by the intended receiver unit. So if the trunk unit was disconnected, the packets sent out by the touch screen to the trunk unit would not be ACKed. Which would probably cause them to be retransmitted multiple times until it gave up. I'm not sure what kind of error handling there is in the existing software and what it does in the event of a comm failure. So this may work, or it may cause the whole system to go nuts.

The "correct" solution is to build the following instead of a just the passive sniffer:

In NAV mode, the bus would be connected from display to trunk unit as normal. In "computer" mode, the interface hardware would have to break the connection between the two devices, and listen for packets addressed to the trunk unit. Upon reception it would have to acknowledge these. Now this assumes that the trunk unit does not initiate unsolicited communication with the display unit (perhaps for some sort of status information or something. If this is the case, you would also need to listen to that side of the bus and answer or at least acknowledge these transmissions as well.

Again, now knowing what kind of error handling is built in and how gracefully the existing hardware handles a comm failure, it's hard to say how much of the above is actually necessary.

Spoon

Is there really any other way for it to work as intended without creating a second bus? The angrycamel unit (ACU) takes the address of the trunk unit (TU) and the TU is removed from the existing bus. A secondary bus is created consisting of only the ACU and the TU. When in nav mode, all packets are simply relayed by the ACU between buses, otherwise, packets are grabbed and processed.

How else could the ACU be placed on the bus and not result in some sort of conflict?

angrycamel

You guys are on the right track. These are all things that I have considered when thinking this thing through, but without actually testing, I just don't know which will work and if any. I will be doing some more testing this weekend to pin down all issues and try to see what can be done in the ways of an IEBus "gateway".

Last night I resumed work on my app for the pc that processes the messages as the chip sends them back up the serial connection. Currently it is merely written to help me identify frames and associate them to an event then store that information in a database. I am keeping other makes and models in mind too while I write this (because codes will vary from vehicle to vehicle). What that means is, if you have a Toyota, Lexus, Acura, Honda... you could use the module, but first you would have to configure it for your car, and download a library of event definitions to plug into the driver. This would allow for the IEBus controller unit to be nothing but that, an abstract "IEBus Controller" unit. Meaning that its not an Acura specific item, rather any vehicle that utilizes the IEBus could make use of it to handle IEBus events on their pc, any which way they'd like. By going with separate library's for each make/model and writing the plugin architecture into the pc driver so that there is nothing hard coded in the chip, will allow for people to develop event libraries for specific make/models on their own. (obviously I don't own every car that utilizes the IEBus)

How would people develop event libraries, you say? (...but wait, there's more!)
In order to facilitate building the vehicle specific event libraries, I am writing an application that will run on a pc (idea being that its a pc installed in your car), recieving data from the IEBus controller module. You will have to set the module to "discovery mode", then follow along in the wizard. It will walk you through identifying common controls, such as volume, channel up and down, etc. You will have the ability (outside of the wizard) to identify custom events too. I imagine it working on a timer... you choose the "Identify Custom Event" then a window pops up that asks for you to choose the Master->Slave devices you wish to capture an event for. Next you would set a capture timer in seconds that you would like the program to attempt to identify for. Now for examples sake, lets say you are identifying the "Map/Guide" button in your Acura with navigation and you know that once you set the identify event process to start you can hit the map/guide button within the next 5 seconds, so you set the capture timer for 5 seconds then hit start. Now all you have to do is reach over and hit the map/guide button a few times until the timer runs out on the capture. It will then present you with a list of events that were captured before the timer ran up. It will take the one that showed up most often during the capture time (this is why you hit the button a few times) and put it at the top of the list of possible matches. If there are multiple events captured, you may be confused as to which of these messages actual happens when you hit the map/guide button, thats why you will be able to right click on events in that list and choose "test event". If your navi switches to the map/guide screen then you know you have identified it. You would then, make sure that the correct event is selected in the list of events, fill in a name/description of the event in the appropriate fields then hit store event. It will attempt to store the event in the library with the others and present an error if you are writing a duplicate.

ITL

i like the way you think

What's your physical connection to the bus? Did you simply splice into a couple of data lines? (+ and -)

angrycamel

I have connectors, so I made a PNP harness, but I made a mistake when I wired it (Doh!). So for that video, I simply had jammed some wire into the back of the stock connector then ran that to the breadboard. They are the two wires on the end of the 20 pin connector. If I remember correctly, its Blu/Red for (+) and Blu/Wht (-), but go back to page 5 and check the PDF's I made to be sure.

Geekeng

Ahh... the sweet smells while sniffing the IEBus indeed. I only recently started exploring the GA-NET II Bus and soon found NEC's IEBus, and now I've found you. Amongst a few others, who apparently have ceased their efforts, you have taken this project quite far. It seems we have the same goal in mind - so I admittedly will be using your R&D to bring me up to speed and hopefully allow for some constructive additions to an already great project.

I have a few UPD72042BGT-A's on the way as I was thinking exactly what you were, and now that I found you and your website, I shall be following closely along with my own efforts (feel free to check my nearly daily updates on my blog @ www.geekeng.com)

Thanks for all the work you've put in so far, happy to be on board.

Osmodious

Well, I guess this is going to be public, then...
Geekeng - tried to leave a comment on your blog but even after logging in it would not allow me to do so ('must be a team member to post comments'), and there was no link to send an email. Then tried to PM you here, but since you are a new member it won't allow me to. <sigh>

Anyway, here it is:

Another resource to check out might be the forums at mp3car.com. They have a lot of carputer types of installations, and there might be something to be gleaned from those (considering your uber-searching skills, since you found angrycamel at acurazine, you should find SOMEthing worthwhile!). I know that there's a guy on there who did a carputer in a similar model Honda Accord to yours...and there's someone who did a whole reengineering of the nav in his Acura TL (might be on Acurazine as well).

That's all I wanted to say...I don't have a link to the exact threads I mentioned, but I will search later on when I get home (I know I have them bookmarked, but was it in IE, Opera, Firefox or Camino? Hmmm.).

Geekeng

Osmodious, thanks for the comments. I have since updated my site to allow non-registered guests to add comments. So comment away!

As per your comment of mp3car.com -- I have been there and have read some of the info. Like I mentioned, I've only been at this for the better part of 4 days. I realize this project will likely take the better part of a year if done completely alone, but alas! I have found others who are on the same quest as I.... albeit some have been here alot longer than I... namely AC.

Just a side thought... the newer Honda/Acura's are now coming with navi's that support bluetooth and pioneer has a 6-disc in-dash MP3/WMA player. Seeing how all these systems operate on the IEBus architecture, wouldn't it be possible to strip oem components and mount them into another model/year? Assuming you have all the mounting equipment and the console/dash hardware to support a navi. ...

...I might have just solved my end of the quest ! LOL --- Or maybe not - the IEBus addresses are likely different/incompatible with each manufacturer / model / year.

My research continues... good thing they taught us reverse engineering skills to troubleshoot our non-working labs in school!

angrycamel

The IEBus protocol is nothing more than that, a protocol. Just because something else uses a compatible protocol, does not mean that the information it transmits will also be compatible. However it is highly likely that a setup from one year to the next in a similar model vehicle would be compatible.

Just some food for thought . I'm loving the enthusiasm!

"There is a lot more to speaking a language... to talk with the natives, you must also know some slang."

angrycamel

I have made a bit of progress on the sniffer console/library builder thingy that I am calling the IEBus StudioBridge. I am wondering if anyone else here knows C# and would like to give a hand at coding this thing?

Its not a question of CAN I keep working on it, but there are some subtle things about C# that I do not have as much experience with and I would like to spend more time on the firmware. Having both developed at the same time would speed up development significantly.

Below is a shot of what I have working now. The reason you see the same message over and over again is because I currently have the Mega8 programmed to send it in a loop for testing. There is a parsed tab for showing the translated version of the message by referencing the selected library (but there are no libs yet, so it isn't complete). Then there is also a tab for viewing the raw serial data as it comes in.

The message format coming out of the chip is like this:
If you really know that you can handle a program like this please let me know. If you don't think you will have the time or the know how, please do not offer, because it will most likely end up delaying things. I need someone who can take this and run with it and get a finished product quickly for it to be worth while.

Thanks in advance!

Geekeng

AC - I wouldn't mind taking a look at the program. I have to admit my programming skills are mainly ASM,C,C++ and Java, but I'm sure C# isn't far off.

Let me know what you need and I'll do my best to make it happen.

P.S. -- As I mentioned earlier, I have only recently started looking into this whole entertainment system hacking business. Keep in mind I'm still about 6 months away from dropping the cash for the navi system and components to start taking the hardware seriously. I figured starting early with r&d before running out and buying anything was a wise move. Hopefully I can help you out in some way until then.

angrycamel

I decided to go ahead and make the app open source under the GNU license and I have already created a project on sourceforge.net. They have a review process that only happens during business days, so it probly will not be out of "Pending Review" until early next week. However the project name there is "IEBus Studio".

As soon as they approve the project and I have access to upload the source files I will do so and then I will add anyone who is interested in working on the project to the project on sourceforge.

In the meantime, here is a copy of the sourcecode for anyone to review.

IEBus_Studio_src[a1.0].rar

Geekeng: C# is just like Java, pretty much. It has garbage collection.

Geekeng

I downloaded the source code. I should have some more questions/suggestions about the serial data stream format as I look deeper.

angrycamel

Sounds good. I have been working on the firmware all morning, so I am here. Just send me an email if you need to chat about it. Maybe we can get on a chat client too.

Geekeng

I've now emailed you. I would love to hear about what equipment you're using to program the ATMega8 and have a gander at your firmware source.

Any idea how many people are actually interested in our success with this?

angrycamel

Ya, I just replied to ya. I posted the schematic and a parts list back on page 5. Here is a direct link.

Seems like quite a few from the responses I have seen in this thread.

Geekeng

Thanks. I took a look and it seems to make logical sense.

What are you using to program your ATMega8?

Is this schematic a final revision? Or is there more modifications planned?

I may have a source for PCB fab for cheap/possibly fee if the circuitry is ready (I would ensure a ZIF or DIP socket was in place of the ATMega8 for easy removal and revisions. Another thought was the design of an enclosure for the circuit which would be a good thing to look at to ensure PCB component placement is where we want it before doing anything permanent.