Vaughan

All 0's just means it is always using just the IAT as the air temperature instead of a mix of ECT and IAT. The charge temperature is used to calculate the density of the air coming in so that  the volume of air going into the cylinder as specified by the VE table and engine capacity can be converted to a mass of air.
A value of 100 in the table means that the air coming in is the same temperature as ECT and a 0 means the air is the same temperature as the IAT runtime. a value of 50 means that the air temperature is (IAT +ECT) / 2.
The charge temperature approximation table is always used all of the time.
I'll have a look through the code.

CLL is disabled when any cut is active

Ah I gotcha now. I didn't realize I could do that, I'll have to look up a connector pinout and see which ones can be used without causing further issues haha. Hacking into the factory harness worries me, but I'll do my research and see where I can pin it to in order to get a reading. Do you have any pointers on that? Not sure how versed you are in S Chassis specific stuff but any pointers would be appreciated .
 
Edit: a quick Google search is showing me I can use AN 4 from the MAF plug or AN 1 from the 02 sensor plug. I'll try to figure out which wires these are at the engine bay plug side, should make it easier than running a wire back to the ecu.
Edit 2: I've found the pinout for my ecu in PClink, this should make it far less confusing. I'll double check continuity to make sure I have the right wires but looks like ill be able to use AN Volt 2 fairly easily.

To confirm you are looking in the ECU Settings tab?

That's my bad, will be fixed in the next release

Just to update here. Manage to get the speed input working. The problem was somehow the sensor sits a little to far from the wheel that causes low reading. Adjusted the distance of that sensor and we got a good reading
now everything up and running. @Vaughanyes same goes. only detect speed more than 20-25kph
 
Thanks @Adamw and everyone for your respond

On 2nd thoughts gp idle isn't a table just a value and slapping CAN DI on the axis of the Idle base position table wouldn't give you the ability to remove the extra throttle at idle so 2nd E-Throttle table is probably the best option. Slap RPM on one axis and have 0% APS be something bigger than 0 at Engine speeds above like 2000rpm and 0% below ~2000rpm. Note the value you put in the e-throttle table isn't the exact value you're going to get, you're going to get some combination of the idle target and the E-Throttle target so have a play with it.
As a side note I recently had a play with one of my cars using antilag but only enabled under conditions that I want pops and bangs as Antilag gives you the ability to control cut percentage, ignition trim, fuel trim and it disables overrun fuel cut while active but I couldn't get it to work on my car due to what I suspect was too much vacuum/not enough air.

Yes you can put the CAN DI in as the activation for the 4d/5d ignition and Fuel tables so that they are activated at the same time.
You could do a 2nd E-Throttle table or if you are using the E-Throttle for idle control you could use the GP Idle trim setup to increase the throttle position when you are off the accelerator pedal.

Sorted. I downloaded the latest version of firmware. All good thanks. Base timing was fine too so didn’t need to adjust. 

Leave overrun fuel cut off but setup a gp rpm limit as shown here, it should act pretty much the same as the overrun fuel cut shown but won't cut when CAN DI 1 is active.
 

Having a look at dbc files at the moment and it looks like they're designed for dash style setups where the runtimes are generic and it's all about displaying that data. Can either of you provide an example (file or explanation) of how you would want to use a dbc file with an ECU?
Would you be wanting to import a dbc file to tell the ECU what to transmit, importing it to tell the ECU what data to receive or a combination of both (loading one file for transmit and another for receive)
Or are you wanting to generate a dbc file from a custom CAN stream setup?

