launch control

It's all about the code!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

launch control

Post by AndreyB »

What is it? What is the logic and what are the parameters?

https://sourceforge.net/p/rusefi/tickets/196/
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: launch control

Post by kb1gtt »

Launch control varies. Often it's a power limiting, other times it's a rev limiting. The goal is to not burn off the tires when jumping off the line. In the end, we probably want a mechanism that allow for multiple algorithms. AKA drag strip vs Rally have different desires for launch control.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

kb1gtt wrote:Launch control varies.
Well, we need to begin with one :) I guess whoever describes whichever in some detail that would be the one I would begin with.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: launch control

Post by kb1gtt »

Looks like these two pages explain it reasonably well.

http://www.enginebasics.com/EFI%20Tuning/2step%20rev%20limiter.html
http://tunertools.com/articles/Launch-Control-101.asp

I say lets start with that. General procedure would be, you press clutch, then you enable launch control via a switch, then you floor it, and it revs to some limited rev. Lets call it 3kRPM. Then you pop the clutch, which triggers a switch. This switch starts a timer, which will keep the rev's limited to 3kRPM for perhaps 1 second, then after one second it allow say 5kRPM for say another 1 second. Then after this 2 seconds, you have launched and your engine is at full RPM and full power. AKA it prevents you from spinning the wheels to much on the line.

Switches can be pressure switches in the hydraulic lines that go to the clutch cyl, or pressure sensors attached to the shifter. For now lets just call it a dry contact from a mechanical switch mounted near the clutch.

As for RPM limiter, I think that's a first baby step development. The issue is how do we create this RPM limiter. I'm tempted to think it needs to be a PID loop, that controls spark advance and eventually fuel. But I also feel it can probably be tuned with a table instead of complicated math loop. How should we soft and hard limit this thing?
Welcome to the friendlier side of internet crazy :)
Number-One
contributor
contributor
Posts: 101
Joined: Sun Jan 05, 2014 2:59 pm

Re: launch control

Post by Number-One »

Don't forget bikes. Launch on cars 3k, on bikes 6k .
User avatar
rus084
contributor
contributor
Posts: 678
Joined: Sun Dec 01, 2013 1:40 pm
Location: Russia , Stavropol

Re: launch control

Post by rus084 »

it works when brake/coupling is pressed?
i need it at 5000rpm
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: launch control

Post by puff »

doesn't this need readings from abs sensors?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: launch control

Post by kb1gtt »

What do you mean abs? Do you mean wheel speed sensor?
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: launch control

Post by puff »

yep.
Number-One
contributor
contributor
Posts: 101
Joined: Sun Jan 05, 2014 2:59 pm

Re: launch control

Post by Number-One »

Launch need speed wheel sensor and clutch switch. (launch start with speed =0 and clutch pressed at same time)
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

OK launch Control 101 - Initial [For both turbo and N/A vehicles]

The main target of launch control function is to limit the initial wheel slip when the cluch is released [eg. launch in a drag race] AND build boost on Turbo vehicles (in Older ECUs this was a diferent function called "standstill boost generator") today tho, the two functions have been merged into one, in virtualy all StandAlone ECUs.

launch control offers the function of keeping a lower rev limit while cluch is depressed OR VSS(wheel speed) is below a preset limit(LaunchDisableSpeed) AND the option to decrease ignition advance and enrich the fuel mixture in order to spool-up the turbocharger.
This is usualy achived by setting a secondary revLimit parameter in the firmware that overides the normal hardLimiter while CluchSignal is enabled or VSS <= LaunchDisableSpeed
you can also set an rpm window where the fuel is enriched by a preset amount and the ignition advance is reduced again by a preset amount (can be a single variable or a couple of 1D tables load->degIgnRetard , load->%enrich).

since this is an old thread and it's my first post to forum (hopefully i didn't bring a dead thread back :) ) i'll wait to see if there is any interest in this matter before describing it fully. However, as soon as i get my bearing around the source code (it's been a while since i last wrote any c code) and get an STM board i'll get around to implement the function anyway [gonna take some time....].
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

Good info! Next step would be somebody actually implementing a first version :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

