Electredge

AIM dash will not appear under the CAN device tab... only Link items will pop up here. 

Both your ECU and dash config are fine, most likely a wiring issue.  Can you attach some pics of the CAN wiring between ECU and dash?

I had an email from HTG in June 2021 and I said yes we would be happy to set up either a predefined stream or templates etc as well as offer any info or setup instructions for documentation, he said he would get his developer to come back to me with what they wanted but I haven't heard anything since.  
I have helped a few people set up the basic comms before so can probably help you.  

Direct control from the ECU won't be happening for modern transmissions as they require way too much IO. Communication with the factory TCU over CAN should be coming, I'm working on getting an ECU in my N54 powered 135i in my spare time which will involve a new CAN mode which should support the various transmissions that come in vehicles with that CAN setup (proper auto, single clutch automated and DCT).
What vehicle (model and year) and what engine do you have?

I thought I'd toss some of my wishlist items together. Some of which I don't currently need but would like the functions for future and others i've made work arounds for.
I'm happy to provide working examples or further justifications to the use cases. 
 
Parameters
Air Density Bank 1 (Kg/m^3) or (g/m^3) - Currently resolved in Math Channels Air Density Bank 2 (Kg/m^3) or (g/m^3) MAF 2 Air per Cylinder 2 Measured (g/cyl) MAP 2 IAT 2 MAF 1 VE (%) ((“g/cyl”/p)/“Cyl Vol”) - Currently resolved in Math Channels MAF 2 VE (%) ((“g/cyl”/p)/“Cyl Vol”) MAF Avg MAF VE (%) Avg MAP Avg IAT Avg Wastegate %DC 2  
Tables
16 more table allocations to better support V8s CAL tables to have 16 more axis points. More granular CAL tables for MAF sensors GP Outputs to be friendlier for “user definable” - Currently resolved in GP output DC (1tbl)or PWM(2tbl) Unit output (g/sec, KPA, ms, g/cyl, %, etc) Allow decibel placement e.g. 0.000, 0.00, 0.0 To allow only 1 table consumed with Larger units than 100. Fuel Table Ratio table to allow for 3D axis - Currently resolved in GP output DC Additional “Torque Request Table” channels. -  Currently resolved in GP output DC(Interpolate) Two tables To be able to switch between or interpolate between. Wastegate %DC 2 Allow for second WG Solenoid to control a second turbo. Closed Loop Boost control for second turbo. Single(Parallel) or Twin(Compound) staged control. 4D & 5D Fuel tables assignable. 4D table can be assigned to fuel table 1 and/or fuel table 2 5D table can be assigned to fuel table 1 and/or fuel table 2  
Parameter/Channel functions
MAF to allow for averaging over time - Currently resolved in Math Channels Math Channel example - av(MAF,0.06)  
CAN
Gen 1 FRS/BRZ/86 ***I do have pretty much all of the surface values worked out(CEL,Fuel,PS,ECT,RPM etc)*** Gen 2 BRZ/86

The fuel pump can be connected to different pins depending on region.  Try changing the fuel pump jumper to the alternative option.

You will need to log gear pos voltage at 500Hz minimum to see enough detail.  It is not going to work correctly with a gear position voltage that rolls past 0V and back to 5V during a normal shift.  It is ok for that to happen during an R or N shift but not for a normal shift.  Your voltage doesnt reflect barrel rotation so the "next gear voltage margin wont be applied incorrectly.  If we plotted gear pos voltage (Y axis) Vs gear barrel rotation yours would look something like below.  
So the correct shift end would be 0.15V before 5th which is 4.65V where I have put the green dot.  But because the ecu only knows 4th is 0.34V and 5th is 4.5V, it will use 4.5-0.15 = 4.35V as the shift end (where I have the red dot), which is only about halfway through the shift.  Notice also 4.65V would occur just above the red dot as well so even if you fudged the voltages somehow the shift end would still occur in the wrong place.  

you can leave it on if you use a math channel
 

