[xafalcon]

OK, I'm looking at ways of getting a Quarterhorse to datalog on my Auzzie ecu which does not have the patch code. This is where I have come up against a wall. Not knowing how to develop the patch code (any help on this much appreciated)

But I've been thinking about the situation and have come up with a possible interim solution I'd like some feedbck on while I continue patch code research. Can I run the Auzzie EEC4 ecu and a quarterhorse with an A9L binary loaded? Will this then allow me to datalog as if I had an A9L ecu physically installed? ie use datalogging patch code that is available for the A9L ecu?

I have run the engine with a stock A9L binary on the Auzzie ecu and it starts & runs. The only KOEO codes I got were expected - no BAP, TAB, TAD. I did not run KOER, ran out of time.

Thanks in advance

[mpaton]

OK, I'm looking at ways of getting a Quarterhorse to datalog on my Auzzie ecu which does not have the patch code. This is where I have come up against a wall. Not knowing how to develop the patch code (any help on this much appreciated)

But I've been thinking about the situation and have come up with a possible interim solution I'd like some feedbck on while I continue patch code research. Can I run the Auzzie EEC4 ecu and a quarterhorse with an A9L binary loaded? Will this then allow me to datalog as if I had an A9L ecu physically installed? ie use datalogging patch code that is available for the A9L ecu?

I have run the engine with a stock A9L binary on the Auzzie ecu and it starts & runs. The only KOEO codes I got were expected - no BAP, TAB, TAD. I did not run KOER, ran out of time.

Thanks in advance

BE can now do a reasonable attempt at generating its own patch code, based on looking for a code sequence. It isn't foolproof, but I haven't heard of any complaints of it not working. On QH, the patch code is only for datalogging variables that live in CPU registers, that is addresses 0x0 to 0xFF on 8061 and 0x0 to 0x3FF on 8065. If you have a non encrypted def file, you can see which PIDs you can log with patch code and which you'll need patch code for. I guess that should be "working patch code" as I imagine BE will object to datalogging with no patch code at all. Post the bin, and I'm sure we can get you patch code.

Patch code goes with the binary, so if you can run your engine on an A9L CORRECTLY, as opposed to just seeming to run OK, then what you datalog may well be correct. But it could be that your ECU hardware feeds data into places that a foreign binary can't find it. And it may then send outputs to locations that never send it to the output pins.

[decipha]

yeah what he said

[xafalcon]

It would be highly appreciated if you were able to help with the patch code development for my ecu.

Here is a 64k bin (an unmodified one). In case you need some details about the ecu's original fitment, this is a summary of the OE setup which is very close to what I run now.

The ecu is a mid 1991 "1DGA" box code. The processor is an 8061 with 15MHz crystal. It runs a BAP sensor & EGR, but no TAB/TAD from the factory (THRMHP = 0). This ecu is for use with a locally manufactured automatic electronic controlled transmission & tcm, rather than an AOD. There is a link from the ecu to tcm to signal A/C status & engine overheat (to alter transmission adaptive learning or operating strategy respectively), and a seperate link from TCM to ecu to signal reverse gear (impliments torque truncation & is the default setting if the link is severed/disabled).

I have mapped the Aussie binary to the A9L using hex comparison. The code seems very similar to A9L.

I intend to use BE/EA for future tuning if I am able to get a Quarterhorse to work successfully

If you need anything more just let me know.

Thanks again for your help

[mpaton]

I have mapped the Aussie binary to the A9L using hex comparison. The code seems very similar to A9L.

I intend to use BE/EA for future tuning if I am able to get a Quarterhorse to work successfully

If you need anything more just let me know.

Thanks again for your help

So does this mean that you know what locations you want to log, and where the important scalars, functions and tables are?

In other words, is it correct that you are able to build yourself a def file for your bin, except that you don't know how to do the patch code?

The patch code is simple, finding all the other stuff is lots of work. Congratulations of you've done it. If you haven't, then there is a whole lot to do beyond the patch code.

[xafalcon]

I have made a definition with 90% of the corresponding A9L/GUFB parameters identified. I used the TunerPro GUFB definition as the reference and I have imported an A9L ecu that I read the binary from. Then I used hex matching to tie down the location of a range of parameters in my ecu. Next I used Excel to map the "data shift" (A9L address to my ecu address) to help speed the remaining conversion. Note that this "data shift" was variable (a few bytes added or removed from A9L code at various points), and became more random in the lower addresses. Finally I did a side by side comparison with A9L stock values to confirm the above. All up it's around 60 or more hours of staring at a pair of hex editors or a pair of PC screens. I did not bother with most of the remaining 10% of the TunerPro A9L definition data conversion as it relates to Self Tests, Alternator control, Cruise control, EPT, Errors etc.

I've also used my definition to burn some chips to confirm many common parameters are correctly mapped. All OK so far.