i already have the simulator working and the eclipse IDE with the latest code loaded, so i'm gonna give it a try, it's just going to take some time to go through the source code.
I've seen that you use the variable "hardLimit" for the rev limiter, would you mind pointing me/explaining where in the source code the normal limit is implemented? I'll try to take it from there.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

It would be tough without a car, at least you would need a discovery board with a couple of potentiometers to simulate sensors, or, probably a better option, you would need to add 'mock' clutch up/clutch down/VSS speed into the simulator the way there is mock voltage for analog sensors in simulator.

you would need some logic to set/reset a 'needStep1LogicNow' flag maybe in engine_controller.cpp and then apply step1 limit same way hard limit is applied?

See also https://sourceforge.net/p/rusefi/tickets/196/#f777
See also http://rusefi.com/forum/viewtopic.php?f=5&t=10
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: launch control

Post by kb1gtt »

Sounds like some good news. Just in case you didn't find this already, there is doxygen documentation found here http://rusefi.com/docs/html/

I'm more of a hardware guy, less of a software guy. I can generally follow software, but have trouble creating it. If you have any questions on how to get something physically connected, feel free to inquire. I'll offer what support I can.
Welcome to the friendlier side of internet crazy :)
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

kb1gtt wrote: I'm more of a hardware guy, less of a software guy. I can generally follow software, but have trouble creating it. If you have any questions on how to get something physically connected, feel free to inquire. I'll offer what support I can.
Thanks kb. My knowledge of electronics stops at "analog" stuff, my worst nightmare is op-amps. On the other hand i known my way around FPGAs and digital Systems Design (nothing fancy tho). Anyway, back to tortur.... err coding

Most of the code is already there.
Assuming that in:

Code: Select all

engine_configuration.cpp
[209]   boardConfiguration->clutchUpPin = GPIO_UNASSIGNED;
[210]   boardConfiguration->clutchUpPinMode = PI_PULLUP;
and the call

Code: Select all

engine->clutchUpState
are working correctly then we can enable a very simple Launch Control by adding a few lines to main_trigger_callback.cpp after line 400

Code: Select all

	if ((engine->clutchUpState != true) && (rpm > engineConfiguration->step1rpm)) {
                warning(OBD_PCM_Processor_Fault, "skipping stroke due to Launch Limit, Current RPM=%d", rpm);
                return;
  	}
I'm gessing that step1rpm is there for standStill rpm limiter [it is the same as launch control at least for N/A engines]

I also noticed that the code for ignition retard on launch control is already there, in advance_map.cpp

Code: Select all

[55]  bool_t isStep1Condition(int rpm DECLARE_ENGINE_PARAMETER_S) { 
        return  boardConfiguration->enabledStep1Limiter && rpm >= engineConfiguration->step1rpm;
        }

[73]  if (isStep1Condition(rpm PASS_ENGINE_PARAMETER)) {
        return engineConfiguration->step1timing;
	}        
Maybe isStep1Condition definition has to move to somewhere else, scheduled to run every 40-50ms autoupdating the Condition with some extra logic (tps check, vss check etc)

this is just a start-point, as soon as i get my F4 board i'll try to implement a state-of-the-art launch control, for the time beeing i'm going to get in to "round 2 fight" with the source code, it's the first time i see so high abstraction level in an otherwise non OO Language. I like it :D
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: launch control

Post by kb1gtt »

I know launch control has been discussed before, so It doesn't surprise me that russian has been leaving bits and pieces around that are friendly to implementing the feature. Good to see you jumping in. Has russian noted the build server? He has a server he uses for building, which includes a validation process. The validation process will upload the firmware to a F4 board, put it in simulate mode which generates cam and crank signals, ect. Then it logs the outputs and validates they are some form of sane setup. This process helps prevent bugs from getting out accidentally.

I'll refrain myself from talking FPGA stuff. I tend to think that long term we want an option that includes an FPGA fabric. The HAL abstraction makes it much easier to port to other newer platforms as time progresses. AKA easier to port to a FGPA or what ever new ARM processor shows up in the future. For now I agree that it needs to function well, before it can get the additional complexities and costs of more advanced hardware. I can think of many other features that should be implemented like accelerometer feedback, transmission control, SD logging, ect. I just added launch control to the wish list found here http://rusefi.com/wiki/index.php?title=Development:TODO
Welcome to the friendlier side of internet crazy :)
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

