Jump to content
AVIC411.com

OBDII/Dash/Car stats / possible programs?


Recommended Posts

Hey guys, I wrote the software to interface with our own hardware used for tuning. If you all want to be able to use it without our hardware, find me whatever retail part you'd like to use to connect the unit to the obdii port and I'll make the software work for it as well.

Link to post
Share on other sites
  • Replies 128
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I currently have one of the Scangauge II devices

http://www.scangauge.com

It is a great piece of hardware and software. If there was a way to mimic most of it's functions on the AVIC, that would be amazing. It has a fully functional trip computer with all of the fuel functions also. Plus code reader/resetter. It can monitor up to 4 sensors at once. Plus it's back light's colors are user programmable to match any color dash lights like the AVIC.

Link to post
Share on other sites

I finally got the chance to watch the videos and it looks great, functionality-wise! I cant wait to see it actually used in a vehicle! Any chance well be seeing the software downloadable anytime soon? Also have you been able to look into the interfacing options any further?

 

In for the BETA! =]

Link to post
Share on other sites

So, in response to a PM I got, I wrote this, figured I could post it for all to see. This is in reference to the videos I posted on here a page or so back in here...

 

I write software for a company that makes performance parts for cars. One of their products is an engine control unit that allows you to record engine data and change or "tune" engine settings as well. The software in the video is used to allow the AVIC units to connect to this tuning unit via the usb cable. The software then displays in realtime the data being recorded from the engine controller and also allows you to adjust settings on the fly. Our current software runs on a laptop you must carry with you in the car. I thought it'd be easier to use the software if it was on your GPS unit you already have with you.

 

You can't connect a usb port to an OBDII connector, so you need something to make the two talk to each other. So, at the moment, the AVIC connects to the cars OBDII connection through our own tuning unit. If there is some other hardware out there similar to ours, I wouldn't have a problem making this software work on it as well. Our tuning unit currently only works on the new turbo-charged BMWs (135i & 335i) and the Mazdaspeed6 (my car) and the Mazdaspeed3.

 

I live in PHX area (Mesa) if any are interested in seeing it working live. I have made more progress lately and am adding the knock retard sensing ability so you can see if you're engine's knocking due to too aggressive of a tune. I'll add ability to read/erase error codes soon.

Link to post
Share on other sites

Great to hear more from you EEGeek, You mentioned a couple times about your "hardware" what exactly are you guys using? Also what are the chances this could be used on say my 98 Nissan Maxima? Its global OBDII so im sure theres ways to make it compatable, and i work part time on the weekends at my fathers shop so i know that with scanners of many types you need certain Keys to use even the global OBDII on diffrent vehicles.

 

as to the subject of the interface for the USB, i defintely saw that coming and such is not a problem i was just curious as to the bare minimum hardware needed to interface.

 

Would a Generic OBDII interface such as a Fleabay model ODB to USB interface?

 

http://cgi.ebay.com/ebaymotors/CAN-BUS- ... veQ5fTools

 

or

 

http://cgi.ebay.com/ebaymotors/Scanner- ... veQ5fTools

 

sorry if im asking alot, or just plain dumb questions. thanks for your contributions man!

Link to post
Share on other sites

What about a sct xcal 2 device ???

 

It performs similar functions and is used by the mustang and the f150 that I know of. I can monitor lots of sensors and speed and such with it. Something that allowed users just to monitor stuff going on with maybe analog gauges might be neat. What do you think. BTW, this device normally plugs into my odbII port and then plugs into a usb port and we use sct live to monitor things.

Link to post
Share on other sites

Hey all, more vids. This time I'm driving while using the software. These videos are only of the turbo boost page, the page most people using our hardware care the most about. The top two videos are the new ones:

 

http://www.mediafire.com/?sharekey=3da5 ... 0a1ae8665a

 

Onto the hardware discussion...

 

The hardware I'm using is the Standback engine controller from Custom Performance Engineering. It's $600 or so but isn't just an OBDII scanner. Actually, we're only testing the OBDII stuff now, hence my software. The real purpose of the hardware is to tune cars; it's an engine management system. A secondary function of the hardware is to stream realtime data from the wired in connection to the car's engine control unit out to a laptop in the vehicle. Because we're wired into the ecu, I can actually change what the engine does, as you can see in the video. I have two different engine maps loaded, one with higher boost and one with lower. A switch in the cabin toggles the map in use. I can uber easily change those boost settings on the fly with the AVIC software by just using the volume wheel and center button. Loosing a race? Dial it up a couple more notches and let'r rip!

 

I currently boot into test mode, install .net compact framework 2.0 and then launch my app.

 

I chatted with another guy on here about possibly using a cheap usb-obdii converter built into a cable. I think I found it for sale for <$100 on froogle. I wouldn't have a problem making this software run on other devices, I just need something to test it on. I'd obviously have to rewrite a bit of the logic as it won't work the same way as our hardware. If anyone has an extra of whatever you want this to work on, I can play with it an let you know if it'll work. I'd obviously send it back to you.

 

In any case, I'm adding OBDII reading to get access to some info we can't read yet, like boost air temps and knock retard (Mazda specific pids that are useful for tuning). I won't stop at those two though, I'll be able to pull all the standard OBDII data down as well as read/reset error codes. Those new OBDII additions to my software would be the only pieces that could possibly work if we got some of your suggested hardware supported. Obviously the tuning pieces would mean nothing to an obdii to usb converter by itself.

 

