Software On ELM Street - OBD2 Software Development

[vn5000]

I think the reason its disconnecting and reconnecting is that it trying to detect the type of pcm/vehicle connected .ve v8 addresses are 7E0 > message to pcm 7E8 > message from pcm.

77 [00081176] IRP_MJ_READ Length: 0012, Data: 0B 00 07 E0 07 23 00 3F 91 BC 00 04
78 [00081176] IRP_MJ_READ Length: 0012, Data: 0B 00 07 E8 10 09 63 00 3F 91 BC 00
79 [00081176] IRP_MJ_READ Length: 0012, Data: 0B 00 07 E0 30 00 00 00 00 00 00 00
80 [00081177] IRP_MJ_READ Length: 0012, Data: 0B 00 07 E8 21 00 00 00 AA AA AA AA
81 [00081178] IRP_MJ_READ

If you want to pull pids from ram this is the format ,ill have a look at an adx i made to scan ve v8 with elm for the std way.

[Tazzi]

Ah that makes sense. Checks what the PCM responds to by trying out a few of the generic header ids.

[antus]

AVT Tell me that "in theory" the AVT-852 should be able to do a full 500kbit can bus dump. The MCU and the firmware in it are fast enough/capable, as is its FTDI. But in practice it is a bit hit n miss depending on the PC (I get the impression that the driver layer inside windows adds a lot of overhead and thats where you start to run in to problems).

[Jayme]

I have a full 500kbaud bus dump of my VZ and the AVT doesnt throw any buffer errors but Im losing packets occasionally somewhere... here and there I get a few random bytes that look like they are from the middle of a message. I suspect the AVT can keep up but my virtual serial port drivers or maybe app cant....

also the data stops flowing about 2 seconds after I disconnect the avt from the OBD port... so its definitely buffering somewhere.

[Jayme]

Well, I had success... turns out the c# read codeI was using was baaaad for high speed. was polling the serial port directly until it saw a header byte with the length, then pulled that amount of bytes one at a time off the serial bus and reset to hunt for another header byte.
new read code uses the serialPort1_DataReceived event handler and when that event fires off (windows sees data on serial bus) it asks for BytesToRead then reads that many bytes in one hit instead of reading one byte at a time. its way faster and now the data stops the moment I unplug the cable, so the buffer is staying empty now

so looks like a single AVT can handle a full on CAN 500kbaud bus dump on its own im just wading through the reams and reams of data to see if ive got any strange packets now. ill post up the log when ive had time to get it formatted a bit nicer.

so anyway now im just going to have a play with masks and PID's and start making up a tunerpro adx to log any can 500k vehicle

[vn5000]

Nice work ,so you have it monitoring all addresses or or do you need to define a range

[antus]

Nice one! Yeah I thought it'd be possible because the AVT does not use serial internally. The VCP driver speed only applys to the serial link on the other side of the FTDI, the pc talks to the FTDI at USB speed (400mbit for usb2 or 1mbit for usb1). Because the FTDI is connected to the AVTs cpu via i2c (or some other non-serial protocol) you dont hit VCP serial limitations.

[Jayme]

Nice work ,so you have it monitoring all addresses or or do you need to define a range

can set the range to 'dont care' then it listens to everything.

[VL400]

Nice work Jayme

[Jayme]

so I found some hiccups.... the log where I streamed raw data directly to my text box unformatted and unprocessed, was fine, I was keeping up with the buffer and each read from the avt was about 170 ish bytes long.

as soon as I added in code to format the individual frames and check AVT length codes etc, it started lagging behind the buffer, and each time it was reading data, it was 4096 bytes long and missing data.... so it looks like my processing code is either very ineficcient or .net (C#) is just too slow and too much overhead... as antus told me.. it might be time to go c++ ? either way I dont really care, my goal here was to get the chatter and make an ADX.