MGV101

I ran out of AN Temp inputs so had to use a pull-up resistor with a normal AN input for oil temp. The function setting in the AN input does not have a Oil Temp function to choose so I had to select GP Temp (Ext Pullup). This worked fine for me until we decide to hook up an AIM dash to the car. I cannot get the dash to show the oil temp because it is recognised as GP Temp in the ECU in the AIM pre-set CAN stream, this was not sent to the dash, only Oil Temp does. Is there any way to "assign" the GP Temp as Oil Temp so that it can be sent to the dash? Thank you! Seems like this is a G4+ specific problem. In G4X, the inputs are listed as function rather than pins and I could simply select Oil Temperature and it will allow me select normal AN inputs as source.

Thank you Adam. So with the Tacho function selected, the Ign output actually functions as a low side output? Sorry I thought the Tacho function was giving out a high side signal between +12V and floating for a normal Aux output instead of ground switched (as described in the help file: "This function provides a 0-12V pulsed output to drive a low-level tachometer from an auxiliary output pin.") So in the case of Ign out, I thought it was just giving out +5V instead of +12. But from what you are describing, the Ign out actually functions as a low side output switching to ground and does not put out a +5V pulse (which I though it would, in place of the +12V) when assigned as a tacho. Anyway, while waiting for your reply, I have tried a 1K and a 3.XK resistor instead of the 1.8K on the tacho input, none of which worked so yes, changing the resistor does not solve it.

Hello Adam. Did the 12V pull up and it seemed to have worked initially. But after a few drives it started acting up and would work only intermittently with the needle bouncing up and down as the signal constantly gets picked up and dropped or simply not work at all. Would changing the ohm value of the resistors help solve this problem? I am currently using a 1K for pullup and 1.8K on the tacho. I am still struggling understand the principle of how the 12V pull up is working in this system. My guess is when the ECU signal is pulsed off, the connection is floating at the ECU end so the full 12V current would flow throw the pull up resistor to the tacho (or the 1.8K resistor in front of the tacho in this case). With the ECU signal pulsed on, it is connected to 5V so there is a 7V difference between the 12V pull up and the ECU so some of the voltage is diverted to the ECU and the tacho will receive a lower voltage signal. However, this voltage will not be zero. Is it possible that this voltage is still too high for the tacho to distinguish it from the 12V signal? In this case, I will need a higher ohm resistor at the tacho I guess? That that would also lower the 12V peak going into the tacho. Thank you!

You are right, I completely overlooked that lol. I will give that a try, thank you Adam.

Won't the lower voltage on Ign 5 effect the operation of the solenoid and require a higher duty cycle as a result? Tuning on the car had already been done, won't this require a retune of the boost control?

Was struggling to get the Tacho working on a MR2 Link V2 Pnp even after modifying the resistor on the dash. After some diagnosis, I realized that the Ign 5 output I was using on the expansion connector was only putting out around +5V (both under the Tacho function and Test(On)/High side). After noticing the problem, I tried reassigning the Tacho output to Aux 3 which does measure +12V when set to high side and the tacho worked straight away. So it seems like there really is a voltage problem in Ign 5. Are the Ign outputs supposed to output 5V only? I still need to look for an alternative output for the Tacho as Aux3 is currently used for the boost solenoid and I just borrowed it for test purpose. Would using an even lower resistance resistor (1.8K currently used) allow me to use the Ign output for tacho? Thank you!

Actually, when playing with the the settings and setting the driver type to low side, I've caused to ECU to immediately shit down as it stopped providing power to the main power relay. Somehow the changes got stored without pressing ctrl-S and I had to disconnect the relay wiring from AUX 7 and hook it up directly to the battery to power on the relay and turn on the ECU disconnecting the relay from the battery and the ECU would immediately power it down. So this makes me think maybe this is not Output Back-feed keeping the ECU powered on? Looks like the ECU just refuses to deactivate the output to the relay to power itself down. The DI input for igniton is working fine. I can see its status changing between active and inactive as I turn the ignition on and off. The ECU hold power would show as Active when the ignition is on and Fault when the ignition is off and the ECU is supposed to shut down.

