Search Archive

OBDII/Dash/Car stats / possible programs?

By bsnively · May 25, 2009in Hacks/Mods💬 129 posts👁️ 47,511 views
Page 3 of 6
Posted Oct 14, 2009 · 01:08 UTC#51

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!

Posted Oct 14, 2009 · 03:23 UTC#52

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.

Posted Oct 14, 2009 · 19:02 UTC#53

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!

Posted Oct 15, 2009 · 00:58 UTC#54

If you make something that works with 08 Sti through Tactrix 2.0 cable (interface between OBD II and compueter), I'll test it out for you. I'm currently using Romraider to log and tune the car.

Posted Oct 15, 2009 · 01:28 UTC#55

Any chance your software would work with the HP Tuner module? It would be really nice not to have to bring my laptop just to log the car. Thanks.

Posted Oct 15, 2009 · 05:38 UTC#56

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!

Posted Oct 15, 2009 · 19:32 UTC#57

Hi EEGeek. I like this idea of tracking your cars functions, I just wanted to throw another model your way. I'ts (INNOVA 3100a model) web site(www.CanOBD2.com)It has a USB Cable that can connect to the computer, I would like to know if it can be use on the AVIC-F900BT.

Posted Oct 15, 2009 · 22:55 UTC#58

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.

Posted Oct 15, 2009 · 23:58 UTC#59

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! :)

Posted Oct 16, 2009 · 00:58 UTC#60

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.

Posted Oct 16, 2009 · 04:25 UTC#61

Well, I can post what I've got so you an at least run it, even though you won't be able to use it with any of your hardware. It's more than just a file though, there's a bit to bundle up. I've got the day off tomorrow so I'll do that. If you all use Visual Studios then I can provide dummy GUIs of what I've got with no code so you can play with the design.

Posted Oct 16, 2009 · 14:22 UTC#62

well I checked the drivers included with my software and there is alot of ftdi stuff in there, seems like its compatible like you say... so now I just have to figure out how to tell the device to get me the info I want correct? and this is done through the companies API ??

Posted Oct 16, 2009 · 18:06 UTC#63

Yup. An example would be that you create your own cable and use the same ftdi chip. The chip connects to your cable on one side and some electronics you design on the other. You decide to be funny and require the the software running on your laptop send the command "banana" as a string down the usb cable to the ftdi chip which would relay it on to your hardware. You're hardware is designed to recognize the banana command and respond with the engine coolant temperature it recorded from the obdii port.

 

As you can see, you need not only the driver to talk to the device's usb controller, you also need the expected commands and the format of the responses to those commands. Otherwise you're just guessing and sending random stuff seeing if you can get the device to respond. A published api states just that. If there isn't one then you have to do some low level debugging, like running your software and finding a way to intercept the commands. Then you can see what commands to send based on what button you clicked in your software. I hope we don't get to that point as it'd suck up so much of my time.

 

well I checked the drivers included with my software and there is alot of ftdi stuff in there, seems like its compatible like you say... so now I just have to figure out how to tell the device to get me the info I want correct? and this is done through the companies API ??
Posted Oct 16, 2009 · 19:07 UTC#64

cool, I'll email the company and see if they have or will even release that to me. Thanks!

Posted Oct 21, 2009 · 18:54 UTC#65

:( they said they can't give me the info, any they don't have plans to develop for winCE

 

this sucks.

Posted Oct 21, 2009 · 21:11 UTC#66

You guys have promted me to attempt an install of the COBB AccessPort software on my AVIC. Theoretically I should be able to log data, change fuel maps, view realtime data and troubleshoot error codes. Here's hoping it works on Windows CE.

Posted Oct 22, 2009 · 06:49 UTC#67

An app compiled for a PC can not run on a Windows CE device. That's what I was trying to explain earlier. Got an AP eh? I'm supposed to not like you because of that :)

Posted Oct 22, 2009 · 18:25 UTC#68

Hey EEGeek anything new worth mentioning?

Posted Oct 22, 2009 · 18:53 UTC#69

Well, I still work on the software, but I get the feeling its mostly for my own use unless someone else gets an api for another specific piece of hardware. I can post what I keep updating, but until you can use my software on something beside the Standback, not much of it will mean much.

Posted Oct 23, 2009 · 12:11 UTC#70

I am considering getting an elm chip/cable from the usb to try this.

 

I understand if the answer is no, but would you be willing to loan out the source to me w/ the understanding that the source is the rights to you and any changes I make, you will own?

 

(much like some of the open source licenses that allow you to use, but have to submit edits back...)

 

Thanks,

Ben

Posted Oct 27, 2009 · 05:23 UTC#71

Hey,

 

I just quickly looked through this thread, ... while browsing around I found this;

 

http://freewareppc.com/utilities/obdgauge.shtml

 

Unfortunately the link seems to be dead.

 

Best of luck, awesome ideas.

Posted Oct 27, 2009 · 22:43 UTC#73

I know it requires the .net compact framework (has the source with it as well as the binaries)

 

thx,

Ben

Posted Oct 27, 2009 · 22:45 UTC#74

This is the link I got it from - source zip file is at the bottom

 

http://www.qcontinuum.org/obdgauge/

 

Thx,

Ben

Posted Oct 28, 2009 · 08:25 UTC#75

I can not believe some of you have not yet realized that the problem is not in the program or device, but how to connect that device to F900BT ... The only question is whether via USB, Bluetooth or maybe wireless

Page 3 of 6