[jonygeorge]

I have an aeromotive fuel pressure regulator and always have to cycle my key 2-3 times to fully pressurize my fuel lines so the engine starts on the first try. I found an old post from 2015 where the same topic was discussed and decipa said he changed the a9l2 base tune so that it would run the pump for three seconds? No mention was made of how he did it just that he did. I am already using a9l2 as my base and would like it to prime for 5 or 6 seconds. If anyone knows which pid to use or how to make this happen on GUFB, let me know. Thanks !

[LeadHead]

Basically the EEC-IV hardware is configured so the fuel pump control circuits by default are activated. Once the processor finishes initializing, the fuel pump turns off. You'd have to hack in some code to keep the pump priming.

Why is your regulator bleeding down? It should be able to hold pressure over night. Additionally it should only take like 1 second to pressure the fuel lines. It sounds like your fuel pump has a bad check valve allowing the rail to bleed down.

[cgrey8]

My old adjustable FPR was the same way. With a fuel gauge connected, I could watch it bleed down in a matter of about 5-10 seconds. And I too had to switch the ignition ON and OFF a few times right before cranking to prime the line. Otherwise cranking took noticeably longer. When I put the 331 in, I just reverted back to the stock FPR which holds pressure just fine.

I only put the AFPR on because at the time, I thought my injectors were undersized...and it was something I could use to toy with to experiment. Once I got a WB, I could see, they weren't but the FPR was already on, so I just got used to having to prime the truck before cranking. I was glad to go back to the stock FPR with injectors that were no where near being undersized.

[jonygeorge]

Thanks for the reply, maybe I’ll look into a different regulator or just eliminating the aeromotive one, actually I think my problem might be related to my having switched to an in tank pump and still having an external regulator at the same time. I installed a gas tank out of a newer model 1998 jeep Cherokee after I had everything all set up for the external pump that needed the regulator and just left it on, I could be wrong but my understanding is that the in tank pump that I am using doesn’t need a regulator at the fuel rails at all and it should be self regulating at 42 psi. Although I don’t understand how that type of pump-regulator works accurately without a vaccume line?

[decipha]

i broke that scalar out a couple years ago, download tunerpro and my gufx xdf, you can simply change the pump prime time scalar to anything you want.

Theres prob 40-50 custom parameters I have added to gufx that isnt in the regular gufb.

[Vortech347]

Decipha,

Is there anyway to get this magical scalar into an older BE2010 with a Tweecer R/T?

[jsa]

Decipha fell out with some here.

If your BE def is plain excel you could add the scalar by getting the info from the xdf and manually adding.

[Vortech347]

Sounds good. I'll research how to do this process. Thank you.

[motorhead1991]

I've added this hack to every tune I've worked on in the last 6 months

[Vortech347]

Motorhead, you wouldn't by chance be able to insert that into my current bin tune?

I did some searching and I can't find GUFX.XLS that Binary Editor will recognize.

This is clearly above my paygrade to get this Scalar into my current tune. The GUFB I'm running is from quite some time ago just downloaded from the Binary Editor website. I saw that there is a GUFX patch, but again, I have no clue how to implement...

[cgrey8]

If it's just a simple exposure of a scalar, let me know what the offsets are for GUF1, GUFA, and GUFB. I can get them added. It'd make a nice addition to the rescaling of BZZTM that was found at fault here recently. With these two things, maybe it'd actually feel like an update to the defs worth releasing.

[Chucko]

The fuel pump prime time in GUFB isn't a calibration PID, it's an immediate constant in this code:

Code: Select all

#################################################################
# Tasklist Routine at 2151, routine offset 2E
# Update fuel pump enable. Skip if flag set.
# turn pump off if more than 1 sec elapsed since last PIP occurred
#################################################################


  Update_fpump:
50ee: 38,d9,11            jb    B0,Rd9,5102      if (Vip_fp_override == 0)  {
50f1: a3,72,be,14         ldw   R14,[R72+be]     R14 = TSLPIP;
50f5: 89,00,04,14         cmpw  R14,400          
50f9: d3,04               jltu  50ff             if ((uns) R14 >= 400)  {          # 1024 = 1 second
50fb: 71,7f,46            an2b  R46,7f           Pump = 0;
50fe: f0                  ret                    return; }

50ff: 91,80,46            orb   R46,80           Pump = 1; }
5102: f0                  ret                    return;

You're looking at a 2-byte constant at 0x50f6 (offset 0x30f6), the units are 1/1024 seconds. The factory value of 0x400 = 1024 = 1 sec.

Have at.

[motorhead1991]

The fuel pump prime time in GUFB isn't a calibration PID, it's an immediate constant in this code:

Code: Select all

#################################################################
# Tasklist Routine at 2151, routine offset 2E
# Update fuel pump enable. Skip if flag set.
# turn pump off if more than 1 sec elapsed since last PIP occurred
#################################################################


  Update_fpump:
