38 replies to this topic

[clipping_point]

Look HERE

Could it be useful?

[AmazingMonkey]

Looks interesting.

Did you see the bluetooth ODB2 connector HERE

I might email and find out how much it is.

It would be great to have the PDA in car with the sat nav and detailed engine diagnostics.

[cyberman]

Looks interesting.

Did you see the bluetooth ODB2 connector HERE

I might email and find out how much it is.

It would be great to have the PDA in car with the sat nav and detailed engine diagnostics.

The OBD Bluetooth transmitter with s/w Cd is quoted at £199. Plus PC interface £249. Which all seems reasonable. the kit requires formal OBD-II compliance. Anyone know if the VXT achieves that cos, if so, these chaps probably have a sale....

Regards - Ian

[Dave]

Is it as simple as cable and software with PC or Palm or Pocket PC? if it were I'll have one............. a group buy I'm sure. I like my gagets. keep us informed as to the compatability with VX/VXT/VXR Dave

[cyberman]

Well, I spoke to Sinclair who runs the company (nice guy)and he confirms that the VXT has an OBD-II compliant port and the ECU being Bosch Motronic it knows how to speak politely. The port he thinks is under the dashboard on the drivers side. This may need some investigation unless anyone knows where it is? I'll look on the TIS disk later and see if I can find it. I imagine its where Vauxhall plug in their diagnsotic kit. All sorts of data are immediately available including AMM, O2 sensors, fuel flow throttle setting etc etc. There may be Vauxhall private data which is outside the standard which may need decoding particularly - can't know till we try it. Commands can be sent to the ECU to get it to format data to order apparently. Probably need to read the standard I guess..... I plan to get one of these and try it this week. I'll report how it goes. Sinclair offers 10% discount for online purchase and would do better for any group buy. Regards - Ian

[garyk220]

Ooooh, keep us posted Ian. I've got a bluetooth PDA, so a OBD-II reader/transmitter for less than £200 sounds good, especially if it can monitor boost and intake temps PS diagnostic port is under the dash on the pasenger side - just above the footrest. Easily accessible.

Edited by garyk220, 24 January 2005 - 09:21 AM.

[Paul]

Sounds good - is the deal to buy the connectors then use the freeware software OBD Gauge above to display the information?

[Dave]

their site said it dose not work with USB devices??? I assume this means when you synch with PC or download software to PPC or PDA it has to be done with a serial cable? Not knowing much about PPC PDA PC's can you still synch with a serial cable? Dave

[cyberman]

Sounds good - is the deal to buy the connectors then use the freeware software

AIUI yes, thats exactly right. ian

[cyberman]

Well, this *was* a nasty double post which I couldn't spot how to delete. So I won't waste it and will respond to Dave instead.... Dave, I will be getting more data later today and will try to answer your question then. Otherwise, Sinclair is a very nice guy and well clued up on the technicalities. I am sure he would be as helpful as possible. +44 (0)208 4455008 Regards - Ian

Edited by cyberman, 24 January 2005 - 09:36 AM.

[garyk220]

Not knowing much about PPC PDA PC's can you still synch with a serial cable?

Most Bluetooth PDAs have a serial port client. Non-bluetooth tooth PDAs would need the additional hardware/interface I presume

[AmazingMonkey]

Sounds good - is the deal to buy the connectors then use the freeware software

AIUI yes, thats exactly right. ian

I think the bluetooth ODB2 connector comes with software anyway.

Does anyone know if the NA is fully ODB2 compliant?

Edited by AmazingMonkey, 24 January 2005 - 10:45 AM.

[cyberman]

I have been doing a bit more research on OBD stuff and it turns out that data is available from the port in a fairly straightforward form. Conversion to asynch serial data interfacing to a PC is pretty simple and a program for a PIC which is supposed to do this is available as freeware. If thats gobbledegook it means that a cheap piece of electronics only is needed to convert the OBD port to something a PC can talk to through a cable. So, while the Bluetooth device is a nice package, for those who want to roll their own and don't mind doing some programming this is easily possible and shouldn't be too hard. It also mean that if the Bluetooth device doesn't do everything one wants *there is a way out* and it can act as a good working model whilst doing any development. I found one US site where they use it to calculate engine power output based on acceleration figures. A very neat extension application. Probably do something similar for comparing pad / disk efficiencies as well. It sounds fun.

