Pete_89t2

Yesterday I applied the suggested changes to the CLL rate below 3000RPM, reduced the anti-stall gain to 1.5 and went for a test drive. The near stalling and wild idle & lambda oscillating behavior is gone now, but you're correct that I still need to adjust the idle base position table and probably the base E-throttle target, fan & AC steps - the idle was still overshooting frequently, taking a long time to converge on idle target and sometimes oscillating, though not with wild swings in magnitude like before. Didn't have the time to tune it further yesterday, but before shutting it down, I let it idle at full operating temp for a while to collect log data. After looking at the logs, idling with the ECT at 190~194*F and both E-fans running, I was seeing the E-throttle ISC Trim between -2.8 and -3.8 whenever the idle status was reading RPM Target, so on average it looks like I need to go -3.3 total. Same conditions, but with the AC on, the ISC trim was at about -4.3 to settle on RPM target. Will test & tune this further today, but here's the plan: - Reduce E-throttle base target for idle from 4% to 3%; Reduce Fan Step from 1.5% to 0.5% - these two should take -2% out of the -3.3% ISC trim average - Reduce the AC step from 3.5% to 2.5% - This change plus the above changes should take -3% out of the -4.3% ISC trim when the AC is running - Start the car cold & run the car at idle while monitoring the run time data for E-throttle ISC Trim & RPM target, making adjustments on the Idle Base Position table as needed to null the ISC Trim to as close to zero as possible when the car hits its RPM target. This should get the table right from whatever temp it is at startup to full operating temperature.

Thanks Adam. I'll try reducing my CLL update rates below 3000RPMs as suggested first and see if that improves things at idle & below 3000RPMs. I need to take a closer look at some of my other logs for the higher RPMs, but previously I was using slower sample rates and slightly lower CLL gains across the board, but found that CLL was rather slow to converge on target lambda's, especially above 2500 RPMs or so. It wouldn't oscillate around the target lambda, it was just very slow to converge from whichever direction (rich or lean) that it needed to go. Which I think means that my gains & update rates >3000 RPM are probably close to where they need to be? I'm using the 3D CLL correction table to allow +/-10% CLL correction in vacuum, but in boost I'll allow it to go up to +10% richer, but limit the % fuel I allow it to pull out based on boost level (more boost ==> allow less % correction in the lean direction) Ok, if I understand correctly, first thing to do here is to reduce just the anti-stall gain to 1.5~2.0, and then if I still have idle overshoot/stability issues, try playing with the E-throttle target/Idle base/fan step, using the E-throttle ISC CL trim data from logs to inform how much/which direction to tweak those? I initially got the E-throttle step, Idle base position & fan step numbers all set up before CLL was enabled, and idle was pretty stable back then, so is it safe to assume only the anti-stall gain is really out of whack here? Interesting, I have E-fan 2 set for 2*F hysteresis, but because it only has +/- 1* resolution that's effectively the same as setting the hysteresis to 1*? I'll increase that to 3~4*F then. FYI, these are not separate fans, but multiple speeds for a pair of fans that run together. I basically replicated the FD's OEM fan operation - when EFAN 1 comes online, both fans start at low speed; when EFAN 2 comes online, both fans speed bumps up to medium speed. If the A/C is turned on, the factory wiring bumps up the fan speed one level from whatever speed it was running at the time, or if not running, starts the fans up at low speed

I'm a bit stumped at this point trying to solve a somewhat intermittent idle stability issue I'm having with my FD. It will sometimes have an unstable, oscillating idle where idle speed error swings wide of the target in both directions and may sometimes even get close to stalling. It does this most frequently when returning to idle speed from low speed/low RPM/light load maneuvers, like you would have in a parking lot or for example when I come to a stop/idle after goosing the throttle to climb the slight hill up my driveway to park in my garage. This Google Drive link contains my current tune file and a PC log of it behaving this way: https://drive.google.com/drive/folders/1HPzL_D1X3PD_X1ck0d3zerRav5QcjCgG?usp=sharing You can see the erratic idle behavior happening between time index 7:02 - 7:28, after I stopped for a traffic light where the idle was simply a bit unstable but never close to stalling. At index 9:00 - 9:35, again after stopping for a traffic light, the idle was consistently overshooting the target, and then towards the end of that period it started to oscillate wildly. Just after index 12:12, which was after I pulled car into my garage (i.e. low RPM/higher load to climb driveway hill), it returned to an unstable idle with several near stalls until the end of file when I shut it off. Since I also have closed loop lambda control enabled at idle, and the Lambda1 is oscillating around the target lambda while idle is acting up, I'm not sure if this is a chicken & egg issue - unstable idle control causing the unstable lambda, or CL lambda instability causing the unstable idle? Anyway, I would appreciate any tips I could get to help me figure this out from the more seasoned experts.

