Pete_89t2

Thanks Vaughan, I can see how the text scaling can be a problem. Perhaps instead of trying to make the user scaling feature continuously variable, maybe try implementing a few switchable display settings that would cover most of the common laptop/tablet/desktop screen size resolutions?

Just bumping this topic since it seems it's something the users want, but we haven't seen any response from the Link folks yet. Is what we're asking for feasible?

That's good news, thanks! It wouldn't change the frequency of the VSS sensor signal, but having a 2nd load (Link ECU input) wired in parallel would change the AC impedance some, which may impact the accuracy of the OEM speedo.

Will the DI1 input on a Fury G4+ accept a 0-5VDC TTL type square wave input? If so, would I need to apply the pull up option? Some background - I'm currently using a direct connection my car's vehicle speed sensor (VSS) on DI1; car is a series 6 FD RX7. The VSS is a 2 wire VR type sensor that outputs a sine wave at 8 pulses per revolution of the sensor. So basically the frequency of the VSS varies as speed increases; I have it calibrated & setup in my G4+ to measure driven wheel speed which works just fine for use with the G4+, but I've discovered that doing so causes the OEM dash speedometer to read a few % higher than actual road speed when calibrated against GPS or via the time/mile marker measurement method. After reviewing the FD's shop manuals, I found that there is another possibly better way to obtain my vehicle/driven wheel speed signal, assuming it's compatible with the G4+. The FD's OEM instrument cluster outputs a 4 pulse per VSS rotation square wave signal that it normally would send to the OEM ECU and OEM cruise control unit. According the the shop manual, this signal reads on a DC voltmeter approx. 5VDC when the car is keyed on/not in motion, and approximately 2.5VDC when it is in motion, which implies to me that it's a TTL logic output (0V/5V). So the thought is if I tapped this signal for DI1 instead of doing the existing direct VSS connection, it might eliminate the speedo error I'm seeing on the OEM cluster speedo.

One more point to add to this discussion that I didn't see mentioned - you do need to have accurate characterization data on your injectors (i.e., flow @ rated base diff. FP, dead times vs. diff. FP & voltage, SPWA table data) to plug in to your tune so modeled mode can do its thing as well as it normally does.

