Any general discussion around the firmware, what is does, how it does it etc.
User avatar
By EdMcGuirk
#43910
Sorry to bring up another issue but the original NACA tests during WW2 concluded that WMI did not increase HP unless the ignition was advanced to compensate for the reduced flame speed due to inert steam in the combustion chamber. (If WMI boost = dry boost, HP is the same. More boost would get more HP) In that case it would require some kind of ignition advance table to be used during water injection.

I guess what a lot of people are doing is to use a window of high boost with water injection and advanced ignition and the rest of the ignition map is for low boost without water injection and standard ignition advance. The safety system prevents ever going into the high boost window unless water injection is working. Water injection in the low boost area of the ignition map would be suboptimal.

It's probably not important in racing where low boost is rarely active. On the street water injection can be more of a safety protocol instead of a means for maximum HP, so optimization might not be critical.
User avatar
By PSIG
#43912
Just to inform; ignition alteration was originally conceived through internal command or external GPIO input to the Flex Fuel input, altering timing and even fuel if desired within its tuning tables, on-demand. This avoids yet more tables, using existing assets already available for additional uses. Limited I/O and feature capacity are always concerns to address, and at the front of this concept and others.

David
User avatar
By DeeEmm
#43967
Timus wrote:
Tue Jun 23, 2020 3:43 pm
I have started wmi coding yesterday, should be operational by the end of the month. :)
That's awesome news Timus. Thanks for taking up the challenge. I've followed your github fork. Please feel free to tag me in any communications if you need any input. My github tag is the same as my username.

Sorry that my reply here is somewhat delayed, I'm super busy at work and have not had much chance to get online

You can also reach out to me at deeemm[at]deeemm.com
PSIG wrote:
Tue Jun 23, 2020 10:49 pm
DeeEmm wrote:
Sat Jun 20, 2020 11:39 am

Operating modes [Simple / Proportional / Mapped open loop / Mapped closed loop]
-- Simple mode - Output is turned on when preset boost level is reached
-- Proportional Mode - Output PWM is proportionally controlled between two MAP values - MAP Value 1 = PWM:0% / MAP Value 2 = PWM:100%
-- Mapped open loop - Output PWM follows 2D map value (RPM vs MAP) Cell value contains desired PWM% [range 0-100%]
-- Mapped closed loop - Output PWM follows injector duty cycle with 2D correction map applied (RPM vs MAP). Cell value contains correction value% [nom 100%] (additional offset value is also required - see below) …
If I misunderstand, please correct me, and it's your bounty. However, the terms are either unclear or missing association. For example, Proportional is generally defined against fuel quantity as a percent, e.g., 30% water against 100% fuel quantity on that cycle. This is partly why WI was considered for Speeduino (rather than GPIO or standalone), as it directly correlates the fuel quantity to the water quantity, under various other conditions known to the ECM, while allowing other functions (boost, spark, etc) to be directly altered if desired.

This also requires the control system to know what the water quantity is, or could be, so another param to accommodate. Often this is extrapolated from the injector time, but there are other ways to accomplish it such as the flow meter previously mentioned, which can also act as a safety. To be fair, all of this might also be GPIO territory, with all the info available there as-well, and may possibly help to ensure dev and maintenance would be unhindered while reducing potential conflicts within Speeduino. <shrug> Looking to clarify or define terms and intentions when possible, as there are 101 ways to come at it.

David
With regards to terminology, yes I agree, my chosen mode descriptions may not be the best, they were written rather hastily trying to get something down as a basic description so that others may take up the bounty. Very open to suggestions.

Perhaps...

- Basic
- Scaled
- Mapped
- Proportional?

With regards to methodology on how to obtain the current engine loading, it does not have to be injector time. If there are other better methods available within the code, or if this method does not fit with current best practice, then those other methods should be used. The same applies to other interactions.

Consider my descriptions those of a layman and exercise your best judgement in how this is achieved.

David, you have also reminded me that early on there were indeed discussions relating to altering timing, which I did not include on the description on the previous page. I will add it in, but as Timus has already started the code, it would only be fair that this now does not form part of the bounty as it was not part of the description that he is working to. (unless of course he wants to add it, in which case I would be super grateful :D )

/DM
User avatar
By DeeEmm
#43984
Timus,

Just looking through your latest commit and noticed the following:
Code: Select all
  // wmi can only work when vvt and fan are disabled 
  if(configPage6.vvtEnabled == 0 && configPage6.fanEnable == 0)	  if(configPage6.vvtEnabled == 0 && configPage6.fanEnable == 0)
  {	  {
Not sure how it is dealt with elsewhere in the Speeduino code, but is this the best method to deal with shared / recycled I/O?

I would have thought that I/O are able to be assigned freely and that any sanity checking is done by the board creator when the INI file is created. If the end user wants to reassign I/O then they can do so, without there being checks like this in the code that exclude them from using certain I/O combinations. I believe that this is how it is normally, as this has been my experience when swapping between different ECUs where I/O has been reused but not specifically redeclared in the INI file (i.e. no sanity checking performed on the INI I/O declarations)

There are four PWM / High current outputs on the board - VVT, Idle, Idle 2 and Boost (If my memory serves me correctly). Your code means that anyone running VVT will not be able to run WMI, even thought they may have both Idle and Idle 2 outputs unused as they are running a stepper based idle control.

Same applies to the Fan output. I use this on my car, so I will need to be able to use both Fan and WMI by reassigning some other output to use with WMI.

Hard coding the specific combinations such as you have excludes the use of WMI for many users. There is a definite requirement for both WMI and VVT as stated earlier in the thread and a definite use by me to be able to use both the fan and WMI functions together. In fact I would have thought that excluding the use of the fan function whilst using WMI will exclude 99% of users.

Thoughts ?
By pazi88
#43985
DeeEmm wrote:
Tue Jun 30, 2020 2:38 am
Timus,

Just looking through your latest commit and noticed the following:
Code: Select all
  // wmi can only work when vvt and fan are disabled 
  if(configPage6.vvtEnabled == 0 && configPage6.fanEnable == 0)	  if(configPage6.vvtEnabled == 0 && configPage6.fanEnable == 0)
  {	  {
Not sure how it is dealt with elsewhere in the Speeduino code, but is this the best method to deal with shared / recycled I/O?

I would have thought that I/O are able to be assigned freely and that any sanity checking is done by the board creator when the INI file is created. If the end user wants to reassign I/O then they can do so, without there being checks like this in the code that exclude them from using certain I/O combinations. I believe that this is how it is normally, as this has been my experience when swapping between different ECUs where I/O has been reused but not specifically redeclared in the INI file (i.e. no sanity checking performed on the INI I/O declarations)

There are four PWM / High current outputs on the board - VVT, Idle, Idle 2 and Boost (If my memory serves me correctly). Your code means that anyone running VVT will not be able to run WMI, even thought they may have both Idle and Idle 2 outputs unused as they are running a stepper based idle control.

Same applies to the Fan output. I use this on my car, so I will need to be able to use both Fan and WMI by reassigning some other output to use with WMI.

Hard coding the specific combinations such as you have excludes the use of WMI for many users. There is a definite requirement for both WMI and VVT as stated earlier in the thread and a definite use by me to be able to use both the fan and WMI functions together. In fact I would have thought that excluding the use of the fan function whilst using WMI will exclude 99% of users.

Thoughts ?
Didn't find the actual code, but I would guess that's not about I/O. You can freely select what I/O what you want. It's about timers that are needed to get PWM outputs. All the timers in Arduino Mega are in use in Speeduino, so you will need to give up something if you want to have different PWM outputs. For example the VVT PWM timer can be used for WMI, but then of course VVT can't be used anymore. Future the stm32 and Teensy will allow lot more PWM outputs, because of increased timers.
User avatar
By DeeEmm
#43987
pazi88 wrote:
Tue Jun 30, 2020 5:38 am
Didn't find the actual code, but I would guess that's not about I/O. You can freely select what I/O what you want. It's about timers that are needed to get PWM outputs. All the timers in Arduino Mega are in use in Speeduino, so you will need to give up something if you want to have different PWM outputs. For example the VVT PWM timer can be used for WMI, but then of course VVT can't be used anymore. Future the stm32 and Teensy will allow lot more PWM outputs, because of increased timers.
Ahh okay. That makes sense, however the mega has 6 timers. I assume that two are used on ignition and fuel respectively, what are the other four used on? If those four are the four standard PWM outputs then what I have stated above still holds true. We should be able to use WMI + VVT whilst forfeiting idle (1+2) PWM control.
By pazi88
#43988
13 timers

-1ms counter
-idle
-boost control
-vvt
-ign1
-ign2
-ign3
-ign4
-ign5
-inj1
-inj2
-inj3
-inj4

Changes to these need to be done in code before compiling. So if you want to use timer from another function, you can't do it from TS.
By dazq
#43989
No that's not true about the pwm!
A new pwm can be created for the wmi.
The pwm use a free running timer by creating a software pwm output, thus you don't have to lose the other features.
Although it does slow things down somewhat I have had up to 8 pwm channels running on a mega2560 within the speeduino firmware itself ( it was during testing way back when I was working on stm32 pwm out for the idle and vvt)
By pazi88
#43990
Well yeah with proper coding, a lot can be done. But if the PWM output is done like the current implementation is done, the the timer amounts are problem.

But as I said, I didn't find the WMI code so I'm just guessing what is the cause of limitation in that.
User avatar
By DeeEmm
#43991
dazq wrote:
Tue Jun 30, 2020 11:18 am
A new pwm can be created for the wmi.
The pwm use a free running timer by creating a software pwm output, thus you don't have to lose the other features.
Thanks. That makes more sense.
pazi88 wrote:Well yeah with proper coding, a lot can be done. .
That's the reason for the bounty. If I wanted a half rate job I'd do it myself :lol: :lol: :lol:

Also q1 gets very hot when the ecu is plugged in t[…]

Connecting Cam Sensor

I found detailed informations. It is a hall sensor[…]

Tuner Studio installation

I got it, the driver was already installed, the ar[…]

@plazomat Not sure if there is still interest in t[…]

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