Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Dragtools - development starting...


Guru

Status: Offline
Posts: 2338
Date:
Dragtools - development starting...


The develompent for drag tools is slowly starting, so lets document here the notes what is needed to implement these.

The idea of improving bike handling on a drag strip contains two functions (these both ideas have been discussed on this board earlier):
- antislip control using rpm/s limiter
- antirollover control using yaw rate sensor degrees/s

The basic concept is just to tamper with the ignition advance allowing user to retard the advance.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Antirollover control is planned to be implemented by replacing the TOS sensor in bike harness with a YAW rate sensor.

As the first step we need to disable the TOS sensor in programming code by giving it a constant value. This happens by replacing the reference to AD sensor #AD0DT5_TOS with fixed value in the rom space. Elsewhere in the firmware the TOS is checed agains certain trhesholds, so we know that e.g value 0x80 as a fixed value should work just nice.

ROM_:0000475C nop || nop
ROM_:00004760 ld24 R1, #AD0DT5_TOS
ROM_:00004764 lduh R1, @R1 || nop
ROM_:00004768 ld24 R0, #AN5_TOS
ROM_:0000476C sth R1, @R0 || nop
ROM_:00004770 ld24 R0, #AN5_TOS
ROM_:00004774 lduh R1, @R0 || nop
ROM_:00004778 ld24 R0, #AND_TOS
ROM_:0000477C sth R1, @R0 || nop

ROM_:00072536 TOS_threshold_unk_72536:.byte  0xA
ROM_:00072537 TOS_threshold_unk_72537:.byte 0xF6


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

The ingnition compensation is calculated adjusting the map values with some compensation values. As busa does not really use ambient pressure compensation we most likely can use that one without many problems.

IGN_calculate_various_compensations_together_sub_33C00:
addi sp, #-4
push R8
push R9
push lr
mv R9, R4 ; cylinder specific ignition compensation
mv R8, R5 ; ign for multiplication variable
ld24 R0, #unsure_baseline_pressure_unk_806396
ldub R4, @R0
mul R4, R9
srai R4, #7 || nop
ld24 R0, #SAP_ignition_compensation_unk_8063A4
ldub R0, @R0
add R4, R0
ld24 R0, #Ignition_retard_if_running_constantly_over_12500_rpm_unk_8063A2
ldub R0, @R0
sub R4, R0
ld24 R0, #ECT_ignition_compensation_unk_806380
ldub R0, @R0
add R4, R0
add R4, R8 || nop
ld24 R0, #SAP_IAT_ignition_compensation_unk_8063C7
ldub R0, @R0
sub R4, R0
addi R4, #-0x80
ldi8 R6, #0
ldi16 R5, #0xFF
bl.l minmax_r4r5r6_ret_r0_sub_2E54
stb R0, @(0xC, sp)


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

This algorithm should be hang into the ignition loop so that its run at least once on every engine revolution.

/*
Activation of both of these controls should be easy. The algorithm for activation I am planning to use is:
*/

if (gear not neutral) and (clutch is not depressed) and (rpm>user_adj_limit)
{
dragtools=ACTIVE;
}
else
{
dragtools=INACTIVE;
tickcounter=0;
}

/*
The dragtools module is active only for a certain amount of engine rounds. Each tick is propotional to an engine round.
*/
if (dragtools == ACTIVE)
{
tickcounter=tickcounter + 1;
if (tickcounter > user_adjustable_timelimit)
dragtools=INACTIVE;
}


/*
The YAW sensor should be easy to implement too by just letting the yaw sensor to adjust the
ignition retard.
*/
if (dragtools == ACTIVE)
{
if (YAW_SENSOR_VOLTS > yaw_user_adj_limit)
ign_retard = sap_sensor_adj + ((YAW_SENSOR_VOLTS * yaw_user_adj_factor) / 1000);
}

