Ok cool. I'll pick up another relay tonight and see where that gets me. I hooked my test light to the actual ground wire connected to the relay so I know ground is good. Now would this cause my lumps not to prime? I assume power runs from BAP to pumps and if the power their is lost then pumps wouldn't operate at all?
Need help with fuel problem.
- Thread starter Stater212
- Start date
Ok cool. I'll pick up another relay tonight and see where that gets me. I hooked my test light to the actual ground wire connected to the relay so I know ground is good. Now would this cause my lumps not to prime? I assume power runs from BAP to pumps and if the power their is lost then pumps wouldn't operate at all?
Alrighty guys well I went and bought a new relay for the trunk and what do you know. Put the key in turn on and THE PUMPS PRIMED!! Took a couple starts but fired right up drove it around the block to let the car relearn everything and so far all seems fine. I wasn't getting power to my BAP with previous relay. The other three connections were fine. When I installed the new and checked power to the BAP with the key on I finally had power. Thank you for all your guys help! I'm going to go ahead and data log the car just to make sure all is good. What parameters do you guys suggest?
See my post above for a handful of basics pids.
battery voltage is another good one to log.
Spark Advance
The reason for your data logging determines what pids. Sometimes you need to know what spark table is been read for example and other times that's of no interest. Here's my basic list
Analog1 (wideband input)
Battery Voltage
Coolant Temp
Desired Idle RPM
Downstream Air Temp
Engine Speed
Fuel Source
Idle Air Integrator
Idle Air Valve Duty Cycle
Intake Air Temp
Load
Long Term Fuel Trim Bank 1
Long Term Fuel Trim Bank 2
MAF AD Counts
Pressure Drop Across Fuel Injectors
Short Term Fuel Trim Bank 1
Short Term Fuel Trim Bank 2
Spark
Spark Source
Throttle Position Absolute
Throttle Position Relative
Vehicle Speed
My car is a return style fuel system though. For returnless add Fuel Pump Duty Cycle too.
Analog1 (wideband input)
Battery Voltage
Coolant Temp
Desired Idle RPM
Downstream Air Temp
Engine Speed
Fuel Source
Idle Air Integrator
Idle Air Valve Duty Cycle
Intake Air Temp
Load
Long Term Fuel Trim Bank 1
Long Term Fuel Trim Bank 2
MAF AD Counts
Pressure Drop Across Fuel Injectors
Short Term Fuel Trim Bank 1
Short Term Fuel Trim Bank 2
Spark
Spark Source
Throttle Position Absolute
Throttle Position Relative
Vehicle Speed
My car is a return style fuel system though. For returnless add Fuel Pump Duty Cycle too.
Last edited:
You log all of that at once? My list wasn't that long and Don Lasota told me not to log so many things at once as the log will be jumpier.
Agree. I typically have 14-16 max. If the car has issues I will adjust based on the issue or create a new configuration file for it.
But nobody has really said how many is too many. I just know on a mechanically sound car that 14-16 is all I need.
Last edited:
I do. Sometimes more, depends what I'm doing. Remember data log upper case PIDS over lower case. They are enhanced by SCT for faster response. Sometimes you'll hit some that only lower case is available. In those cases select them.
Also you get a choice now days of rapid packet mode data logging or the normal slower mode? You will see this prompt after selecting the PIDS. If you have a PID in there that does not support rapid packets as they call it the whole thing will default to the slower version. I have none.
Lastly you can confirm if you're data logging correctly or not but opening up a log file and looking at the time column. As I recall SCT data logs 42 times a second. Take a look. If you're seeing less and jumps and skips in the time line it's having an issue and you need to adjust. If it's running smooth enjoy.
BTW it appears to be the limit of the SCT stuff we hit prior to the OBD2 limits. I've been playing with my own little data logger I built. I got a EML327 chip hooked up to my OBD2 port which decodes the protocol etc. and feeding it to a blue tooth master chip (I've since eliminated that part and just use a cheap ebay bluetooth OBD2 piece like what guys use to feed their torque app). I then build a little LCD screen setup with a blue tooth slave and also integrated into it is an SD card for data logging. I wrote the code to write the files in SCT format so I can pop the SD card out and put in my laptop and open up with SCT livelink Gen 2 and view as though I'd data logged with my X3.
The beauty of my device is I see all the PIDS all the time without a laptop. I can configure up to 18 at a time to display when maxed out (screen capacity issue) and the best part is at any time I can hit a button and it starts data logging. The main reason I came up with it.
Here's an old video I found of when I first got it working. Ignore actual values, some was correct, others I was still working out. It's still a work in progress but much further along now.
[video=youtube;cqmjXSLObrQ]https://www.youtube.com/watch?v=cqmjXSLObrQ[/video]
Anyway my point was the number of PIDs I was data logging in SCT was just fine.
Interesting. With the gen 1 livelinks I was always told to use the lower case pids. I still use version 6.5 on some cars and gen 2 on others.
the thing I hate about livelink and advantage is how long they take to load. I can go drink a beer and come back and still be waiting for advantage to load. I deleted it all and reinstalled. Same thing. SCT needs to fix this
the thing I hate about livelink and advantage is how long they take to load. I can go drink a beer and come back and still be waiting for advantage to load. I deleted it all and reinstalled. Same thing. SCT needs to fix this
Last edited:
Yeah there's a lot about SCT they could improve upon. It's a love hate relationship lol.
Technically lower case are PIDS and uppercase are DMRs. DMRs will provide faster data rates and are more accurate. They do use more resources though so if your laptop is slower or resource constrained go for the lower case.
Users who are viewing this thread
