KPro / KManager requests
KPro / KManager requests
Official thread for software requests. No responses are guaranteed, but we do read the forums at least once per day.
Hondata
Re: KPro / KManager requests
Generic feature request: Revision number inclusion in KAL filename with auto-increment so each consecutive 'save' of a modified calibration doesn't overwrite a file but creates a new one with a version bumped.
Could be useful for being able to 'roll-back' to a certain calibration after modifications or re-tunes didn't give the desired result.
K-manager PRA ECU specific feature request: proper support for PRA primary narrowband O2 sensor readout in datalog/sensor data. (only datalog/display issue, not an oprational/feedback issue in the ECU)
Current PRA primary narrowband voltage shown in datalogs seems to be about 1/4th to 1/5th of the actual narowband voltage (between 0 to 0.25V) while an OBD2 readout done at the same time does show the correct sensor voltage range (0 to 1V). Current work-around is to set the scaling or min-max in the sensor data to the smaller voltage range to get a decent graph.
Also O2 current/mA variable is probably meaningless on the narrowband PRA ECU so not sure it's useful to log it at all on a these ECU's?
Bye, Arno.
Could be useful for being able to 'roll-back' to a certain calibration after modifications or re-tunes didn't give the desired result.
K-manager PRA ECU specific feature request: proper support for PRA primary narrowband O2 sensor readout in datalog/sensor data. (only datalog/display issue, not an oprational/feedback issue in the ECU)
Current PRA primary narrowband voltage shown in datalogs seems to be about 1/4th to 1/5th of the actual narowband voltage (between 0 to 0.25V) while an OBD2 readout done at the same time does show the correct sensor voltage range (0 to 1V). Current work-around is to set the scaling or min-max in the sensor data to the smaller voltage range to get a decent graph.
Also O2 current/mA variable is probably meaningless on the narrowband PRA ECU so not sure it's useful to log it at all on a these ECU's?
Bye, Arno.
Re: KPro / KManager requests
Adding a revision number - done.
The P02 voltage for the PRA was divided by 4. I've fixed that and hidden the current sensor as you suggested for PRA datalogs.
The P02 voltage for the PRA was divided by 4. I've fixed that and hidden the current sensor as you suggested for PRA datalogs.
Hondata
Re: KPro / KManager requests
Thanks!
-
- Posts: 95
- Joined: Wed Jul 15, 2009 11:09 am
Re: KPro / KManager requests
- Add ability to use analog wideband input (ELD or aux analog) for closed loop and lean protection
- Add PID target boost controller option
- Add Boost control air temp compensation table
- Add boost controller frequency settings
- Add aftermarket IAT sensor support - provide similar options for popular IAT sensors, similar to the functionality offered for MAP sensors
- Provide option to use filtering/smoothing on analog inputs - gives more flexibility to tailor the input we log for better
- Suppress "ELD High Voltage" error code if using ELD input for wideband sensor
- Add option to use CEL as shift light (or any other pre-designated output)
- Add open loop vs closed loop water compensation tables
- Add rev limit by gear
- Add flex fuel sensor support
- Add test outputs function
- Provide peak values summary for datalogs - would make it easier for quick comparisons of different logs for specific values without having to manually scrub through
- Change datalog comments to small, numeric or colored placeholders and separate actual comments to a docked window. As currently configured, a long comment can block a lot of the data in the graph window. Labeling them with an arbitrary placeholder and placing the comments separately will clean up the graphing window and utilize space more efficiently
- When a datalog is loaded, make playback controls available on all windows - this would be especially useful when trying to monitor compensation settings through a log and reduce effort when needing to rewind/fast forward, etc
- Include min/max values for sensors window inside graph templates window - this would reduce jumping around from window to window when trying to get the sensor ranges setup correctly
Overall thoughts or odds of implementation would be greatly appreciated!
- Add PID target boost controller option
- Add Boost control air temp compensation table
- Add boost controller frequency settings
- Add aftermarket IAT sensor support - provide similar options for popular IAT sensors, similar to the functionality offered for MAP sensors
- Provide option to use filtering/smoothing on analog inputs - gives more flexibility to tailor the input we log for better
- Suppress "ELD High Voltage" error code if using ELD input for wideband sensor
- Add option to use CEL as shift light (or any other pre-designated output)
- Add open loop vs closed loop water compensation tables
- Add rev limit by gear
- Add flex fuel sensor support
- Add test outputs function
- Provide peak values summary for datalogs - would make it easier for quick comparisons of different logs for specific values without having to manually scrub through
- Change datalog comments to small, numeric or colored placeholders and separate actual comments to a docked window. As currently configured, a long comment can block a lot of the data in the graph window. Labeling them with an arbitrary placeholder and placing the comments separately will clean up the graphing window and utilize space more efficiently
- When a datalog is loaded, make playback controls available on all windows - this would be especially useful when trying to monitor compensation settings through a log and reduce effort when needing to rewind/fast forward, etc
- Include min/max values for sensors window inside graph templates window - this would reduce jumping around from window to window when trying to get the sensor ranges setup correctly
Overall thoughts or odds of implementation would be greatly appreciated!
Re: KPro / KManager requests
That's a lot at once. Can you order them in order of important to you? Some will need a little more information too.
Many of the requests require a hardware change (ie new design of KPro). eg analog smoothing, flex fuel.
Many of the requests require a hardware change (ie new design of KPro). eg analog smoothing, flex fuel.
Hondata
-
- Posts: 95
- Joined: Wed Jul 15, 2009 11:09 am
Re: KPro / KManager requests
That's kinda rough because I want it all lol. The analog input wideband support would be my #1 request right now. All the boost control related requests would be #2, and any KManager related revisions would be #3. All the other additional requests would fall in line after that. How specific would you like me to get?
I would be more than happy to go into detail about any of my requests.
I would be more than happy to go into detail about any of my requests.
Re: KPro / KManager requests
External wideband input we can split into closed loop operation and lean protection activation. Both would require an ECU input, as the KPro analog input goes to the KPro not the ECU. Also you may wish to know that I've recently added a fail safe input which covers some of the lean protection behavior (if you have an AEM fail safe that is). Be aware this would require a KPro hardware change, and this take some time to implement.
Boost control frequency - can be done, but not particularly easy.
Boost control PID control is more difficult. I have done this in testing and it is very hard to get the parameters correct. The thing that will get most people is that you need a well functioning existing setup with duty values which are close in order for PID control to work. The current open loop system really is the P part of the control loop, so needs to be accurate to begin with. If people expect the system to self tune without any setup they might be disappointed.
Boost control air temp compensation should not be a problem, subject to the PRA limits.
You can remove the ELD voltage error by unchecking 'ELD enabled' in Misc.
Rev limit by gear is planned (again, were waiting for more feedback from the s300 first).
Flex fuel support is planned, but some time off because we wish to revise how we do the flex fuel support in the s300 first & re-test. We also planned to implement the s300 soft rev limits once we are happy how they work in the s300. Be aware this would require a hardware change, and this take some time to implement.
CEL shift light - is easy as long as I can find a way to keep the knock flash logic too.
Test outputs - need to check on the complexity of this first.
Open loop vs closed loop water compensation tables - I don't understand the request.
The KManager stuff I'll leave for the moment.
Boost control frequency - can be done, but not particularly easy.
Boost control PID control is more difficult. I have done this in testing and it is very hard to get the parameters correct. The thing that will get most people is that you need a well functioning existing setup with duty values which are close in order for PID control to work. The current open loop system really is the P part of the control loop, so needs to be accurate to begin with. If people expect the system to self tune without any setup they might be disappointed.
Boost control air temp compensation should not be a problem, subject to the PRA limits.
You can remove the ELD voltage error by unchecking 'ELD enabled' in Misc.
Rev limit by gear is planned (again, were waiting for more feedback from the s300 first).
Flex fuel support is planned, but some time off because we wish to revise how we do the flex fuel support in the s300 first & re-test. We also planned to implement the s300 soft rev limits once we are happy how they work in the s300. Be aware this would require a hardware change, and this take some time to implement.
CEL shift light - is easy as long as I can find a way to keep the knock flash logic too.
Test outputs - need to check on the complexity of this first.
Open loop vs closed loop water compensation tables - I don't understand the request.
The KManager stuff I'll leave for the moment.
Hondata
-
- Posts: 95
- Joined: Wed Jul 15, 2009 11:09 am
Re: KPro / KManager requests
My requests are indeed for the PRA calibration (specifically, the S2000 application). The overwhelming majority of my requests are already present in the S300. I guess I could have wrapped up most of my requests by asking for better parity between the S300 and the KPro. I've seen you state before that the PRA codebase is limited, although I don't really know what that means compared to the PRB. Can you shed some light on this?
For the water temp comp tables, the S300 has this:
While the KPro currently has this:
Understand that the closed loop boost control is more difficult in implementation, but when dialed in correctly it is a superior solution to what we have now. As long as you put the explicit warning in that the duty lookup tables need to be dialed in first, I don't think you'll have too much of a support problem (hopefully).
I would love to give more detailed feedback on my requests in KManager. It's good software that could just use some slight tweaking here and there to improve.
Really appreciate you looking into this and giving feedback. Means a lot.
For the water temp comp tables, the S300 has this:
While the KPro currently has this:
Understand that the closed loop boost control is more difficult in implementation, but when dialed in correctly it is a superior solution to what we have now. As long as you put the explicit warning in that the duty lookup tables need to be dialed in first, I don't think you'll have too much of a support problem (hopefully).
I would love to give more detailed feedback on my requests in KManager. It's good software that could just use some slight tweaking here and there to improve.
Really appreciate you looking into this and giving feedback. Means a lot.
Re: KPro / KManager requests
I would be careful assuming that anything available in the s300 can be implemented in the KPro (and vice versa).
The PRA ECU has very little code space left in it from the factory, whereas the the PRB has much more. We're ultimately limited as to what we can fit in the processor flash memory.I've seen you state before that the PRA codebase is limited, although I don't really know what that means compared to the PRB. Can you shed some light on this?
Hondata
-
- Posts: 95
- Joined: Wed Jul 15, 2009 11:09 am
Re: KPro / KManager requests
Acknowledged on the S300 vs KPro feature parity.
Perhaps things would be clearer if I understood this - Why does the S2000 KPro use the PRA calibration when the ECU is PRB? I assume its because of the narrowband o2 sensor (amongst other things)? Can the S2000 use a PRB calibration, thereby removing the codebase limitation?
Perhaps things would be clearer if I understood this - Why does the S2000 KPro use the PRA calibration when the ECU is PRB? I assume its because of the narrowband o2 sensor (amongst other things)? Can the S2000 use a PRB calibration, thereby removing the codebase limitation?
Last edited by The Spectacle on Fri Dec 06, 2013 12:19 pm, edited 1 time in total.
Re: KPro / KManager requests
Because of the narrowband o2 sensor. It would only be able to use a PRB calibration with a wideband or in open loop.
Hondata
Re: KPro / KManager requests
Spectacle's list is great. For me I'd bump flex fuel support up to second place after analog wideband (I already have a zeitronix installed for monitoring. Simplifying changing fuels or blending fuels would be amazing)
Are ignition tables for flex fuel possible/beneficial?
Are ignition tables for flex fuel possible/beneficial?
Re: KPro / KManager requests
I agree with the point listed from The Spectacle.
For PRA ECU
-is interesting use a analog wideband input for closed loop operation with a target vs load table..
A simple table with 3-4 load collumns ( 10 to 70 kpa, 70 to 110 kpa, 110 to 250 + kpa).
- boost control target PID , all the competitors ECU have the boost controller PID target. This is a request for expert tuner that normally spend a lot of time on the actual boost table Open loop. For the advancer tuner is a normal work Made the boost vs % duty valve very clean and precise.
A lot of time the iat , load and weather change can modify the boost..with a PID target you can have the same boost in all condition for better reliability on daily drive or race drive.
And if on PRA ecu don't have Space for this New features can you do this for PRB ECU ;)
For PRA ECU
-is interesting use a analog wideband input for closed loop operation with a target vs load table..
A simple table with 3-4 load collumns ( 10 to 70 kpa, 70 to 110 kpa, 110 to 250 + kpa).
- boost control target PID , all the competitors ECU have the boost controller PID target. This is a request for expert tuner that normally spend a lot of time on the actual boost table Open loop. For the advancer tuner is a normal work Made the boost vs % duty valve very clean and precise.
A lot of time the iat , load and weather change can modify the boost..with a PID target you can have the same boost in all condition for better reliability on daily drive or race drive.
And if on PRA ecu don't have Space for this New features can you do this for PRB ECU ;)
Honda Ep3 stock k20a2 jrsc
Re: KPro / KManager requests
I would like to see a detailed history log, so I can see what I did previously.