50ee: 38,d9,11            jb    B0,Rd9,5102      if (Vip_fp_override == 0)  {
50f1: a3,72,be,14         ldw   R14,[R72+be]     R14 = TSLPIP;
50f5: 89,00,04,14         cmpw  R14,400          
50f9: d3,04               jltu  50ff             if ((uns) R14 >= 400)  {          # 1024 = 1 second
50fb: 71,7f,46            an2b  R46,7f           Pump = 0;
50fe: f0                  ret                    return; }

50ff: 91,80,46            orb   R46,80           Pump = 1; }
5102: f0                  ret                    return;

You're looking at a 2-byte constant at 0x50f6 (offset 0x30f6), the units are 1/1024 seconds. The factory value of 0x400 = 1024 = 1 sec.

Have at.

Yup, offset 50f6 and 50f7. It's technically a hack but doesn't adversely affect things to my knowledge.

[cgrey8]

Just for my own understanding, what makes it a hack vs being like any other scalar that has an offset location and conversion? I'm sure it has something to do with the structure of the code. But being I'm not intimately familiar with how Ford structured the code, the nuance is lost on me.

[Chucko]

The GUFx code, and probably lots of other strategies, are organized such that the code itself doesn't change between calibrations. Only the constants, functions, and tables differ. Those have PIDs associated with them.

This is a "hack" because you have to modify the code itself. There are several other such "hacks" in the existing GUFB strategy, including the patch that reads the zero page registers out of the 8065.

[cgrey8]

In the case of a more modern program where there's storage like a file system with executable files and data files, it's easier to describe what's data and what's code and where it comes from. However in the case of a completely compiled application, it just seems like splitting hairs to differentiate what's code and what's data. But again, I'm saying this without nearly the knowledge and experience reading and deciphering the code as others.

In my head the best I can make of the difference in this case is an opcode that references a register that holds a pointer pointing to the data that the opcode operates on vs an opcode where the data is an operand (no pointer). Is that at least in the neighborhood of being the difference?

[Chucko]

In my head the best I can make of the difference in this case is an opcode that references a register that holds a pointer pointing to the data that the opcode operates on vs an opcode where the data is an operand (no pointer). Is that at least in the neighborhood of being the difference?

Yeah, that's right on the money.

[Jman]

Chucko,
This hack interests me and I see 0x30f6 is 00 and 0x30f7 is 04. 400 in HEX equals DEC 1024 so if I replace the 04 at 0x30f7 with 16 it would be 1600 HEX and that equals DEC 5632 divide that by 1024 and I get 5 seconds of fuel pump prime. Based on the comments I think if the engine conked out then the fuel pump would also continue running for 5 seconds after the last PIP pulse. I don't see this as a problem though.

Curious what you have been entering into this hack for your tunes? I also wonder if this make you have to recalculate the checksum? I was thinking of using a hex editor to change this on my last BE tune (.BIN file) I have and then open it in BE to load it to the Quarterhorse. I'm a BE dongle licensed user and this is on a 91 Mustang GT with A9L.



Thank you
J.W.S.

[jsa]

Yes the change will require a new checksum.

If cgrey has put it in the definition, just use BE to make the change and adjust the checksum.

[Jman]

I looked around and it seems that fuel pump prime is not in the A9L.BEB but I did see checksum scalars in there and for the stock A9L, the base is 0x2000 end is 0x9FFE with checksum being ECDE. Looking around in an untouched A9L.BIN I can see at 0x0A and 0x0B is a DE EC respectively. I tried to highlight with my Hex editor 0x000 to 0x7FFE to see if I could get the same checksum, but it didn't match. I get 48EC and not being very Hex editor savvy so I'm not sure why I can't get the same result.

Is locations 0x0A and 0x0B actually holding the checksum?

Thank you
J.W.S.

[jsa]

Search the GUFB.xls definition for the Scalar Z_PUMPP

Who's BEB are you using?

The xls definition is available from here.
http://www.eecanalyzer.net/index.php/co ... gZ9f6ZDPtY,

In a 56kb single bank bin you will find the checksum at 0x0A & 0x0B.
It's little endian so swap the order of the two bytes.
Your hex editor should give you a checksum of Zero.
0xECDE is the value required to bring the checksum range to equal Zero.

[Jman]

I think the BEB I'm looking at is just what would be saved if I made some changes and saved using a token. When I have use database checked and open calibration then type in A9L it opens up a stock calibration. I can use the Find tool in here and there is no Z_PUMPP found.

I have found it in the XLXS as you suggested if I uncheck use Database then select GUFB.xlxs as the Strategy. I first get an error about no visible tables until I then select a calibration which is one of my .BIN files. Long story short is I was probably using the GUFB.xlxs the whole time and had the last known calibration checked, from the last time I messed around in BE, from a couple years ago.

I was also not looking thoroughly enough for the fuel pump prime setting. I wasn't using the Find tool (Binocular Icon in the upper left) and highly recommend using it anytime you need to search around. Z_PUMPP is a scalar in the scalar agregator under the Fuel aggregator, Binary Editor refers to this as under the Level Fuel if understanding the BE terminology correctly. It's about halfway down that list.

I've never really gotten used to BE just because I'm hobby user with way too much time between uses.

I really appreciate this Forum and hope it continues forever!
Thank you again
J.W.S.