/*
The spin control based on time is a bit more trickier, need to think this part a bit more...
*/
if (dragtools == ACTIVE)
{

}


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1247
Date:

Great work PetriK Since the TOS logic has been identified, is it practical to include a radio button in EcuEditor to disable for those using the bikes in race only conditions which allow it rather than the current solution of installing a resistor?


Thinking ahead, if the ignition approach does not produce adequate results to reducing power, perhaps the STP could be used. This would only work for bikes with the STP intact of course.


__________________


Guru

Status: Offline
Posts: 953
Date:

John,

I have TOS sensor connectors here if you need one to wire into your harness for a yaw sensor, let me know if  you want one and can drop it in the mail.

Greg


__________________


Guru

Status: Offline
Posts: 1344
Date:

PETRIK, I HAVE BEEN HEAVILY INVOLVED WITH THE NEW 2011 MIROCK SERIES RULES, (NO MORE AMA), SO THIS IS THE ONLY SANCTIONED BODY THAT IS INVOLVED WITH DRAG RACING IN THE "US", I HAVE SPENT HOURS WITH PHIL DAVIS AND COUNTLESS OTHERS I GETTING ECU FLASHING DEEMED OK FOR MODIFICATIONS AND HAVE IT PUT IN THE RULE BOOK, SO FAR EVERYTHING IS LEGAL, EXCEPT FOR THE YAW SENSOR FOR LAUNCH CONTROL, ROA ( RATE OF ACELLERATION) RPM'S PER SECOND WOULD BE CONSIDERED LEGAL.....CAN YOU INCORPERATE RPM'S/PER SECOND BE PUT IN THE SOFTWARE SO THAT IT WILL BE DEEMED "LEGAL" PLEASE, I HAVE RR UP TO DATE ON ALL OF THIS ALSO, WE STILL TALK AND HOPEFULLY HIS SOFTWARE WILL BE LEGAL FOR THE 2011 SEASON....I HAVE WORKED HARD FOR THIS TO HAPPEN, AND EVERYONE THANKS YOU, GREG, AND EVERYONE INVOLVED TO MAKE THIS POSSIBLE FOR THE "AVERAGE" RACER....

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 2338
Date:

Sure - same rules in here so will make a race approved version of course.

Anyhow as some stock bikes have wheelie control as stock, that rule is most likely going to be changed in the future...

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1247
Date:

2011 rules allow any ecu flashing as well as aftermarket ECU's for realstreet / prostreet.

Marc / Stocker, PM me on one of the other boards, I am not sure that I read that a rate of rotation sensor would be illegal? Unless I guess they may be considering if a height or front suspension condition sensor? No need to discuss rules on this board though.

John

__________________


Guru

Status: Offline
Posts: 1344
Date:

I have been super quiet, but very busy in getting ecu flashing legal to do here in the usa...in which, i have been very sucessfull...in getting everything in the software legal.....trust me....it was a challenge, and has changed the game forever for the "premier" dragracing classes here for 2011, big oppertunities here.....and "NO" external sensors for a roa, software only...john, i will contact you.....marc...

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

in order for "flashing " to be legal, phil davis had to let stand alones to be legal to even out the playing field, especially since the kawi's do not have anything yet......till rr gets his stuff finished......politics.......geez...i have worked hard, many of phone calls, explanations...ect.., plus lots of talks with rr to get his stuff done 30 days before the first race of the season.....playing both teams, hopeing everyone wins....both sides.....plus knowing enough of the "rule book" to see whats up.....???? the m-84 is baddddd.......and some of the algrothims in ee2 and rr's stuff needs to be stepped up......it can be done.......smile

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

petrik, i see that dragtools.vb is written, is there anything else that needs to be reasearched or written...?

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 2338
Date:

Hi, thanks, not really - at this stage the most difficult thing is to find proper time to get the ideas into a simple implementable format.

The prevailing idea starts to look like something below to the end users... there is no logig or anything yet, this is just a mockup what the end result could look like to give the forum members to give feedback about the thinking.