Helping a friend diagnose his 1NZ Yaris with a G4X Xtreme. Most problem had been fixed other then the ECU Hold Power function. I think it is missing a diode to initially power up the ECU when the ignition key is on but somehow it would manage to power itself on when the key is in the start position. This is not why I am asking for help here though as I am sure installing diode will fix it. The problem we have is trying to switch off the ECU once it has powered on. Looking at the stock wiring diagrams, seems like the main power relay also provides power to a few other devices including a VSV purge solenoid. Link's diagrams it does specifically show under this situation, Ign/Inj driver must be used but we are using AUX 7 to drive the power relay right now. I guess this is because the solenoid would cause Output Back-feeding keeping the ECU powered on? The ECU Hold Power is currently connected to AUX 7 as the stock relay is actually driven by +12V from the ECU side. I know the injector drivers are ground driven (Low Side Driver) only so they cannot be used so I tried to configure one of the ignition drives given ignition system is positively driven but looking at in the software there is also no option to select Driver type set it to High Side even for the ignition drives. So given the AUX inputs cannot be used due to output back-feeding and the ignition/injector drivers does not given our a high side driven output, I have no idea what output to use. I am out of ideas on how to wire this up and hope I can get some help here. Thank you.

Yes, but an oscilloscope function would help verify the polarity of the reluctor sensor and also the optimal arming voltage. Looks like I'll need my own oscilloscope for that unless it is on the trigger 1/2 input then?

Does the oscilloscope function of the trigger scope work for trigger inputs only or does it also work for the other digital inputs? I wanted to verify the VVT cam position signa which is independent from the trigger home signal and is wired to one of the DI channels. There is a DI tab in the trigger scope window but seems like it is only show the processed signal rather than the oscilloscope display. Thank you!

Thank you Adam, so other than "Because of a lower tooth count the ecu "sees" less effect from the cambelt whip than it does from the 360 slots.", the 360 teeth isn't really too much trouble for the ECU to handle and swapping in a 24 tooth disk would have a minimal effect for improvement? This is way way worse than other cam/distributor based trigger system I have seen. Also should I turn on RPM filtering? Or would that create other problems on fast RPM changes?

I'll do a trigger scope at higher RPM tomorrow if needed but here is one done while cranking when I was trying to figure out why the engine won't start when I had the wrong jumpers configured. Well, it won't let me upload anymore files due to the tiny file size limit per thread so here's a link: https://drive.google.com/file/d/1BYUwCxZTyGGHIAthCt0NxVWlSKir74ln/view?usp=sharing

Running a R32 on stock Nissan 360 Opto triggers, all trigger settings as per the provided base map. Signal from trigger scope looks clean, no trigger errors. The RPM reading is jumping all over the place especially at higher RPMs, the inaccurate RPM also seems to be causing unstable ignition timing. When calibrating the base timing, the rpm/ignition was stable enough for me to dial in the offset at idle but once I increase the RPM to dial in the delay (around 3000-4000rpm), the timing was fluctuating so wildly that I cannot properly read the timing mark at the crank pulley. Due to the inconsistent/inaccurate ignition timing, I am only running at around 4-6 degrees advance at 1 bar of boost before I get knock. Are the 360 teeth just to much for the ECU to process or is there something else wrong?

Hello Kris! It's been a loong time! Since CAN Bus is working on the ECU, I suppose the RS232 connection should work too. But the ECU's on its way back to Link already...

