rusefi.com

Sorry it took me so long to respond - not ignoring you, just both yet another car today and now I need to part out most of it. Long story

Dude! This is amazing! Not only you've discovered an issue, but you've also fixed it as well! This is really GOOD stuff

Code committed. Technically you kind of probably need to fork on github and do all the fancy stuff so that I can take your changes automatically. As an option SVN patches are also an option so that I do not need to re-edit the sources you've adjusted already.

Once again, thank you _a lot_!

No worriez, you can't be in front of the computer screen all the time

I was meaning to ask you about code commiting, i'll link Eclipse tommorow and fork the project for the major/crazy changes and look into svn patches [I never used that before ] for the bug squashing.

Here the first patch, it contains the launch control code.

unfgr wrote:Here the first patch, it contains the launch control code.

Good stuff!

I some spare 'unused' fields in the config so that adding a new field does not change the total size of the flash image - this case at least some minor code changes are compatible with older custom configurations. Can you please take my version of step1RpmWindow placement and re-generate your patch? It should get much smaller since no offsets would shift.

Sorry, i've been away for the last 3 days.
I'll get right in to it asap

well, it looks like you've already done the job....

Anyway now that we have a launch control it's time to increase accuracy at high revs(>16K)
FYI right now it's doing fine up to 20K but there's an issue where "randomly" (if there's such a thing!) every other ignition falling edge event (=even or odd index of ignition event) the timing shifts by as much as 8 Degrees (@16K RPM). the shift maximum point [= worst case measured] is constant in time duration so at 8K RPM it is shifting by 4 Degrees.

I will open a new thread as soon as is have more info on this, right now i think it only affects Channel#1.

unfgr wrote:well, it looks like you've already done the job....

Nope, I have not! I've manually merged a little bit, but not the main logic and maybe smth else. Still need the patch

Here's the new patch. Minimal changes as you have predicted

unfgr wrote:Here's the new patch. Minimal changes as you have predicted

LaunchControlPatch_V0.1.patch

What is step1rpm and what is step1RpmWindow? I know but can you please elaborate a bit? I want to put the documentation into

Launch RPM Window:
RPM range (window) prior to RPM Step1 Limit point (Launch RPM) that retards ignition to Step1 Ignition Value [usefull for turbo spool-up. a Later ignition point will produce more heat and exhaust gas pressure to exhaust manifold (=more energy for the turbocharger) helping it to spool-up while vehicle is stationary]

step1rpm:
A (usualy lower) RPM limiter that is engaged by the driver, to help keep the engine reving at a preset point that is advantageous for the tires traction during the transition from stationary state to moving state

Short Version:
Launch RPM Window: RPMs prior to step1rpm point where ignition advance is retarded
step1rpm: A secondary Rev limit engaged by the driver to help launch the vehicle faster

git updated, new patch created(also includes previous changes).

Merging is often not a piece of cake, these comments with the timestamp of when the tool has generated a file are not helping. Anyway, some progress, please take my latest versions.

1) engine_configuration_generates_structures.h rusefi_config.txt rusefi.ini should be in sync with your field comments, can you please take my version with my dates to unify?
2) adc_inputs.cpp & allsensors.cpp looks like the difference is just a new line somewhere, do we really need this?
3) engine_configuration.cpp should be in sync, I believe is not needed since same stuff is already set by prepareVoidConfiguration() method, but I could be wrong
4) main_trigger_callback.cpp something is weird around assigning true and false to boardConfiguration->enabledStep1Limiter. These are supposed to be persistent configuration settings, we should not be changing these dynamically. For dynamic stuff, the best way is probably a new field on EngineState?

1 - Since engine_configuration_generates_structures.h and rusefi.ini are generated by rusefi_config.txt they should be in sync allready, one problem tho is that i don't know how to add the new submenu to rusefi.ini though rusefi_config.txt. so, I manualy edited rusefi.ini to add "Racing Features".

2 - adc_inputs.cpp & allsensors.cpp have no changes other than a few blank lines since i've used them for debugging [leftovers from deleted debug lines]

