Adamw

Yes they are completely sealed, the internals are fully potted in epoxy and the anodised aluminium seems to stand up well to hasrsh environments.  

Yes they are completely sealed, the internals are fully potted in epoxy and the anodised aluminium seems to stand up well to hasrsh environments.  

Sorry, I forgot about this one.  Your fundamentals were already mostly set up pretty well.  I changed fuel equation load source to BAP since you dont have a MAP. 
Imported some fuel and Ign tables from a similar engine.  A few tweaks to cold start, charge temp, lambda target, RPM limiter and trigger arming threshold. 
Post a triggerscope if you can - it is a bit odd to have the sync tooth set to 8 so just want to check that is ok.   
B16A ITB.pclx

Im suspicious of your MAP sensor calibration.  The fuel pressure actually increases by significantly more than the expected 1:1 ratio with MGP.  
Snip below shows a 209kpa FP increase for a 102Kpa MGP increase.  It could potentially be a fuel press sensor issue or regulator issue, but an incorrect MAP sensor cal fits your symptoms better.  

 
 

Does your car have the 2 speed fuel pump on pin 21?
 
Your accel enrichment cold correction table is zeroed out.  The smallest value in there should be 1. 
 
You need to change the wiring to suit the ecu, this is why it is sold as an Evo3 ecu and not a 3000GT ecu.  

I would put 1.8ms right across the 14V row and 1.6 across the 15V row, I doubt they will need any more than that for an NA engine and these coils draw a heap of current as you increase dwell.  Only add more if you dont have enough ign energy.  
You dont really need a 8K column unless you want to change dwell between 7 & 8000.  But it you wanted it then click on the table then hit the X key.

Cant really tell from just the voltage, you really need to put an amp clamp on it to see if the alternator is outputting its rated current or not.  

There is no serial output on the G4X so the only way to use realdash with G4x at present is via obd2.  I’m testing a CAN bus connection for them soon but still waiting on the hardware to arrive.

Your throttle tracking looks ok to me but your target looks pretty tame, that could possibly make it feel pretty lazy.  For example at the time mark -3:12 in your pic above we cant see the actual APS as it is off the screen, but the axis goes to 23% so we can say you have more than 23% pedal commanded, but your TPS target is only 12.5%.  

Here is an example.  I have a GP output that will become true when the both the brake has been active and the TPS has been > 60% for 5seconds.  The 3rd condition "OR virt aux 8 = active" is used to latch it on once conditions are met (ie you dont want it to return to false/off as soon as you take your foot off the brake).  The catch with this logic is it works backwards compared to what we what - we actually want to turn off antitheft after 5 sec, not turn it on.  And I couldn't see a nice way to do that in the GP output - possibly I just need more coffee to see it.  So anyhow I used a mathblock to invert the logic, then we use that mathblock to turn the antitheft function on/off:
  
 
 
There are many ways you can do stuff like this, often it is hard to think through all of the logic in your head prior to setting it up, so I find it easier to sit in the car, set up a blank page in PC link displaying the parameters and statuses you are working with and work through one step of the logic at a time.  An example below to hopefully answer both of your questions, or at least give some direction.
Lets say I want the CE Light to flash fast when the Antitheft is active, and switch over to normal CE light functionality once antitheft is off.
First I need to generate the flash.  We can use a GP output on delay/off delay to achieve this.  This GP output will make virtual aux 1 flash on/off when the antitheft status is active:

 
CE Light output is assigned to a virtual aux rather than the real output that is connected to the lamp:

 
Now we need some logic to switch between our lamp acting on the antitheft flash virtual aux or the CE Light virtual aux.  I really needed more conditions than a GP output can do so I used a math block to achieve this.  The equation (a&c)|(b&!c) means the math book will be true when (a AND c are true) ie antitheft is active and the flash is in the "on" period), OR (b is true and c is not true), ie CE light is on and antitheft is not.  The result of this math block will be a 1 when we want the dash lamp on and a 0 when the dash light should be off:
 
 
Now we can control the dash lamp that is connected to aux 3 using the result of math block:

 
 
  
  

Here is an example.  I have a GP output that will become true when the both the brake has been active and the TPS has been > 60% for 5seconds.  The 3rd condition "OR virt aux 8 = active" is used to latch it on once conditions are met (ie you dont want it to return to false/off as soon as you take your foot off the brake).  The catch with this logic is it works backwards compared to what we what - we actually want to turn off antitheft after 5 sec, not turn it on.  And I couldn't see a nice way to do that in the GP output - possibly I just need more coffee to see it.  So anyhow I used a mathblock to invert the logic, then we use that mathblock to turn the antitheft function on/off:
  
 
 
There are many ways you can do stuff like this, often it is hard to think through all of the logic in your head prior to setting it up, so I find it easier to sit in the car, set up a blank page in PC link displaying the parameters and statuses you are working with and work through one step of the logic at a time.  An example below to hopefully answer both of your questions, or at least give some direction.
Lets say I want the CE Light to flash fast when the Antitheft is active, and switch over to normal CE light functionality once antitheft is off.
First I need to generate the flash.  We can use a GP output on delay/off delay to achieve this.  This GP output will make virtual aux 1 flash on/off when the antitheft status is active:

 
CE Light output is assigned to a virtual aux rather than the real output that is connected to the lamp:

 
Now we need some logic to switch between our lamp acting on the antitheft flash virtual aux or the CE Light virtual aux.  I really needed more conditions than a GP output can do so I used a math block to achieve this.  The equation (a&c)|(b&!c) means the math book will be true when (a AND c are true) ie antitheft is active and the flash is in the "on" period), OR (b is true and c is not true), ie CE light is on and antitheft is not.  The result of this math block will be a 1 when we want the dash lamp on and a 0 when the dash light should be off:
 
 
Now we can control the dash lamp that is connected to aux 3 using the result of math block:

 
 
  
  

