Any general discussion around the firmware, what is does, how it does it etc.
By Timus
#43992
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?
User avatar
By DeeEmm
#43995
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 pm
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?
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
User avatar
By PSIG
#44000
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.
By Timus
#44002
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 pm
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.
Make sense. I will change logic to achieve this.
By Timus
#44008
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.
Attachments
WaterMethanolExampleConfig.png
WaterMethanolExampleConfig.png (329.69 KiB) Viewed 183 times
User avatar
By DeeEmm
#44023
I have a firmware mismatch...
Code: Select all
    
Project Serial signature: 'speeduino 202306-dev-wmi'     
Speeduino Serial signature: 'speeduino 202006-dev'
User avatar
By DeeEmm
#44024
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...
Screen Shot 2020-07-02 at 9.33.09 pm.png
Screen Shot 2020-07-02 at 9.33.09 pm.png (5.49 MiB) Viewed 154 times
/DM
User avatar
By DeeEmm
#44049
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
Attachments
Screen Shot 2020-07-03 at 5.55.43 pm.png
Screen Shot 2020-07-03 at 5.55.43 pm.png (278.78 KiB) Viewed 112 times

The IRLB3034 may work better? https://www.infine[…]

MX5/Miata PNP on 1.8 issues

@D0nny94 As for the tachometer. If you do ne[…]

Thanks Eric for pointing me to that one, basical[…]

... Thanks for picking this up - some good wo[…]

Still can't find what you're looking for?