Ford Universal ADX

[jsa]

Your Struct is good.

For an 8061 those addresses can be logged directly because 0x100 and above are outside the processor.
For an 8065 those addresses must be copied to a location outside the processor because 0x3FF and below are in the 8065.
QH can't emulate memory in the processor.

I don't use TP and have not looked at Decipha's patches for a long time, so my advice on his ADX is not much use to you.

[efloth]

Ok that is good to know, I will try to log directly. I really appreciate your help. FYI the universal ADX has selectable payloads configured for every strategy. A1C Payload Looks like this: I am just adapting for a different box code.

Code: Select all

0x51 0x40 0x01 0x03 0x1F 0x1F 0x02 0x03 0x0D 0xD6 0x02 0x03 0x03 0x96 0x01 0x03 0x0D 0xB6 0x01 0x03 0x0D 0xB7 0x02 0x03 0x0D 0x9A 0x02 0x03 0x0D 0xCC 0x02 0x03 0x0D 0xBA 0x02 0x03 0x0D 0xB4 0x02 0x03 0x01 0x24 0x02 0x03 0x0D 0x8A 0x02 0x03 0x01 0x62 0x02 0x03 0x01 0xF2 0x02 0x03 0x0D 0xBE 0x02 0x03 0x0D 0x96 0x02 0x03 0x01 0x70 0x02 0x03 0x01 0x1A 0x02 0x03 0x01 0x54 0x02 0x03 0x0D 0x92 0x01 0x03 0x0D 0x8D 0x01 0x03 0x0D 0x8D 0x02 0x03 0x1F 0x44 0x01 0x03 0x0D 0x91 0x01 0x03 0x0D 0xB9 0x02 0x03 0x0D 0xB2 0x01 0x03 0x0D 0xA8 0x01 0x03 0x01 0x5C 0x02 0x03 0x01 0x6A 0x01 0x03 0x01 0x5D 0x01 0x03 0x0D 0xDB 0x01 0x03 0x1F 0x1F 0x01 0x03 0x02 0x1B 0x01 0x03 0x1F 0x1F 0x01 0x03 0x02 0x28 0x01 0x03 0x01 0x4E 0x01 0x03 0x02 0x39 0x02 0x03 0x0D 0x96 0x02 0x03 0x01 0x70 0x02 0x03 0x01 0x1A 0x01 0x03 0x1F 0x1F 0x01 0x03 0x1F 0x5D 0x02 0x03 0x1F 0x20 0x02 0x03 0x1F 0x20 0x01 0x03 0x0D 0xD9 0x01 0x03 0x1F 0x1F 0x01 0x03 0x03 0x5C 0x01 0x03 0x1F 0x1F 0x02 0x07 0xFF 0xFE 0x02 0x03 0x03 0x14 0x02 0x03 0x03 0x22 0x02 0x03 0x01 0x6C 0x01 0x03 0x03 0x98 

[wwhite]

Please correct me if I am wrong, the above addresses are not directly readable by the QH so they are being copied by the datalogging routine to readable addresses. The ADX is configured to read shadow addresses so the big question is in what order are these shadowed? My Datalogging List function below is a copy from the A1C DL Patch. Can I assume that 010a=3030? I think I am missing part of the equation. Thanks for all your help.

The datalogging function is to copy addresses 0xff and below to shadow ram so QH can read and be logged.

There are three parts to the patch:
- first, the function that copies addresses from list to be shadowed, this is hardcoded into bin, the patch
- second, the list of specific address that are below 0x100, this is hardcoded into bin.
- third, payloads are sent from QH to read specific address locations.

It is the ordering of payloads that are important.

Example:
- data logging list: "D600 9603 B600 9A00 CC00 BA00....'
- data logging function copies "0x00d6" to [d00] = 0x0dd6
- payload read from xdf has "0DD60203", second packet (first 0-index based), means Read address 0x0dd6, 2 bytes from bank 3.
You will see that in the adx, packetoffset 0x01 is QH_ATMR1.

So, if you were looking for 0x010a, which isn't logged, or read in the payload, your not going to find it unless you put it there.

If your bin is anything like mine, 0x010a could be key power or battery voltage, maybe:

Code: Select all

02,0a,01            struct    2, Key_Pwr 

I do not see where you get 0x010a = 3030, that doesn't make sense, you are missing something there.

[wwhite]

Ok that is good to know, I will try to log directly. I really appreciate your help. FYI the universal ADX has selectable payloads configured for every strategy. A1C Payload Looks like this: I am just adapting for a different box code.

Code: Select all

0x51 0x40 0x01 0x03 0x1F 0x1F 0x02 0x03... 

QuarterHorse protocol:

Code: Select all

5140 // set up data query format
01031F1F // offset 0 - not in list but polled for superlogger offset
02030DD6 // packet offset 1, ram 0xd6, 2 bytes, memory location 3
02030396 // packet offset 2, ram 0x396, 2 bytes, ...
01030DB6 // packet offset 3, ram 0xb6, 1 byte
01030DB7 // packet offset 4, ram 0xb7, 1 byte, ....
02030D9 ......