Thanks for the help with this! I found the culprit. Pulled the sensor out to test it with heat and pressurizing it and everything worked. So I took a closer look at the install and noticed that the probe on this sensor is longer than the AEM unit I was using. It essentially blocked the oil passage in this AN to NPT adapter I was using off the block.  No oil was getting to the little hole that measures pressure and only the tip of the sensor touched any oil. Installed it on a different port and it worked! 

Fuel temp overrides Ethanol Temp.  If you only have a flex sensor connected the ethanol temp will be used in the fuel calculation.  If you have only a fuel temp sensor/no flex then the fuel temp sensor is used.  If you have both a flex sensor and a separate fuel temp sensor then the fuel temp sensor is used as the fuel calc input.  

Nearly always with road car engines with the injectors spraying directly at the back of the valves, the ideal injection angle for efficiency is around 360-400BTDC at idle and light loads, this same angle usually gives the best transient behaviour as well.  
In many cases with mild engines the difference between ideal injection timing and "timing miles out" is small, you may only see a small correlation in lambda Vs PW or maybe hear a slightly sweeter idle without any obvious measured changes.  On a well-balanced low inertia chassis dyno with a good control system you can usually just detect the small change in torque but it is not much above the general noise level.  Above about 30% DC the timing becomes irrelevant in this type of application.
As the engine gets more serious however - increased valve overlap, high compression, itb's, outboard injectors etc, then the differences become far more apparent and worth chasing  - often even essential in terms of airbox fire risk from stand off etc.  

show-off lol

You will typically see small/short spikes of error accumulator during heavy foot work - maybe up to about 15, maybe 20 worst case and it should recover to zero within a 10th of a sec or so.  
Log I just pulled from my car below, the worst TP error spikes reach a count of 6.  You can see E-throttle target, TPS sub and TPS main barely deviate from each other at all, you cant even see the green or yellow TPS traces...
  

Our CAN lambda uses the Bosch CJ135 chipset which is their most advanced digital LSU controller, it performs many more error and signal validation tests than most other performance aftermarket controllers as well as some less common advanced functionality for sensor life improvement such as dewpoint detection of the exhaust gas for the correct heating strategy at startup.  It requires a stable clean power supply with adequate current for many of the tests to be effective.  For performance engines which may run CLL at full load, often coupled with a fairly extreme environment for the sensors such as aggressive limiter bangs, fuel additives, silicone poisoning etc, we think it is an advantage to have as many of these validations functional so CLL can be disabled and warn the driver when the signal is suspect.  Yes you can add a capacitor as a fudge in cases where the errors are being falsely reported due to excessive inductive noise or voltage drops, if a clean source cant be found, but this does potentially weaken the ability to detect real errors at the same time.  
There was a small hardware revision to the CAN lambda about the middle of last year in an effort to allow a bit more supply noise.  

Actually given it takes 1s to shut I think it's a mechanical or a TPS reading issue as it shouldn't take 1s to shut even with no power to the throttle
Can you replicate the log while watching the throttle to confirm TPS is correct?

Jon, 
I just replied to your email a short while ago assuming it is the same car we were talking about.  Im 99% sure this is the brushes bouncing off the commutator from vibration. 

Technically possible and kind of already done with CAN Lambda detection and setup, has been mentioned before and is in the list of things to look at doing at some point in the future but no real time frame on it.

A G5 plug-in board is in development but its main intent, at least initially, will be for any future GDI plug-in applications.  All the existing plug-in ECU's will remain as G4X for the foreseeable future.  G4X and G5 use very similar firmware so G4X will continue to be developed and G4X will continue to get most new software functionality that the G5 gets, with the exception of GDI stuff and possibly a couple of others related to hardware such as GPS. 

I'm going to assume there's a reason for why math blocks have a 20 character limit, but thought I'd ask anyway. I have to use 2 math blocks to calculate some channels due to needing just a couple more characters. You eat into the characters pretty quickly with just basic equations. Would it be possible to increase this limit?

They'll be longer in the next release