I received my discovery board yesterday and went ahead to implement the launch control

I had to hardcode the Launch Control pin state read since for some mysterius reason defining the pin at engine_configuration.cpp Completely ignored me

Code: Select all

:
[code]boardConfiguration->clutchUpPin = GPIOE_13;
boardConfiguration->clutchUpPinMode = PI_PULLUP;
Debugging it revealed that the value passes correctly (77) but somewhere in the way it is changing to 80 which is the defaul value for GPIO_unussigned [Some help here..... ???]
Anyway, other than this "minor" problem i got successful, at least at this simple function form.

The code is keeping either fuel or spark events (in main_trigger_callback.cpp) from beeing implemented according to 2 variables (step1SparkCutEnable or step1fuelCutEnable) by checking the [hardcoded] pin E13 and the rpm value.
if the user has issued a low level signal to GPIO_E13 and the "rpm" is greater than "step1rpm" the code sets the flag "enabledStep1Limiter" so the ignition advance can take the value indicated by "engineConfiguration->step1timing" and it skips handleSpark() or handleFuel() (or both if needed).
When rpm drops bellow "step1rpm" the "enabledStep1Limiter" is maintained until the user releases the low level signal to pin E13

Code: Select all

	if (rpm > engineConfiguration->step1rpm && !(bool_t)palReadPad(GPIOE,13) && (step1fuelCutEnable || step1SparkCutEnable)) {
		boardConfiguration->enabledStep1Limiter = true;
		if(!step1SparkCutEnable){
			handleSpark(eventIndex, rpm, &engine->engineConfiguration2->ignitionEvents[revolutionIndex] PASS_ENGINE_PARAMETER);
			warning(OBD_PCM_Processor_Fault, "Launch Fuel Cut, rpm=%d", rpm);
			}
		if(!step1fuelCutEnable){
			handleFuel(eventIndex, rpm PASS_ENGINE_PARAMETER);
			warning(OBD_PCM_Processor_Fault, "Launch Spark Cut, rpm=%d", rpm);
			}
		}
	else
		{
		if((bool_t)palReadPad(GPIOE,13))
		boardConfiguration->enabledStep1Limiter = false;
		handleSpark(eventIndex, rpm, &engine->engineConfiguration2->ignitionEvents[revolutionIndex] PASS_ENGINE_PARAMETER);
		handleFuel(eventIndex, rpm PASS_ENGINE_PARAMETER);
		}

this is an experimental version of this function, next step is to figure out the clutchUpPin problem and pass the 2 extra variables to TS UI.
At the end i'm going to move the whole function to a new class, implement an "rpm window" a fuel enrichment function and use the MCU's random number generator with a PID controlled event cut function [more on this later...]
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

integration completed.... up to the point where i screwed up the struct offsets (bound to be happen at 4:30 in the morning!!!). Now i'm getting a nice console error message
"EngineState: FATAL error: Unknown hw channel 1073741824" :D
oh well, at least i got the code ready plus the .ini for TS, for now... /sleep

p.s.
new TS tab -> "Racing Features"
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

rebuild flash struct with extra variables -> done
TS .ini -> done

we now have exposed cluchUp and CluchDown channel selection, Launch RPM and Launch Ignition advance setting, use of fuel cut/spark cut/both exposed to TS
the code works good on a basic level, however, a bug appeared on the rpm transition from normal operation to launch control operation that manifests as 100ms dwell charge [ouch.... coils on fire], going to squash it by changing the logic of the code, as it looks like skipping handleSpark() is the reason for the bug.

The strange thing with this is that skipping handleFuel() works perfectly!!!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

unfgr wrote:as it looks like skipping handleSpark() is the reason for the bug.

The strange thing with this is that skipping handleFuel() works perfectly!!!
100ms is probably the watchdog - see engine->watchdog()

Just added some comments:

Code: Select all

	/**
	 * For fuel we schedule start of injection based on trigger angle, and then inject for
	 * specified duration of time
	 */
	handleFuel(eventIndex, rpm PASS_ENGINE_PARAMETER);
	/**
	 * For spark we schedule both start of coil charge and actual spark based on trigger angle
	 */
	handleSpark(eventIndex, rpm, &engine->engineConfiguration2->ignitionEvents[revolutionIndex] PASS_ENGINE_PARAMETER);