Thanks Adam for the clarification & diagrams, that was very helpful in helping me visualize how Mazda's oddball port timing references relate to the typical TDC compression cycle reference ECU's typically use for tuning. Now I see why 130*BTDC injector timing makes sense for a stock ported 13B-REW. I've got one of those illustrated GIF animations of a rotary engine on my computer somewhere. If I get ambitious I'm going to see if I can edit it to overlay the above info into it to try to illustrate this for a complete 4 stroke cycle of the 3 rotor faces (i.e., 3 revs of the E-shaft, 1 full rev of the rotor).

As another guy with a rotary (FD, 13B-REW with stock ports), I've been trying to understand how Injection Timing relates to the rotary combustion cycle. FWIW, I've been using the default 130* BTDC Injection Timing figure that is provided in Link's base maps for the S6 & S7/S8 RX7s in mine, and it seems to work pretty good. I understand Adam's point that you want injection to start as early as possible on the intake stroke, but after the exhaust port closes. But where I get completely confused is reconciling Adam's statement "the exhaust port generally closes around 130BTDC" with what I'm finding in the FD's factory shop manual, which specifies the exhaust & intake port opening/closing timing metrics as follows: Intake Ports: Primary Opens @ 45*BTDC; Secondary Opens @ 32*BTDC. Primary Closes @ 50*ABDC; Secondary Closes @ 50* ABDC Exhaust Port: Opens @ 75* BBDC, Closes @ 48* ATDC I'm assuming Mazda means "BBDC" = before bottom dead center; "ABDC" = after bottom dead center; BTDC = before top dead center and ATDC = after top dead center. The math & understanding here would probably be simplified if we had a consistent definition and usage of these metrics relative to the rotary combustion cycle.

^Absolutely. Could be a faulty fuel pump, wiring associated with the pump, fuel pressure regulator, clogged fuel filter or anything else applicable to your fuel system that could impact fuel pressure. Your differential fuel pressure should be relatively flat & constant - no crazy swings far from your base fuel pressure setting

Copyninja, Just curious - your question implies you're able to measure AFRs independently for each rotor, which means you must have dual WBO2 sensors fitted. Is this a turbo or N/A rotary and how/where did you mount the dual WBO2 sensors? Thanks, Pete

Looks like my attachment limit is blown, but here's a quick cut & paste of the charge temp approximation table from my tune file. Top row is at MGP = -15psi, from 0 RPMs (left most column) to 7000 RPMs (right most column). Next row down is at MGP = -7psi, 3rd row down is at MGP = 0psi (transition point to positive boost). All the rows under that are in positive boost (MGP = 7psi, 15psi & 22psi). FWIW, my FD is running a stock ported 13B-REW with a 13B-RE Cosmo upper & lower intake manifold, GM 90mm DBW throttle. Port matching was done to match the REW ports to the Cosmo LIM runners. It has an efficient large core IC in the stock mount configuration with dedicated cold air ducting, and I fabricated a cold air intake to supply fresh air to the turbo (single BW SXE 300 series). My logged IATs typically run no more than 20~25*F higher than whatever the ambient air temp is. 8 7.5 7 6.5 6.5 6 5.5 5 6 5.5 5 4.5 4.5 4 3.5 3 3 2.5 2.5 2 2 1.5 1.5 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Note that this table works fine assuming a cold/warm start & drive off under MOST conditions. If you get yourself stuck in traffic, or for the first several minutes following a heat soaked hot start where IATs typically soar, these numbers result in charge temps that are significantly lower than reality, at least until you start getting some airflow going to relieve the heat soak condition.

I did manage to get a charge temp table sorted out, which has worked well for all conditions except for a heat soaked start up & idle. In that case, I'll still experience some idle instability for a minute or two after a heat soaked startup. To correct that, I've been thinking of adding a 4D fuel trim to tweak my fueling only under heat soaked start up conditions, so the 4D correction table axes would be something like charge temp vs time after engine start, and corrections would null out to zero after say 1 minute of run time I also watched that HPA webinar you linked, and I'm also lacking a dyno. So I did it on the road by analyzing my log data to iteratively improve the charge temp approximation table. Since I had a 2nd IAT sensor fitted in the upper intake manifold (UIM), I used data from logged that sensor, as well as logs from my faster responding IAT sensor (located in the charge pipe), and logged my coolant temps, RPMs & MGP/MAP data to do some data comparison under all conditions to tweak the table. Goal was to get the charge temp that the ECU calculates as close as possible to the 2nd UIM IAT sensor's reading under steady state driving conditions (i.e., when you would not expect to see much change in IATs).

