Ok, understood, smart. So values from V2 won’t work in V3 unless we set MIN as 0 and MAX as 100.
Yes.
Or you can recalculate them in excel
Is the “end of injection” injection angle option rewritten and working? I remember it wasn’t available initially
1 Like
It works, but it is planned to rewrite it in the future.
1 Like
Would it be possible to have separate RPM axes for fuel and ignition tables 1 & 2?
It would be beneficial to have a higher RPM-resolution in the tables for VTEC engines for VTEC on and off.
RPM Axis 1 (VTEC off) for:
- Fuel tables - VE table 1
- Fuel tables - Lambda trgt. 1
- Ign. tables - Ign. table 1
RPM Axis 2 (VTEC on) for:
- Fuel tables - VE table 2
- Fuel tables - Lambda trgt. 2
- Ign. tables - Ign. table 2
I am asking for this, for the past 8 years 
The results from my testing so far for idle quality and tip in response are dissapointing. The idle ign. pid can’t even catch the coolant fan load, huge dip when the fan turns on. If pid set more agressive, even a little bit, it winds negative during engine decel and again dips down low. Even when the ign. pid is set as soft as possible, it still dips when it returns to idle. I did set the active air flow table with all pids off, as close to target as possible. I have now played 3-4 hours just with idle and tip in without a cure. Tip in is also bad. In comparison, idle with V2 is perfection, and tip in is good. I can’t upload the V2 log i took right after experimenting with the V3.
V3idletest.emublog3 (2.6 MB)
Ur ignition PID seems to be strange tuned and ur air PID seems to be off. Can u share ur settings? I think there is something very strange. For me it seems ur idle control is more or less off.
My idle is running perfect with those settings:
I turned off I term for Ignition. That helped a lot.
1 Like
I don’t know what you consider perfect, so can’t say anything.
I always keep the iacv pid off, with V2 as well. When everything is well setup, it’s not needed and idle is equivalent to oem. I immediately went back to V2 when i finished experimenting with V3, and saved a log for comparison, but i can’t attach it here as the file format isn’t supported.
To catch up ur dips u need P and D Portion of ignition control. And to bring ignition back to target u need some air PID (independed if ur base DC is set up perfectly).
The reason u have a dip is u are just useing I portion. Ur settings are actually a garanteed dip.
Try something similar to mine and i bet u will see hudge differences.
The dips shouldn’t be there in the first place, no matter the airflow pid off. It is because the ramp down, combined with the ign. corr. pid, don’t work well. No matter how you set the pid, it will always wind up all the way negative when you release the throttle as it stands at the moment. I don’t mind if the ignition is a few degrees off target when the rpm target is met or nearly met. Stability is what matters. When target is 860, i dont care if it sits at 880 or 840. The pid based idle ignition correction will give issues, especially with sloppy camshafts. (i would guess you never had a well setup idle with V2 to compare with)
Here is why it’s dipping with V3. The iacv dc% doesn’t drop linearly, even with the target settings all correct. With V2, it does.
So in other words you want to have an option to use error table instead of PID ?
As I have posted for the v2 software package, the client software runs on an ARM-based computer but will not connect with the EMU Black.
Depending on your software development environment it might be not that difficult to build for ARM computers. It could be your IDE supports ARM-targets out of the box.
Just a thought.
Christian
It is not such easy as we use 3rd party libraries.
I would never want to use a Dc error correction table for airflow dc %, it is very bad. I just pointed in the circles how smoothtly the airflow dc % tapers down to target in V2, giving a very smooth and linear return to idle, without dipping down, and without hanging up too high for too long. Whereas in the V3, it goes straight down to the idle target airflow dc%. What i get from the two screenshots i posted is that the virtual target in V2, works exactly as expected, per the offset and ramp down rate entered. It doesn’t seem to work as good in the V3. It did get much better today with your support, but still doesn’t match V2. I am not trying to be negative towards V3, just stating what i think/find.
Yes, then it will be difficult.
My hopes are still somewhat high since Parallels Desktop is officially supported by Microsoft and the FTDI ARM-driver has a Windows Certificate. Maybe they find a solution.
I am missing the option to open a XML file version of the project in the v3 client.
In the v2 version the .emub file was a XML file in disguise that I could open rather easily with other software (MATLAB) to open and manipulate the project and then open it in the client software programming the EMU.
The .emub3 file is now a binary format but I was delighted you built in a XML export option. Would it be able to import the XML version in the client as well? Otherwise it will be difficult to make bigger changes in the project.
I just discovered the tables can be manipulated by copy and paste even outside the client software, the format being text with columns separated by tabs and rows separated by newlines using commas for decimal points. Importing a XML file would be much easier though.
You can already load xml file without any issue using open project option ( I hope )
According ARM, if you press shift + f9 there is console in application. There are logs connected to communication.
If you send me those logs I can take a look, also i can add more debug if I find it usefull.
Maybe we will be able to find solution to allow the software works using parallels.
Yes, you can!
The tables for VVTI angle are smaller than before (10 x 10 compared to 12 x 12 before). As someone with a Honda K20A VTC engine I am not amused 
.
But I spotted two VVTI RPM axes in the XML project file (vvtiRpmBins10 and vvtiRpmBins10_2). Just the first is in use right now. Do you plan on having two separate RPM axes in the future (for VTEC on and off) 
?
Anyway, why would it be so difficult to have separate RPM axes (VTEC on and off) for VE, Ignition and VVTI 
?