ADX and XDF creation help

[antus]

Here is a file I was sent, which is partially working the allpro. It'd be a good starting point. It also has the lookup tables, but its not good enough to consider usable yet. But the heavy lifting is in.

The lookup table uses PC CPU time, and not a lot of it. So yes technically it is another reason its slower but in practice humans wouldnt notice the extra delay from that part of the processing. It'll be a lot less CPU cycles than driving the display, say.

[DavidBraley]

Here is a file I was sent, which is partially working the allpro. It'd be a good starting point. It also has the lookup tables, but its not good enough to consider usable yet. But the heavy lifting is in.

The lookup table uses PC CPU time, and not a lot of it. So yes technically it is another reason its slower but in practice humans wouldnt notice the extra delay from that part of the processing. It'll be a lot less CPU cycles than driving the display, say.

Thank you so much! I will pour over this tonight. I will make a copy of it to play with.

Is it possible to put comments in a .adx file? The only clue I can see for proper commenting syntax would be this line from the .adx you just shared:

<!-- Written 03/16/2019 17:14:31 -->

Or was that line somehow created by the .adx editor in TunerPro and not a comment? (that time stamp looks suspiciously like it was computer generated)

I'm thinking being able to add comments to the file I'm working on might help me while I'm discovering how this stuff works. There is a lot to juggle...

Thank you again!

[antus]

Yeah the xdf has a big warning in there about not hand editing too. I think dont hand edit it, only use the built in editor. If its too hard to solve whats wrong it with, dont be afraid to start deleting a bunch of stuff and try again. There is more in there than there needs to be, thats for sure. But the lookup tables are there so def. keep those.

[DavidBraley]

Again, very helpful! I guess I'll be deleting the vi editor for windows I just downloaded...

Rolling up my sleeves. If you don't hear from me in a couple of days, send for help.

[jenko]

[DavidBraley]

Short update: Spent most of the weekend taking a good long look at what the heck this ADX thing is all about. This stuff is not for the faint of heart that's for damn sure. I admit to getting pretty frustrated and feeling like I wasn't going to get this...

But on Monday evening, I had sort of a breakthrough of understanding. I'm still not out of the woods, but decided to step away for a couple of days to let it all cook. I was headed for burnout. Plus my wife has me getting some things done that I was supposed to do last weekend.