This is the simpliest form I can get the idea working at least when sketching.


slewrate.jpg



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:

Hi, thanks, not really - at this stage the most difficult thing is to find proper time to get the ideas into a simple implementable format.

The prevailing idea starts to look like something below to the end users... there is no logig or anything yet, this is just a mockup what the end result could look like to give the forum members to give feedback about the thinking.

This is the simpliest form I can get the idea working at least when sketching.


slewrate.jpg



There should be the possibility to input the final transmission ratio, for example speed at 1000 rpm in a specified gear. Knowing this there is a 1:1 relation
between rotational acceleration (RPM/sec) and linear acceleration (meter/sec2).
I think m/sec2 target is more meaninful, for example 400m in 9.5 seconds corresponds to an average acceleration of 8.8 m/sec2. Knowing the target final speed the average acceleration can be estimaded easily:
(254 Km/h / 3.6) / 9.7 = 7.42 m/sec2.
Since people use different gearing, it makes more sense to discuss and compare linear acceleration values, which are more closely correlated to traction results rather than rotational acceleration.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks for an idea. The way to implement this could be an additional raport on the screen for the full ride and use the rpm/sec information as input together with final drive ratio.

Anyhow if we use a data logger as basis for the adjustment then the meter/sec2 is not really available without very fast gps or non slipping wheen information (neither avail for and not allowed by the rolebook). Based on datalogging we can easiest see the RPM ramp up times and adjust settings accordingly.

Comments ?



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

I think there needs to be an activation RPM threshold also. This is propably just above the launch rpm ? This is now added to the mockup user interface.

Initially I was thinking to use clutch as activation parameter - but thats not as accurate as a certain rpm - particularly with 2 step limiter.

Comments ?

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:

Thanks for an idea. The way to implement this could be an additional raport on the screen for the full ride and use the rpm/sec information as input together with final drive ratio.

Anyhow if we use a data logger as basis for the adjustment then the meter/sec2 is not really available without very fast gps or non slipping wheen information (neither avail for and not allowed by the rolebook). Based on datalogging we can easiest see the RPM ramp up times and adjust settings accordingly.

Comments ?