[efloth]

Thanks for the input. I adapted Decipha's DL from the A1C bin and patch to my stock bin using the same parameter list. Are you suggesting that the parameter list needs to be changed? I was under the impression that was not necessary but maybe that is where I went wrong.

[wwhite]

I wouldn't change the parameter list, unless your not using A1C.bin.

If your not using A1C.bin, your going to have to disassemble enough, to know what memory address locations are what parameters.
Then you will have to update the parameter list, to match the packet offsets.

The only thing universal, is the mapping of returned bytes from the payload list, maps to packet offsets in the .adx for displaying of data.

[efloth]

Ok I think I follow you. Thank you. I am not using the A1C bin. My bin is J1X. Surprisingly the hego voltage is logging correctly though. it sounds like this will take some serious time to figure out. Is there a procedure documented for finding the memory addresses for things that are not in the ADC routine?

[jsa]

Once you know what the adc channels are physically, look at where they used and start finding associated parameters.

You could compare the use in your bin with the use in bins that have been fully disassembled to identify parameters. You could also look at the ford strategy docs to see how they are used.

You could start looking at interrupts for binary inputs.

[efloth]

Decided to just disassemble A1C and take a look at the known working values to try and make sense of this. I am definitely making some connections now. I can see how 0xD00 is added to the addresses lower than 0x100 and how the payload is referencing those copies in some but not all cases. Are the extra values in the parameter list just garbage left over? If the Payload references values like 0x0D8D(twice) that were not copied by the patch then how could that data be relevant? Placeholders? The only AD channel that is being referenced by the payload is ChB. Is that normal?
A1C AD Channels:

Code: Select all

3b91: 00,08,01            struct    0, iADC_Ch0
3b94: 01,0e,01            struct    1, iADC_Ch1
3b97: 02,0a,01            struct    2, iADC_Ch2
3b9a: 03,0c,01            struct    3, iADC_Ch3
3b9d: 05,44,03            struct    5, iADC_Ch5
3ba0: 07,1c,01            struct    7, iADC_Ch7
3ba3: 08,10,01            struct    8, iADC_Ch8
3ba6: 09,12,01            struct    9, iADC_Ch9
3ba9: 0a,18,01            struct    a, iADC_ChA
3bac: 0b,1a,01            struct    b, iADC_ChB
3baf: 0c,14,01            struct    c, iADC_ChC

A1C Parameter list:

Code: Select all

00D6
0396
00B6
009A
00CC
00BA
00B4
0124
008A
0162
01F2
00BE
0096
0170
011A
0154
0092
008C
0090
00B8
00B2
00A8
015C
016A
00DA
021A
0228
014E
0238
00D8
035C
0314
0322
016C
0398
0000
0027
5D01
009E
4404
00A5
4480
0000
0000

A1C Payload:

Code: Select all

02 03 0D D6
02 03 03 96
01 03 0D B6
01 03 0D B7
02 03 0D 9A
02 03 0D CC
02 03 0D BA
02 03 0D B4
02 03 01 24
02 03 0D 8A
02 03 01 62
02 03 01 F2
02 03 0D BE
02 03 0D 96
02 03 01 70
02 03 01 1A
02 03 01 54
02 03 0D 92
01 03 0D 8D
01 03 0D 8D
02 03 1F 44
01 03 0D 91
01 03 0D B9
02 03 0D B2
01 03 0D A8
01 03 01 5C
02 03 01 6A
01 03 01 5D
01 03 0D DB
01 03 1F 1F
01 03 02 1B
01 03 1F 1F
01 03 02 28
01 03 01 4E
01 03 02 39
02 03 0D 96
02 03 01 70
02 03 01 1A
01 03 1F 1F
01 03 1F 5D
02 03 1F 20
02 03 1F 20
01 03 0D D9
01 03 1F 1F
01 03 03 5C
01 03 1F 1F
02 07 FF FE
02 03 03 14
02 03 03 22
02 03 01 6C
01 03 03 98

[decipha]

no its not garbage left over.

I did it so those values are populated with sane values rather than being blank. 8d is vehicle speed == vsbar. I have it logging for vsbart_rt which is reverse calculated vehicle speed from the oss on newer ecus. Since the older ecus dont have it I have it showing the vss mph so anything that relies on it such as histograms or my calculate nvbase is correct and still populates.

The payload list shows you the order the payloads are being polled. http://efidynotuning.com/payloads.htm

Your mising the top byte 1f1f for the variable speed fan which a1c doesnt have.

d6 is the atmr1 timer
396 is ipsibr
b6 is ect
b7 is act
etc...

11a is the throttle position sensor voltage which other than iego and iegr is the only useable ad channel to read. On newer maf ecus imaf would be another. The other ad channels are only useful for diagnostics and serve no purpose to log for tuning.

raw ad values usually get passed through rolling average filters then passed through transfer functions to come up with a useable value such as the ect and act. Logging their raw voltage wont give you any useable data for tuning.

That should clear it up for you and make it easy to understand. If not lmk and Ill break it down.