angrycamel.com

There's a crack in the interweb

IEBus Studio – In Car DLL Tests

Well I finally made it into the car today to do some tests with the first DLL that was produced by IEBus Studio. The test went great and it seems like we are definitely on the right track. I put together a video of my test today if you want to check it out below:

The testDLL application in the video consists of very little actual code to do what you are seeing there. It is a simple VB.Net application that references the DLL exported from IEBus Studio for my 2004 Acura TSX.
Thanks to CLuis for putting this together!

Here is the DLL as viewed in the VS.Net object browser. The only event we had defined at the time of building this DLL was the touchscreen event:
DLL Object Browser

I have pasted the code below to show just how simple it really is:

Public Class Form1
   	Dim WithEvents Acura As New Acura.TSX_2004()
   
   	Public Delegate Sub SetTextDelegate(ByVal text As String)
   	Dim sText As New SetTextDelegate(AddressOf SetText)
  
   	Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
   		For Each strPort As String In My.Computer.Ports.SerialPortNames
   			Ports.Items.Add(strPort)
   		Next
   	End Sub
  
   	Sub SetText(ByVal text As String)
   		Output.Text &= text
   		Output.ScrollToCaret()
   		Output.Focus()
   	End Sub
  
   	Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
   		Acura.OpenPort(Ports.Text, 9600, 8, IO.Ports.Parity.None, IO.Ports.StopBits.One, IO.Ports.Handshake.None)
   	End Sub
   
   	Private Sub Acura_TouchScreenPress(ByVal Master As Acura.TSX_2004.CarDevice, ByVal Slave As Acura.TSX_2004.CarDevice, ByVal X As Integer, ByVal Y As Integer, ByVal Unknown1 As Integer) Handles Acura.TouchScreenPress
   		If Output.InvokeRequired Then
   			Output.Invoke(sText, "TouchScreenPress: X:" & X & ", Y:" & Y & ", Unknown:" & Unknown1 & Environment.NewLine)
   		Else
   			SetText("TouchScreenPress: X:" & X & ", Y:" & Y & ", Unknown:" & Unknown1 & Environment.NewLine)
   		End If
   	End Sub
   End Class

IEBus Studio – Progress Update

IEBus Studio is coming along very well with the help of my two friends CLuis and Ramzi. We are really cranking code out at an astonishing rate and bringing IEBus Studio into reality. Here is the 1000 foot view:

Event Discovery works but we are just beginning to rewrite a lot of it to add functionality that will discover dynamic message types such as volume or touch events (Ex: most of the message is the same structure except for the coordinates of the touch, so we need to use some pattern matching to define non unique messages as the same event)

Defining devices is a cinch with the new Device Discovery tab. You can manually add devices or have it automatically add them to the library when it sees a message with a new unique device come across the bus. For each device you can record a name and description for it.

In the Define Events tab you can easily describe events that you have identified. Currently this only supports static messages such as a single button press on the dash (Ex: the cancel button), but it will soon support the dynamic messages as well.

CLuis did a great job with the DLL generation code. You can now build the library of events then choose File->”Export DLL” to produce a DLL of event definitions which you can tie into from any software that allows the referencing of a DLL. A test application has been setup and works in the emulation environment, so I will be testing it in the car very soon. The only events that the test DLL contains at the moment is touch events from the screen. This sample application will handle the touch events and display the x and y coordinates in a console as you touch the screen. Soon it will graphically overlay the screen with a grid to show how this whole thing will eventually control your computer.

And last but not least, you can now save out your progress into a library of events and device definitions (xml file) and open it back up again later to resume your work where you left off. If you thought you had all of the events that you wanted to use in your installation defined but realized you needed one more, simply open the library file do event discovery for that new event then re-export your DLL. Thats all there is to it.


IEBus Emulator

Tonight I put together a screen cap of me using the new IEBus Emulator in conjunction with com0com and IEBus Studio. Com0com is used to produce a virtual null modem connection as well as the virtual com ports from com2->com4. With the emulator we can test IEBus Studio locally with data captured to log files from inside of the car or with manually typed in commands.

It’s the first thing I did when I got back from my trip, here it is:


The new IEBus firmware is working!

I just got to a stopping point on the firmware tonight and decided to grab some data off the bus for review. You can check it out here if you want. You will notice a lot less errors. Its because my firmware is lighter and seems to run considerably faster. I think the reason for the errors you saw in the video before was because of the firmware was not processing the packets fast enough to keep up with the bus.

Also, this is what we are looking at for the structure of the lib files. (for defined devices and events per vehicle) This is the filetype that you will be able to open and work with in IEBus Studio. Pretty simple, right!

<vehicle>
  <make>Acura</make>
  <model>TSX</model>
  <year>2004</year>
  <navigation>yes</navigation>