So it seems like firing the spark after coil charging was started is handled by the same handleSpark method which you disable, thus coils on fire.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

unfgr wrote:ad to hardcode the Launch Control pin state read since for some mysterius reason defining the pin at engine_configuration.cpp Completely ignored me
New code comment:

Code: Select all

/**
 * @brief	Global default engine configuration
 * This method sets the global engine configuration defaults. These default values are then
 * overridden by engine-specific defaults and the settings are saved in flash memory.
 *
 * This method is invoked only when new configuration is needed:
 *  * recently re-flashed chip
 *  * flash version of configuration failed CRC check or appears to be older then FLASH_DATA_VERSION
 *  * 'rewriteconfig' command
 *  * 'set_engine_type X' command
 */
void setDefaultConfiguration(DECLARE_ENGINE_PARAMETER_F) {
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

It's not always 100ms this is just the higher number i have seen [worst case :)]
This looks like a bug in the scheduling,it manifests only on COIL#1 and it also affects rpm Hard Limit
try to set rpm limit at 7000 and set console RPM at 7001 , there's a chance each time the rpm signal goes from 7000->7001 the ignition coil dwell will go insane
What i noticed is that ignition start (rising edge) is OK but falling edge is delayed by a multiple of exactly 720 degrees. eg it happens at the correct angle but a few crank rotations later.

What i believe it happens is that the coil#1 is going high prior to rpmHardLimit enable [which is correct to do so] and then, before the coil#1 set-Low-event is programmed the rpm becomes greater than rpmHardLimit, consequently the coil#1 signal does not go LOW until rpm<=rpmHardLimit (so a new event can be programmed to scheduler). However this assumption doesn't fit with the fact that this problem only occurs on coil#1

see bellow for screeshot, rpm:4000, trigger:12-1
Coil#1 RPM Hard Limit Problem
Coil#1 RPM Hard Limit Problem
rpmLimitBug.jpg (377.19 KiB) Viewed 29727 times
Last edited by unfgr on Sat Sep 26, 2015 4:24 pm, edited 1 time in total.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

It fits perfectly: coil #1 charge start is on one engine cycle and spark is on the next cycle. Next engine cycle has different schedule and nobody is there to fire the spark.

Can u please create a ticket in issue tracker on SF or i will do once get home. Thank you for a great bug report!
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

Excellent... i will create the ticket.
btw, if you fix this we get a working launch control aswell.... :D
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: launch control

Post by puff »

is it the same issue I mentioned some time ago (the duration of ignition pulse on coil#1 was slightly bigger than for other coils)? nice to see it's nailed down!
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

yep hopefully it is the same bug, however the time on coil 1 is varying by at least 720 degrees on this one
then we still have the bug of timing variation every other pulse of coil 1 http://rusefi.com/forum/viewtopic.php?f=5&t=929
i'm going after it as soon as i finish with launch control


*edit, about Launch Control
This is the initial settings. For now launch rpm window only sets the ingition advance to indicated value. I need an implementation of a random number generator so i can map spark/inject possibility to:
Rpm Step1 Limit-window lower Limit = 100% possibility to inject/spark
Step1 RPM limit= 0% possibility to inject/spark
In later Launch control Versions, the spark possibility will be controlled by a PID controller
Launch Control Settings
Launch Control Settings
launchV1.JPG (290.26 KiB) Viewed 29710 times
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: launch control

Post by AndreyB »

Nest step is getting this on a real vehicle, would you be interested to test it in real life? But first I need to fix https://sourceforge.net/p/rusefi/tickets/225/ - that's unless you can suggest a fix.

I myself is now focused at https://sourceforge.net/p/rusefi/tickets/226/

Any chance you would be interested to write some JAVA code like https://sourceforge.net/p/rusefi/tickets/213/?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

Nest step is getting this on a real vehicle, would you be interested to test it in real life? But first I need to fix https://sourceforge.net/p/rusefi/tickets/225/ - that's unless you can suggest a fix.

I myself is now focused at https://sourceforge.net/p/rusefi/tickets/226/
I'm onto 225 myself, just trying to get a full grasp of the whole code logic right now since i don't have any hands-on experience with RTOSs. So, focus on 226, i'll do 225 unless you beat me to it :D

btw, one question(purely theoretical), why didn't you use OPM (One pulse Mode) so you don't have to schedule double events(goHi,GoLow)? there are more than enough timers available and at least for injection is accurate enough.

Now about testing on a vehicle, i got the vehicle(s) but i dont yet have the hardware, soon enough tho, i'll be able to test RL.
I currently have 3 vehicles i can use with custom setups (stand-alone ECUs). All hondas,
a civic 1.6Vti(B16A) heavily modified (235bhp N/A, 400bhp on nitrous)
a CRXII 1.6 Single Vtec(D16Z6), this one is turbocharged & spraying methanol/water, made 556bhp on dyno and i estimate it currently somewhere near 600-650bhp (upgrading never ends)
a CBR400RR modified for fuel injection (current project). This is the perfect candidate for testing since it's bone stock engine, revs @ 16K RPM and has easier connectivity (PSU 24P Connector)than the 2 cars mentioned above (AEM Infinity-MOLEX MX123). it's gonna be hard on the ECU but if it can run this type of engine then it can literaly manage every other engine out there :)
plus one in the near future which is a 250cc 2-stroke V-90 [thinking about fuel-injecting it].

So yes,when i got the rest of the hardware in my hands,i'll test it... in fact i'll torture the ECU till it cryes out for mercy.... :mrgreen:

Any chance you would be interested to write some JAVA code like https://sourceforge.net/p/rusefi/tickets/213/
Java i can do, a lot...lot better than C, however tcp/ip conectivity is not available in TS Lite anymore so there is no way i can debug it :(
After i'm done with Launch control, Traction Control and some other features i have in mind for the firmware i'll try to write our own tuning app, after all, the dev console protocol you have designed is far superior to the TS/MS communication protocol
unfgr
Posts: 33
Joined: Wed Sep 09, 2015 10:26 pm

Re: launch control

Post by unfgr »

Bug squashed :)
The problem was that during hard limit we where returning from the triggercallback without doing anything. That had the effect that if the signal was up in the previous ignition event it never came down (return) and while rpm was greater than rpmHardLimit it kept beeing high since we were again returning without doing something about it.
I added 2 boolean variables to main_trigget__callback
(bool limitedSpark=false; bool limitedFuel=false;)
these variables control the scheduling registration like this:

Fuel:

Code: Select all

..........
if(!limitedFuel){
		scheduleTask("out up", sUp, (int) injectionStartDelayUs, (schfunc_t) &startSimultaniousInjection, engine);
		scheduleTask("out down", sDown, (int) injectionStartDelayUs + MS2US(injectionDuration), (schfunc_t) &endSimultaniousInjection, engine);
						}
	} else {
		if(!limitedFuel)
		scheduleOutput(&event->actuator, getTimeNowUs(), injectionStartDelayUs, MS2US(injectionDuration));
	}
Ignition:

Code: Select all

if(!limitedSpark){
	scheduleTask("spark up", sUp, chargeDelayUs, (schfunc_t) &turnPinHigh, iEvent->output);
	 }
Now if you take a closer look to the full code you'll see that only ignition signalUp is affected.there is no reason to process the Signal Down unless we need in the future to support signal inversion or make the method less MCU intensive while on Limiter.... from my point of view it doesn't worth making the code longer and thus more difficult to read

here a screenshot of the limiter working correctly
bugSquashed.jpg
bugSquashed.jpg (399.51 KiB) Viewed 29674 times
As a bonus we get, a 100% (theoreticaly)functional Launch Control and if i observe it correctly less variation to coil#1 falling edge http://rusefi.com/forum/viewtopic.php?f=5&t=929 [i don't know how this affected the other bug but i'm measuring 0.1ms variation now]

As an extra not-so-good thing: some other bugs that are purely performance related came into light, take a look at this.... we broke through the 720 degrees cycle :shock:
720degrees + VAT
720degrees + VAT
wtf.jpg (456.9 KiB) Viewed 29674 times
Post Reply