You'll need to post up the tune file in addition to the log posted to get a meaningful look at what's going on there. If you're past your attachment limit, post it to Google drive or similar sharing site with a link to the file(s) here. Also sharing your FD's general specs (i.e., FI's, turbo setup, ignition setup, etc.) would be very helpful too. From a cursory look at just the log, I doubt that lean spot by the yellow cursor is related to secondary staging. Can't know for sure without the tune file, but since you're still in vacuum there (-2.3psi MGP), you're probably still below the MAP threshold for staging to take effect. Most staged injection tunes need to cross an RPM and MAP threshold to start staging. That said, elsewhere in the log where you're running it up to 100% throttle and at full boost, the transition into boost where the secondaries should be/are staging on does trend lean until the CL Lambda control MAP delta time-outs expire, and CLL control has a chance to get it close to target.

I'm not familiar with the 20B Cosmo's, but the RX7 series 6 FD's of similar vintage that are equipped with auto transmissions have at least some integration between the factory engine management ECU and the AT's ECU. According to the FD factory service manual (FSM) electrical schematics, there are approximately 5~6 direct wire connections between the OEM engine & AT ECUs. The purpose of some of these are connections are obvious from the FD schematics - most look to be just pass-thru's for shared sensor connections (e.g., TPS, perhaps MAP, etc.) that the AT ECU needs to do its thing. I have no clue what all of these connections are for, as I have a manual FD and never really had to deal with an automatic FD. I'd recommend trying to track down a 20B Cosmo factory shop manual/schematic diagrams to help figure out all the electrical integration specifics. Might be difficult to find the FSM in your native language unless that language happens to be Japanese.

Thanks! I wasn't 100% sure if that was the correct way to select DI3 in the logic.

Greetings, I've been using a simple Virtual Aux logic that switches based on MAP > "X" as a means to implement a simple soft boost limit with my DBW throttle. Basically when that MAP level is exceeded, it switches the DBW throttle to a 2nd throttle map, which reduces the throttle by about 1/2 of whatever my accel pedal is demanding. It works great and is effective. I'm currently setting up 2 different closed loop boost control levels (i.e., a low boost/daily driver mode and a high/max power mode), that I select with DI3, so when DI3 is OFF, it's in low boost mode, and when DI3 is ON, it's high boost mode. With that in mind, I wanted to extend the Virtual Aux logic here to give me a higher MAP soft boost limit when DI3 is ON/active. Link below is the logic I set up in my G4+ Fury. I'd really appreciate if someone can provide a sanity check of what I came up with, or suggest a better way of doing what I'm trying to accomplish. https://drive.google.com/file/d/1XPixJNgifSzNOP6jPYx9QfdjV8X0kwwZ/view?usp=drive_link

Now that you mention it, I did do a small adjustment to the speed calibration about a month ago so the speed displayed would match closer to actual/GPS speed measurement. Didn't realize I'd have to do the gear calibration again after that - assumed those gear cal #'s are just fixed constants based on your gear ratios. On a semi-related question, on the series 6 FD there's 2 options for tapping a speed input. One is doing what I am now, which is taking a parallel wired connection to the analog VSS sensor, and sharing the VSS sensor input with the OEM dash speedo. The VSS is a VR/magnetic sensor that puts out a sine wave signal, 8 pulses per shaft rotation. The other option available is to tap the digital speedo output from the OEM dash cluster that would normally goes to the OEM ECU - that is a digital square wave 4 pulse/VSS sensor rev signal. I think both will work with the Link's DI1 input, but is there any advantage in using one over the other?

Adam, Here's a link to the log & current tune file. https://drive.google.com/drive/folders/1mxt-Y19KZ0yTBcaL444ulelE5zL0UmuU?usp=sharing You can see the gear glitch happening right around time indexes 5:46~5:47; 6:51~652; 9:30~9:31 and a few more places later in the log. Thanks in advance!

After a drive yesterday with my laptop and PCLink logging data, I noticed something odd in my logs. This is with a G4+ Fury in an S6 RX7. For some time now I've been using the OEM vehicle speed sensor (VSS) as an input to DI1 to provide driven wheel speed, and I've done the gear detection calibration procedure so the G4+ can compute which gear I'm in. When testing that function out months ago, it always seemed to work - gear reported in live/real time data matched what was going in. I haven't used the gear detection functionality yet for anything in my tune, but now that I'm working on boost control, I may want to apply a gear trim, so I've been taking a closer look at that gear data in my logs. What I noticed in the PCLink log yesterday while looking at a time plot that shows gear, Engine RPMs, DI1 frequency and Driven Wheel Speed was that sometimes the gear position will randomly drops from whatever gear I'm in to 0 on the plot while the car is actually running at speed in any one of the gears (1st thru 5th). At the same time on the plot, the DI1 frequency, driven wheel speed and engine RPMs are all showing correct data, consistent with the speed I'm driving & engine RPMs. I can post up a log later for review, but the log data indicates to me that there's no hardware/wiring issues, as I'm getting consistent input on DI1, no RPM/trigger issues and there are no issues with the G4+ calculation of driven wheel speed from the VSS. Is this perhaps a glitch in PCLink logging?

Other than changing the accel fuel in the staged injector setting to 5, were there any other changes to the tune file you posted before? If so, post that up too. The reason you're hitting the injector duty cut is because in your log you're pushing >84% on the primaries at the stage-in point, which is what that cut is set at (under fuel main, "injector duty cycle fault value"). You can raise that cut, but since it's already pretty high I wouldn't recommend that. Instead since you're pretty much maxing out the primaries at the MGP you're staging at, I would adjust the secondary staging table so the secondaries stage in earlier, and a bit more abruptly (i.e., a steeper ramp-up to the full 62% you've got). Maybe try setting the 14.5psi MAP cell to about 20~30%, and the the 17.4psi MAP cell to your maximum 62%, and then do an interpolation for the cells in between those two cells.

Ok Adam, I had a chance today to test out all 3 of your suggested changes individually. Link below has the tune & log file for each test, file name describes each one. https://drive.google.com/drive/folders/1mwQ4HPjgyoO-hV6gGRl3iuXew-9GpmW5?usp=sharing Summary results: For drive-ability, best idle quality and the least oscillation in either idle error or target/actual lambdas, suggestion #2, "make target lambda something like 0.87 around idle" worked the best. When I did this I set it at 0.880 in the entire idle region, and I undid the changes made from suggestion #1 (zero out the SWPA table). The drive-ability, idle quality and idle/lambda oscillation did improve slightly in suggestion #1, "zero out the SWPA table", but it wasn't improved enough (on the road or in the logs) for me to say conclusively that the SWPA table was the root cause - those oscillations are still there in the logs, just with generally smaller magnitude swings. Suggestion #3, "put 10 right across the ignition idle table" made idle quality and the idle/lambda oscillations significantly worse than my original baseline So I'm concluding two things from this exercise - (1) My FD really needs the idle ignition control to assist with maintaining a steady idle, and (2) It would appear it would be happier with a richer target lambda than I've been running in the idle region. Which is unfortunate, because I was hoping to get it to idle as close to stoich as possible. I suppose I can try to iteratively lean out the idle region target lambda until I reach the point where idle/lambda target tracking just starts to get wonky again? Thoughts?

I had a chance to test zeroing out the SWPA table for my primary injectors, and do another test drive/log. I also set my non-driven wheel speed source to the same sensor as the driven wheel speed source, so that the Ignition Idle control and E-throttle idle CL control have the same speed lockouts. Google Drive link to the files is here: https://drive.google.com/drive/folders/1DlabmLEpip2GFLkRar7Ia2MqIfUkWQ2s?usp=sharing From behind the wheel, the drive-ability feels much improved - feels like there's a smoother transition into idle from those low speed clutch/brake & stop traffic situations, and the idle settles down and smooths out faster. From a quick look and comparison to previous logs, I still have some lambda/lambda target oscillation happening initially after the transitions to idle, but the magnitude of the swings are not as large as before, and it seems to flatten out quicker. Same for the idle speed error - settles to target quicker, and for the most part stays on target. BTW, I only zeroed out the SWPA table of my primary injectors - the staged secondaries don't come online until I'm a few psi into boost, so I didn't mess with the secondary injectors SWPA table. Being a noob at this, I guess the question I have is this good enough? Does my target/actual lambda track well enough, and is this the best I can expect here from CLL control? I'm also wondering if the occasional ignition miss at idle would cause the CLL control to get wonky? Seems reasonable, as a single ignition miss on one of the 2 rotors would show up at the WBO2 sensor after a short delay as a lean reading, but because the CLL update rate can't be any slower than 1Hz in the G4+, it might end up over correcting on the transient lean reading.

Ok, so it looks like your core problem is you've got your "accel fuel" under the staged fuel settings set to zero. Not being familiar with the G4X, I had to read the help file as they do it a little differently than in the G4+ which needs you to specify an "accel fuel" and "accel time" figure there. AdamW or one of the Link reps can give you better advice, but I'd probably start with a smallish non-zero number like perhaps 5 or 10 for your "accel fuel" under the staged fuel settings, take a drive, and see what it looks like in the logs. If it's still spiking lean at the secondary transition, increase your "accel fuel", if it spikes too rich at the transition, reduce it. Also, make sure your primary/secondary ratio is set correctly to match your pri/sec injectors.

Post it somewhere like Google Drive, with link to the shared files here.

That depends, how lean and for how long? At any rate, it sounds like the transition into the secondaries needs a bit more tuning. Post up your current tune and a log of it transitioning into the secondaries so we can give you better advice. I'm familiar with the G4+, but I would imagine the G4X is similar. If it's a short duration lean spike just as the secondaries are coming online, it sounds like you'll need to tweak the "accel fuel" and "accel time" settings under the staged injection section (at least that's where it is for the G4+). In this case, "accel fuel" is a fuel enrichment added to the Primary Injectors (separate from the normal accel fuel enrichment) just as the secondaries start staging in, and "accel time" is an amount of time that enrichment via the primaries stays active, which I think is measured in engine cycles. The idea being that secondary injectors are not physically mounted where the primaries are, so there's typically a lag time before fuel flowing from the secondaries can influence the AFR/lambda. The temporary enrichment via the primaries (accel fuel & accel time settings) work together to compensate for that lean dip.

^ I didn't even realize that was an option! Since I'm not using traction control, but limited to the one driven wheel speed sensor I have, I suppose it wouldn't hurt to try this so both the ignition & throttle based idle CL controls have the same speed lockouts. Thanks for confirming. I'll give those tweaks a shot & post logs when I get a chance.

Understood, I was thinking the initial undershoot is being caused by the ignition idle control acting alone first because of the speed lockout on E-throttle CL ISC. In those cases where I clutch in & coast, you can see the ignition idle control goes active as soon as the RPMs drop below the 1500 RPM lock out, ignoring the 10mph speed lockout and that's where the undershoot happens. So I was thinking of trying one of the following: (1) Lower the RPM lockout on Ignition Idle Control to be closer to warm idle speed, say about 1000RPM, or (2) Put all 10's (normal timing @ idle) in the Ignition Idle Control table where the error is overshooting idle, which essentially prevents ignition idle control from doing anything if the idle overshoots. Neither approach is perfect; (1) would likely degrade idle during warm-up, and (2) would make idle overshoot conditions tougher to manage I would assume. Just to clarify, are you suggesting I try each of these changes (1), (2) & (3) individually, log & then revert to what I had before trying the next one & repeat? That SWPA suggestion is interesting; I got my SWPA data & dead time data table direct from Injector Dynamics when I purchased the new injectors. But I also see that the leaner than typical target lambda's (for a rotary) I'm running at idle are resulting in small injector duty cycles & pulse widths, so maybe it's trying to operate in a non-linear area?

Which closed loop control are you referring to as not being active? In those previous examples, the Ignition Idle Control goes active first, as soon as my RPMs drop below 1500. Since I only have a driven wheel speed sensor, the speed lockout is apparently ignored by the Ignition Idle control, but the speed lockout for the E-throttle idle control prevents that from activating until speed drops below 10mph. Anyway, I went ahead and tried your suggestion to add back another 0.25 to the Idle Base Position table in that temperature range (cells from 176* thru 212*F), and reverted the +/- CLL limit tables back to where they were in the overrun/return to idle areas, then took another drive with it. Tune file & log from that drive is here - https://drive.google.com/drive/folders/1BD40aTlvR6pv38NBl1PH9v0BcI5OA_Ow?usp=sharing I'm seeing a bit more oscillation of lambda & idle errors after making the above changes, see log between time index 13:08 to 13:55.

I'll give that a try, but I suspect that whatever I add to the idle base position table will end up being pulled back in the E-throttle ISC CL trim, no?

Ok Adam, I went ahead and zeroed out the CLL trims (+ & -) in the overrun/idle entry areas as suggested. Google drive link to the current tune & log file of it running with that change: https://drive.google.com/drive/folders/1wUKlKTnfxWezpxcjkIOnhgXaIJZRaXtE?usp=sharing I basically replicated the same drive as last time, though ambient temps were a few degrees cooler today than last time. From behind the wheel, the undershooting on return to idle is less pronounced and recovers quickly so the drive ability is much better, but it's still happening and evident in the log. You can see this behavior (minimal RPMs/worst undershoots) around time indexes 12:23; 13:09; 13:55; 17:08; 17:38; 18:03; 18:24; 19:27 and 19:38. In most of those cases, it looks like CLL was still trying to trim the lambda towards target, unless RPMs dropped below the CLL RPM lock-out. Should I zero out the CLL +/- trim limits in the 5.8psi MAP row out to 3000RPMs as a test? Looking at my Lambda/AFR target table and Fuel Table, would it be smart for me to adjust those axes to better suit my application? I only plan to boost this engine to 15~16psi MGP max, so I was thinking since the engine practically never sees the 0psi MAP cells in practice, I could get rid of that row, start at 2.9psi MAP instead and put the maximum row at 16psi MGP/30.7psi MAP, which would buy me a row or two of extra load (MAP/MGP) resolution to use in the vacuum regions.

Sure, I'll give that a go and post up a log after I take a drive to collect one. Should I zero out both negative AND positive CLL trims in the overrun/idle entry areas, or just the negative CLL trim as pictured? If the intent is to completely disable CLL in that region I'd assume I'd need to zero both out.

Update to my idle & CLL tuning. I've done some further tuning per Adam's suggestions, and things have improved quite a bit - idle is much more stable, and CLL seems to be working much better. Google drive link below has the current tune and a log that captures a cold start & drive for about 25 minutes or so. https://drive.google.com/drive/folders/1_MTn87vUJtRVB760aJPZs1y3SRk-ERR6?usp=sharing The one problem I'm still having is when driving around at full operating temperature in a residential neighborhood (i.e., 25MPH max, stop signs on every corner, barely hit 2nd gear before having to clutch & coast/brake for the next stop sign), the engine wants to stall, though in this log you can see where the idle control catches it before it does. You can see examples of these near stalls between time indexes 21:11:426 and 21:14, and again between indexes 22:33:224 and 22:35, from where I depress the clutch and the engine RPM should drop to idle, but undershoots idle speed to a near stall. My car lacks a non-driven wheel speed sensor, though I do have a driven wheel speed sensor, so I think the ignition idle control feature is ignoring the idle speed lockout, but the DBW throttle closed loop idle control isn't ignoring the speed lockout because I do have a driven wheel speed sensor fitted? Anyway, I tried to setup the RPM lockouts on both to coincide at 1500 with the car running at full operating temperature Does the closed loop lambda control at idle look good enough here, or could I expect to do better with further tweaking of the CLL gains?