Looking at the BE GUFB.xls V84 document I have on file, I have defined most of the parameters on pages Scalars, Functions, Tables. I have not defined Payload (although taking a quick look this seems do-able in an hour or so). And Qhorse is where I have come unstuck. This page make no sense to me at all. The data at these locations in the A9L binary are all FF's so my data matching/comparison method simply doesn't work.

I think this means I only need the elusive "patch code" but as I'm not 100% certain of that, I included the above info of exactly what I have and have not done so far.

Should I start mapping the parameters on Payload page? They sound alot like datalogging targets.

Thanks again for your help, it would be great if I could use the Quarterhorse with the original Auzzie binary as it simplifies everything (from my perspective).

If you need any additional info, I will do my best to supply it.

cheers

[mpaton]

Looking at the BE GUFB.xls V84 document I have on file, I have defined most of the parameters on pages Scalars, Functions, Tables. I have not defined Payload (although taking a quick look this seems do-able in an hour or so). And Qhorse is where I have come unstuck. This page make no sense to me at all. The data at these locations in the A9L binary are all FF's so my data matching/comparison method simply doesn't work.

Good for you. That's a lot of work. What you're missing is that when you have a 64k binary, the first 8k is RAM. The binary data is really somewhere in the last 56k. BE uses the Ford tuner convention from way back, which is that addresses given are offsets into the bin file, not actual 8061 addresses, EXCEPT when they are addresses in RAM(like Payload Tab addresses), or data to be put into EEC RAM, (like QH or Tweecer addresses). That means that the offsets into a 56k bin file are different from those in a 64k bin file or in EEC memory. It's kind of a goofy choice, and it doesn't extend well int0 8065 addresses, or cope well with different sized bins, but there it is. You probably missed an offset when you found all FFs.

I think this means I only need the elusive "patch code" but as I'm not 100% certain of that, I included the above info of exactly what I have and have not done so far.

Should I start mapping the parameters on Payload page? They sound alot like datalogging targets.

The Payload tab should contain any RAM data you might ever want to data log. The addresses will be actual EEC-IV 8061 addresses, no offset.

You can try the attached QH tab. You can compare it to the GUFB QH tab. All that's changed is the address where the patch code is located, and a single absolute address pointing at the start of the data part of the patch code.

[xafalcon]

Thank you so much. I am very greatful for you taking the time to do this. I can now buy myself a belated Christmas present - a Quarterhorse & BE/EA.

Thanks again

[decipha]

i think in the end when it comes down to it you'll be more interested in running the gufb strategy and making your tune from an a9l bin

also if you can find any info on the gure strategy that may have more things in common with your specific strategy, it could give you a pretty good idea of the guf strategies as well as they are very much alike

i did something kinda similar to what you did not too long ago to make a pcaf5 strategy for BE so i could tune my moms 99 explorer, i still haven't figured out the payloads im not even sure if i want to but when and IF that time comes i guess i'll have to plunge further into this disassembly stuff than i would really like to

in any case mpaton is a bright fella, i spoke with him not too long ago about finding the look up routine for the maf transfer in the guf strategy, he kindly gave me some input and when i went and looked it up it all made sense.. thanks mike

anyway good luck with it and when your done if you want to share it send the strategy to clint garrity so he can post it

[xafalcon]

Right, I've re-read your reply (several times because the first time I didn't quite get it) and from what I understand the "Payload" and "Qhorse" hex locations in a 64K binary are exactly at the location specified by the address ie for A9L Payload ACT @ 00B1, RPM @ 00AE-F & for the Qhorse @ 84B2 - 852F. Whereas the binary is located at the specified address plus the offset ie. for A9L BAP sensor present switch @ 747B + 2000 = 947B

I had previously been adding the 8K offset (hex 2000) to all the addresses, hence why the data matching appeared not to work for the "Qhorse". Just as you thought might be the case

I can now see the data match for the "Qhorse" patch code and the modifications you highlighted. Thanks for explaining that so clearly. I can see what you did and also why you did it.

But unfortunately my method of hex code matching for the "Payload" won't work as I previously thought it would (now that I know NOT to add the offset to the specified locations). However I've had a good look through GUFA, GUFB & GUF1 "Payload" locations and they seem to be the same. I'm hoping you will be able to confirm that these RAM locations are common for ecu's built with this architecture & very similar code. If not, what is the method of mapping?

decipha - you are right, for speed and simplicity I would prefer to run GUFB/A9L due to the wealth of knowledge & support. But my car is an (Auzzie) electronic auto with some unique data links between the ECU and TCM / EAT that I would prefer to maintain if possible. Plus I like a challenge, and this way I'm learning how & why rather than just "using".

[86GT]

I have not read through the entire thread so forgive me. I do know that Derek AKA sailorbob has a few of the AUS strategies broken out and he has datalogging working on them. He maybe a good person to contact.