I just went to check that. The MAP (using a Link 4 bar MAP sensor) was reading 14.5psi, BAP was reading at 14.4psi. Since they differed, I ran the MAP sensor calibration from the PCLink drop down, and after that both readings were sitting at 14.4psi. I agree the 14.7 vs 14.5psi BAP is a small difference, and probably won't noticeably effect idle. I just find it odd that BAP is reading off from it's usual sea level norm after this trip, but didn't do that last year.

Some background info first: I live and normally drive my car at sea level, so I'll normally see a barometric pressure of at 14.7psi in PCLink or in my logs almost 100% of the time. Sometimes that baro reading may be slightly lower or higher at 14.6 or 14.8, if there is an unusually low or high pressure weather front moving in, respectively. Normal behavior I'd expect. I just returned from a road trip to the Smokey Mountains where I had driven my car (FD RX7, single turbo build) up to about 6000 feet above sea level, and while there I noted that BAP would change relative to altitude, and those readings went as low as ~12.6psi BAP, which sounds about right. Upon returning home to sea level though, I've noticed that my BAP readings are on the low side - I've been consistently seeing 14.4 to 14.5psi BAP since returning, which seems odd. Last year when I made this same trip (annual Deals Gap Rotary Rally), my BAP sensor read the usual 14.7psi upon my returning home to sea level. Also I've noted that since returning, and while there at the high altitude, my idle stability is a bit off, though no changes were made to my tune file before or during the trip. So I'm wondering if the Fury's internal BAP sensor might have a part in this? Questions - Are these symptoms indicative of a failing internal BAP sensor? If so, is that something that Link can repair? Thanks!

I had the similar problem yesterday trying to post a new topic to the G4+ section. Initially I included a Google drive link to my tune file with my post (subject: DBW problems, G4+ Fury), but that attempt to post was blocked. I then edited out the the Google drive link, and it allowed my post to get published on the forum.

You nailed it Adam. Turns out I had a slightly loose/intermittent connection at the GM throttle body connector which apparently caused the TP tracking error, which disabled the DBW relay (code 73). Found it by jiggling the connector shell, and then subsequently re-pinning the connector. After doing that, and running the APS & TPS calibration all is good to go.

Today after driving the car & shutting it down normally, I encountered to following errors upon keying it back on with the laptop connected: ECU Fault Code 73, Aux 9/10 supply error and ECU fault code 76, TP(main)/TP(sub) tracking error. Obviously this error puts the engine in the limp home/crippled mode. I didn't attempt to start the car, but went straight into electrical troubleshooting. Checked out the relays (ECU main relay, DBW relay, fuel pump relay) and all checked out on the bench as good and I was unable to find any issues with the any of the loom wiring. The DBW relay coil gets +12V to its coil as it should when the ECU Main relay is energized on key on. The other coil terminal of the DBW relay coil should be pulled to ground when the G4+ powers up, through the INJ7 output, but it appears that isn't happening. Any ideas on what to tackle next? Thanks in advance!

Are you using the OEM FD TPS sensor? I see from the FD factory shop manual (FSM)/wiring diagram that it is indeed a dual track sensor, and you're correct that it is directly linked to the OEM throttle body, so the linkage isn't your problem here. That said, I'm not certain if both tracks of the FD's dual TPS sensor mechanically track the full range of throttle motion - the FSM refers to one of these as a "partial" and the other as "full" range, but doesn't give much more detail. This is similar to the TPS in the series 5 FC, where one tracks full range of throttle motion, and the other would only tracks partial motion, like the first 1/4~1/3 throttle opening. If that's the case, you'll need to somehow rig up a dual TPS sensor that can mechanically "see" the full range motion of the throttle.

Howard - I'm in agreement with Adam that those two data points were most likely noise induced outliers for all of the reasons he mentioned. And I think Adam's statement that the knock sensor is "just a microphone" might confirm what I've suspected regarding how the G4+/G4X processes raw sound data from the knock sensor to decide on what a knock "detection" is - it is simply an amplitude only strategy. So if there's enough audio energy in the sensor's output to cross your set threshold within the bandwidth selected, and it occurs within the knock window, the G4+/G4X declares knock and takes action as programmed. Adam - this is probably something for the engineers to look into for the G5 generation & beyond ECUs wish list, but have you guys considered combining frequency domain & time domain processing of the knock sensor's raw data with the amplitude only/threshold based processing already employed to better discriminate actual knock against background/spurious noises? In essence, this would be an AI that would act like a skilled pair of human ears listening to the knock audio. As implied, frequency domain processing looks at the tonal qualities of the sound, and time domain processing looks at the rise/fall times of the sound signal - both of these when used together with an amplitude based measurement can help discriminate the actual sound of interest (knock) against all the other noise.