Sent a message to support a few weeks ago but never got a reply so I'll see whether I can get any feedback here. Long story short (still quote long lol), the wiring behind the ECU was a mess. After doing some wiring work to setup a few PWM relays for fan speed control, I think I knocked some splices loose while tucking away the wires during wrap up and the ECU won't boot properly (no, the old messy wiring was NOT done by me). Car/ECU was running fine even after the PWM relay/fans was setup and the problem only popped up after I tucked the mess of wire back into place to wrap up. The green light on the ECU PCB was flashing and I can hear relay at the front of the car clicking on and off (probably the ECCS relay). After nudging the wire a little and powering it up again, the LED become a solid green. However, the car would refuse to start (or maybe we just did not crank it long enough) although the AiM dash is receiving signal from the ECU and all sensors seem to be reading normally according to the readings I see on the dash. USB will not connect either. Unplugged everything and tried my best to tidy up all the previous wiring work from the last person and plugged everything in again but the problem still persisted. We tried starting the car in the morning the next day it just suddenly came back to live and started without any problem without changing anything. Maybe somehow the ECU recovered overnight or maybe we just did not crank the engine long enough the night before. Everything seems to be running normally but the USB connection still refuses to work and we are unable to connect the ECU to the PC. Windows can detect the ECU being connected and we can see it in device manager but F3 will not connect. We then try to connect a new ECU (G4X) to see whether there is something wrong with the car or the ECU itself. While swapping the ECU we managed to identify a possible cause of the problem. Somehow the connector going from the harness to the ECU have become bow shaped with the sides bending upwards resulting in a bad connection for some of the pins and the ECU will only run in boot mode. We had to wiggle and push on the sides of the connector before can get the new ECU to start up properly. The connector straightened itself after heating it lightly with a heat gun and after that the new ECU is running perfectly. Thinking it was just a bad connector we tried plugging in the old ECU again. USB still refused to connect. Car is running on the new ECU now and doing fine and I brought home the old ECU to do a bench test while waiting for a response from link. Power up the ECU by connecting pin 49, 58, 59 to 12V and 50, 60 to ground. The green LED lights up but USB still refuses to connect. Could the unstable power connection have killed the ECU (at least the USB part)? Is there anyway to get it fixed? Thank you! Car: Nissan GT-R R32 ECU: Link G4+ PnP NGTR+ Best regards, Jerry Ip

Hi, I have replaced the stock knock sensors and is connecting the new sensors with new wiring. I am unable to access the stock knock sensor connectors to check which sensor goes to which input. Since there are two knock inputs, does it matter which sensor goes to which input? Are the channels mixed or is each channel assigned to specific cylinders i.e. front sensor would be assigned to cyl 1-3 and rear sensor assigned to cyl 4-6. I tried swapping the sensors and there seem to be no difference so I guess it is mixed?

Finally got some time to work on the tune again. Managed to get the idle to be somewhat stable with 10 degree ignition and enabled idle ignition to further dial in the idle. As I was dialing in the idle ignition, it still felt like things would benefit with a slower igniton with 8.5 degree in the zero error cell. Throughout the day, I was struggling hard to keep the RPM with dipping and fluctuating for a few cycles before stablising after blipping the throttle or a warm startup. After spending some time with close loop idle control (which seem to have little effect) and also working on the fuel map, things seem to have improved a little. By the end of the day, the RPM would still dip by roughly 100 rpm and takes maybe 4-5 seconds to stablise again but was already much better than what I started with. There seems to a brief moment where the engine would run lean after lifting off the throttle but I can't seem to tune it out (I've checked and it's not overrun fuel cut). Not sure whether that is the cause of the rpm dip. Also to note on the A/F ratio is that the 0-5V signal coming from the AEM gauge seem to be a little off. When it's at stoich on the AEM gauge itself, the ECU is reading 1.05 lambda. It is not a grounding issue as the ECU and gauge share the same ground and I have read the voltage right at the connector of the gauge between the 0-5V signal and ground and the voltage given off is indeed slightly different from the calibration table given. It's not a big problem and I would deal with it by adjusting the calibration table later. (Damn, I missed the Link CAN Lambda on my own car). If I rise the idle RPM to around 1200, things were significantly but my friend (the owner of the car) seems to prefer a lower idle even if it sacrifice power. I am wondering how much cam timing would affect the idle quality. If it would help, I am thinking of advancing the exhaust cam by 2 degrees from its current position if it would help (the intake cams are too difficult to access with the engine still in the car). Attached is the latest map I cam up with so far and a log showing the oscillation on a warm start up and throttle blip. https://drive.google.com/open?id=1dagL6I2eSxUJwja4YKddCcbGYx1dAw2U https://drive.google.com/open?id=1pMdI18ZQv1IT4mYq6pBPsVz-qQXhBRWn A big thank you for all the help I have received here so far!

