Software On ELM Street - OBD2 Software Development

[Jayme]

yep, you give it as many bytes as you want in the header. AVT data is in hex so you cant read the 1.5 bytes 5E8 together like the elm lol. so if you put 05 E8 08 FE in the header and click align to header, it will sit there and wait (until your timeout value) for that string, and then process the next X bytes, then move on to the next command in your macro, prevents junk on the bus being processed as a packet, so all good.

all you do for tester present is put a send packet in your macro every loop or every 10 loops or whatever, thats no problem either.

[antus]

avt does support periodic messages for exactly this, so you can program it to fire off tester present messages in your connect macro and then forget about it. Although you then have to clean up on disconnect and tell it to stop. So keeping it simple so doing it jaymes way and implementing it in the loop might keep it clearer to the next person reading the adx.

[Tazzi]

yep, you give it as many bytes as you want in the header. AVT data is in hex so you cant read the 1.5 bytes 5E8 together like the elm lol. so if you put 05 E8 08 FE in the header and click align to header, it will sit there and wait (until your timeout value) for that string, and then process the next X bytes, then move on to the next command in your macro, prevents junk on the bus being processed as a packet, so all good.

all you do for tester present is put a send packet in your macro every loop or every 10 loops or whatever, thats no problem either.

Im looking forward to processing raw bytes.. rather then the nonsense string<->byte conversions constantly!

Something to think about for the DPID setup though, is only a fixed amount of data can be read out between all the dpid's. The "major" important pids should all fit plus a few extras. But to cover the entire PID selection, will probably need multiple ADX's.

avt does support periodic messages for exactly this, so you can program it to fire off tester present messages in your connect macro and then forget about it. Although you then have to clean up on disconnect and tell it to stop. So keeping it simple so doing it jaymes way and implementing it in the loop might keep it clearer to the next person reading the adx.

I read that in the doco sheets last night, handy little function!. But achievable and more manageable controlling it within a loop like you said.

[Jayme]

yeah im not too worried about fitting every single thing in. for the VPW DPID adx, I just added in the major PID's for tuning and declared that the adx! the rest can be covered in different ADX if there is need for it maybe? or maybe they can use the ADX for tuning and use your tool for the more deep dive into the rarely used PID's

did you end up finding any way of requesting an enhanced PID directly? as far as I have been able to figure out, you can only request SAE pids individually and enhanced PID's are DPID only? also do the bosch and delphi E38 etc differ in the DPID method? are we going to have to have an alloytec and a v8 ADX separately?

[Tazzi]

yeah im not too worried about fitting every single thing in. for the VPW DPID adx, I just added in the major PID's for tuning and declared that the adx! the rest can be covered in different ADX if there is need for it maybe? or maybe they can use the ADX for tuning and use your tool for the more deep dive into the rarely used PID's

did you end up finding any way of requesting an enhanced PID directly? as far as I have been able to figure out, you can only request SAE pids individually and enhanced PID's are DPID only? also do the bosch and delphi E38 etc differ in the DPID method? are we going to have to have an alloytec and a v8 ADX separately?

Your right there, thers only really the "main" PID's people want need to see of want to see. The others are just extras for the curious really!

Nah I didnt find a way of requesting the PID's directly, The only way to request 1 PID was to set 1 pid up in a DPID.. the request the DPID spam request using an 01 instead of 04..

So if I recall correctly.. AA 04 F4 ect Will do a massive spam of all that PID
And.. AA 01 F4 will send the DPID F4 response once and then stop immediately. So each DPID could be separately request this way.

The problem here was the for some reason, it wouldnt let you spam the request really quick the "single" request way. I could only get it to send about 2frames/s.
The normal DPID request using 04 on the VZ V6 ecu (E55), I had it over 150frames/s, and there was still more to capture because the ELM couldn't keep up!

Gives some razor sharp needle responses thats for sure!

[Jayme]

and thats my worry..... the AVT will keep up but tunerpro might not. and if it cant read the data fast enough, then the buffer will fill up in the avt slowly and start missing packets and all sorts of hairy badness.
I hope there is a way to slow down the spamming to a reasonable speed.

[Tazzi]

and thats my worry..... the AVT will keep up but tunerpro might not. and if it cant read the data fast enough, then the buffer will fill up in the avt slowly and start missing packets and all sorts of hairy badness.
I hope there is a way to slow down the spamming to a reasonable speed.

The AVT gives a warning when the buffer is full right? As an option, you could periodically turn off the CAN responses so no frames come through, clear the entire buffer, then re-start the CAN responses?

[antus]

It cant if the pc serial buffer is full. You'll get errors from the serial api and data will be missing when you catch up, so just need to discard corrupt packets and keep going. The avt is fast enough for max bus speed - its the pc buffer that'll overflow. You can flush it or not and keep going.

[Tazzi]

It cant if the pc serial buffer is full. You'll get errors from the serial api and data will be missing when you catch up, so just need to discard corrupt packets and keep going. The avt is fast enough for max bus speed - its the pc buffer that'll overflow. You can flush it or not and keep going.

Ahh right I see. I guess you cant check how full the buffer is in tunerpro?

I just read out all the data available and chuck it into a ring buffer that a separate thread can process onto the user interface. Id assume tunerpro will probably do everything on the same thread so it might actually fill the buffer up slowly. Id say best bet would be to make it disable the responses, clear out the buffer so its a fresh start then re-enable it, that way you know your not getting mumbo jumbo and should still all be in 'order'

Anyway.. something to tinker with once the AVT rocks up!

[antus]

Tunerpro is multithreaded and it takes as much time to check as it does to get it out in to your own buffer so might as well just hit it but handle failures sainly when winapi sends one back.