10463 Add AFR to lambda based on 14.7 translation to wideband panel
10464 Fix zeitronix output for RPM, boost, TPS, User.
10466 Update wideband directories in install package and documentation
0.91124 is the GUN, works a treat, logged 40 mins of data on way to work this morning and didnt miss a beat. Should be even better when i get the better serial adapter.
Will be giving it a dyno run this arvo to do some ramp logs. Last time i dynoed( 2 weeks ago) i hit 204 rwkw with a rich tune (10.5:1) on an rb20.
What does that "First 3 address files and 5 IDs" means?
If I ever loaded 3 address files, it won't do real-time tuning for the 4th I load?
And what is ECU ID?
That is correct. So for an indiividual users license, the first three address files opened will let you do realtime tuning. Any others opened afterwards will still let you modify/save etc but no realtime tuning would be available
Each time you connect to an ECU, NIStune will display the ECU ID (Nissan part number 23710-xxxxx) on the screen. Upto the first five ECU IDs can be used for realtime tuning, anything afterwards you can view, display, look at consult/log etc but no realtime tuning
Normally only workshops would connect to more than this many different vehicle/ECU types and require realtime tuning also, which is where the other license is required.
Just a quick question Matt, say i connect to 3 different ECU's for the sake of just downloading bin files or data logging, without realtime boards, will they count towards the 5 or is it only if the five have tunable boards?
Matt wrote:That is correct. So for an indiividual users license, the first three address files opened will let you do realtime tuning. Any others opened afterwards will still let you modify/save etc but no realtime tuning would be available
Wow, I'm pretty sure I've opened more than 5 address files while first playing with Nistune
This change has only been introduced in the latest version. Since you only have the one Type 1 realtime board, this wont be a problem if it was one of the first five address files opened. Otherwise just do a reinstall and it will reset it
kenbam wrote:Very inaccurate. didnt really move off 20:1, i had just started car so it was running about 13:1 cold. If i gave engine a rev they went to about 17:1, still way out.
I've been having this problem too with 91122. I've updated to 91124 and will test it tomorrow. I've confirmed my afr with tewblog several times.
BTW, I'm using a Celeron 600 with a native serial port and have been getting the "Techedge not connected to com1" problem. Hopefully I will have a more current machine this week to try out for that issue.
NIStune supports a number of wideband units, and given this there is increased potential for people to use the lookup tables for the wrong unit
The main thing with the AFR is to ensure that you are using the correct wideband lookup tables.
When you select your wideband unit from the dropdown list, you will now be prompted in the latest version to ensure that the correct lookup table is selected for your wideband unit
For example for TechEdge it would be
C:\Program Files\NIStune\Wideband\TechEdge2.0
I've also updated the Software Users manual to make this explicit. If in doubt have a look at the updated manual
The latest version has specific wideband files in folders. Browse to your wideband unit and select that
If any of the tables need adjusting, do it for your wideband unit within that subfolder (eg adding boost sensor to Aux input)
Ken has got this working now for TechEdge, and I have it working here also. Please let me know if you have any more issues however, but should all be good now ...
91124 fixed my incorrect AFR problems. I'm still seeing some disconnects from the techedge. But I'm pretty sure it is related to the laptop, not any of the cars hardware/software.
If you can post/send a debug log with just the TechEdge running I can tell you what is going on.
File-Configuration-Debug Logging
Fiels put in C:\Program Files\NIStune\logs\*.log
In the case of Kens USB-Serial converter we could see that it sent the data in 0.5 second bursts which caused problems with the 'timeout' period which is checked for when no data is received