Thank you for all the feed back. Yep, seems like my attempts to "flatten" the base map had gone the completely opposite direction. Instead of lowering the ignition for 1500 rpm, I raised ignition for the lower rpm range to match with the higher rpm and made the matter worse. Following the suggestions here, I started the up the engine with around 15 degrees ignition across the board. It still fluctuated initially but after further flattening everything to 10 degrees (map1 attached), the idle stablised significantly (the last section in log1 attached). However, after shutting down and restarting the engine, the revs started bouncing again. After playing around with the ISC% and igniton timing again, idle seems to have settled down a little with ignition lowered all the way to around 7 degrees (map2 and log2). Also, after blipping the throttle, it takes awhile for the engine rpm to settle. Regardless, things seems to be on the right track and it probably just need more work from my end to make it better but I was already choking to death from the exhaust and had to call it a day. No exhaust was installed yet after the downpipe and I was standing right next to the engine (and down pipe) while updating the map breathing in all the exhaust. map1 https://drive.google.com/open?id=1IaVah5A4vdlLyH5JfTU0La5ZAXwTz1y4 log1 https://drive.google.com/open?id=1F5teTRz1bkeCcFuiAugsOg4vFyMkF3JF map2 https://drive.google.com/open?id=1GJgUpzr4-_9pc9KzLwfxF7Bis5nZ9MTm log2 https://drive.google.com/open?id=1EdA81ldKOtN2gkaN2j2tRC-8LZXLyyAn

Finished building up a 3S-GTE engine for an MR2 but could not get it to idle properly below 1300rpm. Anything lower would gradually cause the rpm to fluctuate more and more the more I close up the ISC valve or idle adjustment screw and would eventually fluctuates to a stall. ISC is on open loop and I have went as far as plugging the ISC port up to control idle with the adjustment screw only so it is not the ISC settings that are causing the fluctuations. Aftermarket cams were installed on the car and degreed per manufacturer spec while building up the engine. These were Kelford 264 cams which isn't that aggressive. However, the final adjustment on the cam gears were a little worrisome as the adjustment were pretty must at the end of the adjustment scale on the exhaust gear with 11 degrees of retard but I did measure it two more times while building up the engine to make sure it is correct. I know aggressive cams will require a higher idle due to note being able to pull sufficient vacuum but 262 cams are far from aggressive and looking at my MAP readout, vacuum is pulling strong. I have another 3S-GTE engine with the same cam that idles just fine at 900 to 1000 rpm. Lambda looked stable enough to me and would be fine tuned once the idle problem is solved and I have already flattened the ignition map a little to make sure its fluctuation between the rpms isn't causing the problem. Right now, I am truly stuck on what's causing the crazy fluctuations in rpm and cannot progress any further with the tune. Attached is the latest map used and a log from startup where the rpm was stable and high until the engine warmed and the ISC valve started closing up and the fluctuations begins. Manually pushing the ISC% back up rises and stabilises the rpm. EDIT: Attachments deleted as I ran out of space for attachments and have to delete some from my old posts.

Thank you Adam. I am actually using the 8V power source from the Fury ECU so the recommended resistor would be approximately 1.8K, its slightly closer but still pretty very far from 4.7K. This may explain why I never had the trigger error before though as I have only switched to a fury unit at the end of 2018. I was using a plug-in unit before which did not have a 8V output so I was using 12V instead which would give a closer recommended value of 2.4K. So to correct this, I'll have to turn off the pull up resistor on the ECU and wire in my own? So to correct this, I'll have to turn off the pull up resistor on the ECU and wire in my own? Edit: Oh, we actually discussed the pull up resistor before on 12V a long time ago and I almost forgot about it.