I assume it means "What Lambda would have read without the CLL correction"?

For a true "rev match" you would have to use the motorsport gear shift function which is over the top for what you want I think.  
To use the gear shift function to achieve a rev match it would be done something like this:
In road car with an H pattern shift and no strain gauge or similar on the lever then really the only thing you have to indicate to the ecu that you want to initiate a gear shift is a switch on the clutch pedal.  But that alone doesnt tell the ecu whether you want to do an upshift or downshift.  So you use a GP output to asses a whole lot of conditions that you think would be present for a down shift but not an upshift.  This, for example, could be something like Throttle pedal is not pressed, clutch and brake pedal are both pressed and the speed is above 30kmh.  Whenever the ecu see's all of those conditions true then it will initiate a downshift sequence.   
Next, for the ecu to be able to rev match, it needs to know what gear you are in and the ratio of the current gear and the ratio of the next gear that you want to engage.  Since you dont have a gear position sensor, you will need a working speed sensor so the ecu can then determine which gear you are in by using speed, RPM and gear ratios. 
With all of that the ecu would then have enough info to generate an RPM target that it needs to hit with the blip based to achieve matched input and output shaft speeds during the shift.  This RPM target can be met in 3 different ways.  1). You can use a speed match limiter - this is where the ecu blips the throttle a little more than is required and introduces a rev limiter to control the RPM at the desired target.  This is the most accurate and fastest blip. But you dont really want to be bouncing on a limiter on every shift when driving around town etc. 2). You can use what we call an RPM target blip. This is where the ecu performs a blip then removes the blip once the target RPM is reached. Since the throttle doesnt close until you are already at target you will get quite a bit of overshoot with this method.  3). A predictive blip, this is where the ecu looks at the rate the engine is accelerating during the blip to predict how long it will take to reach the correct RPM, it can then close the throttle early so you dont get as much overshoot as method 2.  
Having said all that, it is rare to do a proper RPM match for a road car with a synchro gearbox, the normal technique is just to switch to a 2nd e-throttle target table when your downshift conditions are met.  That table can have RPM Vs gear or Speed Vs gear on it so you can command more blip for high speed gear changes and less or none for low RPM/speed shifts.  
 

You have a blend table for the fuel properties so you can set that up with whatever values you like in it.  For example use 100% of "fuel 2" properties when ethanol sensor is reading 60% or whatever.  
 
I have seen others quote similar relationships before, and I will say up front Im no chemist and I have never personally tested it myself, so really im just another internet expert with an opinion - but I have researched the ethanol content sensors probably more than most.  From my understanding of how an ethanol content sensor works I have some doubts that these assumed linear relationships are correct.  Im suspicious the people or person that came up with this quote have probably only tested with methanol at room temperature - or at least only tested over a very small range of temperatures.  Both permittivity and conductivity of most fluids vary greatly with temperature, these are the properties that the ethanol sensor uses to approximate ethanol content.  To generate ethanol content from temperature, permittivity, conductivity and dielectric constant, none of which relationships are linear, would have to be hardcoded in either multi-dimension lookup tables or complex equations. I just cant see the result of all those variables for 2 very different solvents when put through a complex set of equations, somehow by magic work out with the same perfectly linear relationship over a range of temperatures...    

One problem with that math is that 10% of .8 lambda is not the same as 10% of 1.0 lambda.  It would still be close but ideally you would modify your math as follows:  a*(1+(b/100)+(c/100))

Would something like this be suitable where you can select a percentage fuel trim runtime to 'remove' from the mixture map (i.e. if this trim is adding 20% fuel the lambda value at that point in time will have 20% added to it so that Lambda value displayed is what the lambda would have theoretically been if the trim was at 0%)

Not sure how much value I see in this but will look into it.
Best way to tackle this is to use the conditional filters to remove transients
What filter conditions do you normally use and what would you want to use in addition to your current filters
For more complicated filter setups if you know what filtering you want ahead of time you could setup a gp output, gp pwm or mathblock to create an easy to use conditional runtime.
will look into this