I am so absolutely grateful for all of those who have attempted and succeeded at .adx file creation before me. The .adx files that I have are invaluable in helping me understand this. But because they are so overwhelmingly large (and full of a lot of stuff I just don't understand yet), I made the decision to starting building a new .adx from scratch. My plan is to get ONE thing to work. Then I will add something else. Then another... I feel doing it this way will aid in my understanding (using the kiss rule). Plus, I can test it with each added feature. That way I know if it stops working, it has something to do with what I just did and everything else is good.

All of the .adx files I have do not work in my particular situation. I think this is because I am only testing them with a bare PCM on my bench with no sensors hooked to the PCM sending some kind of signal that would show up on the TunerPro Logging Dashboard. My plan is to add sensors to the PCM on the bench as I add features.

The only .adx that will at least stay connected to the AllPro USB is the one Antus shared a few threads above this message. But again because my PCM is not in a car, I can't really test it.

So, give me until the end of this weekend, and I hope like hell to have a .adx file for the AllPro USB that does something. Not much (maybe only one thing), but my plan is to continue building on it until it becomes something useful to myself (of course) and others as well.

There is still a chance I will not succeed at this... Fingers Crossed!

[j_ds_au]

Good luck!

FWIW, any official information on TunerPro file formats would be posted here :
http://tunerpro.net/whitepapers.htm

There is one paper there and it seems to be describing a generic file format from which ADX & XDF presumably were derived? More specific ADX & XDF details are listed under "Coming soon", and have been so for a very long time now.

Joe.

[DavidBraley]

Thanks Joe! I haven't seen those documents. I will pour over them tonight. Hopefully it will help improve my vocabulary.

Sorry for getting a little off topic:

I started building an engine run-in stand that will hold both the engine and transmission for my project. The plan is to first use this stand to rework the the LS wiring harness I have here into one good one that will fit both the engine/trans combo and fit nicely in 48 GMC truck. With the engine and trans operating on the stand in the comfort of my heated space, I can work out a lot of bugs and make sure the trans shifts OK. This engine/trans on stand combo will allow me to further develop the .adx file. It will also provide me my first experiences tuning. I figured because I'm going to rebuild the engine and transmission anyway, I can't really hurt anything while doing all of this testing.

The engine is a Mark IV Big Block Chevy and I will be making my own intake manifold, and 24x crank position sensor setup for it. I will be using a 1x cam sensor from a Express Van distributor housing. I will still be using coil near plug for ignition, so I will be making a billet cap for the top of the distributor where the cap would normally go. The other reason I need that distributor housing in the back of the block is to drive the oil pump! The transmission is a 4L80e.

I know, it seems like a lot of extra work for an engine swap. But my plans are to do a few of these "Adapt the Gen III Engine/Trans Control System" to several other "Non Ls" engines. I'm betting the stand will come in handy again.

David

[bubba2533]

I have an AllPro USB as well, and I have a bench harness with a JimStim wired up to simulate some of the sensors.

So if you get one of the normal sensors working I'd love to test the adx out.

[160plus]

The Obdlink ADX worked to some degree but if I recall the lookup table needs to be relinked or it might have needed a lookup table added, it's crazy fast when it is working......I want to say it would run around 60hz.

The allpro Adx is based off the Fixed Elm ADX listed here just so you can compare these to each other and see what I did to make it work with the Allpro VS a normal Ebay Elm.

The DVI Dpid is just for reference since only a couple people have one of the DVI Prototypes and I'm not even sure what version of the DVI ADX I was working on last. I sent out all the DVI's I built for testing so I can't even load it and see. But I'm providing it to use as a comparison against this reworked version of the AVT ADX to see the difference in how they are requesting and parsing data. The DVI will send 3 requests total and read a single line back for each request. The AVT Adx is sending one request and reads 3 lines back from the pcm in one shot. While tools like the Allpro are not able to parse data this way it gives you an idea how of how to deal with reading multiple responses while still filtering whats read. There is a 50% difference in the speed when changing the format going from 3 requests to a single request.

The issue your going to have with reading data back from the OBDLink or Allpro is the data is read back in ASCII format and tuner pro is expecting it back in byte format. This is what the lookup tables are for, it converts between byte and ascii format but is a real pain to relink the tables once you break the response format. The Allpro is capable of running dpid like I setup with the Obdlink stuff but it's not going to be nearly as simple to do and won't be as fast. The biggest thing to keep in mind with the Elm stuff is the need for \r on the end of each line you send. You can't set the \r in the ascii table, you will have to do it in the byte section of a TX line for it to work correctly with most tools.

You should be able to get an ADX working after going over these and looking at the differences. You can do this with a PCM on a bench, just use pids you know what to expect from. Coolant temp and air temp will read -40, battery voltage will read your power supply voltage and the 02 sensors will float slightly....they should hover around .450mv and move maybe .008-.010 up or down. If you break out the O2 wires from your connector you can touch the O2 wire with your hand while your hand touches the pcm and you can force the O2 reading to move. Just don't ground the sensor wire itself......touching it with bare skin while being grounded is enough to make it move.

If you need the dpid format changed or different pids used and are not able to figure that out either myself or Tazzi should be able to help you get the pids loaded your looking for.

Be ready to get frustrated, getting Tuner Pro to parse data correctly can be a royal nightmare and even when you'd swear it should be working don't be surprised if its still got an error or not parsing correctly. It has to be like 110% perfect for it to work correctly. I'm pretty sure writing a program to log with from the ground up would be less frustrating than creating an ADX for an Elm type tool in Tuner Pro.

Obdlink STPX Dpid_Unfinished.adx

(135.21 KiB) Downloaded 359 times

Allpro Elm Headers working with 3 pids.adx

(206.84 KiB) Downloaded 361 times

Fixed_ELM327 V2_20.adx

(206.77 KiB) Downloaded 389 times

DVI Dpid V1.2_working.adx

(53.29 KiB) Downloaded 343 times

AVT Change DPID format_NowMucFaster.adx

(54.21 KiB) Downloaded 349 times