Tried to replicate the problem today by free revving the engine but seems like it only happens under load and given I cannot drive the car outside, I cannot replicate it. For the trigger setup, it was an off the shelf kit specifically made for the MR2. The trigger wheel and the sensor were supplied by the same shop as a kit with a Cherry GS10701 sensor but specification of the trigger wheel did not exactly fall within the specs recommended by Cherry (http://switches-sensors.zf.com/us/wp-content/uploads/sites/7/2012/05/Datasheet_GS1005-GS1007_Letter_EN.pdf). The wheel itself is only a little over 3mm thick vs 6mm as recommended and tooth gap is approximately 5mm vs the recommended 10mm. However, when I looked at the trigger scope when installing the trigger setup for the first time, the signal looked clean (and it still does now) so I never thought much about it as everything worked. My trigger setup had actually been working trouble free for over a year. Could the sensor be failing? Here is a link to the kit I use but I've skipped the 1zz coil part using just the crank and cam sensor from the kir. http://racerxfabrication.com/mr2-celica/ignition/1zz-coil-on-plug If I were to change the hall sensor, is there any recommended alternative that I can use? Preferably in the same form factor so I could use the existing mounting. Also for the trigger scope, should I try running it at a higher RPM to see whether there is any degradation of signal when the frequency increase?

To add a little backgroung information. This is a Gen 3 3SGTE engine on a MR2 managed by a Link G4+ Fury with the distributor replaced by a crank 36-1 crank sensor and a cam sensor with LS2 truck coils.

I seem to be getting a lot of random ignition cut lately. I thought it was due to MAP limit being triggered from over boosting which was initially true but as boost was begin dialed in I was still getting ignition cut under hard acceleration. All this was happening at the track and it was difficult being the driver and tuner at the same time so it was overlooked and I simply continued to dial the boost down thinking I was just touching the MAP limit. Now that I have returned and have time to look at the logs in detail, I noted MAP was very much in check most of the time when the ignition cut occurred. Sadly, none of the Limit status was logged so I have no idea which limit was triggering the ignition cut but I do have Percentage ICut logged so I know for sure the sudden drop in power and loud pop coming from my exhaust was due to ignition cut. Attached are maps and logs from the second day of the track event (after addressing most of the overboosting issue) to help identify the problem. The first map was uploaded to the ECU in the morning where the ECU statistics had also been reset. The first log were pulled around noon after a couple runs at the track (somehow it only recorded one session). The second map was upload to the ECU right after pulling the first log with some minor updates to the PID boost control as I still thought it was the MAP limit causing problems and the second log were of the track sessions logged after loading the second map, closed loop lambda had also been disabled as all the pops and bangs from the ignition cut seemed to have killed my wideband. Looking at the logs you could see when ICut was being applied, MAP was nowhere near the 250kpa MAP limit or 235kpa after factoring in the 15kpa control range. Looking at the engine speed however, I've noted there were sometimes, a sudden spike in engine RPM when the ignition cut occurs. However, this only happens 1/4 of the time and seems to happen miliseconds after the ignition cut kicks in so I suppose it was the violent ignition cut itself throwing the RPM off rather than it being a cut due to RPM limit? Engine speed is being logged at 50hz, is it fast enough to catch all the rpm spikes that the ECU itself sees or could it be too slow? Other than the RPM and MAP limit trigging the igniton cut, I was unable to identify any other settings on the map which could cause the cut. Could anyone offer some help? Thank you! I would love to go on the street and test everything again now to diagnose the problem but sadly, due to the strict modification laws here in Hong Kong and the fact that its such a crowded city, there is no way I could drive my dedicated track car on the street without drawing attention and getting caught. Also, there are no race tracks in Hong Kong and the only option to hit the track is to travel up to mainland China which requires the application of a special one time permit (unless you are some one rich who can afford regular cross border license) so the opportunity of road testing the car at the track is really limited. Day 2-1.pclr Day 2-2af.pclr Below is the second log on google drive which I am unable to upload due to file restrictions: https://drive.google.com/open?id=1Wnbves6DvJpBVGHoEAw0pVCqoVuJ9DGg

Thanks! I was always under the impression that the injectors would always been injecting less fuel than the "straight line" curve given it takes time for the nozzle to fully open and that's why I found the base map strange. I am using ID850 so it was correct to use positive numbers then.

Should the short pulse with adder values be in +ve or -ve? Previously I have used +ve numbers for the values but I am building up a new map today for a new ECU using the sample base map for my Fury and noted that all numbers are in negative. Tried looking at other base map too and noted they are also entered as -ve numbers. Does it mean logic of the G4+ actually adds the value entered into the tables to determine the effective pulse width and therefore -ve numbers should be entered for it to work properly? Meaning I have entered the wrong numbers into the pulse width adder all along?