For the cam and crank sensor these need to be connected to trigger 1 and trigger 2 inputs.  These are both available either at the main ecu header (check the pinout in the manual) or at the original CAS plug.  Most commonly you would just cut the original CAS plug off the loom and run 2 new shielded wires from there to the new cam and crank sensors.  Yes you will need to set the ecu up with the correct trigger settings for the new trigger system.
 
Doesnt the CA18 have a factory IAT sensor?  If not the expansion loom may be easier for the IAT.  The MAF loom only have a AN Volt input from memory so cant be used directly for a temp sensor.  Knock control wiring is easy, set up any tuning is probably best left for someone experienced.  
 
Yes.
 
The Analog wideband can go into the narrowband o2 input yes.  Note Innovate doesnt have an analog ground so make sure the black wire is connected to the engine block for best chance of success.  You wont be able to connect the oil press/temp sensors to the ecu - the innovate does something really weird with measuring those sensors - they only have a single analog to digital converter for reading the two sensors, it constantly swaps back and forwards between the two sensors and turns a pull-up on/off everytime it does that so the ecu will see all this weird behaviour.   

Here is an example.  I have a GP output that will become true when the both the brake has been active and the TPS has been > 60% for 5seconds.  The 3rd condition "OR virt aux 8 = active" is used to latch it on once conditions are met (ie you dont want it to return to false/off as soon as you take your foot off the brake).  The catch with this logic is it works backwards compared to what we what - we actually want to turn off antitheft after 5 sec, not turn it on.  And I couldn't see a nice way to do that in the GP output - possibly I just need more coffee to see it.  So anyhow I used a mathblock to invert the logic, then we use that mathblock to turn the antitheft function on/off:
  
 
 
There are many ways you can do stuff like this, often it is hard to think through all of the logic in your head prior to setting it up, so I find it easier to sit in the car, set up a blank page in PC link displaying the parameters and statuses you are working with and work through one step of the logic at a time.  An example below to hopefully answer both of your questions, or at least give some direction.
Lets say I want the CE Light to flash fast when the Antitheft is active, and switch over to normal CE light functionality once antitheft is off.
First I need to generate the flash.  We can use a GP output on delay/off delay to achieve this.  This GP output will make virtual aux 1 flash on/off when the antitheft status is active:

 
CE Light output is assigned to a virtual aux rather than the real output that is connected to the lamp:

 
Now we need some logic to switch between our lamp acting on the antitheft flash virtual aux or the CE Light virtual aux.  I really needed more conditions than a GP output can do so I used a math block to achieve this.  The equation (a&c)|(b&!c) means the math book will be true when (a AND c are true) ie antitheft is active and the flash is in the "on" period), OR (b is true and c is not true), ie CE light is on and antitheft is not.  The result of this math block will be a 1 when we want the dash lamp on and a 0 when the dash light should be off:
 
 
Now we can control the dash lamp that is connected to aux 3 using the result of math block:

 
 
  
  

Try this.
51egc81050CC with AEMnet.pclx

I hate those clown fuses -- no sense of humor!

New update is available here:  https://linkecu.com/software-support/pc-link-downloads/
Release notes:  https://www.linkecu.com/pclink/Link Engine Management PC Link G4X Updates 21042021.pdf
Important notes:
This firmware changes the sync point in some triggermodes so base timing must be checked after doing this update.  
There is a new "Slow Comms" setting added, this may help those with communication problems that are due to some laptops with USB ports that are slow to respond.  This a an ECU setting so the ecu needs the latest firmware instaled before you will have this setting available, you will find it in the main configuration menu (where you set number of cylinders and engine type etc). 
Any new issues related to this update can be reported here.  

It doesnt matter if it moves.  I dont know how to make it any clearer, there is no advantage or need for 2 cam sensors.

I looked at this a bit closer today, there is not a lot of solid info around for the F20C temp sensor, but im pretty sure from the few clues I found it should use the "Honda K20" calibration.  Our base map is set to "Std Bosch NTC" which I assume is what you are using.  The car that our S2000 basemap came from was pretty modified so it possibly didnt have the factory temp sensor in it.  The reported temp will be about 5degC too high if using the bosch calibration with the honda sensor so that may be what you are seeing.  

This is why I asked what controller you had in my first post.  For the OEM subaru pump controller you need to use 80Hz, and it only has 3 speeds.  Set up below from our V10 base map, this mimics the factory control.  

If the engine appears to be running correctly when the lambda is reading 6.5 then yes I would assume the sensor has failed. 

If your car has cruise control you could set up something like "hold the set button and brake pedal together for more than 5 seconds" to disarm the antitheft, if it doesn't have cruise you could do something like throttle pedal >50% and brake pedal together for more than *sec.  I would also set up something like the CE light to flash when antitheft is active so you know when you have successfully met the conditions.

Yes, you can connect it via CAN bus (most accurate) or using an analog input such as pin 56.  

The stock O2 sensors are narrowband so not much use to you unless you have a catalytic converter and have some emissions regulations to meet.  But if you want to use them then you can connect the 2nd one to any spare analog input.  If you want dual bank closed loop then I would suggest 2 CAN based wideband lambda devices.  

Resolution will be no problem.  For the frequency divider I dont know of a good commercially available option - there are things like "speedo correctors" etc but they tend to be expensive for such a basic requirement.  I usually suggest this:    
Note there is a mistake on that drawing, it should say this circuit will divide by 8, not 16.  

Yeah it looks like you better contact tech@linkecu to get it inspected.  I cant think of any explanation for what you see here assuming it is only connected to a stable power supply.