exporting to a dbc shouldn't be too difficult, we can take our runtime names and slap them in a file, little bit of UI work required around selecting what you are saving to a dbc, e.g. saving all channels, just one channel or specific channels and a little bit of hardcoded work around defining built in CAN streams as dbc and merging them into generated files if combining multiple channels into one file.
Note I've only found one example of compound ID/multiplexed messaging with multiple frames for one ID being made into dbc files and that format doesn't appear to be widespread so anything which uses compound IDs might not be dbc convertable.
Would be theoretically possible to import a dbc, throw up a window which the user uses to connect dbc Signals to CAN Analogs, CAN DIs, CAN Frequency, CAN TC and the short list of other CAN receivable runtimes. We don't currently have a way to name CAN Analogs etc in isolation as usually they are fed into a function like Oil Pressure or GP Input instead of having a label on the runtime. Maybe we should add user configurable labels for the runtimes.
We don't have any internal support for user created enumerations at the moment.
This could be covered by just adding labels for the PDM runtimes, feels like a dbc would be a bit redundant here. But again another good point that maybe our CAN runtimes should have configurable labels.
Importing a dbc file into the ECU to use a specification for what the ECU should transmit would the user linking every single signal in the dbc to an ECU runtime when importing  which would still use a lot of time. When reverse engineering a CAN Bus do you create a dbc file for ecu transmit and another for ECU receive as from what I can see there is no way to specify transmit or receive in dbc files, it's all just assumed to be receive.
As another note from what I can see dbc files don't allow you to specify how counters work or to specify fixed values so again very focused on specifying the receiving side rather than the transmit side.
I made a basic sniffer in PCLink but it needs a large amount of user interface improvement to move it beyond a basic list of the messages and values sent over the last set time period. Would like to do a semi live view with a row for each ID and the values displayed and updated realtime and also the ability to save a log but that will take time and time for that hasn't been set aside yet.
 
Basic summary from a quick investigation of dbc files yesterday is that generating them from user streams and providing pre made ones for fixed built in streams  is possible (as long as compound IDs aren't being used) but anything involving importing them as something for the ECU to receive or transmit still involves a lot of user input, the only useful information from the file being IDs, byte order, multi/offset, bit location and width. The signal names and units aren't realistically importable without forcing a parameter selection for each and every one.

AL Fuel cut is waiting on testing

Outstanding response. Answered all my questions! Thanks Vaughan

Perfect, thanks again for the help!

Most likely just a hall affect style square wave. You would probably want the DI pullup off if you tap into the cruise signal.

Update your firmware, there was an issue fixed in 6.22.8 around map limit statistics reporting.

The 3 pin cruise sensor is only used for cruise control but if the cable setup is in a bad way you could theoretically wire it up to the ECU as well and calibrate the ECU to suit. The Power steering does use the speed signal from the dash though so improving that is still a good idea.
On my car I installed a later gauge cluster (needed different plugs) and ran a hall sensor from the gearbox to the ECU with the ECU sending the speed to the gauge cluster speedometer so that I could correct for different wheel sizes. ST18X Celicas have a mechanical to electrical conversion on the gearbox that screws onto the MR2 gearbox too or later gearboxes (with the better synchros and lsd diffs) have hall sensors in them with no provision for a speedo cable.

Looks like you're hitting the rpm limit on each shift which causes a fuel cut which causes it to report lean (due to the missed ignition event), the lean patch happens about half a second after the cut which will just be a transport and sensor reading delay.

You're still losing triggers, can you take a trigger scope while the engine is cranking please
Lambda 1 isn't doing anything, if you attach your basemap I can check your settings for it

You're losing triggers, looks like there was a fix in for the EVO1-6 trigger pattern in a newer firmware version than you have, please download the latest PCLink from https://linkecu.com/software-support/pc-link-downloads/ and then update your ECU to the latest firmware.

Thank you for explaining this one ... it makes sense now 
I'll set this up tomorrow

The typical method of hysteresis would be (temperature > lower value AND output already on) OR temperature > higher value.
So use a GP Output for each feeding into virtual Aux's and then a GP Output that takes both the Virtual Aux statuses and feeds it into the actual output or feed the Engine Fan output into a Virtual Aux, use a GP Output into a Virtual Aux for the IAT and then a 2nd GP Output that looks at the engine fan status or engine fan Virtual Aux and the IAT GP Output Aux.

The typical method of hysteresis would be (temperature > lower value AND output already on) OR temperature > higher value.
So use a GP Output for each feeding into virtual Aux's and then a GP Output that takes both the Virtual Aux statuses and feeds it into the actual output or feed the Engine Fan output into a Virtual Aux, use a GP Output into a Virtual Aux for the IAT and then a 2nd GP Output that looks at the engine fan status or engine fan Virtual Aux and the IAT GP Output Aux.

The typical method of hysteresis would be (temperature > lower value AND output already on) OR temperature > higher value.
So use a GP Output for each feeding into virtual Aux's and then a GP Output that takes both the Virtual Aux statuses and feeds it into the actual output or feed the Engine Fan output into a Virtual Aux, use a GP Output into a Virtual Aux for the IAT and then a 2nd GP Output that looks at the engine fan status or engine fan Virtual Aux and the IAT GP Output Aux.