[AmazingMonkey]

I think a wired solution would be about £50ish, but I do like the idea of bluetooth.

[caleebra]

I  have been doing a bit more research on OBD stuff and it turns out that data is available from the port in a fairly straightforward form. Conversion to asynch serial data interfacing to a PC is pretty simple and a program for a PIC which is supposed to do this is available as freeware.

Say you had a PIC programmer, and lashed up a suitable i-face cable, how easy/hard would it be to interpret the incoming data? Also, is it a stream that can be picked off at will or do you have to poll the ECU for specific data? Or is this something the PIC interface does?!?

[cyberman]

[Say you had a PIC programmer, and lashed up a suitable i-face cable, how easy/hard would it be to interpret the incoming data? Also, is it a stream that can be picked off at will or do you have to poll the ECU for specific data? Or is this something the PIC interface does?!?

The way I understand the limited number of documents I have scanned this am is that:

(a) the freeby PIC software acts as a relatively dumb asynch data / OBD data converter. It probably does any framing needed etc but I am pretty sure thats your lot. 19K2 is the defined baud rate but this may be a PIC implementation issue. Its hard to bit pick much faster than that with a dumb PIC.

( depending on the protocol in use (there seem to be at least 3) you either specifically request individual or block data items or can get a frame dump (which may be everything available).

The impression I got from a US website is that OBD / ANSI supports the frame dump. I think you have to poll for a dump. I think you have to wait no data transfer delay to know the frame is complete (sets a maximum refresh rate).

© The standard codes are defined and the non-standard ones are documented somewhere (the Bluetooth chap has a list I think). Once these are known and the data is in asynch form interpretation is a defined problem.

Defined problems may be tedious / trivial to handle. I expect it will be relatively trivial and that the maximum needed will be (a) field extraction ( data format conversion © scaling and (d) range adjustment.

If that doesn't make much sense then frinstance: the data for an item might (I don't know) be in the 12 bits following the Esc * sequence, may be in BCD, may be in some strange floating point format, may be based at 47 instead of zero and may have a range of 47 to 319 when one wants 0 - 100. All of that is very straight forward to deal with in a little piece of code although its a bugger to pick out by eye and with the forebrain only...

Best I know at this time.

[garyk220]

but I do like the idea of bluetooth.

After reading Ian's last post so do I

[Thorney]

We're working on one of THESE but with full OBD data output integrated with it.

Should have it in Feb.

[caleebra]

The way I understand the limited number of documents I have scanned this am is that:

....Best I know at this time.

Good info

I expect it will be relatively trivial and that the maximum needed will be (a) field extraction ( data format conversion © scaling and (d) range adjustment. 

And this is trivial?!? Would the bluetooth chap be willing to provide a list of codes FOC to random 3rd parties?!?

Edited by caleebra, 24 January 2005 - 03:40 PM.

[cyberman]

And this is trivial?!? Would the bluetooth chap be willing to provide a list of codes FOC to random 3rd parties?!?

Ah, yes. If you want to handle any sort of process data then these are the minimum 4 manipulations you have to expect. It can get worse.... If execution time isn't critical you would probably write (or use a library of pre-written) generalised functions which will do all the twiddly bits if just given the minimum parameters for each operation.

As to willingness to provide list of codes I don't know. I have just purchased a unit and asked for any extra information (including codes) he can provide. I expect I will see it before the end of the week. I'll let you know what I find.

The standard codes are I think publicly defined. I haven't had time to look but I think the Society of Automotive Engineers (or whatever) have the relevant standards and will be glad to supply them (no doubt for a fee). A more extensive websearch might be useful too.

Ian