Speeduino

VVT is indeed being used because of timer. Fan output was selected for testing because of transistor presents on board, but I will remove it today and user will be free to use any pin, same thing for tank empty sensor and indicator light.

I can use 1ms timer instead of VVT timer for PWM but that will limit frequency to maximum of 10hz, code could possibly be hacked to support higher rates but I don't feel like I can do it without high possibility of breaking rest of speeduino code.

Yesterday I was testing wmi code on bench and simple, proportional and openloop(or whatever you like to call them) works just fine

EDIT:
I almost forgot to mention that i reused VVT map as alternative boost map when there is not water in tank for protection. Is it enough? or would you like some kind of 2d ignition correction as well?

Thanks or the update Timus

Timus wrote: ↑Tue Jun 30, 2020 2:05 pm VVT is indeed being used because of timer. Fan output was selected for testing because of transistor presents on board, but I will remove it today and user will be free to use any pin, same thing for tank empty sensor and indicator light.

Thanks Timus. I think that this is better.

Timus wrote: ↑Tue Jun 30, 2020 2:05 pm I can use 1ms timer instead of VVT timer for PWM but that will limit frequency to maximum of 10hz, code could possibly be hacked to support higher rates but I don't feel like I can do it without high possibility of breaking rest of speeduino code.

I think that without specific testing it would be more prudent to use the VVT for the present. Then perhaps down the track once some baseline testing has been undertaken the change could be made to use a dedicated timer. I currently have no data from which I could make a decision on whether 10khz is a suitable upper limit, so I think it is better to play it safe.

Timus wrote: ↑Tue Jun 30, 2020 2:05 pm Yesterday I was testing wmi code on bench and simple, proportional and openloop(or whatever you like to call them) works just fine

Timus wrote: ↑Tue Jun 30, 2020 2:05 pmEDIT:
I almost forgot to mention that i reused VVT map as alternative boost map when there is not water in tank for protection. Is it enough? or would you like some kind of 2d ignition correction as well?

The Ignition correction would be nice to have. I use blown setups and so the boost control is not utilised in my specific application. In blown applications the ignition control would be more appropriate.

/DM

Timus wrote: ↑Tue Jun 30, 2020 2:05 pm I almost forgot to mention that i reused VVT map as alternative boost map when there is not water in tank for protection. Is it enough? or would you like some kind of 2d ignition correction as well?

IMO, default should be primary tables for basic engine operation, e.g., boost without WI. Altered fuel and ignition timing would be enabled only if WI was operational. In this way, WI and WI corrections work together, also allowing other or future schemes to be used as a 'package', e.g., WI and corrections enabled if IAT limit setting is exceeded. My opinion follows both typical tuning protocol and the reasoning behind my comment of using Flex input (or similar) for fuel and timing changes or offsets from primary tables. Hope that helps.

DeeEmm wrote: ↑Tue Jun 30, 2020 3:35 pm The Ignition correction would be nice to have. I use blown setups and so the boost control is not utilised in my specific application. In blown applications the ignition control would be more appropriate.

Work in progess

PSIG wrote: ↑Tue Jun 30, 2020 6:09 pmIMO, default should be primary tables for basic engine operation, e.g., boost without WI. Altered fuel and ignition timing would be enabled only if WI was operational. In this way, WI and WI corrections work together, also allowing other or future schemes to be used as a 'package', e.g., WI and corrections enabled if IAT limit setting is exceeded. My opinion follows both typical tuning protocol and the reasoning behind my comment of using Flex input (or similar) for fuel and timing changes or offsets from primary tables. Hope that helps.

Make sense. I will change logic to achieve this.

We can start alpha testing

I test it today on bench and its seems like everything is working. Sadly I cannot test it on car because I don't have both speeduino pcb and water-methanol injection kit
For futher improvemnts and bug fixes testers are needed.

Code is on my fork: https://github.com/Timu5/speeduino
You can as well check what I changed in comparsion to orginal source code: https://github.com/noisymime/speeduino/ ... mu5:master

I attached screenshot with basic example configuration, new gauge and tank empty indicator.

Thanks Timus.

Will take a look tonight

I have a firmware mismatch...

Just taking a quick test drive of the TS interface, it looks like the Alt boost map on/off control is greying out the wrong item in the Accessories menu...
/DM

Should be fine now

I'm waiting for more feedback.

Thanks Timus, yes the mismatch seems to be fixed. On to the next hurdle...

I've got something weird going on with TS. Initially I thought that there was an issue with the databins / ini setup with your code, as I was getting values of '510' for all vertical axis KPA bins, but then I noticed it is the same for the AFR table. So I installed vanilla 202005 firmware using speedyloader and also downloaded the vanilla baseline tune via speedyloader and I get the same issue, see attached image.

Any ideas?

I'm not exactly sure the issue is within your code, however it is preventing me from being able to install a valid tune as I am unable to convert my existing tune to use the new code without introducing these errors. I'm apprehensive to test further until I understand what's going on as it looks very much like some kind of data corruption.

I'll dig out another Arduino over the weekend and try again with different hardware, just in case it's some kind of memory issue but if anyone has an idea of what's causing this it'd be helpful.

Timus, assuming that your TS does not have these issues, are you able to upload your MSQ?

Cheers.

/DM