I'm new to this board, but been lurking for 2 years and using this site as a reference. Just recently picked up a burn2 from another member, as well as some other goodies. Anyways, short story is after loading up s_aujp, and the logging file for the same, I found that I kept having problems trying to data log. It would connect, but then flash "DA Data Error" and insert a series of bad logs into the xdl session.

It made viewing my actual data darned near impossible. I couldn't seem to find anything on this board that detailed a fix for it so I figured I'd document for the search engines (and anyone else who has this problem).

When you're data logging your application (TP in my case) sends a dump request to the PCM, and then waits for a reply. In TP this can be seen by clicking Acquisition -> Edit Definition. Click on the "ADX Header Data" item and you'll see the "Monitor Command" (Usually set to a dump request macro).

The problem comes in to play when you have a bin on your prom that has more data then this the reply portion of this macro is expecting to see. Basically the PCM is still transmitting its packet, and TP blasts off another request before the serial line is ready for it. The solution is to either update your request reply, or to add a pause. I opted for adding a pause. Here's how you do that:

• Expand the Commands Node within the ADX editor.
• Make sure "Commands" is selected, and click the "Add New Item" button at the bottom of the dialog.
• Select "Listen for Silence" and click OK.. This basically adds a buffer that says "wait until the line's ready before you send another command"
• Give the Listen For Silence Item an id (maybe "silence"). Set the Silence Length to 15 ms
• Click on your dump request macro.
• Click Add New, select Listen for Silence and click ok.
• Click save

Happy logging! Hopefully this helps at least one person .

 

Good note.

You can also edit the ADX so that it reflects the correct response packet size instead of the erroneous one you're likely working with.

It should be 67, not 66.

 

sounds like what i've described on the TP forums.

http://forum.tunerpro.net/viewtopic.php?t=2215

so far, it's worked for 100% of the people that have tried it.

 

I actually asked this question in this forum about a week ago, that link Saar posted fixed it for me. Good info here.

 

Does it matter where in the list of commands that you put the new "listen for silence" command? eg, in the TP forum, it shows it down the list on the example, about in the middle of the command list.
Right now my new command is at the beginning of the list. I hope this new command helps, as I also get erroneous data while logging.

 

In the list of commands it has NO effect. In the macro you use to datalogg, it must be at the end of the list of calls to commands, such as "receive data, send data, wait for silence, repeat" etc.

 

Ok, I think i got it now. I needed to add the new silence command to that macro. Looks like I just created the new command, in the list, but did not add it to the macro.
The macro I used was called "Mode 1 ALDL Dump Request Macro". Is that the correct one? Looks like some of the wording may be different than the example on the forum.
thanks much, hope it works!

 

That is the correct one. It should work properly now.

 

Very cool. Can't wait to test it out. Just that I am running out of time before I have to park my IROC for winter. Hopefully this weekend I can get to a road test.

 

OMG
That's why I love this place!!!!

Is this gonna help with the lock-ups we were talking about here?

https://www.thirdgen.org/forums/diy-...w-connect.html

 

Well, this helps with getting "sporadic bad data" such as glitching numbers every few seconds, I'm not sure about disconnects/connection issues, but it's worth a try. Maybe someone else knows more about the disconnect issue, as said above, this was intended and is a fix for sporadic bad data.

I get booted (disconnected) every once in a while, sometimes not for days, sometimes twice in a day. I have read while searching about this issue that the 165 ECU is simply a pain like that, and that it is (possibly) due to a millisecond of low voltage to the ECU, causing it to boot the connection. Whether that is true or not remains to be seen. Just passing along what I've learned. Guess to test that theory you could install a capacitor before the main power line to the ECU..

 

Well I was finally able to get in a road test scan/record today. It was only about a 6 minute recording, but all data was rock solid, no DA errors and no "spikes" in the data.
I love it when a plan (fix) comes togethor!
Good stuff, thanks again!

 

Has anyone else tried this? It works well.