^That is correct, the FD's secondary throttle plates are mechanically linked to the primary throttle plate, but they should not start to open until the car is revving well past a high idle speed on a cold starts (about >1500 RPMs).

Here's something for the wish list that would apply to the PCLink tuning software, that preferably could be applied to both G4X and G4+ versions. Would it be possible to add a "Layout Display Scaling" function to the software? What I'm thinking of would take the existing user's layout (i.e., applies globally to all pages/tabs), and proportionally scales the horizontal & vertical size of the original layout on each page/tab up or down by a user defined percentage. The idea here is that if you have an existing layout you like that fills the screen of one laptop, and then switch to a different tuning laptop/tablet, with a different screen size/resolution, you wouldn't have to go thru the tedious process of editing your existing layout to fit/fill the screens on the new device - just play with the new global scaling feature instead.

Next time you export your log in PCLink, try skipping the "File Time" parameter. I've been using MLV HD histogram features for some time now to fine tune my fuel tables with ECU logs, and I never had a problem with MLV HD importing my logs when I did the export as follows in PCLink: "Logging" > "Export", select only "Full Log" check box.

Looking at the circled part of the log, I would agree that a plumbing leak is a plausible cause for the boost suddenly dropping rapidly from about 18ish psi MGP down to about baro pressure while the throttle was still floored. May have popped a hose/coupler or had a BOV failure. Start inspecting all the joints/connections & plumbing between the turbo compressor output and throttle body. Should be an easy fix for that; I'd be more concerned with the weird fuel pressure fluctuations elsewhere in the log though.

I'm not seeing any evidence of a fuel or spark cut happening anywhere in that log where TP(main) is above 90% and/or RPMs at approx. 6000RPMs and above. But I am seeing the same erratic differential fuel pressure and wheel speed data that the others pointed out.

^Are those prices for the OEM Mazda sensors? The OEM sensor is a VR type sensor, and I think the sensors are still available new from Mazda. You might try searching for set of used OEM rings & sensors on the marketplace section of the RX7 Forum - http://www.rx7club.com/ Often times the same knuckleheads that hack up their FDs to delete ABS end up selling the left over parts on the forum. Also, the VR sensors themselves are typically very reliable - my biggest concern with buying a used one from an FD would be if it was removed properly without any incidental damage. Sometimes they get rusted into the spindles, and removal may take a bit of extra "persuasion" to get them out - though that kind of damage is normally visible in pictures of the harvested used part.

This free video from Evans Performance Academy gives a good rundown comparing the G4+ and G4X, should help inform your decision. I'm also running a single turbo modified S6 FD on a G4+, and personally if I didn't have so many other things I needed to spend cash on to finish my FD, upgrading the G4+ to a G4X would be a no brainer. As you'll see in the Evans video, the additional processing speed basically improves everything the ECU does when compared to the G4+. G4X brings in a number of new features such as long term trims and custom programming flexibility with math channels too. As far as input/output support, I'm pretty sure they are the same between G4+ and G4X within the same model family, i.e., a G4+ Fury and G4X Fury will have the same number and types of I/O and use the same connectors/pin-outs. Which is great because it means you won't have to rewire your car to upgrade to a G4X.

@Copyninja Regarding the idle/stalling issue, I noticed in your idle tune settings that you have Idle Ignition Control disabled. Enabling that might help - basically when you're operating in the idle region, it will advance/retard your timing based on the idle speed error. When you enable it. you'll need to populate a 2D or optionally 3D Idle Ignition Table.

Given the kind of boost you've got in that log screenshot, I'd assume you have a very robust aftermarket fuel pump in there that is pulling a lot more current than the OEM pump did. So my first question would be how do you have the fuel pump wired - was the wiring upgraded to handle the additional current draw of the new pump? If there are any tank bulkhead connectors in the fuel pump circuit/wiring, first thing I'd do is take a close look at them and any other connection points in your fuel pump circuit - look for signs of melting and/or burned contact terminals. If you see any of that, you'll need to upgrade the wiring on your fuel pump circuit. If not, take voltage measurements at the pump while doing another pull as Adam suggested to rule out voltage drops as the root cause. If pump voltage is good, next thing I'd look into is the fuel pressure regulator.