MagicMike

I've successfully got customers using the CAN keypad on link G4+, I've got it working with both Latching and momentary button functionality too.

We use the Blink Marine Keypad and load their "Motorsport" firmware, this gives you multiple outputs on the CAN stream, and depending on what logic you want to use (Momentary, Latching, 3 Pos or 4 Pos) You ask the link to listen on a different CAN address for the button presses.

This essentially puts the button press type back on the Keypad, not the ECU.

 

Rant time...
That is just innovate being innovate.  They used to also spit out the very robust NTK and LSU4.2 sensors at the same rate in the old days when they used to work with those sensors before the LSU 4.9 was even invented.  
They control the sensor completely differently than it was ever designed to be controlled so the controller is very sensitive to sensor response time.  The founder Klaus was a very smart guy that invented this new measurement strategy which gave very fast response and made control cheap/easy at a time (20years ago) when wideband controllers were a very expensive tuning tool not affordable for consumers.  You can read his patent here:  https://patents.google.com/patent/US6978655.   But when Klaus sold up shortly after the first LC1 was released their wideband controllers never got any improvements or fixes since.   Every innovate controller produced since is just a copy/paste and has the same issues the first ones had 20 years ago. As soon as the sensor ages a little or gets too hot or too cold, the innovate will report it as Error 2 or 8 and innovate will tell you the sensor has "failed".  It has not failed and will still work on any other LSU4.9 controller that uses proper control.  With Innovate controllers it is generally not thermal shock as per the NZEFI article.  So dont throw away any sensors the innovate tells you have "failed" until you try it on a non-innovate controller - 99% of them wont be failed. 
You can tell Im not a fan - my old boss used to have 8 of them on his engine dyno.  We used to go through 8 sensors about every 2 full dyno days there.   I still have a filing cabinet full of his "failed sensors" - I'll go through about 2 a year on my dyno - and that is usually only because I drop it. 
 
You certainly could, but if it is only 2-5% at low RPM I personally wouldnt bother.   
 
 
 

Ugh Link please dont waste time on this, focus on firmware features!!!

Wheelspeed input via CAN is fine.  Most of the plug-in ECU's for modern cars get wheelspeed via the ABS ecu.  Not too many wheelspeed to CAN devices in the aftermarket though.  ECUmaster and AEM have one I think.  
CAN DI's can be used for virtual auxes.  
Since there are so many different ways to acheive things, the best way to see if something is possible is to try to set it up in the software yourself, you will quickly find what is possible and not.  List below is what inputs can be received over CAN.  You will notice Analog input and digital inputs options are pretty limited compared to hard wired inputs.  

Hi all,
these will be available also in the next few weeks.
Will work with LINK and ViPEC products
I forgot to mention the unit also has a spare analogue volt input so for example you cold add another temp sensor or connect a wideband AFR signal into it and have that also transmitted via CAN BUS to your ecu etc.
Regards
Dave.
 

CAN EGT-8_Manual.pdf

Another good solid state relay option is the NOS 15620 relay (Nitrous Oxide Systems).  It's got good current capability, extremely low response time, and can be PWM'ed to 1000Hz.  

I'd turn off ignition idle control. It seems to be keeping your idle stable when active. In the log and file you posted, the speed lockout is 20kmh. As soon as the speed is greater than that everything goes weird.
Removing it could help identify other things at play.

The 300Z ecu has two CAN ports so it would probably be easier to wire the OBD2 socket up to the other one.  
The ecu will actually support the OBD2 and CAN lambdas all on the same port, but by default the lambdas run at 1Mbit/s and although that is officially allowed in the OBD2 standard, the vast majority of OBD2 tools only support 250K or 500K. 
You can reprogram the lambdas to run at 250 or 500K though if you wish to have it all on the same bus.  

Pin 1 +5v
Pin 2 signal out to Ecu An Volt
Pin 3 signal in
Pin 4 ground

Realdash now works on Linux! As of a couple of days ago the Developer released a version that works with CAN as well. I'm using a Raspberry Pi 3B and a RS485 CAN HAT.
 
https://www.realdash.net/forum/viewtopic.php?f=5&t=1412

This is the latest firmware version. Unfortunately, the G4+ is not having any major new features or functionality added, and it appears only critical bugs are being considered for fixing.

It would be nice if they did a few minor "quality of life" improvements, but I don't think that's going to happen either

I've love this change to be back-ported to the G4+ too, please!

Yes to both.  

I would do it something like below.   The low pressure lockout will be ignored for the first 1 second whenever the WMI activation conditions are first met.  If the pressure drops low after the system has been running it will shut off instantly.  

This seems to be a long waited feature. Any actual plans to incorporate this into a new release?
+1 from me along with some more log manipulation functions like
"save as" only a section of the log. (marked in the log markers or only displayed on the screen) cut out/delete a section of a log and save it like that (to remove transient sections maybe, so mixture map could be used a little more targeted) easier retrospective log marker or log section creation. shortcut key B does not place a marker in the log if it is used during log playback. Maybe make the log marker window not a popup, rather an individual section like ECU Settings, Log manager, event log and parameters. This would help creating markers and sections much easier when pinned to the left of the screen as it would allow navigating through the log file and creating markers in two clicks pretty much. customizable number of entries (maybe with a sampling rate as well) to use in Mixture map to calculate the actual lambda as right now it is only the first 1000 data points that are used which is not too useful for long duration logs like cold start and warm up

If you put a 100-200ohm resistor between the signal wire and ground that should drop your max voltage down to around 4-4.5V.

2 are 48 are generally caused be a failing sensor, but since you have an error 16 and 26 in there too which are usually power supply related, it would pay to eliminate that first.  Try moving the power wire direct to battery - even if its just with a biot of scrap wire for a test.  If the errors go away then you can look closer at the power source, if error 48 or 2 still remains then replace the sensor - or try swapping with lambda 1 if you have two.  

It is in G4X.  In G4+ it is unlikely to be changed due to it being highly likely to break other functions that use the same block of code and it is not something that has been requested often enough to justify the consequences.  In G4+ cars without a non-driven wheel speed you just assign the same speed source to both driven and non-driven.  

i did a OEM gauges over can with anduino as middleman, and i add parameters to oem dash, maybe that is solution?
 
 

Would this be at all possible?
Instead of having to save each individually?

I still think it would be useful to be able to know that the mixture map is being applied with the ST corr. and the LT corr. accounted for.  I'd happily just use the LTT map if there was a way to apply it's learned values directly to the ve table of my choice. Like a copy and paste special mulitply by percent as well as if it was possible to use one or two LTT tables to get the axis values to match the VE table in question directly.

To verify deadtime, you can set injection mode to multipoint group and switch the injection rate back and forth between 1 cycle and 1/2 cycle, while at constant fast idle.  Lambda should settle to about the same value on either rate setting.  If lambda changes when injection rate changes then adjust the deatime up or down until lambda is the same with either rate.  Give it a few seconds to stabilize each time you make a change.   

Can anyone confirm that mapper's method is still relevant? Nothing changed in subsequent versions that would disrupt?

Turn off overrun fuel cut.

You guys are pussies. Lol.  
Here's mine.

 
keep in mind the sensor location and exhaust volume will have a large impact on the amount of gain you can get away with and the update rate.  My sensor is right in the turbine exit so responds to changes in fueling quite quickly.
The current software may not allow numbers as big as mine, I am running a beta version which has some updates to CLL but it should be available soon.
 
I just have my trim limit table set to zero trim in the high-vacuum region.