Jump to content


  • Content Count

  • Joined

  • Last visited

  1. I'm building out a new wiring harness for an FD RX7 project that is running a G4+ Fury that has a Continental flex fuel sensor. According to the Link help file wiring diagram for this brand of sensor, it says to connect the sensor's ground pin to the "Ground Out" (green wire on the "A" connector if I were to use the Link wiring loom). The previous owner simply grounded this sensor pin to the engine block. Does it make a difference? The sensor seemed to be working fine in that configuration, as I was seeing good data from the sensor in the logs. Thanks, Pete
  2. Related to this topic, is it possible in PCLink to combine multiple log files into one very large log file so that the mixture map feature would have more data points to work with? Basically the idea is to have the PC collecting data every time I'm on the road with it, and then use the conditional & transient filters in the mixture map tool to effectively utilize it.
  3. I didn't even consider "fan 2" because that fan is not actually being controlled by the ECU - another one of the previous owner's wiring faux pas I have to fix when I rewire the car. He actually had the 2nd FD fan wired to come on constantly as soon as the ignition switches on, and the main FD fan is controlled as "fan 1" by the link. So for now, while temps are still cool here, I disconnected the 2nd FD fan (so the car can actually reach operating temps), and have been relying on the main fan, controlled by the "fan 1" settings. Anyway, I see what you're referring to - I went ahead and changed "fan 2" to come on at 212*F, and changed the "fan step" in the idle settings from 3.0 to 0.5. Idle is behaving reasonable well with those settings. Attached is the current tune file and a log from cold start, warm up & some driving and idling around town thru a few fan cycles. About 13 minutes worth. Log 2020-03-21 10;32;44 am.llg Baseline Tune - with Link Updates v006.pclr
  4. I think I get the gist of how the Mixture Map tool can be used to help tune your fuel table with log data, but I'd like to confirm a few things to hopefully make my road tuning an efficient & productive process. Goal is to get as much of the N/A and low boost parts of the map cleaned up before I invest in some dyno time to do the rest. Attached is a screen shot of my current mixture map properties settings. As I understand it, if I set this up right, it will filter the raw data so that only the useful bits of data go into the suggested fuel table corrections. Generally, I assume more samples is always better, so I set the minimum at 100 -- can I get good results with less? I know I'd cover more of the map with less drive time that way, but I am concerned about the quality of small sample size calculations. As you can see, I'm setting a few conditional filters that will only accept data that is: (a) Above operating temperature, so that all warm-up enrichment's are zero at these temps and above; (b) RPMs at idle & above; (c) Overrun/Fuel cut is not active (0 or off state) as that would skew actual vs. target lambda. I also have the closed loop lambda (CLL) turned off for the road tuning. Are there any other conditional filters that might be better options here? I also set a transient filter for Accel Fuel < 0.1 units/sec. If I'm understanding the transient filters correctly, it should only accept data when the Accel Fuel added is between 0 and 10%. My understanding is the mixture map tuning works best when the cells are as close to steady state conditions as possible, correct? Is there a better way to filter out accel fuel trim transients? For the "% of zone", I'm not sure I really understand what that means, but from experimenting, it seems that the lower the % value is, the fewer cells get filled in, given the same # of samples and other conditional & transient filters - is there a good trade-off number here, and what does it really represent? I'm currently using 50% Thanks!
  5. Ok, thanks! I reduced the deadband to 25RPM and reduced the idle base position to 0.7% (from 1.0) for ECTs above 194*F and did some testing/logging today. I don't think the ECTs made it much past 190*F on this drive, so it's possible the idle base position tweaks didn't come into play. Attached is the current PCL file, and here's a link to my Google Drive where you should be able to get the log file: https://drive.google.com/drive/folders/14YW4Yrme85dJZxLmVlBplBXHdVE6ezdI?usp=sharing There's about 23 minutes worth of data there, from cold start through warm-up cycle, and driving around town with several stops idling at traffic lights Baseline Tune - with Link Updates v005.pclr
  6. Thanks Simon, I ended up figuring that out for myself just by dabbling with the firmware update menus in PCLink. I updated my FW to the most recent version that my copy of PCLink had on file - there were 2 FW versions in the firmware directory, so I updated to the one with the highest revision # and latest file date. On the FW topic, how frequently do you guys release FW updates? I don't have my version # handy, but since it came with my copy of PCLink that I downloaded in November 2019, it can't be any newer than that - have any FW updates been released since then? You nailed it Adam, the timing & idle tweaks you provided pretty much solved my idle problems! I applied all of the tweaks you provided as-is and reverted the fuel table back to my original base map to correct those bad cells and did some testing. Starting up from cold (ambient temps ~50*F), it fired up easily, and idled almost spot vs. ECTs on to the base idle target table as it warmed up. Once at operating temp (ECTs > 176*F), the idle speed overshot the target slightly by about 50~100 RPMs with a very small hint of hunting around its attempted idle target. Much more stable than before though. First thing I think I should try to refine it further is to just reduce the base idle position table values from the current 1.0% down to perhaps 0.5% in the cells 176F and higher. That should get me closer to the target idle when warmed up, and if the current PIDs are good enough enough, result in less hunting around the idle target.
  7. Thanks Adam, I'll give these suggestions a go. Probably a dumb question, but is there a download link somewhere on this site for the current G4+ firmware? Can't seem to find it anywhere. On the fuel table, I think I misused the VE Mixture "correct fuel table" feature - accepting a bunch of changes to the fuel table prematurely, based on too few samples/bad data. Easy fix there, just go back to my original baseline. Regarding timing at idle, I've had good results in the past setting the idle region around 12~15* BTDC on similar 13BT / 13BREW builds; that additional advance typically results in a smooth idle and a nice throttle tip-in. Basically it perks up the throttle response a bit as you drive off normally in NA mode. But this is the 1st time I'm trying it with a non-stock TB, which I suspect could be another problem here. The stock mechanical TB has mechanically linked primary & secondary throttle plates; the secondaries don't crack open until the primary opens a bit, and even then there's a double throttle mechanism that which blocks the secondaries until the coolant reaches operating temp. Air delivery with a single 90mm DBW throttle is a very different beast, unknown territory for me.
  8. I'm having difficulty getting my E-throttle equipped FD to achieve a stable idle at about 1K RPMs when warmed up - the idle will hunt wildly above & below that mark by a few hundred RPMs, and sometimes stall with no load on the motor. The car starts up fine, settles into its higher cold idle target, but as the coolant temps start approaching about 80*F and go hotter, the idle starts hunting - which just gets worse as the idle target RPM drops and temp increases. Oddly enough, the car runs OK when it's under load - if I drive off, AFRs stay reasonably close to the cell targets, though the VE table still needs a bit of tuning. I attached the car's current tune, hopefully someone can take a look and point me in the right direction on how to fix this? Would have attached a log, but my logs were too large to attach here. Anyway, here's some pertinent background info on the car's setup as I got it from the previous owner: (1) New Mazda 13BREW short block (no compression issues); (2) Single BW S364.5 SXE turbo, 1.0 AR turbine housing; (3) Fuel injectors - Bosch 1000cc EV14 primaries, Bosch 2200cc EV14 secondaries; (4) Rest of the fuel system is a Fuel Lab pressure regulator, and there's a fuel pressure sensor wired to the Link. Fuel pump is still the stock FD pump driven by new relay/wiring (simple on/off control); (5) DBW throttle is a 90mm GM e-throttle body with a custom fabricated adapter to mate with the intake manifold, which is a Cosmo 13B-RE upper & lower intake manifold. Thanks! Baseline Tune 0947-3-15-2020 v002.pclr
  9. Thanks Adam, that's a great explanation and it answers what would have been my next question regarding dwell settings. Besides the fact that these coils don't need more than 3mS dwell in most situations, your math confirms the previous owner had his dwell settings set WAY too long, and backwards -- 7.0mS at the RPMs above 6K which clearly would not end well! Luckily for me the motor is new and still being broken in at under 4500 RPMs, so no fried coils or a blown motor. I've updated the old dwell table per the attached file. For voltages above 13V, and RPMs below the 8K redline, I have dwell set at 3.0mS. I reduced that to 2.6~2.5mS for voltages above 14V and RPMs > 8K to protect the coil from overheating. At voltages 12V or less, and RPMs under 1K, I bumped up the dwell to 4.0mS. Thought there was to get a hotter spark during cranking/start up, and to help promote a smooth idle when the electrical loads on the system are high (e.g., lights, AC & e-fans operating) Ignition Dwell Control (ms).lte
  10. I just wanted to confirm that I'm using the correct spark duration settings for my coils. The car is a single turbo S6 RX7 FD that is running AEM IGN1A smart coils in direct fire/COP mode. According to the coil's spec sheets that I downloaded from AEM (see attached), it lists an "Arc Duration" specification of 2.9mS (+/- 10%). Am I correct in thinking that "Arc Duration" is the same thing as "Spark Duration", and I should be plugging that 2.9mS value into my G+ Fury? I'm somewhat confused, as the car seems to be running fine with its current setting of 2.0mS from its prior owner, and the Link help file for this parameter states typical values range from 0.5 to 1.0mS. Thanks! 30-2853 High Output Inductive Smart Coil.pdf
  11. Thanks! That detailed explanation helps a lot. Looks like there's no need for me expand beyond the 16 x 11 limits of the trailing split table.
  12. Hi, I'm working on a modified single turbo FD that is running a wired in G4+ Fury that I purchased recently. While reviewing the prior owner's timing settings, I noted that his "Ignition Table 1" (aka Leading timing) and his "Trailing Split" table (trailing timing) had a different # of columns & rows, and different axis values assigned to them. I noted that the base S6 RX7 map that Link provides also has different axis values -- e.g., "Ignition Table 1" goes from 0 to 8500 RPM, while "Trailing Split" is 0 to 7500 RPM; "Ignition Table 1" uses MAP(psi) from 0 to 35.5, while Trailing Split also uses MAP, but from 0 to 36.2 Since it's my understanding that the actual trailing timing (i.e., when trailing plug fires) is based on the cell in the Ignition Table 1 plus its corresponding cell value in the Trailing Split table, shouldn't one use the same axis values on both tables for engine speed & load? In this case, the 2 tables have a different # of rows & columns, and the end limits differ, so what is really going on to set trailing timing? I tried to change the trailing split table axes to match up with the "Ignition Table 1" axis values, but PCLink would not allow me to add the additional columns/rows that were necessary. Is this a limitation for this particular table? If it's not a hard limitation, how do I add rows/columns to the table? I followed the steps in the help file to add rows/columns, but it didn't work as expected. Thanks!
  13. Thanks Adam. Per the FD wiring diagrams I have, the highest resistance across those cruise mode switch terminals is 910 ohms for the "resume/accel" function. It's 240 ohms for the "set/coast" and a 0 ohms/short circuit for the "cancel" function. I'll verify those with an ohmmeter when I have a chance. For the mode control, I'm thinking I'll want at least 2 boost tables - 1 for full boost, and 1 that is a lower boost profile. Both of these would use the same direct linear proportional DBW table, i.e., 0% accel pedal = 0% throttle position & 100% accel pedal = 100% throttle position. Then I'd like to add in a 3rd driving mode, which would be a "valet/wife/kids" mode, that would be drive-able but would feel a lot like a normally aspirated 13B FD might - Thought there is to set up a 2nd non-proportional DBW table (e.g. 100% accel pedal = perhaps 50% throttle position), and pair that with the lower of the two boost tables. Does this make sense?
  14. After the great responses I got last time, I did some digging into the FD wiring diagrams, and did some refining of my Link Installer I/O table. I'd appreciate some feedback on the revised installer I/O table (attached), to confirm I'm on the right track and to answer the new cruise control related questions below. To reiterate on my specifics, I have a modified '93 US market RX7 FD that is managed by a Link G4+ Fury. It runs a single turbo (BW) and has a GM drive-by-wire throttle body adapted to it. I'm putting the factory Oil Metering Pump back on, and I'd like to use the factory cruise control switch gear and the G4+ to implement a cruise control functionality with my DBW throttle. On to the questions: 1. Reference how I intend to use Analog Voltage Input #6, for cruise control "cancel" "set/coast" and "resume/accel" functions, will this work given that the factory cruise switch gear uses momentary contacts? Since it's a 2 terminal device, I assume I'll need to use an external pull-up to the +5VDC supply; what value pull up resistor should I use with this? 2. Since I'm out of analog inputs, but still had plenty of DI's, instead of using a 12 position trim pot for a DBW/Boost control mode select switch, I was thinking I could do the same with the free DI's. Two DI's would get me up to 4 discrete DBW/boost control modes programmed by just using 2 SPST switches (e.g., binary 00, 01, 10, 11 = 4 possible modes which is enough for me). Sound like a plan? 3. I should be able to use the CAN bus port to drive a CAN bus gauges/display devices (e.g., BTI, GaugeArt, etc) in lieu of using DI9 & DI10 as I previously though, assuming I terminate the bus properly, correct? Thanks in advance! Link G4+ Fury IO Installer Table (Rev B).pdf
  15. ^ I might be able to do what you suggest. below is the schematic for the factory cruise control switch. What's not shown below is there is another "cruise main" switch, which is a latching switch that routes power to the cruise control unit. I'd assume I'd route the "cruise main" switch to a digital input, to engage the cruise functions. Similarly, brake and clutch switches would be digital inputs as well to cancel cruise on demand. As you can see, there are three control switches on the steering wheel assembly for the "set/coast", "resume/accel" and "cancel" functions. The problem might be that all of these are momentary contact switches - so if connected to a spare analog input (with a pull-up resistor wired in since this is a 2-wire switch assembly), the G4+ would see the max voltage normally (~+5VDC) when no switches are being pressed, and depending on what those resistor values are, the G4+ would see different voltages while the driver is pressing on any of those 3 switches momentarily. Could the G4+ be programmed to respond to momentary changes in an analog voltage in this manner?
  • Create New...