I meant to allow m/sec2 as  input (and display rpm/sec) or display m/sec2 if input is rpm/sec.  Once the speed at 1000 rpm is know, theere is a 1:1 mapping. The speed at 1000 rpm table could have a default (stock values, see http://www.gearingcommander.com/ ). The default could be replaced (in a similar way of the target afr table) by a csv input file with the needed values.
The benefit of m/sec2 it that is an absolute value to discuss and optimize, independent of the tyre size, gearing etc. As a matter of fact knowing optimal m/sec2 values, gearing and tyre could be choosen to reach that value before spinning.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

OK, that could be done so that both are on the screen - that does not change the logic at all.

Now the problem rather is how to get the rpm/sec information out of the ecu. There is not a kind of real time clock inside - rather timers. And at this stage I dont really want to program new timers as those are fairly critical for the normal operattions of the ecu.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1247
Date:

Launch conditions may need to be somehow filtered. With a modern engine driven clutch, the engine rpm may spike to some point as soon as "lunch" is initiated. This spike is very rapid and we wouldn't want it to trigger the roa.

Example, launch rpm = 7500
Engine spikes to 10,000 as soon as clutch is released, slipping the clutch until the input shaft "catches up".
Then the engine accelerates above the 10,000 to the shiftpoint of 12,500- 13,000 or so.

__________________


Guru

Status: Offline
Posts: 1247
Date:

I have not sorted through this, but here is the site for the most popular external ROA controller. Many other ecu's have it built into their software. Very popular with the high power import racers.

http://www.moretraction.com/


Patent for Davis:
http://www.google.com/patents?id=YxIPAAAAEBAJ&zoom=4&pg=PA1#v=onepage&q&f=false

Edit: Added link, not sure what happened to the post as I tried to post it previously.
-- Edited by sportbikeryder on Saturday 1st of January 2011 03:47:55 PM

-- Edited by sportbikeryder on Saturday 1st of January 2011 03:48:34 PM

-- Edited by sportbikeryder on Saturday 1st of January 2011 03:50:13 PM

__________________


Senior Member

Status: Offline
Posts: 186
Date:

PetriK wrote:

OK, that could be done so that both are on the screen - that does not change the logic at all.

Now the problem rather is how to get the rpm/sec information out of the ecu. There is not a kind of real time clock inside - rather timers. And at this stage I dont really want to program new timers as those are fairly critical for the normal operattions of the ecu.



BTW logged data has the pc timer as first column and rpm as second, it would be usedful to add display of instant RPM/sec and maybe m/sec2 (positive or negative). The autotuning module could also select to use only values with acceleration over a specific threshold to focus on the acceleration phases (this can be done now with some excel postprocessing of the raw log file).

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

I think the answer is in TML1CT which is a counter that runs clock speed/4 to measure the time between two RPM numbers.

We can hang the calculation routine where ever in the code and just measure the time between two TML1CT counter values. Only thing to be aware is that after around 20 minutes of engine running the TML1CT resets so the measurement needs to check that counter is increasing. In practise this means that there may be 10ms delay before next adjustment once in 20 minutes...

One place to hang this kind of subroutine is
00005624 bl.s nullsub_27
which looks like it gets executed once per each revolution just before missing crank tooth.

Now as the RPM is not a steady number its propably better to compare RPM average over e.g. 10 revolutions.

I think this solves the next piece in the puzzle - calculating the rpm/second values.... so now just need to check the formulas of how often this needs to get calculated just to keep everything very simple and not to steal valuable processor time.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:



Coming back to the activation algorithm - any suggestions what engine condition should trigger the controls ?

Slipping clutch I dont know if that really is an issue. When looking at MSD logs from their systems, there is no indication of clutch slippage at the beginning of the run.

Clutch is a torque converter during launch - but if torque is limited by this module then clutch can be just dumped ? To get to the point I think we need to talk about launching techniques...

So far I have used a slipping clutch to give a steady RPM at launch, but too often that has resulted wheelspin or when dumping clutch too fast too low rpm off the line with stumbling engine (=reason for getting Hays clutch). I would not mind slew rate with normal clutch as then I just could dump the clutch faster as torque from engine would be limited by this software module rather than the cluch ? ... am I talking sense here ... ???



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

''I talking sense here ... ???''     yes..




__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1247
Date:

The Gen2 has a speed sensor input to the ecu. Is this input actually used by the ecu?
Could this perhaps be used as a "driveshaft sensor"?

This would eliminate the variables associated with the clutch. That said, it would then be a wheel speed sensor which would make it illegal for most all racing.....nevermind.



__________________


Guru

Status: Offline
Posts: 953
Date:

Speed signal goes there but from what petrik said in the past he can find no references to it in the code

__________________


Guru

Status: Offline
Posts: 2338
Date:

Anyone with programming intelligence, please have a look of the below program and please feel free to give feedback. I may have some logic errors in it - so rather get those straightened out before starting flashing testing. That is quite difficult without a debugger for this processor so therefore any hints of errors would be most helpful.

/*

 dragtools.c
 
    This file is part of BusaECUeditor - Hayabusa ECUeditor

    Hayabusa ECUeditor is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    Hayabusa ECUeditor is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with Hayabusa ECUeditor.  If not, see <http://www.gnu.org/licenses/>.

    Notice: Please note that under GPL if you use this program or parts of it
    you are obliged to distribute your software including source code
    under this same license for free. For more information see paragraph 5
    of the GNU licence.

*//* These are the RAM variable addresses that are internal to this subroutine*/#define ECU_AD_GPS *(volatile unsigned short *)    0x00804318 // tested to work with 220 ohm resistor#define ECU_GPS *(volatile unsigned char *)     0x008050B3#define ECU_RPM *(volatile unsigned short *)     0x0080502E#define TML1CT *(volatile unsigned short *)    0x00800FE0 // timer/* Internal variables for this subroutine only, these are borrowed from the ecu ram area using addresses that are considered not having been assigned for any use.*/#define ramaddr           0x00806800 // This is the starting address for free ram area needed for this program/* 00 - 0x16 reserved for shifter *//* 0x18 - 0x60 reserved for boostfuel and nitrous control *//* 0x64 - 0x6F reserved for gen2tools *//* 0x70 - reserved for dragtools */#define counter *(volatile unsigned short *)    (ramaddr + 0x70)#define timer_old *(volatile unsigned short *)   (ramaddr + 0x74)#define rpm_old *(volatile unsigned short *)    (ramaddr + 0x78)#define rpm_tmp *(volatile unsigned short *)    (ramaddr + 0x7C)#define timer_diff *(volatile unsigned short *)   (ramaddr + 0x80)#define rpm_diff *(volatile unsigned short *)    (ramaddr + 0x84)#define rpm_now *(volatile unsigned short *)    (ramaddr + 0x88)#define rpm_rate *(volatile unsigned short *)    (ramaddr + 0x8C)#define ign_retard *(volatile unsigned short *)   (ramaddr + 0x90)

#pragma SECTION C PARAMS //0x5A000
const short const_pgmid =     100;   // 0 program id, must match to ecueditor version to be able to load this code to ecu
const short GEAR1_RATE = 3500;
const short GEAR2_RATE = 3200;
const short GEAR36_RATE = 3000;
const short GEAR1_RETARD = 5;
const short GEAR2_RETARD = 2;
const short GEAR36_RETARD = 1;
const short ACTIVATION = 5000;

#define divider 0x16         // this is the amount of cycles that is used for calculatting average RPM

#pragma SECTION P TOOLSCODE //0x5A100
void toolsmain(void)
{
/*
 Here is the main program.
*/

counter = counter + 1;
if (counter < divider)
{
 rpm_tmp = rpm_tmp + ECU_RPM;
 if (rpm_tmp > (0xFFFFFF - 0xFFFF)) // lets avoid overrunning the numbers just in case
  {
   counter = 0;
   timer_old = TML1CT;
   rpm_tmp = 0;
  }
}
else
{
 rpm_now = (rpm_tmp / divider);
 ign_retard = 0;
 
 if ((TML1CT > timer_old) & (ECU_RPM > ACTIVATION) & (rpm_now > rpm_old))
 {
 
 timer_diff = TML1CT - timer_old;
 rpm_diff = rpm_now - rpm_old;
 rpm_rate = (rpm_diff / (timer_diff>>8)); // this needs to be calculated to rpm/s value, now it is not that

 counter = 0;
 timer_old = TML1CT;
 rpm_tmp = 0;
  
 if (ECU_GPS == 1)   // Gear 1
  {
   if (rpm_rate > GEAR1_RATE)
    {
     ign_retard = ((rpm_rate - GEAR1_RATE)/256) * GEAR1_RETARD;
    }
  }
 else if (ECU_GPS == 2) // Gear 2
  {
   if (rpm_rate > GEAR2_RATE)
    {
     ign_retard = ((rpm_rate - GEAR2_RATE)/256) * GEAR2_RETARD;
    }
   
  }
 else if (ECU_GPS > 2) // Gear 3-6
  {
   if (rpm_rate > GEAR36_RATE)
    {
     ign_retard = ((rpm_rate - GEAR36_RATE)/256) * GEAR36_RETARD;
    }
   
 
  }
 }
 
}

/*
 This is inline assembly put at the end of the code that returns control back to main loop in the ecu code.
*/
#pragma keyword asm on
 asm(
 " jmp R14 \n"
 );

}


 

ps. Speed signal is not connected to anywhere, based on some testing.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

The first release candidate for desktop testing is waiting for one additional piece of information: we need a method to calculate how many timer clicks is one second.

If I remember correctly its 20Mhz CPU runing timer /4. RPM is real rpm * 2.56. Now based on this the timer calculation should be pretty close to the below ???

rpm_rate = ((rpm_diff * 0xC350) / (timer_diff >> 8));



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

nice.....thank you petrik, a lesson, a test, and a challenge from the teacher....i like it....thank you....smile

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

i will study chapter 10.6 clsely...and get familiar with the structure, i wish i had an .idc for ida.......?

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1247
Date:

I have now read the Davis Technologies information a bit. Rather than calculating what the rpm rise rate is per discrete time event (seconds) and comparing this to a discrete RPM value per second,

Perhaps it could read the previous rate and compare it to the current (next) rate.

This comparison could have a set of thresholds;
i.e if it is 100 rpm per unit greater than the last, then retard X amount of timing for X amount of cycles.

if it is 200 rpm per unit greater than the last, then retard X+Y
amount of timing for Y amount of cycles, then continue to retard X amount of timing for . X amount of cycles.

Not sure if I am explaining it as I am thinking it, but basically, removing the normalization of the values and leaving them in terms of the ecu timer rather than converting them into a common value (seconds)

Davis Technology Video


-- Edited by sportbikeryder on Monday 3rd of January 2011 01:30:56 AM

__________________


Guru

Status: Offline
Posts: 2338
Date:

stocker wrote:

in order for "flashing " to be legal, phil davis had to let stand alones to be legal to even out the playing field, especially since the kawi's do not have anything yet......till rr gets his stuff finished......politics.......geez...i have worked hard, many of phone calls, explanations...ect.., plus lots of talks with rr to get his stuff done 30 days before the first race of the season.....playing both teams, hopeing everyone wins....both sides.....plus knowing enough of the "rule book" to see whats up.....???? the m-84 is baddddd.......and some of the algrothims in ee2 and rr's stuff needs to be stepped up......it can be done.......smile


WELL DONE !!!

mirock.jpg


 



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

First small breaktrhough... see how the ignition changes when RPM is increased. This is now downloadable to users for testing. Test procedure after setting values and flashing is: Clutch on, Gear on, rev the bike with clutch in to see if raising rate rpm changes ignition advance.

The RPM/SEC rate calculation is most likely incorrect so that the values needed to limit rpm increase may differ significantly from real world values.

Name:Ecueditor.com for Hayabusa K2-K7, K8-, BKing and Gixxer K7-
 
Version:2.5.0.54








__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

this is exciting news, and i  will be testing in a couple of hours, some family things to do first.......very exciting....biggrin

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Senior Member

Status: Offline
Posts: 148
Date:

This is AWESOME i can't believe that. this software is years ahead!!

__________________

LIFE IS SHORT RIDE HARD



Senior Member

Status: Offline
Posts: 109
Date:

This is fantastic.

Is it possible that, in time, this could be implemented with MS0/MS1 switchability for wet and dry races perhaps?

Can't wait for the weather to get better so I can do some testing....

__________________


Guru

Status: Offline
Posts: 1344
Date:

well great news, it works.....!
1st tried what i thought would be normal values....5000 rpm activation, 4000rpm/sec 1st 5000/sec rest with 5 degrees out.....well it wheelied like a wild horse, so i re-flashed it with 100/sec and 15 degrees out and it activated at 5000 exactly and bucked on the limiter....so some fine tuning next....but i think the town can hear me, and it looks funny with a laptop taped to the tank.....no.....but it works and no fi codes.....

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

well flashed it back to petrik's default values and moved the threshold to 7000 and big power wheelies....no to get the rpm/sec fine tuned....tried to look at laptop on the tank to see the ign timing....but i was too busy wheeling....great job petrik...smile

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Senior Member

Status: Offline
Posts: 498
Date:

WOW!!! Great Work Petrik!!! wink Just don't know anyway else to put it...........YOU SIR ARE AMAZING! smile

__________________
08 Busa AKA: }ToXSicK{


Guru

Status: Offline
Posts: 1344
Date:

i will be testing more this afternoon, as soon as wife get's home to watch our daughter....track testing bike on friday...so hopefully i can find a sweet spot before then...

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 2338
Date:

OK - I will publish soon then a new version where the RPM ramp rates are more realistic.

Could you test the 2 step ignition limiter too ? I am really wondering whats going on with that, so additional feedback would not hurt.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1247
Date:

stocker wrote:

well flashed it back to petrik's default values and moved the threshold to 7000 and big power wheelies....no to get the rpm/sec fine tuned....tried to look at laptop on the tank to see the ign timing....but i was too busy wheeling....great job petrik...smile



Marc, I am a bit confused. How will this prevent a wheelie? I suppose it could be fine tuned enough to do so, but it seems that it may be leaving some acceleration on the table in the process.

 I can certainly see it working for wheelspin, but it seems a wheel stand will always be much more gradual than wheelspin.


Go out and pour some stripes of Beleach on the road at 50 ft increments and run across them at wide open throttle. Where the wheel slips, the software should catch it and retard the timing....  biggrinbiggrin

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

The ramp up rate is one challenge to find, then there is sensitivity (how wide stripe it will catch). Righ now this module uses average over 100 samples, but we can reduce the amount of samples if it does not react fast enough.

We have 25" of snow here, so very glad that you guys have weather to do some runs...




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

i will flash the 2 step also petrik.....john.....i did blow the tire off a few times.....the hook up on the street....the "leaving" of excessive acelleration and the stp mapping slows down the rate in which the tire comes up...thus i can ride out a small...2" frt tire off the ground through first gear....

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 2338
Date:


What we would need next is someone to log with a datalogger how this works, e.g. setting the slew rate limiter to 1000rpm and then log the rpm. Then repeat the same with 2000rpm and 3000rpm if possible.

That way we could calibrate the RPM calculations. When doing the maths I got a cetrtain multiplier of 21 but when doing desktop testing I decided that right multplier should be 25,6 - so there is a margin of error here, or even bit more. Looks like that correct value we can only get with some real world testing.

Also logging the rpm reveals if this really works of if we need to increase the sensitivity.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

just went for a ride with 2 step set to 7000, anti-slip activation at 7000 rpm/sec set at 1600rpms and all works fine, i have 5 different .csv files to see if retard is working....so far it feels like i can get to full throttle faster than before, and the wheelies are more controllable....petrik, will the .csv files work, if not i will datalog with my daydona wego unit...i am impressed so far...biggrin

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

just set 2-step at 7000, anti-slip activation at 7000, rpm/sec at 1400 rpm and 15 deg out, the tps read 70percent open,threw the clutchand,and it left HARD on the street and was able to go to wot ,no tire spin and a small power wheelie ran great all the way to rev limit, then went wot through 4th and bike ran fine, and no fi light.....biggrin

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1247
Date:

This is good news Marc. Great that you are able to test this time of year as well. Our snow just melted due to a bit of a heat wave over the weekend, but I am sure it will return soon.

Any chance you have an area that you can make a run where it will lose traction as you shift into a next higher gear maybe a 2-3 shift), then add traction control and do it again to start to fine tune.



__________________


Guru

Status: Offline
Posts: 1344
Date:

only if i ride in the rain....swb with the hook-up, it is hard to get to spin...

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1247
Date:

stocker wrote:

only if i ride in the rain....swb with the hook-up, it is hard to get to spin...




Good point. If mine was together, I'd put my dyno tire on and could spin it in 6th at 68" if I wanted to.



__________________
1 2 3  >  Last»  | Page of 3  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard