[DeeEmm]

No. no take up. The bounty is still open but is about to be closed and retained by bountysource.

There's $200 available to anyone who wants to take this up.

[DeeEmm]

Deadline is 11 August

[PSIG]

Yes, I see there are still several bounties on GitHub. I think one of mine has already been lost, and they kept the money. I think that's one reason BountySource never really took-off. Then again, bounties were encouraged here but I don't think I've seen a bounty claimed for Speeduino, so maybe the concept is failed.

David

[ric355]

Yes, I see there are still several bounties on GitHub. I think one of mine has already been lost, and they kept the money. I think that's one reason BountySource never really took-off. Then again, bounties were encouraged here but I don't think I've seen a bounty claimed for Speeduino, so maybe the concept is failed.

David

To my mind, the principle problem is lack of a specification or at least something that resembles one. A discussion thread is not enough. I come from a pretty formal commercial software development background and I would gladly do work on a bounty driven requirement provided;

- It was already agreed it would be accepted into the master codebase
- There was a well defined specification of the minimum viable product required to collect the bounty (also applies for stuff where no bounty is present; I will gladly develop against anything really the bounty is not a key requirement for me)

If either or both of these is not known then I put it in the bracket of 'probably wasting my time'. I realise that could sound a bit harsh but that's the way it is.

I suspect few people want to have to do the work to establish all the ins and outs of a particular function / new requirement unless it is for their own benefit where they just have to. Writing the code is often the easy bit really.

[PSIG]

Rather than hijack this thread with the Bounty topic, I have moved my reply and questions to a new thread located here:
viewtopic.php?f=12&t=4049
Replies there are certainly welcome!

[DeeEmm]

ric355, The basic outline is relatively simple but looking back at this thread, unless you read through the original conversation it's not 100% clear. I had envisaged that the actual specs would be something derived from community discussion but that does not seem to have happened.

Also, I've never really pushed this as it's just a nice-to-have and I know that the main devs are tied up with core development. It seemed to get traction a couple of times but I guess has just not taken focus over other development.

I can summarise for you if you are interested. This is how I see it.

Inputs:
- Water Low (high value indicates water OK)
- System Enable (high value indicates WMI function is enabled)
- Safety Chain (high value indicates other safety requirements are okay)

Essentially all inputs are boolean and comprise of simple failsafe signals. These could all be condensed into a single safety chain input and the necessary devices wired in series, but giving the user the option to map these signals to seperate inputs would provide a more granular view of the system, which is good for those using remote dashboard applications where these inputs can then be mapped to mimics on the display.

Outputs:
- Water pump [PWM] - (Direct drive for DC pump / injector / solenoid control for basic on/off)
- Water level low indicator(to control warning lamp - option to flash the light?)
- Analog out (Typical 0-5v for driving external pump controller / WMI system)
- Pump enabled (for operating solenoid)

Functionality

Limits
- TPS - System is only active above this TPS value
- RPM - System is only active above this RPM
- MAP - System is only active above this MAP
- IAT - System is only active above this IAT

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)

'Mapped open loop' - a basic RPM vs MAP table of PWM values. This is also how Megasquirt do it. Essentially you are just mapping arbitrary values based on RPM and MAP. It's not really integrated with the ECU control and has no direct relation to what the engine is doing, its just operating as an independent function. It's basically the equivalent to a Snow systems stage 3 control.

'Mapped closed loop' takes into account any real-time engine corrections that are currently in play by following what the the injectors are doing. There is also a 2D correction table to fine tune this value. For this to work an additional 'offset' value is be required to dial in the system such that PWM Out = injector duty cycle + offset + table correction. This is basically the equivalent to a Snow systems stage 4 control.

There's some further considerations relating to PWM operation such as operating modes / frequencies but that's pretty standard stuff and used elsewhere.

Integrations

- Boost control (ability to limit boost control based on system availability)
- Ignition control (ability advance / retard ignition)

Essentially that's it.

/DM

[EdMcGuirk]

In my opinion, moving water injection control inside the ECU also requires integration with boost control. I would not want to allow full boost if I was not allowing water injection or if water injection is in an error/failed state.

Would I want some reduced boost allowed or just no boost? RPM related boost allowances? (I am not familiar with current speeduino boost control abilities)

Otherwise the 'Pump Enabled' output could be used for wastegate or other boost limiter. (I assume that would be the main online/offline water injection output signal)

[DeeEmm]

In my opinion, moving water injection control inside the ECU also requires integration with boost control. I would not want to allow full boost if I was not allowing water injection or if water injection is in an error/failed state.

Would I want some reduced boost allowed or just no boost? RPM related boost allowances? (I am not familiar with current speeduino boost control abilities)

Otherwise the 'Pump Enabled' output could be used for wastegate or other boost limiter. (I assume that would be the main online/offline water injection output signal)

Totally agree. All of the stuff I deal with is blown so not something I considered. I'll update the description (in case someone is actually interested enough to code this)

[Timus]

I have started wmi coding yesterday, should be operational by the end of the month.

[PSIG]

…
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