</vehicle>
<device>
  <address>0x183</address>
  <name>Navigation Computer</name>
  <description>Navigation computer mounted in the trunk of the car.</description>
</device>
<device>
  <address>0x131</address>
  <name>Touchscreen Controller</name>
  <description>Touchscreen controller for sending touch events from the navigation screen in the dashboard to the navigation unit in the trunk.</description>
</device>
<device>
  <address>0x100</address>
  <name>Head Unit</name>
  <description>The head unit send commands like the volume up or down as well as changing the channel on the radio.</description>
</device>
<event>
	<name>Volume Level 3</name>
  <raw>1:100:183:F:14:60:2:31:0:2:0:3:10:0:E0:20:0:0:9D</raw>
  <broadcast>1</broadcast>
  <master_device>0x100</master_device>
  <slave_device>0x183</slave_device>
  <control>0xF</control>
  <datasize>0xE</datasize>
  <data>0x60</data>
  <data>0x2</data>
  <data>0x31</data>
  <data>0x0</data>
  <data>0x2</data>
  <data>0x0</data>
  <data>0x3</data>
  <data>0x10</data>
  <data>0x0</data>
  <data>0xE0</data>
  <data>0x20</data>
  <data>0x0</data>
  <data>0x0</data>
  <data>0x9D</data>
</event>

IEBus Studio is now on SourceForge.net

The project request on SourceForge.net was approved and we now have the project page. You can view the project status and get regular updates about it here.

A couple old friends of mine have signed up to help with development of the app and have already started making pretty good progress. I have worked with these two a lot in the past since they were the two that helped make Mimesis a reality. (there is a link to the Mimesis website in my signature, in case anyone is interested as well as a good writeup about it on my site)

Now back to IEBus Studio… we will soon have the ability to export a DLL from a device/event library defined within IEBus Studio. This means that, as described in an earlier post, you will use IEBus Studio to discover events and devices by watching the data pass over the bus, then storing the identified events in a vehicle specific library file as you go. Once you have defined all of the events for your vehicle, you will have the ability to then export those events out as a custom built DLL. The reason we are going with a DLL is because it allows for event handlers to be built into any language that you can plug the DLL into. In addition, the DLL will come fully equipped with an intellisense file which contains descriptions for all events and devices defined in the DLL. This is very handy for you to reference when building your event handlers.

The firmware is coming along nicely as well. It is taking packets, forming them into easily digestible blocks and sending them up to the PC so that IEBus Studio can handle them in any way that you want. I have written the code which allows for you to send down Master and Slave filters from IEBus Studio when in discovery mode. This will mean faster identification of events so that you can store them to the vehicle library then build your DLL!

Now, just in case anyone is wondering… the discovery of events and devices for a vehicle (as long as it is done correctly) only needs to be done once. So if you are thinking that this sure sounds like a lot of work, then don’t worry. At least for the ’04 Acura TSX, this will already be done by the time I am ready for anyone else to beta this thing. So that will make it easier for you guys to pick it up and start using it.

There it is, a much longer update than I intended to write, but informative nonetheless.


AC’s Conversions Map Pack Downloads

I have been getting a lot of emails lately requesting a link to download the conversions map pack that I put together for Halo 1 a couple years ago. Since the torrent doesn’t have anyone seeding it at this point and the number of downloads will likely be small, I have added links to download the files form this site on the project page.

For those who care, enjoy!


IEBus Studio development – help wanted

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:
Code:

~1:2A:A8:01:6:2E:4F:FF:12:0C:8B^\r\n

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!


Sniffing the IEBus smells so sweet!

I finally got it all together and working tonight. Here is a run down of where I am at now on the IEBus project:

Dom’s video converter unit is installed and mounted cleanly in the trunk next to the navigation unit
I have a carpc built and working (it’s still very rough around the edges, so I will not be permanently installing it just yet)
The IEBus sniffer breadboard is put together and working

So now I will begin to work on the firmware. I want the ability to control the carpc by using the stock navigation’s touch screen events which are passed over the IEBus. I also plan to generalize the code base to allow for implementation in vehicles other than just mine.

I put together a video from the first tests tonight. Pictures and data log files will come later. (If the embeded video doesn’t load click here for a direct link to the video page on YouTube.)


The com port is back in style, baby!

I have been working on the IEBus project a lot these past few weeks and I realized that I have been updating the forum thread, but never updating the site with my progress, so we are.

Just to recap where I am on the project… I found research that others have done regarding the AVC-LAN (Toyota’s name for the IEBus) and have been working towards building a circuit of my own based on their designs. I received most all of the parts from Digikey yesterday and the programmer for the ATMega8 arrived this afternoon, so I have been getting familiar with the it’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):