3 - yep they are in sync [you also corrected an error I 've made]. As for the extra initialization yes you are right, debuggin leftovers again from when i wasn't able to initiate cluchPin correctly [long story short it was in fact conflicting with the default configuration, don't know how, but it was!]

4 - yes again, it was "the easy way" to gain access to ignition retard since there was no functions available to manipulate ignition (and fuel). it's a bit awkward but will have to suffice for now, at least until we have implemented something that will give as direct access to ignition and fuel [we going to need two functions for each one, one additive and one multiplicative].

unfgr wrote:4 - yes again, it was "the easy way" to gain access to ignition retard since there was no functions available to manipulate ignition (and fuel). it's a bit awkward but will have to suffice for now, at least until we have implemented something that will give as direct access to ignition and fuel [we going to need two functions for each one, one additive and one multiplicative].

I believe that this should be improved, the way it is right now is too hacky... Not sure if we need to move the flag into dynamic EngineState or just add another flag into the logic, but we should not adjust persistent configuration dynamically.

True, we'll have to add a new variable to dynamic Engine State in order to be within your design constrains, but, in order to have non-static ignition retard and some kind of fuel enrichment not just for launch control but for other functions aswell like knock retard & enrich, traction control retard, engine protection enrich etc, we also have to add some more variables [in fact 4 will be enough for now].

What i was thinking is to linearly manipulate final injection and ignition values before they enter the queue, eg for fuel, if x is the calculated injection open time we can have 2 variables (a,b) and manipulate x as: x = ax+b. This way we can have both multiplicative (eg %100 increase or decrease) and additive (+/- b ms of duration) changes for the calculated values.

For now tho, i have to look into the infinitly more pressing matter of the ignition timing innacuracy, this is a big issue when you pushing engines to the limit (and some times even on lightly modified engines).

Maybe somebody with a logic analyzer can more accurately scope the trigger wheel signal vs the ignition timing signal and verify this problem. Our target should be accuracy within +/- 10us , which we already have [most of the time] but the ignition signal randomly offsets by 80us.

OK new launch retard is using: No more "L33t H4X0r" board configuration manipulation
changes available @ git

Disregard the other float variables i've added, they are for future racing function and launch control enrichment in the future.

Now about the timing offset bug, it looks like without a logic analyzer (or a better oscilloscope with greater timing resolution/stability), i can't clearly verify it's existance.

There are many low cost china logic analyzers. Could one of those be obtained for the capture you are looking for? Could a discovery be made into a logic analyzer you are looking for? I seem to recall crank decoder is basically a logic analyzer. Perhaps the firmware could be modified / stripped down such that one board could be a logic analyzer.

I wonder if they fixed the capture buffer issue with this guy http://www.seeedstudio.com/depot/open-workbench-logic-sniffer-p-612.html?cPath=174 I got a V1.04 some years ago, but it had an issue in that it couldn't capture direct to the USB attached PC's HDD. So it's capture abilities were kind of limited. At the time I was trying to decode SPI packets which were spaced some mS apart. I could only capture one or two packets with that LA, then I got a china Logic 16, which worked better.

Seems these china LA's can be obtained as well http://www.ebay.com/itm/New-USB-Logic-100MHz-16Ch-Logic-Analyzer-for-ARM-FPGA-/381278899456?hash=item58c5fe4d00 for about $50, there are some lower cost ones but I'm not sure what they use for PC software.

I was thinking (for a long time now but always postponed it) to buy one of these

http://www.hantek.com/en/ProductDetail_16_14.html

Anyway, the console, is it a true logic analyzer or it's just pulling the data from the firmware/RAM and display them graphicaly?


**update
I had an Arduino mega lying around so i went ahead and used it as a logic analyzer, I'm starting to get a clear image now, the problem is verified... going to add it to this thread.
http://rusefi.com/forum/viewtopic.php?f=5&t=929

It appears that the Hantek4032L has a programmable threshold. Is it safe to assume that below level A is a 0, and above threshold B is a 1, and anything in between these voltages is undefined? If so that's great, but I wonder if that can be confirmed some how. Other than that I see it has a 2 gig RAM buffer which is also helpful, but in reality most signals are reasonably slow packets spit out over the course of fairly long periods of time. So capture to a USB HDD and only capturing changing data is beneficial. At it's 2nS capture rate, 2 gig ram gets gobbled up quickly. In the manuals block diagram I don't see any blocks for trimming out redundant data. If it has USB HDD capture abilities I suspect it's a low MSa/s. I'd like to find a better review.

there is a discussion at http://www.eevblog.com/forum/testgear/hantek-ht4032l-logic-analyser/15/ about this but it's almost 3 years old
It looks like they moded the crap out of it

i have a DSO-2150 oscilloscope from Hantek for i dont really remember how many years , for the money back then, it was a bargain plus it turned out to have very good support over the years, i'm running it on Win7 64Bit now. When i bought it, i think it was running on a system with WinXP pre-SP1

kb1gtt wrote:There are many low cost china logic analyzers.

that's off-topic in the "launch control" thread. Sounds like you guys want me to figure out how to split messages which are half on-topic and half off-topic, and extract off-topic halves into separate threads nicely? Unfortunately I do not know how to do so in phpbb, and unless people would self-moderate, there will be well, a mess.

I agree, I started going OT, Lets migrate the LA stuff to here http://rusefi.com/forum/viewtopic.php?f=13&t=938 No need to copy the above, we'll just continue over there if we need to talk more about LA's.

unfgr wrote:changes available @ git

I am failing to figure out how to take these from git - there are too many unrelated changes (like hardware changed or project files changes). A patch would be easier for a limited me.

I use default K&N code formatted in Eclipse, the only change I have is line width of 120 characters instead of the default 80:

I have tried to set up lunch control on my mx5, but is doesn't seem to do anything. I use an external SPDT switch for clutchUp/clutchDown inputs just for testing. Do I need to wire the brake input switch as well?

Is this launch control feature usable yet?

RadMx5 wrote: ↑

Sun Mar 04, 2018 9:57 pm

Is this launch control feature usable yet?

Not working yet and development abandoned. Just updated the project to reduce confusion - https://github.com/rusefi/rusefi/commit/980925747d3714c3131de72639c8bd5c67fde118

So, russian do you know what needs finishing on this? Maybe there is someone who can make it work?

I remember nothing about that. There is some code attached to the https://github.com/rusefi/rusefi/issues/203 ticket

Someone would have to understand the whole thing, implement and test

I implemented some of this back in December. Let me see what I can do.

mck1117 wrote: ↑

Tue Mar 06, 2018 9:06 pm

I implemented some of this back in December. Let me see what I can do.

Did you get a chance to see anything about it?

Did anybody had a chance to take a look at this feature?

I would really need it, i will tray to make some time to take a look in the code but i do not have enough free time (

TURBO spool for launch.... I saw the thread and thought is was launch control as in controlled wheel spin during launch maybe using the new ETC whicuh is something I have roughed into my setup but completely untested and probably not yet functional hoped to find some clever thoughts