Thanks all for the interest, I'm considering starting a blog about this and my other ideas/projects. I love my AVIC!

Link to post
Share on other sites

I'd say that both those products should technically have everything I need hardware-wise to make it work. The issue is first having access to their api (software driver interface I would call to retrieve data) and second, having a unit to test on. I could dig a bit on both of those to see if they have documented apis to interface with their cables. Quite honestly though, I've done what I've done because I have an AVIC and a Standback. That's my motivation. If you really want to help me develop the software and really want it to work on your device, I'd need something to test with.

 

Thanks for pointing me to what you two are using though. I like reading up on other products to get ideas!

Link to post
Share on other sites

EEGeek: great work on the interface and all your progress on this topic, it really makes me hopeful that I wont need to build a separate computer just to show software gauges.

 

maybe you can help me through a solution for a product I already have. It was mentioned earlier that a company (www.uprev.com) makes a cable to interface with the ECU on many nissan and infiniti vehicles. Through this cable and the software they have already developed you can flash the ECU with tuned roms they design for each car, I don't mind doing this from my laptop when needed...

 

The part I'm interested in is the other piece of software that is used for datalogging, It has real-time gauges and monitors every sensor the ECU can see.

 

I'm having an issue in three places: first figuring out how to get the f90bt to recognize the cable and install the driver (truth be told I haven't tried just plugging it in... but I'm assuming it wont work because the driver for it is made on windows xp/vista.) Second, installing the software that was developed for XP/Vista on win CE. And third, figuring out how to launch the app as part of the normal function of the headunit (IE: how the GPS portion is integrated.)

 

I envision a radio that functions like normal (plays music when in other menus) and has a real time gauge section that I can click on where it will load up the program and keep it up until I turn the unit off, yet will allow me to click back and forth between external menus like its integrated.

 

Is this impossible? do you have any Idea on where to start? Even getting it to run in safe mode would be great... It's frustrating(dangerous) bringing my laptop around and trying to watch it in my passenger seat while driving.

Link to post
Share on other sites

You think like an engineer! That's the exact list I had to go through. In my case, I've figured out the first two of those steps and use leetlauncher and the configurable launch scripts to take care of the third. I've been looking into actually modifying the AVIC rom and writing it out to the unit to make it permanent, but I'm saving that for a later date.

 

Ok, the first point on your list. Our unit (Standback tuner) was made to be connected to a PC and so we only had PC drivers for it. When dealing with drivers for a usb device, you usually aren't dealing with completely custom drivers. Most usb devices have a single chip that the usb wire is connected to. It acts as the middle man, converting commands from the usb bus to commands the actual electronics are expecting, usually 5v TTL. Because our device uses a standard usb controller chip (an ftdi chip) I was able to go to their site and find drivers for that chip that work on PocketPC and Windows CE devices. Then I only had to modify the driver's .inf file to specify the "code" that identifies our device uniquely (So windows can differentiate between multiple devices that use that common chip). To install the driver I made some registry changes and copied the driver file into a Windows system folder. It was a pain but I made a script that did it for me and just launch that when the avic boots.

 

On the second point, you can't run Win32 apps on an arm based device. There are two types of applications: managed and native apps. You have absolutely zero chance of running native apps as they are compiled for the specific processor of your target platform. Managed apps, like those based on .NET framework can run on a machine as long as the right .NET framework is installed. The problem is that even if the software you are trying to run (the software that came with your cable) is a .NET app, its still not going to work. The reason is that PCs have loads of resources and run the full .NET framework. Windows CE devices are skimpy on resources and run .NET compact framework. You can't run an app compiled for one on the other. SO, you have to write your own software (like I did) or you have to find a version of the original software built off of the .NET compact framework. I doubt they ever did that as Windows CE devices were probably never in their sights. For me, I had already written the original application for the PC so I just copied and pasted the code into a new .NET compact framework project. I then had to clean it up since many of my beloved commands and interfaces weren't available to me in the slimmed down compact framework.

 

Good news is you can write your own app as long as the api is available for your cable. If the cable uses the same ftdi chip everyone uses then you can get the driver working. Once you can talk to the device, you have to know what to "say" in order to get the thing to spit back the info you want. And then you have to know how the info it spits back is formatted. All that covered by an api. If there is an sdk or documented api for how to talk to your cable once the driver's installed, you have a chance to make it work with my software or with your own software you write.

 

That's the same for everyone else who have made suggestions about cables or devices to try. My software can be made compatible with them all as long as I have a way to talk to your device AND know the device's "lingo". The driver is the easy part, then I need to know the api. If the company has not provided the api to the public, then you'd have a long road ahead as you tried to reverse engineer their .dll files which are probably where they store their interfaces.

 

If any of that is over your head, you can always wikipedia it or ask me on here! :)

Link to post
Share on other sites

I find myself consistently checking this thread over the course of the day, and this has all left me wondering what can we do (the members involved or interested in this project) to help make this a less painful project? Or to help improve upon this project?

 

Im sure you could use help with the GUI, testing, ect. and im sure all of us will agree were willing to help.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...



×
×
  • Create New...