OBD Serial Data

[Mos]

Hi Amichie - is this in windoze?
Polling the parallel port, at least in linux, is not time deterministic and depends on what is using the processor at any particular time, so the bit edges may be all over the place in the bit stream you acquire. Always wanted to run a binary counter into some of the other input pins so a snapshot of the time of acquisition can be had (but never got around to it ).
Are you getting usable data?
Mos.

[wilbo666]

Hi Wilbo,
This is bloody cool!! Glad to see there's people on here playing with micros and all the jazz that goes with it What micro are you using?
How are you coming along with working out the meaning of each byte?
The bit stream you posted earlier - that was received at 100baud, is that right?
(Now how to find more free time...grrr)
Mos.

Using a ATMega32

I haven't had a chace to look at the data properly yet, soon hopefully.

Each bit is ~8.3msec wide which works out to be ~120 baud from my calc? Each sample in that bit stream is taken at 1msec (I used the micro as a poor mans digital storage CRO pretty well).

I was thinking about using a PC, I have a TTL -> RS232 converter whipped up, but I haven't had time to see if you can set the PC uart to recognise 4 data and 5 data words (as opposed to the normal 7 or 8).

Seeing as I have something to decode the data already it isn't a high priority.

Cheers
Wilbo

[amichie]

Hi Amichie - is this in windoze? YES
Polling the parallel port, at least in linux, is not time deterministic and depends on what is using the processor at any particular time, so the bit edges may be all over the place in the bit stream you acquire. Always wanted to run a binary counter into some of the other input pins so a snapshot of the time of acquisition can be had (but never got around to it ).
Are you getting usable data?
Mos.

I'm using National Instruments Labview to read the parallel port. The program is set as highest priority and works fine at the very low baud rate of the data coming out.Labview is also putting a millisecond time stamp on the data.

[ndgcpr]

yeah ok looks good. It shoudln't be too hard to setup a program to expect that sort of flow though would it, like looks for 4 5 8 8 8 8 8 8 8 8 8 8 8 8 4 5 8 8 8 8 ect specifically? and then just list the numbers, it woudl help the troubel shooting, woudl require a bit of time to code though.

if they are nicly lined up like that you would expect the throttle to be 0 as well no (ie on the plot you did for us previously). if it is the 7th it is on 46hex which is around 30%. but yeah. it is just a matter of finding time to debug all of that data. if you can plot a hugh data stream i would debug it for you, make sure you do somethings though like open the throttle and maybe start the car. i am in syd tomorrow so i won't be till the weekend.

[amichie]

This is what my data looks like.
The top graph is a 3 second log.
The bottom graph is one complete transmission data set.
The software searches and finds the long idle section of continous logic ones. Then discards the first part and displays the balance.So the first bit is the first start bit (a zero)
Works a bit loike a scope.
Next step is to figure out what everything means.

[wilbo666]

Awesome work man

Wish I had labview!

Cheers
Wilbo

[amichie]

Hi Wilbo

I connected up today and tried to figure out a little bit about the data stream. I can see the TPS, and water temp change as I move throttle, or disconnect the temp sensor etc when the engine is not running.
When the engine is running everything starts to change. The most interesting thing is that long idle state of ones starts showing heaps of data. I guess this means there are nore than the 10 or so words that you first suspected.

amchie.

[wilbo666]

Yep, I suspect that some of the 8 bit words contain more than one data item. Likely that some are binary for things like valves on/off, gearbox solenoids etc!

I'm trying to work out the easiest way to make a realtime visualization come about, the easiest I have so far is writing a VB app to plot it in excel in real time....hmmm.

Sounds like you're doing great man !

Cheers
Wilbo

[amichie]

Mine is updating every 3 seconds. Any less than that and I seem to miss a full data set.

It triggers nicely with engine off and at idle, but as soon as you rev it up you lose that long string of ones that I was searching for and the triggering gets lost. I was thinking of triggering the serial data mode by closing the te2 to e1 pins with a transistor switched from the parallel port. I'll give it a try and let you know.

This is about all I have so far.

[ndgcpr]

Any more news or has everybody given up?

[amichie]

I've been out of action for a while with a short stay in hospital. Should be back into it in about a week.

Iv'e got a few more ideas to try out anyway.

[wilbo666]

Any more news or has everybody given up?

Was away for the weekend,

I've got a realtime logging program setup now so will drive and log and see how I go...

Cheers
Wilbo

[Toysrme]

Updates guys?

[wilbo666]

Urgh groan I say!

I have some plots of data that I got....doesn't make any sense to me!!!!

I might have an issue with getting the data out or?

As such I have let it slip via the way side!

Cheers
Wilbo

[82MKII]

Amichie/Wilbo,
any chance you guys could give us a list of what you have discovered to date?
ie
data rate
first x bits known/unknown
next x bits
...
VAF (x bits)
ECT (x bits)
Throttle (x bits)
...

Just list out any bits you are uncertain about and when one of us gets time we can have a crack at it. I'd like to think maybe a Picaxe would be good to decode this with.

Thanks

Peter