Confused

Error code 46 is "An Temperature 2 above Error High Value" - so, what do you have attached to An Temp 2 input?

I've recently picked up a G4X, as well as having my existing G4+. I was wondering if I could make use of the some of the advanced features of the G4X, such as long-term Closed Loop Lambda, to improve my G4+'s tune. If I were to use Modelled Mode, enter the same injector data, target lambda, charge temp approximation etc, could I run the G4X in the vehicle, flesh out the fuelling table, then apply this to the G4+ and have a reasonable result? I appreciate things like warmup, throttle transients, wall wetting etc may not translate, but the raw fuelling table - would that be close enough? Or, does the G4X calculate fuelling fundamentially differently to the G4+, and I'd be wasting my time, and it'd be better to just stick with doing it the "normal way" in the G4+ with logs + Mixture Map?

There was a similar thread here which might give you some suggestions and ideas on how this might work

You should use CANBUS/AEMNET for your X-Series AFR gauge, this will give you substantially more accurate fuelling data - the analog outputs on AEM wideband devices are notoriously terrible and inaccurate - the newer ones less so, but as the one you have supports CANBUS, you should totally do this - which also frees up an analog input for other purposes. Your Flex Fuel sensor (assuming it's the actual sensor itself, and not via some dodgy 3rd party gauge/controller) only requires a single Digital Input into the ECU - plus power, of course. Your boost solenoid requires an output, this can be a spare Injector or Ignition output, or a generic Aux output. The other side of the solenoid should be powered by a switched power source, such as a relay triggered by the ignition switch or main relay) Your fuel pump(s), if you want to run them staged, will require an output similar to the boost solenoid - again, these switch ground, into a suitable relay where the other side of the coil is powered from a switched power source.

If all your supporting data - injector deadtimes, Fuel table, charge temp approximation, etc isn't correct, changing the Target won't make the impact you're expecting.

Stock narrowband O2 heater wiring is probably insufficient for the wideband power supply. You can try adding a 22uF capacitor, as per the Alternative Wiring in the manual, which may help, otherwise you'll want to improve that power supply with some thicker wires.

This just seems like you're confusing the two different ways the data is presented? As far as I'm aware, they've always been Superseal connectors. One is showing you the actual shape of the connector, and then a table view of the functions, the other is showing you a stylised representation of the layout with the pin function/wire colour together.

Yep, that's pretty much what I've done with my 6A13TT engine in my Ford Anglia with an Evo 1-3 ECU. You'll have to adhere to any limitations on the board, such as on the Evo 1-3 Ignition 4 is used for ECU Hold Power (to keep the ECU powered after turning off the engine, so that the Idle Speed Control stepper motor can reset itself to the start-up position), so I couldn't use sequential ignition. But other than that, and if it's got enough inputs & outputs available between the main connector and the expansion ports to do what you want, it's potentially a cheaper way of getting going. Although it's based upon an Xtreme, the number of inputs & outputs made available vary based upon the target chassis, which is the main difference between the models and why there are price differences between the Plug-In models.

What have you changed to try to run it in Modelled Mode? This is a fundamental change, and requires reconfiguring a huge number of things, and retuning from scratch. You can't just enable Modelled Mode and expect it to work.

The teeth count was only a "limitation" in the G4+, and only really applicable if you had a really "busy" ECU, such as a V8 with sequential ignition & injection, quad cam VVT, dual bank knock monitoring etc, the speed calculation would tend to top out at around 500Hz. On something less "busy", then higher frequencies may work but generally aren't guaranteed. With the G4X, though, the processor is much faster, and it doesn't have the same kind of limitations - all digital inputs are capable of over 10,000Hz, so a 43 tooth ABS ring won't be an issue. That said, as someone has unfortunately already butchered your car removing rings & sensors, there are other options. On my Ford Anglia, I'm picking up rear speed from the diff -> propshaft joint, where there's 4 bolts, so I get 4 x Diff Ratio pulses per revolution. For the front, I was picking up on the 4 bolts that hold the brake disc to the hub, but I found that the mismatch in ~16 vs 4 pulses per revolution caused a bit of an issue with it calculating the "slip" percentage, so I added some extra bolt heads to increase the number of pulses up to 12, and with a change in diff ratio at the same time (from 3.96 to 3.69) means it's now 15 vs 12, which works much better This snip from a log file shows the issue I was having, the "staircase" effect on the front wheel speeds with only having 4 pulses compared to 16 for the rear. Certainly on the G4+, each time either sensor has a pulse, it recalculates the Slip % (difference between Driven and Non Driven speeds), and as I had the Driven speed ticking up more regularly, the Slip % was calculating based upon the last known speed from the Non Driven wheel, so the slip % kept going up & down, which meant I needed bigger values in my Slip Tolerance table, otherwise it was activating too easily. Since adding the extra bolts, this has become much smoother, and track much closer together during acceleration, and the traction control can be tuned a bit better now

For anyone following here, I've been talking to Wheelspk on Facebook, where he also posted the same questions. From that log, I've suggested the following:

I'd say either CAN H and L are reversed, or there's a bitrate mismatch between devices on the bus.

Give Brands Hatch Performance a ring, they do loads of Link ECUs.

I suggest you go and look at the Help, and get your head around the basics of what is defined as an Input and an Output. This requires an OUTPUT from the ECU to activate for boost control. But, basically, you feed an ignition switched power supply to one side of the solenoid, then the other side of the solenoid connects to your Aux Output. The ECU will pulse this to ground to activate the solenoid.

If I remove my thought of having two separate output styles for under temperature and over temperature, then I've found a way to make it work kind of as expected, in that I can have a solid output if I have a Pressure issue, and a pulsing output if I have a Temperature issue. Obviously, the actual values will vary and these are just examples - these haven't been used on a vehicle yet. I had to shuffle some Virtual Aux around as only 1-3 are available for use as an axes parameter for a table. I guess there's no chance we'll ever get an update to allow the use of VA4-8 for this purpose? Is there a way to get a Timer to constantly repeat without doing what I'm doing with Virtual Aux 5? I found this concept in another thread here on the forum.

Could be Overrun Fuel Cut, which should be disabled during tuning. Also, check your Error High and Error Low values for the analog input, as I believe the Innovate uses the full 0-5v range for its output, with 5v being fully lean. Your question would have also been simpler to answer if you'd provided a copy of your configuration and a log file which has the issue present, because at the moment we're all just guessing without having anything but what you think is relevant.

Are you sure you haven't reversed the pinout - some diagrams specify it looking into the harness connector, some specify it looking into the sensor itself.

I'm considering trying to have something similar to the following: Oil Pressure low - output on solid Oil temperature low or high - output "pulsing" (slowly when under temperature, quicker when over temperature) I've managed to get the 2nd part (which I thought was probably the hardest!) working, using the following: (Ignore the actual values, I'll of course make these more sensible once I get it working) And the first part works with this GP RPM Limit 1 table values and Virtual Aux configuration: I found that with ignition on, but engine off, the Limit isn't "Active", so also need a static low limit for the output to be on solid prior to cranking. So - if I wanted only one of the two things, then I think what I've got above would work well enough for either one individually. But, the fun comes (and where my abilities ends?) in trying to combine both together into a single output to the light in the dash... If anyone can help me here and provide suggestions, then that would be appreciated! Or, if someone can tell me that this will never work, then that's useful too, and I'll re-evaluate my theory about how to use this output

A new gauge is about £15 - and that's all my issue was - my actual FPR was working perfectly, but my gauge was not.

If you're struggling this much with a tune that's come from another vehicle with the same hardware, then I suggest that you've probably got a physical issue on your car. My first port of call would be to confirm your fuel pressure - don't just trust the gauge you have, it might be wrong. You need two separate additional known values to confirm against. "A man who has one watch always knows what time it is. A man with two watches is never sure."

You can chain many devices together on a single bus, the only requirement is that they all run at the same bitrate.

From the Help: However, this Note potentially contradicts this? So... I guess a question might be are you talking about initial ECU startup, or after stalling?

This appears to work with a Serial interface, which no Link ECUs will support. Best you might be able to do is an Arduino-type device communicating via CANBUS, to then output to the required Serial stream required for these devices. That said... it seems that maybe the source is available for the gauge itself, so you could instead modify this to accept a PWM input to set the value(s). However, you'd be using a lot of ECU outputs, whereas if you use CANBUS you use no outputs on the ECU itself.

You've missed out lots of critical information - mainly what injectors do you have, and do you have good, correct data for them, especially deadtimes. If you don't have good injector data, then forget Modelled Mode, and stick with Traditional. The Master Fuel value here can be adjusted to allow you get a good range of values in the fuelling table. It's not VE in this instance, so it doesn't matter what the numbers are, so long as the maximum value you have is under 150. There's a whole host of cold start enrichment that needs modifying once you've got your fuelling correct at operating temperature. Post a copy of your actual tune (.pclr file) as this contains all the settings the ECU is trying to run with. I got myself a fuel pressure sensor, and found it was reading vastly different to the mechanical gauge on the FPR. I added a 3rd source (the MAP sensor of the ECU itself) and used some regulated compressed air with the fuel sensor, fuel pressure gauge, and ECU's MAP sensor (away from the fuel system totally) and found that my MAP sensor and new fuel pressure sensor read the same values, but my fuel pressure gauge was different. Swapped this gauge out with a new one (which is MUCH cheaper than a whole new FPR) and low and behold, the gauge matches the sensor now. What I'm getting at is that I had been running what I thought was 3 bar fuel pressure, but I was actually running about 4.5

In the configuration posted in the opening post, you have a RPM limiter set against Lambda too, so it might be hitting this? Logs showing the issue will always help, otherwise people are just shooting in the dark.